I was speaking at a SIM (Society for Information Management) event the other night, when the question came up "What's the most common mistake you see PMOs making?". A great question, and a really great blog topic! At EffectiveIT Group, we encounter several PMOs a month, and so we have ample opportunity to see the good, the bad, and the ugly of PMOs.

So, here are my most commonly observed PMO mistakes. Feel free to add your own or comment on these!

1. PLAYING COP. If there is a common refrain to failed PMOs, this is it. The PMO becomes the "Methodology Police" and enforce an often ill-fitted SDLC rigorously. This leads to complaints from project managers at best, and open revolt and ignoring the methodology at worst. Rather than becoming an aid and guide to project managers, and creating consistency in PM practices, this PMO has become the PM's worst enemy, loses visibility into the project portfolio, and leaves a bad taste in everyone's mouth.
2. IMPLEMENTING AN SDLC. OK - this might sound heretical, but hear me out. I have seen many PMOs implement an SDLC, literally a "Software Development Life Cycle". This is great for the software development team, but drives the infrastructure and process improvement folks nuts! The point here is, one size does not fit all. A better structure is an overall project management framework, with just the basic phases and gates and a few key controlling artifacts (business case, project schedule, status report, etc.). This is sometimes known as a PDLC (Project Development Life Cycle), and many different SDLCs can fit under the framework, tailored to the need of the project type.
3. NOT IMPLEMENTING A METHODOLOGY. What, am I contradicting myself? Not really. If the PMO does not implement some kind of overarching framework, it cannot create an apples-to-apples view of the projects in the portfolio. Further, federal regulations, especially Sarbanes-Oxley, require methodologies that meet their requirements.
4. NOT MATCHING DEMAND TO SUPPLY. I've sat in on many a Steering Committee meeting, and the focus is almost always on prioritization. That's great, and a good prioritization process results in a good understanding of project demand. But when it comes to deciding how many of the top projects can actually be done, discussion usually turns to pure guess work! - "How overloaded is you department, Tom?". "If we take on the top 10, can we handle the load?" Without a metrics-based understanding of resource capacity, it is impossible to match that wonderfully organized demand with the actual supply of human resources.
5. NOT TRACKING TIME. This is actually the source of number 4. Without tracking actual time worked on actual projects AND other work, it is impossible to know any department's true capacity. Planning, even at the most detailed level, is merely guesswork if it does not involve the feedback loop of actual time.
6. GATHERING UNECCESARY INFORMATION. PMOs are great at gathering all sorts of statistics, from very detailed SDLCs (see number 1 above!). If that information is not used in the decision-making process, why gather it? It just creates an extra burden on the project team without generating any useful result. Example: gathering time data at the detail task level, including sub-day tasks like "Enter time", "Check email", "Respond to email", "Attend staff meeting". These may be useful reminders as tasks, but for planning purposes all we really need to know is how much time each resource is spending performing "Admin" tasks.

There's more - but that's my list for today. I'm sure you have others to add to the list - please do! And if you want to hear more on any one of these topics, please let me know. I'll try to address it in a future Blog.

- Dave Blumhorst

  CEO - EffectiveIT Group

  www.effectiveitgroup.com