A plan full of activity tells you almost nothing about what you will be holding when it ends. Activities are comfortable to write down, because an activity is finished when the people doing it say it is finished. An output is harder. It lands on a date, in a form somebody can pick up, and someone has to accept it or refuse it.
An international health insurance group was offered a fourteen-week design engagement written the harder way. Twelve outputs, numbered, each placed against a week of a three-stage schedule. Six of the twelve were specified further: not only what they would contain, but what they would physically be, and what the group would be entitled to be sure of once each one arrived.
The challenge
The work sat inside a larger transformation portfolio and covered only part of it. Two strands, one on where automation and digital service should be applied, one on how the service operation should be organised across countries. Both reach into large parts of the operating model, and both depend on strands of the portfolio nobody was asking this team to design. The proposal stated that on its own face rather than discovering it in month three.
That is the condition under which a deliverable list usually goes soft. When a design cannot close inside its own boundary, the outputs have to be useful to people outside it. A pack of workshop material is finished when the workshop happens. A gap analysis between the current operating model and an agreed future one is finished when somebody who was not in the room can read it and say how big the change is.
The approach
Start with form, because form is the part most plans omit and the part that decides whether an output can be used. The six specified deliverables each declared what they would be. One would be a document setting scope, objectives, the participation required from stakeholders, the delivery plan and the method being applied. One would be a pack of operating-model options, each option carried far enough to state the capabilities it implies and the effect on different customer segments. One would be an analysis pack holding an agreed set of future capabilities across people, process and technology, set against the current model with an assessment of how far apart the two are. One would be a slide deck with regional and country views of the end state, including the future process architecture. One would be a spreadsheet model of the costs and the benefit case, projecting the cost of the new global structure against the current one alongside the benefit expected from automation. And one would be a single picture, backed by a phased plan in which only the first phase carried named resources.
That last pairing is the honest one. Naming resources for phase one and leaving later phases at picture resolution is a decision about form, and it is the decision that stops a roadmap being read as a commitment nobody was ever able to make.
The second half of the specification is stronger still. Each of the six descriptions was paired with a plain statement of what the group would have once it landed: an understanding of the distance between the model it runs today and the one it has agreed to, assurance of what is being delivered and by when so that delivery could be measured, a view of the cost and savings impact of the change. Those sentences are acceptance criteria written before the work starts. They convert a list of outputs into a set of tests, and a test written in advance is the only kind that cannot be argued away at handover.
Around the twelve outputs, two tracks were drawn to run continuously across all fourteen weeks instead of closing the engagement: programme and dependency management, and the commercial model with its business case and financials. Most schedules treat both as terminal activities, which is how a business case arrives too late to change a design and how a dependency surfaces as an escalation.
The dependency track was the more carefully built of the two, and it is the part we would copy outright. Every dependency was to be contracted between the side that provides it and the side that receives it, with the coordinating office accountable for running that process. Then four kinds of dependency were separated and each given its own owner and mechanism. Dependencies on a solution were to go through a standing design authority, so that anything spanning more than one workstream would be assessed end to end rather than at each end separately. Dependencies on requirements were to go through a named requirements owner and a traceability record, so it would stay clear which workstream was accountable for delivering what. Dependencies on benefits were to be documented and watched through change control, on the explicit reasoning that a benefit case is eroded by incremental change rather than by any single decision. Dependencies on timing were to be driven into one integrated plan with a single owner.
Four cross-portfolio reviews were placed across the fourteen weeks, which is one every three to four weeks. The plan does not say what they were for. A design that owns two strands and leans on strands it does not own has one thing worth reviewing at that cadence, and it is not status. Governance was drawn so that accountability for outcomes would sit at project level rather than centrally, with the coordinating office holding the things that genuinely cross workstreams: change control, the dependency process itself, and one plan holding the whole of it.
The outcome
Be clear about what this document is. It is a proposal, and a large part of it is the proposing firm describing what it can do. The fourteen weeks were offered. The twelve outputs were offered. Nothing here was delivered, no acceptance statement was ever tested, and the source does not record whether the work was bought or whether any of the twelve arrived. The reason to publish the shape anyway is that the shape is reusable regardless of how that engagement went.
Three things we would build differently now.
The deliverable ledger should be instrumented rather than drawn. Twelve rows with a week, a form, an owner and an acceptance statement is a record a programme should be able to query, not a picture redrawn for each steering meeting. The same is true of the dependency register: a traceability record kept in a spreadsheet is accurate on the day it is written, and a contract between provider and receiver only means something if breaking it is visible the week it breaks.
The evidence under the outputs should come from the operation, not from interviews. The capability gap analysis and the process architecture are both reconstructions of how work actually flows, and process mining over the servicing and claims event logs produces that reconstruction with a source attached, ranked by volume, rework and touch count. Straight-through processing rates per process are already in the logs. Asking people to estimate them is a choice, and an expensive one.
And the automation deliverables are where machine learning enters an operating-model design, which means data readiness, model deployment and lineage belong in the acceptance statements rather than being deferred to implementation. A model that scores a claim or a renewal is worth building only if the process it feeds can act on the score inside the customer's patience. The early and cautious language-model pilots now appearing in document handling do not change that arithmetic. A model that reads a form well still needs somewhere to put the answer, and where the process cannot act on it the answer lands in a queue. Our Consult engagements start at that landing point, because it is the cheapest way to separate an interesting pilot from a case that will pay.
A plan is legible when every output has a week, a form and a test. A plan is survivable when the dependencies it cannot control have owners from the first week rather than the last.