The most common way analytics initiatives fail isn't poor technology — it's poor sequencing. Companies buy tools first and ask strategic questions later, if at all. Here's what gets skipped, why it matters, and what to do instead.
The statistic gets cited often enough that it should be embarrassing: roughly 85% of large data initiatives fail to deliver on their original goals. It isn't a technology problem. The tools have never been cheaper, more capable, or more accessible. A company with a few thousand dollars and a cloud account can stand up infrastructure that would have required a dedicated data center fifteen years ago. The failure is almost always upstream of the tools — in the absence of a clear reason to have them.
Data strategy is not a technology plan. It is not a decision about which BI platform to buy or whether to move your warehouse to Snowflake. It is a decision about what you need your data to do — for which people, in support of which decisions, against which constraints — and then a plan for building the people, processes, and technology that make that possible. In that order. The technology is the last decision, not the first.
This sounds obvious stated plainly. In practice it is consistently violated, because technology decisions are concrete and satisfying — you can buy a license, spin up a dashboard, show something to leadership — while strategic decisions are ambiguous and require alignment across functions that often don't naturally talk to each other. The path of least resistance runs straight to the tool purchase. That path also runs straight to a warehouse full of data nobody trusts, dashboards nobody uses, and a data team that spends most of its time fielding one-off requests and explaining why the numbers don't match.
Data is not inherently strategic. People, process, and a clear purpose are what make it so.
A practical data strategy for a small or mid-sized company doesn't need to be a hundred-page document — the organizations that actually execute on their strategies tend to keep them shorter and more opinionated, not longer. But it does need to address seven distinct questions. Skip any of them and you'll feel the gap later.
Who owns which data? Who can access what? Who is responsible when a number is wrong? Governance is the policy layer — roles, responsibilities, and rules that make data trustworthy across the organization.
How do you know the data is accurate, complete, and current? Not a one-time audit — an ongoing process that catches and corrects problems before they reach a dashboard and undermine trust in the whole system.
Where does data live, how does it move between systems, and how is it structured for the uses you need? This is where technology decisions actually belong — downstream of governance and quality, not upstream.
Can the people who need data actually get to it — securely, reliably, without filing a ticket and waiting three days? Access is about design, not just permissions. The right data should be findable by the right people.
Can your team read and interpret data, ask good questions of it, and recognize when something looks wrong? Technology doesn't compensate for a team that can't engage with the output. Literacy is infrastructure too.
How does the data get from the source to a decision-maker's screen? Who builds the reports, who owns the definitions, and what happens when two reports show different numbers for the same metric?
What analytical capabilities does the organization actually need — descriptive, diagnostic, predictive? This is where BI tools, data science, and modeling live. It's a later conversation than most companies treat it as.
These aren't independent workstreams. Governance enables quality. Quality enables trusted access. Trusted access enables literacy. Literacy enables useful analytics. Jumping to analytics without the foundation underneath it is where most initiatives strand themselves.
Before a data strategy can be built, four foundational questions need honest answers. These aren't planning exercises — they're the inputs. Without them, any strategy you build is working from assumptions that may not hold.
Is the current state good enough to survive? This is the USTRANSCOM framing, and it's the right place to start. Not "could things be better?" — things can always be better. The useful question is whether the current state of your data is actually limiting decisions, creating risk, or costing money. If the answer is yes, you have a mandate. If no, you have a nice-to-have project that will lose every resource fight it enters.
What decisions does your data need to support? Not generically — specifically. Name the decision, name the person who makes it, and name what information they currently lack or distrust. A data strategy that isn't organized around specific decisions tends to produce a lot of data and not much insight. The USTRANSCOM team's specific list — advance decision-making, offload common tasks, provide information at the speed of operations — is a model of what useful specificity looks like.
What are you willing to hold still long enough to build on? Data infrastructure requires stability to develop. If the business processes it mirrors are being redesigned every six months, the data layer built on top of them will constantly break. Part of a data strategy is identifying which parts of the business are stable enough to instrument reliably — and which aren't yet.
Who has to own this? Data initiatives that live entirely inside a data team tend to produce outputs that the rest of the organization doesn't trust or use. The strategy — not the execution, but the strategy — needs an executive sponsor and business-side ownership. Without it, every data quality issue, every definition disagreement, every access request becomes a negotiation the data team will consistently lose.
The United States Transportation Command coordinates over 240 air missions, 1,500 ground shipments, and 20 ships underway — every single day — across the entire world. Few organizations produce data at that scale or under those operational pressures.
When USTRANSCOM's Chief of Emerging Technology Larry McLean presented their data strategy journey at the DATAVERSITY Enterprise Data World Conference, his opening was instructive: before anything else, they found the why. Not the tools, not the architecture — the purpose. Their data strategy nested explicitly under the organizational vision, which drove goals, which drove objectives, which drove the data work.
McLean's specific list of what a data strategy was supposed to accomplish — advance decision-making, mature as a data-driven organization, offload common tasks, provide information at the speed of operational need, use personnel where they're needed most — is a model of outcome-first thinking. Each item connects directly to a capability the organization needed and didn't have. None of them say "buy better software."
The lesson for smaller organizations isn't scale — it's sequencing. Start with the why. The what and the how follow.
Fifteen years across finance, healthcare, real estate, and nonprofit — the failure modes look remarkably similar regardless of industry. They tend to cluster around four recurring problems.
Pick one decision that your leadership makes regularly, that is currently being made with incomplete or distrusted data, and that has a clear owner. Build the minimal data infrastructure to support that decision well — clean source, clear definition, single owner, one trustworthy output. Get that working and trusted before adding anything else. Credibility compounds; a small thing that works is worth more than a large thing that doesn't ship.
We help companies at the strategy layer and the build layer. On the strategy side: working through the four foundational questions, auditing the current state honestly, identifying the first phase of work that will actually ship and create value, and building the governance foundations that make everything downstream trustworthy. On the build side: the dashboards, the warehouse architecture, the reporting layer — but only in service of a strategy that's already been defined.
What we don't do: sell a tool and call it a strategy. Recommend platforms we have financial relationships with. Scope projects that are designed to run forever. The engagements we take are the ones where we believe there's a clear problem, a defined first phase of work, and a business owner who's committed to seeing it through. That's a smaller set of engagements than we could theoretically take — and it's the right set.