Why some (or maybe many) Project Management Offices fail?
What are the gaps in PMO implementation?
What is the organizational impact?
Why failed PMO might damage project management in the organization or at least dilute its value?
Many questions we are posing here to open the discussion.
We will share some observations but here and now we stress that we do not have all of the answers or a scientific evidence, although there have been some studies on this subject done globally, and we in SUKAD did a survey also in West Asia and North Africa. Therefore, what we post here is our views derived from observations and interactions with numerous organizations in additions to the studies.
Stakeholders Alignment Gaps
Most project management practitioners are familiar with one version of the following image or another. We cannot credit the source of this image since unfortunately we do not know the source.
Our hypothesis is that the challenge we face when we implement project management offices (PMO) is the same kind of challenge presented in the above illustration; primarily, but not limited to, the first and last frames.
So what are the challenges in PMO implementation?
In the prior two articles, we did provide some explanation on what is a PMO and how we differentiate between different types of PMO; please refer to these articles for a quick review.
In today’s article we will discuss
- The Executive Factor,
- The Consultant Factor, and
- The Suggested Solution
Our hypothesis is that despite the fact PMO have been around for many years, they are still misunderstood, especially by executives who do not have project management expertise or proper awareness.
Here is the scenario.
- Let us say company Z have had some issues, challenges, or even failures in implementing projects.
- Company Z executives have been hearing about project management and the value of project management.
- They also hear about this thing called “PMO”.
- They hear about these things maybe from a professional journal, an employee, or a consultant eager to sell services.
With the above scenario executives decide to implement a PMO.
If we go back to the last frame in the above illustration, what do the executives really want? Do they want a PMO (a project management office – the office) or do they want to improve the performance of their organizational projects? Is there a difference? Absolutely – as we will explain below. In our humble opinion, effective executives are after organizational performance and not just adding an office. The office (PMO) can be a facilitator, a bystander, or a leader … it all depends …
Now let us go back to the illustration and focus on the first frame, “what to executives ask for?” Typically the answer is PMO. Why? Because they think (or are sold the idea) that the PMO will lead the performance transformation.
The fundamental issue here is that executives are asking for PMO … thinking … that they will have improved projects’ performance. In other words, the requirements is for a PMO but the expectations is improving performance.
What executives do not realize is that just by implementing a PMO (the office) with 1, 2, or more employees in reality they are only structuring an office for project management. This office might end up being responsible for reporting or a bit more. In other words, this office become another layer between management and project managers … in blunt terms: more bureaucracy /// or worst /// policing force; which is a turn off.
With the above months later or maybe a year or two later … the organization might accomplish improved reporting but performance of projects might not improve or improve significantly. If the executives are patient enough and understand project management (partially) they might assess the situation and see if a change in the PMO could solve the problem. If they are not patient enough … they will likely dismantle the PMO. What could be worst? Executives losing trust in the domain of project management. The consequences: lost opportunity, wasted effort, and damaged reputation … or leading to potentially more projects failing or challenged.
The Consultant Factor
We will not expand on this factor much today, one of our Guest Authors have an article on this topic that we will share later.
The main point that we want to raise here today is the difference between expectations and requirements. Traditional management and project management teaches us to focus on requirements and deliver our projects per the requirements. Since a PMO implementation is a project than consultants comply with the requirements and implement a PMO. In this case, the consultant focus is on the “office” since no one asked them to do more.
The reality is: a good consultant must drill down for the root cause of the request in order to identify the client’s expectations. By drilling down we might find out that the client is not interested in another layer but for a PMO to lead the transformation. We know that some consultants will jump now and say this is not our job – the client has to provide clear requirements; we say otherwise since as the illustration shows: executives might have one expectation but what they ask for is requirements … expecting that an experience consultant will guide them through the maze.
The Suggested Solution
The suggested solution we derive from the last paragraph. In SUKAD, our first guideline in the Quality Management System is to insist on our business consultant when they work with perspective clients is to drill for the expectations and not just follow the requirements.
The real question today is how to avoid PMO failures?
In our professional opinion, what we really need is to combine PMO implementation with project management system implementation. By project management system we do not mean IT System or Tools … we mean the full system from governance and strategic aspects, adding project management methodology, down to the processes, professional development and competency. In our learning solutions we offer two separate programs, one is about Building the Program Management Office and the other is Building the Project Management System. We do this to emphasize the need for both.
In future articles, we will discuss a failed implementation. We will also share a maturity model that we developed to help avoid the risk of failures.
What do you think about what we present here?
Do you have an opposing opinion to share?
We would love to hear from you!