The First 72 Hours of a Software Project Rescue

By the time an executive agrees to a software project rescue, the project has usually been in distress for longer than anyone has been willing to say out loud. The impulse when a rescue team arrives is to begin fixing things immediately — to demonstrate progress, to show momentum, to prove the intervention was worth commissioning.

That impulse is exactly wrong. The first 72 hours of a software project rescue are not about fixing the project. They are about six specific moves that must happen in a deliberate order before any fixing is safe. What distinguishes a rescue that stabilizes from one that makes things worse is almost always whether these six moves were made correctly, or whether the team skipped to remediation before they understood what they were remediating.

01Move 1: Secure access before anything else

If you cannot access the production system, the deployment process, the version control history, and the issue tracker independently of the existing team, you cannot diagnose the project accurately. Credentials concentrated in one person — a developer who may be leaving, a vendor who may become adversarial — are the first structural problem to resolve, not the tenth.

Securing access is not an administrative task to delegate to someone on the team. It is the rescue team's first move, because everything that follows depends on being able to see the real state of the system rather than a curated version of it. A vendor who controls access can delay, filter, and shape what gets seen. The rescue team needs direct access, confirmed and tested, before any diagnosis begins.

What "confirmed" means: each access point is verified by the rescue team itself, not reported as granted by the existing team. Version control access is tested with a live pull. Production environment access is tested with a read operation. Deployment credentials are tested against a non-production environment if possible.

02Move 2: Gather evidence firsthand

The evidence that matters in the first 72 hours is primary evidence: what the product actually does in production today, not what the status report says it does. Run the critical user journeys yourself. Review the open defect list directly rather than having it summarized. Pull the deployment history from the version control system rather than asking the team to describe it.

This is not about distrust of the existing team. It is about the structural reality of troubled projects: the people closest to a failing system have spent months managing up and managing around the problems, which means their mental model of the project's state is shaped by everything they have said and done to keep it moving. Their summary of the situation reflects that history. The primary evidence does not.

The specific artifacts to review in the first 72 hours: a live walkthrough of the product in production, the open defect list sorted by severity and age, the deployment history for the last 30 days, and any architectural documentation that exists — not to trust it, but to compare it against what you see in the codebase.

03Move 3: Find the critical path

A struggling project has more problems than it can fix simultaneously. The move is not to catalogue every problem — that produces a list so long it is paralyzing. The move is to find the one constraint that is blocking the most downstream work: the dependency that nothing else can proceed around, the defect whose presence prevents any other testing, the architectural bottleneck that every team depends on.

The critical path is not the loudest problem, not the most recent fire, and not the problem the team has been working on longest. It is the single constraint whose removal unlocks the most forward progress.

Finding it requires a map, not a list. Draw — or reconstruct from what you can observe — the dependency structure between the things that need to happen. The critical path is the longest chain of sequential dependencies. That chain, not the most dramatic individual problem, is where intervention has the most leverage.

04Move 4: Contain production risk before anyone tries to improve anything

No one should be making improvements to a production system in a rescue's first 72 hours. The system is in a state of unknown stability. Adding changes to it — even well-intentioned ones — adds variance to a system whose behavior is not yet understood. The first production incident caused by a well-meaning improvement during a rescue extends the rescue timeline by weeks and damages the trust that the intervention was designed to restore.

The move is to put a controlled change process in place before anyone acts: a defined window for production changes, a required rollback path tested for every deployment, and a named person who approves any exception. This is not bureaucracy — it is the minimum structure required to make production behavior predictable enough to work with.

The change control process should be as lightweight as possible while achieving its purpose. For most rescues, it means: no production change without a 24-hour notice period except for genuine emergencies, every deployment has a tested rollback, and one named person approves any exception to either rule.

05Move 5: Establish decision rights

The most common cause of delay in a struggling project is not a technical problem — it is a decision that needed to be made three weeks ago and still has not been made. Decisions accumulate because no one is sure who can make them, or because the people who could make them are managing multiple competing stakeholders and have learned that a delayed decision is safer than an unpopular one.

The move is to establish, in the first 24 hours, who has the authority to make urgent decisions without convening a committee. This is a single name for a single role: the person who can approve a scope reduction, authorize a deployment outside the normal window, and decide to replace a vendor relationship. It does not have to be the most senior person in the room — it has to be a person who has the authority and the willingness to exercise it.

Without this name, every decision that needs to happen quickly will require a meeting, a consensus, or an escalation. Any of those adds days to a timeline that has already run out of room.

06Move 6: Replace optimism with a small number of honest facts

The stakeholder communication in the first 72 hours is not a new delivery date. It is not a recovery plan. Both require information that will not exist until the first five moves are complete — and presenting either prematurely sets expectations that the rescue will then be judged against.

The move is to replace the last status update — which was almost certainly optimistic — with a small number of specific, verifiable facts: what access has been secured, what the rescue team has seen directly, what the change control process now looks like, and when the next update will arrive.

Specificity is the only thing that restores trust in a reporting system that has been producing optimistic estimates for months. "We have confirmed write access to the production database and have reviewed 47 open defects, of which 8 are blocking a release" is credible. "We are assessing the situation" is not.

07Why the order matters

These six moves are not independent — they depend on each other in a specific sequence. Without access, you cannot gather primary evidence. Without primary evidence, you cannot find the real critical path. Without containing production risk, every move you make after this point runs the risk of making the system less stable. Without decision rights, your stakeholder communication will include commitments you cannot keep.

The temptation is to run them in parallel — to start the stakeholder communication while the access is still being sorted out, to begin remediation while the evidence is still being gathered. That parallel execution is where rescues go wrong. A stakeholder communication that happens before the evidence is in will commit to something that the evidence will later contradict. A remediation that starts before production risk is contained will produce incidents that undermine the rescue before it has had a chance to work.

08What happens after 72 hours

At the end of 72 hours, a rescue that has made these six moves correctly has four things: confirmed access to the actual state of the system, primary evidence of what is really done and what is not, a single constraint identified as the highest-leverage intervention point, and a decision-rights structure that can move without convening a committee.

That is the foundation for a recovery plan — not the plan itself, but the conditions under which a reliable plan can be made. A recovery plan made before these conditions exist is a guess dressed up in project management language. A recovery plan made after them is a diagnosis.