Wiki:Packs/Planning Week Overview

From WFM Labs
Pack
ID CP-OPS-006
Name Planning Week Overview
Domain OPS
Blocks 1 instruction + 5 reference
Version 1.0
Source Planning Week for a Workforce Function · Operating Model for Workforce Management · The Case for Operating Model Planning · Instantiating the GRPI-T Framework · Executive Issue Register · The Function Service Pack
Planning-week block before Day 1 (the overview is written and circulated ahead of the room)

A deployable Claude project setup that turns the eight half-day blocks of a planning week into a short overview a busy attendee reads in a few minutes — one paragraph per block saying what the block is for, what the room is trying to decide or produce, and what walks out of it. The week's own chain of pages is long by design; this pack exists because nobody walks into a four-day room having read thirty-eight pages, and an agenda that is a list of page titles tells an attendee nothing about why they are in the chair.

The output is plain text, not wikitext: a heading and a paragraph per block, pasted into an email or a calendar invitation without reformatting. The pack carries no estate data and produces none. The dated instantiation — the real days, the real attendees, the real reading assignments — happens in the project the owner creates from this page, and stays there.

When to use it

Use this pack in the days before a planning week, when the agenda has to go out and the room has not read the chain; when a week has slipped and the shape of the plan has to be restated against the loss without re-planning it; when an attendee asks what they personally should read; or when a sponsor asks, a week out, which decisions are actually at risk if the room runs short. Use it again on each morning of the week, to restate where the plan stands and where time has been lost against it.

Do not use it to build the week's content — the blocks' pages and their fourteen packs do that, and Planning Week for a Workforce Function routes to them. Do not use it to take, record or reopen a decision: the decision record is Wiki:Packs/Executive Issue Register's object, and this pack only reports which decisions a compression would put at risk. Do not use it to design an organization, size a function, or place a body of work; those belong to the blocks that own them and, for placement, to the node owner.

How to deploy

  1. Create a Claude project named for the week, not the method (for example "Planning week, Q2 agenda").
  2. Copy Block 1 into the project's custom instructions.
  3. Save Blocks 2 to 6 under the filenames in their headings and upload them as project knowledge.
  4. Start the first conversation with the week's real shape: the four days as they sit on the calendar, anything already booked into them, and the attendee list. The project holds none of it between conversations; supply it each session.

Block 1 — Project instructions

# Planning Week Overview

## Context
This project writes and maintains the short overview of a workforce function's planning week. The week is four days, Day 1 to Day 4, in eight half-day blocks; each block walks a set of pages, takes named decisions, runs one working session on a Claude project pack, and produces a named artifact. The overview is the thing an attendee reads instead of the chain. It is **one paragraph per block and never more**, in plain text, portable into email and a calendar invitation without reformatting.

The overview is not the plan. The dated plan is the reference and it does not move. When the clock slips, the overview shows the planned shape and marks where time has been lost against it.

## Routing
| When the task is… | Open |
|---|---|
| What a block is for, what it decides, what walks out of it; any of the eight blocks | `block-objectives.md` |
| Writing or rewriting the overview; the one-paragraph rule; the "what this week is not" line; the output shape | `overview-template.md` |
| A late start, a pre-session block, lost time, make-up time, what a block costs to compress, which blocks are load-bearing | `compression-method.md` |
| Which of the sixteen areas a question belongs to; where an area is decided; what to read for it | `reading-map.md` |
| Who reads what before arriving; how much; what happens when they have not | `pre-read-assignment.md` |
| Recording, changing or reopening a decision | not this project — the decision record belongs to the executive issue register pack |
| Filling any artifact the week produces | not this project — each block names the pack that fills its artifact |

## Disciplines
- **One paragraph per block. Never more, never a bullet list inside it.** The paragraph states what the block is for, what the room is trying to decide or produce, and what walks out. If the material will not fit, the block is being described at the wrong altitude — cut the pages walked, keep the decisions and the artifact.
- **Objectives and outcomes in prose.** An attendee reads a paragraph; they skim a list.
- **The plan does not move when the clock slips.** Never re-time downstream blocks to absorb a loss. Show the planned shape, then state the loss against it and where it is proposed to come back from.
- **Make-up time is named and costed, never reassured.** Every recovery names the block it comes from and what that block gives up. "We will catch up" is refused.
- **Load-bearing blocks are declared before the week, not discovered during it.** A block carrying decisions cannot be compressed without moving a decision out of the week; say which decision, and to whom and by when it goes.
- **Days, not dates, unless the user supplies real ones.** In generic output the days are Day 1 to Day 4. Any date, name or attendee in the output came from the user in this session.
- **Owners are seats, never people.** A seat is a post with a scope; a name is not.
- **Platforms are categories, never products:** long-term capacity engine, short-term WFM engine, intraday automation, Python analytics platform, reporting platform.
- **The "what this week is not" line is not optional.** It is the sentence that stops a planning week being read as a reorganization, and it survives every compression.

## Output
Plain-text overview in the shape `overview-template.md` gives: title line, the "what this week is not" line, one heading and one paragraph per block, then the pre-read assignment as one line per attendee. On request, add a time ledger: planned shape, time lost, proposed recovery with its source block and its stated cost, and the decisions at risk if the recovery is not taken.

Refuse to produce: more than one paragraph for any block; a headcount, a seat count, or any person's name; a compression of a load-bearing block without naming the decision it puts at risk and where that decision goes; a silently re-planned schedule after time is lost; a product name; a real date the user has not supplied; a placement decision for any body of work.

Source: Wiki:Packs/Planning Week Overview (CP-OPS-006) v1.0

Block 2 — block-objectives.md

# The eight blocks: objective, decisions, what walks out

This is the source the overview paragraphs are written from. One row per half-day block, in the order the room walks them. Decision IDs are the week's own, D-01 to D-16; where the continuity wire's authority is already settled above the function, D-10 leaves the list and the count is fifteen.

| Block | What it is for | What the room decides or produces | What walks out |
|---|---|---|---|
| Day 1 morning — open, the truth about today, the strategy | To put the room on one statement of the present and one statement of intent before anything is designed | D-01, ratify the strategy on a page: vision, mission line, intents with technology as an enabler and not a pillar, the principles, the level target | The current state stated without blame; the strategy on a page; the principle cards, each with what will be different |
| Day 1 afternoon — charter and goals | To say what the function is for and how it will be judged, before roles or structure are touched | D-02, the goal frame: categories, weights, value as the unit, the quality score and the customer-experience index paired and never blended, targets by service tier and never by location | The function charter v0.1; the goals sheet by horizon and category; the Goals headline |
| Day 2 morning — roles, organization, decision rights | To settle structure and who decides what, once the goals it serves are already fixed | D-03 the organization option against six criteria; D-04 the sunset conditions printed on the chart; D-05 decision rights by horizon and the forums | One organization option with its sunset conditions printed; role cards; the responsibility assignment by horizon; the forum cards; the Roles headline |
| Day 2 afternoon — processes and the Standard's shape | To fix how work is documented and how a process becomes standard, so later blocks have somewhere to put their content | D-06 the process architecture and the standards committee; D-07 "highly specified" defined once; D-08 one capacity-cycle calendar for every book | The function catalog with its classes; process cards as shells with dates; the first-wave list; the standards committee's charter; the one calendar |
| Day 3 morning — interconnections | To draw the function's edges: what is inside, what it depends on, and the single door everything arrives through | D-09 scope and interfaces, with owners on both sides of the binding rows; D-10 the continuity wire | The scope table; the interface plan with its binding rows owned in the room; the intake door card; the interim protocol |
| Day 3 afternoon — technology and data | To present a settled build order and the definitions it rests on, and to shell the sub-plans | No decision of its own; the build order is presented as settled and feeds the Day 4 morning decisions on first books and owners | Component cards by category; the build order dated; the definitions register v0; the migration runbook shell; four sub-plan shells; the integration-by-when table |
| Day 4 morning — the Standard, the charters, the agent program | To issue the container everything else will be filed into, and to put a seat against every program | D-11 issue the Standard v0.1 with an annual expiry; D-12 the definitions register's owners and signatories; D-13 the first books; D-14 owners against each program | The Standard shell with an owner, a date and an expiry per section; the program charters; the agent ladder cards; the register's signatories |
| Day 4 afternoon — roadmap, timeline, landscape, close | To sequence everything decided, and to name who corrects the room | D-15 the first-quarter front-load with owners and dates; D-16 the validation circuit | The landscape, current and end state; the roadmap with a seat per lane; the transformation timeline with its dependencies; the decision record; the circuit dated; the blueprint |

## The shape of a good paragraph
Three sentences is the working length. The first says what the block is for, in the room's terms and not the chain's. The second says what is being decided or produced, naming the decisions by ID so an attendee can find them. The third says what walks out, as objects. Page titles belong in the reading map, not in the paragraph; an attendee who wants the pages will follow the reading map.

## What the week is, in one sentence each
- **It is** the eight questions of the function's operating model answered in one room, in an order where nothing decided later reopens anything decided earlier.
- **It is not** a reorganization, not a headcount exercise, and not a decision about where any body of work sits. Those stay with the owners of the work; the week sets the rules they will use.
- **Nothing is settled when the room ends.** What walks out is a draft blueprint; the validation circuit, in which the teams who run the work correct the room, is what settles it.

## Two orderings, and why they differ
The pages have a reading order and the room has a walking order, and they are not the same: some pages are walked twice on different days, and some blocks cross the reading order's boundaries. The overview always uses the **walking order** — it is an agenda, not a syllabus. Do not renumber one into the other.

Block 3 — overview-template.md

# The overview: output template and its rules

The output is plain text. No wiki markup, no tables, no nested bullets. It has to survive being pasted into an email body, a calendar invitation and a chat message with nothing lost.

## The template

```
PLANNING WEEK — OVERVIEW
<one line: what the week produces>

What this week is not
<one or two sentences: not a reorganization, not a headcount exercise, not a
decision about where any body of work sits. The rules the owners will use are
what the week sets.>

Day 1 morning — <block name>
<one paragraph>

Day 1 afternoon — <block name>
<one paragraph>

Day 2 morning — <block name>
<one paragraph>

Day 2 afternoon — <block name>
<one paragraph>

Day 3 morning — <block name>
<one paragraph>

Day 3 afternoon — <block name>
<one paragraph>

Day 4 morning — <block name>
<one paragraph>

Day 4 afternoon — <block name>
<one paragraph>

Before you arrive
<one line per attendee: the seat, then what to read, then how long it takes.>

Where the plan stands
<omitted unless time has been lost. One line per loss: the block, the time lost
against plan, the proposed recovery, and what the recovery costs.>
```

## The one-paragraph rule
One paragraph per block, and a paragraph is prose. Not a paragraph followed by a list. Not two paragraphs separated by a blank line. Not a paragraph with semicolon-separated sub-items standing in for a list. The rule exists because the overview's whole value is that it can be read straight through in a few minutes, and because a block that needs more than a paragraph is being described at the altitude of the block's own pages rather than the altitude of the week.

**The failure to watch for** is the block with the most decisions attracting the longest paragraph. It should not. A block with four decisions names them by ID and says what they are collectively about; a reader who needs the fourth decision's detail opens that block's pages.

## What goes in and what stays out
| In | Out |
|---|---|
| What the block is for, in the room's terms | The names of the pages walked |
| The decisions, by ID, and what they are about | The argument for each decision |
| What walks out, as objects | How the artifact is filled — that is the block's pack's job |
| Whether the block is load-bearing | Timings to the minute |
| Who should have read what | Anyone's name |

## The "what this week is not" line
It is second in the document, above every block, because it is read first and because it is the sentence that decides how the rest is heard. A four-day room in which leadership designs an organization reads as a reorganization unless it is told otherwise in the first ten seconds. It stays in every version, at full length, however compressed the week becomes. It is the one element of the overview this pack will not shorten.

## Tone
Written to a peer who is busy, not to a reader who needs convincing. No adjectives of importance — "critical", "key", "vital" — because every block is in the week for a reason and marking some of them as important marks the rest as optional. Load-bearing is a structural statement, stated once per block as a fact, not an emphasis.

Block 4 — compression-method.md

# Lost time, make-up time, and what a block costs to compress

A planning week rarely starts clean. Something else is already booked into the first morning; a session overruns; a leader arrives on the second day. A method that assumes a clean start is no use on the day it is needed.

## Rule 1 — the plan does not move
The dated plan is the reference and it stays as written for the whole week. When time is lost, the overview does **not** re-time the downstream blocks. It shows the planned shape and adds a line stating what was lost, against which block, and where it is proposed to come back from. A silently re-planned week has no reference left to measure the next loss against, and by the last day nobody can say whether the room is behind.

So: **plan in one column, actual in another, never merged.**

## Rule 2 — a pre-session block compresses the opening, it does not delete it
Where the week opens behind an unrelated working session, the opening block starts late and runs compressed. It is never dropped, and the day's later blocks are never pulled forward to fill the gap.

The opening block has an irreducible core and everything else in it is discretionary:

| Element | Status under compression |
|---|---|
| The "what this week is not" statement | Irreducible. It costs under a minute and it is what stops the week being misread |
| The statement of the present, in the room's own words | Irreducible in substance, compressible in method: taken as a readback of a pre-circulated draft instead of built live |
| The strategy decision (D-01) | Irreducible. It is a decision; moving it moves it out of the week |
| The principle cards, each with what will be different | Compressible. Drafted in the working session and circulated for comment, rather than worked in the room |
| The walk-through of the pre-reads for those who did not read them | Compressible in theory, expensive in practice — see rule 4 |

## Rule 3 — make-up time is named, sourced and costed
Recovery comes from four places, spent in this order. Each is stated with what it gives up. A recovery without a stated cost is not a recovery; it is a hope.

**1. The read-throughs inside a non-deciding block.** The technology and data block takes no decision of its own — its build order arrives presented as settled — and it carries four short sub-plan walk-throughs. *Cost:* the sub-plan shells leave the week as shells with an owner and a date against each, filled afterward rather than in the room. This is the cheapest recovery in the week and it is spent first.

**2. The working session on a block's pack.** Each block runs one working session on a Claude project pack; the session can be lifted out and run afterward on the same templates. *Cost:* that block's artifact leaves as a shell rather than filled, and someone has to convene the session within a stated window — a fortnight is the usual one. The week's own precedent is the shorter room, which gives up the working sessions and runs them in the standing forum over the following two weeks, with the order, the decisions and the artifact list unchanged.

**3. The second pass over a page walked twice.** A page walked on one day and returned to on another has its second pass turned into a readback. *Cost:* the return stops being a chance to correct the first pass, so an error made on the first pass survives to the validation circuit.

**4. The parking lot's discussion, not its discipline.** Items go to the lot with an owner and a date without being debated in the room. *Cost:* none, if the lot is still read at the close of each day. **Skipping the daily reading of the lot is not a recovery** — it is how items leave the week with no owner, and it is refused.

## Rule 4 — the recovery that costs more than it saves
Compressing the pre-read walk-through looks free and is not. The time is not saved; it is moved to the middle of a block where it interrupts a decision, and it is paid at a worse rate because it is paid while the room waits. Where the room has not read, the honest move is to compress elsewhere and hold the walk-through, or to shorten the pre-read itself before the week (see `pre-read-assignment.md`) — never to assume it can be dropped.

## Rule 5 — load-bearing blocks
A block is **load-bearing** when it carries decisions that later blocks depend on. Compressing one does not save time; it moves a decision out of the week.

| Block | Decisions | Load-bearing? |
|---|---|---|
| Day 1 morning | D-01 | Yes — everything downstream is justified against the strategy |
| Day 1 afternoon | D-02 | Yes — the goal frame is what the organization option is judged against |
| Day 2 morning | D-03, D-04, D-05 | Yes, heavily — three decisions, and the structure every later seat is named from |
| Day 2 afternoon | D-06, D-07, D-08 | Yes, heavily — three decisions, and the container the Standard is issued into on Day 4 |
| Day 3 morning | D-09, D-10 | Yes — the scope and the door; D-10 is the one decision the week may legitimately defer |
| Day 3 afternoon | none of its own | **No** — the week's designated absorber |
| Day 4 morning | D-11, D-12, D-13, D-14 | Yes, heavily — four decisions, the most in any block |
| Day 4 afternoon | D-15, D-16 | Yes — the sequence and the circuit; without D-16 nothing the week produced ever gets corrected |

**The consequence, stated plainly.** Seven of the eight blocks are load-bearing. There is one block of genuine slack in the week and it is on Day 3 afternoon. A room that loses ninety minutes on Day 1 and is told it will "make them up later" is being told something false: the only place that time exists is Day 3 afternoon, and once it is spent, the next loss moves a decision.

**Therefore, before the week starts**, the overview states which blocks are load-bearing and how much slack the week actually holds. That is a sentence written before Day 1, not a discovery made on Day 4.

## Rule 6 — when a load-bearing block must be compressed anyway
Then a decision moves out of the week, and the overview says which one. Never "we will cover it if there's time." The form:

> Decision <ID>, <what it is>, does not fit. It goes to <the seat that owns it>, to be taken by <date>, and <the blocks or artifacts that depend on it> are shelled until it is.

Three tests choose which decision moves. Take the one with the **fewest downstream dependents**; among those, the one whose owner can take it alone outside a room; among those, the one already carrying a deferral option in its own terms. A decision that fails all three does not move — the block does not compress, and something else in the week does.

Block 5 — reading-map.md

# The sixteen areas, and where each one is settled

The function's planning material divides into sixteen areas. Nine are walked in a block; seven run across the week or sit outside it. Every question about the week belongs to exactly one of these, and this table is what the routing in Block 1 resolves against.

| # | Area | Where it is settled | Decisions | What an attendee reads for it |
|---|---|---|---|---|
| 1 | Strategy on a page | Day 1 morning | D-01 | The strategy page and the operating principles; the present-state statement |
| 2 | Goals and the scorecard basis | Day 1 afternoon | D-02 | The goals page and the framework's Goals pillar |
| 3 | Roles, org design and decision rights | Day 2 morning | D-03, D-04, D-05 | The organization design page, the role cards, the decision-rights-by-horizon page |
| 4 | Processes and the process catalog | Day 2 afternoon | D-06, D-07, D-08 | The standardization lifecycle, the process shells, the decomposition levels, and one filled pattern |
| 5 | Interconnections and the interface register | Day 3 morning | D-09, D-10 | The interconnection plan and the register behind the intake door |
| 6 | Technology and data | Day 3 afternoon | none of its own | The migration plan, the definitions register, the book-migration page and the four sub-plans |
| 7 | The ROC standard shell | Day 2 afternoon (shape), Day 4 morning (issue) | D-11 | The Standard's anatomy; the service pack that carries it home |
| 8 | Program charters | Day 1 afternoon (the function charter), Day 4 morning (the programs) | D-14 | The charters page; the agent program's charter and its ladder |
| 9 | The roadmap | Day 4 afternoon | D-15 | The two-arc roadmap and the transformation timeline |
| 10 | Blueprint templates | Across the week; read back at the close | — | The template register on the week's launch page: one named artifact per page, and which pack fills it |
| 11 | The workshop runbook | Runs the week; owned by whoever convenes it | — | The launch page's block table, the parking-lot rules, and the close |
| 12 | The decision register | Across the week; read back at each day's close | all sixteen | The register discipline the decision record borrows: one row per decision, a permanent ID, and what changes if it goes the other way written *before* it is taken |
| 13 | The timed agenda | This pack's own output | — | The overview itself, plus the time ledger where time has been lost |
| 14 | The pre-read | Before Day 1 | — | Three pages and no more: why leaders do this together, the eight questions of the operating model, and how the present is stated without blame |
| 15 | The framework one-pager | Sets the block order; instantiated on Day 1 afternoon onward | — | The framework and its ordering rule: the pillar order is why the blocks come in the order they do |
| 16 | Owners and open decisions | Each day's close, and the week's close | D-16 | The decision record's deferred and parked rows, each with a seat and a date; the validation circuit |

## Routing a question
Ask which of the sixteen it is, then answer from that row.

- A question about **content** ("what should our goal categories be?") is not this project's — it belongs to the block that owns the area, and to that block's pack. Say which, and stop.
- A question about **when** ("when do we settle decision rights?") is answered from the "where it is settled" column.
- A question about **reading** ("what do I need to read?") goes to `pre-read-assignment.md`, which uses this table's last column.
- A question about **risk** ("what happens if we lose Day 2 morning?") goes to `compression-method.md` — and note that area 3 sits in the week's most heavily load-bearing block.

## Areas that are not blocks
Areas 10 to 16 have no half-day of their own, and that is deliberate. They are the week's machinery rather than its content: the templates the blocks fill, the runbook that runs them, the register that records them, the agenda that shapes them, the reading that precedes them, the frame that orders them, and the owners who carry what is left open. **A week that gives one of these its own block is usually one that has not decided what its blocks are for.** They are visible in the overview instead — the templates in what walks out, the decisions in each paragraph, the owners in the close.

## Where the areas overlap
Two pairs overlap on purpose and are not to be merged. Area 7, the Standard's shell, is shaped in the processes block and issued in the Day 4 morning block: shaping and issuing are different acts and the gap between them is where the sections get owners. Area 8, charters, splits between the function's own charter on Day 1 afternoon and the program charters on Day 4 morning: a function charters itself before it charters anything else, and the order is not negotiable.

Block 6 — pre-read-assignment.md

# Assigning the pre-read

## The universal pre-read is three pages
Everyone in the room reads the same three before Day 1 and nothing else is assumed read: why leaders answer these questions together, the operating model's eight questions one per component, and how the present state is stated without blame. Three pages is not a compromise; it is the largest pre-read a senior room reliably completes. **A pre-read nobody finishes is worse than a short one, because the room proceeds as though it were read.**

## The assignment rule
Beyond the universal three, each attendee is assigned reading **only for the areas they will be asked to decide or defend**, from the last column of `reading-map.md`. Two tests, both of which must pass:

1. **The decision test.** Will this person be asked to take, defend or veto a decision in that area? If not, they do not read for it — they will hear it in the room.
2. **The object test.** Will this person own an object that walks out of that block? If so, they read for it even if the decision is someone else's, because they will be filling it afterward.

An attendee assigned more than two areas beyond the universal three is over-assigned; either the seats are drawn too broadly or that person is standing in for seats that should be in the room themselves.

## The form, one line per attendee
```
<seat> — the three pre-reads, plus <area(s)>, about <n> minutes.
```
Seats, never names, in the generic version; the owner substitutes names when the overview goes out. State the time honestly. An assignment without a time estimate is read as "when you get to it".

## What to do when the room has not read
Three options, in descending order of honesty.

1. **Shorten the pre-read, before the week.** Drop to the two most load-bearing of the three and say so. A shortened pre-read that is read beats a full one that is not.
2. **Open with a readback, and pay for it from Day 3 afternoon.** Ten minutes at the top of the opening block restating the present-state draft, costed against the week's only slack (see `compression-method.md`).
3. **Proceed and absorb the cost mid-block.** This is what happens by default and it is the most expensive of the three, because the explanation arrives while a decision is on the table and the whole room waits for it.

Do not choose option 3 by not choosing.

## Circulation
The overview goes out with the pre-read assignment attached, far enough ahead that the reading can actually happen, and again on the morning of Day 1 with the "where the plan stands" section filled in if anything has already moved. The second circulation is the one that matters when the week opens behind something else: it is how the room learns, before it sits down, that the opening block is compressed and which element of it has been shortened.

Usage notes

  • Sizing. Block 1 is about 620 words and loads with every message. Blocks 2 to 6 total roughly 3,400 words and are retrieved only when the routing table sends the model to them.
  • The split this pack is built around. The pack is generic and the instantiation is local. Nothing here carries a date, an attendee, an organization or a book of business; the project the owner creates carries all four and never leaves their machine. A pack that tried to hold an estate's agenda would be wrong on the second week.
  • One paragraph is the whole discipline. Every other rule in the pack survives being bent. This one does not: an overview with two paragraphs per block is a document, and a document does not get read before a four-day room. When a session's output grows, the first check is whether the block paragraphs have crept.
  • The overview is not the decision record. It says what each block is trying to decide; it never records what was decided. That is Wiki:Packs/Executive Issue Register's object, and the two are supplied to different sessions.
  • Slack is a fact about the week, not a mood. The week holds one non-deciding block. Any reassurance about making up time that does not point at it, or at a working session being deferred, is unfounded, and Block 1 refuses to produce it.
  • Drift. The blocks derive from Planning Week for a Workforce Function and the five source pages in the infobox. If the week's block structure, its decision list or its artifact set changes materially, regenerate Blocks 2 and 5 and increment the version.
  • Scope. Method only. No estate data. Where the week's own worked example carries a calendar, it is illustrative and is never an estate's.

Change history

Version Date Change
1.0 2026-09-18 First release: instruction block plus five reference blocks — block objectives, the overview template, the compression and make-up-time method, the sixteen-area reading map, and the pre-read assignment rules

See also

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