Most design engagements are sold on a total. Fourteen weeks, one quarter, half a year. The total is the least informative number on the page, because a total absorbs things. A decision that slips a fortnight vanishes into it, the end date holds, and nobody has to stand up and say that the thing everyone was waiting for did not happen.
An international health insurance group was offered a plan written the other way round. Six weeks, then five, then three. Four gate workshops with dates attached before any work began, and twelve deliverables, each numbered and placed on a named week. The total is fourteen. The shape is what makes the total mean anything at all.
The challenge
The group had a transformation portfolio in flight, and this work covered two strands of it: where automation and self-service should be applied, and how the service operation should be organised across countries. The proposal said so plainly: those two touch large parts of the operating model and carry many dependencies onto the strands this engagement was not being asked to design. That admission sets the constraint. A design that assumed it could finish inside its own boundary would have been wrong on day one.
A diagnostic phase had already run, and the standard failure at exactly this handover is the second discovery. A new team arrives, reopens the interviews, and produces after three months a document the client could have assembled from the diagnostic in a fortnight. The plan's answer was to build on the outputs of the initial phase and to work by hypothesis: candidate opportunities were to be framed as propositions and tested with the client in a workshop convened for that purpose, rather than researched to a conclusion. Past a certain point, more research is not more accuracy. It is a way of not deciding in public.
Which is why the gates, rather than the durations, are the part worth copying. Four events were named at the outset: an options assessment workshop, a hypothesis testing workshop, a design approval workshop, and an implementation kick off. A plan with continuous review has no moment at which a decision is obliged to exist. A plan with four dated gates has four of them, and at each one a missing decision becomes visible to the room instead of disappearing into the float.
The approach
Stage one, six weeks and the longest of the three, exists to produce a shortlist rather than a design. It asks where process redesign, workflow and automation would most affect four groups at once: customers, partners, providers, and the group's own people. Most automation cases are scored on internal cost alone, which is how a programme surprises its own partner network in month nine. Options were then to be scored in a workshop against two primary criteria, potential value and ease of implementation, and every surviving option traced past the process it changes into the product it sits under, the channels it is served through, and the systems beneath it.
Stage two, five weeks, designs. It refuses to converge early. Each shortlisted option gets its own full picture, with country and regional impact and its own financial and effort implications, and the choice happens after those pictures exist rather than before. The organisational question is reduced to two decision variables, the number of hubs and where they sit, which is far more tractable than arguing service models in the abstract. Everything is tested against quality, cost and delivery.
Stage three, three weeks, turns a design into a phased plan. Cost and benefit are assessed per phase of change rather than for the programme as a whole, so phasing can be sequenced on value instead of technical convenience, and only the first phase receives a resourced plan. Later phases stay at roadmap resolution, which is an honest statement about how much anyone can know about month eleven.
Two tracks run continuously across all fourteen weeks instead of being back-loaded: programme and dependency management, and the commercial model with its business case and financials. Four cross-portfolio reviews sit across the timeline, and their only job is to keep this work aligned with the priorities it does not own. Dependency management as a standing activity rather than a closing chapter is what most schedules get wrong, and a scope that owned only part of the portfolio made it unavoidable here.
Twelve deliverables were named and numbered, running from confirmed objectives, scope and plan through design options, refined customer journeys, a target capability map with gap analysis, a cost and benefit model, the target operating model with its process architecture, a roadmap and transition plan, and an outline business case at the end. Six of the twelve were described in detail, and each description was paired with the specific assurance the client would get from it. That pairing is the quiet mechanism in the whole document. It converts a list of outputs into acceptance criteria: the document already states what the client is entitled to be sure of once each one lands.
The outcome
Be clear about what this is. The document is a proposal. It designed and priced the work; it did not report on it. Every number here is a plan: three stage lengths, four gates, twelve deliverables, four cross-portfolio reviews, two continuous tracks. None of them is a result, and the source does not say whether the fourteen weeks held or whether the investment case was ever signed. The reason to publish the schedule anyway is that its shape is reusable independently of how that particular engagement went.
Three things we would build differently now.
First, stage one's activity list is dominated by reconstructing how work actually flows: operational scenarios, customer journeys, workflow design per segment, user experience mapping. Nobody can rank where to intervene until that reconstruction exists, and it no longer has to be interview work. Process mining over the claims and servicing event logs produces the current state with a source attached, and it ranks automation candidates by volume, rework and touch count rather than by who argued best in the room. Straight-through processing rates per process are already sitting in the logs; asking people to estimate them is a choice, and an expensive one. It does not shrink stage one to nothing. It changes what the six weeks are spent on, from establishing facts to deciding what to do about them.
Second, the financial model. A cost and benefit model built once in a spreadsheet is true on the day it is signed off and drifting from the day after. If the commercial track genuinely runs all fourteen weeks, the baseline should be refreshed from the same event data the design is being built on, so the benefit claimed at the end is measured against the operation as it now stands rather than as it stood at kick off.
Third, automation. The plan defines workflow and automation options per function, underwriting, claims and customer service each getting their own, rather than as one switch thrown across the business, and that is where machine learning quietly enters it. A model that scores a claim or a renewal is only worth building if the process it feeds can act on the score inside the customer's patience. That makes model deployment, data readiness and lineage gate items in stage two, not technical detail deferred to implementation. The early and cautious language-model pilots now appearing in document handling change the deliverable list at the margin and the schedule's shape not at all: 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. The Platform work we do begins at that landing point, because it is the cheapest way to tell an interesting pilot from a case that will pay.
Fourteen weeks is not the finding. Six, then five, then three, with four dates fixed before the first interview, is the finding. A schedule built that way cannot quietly absorb a decision that nobody wanted to make.