Technical Writing – What Is A Business Case

At some point every technical writer will be asked to create a business case for a project, but it’s often unclear what a business case should consist of. Here are some simple steps for determining what a business case is and when it should be used.
Why Write a Business Case?
There are lots of ideas floating around a company at any one point in time, in terms of how to improve the organisation and/or its products and services. In order to sensibly evaluate these ideas, you need a business case to outline:
The costs and the returns
The work required to implement the idea
The overall benefits of implementation
The risks involved in implementation and how they can be minimised
This means that you have spent some time looking at the project and evaluating it, to the point where it can be considered to be a practical idea and not just blue sky thinking. It also enables decision makers to understand your proposal and act on it (or not).
What are the roles played by a business case?
Firstly to understand how the business will function both with and without implementing the project/solution.
Secondly to enable leadership decisions geared to implementing your project and having it prioritised amongst existing and other upcoming projects.
Finally it is to enable you to deliver a consistent message about your project across the company to all audiences as you move further towards implementation.
Who should write your business case?
Ideally a business case should be developed by the team proposing the project, however if the skills to write one are not available within the team, you should engage a technical author to work with the team to develop the business case with the input of the team.
When should it be written?
There’s no bad time to develop this kind of document, but the best time to write one is prior to commencing a project so that everyone understands the objectives and can work towards them. There’s nothing wrong with treating the business case as a “live document” and amending or enhancing it as you move through the project and your understanding of the benefits and risks grows.
How should it be written?
Your main objective is to receive a green light for your project and the commensurate investment to get it going so you should:
Keep it Interesting – Don’t forget your document will be read by people not machines
Keep it Simple and Clear – As above
Lose Jargon and Conjecture – If something is uncertain it’s not much of a case is it?
Tell the Whole Story – Show your research and analysis as well as the final “why we should do it”.
Have a Recommendation – This is where it ends, you should have an idea of what happens next.
Show Value – First and foremost your project should have a tangible measurable return on investment, but don’t be scared of including other less measurable benefits too.