Rescue a failing software project: the first 30 days

In short: to rescue a failing software project, spend the first week establishing facts (access, state of the code, what is actually delivered), the second week deciding whether to continue, replace or stop, and the rest of the first 30 days stabilising. Do not add features, people or deadlines until you know the real state. This plan is the order I would follow.

Before day 1: stop making it worse

• Freeze new scope. Every addition now deepens the hole.
• Do not hire more developers yet. Adding people to a project that nobody understands slows it down.
• Do not end the vendor relationship until you hold the code and the accounts.

Week 1: establish the facts

1. Secure access. Repository, hosting, database, domain and app-store accounts, in your organisation's name. In one review the code was better than expected, but a single contractor held the only credentials to the production database and the deployment pipeline and had not been paid in seven weeks. It was resolved in four days once it was named.
2. Take a backup of the production data and the repository.
3. Find out what is actually delivered. Grade each delivered item against the written acceptance criteria: delivered, partially delivered, or not delivered. On one $90,000 build, three of six sprints that had been reported as complete were only partially delivered.
4. Inventory the risk. Who understands which part of the code, what has no tests, which dependencies are outdated, how releases happen. The due diligence checklist covers nine areas.

Week 2: decide

Option	Choose it when
Continue with the same vendor	The code is sound, the problem is governance, and the vendor is cooperative. Put written acceptance criteria and sprint grading in place.
Continue with a new team	The code is sound but the relationship is broken. Needs full handover and documentation.
Rebuild part of it	Specific modules are unsalvageable (for example a data model that cannot support multi-tenancy). Cost each part in developer-days.
Stop	Remaining cost to a usable product exceeds its value. Stopping early is a legitimate decision.

Decide using costs in developer-days and a ranked risk list, not feelings about the vendor.

Weeks 3–4: stabilise

1. Rewrite the scope as ranked requirements with testable acceptance criteria. See examples.
2. Define the smallest releasable version and a date for it.
3. Put a weekly gate in place: each release is tested by the business side against the criteria (UAT checklist).
4. Name one decision-maker with a response time.
5. Write down what happens if the vendor stops (ownership and handover).

Signs the rescue is working

• Weekly reports are factual, per deliverable, with what remains.
• Vendor questions get answered within two working days.
• Releases pass your acceptance checks before going live.
• You can access everything without asking permission.

Get an independent view first

The fastest way to replace opinions with facts is a ten-day review: a one-page risk matrix, the three weakest areas costed in developer-days, and a 90-day plan. That is the Delivery Risk Audit, delivered by someone with no stake in the fix. If you continue with the same vendor, Build Oversight grades each sprint against written criteria. Related reading: the five warning signs a project is about to slip.