The Professional Project Manager

I’ve completed many project management maturity assessments using the P3M3, OPM3, and 4Q models for clients, and they are a great tool for improving project management success but too many organisations get fixated on the scores that come out of the model. Some organisations think that if they are a 2 they need to be a 3; or if they are a 3 they need to be a 5 (the scale is usually 0-5 with 5 being the highest level of maturity). I know of one organisation that made it clear to the assessor that they would not accept any score less than 4 in any of the assessment areas because that is what their manager expected them to be (despite clearly not meeting the requirements for this). 

The organisation’s that do this, and the consultants that allow it, are missing the point about these tools. The point of any maturity assessment should always be about success, specifically how the organisation defines success, and helping the organisation be more successful. The maturity assessment itself should take a snapshot of current levels of success and also the score from the model – this becomes the baseline. The next step is to work with the client to define what the future level of success should be, and then with this information define target scores in areas that the organisation should focus on to achieve these levels of success – achieving the new/higher scores is just an added bonus. It should always be about success and not about the score - there is a correlation not causation relationship between scores and success.

For example, I have personally seen that it is possible to have a highly successful organisation scoring low 3’s and an organisation scoring high 4’s that wasn’t successful at all due to unnecessary process and bureaucracy. For the first organisation there was room for slight improvement in areas that actually delivered value, and for the second organisation there was an opportunity to become more efficient but doing less.

One of the first questions you should ask when starting a maturity assessment is how successful are you, and how successful do you want to be? If the organisation can’t answer these then they are going to get a low score anyway and they probably have a range of issues to deal with. Once you have this information you can then use the model you want (P3M3, OPM3, & Praxis are all good models) to get scores from 0-5 in multiple areas of portfolio, programme, and project management.

The instead of arbitrarily recommending increases in scores, you need to focus on an increase in success, and use the model to identify the areas (and their scores) that will provide this uplift. The target scores should be focused on being more successful and not just getting a higher score.

And of course, the most important part of any maturity assessment are the recommendations for improvement. These need to be prioritised and achievable given organisational abilities and constraints.

So, if you are considering a project management maturity assessment, and you definitely should, make sure that the focus in on lifting your success rates, and not simply lifting the score.

• Full disclosure, I offer P3M3 assessments and I’ve worked with other models like the OPM3 model and 4Q model.

This article was inspired after meeting a couple of people in situations where they did not have the necessary delegated authority to keep a project moving along, but were being blamed for all the associated delays and issues.

The first was meeting a project manager for a large international IT company several years ago at a conference, where she depressingly told the story that she had no delegated authority at all, and every single change request, had to go to the Change Control Board, which would meet only on Mondays. So, a normal week would be that she would leave the Change Control Board meeting with a list of approved and declined changes, and the team would begin work on any amendments. Then throughout the week a change request would come in and the team would essentially grind to a halt and have to wait to the following Monday for the Change Control Board to consider the changes.

The second situation was working with a client recently and during the maturity assessment we discovered that the project managers had no delegated authority at all. I made the recommendation to the client that the project managers should be given sufficient delegated authority to deal with minor changes and was met with a few conflicting answers about why this wasn’t possible. When I finally pressed them, they revealed that it was because they didn’t trust their project managers. I then pointed to their intranet site, which clearly stated on the first page that their people were the greatest asset and that they trusted and respected them. I am still not sure this contradiction has been resolved. What I do know is that project managers were incredibly unhappy with the situation and believed they would be performed better with an appropriate amount of delegated authority,

These are two extreme examples of what is, in fact, quite a common problem in the world of project management. The problem is the project managers who are experienced, and professional are not being given sufficient delegated authority to receive, consider, and make decisions on relatively minor change requests, or given the authority to get team members when they want them. At best this is inefficient, at worst it could contribute to project failure.

A project manager should have delegated authority that is equivalent to their levels of experience, competency, and professionalism. This means a junior project manager would have minor levels of delegated authority and have the ability to handle very small change requests but probably still have to request resources from functional managers for example. They should always have direct access to the decision makers needed to handle large change requests so that they are not obliged to wait for regular steering committee or governance groups or change control board meetings.

At the other end of the spectrum, a senior, experienced, competent, and professional project manager should have large amounts of delegated authority, and the ability to receive and consider significant change requests, and to get team members when they need them. They should be trusted to make these decisions and report the outcomes of these decisions to team members, the sponsor, members of the steering groups, and other stakeholders.

Too many people get caught up in the idea of the governance group performing a change control function when they’re supposed to be about governance not management nor control. Even if you have separate Change Control Board that is just there to consider change requests it shouldn’t be responsible for all change requests – that’s just an inefficient use of their time, and a drag on the project.

So, make sure you have a clearly defined and documented change control process that includes agreed tolerances and contingencies, and clear and appropriate descriptions of delegated authority to project managers based on their experience and competence levels.

And if you are reading this article thinking that you can’t give any more delegated authority to your project managers because you don’t trust them then you have an issue of an altogether different type, and it is not to do with the project managers.

Have you ever been in a meeting and you’ve thought “What am I doing here, I could be doing real work?”.

Of course you have, we all have. So, what do we persist with attending meetings when we know they probably aren’t the best way to get work done?

Imagine if you had to prepare a business case to have a meeting. You know, outline the expected costs and benefits and only get approval if the benefits outweighed the costs. Maybe that’s what we should be doing because if you want to add up the charge out rates of everyone in a meeting you probably aren’t getting any change out of thousands of dollars an hour. We accept this waste as a normal way of doing business but I bet if you asked for permission to get a thousand dollars cash from the companies bank accounts and flush it down the toilet you would get a solid “no” answer.

Don’t get me wrong, meetings can be a useful way to get decisions made, or collaborate on important issues, or spread information. But they usually aren’t.

Here are some tips to get real value from a meeting (please add yours to the list):

1. First, ask yourself why you need a meeting and if a meeting is the best way to get the work done. Can it be dealt with by an email, a phone call, an intranet post, or a coffee? If you do decide a meeting is the most efficient way to get the work done, then tell people this. I start every meeting I run by clearly stating what the purpose of the meeting is, and what success looks like.  
2. If you have a regular weekly meeting scheduled for your team, ask yourself if its really needed this week. Don’t keep having regular meetings just because they are in your calendar. And please don’t be the kind of team leader who gets each member of their team to provide a quick verbal update to the rest of the team if you have received written reports containing the same information. This really annoys me but it’s surprising how common it is.
3. Then choose the right amount of time for the meeting. How did human evolution end up where 3600 seconds (60 minutes) is somehow miraculously the right amount of time to hold a meeting for. Why not 47.3 minutes, or 67.18 minutes, or 3.142 minutes?? Don’t feel obligated to take up all the time reserved. In fact, nothing makes me happier than saying to people “I’m going to give you back 18 minutes of your day”.
4. Set a day and time that suits everyone you need to be there. No point having half a meeting if some people can’t make it.
5. Start on time. If the meeting invite says the meeting starts at 10am, start it at 10am on the dot. If someone turns up at 10:01am just record their attendance and write “late” beside their name. This may seem picky but once you add up someone turning up 1 minute late, and someone else being 3 minutes late, and someone else being 4 minutes late, you’ve probably waited for up to 10% of the allocated meeting time. Let people know your meetings start on time.
6. Only invite the people for the time they need to be there. If someone is number 3 on the agenda then let them know they can turn up 15 minutes after the meeting starts, and they can leave when they have done their part – or stay on if they are interested. In fact, anyone should be free to leave a meeting if their contribution is not needed.
7. All documentation supplied before the meeting should be taken as read. Nothing wastes time more than someone who hasn’t read the documents or insists on going through them at the meeting.
8. Don’t let two, or three, people have a conversation that they should have before or after the meeting. Don’t let the loud people talk over the quiet ones. Don’t let people dominate the meeting. Make sure people stay focussed, and ask them not to be checking emails etc. In fact if they are they probably don’t need to be at the meeting anyway. Actively solicit contributions from everyone there or otherwise you just get the extroverts talking.
9. Finish on time. If the meeting is due to finish at 11am and its 10:50am, and you can see you won’t get through everything then let people know that you will still finishing on time and you will follow up with people to get the remaining work done.
10. Record really good minutes and action points and distribute them quickly, and make sure you follow up with people before any future scheduled meeting.

As I said at the beginning, meetings can be a useful tool to get decisions made, or work done, but they usually aren’t. Start questioning those meeting invitations, and being brave enough to decline them – simply explain to people that you are focussed on delivering value to the organisation and the meeting isn’t the best way for you to achieve that. And if people persist in sending out meeting invitations ask to see the business case for the meeting :)

What are your tips for a good meeting?

Did you know that, in my opinion, no project ever approved has been approved on the basis of the thing, output or deliverable it will build?

Let that sink in for a moment because for some people that simply doesn’t make sense. Surely that is the entire reason for a project – to build a thing, output, or deliverable? What other reason could there be?

Well, it isn’t, never has been, and never will be.

The reason for the project is to deliver the expected, and desired, outcomes and benefits. The thing, deliverable, or output is simply the preferred method of achieving these outcomes and benefits.  Too many people get fixated on the deliverable and there are handshakes, and congratulatory notes, and celebrations of successful projects one the deliverable appears. Then everyone turns their attention to the next thing to be built.

And that is major contributor to project failure.

Project success occurs when the deliverable produces the outcomes and they in turn deliver the expected and forecast benefits. If you want proof of this simply refer back to your business case, project initiation document, charter, mandate, work order or whatever it is you call the document that captures the reason for the decision to start the project. Sure it mentions the deliverable but it should make it clear what the expectations are around outcomes and benefits.

And this is what Benefits Management is so important to successful project management.

But here’s the thing, there are three important steps to successful benefits management and if you don’t do all three, don’t bother doing any of them. Here are the 3 steps to successful benefits management:

1. Benefits Estimating and Forecasting – this first step is focussed on justifying the investment in any project. It’s outlining the expectations about the outcomes and benefits the organisation is seeking, the costs and risks of achieving them, and then choosing the deliverable best placed to help these be achieved. These can be strategic, operational, financial, non-financial or other forms of outcomes and benefits that are important to the organisation. The key thing is to document them, make them measurable, define roles and responsibilities early for who, how, when, and what?
2. Benefits Tracking – once the benefits have been defined then it’s time to turn your attention to tracking their delivery throughout the entire project lifecycle. Yes, even while things are under construction you should be checking that what you are building is still going to deliver the expected outcomes and benefits. This information should be part of your regular reporting. I’ve always said that there is a possible theoretical situation where you may find the deliverable you are producing is wonderful and shiny and slick and perfect, but you realise it will no longer deliver the expected outcomes and benefits. In this case you should be prepared to change it or cancel the project. The achievement of these outcomes and benefits is the sole reason for the project. Please let me know in the comments if you have actually encountered this.
3. Benefits Realisation – the final of the necessary three steps to benefits management is benefits realisation. Despite it being the final step you don’t leave planning for it until the end of a project. In fact, quite the opposite. You should be defining who is responsible for this, when it will be done, what metrics will be used, what reports will be produced, the time period to ensure full and permanent realisation etc right at the beginning of the project. You should also make sure that appropriate levels of money, time, and resources are allocated to complete the work. Remember that different projects have different time horizons for realisation of benefits – some realise benefits during the project, some upon the deliverables being completed, but many organisations complete projects that can’t check benefits realisation for significant periods of time after the deliverable appears. I’ve often found difficulties for organisations that do not realise their benefits for months or years after the appearance of the deliverable. The main problem seems to be getting agreement on who will be responsible for completing benefits realisation. Is it the project manager, the asset owner, the product owner, the client, the PMO, the regional manager, Bruce from accounts? The answer to this question is unique to the organisation but this often means that it is put into the “too hard” basket. If you don’t do this essential part of benefits management, you will never know if you achieved the expected and forecast benefits and if you don’t do benefits realisation you are giving people permission to write whatever they want in those project initiation documents.

So, stay focussed on outcomes and benefits, define what they are  and how you will check that your decisions are achieving them, and stop being primarily focussed on the thing, output or deliverable.

When I am teaching project management and we get to the subject of lessons learned I often make a joke that if people did lessons learned properly that consultants like me would go out of business – In truth, I’m only half joking. But the point I am making in jest is that if companies fully committed to gathering and learning from lessons they wouldn’t need half the advice that consultants bring to the table.

But here’s the thing, there are 3 important steps on the lessons learned process and if you aren’t doing all three you may as well not do any of them.

Here are the 3 steps:

Step 1: Lessons Gathered

This should be a continual effort throughout the life of the project and not just done at the end. You should be regularly asking team members and stakeholders, regularly collecting data and analysing it, regularly holding formal and information sessions all focused on gathering lessons.

Don’t forget that you should be gathering both the good and the bad. Too many people focus on gathering lessons about what went wrong and make the assumption that if you find out what went wrong and do the opposite in the future that somehow you will be doing what’s right – this logic simply doesn’t stack up. Learn to avoid the bad, not do the opposite of it. Learn about the positives and what worked and replicate that in future. Gathering lessons learned should be an accepted and expected practice throughout your entire project lifecycle.

Step 2: Lessons Stored

If you gather the lessons learned and don’t store them, or don’t store them where people can access them, there is no point in gathering them. You need to be able to store them somewhere highly visible where everyone who needs to see them can easily find them, search them filter them and actually learn from them. I’ve seen companies using Excel for this very well, and I’ve seen specialist pieces of software that allow filters, and meta tags, and keyword searches as well.

But I’ve also seen companies gather lessons learned and then store them deep in a sub-folder in the project folder where no one will ever know about their existence. This is pointless and they could’ve just avoided gathering them for the benefit they will bring.

So, please, make sure you have an easily accessible and searchable repository for your lessons learned.

Step 3: Lessons Learned

If you do steps 1 and 2 and don’t actually learn from the lessons then there is no point in doing the first two steps. Learning the lessons and applying them in the future is the key to getting better.

You may have the opportunity to apply lessons learned on the current project to improve its future prospects. You will definitely have the opportunity to learn from the past on future projects and you need to make sure you are actually doing this. Here are some tips to make sure that you apply the lessons learned and reap the benefits:

1.    Insert a section into your project initiation documents that ask “what have you learned from recent similar projects, and how will you apply these lessons to this project?”. This means that right at the beginning that the database has to be consulted and lessons applied to the current project.

2.    Make it a standing item on governance groups agendas. Ask about lessons gathered, stored and how they have been applied to the current project.

3.    Get people to regularly present to others to share the knowledge or put up posters each month showing valuable lesson learned.

4.    Do some data analysis, such as Pareto analysis, to determine which lessons provide the greatest value.

5.    Prize and reward continual improvement and value the time, money and effort spent in gaining individual and organisational wisdom through lessons learned.

So, make sure you are gathering AND storing AND learning from experience to get the full benefits.

On a final note, I can guarantee you that if you do gather, store, and learn from experience you will get better at delivering your portfolios, programmes, and projects.