PMO Tools Handbook

milestone-planning-guidelinesA Project Management Office, will invest a lot of time and effort creating standardised templates and processes.  The reason being that this should help improve the quality and consistency of how each project is executed.  It also should mean that project data can be quickly and efficiently consolidated to produce meaningful reporting and management information

Important Point – the benefit of the standard templates and processes can only be truly realised if the defined methodology can be quickly communicated so that the project teams embed the standards.  This embedding stage can be very time consuming especially when project team resources are joining an organisation over a period of time.

The solution to this challenge is training and, the PMO Tools Handbook.

What is a PMO Tools Handbook?

In very simple terms, it is a guide / manual that documents all of the tools and processes that should be used to execute a project.  It should have sufficient information that a new joiner to an organisation can read the handbook and know what they need to do for each process.

What format should be used?

This is down to the personal choice of the PMO, obviously considering any standards mandated by the organisation.  The handbook can be published as:

  • Word document
  • Powerpoint
  • PDF
  • Website / Intranet Site
  • Bespoke publishing platform

It is a good idea for an electronic format as this will allow the inclusion of hyperlinks to additional information or templates.  It also means that the changes can be made as part of continuous improvement where as printed / bound handbooks need to be replaced.

It is also important to make use a format that does allow the information to be printed.  Many project managers like to be able to print and review documents.  A good tip is to produce simple guides that are easy to digest and link into the further detail.

Who should own the handbook?

The ownership should be with the PMO.  It is important that the content is maintained and kept up to date.  It is a hard sell to push people to use standards when the PMO is not keeping on top of their own content.

What should be included in the handbook?

The handbook should contain details that explain the context of the PMO and then the different tools and processes.


  • Purpose & objectives
  • Context & background
  • Vision & mission
  • Design principles
  • PMO responsibilities
  • PMO organisation
  • PMO roles & responsibilities
  • Engagement model

PMO Tools & Processes

  • Planning
  • Cost management
  • Benefit management
  • RAIDs management
  • Reporting
  • Change control
  • Resource management
  • Communication management
  • Procurement management
  • Document storage management
  • PMO contact details

There should be sufficient information to explain:

  • Process
  • Tools
  • Ownership
  • Frequency

It should also include examples of any templates and links to where the latest version can be downloaded.

How to use a PMO Handbook?

It is important that the handbook is made available to all appropriate project team members and stakeholders.  Communication is key.  Therefore for maximum benefit do not just send a link and leave project teams to find and review the handbook.  This will not achieve the required outcome.

The PMO should set up training / orientation sessions with project teams.  While you can set up a large workshop, it is better to work with project teams on a case by case basis with perhaps a couple of the project team and project manager.  This will ensure that there is engagement.  Allow for questions specific to project to be answered and allow the PMO to get a sense of how committed the project are to the process.


A PMO Handbook is a very valuable tool to communicate and embed the required standardised tools and processes.  Couple with targeted training, standards can be quickly communicated and embed to maximise benefit.

4 Simple PMO Metrics to Measure Success!

Example graph tracking PMO metricsThere is typically a lot of time and effort invested to monitor the progress of projects.  It is usual that the primary reason for establishing a project management office (PMO) is so as to provide an independent view on project performance.  While this is helpful for measuring the success of projects it is also important for a PMO to have a process to measure their own success.

The reason for this is that at some point someone will question what is the value provided by the PMO (especially when there is a downturn in the fortunes of an organisation).  Therefore, a smart PMO will implement processes to track and communicate success.  This means that they are ready to demonstrate value.

As many of the metrics to demonstrate progress will need to be collected over time, the quicker the PMO starts to collect the data, the better they will be positioned to articulate the value they are adding / creating using facts.

There are a number of metrics that can be utilised, some will be specific to each organisation.   Below are 4 ideas of more generic metrics that are very powerful to demonstrate success.

1. Time to Mobilise

A common reason for project failure is slow mobilisation.  Tracking the time from project kick-off (the initiation) to mobilisation being complete, will demonstrate that the PMO has improved the time it takes for a project to become productive.  This can be achieved by measuring the time between a project being formerly started to sign-off of the business case (the usual gate into project execution).  Obviously you can use the recognised gates used by your organisation.

Over time you will build a bank of metrics that show you how long it typically takes to mobilise.  By collecting details of project size and content i.e. IT or even IT, System Name, this information will also help future projects to plan.  For example an IT project can look at previous IT projects for the same system and get an indicator of how long it took to mobilise.  This should result in better plans.

2. Percentage of Projects Delivered

This metric will measure how many projects launched (were started) each year (or appropriate time frame) were actually delivered and achieved the benefits in the business case.  To track this you will need to be able to build a view of the performance of previous years so as to demonstrate how this has improved.

Variation of this metric is % of projects stopped and % of projects that fail to deliver benefits.

Both are good as it will inform the organisation of their success rate.  So if only 60% are delivered, they can factor this into their planning and expectation of the benefits that will be delivered.  Far better than assuming and planning for 100% success.

It would then be possible to analyse this data to identify trends / common factors.  For example, is it a particular type of project that always fails?  Is it a particular team or even project manager / sponsor?

Using other metrics.  Is it where a project is slow to mobilise.

All of this should give some good, actionable insights.

3. Benefit Realisation

With the exception of regulatory or mandatory projects, most projects are started in order to achieve some form of benefit for an organisation.  Tracking the realisation of benefits against business case will provide focus to ensure that the benefits are achieved.  Again the % realised should be measured against previous years.

This is tracked by simply capturing the baseline of benefits against a timescale and then tracking the actuals.  This will highlight where the realisation is delayed, reduced or missed.

Similar to Percentage of Projects Delivered, you will be able to analyse to identify the trends and common factors for where benefits are not realised.

4. Return on Investment

Tracking the overall project costs and benefits will allow the calculation of return on investment (ROI) for the portfolio of projects.  This is a good metric for senior management as it will provide them with insight on the return from investing in change.

By monitoring year on year, the PMO can show if their service is leading to an increase in project ROI.  Again the data can be analysed for trends and this will help corrective actions and / or allow senior management to make more informed decisions i.e. investing in the projects where ROI has historically been higher.

In Summary

A smart PMO will ensure that they have processes in place to track key metrics in order to demonstrate the value that is being added by the PMO through the improvement of project delivery.  Over a period of time the metrics will help identify problem areas i.e. slow mobilisation due to time to gain approval from management, types of projects that fail to deliver, etc.  This in turn will allow corrective action.

The data will also help the organisation to make smart informed decisions to best utilise the change budget.

Use the comments below to add your thoughts and experiences of using project metrics.

Plan the renewal of your PDU’s and avoid a mad rush!

Person upset as short of PDU'sFor those who have invested the time to attain the Project Management Professional (PMP) that is overseen by the Project Management Institute (PMI), you should be fully aware that you need to re-certify every 3 years.

In order to recertify, you need to obtain 60 Project Development Units (PDU’s) over the 3-year period.  The good news is that you can gain up to 45 through working in project management and self-directed learning.  However, this still means that you need to gain 15 (or more) through other categories such as training from recognised providers.

The PDU’s need to be recorded online via your PMI account in order to be recognised.  When you have achieved 60 in the 3-year period, you then are presented the option to “Renew”.

The reason for raising this is that due to work and personal commitments, many people do not record the PDU’s they have earned over the 3 years until the last minute.  This then causes a mad panic creating unneeded pressure, especially if you have forgotten your PMI login and have not kept a record of the PDU’s that you have earnt.

It is very easy to avoid this becoming an issue and causing stress by a couple of simple actions.

PMI Account

You will need to log into your PMI account to claim PDU’s.  Therefore, you need to make sure you keep a record of the user name and password.  A good idea is to keep a record of account logins and passwords using an Evernote account so as not waste time hunting for login details or password.

Word of caution.  Make sure that you password protect the note books on your device just in case you lose your computer, password, etc.  If you do then someone could access the details through the Evernote programme / app.

Record PDU’s

Keep a spreadsheet or similar log of PDU’s.  This is easier to capture PDU’s as opposed to logging into the PMI account at the time of completion.  However, if you do have time to login and record at the time of completion, this will be the best approach.

The spreadsheet needs to capture the details of the PDU together with date completed, duration and number of PDU’s.  For recognised training (category C), you need provider number and PDU / training number.  This is important for category C as you need to enter this into the PMI interface to claim the PDU.

Make-up Shortfall

Make sure you do not leave it to the last minute to make up any shortfall as you will not have time to complete any required course, training, etc.

There are a number of training organisations who provide online PDU’s, usually delivered via presentation or video training.  Therefore, you should be able to find a course that provides access immediately enabling you to gain the required level of PDU’s.  Simply register, pay (if required) and complete the training.

A good method to avoid the mad rush to earn PDU’s near certification is to use a service such as PDU Podcast.  For a low monthly fee, you can receive a webinair that is worth at least 1 PDU each month.  Simply download to your computer, smartphone or tablet and watch at your convenience.  Great approach as you do not need to remember, the e-mail arrives each month and you can watch whenever you want, especially good if you have to commute to your job by train or public transport.



  • As with a project, make sure you plan the capture and recording of PDU’s.
  • Make sure you know how many you have, especially the ones that need to be achieved through training, etc.
  • Where possible record directly with PMI at the time of completion.  If not use a spreadsheet to record and enter as soon as possible.
  • Aim to complete the required training at a steady pace over the 3 years

I hope that this information is helpful and can help avoid a mad rush.  If you have any great tips for earning PDU’s please use the comments below to share with the PM Majik community.

Project Book of Work Template Download

Over the last 3 posts, the topic of capturing and mobilising a Project Book of Work have been covered.  To conclude this series, I am pleased to announce that this post provides a Project Book of Work Template that you can download for free as part of this post!


The Project Book of Work Template will allow for the structured capture of projects.  This is very helpful when trying to build a view of the demand for a given year.  The template also features the following highlights:

  • Capture split of Mandatory & Discretionary projects
  • Automatic sorting based on priority
  • Application of risk factors to allow for budget / benefit overruns
  • Generation of useful graphs and summary tables that can be pasted into SteerCo’s, Status Reports, etc.

Template Tabs

Below is a list and overview of each tab in the template.  Full instructions can be found on the Instruction tab in the template.


This can be used to give details about the owner and date published.

Project Book of Work Header tab


This tab provides an instruction section for each of the tabs, many listing a field by field description.  The picture below is an extract of the list of instructions.

Project Book of Work Instructions tab


This tab is used to capture important static data points such as budget and risk factors that are then applied to the input and calculation tabs.  This provides great flexibility allowing you to model different risk factors to see the potential impact on project budgets.

Project Book of Work Static tab

Project Inventory Dashboard

This tab is automatically generated based on the inputs.  It presents key data points in the form of graphs and tables.  This is useful and can save time as these can be copied and pasted into reports i.e. SteerCo’s, Project Status Reports, etc.

Project Book of Work Dashboard tab

Data Summary

This tab is automatically calacultaed based on the inputs.  It presents different views of the data based on Mandatory and Discretionary projects split by a number of factors including risk factors and inflight / new.  This is useful when you want to review the data in a single view.

Project Book of Work Data Summary

Mandatory Projects

This is where details of the Mandatory projects are captured.  Data is entered into the Yellow fields and the remaining fields are calculated.  The user can set the Priority and Risk Factors.  The top section provides a summary split by different dimensions and shows if the demand is within the available budget.

Project Book of Work Mandatory Project input tab

Discretionary Projects

This is the same as the Mandatory Project tab but for Discretionary projects.

Project Book of Work Discretionary Project Input tab

Prioritised Project List

The final tab in the Project Book of Work template allows for the simple construction of a prioritised list of projects based on the inputs.  With Macros enabled, simply click the Priority List “Start” button and the list of prioritised projects will be built on the page.  The split is by Mandatory and Discretionary using the user defined Priority.

Project Book of Work Prioritised Project List tab

Template Download

You can download the Project Book of Work by clicking the link below.

Free Download - Project Book of Work TemplateSummary

This template provides a structured framework for capturing a Book of Work.  It also allows the smary use of risk factors that will help improve the decision making on projects.

As with any template, think how you can adapt and make use of the ideas and concepts to help your objectives.  Templates can always be improved.

If you have some good ideas, please use the comments below to share with the PM Majik community so everyone benefits from shared learnings.

Small Request

A lot of time and effort goes into developing these resources and writing up the information.  It is a big encouragement when people take a moment to appreciate and share this and other content using the social media buttons on this page.  Please consider taking a moment to share.

Executing a project book of work

Planning to execute project book of workThe last posts covered an Overview of a Project Book of Work and how to Capture the Projects for a Book of Work.  So following these steps will mean that you have a consolidated, signed-off list of the projects that need to be executed.  Now comes the more difficult step of executing the book of work – making them reality! Below are some important steps you will need to take to give the book of work the best chance of being successfully executed.

You can get your own free copy of the Project Book of Work template by visiting Project Book of Work Template download.

  1. Demand exceeds budget

It is highly likely that the initial budget estimates for the book of work will exceed the amount of available budget.  This means that if the estimates remain the same, it will not be possible to complete all of the projects in the list. There are a number of options for trying to address this challenge:

  • Ask for additional budget to cover all of the demand.  This is the best option.  However, in most cases the additional budget will not be granted.
  • Review the prioritised list and remove projects from the bottom of the list until the budget demand of the list is equal or less than the available budget.  The removal of the projects must be agreed with all stakeholders.
  • Review the estimates and contingency in each of the projects to see if savings can be made.  A word of warning, most projects tend to take longer and cost more than anticipated so this is a high risk strategy.
  • Review projects for opportunities to capitalise expenditure.  While this may provide some savings in current year, it only serves to store up expenses in future years.  You also have to be confident that the project will be delivered in the time period to meet any rules your organisation may have on claiming capitalisation.

Out of these options, reprioritising and reducing the list usually gives the best outcome.

2. Prepare business cases

In order for a project to be initiated, it is normal for an organisation to have a formal method to approve a project and provide budget.  So to minimise any delays, make plans for the preparation of the required business cases. As part of the planning and completion of the business cases, make sure that you:

  • Ensure you understand the process and have the correct templates.  It is typical for an organisation to change the process on an annual basis to learn from previous budget cycles.  Therefore, make sure you have the latest template and not just use one from a previous year.
  • Make sure you understand what is the governance process for gaining approval.  If there are governance forums investigate when they are held, when papers need to be submitted, what information is required, who will need to present and how quickly approval will be provided.
  • It is critical that you take the time to ensure that the business case is robust and presents a compelling investment case.  Do not simply treat it as a form filling exercise.  You want to make the business case easy for people to say yes.

3. Resource plan

As soon as you receive approval for a business case, you should be ready to mobilise.  So many projects lose valuable time by taking time to mobilise. Based on your prioritised list, make a plan of the resources you will need as soon as a project is approved.  This will typically not be the full set of resources, just those that will be needed on day one to allow progress to start. If possible try to identify potential candidates.  Ideally these will be people who already work for the organisation.  However, this may not always be the case.  Therefore, it is prudent to start building a list of possible resources external to the organisation.


Having an agreed project book of work is a great start.  However, the real success comes from making plans to quickly mobilise and execute the book of work.  Following the 3 steps above will help with achieving this objective:

  1. Resolving where demand exceeds budget
  2. Preparing business cases
  3. Initial resource plan

Mobilising & Executing Project Book of Work Presentation

Capturing projects into a book of work

In the last post, Overview of a Project Book of Work (BoW), it covered what is a BoW, why you need one and the important data items that need to be captured. This information allows a template to be designed to capture the projects.

This is the second post in the series and will cover what you need to do to identify and capture the projects that will form the BoW.

4 sources for building project book of work1. In-flight Projects

The first source for building the Project BoW is all of the current in-flight projects.  In-flight is the term often used to describe active projects.  The fact that they are active should mean that they are important to merit the budget and resources.

When capturing the current projects, it is important to consider what is the criteria of the BoW.  For example, if you are building a BoW for the next year, you only should capture the details of those projects that will still be active in the following year.

Tip: When you review the active projects, you may eliminate all of those scheduled to finish in the current year.  Before you do this you may want to consider if they will actually finish or will there be delays that mean they need to roll into the following year.

It is advisable to allow some budget for all projects that are due to finish in Q4 just in case they overrun.  Additionally look at the performance of the active projects.  If there are projects that constantly miss dates and extend the schedule, you need to think hard for including them in the BoW.

2. Next Phase Projects

In some cases, a current in-flight project maybe the pilot / proof of concept for a much bigger project.  For example proving a platform is fit for purpose in a single country before embarking on a project for a global roll-out.

So a review needs to take place of all in-flight projects to identify any that will naturally lead to a new project (or continuation of the existing project as a new phase).  This applies even to the projects not finishing until following year.

3. Commitments

It is usual for there to be a level of mandatory change that needs to be delivered within an organisation.

It may be that a vendor is remove support for an older version of their software and, to continue to receive support, the software must be upgraded.  Regulators may mandate that an organisation makes changes to address weaknesses.  Central bodies may change their protocols.  An example being the SWIFT payments network who sets a deadline when certain message types must be updated if you wish to continue to use them.

So a “Commitment” should be seen as any change that must be made. These need to be included on the BoW.

4. Stakeholders

Discussing projects with stakeholder

When you have constructed the initial BoW you should then engage and hold meetings with key stakeholders.  This will allow you to show them the draft BoW so that they can provide feedback on the items captured and help identify additional items that should be included.

It is important to have an initial draft as, starting from a blank piece of paper can appear daunting.  It is also likely that seeing a list of projects will make them think of other items that need to be considered.  For example if there is a project that is to implement an operational platform to support a new service, this may prompt the stakeholder to consider that a client facing interface and app is required to feed the operational platform.

As part of the process you need to ensure you engage all relevant stakeholders.  So make sure you create a stakeholder list and then schedule sessions.  You may even want to try and hold a single session.  If you have the list, you can check with each stakeholder as you meet them if anyone else should be engaged.


When you have captured all the items and held the stakeholder sessions, you should review the feedback to ensure it makes sense and that there is no duplication.  This updated BoW should then be sent out to all of the stakeholders for final review and sign-off.

This should result in a final BoW.


The process to capture items for a project BoW is achieved through simple, structured actions.  It is important to create an initial draft based on solid inputs.

Stakeholder reviews are critical to test the projects that have been captured and identify any that should be added.

Using a final review by all stakeholders should result in an agreed project book of work.

Capture Projects for Book of Work Presentation

Building a project book of work

When an organisation is making plans for the coming year (or even years), this will inevitably result in a number of change projects.  Each project having the objective to implement part of the overall strategy.

It is therefore important that an organisation has visibility of all of the current and planned projects.  Otherwise there is a risk that projects will be missed meaning they will not be delivered resulting in a gap in achieving the overall strategy.

A very good tool for capturing information on all current and planned projects is a Project Book of Work.

What is a Project Book of Work?

The concept of a Book of Work is very simple.  It is a list of all the current and planned projects for an organisation.  Each project is captured as a line item with important information including Project Name, Budget and Benefits.

In large organisations, it is common for each area to have their own Book of Work that aligns to the organisation / budget structure.  This may even be broken down further with each function having a regional or country Book of Work.

Whatever level the information is captured, it should be possible to consolidate the Book of Works to give each area a view of all of the projects within their area.  Ultimately all the information can be consolidated to give a Book of Work for the organisation (useful for senior management).

Why use a Book of Work?

In most cases the budget demand will exceed the available budget.  This means the organisation will need to prioritise what projects receive funding.

The BoW allows a consolidated view to be built across all of the demand.  The information can then be used to provide meaningful management information to make decisions on how the budget is allocated.

A good example being that an organisation usually needs to fund all Mandatory projects before considering funding discretionary projects.  The BoW can provide the total demand for all Mandatory projects.  If there is any budget available after all Mandatory projects are funded, this can then be used to fund the discretionary projects in order of priority.

This is a good approach for an organisation as it helps avoid funding being split across the organisation and then used to fund less critical projects.

Consider an organisation has 4 lines of business.  If budget is allocated 25% to each line of business, you may have a situation where one line of business has Mandatory projects that exceed the 25% allocation and another area has Mandatory projects that represent less than 5%.  This presents the risk that Mandatory projects will not be funded for the first line of business and line of business funds 20% discretionary projects that are not a priority.

What information should be in a Book of Work (BoW)?

Example of project book of work templateThe aim is to collect enough information to be able to build a meaningful list of projects.  This may be slightly different from organisation to organisation.  In fact it is common (and confusing) for different organisations to use different names to describe the same thing!

Below is a list of the core information that should be included within the Book of Work template.


This is used to give a user defined identifier to the project.  The reason for this is if you are building a BoW that takes inputs from a number of different areas, you may want to be able to identify the source.  For example, you may want to use OP1, OP2, OP3, etc to identify that the project is for Operations.

Project Name

This is the simple, succinct name of the project that will be recognised in the organisation.  While the aim is to keep it brief, it must be descriptive.  For example using ABC System Enhancements may describe what is being done.  However, what if another area is using the same system and plans to make enhancements.  It may be better to add the area i.e. ABC System Operational Enhancements.


It is normal for the project budget demand to exceed the available budget.  Therefore, each area should prioritise their project submission.  So if the area submits 10 projects, they will be prioritised 1 to 10, with 1 being the highest priority.

Business / Function

The field is used to identify the area requesting the project.  It should be the same as indicated in the ID.  This field helps when the overall demand is consolidated so as to see what each area is requesting.


This can be used to identify what location in the organisation is making the request.  It could be that a BoW is developed at a country level and then consolidated to a regional level i.e Hong Kong, Singapore, etc that rolls up to Asia Pacific.  Having this allows the demand by location to be reviewed.

Investment Type

Very important.  This is used to indicate if the project is Mandatory or Discretionary.  A Mandatory project will typically something that the organisation has no choice and must complete i.e. to meet requirements mandated by Governments, Law Enforcement Agencies, Regulators, etc.  Discretionary being where the choice to complete the project is not being mandated.

This can be a grey area.  For example, in banking the SWIFT network periodically upgrades their message types.  If a financial organisation wishes to continue to be able to send / receive the messages they need to upgrade their systems.  This is not technically a Mandatory project as the organisation can choose not to upgrade and decide they will no longer use the SWIFT message.  However, realistically the organisation must upgrade as without using the message, they probably will need to stop parts of their business.

In Flight

This is used to indicate that the entry is an active project.  This is important as it is typical for projects to run multiyear whereas budgets are set annually.  Knowing this helps inform funding decisions.

Tip: Just because a project is in flight, do not assume that it automatically should be allocated funding in subsequent years, especially if it is not Mandatory.  When the BoW is prioritised, if there is not enough budget, and an in-flight project is lower in priority than others not started, you should evaluate stopping the in-flight project to pass the budget to those with higher priorities.

Risk Factor

This is an optional field in order to build a risk based view to the project budget and benefits.  Many projects end up costing more with reduced benefits.  Allocating a rating of High, Medium or Low risk that applies a risk multiple to the budget and benefit value, helps give an indicator of potential true costs.

For example, you may decide that a High risk factor for Budget is 200%.  High risk being that the project is a new system that has not been implemented at any other organisation and resources need to be trained in the new programming language.  The Risk to delivery is high so the Risk to budget is high.  Therefore, the 200% Budget Risk Factor will provide a view of potential real costs i.e. $2m against request of $1m.

Budget Current Year

Used to indicate the amount of budget being requested without Risk Factor applied.  This should be the best estimate available.

Benefits Current Year

Used to indicate the benefits expected to be delivered in current year.  This should be the best estimate available.

Budget Total Project

Used to indicate the total multiyear cost for the project.  This is important as Year 1 may only be a request for a low amount.  However, there are 4 more years of much greater cost required to complete the work.  This is important information to make an informed decision.

Benefits Total Project

Used to indicate the total multiyear benefits for the project.  This is important as benefits typically are “back loaded”, come near the end of the project.  Therefore, having a view on total benefits helps inform the investment decision.

Budget Risk Factor Applied

This is the calculation of the budget by the defined risk factor (High, Medium, Low).  It helps to understand potential cost if the projects do not go to plan.

Benefits Risk Factor Applied

This is the calculation of the benefits by the defined risk factor (High, Medium, Low).  It helps understand how the benefits could change if projects do not go to plan.

A project with High Risk Factor for Budget and Benefits could result in much higher costs and much lower benefits.  Management may want far more information before making the decision to invest.


This allows the submitters to provide any other useful information to support the submission.


This post has given a good overview of what is needed to build a Project Book of Work.  The next post will provide guidance how to capture the information.

Project Book of Work Presentation

PMO tips – project and PMO planning for significant events

pmo planning for significant events like the OlympicsWhile writing post “Keeping projects on track over the summer holidays“, it made me think about the plans that many organisations make when major events are held such as the Olympics, World Cup, etc.

For example, when the Olympics was held in London in 2012, many organisations in and around London made contingency plans.  The reason for this was that for the duration of the Olympics and ParaOlympics, it was highly likely that there would be a number of challenges to the normal working day:


Increased number of visitors to the areas in an around the stadiums.  All of these people needing to get to the stadiums meaning the travel systems being placed under extreme stress.  The daily number of people using the travel systems greatly increasing making it a challenge for workers on their daily commute.

Road Closures

For some major events, it can be common practice to close or divert roads.  This makes driving very difficult, delay buses and push more people onto other modes of transport such as the underground (making the problem even worse).

So what…..

The ‘so what’ in all of this is that all the extra people and transport challenges will make it difficult for people to go about their normal working day.  During the London Olympics many organisations made plans for staff to work remotely, not to arrange any key face to face meetings in London and, generally accept productivity will reduce.

PMO Action

In a similar way to proactively manage staff holidays.  Similar assessments should take place for the significant events (such as the Olympics) (see post on Project Holiday Planning).  This will allow the PMO to identify potential problems and help put mitigating plans in place early.

Take Away Thoughts

While you may think the Olympics in London is very specific, the principles of identifying potential events that will impact project delivery is universal and timeless.  The Olympics will be held every 4 years like the World Cup.  There are other key events that will impact particular Cities and countries.

The lesson is that a good PMO or project leader should automatically be thinking and identifying events that will impact the projects under their control and take positive, proactive action.

PMO tips – keep your projects on track during the summer holidays

Holiday project ganttWe are now nearing the end of June and the holiday season is fast approaching (the period mid July to mid September).  This is the time many of the people working on projects decide to take their main holiday of the year, which can be a period of 2 – 3 weeks.  With so many people out of the office, it is only natural that productivity and progress slow down.  Therefore, I wanted to share some tips and ideas how you can demonstrate the value of your PMO by being proactive.

Holiday Plans

Before putting contingency plans in place, it is good to understand if there is a problem.  Make sure that each project has put together a holiday planner showing the dates when project resources are out of the office.  In fact it is good practice to prepare a holiday planner at the start of the project and then keep it up to date.

In the UK it is normal for people to take 2 weeks holiday.  In Europe this can be up to 4 weeks and in certain countries you will find very limited staff in the office in August.

Having a clear understanding of the holiday dates will act as an important input to assess impact on the deliverables and plan.

Key Deliverables / Milestones

Ask the project manager to review all the key deliverables and activities over the period July to September.  Make sure they consider the resources who will be on holiday and then evaluate how this may impact deliverables and what this will do to the overall project timeline and benefit realisation profile.


In a similar way to Deliverables, ask the project manager to identify where key dependencies need to be delivered during the period.  This will then allow a check with the project manager who is the ‘giver’ to assess if the delivery will be delayed due to staff holidays.

This is where a proactive PMO can add real value as they should have a good overview of all the key milestones and dependencies allowing them to quickly identify potential hotspots.


Are there any key decisions or sign-off’s required from senior management or sponsors over the holiday period?  If so, will they be in the office and able to attend the appropriate steering committee, etc.  Again show your value to the project managers by building a holiday schedule of senior management and sponsors.

Where they will not be around, see if there is a way to accelerate the decision meeting, arrange for an empowered delegate to be appointed to take the decision.  On this it helps if you can layout something like “If deliverable meets x,y, z criteria then it is possible to sign-off / make decision”.  By doing this you help the delegate to make the decision as they know their boss has laid out the criteria.  Likewise, it helps the project manager to remember what standard they need to meet.

Run Rates

When all the information has been pulled together, it is worth looking on how it will impact the run rates.  In many cases, project planning does not take into account holidays.  This is normally OK when there is a only one or two people out.  However, when there are lots of people, this will reduce the run rate.

It will reflect very well on the PMO if they can identify that not so much budget is needed in a given year providing senior management to redeploy the surplus funds on other projects.


Using some or all of these tips will demonstrate that you are a forward-looking, proactive PMO that delivers real value.

If you look at all of these tips, none are rocker science, just good practical, common sense.  Unfortunately this type of thought process gets lost when people are focusing on near term deliverables.

This leads to my overarching tip.  As a PMO manager, always think ahead to try and identify what will cause problems in the future.  Doing this gives you the best chance to take action and avoid issues.

Project Deliverable Tracker (the fields you need)

Woman pointing at project deliverable tracker signThe last post, How to know the project is done, covered 4 principles that could be used to help ensure that a project delivered the required outcomes. One of the principles being the use of a Deliverables Tracker to monitor and store key project outputs.

This post will expand on the practical components of the Deliverables Tracker.

Before you start

It is important that the project managers have taken the time to define the deliverables for the project. If not, it will be nearly impossible to populate a Deliverable Tracker. However, while this is in progress, you can create the template to capture and track the deliverables.


The Deliverable Tracker is simply a log of the deliverables that must be completed for each project. A simple solution is to use a spreadsheet application such as Microsoft Excel as this will allow the filtering and searching of data. It is also possible to build more sophisticated trackers using applications such as SharePoint. This will then allow the automation and integrated storage of deliverables.

Key Data Points

The following gives an overview of the data fields you should capture within your Deliverable Tracker.

Unique ID

Each deliverable should be assigned a unique reference. This will help make it easier to search for a specific deliverable, especially if the tracker contains deliverables for multiple projects and programmes. It will also help the traceability back to the original requirements.

Aim to use the same unique ID as what is used by the project. This will eliminate the risk of confusion and the need for cross reference tables.

Work Breakdown Structure (WBS)

It is good practice to use a WBS when structuring project plans. Therefore, you may wish to capture the WBS that has been assigned to a deliverable. However, take care when tracking multiple projects as there may be a risk that the same WBS may be used across different projects.

You can even consider using the WBS as the Unique ID if there is no risk that there will be duplicates.


This should be a clear and concise description that details the deliverable. It should allow for anyone to understand what is being delivered without having to refer to the underlying project. This is also useful if part of the process is for an independent review of each deliverable against the tracker.

Business / Function

For a large organisation you may wish to include a field to indicate what area of the organisation owns the deliverable. This will then allow the data to be filtered to create specific reports I.e view of deliverables for specific business. You may wish to have separate fields for each if it is possible to have Functions within a Business.

Region / Country

This allows for data to be filtered to give reports based on Country or Region. Again you may wish to use separate fields to allow better filtering and report production.

Project / Programme

If the tracker is being used for multiple projects, this field will allow the filtering by project.


This should be the ultimate owner for each deliverable. This is the person responsible for the final sign-off and acceptance of the deliverable. The deliverable should not be marked as closed unless it has been signed off by the owner.

Baseline Completion Date

In order to track progress, it is important to capture a target date for each deliverable. This will then allow the tracker to be filtered to highlight those that are past the due date so that action can be taken.

Actual Completion Date

This will capture when the deliverable has been completed. This is important so as to provide an audit trail if any questions come up in the future.

Deliverable Status

This field allows for progress to be captured. For example, it is good to know that the deliverable has been started as this will give more confidence that it will be completed by the required date. Likewise, it will allow for reports to be generated where deliverables have not been started but due in next 4 weeks, they may need attention.

RAG Status

This can be used to indicate if the deliverable is on track or not. While this is similar to Deliverable Status, it is useful for providing simple reports where each deliverable can be shown with the RAG status. Then the ones that are Red can be prioritised.


Using the above to construct a Deliverable Tracker will help you monitor progress and allow analysis of data to focus on exceptions. It is also a good idea to consider developing exception reports that are generated on a regular basis to send to the different owners. This helps propmt action by effectively delivering a “to do” list to each area.