Why Most Analytics Projects Fail Before They Start
The Decision Stack · Post 1 of 10
Marcelo Katogui
March 03, 2026
The Decision Stack · Post 1 of 10
A series on the architecture, methods, and mindsets behind building analytical systems that actually drive decisions.
1. The Pattern
There is a version of this story that repeats itself across organizations of all sizes: a team invests months in data infrastructure, builds out a set of dashboards, and then watches as those dashboards go largely unused. The data is clean, the visualizations are polished, and the underlying analysis is sound. And yet nothing changes in how decisions get made.
The failure is rarely technical.
Most analytics projects fail because they begin with data, not with decisions. The implicit assumption is that if you give people access to information, better choices will follow naturally. This assumption is wrong — not because people are irrational, but because information and decision infrastructure are two different things.
2. Information vs. Decision Infrastructure
Core Distinction. Information tells you what is happening. Decision infrastructure tells you what to do about it.
The distinction matters enormously in practice. A report showing that churn increased by 12% last quarter is information. A system that surfaces which customer segments are at risk, quantifies the cost of inaction, and runs intervention scenarios against budget constraints is decision infrastructure. One describes a situation. The other supports a choice.
The analytical work behind both may be identical. The architecture is completely different.
Two architectures for the same data. The information path terminates at a report. The decision path terminates at an allocation.
3. Starting with the Right Question
Projects that start with the question “what data do we have?” almost always produce reports. Projects that start with the question “what decision needs to be made, by whom, on what cadence, under what constraints?” produce systems that get used.
Common Mistake. Treating data availability as the starting point for an analytics initiative. The data is usually not the bottleneck. The architecture is.
This is not a technology problem. It is a design problem.
4. Design the Decision First
The practical implication is a shift in where you invest your first effort. Before writing a single line of code or pulling a single dataset, the most valuable thing an analytical team can do is map the decision — who owns it, what inputs it requires, what the cost of getting it wrong looks like, and what a structurally better process would need. That map determines almost everything else: what to model, what to surface, how to structure the interface, what to automate.
Decision Map. A specification of the decision owner, the required inputs, the cadence, the cost of error, and the structural constraints under which the choice is made. The map precedes the model.
The cost of skipping this step is not abstract. Every day a decision runs without structure, the organization absorbs an unpriced loss. A rough but useful formalization:
\[ \text{Cost of inaction} = L \times D \]
where \(L\) is the latency in days before a structured process replaces the current one and \(D\) is the daily exposure in dollars from suboptimal allocation. A weekly staffing decision with $2,000 daily exposure and a 90-day implementation delay costs $180,000 in unrecovered value before the first improvement ships. Most organizations never compute this number. They should.
This is the pattern from Section 1, seen from the other side. The teams that built polished dashboards nobody used did not lack data or skill. They lacked a decision map. The investment that would have prevented that failure is not technical — it is architectural, and it starts before the first line of code.
Design Principle
Organizations that treat analytics as an information function will keep producing reports that inform without changing behavior. Organizations that treat analytics as decision infrastructure will build systems that reduce latency, improve allocation, and compound in value over time.
5. Codified Rules
The principles above reduce to four binary gates. An analytics initiative that fails any gate is building information, not decision infrastructure.
| Gate | Condition | Action |
|---|---|---|
| G1 | No decision owner identified before design begins | → Stop. Map the decision first. |
| G2 | Decision cadence undefined or > 30 days | → Define the cadence. Decisions without rhythm become reports. |
| G3 | Cost of inaction unquantified (\(L \times D\) unknown) | → Estimate exposure. Unpriced latency is invisible waste. |
| G4 | System answers “what happened?” but not “what should change?” | → Redesign. Information without action logic is a dashboard, not infrastructure. |
These gates are binary — a project either passes or it does not. The value of making them explicit is that failure becomes diagnosable before the first line of code ships.
References
- Davenport, T. H., & Harris, J. G. (2007). Competing on Analytics: The New Science of Winning. Harvard Business School Press.
- Provost, F., & Fawcett, T. (2013). Data Science for Business: What You Need to Know about Data Mining and Data-Analytic Thinking. O’Reilly Media.
- Kahneman, D., Sibony, O., & Sunstein, C. R. (2021). Noise: A Flaw in Human Judgment. Little, Brown Spark.
- Howard, R. A., & Abbas, A. E. (2015). Foundations of Decision Analysis. Pearson.
- Shmueli, G. (2010). To Explain or to Predict? Statistical Science, 25(3), 289–310.
- McAfee, A., & Brynjolfsson, E. (2012). Big Data: The Management Revolution. Harvard Business Review, 90(10), 60–68.
- Seddon, P. B., Constantinidis, D., Tamm, T., & Dod, H. (2017). How Does Business Analytics Contribute to Business Value? Information Systems Journal, 27(3), 237–269.