The early warning signs a software project is in trouble

By the time a project is formally in trouble, the decisions that put it there were made months earlier. The signals were present; they just did not look urgent.

Here are the ones worth acting on early, from both sides of the table.

Nothing has been demonstrated

The clearest signal. If several weeks have passed with status updates but nothing you can click, the work is not where the updates say it is.

This is not necessarily dishonesty. Teams genuinely believe they are nearly there, right up until integration reveals they are not. A working demonstration is the only reliable measure, and its absence is the earliest signal available.

The same percentage for three weeks running

"About eighty percent done" in week six and week nine means the estimate was never grounded in anything measurable.

Progress should be expressible as things that now work which did not before. If it can only be expressed as a percentage, it is a feeling.

Integration keeps being deferred

Any plan where the pieces come together at the end is a plan where every integration risk lands at once, with no time left to absorb it.

If the first time the front end talks to the real backend is the final fortnight, the schedule is already fictional.

Questions take days to answer

In either direction. A supplier slow to respond is overcommitted; a client slow to decide is blocking work that is being billed for.

Response latency is a decent proxy for project health generally, and it degrades before anything else visibly does.

Scope grows without anything leaving

Additions are normal. Additions with no corresponding removal, date change or budget change are a schedule failure that has been agreed to without anyone noticing.

• Track what was in the original scope and what has been added since.
• If that list only grows, the launch date is no longer real.
• Say so early, while the options are still cheap.

Testing is scheduled for the end

Treating QA as a phase after development means defects are found when they are most expensive and there is least time.

Projects that go well test continuously. Projects in trouble have a testing phase that keeps getting shorter.

What to do about it

1. Ask for a working demonstration this week, however incomplete.
2. Ask what is not done rather than what is — the answer is more informative.
3. Re-plan from where you actually are, not from where the original plan says you should be.
4. Cut scope rather than quality. A smaller thing that works beats a larger thing that nearly does.

Most troubled projects are recoverable if addressed in month two. Far fewer are in month six, which is when the conversation usually happens. Our note on why software projects run late covers the causes behind most of these signals.

What is the earliest sign a software project is in trouble?

Nothing has been demonstrated. If several weeks have passed with status updates but nothing you can click, the work is not where the updates say it is. This is rarely dishonesty — teams genuinely believe they are nearly there until integration proves otherwise — but a working demonstration is the only reliable measure of progress.

Can a failing project be recovered?

Usually, if it is addressed early. Most troubled projects are recoverable in month two by re-planning from where the work actually is and cutting scope rather than quality. Far fewer are recoverable in month six, which is unfortunately when the conversation normally happens.