Does your PMO practice continous improvement?

graph showing improvement stepsTo design and implement a PMO can be hard work.  It obviously helps if you have set one up before or have the appropriate tools and methodology.  Therefore, it is understandable that when it is up and running, the PMO manager can think their set-up work is complete.  While this may be technically true, the reality it is not.

Up until recently there was an analogy in the UK where something could be referred to as being “like painting the Fourth Bridge“.  This is a structure spans the Firth of Forth connecting Edinburgh to Fife.  The statement comes from the (myth) that as soon as the work teams finished, they had to start again.  The PMO is similar, just because you have set it up, your are not finished, you need to ensure regular maintenance.  In fact, unlike the Forth Bridge, you should be looking to improve.

Why continuous improvement is important

A PMO needs to demonstrate and increase value.  Therefore, it makes sense for the service offering to be continually improved as part of the maturity process.  The reason being that improving the service equates to improved oversight / delivery resulting in increased value for the organisation.  So if you run or work in a PMO, always be striving to improve the service.

How to improve?

The process for continuous improvement should not be difficult or hard.  It should be practical and based on real world events.  What is important is having a structure and process to capture where improvements should be made.

Regular Reviews

Make sure that you have routines to regularly review tools and processes among the PMO team members.  The people executing the routines will know what works and what does not.


Make sure that there is a process to capture feedback from stakeholders such as project managers, project teams, etc.  While many will volunteer information without you having to ask, others may need to b encouraged (especially more junior resources or those from cultures not used to providing feedback that can be perceived to be bad).

There are other sources.  The key is having a process that has been communicated, to capture the points as they arise.

On a regular basis, probably monthly, the PMO should review all of what has been captured and determine which ones need action.  Plans should be developed to incorporate the enhancements (note: it is advisable that changes are discussed with those who made the observation to test that the proposed changes to ensure they will make the required difference).

However be mindful of…

Allow Changes to “Bed Down”

When new processes are introduced, it can be painful and users may re-act badly if they don’t achieve the desired outcomes on day 1.  However, it is important to allow new processes to have a period to settle and resist the temptation to make changes.  It also allows other feedback to be captured.  I have often set a period of x weeks to allow the processes become stable and let people know that feedback will b captured but no changes will be made until the defined period has passed.  Obviously if something critical arises you may need to make a quick change.

Giving Notice of Changes

A common complaint from project managers is changes are advised last minute meaning everyone is under pressure to adopt the new change.  Make sure that changes are clearly communicated ahead of when they will be introduced.  Provide training and support to ensure the implementation is trouble free.  If you are moving to revised templates, the PMO can help ease the transition by copying data from the previous templates for the project teams (this is a sure way to build good working relationships).

Frequency of Change

Closely linked to the “Bed Down” point.  Do not make changes to often.  Try to have a set schedule for maintenance updates.  You may want to start with monthly and as the PMO becomes more mature move to quarterly.  This means that the stakeholders know when to expect updates.

In summary

A PMO must adopt the mindset of continuous improvement so as to increase the value it adds.  The process to capture and implement improvements should not be complicated.  Being mindful of the impact of changes, clearly communicating and supporting, will vastly improve the outcome of implementing enhancements to the service offering.

Project inventory overview (planning next years change portfolio)

Diagram showing project planning cycleIn the 3rd and 4th quarters of a year, many organisations are planning and budgeting for the coming year.  This has to include any projects so that the budget can be secured.  This post will provide an overview how to construct a project inventory.

An organisation will undertake a number of change projects at the same time.  In a large, global organisation there could be thousands if not ten’s of thousand projects running at any given time.  Some will be small, such as report changes.  Others could be very large, multi-year projects.  This presents a challenge to many organisations.  How to track and ensure that change projects are aligned to the overall strategy.

In many cases, change will be specific to a specific function or business line and / or a location.  Therefore, it is difficult for the organisation to have a single view of all of the change activity.  This means that senior management will not have a clear sight of how the change budget is being spent, what benefits are being returned and crucially, be able to determine if the change budget is being spent wisely.

This is where an enterprise Project Management Office (PMO) can add considerable value.  The enterprise PMO should be able to link into all of the regional and local PMO’s so as to gain sight of all of the active change projects.  Even in a small organisation, having a central list of all change activity will be a benefit to management.

Objective of Project Inventory

Constructing a Project Inventory is a way for any PMO to quickly add value, especially where an organisation has not had a PMO before.  Instead of having to speak to many different functions, etc to understand all of the change, senior management can simply ask the PMO – a huge time saving.

While Project Inventory makes it sound like a complex process, it is simply a list of all active and planned projects for an organisation.  So for Project Inventory you can think “list of projects”.  So the simple objective of the Project Inventory is to capture all of the active and planned projects in a single list.

Constructing the Project Inventory

The PMO should take the lead on constructing the project inventory.  The approach can be:

  • Pull – ask all of the project teams to submit details of change projects
  • Push – create a central list and then send to project teams to review and validate

If possible I would lean towards the “Push” approach as it demonstrates that the PMO is trying to add value by taking on what work it can and then, only asking projects teams where they cannot complete the task.  This will create a positive reaction as opposed to the PMO being seen as simply making requests of the project teams and offering no support.

The reason this is important is that the project teams should be busy focusing on delivering the projects.  Therefore, a smart PMO will try to avoid making any requests that they can perform themselves without diverting the attention of the project teams.

Standard Format

Collecting the details of the projects is an important step.  However, to make the information easy to understand and compare, it should be in a standard format.  Therefore, if you decide to use either the “Push” or “Pull” approach, the PMO should spend time creating a standard template to collect the data.

While there are enterprise portfolio management tools, the simple approach is to use standard word processor or spreadsheet programmes such as Word and Excel.  I would suggest Excel as this will allow for data manipulation when you have gathered the data.  Another example of using standard programmes is that it makes it easier to share the information as most organisations use these programmes.

The template should include:

  • Project Name – recognised name used to identify project
  • Project Description – short description to allow easy understanding of project purpose
  • Project ID – <optional> used if there is an internal numbering system such as Clarity
  • Business / Function – used to indicate who the project is for
  • Location – used by global organisation to indicate regional or global
  • Investment Type – mandatory or discretionary
  • Budget – indication of approx. budget spend
  • Benefit – indication of project benefit in monetary terms
  • Comments – allows for any additional information

Collecting the above information should provide all of the information to give a high level understanding of the project.  With this information, senior management are able to make decisions on the change portfolio.

Having the information in a spreadsheet, it is possible to total the budget column, sort by Investment Type, allowing for the cost of mandatory projects to be calculated and compared against available budget.  This then will provide how much budget is available for discretionary projects.


The PMO can provide value to an organisation by collating and providing a central list of projects – the Project Inventory.  This will save management time by presenting a single list with all of the required data point to prioritise and make decisions.

Project close review

The last 3 posts have explored the different aspects of project reviews and how they can be used to improve the delivery of change. This post will cover the dimensions of a review and the types of question to ask.

Lessons Learned Template

Lessons learned mapThe actual lessons learned template should have a logical structure that covers all of the important aspects of a project. It suits a word processor or spread sheet format.
Below is designed to give ideas on how a template could be structured around logical groupings and example questions. Remember, you need to use questions that allow for open and honest discussions that do not look to assign blame. Therefore, it is important that questions and responses are factual and non-emotive.
Overview / Background

Project Objectives – this reminds those involved in the review of the original purpose and makes it more likely that feedback will be relevant and meaningful.

Scope of review – it is important to be clear of the scope of what is being reviewed so as to capture focused feedback. For example, the review may want to target the performance of the technology solution. Therefore, this would be defined in the scope and then could be used as a point of reference during the review feedback sessions (stopping people feeding back on other areas that are not applicable to the review).

Overall Performance
The first part of the review should be used to capture feedback on the high level performance of the project.

  • Project Outcome – did the project achieve the defined objectives
  • Scope – did the project deliver the documented / agreed scope
  • Schedule – did the project deliver inline with the schedule
  • Budget – did the project deliver within the allocated budget
  • Benefits – were the benefits in the signed-off business case realised?


All should allow the user to provide feedback and comments as well as examples to back-up any statements.

Project Processes
This should explore in detail the main project lifecycle processes. Where there have been delays / challenges, these should be captured together with underlying reasons.


Was the project initiated quickly and efficiently?
Were there barriers to initiation
Were approvals given quickly?

Requirements / Design

Objectives clear, understood achievable
Requirements gathered to sufficient detail
Requirements accurately documented
Tasks captured and understood
Any issues gathering requirements?


Testing plans were clear and accurate
Testing covered all functionality
Were there many defects
Were defects quickly addressed?
Was their sufficient implementation planning
Was there a back out plan
If back out was used, was it a success
Was the implementation a success
Were resources suitable trained
Were there post go-live issues?


Progress was tracked against plan
Robust reporting established
Change control implemented and followed
Was there many changes? If so were there common themes
Robust governance established
SteerCo’s well attended
Was there appropriate quality control
Risks, issues and dependencies managed effectively?


Were all project objectives met
Was the project team released in a structured manner
Was all project documentation completed and archived
Did sponsor sign-off project was complete?

Project Team

While the focus is on the project team. This section should also capture any appropriate findings in respect of sponsor, stakeholders, etc that have had a positive or negative impact on the performance.

Did the team have sufficient resources
Did the team have the correct skills
Was the team recruited in line with schedule? If not what was the impact
Were resources prioritised from other projects
Were BAU resources available as required
Did the sponsor support requests and provide resources?

Depending on who is conducting the review. You can make the questions more focused:

Was the project manager, sponsor effective, etc


Did the project have sufficient budget
Was the budget approved quickly
Was the budget incorrect? If so what was the reason?


Did the project deliver the required outcomes
Could the outcomes be measured
What was the cause for not meeting the required outcomes?

All of the key findings from the review should be captured and consolidated within the document. Findings can be captured with the questions. However, it is helpful to consolidate the findings in a separate section with a reference to the finding in the document.
The findings can then be consolidated into themes and analysed to establish what changes should be made to existing processes (or new ones established).
They should be captured using a standard format, preferably tabular format so that they can be easily copied from each lessons learned document and transferred to a central register. This allows for output from multiple projects to be compared and then changes designed for the organisation, not just for a single project.


It is important to have a structured approach to lessons learned to give the best chance of identifying what went well and not so well in a standard way for all projects. This will allow the information to be captured and then compared against all other projects to identify themes that need to be addressed. The result should be an improvement in an organisations project delivery.

Project review at close of project

project review listThe last couple of posts have been covering the topic of project reviews and how the output can help improve the outcomes of other projects across an organisation (or even later phases of the same project).  When to conduct a lessons learned review focused on the different points where you can conduct a review.  By far the most used, is the review that is completed when a project is complete.  This post will focus on the mechanics and structure of this important process.


It is important that the appropriate preparation takes place ahead of the review.  As with anything, if you do not prepare, the quality of output will suffer.


There should be a standard approach to conducting the lessons learned reviews.  This should ideally be owned by the PMO.   Hopefully, there will already be a defined process to use, if not you will have to spend time creating:

  • Process
  • Tools and Templates

This does not have to be overly complicated.  As you will recall, the objective is to work out what went well (so the organisation can embed and do more of the same on other projects) and what did not go well (so the organisation can identify the root cause and not repeat).

The process provides a standard approach to:

  • Review selection
  • Setting up reviews
  • Executing reviews
  • Analysing findings
  • Defining actions to embed change


This should detail the end to end flow of the process:

  • Overview: provides context of process – useful for senior management
  • Detail: builds on the overview to explain detailed steps of the process
  • Templates: to be used to execute the review process

Review Selection

This will define the criteria for selecting when a review should be conducted on a project.  This will normally be at the end of the project.  However, as mentioned in the last document, this may be at other key phases.

The selection criteria is important as it sets a clear policy across an organisation as to when reviews must be conducted.  This ensures common understanding and allows delivery teams to include in their plans as a formal milestone.  It also educates the organisation and embeds the process i.e. senior management will start asking for the output of the reviews.

Setting up Reviews

With a clearly defined policy, the delivery team should plan the required reviews into the project schedule.  This should be done pragmatically as the purpose is to provide benefit to the project and wider organisation.  Reviews should not be scheduled just because it is stated in the policy.

For example, a review may naturally take place at the end of phase for a multi phase project.  If delivery team is also scheduled to be holding a planning workshop, at a 5 day offsite, for the next phase, move the review earlier or later.

Likewise, if the review is scheduled for 2 weeks after a new system has been implemented, it may be wise to delay to later.  This will allow the team to deal with any production issues, and provide more time for issues and benefits from the project to develop.

Executing the Review

It is important that all of the review sessions are scheduled ahead of time and any supporting information / templates issued.  This is especially important for senior members of staff as their diaries ten to be very difficult to secure time at short notice.

If the approach is to hold a lessons learned workshop, there may be a requirement for inputs to be prepared and gathered ahead of the session.  Make sure that all participants have sufficient time to complete and return the lesson learned template.  This will allow time for the data to be consolidated and any themes identified.

If the information has been gathered and consolidated ahead of the workshop, the information should be packaged so that it can be used to drive the session.

  • Review / discus themes
  • Reach agreement on themes and underlying root cause
  • Review and agree what has been learned
  • Agree practical steps to embed learnings

It is possible for a number of the workshop steps to be completed ahead of the workshop.  However, I find it very helpful to discuss and agree as a group so as to ensure alignment.  It also often leads to additional ideas.

Analysing Findings

The agreed findings and next steps from the workshop should be reviewed and documented.  Particular focus should be on the steps to embed the process.

The PMO should review the findings against output from other projects to see if there are any wider trends across project delivery for the organisation.  It is possible that other projects have raised similar points and these are being embedded.  The check allows for any proposed changes to be refined.

The findings should be captured into a register to ensure that they are tracked through to implementation.  Ideally this will sit in the PMO.  It is a good idea to define and use standard themes so that lessons learned and recommendations can be grouped.  This will increase the value of data mining.

Define Actions and Embed Change

The findings should be sent back to the workshop attendees and any other stakeholders, for review.  When agreement is reached, work can commence to embed the changes.  The register can be used to track progress and to report back to stakeholders.


In order to conduct a productive lessons learned review:

  • Ensure that there is a simple process with defined tools and templates
  • Schedule reviews at an appropriate time in project life cycle – be pragmatic
  • Seek input ahead of review workshop
  • Hold workshop and review themes, agree root cause and changes
  • Analyse against other findings across the organisation and refine
  • Capture in register and implement

Following this struc

When to conduct a project lessons learned review

The last post, Project and PMO Lessons Learned Overview, provided an overview of the project lessons learned review process.  This post and future posts will go into more detail on the different aspects of the process.  I also would like to state that I will highlight where there are differences with PMO lessons learned.  However, the principles are similar.

Remember the objective

It is worth taking a moment to remember the objective of conducting the review.  After all it is an investment of time and money, and, like other activities, it must add value (those who have read my other blog posts will know that one of my core principles is that PMO and project activities should only be performed if they add value and / or are absolutely required – if not don’t waste time and money performing them).

The objective is to learn from what has happened (good and bad) so that changes can be made to improve the process in the future.  The rationale being, if something has worked well, we want to ensure that all projects use a similar approach as it should provide the same benefit.  Likewise, if something goes badly, it makes sense to take steps to avoid the same issue impacting other projects.

Of course it is not quite as simple, as each project will be different and what has worked well for a project may not be applicable to others.  I want to expand on this point in a future post.

When to conduct lessons learned

Conducting project reviewIf you ask a project manager when to conduct a lessons learned review, I would be confident that the majority would say at the end of the project.  A relatively small minority will say at the end of a significant toll gate.

While both answers are correct, the second response provides far more value to an organisation than the response “at the end of the project”.  The reason being, the earlier that lessons can be identified and embedded into an organisation, the more value they will provide.  So the ideal response to the question would be to conduct reviews on an ongoing basis so as to allow for continuous improvement.

Obviously, it would be impossible to conduct reviews on a continuous basis.  Likewise, you would have to question the value (remember the principle only perform an activity if it adds value).  Therefore, the following provides 4 ideas of where you can use lessons learned.

1. Mobilisation

This may sound counter intuitive, why would you want to have lessons learned at the start of a project?  Well, this is not so much lessons learned from the current project, it is the learning’s and collective knowledge from other projects.

When starting a new project, the project manager should check to see if a similar type of project has been undertaken before (does not matter if it was not finished).  Then request details of lessons learned, arrange to meet project manager, sponsor, etc so as to find out “first hand” more information.

If a similar project has not been completed before, put a request out to the project managers, PMO teams, etc.  There is a possibility that somebody may have completed a similar project at another organisation.  Definitely worth buying them a coffee to get their thoughts on where there may be problems.

Gaining this knowledge will allow you to incorporate these learning’s into your planning.  This should improve the odds of a successful outcome.

If no one has completed a similar project, another approach is to ask for other project managers to conduct peer reviews of your plans, terms of reference, etc.  Good project managers will be able to review and ask probing questions that will tease out potential issues.  Updates can then be made resulting in a more robust approach.

2. Tollgate

In many project life cycles, there are phases of work i.e. Initiate, Design, Build, Test, Implement.  Some organisations define tollgates that need to be satisfactorily achieved in order to move to the next phase.  It can be common to use this in association with gated funding so that the budget to support the next phase can only be drawn down when the tollgate is achieved.

The project team will usually need to prepare evidence that the tollgate has been met to present to the project steering committee.  So, if they have to prepare a presentation, it is logical for the presentation to include lessons learned.  These can then be used to inform and make changes for future phases.

The PMO can take the presentation, analyse, review against defined tools and processes and then, where appropriate, make changes to benefit the wider organisation.

3. Change Request

Most projects will have at least one change in scope, budget or schedule over the lifetime of the project.  This will result in the project team having to create a change request to present to the steering committee or change board to reset the project.

The analysis and presentation provides a similar opportunity to the tollgate review.  The project team will need to provide the driver for the change and why it impacted the project.

Again the PMO should review the reason and workout if any changes need to be made across other projects.

4. Project Closure

Finally, the point where we started, lessons learned should always be completed at the completion of the project.  This will follow a defined template that is specifically designed to capture all aspects of lessons learned for the project.

This review will be more in-depth and will capture inputs from project team, sponsors, stakeholders, etc.  While the feedback will be more comprehensive, it comes to late to help the project so the time invested is for the benefit of others.  The only time it may be a benefit for the project is if it involves multiple workstreams.


To close I would like to summarise the key messages.

  • Lessons learned does not have to wait until the end of the project
  • Look for natural opportunities to learn and make changes i.e. change control, tollgate, etc
  • Adopt an approach on continuous improvement, making changes even if there has not been a formal review
  • PMO should be the custodian of the learning’s – actively reviewing and embedding organisation changes to improve project delivery

The next post will cover the end of project lessons learned review in more detail including the structure of the template.

Project and PMO lessons learned overview

lessons learned signIf all goes well, a project should eventually come to an end, hopefully with a positive outcome.  However, even though all the project deliverables are complete and the product, process, platform, etc is now handed over into business as usual, there is still a very important project tasks to be completed before the project can be finally closed – a lessons learned review.

It is unfortunate that this step does not get completed at the end of most projects.  In extreme cases of failure the sponsor will often demand a review in the guide of lessons learnt to understand what went wrong.  While this is good, this is normally undertaken with the agenda of finding who is to blame, not to learn.

What is lessons learned

Lessons learned is the formal process at the completion of a project, where a review is conducted on what went well and what did not go well.

Objectives of lessons learned

At a high level, the primary objectives are:

  • Identify what processes and techniques worked for the organisation so that they can be replicated by other projects
  • Identify what did not go well so that other projects can avoid making the same mistake

The overarching principle is to learn from what has happened so that future projects can benefit, resulting in a higher probability of favourable outcomes.

When to perform lessons learned?

Usually a review is completed at the end of a project as part of formal closure.  However, it is also possible to conduct a review at the end of key stages in the project lifecycle or after a particular event (usually a high impact issue).

The reason it makes sense not to wait until the end, is that identifying items to improve early will allow the project and other projects to learn quicker.  If you wait until the end of the projects, there is more chance other projects will have already made the same mistake.

Who performs lessons learned?

Typically it is performed by the project manager and / or project team.  However, sometimes it makes sense to have the review conducted by a team external to the project as they will be more objective i.e. Quality Assurance function, audit, etc.

In extreme cases it may make sense to ask a 3rd party to come in to conduct a truly independent review.


Usually a template with defined questions is used to conduct the review.  This is often in the form of a spreadsheet or word processor document.  The reason for having a set format means that reviews can be completed in a consistent manner and all the appropriate questions asked.

It is important that it is possible to tailor the questions for a specific project so as to provide maximum benefit for the exercise.

The review can be conducted as a formal meeting / workshop with all relevant project team members and stakeholders.  It can take the form of a number of desk based interviews.  Request for information via e-mail or telephone.  In reality it will be a combination.

How to use the output

This is the real power of a lessons learned review – the outcomes.  There are organisations who complete the reviews, tick the box to say it is complete, file the report and then do nothing with the findings.  This adds no value, in fact it destroys value as the review takes valuable time.

The real benefit comes from taking action on the back of the findings.  The conclusions should be reviewed and themes established.  These then need to be fed back into the process on how the organisation executes project delivery.

Ideally, changes can be translated into tools and processes.  This means that there is a higher probability that change will be made.  This is where the PMO can take a lead by reviewing the lessons learned, reviewing against the project methodology and then making changes to embed the process.  The result is that the organisation will take on the lessons and improve.

If the PMO is keeping track of all of the lessons learned reviews, they are also in a very good position to spot trends that may not be obvious.  Again allowing them to make changes to improve the process.


Lessons learned is a very important tool for an organisation that wishes to learn from their projects and improve outcomes.  The PMO is well placed to coordinate the gathering and review of the data so as to be able to update tools and processes that embed the changes.

While it takes time to conduct the reviews, it does provide a positive return on investment in the long run.

The next few posts will focus on specific aspects of the process.

First week in a PMO role

PMO CommunicationThe last few posts, have been focusing on the move from one PMO role to a new PMO role.  To build on this, this post will spend some time considering some of the Do’s and Don’t for the first week in the new PMO role.

Build understanding

If the role is in a new organisation or different part of your current organisation, you will need to get up to speed on what is going on.  Without doing this, there is a risk that any decisions you make, may not be appropriate.  Remember, when you start a role, there will be a number of people watching how you perform.  If you make some rash decisions without taking time to understand, you will struggle with support.

Good ways to build understanding are:

  • Key documents
  • Meet stakeholders
  • Meet the people doing the work (they know what is going on)

Ask questions

While you are building your own opinion through observation, you also need to seek feedback.  As you go about the day, you will be interacting with different internal and external stakeholders.  Take each opportunity to ask how they think things are going – what works and what does not work.

This is the best time to get honest feedback.  As you are not responsible for what has happened before you joined, people probably be more candid with providing feedback as it will not be in respect of what you have put in place.  They will also be aware that this presents an opportunity to influence changes to current processes.

Test feedback

People always have specific items that are important to them or what they are doing.  It may not always be representative of the wider picture.  Make sure that you test the feedback and inputs with other people.  As you speak to more people you will soon identify emerging themes and what items are unique to individuals.

Take action

While it is important not to make rash decisions, you do need to make an impact and demonstrate leadership.  When you have enough data to make decisions, don’t be afraid to push ahead.  It will demonstrate to your manager and your team that you have the courage to make decisions and lead.

In summary

All of the above is very practical and straight forward and no clever / complicated tools or processes.  It really comes down to asking the right questions and (most importantly) listening.  Doing this will set you up for success.

Taking on a new PMO role

Taking on a new PMO roleThe last post, PMO Handover Plan, covered the importance and key elements of transferring the running of the PMO when you are in the process of moving to a new role.  Therefore, it is logical to cover the steps to take when you take-on a new PMO role.

Overview of PMO

Make sure you have a good understanding of the objectives and scope of the PMO.  This will include:

  • Number and types of projects
  • PMO maturity
  • PMO type (admin, managerial, hybrid)
  • Current resources / open vacancies
  • Services being provided
  • Challenges / weaknesses

The aim is to gather a good understanding of the current state and an idea on areas of concern, gaps in service, etc.

Understand role

It is very important to understand the role.  This is important as you need to ensure that what is being asked is achievable, that you have the appropriate skills and that you can be successful.

Ideally there will be a job description.  If there is not, build your understanding and then write one so that your role is clear to both you and, more importantly, your manager.  This is crucial for demonstrating that you have achieved at the end of the year.

Meet your manager

This is closely linked to understanding the role.  Meet with your manager and find out what they require from the PMO, their concerns and expectations for you fulfilling the role objectives.  It is good to use the job description for this conversation.

Make sure that the expectations are realistic.  If not, work with the manager to ensure they are realistic.

Meet the current role holder

If this is possible, always try to spend time with the current role holder.  They will be best placed to provide you with the real insights to what has been achieved, where there are problems and the usual nuances of the organisation and people.

This step should give the real insight to the role and to work out how difficult it may be.

Meet PMO team members

Arrange meetings with the current PMO team members.  This will allow you to understand their roles and gain their input on what is and is not going well.  This can be very revealing compared to the messages from sponsor and PMO manager.

Review documentation

Review available documentation such as:

  • PMO vision and mission statements
  • PMO charter
  • Example reports

This will provide an understanding of the objectives of the PMO and the quality of the deliverables.

Meet stakeholders

Spend time speaking to stakeholders – people who consume the services from the PMO.  Ask them there thoughts on the service – what is working and where there are issues.  Gain an understanding of what they require from the PMO.

These meetings will also reveal who is supportive of the PMO.

In summary

Before taking on a role in a new PMO, you must try to gather as much information as possible about the PMO and the role.  When you have decided to take on the new opportunity (or challenge), spend time engaging PMO resources, stakeholders and sponsor to understand what works and what does not work.  This will then allow you to create a plan that will move the PMO forward and deliver the services that the stakeholders require.

If you can quickly improve the service it will benefit the organization and stakeholders.  All of which should enhance your career.

Word of caution, if it becomes obvious through the data gathering that the PMO is not supported by the sponsor and stakeholders, there are lots of challenges, deliverables are poor, etc, then it might be wise not to take the role.

PMO handover plan

calendar for handover planIt is highly likely that at some part of your career, you will decide to move roles (either internally or externally).   While you will be very excited and focused on what the new opportunity will bring, you will also need to consider how you will complete a seamless handover of your current role.  In this post I want to focus on how this can be achieved through a PMO Handover Plan.

Why is handover important?

Before covering the steps that you can take to facilitate a successful handover, it is worth considering why this is important:

Reputation – hopefully you have played a part in establishing a successful PMO, it is probably the reason you secured your new role.  So why risk reputation by not paying attention to the handover.  Remember news does travel.

Commitment – you have probably invested considerable effort an emotion and have a strong attachment for the PMO to flourish even after you have left.

Loyalty – you are leaving colleagues who have shared the journey and you want to ensure that you don’t “drop them in it”.

Future Role – you never know what may happen in the future and you may wish / need to return to the team in the future.  Leaving on good terms and taking the effort to execute a good handover will hopefully leave the door open.


As with any project, preparation is very important.  As soon as you’re aware that you may be moving on, start to construct a plan to cover:

  • Activities
  • Handover Document
  • Handover Review
  • Handover Training



Collect all of the activities that you perform.  This is both planned and ad-hoc.  I suggest that this is done by capturing them as a simple list under the headings Planned and Ad-hoc.

It is a good idea to capture them in the back of the notebook as it will be with you when you are away from your desk in meetings.  This allows you to capture items you have missed when they occur.  I find this often happens when you are in a meeting.

Handover Document

Transfer the activities into an electronic document.  This should be formatted so that you can capture activity, description (explain purpose of activity), when (date / time needs to be completed), output and proposed new owner.

This should be split into 2 sections.  The first covering all of the planned activity and the second the typical ad-hoc requests.

This should then provide a concise record of all activities that can be used to handover tasks.  It is important to include all relevant information including key contact points, location of documents, etc.

You should make sure that the document includes any outstanding items that need to be addressed.

Handover Review

This will typically be with your manager and / or person assigned to take a lead on the handover.  The purpose is to walk them through the Handover Document to ensure that they have a clear understanding of activities.

This will allow for the identification of:

  • Gaps
  • Items that are not clear
  • Activities that can be removed

A very important aspect is agreeing who each task should be handed over to so as to allow for training.

Handover Training

Handover sessions should be set-up with all of the proposed new owners.  The session(s) should be used to formerly handover the activities.  These must be structured and not rushed as you want to ensure that the new owner has time to understand and digest.

It is advisable to start this as early as possible so as to allow time for follow up questions before you formerly leave.

Make sure that you do not just assume that just because you have completed the meeting that the new owner understands.  Make sure that you seek positive confirmation that they are happy that they have the information they require.

General Tips

Make sure that all important documents, e-mails, etc are stored in the designated shared location.

Keep your line manager appraised of progress and any concerns you have on the knowledge transfer.

If you are moving internally and if it is viable, make it known that you will be available to answer questions, provide clarification, etc even after you have moved to your new role.

In summary

If you are going to move roles, make sure you plan an orderly exit.  This will ensure that your current PMO continues to perform, will assist your colleagues, safe guard your reputation and hopefully mean that the door will be open if you should to return some point in the future.

PMO project dashboard

At times it can be very confusing about the definition and purpose of the many tools and templates used in project management.  Therefore, building on the last post that covered PMO Reporting Framework, this post will cover the PMO Project Dashboard.

What is a PMO Project Dashboard?

This is typically a summary of all of the projects, programmes or work streams that the PMO has oversight for.  So if the PMO had oversight for 10 projects, the dashboard will contain a summary and status based on the 10 projects.

What is the benefit?

The main benefit is for senior management as the use of a dashboard allows project data to be summarized using defined and understood standards.  This means that senior management can review the dashboard and very quickly understand where there are problems so as to focus their valuable time on the right items.

Without the data being summarized, senior management would then need to go through individual reports to understand status and areas of concern.

How is the dashboard produced?

The dashboard is typically produced by the PMO collecting and reviewing each of the individual project reports.  Key elements are then taken from each of the reports to be used on the dashboard.

An important aspect to this is the definition and criteria for different report attributes.  For example, clear guidance on the RAG status so all projects can be compared on the same basis.

How often is the dashboard produced?

This is really down to each organization as they will each have different needs.  The typical reporting cycle for most organizations is monthly.  However, in some industries, projects are under a year, therefore, there is a requirement to monitor progress more closely.  In these situations you could see weekly or fortnightly reporting.

When setting reporting cycles it is important that the PMO sets a timetable that is appropriate and provides value.  Don’t report weekly if fortnightly will provide the required transparency and controls.

If you decide for a weekly or fortnightly cycle, you should review the project report and dashboards and endeavor to make them simpler to complete.  This will ensure that the project teams do not spend a disproportionate amount of time producing reports.

What project data should be captured on dashboard?

A good dashboard at a minimum will normally contain the following elements:

  • Project name
  • Project manager
  • Overall RAG status
  • Previous reporting period RAG status
  • Costs
  • Benefits
  • Brief status summary


A PMO Project Dashboard is a dashboard used to provide a summary report of all the projects for which a PMO has oversight for.  It is a powerful tool for senior managers to quickly understand the status and areas of concern, especially when time is limited.