Why IT Projects Rarely Fail Due to Technology—But Often Due to Unclear Requirements

When an IT project fails, the blame is often placed on technology:

The software wasn’t mature enough.
The vendor delivered poorly or not at all.
The architecture was unsuitable for the problem.
The developers were overworked.

In reality, however, the real issues often arise much earlier—long before the first line of code is written. They emerge when projects are launched with unclear goals, conflicting expectations, and poorly defined requirements. The consequences usually only become visible months later—but then with full force.

The Most Expensive Mistakes Happen in the First Few Weeks

At the start of many projects, there is immense time pressure.
The budget is finally approved, the project can begin, and the business department—which has been waiting for a solution for months—naturally pushes for rapid implementation. This creates a strong temptation to shorten the analysis phase, especially since teams have already discussed the problems and desired features for a long time.

This is where the first major mistake often occurs:
A misunderstanding in a requirements workshop may cost just a few minutes. The same misunderstanding after go-live can cost hundreds of thousands of euros.

As software engineering pioneers Barry Boehm and Victor Basili demonstrated in the late 1970s, errors detected in later project phases are exponentially more expensive to fix than those caught during requirements analysis. In many cases, correction costs increase ten- to a hundredfold. They referred to this phenomenon as the “Cost Escalation Factor”.

Saving time on analysis rarely saves money—it merely shifts costs to later phases.

The Numbers Are Alarming

Poor requirements are not just a theoretical problem—they have real-world consequences. Numerous studies highlight this:

The Project Management Institute (PMI) identifies inadequate requirements management as a key reason why projects fail to meet their goals.
Research by the International Institute of Business Analysis (IIBA) and IAG Consulting found that poor requirements in large projects can lead to cost overruns in the millions.
A study by Bent Flyvbjerg and Alexander Budzier (University of Oxford), based on 1,471 IT projects, revealed that projects exceed their budgets by an average of 27%. Even more critically, one in six projects became a “black swan,” overshooting planned costs by 200% on average while also facing severe delays. The root causes were rarely technological but instead stemmed from unclear objectives, unrealistic assumptions, and inadequate requirements definition.

The Costliest Misconception: Confusing Features with Value

A common mistake is that organizations describe what features a system should have in great detail but fail to define what value it should deliver.

The result? Specifications that look impressive on paper but miss the actual business need. Users only realize during operation that the system doesn’t support their daily work.

Instead, the right questions should be asked:

What problem is being solved?
Which key performance indicators (KPIs) should improve?
How will success be measured?
What value justifies the investment?

Without answering these, the outcome is often a system that meets all requirements yet is still perceived as a failure—not because the software is bad, but because the expected value was never clearly defined.

Poor Requirements Trigger a Domino Effect

High costs from poor requirements are not just due to expensive late-stage changes. The real damage comes from:

Procuring the wrong solution
Project delays
Claim and change management
Budget overruns
Increased testing efforts
Low user adoption and productivity losses
Missed business goals
Additional operational and integration costs
Loss of trust in IT projects

These costs are difficult to quantify but often far exceed development expenses—and their impact can linger for years after go-live.

Why Requirements Management Is a Leadership Responsibility

Requirements engineering is often seen as an operational task. In reality, it is risk management in the context of investment decisions.

Good requirements provide transparency on:

Goals
Value
Scope
Risks
Priorities
Quality

They form the foundation for sound decision-making. The larger and more complex a project, the more critical this transparency becomes.

Conclusion

Most IT projects don’t fail due to a lack of skills or technology. They fail because different stakeholders have different understandings of what should be achieved—or because the value the system is supposed to deliver was never properly defined.

This is why requirements are far more than just documentation. They are the basis for Investment decisions, Tender processes, Architecture, Development, Testing and Operations.

Those who skip professional requirements management aren’t saving effort—they’re taking a gamble. A gamble that all parties share the same understanding of the project and its goals.

Experience shows: This bet is lost surprisingly often.

The costs of poor requirements rarely hit all at once. Instead, they accumulate through poor decisions, rework, delays, and missed value—often exceeding the original investment in professional requirements analysis many times over.

Sources & Further Reading

Project Management Institute (PMI): Pulse of the Profession
https://www.pmi.org/learning/thought-leadership/pulse
Flyvbjerg, B.; Budzier, A. (2011): Why Your IT Project May Be Riskier Than You Think, Harvard Business Review
https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think
Boehm, B.; Basili, V. (2001): Software Defect Reduction Top 10 List, IEEE Computer
https://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf
Consortium for Information & Software Quality (CISQ): The Cost of Poor Software Quality in the US
https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/
IAG Consulting: Business Analysis Benchmark Report
https://www.iag.biz/business-analysis-benchmark-2008/