A good idea and a good business case are not the same thing. Every organisation has a graveyard of proposals that had genuine merit but did not get approved, and a smaller collection of things that got funded that probably should not have. The difference is rarely in the underlying idea. It is in how the case was made.
Writing a business case that gets approved is not about advocacy. It is about answering the questions the decision maker has, in the order they have them, clearly enough that a yes is easier than a no.
Here is how to do that.
Start with the problem, not the solution
The most common structural mistake in a business case is leading with the proposed solution. The writer knows what they want to do and they are excited about it, so they start there.
Decision makers do not start there. They start with the problem. Before they will consider any solution, they need to be convinced that the problem is real, that it is significant, and that it is worth the organisation's attention right now rather than later.
Open the business case by making the case for the problem. Describe it specifically. Quantify it where you can, in terms of cost, time, customer impact or risk. Establish why it matters and why it matters now. If the reader is not convinced by the problem statement, they will not be open to the solution.
Be honest about the options
A business case that presents one option and argues for it is advocacy. A business case that presents a genuine range of options and recommends one is analysis. Decision makers trust the second kind more, and they are right to.
The options section does not need to be exhaustive. Three is usually enough: do nothing, a scaled-down version of the proposed approach, and the full proposal. Each option should be assessed against the same criteria: cost, time, risk, and the degree to which it addresses the problem.
The do nothing option is the most important one to treat honestly. If the cost of doing nothing is low, that is information the decision maker needs. If it is high, making that explicit is one of the strongest arguments for action.
Build the financial case carefully
Numbers give decision makers something concrete to test. They also give them something to challenge, which is why numbers in business cases often get gamed. Optimistic assumptions, selective cost inclusions, benefits that are counted twice.
Decision makers who have been around long enough have seen this enough times that they apply a mental discount to the financial projections in any business case. The way to overcome that discount is to build the numbers carefully and show your working.
State the assumptions clearly. Note where the estimates are less certain and why. Present a base case and a conservative case rather than a single projection. The business case that acknowledges its own uncertainty is more credible than one that presents a single confident number.
The benefits need to be specific. Not "improved efficiency" but "reduction in processing time from four days to one day, across a volume of 200 transactions per month, equating to approximately 1.5 FTE of capacity." Not "better customer experience" but "reduction in complaint rate from 8 percent to a target of 3 percent, based on comparable implementations."
Soft benefits are real but they are not sufficient on their own. Every business case should have at least one hard financial benefit, even if it is a rough estimate.
Address the risks directly
A business case that does not address risk looks naive or dishonest. Decision makers will identify the risks themselves; the question is whether you got there first.
List the key risks, assess their likelihood and potential impact, and describe what will be done to manage them. This does not need to be a comprehensive risk register. Four to six material risks, honestly assessed, is usually enough.
The risk section is also where to address the implementation risk specifically. Most proposals are rejected not because the idea is bad but because the decision maker is not confident the organisation can execute it. If there is a credible plan for delivery, including who is responsible, what the timeline looks like, and what the key dependencies are, say so here.
Write for the reader, not the writer
The final check before submitting any business case is to read it as the decision maker, not as the author.
What does this person care about most? What objections will they have? What information do they need that is not yet in the document? Is the recommendation clear? Is the ask specific?
A business case should end with a clear recommendation and a clear ask. Not "we recommend further exploration of this option" but "we recommend approving the investment of $X to deliver Y by Z, and are seeking board approval to proceed." Vague recommendations produce vague decisions.
The decision maker's job is to make a call. Make it easy for them.