When the Problem Isn’t the Technology

Across four independent fields, large projects fail at the same point — and it has little to do with the tools

A company is running five different software systems that all do roughly the same job. Everyone agrees this is wasteful. Four of the five should go. Leadership funds a project to remove them. Consultants arrive. Two years later, all five systems are still running — and a sixth has appeared.

This is not a story about incompetence, and it is not a story about technology being hard. The tools to consolidate systems are mature. The people doing the work are capable. The project fails for a reason that sounds almost too simple: nobody can answer basic questions about the systems they are trying to remove. What does this one actually cost? Who has the authority to switch it off? What else will break if we do? When those questions have no retrievable answer, the safe choice is always to keep the system «just in case.» So it stays.

This article makes one claim, and only one. When efforts to simplify, automate, or improve an organization fail, the binding cause is, time and again, informational rather than technical. What is missing is not a better tool or a smarter model. What is missing is the organization’s knowledge of how its own work actually works — and the decision that knowledge would make possible. There is a paradox folded into this, which the four cases below make plain: the tools that fail are the very ones we reach for to know and to order our organizations.

The reason to take the claim seriously is that the same failure shows up in four independent fields, none of which borrowed the idea from the others.

1. Cleaning up duplicate systems (rationalization)

This is the story above, and it is the best-documented of the four. Organizations accumulate overlapping systems and periodically try to cut them back. They mostly fail. The analyst firm Gartner has long observed that rationalization initiatives seldom deliver the benefits they promise. McKinsey’s research on technical debt is blunter still: roughly half of the firms that completed modernization programs did not actually reduce the debt they set out to reduce, and in one survey 60% of chief information officers said their technical debt had grown over the previous three years — the opposite of the intended result.

The mechanism is informational. A cleanup tends to remove the systems that were already dead — the ones nobody used anyway. The live systems survive, because retiring one safely requires facts no one can produce: its full cost, its real owner, the hidden things that depend on it. The set of systems you can safely remove and the set that actually carries the waste turn out to be almost completely different. The decision is not blocked because it is technically difficult. It is blocked because the information that would justify it does not exist in any form you can retrieve.

2. Rolling out artificial intelligence

Companies buy or build AI, point it at their data, and most of the time it never reaches real use or never pays off. A 2024 RAND study, based on interviews with 65 data scientists and engineers, found that more than 80% of AI projects fail — about twice the failure rate of ordinary IT projects — with inadequate data and infrastructure among the leading causes (Ryseff, De Bruhl & Newberry). A 2025 MIT report found that, despite enormous spending, the great majority of organizations saw no measurable impact on their bottom line. A survey by S&P Global Market Intelligence recorded the share of companies abandoning most of their AI initiatives jumping from 17% to 42% in a single year. Gartner projects that most AI projects not supported by «AI-ready data» will be abandoned.

The most telling detail is what the failure is blamed on. Across thirty years and every successive wave of technology — data warehousing, then CRM, then big data, then data science, now generative AI — the number-one reported root cause has stayed exactly the same: the data isn’t ready. The technology changed completely each time. The blocker did not. That points to a cause sitting upstream of the technology. A capable model still works in the laboratory; what it cannot do is supply an organization’s missing knowledge of its own processes. Drop a powerful model into a company that cannot describe how its own work flows, and it inherits the confusion rather than curing it.

3. Discovering how work flows (process mining)

Process mining is a family of techniques that reads the digital trail your systems leave behind and reconstructs how a process actually runs — where it loops, stalls, or doubles back. It is, by design, a discovery tool: it exists precisely to recover process knowledge an organization doesn’t already have.

It has a catch that makes the point sharply. To run at all, it needs an «event log,» and to build one you must first decide what counts as a single run of the process (specialists call this the case notion) and pull the right records from the right places. Both steps require knowing the process before you can discover it. The field’s founding figure, Wil van der Aalst, made data quality the first principle of the discipline. Researchers have catalogued eleven recurring flaws that quietly ruin event logs (Suriadi and colleagues). Studies of real systems find that reconstructing a single purchasing process can require pulling data from more than thirty scattered database tables — and that only someone who already understands the business can identify which tables matter, because business systems are organized around documents, not processes. Even recent attempts to automate this with AI report that they only work when human domain knowledge is already on hand.

So the tool built to recover lost process knowledge needs a minimum of that same knowledge just to start. Where the knowledge is most absent — which is exactly where you most need to discover it — the tool struggles most.

4. Setting automated limits (guardrails and monitoring)

A guardrail is an automated limit that watches a system and raises an alarm when something moves outside safe bounds: a server overheating, a machine vibrating, a model drifting. Common in operational and machine-learning systems, the mechanism almost always works. What breaks is the human step before it: someone has to decide where «normal» ends and «alarming» begins, and that requires knowing the true operating range of this particular system.

A 2025 study of practitioners who monitor machine-learning systems found that configuring these thresholds is one of the hardest parts of the job and a direct cause of «alert fatigue.» Fault-detection research names the need for scarce expert knowledge to set thresholds as a core limitation. The trouble is that a fixed limit is wrong by construction — a load that is perfectly normal on a busy machine is a danger sign on an idle one. When limits are set without real knowledge of the system, they flood people with false alarms; people stop trusting the alarms and switch them off, which undoes the entire investment. Alarm fatigue is documented as one of the top medical-technology hazards for exactly this reason.

Why the same story four times is the point

These are four fields that work in isolation from one another: an IT housekeeping discipline, the rollout of a new technology, an academic process-discovery method, and the operational practice of monitoring. They use different tools, different experts, different vocabularies. And they fail at the same spot — the moment when knowledge of how the work actually works has to be supplied, and isn’t there.

There is a sharper way to see what binds them. These are not arbitrary activities. They are the very instruments an organization reaches for in order to understand itself and put itself in order. Rationalization exists to create order. Process mining exists to discover how work flows. AI is deployed to turn what a company knows into value. Guardrails exist to hold a system inside known limits. Every one of them is a tool for producing knowledge or order — and every one is defeated by the absence of the very knowledge or order it was built to produce. That is the paradox at the heart of the pattern: the instruments of order fail for lack of the order they exist to create. You cannot mine a process you do not already partly understand; you cannot automate a process whose shape no one can state; you cannot guard limits no one has defined; you cannot retire a system whose value no one can establish.

When four independent fields converge on one failure point, the convergence is itself the evidence. It is hard to wave away as coincidence or as anyone’s bad luck. It suggests the failure is structural: it lives in the organization’s ability to know and govern its own processes, not in the quality of any tool aimed at them.

What this does and doesn’t prove

Two honest limits keep the claim defensible.

First, this describes a deficit — a shortage of usable process knowledge that exists right now — and not a claim that the situation is steadily getting worse over time. Whether organizations are actually decaying year over year is a separate and harder question that needs longitudinal measurement to answer. The persistence of «the data isn’t ready» across decades shows the problem keeps recurring, which is a strong sign of non-convergence; it is not the same as proof of decline, and the two should not be confused.

Second, the claim is testable, which is what keeps it honest. If these efforts failed just as often when full information was available — failing for the tools’ own technical reasons — the claim would be wrong. The pattern is that they don’t. They fail where the knowledge is missing, even when the tools are mature and the people are capable. If future evidence showed the reverse, the claim should be abandoned.

Why it matters

The comfortable assumption is that the next tool will fix it: faster cloud, cheaper storage, smarter AI. But if the bottleneck is missing knowledge of your own processes, no tool can supply it. A tool can only act on what is already known. The scarce resource turns out not to be computing power, or even talent. It is the human capacity to understand how the work actually works, and to decide how it should — and that is precisely the thing automation cannot manufacture on your behalf.

Sources

Figures are drawn from public sources as of early 2026 and should be read as benchmarks rather than precise statistics.

• Rationalization & technical debt — Gartner, on the limited benefits realized by rationalization initiatives; McKinsey & Company, research on technical debt (share of modernization programs that failed to reduce debt; 60% of CIOs reporting rising technical debt over three years).
• AI deployment — Ryseff, J., De Bruhl, B., & Newberry, S. (2024), The Root Causes of Failure for Artificial Intelligence Projects, RAND Corporation; MIT NANDA, The GenAI Divide: State of AI in Business (2025); S&P Global Market Intelligence, Voice of the Enterprise: AI & ML, Use Cases (2025); Gartner projections on AI-ready data.
• Process mining — van der Aalst, W. M. P., Process Mining Manifesto; Suriadi, S., Andrews, R., ter Hofstede, A. H. M., & Wynn, M. T. (2017), event-log imperfection patterns; systematic reviews of event-log extraction (case-notion specification and domain-knowledge requirements in ERP systems).
• Guardrails & monitoring — practitioner study of monitoring machine-learning systems (2025); fault-detection literature on threshold setting and expert domain knowledge; clinical and industrial research on alarm fatigue (ISA standards bodies; medical-technology hazard rankings).