Why IT projects fail, and how to avoid it

It is rarely a technology problem

When an IT project goes wrong, the first explanation you hear is almost always technical: the software was not suitable, the supplier was not up to the job, the infrastructure could not cope. It is a convenient explanation, because it places the cause outside the company. In practice, when projects founder, the problem almost always lies upstream of the technology: nobody with the power to decide, scope that grows unchecked, adoption that was never really looked after once the system was released.

The first problem: scope that grows by itself

A project starts with a defined scope. Then, meeting after meeting, someone asks to add "just one more thing, while we're at it". Each individual addition seems small and reasonable. A few months later, they add up to a different project from the one that was approved, while the budget and timescales are still the original ones.

This phenomenon has a name, scope creep, and the answer is not to say no every time: the answer is a process for assessing every change request, with the impact on time and cost made explicit before it is accepted, and with someone who really has the authority to say "we'll do this in phase two".

The second: nobody with the power to decide

Many projects involve several departments, each with its own opinion, and nobody with the authority to close a discussion. The result is decisions taken because everyone is worn out, decisions postponed, or the same decision taken twice, in different ways, by different people.

You need a real project owner, not just one on paper: someone who has the mandate to decide, who is accountable for the outcome, and whose role the other people involved genuinely recognise. Without that person, even the best project management method becomes little more than a calendar of meetings.

The third: adoption neglected after release

A project is often considered finished at the moment of technical release: the system is up and running, the invoice has been issued. But a system that people do not use, or use badly because nobody trained them properly, has not delivered the value it was commissioned for.

Adoption needs to be designed as carefully as the system itself: training geared to people's real tasks, internal contacts to turn to in the first few weeks, a period of hands-on support before the project is considered truly complete.

The fourth: suppliers chosen on price, not on method

The lowest quote does not necessarily mean the cheapest project: it only does if the supplier delivers what it promised, when it promised. No working method, no risk register, no formal handling of change requests, and communication only when something goes wrong: that combination almost always costs more than a higher hourly rate backed by a sound process.

What to do differently

1. Choose the method to suit the context: predictive (waterfall) when requirements are stable and known from the outset, agile when the product takes shape as the work progresses, hybrid when you need a bit of both. It is a practical choice, not an ideological one.
2. Appoint a project owner with real authority, not just a name on a document.
3. Keep a risk and decision log and update it as you go, rather than writing it once and forgetting it.
4. Manage every change request formally, with the impact on time and cost made explicit before it is accepted.
5. Design adoption as part of the project, not as a separate activity after release.

Checklist before you start

• there is a project owner with real authority to decide, not just on paper;
• the project scope is written down and shared, and there is a process for assessing changes;
• there is a risk and decision log, kept up to date during the project;
• the supplier has a working method you can verify, not just a competitive price;
• time has been budgeted for training and adoption, not just for development;
• the project's success is defined by measurable criteria, agreed before starting.

In short