A project rescue assessment is the bounded piece of work that sits between “this project is in trouble” and “here is what we are going to do about it”. Its job is to establish, with evidence, what state the project is really in, which parts of it can be recovered, and whether the sponsor should carry on, restart part of it, or stop. The rescue itself comes later, and a general audit is a different exercise altogether. An assessment is short and deliberately uncomfortable, and its purpose is to replace what everyone has been told with what is actually true.
Our guide to software project rescue covers the warning signs and the first forty-eight hours, and our article on ERP and Salesforce project rescue looks at the integration and data layer, where so many enterprise programs stall. This piece fills the gap between the two. I’ll walk through how a competent assessment runs over its first two weeks, phase by phase – from the decisions about access and freezing work on the first day, to the recommendation and the package the sponsor should be holding at the end.
Why two weeks, and why not longer
The first serious look at a troubled project should take a day. A month is far too long. A focused day with the people who know what is really going on is usually enough to find the real constraints, and enough to tell the sponsor whether a fuller assessment is warranted at all.
When the situation is bigger than that, a structured assessment follows, and two weeks is a sensible ceiling for it. That’s long enough to read the code, rehearse the critical data paths, interview everyone who matters and test the claims that came out of the first day. It’s also short enough that the project doesn’t drift further while it’s being examined – and short enough that nobody is tempted to turn the assessment into a second project, with its own budget and its own status meetings. An assessment that needs six weeks has usually lost sight of its question.
The calendar below assumes a mid-sized enterprise program with several integrations, a data migration and a team of a few dozen people. Smaller projects compress it, and the order of the work matters more than the exact days.
Days one and two: access, freeze and ownership
The first decisions are administrative, and they decide whether the rest of the assessment is possible at all. The assessment team needs read access to the repositories, the issue tracker, the CI pipeline, the environments, the test results and the document stores, and it needs that access on the first morning – after a week of tickets is too late. If access is slow in coming, that is itself a finding.
The second decision is what to freeze. In most cases, new scope should stop entering the backlog until the assessment is finished, and releases to production should continue only for genuine defects. Freezing development entirely is rarely right, because idle teams lose momentum, and the assessment needs to see how the team actually works. Freezing scope almost always is right, because you can’t measure a moving target. The sponsor should make this call in writing, and it should be explained to the client or the business as a short, deliberate pause, before they find out about it on their own.
The third decision is ownership. Someone on the sponsor’s side has to be named as the person the assessment reports to – someone with the authority to unblock access and the standing to hear an unwelcome answer. The assessment team, for its part, should agree at the outset on what it will deliver and when, so that nobody can renegotiate the findings into something more comfortable at the end.
Preserving evidence belongs in these first days as well. Backlog history, changes to estimates, defect trends, incident logs, decision records and old status reports are the raw material of an honest assessment, and on troubled projects they have a way of getting tidied up once people know someone is looking.
Days two to four: stakeholder interviews
Interviews start as soon as access is underway, and they’re the part of the assessment most often done badly. Collecting opinions about whose fault the project is gets you nowhere. What you want is each person’s own account of what is true, given privately and specifically, so that you can compare those accounts with each other and with the evidence.
The useful interviews are with the sponsor, the delivery lead, the architects, two or three of the engineers who actually write the code, the test lead, whoever runs the environments, and the business owners who will have to live with the system. The questions are concrete. What is finished, and how do you know? What would you not want to demonstrate tomorrow? Which decisions are still open? What has been promised to the client that the team doesn’t believe? The gap between their account and the official status is one of the most valuable findings the assessment will produce, and it should be recorded as one.
Days three to seven: code, configuration and data
The technical review runs alongside the interviews and takes up most of the first week. It covers the architecture as built (which is often quite different from the architecture as drawn); the code itself, including its structure, its test coverage and the parts only one person understands; and the configuration of the platforms involved, which is where a surprising share of the risk on enterprise programs lives.
Data deserves its own attention. If the project includes a migration, the assessment should establish whether it has ever been run at full production volume, how long it took, and whether anyone reconciled the result. If it has only ever been run against a sample, then that is the finding. Where it’s possible, the assessment team should run or watch a rehearsal and check the output against record counts, financial totals and a sample reviewed by the people who use the data. A migration that hasn’t been reconciled hasn’t been tested, whatever the test report says.
By the end of the week, the review should produce a short, plain list of what is sound, what can be repaired, and what should be replaced.
Days six to nine: integrations and environments
Integration and environment problems are where troubled enterprise projects most often hide their real schedule, so they get a pass of their own. The assessment builds, or reconciles, an inventory of every interface: source, target, direction, mechanism, volume, owner, test status, and evidence that it works in an environment resembling production. On programs that need rescuing, this list frequently doesn’t exist, and building it often turns up interfaces nobody had scoped.
For each interface, the team checks whether the system of record has been agreed for every object it touches, whether failures are retried and surfaced or just rerun by hand, and whether anyone can say how many failures there were last week. The environment audit asks how many environments exist, how closely they match production, how data gets into them, and how long it takes a change to get from a developer’s branch to a production-like system. A two-week lead time to get a fix into a test environment can account for months of slippage all by itself.
Days eight to eleven: the defect and risk register
By the second week, the assessment has gathered a great deal of evidence, and it needs one place to put it. The register is that place. It combines the existing defect backlog – re-triaged against the findings, and never taken at face value – with a list of the risks the project hasn’t recorded: undecided design questions, untested integrations, gaps in the migration, dependencies on key people, and promises the plan can’t keep.
Each entry should carry a description, the evidence behind it, its consequence for the schedule or the business, a rough estimate of the effort to resolve it, and a recommended owner. Nobody should mistake the register for a decorative appendix. The recommendation will be argued from it, and anyone reading the recommendation should be able to trace every claim back to an entry here.
Days ten to fourteen: the recommendation
The last few days turn the evidence into a decision. A competent assessment recommends one of four courses: rescue, where the foundations are sound and the problems are mainly about delivery, capacity or a few poor design choices; partial restart, where one component (an integration layer, say, or a migration) has to be rebuilt but the rest can be saved; full restart, where the foundations are wrong for the problem; or stop, where the business case no longer holds up at a realistic cost.
The recommendation should set out its reasoning, name the conditions under which it would change, and include a credible path for the chosen option, with a defined end state and the responsibilities each side would carry. It should be presented to the sponsor in person before it goes any further, because a recommendation to stop part of a program is a political event as well as a technical one, and the sponsor deserves to hear it first.
A client example. We ran an assessment like this for a wholesale equipment business whose Salesforce opportunities flowed into an ERP to create orders. The status deck said 90% complete, with UAT the following week. We traced ten real orders end to end with each team, and three gaps came out. The integration failed to amend orders reliably after a quantity change, because the middleware had no stable external order reference and treated each revised payload as a new order. Sales believed Salesforce price overrides were authoritative, finance assumed the ERP recalculated contractual prices, and no signed rule said which one won. And the migration rehearsal had used a handpicked 10% of fairly clean customer data, leaving out inactive customers, historic ship-to addresses and credits. We recommended stopping the planned UAT date while the rest of the program carried on. The working new-order flows stayed, amendments and pricing went onto a short redesign under a named pricing owner, and a full-volume rehearsal followed. The reset added four to six weeks, and the steering report began showing tested business scenarios and open defects by severity in place of a percent-complete figure.
The two-week plan at a glance
| Days | Phase | Main activities | Output by the end of the phase |
|---|---|---|---|
| 1–2 | Access, freeze and ownership | Get access to code, tools and environments; freeze new scope; name the owner on the sponsor’s side; preserve the evidence | Access log, written freeze decision, agreed deliverables and dates |
| 2–4 | Stakeholder interviews | Private interviews with the sponsor, delivery lead, architects, engineers, test lead, environment owner and business owners | Interview notes, and a list of discrepancies between reported and actual status |
| 3–7 | Code, configuration and data review | Architecture as built, code and test coverage, platform configuration, migration status and reconciliation | Technical findings: sound, repairable, replace |
| 6–9 | Integration and environment audit | Interface inventory, systems of record, failure handling, how closely environments match production, lead times | Interface inventory with status and evidence; environment assessment |
| 8–11 | Defect and risk register | Re-triage existing defects; record unlogged risks with evidence, consequence, effort and owner | A consolidated register |
| 10–14 | Recommendation | Rescue, partial restart, full restart or stop; the path, end state and responsibilities | A written recommendation, presented to the sponsor in person |
What the sponsor should hold at the end
At the end of the second week, the sponsor should have a package that stands on its own, whether or not the same team gets hired for what comes next. It belongs to the sponsor, and it should be complete enough that another firm could pick it up and act on it.
- An executive summary of two pages at most, stating the recommendation and the three or four findings behind it.
- The written recommendation, with its reasoning, the conditions under which it would change, and the path forward for the chosen option.
- The defect and risk register, with the evidence, consequence, effort and owner for every entry.
- The interface inventory, covering every integration and data flow, with its status and the evidence for that status.
- Technical findings on architecture, code, configuration and data, each one tied to a consequence for the project.
- A re-baselined view of the remaining scope, separating what go-live genuinely requires from what can be deferred or dropped.
- A definition of done for the next phase, written as conditions anyone can check, with responsibilities on both sides.
- The evidence itself: interview notes (anonymized where that’s appropriate), rehearsal results, access records and anything else the findings depend on.
A sponsor who gets slides with no register behind them, or a recommendation with no evidence beneath it, has paid for an assessment and received an opinion.
Related reading
- Software project rescue: warning signs and what a real rescue looks like
- ERP and Salesforce project rescue: where these programs really stall
- How to scope integration work in a statement of work
How we approach it at eProxim
eProxim responds to at-risk projects on the same business day, and we start with a one-day deep dive, where others might begin with a three-week discovery. Where the situation calls for a fuller assessment, we run it in the order I’ve described here, keep it bounded, and leave the sponsor with a package they own. We’re willing to recommend stopping or restarting parts of a program, because an assessment that can’t reach that conclusion isn’t worth paying for. When the right answer has been to take over delivery outright, we’ve done that too. We did it for a consumer travel booking portal that had produced no delivered software in more than two years: we took over delivery leadership, stood up a 125-person offshore development team, and shipped the portal.
The details of how we work on troubled programs, including under a partner’s brand, are on our project rescue page. If a project you’re responsible for is already going wrong, talk to us today.