How to Write a Business Case With Credible ROI

Knowing how to write a business case that finance and executives will trust is a career skill, because the same project can be approved or rejected depending on how its case is built. A credible business case is not the one with the highest ROI. It is the one whose assumptions are visible, whose numbers can be traced, whose risks are acknowledged and whose request is clear. This guide sets out a structure for a business case, explains how to frame options, how to build the cost and benefit estimates, how to show scenarios and weight them with checked arithmetic, what reviewers look for and the habits that undermine credibility. It is part of business analytics for finance and operations, follows the ROI calculator template and how to track ROI across departments, and leads to cost-benefit analysis and the ROI formula. Approved business cases flow into the plan in budgeting and forecasting.

The structure

A business case can be as short as two pages for a modest request. A reliable structure has eight parts.

1. Executive summary. The request, the benefit, the cost and the recommendation in one paragraph. Many readers will read only this.
2. The problem or opportunity. What is wrong or possible, with evidence. Give numbers: how often errors occur, what they cost, how large the opportunity is.
3. Options considered. At least three: do nothing, a minimal option and the recommended option. Explain why alternatives were rejected.
4. The recommendation. What will be done, by whom and by when.
5. Costs and benefits. One-time and recurring costs, benefits by type, the period, and results: ROI, payback and NPV.
6. Risks and assumptions. What could go wrong, how likely, what you will do and which assumptions the result depends on most.
7. Implementation plan. Milestones, resources, dependencies, and how success will be measured.
8. The decision requested. Exactly what you are asking for, such as approval of $85,000 and two people for six months.

Start with the problem, not the solution

Business cases that begin with a product tend to read as a sales pitch. Begin by establishing that a problem is worth solving. Quantify it from your own data. "Planning takes too long" is a complaint; "three analysts spend 48 hours a month rebuilding the same report, at a loaded cost of $55 an hour, which is $2,640 a month" is a problem the reader can evaluate. Show how the problem has trended and what happens if nothing is done. The cost of doing nothing is the benchmark for every option.

Always include a do-nothing option

The do-nothing option is not zero. Costs may grow as volume rises, staff leave or a system goes out of support. Include its cost over the same period. Then each alternative is judged on the difference from do-nothing, which is the incremental logic described in incremental ROI. A recommended option that is better than doing nothing by a small amount, at a large cost, will look different from one that avoids a significant and growing loss.

Building credible numbers

Credibility comes from traceability. For every material number, state where it comes from.

• Costs: quotes, contracts, rate cards and payroll data. Add a contingency, and say what it is.
• Benefits: your own operational data, a pilot, a reference customer or a published benchmark. Do not rely on a vendor's claim alone.
• Time savings: convert to value only for the share that will be removed or redeployed, and say which.
• Revenue effects: use contribution margin, not revenue, and be explicit about what would have happened anyway.
• Ramp-up: benefits rarely arrive on day one. Phase them in realistically.

Do not give false precision. A figure of $23,760 suggests a more exact estimate than the data supports; "about $24,000" is more honest. Round, and show the range.

Scenarios and probability weighting

Show at least a conservative, a base and an optimistic case. A three-year cost of $85,000 might yield these total benefits (hypothetical):

Check: 25,000 / 85,000 = 0.294; 85,000 / 85,000 = 1.0; 145,000 / 85,000 = 1.706. The weighted expected benefit is 0.40 × 110,000 + 0.45 × 170,000 + 0.15 × 230,000 = 44,000 + 76,500 + 34,500 = $155,000. The expected net gain is 155,000 - 85,000 = $70,000, and the expected ROI is 70,000 / 85,000 = 82.4 percent. Notice that the expected value is lower than the base case, because the weights lean toward the conservative scenario. The weights are judgments. Explain them, and be ready for challenge. An even simpler approach is to base the decision on the conservative case: if the project still pays back, it is a safe bet. Whichever you use, say so.

Risks

List the real risks, not generic ones. Typical risks include adoption (people will not use the new process), data quality, vendor delivery, resource availability and external changes. For each, state the likelihood and impact, the early warning sign and the mitigation. Identify the two or three assumptions that most influence the result, and show what happens if they are wrong. Honest risk sections increase credibility, because reviewers see that you have thought about how the case could fail.

What reviewers look for

Finance reviewers typically check five things.

1. Do the numbers reconcile with existing budgets and actuals?
2. Are benefits real and owned? Can they be seen in the P&L or the cash flow, and is someone accountable?
3. Are costs complete? Have internal time, support and contingency been included?
4. Is the period reasonable and are cash flows discounted?
5. How will we know? Is there a plan to measure results?

If you can answer these in advance, approval is quicker. Ask a finance colleague to review a draft before you submit it. It is quicker to fix a gap in private than in a committee.

A model executive summary

"We request $85,000 over three years to automate the monthly management report and build a forecast dashboard. Today three analysts spend 48 hours a month assembling the report, and late numbers delay decisions on purchasing. The recommended option costs $85,000 and, in our conservative case, returns $110,000 over three years (ROI 29 percent), in our base case $170,000 (ROI 100 percent). The main assumption is that 60 percent of the analyst time saved is redeployed to margin analysis. We will measure results at 6 and 12 months against the baseline of 144 hours a quarter." That is five sentences, and a busy reader knows what is wanted and why.

Habits that undermine credibility

1. Starting with the answer and fitting numbers to it.
2. Burying the assumptions.
3. Counting every benefit at full value.
4. Leaving out do-nothing.
5. Presenting a single number with no range.
6. Overselling intangible benefits.
7. No plan for measurement.

From hours saved to value, honestly

Time savings are the most common benefit in business cases and the most often overstated. Take the example above: three analysts spend 144 hours a quarter, or 576 hours a year, on the report, and the loaded cost is $55 an hour. The gross value of the time is 576 × 55 = $31,680. If the new process removes 75 percent of the work, 432 hours a year are freed, worth $23,760. But a freed hour is worth $55 only if it is turned into something. If the analysts spend 60 percent of the freed time on margin analysis that the business wants, and the rest vanishes into the ordinary variation of the working week, the credible value is 0.60 × 23,760 = $14,256 a year. A reader who sees the chain from $31,680 to $14,256, with each step explained, will trust the final number more than one who sees $31,680 and a claim of full savings.

Writing for the reader

Different readers want different things. A chief financial officer wants to see cash flows, payback, the risk to the numbers and the budget effect. A chief operating officer wants to know what will change for the team, how long it will take and what could disrupt service. A board member wants the strategic reason, the size of the commitment and the downside. Write one case with a short summary for each reader, and keep the detail in appendices. Use plain language, avoid jargon and define any term that the reader might not know. A business case is not a technical specification.

Before the meeting

Informal conversations before a formal decision make the formal meeting shorter. Talk to the finance partner about the assumptions. Talk to affected department heads about the changes and their concerns. Ask the sponsor which objection they expect, and prepare an answer. Bring a one-page summary to the meeting, and the full document as backup. If you are asked a question you cannot answer, say so and commit to a date. It is better to defer than to guess. After approval, send a short note confirming the decision, the conditions and the review dates, and add the benefits to the register described in how to track ROI across departments.

What to put in the appendices

• The cost and benefit model, with all assumptions and sources.
• Quotes or contract terms for the main costs.
• The data behind the problem statement, such as error logs or time records.
• Reference customer or pilot results.
• The detailed risk register.
• The implementation plan with milestones and dependencies.

Appendices let you keep the main document short while showing that the work was thorough.

FAQs

What should a business case include?

An executive summary, the problem, options, the recommendation, costs and benefits, risks, an implementation plan and the decision requested.

How do I make ROI credible?

Trace every number to a source, include all costs, apply realization and ramp-up factors, show scenarios and name the assumptions that matter most.

How long should a business case be?

As short as the decision allows. Two pages for a modest request, and longer for major investments, with detail in appendices.

Should I include a do-nothing option?

Yes. It is the baseline against which other options are compared, and it may have growing costs.

How do I deal with benefits that are hard to quantify?

Describe them, keep them out of the headline ROI and present them as upside.