PMO Process Purge


I'd like to share a PMO Antipattern with you. For those of you who are unfamiliar with the term - antipatterns are repeated practices that initially appear beneficial, but result in consequences that outweigh any of the hoped-for advantages.

This particular antipattern goes something like this: A PMO is formed with a mandate to solve a specific business problem or need. The PMO puts new, efficient processes in place. They train the business in new ways of working, and use KPIs to demonstrate their success. Snr Management are impressed with the impact the PMO has had. Department Managers are impressed with the impact the PMO has had. Everyone is happy with the impact the PMO has had. They think of all the problems they have that the PMO could help them solve. The PMO take on more and more processes and services. Now the PMO is stretched and reduces its engagement in some areas to little more than a veneer, but keeps its original, 'core' processes in place as these have proved their worth to the business in the past and they are what the PMO was founded for. Dissatisfaction with the PMO increases. The 'light-touch' approach applied to new business challenges is not having the desired effects. The core processes and services that the PMO was once praised for are now seen as being 'overly bureaucratic'. People start viewing the PMO as being a blocker, rather than an enabler. 6 months later, the PMO is disbanded - another statistic for a future Standish report.

So what went wrong? The first mistake was that the PMO did not critically assess the value it could add to the business problems it took on. The PMO had robust processes for assessing and prioritizing business cases for new projects, but inexplicably did not apply these same processes when taking on additional PMO services. The second mistake was that the PMO did not review the original 'core' processes and conduct regular purges. This article focuses on the second of these mistakes. 

When new processes or services are implemented, they solve a particular problem, or set of problems. to ensure the process 'sticks' the process is defined as a series of tasks that have to be followed. Templates and gates are introduced, and compliance checks are put in place. These controls are essential to ensure the process is adopted. But processes mature, the draconian level of control can, and should be reduced. PMOs should be constantly looking for opportunities to strip back controls on mature processes and hand processes back to the business. Ask yourself the following four questions:

  1. If the PMO stops tracking this process, will the business suffer? (note, a small amount of suffering may well be acceptable when compared with the effort that would be saved within the PMO).
  2. Does the problem that this process was designed to fix still exist? (changes in personal and organisational maturity may well have removed the problem that the process was originally trying to solve).
  3. Who benefits from the process? (some processes that were originally beneficial may now actually be creating disbenefits due to the number of non-value adding steps).
  4. Who would shout if we stopped offering this service tomorrow? (it is not uncommon to find that the business would actually celebrate if you removed a particular process or 'mandatory' service!).

PMOs should regularly purge processes from their portfolio. Doing so allows them to be nimble and focus on the business challenges that are important to the Snr Management team. Doing so allows you to diverge from the antipattern outlined above.  With this in mind, I offer you this challenge: Go back to your PMO and look at every process, procedure and service with fresh eyes. Ask yourself the four questions above and see how much legacy bureaucracy you can purge from your PMO and your organization. Let us know how you get on in the comments section below!