Fallacy of the PMO

In UnitsOfWork, I talked about how teams who stay formed through a series of projects become better at converting units of value to units of work consistently. While re-reading this post, I realize that a great fallacy of the PMO is that it is not the project manager who is responsible for this process, but analysts and technical resources who make up a software development team. They key point of a PMO is to provide the consistent planning process so that the organization can form, disband, and reform teams to complete projects.

For the past few years, I have run something like a PMO. I managed a pool of analysts and project managers and testers that were assigned to virtual teams. I tried repeatedly to establish repeatable practices around planning and estimation. I established (with my project managers) standard practices around these. The two biggest frustrations the project managers were that the business stakeholders did not have a consistent practice for reflecting UnitsOfValue in requirements, and that the analysts and architects did not have a consistent practice for converting units of value into Units Of Work.

I am not saying that the projects or the project managers weren’t successful – most of them were. Good PM’s know how to wrestle a plan to the ground and make it tap out. What I am saying is that the practice of forming and disbanding virtual teams for each project is orthogonal to the development of a consistent repeatable planning practice, because of the project manager is not directly responsible for these two key inputs into the planning process.

The theory of having individuals grow together to refine a set of practices toward consistency when every project has different individuals is the opposite of what a PMO does. What the PMO does is to construct a set of theoreticals, and one or more flavors of project practices to cover different types of projects, and push these practices, top down, into the field. It (typically) does not get feedback from every project to improve its practices, because its focus is on driving consistency at a high level into all projects to improve organizational capabilities around governance, rather than driving consistency, predictability, and repeatability into every team, to improve the execution of every project.

No Comments

Leave a Reply