An operating model that takes a year to design describes an organisation that no longer exists by the time anyone signs it. The people have moved, the portfolio has moved, and it arrives as history. That is why so many groups have a target operating model in a shared drive and no operating model in the building.
A European travel and tourism group was standing up a new digital function. An earlier phase was producing a structural blueprint, due to complete at the end of the month. The proposal for turning that blueprint into something operable did not open with a philosophy. It opened with a number. One hundred and fourteen consultant days across a single quarter, covering roughly thirty processes, role mapping at two levels, a competency model, and a governance cadence with named forums. Almost everything worth learning from it follows from the size of that number.
The challenge
A structure tells you who reports to whom. It does not tell you how a decision gets made, which meeting settles it, who owns the process it runs through, or what a person in a named role does on a Tuesday. The proposal says so plainly: the blueprint completes, and there is then a requirement to build on it through three further streams before any of it can be run.
Those streams were the design of the wider technology function's model, the implementation of the organisation structure down to individual people, and a prioritisation method mapping the existing portfolio against the customer journey, with value to the customer and value to the company kept separate. All of it ran alongside a group-wide reorganisation, with alignment on the overlaps named as a responsibility rather than assumed.
Around thirty processes were identified as needing description. That count is the scoping unit for the whole build, and the sequencing rule attached to it is what most process programmes get backwards. Start with the complex and critical areas, the document says, and it names them: financial processes, capacity management, standing up a hub, gating, product end-to-end management. Then engage the actual owner of each process in the design of it. Easiest-first buys a thicker binder and a model that fails at the first hard case.
Depth was rationed harder than breadth. Ten main processes go to level two first, the remainder follow, and only five reach level three, which is the depth at which a process can be executed rather than discussed. Those five are drawn from the processes the predecessor organisation did not have at all, and that is the sharpest decision in the document: an inherited process can be described from an interview with whoever runs it today, while an invented one has to be designed in a room with the people who will live in it.
One honest caveat. The narrative names six candidates for that deepest treatment while the plan and the price commit to five, so the scope narrows by one between the story and the contract, and neither page acknowledges the other.
The approach
The staffing shape is the argument the rest of the proposal rests on. One hundred and fourteen days split three ways: five days of senior time, thirty-nine of design and facilitation, seventy of production. Effort in inverse proportion to seniority, and a deliberate choice rather than a budget accident. The people who ran the previous phase stay engaged because continuity of context is the scarce asset, and a dedicated producer is added so the detailed flows get made at pace without senior time going into documentation.
Read against the window, those numbers say something the proposal does not. The window holds about sixty-five working days, so the senior presence is about eight percent of it, the lead designer about sixty percent, and the producer, at seventy days, is booked at roughly a hundred and eight percent of the time available. The offer calls the window fourteen weeks; the dates it names come to nearer thirteen. A plan that fits only when the calendar is described generously has an assumption inside it, and the time to name that is before signature.
The most transferable move in the document costs nothing. The organisation design wants a fact-based cost and resource review as its input. Rather than assume that review will land, the proposal names the day in the middle of the first month by which it must, and pre-agrees the substitute if it does not: headcount and job-title data from the people system. No escalation, no renegotiation, no slipped date. That is a data-readiness clause with a calendar attached, and we recommend it to anyone scoping work whose value depends on a dataset somebody else owns.
The same discipline holds the extra work. A further forty-five days sit in the document as a dated option rather than an open change request: twenty-five to describe five processes in detail, about five days each and the only per-process effort figure in it, and twenty to analyse the people data. Confirmation is due on a named day late in the first month. That is a further two-fifths on top of the core day count, parked in an option that expires, which beats a change control that never closes.
The plan is cut into three lanes by operating-model dimension rather than by team, so the dependencies between structure, process and governance sit on one page. Three verbs appear as their own bars: workshop, refine, validate. Putting review on the plan converts a hope into a booked commitment, as does listing "confirm process owner and sponsor" as a gated activity ahead of designing the process. Governance is defined behaviourally, a gating cycle plus customer, product and executive meetings rather than a policy pack, and rules of engagement with three commercial functions are a deliverable in their own right, because the usual failure of a new central function is an unowned boundary. The last milestone is the operating model in use with people trained, which forces training material into scope as a deliverable rather than an afterthought.
The outcome
What this document is, is a scope, a plan and a price. It was written as an offer, not as a record of a result. There is no adoption evidence, no post-implementation review, no claim that any of the thirty processes was ever described. Reading it as a result would be reading a menu as a meal. What carries is the arithmetic, and three things would be done differently on the same scope now. Only the first changes the day count.
The level-two sweep is the largest block of production effort, and it has stopped needing to be a workshop exercise. Process mining over the workflow and case-management event logs produces those flows from what people already do, variants and rework loops visible rather than remembered, and it leaves the workshop budget for the five with no behaviour to mine. The direction is clear even where the size of the saving is not: the document gives no basis for quantifying it, and we will not invent one.
The dated fallback clause deserves to be standard in machine-learning work rather than rare in operating-model work. Model deployments stall on the same shape of dependency, and each would be better for a named date and a pre-agreed worse dataset, with the lineage of whichever was used written down at the time rather than reconstructed later.
The third is cautious. Turning an event log and a policy document into a readable process description is a drafting task, and the early language-model pilots here are useful for a first pass. They do not change the review cycle. Workshop, refine, validate is still what turns a plausible flow into one the owner will sign, and a first pass nobody validates is a faster route to the same shared drive.
The number stays the argument. Our Consult engagements open by asking what day count the operating model is worth, because one priced at a year is not a more thorough version of one priced at a quarter. It is a different document, addressed to a company that will have changed before it lands.