10 practical pitfalls of the PMO

Based on our experience, we have created a top ten of pmo pitfalls with advice about how to avoid them.

Gartner Research & PMI estimates that Project Management Offices (PMO) have a success rate of less than 50 percent when first set up. Mojeo helps project organisations to ensure that they are successful in setting up their PMO from the start and helps to avoid the pitfalls that lead to failure. Based on our experience, we have compiled a TOP TEN PMO FAILURES and of course we are happy to give advice on how to avoid them.

Pitfall 1: The PMO plays "police method"

If there is a true common denominator for failed PMOs, this is it: The PMO becomes the ‘Methodology Police’ that often tries to rigorously enforce their methodology. In the best outcome this leads to complaints and frustration of Project Managers; in the worst case it causes revolt and complete ignoring of the PMO. Instead of offering help to Project Managers by creating cohesion in the project management methodology, the PMO becomes the biggest enemy of the Project Managers. The PMO loses the sight of the project portfolio and fails due to lack of support.

Pitfall 2: Method without framework

Some PMOs try to implement a Software Development Life Cycle (SDLC) within their organisation. This is amazing for software development teams, but may be completely unimportant for infrastructure teams and process improvement teams for example. A better structure is an overall project management framework, with only elementary phases and gates and a number of important project management products (business case, project planning, status report, etc.). This is also known as a PDLC (Project Development Life Cycle) and many different SDLCs fit into this category, adjusted to the requirements of the different types of projects.

Pitfall 3: Not implementing a methodology

Are we contradicting ourselves? Not really. If the PMO doesn’t implement an overall framework, it can’t provide oversight of the projects. A methodology is required to ensure the consistency of the implementation of the project and to decrease the risks resulting from inexperienced Project Managers for example. A junior Project Manager, for instance, often isn’t capable of creating the right project schedule, may misjudge the allocation of work, or could forget risk assessments, which leads to problems during the project, leading to heroic efforts being needed to get a project back on track. An established method is therefore essential.

Pitfall 4: Failure to match demand with availability

During meetings of the steering group, the focus is almost always on prioritising. That’s good because good priority processes result in good understanding of the project’s requirements. But when it’s about the decision how many of the important projects can actually be carried out, it’s often pure guesswork; “How overburdened is your department, Roger?” Or “If we implement the Top 10 projects, can we do that in terms of work load?” Without a unit-bound concept of the resource capacity, it’s impossible to correctly match the actual supply of resources to the requirements of the projects.

Pitfall 5: No time registration

This is actually the source of PMO Pitfall 4. Without keeping track of actual hours spent on actual projects and other work, it is impossible to know the real capacity of the project organisation. Planning, even at the most detailed level, becomes mere guesswork if it is not linked to actual hours.

Pitfall 6: Gathering unnecessary information

PMOs are good at collecting all kinds of statistics. If this information isn’t used in the decision making, why are you collecting it? It only creates extra work for the project team, without actually leading to a result. An example of this is the collection of time data at a detailed level, including issues such as ‘responding to email’, and ‘attending a meeting’. For planning purposes, it’s only necessary to know how much time each resource has spent on main tasks, and subtasks can be summarised under a single header, ‘record keeping’ for instance.

Pitfall 7: Keeping track of an ad hoc project request is impossible

The most common process for handling new project applications is to analyse them and decide per request whether it really is a new project. But how does that work when there are 100 project applications? How do you prioritise? The upgrading of the OS on the servers can be important, but is that more important than the new data centre in EMEA? When you evaluate new applications individually, each ‘important’ project application supersedes the already active projects. The result is a complete switching up of active projects. The solution is to handle applications cyclically, so all project applications are placed next to each other and therefore the applications that are most important to the organisation are given priority. How many project applications need to be implemented? See pitfall 4: not tuning demand and availability.

Pitfall 8: Lack of executive support

This should be very obvious, but it happens all the time. The executive team realises there’s a problem with projects that are not executed properly, due to a lack of resources for instance. So they give the PMO power and hope the problem is solved. But then they send less senior individuals to the steering group meetings and don’t give them decision-making privileges. Or, worse, they overrule PMO decisions. If projects perform badly, as a result of priority conflicts or lack of appropriate resources, they blame the PMO and dissolve it.

Pitfall 9: Implementing a tool without a process behind it

Another obvious problem. Whether it’s about the implementation of a PPM solution or an ERP system, if there’s not a good process behind it, you’re asking for trouble! IT departments often seem to think that the tool is the solution, but it’ll surprise you how many other organisations fall into the same trap. The usual excuse is that the tool already has ‘best practices’ built into it, so why not simply follow those? Our experience is that every organisation is different and therefore they all require a tailor-made solution, based on their own ‘best practices’.

Pitfall 10: Implement a tool and the process simultaneously

The standard advice seems to be to make the processes clear first, before automating them with a tool. This can cause big problems for the PMO. Complex processes are about spreadsheets and documents get heavier and heavier if the right tool isn’t used for the process. Our advice is to implement the process and tool simultaneously. This has the following benefits; firstly, you can design the new process based on the strengths of the chosen software tool. Secondly, users learn to use the new working method and tool immediately. Finally, the new working method has the best chance of being accepted if users are able to immediately start using the new tool from the beginning. However, there’s a disadvantage to this approach. If something goes wrong, you do need to be able to discover whether it’s because of the process or the tool. Because the tool often gets blamed, even though it’s not always the problem.