PMO tips – 5 actions for a PMO to quickly add value

Unfortunately, there is still an unfair perception that PMO’s add little value, often being labelled as adding layers of bureaucracy.  While completely untrue, this is something that anyone tasked with setting up a PMO needs to be aware of and actively manage.

An important aspect to managing this is delivering value early.  Unfortunately, most stakeholders will not be prepared to wait until the completion of the PMO implementation project to see value – especially if they are concerned that the PMO may never add value.  So the smart PMO manager needs a ‘game plan’ to deliver some early wins onto the scoreboard.

Below are 5 actions a PMO can take to quickly start demonstrating value.

1. List of Projects

In many organisations with no central PMO, it is quite likely that there is no single list of all of the projects – no project inventory.  Therefore, it is difficult for senior management to understand exactly what projects are active, who is running them, budget, etc.  This can result in regular fire drills from management to try to uncover what is going on.

The PMO can take the lead in building and maintaining a central register of all projects (active, complete and pipeline).  Make sure that the list captures key aspects of each project:

  • Project ID
  • Project Name
  • Project Description
  • Grouping (if applicable i.e. Business Area / Function / Country, etc)
  • Project Sponsor
  • Project Manager
  • Project Budget
  • Project Benefit
  • Start Date
  • End Date
  • Status (active, not started, complete, cancelled, etc)

Ideally try to fit all of the projects on a single page if possible and add totals to all of the budget / benefit columns.  You may also want to order by Grouping and then Status.

While a simple document, this is important information that will be valued by senior management.

2. Standard Reporting

If you have completed action 1, senior management will be happy to know the complete list of projects.  However, this will quickly lead to them wanting to know how each one is progressing.

By implementing a standard status report (ideally based on an existing format) on a regular basis, you will quickly be able to provide senior management with the status of all of the projects in a common, consistent manner.  The individual submissions should be used to generate an overall dashboard, using a common RAG rating system so as to allow the rapid identification of projects that have challenges.

Again strive to fit the dashboard onto a single page containing only the information required by senior management.  Where possible, you may want to combine the List of Projects with the Dashboard – big time saver.

3. Define RAG Levels

If you let the project teams set the RAG status with no guidance, it is high likely, in fact certain, that all will have their own view of what constitutes Red, Amber, Green.  This causes a problem to senior management as some projects may report Amber when they should be Red and others Red when they should be Amber.

The PMO can quickly address this by defining standards for the RAG settings and then communicating them to all project teams.  The settings must be clear, precise and with little room for interpretation.  This will help ensure that the RAGs are then set across all projects on a like for like basis.

4. Contact List

A lot of time can be wasted as it is not clear on who should be contacted in respect of each project or even the PMO.  Building a list of project managers, sponsors, etc clearly identifying the projects will provide a simple but effective way for the correct person to be identified when somebody has a question.  The list should also include other key contacts (including PMO).

5. Steering Committee / Governance Schedule

It is high likely that the active projects will have steering committees.  There may also be an overall governance meeting for the projects.  There is often confusion on when these meetings take place, submission date of inputs, paper publication dates, etc.

The PMO can build and maintain a list of all meetings so that it is easy to see when meetings take place and, importantly for the project teams, when papers need to be ready.

In summary

It is important for a PMO to deliver value early.  Implementing the above, especially the List of Projects and Reporting will add value quickly and promote confidence that you are in control and making progress.  This will result in a higher probability that you will continue to receive support as you implement the other aspects of the PMO.

PMO Charter

This blog post will cover the importance of producing a PMO charter.  As I have mentioned before, there is no such thing as a standard PMO.  They are all different and should be designed to meet the objectives of the organisation while, being aligned to the culture of an organisation.

What is the purpose of PMO charter?

The purpose of a project charter is to define the scope, objectives and participants of a project.  The same is equally true of a PMO charter, it defines the scope of the PMO i.e. oversight of all change programmes over £5 million of spend, the objectives of a PMO i.e. promote the use of standard project delivery methodology to improve the probability of success and participants i.e. define the PMO organisation structure and name role holders.

A PMO charter is simply a document, normally designed in a word processor or presentation.  The document will contain words and diagrams to clearly articulate the scope, objectives and participants of the PMO.  It is important that the document is direct and to the point.  This helps to ensure that the key points are easy to understand and, does not discourage people from reading (a long document may have ‘thud’ factor but many will be put-off from reading, important points will be missed and it could be viewed as being bureaucratic).

What to include in the PMO charter?

The key points to cover in a PMO charter is:

  • Background – set the context and reason for setting up the PMO
  • Scope – make it clear what services the PMO will provide (“what it will do”).  It also is worth capturing specific services that will not be provided (especially if they are what may be expected).
  • Organisation Structure – explain how the PMO is structured and who covers each role.
  • Engagement Model – document how the PMO will engage with projects and stakeholders.
  • Services – provide more information on the services that will be provided by the PMO.

You should also add details of any specific service or responsibility over and above the points listed above if it is important and / or required by your organisation.  Remember, the PMO is designed to serve the needs of your organisation.

For more details, you may want to visit the post How to develop a PMO charter.

PMO Monthly Reports

The last post covered why it is helpful to establish a PMO reporting calendar so as to ease the task of collecting updates from all the project managers. So if you have been successful in putting this in place and all of the project managers are submitting their status reports, what next? You had better do something meaningful with them otherwise you will soon have a bunch of disgruntled project managers on your hands and no reports in future months.

On a serious note, you should aim to collect the following from the project managers for the PMO reporting.

Monthly Reporting Data Items

You should ask (expect) the project managers to provide the following:

  • Status Report
  • Milestone Update
  • RAIDs Update
  • Schedule Update
  • Costs Update
  • Benefits Update (if applicable)

The PMO should review all of the reports to make sure that they are accurate and make sense. If the PMO is aware of an emerging theme that is not correctly reflected in the reports, they should discus this with the project manager so the report can be updated. Remember one of the responsibilities of the PMO is accurate and timely reporting. How can senior management make decisions if the report is incorrect?

PMO Reporting

When you have all the reports with accurate information, you are ready for producing the PMO reporting.  What this means is taking all of the reports from the projects and consolidating them into dashboards that provide a clear overview of the status of all projects.

It is very important to invest time into building effective dashboards.  A good dashboard will definitely get the attention of senior management meaning the PMO will be seen to be in control and doing a good job.  Don’t invest the time and the information will be questioned and will raise concerns in the minds of senior management.

Take a look at the post on 5 Things you need on a propject report for some more ideas.

Project Mobilisation Heatmap

Programme Mobilisation Heatmap

If you are struggling defining reports, consider investing in a set of project templates.  It is far easier to use or adapt a template that has already been put together.

PMO tips – PMO reporting calendar

As part of managing or working in your PMO do you find that it is a constant battle with the project managers to get timely project updates?  This is an experience everyone in a PMO has experienced at some point.


When you chase a project manager for the status update, it is not unusual for them to act as if they did not know about the request, claim it is yet another ‘fire drill’ diverting time from ‘real delivery work’ and then go around telling the sponsor and everyone else who will listen that the PMO is creating bureaucracy!


At this point I just want to remind everyone that one of the responsibilities of the project manager is to provide frequent and accurate reporting of their project.

What not to do

As reporting is part of the job description of a project manager, it is very easy (even tempting) to state the fact “it is your responsibility”.  Followed very closely by “the reporting is required for <name of CEO of your organisation>”.

While both are factual statements, they will not get the reaction you require.  If they do, it probably will only be the absolute minimum.


Like with any challenge, it is good to break it down into components that can be addressed.

1. Is the report really required / too complex?

Make sure you validate that all the information requested on the report is really required and will be used productively.  If not redesign and rationalise.

2. Reporting frequency

Are the requests to frequent meaning that project teams are spending a lot of time constantly preparing reports?  Work out how often you need updated reports so a to maintain the required level of visibility to allow timely interventions.  This will vary from project to project depending on duration.  A short 3 month project probably needs weekly reporting, a 2 year project probably can be monthly.

3. Leverage existing reporting

Does the project already produce a frequent update for their working / steering group?  If so look to see how the same data can be used to service the reporting to the PMO.  If they are using a different format / template and it is difficult to get them to use the standard PMO template, don’t ask them to complete both versions, make the effort to transfer the data for them and then ask them to review and sign-off.

4. Reporting calendar

Many project managers do not provide updates on time because they and their teams are unclear what is required by when.  In defence of project managers, they usually have a lot to think about.

PMO’s don’t help as reporting requests are buried in e-mails, a 30 second update in AOB of a meeting, etc.  While these should still be used, make sure you create a simple reporting schedule on a single page that clearly articulates:

  • Date report to be submitted
  • Date reports will be published
  • Date of meeting material will be used (if necessary)

This is then communicated to all project teams and constantly referred to in meetings, etc.  This helps overcome the risk that the project manager thinks that the requests are ‘fire drills’ and you will be very surprised how quickly it becomes part of their routine.

There is also an element that writing it down on paper somehow makes it more real!

PMO Functions

There is no such thing as a typical PMO.  The very fact that all organisations are different in style, culture, principles, etc, means that an administrative PMO in one organisation will look different and behave differently than one in another organisation.  The good news is that there is no right or wrong answer on how a PMO should look and behave, as long as it is “fit for purpose”.

However, while they may look and act differently, there should be a core set of functions that will (probably) be performed by a typical PMO.

PMO Functions

The diagram below gives an overview of the typical PMO functions and activities.

PMO Functions


This provides the definition of how the projects, workstreams and PMO will be governed.  It should capture the appropriate forum’s, meetings, steering committees, etc together with escalation paths and approval thresholds.  This is particularly important for Change Requests and Business Case approvals.


Documentation of PMO organisation to clearly identify roles.  This should be accompanied with clear responsibilities.


Project planning is all of the activities to define scope, estimate costs and create a project schedule that will enable the desired outcome to be delivered.

Financial Management

Chapter 7 of the PMBOK is dedicated to project cost management and uses the following definition.
“Project Cost Management includes the processes involved in estimating, budgeting and controlling costs so that the project can be completed in the approved budget.”
PMO Cost Management provides a framework to complete the cost management activities in a standardised manner.


Benefit Management is:
“The processes involved in estimating and monitoring benefits so that the value can be realised”.
PMO Benefit Realisation is the process of releasing the value of the benefits.

Benefits fall into 2 broad categories:

Tangible Benefit
This is typically a benefit that can be measured numerically i.e. reduction in costs, increase in profit, reduction in headcount, etc.
Tangible benefits tend to be easier to quantify and demonstrate that they have been achieved.

Intangible Benefit
These are more difficult to measure numerically i.e. reduction in operational risk, improve reputation, provide better customer experience, cost avoidance, etc.


The process of identifying, managing and reporting the risks, assumptions, issues and dependencies that may impact the successful delivery of a project.  It allows informed decision making on what mitigation actions to take.


The process of providing an accurate and timely update of the status of a project, programme or workstream so that there is common understanding of status.  This allows the rapid identification of risks threatening the successful delivery of the project so that timely interventions can be made.

Quality Assurance

The process of reviewing the quality of project execution NOT the quality of the deliverables from each project i.e. delivery of software component.  Ensuring the quality and discipline of project execution should result in a better quality of project delivery.

Change Control

Change Control is the formal process to ensure that changes to the agreed scope, schedule, benefits and budget of a project are introduced in a controlled and coordinated manner.

Resource Management

The process of identifying and adding the required resources to the project to enable successful delivery.

Communication Management

The PMBOK defines communication management as:
“The processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval and ultimate disposition of project information”.

Procurement Management

The PMBOK defines the procurement process as being:
“Project Procurement Management includes the processes necessary to purchase or acquire products, services or results needed from outside the project team.  The organisation can be either the buyer or seller of the products, services or results of a project”.
In simple terms it is the process of getting the “stuff” needed to successfully deliver the project.

Document Storage

Project document storage is the standard approach to the naming and storage of all project documentation so that they are securely stored and can be easily accessed by all project and PMO members.

This is a very quick and high level overview of the typical PMO functions and activities.  This will vary between different types of PMO.  You can visit blog post How to set up a PMO for more information on each of these function.

Define a programme management office

After you are happy with the PMO mission, PMO vision and PMO design principles, you are now ready to define the program management office, with a level of confidence that it will be aligned to the overall objectives for the organisation.

What type of PMO?

As a PMO should be defined to support a particular organisation, while there will be core functionality, each PMO will look at behave differently.  This is further compounded due to the fact that PMO’s will be at different levels of maturity.

The PMO Maturity model defines 6 levels of maturity as:

  • Level 0 – Nonexistent / ad-hoc
  • Level 1 – Initial / reactive
  • Level 2 – Developing / emerging discipline
  • Level 3 - Defined / initial integration
  • Level 4 – Managed / increasing integration
  • Level 5 – Optimised / enterprise orientation

As the level of maturity increases so does the value added by the PMO.

However, the maturity model does not really provide specific guidance on defining the PMO you want to build.  What it can be used for is to evaluate, based on the mission and vision statements, where your PMO needs to be based on the current level of maturity.  Knowing this will help define that needs to be addresses and / or constructed.

Easier PMO Model

I take a simpler view on the definition of a PMO, namely to split into 3 distinct categories:

In some cases, the mission and vision statement may only require an Administrative Reporting PMO and there is no need to invest moving towards a Managerial PMO.  This does not stop the PMO becoming a highly valued function that moves up the maturity curve.

Diagram showing PMO maturity

Having a clear view of the objectives of the PMO will help to define what type of PMO you need / wish to build.  This in turn will allow you to work out what functions and activities need to be included.  This should be documented and then shared and agreed with stakeholders to make sure that it is aligned to their objectives and, probably more importantly, their expectations.

In Summary

Use the mission, vision and design principles to define the PMO you need to construct.  Be mindful of the PMO Maturity Model with the main focus on building a PMO that works for your organisation.  Then look to improve the chosen model as required.

PMO Design Principles

In the last 2 blog posts have covered the importance of having a PMO Mission and PMO Vision Statement.  Having both of these well thought out, clearly documented and communicated, means you are in a position to define some key PMO Design Principles.

What are PMO design principles?

Very simply, they are the rules and principles that will be followed in the design of the PMO.  In theory, if you have designed your principles to align to your mission and vision statements, you should be designing a PMO to support the strategic direction of the organisation.

As you design each component of the PMO, you should check what you are proposing against each of your design principles.  If what is being proposed is aligned, then it can be included.  If it does not, you need to review and rework the approach so that it is aligned.  Note: is you are finding it hard to align a particular component to the principles, do not be afraid to review the principles to make sure that they make sense.

 How to establish PMO design principles?

The PMO Manager and, ideally, other team members should take the mission and vision statement and then come up with a number of rules and principles that, if applied, should ensure the PMO will execute its duties aligned to the mission and vision.

This works well in a form of workshop where the mission and vision statement can be posted on the wall.  The attendees can then capture and debate principles so as to come up with approx. half a dozen that capture the sentiment of both statements.  It is a good idea to use the end of the session to check and validate that the principles cover all aspects.


It is a good idea to ask key stakeholders, especially the PMO sponsor to review and validate the principles.  This provides a further check that the principles are aligned, allows for them to be adjusted and enables buy-in from senior management before being formally communicated.

Example PMO Design Principles

  • Pragmatic – only do something if it is needed and adds value.
  • Fit 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?).

Where to capture the PMO design principles?

These should be captured in the same place as the mission and vision statement i.e. key presentations, PMO charter and PMO terms of reference.


Spending the time to define design principles before rushing ahead with building a PMO should help ensure that you construct a PMO aligned to the objectives, only build the functionality that is required (which avoids bureaucracy), meaning that it offers the correct level of support and oversight to the project teams.

It is also good practice for the PMO to conduct a periodic review that the principles are still fit for purpose and that they are operating in accordance to the principles.

PMO Mission

Following on from the post PMO Vision statement, this post will cover the topic of PMO Mission Statement.  Both are important and help when setting up a PMO.

Difference between PMO Mission and PMO Vision

It is worth spending a moment understanding the differences between a mission statement and vision statement.

The aim of the Mission Statement is to define the business / organisations purpose and primary objectives / goals.

The aim of the Vision Statement is to also define the purpose of the business / organisation.  However, this is done in terms of a business / organisations values.

PMO Mission Statement

When you have been asked to set-up a PMO it is a good idea to develop a mission and vision statement.  If you already have a PMO up and running and do not have a mission and vision statement, it is worthwhile taking the time to create them.

The reason it is good, is that it helps focus the mind on what you and your organisation wants to achieve by setting up a PMO.  Knowing what you want to achieve informs the design.  This is very good as it helps prevent a PMO being formed for the wrong reasons and, in my opinion, much worse a PMO with no direction or clear purpose that is perceived as ‘low value’ by the rest of the organisation.

A clearly defined mission statement should be something all PMO team members can connect with, as well as the rest of the organisation.  Everyone feels a clear purpose and knows what they are trying to achieve.

Example PMO Mission Statement

You may define the mission statement along the lines of:

“To provide a high performing PMO to fully support the change agenda by implementing sound project management practices.  The aim being to enable 80% of projects and programmes to deliver the defined benefits in their business case.  Achieving this will support the overall strategy of the organisation to be ranked in the top 5 of our industry peers”.

Or the statement could be in more direct bullets:

  • Provide a group wide standard approach to project delivery
  • Provide full and accurate visibility of project status
  • Provide effective prioritisation of project management resources to support the strategic change agenda.

Remember these are just examples, your mission statement must be appropriate and relevant to your organisation.

Where to capture the PMO Mission Statement?

Like with the vision statement, it should be captured in key presentations, PMO charter and PMO terms of reference.


Spend time thinking about your missions (and vision) statement.  It will result in you building a better PMO.

PMO Vision

PMO VisionOver recent years, more and more organisations have decided to set-up PMO’s.  Some are purely for individual projects and programmes.  However, increasingly they are being set-up on a permanent basis.  Therefore, given that this involves an investment by the organisation, it is important to maximise the benefit delivered.

When a decision is taken to commence a project or programme, it is usually that somebody has an idea, a vision of what they want delivered.  You will often see “vision statements” included in presentations and business cases to help gain support for the project.  Therefore, if a decision is taken to invest in a PMO, the same logic should apply, more value can be gained and more support, if there is a clear PMO vision.

What is a PMO Vision?

Very simply, it is a short aspirational description of what an organisation would like to achieve as a result of forming a PMO.   As the statement is short, a single paragraph or up to half a dozen bullets, it is important that the words are chosen carefully.  The words need to strongly convey what the service and culture of the PMO will look like over time.

Why it helps?

Spending quality time considering the PMO vision statement, will help shape what type of PMO an organisation would like to build so that it is best aligned to support the strategic objectives of an organisation.  This is a good investment as the last thing an organisation should do is march ahead building a PMO that may not be fit for purpose.  This would be a waste of time and money.

By capturing the vision statement, it allows the stakeholders to review and validate how the proposed PMO will align to their requirements.  This is a good test as sometimes stakeholders don’t know why they are asking for a PMO and it helps them collect their thoughts.

Where to capture a PMO Vision statement?

When a strong statement is agreed, it can then be communicated within the organisation.  This allows everyone to understand the vision for the PMO and, if the statement is published by senior management, provides the person tasked with setting up the PMO will the all important mandate.

Good places to capture the PMO vision statement is in a PMO charter or terms of reference.  It should also be used in any presentations and posted on the central PMO intranet site.

Consistent message

When you have agreed the PMO vision statement, it is important that it becomes part of the culture, DNA of the PMO.  Make sure that all PMO members and stakeholders are aware of the statement.  When making decisions, be mindful to ensure that they are aligned to the vision.  Don’t just forget about the statement, this is a sure way of not achieving the long term objective.

What does a PMO vision statement look like

The statement can take many forms and must be written for your organisation.  Don’t just ‘lift’ a statement from another firm.  All organisations are different and the statement should really reflect the personality and strategic vision.

The statement can be a single sentence, a paragraph or bullets.  The key is that it must be powerful and convey the vision of the organisation that is easy to understand and for people to connect with.

A PMO statement may look like:

The PMO supports the implementation of the organisations strategic objectives by providing a full set of professional PMO services.  Working in partnership with project teams, stakeholders and sponsors to attain successful outcomes. 


A PMO vision statement is a powerful tool for conveying the purpose, style and vision of a PMO.  It acts as a great reference point to ensure the PMO is aligned to the overall objectives of the organisation.

Please take time to view post PMO purpose, vision and design principlesfor more information on this topic.

PMO assumptions

It is typical that when a project or programme is being planned, that the project manager has to make a number of assumptions in order to create the initial project schedule, budget, resource and benefit profile.  The reason this is necessary, is that in the early stages, a lot of the detailed analysis will not have been completed (or even started).

The use of assumptions allows for initial plans to be constructed without investing the time, budget and resources in completing the detailed analysis.  This is good for the sponsor as it means they can get an estimate without having to invest to have the detailed analysis completed.  This in turn should allow for an informed decision to be made.

If assumptions are going to be made to support the estimates, it is important that they are accurately documented.  This will allow them to be reviewed by all stakeholders to establish if they are comfortable with the assumptions.

In order to support this, the PMO should ensure that there is a recognised process to capture and document assumptions.  This will normally be in the form of a register, usually in table or spreadsheet format.  It should allow important details to be collected about the assumption to be listed including:

  • Assumption name
  • Description
  • Date identified
  • Identified by
  • Impact if assumption is incorrect
  • Owner
  • Target resolution date

The PMO should check to make sure that each project is capturing and documenting assumptions using the defined process.  It is also sensible for the PMO to review the assumptions before they are formerly presented to the sponsor.  This will allow for the assumptions to be tested and refined.  This should be seen as helping the project manager NOT trying to catch them out!

While it is important to capture assumptions during the planning process, it is also critical that assumptions are proven to be correct or not correct as soon as possible.  For example, if a project schedule and budget has been based on the assumption that a new accounting process will be able to be used on a global basis meaning only a single software program needs to be written, then it is important to prove this assumption is true.  If not, it may be necessary to build several versions to support the accounting processes for a number of countries.  This will result in increased time and costs and may make the project not viable.

Due to the risks in assumptions proving to be incorrect, the PMO should make sure that each project is taking the action to prove the assumptions.  The PMO should regularly review the assumption log with the project manager and track if the assumptions are being closed out in line with the target dates.


  • The PMO should define an assumption process and tools.
  • The PMO should review the initial assumptions with the project manager.
  • The PMO should regularly monitor that assumptions are being closed out in a timely manner.

For more details, take a look at post PMO tools – Risk, Assumptions, Issues, Dependencies.