It is an inevitable defect, that bureaucrats will care more for routine than for results.
—Walter Bagehot

The Project Management Office: From Technology Spectator to Enterprise Enabler

A topic which several customers have raised is the role of Project Management Offices (PMOs) in agile organisations. The question is normally about the PMO’s relevance in the world of agile, sprinkled with a hint of frustration that something needs to change but a lack of clarity on what. After 25 years of setting up and working with PMOs I do believe we need to be more deliberate in understanding and crafting the role they play in modern organisations. This is particularly important as accountability and autonomy are driven deeper into the hierarchy chart, and as progress is evaluated by value delivered rather than project activities completed. I say this not just as an ex-app dev leader, but also as someone who has been through the traditional career path of project and programme management and who has held the traditional certifications associated for these roles. While educational, many of these certifications reinforced a process-over-outcome philosophy.

When interviewing candidates for PMO roles, I ask how they see the role directly supporting value creation. This question comes from a history of seeing very capable people becoming the arch-nemesis of delivery teams, or junior project managers trying to control plans they don’t understand. A PMO’s constant demands to fill in time sheets, implement new intricate processes, complete reams of status reports, and check off Gantt chart tasks are often bookended with a proclamation of little knowledge or accountability for initiatives they are involved in. As I’ve discussed in my blog post on messiness, this semblance of control hides the realities of complex initiatives. Empirical data is sporadic but reflects a common view that the PMO is perceived as a bureaucratic impediment rather than an organisational enabler.

This doesn’t need to be the case. I have seen five patterns work for PMOs, and corresponding anti-patterns that hold PMOs back.

From Enforcers to Enablers

If you subscribe to the belief that autonomous teams will become pervasive, how do you reconcile this autonomy with PMOs’ mission to standardise procedures, processes, and tools? This can be addressed by having a small PMO take on the role of a centre of excellence. In this role the PMO uses the “F” word a lot: facilitation. They facilitate enabling standards and tools, communities of practice, and lessons learned. I’ve been asked several times whether a PMO should enforce a common way of doing agile in teams, for example. My answer: Not necessarily. It is powerful to have people all the way up to the CEO be conversant in agile terminology, but to enforce a specific flavour of agile becomes a slippery slope of making autonomous teams less autonomous and less accountable. Standards are great if, and only if, they genuinely add value to the teams delivering on outcomes and if time is taken to communicate what this value is while actively listening to feedback.

From Spectators to Supporters

Product teams are not going to replace every project you run. In either case, PMOs rarely seem to have accountability for a successful outcome. Often, due to their relative lack of technological understanding, they also lack the ability to ask insightful questions to establish whether a technology project is healthy. This leads to “watermelon” status reporting results: projects that are green on the outside are actually red on the inside. What I have seen work spectacularly well is when a seasoned PMO member steps up, embeds themselves in an initiative, and takes accountability for the outcome. These individuals work hard to earn the respect of the delivery teams, and in return the delivery teams embrace the discipline that is brought to bear.

Amazon does not have a PMO, partially due to autonomous teams that have minimal dependencies, but there are still complex, multi-team initiatives to run. Amazon approaches these by appointing a single-threaded leader who wakes up in the morning with just one priority: driving a successful outcome. They are experienced, empowered, and emotionally intelligent. The PMO individuals I call out here resemble these leaders.

From Check-box Checkers to Coaches

I’ve participated in many conversations where questions along the lines of, “Did you complete task 100 on the Gantt?” occur. The individual asking the question might have little idea about the relevance of task 100, whether it is truly still critical, or the options to ensure it is completed. It’s not an overly useful role for achieving an outcome. Experienced PMO members play a different role. They become coaches to product and project teams. In a similar way that servant leadership prevails in modern organisations, the PMO can bring experience to the table by asking the right questions and providing gentle coaching to up-skill teams. This is particularly important as many project managers morph into product managers, and where non-technologists increasingly move from order-giving roles to being part of product teams.

From Work Generators to Waste Warriors

It’s surprisingly easy to be blind to the usefulness of a way of working. A method of working can easily switch from being useful to being a barrier. Governance meetings established for a specific reason years ago continue, well, just because we’ve always held these meetings. As with many teams in large organisations, a small PMO started for a very specific reason can become self-justifying over time, ballooning in size and on occasion becoming bigger than the teams trying to deliver initiatives.

Contrast this to a PMO that is a guardian of our time, a most valuable asset. From their enterprise perch, by actively peering across working practices and applying Lean engineering techniques, sources of waste that impede time-to-market can be ruthlessly eliminated. In other words, what is getting in the way of the product teams from being successful? Take care that the PMO does not drift into being the “process police” by balancing effectiveness, such as encouraging more experiments to be run, with efficiency. From this work the PMO can surface better and simpler practices to operate, steering clear of unnecessarily proclaiming singular best practices.

From Functional Monitors to Business Transformation Agents

Over the last 30 years PMOs have taken root in IT departments in an effort to improve project delivery results. The data is mixed but doesn’t suggest a case for universal celebration here. Complex cross-functional projects require careful coordination, especially in more traditionally structured firms but having the PMO situated in IT often does not lead to success. As a case in point, many projects fail due to a lack of active business sponsorship. An IT-centric PMO often has no ability to address or change this.

Companies that successfully transform mostly have some sort of business transformation office (BTO). A good BTO looks across all business functions with the CEO’s authority and actively helps unblock projects through regular, action-oriented, fast-paced meetings. Unblocking activities can be as basic as ensuring effective executive sponsorship or alignment on business success measures, or ensuring business functions outside of technology are focused appropriately on change management rather than just writing the next set of functional requirements. I’m not advocating for lifting and shifting existing PMOs to the BTO. Rather, simply move the essential elements required for complex initiatives. This can lead to a much more gratifying role for PMO members: moving from a reporting arm for a company officer to truly enabling value delivery.

While the results from PMO are mixed, an organisation where both product and project management coexist still needs an effective PMO-type group. Companies that effectively use their PMO as a coordination mechanism to coach and actively up-skill their teams are more likely to see outsized results. I would encourage you, as technology leaders, to be explicit about what this value is, and to keep a wary eye on teams turning from supporting outcomes to trying to become process police.

Phil
plebrun@amazon.com

“Kill the PMO! Resurrect the Department of Simplicity”, PMI
“The PMO is Dead, Long Live the PMO”, DevOps Summit