Start with the Use Case or Don’t Start at All
This article is about why most data initiatives fail, and how to stop wasting time, money, and credibility.
I know you have heard it all before and it’s a familiar story that you read in yearly reports or you might have been privy in boardrooms. What I am alluding to are the grand declarations about becoming “data-driven,” which is typically followed by ambitious investments in platforms, talent, and large elongated transformation programs.
Yet, and here is the story that we all hear or read on a LinkedIn post, that a year or two in, very little of tangible value has been delivered. Then the frustration builds, accountability is vague, a few discussions occur about why, and then the business moves on.
The typical outcome?
The data team either gets restructured, rebranded, or worse, shut down.
Then the usual cycle begins where the analyst firms release yet more statistics, you know the usual ones that circulate year in year out. 80 percent of data initiatives failing, yet again!
What do we think the root cause might be? Of course, I’m sure there are many papers that have been written about this very subject. But this is my take, of what I have observed and seen through almost three decades of experience:
It’s not the technology and I’m sure you are surprised by me stating that!
It’s not even the talent, because there are good people attempting to do their part in the transformation.
The challenge that I see it is this: the work is not anchored to a use case.
Many don’t see it this way, as for them the Use Case is just a line item in a long list of “to dos”. Nope it’s not a long list, it’s the spine of everything we do.
Let’s look at what happens when we don’t focus on use cases. Far too many data programs operate like parallel universes. You typically have data governance running over here, engineering teams building pipelines over there, architecture frameworks getting signed off in yet another silo, and all without a common thread pulling them together.
What’s missing is the use case. But not as an afterthought or an output, as the starting point, the organizing principle if you must. The reason any of this exists.
When you lead with a use case, whether it’s reducing churn, improving fraud detection, or shortening time-to-cash, you will unlock three things:
- Clarity on what matters and why.
- Alignment across stakeholders and technical teams.
- Momentum that comes from delivering real value.
More importantly, you create a forcing function. What do I mean by a “forcing function”? If you focus on the use case, it forces you to think through the entire data value chain:
- What data is needed?
- Is it available and trustworthy?
- Do we have the architecture to support this?
- Who’s accountable for delivery?
- What does success look like?
Only then do such areas of governance, engineering, analytics, and change management make sense. Without the use case, they’re just floating disciplines, nice to have, but directionless.
Why Most Data Teams Still Get It Wrong
Many organizations still approach this backwards. They start by investing in tools and infrastructure, focus only on governance activities, the endless discussions about ownership! At some point and somewhere down the line, someone has no must as the sane question:
“What exactly are we solving for?”
Often though the horse has bolted, half of the budget has been consumed, and the business has already lost patience.
In this typical model, use cases are normally bolted on. Or worse, they’re invented retroactively to justify the sunk cost. Either way, it’s a recipe for failure and back to our well known industry statistic!
If You Want Different Outcomes, You Need a Different Approach
Here’s the simple truth. If you want to build a data capability that delivers actual business value, every part of your operating model needs to revolve around the use case. That includes all those areas I spoke about previously:
- Governance procedures and policies tailored to the data the use case needs.
- Engineering focused on building pipelines that serve that use case, not some theoretical future state.
- Architecture that scales based on what’s being delivered, not on what someone saw in a vendor demo.
- Accountability that tracks delivery of the use case outcome, not activity metrics.
There is nothing radical about this approach and if you approach it in this manner, it works.
The Use Case Is Your North Star
If your organization isn’t clear on what specific use cases it’s trying to deliver, and how each part of your data function supports them then stop. Really, don’t spend another pound/dollar/euro etc. Don’t sign off on another strategy document. Here is what you do:
Get the business around the table and identify 3–5 priority use cases that actually move the needle.
Then build your data strategy around them. Not the other way around.
Because if you’re not solving a problem, you’re just building a capability for the sake of it. That is why so many teams end up answering the same question:
What did we get for all that money?
