I Write a Business Case for Every Data Project. Even the Small Ones. Here's Why.

Before I start any data project — a new dashboard, a governance framework, a data quality audit — I write a one-page business case. Even if it's a three-day piece of work. Even if nobody asked for one.

This sounds like overhead. It isn't. It's the cheapest insurance you can buy on a data project.

Why data projects fail

In my experience, data projects fail for three reasons — and only one of them is about data:

• The analyst built something technically correct that nobody needed (wrong problem)
• Success was never defined, so nobody knew if it worked (no criteria)
• The data wasn't trusted enough to act on, even when it was right (no buy-in)

A one-page business case addresses all three before a line of SQL is written.

The template

Problem statement. One sentence. What specific pain exists right now? Who feels it? How often?

Proposed solution. What will be different after this project? Be specific. "A Power BI report showing X, refreshed daily" beats "improved data visibility."

Success criteria. How will you know it worked? Name the metric. "Reconciliation time drops from 3 days to 1 day" is measurable. "Stakeholders are happier" is not.

Effort estimate. Days, not weeks. If it's weeks, it needs a proper project plan, not a business case.

Risk. What's the one thing most likely to kill this project? Data availability? Stakeholder time? Tool access? Name it early.

What happens when you skip it

You spend three weeks building a dashboard that answers the question you thought stakeholders had, present it in a meeting, and find out they actually needed a different cut of the same data. The underlying work wasn't wasted — but the three weeks was.

A 90-minute business case conversation before the work starts would have caught this. It almost always does.