Program Roadmap & Cross-Project Dependency Map

What you'll produce

A one-page program roadmap plus a cross-project dependency map and a resource-arbitration decision for the Unified Checkout program at NovaPay — the artifact that proves you can do the thing the "program manager" title actually charges for: coordinate three separate projects toward one shared outcome, rather than run one project well. The roadmap places Checkout-Core (Marco), Partner-Integration (Lena), and Migration & Cutover (Dana) on a single timeline with their own milestones, then draws the dependency arrows between them — the handoffs where one project's output is another's input and where the program lives or dies. The dependency map scores each cross-project link, names the integration milestones (the dates where two projects must meet), and identifies the critical chain that runs across projects, not just within one. Finally, you make one real resource-arbitration call: the shared senior engineer (Diego) is needed by two project leads in the same window — you decide who gets him, when, and why, in writing, the way a program manager has to.

This is the deliverable a senior project manager doesn't produce, because a single project doesn't have it. It proves the program-altitude skills directly: sequencing parallel projects, managing dependencies you don't own (Lena can't fix a date that depends on Marco's team), arbitrating a resource across teams none of whom report to you, and holding a portfolio-level view of "are we going to make it" that no single project board can show. It is the artifact the program-deep-dive interview is built around — "you had three projects and one date; walk me through how you kept them aligned."

Instructions

1. State your altitude and pull the outcome forward. Write at the top: "Program altitude — coordinating Checkout-Core, Partner-Integration, and Migration & Cutover toward the charter outcome." Copy the charter's (Deliverable 1) program outcome and the immovable Sep 30 date. The roadmap exists to make that outcome happen across these three projects — not to re-plan any one of them (the WBS in Deliverable 2 already did that for Checkout-Core).
2. Lay the three projects on one timeline as swimlanes. One row per constituent project, weeks across the top (anchor to the charter's calendar — W1 = week of Jun 15, hard deadline Sep 30, same as Deliverable 2). In each lane, place that project's own 3–5 milestones with target dates and its own lead's name. The point of a roadmap is that a stakeholder sees all three projects' shapes at once — where they run in parallel, where one waits on another.
3. Draw the cross-project dependencies explicitly — these are the program's spine. A cross-project dependency is where one project's deliverable is another project's precondition. Name each as an arrow: from (producing project + milestone) → to (consuming project + milestone), the date it must land by, and what breaks if it's late. At minimum capture the two that define this program: (a) Checkout-Core's stable payment interface → Partner-Integration's integration test (Lena can't test against a moving target), and (b) Checkout-Core + Partner-Integration both done → Migration & Cutover's go-live + PCI sign-off (Dana can't cut over to a flow that isn't finished). Do not list intra-project dependencies here — those belong in each project's own plan; the roadmap is only about the links between lanes.
4. Identify the cross-project critical chain and the integration milestones — and prove it with dates that chain. Trace the longest path of dependent work that crosses project boundaries — the chain that sets the program end date. Mark the integration milestones: the specific dates where two projects must meet (e.g., "Payment interface frozen — Jul 3," "End-to-end partner test — Jul 24," "Cutover gate — Sep 21"). Every milestone on the chain must be a real dated marker in a swimlane — including the convergence points. If a downstream gate needs "both projects feature-complete," then both projects must show a dated feature-complete milestone, and the gate date must equal the later of the two (max), not a number you wrote down. Walk the chain end-to-end and check two things: each end-date is monotonic (climbs, never goes backward) and each downstream milestone starts when its upstream lands (no idle gap at the joins). A convergence date asserted with no milestone behind it is the most common way this artifact fails — don't claim "feature-complete by Aug 14," show the two milestones whose max is Aug 14. These are the dates you own as program manager; the leads own the work, you own the seams.
5. Make one real resource-arbitration decision, in writing. Diego (senior engineer) is needed by both Checkout-Core and Partner-Integration in the same 2–3 week window (the interface freeze overlaps the start of partner integration). You cannot split him in two. Decide: who gets him, in which weeks, and why — and state the cost to the project that loses him and how you'll cover it. The reasoning must be program-level: protect the cross-project critical chain, not whichever lead complained loudest. Name the backfill or the descope on the losing side. A decision with no stated cost is a coin-flip dressed up as a plan.
6. Add a portfolio-level rollup line. Under the swimlanes, one summary row: each project's current RAG and a single program RAG that is never greener than the worst project on the critical chain. State the rollup rule you used in one sentence (this is the same logic your Deliverable 5 dashboard will report weekly). The roadmap is where the rule is born; the weekly report just applies it.
7. Keep it to one page and make the seams obvious. A reader should finish it knowing: the three projects, who leads each, the two or three dates where they have to meet, the one resource fight and how you settled it, and whether the program is on track. If your roadmap looks like three independent plans stapled together with no arrows between them, you've drawn three projects, not a program — go back and find the seams.

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.

• Three real projects, not one project in three parts — 1: a single plan relabeled, or "projects" that are just workstreams of one team with no distinct lead, backlog, or done-definition · 2: three constituent projects on swimlanes, each with its own named lead and milestones · 3: the three projects are genuinely distinct (different cadences/leads/definitions of done — e.g., two Scrum, one Kanban), and the roadmap makes clear why this is a program (an outcome only all three together deliver), not a project a senior PM could run alone.
• Cross-project dependencies (the seams), not intra-project tasks — 1: dependencies are missing, or they're tasks within one project · 2: at least the two scenario-critical cross-project links are drawn as from→to arrows with dates · 3: every link is between lanes (one project's output = another's precondition), scored by likelihood×impact, dated, with the consequence of a slip stated — and intra-project dependencies are correctly excluded as out of scope for a roadmap.
• Cross-project critical chain & integration milestones — 1: no critical path, one drawn inside a single project, or a chain whose dates don't actually chain (a convergence/gate date asserted with no milestone behind it, end-dates that go backward, or an idle gap at a join) · 2: a dependent chain identified that crosses project boundaries and sets the end date, with end-dates that climb monotonically · 3: the critical chain is traced explicitly through all three projects with named integration milestones (the dates two projects must meet); every convergence point is demonstrable arithmetic — each contributing project shows a dated feature-complete milestone and the gate date equals the later (max) of them, end-dates are monotonic with no idle gap at the joins; the program float is quantified; and the chain — not any one project — is shown to set the Sep 30 date.
• Resource arbitration with stated cost — 1: the shared-engineer collision is ignored, or "split him" with no reasoning · 2: a clear who-gets-him-when decision is made and justified · 3: the decision is justified at program altitude (protects the critical chain, not the loudest lead), names the explicit cost to the losing project, and states the backfill/descope/escalation that covers it — a decision a VP could sign.
• Portfolio rollup with an honest rule — 1: no program RAG, or a program RAG greener than its worst critical-chain project · 2: per-project RAGs plus a program RAG with a stated rollup rule · 3: the program RAG strictly follows "never greener than the worst project on the critical chain," the rule is stated in one sentence, and it's consistent with the logic the weekly dashboard (Deliverable 5) will reuse.
• Coherence with the charter and one-page discipline — 1: disconnected from Deliverable 1, abstract dates, or sprawls past one page · 2: reuses the charter outcome and calendar, fits one page, altitude stated · 3: outcome, dates, leads, and the shared-engineer risk all trace cleanly from the charter; the altitude ("program") is declared; and a reader finishes in under a minute knowing the three projects, the two–three seams, the one arbitration call, and whether the program will make it.