Renegotiating Scope With the Business

Renegotiating Scope With the Business is the conversation the whole rescue has been gathering evidence for. It is not a status update and it is not an apology. It is a priced choice, presented once, in a form the person paying can act on that day.

Key takeaways

• Lead with the choice, not the diagnosis. A reset that opens with the technical explanation gets heard as an excuse, because the listener has already been given three of those by people who were wrong.
• Bring four artifacts or do not call the meeting: the four facts from week one, the outcome memo from Chapter 4, the instability baseline from Chapter 5, and the tested perimeter from Chapter 6.
• Offer three options that each hold something different, and price all three. Date holds and scope moves, scope holds and the date moves, or cost moves. The fourth option, where everything holds, is the one that produced this rescue.
• Quote a range with a stated confidence rather than a single date, because a rescue inherits the cost-overrun distribution of a new project and a single date implies a certainty the evidence does not support.
• The output is a written change to the plan with a named owner and a review date. A verbal agreement in a difficult meeting is remembered differently by everyone who was in it.

Read this beside Chapter 4, whose memo supplies the options, and Chapter 5, whose baseline is what makes a forecast credible. Chapter 9 is where the agreed plan gets sequenced, and Chapter 8 is the parallel conversation with the people who built the system.

The meeting will happen whether or not you prepare it. Somewhere between week four and week six, a founder or a sponsor asks the direct question: when will it be done. The honest answer at that moment is a range with a confidence attached, and the range is wider than anyone wants.

Most engineers answer that question by explaining. That is the error the rest of this chapter is about.

Why the technical explanation loses the room

The person across the table has already received several technical explanations. Each arrived attached to a date. Each date was wrong. From where they sit, an explanation is the sound a slipping project makes, and their pattern recognition is correct even when your explanation is better than the ones before it.

There is a second reason, and it is less about credibility than about roles. Scope, date and budget belong to the business. When an engineer explains why a date is impossible, they are announcing an outcome inside someone else's authority, and the predictable response is resistance to the announcement rather than engagement with the evidence.

Reverse the order. Present the choice first and the reasoning second, on request. The sponsor is being handed back a decision that is theirs, with the costs of each branch made visible. Almost every difficult reset I have seen accepted was accepted in that shape, and almost every one refused had opened with the diagnosis.

The diagnosis still matters. It is the appendix, not the argument.

What has to be in the room

Four artifacts, and they are already written.

The four facts from week one, which establish the state without interpretation: whether it can be deployed, whether it can be tested, whether the domain logic can be located, and whether anyone can explain a decision. The outcome memo from Chapter 4, one page per component, saying repair, wrap, replace, rewrite or archive with the selecting evidence. The instability baseline from Chapter 5, with the change fail rate and the deployment rework rate as they were measured, not as they were described. The tested perimeter from Chapter 6, showing which paths are now pinned and which are still a stated risk.

Those four exist because of the order this book runs in. That is the argument for the order. A rescue that begins by rebuilding architecture arrives at this meeting with opinions and a burn rate, and the meeting goes accordingly.

One presentation rule, which is my own and not a finding: put the numbers you measured on the page and leave the numbers you did not measure off it. A single soft figure in a pack of hard ones invites the entire pack to be treated as soft.

Three options, all priced

The reset is a choice between three shapes, and the discipline is to price all three rather than to recommend one and dress the others as strawmen.

Then name the fourth option out loud, because everyone is thinking about it. Everything holds, and quality absorbs the difference. That is not a hypothetical: it is the option that was taken, probably implicitly, to produce the delivery you were called into. Cartwright, Horn and Lewis make the same point at the organisational level in their 2024 work on legacy displacement, that agreeing the desired outcome comes before choosing a technique, because different parts of an organisation routinely want different things from the same programme.

Do not moralise about the fourth option. State what it costs, in the language of the previous eighteen months, and let the room reach the conclusion.

Quote a range, and say what the range is made of

A single date is a claim about variance you cannot support.

Flyvbjerg and Budzier, studying 1,471 IT projects and publishing in March 2013, found a mean cost overrun of 27% with a long tail: one project in six overran cost by 200% and schedule by almost 70%. A rescue does not escape that distribution. It inherits it, because everything after this meeting is a new project by every measure that matters.

So quote a range. Give the range a stated confidence, name the two or three things that would move it, and say which of them you will know more about in a fortnight. Ranges are frequently criticised as evasive, and the criticism is fair when the range is wide and unexplained. It stops being fair when the range comes with its own arithmetic.

The credibility of any range depends on the baseline behind it. This is the second place the instability work pays: a team whose change fail rate has been published weekly for a month has demonstrated that its numbers arrive whether they flatter or not. Tornhill and Borg's finding on maximum issue cycle times in low quality code is the mechanism to point at if someone asks why the tail is long, rather than an apology about the codebase.

Adding people behaves least like the room expects

The cost option is the one a sponsor most often reaches for, because it is the only one that appears to preserve both the date and the scope. It deserves a careful answer rather than a reflexive one.

Fred Brooks stated the general case in 1975, and the sentence has survived because it keeps being true: adding manpower to a late software project makes it later. The mechanism he described is that new people consume the time of the people who already know the system, and that communication paths grow faster than headcount does. On a rescue there is a third cost he did not have to name, which is that the knowledge being consumed is the scarce asset the whole diagnosis depends on. Every hour the two remaining engineers spend onboarding is an hour not spent closing a cell in the why column.

That is not an argument against ever adding people. It is an argument about where they go. Capacity added at the perimeter helps almost immediately: writing characterisation tests, taking on the alert cleanup, absorbing the delivery lane so the people with the theory stay on the repair lane. Capacity added into the middle of the unmapped code will cost more than it returns for at least a quarter.

Buying rather than building is the underused form of the cost option. If Chapter 4 marked a component for replacement and a credible product exists, spending money there converts an engineering risk into a procurement one, and procurement risk is the kind a business already knows how to carry.

The clock in the room is financial

There is a constraint on all three options that engineers routinely underweight, and it is not technical.

CB Insights, reviewing 431 venture-backed companies that shut down from 2023, found 70% ran out of capital. On a stalled build that number is the frame around the entire conversation. A technically ideal plan that lands after the money does is not a plan, and a sponsor who seems irrationally attached to a date may be reading a bank balance you have not been shown.

Ask directly, before the options meeting, what the funding horizon is. The answer changes which option is correct. It is also the fastest way to discover that the argument was never about engineering, which is a finding worth having in week five rather than week twenty.

Write it down, or it did not happen

What leaves the room is a document. One page, written the same day, circulated to everyone who was there.

It states the option chosen, what is now in scope and what has been removed, the date or the range with its confidence, the named owner on the business side, the conditions that would trigger another reset, and the date of the next review. Circulate it as a decision record rather than as minutes, and ask for a written acknowledgement. Not a signature. A reply.

The reason is unglamorous and reliable. In three weeks, under pressure, the same people will remember this meeting differently, and the differences will favour whoever is most stressed. A document does not prevent the conversation from reopening. It prevents it from reopening from zero.

When the answer is no

Sometimes the business declines all three options and reasserts the original plan. That is their right, and it is a decision rather than a failure of your presentation.

What you owe them then is a written record of the risk, in plain language, with the specific consequence you expect and the date by which it will be visible. Not a threat, and not a paper trail assembled for a later argument. A forecast, offered once, in writing, so that the review in six weeks starts from evidence rather than from memory.

Then work the plan they chose. A rescue that stops cooperating the moment its advice is declined confirms every suspicion the room already had about outside help, and the next person walking into this delivery inherits that too.

Chapter summary

The reset conversation is won or lost in its first thirty seconds, because a technical explanation is what every previous wrong date arrived attached to, and because scope, date and budget sit inside the business's authority rather than engineering's. Bring four artifacts or do not call the meeting: the four facts, the outcome memo, the published instability baseline, and the tested perimeter. Present three priced options, one holding the date and cutting scope, one holding scope and moving the date, one moving cost, and name the fourth option, where everything holds and quality absorbs the difference, because that is the option that produced this rescue. Quote a range rather than a date, with a stated confidence and the two or three things that would move it, on the grounds that Flyvbjerg and Budzier measured a 27% mean overrun with one project in six overrunning by 200%, and a rescue inherits that distribution rather than escaping it. Treat the cost option carefully rather than dismissively, because Brooks' observation that added people make a late project later applies hardest in the middle of unmapped code and least at the perimeter, where new capacity can write tests and absorb the delivery lane. Establish the funding horizon before choosing among the options, because CB Insights found 70% of 431 shutdowns since 2023 ran out of capital and a plan that lands after the money does is not a plan. Write the outcome as a one-page decision record with an owner, a trigger for the next reset and a review date, and ask for a reply rather than a signature. If the answer is no, record the risk once in writing and then work the plan they chose.

The plan is now agreed with the people funding it. It is not yet agreed with the people who built the system, and they have been in the building the whole time, watching an outsider reorganise their work. Chapter 8 is Working With the Team That Built It: how to get truthful answers from people who expect to be blamed, why the blameless review is a technique rather than a courtesy, and what to do when the person with the most knowledge is the one with the most to lose.