How to rescue a stalled software project

Most software projects hit a rough patch at some point. A smaller number stall: deadlines have slipped more than once, the budget is stretched, people are tired, and nobody is quite sure what “done” looks like any more. The good news is that many of these projects can be recovered. The key is to stop adding pressure and start with a calm, honest reset.

Signs a project is in trouble

• Dates keep moving, and each new date is less believable than the last.
• Status reports are all green, but nothing demonstrable has been delivered for weeks.
• The scope has grown, but the team and budget have not.
• People disagree about what was promised.
• The people paying for it and the people building it have stopped talking openly.
• Fixing one thing keeps breaking another.

If several of these sound familiar, it is time to act rather than hope.

A recovery plan in six steps

1. Pause and take stock

Stop adding new work for a short, defined period. Gather the facts: what has been built, what works, what is left, what has been spent, and who is doing what. You cannot fix what you cannot see.

2. Talk to the people involved

Speak with the sponsors, the users and the team, separately. People often say things one-on-one that they will not say in a status meeting. You are listening for the real blockers, not for blame.

3. Face the real numbers

Estimate the work remaining honestly, with a range rather than a single date. Compare it to the time and money available. This is where it often becomes clear whether the original goal is still realistic.

4. Decide: continue, reset or stop

There are three honest options:

• Continue with a clearer plan and better controls.
• Reset by cutting scope to a smaller first release, or changing the approach.
• Stop and put the money elsewhere, if the original case no longer holds.

Stopping can be the right answer, and it is better to reach it early than late.

5. Replan around a smaller win

Pick the smallest slice that delivers real value, and get it into users’ hands. A working release, even a modest one, rebuilds confidence in a way that a revised plan alone cannot.

6. Put a steady rhythm in place

• A short weekly check-in with the same simple questions: what shipped, what is blocked, what is at risk.
• A visible list of risks and decisions, each with a named owner.
• Regular demonstrations of working software.
• Honest reporting, including when the news is bad.

What to avoid

• Throwing more people at a late project. New people need time to get up to speed, and this often slows things further before it helps.
• Cutting testing to hit a date. It moves the problem to your users.
• Replacing the team in anger. Understand the cause first. Often the issue is unclear requirements or decision-making, not the people.
• Reporting only good news. Trust returns when people believe the numbers.

Fix the technical debt that blocks progress, not all of it

Some old shortcuts in the code are worth leaving alone. Focus on the ones that slow every change or cause repeated failures, and fix those first.

Bring in a fresh pair of eyes

A neutral person who is not caught up in the history can often see the way forward more clearly, and can have the difficult conversations more easily. That might be an experienced delivery manager from inside your organisation or an outside partner.

If a project of yours has stalled, we are happy to take a look and tell you plainly what we would do.