Why some (or maybe many) Project Management Offices, PMO fails? What are the gaps in PMO implementation that could be contributing to their failures? What is the organizational impact? Why a 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.
For the answers, continue to read.
We start by stressing that we do not have all of the answers. We do not have any scientific evidence. Although there have been some global studies on this subject, and we in SUKAD did a survey also in West Asia and North Africa. Therefore, what we post here is our views and professional opinion, derived from observations and interactions with numerous organizations in additions to the studies.
Stakeholders Alignment Gaps
Many project management practitioners are familiar with one version or another of the following image. We cannot credit the source of this image since unfortunately we do not know the source.
Our hypothesis is that the challenge organizations face when they implement project management offices (PMO) is the same kind of challenge presented in the above illustration. For now, focus on the last frame, first, then the first frame.
So what are the challenges of PMO implementation?
In today’s article, we will discuss:
- The Executive Factor,
- The Consultant Factor, and
- The Suggested Solution.
The Executive Factor
The Hypothesis & Scenario that trigger PMO Implementation
Our hypothesis is that despite the fact that PMO’s 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 a 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.
What do the executives want?
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; i.e. the office) or do they want to improve the performance of their organizational projects? In other words, begin with the end in mind, what is the ultimate results that executives want?
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.
What will the executive ask for?
Now let us go back to the illustration and focus on the first frame, “what to executives ask for?” Typically the answer is a PMO Implementation.
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 are for a PMO but the expectations are improving performance. As you know, there are differences between expectations and requirements.
The executives’ gaps and results
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 becomes another layer between management and project managers. In direct 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. However, projects performance might not improve; or only marginal improvements. 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 problems. 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 a 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; the what. 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; the why. 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 experienced consultant will guide them through the maze.
The Suggested Solution
We derive the suggested solution 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 prospective 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 the organizational project management system implementation. By organizational 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 Project 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!