Most data projects don't die from technical failure. They die much earlier, in a budget meeting where someone asks "and what return does this bring?" and no one around the table can answer clearly. The model was correct, the pipeline worked and the report looked good — but it was never clear which business problem it solved, or how much solving it was worth.
A business case is the bridge between a good technical idea and a business decision. It is the document — often a spreadsheet and two or three slides — that translates "we want to build a data warehouse" into something like "we want to free up 300 hours a month for the finance team and cut stockouts by 8%, for an investment of X and an expected payback in Y months". Without that translation, a data project competes for budget at a clear disadvantage against everything else.
This guide shows how to build a solid business case for a data project: starting from the right problem, quantifying value and cost without inventing numbers, handling uncertainty honestly and presenting it all to decision-makers. It is not an exercise in internal marketing. Done well, it is a discipline that improves the project itself, because it forces you to clarify what you want to change and how you will know it worked.
What a business case is, and what it is not
A business case answers three simple questions: what problem will we solve, what does solving it cost, and what do we gain. Everything else is secondary. It is not a detailed project plan, not a technical architecture and not a requirements document — those come later and for a different audience.
The most common mistake is to confuse the business case with the description of the solution. Whoever signs off the budget rarely wants to know whether you will use Snowflake or BigQuery, whether the model is a star or a snowflake schema, or which ETL tool sits in the middle. They want to know whether the money invested comes back, over what period and with what degree of confidence. The business case speaks the language of the person signing the cheque, not the person writing the code.
A good business case is also honest about what it does not know. It states explicit assumptions, shows the likely range of outcomes and does not promise a precision that the starting data cannot support. That honesty is what makes it credible the second and third time you present one.
Start with the problem, not the technology
Many data projects are born backwards: someone saw a tool demo, got excited and only then looked for a problem to fit it to. A strong business case reverses that order. It starts from a concrete business pain — a report that takes three days to close, a purchasing decision made blind, customers who leave without anyone noticing in time — and only then asks which data and capabilities solve that pain.
A good way to test whether you are starting from the right end is to write the problem in one sentence that contains no technical word. "The sales team doesn't know which customers are at risk of leaving until it's too late." If you can describe it like that, you have a business problem. If you can only describe the solution ("we want a churn model"), you are still thinking like an engineer and not like the person who will foot the bill.
Quantify value on three fronts
The value of a data project almost always falls into one of three categories. It is worth separating them because each is estimated differently and convinces different audiences:
- Revenue growth: more sales, better conversion, fewer lost customers, sharper pricing. It is usually the most exciting number and also the most uncertain, because it depends on market behaviour.
- Cost reduction: manual hours freed up, fewer errors to fix, faster processes, consolidated infrastructure. It is the easiest value to defend, because it depends mostly on us.
- Risk reduction: fewer stockouts, fraud detection, regulatory compliance, decisions less exposed to chance. It is the hardest to put in euros, but often the most important.
For each front, look for an anchor number that already exists in the organisation. If the finance team spends three days a month consolidating reports by hand, those are hours with a known cost. If average stockout is 5% and each percentage point is worth a known amount in lost sales, you have the basis for a defensible estimate. The goal is not accuracy to the cent; it is an order of magnitude that survives questioning.
Estimate total cost, not just the licences
The cost side is where business cases most often sin through optimism. It is tempting to add up only the price of the software licences and present that as the investment. In reality, the total cost of ownership includes much more: the time of the people who build and maintain the solution, data migration and cleaning, training for those who will use it, integration with existing systems and the cost of maintenance in the years that follow.
A prudent rule is that the initial build is only a fraction of the cost over the life of the project. A pipeline or a report is not an asset you buy and forget; it is something that needs to be maintained, fixed and adapted as the data and the business change. Including that recurring cost from the start avoids the uncomfortable conversation, a year later, about why "the project that was already finished" is still consuming resources.
The baseline: the cost of doing nothing
Every business case needs a point of comparison, and the most honest one is the scenario in which the project is not done. What happens if we carry on as we are? Often the answer is not "everything stays the same" — it is a slow degradation: more hours spent, more errors, more bad decisions, a competitive disadvantage that accumulates.
Making that cost visible is half the persuasion. When decision-makers realise that inaction also has a price — one they are already paying, diffusely, every month — the question stops being "is it worth spending this?" and becomes "is it worth continuing to lose that?". It is a reframing that changes decisions.
Assumptions, uncertainty and sensitivity
No estimate of future value is certain, and pretending it is destroys credibility. Instead of presenting a single number, present a range and make the assumptions behind it explicit. "If we can cut stockouts by 3 to 6 percentage points, the annual return sits between A and B." This shows maturity and protects you when reality lands somewhere inside that range.
Sensitivity analysis takes this a step further: it identifies which two or three assumptions move the result the most. If the return depends mostly on the team's rate of adoption of the tool, then that is the real risk of the project — and the business case should say so and propose how to mitigate it, for example with training and follow-up. Discussing risk openly is a sign of strength, not weakness.
Phasing: prove value before scaling
A business case is easier to approve when it does not ask for everything at once. Splitting the initiative into phases — a focused proof of concept, then a pilot with real users, only then the expansion — reduces perceived risk and creates decision points. Each phase produces learning and results that fund confidence in the next.
This phasing also protects the organisation. If the first phase does not deliver what it promised, you stop with a small loss instead of discovering the problem at the end of a large investment. Decision-makers like knowing there is an exit at each point. A plan with clear milestones and "continue or stop" criteria is almost always more convincing than a single request for the full budget.
How to present it to decision-makers
The best analysis in the world does not convince if it is poorly communicated. Start with the conclusion — the problem, the expected value, the investment and the timeline — on one page. Decision-makers should be able to grasp the essence in two minutes and only then descend into detail if they want to. Burying the result at the end of twenty slides is the fastest route to a "let's think about it".
Adapt the language to the audience. A finance director wants to see return, payback period and assumptions. An operations lead wants to understand the impact on the team's day-to-day. A board member wants the strategic framing and the risk. The same business case may have to be told three ways — the numbers don't change, the angle does.
Common mistakes that sink a business case
There is a handful of mistakes that keep recurring. The first is over-promising: return figures no one believes undermine trust in everything else. The second is selling technology instead of outcomes, leaving decision-makers unsure which problem of theirs is solved. The third is ignoring maintenance and adoption costs, creating an unpleasant surprise later on.
A fourth, more subtle mistake is failing to define upfront how success will be measured. If the business case promises to cut working hours or increase conversion, there has to be a way to check, months later, whether that happened. Without that metric agreed in advance, the next business case starts from a weaker position, because there is no proof the previous one delivered.
Mini case: from gut feel to decision
Consider a mid-sized retail company that lived with frequent stockouts on its best-selling products. The internal perception was that "this costs us sales", but no one had put a number on the problem. The data team proposed a demand forecasting project, but the first version of the request — centred on the technology — did not pass the budget committee.
They reframed the business case around the problem. They estimated that average stockout was around 6% on the top references and that each percentage point was worth a known amount in lost sales per month. On the cost side, they included not just the tool but the time of two people over three months and annual maintenance. They proposed a first phase limited to one product category, with a clear criterion: if stockout did not fall by at least two points in three months, the project would stop.
The pilot phase cut stockout in that category from about 6% to close to 3.5%, a result within the promised range. With that real number in hand, the expansion to the remaining categories was approved almost without discussion. What changed was not the technology — it was the framing and the proof of value at small scale.
In practice
A business case for data is not there to dress up a project; it is there to force it to be honest with itself before asking for money. Start with the business problem, quantify value and cost with real anchor numbers, show the cost of doing nothing, be transparent about uncertainty and propose a phased path with decision points. Agree upfront how you will measure success, so the next request starts from solid ground.
Done this way, the business case stops being a formality and becomes a management tool. It aligns the technical team and the business around the same goal, filters out the ideas that don't hold up and gives good projects the language they need to compete for budget. In a context where almost every area is asking for investment in data, it is that clarity — not technical sophistication — that usually separates the projects that move forward from those that stay forever "under review".
