I have been asked, more than once, to recover programmes that were described, when I arrived, as too ambitious. That has almost never been the problem. In the programmes I have been asked to recover, the recurring problem has been the same: the ambition was priced against numbers nobody had properly tested.
The volume number had come from a single query against a production database, run by one person, against a cut-off that was never reconciled. The productivity number had been lifted from a benchmark slide that nobody could trace to a particular firm or a particular type of file. The capacity number had been divided out of the productivity number without a working week underneath it: no allowance for QA, no ramp-up, no attrition, no leave. The plan looked precise. None of the numbers were robust.
And there is another part people sometimes miss. Cleaning up the old population only gets you so far if the BAU control that created it is still producing the same problem. You have to scope the historical repair and the control change that stops you building the next backlog.
What scoping actually is
Scoping is mostly the discipline of refusing to write a number down until you can show your working. The team will resist this in the first week. The Steering Committee will resist it more. There is always a date by which the plan has to be tabled, and the temptation to fill the gaps with a benchmark or an estimate is enormous.
The two weeks spent insisting on a reconciled population, a representative pilot on real files and a capacity model built in layers are the two weeks that tell you whether delivery is starting from evidence or optimism. They are also the weeks the Programme Sponsor is most likely to argue against. The argument is usually some version of: we need to start the work. The honest answer is that the work cannot start until the numbers it is sized against are numbers somebody is willing to defend.
The artefact that holds the plan together
The single most useful artefact I produce in any scoping is the assumptions register. Not the plan, not the budget, not the slides. The register. Every number the programme depends on, with the basis on which it was derived, the named owner who derived it, and the trigger at which it must be re-tested.
By the time the Committee approves the plan, the assumptions register has more entries than the budget has lines. That is the right shape.
I normally rebuild the register three times before mobilisation. Once at the end of the population work. Once at the end of the pilot. Once at the end of the mobilisation phase, the week before the Committee approves the plan. Each rebuild changes something. Sometimes the movement is small. Sometimes it changes the plan. The important thing is that it is visible in the register, and anything material gets to the Committee against thresholds agreed at mobilisation. The plan that goes forward should be the one built around what we now know, not the version everyone liked in week three.
Why the register matters in month four
Some of the numbers will move. That is not the problem. The problem is finding out too late, after the budget, team and deadline have all been built around the old ones. The question is whether they move inside a register the Committee can see, or outside a register that does not exist. I have found programmes much easier to recover when the assumptions are still visible and somebody owns them. The real trouble starts when changes have been absorbed quietly for months and everyone is still pretending the original plan is the plan.
The two versions of the programme had the same ambition at the start. Only one of them did the scoping work to make the ambition deliverable. The other ran on assumptions that were never tested, and on a Steering Committee that did not see the assumptions move because the register did not exist to hold them.
What I would do this week, if I were the Programme Sponsor
Open the latest scoping paper. Look for the assumptions register. If it is not there, ask the Programme Director for it, in writing, before the next Committee. If the register is there, look at the column for the named owner of each assumption. If the owners are missing, the register is a document, not a working artefact. If the owners are named, look at the trigger column. If the triggers are missing, the register is unlikely to be re-tested once the work begins. If the triggers are there, and the material ones carry a threshold at which they come back to the Committee, the register is doing its job.
Guide 009 sets out the full scoping cycle, including the independently validated and reconciled population, the file standard, the representative pilot on real files, the capacity model in layers, the correction of the underlying BAU control and the contingency conversation I would want the Committee having at mobilisation rather than at month six. Download the full guide and use the assumptions register at Appendix A as the starting point for your own.