How to Tell a Project Is Drifting Before the Money Runs Out

You do not need to read code to see this

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

All of the following are visible to a non-technical client, which is the point of listing them.

The five signals

1. No working software for more than two weeks. Progress is being described rather than demonstrated.
2. The same screens in every demonstration, with the difficult parts always coming next time.
3. “Almost done” for three weeks. The remaining work is not understood and nobody has re-forecast.
4. Questions taking days to answer. Usually means the team changed or an uncomfortable answer is being avoided.
5. Testing scheduled for the end, which is where bad projects go to be discovered too late to fix.

What to do about each

• Ask for a demonstration of whatever exists this week, however rough
• Specify what you want to see: “an order going through end to end, including a failure”
• Ask for the remaining work as a list; if it cannot be produced in an hour, it is not nearly complete
• Ask directly whether the team has changed and who is currently working on your project
• Ask for access to a test environment from the halfway point, and use it

If several are true

Call a reset meeting and say plainly what you are seeing, without blame. Ask for a written list of what is complete, what remains, and the revised forecast. Then cut scope to a launchable core.

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

Protecting yourself in advance

Fortnightly working software, milestones tied to demonstrable functionality rather than dates, a named team you have met, and a first phase short enough that being wrong is survivable.

Payment on acceptance of each milestone. Paying everything up front removes the only leverage you have.

Frequently asked questions