The Agile PMO

The Project Management Office has received a negative reputation in many corporate circles.  Often hailed as the “Project Management Overhead,” many consider the PMO a waste of corporate budget and time, an office that exists to create strict consistency rules while hampering the efficiency and effectiveness of software, firmware and hardware delivery.  Unfortunately, my experience interacting with dozens of PMO’s, the criticism has roots within reality. 

Back in the early 2000’s, I felt that viewpoint too when I joined my first company that had a true PMO, which seemed more focused on standards and consistency then delivery success.  That viewpoint persisted in my next company when I tried to preserve my own flavor of delivery whilst paying homage towards the old “iron triangle” of schedule, budget and scope (when MS Project was king) for my projects.

In 2007 I was promoted to the lead of a small PMO for a roughly 60 people and seven Project Managers in a global program.  Now I was the “bad guy” in the PMO hot seat.  However, my criticism towards the office made me do things differently.  My goal was to deviate from the standard PMO rank and file.  My PMO followed the Agile Manifesto, adopting a servant leader organization, using the breadth and influence of the position to help projects get out of their major jams, and teach new ways to deliver (i.e. expand the “delivery toolset”) and report on project progress, including the notorious evil Project Status Report. 

These days, after several iterations with multiple companies, I have evolved into leading the National Project Center, which is an Agile PMO for over 30 Project Managers and 500 consultants.  My experience has helped build out the following guidelines worthy of consideration for any PMO: 

• Instill PMO automation with continuous improvement
• Establish and share your PMO vision and roadmap
• Practice Portfolio servant leadership
• Educate and provide solutions, not just simply observations
• Give clear parameters to balance consistency with creativity
• Seek full transparency with rapid feedback on changes 

Let’s focus on the concept of Automation and Continuous Improvement.  Specifically, treat the standard components of any PMO in the spirit of automation, like the concept of DevOps.  I like to consider this the PMO Infinity chain, based on the Wikipedia DevOps Infinity Chain modified to the following seven cyclical steps as shown below: 

1. Plan (same)
2. Create -> Design
3. Verify (same)
4. Package -> Build
5. Release -> Publish
6. Configure -> Automate
7. Monitor -> Adjust 

This blends the ideas of the Improvement Kata (understand challenge, grasp current condition, establish target condition, iterate and adjust) made popular in IT through Mike Rother and works very well within the PMO. Keeping the Lean mentality of “Learn, Build, Measure”, the PMO focuses on a culture of experimentation and change. 

For instance, those dreaded status reports are a pain for many in any organization.  You may ask the question, “Do we really need status reports?”  In many cases, we do not.  However, when working with third party contracts, status reports are still often the primary means of protection as an audit trail of regular agreements.  Providing the appropriate level of detail for stakeholders becomes an exercise in avoiding unread status reports. 

Our solution was to automate the delivery of the key executive summary and health metrics in brief dashboard and then provide links to details for over 80 weekly status reports.  Here are the steps when applied to the PMO automation model: 

1. Plan – Validate with stakeholders what they find lacking in the current report delivery
2. Design – With that input, design the report process based on feedback
3. Verify – Show the report process to a select group of stakeholders for feedback
4. Build – Once agreed upon an initial set of prioritized improvements, implement
5. Publish – Release the new report format and process
6. Automate – focus on minimizing workload for the masses.  For example: auto-loaded attributes (Project Name, budget, SOW end date, etc.), automated graph/chart development, automated reminders of missing/late reports, automated dashboard of reporting metrics (budget, schedule, scope, quality, value)
7. Adjust – Further gather feedback and return to Plan for any remaining prioritized improvements

Automating several steps in report delivery and providing the most important parts to the right level of leadership has given higher compliance and consistency, but not at the expense of creativity by the report submitter. Over 80 status reports are produced every week and now we have automated overview, reminders, dashboard and metrics with a semi-automated creation and submittal process.

This is just one step to convert the PMO from sucking productivity as a vampire and converting to a supporting organization helping improve delivery efficiency while providing delivery transparency to make fast and valuable decisions.