Warning Signs Your Software Project Is Going Wrong

Software projects rarely fail suddenly. They fail slowly, giving the same signals for weeks while both sides hope the next fortnight will be better. Here are five worth acting on.

1. You cannot click anything

Progress is shown as screenshots, recordings, or a call where someone shares their screen. You have never opened the software yourself, on your own phone, at a URL.

This is the earliest and most reliable signal. It usually means the pieces exist separately and do not yet work together, and integration problems get worse the longer they stay hidden.

What to do: ask for a deployed build you can use this week. Not a demo. If the answer is that it is not ready to show, ask what specifically is not ready, and get a date.

2. It has been 90% done for a month

Percentages are opinions. The last 10% of a project is where testing, edge cases, deployment and the things nobody scoped all live, and it is routinely half the remaining work.

What to do: stop asking for percentages. Ask for the list of what is not done, as items. A vendor who can produce that list is in control of the project. One who cannot has lost track of it, which is the actual problem.

3. Every question produces a new cost

Reasonable clarifications keep coming back as change requests. "The report should show last month too" turns into an invoice.

Sometimes that is fair, because it genuinely is new scope. When it happens to everything, it usually means the original scope was written vaguely enough that almost anything counts as outside it.

What to do: ask for the change to be quoted against the original written scope, pointing at the line it falls outside. If the scope document cannot support that conversation, agree a clearer one now rather than arguing at the end.

4. The person you met is no longer around

You were pitched by a senior engineer and now correspond with someone who was not in that meeting and does not know what was agreed.

Handover is normal. Silent handover is not, and it often means your project has been moved down a priority list.

What to do: ask directly who is working on it and how much of their week it gets. A straight answer is fine even if the answer is not what you hoped. Evasion is the signal.

5. Nothing is written down

Decisions are made in calls and messages. There is no document saying what was agreed, so both sides remember it differently, and the disagreement surfaces at the worst moment.

What to do: start writing them down yourself. A short note after each call saying what was decided, sent to the vendor, is enough. If they disagree they will say so, which is precisely what you want, early.

If you see several of these

Ask for the smallest genuinely useful version, deployed, within two weeks. Cut everything else. This is the most effective intervention available: it forces the project to produce something real, and something real is what both sides need to judge whether to continue.

Projects that fail outright are almost always the ones that kept going for months without ever shipping anything. Projects that ship something small and disappointing usually recover, because at that point everyone is arguing about a real thing instead of a plan.