Why IT Projects Fail: Coordination, Decision Loops, and the Cost of Unvalidated Action

Introduction

In large IT and digital transformation programs, one contrast becomes visible over time. Projects that begin with comparable budgets, similar technologies, and equally capable professionals can evolve in very different ways. Some develop clarity, predictability, and steady progress. Others gradually enter cycles of urgency, friction, and rework.

This contrast invites a serious question. If intelligence, funding, and executive commitment are present, why do so many IT projects still struggle?

A closer look at industry data and academic research suggests that the root causes are less technical than organizational. They lie in how decisions are coordinated, how assumptions are validated, and how complexity is structured.

The Scale of the Problem

The magnitude of underperformance in digital transformation is well documented. Reporting in the Financial Times, citing McKinsey and Gartner data, indicates that approximately 70 percent of digital transformation initiatives fail to meet their objectives [1]. Academic reviews of project management literature similarly conclude that organizational and managerial factors dominate failure causes [2].

Failure, therefore, appears structural rather than accidental.

Uncoordinated Intelligence in Complex Systems

A recurring pattern in complex delivery environments is that capable individuals act with good intentions but insufficient synchronization. An engineer, architect, or manager identifies what appears to be the correct approach and proceeds without structured validation, explicit interface checks, or formal alignment confirmation.

As task interdependence increases, coordination requirements grow disproportionately — a dynamic documented in coordination theory [3]. When coordination mechanisms are informal or inconsistent, local optimizations can create systemic misalignment.

Project management research repeatedly highlights unclear responsibilities, weak communication structures, and insufficient governance as major contributors to underperformance [2].

The issue is rarely intelligence. It is the absence of engineered coordination.

Reinforcing Feedback Loops: From Misalignment to Emergency

Project instability often emerges through reinforcing feedback loops.

Systems theory demonstrates how reinforcing loops amplify small disturbances into larger systemic effects [4]. In project environments, early coordination failures trigger reactive behavior. Under pressure, decisions are made more quickly and with less validation. These rushed decisions increase downstream problems, intensifying urgency and further reducing disciplined thinking.

What begins as a minor unvalidated assumption can evolve into sustained instability.

Conversely, when early decisions are validated and risks clarified, fewer downstream surprises occur. Reduced urgency enables better decisions, creating a virtuous cycle of predictability.

Failure and success both compound.

The Coordination Paradox and Invisible Loss

If coordination is essential, why is it frequently avoided?

The asymmetry lies in measurability. Coordination has an immediate and visible cost — meetings, documentation, review cycles. The cost of insufficient coordination, however, is delayed and diffuse. Its consequences may appear in another subsystem or later phase, making causal attribution difficult.

Systems theory explains how delayed feedback obscures learning [4]. Because the benefit of proper coordination exists only in a counterfactual scenario — the problem that never materialized — its value remains invisible. Organizations experience the visible cost of alignment but rarely the measurable benefit of prevented misalignment.

This asymmetry leads to systematic underestimation of coordination value and overestimation of its burden.

Designing for Minimal Necessary Coordination

The solution to uncoordinated action is not endless coordination. It is minimal necessary coordination, enabled by clear guardrails and explicit interfaces.

Coordination theory explains why this matters: as tasks become more interdependent, coordination needs increase and become harder to manage informally [3]. In large IT programs, ambiguity about ownership and interaction boundaries creates predictable failure patterns. People either coordinate too little and create downstream integration issues, or coordinate excessively and create organizational drag.

Herbert Simon’s theory of near-decomposable systems offers a structural answer: stable complex systems are modular, with high internal cohesion and limited external coupling [5]. The practical implication is that coordination should happen intensively inside well-defined boundaries, while cross-boundary coordination should be deliberately limited and formalized.

This requires two design elements.

First, guardrails must be explicit. Guardrails define what can be decided locally and what requires cross-domain alignment. Without guardrails, individuals must guess when to involve others, which produces inconsistent behavior and predictable errors.

Second, interfaces must be unambiguous. Interface clarity makes cross-team impact visible. It turns coordination from a social negotiation into an engineering activity. If the interface contract is explicit, teams can move quickly without repeatedly renegotiating assumptions.

A practical set of guardrail questions makes this operational:

• Does this change impact another domain, team, or component outside the defined boundary?
• Does it modify an interface contract, data contract, or integration behavior?
• Does it introduce a dependency another team must maintain?
• Does it affect security, performance, compliance, or reliability?
• Does it invalidate previously agreed assumptions?

If the answer is no, the decision can be taken locally. If the answer is yes, coordination is part of system integrity.

When guardrails and interface clarity are designed upfront, coordination becomes selective rather than constant. The organization avoids both isolation and bureaucracy while reducing the probability of reinforcing failure loops.

Premature Convergence and the Discipline of Validation

Another contributor to project fragility is premature convergence on a single solution.

Decision science demonstrates that individuals are prone to confirmation bias and early anchoring, often committing to a preferred idea before alternatives are rigorously explored [6]. In project environments, this manifests as rapid movement into implementation without structured option evaluation.

Structured validation — peer review, assumption testing, and alternative comparison — reduces this risk. Without it, early decisions feed reinforcing loops of rework and instability.

Disciplined thinking must precede disciplined execution.

AI Acceleration and the Risk of Faster Failure

Artificial intelligence has dramatically reduced friction in software development. Code can be generated rapidly, prototypes assembled quickly, and integrations accelerated.

This velocity alters coordination dynamics.

When execution becomes easier, the perceived cost of acting without full validation decreases. The pause between idea and implementation compresses. As a result, unvalidated decisions can enter systems more frequently.

The concept of technical debt explains how short-term speed can create long-term structural fragility [7]. Architectural shortcuts, when accumulated, increase future coordination complexity and systemic risk.

AI does not eliminate cognitive bias [6], nor does it enforce architectural discipline. Without structural guardrails, faster development amplifies reinforcing loops rather than resolving them.

Acceleration without architecture increases instability.

Conclusion

The persistent underperformance of IT and digital transformation initiatives cannot be attributed primarily to technological limitations. Industry evidence and academic research converge on a deeper insight: complex projects fail when uncoordinated and insufficiently validated decisions accumulate and reinforce one another.

Projects succeed when coordination, validation, modular design, and explicit guardrails are engineered deliberately into the organizational system.

In complex environments, coordination is not overhead.

It is infrastructure.

References

[1] Financial Times. 70 per cent of transformation projects fail – and everyone’s ignoring the same fix.
https://www.ft.com/partnercontent/teamviewer/70-per-cent-of-transformation-projects-fail-and-everyones-ignoring-the-same-fix.html

[2] Alias et al. (2014). Success Factors in Project Management: Literature Review.
https://www.researchgate.net/publication/293924639_Success_Factors_in_Project_Management_Literature_Review

[3] Malone, T., & Crowston, K. (1994). The Interdisciplinary Study of Coordination.
https://dspace.mit.edu/handle/1721.1/2133

[4] Forrester, J. (1961). Industrial Dynamics.
https://web.mit.edu/sysdyn/sd-intro/

[5] Simon, H. (1962). The Architecture of Complexity.
https://www.jstor.org/stable/25041247

[6] Kahneman, D. (2011). Thinking, Fast and Slow.
https://us.macmillan.com/books/9780374533557/thinkingfastandslow

[7] Kruchten, P., Nord, R., & Ozkaya, I. (2012). Technical Debt: From Metaphor to Theory and Practice. IEEE Software.
https://ieeexplore.ieee.org/document/6148383