Wiki:Packs/Charter and Program Launch

From WFM Labs
Pack
ID CP-WFM-012
Domain WFM
Version 1.0
Blocks 1 instruction + 4 reference
Source Function and Program Charters · The Function Service Pack · Program and Portfolio Management · The Case for Operating Model Planning
Planning-week block Day 1 afternoon (function charter) · Day 4 morning (program charters)

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 1 afternoon working session of a planning week, which drafts the function charter, and the Day 4 morning session, which signs it and accepts the program charters under decision D-14; it also produces the launch note the sponsor sends the day after.

When to use it

Create a project from this pack when a leadership room is chartering a workforce function or its programs, when a function owner is filling the charter sections (4, 11 and 14) of The Function Service Pack, or when a director is adding a program to the ledger after the week. Do not use it to find owners (owners are pre-assigned seats the room accepts), to size a program's team, or to write the agent program's charter, which has a pack of its own in the same template.

How to deploy

  1. Create a project in Claude named for the work, not the method (for example "Function charter, Day 1 afternoon").
  2. Paste Block 1 into the project's custom instructions.
  3. Save each remaining block as the filename in its heading and upload as project knowledge.
  4. Start a conversation with the charter you are filling.

Block 1 — Project instructions

# Charter and Program Launch

## Context
This project supports two blocks of a planning week for a workforce function: Day 1 afternoon, where the function charter is drafted, and Day 4 morning, where it is signed and the program charters are accepted under decision D-14. It also produces the launch note the sponsor sends the day after the week. One template serves both charters; a program charter is a slice of the function charter. The project drafts, checks the cascade and the scope-out, and formats; owners are pre-assigned seats and the room accepts rather than searches.

## Routing
| When the task is… | Open |
|---|---|
| Drafting, amending or checking the function charter: mission, vision, mandate, scope, decision-rights summary, measures, signatories, expiry | `function-charter.md` |
| Drafting, amending or checking a program charter: objective, scope, owner, dependencies, the decision needed, measures, risks, lanes and arc | `program-charter.md` |
| Placing a charter on the cascade (pillar → objective → target → roadmap → benefit); writing or testing a scope-out line | `cascade-and-scope-out.md` |
| Writing a first-ninety-days list; drafting the launch note; checking items against the front-load quarter | `first-90-days.md` |

## Disciplines
- One template, two uses; a field a use does not need is a dash, never deleted.
- Owners are seats (a post on the org chart with its scope and its sunset condition), never names; the launch note names no person against a seat whose holder has not been told.
- Scope-out is mandatory and explicit; a charter without a scope-out line is returned.
- Every charter cites its cascade: the intent number, the outcome cell's words, the lane ID and arc.
- Measures name an instrument and are never a headcount; a program judged on headcount is judged on the wrong thing.
- First ninety days: three items, each observable, inside the front-load quarter; "charter the program" is not an item.
- Mission and vision are inherited from the ratified strategy on a page and are not rewritten here.
- Expiry at most a year out on the function charter; a charter is reissued, never inherited.
- Every number carries [M][C][E][A]; ranges, not points.

## Output
One row per charter in the template shape, plus the launch note as one page. Always state which fields were amended in the room and which were accepted as pre-assigned. Refuse to produce: a headcount number or a seat count; a person's name against a seat; a placement decision; an owner the leader has not pre-assigned (propose "owner to be pre-assigned" instead); a charter with an empty scope-out.

Source: Wiki:Packs/Charter and Program Launch (CP-WFM-012) v1.0

Block 2 — function-charter.md

<!-- Derived from [[Function and Program Charters]] and [[Strategy on a Page]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The function charter (CH)

What the workforce function is, what it owns, what it does not, who decides, how it is measured, who signed, and when it expires. Drafted Day 1 afternoon, signed Day 4 morning. ID `CH-001`.

## Fields
| Field | Holds | Source |
|---|---|---|
| Mission | what the function is, one sentence naming what it owns (the methodology) and what it does not (the decision) | inherited from the strategy on a page |
| Vision | the chosen phrase | inherited |
| Mandate | the authority the sponsor grants, and its limit | drafted in the room |
| Scope: in | what it owns, as a list | drafted |
| Scope: out | what it does not own, explicitly | drafted; mandatory |
| Owner | the leader's seat and the sponsor's | pre-assigned |
| Decision-rights summary | the first rule (the function owns the method; the node owner owns the decision) and the forums | the RACI page carries the matrix; the charter carries the rule and the forum names |
| Measures | how the function is judged; the instrument named; never a headcount | drafted |
| Signatories | the sponsor and the leader, by seat, with the date | Day 4 morning |
| Expiry | at most a year out | Day 4 morning |

## Generic scope lines for a function that places work
In scope: forecast and schedule; real-time automation and incident management; work placement (the gate, the registers, the counterfactual record); the instrument and the comparison key; the methodology for every calculation from queueing arithmetic to simulation.
Wired, not owned: the finance, people, talent-acquisition, technology, continuity, commercial and training functions (named interfaces with an owner on each side).
Owned by operations: every placement decision; daily partner performance for their node.
Out of scope: the in-house nodes' operating models; the commercial pen on partner contracts (procurement, with the function's input); any statement about a partner's performance outside the instrument.

## Generic mandate
"Owns the methodology for forecasting, scheduling, real-time steering and work placement across every node; recommends and computes; does not decide any placement." The limit is the sentence after the semicolon.

## Measures that fit a function charter
Definitions adopted (of the six core: occupancy, handle time, shrinkage, contact, attrition, ramp); processes documented to the standard (count at L2 — the process standard's step table, not a maturity level); instrument coverage by node; declines recorded with their price (all of them); gate output pages with a sealed counterfactual (all). None is a headcount.

## Signing and expiry
The sponsor and the leader sign on Day 4 morning, the same block in which the Standard v0.1 is issued; the two expiries are set to the same date so the function reissues both together. Reissue is a reread and a re-signature; an inherited charter is the condition the week exists to end.

## Checks before signature
1. Mission names the method owned and the decision not owned.
2. Scope-out has at least three lines and names the neighbor who owns each.
3. Every measure names an instrument; none is a headcount.
4. Owner fields are seats.
5. Expiry is a date within a year.

## Output shape
One row: `CH-001` · name · mission · vision · mandate · scope in · scope out · owner (seats) · decision-rights summary · measures · signatories · expiry.

## Example, labeled as one
A function signed `CH-001` on a Thursday with expiry twelve months and one week later, matching its Standard's expiry; scope-out named the in-house nodes' operating models, the commercial pen, and every placement decision. Illustration of register, not required wording.

Block 3 — program-charter.md

<!-- Derived from [[Function and Program Charters]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The program charter (T7)

One per delivery vehicle. Same template as the function charter with the program fields filled and the function-only fields dashed. Accepted, not searched for, on Day 4 morning (decision D-14). IDs `PG-001` onward; never reused.

## Fields
| Field | Holds | Rule |
|---|---|---|
| Objective | what the program delivers, one sentence | an event, not an aspiration |
| Scope: in | what it builds | list |
| Scope: out | what the neighboring program owns instead | mandatory; names the neighbor |
| Owner | a seat | pre-assigned by the leader; accepted in the room |
| First 90 days | three items, observable, inside the front-load quarter | see `first-90-days.md` |
| Dependencies | what must exist first, by ID (a decision, another program, a register) | IDs, not prose |
| Decision needed | the one decision the room must take for this program, by D-number | at most one; the rule the charter carries but does not vote is stated separately |
| Measures | how it is judged; instrument named; never a headcount | count of adopted definitions, catch rate, days to detection, pages through a gate |
| Risks | what could stop it, in the estate's terms | two or three |
| Lanes · arc | which roadmap lanes it delivers into; Arc 1, Arc 2 or both | from the reconciliation table on the roadmap |

## Programs a function of this kind typically charters
Seven is a working number; the set is the chain's construction and a director may add an eighth.
| ID | Program | Typical scope-out |
|---|---|---|
| PG-001 | the definitions register | the quality rubric (the quality function's); forensic reconstruction of history |
| PG-002 | the capability ontology, on paper then as a platform | platform selection before the ontology has run by hand for two quarters; demand-side intent normalization |
| PG-003 | the long-term capacity engine extended into simulation | short-term forecasting; the capability platform |
| PG-004 | the migration (the estate's live book or platform migration) as the forcing function | the platform decision itself; any statement about a partner's performance |
| PG-005 | a short-term WFM engine instance built to the Standard | platform selection; the migration's own schedule |
| PG-006 | the program office | owning any lane's content; deciding any placement |
| PG-007 | the agent program | the definitions the agents read (the definitions register's); the platform instance's configuration; multi-book optimization; replacing the planner |

## Rules a charter carries but does not vote
Some rules ride with a charter and are stated as such, not as decisions: the ontology precedes any platform conversation (PG-002); the two arms of long-range planning are two things and simulation follows the plan of record (PG-003); the function is in the resource call for every migration phase and the migration schedule is a change-control item (PG-004); nothing is configured that is not in the Standard (PG-005); the planner gate stays on and success is measured on catch rate and days to detection, not headcount (PG-007). The agent ladder governs the function's own planning work and runs inside Arc 1; the automated band of the placement landscape governs bodies of work the function plans for and is an Arc 2 transition. They are different objects and a charter does not cross them.

## Acceptance in the room
Each owner reads their charter, amends what they cannot sign, and accepts. The block is one decision, D-14: a seat against each program and each lane, plus the program office and who runs it. If the room chose a different organization option than the one the charters assumed, the owners are re-cut in the validation circuit, not in the room.

## Output shape
One row per program: ID · program · objective · scope in · scope out · owner (seat) · first 90 days · dependencies · decision needed · measures · risks · lanes · arc · status (accepted / amended / re-cut in circuit).

## Example, labeled as one
`PG-001` the definitions register: owner co-owned between the definitions owner and the analytics function; decision needed D-12; measures "definitions adopted (of six); reports citing the register; contracts carrying the comparability clause"; lanes L-001 · Arc 1. Illustration only.

Block 4 — cascade-and-scope-out.md

<!-- Derived from [[Function and Program Charters]], [[Strategy on a Page]] and [[The Two-Arc Roadmap]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# The cascade, and writing scope-out

## The cascade
A charter opens by placing itself on the cascade written once on the strategy on a page. The charter cites; it does not restate.

| Step | Lives on | The charter cites |
|---|---|---|
| Pillar | the strategic intent | the intent's number (1–5) |
| Objective | the dated outcome under that intent | the outcome cell's words, verbatim |
| Target | the star on the roadmap lane | the lane ID and the arc |
| Roadmap | the lane's bars | the quarter the program starts |
| Benefit | the value marker on the companion timeline | plain (one-time) or tailed (accruing); no figure without its source |

Two tests, applied before a charter is written:
1. A program that cannot be placed on the cascade is a project without a strategy. Return it.
2. After the charters are accepted, an outcome cell with no program beneath it is a target no one is building toward. Raise it at D-14.

## Writing scope-out
Scope-out is explicit and mandatory because the boundary is read at the moment someone proposes crossing it; "should we also" becomes "that is the other program's," which is a sentence rather than a meeting.

For the function charter, the scope-out lines are the ones the function is most often asked to cross:
- owns the methodology; does not own any placement decision
- owns the instrument; does not own the verdict
- is wired to the finance, people, technology, commercial and continuity functions; does not own their decisions

For a program charter, scope-out names the neighboring program that owns what this one is tempted to build. Template: "<thing> is <neighbor program>'s; this program <receives / cites / reads> it."

## Scope-out test
| Check | Pass |
|---|---|
| At least three lines | yes |
| Each names the owner of the excluded thing | yes |
| No line is a restatement of scope-in with "not" | yes |
| The most likely crossing in the first quarter is on the list | yes |

## Owners as seats
A seat is a post on the org chart with its scope and its sunset condition. Owners are seats because the charter outlives its holders and because an owner named as a person becomes a program that pauses when the person moves. The leader pre-assigns seats before the week; the room accepts (D-14). Seats assume the organization option the leader recommends; if the room chooses another, owners are re-cut in the validation circuit.

## Output shape
For each charter: the five cascade citations as a row; the scope-out list with its owner per line; the scope-out test as four ticks.

## Example, labeled as one
A platform-instance program's scope-out gained, in the room, "the migration's own schedule (the migration program sets it; this instance receives it)." Illustration of the template sentence.

Block 5 — first-90-days.md

<!-- Derived from [[Function and Program Charters]] and [[The Two-Arc Roadmap]]; figures marked [estimated] are judgment, not measurement; numbers carry [M][C][E][A]. -->
# First ninety days, and the launch note

## The list
Three items per program charter. Each is observable (a person could say on a date whether it happened), inside the front-load quarter (the quarter after the week), and none is a study or "charter the program."

| Good | Not an item |
|---|---|
| the register's first version published with all six definitions and joint signatories | "agree the definitions" |
| the book chosen; its ledgers populated from the platform's exports; the daily loop running with the planner gate on | "assess readiness" |
| the configuration standard written from the Standard's scheduling section; the activity-code dictionary v1 | "review the platform" |
| the first gate run on a live question; the constraint register opened | "design the gate" |

## Checks against the front-load
The roadmap's front-load list has six foundations every later star depends on: the definitions register; the standards committee; the intake door and the register; the ontology on paper; the agent team on one book; the platform-instance program chartered with its first book chosen. A program's first-ninety-days items should either be one of the six or depend on one by ID. An item that depends on a foundation not yet dated is written "after <foundation>, by <date>."

## Dependencies and dates
- Cite dependencies by ID: a decision (D-nn), a program (PG-nnn), a register, a gate.
- Dates are inside the quarter and are proposals until the validation circuit closes; say so.
- Two external clocks are read before dating: the first partner renewal; the commercial function's pricing milestone. Both are actions for the program office, not decisions for the room.

## The launch note
One page, sent by the sponsor the day after the week, written in the room on Day 4 afternoon from the accepted charters and sent unchanged.

Contents, in order:
1. The function charter as signed: mission, mandate, scope-out, signatories, expiry.
2. The program owners, by seat.
3. The first-ninety-days items with their dates, grouped by program.
4. The validation circuit: who corrects the room's answers, by when.
5. One sentence: nothing is settled until the circuit has run.

Rules: no person named against a seat whose holder has not been told; no number without its grade; no placement decision announced; the estate hears the room's words before anyone else's.

## Output shape
Per program: three items, each with an observable, a date, a dependency ID. Then the launch note as one page in the order above.

## Example, labeled as one
A launch note went out on the Friday after a Monday-to-Thursday week, with the validation circuit closing two weeks later on a Friday. Illustration of cadence, not a rule.

Usage notes

  • Sizing. Block 1 is 439 words and loads with every message. Blocks 2 to 5 total about 2,400 words and are retrieved only when the routing table sends the model to them.
  • Drift. The reference blocks are derived from the chain pages and the two existing pages named in the infobox; when any changes materially, regenerate the blocks and increment the version.
  • Scope. Method only. No estate data; the program set in Block 3 is a generic working set, not an estate's.
  • Owners. The pack never proposes a person; where a seat is not yet pre-assigned it writes "owner to be pre-assigned."

Change history

Version Date Change
1.0 2026-09-17 First release: instruction block plus four reference blocks

See also

Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Wiki:Packs/Charter_and_Program_Launch&oldid=4710"