There will be many line and project managers who are not happy with me saying that you should scrap your project management office (PMO), but please just hear me out.
When I worked at a major truck manufacturer in Södertälje, a very senior R&D manager said something like:
“The PMO is unnecessary, let the functional organization do what they know best instead”
I was at this time working as an independent consultant at this PMO, and was as usually the youngest project manager among my peers.
Me and some of my colleagues at the PMO obviously thought what he said was nonsense and that he spoke in his nightcap, not understanding the benefits of having use there. Reasoning together and coming to the conclusion that “nothing” would work without us.
Now a few years later when I am a little bit more experienced, loaded with new insights and have jumped off my high horse, I am willing to agree with the senior managers words.
A PMO often tries to dictate command and control, and instead of being proactive we always seemed to be one step behind. With the typical symptom of constantly updating our plans and asking steering committees for added funding or postponed start of production dates.
Don’t get me wrong, we did some great stuff as well, like planning exercises very much alike the Big Room planning of the Scaled Agile Framework, but instead of doing it for smaller increments we did them for a whole project, spanning a couple of years, thus making them very hard to grasp.
My interpretation of what the senior manager really meant was that we should let the development organization focus on the creation of real customer value and not make them attend to meaningless meetings and create status reports among other things.
Value itself should come from discussions with the an empowered and strong product management team.
Reading this you won’t make you scrap your PMO and you probably shouldn’t either.
But what I think you should do as line or project manager, is try to act as a servant leader and help to remove the impediments that limits the communication between product management and development teams.
But also to help them to decrease the size of increments, limit the number of projects in progress and embrace change both in scope and in workflow.