Writing a business case that sells

By Business Analysis

[responsivevoice_button voice=”UK English Female” buttontext=”Listen to Post”]
Business cases are key to projects in most organizations. A well written business case provides senior management with the information they need to make an informed decision on a project.

One of the key aspects of a business case is to show that you considered several options for the business. We can generate ideas and options through workshops and brainstorming sessions. We can also look at our business process models & business activity models and even what our competitors are doing. From all this, we should try to identify three or four serious options for the business. One of those options should always be to ‘do nothing’ – which will include highlighting the risks and consequences of taking no action. The other options should range from simple (cheap and quick) to complex (expensive with longer time scales), this gives the business a good view of the different ‘stages’ of investment they could make.

So, now we need to present our findings in the business case document. Remember, a business case is a sales document that you hope will lead management to make a particular decision. So, we should seek to stress the benefits of the solution (rather than focusing on the features); sell the benefits before we discuss the cost & highlight the size of the current problem or opportunity.  

The business case is a living document and will change throughout the project. Below, we have each of the project stages & the steps for the business case. Note the decision points. No organization is static, if things change, the business case may no longer be viable, we therefore need to review the case frequently.

The feasibility of the project can be assessed by looking at:

  • Business – strategic fit; market conditions; timeliness; fit with existing architecture; cultural fit; legal / regulatory fit; alignment with existing processes; staff training requirements.
  • Technical – availability; reliability; maintenance (time / cost); performance; scalability; security; fit with existing systems; proven technology.
  • Financial: funding availability; funding sources; ROI.

ROI can be calculated via the Payback calculation. Whereby we work out the breakeven point, like in the below. This is a simple model and doesn’t model the real value of money over time, the lost bank interest or the interest that may be paid on any loans taken out to finance the project. We can combat this by using a DCF (Discounted Cash Flow) which generates an NPV (Net Present Value) by assessing how we think the markets will change over time (e.g. likely interest rate increases). This is done by management accountants.

We can also assess feasibility using PESTLE (as discussed here) or the Force field analysis whereby we look at the forces inside and outside of organization that can impact the adoption of a solution.

The actual business case should include

  • Executive summary: a high level review of the problem, the solutions considered and the recommendations. Short overview (a few paragraphs).
  • Current situation / problems: what are the problems and opportunities? Again, this section should be short and sweet.
  • Options considered to resolve problems: What were the options? Why did we reject the options that we rejected?.
  • Cost / benefit analysis: best practice is to present benefits before we go into the costs. Benefits can be tangible (£££) or intangible (e.g. customer satisfaction or staff morale). We can use the below model to think about the costs/benefits.

We can use assumptions (e.g. 10% reduction in overtime costs if XXX is achieved, but these need to be plausible to ensure we do not undermine the credibility of our business case.

  • Impact assessment: where else in the organization is going to be impacted by your change? E.g. changes in working practices; cross-business-unit processes, etc… these impacts may also incur a cost.
  • Risk assessment: a simple risk assessment highlighting what the risk is, the likelihood that it’ll happen, what we can do to mitigate the risk and who owns the risk.
  • Recommendations: a clear overview of the recommended solution, including a high level timeline (Gantt chart).

We should create a RAID / CARDI document at a high level during this process & attach it as an appendix. CARDI stands for: Constraints; Assumptions; Risks; Dependencies; Issues and RAID stands for Risks; Assumptions; Issues & Dependencies. Which one you use may depend on what is the standard in your organization.

 

Content based on study of the BCS Business Analysis course – Business Analysis 3rd Edition (Debra Paul, James Cadle and Donald Yeates).