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)?
The 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
