Improving project management by focussing on strategy and people

by Alex Roan on Jun 9, 2020

Many of the projects I’ve come into contact with over the years run into problems that stem from a lack of focus in two areas. A lack of ability to effectively deal with people. And a lack of understanding of strategy.

I’ve been around projects for almost 20 years. Working in roles such as systems analyst, business analyst, project manager, program manager, management consultant and change manager. During this time I’ve seen a wide variety of project methodologies put to use, but despite this, there are consistently issues with people.

The profile of the project manager is critical to a projects success. What experience do they have? what do they focus on? what tools do they use? how do they manage conflict? a good project manager needs a wide variety of skills.

If I were to estimate I would say around 1 in 5 projects that I come into contact with have good, multi-faceted project managers. The good news is we can all become better project managers and in this article I’d like to address two of the biggest opportunity areas for improvement.

As a starting point I would say that project managers are generally strong in methods and tools. Project management seems to attract people who are organised and enjoy structure and detail. They feel confident about learning methodologies and applying them to their projects. I often see focus placed on topics such as:

These are very important. However having these in place doesn’t mean a project will be successful. In some cases an over reliance on these may cause problems.

The areas I don’t see enough focus on are how the project connects to strategy and how the project deals with people.

The connection to strategy

Strategy can be challenging in many ways:

To understand strategy well a good starting point is an annual report or an internal communication pack. But often this isn't enough, to understand the nuances it's key to have the right relationship with the right stakeholders.

How the project deals with people

How do we get people to work effectively on a project?

We have to think about anthropology; a huge topic in it's own right. Why do people behave the way they do? To start with we need to practice observing and we need to gain experience in making interventions.

Part one: effectively dealing with people on projects

My path into project management will be somewhat familiar to many. I spent three years working as a systems / business analyst before being given the opportunity to manage my first project. I was both excited and scared about the prospect of becoming a project manager.

I had enough experience to know how projects worked. I had worked under good project managers and because of this I felt comfortable with the tools and methods. I had a solid understanding of how to:

Despite this I was nervous about taking on my first project. The root cause of my nerves came down to the dependency on people. When we work as an analyst we can rely on technical skills and effort to deliver our work successfuly. When we switch to project management it’s a completely new paradigm, we suddenly need to rely on a disparate team of individuals for success.

This is not the same as becoming a team leader. As a team leader we have levers such as career management, performance reviews etc. to build a relationship with our team. A project manager is in a unique position of relying on a team of people, while often having very few levers to use; be those levers carrot or stick!

Not all of the individuals on our project team will care about project success. Some may even be against it.

A simple question that the project methodologies don't clearly answer

As I started leading projects one challenge came up over and over again, and it's very simple:

--How can I get people that don’t work for me to complete their tasks on time with quality?--

I read the PMBOK from PMI. I read websites on Prince2. I studied my empoyers internal project management methods. I read our ERP software vendors methods. I read various books, including even the dummies guide to project management (I thought it was quite good!).

A picture showing several project management books and guides

(books / versions shown only for illustrative purposes)

In my opinion none could provide satisfactory advice on how to get people to complete their tasks on time and with quality. To illustrate the point, a google search for the PMBOK contents shows the 6th version as covering:

The titles alone shows a lack of focus on people. I realise some aspects are considered in the sections listed above, but it’s not enough. I would propose chapter one should be about strategy and chapter two should be about people.

The scope, time, cost and quality relationship

An often cited relationship in project management is scope, time, cost and quality:

An illustration of a triangle with scope, time, cost and quality

The idea being that the relationship between the the four are tied. For example if you have a delay (a problem with time), you may be able to reduce scope, and still hit your deadline. Or alternatively bring on extra resources (increase cost).

If you observe projects in practice I think this simply isn’t true. There are more factors that influence the relationship between these things. As a starting point I would re-draw it like this:

A more complex illustration showing additional points; strategy and people

The way you interact people has impacts scope, time, cost and quality. If you work well with people (with the same no. of resources and hence cost) you can deliver more work, faster and with higher quality.

As for strategy, if you have a clear understanding of the strategy your project supports; including the nuances of what the stakeholder wants, you can focus more accurately and provide better quality given the same scope, time and cost. It could be argued that ‘directing focus’ equates to managing scope, but I think this is too nuanced to be bundled in with scope management.

Effectively managing people on projects

So far, I have spoken in conceptual terms. I’d like to go into some detail based on my own experience. In one of my first projects part of my team consisted of peers. From the first team meeting my peers decided to challenge me on various aspects of the project approach. Understandably the mindset of some team members at the start of a project might be, “why do we have to work for this person?”.

Dealing with resistance is a very common issue. If a project simply had to execute it’s planned deliverables the effort would be vastly less than what it often takes to execute deliverables and deal with resistance. A huge amount of time and effort is spent on managing resistance, this takes the form of justifying actions, preparing extra explanatory documentation, holding debates, giving presentations etc.

The starting point is to consider the source of resistance:

Often; if you make a list of resistances affecting your own project, you will find very few relate to a lack of capacity. Many are emotional. Some are related to fear; which can be founded or unfounded. Some are political. It's important to uncover these and deal with them.

Regardless of the reason for resistance the challenge remains the same:

How do we get people to do something they don’t want to do?

What the methods say

Popular project management methologies try to deal with this by using estimation, planning and monitoring:

This can help organise work and ensure a clear work plan is in place. However it’s not always effective at making sure work is done on time and with quality. To illustrate let's discuss two ways this should help drive task execution:

Tracking task completion – assume there are tasks such as ‘map process’, ‘write development spec’, ‘build development’, ‘run integrated test’. Some project managers will regularly ask task owners for progress updates in the form of percentage complete. The percentages that are collected will often be innacurate. There may be task owners who work dilligently to provide accurate progress reports, but there will also be task owners that provide false percentages and leave work until the last minute. With larger projects there isn’t time to micro-manage and check honesty. This can lead to finding delays only at the deadline which can have a critical path impact and cause a project delay. I recommend not to allow percentage completion tracking on tasks, consider them either done or not done. Keep pressure on for completion prior to deadlines.

Reporting status and escalating tasks which are behind schedule – another way to get tasks done is through escalation. There are a number of issues with this:

A people orientated approach

This is why I recommend a ‘people’ orientated approach. This is not rocket science. We all have skills in dealing with people, we learn these naturally as we grow and live. We just need to be conscious of people as a focal point and apply some consideration to them in our project management. A simple process might look like this:

An illustration showing four phases which are described below

Phase 1: Identify the problem

I suggest spending some time to think about each individual involved in the project and to identify people who may have resistance or cause problem. Make sure to consider the full project team.

As you think through this categorise people by resistance type or problem type. The discussed above may help.

In stakeholder management there are many approaches to consider stakeholders and categorise them as either “for” or “against” a program, and then work through communication strategies and risk mitigations to deal with them. These methods can be applied to the wider team.

Phase 2: Understand their perspective

The next step is to put yourself in their shoes. Often you may find that their ‘problem attitude’ is warranted. Putting yourself in other peoples shoes is one of the most useful business skills, this will help you tailor your presentations and discussions to gain buy in and resolve conflict in many situations.

Questions to consider include:

Phase 3: Plan an intervention

After you’ve identified people that need attention and understood what is motivating them you can start to think about how to intervene.

In the personal example I gave above I had peers who were uncomfortable working under my leadership, my approach to deal with this included:

After a short term their attitude to the project improved and our things went smoothly. In my experience sometimes you can convert your biggest problem to your best ally.

There are different views on the role of project managers. I’m sometimes surprised that some project managers think they are the most important person and should be served by their team. I personally believe project managers are there to help the team succeed.

Another example. As a management consultant I've been hired by senior stakeholders, but then assigned to work with their teams. This is a common scenario where sometimes the teams may resent the presence of external consultants. People sometimes have a bad impression of consultants and may feel that the presence of them is a threat to their expertise or position. I’ve been in this position many times. On one project with a multi-national financial services organisation we were designing a new pan-european business unit and accompany technical architecture. We had one highly skilled technical architect from the client’s UK firm. His initial attitude upon joining the team was to disagree with and complain about everything. To leverage his skills and remove the conflict I asked him to take a lead role facilitating the architecture for Europe. This allowed the project to get the benefit of his expertise. We could still provide design ideas as consultants. The team member could also signal to his management that he was making a valued contribution.

In general I’ve found that with problem people the following actions can work:

Phase 4: Monitor and adjust

As you work through the project continue to monitor resources that are coming on or going out of the project as well your existing team members.

Part two: focus on strategy alignment

I talked quite a lot about people, I'd like to now cover the second area. The understanding of strategy and the degree the project execution is aligned to it.

Project managers may not be involved in strategy development. This means they may never see a study or business case that led to the project they are being asked to manage. This can lead to project managers having only a rudimentary understanding of the objective.

This doesn’t empower the project manager to make nuanced decisions on where to focus effort, what risks to accept and other similar topics.

I think it's best to illustrate this with examples. These are based on real life projects.

Example: An ERP and CRM systems upgrade during a period of high growth

A business is upgrading their ERP and CRM systems. The existing systems are:

This is a must do project to provide stability for operations and reduce effort spent on manual workarounds.

In parallel the company is experiencing strong organic growth. They are currently hiring in the sales and customer service areas, creating new teams and opening new sales offices. Management are also considering small acquisitions.

The program managers for the ERP and CRM systems may have written objectives summarised to:

If the program manager only considers their own work and has limited interaction with the executive team, they may take a very rigurous and comprehensive approach. They may plan to push the organisation to do everything in it’s power to maximise the benefit of the new ERP and CRM system.

But is this the right approach?

While this is excellent in terms of getting the highest value out of the new systems this approach could require significant effort requirements from operations and be very disruptive.

The result of this could be an impact on how well operations are maximising the value from the growth period they are in. The project may distract them from driving sales, on-boarding new hires and setting up the new teams.

The value gained from the ERP and CRM initiative may never pay for the potential value lost in focussing on business as usual in a growth phase.

Further, in this scenario where we have multiple things happening at once – there is a risk of over-loading people, which can lead to key employees burning out or leaving.

A note on strategy - Executive committees tend to overestimate their organisations ability to successfully execute initiatives. This means most organisations will have projects that fail to deliver. Therefore I believe it’s critical for project managers to know where their project sit’s on the list of priorities so they can resolve conflicts with other initiatives in the best interest of the complete organisation.

If the program manager for ERP and CRM in this case has a good relationship with the executive and a good understanding of the strategic priorities they can steer their program to best help the organisation. Things to consider:

With a good understanding of all of the work underway in an organisation and how it connects to strategy a project manager can minutely adjust their scoping, phasing and solution to better support the overall priorities of the business.

This could be as simple as not fully training teams on enhancements during a busy period and activating them later on a schedule over a number of months.

Example: building an offshore shared service centre

Consider a company is setting out to open an offshore shared service centre. A high level business case was created. It defined an offshore location. It also defined a rough order and timeline for the transition of different teams. The program managers start the work based on this plan.

The program manager creates a detailed plan to execute. Whilst moving into the detail a number of issues can arise which make certain parts of the original plan difficult to execute. The project manager can move ahead with brute force and try to execute in line with the business case.

However, if the project manager makes the effort to understand the principles behind the business case and the perspective of the executive committee they may find factors that open up more options, such as:

With this perspective it starts to become clear that the order of transition of teams is not as important in year 1 and 2. The quality of the platform and the stability of the transitions is important for the long term. With this strategic background the project manager can better plan alternate transition scenarios to avoid issues and present options to the stakeholders.

Part three: common mistakes in project management

Strategy and people are by no means the only areas where project management tends to lack focus. Each project is different and each project should have an approach that is optimised to it's particular situation. But keeping to the theme of how project managers interact with people I'd like to provide a list of common mistakes that may be useful in helping project managers think about their approach. These are all things I've seen multiple times in recent years.

Mistake 1: Death by project admin

A good PMO should be somewhat invisible. All project quality measures should improve with a reduction in project management effort. One of the most common mistakes I see being made in project management is using what I call a ‘heavy’ PMO. By this I mean:

I’ve seen teams where for every 1 person doing an actual project task there are 5 people doing ‘project methodology’ work – writing updates, hosting meetings etc.

I believe that certain aspect of agile and scrum are useful in minimising project admin and re-focussing on project tasks.

Mistake 2: Using project tools as communication tools

Long winded project initiation documents, GANTT charts and detailed issue logs are not communication tools. They shouldn’t be shared widely. They are planning tools for project managers and PMO.

For communication use simple, clear and targetted messags. If you want to present a project plan to stakeholders you can share a summary of the critical path elements. To illustrate effort and complexity you can reports statistics on the total no. of tasks planned, in progress, completed etc. they don’t need to see actual list.

Using project management tools as communication formats can create an environment of ‘complexity’ and ‘stress’ by pushing too much content to people.

Mistake 3: Inserting PMO between leadership and teams

Last year I set up a PMO to help the leadership of an organisation manage 7 different programs.

One of the mistakes the PMO lead made was with the handling of the weekly review with leadership. The approach they took was to gather the status information from 7 programs and then present that to the leadership. This was a disaster for several reasons:

The PMO trying to understand and repeat details of 7 programs each week is wasted effort (remembering the are not domain experts this is very hard); The PMO couldn’t answer questions, or commit to actions from the leadership; The individual programs do not get direct access to ask the leadership questions or to get direct instructions / context from the leadership.

In this case the PMO should have been the chair of the process and the meeting. The should ensure each program brings an appropriate update and presents it and they should make sure questions and follow up actions are managed.

I recommend trying to create a flat project structure where even the most junior resources can access messages from senior stakeholdres. Of course this has to be expertly facilitated.

Mistake 4: Under-communication

Project teams often communicate either incorrectly or not enough.

It’s important to keep everyone involved or impacted by a project appropriately briefed. A few suggestions:

Frequent meetings can be important for certain projects, but they shouldn’t take a lot of time.

I recommend avoiding situations where large groups of people are sitting working through Gantt charts or excel lists together, this can be time consuming and de-energizing etc. Try to limit attendance to meetings to those that need to be there.

Mistake 5: Not documenting all actions and agreements

At some point in your career as a project manager things are going to go wrong. If you are unlucky it will be something serious. Not everyone plays nicely in business and you should be ready to prove your approach was dilligent and your actions correct, make sure to:

Don't let yourself or your team become a scapegoat. I don’t advise playing in ‘politics’ but I do advise protecting yourself from ‘politics’.

Mistake 6: Too many resources

When projects run into trouble extra resources are often onboarded. It’s important to remember that there is an optimum effective team size. It’s also important to recognise that adding resources without the correct exertise and experience may slow projects down. Project progress is normally limited to a certain number of people that are “bottlenecks”. Make sure to identify those people early. They are normally either in the most complex technical parts of a new product or the busiest function / team.

Mistake 7: Avoid one danger of using change managers

As a final topic I’d like to address change management.

Change management is often connected to strategy, people and communications. I believe that one of the reasons change management has become popular is due to the gap in skills displayed by project managers.

Change managers can be excellent and can have a very important role in a project, but when misused they can cause a lot of problems for a project.

The situation I would urge organisations to avoid is adding an extra level of change management between project managers and stakeholders this can result in a lot of extra effort for project teams and also a reduction in the amount of information they receive from stakeholders.

On more than one occassion I’ve seen the following happen:

Change managers should not replace what the project management should be doing. It’s critical that project managers lead stakeholder involvement and communication, change mangers can assist and consult, but should not be another level in the organisation chart hierarchy.

Learning resources for people aspects

Prosci ADKAR

I’d recommend applying tools like ADKAR to your project

A picture of the PROSCI ADKAR model

ADKAR is often used with management teams, stakeholders or customers to check if they understand and can contribute positively to change. The diagram shows the ideal timing to apply ADKAR steps, but you can start with them at any time.

I highly recommend using Awareness and Desire. You can use these to run interviews, surveys, brainstorming sessions with your team. I recommend using them with all team members not just management.

In awareness you can investigate how much your team really understands what you are tyring to do. This can be excellent in helping refine the focus of your team members to what is really important.

With desire you can easily help team members find out what is in it for them. You can also find out why they might not be behind the project.

Others

I’d recommend picking up some books on leading change, influence, persuasion. There are lot’s of great titles amongst the lists of top business books.

I’d also recommend that where possible try to identify a role model. Someone who can lead work effectively with people. This doesn’t need to be an active coaching relationship. A lot can be learned just from considered observation.

Final thoughts

What do you focus on when you working as project manager? What do you see as missing skills or issues that come up repeatedly on projects?