Wiki:Packs/Organization Design and Role Cards
From WFM Labs
| Pack | |
|---|---|
| ID | CP-WFM-014
|
| Domain | WFM |
| Version | 1.0 |
| Blocks | 1 instruction + 4 reference |
| Source | Functional Organization Design for a Resource Optimization Center · Role Cards for a Workforce Function · Resizing a Workforce Function After an Acquisition · ROC Organization Models · Role Evolution in the Resource Optimization Center · WFM Roles |
| Planning-week block | Day 2 morning |
A pack is a deployable set for a Claude project: one instruction block pasted into the project's custom instructions and reference blocks uploaded as project knowledge. This pack supports the Day 2 morning working session of a planning week, in which a room chooses the structure of a workforce function against six criteria, prints the sunset conditions on the transition chart, writes the role catalog as cards (T2), and records how the function's size follows the estate; it produces the org options table, the transition chart, the role cards (T2) and the resizing note (RN).
When to use it
Create a project from this pack when a working session is choosing an org option, writing sunset conditions, drafting or amending role cards, or writing the resizing note, during the Day 2 morning block or afterward in a function owner's service pack. It is not for the RACI or the forum cards (those are produced with Wiki:Packs/GRPI-T Instantiation), not for the agent program's readiness check on the third lever (Wiki:Packs/Agent Program Readiness), and not for any decision about where a body of work should sit.
How to deploy
- Create a project in Claude named for the work, not the method.
- Paste Block 1 into the project's custom instructions.
- Save each remaining block as the filename in its heading and upload as project knowledge.
- Start a conversation with the template you are filling.
Block 1 — Project instructions
# Organization Design and Role Cards
## Context
This project supports the Day 2 morning working session of a planning week in which a workforce management function chooses its structure under one leader, prints sunset conditions on the chart, writes its role catalog as cards, and records how its size follows the estate. It produces the org options table against six criteria, the transition chart, role cards (T2) and the resizing note. It designs structure and roles; it does not size teams, name people or decide where work sits.
## Routing
| When the task is... | Open |
|---|---|
| writing the six criteria for an estate; computing the faces arithmetic; comparing the three options; presenting the leader's proposal with alternatives | `org-options-and-criteria.md` |
| writing a sunset condition; testing whether a seat or assignment is transitional; showing how a standards owner carries a migration without the migration owning the standard | `sunset-conditions.md` |
| drafting or amending a role card; the catalog by horizon; the two added roles; partner-held posts | `role-cards.md` |
| writing the resizing note; the three levers; the size test; what to say to the people | `resizing-method.md` |
## Disciplines
- Criteria before charts; the room argues with the six criteria, never with a drawing. Write both faces counts for every option.
- Every option draws placement as a named function; its existence is a consequence, not a vote.
- Present the portfolio-facing structure as the function leader's proposal, with the alternatives beside it, the criteria it passes and the risk it carries.
- The standard is held by a platform configuration, a definitions register and a change-control board, never by a seat or a migration.
- Every transitional seat or assignment carries a testable sunset condition and a destination for its work; a date is not a condition.
- A role card describes a role, not a job; its count direction is a word (new, up, flat, down, retires as a title), never a number.
- Partner performance is a competency in every role, not a team; partner-held posts are "transitional until automated" with a named owner for the automation plan.
- Size is an outcome of three levers in order (standardize the method; consolidate the platform; hand written-down work to agent teams), never a target.
- Frame every heritage as correct for the business it served; never characterize a current state as duplication, failure, absence or neglect.
- Owners and participants are seats, never names. Estate figures are ranges with grades.
## Output
A filled template in a Markdown table with the columns in order and a permanent ID where the template has one (`RC-nnn`, `RN-nnn`), then one line giving the grade of any current-state claim and the assumption behind any estimate. Refuse: any headcount, seat count, ratio or percentage about the function's size; a person's name against a seat; a placement or sourcing decision; a maturity level as a point.
Source: Wiki:Packs/Organization Design and Role Cards (CP-WFM-014) v1.0
Block 2 — org-options-and-criteria.md
<!-- Derived from [[Functional Organization Design for a Resource Optimization Center]] and [[ROC Organization Models]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Org options and the six criteria
## Governing sentence
*Same people, clearer structure.* The structure is a maturity ceiling: the next level needs a function-shaped slot for each capability it requires, and a structure organized by inherited entity has several places each could live and none where it must. The people are not the ceiling.
## The six criteria (write these down before any chart)
Criteria 2 and 3 are the two tests ROC Organization Models sets out, carried unchanged; 1, 4, 5 and 6 are what a room needs beside them to leave with a chart.
| # | Criterion | Write down |
|---|---|---|
| 1 | Faces arithmetic | two counts per option: counterparts per business leader; counterparts per department for the same question |
| 2 | Pooling test | the share of work that is place-bound (regulation, data residency, on-soil promise) against the share servable from anywhere, at the constraint set expected at the end of the horizon; that language constraints may decay while regulatory and data-residency constraints do not is the working assumption ROC Organization Models records, to be tested estate by estate |
| 3 | Size test | how large the human organization needs to be at all, as a direction and a dependency on the estate's interior optimum (the wiki's Interior Optimum (containment rate)); never a number |
| 4 | Converge or ratify | whether the option produces one method and one source of truth or ratifies the inherited ones |
| 5 | Sunset conditions | for every consolidation seat or assignment, the condition under which it ends |
| 6 | Spans | whether each leader's span is defensible for the coordination load; small spans over multi-time-zone, multi-partner coordination are by design; no source validates a total leader count |
## Three options
| | A. Global functional | B. Portfolio-facing with a standardization seat (the proposal) | C. Functional with regional delivery |
|---|---|---|---|
| Organized by | stages of the planning cycle; placement its own block; reporting and administration supporting | two layers on two axes: thin leader-facing portfolio seats (three in the first year: global multinational; small and midsize enterprise; specialty, a regional and specialized-services portfolio) over an execution layer; a placement seat; a standardization seat | functional blocks with regional cells; a standalone block for a regulated segment |
| Faces | departments one per question; leaders several | leaders one; departments one per question | leaders one per region; departments one per region and reconcile |
| Pooling | across the estate | in the execution layer; portfolio layer re-pointed when books move | limited to a region; may regionalize around decaying constraints |
| Size | once, by function | by function in the execution layer; portfolio layer small | per region; capability bought several times |
| Converge or ratify | converges | converges in the execution layer | ratifies regions |
| Sunset conditions | none needed | the migration assignment time-boxed; any real-time consolidation box carries a condition and a destination | none |
| Where placement sits | own block | own seat; absorbs real-time operations at sunset | own block with regional cells |
| Maturity form | Level 3 | Level 3 execution layer under a Level 4 leader layer | Level 2 residue formalized |
| Right when | the room rejects a matrix inside the function | leaders need one counterpart and the estate must converge at the same time | rarely at the planning layer; regional presence belongs in execution |
## The risk option B carries (say it before the vote)
A three-way split (partner, shared service, center of expertise) resolves tensions short-term and fragments accountability long-term unless something other than the seats holds the whole: one platform configuration, one definitions register, one change-control board. A room that cannot name all three has not chosen B.
## Placement as a named function
Every option draws it. It exists because the engine needs an owner for the constraint register and the gate, and the registers need a steward who owns method and never an outcome. Debates about placement are usually debates about whether the node owner keeps the decision; that is settled as a principle and expressed as the RACI's first rule.
## Long-range capacity planning elsewhere
May sit in another organization. Treat the horizon as a hardwired interface (owner both sides, cadence on the cycle's calendar, shared definitions), drawn as a wire on the chart, not a dotted line and not a defect.
## Decisions this produces
D-03 the option against the six criteria with both faces counts written; D-04 the sunset conditions printed and where real-time operations report at sunset (to placement recommended; to the portfolios re-fragments the method). If the room chooses A or C, owners on the standard's sections, the program charters and the roadmap lanes are re-cut in the validation circuit.
Block 3 — sunset-conditions.md
<!-- Derived from [[Functional Organization Design for a Resource Optimization Center]] and [[Resizing a Workforce Function After an Acquisition]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Sunset conditions and the standards owner who carries a migration
## What a sunset condition is
A sentence, printed on the chart, that a stranger could test, naming what must be true for a transitional seat's or assignment's work to end, and where the work goes. It is the seat's contract with the people in it: they know what they are building, that it ends, and that it ends because they succeeded.
| Good | Not a condition |
|---|---|
| "when one scheduling standard is live on one platform and schedulers are reassigned to the portfolio seats" | "end of next year" (a date becomes a deadline the standard is bent to meet) |
| "when the real-time protocol and the automation layer are live; work transfers to the placement seat" | "when the consolidation is complete" (untestable) |
| "when the last migration phase is accepted at the change-control board and the book runs on the standard configuration" | "at the leader's discretion" |
## Test for whether something is transitional
Ask: does it exist to make itself unnecessary? If yes, it carries a condition and a destination. If it would still exist with one method, one platform and every written-down process handed to agents, it is not transitional and carries no condition.
## A standards owner who carries a migration
The pairing: the standardization seat owns the forecasting, scheduling, real-time and placement standards **and** leads the migration of the largest book onto the platform. The migration is the forcing function; the standards owner is the person best placed to refuse a shortcut that would fork the standard.
The risk: the migration comes to own the standard (a deadline amends a definition; a book's inherited configuration becomes the instance default).
The three holders that prevent it:
| Holder | Holds | How the migration reaches it |
|---|---|---|
| One platform configuration | activity codes, skill and pool dictionary, lock calendar, configured once to the standard | the book is configured to the instance; never the instance to the book |
| One definitions register | versioned definitions every report and platform reads | a migration may propose; only the register's change control (propose · review · version · adopt) adopts, with the register's signatories |
| One change-control board | routing, configuration, contracts, the migration schedule; chaired by the placement seat; the standardization seat a member, not the chair | each phase is a change-control item; a phase needing an amendment to the standard waits for the standards committee's acceptance gate |
Consequences to write on the chart:
- What is time-boxed is the migration assignment, not the seat. The sunset condition is the assignment's; the seat keeps the standards.
- The standard's owner, approvers and expiry live in the standard's front matter and do not move with the migration's dates.
- The seat reports the migration to the board and the standard to the council: two audiences, two rooms, no trade between them.
## Where real time goes at sunset (D-04)
To the placement seat (recommended): real time is the horizon at which the engine acts, and the capability layer needs an execution owner. To the portfolios: the real-time method re-fragments by book. Record the choice in the decision record and re-read the conditions at every validation circuit.
## Checklist for the chart
- [ ] every transitional box has a condition and a destination printed on it
- [ ] no condition is a bare date
- [ ] the three holders of the standard are named
- [ ] the migration appears as change-control items, not as a box
- [ ] the long-range planning interface is drawn as a wire where it sits elsewhere
Block 4 — role-cards.md
<!-- Derived from [[Role Cards for a Workforce Function]], [[Role Evolution in the Resource Optimization Center]] and [[WFM Roles]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# Role cards (T2)
## Role, not job
A job is a post with a grade and a person; a role is a bundle of responsibilities the function needs held. One person may hold two roles; one role may be held at several nodes. Write the cards independently of the posts so that one role under three titles, and one title over three roles, become visible.
## Columns, in order
`ID (RC-nnn) · Role · Horizon · Rationale · Responsibilities · Skills · Forums · Node attribute · Evolves to · Count direction`
| Field | Rule |
|---|---|
| Rationale | one sentence that would be false if the role were removed; a role with no rationale should not exist |
| Responsibilities | three to six, active voice, each with an object; matched to the RACI rows |
| Skills | capabilities, not qualifications |
| Forums | by name; the forum cards are built from this field |
| Node attribute | which nodes the role is held at; badged or partner-held |
| Evolves to | the Level 4–5 form, cited from the role map, not redrawn |
| Count direction | new · up · flat · down · retires as a title; never a number |
## The catalog by horizon (draft; the room accepts, amends or strikes)
| Horizon | Role today | Evolves to | Node attribute | Sits with |
|---|---|---|---|---|
| 12–36 months | capacity planner | scenario architect and translator | all; the network design | portfolio seats, or the organization holding long-range planning; simulation from placement |
| annual / quarterly | WFM manager | center leader / workforce strategist | all | portfolio seats |
| monthly | forecaster, mid-term | probabilistic forecaster | all; per book | portfolio seats |
| weekly / daily | forecaster, short-term; scheduler | probabilistic forecaster; schedule designer | badged and partner-held, transitional until automated | short-term forecasting with portfolio seats; scheduling under the standardization seat until the standard is live |
| intraday / real time | real-time analyst | automation orchestrator; agent overseer | badged and partner-held | the real-time consolidation box, to placement at sunset |
| any | reporting analyst | workforce intelligence analyst | all | beside the definitions register's owner |
| any | partner performance analyst | node performance on one instrument (a product) | instrument central; verdict with the node owner | placement seat |
| any | continuity planner; crisis communications lead | placement under duress; the crisis re-plan (products the center keeps; whether the roles leave with continuity or move into the center, as Role Evolution in the Resource Optimization Center describes, is decision D-10) | the wire, not a team | placement seat |
| any | methodology steward (added) | unchanged; gains the engine's explainability records | all | placement seat or a named deputy |
| any | automation analyst (added); operations research analyst | as named | all | placement seat; the analytics function |
## The two added roles (added to the function, not to the wiki)
Role Evolution in the Resource Optimization Center already lists the automation analyst among the roles that are new, and The Automation Analyst is its own page; the methodology steward is the one this catalog introduces. What the catalog adds for both is the horizon, the node attribute and the seat.
- **Methodology steward**: owns the objectives, constraint and definitions registers and the counterfactual record; chairs the standards committee; owns method and never an outcome. Home: the placement seat, with a deputy where the span will not carry the registers.
- **Automation analyst**: converts an L2 step table into an agent specification, reading from the table and never from memory; owner of the resizing method's third lever; reads for the acceptance gate's two automation criteria (step ownership; active voice).
## Partner performance and partner-held posts
- No partner-management team on the catalog. Partner performance is a competency in every role's skills field. Commercial comparison across suppliers stays central and commercial.
- Partner-held posts (schedulers, real-time analysts, some short-term forecasters) are "transitional until automated", with a named owner for the automation plan; same role as the badged twin, different custody line. Not a sourcing decision; that is the gate's.
## Session rules
- Cards are drafted before the week from the role map and accepted in the room; not written from a blank sheet.
- A card is accepted only with its forums filled.
- Count direction is stated once; a number, if ever needed, is the resizing method's output.
- The automation analyst and the overseer are accepted even where the first handover is a year away: the agent ladder's alpha rung needs a named overseer.
## Example row (illustrative)
| RC-001 | Methodology steward | any | the method needs an owner who never owns an outcome | owns the registers and the counterfactual record; chairs the standards committee; runs the validation clause | process standards; queueing arithmetic; evidence grading; writing | council; change-control board; placement forum (method) | all | unchanged; gains explainability records | new |
Block 5 — resizing-method.md
<!-- Derived from [[Resizing a Workforce Function After an Acquisition]]; figures marked [estimated] are judgment, not measurement; this block carries no figures by design. -->
# The resizing method
## Premise
Each acquired estate arrives with its own planning function, sized and shaped correctly for the business it served. The combined function's size is an outcome of three levers pulled in order, never a target set first. The reviews of three decades of downsizing research report that a reduction taken as a target often does not deliver the results expected of it and is frequently followed by rehiring, with substantial variation by context and by how the reduction is implemented; the finding that holds across them is comparative, that reductions accompanying a redesign of the work fare better than reductions taken alone.
## The note's table
`ID (RN-nnn) · Lever · State today (graded) · What must be true before it is pulled · Owner (seat) · What the size does when it is pulled`
| Lever | What it does to the work | What it does to the size | Precondition |
|---|---|---|---|
| One. Standardize the method | one forecasting method, one scheduling method, one real-time protocol, one placement gate, written to the standard | removes reconciliation work (the parallel forecast, the parallel report, the argument at every close) | the definitions register exists; the standards committee sits; the acceptance gate admits a document |
| Two. Consolidate the platform | every book on one configuration of the short-term WFM engine and one long-term capacity engine, migrated book by book, definitions first | removes the work of parallel instances, parallel activity-code sets and parallel lock calendars; the platform's automation reaches every book | lever one produced the configuration; each migration is a change-control item with an acceptance gate |
| Three. Hand written-down work to agent teams | highly specified work runs as an agent team with an overseer and a published catch rate; uncertain work stays with analysts who return a range | removes routine from the roles that held it; people move to checking, modeling and exceptions; count directions are realized | the process passed the handover gate; the overseer is named; the ladder's alpha rung ran in shadow |
The order is dependency: a platform consolidated on unsettled definitions makes every early record wrong; an agent team clones only onto a book whose definitions are in the register.
## The size test
Asked of the estate before the function: the planners are sized to the population they plan, and that population is bounded by the estate's interior optimum, measured on its own work (see the wiki's Interior Optimum (containment rate) and The Hardening Residual). A function that has not measured its interior optimum records the size test as **Open** and does not estimate around it.
## Sunset conditions
Every consolidation seat carries a printed condition and a destination (see `sunset-conditions.md`). A condition, not a date.
## What to say to the people
- Roles evolve; every card names its destination.
- New job classes open (automation analyst, overseer, probabilistic modeler, steward); first hires from the function's own planners.
- Count direction is a direction, realized only through the levers; no one is sized out of a function whose routine has not been handed anywhere.
- Retraining is planned before the handover; a title that retires is a person whose work relocates, and the function owes them a path.
## Framing rules (non-negotiable)
- No figure of any kind about the size of a function: no headcount, no seat count, no ratio, no percentage, no benchmark, and no count of an estate's methods, instances or configurations. Describe a current state in words.
- Never characterize a current state as duplication, waste, failure, absence or neglect.
- The current state is several correct answers placed side by side.
- The agent-team compression of planner effort is a claim to be measured, not a result.
- The share of the function's work that is routine is measured by decomposing its processes and counting what passes the gate; until then it is Open.
## Refuse
Any headcount, seat count, ratio, percentage or benchmark about the function's size; any name against a seat; any placement or sourcing decision.
Usage notes
Sizing: the instruction block is just under 500 words and loads with every message; the four reference blocks are 450–750 words each and are read on demand through the routing table. Drift: the blocks are derived from the six source articles, not copied; regenerate them and increment the version when any source article changes materially. Scope: the pack designs structure and roles and records the resizing method; it carries no figure about the size of any function, and it refuses a headcount, a name against a seat, and a placement decision.
Change history
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-09 | First release |
