The Case for Operating Model Planning

From WFM Labs


The map a planning session works from. Eight components, one question each, with sourcing running through all of them. Leadership answers the eight questions together; the function builds from the answers.

Operating model planning is the practice of a leadership team setting aside its operating rhythm for a defined period, typically a day or two, to answer the eight questions of an operating model together and write the answers down. It is distinct from budgeting, from a reorganization, and from a strategy offsite. The output is not a decision about any single placement, hire or tool. It is the agreed set of answers from which those decisions will later be derived, and a plan for building the function that can derive them.

The case for doing it, rather than continuing to run the function and improving it in place, rests on five arguments.

Why leaders plan the operating model together

A function organized by inheritance runs on unwritten answers

Every workforce function already has an operating model. Where the function grew from several heritages, through mergers, regional build-outs or successive leaders, it has several: each part carries its own answers to the eight questions, and the answers disagree. Nobody chose this. Each answer was correct where and when it was given. Planning together is the first time the answers are put side by side, and the disagreements become visible without anyone being at fault. See Inherited Sourcing Doctrine in Merged Service Estates.

Structure is a ceiling, and only leadership can lift it

On the WFM Labs Maturity Model™, the step from a foundational function to a progressive one requires a formal goal framework with trade-offs written down, interval-level reporting owned somewhere, and processes documented to a standard. A structure organized by legacy entity has several places where each of those could live and no place where it must. That is a ceiling on maturity, not a background condition, and it cannot be lifted from inside a single team. It takes the people who own the structure, in one room, agreeing where the capabilities will live.

Decisions made in the room are cheaper than decisions made in the queue

A placement question that arrives as an escalation is answered under time pressure by whoever is available, on whatever evidence is to hand, and the answer sets a precedent nobody examined. The same question answered in a planning session becomes a rule: an objective, a constraint, or a threshold that the function can apply every time afterward. A rule agreed once is applied every time afterward. An escalation answered once is answered again the next quarter, usually differently. This is the argument for a placement engine: the room sets the objectives and constraints once, and the engine applies them as conditions change.

Alignment precedes deliverables

A deliverable produced without the leadership team having agreed what it is for will be re-litigated at every use. A document written for a room is read as somebody's proposal, and every use of it reopens the question of whose. A document written by the room is read as settled, because each person in it has already spent their objection. The templates a planning session fills in live are therefore the deliverable: the act of filling them is the alignment.

The climb has an order, and the order needs a sponsor

The steps are not independent, and doing them in the wrong order costs the work twice. Data definitions come before comparability, comparability before governance, governance before contracts, contracts before automation, and all of them before an engine can run. Each step has a different owner. Sequencing across owners is a leadership act, and the sequence has to be agreed before the first step starts or the steps will be taken in the order they are easiest, which is rarely the order that works. The dependency order is set out on Vendor Ecosystem Restructuring Agenda.

What happens in the session

The ring is the map. It is shown once at the start, and again at the head of each section with the current component highlighted, so the room always knows which of the eight questions it is answering. Each component is worked in the same four beats: a definition of the component, the truth about today stated without blame, a proposal with options where options genuinely exist, and a template the room completes live.

By the end, the room has agreed:

  • a vision, chosen from candidates, and the strategic intents beneath it, on one page;
  • a short set of operating principles, each with what will be different under it;
  • the scope line: what the function owns, what it is wired to, and what belongs to operations;
  • a landscape of where work sits today and where it will sit at the end state, and the transitions between;
  • the decision rights by planning horizon, and the few forums that hold them;
  • the capabilities the function needs, and which of them have no owner today;
  • the unit of value the scorecard will read;
  • the roadmap, as the same content as the vision page sorted into lanes and quarters.

Run over four days, the session is a planning week: eight half-day blocks, each walking the wiki pages for one component in the order above, taking its decisions and filling its template in a working session on a Claude project pack.

What the wider team receives

The team does not receive a decision about its own work. It receives three things.

  • The filled templates, published as the current answers to the eight questions, with a change history so later revisions are visible.
  • A service pack for each function, in which every enterprise answer is inherited and every function-specific answer is a template for that function's leader and team to complete. The team builds its own path; it does not have one handed down.
  • A validation circuit, in which the answers go back to the people who run the work before they are treated as settled. The room's answers are for validation, not for compliance, and the function is expected to correct them.

What planning is not

It is not a reorganization announcement; structure is one of eight components and is decided for the next transition state only. It is not a headcount exercise; the unit of the model is value, and nothing in the session sizes a team. It is not a sourcing decision; sourcing runs through every component because supply is a property of each answer, not because a supply model is being chosen in the room. It is not a decision on any individual placement of work; those remain with the owners of the work, made later against the rules the session agreed. And it is not final. The answers carry a revision number for a reason.

How to read the ring

When the ring appears, read it as a table of contents rather than a diagram. Each oval is a question the leadership team has committed to answering in writing. The gold ring through all eight is sourcing: vendor and captive supply are inside every component, not a component of their own, so no team should expect a separate vendor plan to arrive later. The center is the coordination point the eight answers describe. What the ring does not show is who decides any particular placement, because that answer lives in the governance component, and it belongs to the owners of the work.

Running the session as a planning week

The chain of pages that runs the session over four days, Day 1 to Day 4, is Planning Week for a Workforce Function. It lays the eight components on eight half-day blocks in the GRPI-T order, so that nothing decided later reopens anything decided earlier; it names the pages walked in each block, the sixteen decisions in sequence, the Claude project pack each working session deploys, and the artifact that walks out of each block. The five arguments above are the reason to run it; the launch page is the map. A room that has a day and a half rather than four days runs the same eight blocks in the same order with the working sessions moved into office hours afterward; the launch page says how.

See Also

Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=The_Case_for_Operating_Model_Planning&oldid=4769"