Most failed software projects were visibly in trouble months before anyone said so. The signals are consistent across clients, industries and budgets, and almost all of them are visible in the first four to six weeks.
Here they are, roughly in the order they appear, with what to do while it is still cheap.
Week 1 to 4: the early signals
1. Nobody can state what success looks like
Ask five people on the project what this software must achieve for the business. If you get five different answers, or vague ones, you do not have a project, you have a wish.
What to do: stop and write one sentence everyone signs off. “Reduce order processing time from two hours to fifteen minutes.” Everything gets measured against it.
2. No single decision maker on the client side
Requirements arrive from three people who disagree. The developer builds something, it goes to a committee, feedback contradicts. This is the most reliable predictor of overrun there is.
What to do: name one person with authority to decide within twenty four hours. Not a committee chair. One name.
3. The specification is a feature list
Twenty bullet points with no detail on rules, edge cases or who does what. “Inventory management” is a heading, not a requirement.
What to do: use a proper structure. Our requirements document checklist covers what belongs in one.
4. No demo scheduled before the end
If the plan is to show you the software when it is finished, the plan is wrong. Problems compound in silence.
What to do: insist on something working and clickable every two weeks. Not screenshots. Not a presentation. Working software.
Week 4 to 10: the middle signals
5. The demo is always almost ready
Two consecutive demos slip, or the demo shows a different part each time and never the same part twice. This usually means nothing is finished, only started.
What to do: ask to see the feature from the previous demo, working. The answer tells you whether anything is actually complete.
6. Content and data are not ready
Product descriptions, images, the opening stock figures, the staff list. The build finishes and launch is still a month away because nobody prepared the data.
What to do: put content and data on the plan with dates and an owner, from week one.
7. Third party accounts are not started
Payment gateway, SMS sender ID, courier integration, bank API. These have approval queues measured in weeks, and they are outside the developer’s control.
What to do: start every external application in week one, before the code needs it.
8. Change requests with no visible effect on the date
Twelve small additions, each absorbed with a nod. The date does not move until suddenly it moves by a month.
What to do: every change gets a written cost in days, even if the answer is half a day. Additions push the date or replace something.
Week 10 onward: the late signals
9. Testing keeps getting postponed
QA is scheduled for the end and the end keeps moving. Bugs found in the last week are the most expensive bugs there are.
10. The same bug returns
A fixed defect reappears. This means no regression testing, and it usually means the codebase is fragile in ways nobody has mapped.
11. Only one person understands a critical part
A single developer is the only one who can touch payments or the sync logic. That is a business risk regardless of how good they are.
What to do: ask for a walkthrough to a second developer and written documentation of that component.
12. Communication gets quieter
Updates become shorter and less frequent, and questions take longer to answer. Teams in trouble tend to go quiet, which is exactly when you need more visibility.
What to do when you see three or more
Three signals together is not a rough patch, it is a pattern. The intervention that works is uncomfortable and cheap compared to the alternative:
- Stop new development for a week. No new features.
- Get an honest inventory. What is genuinely finished, tested and deployable. Not “done except”.
- Cut scope to the one sentence. Whatever does not serve the success statement moves to phase two.
- Re plan from where you actually are, not from where the original plan said you would be.
- Fix the decision making. One approver, twenty four hour turnaround.
Projects that do this at month three usually recover. Projects that do it at month nine usually do not, because by then the budget is gone and the relationship has soured.
The signals that look worrying and are not
- Developers saying an estimate was wrong. Honest re estimation is a good sign, not a bad one.
- Bugs during development. Normal. Bugs found late is the problem, not bugs existing.
- Disagreement about approach. Healthy, provided it resolves.
- A rewrite of one component. Often the right call, and cheaper early than late.
Related reading: fixed price versus time and materials and how to choose a software company.
Frequently asked questions
What is the most common reason software projects fail?
Unclear requirements combined with no single decision maker. Technical difficulty is far down the list.
Should I change vendor if the project is in trouble?
Rarely first. Changing vendor mid project costs three to six months while the new team learns the codebase. Try the reset above first; change vendor if the same signals persist after it.
How do I tell a genuine delay from an excuse?
A genuine delay comes with a specific cause, a revised date and a plan. An excuse comes with generalities and no new date.
Can a fixed price contract prevent this?
It shifts the risk, it does not remove it. Fixed price with vague requirements produces arguments about what was included rather than working software.
Ezitech has delivered 650 or more projects in fifteen years and has inherited plenty that went wrong elsewhere. Tell us where yours is and we will give you an honest read.