The old school project/program/portfolio management office (PMO) is a relic from the command-and-control models of the past. It worked well for managing predictable solutions. But it’s where agility and innovation dies. Bring on the revolution.
Recognize This?
When I see old school PMOs (and these are more common than you think), I see:
- A drive for compliance with processes and standards over the delivery of value.
- A cookie-cutter approach to all projects, regardless of context.
- Trophies of achieving “Six Sigma” awards, not realizing that quality should be table stakes by now.
- Dashboards that measure variances to the plan, not achieved outcomes.
- Shared project managers with little insight into the business, customer centricity, or modern development approach.
- Ceremonial gate-based project checkpoints that don’t reflect product orientation and product lifecycles.
Gartner coined the term Zombie PMOs. These PMOs just go through the motions, like the walking dead. Ah, it’s good times when zombie pop culture makes it into research. This doesn’t mean that the PMO doesn’t mean well. Other than leaving dead bodies around, that is. Whenever initiatives compete for resources, and they always do, it makes sense to manage them. It breaks down when solution development is no longer a predictable software-factory process. Arguably it never was.
If David Byrne were to record the words to “Once in a Lifetime” today, instead of when the underpinnings for the Project Management Office were created, it would start like this:
And you may find yourself
Managing an agile gig
And you may find yourself
Writing another status report
And you may find yourself
Behind the flow of a large PMOAnd you may tell yourself
This is not my beautiful work!
And you may tell youself
This is not my beautiful life!
Same As It Ever Was
Therein lies the problem. After the agile revolution, solution delivery clashes with the command-and-control past. Applications and traditional funding models lose relevancy. But many PMOs somehow missed this revolution from the PMO fortress. Business and delivery teams want to be agile and responsive: prototype, learn by failing fast, build minimum viable products, take risks, continuously deliver. The old school PMO wants to manage to certainty: detailed estimates, long planning horizons, avoid risks, build documentation. It’s a culture clash.
A common theme in my blog posts seems to be: “why don’t we just kill the old relic then?” Not so fast. Remember the zombie reference. Maybe a better question is what do we want to achieve with a PMO? Depending on that, we can revitalize it, or kill it for good (using science, preferably).
You may ask yourself:
1. Why do we want to have a PMO in the first place?
Typical answers are “to improve project management across all projects” or “to reduce delivery delays”. This should immediately be followed by: is a PMO the best way to achieve that goal?
2. What PMO style do we want?
Different styles focus on different areas:
- Activist PMOs incorporate demand management and prioritization of initiatives across a distributed enterprise. They have a portfolio view and seek to remediate projects at signs of trouble. They provide oversight and seek process improvement. Done right, they can provide value.
- Delivery PMOs focus on project execution and the on-time, on-budget status of projects. Modern may versions focus more on outcomes and success criteria that are meaningful to the business, beyond managing to plan. It’s still tough to make a compelling case for this style when delivery methodologies already focus on outcomes by design.
- Compliance PMOs fill a gap when the organization’s processes and methodologies are weak. They are likely to be perceived as the compliance police that interferes with initiatives by insisting on standardization without context. A no-win situation.
- Federated PMOs are more common in large and stable organizations as a mechanism to share best practices, methods, and standards. They often have no real teeth, but as an advisory body, they can help enterprise agile adoption. The chances of success may improve when you re-badge them a center of excellence rather than a PMO.
3. How do we reflect Agility?
The PMO needs to be adaptive to change and support agile delivery. It needs to be a driver for minimizing process and maximizing business outcomes by taking a broad view perspective that hard to keep on a project or product level. It must be an incubator for agile management practices. It must find new and meaningful indicators of success and value, beyond the tired “manage to plan” metrics.
Lean Portfolio Management
An alternative to the traditional PMO is to incorporate an enterprise agile methodology that incorporates portfolio management as an integrated activity. For example, the Scaled Agile Framework (SAFe) does just this with its Lean Portfolio Management approach. The downside is that such frameworks can easily reduce agility when applied in a heavy-handed way. Balance is needed. I’ll leave this for a future post.
Takeaway
PMOs are under a lot of pressure. Business and delivery teams are storming the fortress with battering rams. In the struggle to show value in an increasingly agile IT environment, they tend to be overwhelmed. Rather than trowing up more barriers, the key is to find the right PMO style and integrating it with an enterprise agile approach.
Most of all, the PMO must be able to show value themselves.
Ernst Rampen ©2018
