A good PMO starts with the end in mind

iStock_000017434800Small - planningAll projects evolve as they go through the project lifecycle. Plans will become more definitive  on a rolling basis. Designs crystalise and solutions get identified and adopted. Vested interests become apparent and often new or somewhat hidden requirements come to light.

But even in the most ambiguous of circumstances most projects have a fairly clear overall objective. What evolves is the detail around the solution to meet that objective and the means of delivering that solution.

The PMO ‘problem’

However, all too often the control and reporting environment – or PMO and governance model – around the project is allowed to evolve as a reaction to the evolving project rather than as a means of ensuring the evolution of the project in a controlled way. What results are new processes and reporting requirements that are created on the fly as a reaction to the changing project environment.

This often leads to duplication of data collection with similar data collected in slightly different formats to meet the ‘needs’ of differing stakeholder groups. This in turn leads to project teams getting disgruntled with producing multiple sets of reports or returns and the labelling of the PMO as bureaucratic data shufflers. Project teams are often left reacting to stakeholder demands without a coherent strategy to demonstrate they are in control and are constantly distracted from their real job of delivering the project.

How do the good guys do it?

In the most project savvy of organisations this situation would not be allowed to arise. They have clearly defined processes and controls set at just the right level to provide demonstrable control without over-burdening bureaucracy. They have good project, change and delivery methodologies in place with all project participants trained in, and understanding their role in, managing and delivering the project. Their PMO and governance control model evolves with the project, but hand in hand with it to provide control to the overall evolution, not driven to all points of the compass by it.

Start with the end in mind

What can you do if you don’t work in one of these project savvy organisations. Start with the end in mind! You have the project objectives so use them to drive out your stakeholder map. Map out the stages of your project and the likely changes in the stakeholder landscape. Then build your control environment with the flexibility to meet those changing demands. Discuss and agree compromises up front to meet diverse demands, explaining the benefits of efficiency and cost saving. Defuse issues before they even become issues.

Recognise up front that there will be some constraints. No matter how inappropriate certain corporate reporting requirements might seem (and actually be!) your little (or even large) project won’t be able to avoid them. That’s just happened to me in a PMO I have taken over. An independent reporting process had been defined and implemented and low and behold I no find out as I’m taking over that there is a corporate standard that must be followed. It doesn’t surprise me because I’ve seen it so often before.

Just as your project has objectives, so does the PMO and governance and control environment.  Do a bit of digging and these will become clear and can be stated in terms of:

  • Stakeholder engagement
  • Reporting
  • Planning and tracking
  • RAID management
  • Financial management
  • Resource management
  • Change and quality control

The level of detail will evolve, but if you know your audience (your stakeholders) and the project objectives, you can map the governance and control environment and evolve it in a controlled manner over the life of the project.

Build things in from the start instead of cobbling together ad-hoc solutions driven by emerging situations. For example, create your document management strategy at the outset, correctly classifying and storing all project documentation from the outset. That way when the project closes it will be easy to delete or destroy the documents that don’t need to be retained and archive those that do. I’ve seen many hours wasted searching for documentary evidence of sign-offs or delivery in the latter stages of a project, and whole shared drives being examined to see if the contents needed to be retained for legal purposes. All because they didn’t start with the end in mind.

So save your project time and money and yourself a few grey hairs by planning your PMO’s governance and control environment up front.

Tagged with:
One comment on “A good PMO starts with the end in mind
  1. John Carroll says:

    My experience sounds very like yours Allen and everything you have said makes good sense, but I would add two more factors from my experience:

    1) Understand the level of Organisational Maturity you are starting from and plan where you want to get to with the PMO, but take it one level at a time.

    2) Involve the organisation’s project managers in the PMO process so they can bring a level of hands-on knowledge and real-world feedback to the standards, methods and reporting processes introduced.

    I have set the whole process out in chapter 5 (Organizational Maturity) in “Project Program and Portfolio Management in easy steps” and no there isn’t a missing comma after “Project”.

    Keep up the good work,
    John.

1 Pings/Trackbacks for "A good PMO starts with the end in mind"
  1. […] Allen Ruddock recommends that the PMO start with governance and work backwards from there. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*