The most common problems in IT projects

Why IT projects get derailed

Every IT project is a multi-layered process: from analysis and design, through development, to delivery. It only takes one element to fail for the entire project to lose momentum or end in failure. Here are the most common challenges that recur time and again.

Poorly defined business requirements

It is estimated that around 39% of failed projects collapse because of poorly defined requirements. Without a clear and realistic description of what is to be built, it is difficult to deliver a product that meets the objective, on time and within budget. A common mistake is to develop requirements in isolation from the delivery team, which is then expected to take responsibility for implementing them.

A typical scenario: the business team spends many months creating a document several hundred pages long. When developers begin the work, architectural problems come to light that undermine most of its assumptions – the requirements need to be substantially rewritten.

To prevent this, involve subject-matter experts as early as the scope definition stage: business representatives, IT and – if possible – end users. The business side defines what is to be achieved, while IT designs how to build it. When these two streams work in parallel, the risk of flawed or incomplete requirements falls dramatically.

Case study: Qantas and the Jetsmart project

In 2008, Qantas cancelled the $40 million Jetsmart initiative – a parts management system for aircraft mechanics. The solution proved so poorly designed and complicated that mechanics refused to work with a tool that increased their workload. The company admitted it had built what it believed was right instead of asking users what they actually needed. The lack of involvement from key experts – the end users – ended in failure and financial loss.

Project sponsors not engaged in delivery

A common problem is so-called development in a vacuum: the sponsor provides general requirements and then waits for the finished product. The team has no one to direct questions to, so it guesses. If it guesses wrongly, that only becomes apparent once the work is complete – resulting in sponsor dissatisfaction, a product unsuitable for implementation, costly rework, delays and budget overruns. According to a PMI study from 2017, inadequate sponsorship and support account for 27% of IT project failures.

The antidote is continuous involvement from the sponsor or an appointed business representative during development: answering questions, providing quick clarifications and regularly reviewing work in progress to ensure the direction remains aligned with the original objectives.

Case study: HealthCare.gov

One of the most notorious failures of the past decade was the launch of HealthCare.gov in 2013. The service was meant to enable the purchase of health insurance through private exchanges. In its first days, it was visited by more than 8 million people, yet only a fraction of users were able to register successfully. The investigation revealed poor communication and a serious lack of involvement from key stakeholders. Senior leadership was excluded from critical meetings, and the technical status of the project was not transparent – which translated into a chaotic launch.

Changes to project goals and scope

Every project balances three constraints: time, scope and budget.

In the Waterfall model, time and scope are usually fixed, while the budget remains flexible – if the full scope cannot be delivered on time, additional resources are added to increase capacity.

In the Agile approach, time and budget are fixed, while scope is flexible. Because projects rarely follow the plan perfectly, teams regularly reprioritise in order to deliver the greatest business value on an ongoing basis.

Most Agile teams work in Scrum: short iterations (1–4 weeks), planning at the start of the sprint, no changes during the sprint and the ability to reposition work for the next cycle. The role of the scrum master and project manager is to maintain the rhythm and remove obstacles.

Changes in goals cannot be eliminated entirely, but they can be brought under control with a process that supports controlled adaptation. Although 36% of failed projects attribute failure to changing goals, a change of plan does not necessarily mean failure.

A practical way to reduce risk is to shorten the planning horizon. Plan in two-week iterations, focusing on the most important work that can realistically be completed in that time. The team remains focused on priorities and delivers releasable code on a cyclical basis. An experienced project manager also helps by safeguarding priorities and stakeholder alignment.

Case study: FBI Virtual Case File

Between 2000 and 2005, the FBI was developing the Virtual Case File system, intended to replace its existing case management platform. After spending nearly $170 million, the project was abandoned. The software was assessed as incomplete, inadequate and so poorly designed that it was unusable in real-world conditions. An overly broad scope and frequent specification changes were identified as the main sources of the problem.

Inaccurate estimates

The so-called cone of uncertainty illustrates well how difficult estimation is at the outset. When requirements and dependencies are still poorly understood, cost and time estimates can be under- or overestimated by as much as four times compared with reality. As the work progresses, variability decreases, but it only disappears once the project is complete.

Even so, estimates are necessary – sponsors need to assess whether the investment is worthwhile. On their own, they are rarely a direct cause of failure, although 28% of projects identify them as a contributing factor. They are usually a symptom of other problems, such as:

- Weak estimation practices and a lack of team experience

- Pressure for overly optimistic timelines and costs

- Lack of historical data and comparisons with similar work

- Unaccounted-for technical dependencies and risks

- Frequent scope changes without revising the plan

How can you estimate better and reduce risk?

- Estimate ranges with confidence levels instead of a single figure

- Update estimates iteratively as your understanding of the scope improves

- Involve the entire team and domain experts in the estimation process

- Use historical data and short technical experiments

- Do not freeze both a fixed scope and a non-negotiable deadline at the same time

Summary

The most common causes of problems in IT projects are flawed requirements, a lack of an active sponsor, uncontrolled changes in objectives and inaccurate estimates. The key is early and continuous stakeholder involvement, iterative planning with clear priorities, and conscious risk management. That is how projects are built to deliver value – predictably and with resilience to change.