Why projects still fail - wou can do better
Despite agile methodologies, advanced tools, and modern project frameworks, one old problem persists in the world of software development: projects are delivered late, over budget—or not at all. Numerous studies confirm this, and the root causes are rarely technical in nature. They’re structural.
According to the Standish Group’s CHAOS Report (2020), only 31% of IT projects are considered successful (delivered on time, on budget, and with the expected features). Over half are “challenged,” and 17% fail outright. Even more alarming are the findings of a joint study by McKinsey and the University of Oxford, which reveals that large IT projects (over $15 million in budget) overrun their costs by 45% on average and deliver 56% less value than expected. For 17% of those projects, failure poses a threat to the company's very survival.
So what’s behind these failures?
Estimation Errors Are a Symptom, Not the Disease
Falsche Schätzungen sind ein Problem – aber selten das eigentliche. Meist sind sie das Ergebnis tieferliegender struktureller Defizite. Wenn IT-Initiativen scheitern, sind vier Ursachen besonders häufig:
1. Stake1. Stakeholder Misalignment – When Everyone Pulls in a Different Direction
In 70% of failed projects, decisions were made by stakeholders outside the team that fundamentally disrupted the planning basis (source: Mittelstandcafe.de). Misaligned goals, a lack of shared vision, and poor communication between business, IT, and users result in estimates based on incorrect or outdated assumptions.
The fix: Establish structured stakeholder involvement early and continuously. Ensure transparency in decisions, align priorities frequently, and treat stakeholder management as a strategic discipline—not a side task.
2. Lack of Risk Management – When Surprises Derail the Plan
It’s not the risks themselves that kill projects—it’s the fact that nobody saw them coming. Proactive risk management is still missing in many organizations. Contingency planning is often an afterthought, leaving teams vulnerable to changes in personnel, legal disruptions, or technology failures.
The fix: Implement real, operational risk management. Run regular risk assessments, maintain a living risk register, and include mitigation plans as part of your delivery strategy.
3. Poor Requirements Engineering – Building on Sand
Unclear, incomplete, or unstable requirements are a leading cause of project failure. Yet many teams still begin implementation based on vague or shifting goals. This leads to rework, scope creep, missed expectations—and ultimately, poor delivery.
The fix: Treat requirements engineering as a core craft. Involve cross-functional teams in defining, prioritizing, and validating requirements iteratively. Use structured methods like user stories, acceptance criteria, and traceability matrices to create a solid foundation.
4. Flawed or Missing Estimation Methods – Guesswork Isn’t Strategy
Many organizations still rely on back-of-the-napkin estimates, gut feelings, or outdated templates. This is especially dangerous in high-stakes environments. As shown by the McKinsey study, poor forecasting leads to budget blowouts and massive value loss.
The fix: Use structured estimation techniques like Planning Poker, Wideband Delphi, Three-Point Estimates, or Monte Carlo simulations. Leverage historical data and modern tools—including AI-powered forecasting systems, which 86% of German project managers now use according to PMI (source: Haufe.de).
The Case for Sustainable Product Development
Product development today is more complex than ever: distributed systems, fast-evolving markets, regulatory requirements, global teams, and AI-driven innovation. This rising complexity can’t be managed with reactive project firefighting or ad hoc planning.
What we need is a shift toward sustainable product development, built on:
- effizient Stakeholder Management
- Modular and reuse-focused requirements engineering
- Systems thinking instead of linear task tracking
- Stable and sustainable estimation methodologies
- A culture of responsibility where quality matters more than speed
Conclusion: It’s Not an Estimation Problem – It’s a Structural One
Faulty estimates are not a sign of poor technical skill—they are often symptoms of organizational dysfunction. To build better software, we must first build better systems of collaboration, planning, and learning.
Sustainable Product Development isn’t just a nice-to-have. It’s the only viable response to the ever-increasing complexity of our digital world..