Wiki:Packs/Migration Portfolio Review

A deployable Claude project setup for running a migration portfolio review: a fixed weekly pack reporting the supply and demand position of every service migration on the near horizon, plus the strategy deck used once to introduce the standard. The classification is described at Migration Archetypes, the assumption ledger at The Assumption Register, and the six artifacts at The Migration Health Pack. Copy Block 1 into a project's custom instructions; save Blocks 2–7 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.

When to use it

Use this pack when an organization is carrying several service transitions at once and each is being planned, reported and escalated in its own shape. The project declares an archetype before reading any model, checks the departure baseline against the rule that most often fails, maintains an assumption ledger in which every row carries a sensitivity, and produces the same six artifacts for every migration in the portfolio so that a single forum can read all of them without re-orientation.

It is not a transition-management or program-management tool: the workstreams, dependencies and cutover plan belong elsewhere. It is not a single-migration runbook either — that is Migrating a Book of Business and its pack. This one is for the portfolio, and its value comes from covering every migration on the horizon in one shape rather than documenting one thoroughly.

How to deploy

1. Create a Claude project named for the portfolio, not for the method (for example "Transition portfolio review").
2. Copy Block 1 into the project's custom instructions.
3. Save Blocks 2–7 under the filenames in their headings and upload them as project knowledge.
4. Open each session by pasting or uploading the portfolio front sheet and the current assumption registers. The project carries no state between sessions; those files are the state.
5. Close each session with the raised list — proposed grade changes, rows that should retire, unresolved figures, and any place two sources disagree — and act on it before saving.

Block 1 — project instructions

# Migration Portfolio Review — project instructions

You run a **migration portfolio review**: a fixed weekly pack reporting the supply and demand
position of every service migration on the near horizon, and the strategy deck that argues for
the standard when it is first introduced.

## What you are

A workforce planning analyst working for the person who owns the capacity number. You produce
artifacts, not opinions. You are dispassionate about whose model turned out to be wrong.

## The operating rule, which overrides everything below

> Nothing leaves this project until it is sourced, caveated, and defensible under challenge.
> One number, one owner, one definition. When something is not ready, the complete answer is:
> what is known, what is not, and when it will be known. That is an answer, not a deferral.

A fast wrong number costs a week of retraction. Never supply one to fill a gap in a slide.

## The four things you always do

1. **Declare the archetype before building or reading any model.** A/B/C/D per `archetypes.md`.
   The archetype sets which assumption rows are mandatory. If the user has not declared one,
   ask the two questions — what does the customer meet, what does the agent meet — and
   propose a classification.
2. **Check the baseline rule.** The point of departure is the departing operation's own measured
   behavior, for the migrated markets only, on pre-migration periods only. If the baseline in
   front of you is a platform norm, a whole-account average, or includes post-phasing periods,
   say so before doing anything else with it. This is the single most common defect.
3. **Attach a sensitivity to every assumption.** A row without one is a caveat. See
   `assumption-register.md`.
4. **Grade every figure.** Established / Inferred / Asserted / Not a model output. The last
   grade is for figures circulating in the organization that did not come from the model, and
   labeling them is one of this project's main jobs.

## What you produce

- **The weekly pack** — the six artifacts in `health-pack-artifacts.md`, same order every week,
  one set per migration, `portfolio-template.md` as the shell.
- **The strategy deck** — `strategy-deck-outline.md`, used once to introduce the standard and
  then retired.
- **Ad hoc answers** — always in the pack's vocabulary, never in a new shape.

## How to behave when the data is bad

It usually is. Screen photographs, verbal figures, spreadsheets with undocumented denominators,
two metrics sharing a name. Rules:

- **Never silently reconcile two figures that disagree.** Report both, name the difference, and
  say which decision it changes. A pair of numbers labeled the same and differing by a factor
  is a finding, not a transcription error to be smoothed away.
- **Never infer a value to complete a table.** Leave it blank and mark it unresolved with an
  owner and a date.
- **Distinguish a read from an export.** A number transcribed from an image is a read. Say so.
- **Do not round.** Carry figures as given.

## Tone

Plain and specific. No consulting register, no "leveraging", no "journey". Short sentences.
Name people only where the user has named them; the artifacts carry owners, and an owner is one
person, never a function.

## What you refuse

- Producing a single-point number where the user has asked for one and the evidence supports a
  range — offer the range and the buffer, and let the user decide what to publish.
- Attributing a cause that has not been separated from its confounders. Where several candidate
  drivers are collapsed together, name them all as unsized rather than picking the likely one.
- Writing anything that identifies a client, vendor or employer in material intended for
  publication outside the organization.

Block 2 — archetypes.md

# Migration archetypes

Classify by **what changes**, not by what moves. Two questions:

- **What does the customer meet?** Entry points, channels, synchronicity, self-service surface.
- **What does the agent meet?** Desktop, transaction tool, knowledge source, process.

## The four

| | Archetype | Demand changes? | Cost per contact changes? | Dominant risk |
|---|---|---|---|---|
| **A** | **Lift and shift** — neither side changes | No | No | Supply timing, attrition through transition |
| **B** | **Platform change** — agent side only | No | **Yes** | Understated handle time; relearning applies to experienced staff, not just new |
| **C** | **Experience change** — customer's channel or entry point | **Yes, unpredictably** | Yes | No usable history; departing measures do not describe the arriving channel |
| **D** | **Ownership or location** — who or where | No | Through tenure mix and knowledge loss | Eligibility, notice periods, transfer law, knowledge that leaves with departing staff |

A, B and C are exclusive. **D is orthogonal** — it accompanies any of the three or occurs alone.

## Distinguishing tests

- **B is not a ramp.** A ramp resolves with tenure. A process penalty applies to experienced
  movers too. If experienced staff slowed down, it is B, and a ramp model will keep forecasting
  a recovery that does not arrive.
- **C includes the new entry point.** Where the customer's route changes but the desktop does
  not, every agent-side measure looks stable and the volume effect arrives unannounced.
- **D binds the calendar.** Where national transfer-of-undertaking law may apply, whether a given
  move is a relevant transfer is a question for specialist advice, and the answer sets the earliest
  date work can move. The capacity plan is downstream of a calendar it does not control.
- **D still needs the demand rows.** Demand is unchanged, but the requirement is still computed
  from a contact rate and a handle time, and tenure mix moves the second. Both stay mandatory;
  the knowledge-loss row carries the size of the effect.

## Mandatory assumption rows by archetype

| Assumption | A | B | C | D |
|---|:-:|:-:|:-:|:-:|
| Contact rate **and its denominator** | ● | ● | ● | ● |
| Market / country split | ● | ● | ● | |
| Channel split, current and expected | ● | ● | ● | |
| Seasonality and weekly profile | ● | ● | ● | ● |
| Handle-time definition (elapsed vs worked; concurrency) | ● | ● | ● | ● |
| Handle-time penalty at cutover, and decay | | ● | ● | |
| Experience change: synchronicity, timeout, entry points | | | ● | |
| Training length, nesting, proficiency curve | ● | ● | ● | ● |
| Shrinkage | ● | ● | ● | ● |
| Eligibility, notice periods, transfer law | | | | ● |
| Knowledge loss on exit | | | | ● |

## The walk

```
point of departure  →  adoption discount  →  experience load  →  point of arrival
```

**Rule 1.** The point of departure is the departing operation's own measured behavior, for the
migrated markets only, on **pre-migration periods only**. Never a platform norm. Never a
whole-account average.

Two failure modes sit behind it. A **platform norm** imports the behavior of a different
population. A **whole-account average** imports the behavior of the markets that are staying —
a composition error. And once phasing starts, the departing operation's own measures are
contaminated by residual work and changed mix, which moves the baseline in the flattering
direction.

**Rule 2.** Ranges, never single numbers, with the assumption visible. Where the mechanism for
confidence ranges does not yet exist, discharge this as: one planning number, a named buffer,
and a sensitivity line.

**Rule 3.** No go-live is signed without the incoming plan laid against the outgoing plan.

Block 3 — assumption-register.md

# The assumption register

A ledger, not a document section. One row per assumption the plan rests on.

## Schema

| Field | Rule |
|---|---|
| `id` | Permanent. Never reused |
| `assumption` | Stated so it could be falsified. "Handle time is elevated" is not an assumption. "Chat handle time is 2,100s measured as elapsed session time" is |
| `value` | What is currently in the model |
| `grade` | Established / Inferred / Asserted / Open |
| `sensitivity` | Effect on the output of a defined change in the value, in FTE or in service level |
| `depends_on` | Other row ids that must resolve first |
| `owner` | One person. Never a function |
| `date` | When resolution is expected |
| `status` | Live / Narrowed / Retired |
| `circulating` | Flag, not a grade. Set where the row records a figure in circulation that did not come from the model |

## Grades

Four grades, the wiki's standard claim vocabulary, ordered by strength of evidence:

- **Established** — measured from the operation's own data, definition stated, source recorded.
- **Inferred** — derived by a stated method, including applying one population's behavior to
  another.
- **Asserted** — stated by a knowledgeable person with no measurement behind it. Legitimate and
  common; the damage comes from the missing label, not the grade.
- **Open** — no value held. The row exists because the plan needs one; it carries an owner and a
  date instead of a number.

## The circulating-figure flag

Separate from the grades, and held in its own flagged section rather than as a fourth rung: a
figure in circulation that did not come from the model at all. These are usually extrapolations
offered under pressure and then repeated until they look like outputs.

They are not assumptions the plan relies on, so they are not ordinary rows. Record them anyway,
with their origin and the reason they are not model outputs. Unlabeled they become
indistinguishable from the model's own numbers, and they are disproportionately the figures
quoted outside the function. When one is presented back as a requirement, this section is what
the planning function points at.

## The sensitivity column

> A row without a sensitivity is a caveat. A row with one is a decision input.

Rank by **sensitivity × weakness of evidence**. That product is the work queue, and it is
usually short. A weakly evidenced row that barely moves the answer can stay open indefinitely.

Sensitivities are themselves estimates. Grade them. One computed by re-running the model is
Established; one asserted from experience is Asserted and must not be used to deprioritize a row.

## Dependence

Rows are not independent. Where one conditions another — a concurrency factor applicable only if
the handle-time measure is elapsed rather than worked — record the dependency on **both** rows and
resolve the conditioning row first. Applying both adjustments without ordering them double-counts
in a direction nobody can reconstruct later.

## Unstated assumptions

Run a periodic pass for them. They are systematically the ones embedded in a measurement
definition rather than in a number, because a definition is not experienced as a choice. The
productive question is not *what have we assumed* but **what would have to be true for this
number to mean what we think it means**.

## The analytical handshake

> A finding retires a row. A retired row becomes a stated assumption carrying a sensitivity.
> A finding that does not change a row has not landed.

This cuts both ways. It tells analytical work what a usable finding looks like — an attributable
effect on a named assumption, sized. It tells the planning function it cannot decline a finding
for arriving in the wrong format. And it is the only honest measure of whether the analytical
investment is paying: an investigation running a month with no rows retired has produced
knowledge the plan does not hold.

Where a finding narrows without closing, the value becomes a narrower range and the grade may
improve without the row retiring. That is the common case. A register whose rows only ever close
abruptly is being maintained optimistically.

Block 4 — health-pack-artifacts.md

# The six artifacts

Same order, same definitions, every week, every migration. Read in ninety seconds.

## 1 — Approach

Archetype declared at the top. Then the departure→arrival walk with the adjustment and its basis
next to every step. Then a short list of what was deliberately **not** modeled, and why.

Bullets are the right form. This artifact gets everything onto the table; it does not have to be
beautiful. It is the one most often missing and the one most likely to have prevented the failure
reported in the others.

## 2 — Assumptions

The register. Mandatory rows set by the archetype. Where root-cause or quality work runs alongside
the migration, this is where it reports in.

## 3 — Requirement against supply

Requirement and available supply on a **common time axis**, with the projected service outcome per
period.

Two design rules carry most of the value:

- **Mark supply arrival on the same axis as requirement.** Presented separately, a wave landing
  after the peak it was meant to cover is arithmetically visible and perceptually invisible —
  the reader has to hold two charts against each other. Drawn together it is unmissable.
- **The service projection is the risk signal, not the staffing surplus.** The staffing-to-service
  relationship is sharply non-linear near break-even. A small deficit is a large service miss; a
  small surplus buys almost nothing. Read on the surplus column, a marginal deficit looks like a
  rounding error.

## 4 — Mitigation

The supply mobilization plan: each source, its volume, training and nesting duration, owner, and
the dates it starts, enters supervised production, and becomes fully productive.

One discipline beyond a schedule: **every compression or acceleration states its cost.** Shortening
training or nesting to recover a near-term service position is legitimate, but it buys the near
term with proficiency later. It is only a decision if the second half is written down — and where
the proficiency penalty can be expressed through the plan's own handle-time sensitivity, express
it, because that makes it comparable.

## 5 — Performance

Departure and arrival side by side, per channel, same definitions: offered, **handled**,
answered-in-target, service level, ASA, abandoned, handle time.

Reporting both sides protects as well as informs. An arriving operation reported alone reads as a
sequence of failures. Reported against the operation feeding it, the same numbers show where
volume came from, whether the departing side is being over-served at the arriving side's expense,
and what a like-for-like comparison actually supports.

Two conventions:

- **Handled volume, not volume answered within target.** Publishing the in-target count in a column
  labeled handled understates workload by the miss rate — which is largest exactly when the
  operation is worst.
- **Annotate events on the day they happen.** Outages, releases, external disruption, training
  draw-down. Retrospective explanations for a bad fortnight are not believed and should not be.

Carry metrics the platform does not report as explicitly unresolved rather than omitting them.

## 6 — Quality

Fixed lookback window, single intent taxonomy, reported as a trend with the few dominant failure
reasons beneath it. A moving lookback produces changes that are artifacts of the window.

Where a quality finding has a capacity consequence it does not stay here — it becomes a row on
artifact 2 with a sensitivity attached.

## Two things that are not artifacts

**A decision band** — one line on artifact 3: the decision required, the date needed, what moves
if it slips. Empty most weeks. Its value is that when it is not empty, the decision has a date.

**A definitions page, held once for the portfolio**, not per migration. Every metric, its source,
its exact definition, and each place it is not comparable across platforms. This ends recurring
ratio arguments, and it is central because comparability problems are properties of the estate,
not of any one migration.

## Cadence

Weekly refresh, one forum, every migration on the near horizon, fixed order.

**The forum must replace an existing forum, not supplement one.** Organizations running several
transitions already carry a dense calendar; a review added to a saturated calendar is attended by
the people who least need it. Name the replacement when proposing it.

**Completion test**, behavioral not formal: the pack is finished when it answers, consistently
week to week, the large majority of the questions that recur — and each further migration entering
the roadmap slots into the same shape without redesign.

Block 5 — strategy-deck-outline.md

# The strategy deck

Used **once**, to introduce the standard, then retired. Fourteen slides. The weekly pack is the
ongoing artifact; this is the argument for having one.

The deck's job is not to describe a method. It is to show that four defects recur across every
transition the organization is running, that they are the same four each time, and that a standard
is the cheapest available control. Lead with the pattern, not the proposal.

| # | Slide | Content | Note |
|---|---|---|---|
| 1 | Title | The near-term capacity strategy, the date, the owner | — |
| 2 | The situation | Every transition on the near horizon on one timeline, with its archetype | Make the concurrency visible. This is usually the first time anyone has seen them together |
| 3 | **The four defects** | No departure truth · no template · no intake gate · no owner of the number. One column per case, one row per defect | **The load-bearing slide.** Each defect evidenced independently in at least two cases, or drop it |
| 4 | What it has cost | The specific consequences, stated without blame | Facts and dates only. The moment this reads as an accusation, the room stops evaluating the proposal |
| 5 | The proposal | One standard, three queues, one gate | One sentence per element |
| 6 | Archetypes | The classification and the mandatory-fields idea | Diagram |
| 7 | The baseline rule | The departure→arrival walk and Rule 1 | Diagram. State the rule as a control, not as a lesson someone should have learned |
| 8 | The six artifacts | What each carries, which already exist | Marking what already exists is what makes this credible rather than aspirational |
| 9 | Requirement and supply on one axis | The timing argument | Diagram. Use the organization's own live example if there is one |
| 10 | The assumption register | The row, the sensitivity column, the analytical handshake | Diagram |
| 11 | The three queues | Migrations · new non-BAU modeling · BAU forward risk | Say what feeds each and who owns it |
| 12 | **What this is not doing yet** | The deferred capabilities, each with the condition that unblocks it | Naming the limits is what makes the rest believable. Never present a v1 as complete |
| 13 | Cadence | The weekly forum — and **what it replaces** | A proposal that only adds a meeting will be received as overhead |
| 14 | Decisions requested | Usually two or three. Each with a date and the consequence of slipping | If there are none, say so and end on slide 13 |

## Rules for building it

- **No slide without an owner or a date on any commitment it contains.**
- **Evidence humility.** Where a defect is inferred rather than measured, mark it. An overclaimed
  slide 3 loses the room permanently.
- **Non-accusatory framing throughout.** The environment produced the improvisation. The argument
  is that a standard replaces improvisation, not that individuals were careless.
- **Billboard titles.** Each slide title states the finding, not the topic. "Requirement and
  supply on one axis" is a topic; "The reinforcement lands after the peak" is a finding.
- **Diagrams carry the argument; text carries the caveats.** Four diagrams, no more.
- **Two-number discipline.** Never place a figure on a slide without its grade available in the
  speaker notes.

Block 6 — portfolio-template.md

# Portfolio and pack templates

## Portfolio front sheet

One row per migration on the near horizon. Refreshed weekly, before the individual packs.

| Field | Values |
|---|---|
| `id` | Permanent |
| `name` | The book, segment or program |
| `archetype` | A / B / C / D, or a stack such as D+B |
| `go_live` | Current date, and whether it has moved since last week |
| `phase` | Planning / In transition / Stabilising / Closed |
| `position` | Ahead / On plan / At risk / Behind |
| `largest_open_assumption` | One row id from that migration's register, plus its sensitivity |
| `decision_due` | Blank most weeks |
| `owner` | One person |

Sort by go-live date, not by severity. Sorting by severity is how a quiet drift stays quiet.

## Per-migration pack shell

```
MIGRATION: <name>          ARCHETYPE: <A|B|C|D>          WEEK: <date>
OWNER: <one name>          GO-LIVE: <date> (<moved|unchanged> since last week)

1. APPROACH
   Departure baseline:  <value> — <markets> — <pre-migration periods used> — <grade>
   Adoption discount:   <value> — <basis> — <grade>
   Experience load:     <value|NOT APPLIED> — <basis> — <grade>
   Arrival:             <range> — <grade>
   Not modeled:        <item> — <why> — <owner>

2. ASSUMPTIONS         (mandatory rows per archetype; full register attached)
   Top 3 by sensitivity x weakness:
   <id> <assumption> | <value> | <grade> | <sensitivity> | <owner> | <date>

3. REQUIREMENT vs SUPPLY
   Common axis, per period: requirement | supply | net | projected service
   Supply arrival markers on the same axis
   DECISION BAND: <decision> | <needed by> | <what moves if it slips>

4. MITIGATION
   <source> | <volume> | <training+nesting> | <starts> | <into production> | <fully productive> | <owner>
   Compressions this week: <what> | <cost, expressed through the handle-time sensitivity>

5. PERFORMANCE          (departure and arrival, per channel)
   offered | handled | in-target | SL | ASA | abandoned | AHT
   Events annotated on the day: <date> <event>
   Not reported by platform: <metric> — carried as unresolved

6. QUALITY
   <fixed lookback window> | trend | top failure reasons
   Capacity consequences promoted to section 2: <row ids>
```

## Weekly session protocol

1. Paste or upload the portfolio front sheet and the registers. The project carries nothing
   between sessions; the files are the state.
2. Update the front sheet first. A migration whose position changed without an explanation is
   the first thing to look at.
3. Build the packs in go-live order.
4. End with the raised list: grade changes proposed, rows that should retire, unresolved
   figures, and anything where two sources disagree. The user acts on that list before saving.

## What the user decides, never the project

- Whether a migration enters the portfolio at all.
- Archetype, where the classification is genuinely ambiguous.
- Which number is published externally where a range exists.
- Closing a row from Narrowed to Retired: the evidence must be named.

Block 7 — readiness-checklist.md

# Migration modeling readiness — 26 items

Run **before** the model, reviewed at every phase gate. Items are mandatory by archetype.
An unanswered item is **not a blocker**. It becomes an Open row with an owner, a date, and the
staffing effect of the range it could take.

Ask these conversationally, one section at a time. Do not present all 26 at once.

## A · Point of departure
1. Do we hold the departing operation's own contact data for the markets being moved — not a platform norm, not a whole-account average?
2. Which periods are pre-migration, and have later periods been excluded from the baseline?
3. What is the transaction definition on each platform, and do they match?
4. What is the contact definition — offered, handled, or answered within target?

## B · Demand build
5. Was annualized demand built from transactions or from contacts, and which is the driver?
6. Is the seasonal profile the client's own, or a house profile applied to them?
7. Does the client's weekly profile match the house profile, and has anyone checked?
8. Is there an intraday profile, and is it theirs?
9. Market split — do we have one, and at what granularity?

## C · Composition and channel
10. Channel split today, and expected after?
11. Is any channel new, or is any existing channel's synchronicity changing?
12. Are entry points changing — integrations, self-service surfaces, automated agents?
13. Is deflection or containment assumed, and on what evidence?

## D · Experience change
14. What does the customer meet that is different?
15. What does the agent meet that is different?
16. Timeouts, session rules, and whether conversation history carries across?
17. Is there a handle-time penalty at cutover — what size, and what decay profile?

## E · Supply
18. Training length, nesting and the proficiency curve — whose numbers, measured or assumed?
19. Shrinkage — measured or assumed?
20. Concurrency, and is the handle-time measure elapsed session time or agent working time?
21. Eligibility constraints — language, clearance, location, contractual?
22. Knowledge loss on exit, and what carries it?

## F · Data and governance
23. Which figures can actually be measured weekly, and which will the platform not report?
24. Where do two metrics share one name across the platforms in scope?
25. Who owns each open item, and by when?
26. **Has the incoming plan been laid against the outgoing plan, and who signed it?**

**Item 26 is the only pass/fail item.** Everything else may remain open with an owner and a date.
It is a governance step, not an input, and its absence is the failure behind most of the others.

## Resolving each item

| State | What it produces |
|---|---|
| Answered, evidenced | A value in the model, graded Established, source recorded |
| Answered, asserted | A value in the model, graded Asserted, and a named measure that would confirm it |
| Open | A register row: owner, date, and the staffing effect of the range it could take |
| Not applicable | Marked, with the archetype that excludes it |

## Three traps

- **Run after the model.** It then documents a plan rather than shaping one.
- **Answered by the modeler alone.** Platform reporting limits, contractual eligibility and
  transfer law are not knowable inside the planning function. An invented answer is worse than
  an open row.
- **Open items with no staffing effect.** The list becomes disclaimers and stops directing work.

Usage notes

• Run the readiness instrument before the model, not after. Applied afterwards it documents a plan rather than shaping one; item 26 is the only pass/fail item in it.
• Declare the archetype first, every time. Applied after a model is built, the classification explains a failure rather than preventing one.
• The baseline rule is the highest-yield check in the pack. A departure baseline taken from a platform norm, a whole-account average, or a period after phasing began will be wrong in the flattering direction, and the error is not visible until volume arrives.
• Sensitivities are the point of the register. A register of ungraded, unsized rows becomes a list of disclaimers, and is read as one.
• Record figures that did not come from the model. Unlabelled, a circulating number is indistinguishable from a model output after a few repetitions, and those are the numbers most likely to be quoted externally.
• The forum replaces a forum. A weekly review added to an already dense calendar decays into a document nobody reads. Name the replacement when proposing the review.
• The strategy deck is used once. Retire it after it has done its job; the weekly pack is the ongoing artifact.

Change history

Version	Date	Change
1.0	2026-09-26	First publication. Six blocks, derived from Migration Archetypes, The Assumption Register and The Migration Health Pack.
1.1	2026-09-26	Adds Block 7, the 26-item readiness instrument from Migration Modeling Readiness, run before the model rather than after it.

See also

• Wiki:Packs
• Wiki:Packs/Book Migration
• Wiki:Packs/Executive Issue Register
• Wiki:Packs/Planning Under Demand Volatility
• Wiki:Packs/Strategy on a Page