Skip to main content

Should the PMO go away?

Marty Bradley Principal Consultant
Reading: Should the PMO go away?

When I go in to do large scale transformations I’m invariably asked the question, “should the PMO go away?’  The reasoning is that going agile should get rid of all of the oversight, the Gantt Charts, the weekly status meetings, release scheduling.  The list goes on.

Before I address the question I want to give you some background as to what we typically see when we hit the ground from a coaching standpoint.  The company is in an ad hoc state. They may be delivering but it isn’t always on time.  Scope creep is inevitable in this environment as they schedule 3,6, and maybe even 12 month releases. As much as the teams try to be agile there are a number of processes in place to make sure the product actually gets out the door. There’s some release planning up front, expectations are set.  Development may occur in sprints but integration testing and acceptance testing lag behind. Sometimes it is so complicated to do integration testing it has to happen in a big time box towards the end.  The business becomes disengaged while development is off sprinting.  This process isn’t agile and if you did lay it out in a Gantt chart it would present very much like waterfall.

Now think about all the stage gates you have in your organization. Release planning sign off. Weekly change control. Release scheduling. Release sign off. Deployment planning. Deployment change control. Some organizations I’ve seen have 20 people on the phone during an overnight deployment.  So why is this? The answer is simple. Over time the organization has created an environment of mistrust. Promises have been broken. Buggy software has been delivered to customers. Fingers pointed; “Requirements were bad”, “Development is slow”, “Too many last minute changes.” A number of reasons have caused the need for the stage gates. Once a stage gate exists it’s difficult to remove.

To get the organization back on track we need to refocus on the 3 things that make up an agile process; backlog, team and working tested software.  In essence, clarity, accountability and measurable progress. In order to do this, we need governance, structure and metrics. These things will get us to a predictable state. Once we get predictable we can begin to rebuild the trust in the organization.

To get an organization back on track we need to focus on the 3 things that make up an agile process; backlog, team and working tested software.

The governance model must slice through the organization from the top to the bottom. In many organizations this will be in the form of at least 3 layers; Portfolio, Program, and Team.  The Portfolio layer will deal with the creation, definition and prioritization of themes and epics. The Program layer will create define, and prioritize features. The Team level is responsible for the implementation of the user stories derived from the features.  This governance model will further define the process flows to go from inception to deployment.

What I have briefly described here is an initial step towards a logically planned out transformation strategy. As you can see, in this first step we clearly define a structure and a governance model that leads to a predictable process. We can’t just teach agile practices and hope everybody sees the light. There are a number of manual orchestration activities in the organization to keep everything moving forward. As the organization moves further along the scale towards a more decoupled system of delivery then the manual orchestration will diminish. I refer to this manual orchestration and stabilization processes as scaffolding. As manual orchestration diminishes the scaffolding can begin to come down. It is important in your transformation to identify the scaffolding and plan as part of your future transformation efforts to remove it.

Once we get predictable we can begin to rebuild the trust in the organization.

So, “Should the PMO go away?”  Not in this scenario.  Some part of the organization needs to facilitate the manual orchestration at this stage of the transformation. If your organization already has a PMO then these are the type of people you need to facilitate.

Can the PMO go away one day?  The only responsible answer I can give is, “When your organization is ready.”

One last caveat.  I’ve seen some organizations that are split, some parts need the PMO due to organizational and technical debt, and other parts have been built to be decoupled and on a continuous delivery cycle eliminating the need for manual orchestration.

Next System Design Canvas

Comments (4)

  1. Adrian

    I’ve never liked the “O” part of PMO. It implies a bureaucratic “office”. Program management, in general, is important. I’d prefer a function called “program management leadership” as a responsibility, not as an “office”. The responsibility of longer range planning and maintenance is important. The office is not.

  2. Bruce Taylor

    Marty, thanks for the article, great topic and one that is no doubt hot in a lot of places. One aspect that you didnt dive into was those tricky financial ones. How do you think things like ROI and cost of team etc etc are handled.
    ms, with a ‘relatively’ fixed budget, but decisions to end spending etc. Often teams careen on delivering, without looking at effectiveness of that spend. CEO’s and the like want to know they’re getting value for money and sometimes they want to see reports.

    It’s a particular interest of mine, so I’d probably also benefit from doing some research in what a traditional PMO actually does. In my past experience, they’re generally the guys who beat you round the head when your project goes red, so I’m all for the end…

    • Marty Bradley

      Bruce, Thanks for the comments. The questions you ask could each be a blog entry themselves. I’ll check to see if one of my colleagues have posted on these topics. If not I’ll follow up, as these are great topics. I’ll take a general cut at this. What you are getting into is that many organizations don’t realize that an agile transformation should really be a re-structure to facilitate the flow of value in the organization. That is, an Agile transformation isn’t just an IT thing. What we prefer to see is that we fund teams and not projects. You can fix the budget on the teams and infrastructure and then only bring projects that fit into the teams you already have. If you need more capacity then you need more teams. Simple right? It should be.

      Reinertsen in his book product development flow stated that if you can’t measure anything else for prioritization like business value or ROI then focus only on cost of delay. If you do that and do a quarterly review of your portfolio you can at least adjust quarterly. The assumption is the the Product Owner is putting the highest value items at the top of the backlog even if they can’t measure ROI by feature. There are other issues like technical debt and dependencies. If that’s keeping you from pivoting at least quarterly then getting rid of this technical or organizational debt should be the focus of your transformation.

      Lastly, as the organization changes the PMO will change. The product owner is responsible for delivering value. The team is responsible for delivering quality software. The Product Owner should be in close communication with the team to do the normal agle delivery which is to always hit your date, your timebox. The value you have at the end of the timebox is the value you deliver. No beating about the head and neck. See work can be fun ;)

  3. Ferdi Brannekamper

    This was written 3 years ago & many of the companies that I visit are still stuck in the same paradigm of spending money on projects & calling people “resources” who actually create the working software or revenue streams that their company relies on


Leave a comment

Your email address will not be published. Required fields are marked *