Project Business Case
A well-crafted business case explores all feasible solutions to an opportunity or problem and enables business owners to select the option that best serves their organisation. This guide suggests the content of a business case document and what is involved in its preparation.
Success in the project world is the right project done right. The business case is about identifying the right project. It provides the justification for committing resources and provides the answer to the question “Why should we do it?” The business case is the foundation on which our projects rest. It states why the work of a project is worth doing and is therefore vital in ensuring that the project cost, time and risk is justified.
The project business case is the single most important document in a project. A project charter describes what needs to be done, formally appoints the project manager and authorises project planning to proceed. The project plan explains how we are going to do it. The business case gives the reasons why.
It is important to identify the audience for our business case, so that we can work out how best to ‘sell’ our proposal. The audience is the person or people who need to support or approve it. Sometimes this means our business case needs to be written for several audiences as there may be multiple levels required to support or endorse it. Once we have established who the audience is, useful questions to ask are:
- Does this person understand the background to our project proposal?
- What information will this person be looking for?
- What impact would our project have on this person?
- How could this person influence project approval?
- What does this person need to know to support or endorse our project?
Keep in mind that, although there may be a number of people who will read our business case, we only write it once. This means that our business case will need to be written in a way that will ensure everyone who reads it can understand it. The language we use will need to be understood clearly by all those who will need to read it. This means that we should minimise the amount of jargon and acronyms we use and ensure that the terms we do use are clearly defined within the document. Ensure too that the assumptions we make are reasonable and clearly expressed. If readers need to refer to documents outside of the business case, make sure that those documents are accessible for those who will need to read the business case. If need be, include essential documents as attachments to the business case.
Avoid exaggerating costs, risks, benefits or causal relationships to the point where the audience does not believe them. As soon as our readers start to say to themselves “I think that’s stretching things a bit” or “I don’t really see the connection here” the business case has become less ineffective.
Although a group of people may have contributed to the development of the business case, it is important for consistency that only one person does the actual writing. However, sharing drafts with others is a good way to test the arguments contained within our business case and get buy-in. If they cannot understand the business case or are not persuaded by it, the person who is to endorse it may not either.
While the business case may be prepared by a business analyst or project sponsor, we project managers also need to understand it – it’s the rationale for our project. As project managers we need to appreciate that our management of the project can help or hinder the achievement of business case benefits. However, the majority of unsuccessful projects fail not because of poor project management, but because of poor decisions with respect to the choice of projects. A good business case helps us make the right decision and avoid waste.
It is helpful if the prospective project manager is involved in the preparation of the business case. We will then better understand the rationale for our project and help ensure that it is realistic, since sponsors who are very keen for their projects to proceed might forecast overly optimistic benefits, play down risks, and underestimate costs to create for us an impossible challenge.
A good business case captures and documents the reasons for starting a new project and helps us determine whether or not the project investment is justified. If we cannot demonstrate the project’s value our project is unlikely to be approved.
There is a fallacy that a business case is a thick tedious manuscript, written by professional consultants in an incomprehensible language, printed on high-quality paper and placed on the top shelf in an executive’s office to be used as a breeding ground for dust bunnies. This is not a business case; this is a disaster.
A business case is a communication tool, composed in a language that the target audience understands and with enough detail to facilitate decision-making. There’s no magic formula when it comes to the size and construction of a business case, although a common format for our organisation should help us compare, select and prioritise our various project propositions.
What is most relevant is that the business case provides all the necessary information to make the job of the decision maker possible. Also, a business case does not have to be a written document. It could be in the form of a verbal message, but the structure and the content is, nevertheless, much the same as if it were written. The chances are that if it is written, we will have edited and proofread it to ensure its effectiveness and have an agreed basis for its periodic review and updating as circumstances change.
Short-term actions leading to immediate, measurable and substantial benefits are generally the easiest to argue and most persuasive. However, even long-term projects with effects that are initially detrimental to the bottom line can be in our organisation’s best interests. Investments in employee health and wellbeing, for example, can be costly in the short term and, as such, may not be considered in times of economic stress. However, over the long term, such investments may pay off with decreased absenteeism, better retention, greater engagement and productivity – all of which should contribute to the organisation’s efficiency or bottom line.
Similarly, activities that can initially seem to have a positive effect on finances can be detrimental later on. For example, encouraging salaried employees to work overtime rather than hiring more people or outsourcing work may be profitable in the short term, but the longer hours involved may lead to employee burn-out, less productivity and more absenteeism. As a result, a project that was originally profitable can end up costing money.
Essentially the business case defines the problem, checks to see that the project aligns with the organisation’s strategic plan, identifies and evaluates alternative solutions and performs a Cost Benefit Analysis (CBA) for the proposed solution or most promising solutions. The business case should be:
- Adaptable – tailored to the size and risk of the project proposal
- Consistent – the same basic business issues are addressed on each occasion
- Business oriented – concerned with the business value, rather technical focus
- Comprehensive – includes all factors relevant to a complete evaluation
- Understandable – contents meet a one-read clarity requirement
- Measurable – all key aspects can be quantified so their achievement can be tracked and measured, which means figures in preference to adjectives and adverbs
- Accountable – accountabilities for the delivery of benefits and management of costs are clear.
Once approval for a project is given and a project charter prepared, the business case becomes dynamic and is updated as the project proceeds. We need to ensure that the justification is still valid and the project will deliver the solution to the business need. The result of the periodic business case review may be to confirm, terminate or amend the project.
Our NZ Government has recently adopted a standardised business case template used by the UK Government and known as ‘Better Business Cases for Capital Proposals.’ Check here for a short PowerPoint explanation. This Five Case Model is designed to provide explicit assurance to Ministers, stakeholders and business case assessors that the proposed investment:
- is supported by a robust case for change, the ‘strategic case’
- maximises value-for-money, the ‘economic case’
- is commercially viable, the ‘commercial case’
- is financially affordable, the ‘financial case’
- is achievable, the ‘management case’.
The following example template is not configured in this manner, but does address all relevant issues.
Possible Business Case Template
A written business case usually has a title page, approvals, distribution, an amendment record since it is a ‘living document’ subject to amendment as circumstances change, and a content’s page(s). A larger business case usually starts with a summary:
Although the summary appears first, it is written last when we know what we are summarising. Typically included here are:
- The problem or opportunity the project seeks to address.
- The project goal.
- How the project goal aligns with the organisation’s strategic priorities.
- Key assumptions on which the business case is based.
- The results of the financial and non-financial analyses.
- An assessment of the achievability of the project (capability, affordability, riskiness etc).
- Main conclusions and recommendations.
Describe here the problem or opportunity the project seeks to address, examples being:
- Change in legislation requires action.
- Current technology is outdated and not meeting needs.
- Service levels are low, resulting in frequent customer complaints.
- Demand for products or services is increasing.
- Opportunity to generate revenue, cuts costs, or deliver some other benefit.
Here we clearly and concisely state the project goal applying “SMART” criteria.
We need to describe how the proposed project supports organisational priorities with reference to the organisation’s core values, mission or purpose, longer-term strategic plan and annual business plan. We explain too why the project is important and sometimes it is very persuasive to mention the consequences of NOT doing the project.
We need to briefly explain the method used to evaluate the project proposition.
We summarise here the scope of the business case (ie, what’s included and excluded), but NOT the scope of the proposed project.
Assumptions and Constraints
An assumption is a circumstance or event outside the control of the project that can affect its success, and constraints are restrictions or boundaries that limit our options. Some assumptions might be that material needs will not change, implementation can be completed in one month, and required contractors will be available. Constraints might be the availability of expertise and equipment and need to adhere to national standards, completion date and budget.
Data Sources and Analysis
Here we outline how the data presented in this business case was gathered and analysed.
Because a business case supports decision-making, we must identify measurable criteria used for comparing viable options and recommending a certain course of action. Such criteria might be financial (ROI, NPV, IRR, payback period, etc) and non-financial (employee morale, motivation, organisational reputation etc). Examples are:
- The recommended project will have a payback period of three years or less.
- The recommended project will reduce customer waiting times by 50%.
- The recommended option will improve customer satisfaction by 25%.
- The recommended option will improve worker productivity by 20%.
- The recommended option will improve our organisation’s reputation.
Now we describe the viable options we have identified to achieve the project goal. Some options might be:
- Base case: no changes are made to current situation.
- Minimum functionality: the minimum features and functions the project deliverable could possess to address the problem / opportunity.
- Maximum functionality: the maximum features and functions the project deliverable could possess to address the problem / opportunity.
- Collaboration: ways in which project costs could be shared with other public or private organisations.
- Make or buy: the pros and cons of making the product or service versus purchasing an off-the-shelf solution.
- Pace: the pros and cons of completing the project quickly versus completing the project in increments over a longer period of time.
Here is another example. If we needed extra living space, some possible options might be:
- No change – the “do nothing” option.
- Move to a larger house.Build an extension on side of the existing house.
- Grow into the roof space.
- Adapt the existing room layout.
We should not even consider this project unless we anticipate gaining some benefits from it. This may be increased living space, increased re-sale value of the property, or delaying the requirement to move. Each of these benefits should have a quantifiable value attached to them so that we can keep track of what we hope to achieve. Of course we can’t be sure that these benefits are accurate, after all they are a prediction of the future, but they are an indicator that we can use constantly to check whether the benefits will outweigh the costs. And there are always likely to be some downsides to doing any project, and these are sometimes labeled ‘disbenefits.’ For example, if we extend the house, then there may be temporary dirt and disruption.
This is probably the most important part of our business case as it is often the costs or savings a project promises that win final approval. It is important to quantify the financial benefits of the project as much as possible. This is usually done in the form of a Cost Benefit Analysis (CBA). The purpose of this financial tool is to illustrate the costs of the project and compare them with the benefits and savings to determine if the project is worth pursuing. The analysis of options always considers financial impacts and usually non-financial impacts:
- Financial Impacts. Common measures used include cash flow, payback period, return on investment (ROI), discounted cash flow (DCF), net present value (NPV) and internal rate of return (IRR).
- Non-Financial Impacts. These will contribute to our strategic priorities and business objectives but cannot easily be assigned dollar values for lower costs or increased revenues. Examples might include employee health, morale, retention, customer satisfaction, and improved reputation.
Sensitivity and Risk
This section provides information on the following:
- Sensitivity. Which assumptions are most important to achieving benefits?
- Risks. What is the likelihood and impact of things that could diminish or enhance benefits?
Evaluation of Options
This section provides an evaluation of viable options against weighted decision-making criteria. A decision-matrix is generally prepared.
Achievability and Capability
Here we address factors such as:
- An assessment of our organisation’s capability to complete the project.
- How the project should be governed and managed.
- A high-level timeline for the project.
- An explanation of how risks will be managed.
- Availability of funding for the project.
And does our organisation have the needed skills and experience to execute this project successfully? In particular:
- Are enough people with the required skills and experience available to execute this project successfully?
- Has the organisation successfully completed similar projects in the past?
- For outsourced projects, are there contractors available to complete the project, do these contractors have experience delivering similar projects successfully, and how will their procurement be managed?
If procurement is required to complete the project, briefly explain here how the procurement process will be managed and how contracts will be negotiated and managed once contractors are selected.
Governance and Management
Identify the project sponsor, project manager and composition of the steering Committee if established.
How long the project is expected to take and what project phases and milestones would apply.
Her we list the risks identified to date, estimate their impact and probability, and recommend responses. A risk is something that may or may not occur in the future and that can have an impact on the success of the project. A risk concerns uncertainty and therefore might be a threat or an opportunity.
Do not include things that have a 100% chance of happening or that have already happened: these are issues, not risks. A good risk event statement includes what might happen and its effect on a project. For example, “weather” is not a risk event statement. “Bad weather may delay project completion” is a risk event statement.
Here we comment on available funding for the project, and we should answer the following questions:
- Is a budget currently available for this project?
- If no budget is available, how can finance be obtained?
- If there are budget limitations, are there ways to reduce the scope or perhaps extend the timeline to reduce costs this year and still achieve meaningful results?
Conclusions and Recommendations
Here we list the key findings of our business case and our recommendations. The recommendation for implementation is usually a brief restatement of the cost-benefit analysis results and a statement that we believe the project should go ahead. If there is any question as to the availability of key resources, make that clear.
Because every project is different, some of the elements mentioned above may not always be applicable. Also, once completed we might step away from the document, put it away and return later with fresh eyes. Finally, have at least one other person whose opinion we respect proofread the document.