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.

PMO risks and issues

This blog post will share thoughts on how to make PMO risks and issues real for stakeholders so that they take them seriously and take action.


Most PMO managers and project managers know that it is part of their responsibility to identify and manage the risks and issues.  The reason for this is that risk and issues have this nasty habit of delaying or stopping the successful delivery of a project.


Given the importance of identifying and managing risks and issues, it is important to have a recognised process to capture the risk and issues.  A good PMO will define a framework including tool set to capture the risks and issues.

The project manager will normally spend time at the start of the project to consider and capture risks and issues.  They may even organise a session with the project team and stakeholders to capture as many as possible so that something important is not missed.


Unfortunately, this can sometimes be the only time that the project spends time identifying risks and issues.  They are captured, recorded and then nothing else happens with them!  Very much a ‘point in time’ activity.  This means that:

  1. The risks and issues are not being managed so will probably impact delivery
  2. New risks and issues are not being identified, which will probably impact delivery


A proactive PMO will define a PMO risk and issue framework that will provide the process and tools for managing risks and issues.  The PMO should then actively monitor the registers to make sure that risks and issues are being managed.  This can be achieved by monitoring updates to the register, monitoring how many are being closed, changing / passed target dates, no new items being added.

A good way of doing this is by setting up a regular meeting with each project manager and to discuss the risks and issues as part of the meeting.  Further value can be added by identifying other risks and issues that the project manager has not thought about.

Remember, both the project manager and PMO have a collective objective, that is the successful delivery of the project.

Senior Management Challenge

If and when the project manager is actively managing the risks and issues, there will be occasions where intervention / help is required from senior management.  The challenge can be to get senior management interested in the issues and risks is that they may be important to the project but, rightly or wrongly, not of top priority to senior management.  This is not to say senior management don’t care, it is normally that they have many other items to worry about.

So in order to get the attention and required action, it is necessary to give the issue or risk you need to be resolved the best chance of standing out.  Using a RAG rating of Red on the register can help.  However, there may be many other projects with Red issues.

A great way of helping to focus the mind is to attach a financial value to the risk or issue.  By doing this, you will get senior management’s attention as straight away they can quantify the cost of not taking the action.  If senior management do not provide the required assistance, it is made clear that they are accepting the (financial) consequence.  This has a great way of focusing the mind.

Word of warning, when using the approach of valuing risks and issues, don’t present it in a way that senior management feel they are being forced to hard into a corner, they will remember and probably not helpful for the career.  Likewise, make sure the financial value you place on a risk or issue can be evidenced and is not just made up.


It is important for all projects to actively identify and manage risks and issues on a continual basis.  Placing a financial value on a risk or issue is a great way of quantifying the impact to senior management.

If you are looking for PMO risk and issue templates, take a look at the template pack that includes templates to allow you to quickly set-up a robust process.

PMO reporting frequency

Project Reporting CalendarPMO reporting frequency is often a topic of debate.  It is a balancing act to make sure that there the appropriate level of visibility of delivery activity while not creating a bureaucratic process.  It is not in anyone’s interest where the projects are spending more time on reporting than on the actual delivery work.

Unfortunately, there is not a simple answer.  As you will be aware, an organisation will typically have a number of projects all working to different time lines.  However, I will provide some useful guidelines that should help you define the reporting frequency for your PMO.

Here are some of the considerations.

Project Duration

Projects can vary from a few months to many years.  This will influence the reporting frequency.  For a project is less than 1 year in duration you will want a more regular reporting cycle.  The reason for this is that there is less time to deliver the project.  Therefore, you need to react and take action quickly when the project starts to deviate from the agreed delivery plan.

For projects less than 1 year, I have usually opted for a weekly reporting cycle, fortnightly at a push.  This provides the required visibility on progress and allows problems to be quickly identified.  It is no good waiting 1 month to find out there is problems, you will be 1/12th into the project, meaning less time to recover.

To lessen the overhead on the project, consider a more light touch form of reporting.  This eliminates the risk of bureaucracy.

For projects over 1 year, it is usually acceptable to opt for a fortnightly or monthly reporting cycle.  There is usually more time to take action to keep the project on track.

Organisation Standards

In a number of businesses there is an agreed approach to reporting, usually monthly.  If this is the case, it is difficult for a PMO to define a different frequency.  If you do try, the project manager will quickly point you to what is defined in the methodology.

A way to address this is by setting up a regular catch-up with the project manager, 30 minutes weekly or fortnightly or should suffice.  This will allow an open and honest (it is not being written on paper) update.  This will allow the PMO to quickly identify risks and issues and then recommend action / allow escalation ahead of the monthly reporting cycle.  A good project manager should welcome this as it will help them with their primary objective, delivering the project on time.

In summary

While there is no right or wrong answer to reporting frequency, reporting should be at a minimum monthly and weekly / fortnightly for projects under 1 year in duration.  The PMO should supplement this with a regular catch-up with the project manager to quickly identify potential issues.  This approach will help the project not create a reporting nightmare.

PMO tools – smart PMO’s conduct and enviroment scan

When you have been tasked with setting up a PMO, many of us want to get tools and processes up and running as quickly as possible.  This is a great attribute of a delivery focused person.  However, care is required as this desire usually means that our first choice is to implement tools and processes we have used before or, create new ones!

The potential problem with this is that the organisation may already have its own tools and processes that are already being used.  Therefore, implementing a different set creates standardisation and duplication issues.  Important point to remember, project managers should be spending the majority of their time managing and delivering their project.  If you make their life harder and create extra overhead, you will not be popular.

So in order to avoid this, a smart PMO will conduct an environment scan.

PMO Environment Scan

This is simply a quick check across the organisation to understand what tools and processes are being used.  The steps should be:

1. Are there existing tools and processes for project delivery / reporting / PMO activity, etc?

If there are, meet with the appropriate owners, understand what is required, where you can source templates, reporting cycles, etc and then use them to construct your PMO.

Great for user buy-in as you can point to it being Group Standard!

If there are not any standards:

2. Review what is currently being used by projects, particularly those projects which will be in the remit of the PMO you are building.

This is a very smart move.  Work out what everyone is using and then choose / adapt what is already in place.  This is great for user buy-in as it is already being used and a project manager likes it when their tools get re-used.

If what projects are using is not fit for purpose (or non-existent):

3. Use / develop your own tools and processes.

In some cases, usually more immature organisations, there will be nothing that can be used.  In this instance, you can shine by implementing your own tools and processes.  This offers a great opportunity as professional tools and processes promote confidence and this will be recognised by senior management.  If it goes well, you are in a great position to push to apply your standards Group wide – probably good for the career.

If you don’t have your own project templates or don’t want to spend time developing them, think about the advantage of buying professional project templates.

The above steps should help keep you on the good side of project managers.