The Trade-off Most Recovery Plans Skip

"We're a bit behind, but we'll catch up." That sentence usually arrives after the bad news has already arrived late, and it starts a second problem: the recovery plan asks the sponsor to trust a new date without explaining what changed.

Why "we'll catch up" does not work

The sponsor already extended credit once, when they accepted the original date. A second ask with nothing concrete attached spends down what is left of that balance instead of rebuilding it. The plans that rebuild trust name the trade-off out loud: something gets smaller, later, or different so the new date can hold. That is the part "we'll catch up" leaves out.

What a credible plan names

A recovery plan should put a few things on the table by name, rather than hiding them inside a reassuring status update.

• Scope. What is getting cut or pushed to a later phase, and who agreed to that.
• AI-assisted work. Whether AI is doing more of the work now than it did under the original plan, and what changed about how the output gets verified. A jump in velocity with no matching change in staffing is worth asking about.
• Testing. What verification is being shortened, deferred, or changed, and what risk that introduces.
• Buffer. How much slack is left after the recovery plan, and whether there is room for a second surprise.
• Staffing. Who is being added, reassigned, or pulled off something else to hit the date.
• The ask. The exact decision needed from the sponsor right now.

None of these are signs the recovery is failing. They are the evidence that there is actually a plan.

What happened with the client

A mid-market client in the Midwest was running an ERP program that had gone off track. Status read green for weeks, then flipped red almost overnight. The client had sensed the delay coming before anyone said so, but the team wasn't giving them specifics, and every vague update took a little more out of the trust budget. They stayed patient through it, more patient than they had to be.

What got the relationship back on track was not another reassuring forecast. It was sitting down together and naming what was at stake, the options on the table, and what each one would cost. Once that was clear, the client could decide. Recovery from there was execution.

The part that is easy to miss

A vague promise to catch up spends trust too, just more slowly than hiding the delay does. Both end in the same place: the sponsor stops believing the next date, and every estimate after that gets reviewed twice.

A vague promise to catch up spends trust too. Just slower than hiding the delay does.

A trust budget needs more than honesty about the delay. It needs specifics about the cost of recovering from it, and that cost is not always measured in dollars. It might be scope. It might be testing. It might be staffing. It might be less buffer. Increasingly it is also how much of the work AI is compressing, and what evidence exists that the output is good enough to ship.

My guess is that "AI-assisted" becomes a standard disclosure line in recovery plans before long. Not because anyone is hiding anything, but because sponsors will start asking before teams think to volunteer it.

The fast layer will keep promising to catch up on its own schedule. The slow layer is whoever is willing to say exactly what catching up costs.