If an organization brings me in because their data investments are not delivering, the first thing I do is resist the urge to look at the technology.
That instinct goes against what most people expect. There is usually a platform involved, a dashboard that nobody uses, a data warehouse that took eighteen months and came in over budget. The technology is visible and concrete and it feels like the obvious place to start.
But in my experience, the technology is rarely where the problem lives. It is where the problem shows up.
Here is how I actually think through a broken data strategy, and where I would start if I were sitting across from your leadership team.
The First Question I Ask
Before I look at a single dashboard or a single data pipeline, I want to understand what decisions the organization is trying to make better.
Not what data they have. Not what tools they are using. What decisions.
If I cannot get a clear answer to that question, I already know a significant part of what went wrong. Data strategies that are built around available data rather than necessary decisions tend to produce environments full of reports nobody reads and infrastructure nobody trusts. The organization invested in supply without ever clearly defining demand.
If a leadership team can tell me the ten decisions that most determine their business outcomes, and can articulate what information would make each of those decisions sharper, I can build a data strategy around that. If they cannot, that conversation is where we start. Everything else waits.
The Second Thing I Look For
Once I understand the decision landscape, I want to know whether the organization has agreed on what its numbers mean.
This sounds simple. It is not. I have sat in executive meetings where two leaders were looking at the same metric on the same dashboard and working from different definitions without realising it. Revenue calculated at point of contract in one business unit, at point of delivery in another. Customer count defined differently by sales, finance, and operations. Utilization calculated on different denominators across different teams.
These disagreements do not surface as definitions problems. They surface as trust problems. Leaders stop trusting the data because the data keeps producing results they cannot reconcile. The response is usually to build more reports, which makes the problem worse.
If I find this pattern, I stop the technical work and run a definitions workshop before anything else is built. Getting twelve core metrics agreed and documented before a single dashboard is touched is slower than most projects want to go. It is also the reason the platform that follows actually gets used.
The Third Thing I Examine
I look at how governance is positioned in the existing strategy. Specifically, whether it exists as a separate workstream or as a foundation.
If it is a separate workstream, that is usually a sign that it was added after the fact. Governance that gets bolted on tends to be governance that does not stick. Data quality standards that nobody enforces. Metric definitions that drift because there is no process for managing change requests. Report inventories that nobody maintains until the sprawl becomes unmanageable.
If I find this, my recommendation is to pause the build, establish the governance operating model, and then resume. That conversation is difficult because it feels like going backwards. In practice, it is the only way to avoid rebuilding the same environment in another two years.
Where I Would Start
If you brought me in to look at a data strategy that is not working, here is the honest sequence I would follow.
First, I would spend time with your leadership team understanding what decisions need to be made and what information is missing or untrustworthy. Not a survey. Actual conversations.
Second, I would audit what exists. Not to celebrate what is working, but to understand what is being maintained, what is being used, and what has been quietly abandoned. The gap between those three lists is usually instructive.
Third, I would facilitate the definitions conversation before recommending any technology changes. If the organization cannot agree on what its core metrics mean, no platform will fix that.
Fourth, I would sequence a roadmap around decisions, not capabilities. The first things built would be the ones connected most directly to the decisions that matter most. Everything else would wait.
The technology comes after all of that. Not because it is unimportant, but because technology built on top of unclear decisions, undefined metrics, and absent governance tends to recreate the same problem in a more expensive form.
This is the kind of advisory work I find most valuable: not implementing a platform, but helping an organization understand why its data investments have not delivered and building the foundation that makes the next ones stick.
If this reflects challenges your organization is navigating, I write more on these topics at Data & AI Foundry.