The Professional Project Manager

Survivorship bias is a logical error that focuses on the survivors of a particular process, while overlooking those that didn’t make it. In the context of project management, this can lead to misguided conclusions about what it truly takes for a project to succeed.

The term "survivorship bias" originates from wartime observations when aviation experts examined planes that returned from battle in WWII to identify where they had taken the most damage. They mapped where all the damage was found and then with this information they considered reinforcing these areas to make the planes more resilient. However, a statistician named Abraham Wald pointed out a flaw in this approach. The planes they were examining had survived, despite their obvious damage. It was the planes that didn't return—those hit in other critical areas—that needed to be studied. By only looking at the survivors, they were missing vital data on the planes' vulnerabilities and in fact had they gone ahead they would’ve reinforced areas of the planes that didn’t need reinforcing, and not reinforced areas that did.

How does this relate to project management?

Imagine you want to discover the secret to successful project management (and who doesn’t?). You might be tempted to analyse only successful projects and identify common factors in them (like mapping damage to aircraft that made it back). You then describe successful project management according to these traits of these particular projects and focus your training on these processes, tools, techniques or competencies. On the surface, this seems logical right?

But here's the catch: by only looking at successes, you're missing out on a vast amount of data from projects that failed (the planes that didn’t return, and the reasons they didn’t return). These failures can offer crucial insights into pitfalls and challenges that successful projects either avoided or overcame (sometimes by dumb luck!).

Fortunately for us the world of project management is littered with failures. In fact, it could be argued that the ‘norm’ in project management is failure – after all, most projects are somewhat unique, and subject to a myriad of constraints and risks. I’ve never shocked at those oft repeated statistics that 60-70% of projects fail, often used by people to ask what is the point of professional project management when this figure hasn’t changed over 10 or 20 years. I always think that the number is a constant because that’s just what projects are – failure magnets – and yes, that’s a topic for another post but chime in on this if you want.

Success is not just a product of hard work, planning, and strategy. Sometimes, it's also about being in the right place at the right time – plain old dumb luck. Recognizing the role of luck in project success is essential. Also, don’t discount the role of external factors beyond the control of the project manager. Two projects could be managed similarly, but external factors, timing, or sheer coincidence could lead one to thrive and the other to flounder.

For instance, a company might initiate a project to launch a product just when there's a sudden surge in demand due to unforeseen circumstances, making the project seem brilliantly managed and executed. Another similar project might face unexpected competition or market changes. Is it fair to label one as superior management and the other as lacking, without considering the impact of luck, coincidence, or external factors?

And that’s why it’s important to analyse and learn from success AND failure. So yes, I’m saying celebrate failure as a learning opportunity. I’m not saying throw a party, give bonus’s and promotions, and advertise to your clients how wonderful you are at project failure. I’m saying, treat them as real opportunities to learn something that will help you be more successful in the future.

So don’t fall into the trap of survivorship bias. We all want to be more successful at delivering projects but to truly understand project management the factors that contribute to project success, we have to consider both the winners and the losers. So, maybe at your next monthly community of practice meeting, or your next post implementation review, or your next portfolio planning session, take time to have someone present about failures and what they learned from them. Do this without judgment, compare it to what you learn from successes, and you are probably on your way to discovering what makes your projects successful (oh, and please take time to really define project success and how you will measure it – again, that’s a topic for another blog, but chime in on this if you want).

As a consultant who works with organizations around the globe, I get to see many forms of a PMO and I get to see what works and what doesn’t.  A well thought out and value adding PMO can add measurable strategic and operational value to any organisation regardless of its size or maturity. Getting the right PMO for your organization can be a challenge and I want to share with you some thoughts and observations on what exactly a PMO can be. Hopefully from these thoughts you can take some tips on what your PMO should be.

Let’s start with what do the letters “PMO” stand for? Well the “P” can stand for Portfolio, Programme or Project. The “M” and the “O” generally stand for Management Office. You can add an “E”, for Enterprise, in the front to get an EPMO to indicate it stretches across the entire organization. You can have individual PMO’s that answer into an EPMO. It can even not be called a PMO at all, and there are many other names it can go by. You can call it what you want as long as the name is an accurate representation of what the function actually does.

Answering the question about what a PMO can be takes a bit more time. It is not a single standard format you can apply to your organization which makes it a little hard to define appropriately. The easiest why I have found to describe, at a high level, what a PMO is, is that it should be the center of excellence, whatever that means, for professional project management in your organisation to support the current and future portfolio, program and project management aspirations of the organisation. That is a long winded way of saying that your PMO should support what you currently do but also take you into the future and a better, more mature state.

At one end of the spectrum I have seen a very low maturity organization have a ‘PMO’ that was as small as a few ring binders with templates in it that were regularly updated. At the other end of the spectrum I have worked with large and complex PMO’s which can be a fully separate and resourced unit that does full portfolio management, strategic alignment, governance, project selection & reporting, and also employs, deploys, & trains all the project management personnel. Somewhere between these two extremes is the PMO that is right for you and your organization.

Here is a list of functions that a PMO might consider:

• Governance and sponsorship
• Developing standards, methodologies, processes, tools and templates
• Maturity improvement
• Strategic alignment
• Project selection
• Full control and reporting of all initiatives
• Assurance
• Benefits management at all levels and at all stages
• Programme management
• Allocation of project management resources
• Recruitment of project managers
• Training and development of project managers

What have I missed?

These are the types of things to consider when thinking about introducing or upgrading a PMO:

1. Maturity of your organization – a low maturity organization may want a PMO that helps it increase in maturity in specific ways, while a high maturity organization will want a PMO that supports and maintains its high level of maturity.
2. Size of your organization – larger organizations generally need a larger and better resourced PMO
3. Complexity of the work that you do – the more complex the work that you do the more complex the PMO will need to be to support your efforts
4. C-Level understanding and support – without full support from senior and executive management your PMO will never be considered a full-time part of the organisation.

Unfortunately, the research tells us that there are many threats to a PMO and its success. These include the following:

1. Making a PMO a bureaucracy
2. Not proving the value a PMO brings to the organization. The PMO, whatever its form and name, must deliver real value to the organisation, and not be afraid to tell everyone how good they are. I’ve seen great PMO’s fail because they kept their success to themselves
3. Lack of senior management support
4. Tough financial times – it seems that when finances get tight for an organization the first thing to go is the PMO
5. Trying to be everything to everyone – focus on what you do well, and just do that
6. Being under resourced and overworked and letting everyone down
7. Looking backwards at what you have accomplished and not looking forward to the value you have yet to create
8. Assuming a PMO is static – a PMO should change with the organisations needs. If your PMO is the same as it was 2 years its probably out of date.

Just a reminder, this is just a high level introduction to the PMO. There has been plenty of research done on the topic and if you are academically minded you can easily find some serous pieces of research out there on the topic. There are also many people more on projectmanagement.com who I know would love to share their experiences, both bad and good. So don’t be afraid to reach out and find out as much as you can before deciding on what sort of PMO is right for you.

In the same way that project management practitioners can be described as beginner, intermediate or advanced, organizations can also be described as having low, medium, or high levels of project management. These levels of project management reflect the level of organizational project management maturity (OPMM).  Knowing the level of OPMM your organisation is currently at, and also knowing where it should be is essential to help you reach your organisational goals and strategy through better delivery of portfolios, programmes, and projects.

An OPMM assessment will look at all aspects of the way you run portfolios, programmes and projects within the organisation including:

• Organisational Governance
• Management controls
•  
• Finance and cost estimating
• Planning and Execution
• Scheduling and time estimating
• Stakeholder management and communications
•  
• Lessons learned and information management
•  
• Risk management
• Quality management
• Practitioner capability development

A good assessment will look at all the processes and practices you have, evidence of them being used (or not), and also interview users and key stakeholders either in a workshop or face to face interviews. Once the evidence gathering is completed they can provide scores for individual business units, an organisational score (usually 0-5), benchmarking against others in the industry and a set of prioritized (and achievable) recommendations to move you towards your goal.

A good OPMM assessment provides a benchmark for your future efforts. It lets you know that you are progressing in the right areas. Without it you simply don’t know how well you are doing with your improvement efforts. It’s a good idea to commit to regular OPMM assessments every 18-24 months to check how you are progressing, and to reprioritize recommendations.

Don’t assume that all organizations must be at the top level of maturity, it’s important to consider that the level of OPMM that is desirable for any organisation is directly related to the size, cost, length, complexity and industry of the projects being undertaken. Organizations undertaking highly complex, long term, expensive projects should aim to have a higher level of project management maturity, while organizations and small businesses routinely undertaking short, low cost, low complexity projects may be perfectly suited to a lesser level of project management maturity.

Using an external consultant to assess your level of project management maturity and make recommendations has a number of benefits:

• A good consultant will make sure that your recommendations are achievable, affordable and appropriate.
• You get access to their wider experience with many organisations and their insights into best practice
• The report will be independent and objective

There are several good commercial models available in the market and the benefit of using one of these is that it allows you to more easily benchmark your organisation against others in their database.

I am experienced in using the P3M3, OPM3, HSI 4Q model and bespoke OPMM assessment models and if you have any questions about any aspect of organizational project management maturity please do not hesitate to contact me.

If you have any questions, comments or feedback please feel free to email me.

Are you a little confused by all these project management documents and credentials you keep stumbling across in your quest to understand the profession and further develop yourself as a project manager? Well I’m going to try and explain the situation to you so you understand exactly what a standard, framework and methodology is and how they are different from each other. This will be a brief, yet concise, explanation and if you want more detail just do a search on the internet.

Let’s start the explanation with a diagram. The diagram shows standards, frameworks and methodologies in descending order of influence and importance.

At the top you have ISO21500 which is the newly introduced international standard for project management. It took 7 years to develop and involved all the project management organizations around the globe and as such represents a truly comprehensive, standardizing and unifying approach to project management. It is still early days for this standard as it was only released in 2012 and as such it is a guiding standard only and not a normative one. We expect it to become a normative standard sometime around 2017 and when it does you can start certifying your organisation as ISO21500 compliant. Until then it represents a fantastic guide for professional project management and you should probably make yourself very familiar with it as it will probably become a standard you need to comply with sooner or later.

The next layer down is made up of framework documents and their associated credentials. Here you have project management body of knowledge’s’ which capture what is considered good professional project management practice across the entire project management profession. The largest example of this is the PMBOK^® Guide from the Project Management Institute (PMI) which is a global organization. Frameworks contain much more detailed information about project management processes, tools and techniques than standards such as ISO21500. The Association for Project Management (APM), which is largely based in Europe, also has its own Body of Knowledge as well. Despite this extra information they do not present specific ways of completing projects - that’s a job for methodologies which we cover soon. There are many similarities between the PMBOK^® Guide, APM BoK, and ISO21500, but also a few differences mainly around slight naming and content differences of some processes and process groups. We would expect these differences to be ironed out over the next few years. PMI offers the Project Management Professional (PMP^®) and Certified Associate in Project Management (CAPM^®) credential, and APM offers its own 4 stage certification for project managers. All of these credentials are framework credentials and are at a much more senior and detailed level than methodology credentials which we cover next. I recommend all project managers plan on gaining a framework credential at some point in their career - the sooner the better.

At the bottom of the hierarchy are specific project management methodologies developed from frameworks which in turn align with standards. Each methodology can be traced back to a particular framework document, and its ancillary documents such as extensions to the PMI PMBOK^® Guide. Each methodology is particularly suitable for different projects based on industry, size, value, complexity and risk. For example Scrum is great for fast moving iterative IT projects, Prince2 for low complexity IT projects, and Method123 for defined complex projects from a range of industries. There are usually no, or very little, prerequisites needed to gain a methodology certification so they are generally not any guide to a project managers experience, ability or seniority. My opinion is that you should only look at becoming a certified in a particular project management methodology if your organization is actually going to use that methodology appropriately. Otherwise I strongly suggest getting a framework credential such as PMP^® and gain the skills needed to develop your own project management methodology.

Anyway, that’s the explanation over. I hope you found it useful and you now feel more informed about standards, frameworks and methodologies.