IT projects fail mostly because of decisions made before development starts: an unclear definition of success, an estimate nobody on the client side owns, a scope written as a wish list, and no single person with authority to decide. Delivery problems come later, but they are usually symptoms. The early signs are visible within weeks if you know what to look at.
What counts as IT project failure?
Three very different outcomes get called failure, and confusing them is why so much advice on this topic is useless. Separating them tells you which one you are actually at risk of.
Cancelled before delivery. Money spent, nothing shipped. Loud, painful, and comparatively rare. It usually follows months of visible trouble that nobody acted on.
Delivered late or over budget. The system exists but cost more and arrived after the moment it was meant to serve. Often survivable, sometimes fatal if the business case depended on a season, a contract, or a funding round.
Delivered on time, on budget, and unused. Every requirement met, everyone paid, and six months later the operations team is still working in spreadsheets. It is the outcome least discussed, and the one no contract protects against. Nobody writes a post mortem for it because on paper the project succeeded.
Decide now which of the three would hurt you most. A project run to avoid overspend is managed differently from one run to make sure people use the result.
Can you trust IT project failure rate statistics?
Not as precise measurements, no. The best known figures on IT project failure come from industry reports whose methodology has been publicly criticised by researchers, including a critique of the CHAOS report figures, and researchers continue to publish comparative work on why reported failure rates differ so much.
Two things make any single percentage close to meaningless for your decision. Samples are self selected, so troubled projects are over or under represented depending on who was asked. And definitions of failure differ: as shown above, they describe three separate outcomes.
A more useful frame than an average is the spread. Some projects go far more wrong than the typical case, which is the concern raised in work such as Why Your IT Project May Be Riskier than You Think. Plan for the possibility that yours is one of those, not for the average.
When a vendor quotes a failure statistic at you, ask who was surveyed and how they defined failure. The answer tells you more about the vendor than the number does about your risk.
Which early decisions cause most IT project failures?
A handful of choices made in the first few weeks set the outcome, long before anyone can blame the developers. Each has a better version that costs almost nothing to adopt at the start and is expensive to retrofit later.
| Early decision | Failure it produces | Better version |
|---|---|---|
| Success defined as "deliver the features" | Delivered and unused | Two or three operational numbers that should move, measured before you start |
| Vendor writes the estimate alone | Overrun blamed on scope creep | Client challenges the estimate line by line and names what was assumed |
| Scope written as a feature list | Features conflict once built | Scope written as the workflows people perform, start to finish |
| Decisions made by committee | Stalled sign offs, idle developers | One named decision maker with authority and calendar time |
| Everything built before anything ships | Budget gone before first feedback | A usable slice in production early, then build on evidence |
| No named person who wants it | Rejected on rollout | A department head who asked for it and will be measured on adoption |
The last row matters more than people expect. Projects sponsored by IT or finance for a team that never asked fail on contact with that team. Find the person whose week gets better, and check they agree.
Scope is the other place to slow down. Writing the workflow (what happens when an order arrives, who touches it, what breaks today) surfaces conflicts on paper, where changing your mind is free. Our guide on choosing between an ERP and custom software works through that decision in more detail, including when the honest answer is to buy something off the shelf and stop.
Does fixed price protect you from project failure?
Fixed price moves the risk, it does not remove it. Under a fixed price contract the vendor absorbs overrun risk, so they price defensively and then protect their margin by interpreting the scope narrowly. Anything ambiguous becomes a change request. You get budget certainty on the written scope and open ended exposure on everything the scope failed to describe.
Time and materials moves the risk to you. The vendor has no financial reason to finish quickly, and unless you review output weekly, months can pass with visible activity and little working software.
What matters is which incentive you can supervise. Choose fixed price if your scope is genuinely well understood and you want a hard ceiling, and accept that you will pay for changes. Choose time and materials if you are still learning what to build, and only if you will personally review a working demo every week and can stop the work at any point.
Whichever you pick, three contract terms do more for you than the pricing model: you own the code and the accounts, the code is handed over at every milestone rather than at the end, and the engagement can be terminated on short notice. We wrote about the mechanics of that in why businesses keep getting burned by software agencies.
What are the warning signs, and when do they appear?
Vague symptoms like "poor communication" arrive too late to act on. These signals are countable, have a threshold, and appear early enough to change course.
| When | Observable signal | Threshold to act | What to do |
|---|---|---|---|
| Weeks 1 to 4 | No working demo of anything, only documents and diagrams | Nothing runnable by week 4 | Ask for the smallest working slice before approving more spend |
| Weeks 1 to 4 | You cannot name the end users who asked for this | Zero named users | Pause. Interview the team who will use it |
| Month 2 to 3 | Demo dates slip | Two consecutive slips | Cut scope for the next demo rather than extending the date |
| Month 2 to 3 | Change requests grow faster than completed features | Change log longer than delivered list | Stop and rewrite the scope from the workflow up |
| Halfway | Percentage complete stays near the same number for weeks | Three weeks flat | Ask what is done and deployed, not what is in progress |
| Halfway | Nothing is in the hands of a real user | Zero production users at 50% of budget | Ship one workflow to one team, even manually supported |
| Any time | Status reports are prose, not demos | Two reporting cycles without software running | Change the reporting format before changing the vendor |
One rule covers most of this: measure progress only by software running in an environment you can log into. Working software is hard to fake, and every other progress metric is an opinion.
Should you rescue or stop the project?
Answer one question first: if you were starting today, knowing what you now know, would you fund this? If no, stop. If yes, the problem is delivery and it is usually fixable. Money already spent is irrelevant to that decision, and the discomfort you feel reading that sentence is exactly why so many failing projects continue.
Rescue if the business need is still real, a named team still wants the result, and one clear cause explains the drift, such as unclear scope, an absent decision maker, or a team that is too junior for the problem. Rescue looks like this: freeze scope, define the smallest version that delivers one real workflow, ship that in weeks not months, then reassess.
Stop if the business reason has changed, the users do not want it, the estimate has been revised upward more than twice, or you cannot describe the finished product in a paragraph. Stopping is not a total loss. Recoverable value usually includes the requirements and workflow documentation, database design, any deployed component that works on its own, and a much better brief for whoever you hire next. Take a copy of the code and every account credential before the conversation about cancelling, not after.
Decide in advance who holds the authority to stop, and it should not be the person running the project. Their reputation is tied to finishing. Give the kill decision to a sponsor who can end it without personal cost, and put a scheduled review in the calendar at 30 percent and 60 percent of budget with a stop option explicitly on the agenda. A decision that is scheduled gets made. A decision that requires someone to be brave does not.
Common mistakes that turn problems into failures
- Adding people to a late project. New engineers consume the time of the ones who already understand the system. Reduce scope instead.
- Treating adoption as a training problem. If people avoid the system, the workflow is wrong. More training will not fix a screen that takes eleven clicks to do what a spreadsheet did in two.
- Approving change requests one at a time. Individually each looks reasonable. Review them monthly as a batch against the original goal, and reject the ones that serve nobody named.
- Hiding the trouble from the sponsor. Problems reported at month three get options. Problems reported at month nine get a cancellation.
- Building the whole thing before anyone uses part of it. A deliberately narrow first release exists to test assumptions while you still have budget to respond to what you learn.
If a project you own right now feels uneasy, do one thing this week: ask to log into a running version of whatever has been built so far and try to complete one real task in it. That single test tells you more about your risk than any status report, and it works just as well on internal teams as on outside vendors.