There is a recognisable way that AI projects begin badly, and it is almost always the same shape. The starting line is a capability or an impulse rather than a problem: "we have all this data, what can we do with it", or "we should be using AI by now", or "the board wants an AI story for the next meeting". This is the mistake good AI consulting exists to catch early, before a team burns months on the wrong build. A team takes the brief and builds something genuinely impressive: a model with good accuracy, a slick interface, a clever pipeline. Then they show it to the people who were meant to use it, and the response is some version of: that's nice, but it doesn't solve our problem.
A solutions architect who has worked on dozens of these described the pattern cleanly after watching a team spend six months on a recommendation engine: the model was impressive, the accuracy was high, and they had built the wrong thing, not because the technology was bad, but because nobody ever asked what problem they were solving. His conclusion is the whole of this post in one line: start with the business problem, not the technology. The question is never "what can AI do?" It is "what decision do we need to make better, and can AI help?"
This post is about why starting from the data, the model, or the technology produces AI that impresses and does not deliver, and why starting from the decision is what separates the two.
The wrong starting point has a name
Beginning with the technology rather than the problem is common enough to have acquired several names, all unflattering. Prosci calls it "shiny object syndrome": organisations investing heavily without a clear understanding of the problem they are trying to solve, ending up with solutions looking for a problem. One veteran CIO calls the resulting pilots "proofs-of-cost": projects with no clear business problem to solve, no benefit defined, and no measurable success criteria, which never leave the lab. Harvard Business School researchers, writing in late 2025, put it more structurally: most AI initiatives fail not because the models are weak, but because the organisations were never built to sustain them, lacking the redesigned decision processes that turn a capable model into a business result.
The common thread is that the project produced insight with nothing attached to it. A score, an analysis, a dashboard, a generated summary, disconnected from any specific decision that anyone was going to make differently as a result. And insight with nothing attached to it is, increasingly, the least valuable thing an organisation can produce.
Insight was never the scarce thing
This is the part that takes a moment to sit with, because it runs against the instinct that more analysis is always better. The constraint in most organisations is not a shortage of insight. It is a shortage of insight that turns into action.
Gartner has made this the centre of its data and analytics research. Their distinguished analyst Rita Sallam framed it bluntly in 2026: data and analytics leaders are not short of insight: they are short of control over how insight turns into action, and as AI scales, the real challenge is no longer producing better analysis but governing and improving the decisions that analysis feeds. The supporting figure is sobering: Gartner's research has found that roughly 65% of organisations still use data selectively to justify decisions they have already made, rather than letting data genuinely drive the decision. Read those two findings together and the implication is uncomfortable for anyone planning an AI roadmap. More dashboards, more analysis, more AI-generated insight does not move the business if it is not attached to a decision someone will actually make differently. You can add an enormous amount of intelligence to an organisation and change nothing, because the bottleneck was never the intelligence.
Gartner's own prescription follows directly, and it is the crux of this post. Their guidance to data and analytics leaders is to avoid a technology-driven approach (it is too early for that) and instead develop the decision-making flows first, then look at where AI can be used within them. Start from the decision. Let the technology be chosen to serve it.
Why decision-first works and solution-first fails
The inversion sounds like a slogan until you look at what actually changes when you start from a decision rather than from a capability. Four things, each of which is a failure mode of the solution-first approach.
A decision has an owner. An insight often doesn't. When you start from "which customers should our team prioritise this month", there is a person who makes that call and will use a better answer. When you start from "let's build customer analytics", the output lands on a dashboard that belongs to nobody in particular, and a thing that belongs to nobody gets used by nobody. The most common reason a working AI feature goes unused is that it was never attached to a decision someone was accountable for, which is its own well-documented problem, and it starts here, at the scoping stage.
A decision tells you exactly what you need. Name the decision and the requirements fall out of it: this is the data the decision depends on, this is the question the model has to answer, this is where the answer needs to appear. Start from the data instead and you are building capability in the hope that a use materialises, and the use either never arrives or arrives mismatched to what you built. The decision is a specification. The data, on its own, is not.
A decision is measurable; "insight delivered" is not. You can ask whether a decision got better, faster, or cheaper, against what it cost and looked like before. You cannot meaningfully ask whether "insight" succeeded. Starting from the decision gives you, for free, the thing that solution-first projects scramble to invent afterwards: a clear test of whether it worked. (Doing that measurement honestly, against a real baseline with all costs counted, is its own discipline, and worth treating as one.)
A decision keeps the human in the loop where they belong. Starting from the decision forces the right relationship between the model and the person: the AI informs the decision; a human, or a deterministic rule you can read, makes it. Gartner's framing for the mature version of this is "augmented intelligence": human judgement and machine capability working together, rather than handing the decision to a model wholesale. That is both safer and more trusted, and it falls naturally out of designing around the decision rather than around the model's capabilities.
Working backwards, in practice: the AI consulting approach
The decision-led method is not complicated. It is mostly the discipline of refusing to talk about technology until you have done the first two steps.
- Name the decision. Be specific to the point of discomfort. Not "customer analytics" but "which of our accounts should the team spend time on this month, and why." Name who makes it, how often, and on what information they make it today. If you cannot name the decision, you do not yet have a project: you have an impulse.
- Define what "better" looks like. What would a better version of this decision change: more margin captured, less time spent, fewer wrong calls? How would you see the improvement? Write it down before you build, because afterwards everyone's memory of the goal becomes conveniently flattering.
- Only now choose the technology. What data does this decision actually need? What does the model have to do, and is a model even the right tool, or would a rule or a simple query serve? Where does the answer need to appear so the decision-maker sees it at the moment they decide? The technology is the last question, not the first, and it is chosen to fit the decision rather than the decision being bent to fit the technology.
- Put the improved decision in someone's hands. Not on a dashboard they might visit. In the flow of the decision they already make, with a human or a readable rule making the final call.
- Start narrow and expand from proof. The pattern that works is land-and-expand: prove one decision, demonstrate it improved, then take on the next. A commercial property firm that started with a single workflow, proved the return, and expanded across the organisation got further than the teams that tried to build an AI portfolio up front. One decision improved beats ten dashboards admired.
The test that kills the science projects
If you take one operating rule from this, make it the test you apply before any AI project starts: does this change a decision that someone actually makes, and will we be able to tell? If the honest answer is no, if the thing produces insight with nothing attached to it, then it is a science project, however impressive the demo, and the disciplined move is to not start it, or to stop it. The teams that get returns from AI tend to run smaller portfolios for exactly this reason: they decline the projects that are interesting but unattached, and put their effort where a decision will measurably change.
The industry is formalising this. In January 2026 Gartner published its first Magic Quadrant for Decision Intelligence Platforms, a category defined around designing, executing, monitoring, and governing decisions end to end, treating decisions themselves as managed assets in the way we already treat code and data. You do not need to buy a decision intelligence platform to take the lesson. The lesson is upstream of any platform: the unit of value is the decision, not the model and not the dashboard.
Data is not the starting point. Neither is the model, and neither is the fact that everyone else is doing AI. The starting point is a decision that someone in your business needs to make better. Once you have named it, everything else, the data and the model and the interface, gets chosen to serve it. This is the core discipline behind effective AI consulting: naming the decision before touching the technology. The companies pulling ahead on AI in 2026 are not the ones producing the most insight. They are the ones who started from a decision worth improving, worked backwards to the smallest thing that improved it, and could tell afterwards that it had. Start there, and the technology mostly takes care of itself. Start anywhere else, and you will build something impressive that solves a problem nobody had. Once the decision is named, the five tests for which workflow is worth automating narrow it to something you can actually begin on.
References
- Gartner: Magic Quadrant for Decision Intelligence Platforms (inaugural, January 2026), summarised in SD Times. https://sdtimes.com/ai/gartner-acknowledges-growth-of-decision-intelligence-platforms-with-inaugural-magic-quadrant/
- Gartner Data & Analytics: From Data-Centric to Decision-Centric (including the 65% "justify decisions already made" finding and the "avoid a technology-driven approach" guidance), summarised by Linkurious. https://linkurious.com/blog/gartner-data-and-analytics-2024/
- Gartner: Bridge AI and Business Outcomes With Decision Intelligence (decision-centric, technology-agnostic framing). https://www.gartner.com/en/webinar/728424/1635815
- Prosci: Why AI Projects Fail (shiny object syndrome; solutions looking for a problem; proficiency vs technical failure split). https://www.prosci.com/blog/why-ai-projects-fail
- Nuno Barreto: Why Most AI Projects Fail: It's Not the Technology (start with the business problem). https://medium.com/@nbarr/why-most-ai-projects-fail-its-not-the-technology-eef6d30611eb
- CIO / Kieran Gilmurray: Why 80% of AI Projects Fail, and How Smart Enterprises Are Finally Getting It Right ("proofs-of-cost"). https://www.cio.com/article/4083265/why-80-of-ai-projects-fail-and-how-smart-enterprises-are-finally-getting-it-right.html
- Harvard Business Review / Ayelet Israeli & Eva Ascarza: Most AI Initiatives Fail. This 5-Part Framework Can Help (November 2025). https://hbr.org/2025/11/most-ai-initiatives-fail-this-5-part-framework-can-help
- AI Business: When AI Projects Fail: Rescue Stalled AI Initiatives (land-and-expand; the 70/30 split). https://aibusiness.com/intelligent-automation/rescuing-failing-ai-projects
Written by JP, Sixees Labs. Last reviewed June 2026.