CentriWebWhy software projects fail is rarely mysterious. Most go wrong because the scope was unclear, decisions were slow, real users saw the work too late, or nobody on the business side owned the result. Each has early signs you can spot in the first few weeks, while there is still time and money to change course.
This article is written for the person paying for the software rather than the person building it. It deliberately gives no failure percentages, because the figures quoted online differ widely and depend on how failure is defined. What matters is that you can see trouble coming.
What counts as a failed project
Failure comes in degrees. A project can be cancelled. It can be delivered but never used. It can arrive late and over budget but still be worth having. Or it can launch and slowly be abandoned because it does not match the work. The last two are the most common and the least talked about.
Defining success before you start is the best protection. Ask: what will be different in the business in six months if this works, and how will we know?
Why software projects fail: the five patterns
| Pattern | Early sign | What to do |
|---|---|---|
| Unclear scope | Different people describe the project differently. “We assumed that was included.” | Write a one-page scope with an out-of-scope list and have everyone sign it off |
| Slow or missing decisions | Questions sit unanswered for days. The developer is waiting on you. | Name one decision-maker and a response time |
| Late testing with real users | The first time staff or customers see it is at the end | Show working software every one or two weeks, to real users |
| Scope growth | “Can we just add…” appears every week and nothing comes off the list | Keep a later list, and trade items in and out instead of adding |
| Nobody owns the outcome | No one on your side is responsible for adoption, data or training | Give one person the job, with time to do it |
Pattern one: unclear scope
When the scope is vague, the developer fills the gaps with assumptions, and you discover them at demo time. The price in the quote is for the project they understood. The price you pay is for the project you meant.
The fix is boring and effective: write it down. A short software requirements document with users, tasks, rules, exclusions and acceptance tests turns arguments into checks. If a developer will quote only a rough figure with no questions, treat that as a sign too.
Pattern two: slow decisions
Software teams make hundreds of small decisions a week. Some are theirs. Many belong to the business: what should happen if a customer cancels part-way, who can approve a discount, what the report should show. Each unanswered question either stops work or lets the developer guess.
Early sign: your inbox has a growing list of unanswered questions from the team. Name one person with authority and agree a response time, such as one business day. When that person is also running the business, block out a fixed slot each week for project questions, so answers do not compete with everything else for attention. If you cannot give that time, say so at the start and plan for it in the schedule.
Pattern three: users see it too late
A project can pass every internal check and still fail because it does not fit how people work. The only way to find out is to put it in front of the people who will use it, early and often.
Worked example (invented): a builder commissions an app for site supervisors to record daily progress. The developer builds it on the assumption that supervisors have good mobile signal. The first time a supervisor tries it on a rural site, it loses the entry. Had a supervisor tried a rough version in week two, the fix would have taken a day. Found at launch, it means reworking how the app stores data.
Early sign: no one outside the project team has touched the software yet. Get a real user to complete a real task in the first weeks, even on an unfinished version.
Pattern four: scope growth
Every request sounds small. Together they change the project. A rule of thumb is that anything added should push something else out or change the schedule, and the change should be written down and priced before work begins.
Early sign: the list of features grows while the date and budget have not moved. Something has to give, and it is usually quality or the end date.
One more habit helps: keep a short decision log, with the date, the decision and who made it. When memory differs six weeks later, the log settles it in a minute.
Pattern five: nobody owns the result
Software does not deliver value by being finished. It delivers value when people use it. That needs training, a decision about when the old way stops, clean data, and someone who chases the people who revert to the old process.
Early sign: when you ask who is responsible for rollout, there is a pause. Assign the person early. If the project is replacing a spreadsheet, our guide on moving from a spreadsheet to an app covers the changeover.
Warning signs on the developer’s side
- Progress reports describe activity rather than working software.
- Demos are repeatedly postponed or consist of slides.
- The developer cannot explain their testing, backups or how they handle faults.
- You cannot see the code or the working system on your own account.
- Staff turn over and nobody explains who is now responsible.
- Estimates change without a reason you can follow.
Make sure the contract says who owns the code and accounts: see who owns the code. Not being able to leave is itself a risk.
A checkpoint routine that catches trouble early
- Every week or two: a demo of working software, with a list of what changed and what is blocked.
- At the end of the first month: ask whether you would sign the same contract today knowing what you now know. Review scope, schedule and spending against what has been shown.
- Before each payment: match it to something you have seen working, rather than only time spent.
- Before launch: have a few real users run the main tasks and record what they struggle with.
- After launch: agree a review date to compare results with the success definition you wrote at the start.
What good looks like in the first month
A healthy project has a rhythm you can see. By the end of the first few weeks you should expect:
- A written scope with an out-of-scope list that you have read and agreed.
- A named person on each side who answers questions.
- A test version you can open, even if rough, on an address you control.
- A list of open questions and risks that the developer raises as well as you.
- A real user having tried a core task and given feedback.
If most of these are missing, raise it now. A conversation in week three costs a few hours. The same conversation in month four costs the project.
If it is already going badly
Stop adding features. Agree in writing what must work for the project to be worth finishing. Take a dated copy of the code and data. Ask an independent developer to look at the state of the work. Then decide whether to continue, change the plan or rebuild part of it. Starting again is sometimes cheaper than repairing, but it is a decision to make on evidence.
Smaller first releases lower the risk, because you learn sooner. Our guide to MVP cost and timeline explains that approach. Construction and building firms face many of these same risks, as our page on construction explains.
CentriWeb builds custom software with working demos along the way and one team accountable for the whole system. We make no promise about timing or outcome, but we are glad to look at a project that worries you.