Seven Early Signs a Software Project Is Going Wrong

Trouble is visible long before it is admitted

Software projects rarely fail suddenly. They accumulate warning signs for weeks while everyone hopes the next fortnight will be better.

The signs below are observable without technical knowledge, which is the point — you do not need to read code to know something is wrong.

1. No working software for more than two weeks

If you cannot click through something that runs, progress is being described rather than demonstrated. Design documents, architecture diagrams and status percentages are not evidence.

What to do: ask for a demonstration of whatever exists, however rough, this week. A supplier who cannot show anything running after a month has a problem they are not telling you about.

2. The same screens in every demo

Demonstrations that keep returning to the polished parts, with “we will show the rest next time”, usually indicate a shell with the difficult parts unbuilt.

What to do: specify what you want to see. “Next demo, show me an order going through end to end including a failure case.”

3. “Almost done” for three weeks running

The last 10% of a task takes 50% of the time when the remaining work was not understood. Repeated “almost done” means the estimate was wrong and nobody has re-forecast.

What to do: ask what specifically remains, as a list. If the list cannot be produced in an hour, the work is not understood well enough to be nearly complete.

4. Your questions take days to answer

Slow responses usually mean the person answering does not know, is avoiding an uncomfortable answer, or has been moved to another project.

What to do: ask directly whether the team composition has changed and who is currently working on your project. This is a reasonable question and the reaction to it is informative.

5. Scope keeps growing without price changing

This sounds like good news and is not. A supplier absorbing scope creep is either heading for a loss they will eventually push back on, or quietly dropping something you have not noticed.

What to do: insist on change control even when changes are free. You want a written record of what was added and what was displaced.

6. Testing is scheduled for the end

Testing compressed into the final fortnight is where bad projects go to be discovered. Problems found then are expensive and there is no time left to fix them.

What to do: ask for testing to run continuously and for you to have access to a test environment from the halfway point. Use it.

7. Nobody will give you a launch date

Vagueness about dates late in a project means the remaining work is not understood. Early vagueness is normal; vagueness at 70% is a signal.

What to do: ask for a date with a confidence level and what would have to be true for it to hold. That framing usually produces an honest answer where “when will it be ready?” does not.

What to do if several are true

1. Call a reset meeting and say plainly what you are seeing, without blame.
2. Ask for a written list of what is complete, what remains and what the revised forecast is.
3. Cut scope to a launchable core. Something working beats everything nearly working.
4. Consider an independent technical review — a few days of someone reading the code gives you an objective picture.
5. Agree new milestones with demonstrable outcomes and short intervals.

Projects can be recovered. What kills them is everyone politely hoping for a month that would have been better spent on this conversation.

Frequently asked questions