"It must be considered that there is nothing more difficult to carry out nor more doubtful of success nor more dangerous to handle than to initiate a new order of things" - Machiavelli, 1446-1507
A question for you...
If someone asked you “what is the role of the Project Management Office in an agile organization”, what would you say to them?
Well, let’s be clear about one thing right now. “I don’t know” is a reasonable answer. Should you have a technical background, for example, then perhaps you’ve never even heard of a “Project Management Office”. Or if your experience is mainly with start-ups and other small-scale outfits, then the chances are they didn’t have a PMO for you to hear about in the first place. Then again, if you’ve had some big-company experience you might at least have heard of a "PMO” being referred to at some stage. Perhaps you can even peg this entity - whoever he, she, or it might be - as something to do with administration. Maybe you once walked past some desks or a door which had a “Project Management Office" sign? Perhaps it was when you found yourself on one of those eye-opening floors where the higher-ups are to be found. You know...where there are nice plants, fresh marker pens, and corny motivational posters instead of curling sticky-notes on the walls, and everything is just far too swell for much real work to be going on.
The PMO low-down
Anyway, here’s the low-down on what a "Project Management Office" actually does. Large organizations typically have lots of of initiatives on the boil, including projects which are starting up and being wound down, as well as ongoing service delivery functions to take care of. None of these are typically independent endeavors. In other words, if any of them were to go pear-shaped, then the organization would incur at least some degree of risk. The organization carries the can. If any of these initiatives were to fail then there might be legal exposure, compliance issues, stock price repercussions, or negative exposure (tip: try saying "fake news") and reputational damage. The risk is not necessarily limited to the employees concerned but rather to the enterprise as a whole.
In a small-scale business, executives might be able to manage these risks themselves, perhaps even just in their heads. They don’t necessarily need a special organizational function for this, because they themselves are few and closely linked. And as any fule kno, a small, tight network of people improves the chances of transparency and achieving a successful, collaboration-based outcome.
In other words there is a need for critical oversight and governance. It isn't just a matter of running projects at an operational level and making sure they deliver on schedule. It's about making sure there is alignment with corporate standards so risk is controlled, and that the control is evidenced. At scale, executives can't manage all of this by themselves, and so they delegate as much oversight and governance as they can. But how to do so without compromising team integrity? That's where the PMO comes in, at least in so far as it constitutes an organizational function. When the auditors knock on the door, it's the PMO who lets them in and tries to steer them away from the sore places. "Come this way, please. How was your journey? My, what weather we're having! Can we get you coffee, tea? Have you had lunch?"
Smile, it's the Process Police
For these and other reasons, agile practitioners who've heard of them generally take a dim view of the PMO. The PMO is seen to represent dysfunctional management and its shenanigans when, in an agile way of working, control ought to be localized along with accountability. Whereas an agile team would expect to assert its own quality through a definition of "Done", and to inspect and adapt its own process, the PMO interferes with these practices. They impose certain standards when others will be accountable for implementing them.
To many agile practitioners, consequently, the PMO is a despotic and despicable "process police". They seem to reek with entitlement, privilege, and authority-without-responsibility. Yet they cannot be successfully fought as they have the weight of authority behind them. They have deftly taken over the organization-state. Best not to speak their fell name, lest you invoke their dread arrival. They seem almost as inhuman as HR.
The Machiavellian PMO
Needless to say then, a Project Management Office can present certain challenges to an agile coach. In some enterprises the PMO will indeed run like the "process police". For example they may seek early reassurances from a coach that, in effect, all change is negotiable. A PMO will usually be aware of a directive for "agile transformation", and they may see it as their duty to water this down as far as possible. Thoroughly vested in the established project culture, for them the day cannot come soon enough when this agile nonsense is kicked into the long grass. There may be an appeal to exceptionalism: "this organization is different and things just don't work that way here". The onus is then put on the coach to modify agile practice, rather than to expect enterprise change.
Another technique often used is to try and convince a coach that things are pretty much agile anyway. A PMO might redefine, or seek to control, certain agile terms-of-reference in an attempt to support this position. The gambit being played is essentially one of "embrace, extend, and extinguish". Moreover, as custodians of the organization's project management standards, which have endured so far, they may genuinely see the preservation of the status-quo as the right thing to do. Banks and public sector bodies have earned a certain reputation in this regard, and there may be a bullying and heavily politicized culture to back it up. In these situations agile change can end up becoming a raw test of executive sponsorship. Is it enough to overcome organizational inertia? Not everything lies in the coach's hands.
In an environment such as this, the best thing for an agile coach to do is to politely focus on teamwork, accountability for value, and the reduction of batch sizes. If Scrum is being referenced, a deep knowledge of the Scrum Guide will prove to be indispensable. A coach's duty is to provide clarity and not to be sucked into political intrigue. It is then up to the organization to decide if it wishes to pursue genuine agile improvement.
I, for one, welcome our new Agile PMO overlords
Although the "Machiavellian PMO" is far from being rare, most Project Management Offices are fortunately not so toxic. It is usually possible for an agile coach to not only work with them, but to strike up a very productive and sustainable relationship which serves the organization well, and for years into the future.
Often, when they hear that an agile coach is on the scene, I'll find that the PMO will approach me with a very simple question. In fact it's the same question I originally asked you: “what is the role of the Project Management Office in an agile organization?” This time though, it's important to have an answer. We are faced with people who have very human concerns. They see and accept that things are indeed changing around them. Agility may be just one facet of a wider digital transformation. There may have been redundancies due to re-organization, and they wonder if there is a place for a PMO in an "agile" world of empowered, self-organizing teams. The situation can tug at your heart-strings. It's like a quaint fairy-folk wanting to know if, for them, there can also be a heaven.
The answer I give them is "yes", and here's why. Although the PMO's responsibilities must shrink in terms of operational project control, those empowered and self-organizing agile teams are not yet in place. Moreover, those teams will not be garage start-ups free to do their own thing, but part of a wider enterprise, and with certain obligations towards it. Remember that agile change must happen while the organization is in flight, while it is still delivering value, and without damage to reputation, quality, or stakeholder confidence. A large enterprise cannot stop in order to change its culture and practices, nor can that change possibly happen all at once. Agile transformation is a process which must be measured and managed, especially at scale. Governance and oversight of that change process will be essential. A coach can advise, but ownership of change cannot actually be his or her responsibility. Ultimately, it is the organization's officers who will carry the can for the success or failure of a transformation. A PMO which can help will be needed more than ever.
The basics: how to conduct an agile health check
The most elementary thing you can coach an "Agile PMO" to do is to establish transparency over the change process. Once transparency is there, constructive governance and oversight become possible. Any who are seen to be struggling with agile practice can then be helped instead of being left to flail.
One useful technique is to coach a regular agile health-check, preferably on-cadence. In Scrum terms this may articulate to each Sprint. A coach can start things rolling by having teams self-evaluate their progress, preferably just after a retrospective while thoughts are still fresh. To help them, a list of key agile considerations can be supplied. There must be flexibility as to what considerations ought to hold, as each team will operate in its own context, and a good coach must use his or her discretion wisely. One starting point is to consider product ownership, teamwork, the events which are held, debt, and tooling.
A health-check like this is a useful vehicle for coaching agile governance to a PMO, as well as being valuable for teams who may otherwise feel abandoned. The significance of each dimension can be explained and the elicitation of a RAG (Red, Amber, Green) status put to good use. If a problem is highlighted and the team do not believe they can resolve it, then they can flag it immediately as red. If they believe they can remedy it before the next check, then they may flag it as amber. If it is still unresolved then it will become red. Through an agile health-check teams are thus given a mechanism, configurable to their needs, for escalating problems which may not be within their control. The Project Management Office can then advocate their position and seek to remove serious, organizational-level impediments. In short the PMO takes on a servant-leadership function where Scrum Masters may lack the authority or connections to be effective. For many agile teams this proves to be a revelation: they find an ally in the PMO instead of an enemy.
Towards enterprise agility
As agile practice becomes normed in a team, fewer impediments will require the PMO's attention, and external oversight will become not only less necessary but also less desirable. The self-organizing team can be left to inspect and adapt its own process and to notify the PMO only by exception. The Agile Project Management Office then has the capacity to help other teams on the agile journey, a process which becomes increasingly pull-driven as the evidence of its value becomes apparent to a wider audience. Remember also that newly formed Scrum Teams ought to look to the organization for their Definition of Done in the first instance, and the Agile PMO may be its custodians.
Of course, the "Agile PMO" is in a position to help senior management as well as delivery teams. For one thing, they can provide oversight of transformational progress, of ongoing quality assurance, and of the degree of alignment with the strategic vision for agile change. For another, they can supply evidence of organizational control during an audit. Yet they can also help in ways which executives may not quite expect. Some organizations are notorious for falling into a reactive mode of operation. Why is this so? To a large degree it's because executives lack the means to distinguish between circumstantial and systemic impediments. In other words when a problem happens, managers don't necessarily know if it's a one-off event, or whether it indicates something wrong at a fundamental level. The Agile PMO, however, will be in a position to supply guidance in a timely manner if they have taken key measures and are able to interpret them.
Some useful templates
- An agile health check (XLS format)
- "The Agile Buddy Guide" - a configurable guide which an Agile PMO can distribute to teams
- Guidance on how to use a transformation backlog, with a link to a template