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!

Overview

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.

Header

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

Project Book of Work Header tab

Instructions

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

Static

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.

Summary

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.

Review

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.

Summary

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.

ID

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.

Priority

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.

Location

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.

Comments

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

Summary

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:

Visitors

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.

Dependencies

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.

Decisions

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.

Conclusion

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.

Overview

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.

Description

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.

Owner

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.

Summary

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.

How to know the project is done! Hint: Deliverable Tracker

How would you answer the following question from the project sponsor:

“How do I know the project is done?”

This is a very interesting question as what the project sponsor is really asking is:

“Have the required project outcomes been delivered?”

Project manager thinking if project is completeThe answer is important as the sponsor has typically committed valuable resources (budget, people and time) to achieve a result. Therefore, the sponsor is fully in their right to expect a positive response.

Take a moment to think about your current project or programme and, if this question fills your with fear, panic or simply makes you feel uneasy, the following 4 principles can help.

1.Clear scope and outcomes

While this may sound obvious, there are many active projects that do not have clearly defined scope. Even more do not have a clearly defined outcomes.

Understanding both is critical for the project manager. Without knowing the scope and the required outcome, how can the project manager define and direct the work to achieve the required result? Answer: they cannot.

So by not having this clear understanding, the project manager is putting them self at a disadvantage before they have really started. Not the way I would choose to start a project.

At the start of any piece of work, make sure you take time to capture the scope and required outcomes. Keep asking questions until you and the team are clear as it is far better to remove ambiguities at the start.

2. Document scope and outcomes

If you have completed step1, good work. Now you must document the scope and deliverables in a clear and concise format that can be understood by all stakeholders. Remember, it is easy for misinterpretation of the written word. Therefore, ask for peer reviews to ensure that the document is clear.

Ideally the outcomes will describe each important deliverable and the metrics that will be used to measure if they are complete. Agreeing these at the start of the project is far easier than waiting until the end of the project.

3. Agree scope and outcomes

It is important not to assume that just because you have created a document that the sponsor has read and understand the detail. Therefore, it is advisable to set up a review session with the sponsor and any other stakeholder to walk them through the key points on scope and outcomes. Taking this step will help ensure a common understanding and will allow misunderstandings to be resolved. Make sure that the document is updated to reflect any changes.

At the end of the session, ensure that all parties formally acknowledge and agree the scope and outcomes. This signed off document will then act as the baseline for the project manager to deliver the work. It also means that the project manager has got a reference to validate the deliverables as they are completed.

4. Track progress

Having spent time agreeing the outcomes (deliverables), it is important to track progress. Regular reporting will assist. However, to ensure a robust process, outcomes should be translated into milestones and a deliverable log should be created.

This will allow for progress against each deliverable to be tracked and will highlight where deliverables are late or missed. There can even be an independent process to assure each deliverable and a standard method for storage. This ensures that all the deliverables can be found at the end of the project.

For details on the data points and fields you should include in a Deliverable Tracker, visit the post, Project Deliverable Tracker (the fields you need).

Summary

The purpose of a project is to achieve an outcome. Scope will help define the outcome and ensuring that the scope and outcomes are clear, documented, agreed and tracked will help ensure that they are achieved.

What is one of the biggest frustrations with a PMO?

The project fire drill 4 step action planIf you were to ask people involved in project and change management what is one of their biggest frustrations when it comes to a project management office, what do you think their answer would be?

The most precious commodity to most project teams is time. This means that it must be used extremely wisely. So for this reason, most project teams dread and loathe “project fire drills”!

What is a “project fire drill”?

Just in case you are new to the project world and have not heard of the term “fire drill”. This is the name used to describe a piece of unplanned work, usually with an unreasonable deadline in a response to a request (usually senior management). For those who have been involved in projects, even if only a short time, you probably have been impacted by at least one.

How can a PMO help ease the pain of a “project fire drill”?

A good PMO will always be looking for opportunities to help and support the projects that they support. The following 4 tips are methods a PMO can provide value and help ease the burden on the project team.

  1. Push back

The best way of stopping the impact is by pushing back on the person / area making the request. It is unfortunate that many PMO’s simply accept the request and feel obligated that it must be actioned.

When you receive a request, ask some simple questions to understand the reason for the request, the required outcome, importance, etc. Use the questions to assess if the request makes sense and if it makes sense. From the questions you may identify that the request does not meet the required outcome. It may even be irrelevant.

If this is the case, explain the concerns to the requester and try to get the request stopped. Word of warning, the requester may be simply acting on behalf of senior management so you will need to help provide them with logical arguments to help them to push back or, at a minimum seek further clarification.

  1. Service request centrally

The PMO should be the hub for project information. Therefore, if the request is reasonable, it is highly likely that the PMO can service the majority, if not all of the request from the data they hold.

If this is the situation, the PMO should populate as much of the request as possible and then send on to the project manager (or appropriate person to finalise).

Important: even if you can provide all of the information, make sure you provide this to the project manager to review and sign-off. Even if they trust you, make sure they are aware of the request and what you propose to submit.

  1. Early messaging

Project people like to plan and avoid nasty surprises – like “fire drills”. If are warned that a request will be coming, try to brief the project teams so that they are aware. While “fire drills” are typically unannounced and out of the blue, sometimes a PMO may start to pick up on themes emerging that may result in requests being made.

As soon as you are aware or sense a theme, communicate to the project teams. This must be done in a structured way as you do not want the teams to rush off and take action before the full details of the request are available.

  1. Consistent messaging

When a request has been made, it is important that there is consistent messaging from all team members. If a deadline has been set for submissions, make sure that all team members communicate the same timeline. It is not helpful if different deadlines are being communicated. This will confuse people and make them not trust the dates being set. This will typically result in missed deadlines.

Make sure that all teams are clear on what is expected. Publish clear guidance as this will help the teams respond. This is all linked to the theme of trying to add value and help ease the pain on the project teams. Do not simply forward the request to the project teams without reviewing and providing clarity.

Summary

It will never be possible to eliminate “project fire drills”.   So the next best thing is to have an established method to deal with the requests. The 4 steps listed above are a good base to form your own plan that will mean that you and your PMO will provide more value to your organisation.

Checklist for rolling out a PMO process

Roll out checklistThe PMO is responsible for ensuring that PMO processes and templates are being used across each project and / or programme within their scope.  This helps ensure standardisation that in turn should help improve the management and monitoring.

A PMO can invest a lot of time and effort in designing and developing a new process.  However, if it is not used correctly (or even not at all), the return on the investment of time is minimal.  Therefore, the process of rolling out a new PMO process does need planning if it is going to be effective.

Below is a check list of what should be considered to achieve a successful rollout of a new process.

1.Confirm objective and need

This is very important.  You should only look to develop and implement a new or updated process if there is a clear objective and need.  If not you may invest time and effort in a process that will not be used as it will be seen as being bureaucratic.  This is not a good use of anyone’s time nor will it reflect well on your PMO.

When you are clear on the problem being solved.  It is worth testing the concept with friendly stakeholders across the project.  This will allow for validation and refinement.

2. Advance warning

This step may not always be possible.

Where possible, provide advance warning to the stakeholders across the projects that the new or changed process is coming.  This will help when it comes the time to rollout the process.  It also gives people an opportunity to raise any early concerns.  This may be a very useful source of challenges across the project that the new process will help address.

Capturing these and incorporating them into the design will help ensure the process provides value.  It also helps avoid a lot of re-work at the time of rollout.

You will also find that there will be stakeholders who will ask to be involved in the design phase.  This is good as it provides you with the people to help in any pilots.

3. Develop PMO process and template

With the objective and need, you can start work on developing the process and any templates.  The aim is to keep the process simple and to avoid adding any step or data point that is not needed.

Review the process and template against the original objectives to make sure it addresses the need.  Again, test the proposal with friendly stakeholders and amend as appropriate.

4. Schedule communication and training sessions

Before you rollout the new processes and templates, take time to develop training material and training sessions with the people who will need to use the new process.  This will build on the advance communication and help ensure that all users understand:

  • Objectives and need
  • Overview of the process and supporting templates
  • How and when they should be used
  • Opportunity to ask questions
  • Timeline for rollout

5. Rollout PMO process and templates

This is the last step.  If all of the previous steps have been followed it should not be a surprise and should be fit for purpose.

The rollout should clearly communicate when the new process should start to be used and what support is available.

All process, templates and training material should be made available.

6. Continuous improvement

When a new process is implemented, it is common that adjustments will need to be made.  Make sure the users know how to provide feedback.  It is also a good idea to set a period where you will gather feedback and then make changes and issue a consolidated update as opposed to re-acting to each item and issuing multiple revisions.

Summary

Following the steps above will provide a solid framework for rolling out processes and templates for your PMO.  You can find additional information in the post on “Are your processes embedded and BAU?“.