Resizing a Workforce Function After an Acquisition

From WFM Labs

Part of the Planning Week chain · previous: Role Cards for a Workforce Function · next: Process Shells for a Workforce Standard Resizing a workforce function after an acquisition is a method for deciding the size of a workforce planning function that has been formed by combining the functions of several businesses. Its premise is that each acquired estate arrives with its own planning function, sized and shaped correctly for the business it served, and that the combined function's size is an outcome of three things done in order (standardize the method, consolidate the platform, hand written-down work to agent teams) rather than a target set before any of them. The method is written for a room that contains the people who built the current functions, and it is non-accusatory throughout: nothing on this page describes a heritage as wrong, and the method carries no headcount, no seat count and no target. The page produces the resizing note (RN, identifiers RN-nnn) and is worked in a session with Wiki:Packs/Organization Design and Role Cards (CP-WFM-014) for the method and Wiki:Packs/Agent Program Readiness (CP-OPS-005) for the third lever.

The starting position: several correct answers

An estate assembled by acquisition carries several planning functions, and each of them was designed by people who knew their business. One heritage may have organized by client segment because its clients differed in planning physics; another by region because its labor law and time zones demanded it; a third by platform because its booking or servicing system decided what could be pooled. Placed side by side, the three look incoherent. They are not. They are three coherent designs, each correct for the business that wrote it, that have never been reconciled, which is the condition Inherited Sourcing Doctrine in Merged Service Estates describes for sourcing rules and which holds for planning functions in the same way. The first thing a room does with the combined function is say that sentence aloud, because a resizing that begins by describing the current state as duplication has told the people in the room that their work was waste, and the method that follows needs them.

The second thing the room does is decline to name a target. A function whose size is set before its method is standardized will be sized for a method that does not yet exist; a function whose size is set before its platform is consolidated will carry its inherited configurations with fewer people; and a function whose size is set before its written-down work has been handed to agent teams will have decided how much judgment it can afford before it knows how much routine it still holds. The reviews of three decades of downsizing research report that reductions taken as a target, rather than as a consequence of a change in the work, often do not produce the financial results expected of them and are frequently followed by rehiring; they also report substantial variation by context and by how the reduction is implemented. The finding that holds across them is comparative: reductions that accompany a redesign of the work fare better than reductions taken alone.[1][2][3]

Size follows the estate: three levers in order

Lever What it does to the work What it does to the size What must be true before it is pulled Where the method lives
One. Standardize the method one forecasting method, one scheduling method, one real-time protocol, one placement gate, each written to the function's standard; the heritages' methods become inputs to the standard, not competitors with it removes the work of reconciling several methods (the parallel forecast, the parallel report, the argument at every close); changes little else the definitions register exists and the standards committee sits; the acceptance gate admits a document Standardize Before You Automate · Process Standardization Lifecycle · Anatomy of a ROC Standard
Two. Consolidate the platform every book runs on one configuration of the short-term WFM engine and one long-term capacity engine, migrated book by book with the definitions settled first removes the work of running parallel instances, parallel activity-code sets and parallel lock calendars; the platform's own automation becomes available to every book at once lever one has produced the configuration the instance is built to; each book's migration is a change-control item with an acceptance gate Migrating a Book of Business · Systems Administration for WFM Platforms · Platform Migration as a Definitional Forcing Function
Three. Hand written-down work to agent teams work that is highly specified (its resolution path written to L2 before it runs, through the acceptance gate, with step ownership and the active voice met) is run by an agent team with an overseer and a published catch rate; uncertain work stays with analysts who return a range removes the routine from the roles that held it; the people move to checking, modeling and exception work; the count direction on each role card is realized the process has passed the handover gate; the overseer is named; the ladder's alpha rung has run in shadow The Agentic Journey Map · AI Agent Program for a Resource Optimization Center · The Agent Team Ladder: Alpha to Production

The order is the order of dependency, not of preference. Lever two cannot be pulled before lever one because a platform consolidated onto unsettled definitions makes every early record permanently wrong; lever three cannot be pulled before lever two because an agent team can only be cloned onto a book whose definitions are in the register, and a book on its own platform configuration is a book whose definitions are not. The size of the function at the end of the third lever is whatever the work that remains requires, and it is read from the role cards' count directions realized, never from a number chosen on the first day. That is the wiki's standing position rather than this page's proposal: Role Evolution in the Resource Optimization Center already holds, under the roles that retire, that how much headcount a function keeps is the net of the relocation of displaced work and the demand automation induces, and is an output of the placement machinery rather than a figure a page can state; The Hardening Residual adds why the work left for people is harder per head than the average the function was last sized on, so that any size fixed early is a size for a state the estate is leaving. The three levers are how a merged function operationalizes both.

The size test

The size test is the third of the six criteria on Functional Organization Design for a Resource Optimization Center: how large does the human organization need to be at all? It is asked of the estate the function plans for before it is asked of the function, because the planners are sized to the population they plan. The population is bounded by the interior optimum, and that bound is a curve to be measured on the estate's own work rather than a figure to be read from a benchmark. The function's size follows the same curve one step behind: as the estate's routine contact is contained, the planning routine that served it thins, and as the estate's residual hardens, the planning judgment that serves the residual deepens. A room that has not measured its own interior optimum cannot size the function it is resizing, and should say so in the note rather than estimate around it.

Sunset conditions as the honest form of a transitional seat

Every seat that exists to consolidate is transitional, and the honest way to say so is a printed sunset condition: a sentence a stranger could test, on the chart, naming what must be true for the seat's work to end and where its work goes. A scheduling consolidation seat sunsets when one scheduling standard is live on one platform; a real-time consolidation seat sunsets when the protocol and the automation layer are live; a migration assignment sunsets when the last phase is accepted at the change-control board. The condition is the seat's contract with the people in it: they know what they are building, they know it will end, and they know it ends because they succeeded. A transitional seat without a condition becomes permanent, and a transitional seat with a date instead of a condition becomes a deadline that the standard is bent to meet. The conditions are decided with the org option (Decision Rights by Planning Horizon records them under D-04) and re-read at every validation circuit.

What to say to the people

The people in a merged planning function will read any structure page as a page about them, and the non-accusatory framing is what makes the three levers possible, because each lever needs the heritages' knowledge. Four things are true and can be said plainly. Roles evolve: the role map on Role Evolution in the Resource Optimization Center shows where each role's work goes, and the card for every role names its destination. New job classes open: the automation analyst, the overseer, the probabilistic modeler and the steward are roles that did not exist, and the function's first hires into them should come from its own planners, because those roles depend on knowing what the plan is for. The count direction is stated as a direction and realized only through the levers, so no one is sized out of a function whose routine has not yet been handed anywhere. And the ethics of the transition are part of the method rather than a caveat to it: retraining is planned before the handover, not after, and a role that retires as a title is a person whose work relocates, which the function owes them a path into.[4] The change-management pages this page defers to carry the how; the note carries the commitment.

Where the evidence runs out

That reductions accompanying a redesign of the work fare better than reductions taken alone is the most consistent comparative finding across three decades of reviews, and is the method's strongest support; the absolute effect of a reduction is not consistent across the same reviews, and the page does not rest on one. That standardization must precede platform consolidation is the wiki's own doctrine, grounded in integration theory, and is Inferred rather than Established for planning functions specifically. The evidence that agent teams compress planner effort on written-down work is a claim to be measured per A Roadmap Pattern for Agent Teams in WFM, not a result, and this page carries it as such. And the evidence runs out at the question of how much of a planning function's work is routine in the sense the third lever needs: that share is measured by decomposing the function's own processes to L2 and counting what passes the gate, and until a function has done that its resizing note should say the share is Open.

Worked example

The function is a workforce planning function formed from three heritages, at Level 2 (Foundational) as a band [A]. On Day 2 morning, after the role cards, the room writes the resizing note: the three heritages named as three correct designs; lever one already in motion because the definitions register and the standards committee are in the first-quarter front-load; lever two scheduled book by book behind the migration of the largest book; lever three already in motion on the migrating book, where the planning-loop team is at the pilot rung and the scheduling and real-time teams at beta, with the next rung and the clone onto a second book the things the week decides. The size test is recorded as Open, because the estate's interior optimum has not been measured on its own work. The count direction on every card is left as the card states it. Every transitional assignment on the chart carries a printed sunset condition; no target is written; and the note goes to the validation circuit with the rest of the day's artifacts.

The artifact this page produces

The resizing note (RN), one row per lever, with the size stated as an outcome at the end and a line recording the size test's grade. One filled example row:

ID Lever State today What must be true before it is pulled Owner (seat) What the size does when it is pulled
RN-001 One. Standardize the method each heritage's method still in use and written to its own standard; the placement gate not yet written down (Established) the definitions register signed; the standards committee's first sitting held the standardization seat the reconciliation work ends; the count direction on the forecaster and scheduler cards begins to be realized; no target

Produced in a working session with Wiki:Packs/Organization Design and Role Cards (CP-WFM-014), with the third lever's readiness check from Wiki:Packs/Agent Program Readiness (CP-OPS-005); the filled note is part of blueprint v0.1.

What would change this

The method's central claim is that size set as an outcome of the three levers produces a function that holds, and size set as a target first does not. The observation that would overturn it is a merged planning function that set a target on the first day, met it, and reports two annual cycles later one method, one platform configuration and a written-down share of work handed to agents, with no rehiring into the roles it reduced; if that function exists, the levers are a good description of the work and a poor argument about its order. The claim that the size test must be measured on the estate's own interior optimum would be overturned by a benchmark figure that predicted a function's stable size across estates better than the function's own measurement did.

How this connects

Maturity Model Position

The method is the Level 2 to Level 3 transition read as a sizing question: the first two levers are the climb by hand, and the third is where the automation layer begins to carry the function's own work. The size the method produces at Level 3 is not the size at Level 4, because the fourth level's roles are the modeling and governance roles the third lever opens, and the note says so. Four scales on this wiki use the word "level"; Planning Week for a Workforce Function states which is which. This page uses the maturity levels.

See Also

References

  1. ↑ Cascio, W. F. (1993). "Downsizing: What Do We Know? What Have We Learned?". Academy of Management Executive 7 (1), 95–104. doi:10.5465/ame.1993.9409142062.
  2. ↑ Cameron, K. S. (1994). "Strategies for Successful Organizational Downsizing". Human Resource Management 33 (2), 189–211. doi:10.1002/hrm.3930330204.
  3. ↑ Datta, D. K., Guthrie, J. P., Basuil, D., & Pandey, A. (2010). "Causes and Effects of Employee Downsizing: A Review and Synthesis". Journal of Management 36 (1), 281–348. doi:10.1177/0149206309346735.
  4. ↑ Acemoglu, D., & Restrepo, P. (2019). "Automation and New Tasks: How Technology Displaces and Reinstates Labor". Journal of Economic Perspectives 33 (2), 3–30. doi:10.1257/jep.33.2.3.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Resizing_a_Workforce_Function_After_an_Acquisition&oldid=4726"