Transformation Timeline for a Workforce Function

From WFM Labs

An outcome of Day 4 afternoon of a planning week · the roadmap's dated companion: The Two-Arc Roadmap A transformation timeline for a workforce function is the dated delivery view of the function's change program: a small number of named workstreams, each drawn as a bar across quarterly columns, each with a start, a span, a dependency and a stated test for being finished. It matters because a function that has agreed what it is building has still not agreed when, and the argument a room avoids by leaving the timeline undrawn is the one that surfaces two quarters later as a track waiting on an input nobody scheduled. The page produces the transformation timeline (template TL), and is worked in a session with Wiki:Packs/Transformation Timeline (CP-WFM-017). It is an outcome of the Day 4 afternoon block, taken with the roadmap and the landscape, and it is the only artifact of the week that a room is expected to redraw between planning weeks.

Platforms are named by category throughout, as everywhere on this chain: the long-term capacity engine, the short-term WFM engine (forecasting and scheduling), intraday automation, the Python analytics platform (the reporting platform's notebook component) and the reporting platform. No product is named, here or in the pack, because a timeline that names products has to be redrawn when a contract cycle turns and not when the work changes.

This page and the roadmap are different objects

The Two-Arc Roadmap and this page carry different things, and a room needs both. The roadmap carries seven lanes across two arcs — in the chain's worked example, eight quarters running Q2 2026 through Q1 2028 — where a lane is a capability the estate is building and its unit of completion is a star written as an observable sentence. This page carries twelve tracks across five quarters, where a track is a body of delivery with an owner, a start, a span and a definition of done, and its unit is a quarter cell. A lane is what the function is becoming; a track is what somebody is doing between now and a date.

The five quarters drawn here are the roadmap's first five: the whole of Arc 1, which runs from the front-load quarter to its star quarter, and then Arc 2's opening quarter. The tracks that run off this chart's right edge do not leave the program — they land inside Arc 2. Reading the two pages together, the chart stops one quarter into the second arc, which is why several of its tracks are still in flight at the right-hand edge. Neither page restates the other. The dependency order, the arcs, the value markers and the first-quarter front-load list live on the roadmap and are not re-derived here; the track definitions, the spans, the off-chart markers and the sensitivities live here and are not repeated there. Where a track's content belongs to another page — and most of the technology tracks do — this page dates it and links, and the content stays where it is: Technology Migration Plan for a Workforce Function for the component map and the build order, Functional Organization Design for a Resource Optimization Center for the organization, The Definitions Register for the definitions, Process Standardization Lifecycle and Anatomy of a ROC Standard for the process work.

The chart

Quarters are columns; tracks are rows. The quarter labels are the chain's worked example's and are never an estate's; what is doctrine is the shape of the chart, not the year in the header. A cell is one of four marks.

  • ◆ start — the quarter the track begins. Where a start genuinely straddles two quarters, the mark spans both cells rather than being rounded into one.
  • run — the track is in flight for the whole quarter.
  • ■ complete — the quarter in which the track's stated test for done is met.
  • ▸ — the track continues past the chart's right edge, or begins past it. The chart does not pretend these fit.
  • — — the track is not running.
The transformation timeline (TL). Five quarters on the chart; the last column is off it.
# Track Q2 2026 Q3 2026 Q4 2026 Q1 2027 Q2 2027 ▸ Beyond the chart
1 Organization design ◆ start · ■ complete — — — — —
2 Data definitions ◆ start · ■ complete — — — — —
3 Data standardization ◆ start run run run run ▸ runs as the migrations run; no completion quarter on this chart
4 The operating standard (the shell) ◆ start · ■ shell issued — — — — —
5 Process standardization ◆ start run run run ■ complete —
6 Intraday automation expansion — ◆ start run run ■ complete —
7 The capability record ◆ start, straddling the Q2 2026 – Q3 2026 boundary run ■ complete — —
8 Long-term capacity engine expansion ◆ start run run ■ complete — —
9 Simulation on the long-term capacity engine — — — — ◆ start ▸ completes one quarter past the chart, paired with track 12b
10 Short-term WFM engine migration ◆ start run run run run ▸ the first clean book is live in the last column; the remaining books, and the migrating book last, run past the chart
11 WFM AI agents ◆ start run run run run ▸ runs past the right edge; no completion quarter on this chart
12a Reporting and analytics automation on the Python analytics platform — launch ◆ start ■ complete — — — —
12b Reporting and analytics automation — expansion — — ◆ start run run ▸ completes one quarter past the chart, paired with track 9

Track 12 is two rows because it is two objects. The launch is a dated event with a gate; the expansion is a standing track that follows it and is sized separately. Drawing them as one bar would hide the fact that the expansion can be cut without cutting the launch, which is the decision a room most often has to take about that track.

Two rows on this chart are drawn as one step, and the pairing is deliberate. Track 9 and track 12b start in the same quarter and finish in the same quarter off the chart, because Technology Migration Plan for a Workforce Function places simulation and the Python analytics platform in a single build step — "simulation and notebooks together: the simulation engine and the Python analytics platform, which share the analysts" — and a chart that dated them apart would commit the same analysts twice. This page does not sequence them differently; it draws the step's two halves as two rows so that each keeps its own done test, and moves them together or not at all.

The twelve tracks

Each row states what the track delivers, what it stands on, and the observable test for calling it finished. Owners are seats, never names, in the convention Role Cards for a Workforce Function sets.

# Track What it delivers What it depends on Done means
1 Organization design One structure with its sunset conditions printed, decision rights by horizon, and a named owner against every other track on this chart Nothing on this chart; the week's own decisions D-03, D-04 and D-05 Every track below has a seat against it, and the seat exists on the chart
2 Data definitions The core definitions with their instruments, resolutions, pairings and signatories — the register's first version (The Definitions Register) Nothing on this chart A signed register exists and the first report is read against it rather than against a spreadsheet
3 Data standardization The same definitions in force in every system that holds them: field by field, feed by feed, as each migration touches it Track 2. It cannot begin against unsigned definitions, and it runs as the migrations take place — which is why it spans every column and does not end on the chart Every feed named in the register reads the registered definition, with lineage recorded. That is not reachable while track 10 is still moving books, so the track has no completion cell here
4 The operating standard The Standard's shell: front matter, expiry, and an owner and a date against every section. The shell is the deliverable, not a finished standard (Anatomy of a ROC Standard) Tracks 1 and 2 — a section with no owner is not a shell, and a section whose method cites an unregistered term cannot be written Every section has an owner, a date and an expiry, and none is unassigned
5 Process standardization The sections filled, one wave at a time, through the standardization lifecycle and its acceptance gate (Process Standardization Lifecycle) Track 4's shell. Filling sections before the shell exists produces documents with no home Every first-wave section is filled and accepted; later waves are queued with dates
6 Intraday automation expansion Intraday automation extended from alerting to acting, across more queues and more actions (Expanding Intraday Automation) Tracks 2 and 5. An automated action executes a rule; an unregistered term or an unwritten process gives it nothing to execute — which is why it starts a quarter late The agreed action set runs on the agreed queues with its rule log and action record kept
7 The capability record Who can do what, held once and read by everything that places work: eligibility, proficiency and entitlement as an attribute dictionary, written on paper and then held as a record. On this wiki the machinery that consumes it is the placement engine (Placement Engine Architecture); this track delivers what it reads Track 2, directly and hard. A capability record built on unregistered attributes is a skills matrix with a better name Placement questions are answered from the record rather than from a person's knowledge, and the record's gaps are visible
8 Long-term capacity engine expansion The plan of record on one core — budget, forecast and actuals in one structure, iterating with finance (Technology Migration Plan for a Workforce Function) Tracks 2 and 3, continuously: it absorbs each definition as the standardization track lands it, which is why it starts with them. It closes inside the build order's second step, where the plan of record arrives on one core The reconciliation with finance happens in the engine and not in a spreadsheet
9 Simulation on the long-term capacity engine What-if and sensitivity on the plan of record: a model that calculates and stores nothing Track 8 complete — there is nothing to simulate against until the plan of record is on one core — and track 12b beside it, because the build order ships the two as one step A placement or sizing question is answered as a distribution with its sensitivity, and the answer is reviewable. The test is met one quarter past this chart's right edge
10 Short-term WFM engine migration The books moved between two instances of the short-term WFM engine, onto a single configuration built to the function's standard (Migrating a Book of Business, Systems Administration for WFM Platforms) Tracks 2 and 4. The migration is the forcing function for definitions, not a substitute for them (Platform Migration as a Definitional Forcing Function) Every book in scope is served from the target instance, on the standard configuration, with the transitional arrangement ended. The first clean book is live in the chart's last column; the test itself is met past the right edge
11 WFM AI agents Specialist agent teams under a coordinator with a human gate at every plan-changing transition, climbing the rungs book by book (AI Agent Program for a Resource Optimization Center, The Agent Team Ladder: Alpha to Production) Tracks 2 and 5 for what the agents read and execute; nothing for the first rungs There is no completion quarter on this chart. The track's tests are per rung and per book, on the ladder, and it runs past the right edge
12a Reporting and analytics automation — launch The Python analytics platform launched under governance (Launching an Analytics Notebook Platform) — governed metrics, lineage and a review route, not a folder of notebooks Tracks 2 and 3. It reads, so it needs something governed to read; it does not wait on track 8, because the build order places the notebooks against the register rather than against the plan of record The first governed notebook product is published on registered definitions with its lineage visible
12b Reporting and analytics automation — expansion The reporting estate moved onto the platform, report family by report family, with the manual assembly retired behind each one, and the platform standing as a standard component beside simulation Track 12a, and track 9 beside it: the two are one build step Each retired report has a named successor in production and the manual version is switched off, not merely deprecated

Why two tracks take one quarter

Organization design and data definitions are drawn as single-quarter tracks and every other track on the chart stands on one or both. That is the whole reason they are short: not because they are small, but because a track that everything waits on must be made to finish. A foundation given four quarters will take four, and every dependent track's start slides with it.

The arithmetic is worth stating plainly. Four of the twelve tracks cannot honestly start without the definitions, and one more cannot pass its first gate without them. Organization design is the same shape from the other side: it is the track that gives every other track a seat, and a track with no owner does not run at any speed. Neither is a small piece of work; both are being deliberately time-boxed, and the price of the time-box is that the first version of each is thin. A definitions register with six entries in force beats a register with sixty in draft, and an organization with printed sunset conditions beats one that is still being optimized. Making the first completions visible, unambiguous and early is the mechanism by which a change program buys the credibility to keep running;[1] putting the two foundations in the first quarter is that mechanism applied to a chart.

The corollary binds the room. If either single-quarter track is going to slip, it is discovered in the first quarter and not the third, and the discovery moves every dependent start by the same amount rather than being absorbed quietly inside the tracks that follow. That is the one slip on this chart that is never allowed to be absorbed.

Where the chart's risk actually sits

The risk on a timeline of parallel tracks is not inside the tracks. It is at the points where several tracks feed one deliverable, because that deliverable waits for the slowest of them and each feeding track's own slack is no protection at all — the slack has to sit at the join.[2] This chart has three such joins, and a room should know them by name.

  • The second column, where track 6 and track 7 both enter and track 12a meets its done test in the same quarter. All three are reading track 2's register and track 4's shell, and the foundations were closed only one quarter earlier.
  • The straddled start of track 7, which is drawn across the Q2 2026 – Q3 2026 boundary precisely because it is a join and rounding it into one quarter would hide that: the attribute dictionary is written on paper inside the front-load quarter, and the record it becomes opens in the next.
  • The last column, which is Arc 2's first quarter and the point at which almost everything unfinished leaves the chart: track 9 starts on the plan of record track 8 completed, track 12b is in flight beside it, tracks 5 and 6 meet their tests, and track 10's first clean book goes live.

The honest treatment is to hold protection at those three points rather than distributing it as comfort inside each of the twelve bars, and to re-read them at every quarterly review.

The tracks that run off the chart

Five rows extend past the chart's last column and are drawn as running off the right edge rather than compressed to fit. None of them is late; each is a track whose test is met in a quarter the chart does not draw.

Track 11 starts on the chart and does not finish on it: the agent program's clock is a ladder of rungs per team and per book, not a span, and the quarter in which it ends is not knowable from here. Track 10 runs the whole chart and past it, because the first clean book on the target instance goes live only in the final column and the migrating book moves last of all; track 3 follows it off the edge, since standardization runs as the migrations run and cannot end before them. Tracks 9 and 12b start on the chart and complete one quarter past it, together, as the build order's third step. Drawing any of them as completing inside the five columns would be a false statement about capacity, and a false completion date is worse than an acknowledged gap because it invites the room to plan against it. The standard response to a track that will not fit — compress it, or add people to it — is the response the schedule literature has been documenting the failure of for fifty years;[3] the chart's answer is to draw the overflow and let the room decide what it costs.

What would change this

A timeline with no stated sensitivities is a promise rather than a plan. These are the conditions under which a span moves, written before the fact so that a move is a recorded event rather than a quiet redraw.

What changes Which spans move The test
The definitions register is not signed in the first quarter Tracks 3, 6, 7 and 12a all move by the same amount; tracks 8 and 10 continue but stop absorbing A signed register at the end of the first quarter, or the whole chart shifts right — no dependent track is redrawn to start earlier
The operating standard's shell is issued with sections unowned Track 5 shortens to the owned sections only and the rest leave the chart Count the unowned sections; if any, track 5's span is a claim about work with no owner
A migration is added to track 10's scope Track 10 extends and track 3 extends with it, because standardization runs as the migrations take place. Neither has a completion cell here, so what moves is the quarter each is expected to reach Track 3's end date is never earlier than track 10's
The capability record cannot be built from the registered attributes Track 7 moves right, not down in scope If the record is reduced rather than delayed, what ships is a skills matrix and the track should be retired, not shortened
Intraday automation's action set is cut to alerting only Track 6 leaves the chart as an expansion track An expansion that does not add actions is not this track
An agent team's rung is not cleared Nothing on the chart moves Track 11 has no completion cell to move; only its ladder cards change
The Python analytics platform is dated ahead of simulation, or simulation ahead of it Both or neither: tracks 9 and 12b move as a unit They are one build step and they share the analysts. A plan that lands them in different quarters has committed the same people twice, and the earlier of the two is the one that will be unstaffed
The notebook platform's first governed products slip out of the second column Track 12b's start moves right with them, and the pairing with track 9 is re-read A governed product is one published on registered definitions with its lineage visible; a folder of notebooks is not the track
A thirteenth track is proposed Nothing moves until it is placed against tracks 1, 2 and 4 A track that depends on none of the three foundations is either not part of this program or has an unstated dependency

Two of these are worth naming as the ones a room will be tempted by. Splitting the analytics platform from simulation is attractive because the demand for notebooks is loud and simulation's audience is smaller; it does not accelerate anything, because the pair is one step drawn as two rows and the analysts are the same people. And shortening track 7 rather than moving it is attractive because the deadline is real; it produces an object with the right name and the wrong content, which is harder to correct than a late one.

The artifact this page produces

The transformation timeline (TL): one row per track, one column per quarter plus an off-chart column, with the four marks. Its companion is the track register — the track table above, filled for the estate, one row per track with an owner as a seat — and the sensitivity table, which is filled at the same sitting and reviewed quarterly. Produced in a working session with Wiki:Packs/Transformation Timeline (CP-WFM-017); the filled set is part of blueprint v0.1. The pack's job is adjustment rather than authoring: moving a start, extending a span, adding or retiring a track, and surfacing the dependency consequences rather than letting them break in silence.

How this connects

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. This page uses the WFM Labs Maturity Model™'s Levels 1–5. The chart's first four columns are the by-hand consolidation work of Level 2 into Level 3 — tracks 1 to 5 are almost entirely that — and they close on the roadmap's Arc 1 star quarter, which is where Level 3 arrives. The fifth column is Arc 2's opening quarter and belongs to the next climb: tracks 8, 9 and 12 describe what Level 4 adds, and track 7's record is the Level 4 object that a Level 5 platform later executes. The two pages agree on the arrival because they are drawing one program: the timeline simply draws one quarter of the second arc as well. Nothing on this chart moves a function up a level; the chart dates the artifacts whose use does.

See Also

References

  1. ↑ Kotter, J. P. (1996). Leading Change. Boston, MA: Harvard Business School Press. ISBN 978-0-87584-747-4.
  2. ↑ Goldratt, E. M. (1997). Critical Chain. Great Barrington, MA: North River Press. ISBN 978-0-88427-153-6.
  3. ↑ Brooks, F. P., Jr. (1995). The Mythical Man-Month: Essays on Software Engineering (Anniversary ed.). Reading, MA: Addison-Wesley. ISBN 978-0-201-83595-3.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Transformation_Timeline_for_a_Workforce_Function&oldid=4798"