Key takeaways
- Most software projects do not fail suddenly. They drift, and the signs show weeks before the missed date.
- The earliest signals are about information: unclear decisions, no working software to look at and bad news that arrives late.
- Ask to see working software every couple of weeks. Slides and status reports can look healthy while the product does not.
- When you spot a risk, say so early and in writing. Early problems are usually cheap to fix.
Why do software projects go wrong?
Software is hard to see. A building under construction shows its progress to anyone who walks past; a half-built system looks the same from the outside as a finished one. That makes it easy for problems to stay hidden until a deadline arrives.
Nearly all the causes are ordinary: a misunderstood requirement, a decision that nobody made, an integration that behaved differently from its documentation, or a team that was stretched too thin. None of them is exotic, and all of them show up earlier than people expect if you know where to look.
What are the early warning signs?
You cannot see working software
If the only evidence of progress is a status report, you are relying on opinion. Working software, even a small and rough version, is evidence. Ask for a demonstration every one to two weeks and try the thing yourself rather than watching someone else click through it.
Decisions are waiting, and nobody owns them
Projects stall on questions: which option, which rule, who approves. If the same question appears in two consecutive updates, it has no owner. Name one person on your side who can decide, and agree how quickly they will.
The scope keeps growing without a conversation
New requests are normal. What matters is whether each one is discussed, priced and traded against something else. Silent growth is how a project ends up late and over budget with nobody having chosen either.
Bad news arrives late or not at all
A healthy supplier tells you early when something is slower than expected. If every update is green until the week before delivery, the reporting is not showing you the real state. Ask directly: "What is the thing most likely to make us late?"
The same bugs keep returning
Repeated defects often point to something structural, such as missing tests, rushed releases or unclear requirements. Fixing the symptom each time costs more than finding the cause once.
Key people keep changing
Handovers lose knowledge. If the people you met at the start are not the people doing the work, ask who they are, how they were briefed and what has been written down. The questions worth asking a supplier apply during a project as well as before it.
Estimates become vague
"Nearly done" and "a few more days" are not estimates. Ask what remains, in a list, and how much of the list is certain.
What can you do about it?
- Agree what "done" means for each piece of work. A feature that works on the developer's machine but has not been tested is not done.
- Keep the first release small. A smaller scope has fewer places to go wrong, and you learn from real use sooner. See our guide to building an MVP.
- Test the riskiest part first. If one integration or one idea could sink the project, tackle it in the first weeks, not the last.
- Keep a short risk list. Write down the five things most likely to hurt, who is watching each one and what would trigger action. Review it in every meeting.
- Write decisions down. A one-line note of what was decided, by whom and when removes a surprising number of disputes.
- Check ownership. Make sure the code and accounts are in your name from the start, so you always have an option if the relationship ends. The contract points are worth confirming before work begins.
What if you think a project is already in trouble?
Do not wait for the next milestone to confirm it.
- Ask for a clear status. What is finished and demonstrable, what is in progress and what has not started.
- Check what remains against the time and money left. If they do not fit, say so now.
- Agree a smaller target. Often the right move is to cut scope to something that can be finished well, rather than push everything to the end.
- Get an independent view if trust has gone. A short technical audit gives you evidence about the state of the work without changing it.
- Keep records. Written requests and replies matter if there is later a disagreement about what was agreed.
Frequently asked questions
Is a delay always a sign of trouble? No. Delays happen on well-run projects too. What matters is whether you heard about it early, understand the cause and have a realistic new plan.
Who is responsible for managing risk, the supplier or the client? Both. The supplier manages delivery risk, and you manage the risks only you can control, such as decisions, access and approvals.
Should I change supplier mid-project? Only after you have weighed the cost of lost knowledge and restart time. Often a reset of scope and communication fixes more than a new team does.
What is the cheapest risk control? Regular demonstrations of working software. They surface misunderstandings while they are still small.
If you would like a second opinion on a project, our custom software development team can review where it stands, and you can contact us.