Planning Week Session Guide

From WFM Labs

Companion to the Planning Week chain · the chain's reading order, its sixteen decisions and its template register are on the launch page

The planning week session guide is the orientation layer of a planning week for a workforce function. The launch page says what the week is and lists the eight half-day blocks; this page opens each block and says, for every page walked inside it, what that page is in two or three sentences and what leaves the room when that session ends. It exists so that nobody has to read a page to find out whether they need to read it, and so that a participant who joins one block can arrive knowing what that block is for. It produces no artifact of its own and takes no decision; every artifact, decision and pack named below belongs to the page that carries it.

The week runs in GRPI-T order — goals, roles, processes, interpersonal and interconnected, technology — which is why the blocks read in the sequence below rather than in order of urgency.

How to use this page

A participant reads the block they are in and the block before it — between seven and thirteen entries. A facilitator reads the page once before Day 1, and uses the outcome column as the checklist for what must exist before each block closes. Someone deciding whether to attend reads that block's opening paragraph alone.

Every entry states its outcome in the same shape: the decision the session takes, if it takes one, named by its identifier on the launch page's list of sixteen; the artifact that leaves the room, named by its template identifier where the launch page's template register assigns one; and the plain-language consequence. Twenty-eight of the forty-one entries take no decision at all, and those say so — a session with no decision is not a session with no output.

Timings are this page's convention, not the launch page's; the launch page fixes only the five-minute open and the four ten-minute technology sub-plans, and those are stated in their entries. Otherwise a half-day block of roughly three and a half hours divides between its entries and its working session, so a three-entry block gives each session about forty minutes and a six-entry block about twenty-five; each block's opening paragraph states its own split. A block that runs long takes the time from its own later entries, never from the next block.

Four scales on this wiki use the word "level"; the chain states the difference once, in the Maturity Model Position section of Planning Week for a Workforce Function.

Day 1 morning — the open, the truth about today, the strategy

The week opens by agreeing what is being planned and how the current state will be described, then puts the strategy on one page. One decision, D-01. Six entries, about twenty-five minutes each after the five-minute open. The working session runs on CP-WFM-011.

Session What it is What leaves the room
Planning Week for a Workforce Function — the open The launch page read aloud in five minutes: what the week is, what walks out on Day 4, and what is not on the table. It states the ordering rule — nothing decided later reopens anything decided earlier — which is the rule the facilitator will invoke all week. No decision; no artifact. A room that knows the week produces filled templates rather than a deck, and knows that a question outside the list of sixteen will be parked rather than argued.
The Case for Operating Model Planning Why a leadership team stops running the function for a few days to answer the eight operating-model questions together, and how that differs from budgeting, from a reorganization and from a strategy offsite. Its output is not a decision about any single placement, hire or tool; it is the agreed set of answers those decisions are later derived from. No decision; no artifact. Agreement on what the week is for. One of the two pre-reads.
Operating Model for Workforce Management The eight components of a workforce management operating model and the single question each one answers. It also explains why sourcing appears inside every component rather than standing as one of them. No decision; no artifact. The eight components as shared vocabulary, so a disagreement can be located in a named component.
Truth About Today A funnel method for stating the current state without blame: five situations, four barriers, one question, and a maturity band rather than a point. Each line carries a claim grade, so the room can see which statements are observed and which are asserted. No decision. Artifact: the truth funnel (TF) — five situations, four barriers and one question in the room's own words, with a maturity band. Disagreements about the current state surface here rather than on Day 3.
Strategy on a Page The four-row grid — vision, intents, dated outcomes, programs — that puts the function's strategy on one page, and the argument that the roadmap is that page's second view rather than a separate document. D-01 taken: ratify the strategy on a page. Artifact: the SOAP grid (SG). Vision, mission line, five intents with technology as enabler rather than pillar, the twelve principles and the level target. Every later block is checked against this sheet.
Operating Principles for Work Placement Twelve rules of the road for a function that places work, written as cards with a "what will be different" line on each. Three of the twelve break something downstream if struck, and the page names which three. No decision. Artifact: twelve principle cards (PC), each with its rationale and its "what will be different" line. The cards are what a later proposal is checked against; the discussion is not the output.

Day 1 afternoon — the charter and the goals

The first GRPI-T pillar. The function writes its charter, then turns the Goals pillar into a filled sheet. One decision, D-02. Three entries, about forty minutes each. Packs: CP-WFM-012 and CP-WFM-013.

Session What it is What leaves the room
Function and Program Charters — the function charter One charter template covering both a workforce function and its programs: the fields, how a program charter cascades from the function charter, and why what is out of scope is written down explicitly. The block uses the function half; the program half returns on Day 4 morning. No decision. Artifact: the function charter v0.1 (CH-001) with its mandate, its scope-out list, its decision-rights summary, its signatories and its expiry. A later argument about scope is settled against this document.
Instantiating the GRPI-T Framework How a planning room turns the five GRPI-T pillars into five filled sheets, each with a headline, an owner and a template. It carries the ordering rule the whole week follows, and this session takes the Goals pillar. D-02 taken: the goal frame. Artifact: the goals sheet (T1) by horizon and category, with a measure, an instrument, an owner and a paired metric on each row. The frame fixes four categories, weights per node with a body-of-work override, value as the unit, quality score and customer-experience index paired rather than blended, and targets by service tier rather than by location.
WFM Goals The objective-setting architecture for a workforce function, from enterprise alignment down to interval-level targets, and why goals are the connective tissue between strategy and daily execution. Without them, forecasting, scheduling and real-time work stay technically competent and strategically disconnected. No decision. Artifact: the Goals headline — one sentence for the GRPI-T sheet — and the interval-level end of the goal cascade filled in, so the frame taken in the previous session reaches the work the planners actually do.

Day 2 morning — roles, organization and decision rights

The block that carries the week's structural decisions. Three decisions, D-03 to D-05. Four entries, about thirty-five minutes each, with the organization option taking more. Packs: CP-WFM-014, with the RACI from CP-WFM-013.

Session What it is What leaves the room
Functional Organization Design for a Resource Optimization Center Designing a workforce function that sits under one leader: six criteria, three options assessed against them, work placement named as a function in its own right, and sunset conditions printed on whichever option is chosen. The chart is treated as a transition state, not an end state. D-03 and D-04 taken. Artifact: the functional org chart as a transition state. One option chosen against the six criteria with the faces arithmetic written down (D-03), and the conditions under which the structure is dismantled — including where real time goes at sunset — printed on the chart itself (D-04).
Role Cards for a Workforce Function The role card as the unit of role definition — a role, not a job — with a catalog organized by planning horizon, and two roles this design adds that most functions do not currently have. No decision. Artifact: role cards (T2) for the seats the chosen option creates, each with rationale, responsibilities, skills, forums, node attribute and the role it evolves into. Hiring and promotion conversations get a document rather than a title.
Resizing a Workforce Function After an Acquisition Sizing a merged function: size follows the estate through three levers applied in order, never a headcount target applied first. Headcount is an outcome of the method, never an input to it. No decision. Artifact: the resizing method (RN) — the three levers in order, the size test and the sunset conditions — which yields a size for the function that can be re-derived when the estate changes. Where no acquisition is in play, the same three levers size the function against growth.
Decision Rights by Planning Horizon Who decides what, organized by planning horizon, with method separated from decision and exactly one accountable body on every row. It also defines the four standing forums the rights are exercised in. D-05 taken: decision rights and the four forums. Artifact: the RACI by horizon (T3), four forum cards, and the Roles headline. The first rule is method versus decision; declines are recorded with their price as routine; the placement forum is lock-and-decide. This is what stops the same question being decided twice by two bodies.

Day 2 afternoon — processes and the shape of the Standard

The Processes pillar. The room catalogs its processes before writing any of them down, agrees what "highly specified" will mean, and sees two worked patterns so the shells are not abstract. Three decisions, D-06 to D-08. Six entries, about twenty-five minutes each. Packs: CP-OPS-001 v1.1 and CP-OPS-003.

Session What it is What leaves the room
Anatomy of a ROC Standard The document a workforce function issues as its own standard: front matter that expires, a function catalog, and sections built in ten repeating blocks. This session covers its shape only; the room returns on Day 4 morning to issue it. No decision. Artifact: none yet — the Standard's shape agreed. The room now knows it is filling sections of a real document with an owner and an expiry, which is what makes the next session's catalog a table of contents rather than a list.
Process Shells for a Workforce Standard Cataloging a function's processes before writing any of them down, using the L0 card as a shell — identity filled in, method block deliberately empty, and a "skeleton until" date on the face of the card. D-08 taken: one capacity-cycle calendar. Artifact: the function catalog and L0 shells (T4). Every process classed, with a "skeleton until" date on each shell so what is not yet written is visible rather than missing; and one calendar for every book, published a year ahead, with an owner.
Process Standardization Lifecycle The three-phase, seven-step lifecycle that takes a process from undocumented to written down, through an acceptance gate, and then keeps it true as the work changes. The gate is what separates a standard from a folder of documents. D-06 and D-07 taken. Artifact: the first-wave list and the standards committee's charter. The process architecture — catalog, lifecycle, acceptance gate, committee chartered with the queue, one constraint on the first wave (D-06) — and "highly specified" defined once for the whole function (D-07).
Process Decomposition (L0–L3) The documentation standard underneath the shells: one process, four artifacts, each written for a different reader. L0 is the cover sheet, L1 the one-page flow, L2 the owned and timed step table, L3 the job aids that L2 names. No decision. Artifact: none. The four documentation levels as a shared definition of "documented," which is the raw material D-07 is drawn from in the previous session; without it that definition is argued per process.
Three-Step Forecast Build A filled example of a standard section: forecasting across three horizon steps, each consuming the one above it, each built in three layers. It shows what a completed section of the Standard actually looks like. No decision. Artifact: a worked section (SS) the forecasting owner can copy — evidence that the ten-block section pattern holds for planning work rather than an assertion that it does.
Incident Management for Contact Centers The second filled example: the twelve-step process by which a real-time operation detects, tickets, diagnoses, mitigates and closes events that push service level off target, then learns from them. It also fixes the event, incident and problem separation the rest of the real-time material depends on. No decision. Artifact: a second worked section (SS), and the Processes headline. Evidence that the same pattern holds for real-time work, where the steps are minutes rather than months.

Day 3 morning — interconnections

The fourth GRPI-T pillar, read as designed flow rather than as relationship: the function's wiring to the enterprise, and the door work arrives through. Two decisions, D-09 and D-10. Four entries, about thirty-five minutes each. Packs: CP-WFM-013 for the interface cards, CP-OPS-002 v1.1 for the intake door.

Session What it is What leaves the room
Enterprise Interconnection Plan How a function writes down its wiring: a scope table, an interface register, and a single intake door with defined routes. It also carries the interim protocol that runs the placement function by hand until an engine does. D-09 and D-10 taken. Artifact: the scope table and interface cards (T5), plus the interim protocol. Scope and interfaces with owners on both sides of every binding row and the weekly report derived from the register (D-09); and the continuity wire — trigger and product, authority to move work, or both (D-10). Where that authority is already settled above the function, D-10 leaves the list and the week's count is fifteen.
Interconnected Workforce Management The nine interfaces between a workforce function and the rest of the enterprise — operations first as the customer of everything the function produces, then finance, recruiting, training, human resources, technology, commercial, delivery partners and quality — read as one system. The page also states the failure that follows when any flow is left unowned. No decision. Artifact: none — the nine-interface completeness check. Each of the nine is confirmed present in the register or recorded as deliberately absent, so a missing interface is a decision rather than an oversight.
Executive Issue Register A single ledger of the issues receiving executive attention, the intake discipline that keeps it current from routine email updates, and the layered report it produces. Severity, ownership and line of sight are held as separate fields on purpose, and the page says where the practice fails. No decision. Artifact: the intake door card — the six fields and the live routes. The same register discipline is what the week's own decision record borrows on Day 4 afternoon.
The Placement Gate How a placement question reaches a gate of six tests and five possible outcomes, what the gate's output page records — including the counterfactual — and the conditions under which it is rerun. It is the machinery behind the placement function. No decision. Artifact: the gate output page (GO), the placement route on the intake door, and the Interpersonal and Interconnected headline. The door now has somewhere to send a placement question, which is the gap the previous session's register would otherwise leave.

Day 3 afternoon — technology and data

The Technology pillar, and the only block that takes no decision of its own. It walks the page D-12 is taken against, and the build order it settles feeds D-13 and D-14 the next morning. Seven entries, of which four are ten-minute sub-plans, so the first three take about forty minutes each. Packs: CP-WFM-016, CP-OPS-004, CP-WFM-008 and CP-WFM-002.

Session What it is What leaves the room
Technology Migration Plan for a Workforce Function The technology chapter of the week: a component map organized by category rather than by vendor, a build order presented as settled, and integrations with dates on them. Components are described as categories so the plan survives a change of vendor. No decision. Artifact: component cards (T6) by category, the build order dated, and the integration-by-when table. The build order is the input to D-13 and D-14 tomorrow, so it leaves this block settled rather than open.
The Definitions Register The versioned register holding one definition per metric, with fields, signatories and change control, plus the two traps that reliably break such a register. It is the page the book migration, the agent program and the analytics platform all depend on. D-12's page. Artifact: the definitions register v0 (RG) — the entries drafted here, each with its definition, version, instrument, resolution and pairing. The register's ownership and signatories are taken as D-12 tomorrow morning, once the Standard has an owner to hang them on.
Migrating a Book of Business The runbook for moving one book between platforms or owners: definitions settled first, the measurement model agreed before the phase begins, delivered hours read, and the phase sized as a range rather than a date. No decision. Artifact: the book-migration runbook shell (BM) — object inventory, measurement model, delivered hours, the phase as a range — which is what makes tomorrow's "which books go first" a costed question rather than a preference.
Placement Engine Build Path Sub-plan, ten minutes. The hand-run-first path from a placement gate on paper to an engine that recomputes on triggers, in eight steps. The gate is run by hand until the hand-run is boring. No decision. Artifact: a sub-plan shell (SP) with an owner, a first three deliverables, its step in the build order, a measure and a quarter.
Launching an Analytics Notebook Platform Sub-plan, ten minutes. Standing up the notebook component of the reporting platform as the function's modeling surface, under governance rather than beside it. No decision. Artifact: a sub-plan shell (SP), and the platform instance's book identified as a candidate for D-13 tomorrow.
Expanding Intraday Automation Sub-plan, ten minutes. Moving from pockets of intraday automation to a layer: the rule inventory, the order of expansion, and measuring the catch rate before acting on it. No decision. Artifact: a sub-plan shell (SP), with the catch-rate measurement written into it as a prerequisite rather than a later refinement.
Systems Administration for WFM Platforms Sub-plan, ten minutes. Holding platform configuration to the function's own standard: a change-control board, an instance strategy and clear custody of configuration. No decision. Artifact: a sub-plan shell (SP), and the Technology headline for the GRPI-T sheet, which closes the fifth and last pillar.

Day 4 morning — the Standard, the charters and the agent program

The morning turns the week's answers into issued documents with owners against them. Four decisions, D-11 to D-14; three belong to a session below. D-12 — the definitions register's ownership and signatories — is taken in this block against The Definitions Register, walked the previous afternoon; the launch page assigns it to no session here, so the facilitator takes it alongside D-11, the register's signatories and the Standard's approvers being one conversation. Six entries, so about twenty-five minutes each. Packs: CP-OPS-003, CP-WFM-012 and CP-OPS-005.

Session What it is What leaves the room
Anatomy of a ROC Standard — the return The same page as Day 2 afternoon, now used to issue rather than to explain: front matter with an expiry date, and a §2 catalog carrying an owner and a date per section. An expiry is what stops a standard becoming a historical document. D-11 taken: issue the Standard v0.1. Artifact: the front matter and §2 catalog (SD) — owner, approvers, annual expiry, and an owner and a date against every section. It is issued as a shell, not as finished prose; the shelf pages below are what fills it.
The Function Service Pack The fifteen-section workbook each function owner takes home on Day 4, and the validate-prepare-execute rhythm for filling it. Each section inherits the enterprise-level answer the week produced and asks the owner for the local one. No decision. Artifact: the service pack in every function owner's hands. Each director leaves knowing which of the fifteen sections they owe and which enterprise answer each one inherits, which is how the week's output reaches the teams that were not in the room.
Function and Program Charters — the program charters The same template as Day 1 afternoon, now cascaded: seven program charters, each with an objective, scope in and out, an owner named as a seat rather than a person, a first-ninety-days list and its measures. D-14 taken: owners. Artifact: seven program charters (T7). A seat against each program and each lane, plus the program office and who runs it. The scope-out lines are what prevent two programs later claiming the same work.
AI Agent Program for a Resource Optimization Center How a workforce function charters, governs and measures agent teams introduced into its own work — the program treated like any other program, with a charter, an owner and measures, rather than as an experiment. D-13 taken: the first books. Artifact: the agent program's charter (PG-007) and the readiness check per book. The platform instance's first book, and the next book the agent program clones onto. A book whose definitions are not in the register fails the checklist's first line, which is why D-12 precedes this.
The Agent Team Ladder: Alpha to Production Four rungs an agent team climbs on a single book — alpha to production — each with the exit evidence required to leave it, plus the pattern for cloning a proven team onto a second book. A team does not advance because it feels ready; it advances on evidence. No decision. Artifact: ladder cards (AL) showing the rung each team is on, the rung the room sets next, the exit evidence required and observed, the catch rate and the clone source. The cards are how D-13's second book is executed rather than merely named.
A Roadmap Pattern for Agent Teams in WFM The generic sequence for introducing agent teams: the short-term forecasting loop first with planners approving, then the question register, then integration adapters, then the long-term plan, then scheduling and real time. The order follows where failure is contained and where standardization already exists, not where the savings look largest. No decision; no artifact. The sequence the agent lanes are built in tomorrow afternoon, and the one measurement that must precede any of it — what a planner-hour currently covers — carried out of the block as a task with an owner. The page reports that almost no function has made that measurement.

Day 4 afternoon — roadmap, timeline, landscape and the close

The week's answers become a dated plan, and the room closes with the readback. Two decisions, D-15 and D-16. Five entries, about thirty minutes each, with the close protected. Packs: CP-WFM-011 for the landscape, CP-WFM-015, CP-WFM-017 and CP-OPS-002 v1.1.

Session What it is What leaves the room
Work Placement Landscape Four placement bands with current state and end state set out as two rows of one table, the transitions between them, and the argument that location is a consequence of the placement decision rather than an axis of it. No decision. Artifact: the landscape table (LT) — four bands with node attributes, current state and end state as two rows. This table is what the roadmap's lanes are moving between, so it is built before the roadmap rather than after it.
The Two-Arc Roadmap The two-arc, seven-lane roadmap format, the dependency order it enforces between lanes, and the front-load of the first quarter. Its claim is that the roadmap is the second view of the strategy on a page, not a separate artifact. D-15 taken: the first-quarter front-load. Artifact: the roadmap (T8) — seven lanes over eight quarters, a named seat on each, a dependency step and a value marker. What cannot be staffed is struck, and the quarter that absorbs it is named.
Transformation Timeline for a Workforce Function Twelve named workstreams dated across five quarters, with the dependencies between them drawn and the tracks that do not fit shown off the right edge rather than compressed to fit. It also carries a sensitivity table saying what moves a span. No decision. Artifact: the transformation timeline (TL) — twelve dated tracks, the track register, the sensitivity table, and an off-chart column naming what does not fit in the horizon.
Planning Week for a Workforce Function — the close The launch page again, used for the readback. The decision record is read back row by row, on the rule that a decision the room does not remember taking was not taken; the filled templates are read back as blueprint v0.1, "for validation." D-16 taken: the validation circuit. Artifact: the decision record (T9) and blueprint v0.1. Every row marked taken, deferred with a date and an owner, or parked; the full set of filled templates read back; and who corrects the room's answers, by when. Nothing is settled until that circuit has run.
Open Office Hours for Next-Generation Workforce Planning The standing twice-monthly forum, open to everyone in the function, where people bring a real problem and learn the function's next-generation skills by solving it. Anything brought on the day takes precedence over the standing agenda, and every session leaves something behind. No decision; no artifact. The forum named as where the fifteen-section service packs are filled over the following weeks, so the answer to "what happens on Monday" is settled before the room breaks.

The shelf: pages the week does not walk

Twelve pages of the chain are the shelf the standards committee works from in the weeks after the week, once D-11 has issued the Standard and D-07 has defined what "highly specified" means. The room walks three of them as patterns on Day 2 afternoon — Anatomy of a ROC Standard, Three-Step Forecast Build and Incident Management for Contact Centers, returning to the first on Day 4 morning — which leaves nine that no session above covers.

Those nine are the forecasting sections (Forecast Lock Process, Forecast Collision Calendar), the real-time and incident sections (Event, Incident and Problem in Contact Centers, Contact-Center Incident Severity Matrix, Real-Time Cause and Effect Fishbone, Post-Mortem and RCA for Workforce Operations) and the partner-facing sections (Call-Sharing Models and Cost Allocation, Vendor Change Control for Routing, Activity-Code Consistency). They are written down before the week so that the committee is filling sections rather than inventing them; walking them in the room would displace the blocks that take decisions.

Running a shorter room

Where the week compresses to a day and a half, the entries below do not change and their order does not change; the working sessions on the packs come out and run in office hours over the following two weeks. The compression, the four-plus-four split and the floor below which the room stops working are stated on Planning Week for a Workforce Function.

How this connects

Maturity Model Position

This page carries no maturity position of its own; the week's position on the WFM Labs Maturity Model™ is stated once on Planning Week for a Workforce Function, which is also where the wiki's four uses of the word "level" are distinguished.

Use this with Claude

No pack fills this page, because it produces no artifact. Each block's opening paragraph above names the pack its working session deploys. Fourteen packs serve those sessions and a fifteenth writes the overview circulated before Day 1 (Wiki:Packs/Planning Week Overview, CP-OPS-006); all fifteen are listed with their outputs on Planning Week for a Workforce Function, and the deployment pattern is described on Wiki:Packs.

See Also

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