PMO Benefits Management Overview

It is interesting that in the majority of cases, a project or programme is launched in order to deliver some form of benefit. However, for some reason, many project managers and PMO’s focus on delivering the project on time, on budget and to agreed scope without keeping track on the delivery of the benefits.

While in theory, delivering the agreed scope to budget should result in the delivery of benefits, in many cases this is not the case. It is not unusual for the project manager to think that they are not responsible for delivery of the associated benefits.

The problem usually occurs when the benefits are not directly linked or to the same time line as project deliverables. You may wish to implement a new computer system that automates a process. This could result in the benefit of reduction of costs through less resources. However, it may be the case that the resources can not be released from the current manual process until the system has been up and running for 6 months.

In this scenario, the project manager delivers the system and then closes the project. The view of the project manager is that it is a success as the agreed scope has been delivered on time and on time budget. However, the benefits will not be realized until the FTE have been redeployed.

So to avoid the risk of not realizing agreed benefits, you should think about how the different components of project and PMO management can help.

Business Case

In an earlier post it mentioned how the business case is important, it is the contract between sponsor and organization. Agreement to the business case means the organization agrees to provide funding in return for a stated benefit.

The sponsor is accountable to ensure that they (or their delegate – project manager) delivers the benefits. Therefore, the PMO should ensure that the delivery of benefits are tracked and ensure the project plan includes a benefit realization strategy.


The realization of benefits can be a very emotive subject, especially at the point of realization. To avoid this, the sponsor and project manager should look to include sensible KPI’s that, if achieved, means the benefit can be recognized.

Ideally, the KPI’s should be agreed early, even included in the business case, as this is usually a lot less emotive. Agreeing them early also helps eliminate an industry around benefit tracking and realization.

Benefit Tracking

A smart PMO should look to agree meaningful benefit milestones as part of the plan that can be tracked. This helps monitor where benefits are at risk.

Change Control

Include criteria that require a change control to be raised when benefits are going to vary from those in the original business case. This ensures that everyone knows that the benefits are real and must be delivered (not simply used to make the business case look better to get funding).


Ensure benefit realization and tracking are included in the regular steering committees. This ensures that everyone is focused on delivering the benefits and shines the spotlight where there is risk of benefit erosion.

Example benefits tracking report

When people realize they will be held accountable to deliver against a business case, you will see behaviors change resulting in more accurate proposals.


Benefit tracking and realization is the primary reason for choosing to invest resources to deliver a project. It is the PMO’s responsibility to be the custodian of ensuring benefits are delivered and providing senior management with the information to make informed decisions (including stopping projects that are not delivering against their business case).

Are you in control of your actions?

It is important as a change agent, project or PMO manager that you constantly strive to develop your skills. This will help to ensure that the service, the value you provide increases. This can be achieved through many channels including online articles, reading books, attending classroom based training, etc. A useful method is to listen to podcasts. A big benefit of podcasts is that they are portable and you can listen to them when you are on the move (car, train, walking).

The next logical step on from podcasts is to listen to audio books. There are so many good books but just not enough time to read all of them. Audio books means that you can listen while traveling where it would be awkward to carry a book. What is even better is that it is possible to get a membership from Audible for US $149.50 a year that enables you do download 12 books.

The chimp paradox book coverWhile this is a useful tip, the reason for the post is to share a book that has some lessons that are extremely relevant for change and PMO professionals. The book is The Chimp Paradox by Dr Steve Peters, which is in the Audible business chart (the printed version is also available on Amazon). One of the key take-a-ways is the principle that we all have 2 brains, the human brain and the chimp brain. Obviously we only have one. However, knowing and acknowledging that both fight to dominate our thoughts and behaviors is very insightful for helping drive the right actions.

In the book, the chimp brain is the one that operates at the basic level. Re-acting with emotion. The human brain takes the information and tries to process rationally. So logical, we should all want the human brain to control how we re-act. Unfortunately, the chimp brain is the one that receives the message first and re-acts at lightening speed. How many times has a project manager sent an e-mail that is incorrect, blaming the PMO for something. You know this is not true and, due to the reaction of the chimp brain, you are furiously typing a pointed response. While the original mail may be incorrect, sending a fast, hostile response will not serve to resolve the situation. This is where you need your human brain to be in control.

Being able to maintain a balanced view when working within the change management arena is a very sort after skill. Rising above the emotion, not having the desire to defend, attack, win, will lead to you achieving more and, most importantly, in a way that is professional. So when you feel that your immediate response is to re-act with emotion, take a moment to collect your thoughts so you can respond without emotion. You may have heard of methods such as “counting to 10 in your head” – this is good as it allows the human brain to take control.

However, the book also talks about the importance of allowing your inner chimp to have the ability to be let free but in a controlled manner. So, perhaps you do need to type the response to the incorrect e-mail, stating all the reasons they are wrong – this meets the need to the chimp brain. However, instead of sending, you should save and then review when the human brain is back in control before deciding to send.

Rising above the emotional e-mails and heated discussions to remain balanced and focus on what needs to be achieved will lead to long term success. It will also help to avoid actions that will be regretted in the future.


Self development is important to expand your skills. Understanding the principle of the chimp and human brain will help how you approach each situation giving you a better chance of remaining in control.

If you have any books that you have found useful that you would like to share, please take a moment to add to the comments of this post.

PMO Change Request Checklist

5 checks to make when assessing a project change requestProject’s are unpredictable. A project manager never can fully predict what will happen over the project life cycle. However, what can be depended on is that there will be project risks, that if not managed correctly, will become an issue and will often result in a change request being required to reset the plan.

Given the certainty that change will happen, it is very important that the PMO implements a robust, pragmatic process to manage change. The objective being to make sure all requests are clear, transparent, impact full known and communicated / agreed with all stakeholders.

The purpose of this post is to provide a checklist for the PMO (or anyone) reviewing the change to ensure that it is ready to be reviewed and agreed.

Change Request Checklist

5 checks that a PMO can perform to ensure that a change request is ready to be processed.

  1. Change Request Form

All change request processes should have a mechanism to capture the information relating to the change. This typically will be in the form of an online or offline template.

The first check is to make sure that the form has been fully completed and that it clearly explains the change. If it does not the person submitting the request should be asked to update and fully complete the form.

Tip: If the change is not clear to you, it is highly likely that it will not be clear to other stakeholders who are not as close to the project. Therefore, it is a good test to ensure the form is clear, does not use acronyms, etc.

  1. Impacted Parties

Often the change will impact other projects or BAU processes outside of the project. If this is the case, all impacted parties should be named as needing to review and sign-off the change.

If all parties have not been identified and / or have not signed off. The form should be rejected and the owner asked to ensure that all parties have been engaged.

This is a critical step as it will allow any impacts to be identified. It is common for a project to only consider the impact for their own project not in respect of others.

  1. Impact

The change request must clearly indicate the impact of the change, usually in the form of scope, schedule or cost. It should also include details of any alternative approaches that have been considered to try and keep the project on track.

Using a change control to reset a project can be seen as the easy option but usually has a detrimental impact (usually cost and schedule). A good project manager should try to seek alternatives before going the change route.

Tip: As a PMO, you are entitled to challenge and even suggest ideas that could be considered to try and avoid the change request.   Great way to add value.

  1. Dependencies

Make sure that the request identifies any dependencies.   For example, the proposed dates in a change request may be dependent on another project delivering by a set date. It is important that this is understood and agreed. If not the revised plan will not be achievable and will highly likely result in another change request.

  1. Realistic

This is more of a subjective test. Does the proposed change really look like it can be achieved? Project managers have a habit of being overly optimistic and do not factor all of the day to day organizational challenges i.e. the length of time to achieve sign-off.

The PMO can help by applying the “sense check” to ensure the plan is realistic. If it is not, it is better to suggest that contingency is built in. Remember, the project manager will be under pressure from the sponsor to meet the original time-line. However, the pain of agreeing a change with a slightly longer time-line will be less painful than going back to agree a second change request at some point in the future.


Most projects will be impacted by change. Therefore, having a sensible approach is important. Using this simple list of checks will help the PMO improve the quality of requests and in turn improve quality and transparency.

For more details on what should be included in a change request process, take a look at post Project Change Control.

Rapid PMO Mobilisation

The way to quickly set up a PMOThe mobilisation of a PMO can appear daunting, especially if you organisation does not have an established PMO methodology and you have not set one up before. The objective of this post is to provide a simple but powerful framework that can be used to build and establish a PMO in 4 weeks.

PMO Mobilisation

Establishing a PMO should be thought of as a project. You need to ensure you complete the correct activities as part of a plan. Breaking the steps down is very important as it makes the whole task look less challenging, helping you feel in control and avoiding the feeling of overwhelm. It also means that you have a clear action plan to follow.

4 Week PMO Mobilisation Plan

The PMO mobilisation framework breaks the activities into ‘bite size’ chunks that can be achieved over a 4 week period.

Week 1 Action Plan

Activities to be addressed.

  • Confirm PMO sponsor (very important see the post on PMO Sponsorship)
  • Appoint / formal notification of PMO lead
  • Start work on PMO charter
  • Draft PMO organisation
  • Capture roles and responsibilities


Week 2 Action Plan

  • Environments assessment (what tools, processes, templates exist). Remember my tip of buying project management / pmo templates to save valuable time)
  • Define portfolio of projects
  • Establish governance process
  • Define communication strategy

Week 3 Action Plan

  • Define reporting / dashboards, etc
  • RAID’s
  • Cost Management
  • Benefit Management
  • Resource Management
  • Planning
  • Change Control

Week 4 Action Plan

  • Hold briefing sessions with stakeholders
  • Finalise and issue PMO charter (should include all items above)
  • Publish reporting calendar

Week 5 into business as usual

Week 5 is where you get the processes and reporting routines embedded into the projects / workstreams. There will be issues so don’t be afraid to fine tune the process. Making changes is a sign of a mature PMO and will gain you credit with the project teams. Another important aspect is that you will have feedback based on real world activities.


Remember this is a framework and, as such, can and should be adjusted to be made fit for purpose for your own needs. Don’t be afraid to experiment and find what works best for you and your organisation. Add, remove and amend steps. The principle is to focus on what needs to be done and then take action to make it happen quickly.
You can accelerate some of the activities, run some in parallel, add to, eliminate, etc. The principle is what works best for you.

The post on how to setup a PMO will provide you with more information about each of the steps. This includes links to other articles on this site that cover specific areas.  Make sure that you download the free guide on 7 Steps to set-up a PMO as this includes useful links and resources.

Following a PMO mobilisation approach based on these principles will allow you to take effective action to establish a PMO that works.

Using KPI’s to measure implementation of PMO

Earlier this year there was a series of posts on how a PMO can help the sponsor define objectives, convert to SMART objectives, create vision and mission statements, define aligned design principles and then implement. The last piece of the solution is to ensure that you monitor progress so that the PMO can demonstrate success, which in turn will allow the sponsor to demonstrate success.

An effective way to do this is by way of a PMO Implementation Dashboard. You can define key measures (agreed up front with the sponsor) that you are then able to report progress.
While it is important, like with any project, to show overall progress against Cost, Schedule, Scope, etc. You also want to spend time thinking of what are good indicators, aligned to sponsor objectives, to report progress against. Doing this serves 2 important purposes:

  1. It consistently reminds sponsor and stakeholders of the reason they wanted to establish a PMO.
  2. It provides reassurance that the PMO will deliver the value that is required.
    Both very important to ensure the ongoing support.

Example PMO Implementation Dashboard

While the objectives of each PMO will be tailored to an organisation, I have created a sample PMO Implementation Dashboard to present some ideas of what could be measured. Find out how you can access a fully working version at the end.

Example of PMO Template dashboard


PMO Implementation Status

The top section of the dashboard provides the details of the PMO Implementation project. Namely:

  • Overall Status – subjective view based on overall progress
  • Cost – status of progress against budget
  • Schedule – status of progress against agreed schedule (plan)
  • Scope – status of progress against agreed scope (should be based on Standard Functions section)
  • Resources – status of resources recruited to work on implementation (and running) PMO

PMO Measures

Projects with PMO Oversight

If the objectives is to drive visibility and transparency of projects, showing how many projects had PMO oversight at start and how many currently will show that the PMO is identifying and capturing projects. Therefore, management will gain encouragement that the PMO is gaining traction.

It is important that the PMO promotes the fact that by gaining oversight, they are well placed to be the single point of contact to provide management of details of all of the active projects.

Budget with PMO Oversight

If an objective was to provide visibility of change expenditure, showing how this has changed since the start will demonstrate that projects are being captured and budgets being defined (usually through business cases).

Benefit with PMO Oversight

If the objective is to get oversight of benefits to ensure they are delivered, showing that they have been captured will provide confidence. Having visibility gives an increased probability that benefits will be delivered as projects will be held accountable.

It also leads in to more detailed analysis in respect of Return of Investment, average benefit erosion, delay, etc.

Monitoring and increasing benefit realisation will make senior management more comfortable in investing in change projects. It also is one of the biggest areas where the PMO adds value.

Standard Function Implementation

If an objective was to standardise project delivery through tools and processes, showing progress against each Function will promote confidence that the tools and processes are being implemented. It also shows the incremental benefit. For example, if standard, consistent reporting was a requirement, showing the Reporting bar becoming 100% complete will inform senior management that projects are being reported using a standard report with the same measures.

A fully working version of the template is available as a free download (click to download). All you need to do is populate the values.

In Summary

Dashboards are a powerful way to communicate progress and ensure ongoing support. However, you must ensure that you use KPI’s that a relevant to the audience and are aligned to the original objectives.

Following the ideas and concepts in this series of posts should help demonstrate the value and success of the PMO to the sponsor

Beware of perfection when developing project templates

This article will share some thoughts on why as a PMO it is important to be mindful of not allowing perfection to impede progress.  While the principles will be in respect of developing project and PMO templates, the concept can equally be applied to many other areas.

Challenge to developing project templates

An important role of the PMO is to provide direction on standards for tools and processes.  This often includes defining the templates that will be used for status reporting, risk management, change control, etc.

It is crucial that the templates are fit by purpose meaning that they:

  • Capture correct information
  • Easy to use
  • Clearly convey important data
  • Meet stakeholders expectations

Due to these requirements, there is a risk that the templates will go through numerous iterations and reviews in an attempt to meet every last requirement – quite simply trying to achieve perfection.  The consequence is that the templates take a long time to implement and delays achieving the goal of implementing a standard approach so as to gain oversight of progress.

The PMO needs to be particularly mindful that they are not seen as “not delivering” and “over engineering the solution”.  This is a quick path to be accused of being “bureaucratic”, “over head”, etc.


Firstly, it is important to stress that this is not seen as advocating not doing a good job.  It is very important to develop tools and templates that are fit for purpose.  However, it is important to think carefully on “how” this is achieved.

It is normal that the users of a template (those completing and those using to manage), will have different requirements.  This is compounded where the template is to be used across many different projects (each with their own view of what they need).  This can often lead to each stakeholder insisting that their requirements are included before the template is issued.

Then, when the template is issued this will be when the different users enter real data.  During this process it will become clear that changes are required in the template.  Therefore, even though there may have been numerous iterations before publication, perfection will not have been achieved.


Given the reality that it will be difficult to achieve “perfection”, it is far better to acknowledge this and approach from a position of continuous improvement.  In many ways it is far better to get a useable version of the template into production so that the real feedback loop can start.  This will allow both those entering information and those using the information to really think about what they need from the template.

This concept is aligned to that idea of the “Minimum Viable Product” (MVP).  The principle being that you only deliver the minimum functionality needed for the template to be used.  This approach is very much part of the “lean manufacturing” approach which tries to minimise waste by only implementing features to meet requirements – no “gold plating”.

Important – for this to work you need to make sure that everyone understands the approach and that senior management provide support.  Users need to understand that they are not going to only get “one” chance to define requirements.  Making this clear will help remove barriers to agreeing to move forward and the quest for “perfection”.

A variation of this is approach is the concept of a pilot.  In most organisations, there are users who are very supportive and helpful.  They always try to do what is right and provide constructive feedback.  These users are ideal to choose to pilot new templates.  They will provide feedback in a safe environment ahead of a wider launch.  The additional benefit is that they will be more supportive as they have been consulted early and their feedback incorporated into the design.

The Lean Start Up by Eric Ries coverWhile it does not relate specifically to PMO’s, there is a very good book called The Lean Start Up by Eric Ries.  This covers the concept of the MVP and links to lean manufacturing.  It had some very good concepts that can be applied to many walks of life.


  • You will not achieve perfection regardless of number of iterations meaning you won’t please everyone
  • Aim to implement the minimum level of functionality on the template (MVP)
  • Seek feedback and iterate

Following these steps will mean that the PMO can deliver value more quickly.

Stakeholder analysis template

It is fair to say that an important factor to the success or failure of a project is the behaviour of stakeholders. Therefore, it is important to ensure that project stakeholders are identified, clear understanding of their position and, a plan that will allow effective communication so that they contribute to the successful completion of the project.
This post will cover the 2 stakeholder analysis templates and supporting processes needed to implement stakeholder analysis for your project.

What is a project stakeholder?

Before going into the practical explanation of the templates, it is important to have a clear understanding of what is meant by a project stakeholder. Wikipedia defines a stakeholder as follows:
“Project stakeholders are entities that have an interest in a given project. These stakeholders may be inside or outside an organization which: sponsor a project, or. have an interest or a gain upon a successful completion of a project; may have a positive or negative influence in the project completion.”

What is project stakeholder analysis?

Stakeholder analysis is the process of identifying stakeholders who have an interest in a project and to understand the impact of the project on them. This will then allow a plan to be developed to manage the interests of the stakeholders in a balanced manner.

It is important to recognise that it may not be possible to meet the interests of all stakeholders. Understanding this means that it is possible to identify how supportive the stakeholder will be to the project

Not all project stakeholders are equal!

Another important point, stakeholders have a varying degree of power and influence. Ideally, you want your stakeholders to hold the power and influence to support the project. This will allow for barriers to be removed. What is very challenging is where you have stakeholders with power and influence who do not support the project, this will make it very difficult to achieve.
The good news, having identified the position and drivers for each stakeholder, you will know where you have support and, where you do not. This will allow a stakeholder management plan to be created to move non supporters to supported (or at least move them to a neutral position so they do not adversely impact the project).

Tools and Templates

There are 2 core templates needed to complete project stakeholder analysis.

Stakeholder Analysis Template

Example project stakeholder analysis templateThe template should at a minimum contain the following fields:


A unique reference to identify the stakeholder. This is useful if you are sorting data using Excel.


Enter the name that will be used to identify the stakeholder. This can be an individual or entity.


The role held by the individual or entity. This will provide important context for when assessing the impact of the stakeholder.


This is used to assess the influence and power of the stakeholder. The core values being:

1. Low power, low influence
2. Low power, high influence
3. High power, low influence
4. High power, high influence

Typically those identified as 1. low power, low influence can exercise the least impact to the project. Those identified as 4, high power, high influence can exercise the most impact and can be a great help (or hindrance) to the project.

It is possible to have separate fields in the template if required for “Power” and “Influence”. It comes down to how you wish to handle / use the data.
Advocate / Blocker
• Advocate – supportive
• Blocker – not supportive
• Neutral
• Unknown – note: try to reach assessment as soon as possible

This used to assess if the stakeholder is supportive or not supportive. There are 2 columns:

1. Current – this is the current assessment of the stakeholder
2. Required – this is the position needed for a stakeholder

Action Plan

Used to capture the actions that are needed to move the stakeholder from the Current position to Required position. The actions should be monitored on a regular basis.

Project Stakeholder Grid

Stakeholder_Analysis_Grid Example project stakeholder grid template

While the Stakeholder Analysis Template should provide all of the information required, you can plot the information using a stakeholder grid.

It uses a 4 box principle to map each stakeholder against Power (vertical axis) and Influence (horizontal axis). Take the first row from the stakeholder analysis template and plot on the grid.
Each stakeholder should be colour coded to indicate if they are Advocate, Blocker or Neutral.

Stakeholder Analysis Template FREE Download

Both of the project stakeholder templates are available as a FREE download. Simply click on the links below to download. You will need software that supports MS Excel and MS Powerpoint.

Project Stakeholder Analysis Template Free Download
Project Stakeholder Grid Template Free Download


If you find the templates helpful and this article helpful, please can you use the social media buttons to “Like” the page and share with your network.

PMO Career Path

The 3 PMO Career PathsWith any job, there is always a level of uncertainty on how the job will evolve. People are concerned about their prospects and their career path. The same applies to anyone who chooses a PMO career path. This post aims to provide an overview of the options available if you choose to take a position in a project management office.

Start of Career

If you are just starting your career, perhaps your 1st or 2nd job, it is highly likely that you have been recruited in a more administrative role within the PMO. This is normal as project and change management skills is something you learn over time by doing the job.

A lot can be learnt operating in this capacity as you will typically be involved in a number of the core PMO processes i.e. report consolidation. This will mean you will get the opportunity to engage with stakeholders who need to submit into the PMO and gain an understanding of the process.

From this base, you will then have a number of options.

  1. Continue in the PMO

You may decide that you enjoy the PMO environment. This will open up opportunities to take on lead roles such as Reporting, Change Control, etc. Then as you become more skilled (and confident), you will find yourself providing more constructive challenge and then providing guidance. This is a big value add for an organisation.

As your skills and experience grow, you will find that you take on more ad-hoc tasks such as targeted reviews of projects, trend analysis, etc so as to provide meaningful MI and recommendations to senior management.

As you grow in the role, you will probably start to have resources reporting to you giving the opportunity to mentor and build their skills. This will provide you with team management experience.

As you engage with more senior stakeholders, this will open the pathway to take on PMO leadership roles. It will also mean that you should be equipped to design, implement and manage your own PMO.

  1. Project Management

You may choose to go into project management. It is an easy transition from PMO support to migrate into Project support. The skill set and activities are very similar. You should gain experience in helping manage risks & issues, maintaining the project plan and writing project status reports. You also will gain experience dealing with the day to day challenges faced by a project.

Developing these skills will open up opportunities to take on other project roles including business analyst, workstream lead and ultimately project manager.

When you have become an accomplished project manager, you then will have the option to move into programme management and portfolio management.

  1. Business Roles

Working on projects will allow you to work across an organisation. It is one of the best methods to build your network and, importantly, build your reputation. Demonstrating that you can do a good job will open up other opportunities in a company. People are more likely to recruit people they know and trust.

Nowadays, project and change experience is important in many business roles. Therefore, if you have worked on a project for a specific part of the business, you will have naturally learnt about the subject matter. This means that you could consider moving into a business role within that area.

Note: the same applies to a path in technology.

Have a Plan

Now you have a high level understanding of what options could be available, you need to make a plan to give you the best chance of following your chosen career path.

  • Decide what career path you would like to follow i.e. you want to become a project manager
  • Work out your current skills
  • Identify skills you need to add or develop
  • Create a personal development plan to review and agree with your manager
  • Identify if there is any training available i.e. PMP qualification
  • Regularly review progress
  • Periodically revisit the plan (you may decide you want to go down a different path)


Taking a role in a PMO will provide a number of opportunities to develop your career. The important point is to have a clear idea of what path you would like to follow, create a plan and then execute.

Important: Choose a path where you have a passion and that what you enjoy!

Good luck to your success.

PMO Career Resources

The Project and Business Templates provided by PMMilestones contains a number of professional CV’s and business documents that can be helpful for career development.


Different names for a project management office

PMO Definition

In any organisation or industry, you will find a wide range of acronyms being used.  For a new comer this can be very disconcerting as you join a meeting, people are talking energetically using acronyms and you do not know what they mean.

This means you then have a choice, listen intently and try to work out the meaning.  If you can’t use Google when you leave the meeting or ask one of your new colleagues.  The other approach being to wait for an appropriate moment and ask for clarification of the acronym.

I am a firm believer that you should ask for clarification.  After all, if you are new to an organisation, you can not be expected to know all the terms they use.  However, there is a risk that the other people are using recognised industry terms.  Therefore, you may not want to expose the lack of knowledge, especially if you have been hired for having the appropriate expertise.

This same challenge exists for the different names used to describe a PMO.  Therefore, this article and presentation captures a list of the common terms into this article.

PSO – project support office

Some organisations use this term as the service provided is more administration support as opposed to helping to manage a project.

PMO – project management office

Supporting the project to deliver.  The level of management and support will vary depending on maturity of PMO (and organisation).  Please see the posts on the different types of PMO.

Admin / Reporting Clearing, Hybrid, Managerial

PgMO – programme management office

Typically will have oversight manage a number of projects that form a programme.  This may mean that the PMO’s will report into the PgMO.  Just to confuse matters, it has been increasingly common for PMO to be used for both project and programme.

PPMO – project portfolio management office

This will be building a view of the projects programmes in a defined portfolio.  While they can be used to manage delivery, most organisations use them to make decisions on what should be executed and when.

EPMO – enterprise project / programme / portfolio office

This will usually be the overall PMO owning standards, strategy, direction, etc.  It will link to the PMO network to ensure that all projects are aligned to strategy and following defined standards.  Very popular for organisations who want their strategies to be converted into change programmes and executed.

The diagram below summarises the different types of PMO.  While it is easy to see that the PSO provides the lowest “value add”, it is not so simple to as saying an EPMO provide the most value.  Each offers a different type of service so, a different value.

Types of PMO

Types of PMO Presentation

To close

This should provide with a good starting point of all of the common acronyms used to describe a project management office.  It is also important to remember that if someone does use an acronym, do not be afraid to ask them to explain what it means, you may even find that they do not know themselves!

Inforgraphic showing PMO definitions

5 steps to write a good project risk

If you take a moment to review most risk logs, on closer analysis you will find that the quality is variable at best. The reason is that many project teams do not put the appropriate time and effort into capturing and managing project risks. Unfortunately many see the process as a “tick box exercise” that they only do because they think they should and / or they are asked by the PMO. However, the reality is that capturing and managing risks can help prevent the issues that delay a project.

This blog contains a number of posts on risk management. However, there is not one on how to write a project risk. Therefore, this post will cover the 5 steps to writing an effective project risk. Note, the assumption is that you have taken the steps to capture the risks.

1. Title

Every risk should have a title that makes it clear to what the risk relates.

Poor Title: Resources

While the risk may relate to resources to support the project, this title is too generic. It does not specify what type of resources, is there not enough / too many and why they are needed.

Good Title: Lack of Java resources to develop website interface

This title makes it clear that the risk is lack of java resources and that they are needed to develop a website interface. You could even be specific on the actual website if there are a number of other website developments.

While you want the title to be clear, try to keep it short.

2. Risk Detail

Each risk should have a clear description that explains the risk so that the reviewers can understand the risk. As some may not be close to the project detail, it needs to be written using language that all can understand, including avoiding the use of technical / project jargon and acronyms.

Bad Risk Detail: There may not be sufficient resources to complete the project.

While this makes it clear that there may insufficient resources for the project, it does not detail type of resources, when they are required and the work that needs to be completed.

Good Risk Detail: There may not be sufficient java developers to complete the development of the website interface between September and October 2014.

This makes it clear of the type of resources, that there may not be enough, what they are needed for and when.

3. Risk Consequence

The reason for identifying a project risk is that they usually will have some form of impact on the project if the risk becomes an issue. Therefore, it is important to document the consequence so that the reviewers can understand the consequence to the project if the risk is not managed.

Bad Risk Consequence: Lack of resources may cause delays.

Again, very generic and does not really explain the consequence. Surprisingly, this type of statement is far too common in risks.

Good Risk Consequence: Delays to completing the website interface development by 31st October 2014. This will directly delay the testing phase. Each day delay during development will extend the completion date of the project by 1 day.

This statement makes it clear that the consequence of not having the required resources will delay the development of the website interface and will ultimately delay the end of the project.

4. Target Resolution Date

This is the date by when the risk needs to be addressed (mitigating action taken) or accepted (the project is happy to accept the impact if the risk becomes an issue).

Bad Resolution Date: No date specified, TBC (to be confirmed), TBA (to be advised), general dates (i.e. end of year, end of project).

If there is no clear understanding when the risk needs to be addressed, it is usually because it has not been clearly defined. It is common to see generic risks relating to resources and the end date being set as end of year / project. Not very helpful.

Good Resolution Date: This should be the date by when action needs to be taken to address the risk. In the example in this post, java website development needs to complete between September and October. Therefore, the date to address resource concerns must be 1st September 2014 at the latest (the date the resources need to be available). In reality you would want to set a date in August to give contingency i.e. 15th August.

Important: try to set real dates as opposed to ones where it does not matter. If a date is set and missed and there is no consequence, it will mean that other deadlines will not be taken seriously.

5. Mitigating Action

Defining the risk is only part of what needs to be captured. The project team should also provide proposed mitigation (the action to be taken to address the risk).

Bad Mitigation Action: Monitor resources to identify delays.

Another generic statement that states that resources will be monitored. This will probably result in lack of resources only being known when it is too late.

Good Mitigation Action: Identify named resources to complete java website interface and gain agreement that they will be available to support development between September and October. As contingency, engage 3rd party provider of java developers to see if they can provide resources at short notice should they be required.

This mitigating action gains commitment of the required resources and also tries to put in place a back-up plan.


It is important to clearly capture the key components to a risk.

  1.  Title – a good description of the risk
  2. Risk Detail – specific explanation of the risk
  3. Risk Consequence – what will happen if the risk is not addressed
  4. Target Resolution Date – the date by when the risk must be addressed or accepted
  5. Mitigating Action – what steps will be taken to address the risk

Following these 5 steps will help ensure that you capture and define good risks for your project.  If you are a PMO you can use them as the principles for the processes you define and mentor the project teams.

You can find associated project risk resources in the links below this post.