How to Write a Business Case
Tuesday, November 26, 2013
You've got some great ideas for improving the way your department delivers what's required of it.
But how do you get approval for your projects to go ahead?
And how do you ensure that you receive the resources you need to complete them successfully?
The answer is this: by creating a proper business case document. In formal projects, a business case is the main deliverable from the Strategy and Business Case Project Phase . It's one of the key documents that senior managers review when deciding whether to give a project the funding it needs to go ahead. In the business case, you detail the benefits that the project will deliver, how they'll be achieved, what it will cost, and how long it will take.
There are a number of other benefits that come from writing a business case:
You have to be specific about what your project will achieve, all in a single document, so this encourages you to think the project through and record your key assumptions.
It provides a project baseline, against which you can track scope, cost, time lines, and the delivery of benefits.
It gives you with an opportunity, right at the start of the project, to ensure that all of your stakeholders understand what you're delivering (and not delivering) and recognize any responsibilities and obligations they have in supporting the project.
To get the biggest advantage from this, think about how you can get your most important stakeholders involved. For example, you could consult with them before you put the business case together – or, alternatively, you could get their input when writing your business case, and get their feedback on early drafts.
Several of the articles within the Building Support for Your Projects section of our Project Management area will help you here. In particular, look at our articles on Working with Project Sponsors , Stakeholder Analysis , Stakeholder Management , the RACI Matrix and Influence Maps .
How to Use the Tool
Each business case should include several core components. The level of detail needed within your document will depend on the stage that the project is at, and on the level of complexity and investment required in the project. For example, in a complex project, you may need to submit an initial business case to seek approval of the project in principle. This would then lead to the release of preliminary funding, so that the project manager can produce a full business case, with a detailed analysis of scope, costs, and benefits. Approval of this detailed business case would then release funding for the project to be implemented in full.
On the other hand, a project to change an existing standalone IT system to deliver a legal requirement may be quick to implement, because it's self-contained, and has minimal impact. In this case, the business case may be only a few pages long.
Tip:
Most organizations have a rigorous, careful process for allocating funds to projects. They may also have a set of priorities or considerations against which projects are assessed. Investigate the templates and guidelines available within your organization before you start writing your business case.
In particular, explore whether there's a template that you must use (and which parts of this are mandatory or optional). Identify who approves business cases for the level of investment that your project requires, and determine the assessment criteria for project approval.
The core business case components are as follows:
Management summary – Here, summarize the key points within each business case section, ideally on one page. You'll write this summary after you've clearly thought through the project proposal in detail, and written the rest of the business case document.
Project background – Identify the issue, opportunity, and business strategy requirements that the proposed project will address. Discuss any other options that you have considered and rejected as potential solutions. Identify any implications of not approving the project. Give information on the key stakeholders who have been involved in developing the project proposition, and explain the work that's already taken place in earlier project phases or in dependent projects.
Objectives – State what the project will deliver using SMART objectives .
Scope – Define what the project will deliver. Be clear about what is in the scope, and what's out of scope. You may find it helpful to list processes or process areas, geographical areas, departments/functions, equipment, systems (remember to state which system interfaces are in scope - this is often forgotten!), or stakeholder groups as a way of being clear about what is in scope.
It's often also useful to state where the project responsibilities will end. For example, the project may be responsible for setting up the initial training of the internal support team. However, the internal support team may then be responsible for training end users as part of their existing "business as usual" responsibilities.
Dependencies – Identify any project dependencies. For example, state clearly if your team is in any way dependent on work from another team to complete the project. Also, be sure to state whether another project relies on something that you're delivering.
Risks – Identify the critical risks within the project. State how you plan to eliminate, reduce or manage these risks , and determine the implications of not doing so. You might also find it helpful to estimate the probability of each risk occurring, or give more detail about the conditions under which you could not effectively reduce the risk.
Costs and resources – Clearly lay out your project budget. In addition, highlight resources that you're depending on, but that don't need cash expenditure. These resources may include things like IT hardware, people, equipment, and rooms that are already available. In these cases, state the amount of these resources that you'll need, and highlight where you expect these resources to come from.
Clearly state any assumptions that support the cost estimates in the business case, as well as any numbers that you've left out. For example, if you've assumed that there's sufficient data storage capacity already available, state this.
Areas that are often forgotten in budgets include expenses for staff who must attend project events (such as workshops or business testing exercises) and extra systems hardware capacity. For example, if an additional server is needed to support testing, but it won't be needed once the project "goes live," it's easy to forget to budget for this.
Managers often have problems getting hold of the resources they need for their projects. This is why it's really important to have key stakeholders give up-front approval, and understand the resources that the project will need.
Benefits – State the benefits that the project will deliver. These should include both qualitative and quantitative benefits.
Milestones – State your project time line. If the project has to be delivered by a certain date to achieve legal or internal deadlines, state this. Also, be clear about the implications of the project starting, or not starting, by a certain date.
Project Evaluation – How projects are evaluated will depend on the organization and its mission. However many organizations will base go/no-go decisions on the project's Internal Rate of Return or Net Present Value, both of which are measures of the return that the project will deliver to the organization once costs have been considered.
Tip:
Just as your organization is likely to have specialized templates for business cases, it's likely to have specialized rules detailing how projects should be evaluated. If appropriate, get help from your finance department to make sure that this part of your business case is correctly structured.
Key Points
The business case is a key document in the initial stages of a project. It details how the project will proceed, and it's the key document that decision-makers need to decide whether to approve and fund your project. As well as this, it sets the baseline for the project's scope, costs, and time lines, which means that it's a key document for determining whether the project is judged as a success or a failure. As such, take care with this document – after all, anything that's wrong, left out or misunderstood could is likely to cause problems later.
As with many of the key project management documents, the business case provides you with an opportunity to engage with your key stakeholders and build support for your project. Make sure that you take best advantage of this opportunity!
Tags:
Project Management, Skills
But how do you get approval for your projects to go ahead?
And how do you ensure that you receive the resources you need to complete them successfully?
The answer is this: by creating a proper business case document. In formal projects, a business case is the main deliverable from the Strategy and Business Case Project Phase . It's one of the key documents that senior managers review when deciding whether to give a project the funding it needs to go ahead. In the business case, you detail the benefits that the project will deliver, how they'll be achieved, what it will cost, and how long it will take.
There are a number of other benefits that come from writing a business case:
You have to be specific about what your project will achieve, all in a single document, so this encourages you to think the project through and record your key assumptions.
It provides a project baseline, against which you can track scope, cost, time lines, and the delivery of benefits.
It gives you with an opportunity, right at the start of the project, to ensure that all of your stakeholders understand what you're delivering (and not delivering) and recognize any responsibilities and obligations they have in supporting the project.
To get the biggest advantage from this, think about how you can get your most important stakeholders involved. For example, you could consult with them before you put the business case together – or, alternatively, you could get their input when writing your business case, and get their feedback on early drafts.
Several of the articles within the Building Support for Your Projects section of our Project Management area will help you here. In particular, look at our articles on Working with Project Sponsors , Stakeholder Analysis , Stakeholder Management , the RACI Matrix and Influence Maps .
How to Use the Tool
Each business case should include several core components. The level of detail needed within your document will depend on the stage that the project is at, and on the level of complexity and investment required in the project. For example, in a complex project, you may need to submit an initial business case to seek approval of the project in principle. This would then lead to the release of preliminary funding, so that the project manager can produce a full business case, with a detailed analysis of scope, costs, and benefits. Approval of this detailed business case would then release funding for the project to be implemented in full.
On the other hand, a project to change an existing standalone IT system to deliver a legal requirement may be quick to implement, because it's self-contained, and has minimal impact. In this case, the business case may be only a few pages long.
Tip:
Most organizations have a rigorous, careful process for allocating funds to projects. They may also have a set of priorities or considerations against which projects are assessed. Investigate the templates and guidelines available within your organization before you start writing your business case.
In particular, explore whether there's a template that you must use (and which parts of this are mandatory or optional). Identify who approves business cases for the level of investment that your project requires, and determine the assessment criteria for project approval.
The core business case components are as follows:
Management summary – Here, summarize the key points within each business case section, ideally on one page. You'll write this summary after you've clearly thought through the project proposal in detail, and written the rest of the business case document.
Project background – Identify the issue, opportunity, and business strategy requirements that the proposed project will address. Discuss any other options that you have considered and rejected as potential solutions. Identify any implications of not approving the project. Give information on the key stakeholders who have been involved in developing the project proposition, and explain the work that's already taken place in earlier project phases or in dependent projects.
Objectives – State what the project will deliver using SMART objectives .
Scope – Define what the project will deliver. Be clear about what is in the scope, and what's out of scope. You may find it helpful to list processes or process areas, geographical areas, departments/functions, equipment, systems (remember to state which system interfaces are in scope - this is often forgotten!), or stakeholder groups as a way of being clear about what is in scope.
It's often also useful to state where the project responsibilities will end. For example, the project may be responsible for setting up the initial training of the internal support team. However, the internal support team may then be responsible for training end users as part of their existing "business as usual" responsibilities.
Dependencies – Identify any project dependencies. For example, state clearly if your team is in any way dependent on work from another team to complete the project. Also, be sure to state whether another project relies on something that you're delivering.
Risks – Identify the critical risks within the project. State how you plan to eliminate, reduce or manage these risks , and determine the implications of not doing so. You might also find it helpful to estimate the probability of each risk occurring, or give more detail about the conditions under which you could not effectively reduce the risk.
Costs and resources – Clearly lay out your project budget. In addition, highlight resources that you're depending on, but that don't need cash expenditure. These resources may include things like IT hardware, people, equipment, and rooms that are already available. In these cases, state the amount of these resources that you'll need, and highlight where you expect these resources to come from.
Clearly state any assumptions that support the cost estimates in the business case, as well as any numbers that you've left out. For example, if you've assumed that there's sufficient data storage capacity already available, state this.
Areas that are often forgotten in budgets include expenses for staff who must attend project events (such as workshops or business testing exercises) and extra systems hardware capacity. For example, if an additional server is needed to support testing, but it won't be needed once the project "goes live," it's easy to forget to budget for this.
Managers often have problems getting hold of the resources they need for their projects. This is why it's really important to have key stakeholders give up-front approval, and understand the resources that the project will need.
Benefits – State the benefits that the project will deliver. These should include both qualitative and quantitative benefits.
Milestones – State your project time line. If the project has to be delivered by a certain date to achieve legal or internal deadlines, state this. Also, be clear about the implications of the project starting, or not starting, by a certain date.
Project Evaluation – How projects are evaluated will depend on the organization and its mission. However many organizations will base go/no-go decisions on the project's Internal Rate of Return or Net Present Value, both of which are measures of the return that the project will deliver to the organization once costs have been considered.
Tip:
Just as your organization is likely to have specialized templates for business cases, it's likely to have specialized rules detailing how projects should be evaluated. If appropriate, get help from your finance department to make sure that this part of your business case is correctly structured.
Key Points
The business case is a key document in the initial stages of a project. It details how the project will proceed, and it's the key document that decision-makers need to decide whether to approve and fund your project. As well as this, it sets the baseline for the project's scope, costs, and time lines, which means that it's a key document for determining whether the project is judged as a success or a failure. As such, take care with this document – after all, anything that's wrong, left out or misunderstood could is likely to cause problems later.
As with many of the key project management documents, the business case provides you with an opportunity to engage with your key stakeholders and build support for your project. Make sure that you take best advantage of this opportunity!
