Process Shells for a Workforce Standard
Part of the Planning Week chain · previous: Resizing a Workforce Function After an Acquisition · next: Process Standardization Lifecycle
Process Shells for a Workforce Standard is the method by which a workforce function catalogs every process it runs before it has documented any of them: each process gets an L0 card whose identity fields are filled, whose method block is empty, and which carries a skeleton until date, so that the function's standard can be issued with an owner and a date against every section on the day the room closes. It matters because a function formed from several heritages typically knows its processes as practice rather than as an inventory, and a standard that waits for the inventory is not issued for a year. A shell is an L0 card whose identity fields are filled, whose method block is empty, and which carries a skeleton-until date; the Process Standardization Lifecycle fills it. The page produces the process L0 card as a shell (T4) and the function catalog row it belongs to, and is worked in a session with Wiki:Packs/Process Decomposition (CP-OPS-001 v1.1, the process-shell.md block).
Why a shell with a date beats a blank
A blank section in a standard is silent: nothing reports it, nobody owns it, and it stays blank. A shell is a dated commitment. It gives the standard's function catalog a row on the day the standard is issued, gives the standards committee a queue to rank, and turns "not yet documented" into a fact with an expiry that the compliance step of the lifecycle can report. Standards that ship as skeletons with unowned placeholders commonly stay skeletons; the observation comes from practice and is Asserted, and the remedy is to give each placeholder an owner and a date. Project practice knows the pattern as progressive elaboration: near work planned in detail, far work at the detail the information allows, and the plan saying which is which.[1]
L0–L3 on this page means the documentation levels of Process Decomposition (L0–L3), which places them in the same family as the documentation ladder of the Capacity Planning Cycle with Level 0 added as the identity layer, and states that they are unrelated to the maturity levels of Level 1 Process Templates.
The function catalog
The catalog is §2 of a function's standard (Anatomy of a ROC Standard carries the document pattern; this page carries the row). One row per function, each classed strategic, real-time or supporting (a function may be strategic and real-time, written "both"), because that split survives any org chart. Each row names an owner as a seat, never a person, and a skeleton-until date. Vendor governance is not a row: every function carries a node attribute (which nodes it runs on) and a vendor paragraph (what differs at a partner node), so that supplied work is the same function applied to another node rather than a separate function.
| Column | Filled by | Rule |
|---|---|---|
| Section number and function name | the standard, at issue | one section per function; the numbering is the standard's |
| Class | the standard, at issue | strategic · real-time · both · supporting |
| Owner | the standard, at issue | a seat; the method owner, not the decision owner |
| Skeleton until | the standard, at issue | the date the section stops being a shell; missing it is a compliance fact |
| Processes (the shells) | the inventory, through the lifecycle | one L0 card per process, cataloged here even as a shell |
The catalog is not the inventory. The inventory, the list of processes each function actually runs, is discovered at the standards committee's first sitting and during authoring, and a function that has not yet been inventoried has a catalog row and no cards beneath it, marked as such.
An L0 card and a section of the standard are different objects, and the chain keeps their keys apart: a card is keyed P-nnn and is the identity sheet of a process, while a section is keyed by its section number on Anatomy of a ROC Standard, and one card may stand behind two sections — P-001, the short-term forecast build and lock, is one card, and the standard nests the lock as its own section beneath the forecast section.
The L0 card as a shell
The L0 cover sheet of Process Decomposition (L0–L3) lists its fields flat — name, organization, ID and type, category, owner, document home, publication and expiry, abstract, authors, peer reviewers, approvers, keywords and revision history. This page groups them into six blocks, identity · custody · abstract · people · findability · change control, so that a shell can mark what is empty block by block; the ten-block section adds the method block (the L1 flow, the L2 table, the L3 register) and the controls block (the gate response). A shell fills what the standard can fill on the day it is issued and marks the rest.
| Block | Field | Filled by the standard (Day 4) | Filled by the inventory (the lifecycle) | If empty, marked |
|---|---|---|---|---|
| Identity | ID · process name · function · class | yes | — | — |
| Custody | owner (seat) · document home (the standard's section) · publication and expiry (the standard's) | yes | — | — |
| Custody | lifecycle status | Shell | updated at each lifecycle step | — |
| Custody | wave rank · skeleton until | yes | re-ranked by the committee | — |
| Abstract | purpose and scope, two or three sentences, no steps | — | step 1.2 | SHELL — owner <seat> · fill by <date> |
| People | authors · peer reviewers · approvers | approvers as seats | authors and reviewers at 1.2 and 1.3 | SHELL — owner <seat> · fill by <date> |
| Findability | references · keywords | — | step 1.2 | SHELL — owner <seat> · fill by <date> |
| Method | L1 flow · L2 step table · L3 register | — | steps 1.2 to 2.1 | SHELL — owner <seat> · fill by <date> |
| Controls | gate response · conditions · catch rate | — | steps 2.1 and 3.1 | SHELL — owner <seat> · fill by <date> |
| Change control | revision history | v0.1 · shell created · date | every step | — |
| any | a value the standard leaves to the node or estate (a threshold, a system name) | — | the node, at deployment | SET LOCALLY — <seat> |
| the card itself | a process whose existence is asserted but not yet confirmed by the catalog check | — | the committee's first sitting | NOT INVENTORIED — <seat> · by <date> |
The rule of the shell is that a placeholder without an owner and a date is not a placeholder; it is a blank. Every empty block of a shell carries exactly one of three marks, and that is the one rule for an empty block of a card; this page is where it is said once. Process Decomposition (L0–L3) requires every L0 field to be filled or explicitly marked TBD, because an empty field cannot be told from a forgotten one. A shell refines that mark rather than replacing it: TBD says a field is knowingly empty, and the three marks say who will fill it, by when, and whether anyone should. TBD stays with the unknown cell of the L2 step table and with any card kept outside a standard; inside a shell the marks are used and TBD is not. SHELL — owner <seat> · fill by <date> means the lifecycle will fill it, and names the seat and the skeleton-until date. SET LOCALLY — <seat> means the standard does not fill it and a node does, as the incident severity values on Incident Management for Contact Centers are set locally under a fixed row structure. NOT INVENTORIED — <seat> · by <date> means the card exists because a heritage said the process exists, and the committee's first sitting will confirm it or strike it. A card can carry NOT INVENTORIED for one sitting only; after that it is a shell or it is gone.
The abstract is deliberately not filled by the standard. It states purpose and scope in two or three sentences, and it is where the process owner and the committee discover that two heritages meant different things by one name. Writing it is the first act of authoring, not of cataloging; a shell with a standard-written abstract has had its scope settled by someone who does not own it. The same applies to the method block: the standard names its home and its owner and draws nothing. The discipline is the checklist's: a form that makes the missing item visible is more reliable than a memory that it is missing.[2]
The first wave and its one constraint
The catalog yields more cards than a committee can author in a quarter, so the shells carry a wave rank. The rank is the committee's, set at its first sitting on an importance-by-volume screen with the dependencies that pull items forward: the processes a migrating book needs shared definitions for, the processes the first agent team will run (an agent needs an L2 for every step it takes), and the supplied processes that must be specified before highly specified can be tested on them. The room does not rank; it fixes one constraint, in one sentence: the processes the first agent team will run stay in the first wave. The constraint is the room's because the agent program's first date depends on it, and it is one sentence because a room of directors re-ranking twenty cards produces a rank nobody owns.
The first wave in the worked example is five cards [E], listed below. The number is the example's, not a rule; the rule is that the first wave is small enough to pass the acceptance gate inside the first-quarter front-load, with the skeleton-until dates of everything else set to quarter ends.
The committee's first sitting
The standards committee (Process Standardization Lifecycle charters it) sits for the first time within two weeks of the planning week, before the validation circuit closes, and does five things in order: confirms or strikes every NOT INVENTORIED card; adds the cards the directors' heritages know and the catalog missed; assigns the wave rank under the room's constraint; opens the queue; and sets its own cadence. The sitting produces the first version of the inventory, the difference between the standard issued on Day 4 (a catalog with shells) and the one the validation circuit checks (a catalog with an inventory beneath it); a row still incomplete after the sitting says so with a date.
Worked example
As the example carries it [E]: the function of the chain's worked example issued its standard v0.1 on Day 4 (Thu 23 Apr 2026, D-11) with eleven catalog rows, every one a shell, each with an owner as a seat and a skeleton-until date; the standard's expiry is Fri 30 Apr 2027. The room's constraint on Day 2 afternoon (D-06) fixed the first wave: the processes the first agent team will run stay in it. The committee first sat on Wed 29 Apr 2026, struck one NOT INVENTORIED card (a heritage's "weekly reforecast", found to be a step of P-001 rather than a process), added two cards from a second heritage, ranked the queue, and set a fortnightly cadence through Tue 30 Jun 2026 [E].
| ID | Process | Function (class) | Wave | Skeleton until | Lifecycle status on Fri 8 May 2026 |
|---|---|---|---|---|---|
| P-001 | Short-term forecast build and lock | forecasting (both) | 1 | Tue 30 Jun 2026 | 1.2 authoring |
| P-002 | Daily actuals reconciliation and forecast scoring | forecasting (both) | 2 | Tue 30 Jun 2026 | 1.1 approved |
| P-003 | The intake door and its routing | intake and the register (supporting) | 3 | Tue 30 Jun 2026 | 1.1 approved |
| P-004 | The register row and the 48-hour readout | intake and the register (supporting) | 4 | Tue 30 Jun 2026 | 1.1 approved |
| P-005 | The odd-case loop: exception → specification → table | improvement (supporting) | 5 | Tue 30 Jun 2026 | 1.1 approved |
| P-006 | The monthly capacity cycle, stage by stage | capacity planning (strategic) | 6 | Wed 30 Sep 2026 | Shell |
| P-008 | Incident lifecycle | incident management (real-time) | 8 | Thu 31 Dec 2026 | Shell (a legacy L0–L2 exists; conversion, not authoring) |
| P-013 | Real-time reallocation across nodes | real-time and placement (both) | 13 | Wed 31 Mar 2027 | Shell |
The five first-wave cards share a skeleton-until date because the front-load runs to Tue 30 Jun 2026; P-008's date is later than its wave rank suggests because a legacy package exists and the work is conversion. The incident card is the one the chain walks as its real-time pattern on Day 2 afternoon (Incident Management for Contact Centers); the forecast card is its strategic pattern (Three-Step Forecast Build).
The artifact this page produces
The process L0 card as a shell (T4), one row per process, and the catalog row above it. One filled example row:
| ID | Process | Function | Class | Owner (seat) | Document home | Abstract | Authors · reviewers · approvers | Publication · expiry | Lifecycle status | Wave rank | Skeleton until |
|---|---|---|---|---|---|---|---|---|---|---|---|
| P-008 | Incident lifecycle | incident management | real-time | the real-time operations seat | the standard, incident section | SHELL — owner the real-time operations seat · fill by Thu 31 Dec 2026 | SHELL · SHELL · the function's council | Thu 23 Apr 2026 · Fri 30 Apr 2027 | Shell | 8 | Thu 31 Dec 2026 |
Produced in a working session with Wiki:Packs/Process Decomposition (CP-OPS-001 v1.1; the process-shell.md block carries the card, the marks and the catalog row); the filled set is part of blueprint v0.1.
What would change this
The page's central claim is that a dated shell is more likely to be completed than a blank, and that the skeleton-until date is what makes the difference. The observation that would overturn it is a catalog whose shells expire at the same rate as blanks did, with the compliance step reporting the misses and nothing changing; that would mean the date reports the problem without moving it, and the remedy would have to be in the committee's authority or in the authoring capacity, not in the card. A second observation would narrow the page rather than overturn it: if the standard-filled abstract turned out to settle scope faster than the owner-written one without the mis-scoping this page predicts, the abstract would move to the standard's side of the table.
How this connects
- Previous in the chain: Resizing a Workforce Function After an Acquisition — the catalog is the first of its three levers made concrete: the method written down before anything is consolidated
- Next in the chain: Process Standardization Lifecycle — the seven steps that fill a shell, and the committee that ranks the queue
- Defers to: Process Decomposition (L0–L3) (the L0 cover sheet's fields and the build order) · Anatomy of a ROC Standard (the catalog as §2 of the standard and the ten-block section) · WFM Processes (the three-pillar architecture — forecasting, scheduling, real-time operations — that the catalog's functions sit inside) · Capacity Planning Cycle (its own L1–L3 process levels, a different scale) · Level 1 Process Templates (starter procedures at maturity Level 1, not shells) · Instantiating the GRPI-T Framework (the Processes pillar this page fills) · The Agent Team Ladder: Alpha to Production (why the agent team's processes fix the first wave)
Maturity Model Position
Cataloging is the entry move of Level 2, the level whose apparatus is dedicated planning roles and standardized, documented processes: a function that can list its processes with owners has the foundation of that apparatus, whether or not any process is yet written to L2. The skeleton-until date and the compliance report are Level 3 habits applied early, because the automation layer needs the inventory to be complete before it needs any one process to be specified. The classification framework tradition that catalogs processes without prescribing how each runs is the nearest published analogue of the catalog, and the distinction it draws, taxonomy against documentation, is the one this page draws between the catalog and the inventory.[3][4] Four scales on this wiki use the word level; the launch page states which is which.
See Also
- Planning Week for a Workforce Function
- Process Standardization Lifecycle
- Anatomy of a ROC Standard
- Process Decomposition (L0–L3)
- Incident Management for Contact Centers
- WFM Processes
- Standardize Before You Automate
References
- ↑ Project Management Institute (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide) (7th ed.). Newtown Square, PA: PMI. Progressive elaboration and rolling-wave planning.
- ↑ Gawande, A. (2009). The Checklist Manifesto: How to Get Things Right. New York: Metropolitan Books.
- ↑ APQC. Process Classification Framework, v7.3.1. Houston, TX: APQC.
- ↑ International Organization for Standardization (2021). ISO 10013:2021 — Quality management systems — Guidance for documented information. Geneva: ISO.
