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?“.

 

 

PMO Business Case Review Checklist (plus free template checklist download)

For any project to have a chance for success, it is important to start with a solid foundation. A key part of this is to have a robust business case that has been agreed, and signed off by the sponsor(s). For more information on why this is important view post 5 reasons why a project should have a business case (you may also want to take a look at the post Why sponsors do not want their project to have a business case).

Example of PMO Business Case Review Checklist

The reason for the business case is to ensure that the project has been though through and a credible case developed that makes sense. This means the business case should have a good idea what will be done, the cost, the benefits and if it can be achieved.

A PMO can play a valuable role in helping to ensure that the business case is robust by performing reviews ahead of any formal review and sign-off. This is a worthwhile exercise as it helps improve the quality of the case. The project manager should view this as a positive as opposed to a hindrance as it is far better to catch potential issues in a less formal review so that changes can be made to give the case a better chance of approval.

This review can be greatly assisted by using a checklist. This will help to ensure that important areas are considered. While not an exhaustive list, areas for consideration include:

Alignment to strategy

Resource, time and budget are typically scarce. Therefore, they should only be invested on business cases that help move an organisation in the required direction.

Solution

There must be confidence that the solution has been considered and that it can be clearly explained.

Risk

Very important. How much risk is in the solution? A business case with a high payback but very high risk may not be delivered. Understanding the risk is an important part of the decision.

Buy-in

It does not matter how compelling and good the business case is, without “buy-in” the project is destined to failure.

Resources

Projects are delivered by people. So a check must be made that resources will be made available and that they have the required skills.

Budget

A project will need investment. The budget must be agreed and allocated if the project is to deliver to agreed timelines. Slow budget approval can seriously damage progression.

Return on Investment (benefits)

Most business cases, unless they are mandatory / regulatory type changes, should have some form of benefits. These must be clearly defined to allow a considered investment decision.

Technology

Most projects involve some form of technology change. It is important to understand what technology will be used, if it is new or established, hardware requirements, etc. New untested technology can be very high risk.

Summary

The above checklist gives some ideas on areas of the business case that should be tested. This is not an exhaustive list and you should add other areas applicable to your organisation. The aim is to conduct a thorough review to help improve the business case.

Free PMO / Project Business Case Review Checklist

You can download a free checklist template that you can update and use. It does contain a number of questions you may wish to ask against each of the headings listed above.

Download Free PMO Business Case Checklist TemplateIf you find it useful please can you share your appreciation by using the social media links on this page.

PMO closure checklist

Closed signWhen a project comes to an end, one of the steps will be to close the PMO supporting the project. The reason being that the services are no longer required and the resources can deliver more value by being redeployed.

In the same way that there is a process for project closure, the same applies for a PMO. It is important that the closure is conducted in a structured way.
Below is a checklist of key steps that should form part of the PMO closure.

1. Resource Management

This is the most important item. There must be a defined approach for the roll-off of resources from the PMO. It is rare for the entire PMO team to finish on the same day. What typically happens is that the team reduces over a period of time. This is logical as the requirements from the project should also be reducing as it nears closure.

The plan can be a simple table listing each resource, their role and planned roll-off. For contractors, it is helpful to include the contract end date as this may influence when a resource is rolled-off.

As part of the planning, it is important to consider the skills and knowledge for each resource. There will be resources that it is important to retain for the benefit of the organization. Therefore, those resources must be identified and action taken to find new roles to retain the knowledge. Important: do not wait until the PMO closure to think about how the resources will be deployed as it normally takes some time to reallocate resources. It is also important to let people know that you wish to retain them, especially if they have important skills, otherwise they may find a new role themselves outside of the organization.

2. PMO Review

The project closure process aims to collect what went well and what could have been done better. The same applies to the PMO. A review should be completed on what went well with the aim that the other PMO’s in the organization can benefit.

In a similar way, what did not go well should be understood. The aim being that other PMO’s can make changes and improve the outcomes.

3. Knowledge Transfer

Linked closely to the PMO Review, it is important that knowledge is transferred and retained by the organization. This helps maximize the benefit from the investment.

The PMO may have developed templates, processes, presentations, Sharepoints, etc. This information should be stored in a way that makes it accessible to other PMO’s. A readymade set of PMO templates and processes will help speed up the mobilization of other PMO’s.

4. House Keeping

This means making sure that all outstanding items are either closed or transferred. For example, it is good practice to make sure that all projects are closed (i.e. risks, issues, dependencies, milestones, change controls, etc). Final status reports completed and project officially closed.

It maybe that there are still outstanding benefits to be realized from the project. Therefore, arrangements need to be made to transfer the tracking to ensure that they are not forgotten and the benefits are realized.

Summary

The above provides a number of key points that need to be considered when closing a PMO. By having a structured approach it should help ensure that key resources and knowledge are retained.