Work Breakdown, Schedule & Critical Path

What you'll produce

A Work Breakdown Structure (WBS), a dependency-aware schedule, and an explicit critical path for the Unified Checkout program — the artifact that turns your charter's goal ("ship one unified checkout by end of Q3, hard deadline Sep 30") into estimable tasks, a realistic timeline with buffers anchored to the charter's real calendar dates, and a clear-eyed view of which two milestones will sink the Sep 30 date if they slip. This is the deliverable that separates a real program manager from a meeting-scheduler: it proves you can decompose vague scope into work, sequence it around dependencies (including the shared engineer and PCI sign-off), find the longest chain that sets the minimum possible end date, and then frame the squeeze as triple-constraint trade-offs you'd actually present to the VP — "for the same money and the same deadline, here is the scope we hold and the scope we move, and here's why." It is the single most-scrutinized artifact in a TPM interview's "walk me through your plan" round.

Instructions

1. Start from the charter goal, not a blank page. Copy your Deliverable 1 SMART goal and the in-scope list to the top. Every task you write must trace to something in scope; if a task doesn't, either it's out of scope (cut it) or your charter was incomplete (note it as an assumption).
2. Build the WBS top-down in 3 levels. Level 1 = the program. Level 2 = 5–8 major workstreams (e.g., Discovery & Spec, Design, Core Checkout Engine, PCI/Compliance, Partner API, Migration & Cutover). Level 3 = tasks small enough to estimate and assign — each should be 2–10 working days of effort. If a task is bigger than ~10 days, split it; if smaller than ~1 day, fold it up. Number them (1.1, 1.2, 2.1…) so you can reference them in the schedule.
3. Estimate each task in working days, and get the estimate from the doer's perspective. Write what one team working on it would take, not wall-clock time. Note who owns it. Humans are over-optimistic, so estimate honestly and add buffer at the schedule level (step 6), not by padding every task secretly.
4. Map dependencies explicitly. For each task, list what must finish first (its predecessors). This is where the program lives or dies — PCI sign-off gates launch; the partner API contract gates partner integration; design must precede build for each flow. Flag any task that depends on the shared senior engineer (Sam) or external Legal/PCI review, because those are the constraints you don't fully control.
5. Lay it out as a Gantt-style table with columns: ID · Task · Owner · Duration (days) · Predecessors · Start week · End week. Convert effort to a calendar by respecting dependencies and team capacity (two squads can run parallel streams; one shared engineer cannot be in two places). Anchor program weeks to your Deliverable 1 calendar dates, not to an abstract quarter — reuse the same start date and hard deadline you wrote in the charter (in the worked example: W1 = week of Mon Jun 15; hard deadline Sep 30), so W1…W15 each map to a real Monday–Friday range and your milestones M1–M6 land on real dates. A reviewer should be able to read "end of W15" and see "that's the week of Sep 21–25, with launch wrapping by Sep 30" — if your weeks don't tie back to the charter's dates, the schedule isn't built on the charter, it's built on a different planet.
6. Add buffer deliberately, where risk concentrates. Don't smear 20% across everything. Put a named buffer block before the milestones most likely to slip — typically PCI sign-off and partner integration — and state the buffer size. A schedule with zero buffer on a fixed deadline is a fiction.
7. Trace the critical path — and make it checkable. Find the longest chain of dependent tasks from start to the launch milestone — that chain sets your minimum possible end date. Tasks on it have zero slack; a one-day slip there is a one-day slip to launch. Tasks off it have float. State the path explicitly as a sequence of task IDs, and annotate each node with the week it ends (e.g. 3.1b (ends W8)) so a reader can walk the chain straight off your Gantt table and confirm the end-weeks climb monotonically with no idle gap at the joins. The longest chain is the one whose end-weeks reach the deadline with the least slack between links — show that, don't just assert it. Then prove it beats the runner-up: tally the nearest competing chain (typically the PCI branch) the same way and show it lands earlier or with float.
8. Name the 1–2 milestones most at risk of breaking the Sep 30 deadline, and for each write the triple-constraint trade-off you'd bring to the VP: if this slips, which lever (scope / time / cost) do we pull, and what's the recommendation? This is the deliverable's payoff — not "here's a plan" but "here's the plan, here's where it breaks, and here's the decision I need from you."

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

• WBS decomposition — 1: vague phases or tasks too big to estimate · 2: 3-level breakdown with estimable tasks that trace to the charter scope · 3: clean, numbered, MECE workstreams where every leaf task is 2–10 days, assignable, and clearly maps to an in-scope charter item.
• Estimates & buffer — 1: no estimates or invisible padding everywhere · 2: per-task durations with at least one deliberate, sized buffer · 3: realistic doer-perspective estimates with buffer concentrated where risk actually lives (PCI, partner), and a stated reason.
• Dependencies & schedule — 1: a flat task list with no sequencing · 2: a Gantt-style table with predecessors and start/end weeks that respect dependencies · 3: parallel streams across the two squads, the shared-engineer and external-review constraints honored, and a schedule that visibly fits inside the fixed window and lands launch on or before the Sep 30 deadline.
• Critical path — 1: missing, or just "the longest list" with no dependency logic · 2: an explicit dependent chain identified as the critical path with its length · 3: the true longest chain annotated with each node's end-week so it's checkable against the Gantt table (end-weeks rise monotonically, no idle gap at the joins), plus the nearest "shadow" path (e.g., PCI sign-off) tallied the same way to show it lands with float — the longest-chain claim is demonstrated, not asserted.
• Triple-constraint trade-offs — 1: states risks but no decision · 2: names the 1–2 at-risk milestones and proposes a scope/time/cost lever for each · 3: a VP-ready recommendation per milestone — the specific lever, the contingency, and the one decision needed now — written as something an exec could approve in one read.
• Coherence with the charter — 1: disconnected from Deliverable 1, or the schedule uses an abstract timeline (e.g. a generic "13-week quarter") that contradicts the charter's dates · 2: reuses the charter's goal and scope, and the program weeks are anchored to the charter's real start date and hard deadline · 3: every task, milestone (M1–M6), the buffer placement, and the trade-offs trace cleanly from the charter's SMART goal, named roles, and dates — "end of W_n" can be read back as a real calendar date that lands on or before the charter deadline.