You know those dreadful surveys where management ask for staff feedback? Well once upon a time I worked in an organisation where the most frequent suggestion from the project management community was: “We need a PMO!”
So I set myself the task of trying to understand the request. What exactly were they asking for? What is a PMO?
Even the name is confusing. Is it a Project Management Office, a Programme Management Office, a Portfolio Management Office, or perhaps it is a Project Office or a Project Support Office?
Whatever it is, here, in alphabetical order, is the list of tasks and topics that I came up with, for things that it might do:
- Ad-hoc support for project managers
- Longer-term benefits realisation
- Business case planning support
- Coordination of communications
- Change control
- Dependency tracking
- Project governance
- Lessons learned library
- Lessons learned facilitation
- Management of escalations
- Ownership of project management best practice
- Planning, and planning support
- Project administration support
- Project resourcing
- Project start-up support
- Project tooling
- Quality management
- Risk management
- Support for Project Owners
- Training of Project Managers
The list drew on several sources: P3O, Good PMO, ProjectManagement.com, and my own experience. In this instance the focus was on “project” more than “programme” or “portfolio” – the inclusion of which would have given rise to a longer list.
There are two remarkable things about this list. Firstly, it is vast and varied (yet incomplete; I’m sure most readers will have spotted gaps and omissions). Surely no single PMO can cover all of this scope. But secondly, all of the items mentioned are valuable, or even essential to a project-driven organisation.
The reality is that all of these things exist in most organisations, but they don’t necessarily get parcelled up into a PMO. There might be a CTO office responsible for reporting and communications, for example. Project resourcing might be handled by a resource management function. And so on.
No two organisations are the same, and for this reason no two PMOs are the same. I have learned that when someone asks me to help implement a PMO, a lot more exploration is needed to understand the request – because my understanding and experience of a PMO is likely to be completely different to theirs. Most importantly, they are likely to assume that I know what they are asking for – and I certainly don’t!
One of the fundamental decisions for a PMO is to decide who it serves. Who is the customer? Does it look upwards, serving senior management with reporting, tracking and escalation? Or is it there to support the project managers with best practice, training, and administration services? Does it carry a big management stick with which to beat the project managers, or is it the place that they come to for support and guidance? In practice it is probably some balance of the two, but that balance should be an explicit decision – which is then built into the PMO’s operation.
If I were drawing up the list now, I would add the following:
- Coaching of project managers. The PMO is a good place to coordinate a coaching programme.
- Establishing an Agile Scrum environment. For organisations implementing Scrum (as many are), the PMO can provide a useful function of insulating the scrum teams from corporate governance.
Returning to my story of the PM community that were asking for a PMO. On listing the functions, analysing the list, and presenting it back to the PMs, it turned out that my small “PM Excellence” team already provided about half of the functions of a PMO, although we didn’t call it by that name. About another 40% existed elsewhere in the organisation. In fact the only partially missing items were to do with PM support: admin services, start-up support, ad-hoc support. So what they were really asking for was a bit more admin support.
Did we meet their need? Well, partially. You know how big corporations are. But that’s another story.