The Centralized PMO: A reality check needed?
I read this great article on Gantthead.com about adding a PMO support role for the project managers who work within a PMO. It proposes the idea of having a role dedicated to the administrative functions such as scheduling meetings, updating the project schedule, follow up calls, etc. that can eat up a significant amount of time for the core PMs which prevent them from doing the “core” management part of PM.
I can certainly relate to this as I get bogged down considerably by the administrative aspects of being a PM within a PMO. But I suspect that adding these roles will create more bottlenecks by increasing the communication routes that now get added by this. It’s that whole PM 101 idea of n(n-1)/2 communication channels that grows geometrically every time you add a person to the layer of communications that could bog down such a PMO. Furthermore, a very efficient governance process, solid tools and clearly understood and agree upon roles would have to be in place. The author Andy Jordan agrees and this section of the article outlines it very well:
Administrative functions within a PMO can work well and deliver tremendous efficiencies, but to work properly they require a very distinct environment. Most important of all is a strong, trusting relationship between the project manager and the individual assigned to provide them with support. The PM needs to believe that their support is working for the project, not acting as a PMO “policing” function; and the support resource needs to feel that the PM trusts them and isn’t withholding information, checking up on them or duplicating their work.
This can be a difficult relationship to develop, especially on the part of the PM who has to give up some of the control that they are traditionally used to having. However, it’s a model that can work tremendously well–I haven’t yet met a PM who enjoys entering status updates or chasing people for their updates as the reporting deadline approaches for the week. If the PM is able to invest that time into managing real issues, then the advantages are obvious for all to see.
The model also requires a strong set of administrative tools and processes. To benefit from a centralized function, the PMO needs to be able to apply the same repeatable processes to every project. If every initiative has a long list of exceptions from the norm, then the advantages will soon be lost and the PM may as well retain control over the tasks. Trying to implement this model before there is standard reporting, risk monitoring, change control, etc. is doomed to failure.
The model requires sufficient economies of scale. There won’t be savings for a PMO that has only a handful of project managers, but if you have many PMs each managing a number of projects (or significantly sized projects), the advantages begin to appear.
While I like this idea and fully agree that such a standard would have to be in place, I can’ t help but to feel that this will eventually become another monolithic functional/matrix type office that is suppose to run projects within a larger functional/matrix department or organization with so many layers of bureaucracy that trying to complete projects within it becomes a Kafkaesque experience!
And the more bigger question is does centralizing, standardizing, governing and controlling the inputs and outputs of the PMO functions lead to monotony, complacency and staleness killing off fresh and innovative thinking required to solve the most pressing issues and problems faced by the project manager? Maybe the idea of creating a centralized PMO implies that such thinking and bold action is no longer promoted.
Though I think the idea of a centralized PMO is a good one especially if your in a large, complex structured environment, you need to be mindful of the implications of a centrally controlled PMO. Especially when they start to resemble the centrally controlled Communist governments of the past!
Totally agree with the writer. I am in an organization with a PMO formed about a year ago. We are running into these layers of bureacracy where the PM is stripped off most his/her authority on moving the project forward; away from focusing on the real issues of getting the IT system/application implemented. The project manager from the PMO are tasked to create scores of project management artifacts, most of which are an overkill and do not address the real issues of the project’s product itself.
In theory, the process involves a business/functional PM to handle their business stakeholders and organization change management, coupled with a technical IT lead for overseeing the technical aspect of the project. The PMO PM is pigeonholed into a non-technical role except for budget/funding as well as to ensure all the PMO processes are followed.
This add so much more coordination and communication channels, that delays are almost inevitable and risks, leading to increase cost and time. With this sort of model, is it possible to run a project without having adequate technical or business knowledge of the project you are assigned to run?
Hi Cathy,
While on paper and from a PMO’s initial implementation, it always seems a good idea to segment the business and technical sides, it always seems to inevitably to add more layers of bottlenecks and bureaucracy as you’ve witnessed in your own PMO. Worse, it leads to a Balkanization of your PMO within departments, divisions, etc.
This is not an easy solution. One area I’m exploring is the idea of the Agile PMO, though I’ve yet to hear of an actual successful implementation. But there has been fertile research and literature into this topic and I plan to write about it in the future as well as seek ways to integrate this where I work. Stay tuned…