Unfortunately, in many cases, when a decision is made to set-up a PMO, all attention turns directly to the activities that need to be set-up with no consideration to the purpose, vision and design principles.  When you think about this it is very strange, you would not start on any activity on a project without defining the design?  So why do this for a PMO?

When setting up a project management office, make sure that you spend some time defining the purpose, vision and design principles for the PMO.  The aim being to capture these points on a single Powerpoint slide that can be easily understood and, more importantly, all stakeholders can connect with.


A good place to start.  What is the purpose of the proposed PMO?  Why does it (need) to exist?  Aim to capture this in a single paragraph that all stakeholders will resonate with and agree it makes sense.


When you have a solid ‘purpose’ for your PMO, then you can think about the vision of how you see the PMO operating i.e. will it just be an administrative / reporting PMO or a fully functional pro-active PMO?  Will it own the delivery with the project managers reporting to the PMO or be a facilitator?  Ask yourself (and the team) these questions and then capture this in 1 or 2 clear and precise paragraphs.

Design Principles

I like to define around 5 – 8 design principles for the design and ongoing running of a PMO.  These are a great reference to ensure that the PMO stays true to the mission.  While they will vary from organisation to organisation and by project, the following are good PMO design principles for most PMO’s.

  • Pragmatic – only do something if it is needed and adds value.
  • Fir for Purpose – avoid over engineering and duplication of tools and processes.
  • Transparency – ensure clear and consistent reporting (the principle of no surprises).
  • Consistency – ensure consistent and a normalised approach across all projects / programmes.
  • Strategic Alignment – ensure projects / programmes are aligned to strategic objectives (if not why are they being done?).

You can add more or adapt to your particular needs and requirements.

You can then refer back to these principles over the lifetime of the PMO to ensure that any proposed report, process, etc is really needed.  This approach will win you a lot of respect with the project and programme managers and helps the PMO being labelled an administrative overhead.

Finally, the other test I like to apply is the “so what” rule.  When somebody proposes a new report, process, etc ask “so what if we don’t do it”, keep asking “so what” until you are happy there is a valid reason or there is realisation it is not required.