Software project risks: how to spot them early

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.

Why 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 stretched too thin. All of them show up earlier than people expect if you know where to look.

Early warning signs

• You cannot see working software. If the only evidence of progress is a status report, you are relying on opinion. 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. 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.
• 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. 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.
• 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.
• 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 you can 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.
• 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. 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.

If a project is already in trouble

Do not wait for the next milestone to confirm it.

1. Ask for a clear status: what is finished and demonstrable, what is in progress and what has not started.
2. Check what remains against the time and money left. If they do not fit, say so now.
3. 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.
4. Get an independent view if trust has gone. A short technical audit gives you evidence about the state of the work without changing it.
5. Keep records. Written requests and replies matter if there is later a disagreement about what was agreed.

A delay alone is not a sign of trouble. What matters is whether you heard about it early, understand the cause and have a realistic new plan.

The full guide is on the Cognivise blog. If you want an independent view of a project, planning and technical advice is where we start.