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 depth of knowledge 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 methods and tools applied, but regardless of those, there are consistent underlying problems.
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 one of the biggest opportunity areas for improvement.
I’ll start from where project managers are strong; methods and tools. Project management seems to attract people who are organised and enjoy structure and detail. They feel confident about studying approaches and tools and applying them to their projects. I often see a huge focus on topics such as:
- Documenting the project e.g. writing scope statements;
- Drafting plans including the very popular GANTT chart;
- Preparing lists; issue lists, problem lists, change lists, stakeholder lists etc.
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 strategy and people.
Strategy can be challenging in many ways:
- It’s difficult to access senior people responsible for strategy;
- Strategy information is often not well deployed through an organisation;
- To understand strategy requires a broad view of business, many project teams suffer from a silo focus on functions or technologies.
Ensuring you understand corporate documentation on strategy including annual reports or internal communication packs are a good start, but ideally you want to understand the nuances that senior management are focussed on.
Anthropology is a huge topic of it’s own. Why do people behave the way they do? This requires developing observational skills and experience of how to intervene in various situations.
As a starting point just being aware that people are a factor and taking this into consideration can make a difference.
Project management – where’s the people advice?
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:
- Scope a piece of work;
- Estimate effort and put together a team;
- Create a work breakdown structure and draft a plan;
- Plan and execute the stages of a systems development lifecycle;
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 successfully. 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 little power over them.
Not all of the individuals on our project team will care about project success. Some may even be against it.
The question that none of the project methodologies would answer
As I started leading projects one challenge came up over and over again, and it appears very simple:
How can I get people that don’t work for me to do things?
I read the PMBOK from PMI, I read websites on Prince2, I studied my employer’s internal project management methods, I read our software vendors methods, I read various books, including the ‘project management for dummies‘; which I thought was very good.
In my opinion none could provide a satisfactory answer through the methods and tools listed. To illustrate the point; a google search for the PMBOK contents shows the 6th version of it as covering:
- Section 1: Introduction
- Section 2: The Environment in Which Projects Operate
- Section 3: The Role of the Project Manager
- Section 4: Project Integration Management
- Section 5: Project Scope Management
- Section 6: Project Schedule Management
- Section 7: Project Cost Management
- Section 8: Project Quality Management
- Section 9: Project Resource Management
- Section 10: Project Communications Management
- Section 11: Project Risk Management
- Section 12: Project Procurement Management
- Section 13: Project Stakeholder Management
The titles alone show a lack of focus on strategy and people. I realise some aspects of strategy and people are considered in the sections above, but it’s not enough. I would propose chapter one should be about strategy and chapter two should be about people.
Scope, time, cost and quality relationship
An often cited relationship in project management is 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, to 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:
The way you work with people has a relationship with scope, time, cost and quality. If you use people well (with the same no. of resources and hence cost) you can deliver more work, faster and with higher quality.
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.
People problems – diving deeper
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 complete a project. A huge amount of time and effort is spent on managing resistance, and justifying actions etc.
The starting point is to consider the source of resistence:
- Team members don’t think project managers are experienced enough;
- Team members don’t like project managers telling them what to do;
- Team members simply don’t like their project manager;
- Team members think they are better qualified to be the PM;
- Team members think that the project is a distraction to their work;
- Team members are too busy;
- Team members believe the project puts their job or position at risk;
- Team members have managers who don’t support the project;
- (the list goes on…)
Often; if you make a list of resistance 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.
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 methodologies tend to try to deal with getting things done through estimation, planning and monitoring:
- Build a plan;
- Regularly monitor progress on the plan;
- Report status and escalate tasks that are behind schedule.
This can help organise work and ensure it’s clearly convey what is required. However it’s not always effective at making sure work is done on time and with quality. Examples:
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 inaccurate. There may be task owners who work diligently 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:
- By the time escalation can happen there is already a delay;
- On bigger programs sponsors and stakeholders can be demanding; in some circumstances project managers are expected to not escalate things to management;
- In some cases the task owner that should be escalated may be connected to a stakeholder who is unsupportive of the project. Escalating can cause relationship levels at the executive level.
A people orientated approach
This is why I recommend a ‘people’ focussed 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:
1) Identify problem people
I suggest spending some time to think through the project organisation and identify people who may cause a problem. Make sure to consider the full time project team members as well as the extended team composing of stakeholders, operations representatives and third parties etc.
As you think through this categorise people into the type of problems they have or might cause. The list from “people problems – diving deeper” above could be a starting point.
In stakeholder analysis there are many approaches to consider stakeholders and categorise them as either “for” or “against” the program, these methods can be applied to the wider team.
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 people’s 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:
- What’s their reputation in the organisation?;
- Are they difficult in general, but they deliver, or do they fail to deliver?;
- Are they a peer, how do they feel about being ‘on your project’;
- Career – are they happy in their role, are they trying to move out of it;
- Are there any non-work items that might impact their contribution to the project (take care with respect to human resource sensitivities).
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 intervent.
In the personal example I gave above I had peers who were uncomfortable working under my project leadership, my approach was to:
- Subtly message that I don’t see it as a leader/subordinate relationship, I see them as an equal and I need/value their input;
- Giving them space to do their own work (where I trusted their capability);
- Showing my value by helping them resolve any problems they were having, or making minor adjustments to the plan to help them out.
There are different views on the role of project managers. I’m sometimes surprised by some project managers who seem to 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 was often hired by senior stakeholders, but working with people more junior staff. Many people have a bad impression of consultants or feel that consultants are there to steal their job. I’ve been in this position many times. On one project with a multinational 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 approach to joining the project was to disagree with and complain about everything. To leverage his skills and remove the conflict I asked him to take a lead role in facilitating the architecture for Europe. This allowed the project to get the benefit of his expertise while still providing our ideas and also allowed him to 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:
- Get them on-board with the conceptual objective of the project;
- Build mutual respect;
- Give them space;
- Bring them more on-board, give them bigger responsibilities;
- Help them with their challenges/issues in their own tasks;
- In the worst-case scenario de-scope or limit the impact of the project on their areas, to make success possible even without their cooperation.
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 as your existing team members.
Focus on strategy alignment
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.
Example – project managing an ERP and CRM system upgrade during a period of high organic growth
A business is upgrading their ERP and CRM systems. The existing systems are:
- Technically slow;
- Have a number of problems with effort-intensive workarounds in place;
- Do not feature modern capabilities.
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:
- Replace the existing system without out any negative impact to the business;
- Resolve workarounds caused by existing systems;
- Deliver new features to help modernise sales and customer service processes.
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 significantly 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.
Note that it’s typically a major problem in strategy projects that executive committees will take on too many change initiatives. 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 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:
- What’s the priority between the different elements of driving growth, vs the various projects underway;
- What’s nice to have vs. must have;
- For the resolution of workarounds – what is the value of solving each problem?
- For the enhancements – what is the value of each enhancement?
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:
- In years 1 – 3 cash flow or cost is not a concern for the organisation, but they envisage a downturn on year 4 and onwards;
- Quality is critical for the organisation, any loss in service levels is unacceptable;
- The shared services have to be scalable to support long term growth;
- Because the business is currently doing well, they should avoid any major disruption in the current period.
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.
Common mistakes in project management
To make this article useful I’d like to cover a few of the most common mistakes I’ve seen in recent years and some tips. In keeping with the theme, these are mostly connected to what project managers focus on and how they deal with people.
Death by project admin
A good PMO should be somewhat invisible. All project quality measures should improve with a reduction in 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:
- Using complex and long-winded formats of project templates and tools;
- Taking a highly theoretical approach and following e.g. PMI by the book;
- Long meetings with a large number of attendees;
- Focussing more on the project management method that the project work;
- Complex review and approval;
- Overstaffing – there are studies that show as teams get bigger they can do less.
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.
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 messages. 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 the actual list.
Using project management tools as communication formats can create an environment of ‘complexity’ and ‘stress’ by pushing too much content to people.
Inserting PMO between leadership and teams
In the past 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.
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:
- For stakeholders or extended stakeholders an initial briefing consisting of 1-2 slides clarifying the objective, the key dates and the impact to them;
- For the full team a weekly summary of tasks due that week;
- For intensive projects or phases within a project a daily standing scrum can be an effective way to keep communication flowing in an efficient amount of time.
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.
Document and confirm 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 diligent and your actions correct.
- Document all actions and agreements (concisely);
- If verbal agreements occur follow up with a brief e-mail to confirm;
- Carefully archive all key agenda, minutes, e-mails etc. so you can access when needed;
- Think like an auditor. Make sure to ask your stakeholders or peers or whoever is best for feedback on plans, risk lists etc. make sure people had an opportunity to input. This removes the opportunity to blame.
I don’t advise playing in ‘politics’ but I do advise protecting yourself from ‘politics’.
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 resources w/out the correct expertise 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 areas early. They are normally either in the most complex technical part of a new product or the busiest function/team.
Change management – avoiding 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 mis-used 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:
- A change manager joins a project team and immediately requires a lot of time from the project manager and other team members to educate them;
- The change managers work directly with senior stakeholders, sponsors, and business leads and add an extra layer between those people and the project team reducing communication and clarity in a critical area;
- Sometimes the approach taken by change management can help make people feel good but have no solid benefit in terms of what the project delivers.
Change managers should not replace what the project manager should be doing. It’s critical that project managers lead stakeholder involvement and communication, change managers can assist and consult, but should not be another level in the organisation chart hierarchy.
Learning resources to improve people management skills for project managers
I’d recommend applying tools like ADKAR to your project
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 trying 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.
I’d recommend picking up some books on leading change, influence, persuasion. There are lots 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.
What do you focus on when you working as a project manager? What do you see as missing skills or issues that come up repeatedly on projects?