Project / Program Manager Capstone

The idea: Knowledge becomes skill only when you do the work. In the capstone you take one real initiative — shipping the "Unified Checkout" program at NovaPay — and carry it through the entire delivery lifecycle, producing the exact artifacts a working project manager and program manager owns. You'll do both halves of the job the title names: you'll run a single project end to end (charter → schedule → sprints → risks → status → closeout), and you'll sit a level up and coordinate three parallel projects toward one shared outcome — the work that actually distinguishes a program manager from a senior project manager. By the end you'll have a portfolio that proves — to yourself and to employers — that you can turn chaos into an on-time, on-scope delivery without writing a line of code.

How it works: Each deliverable unlocks after the syllabus topic that teaches its skill. You produce the artifact (a template is provided), submit it, and the app's AI reviews it against a rubric, gives you specific feedback, and lets you revise until it's solid. Finished deliverables assemble into your portfolio.

Your scenario: deliver the "Unified Checkout" program at NovaPay

You don't pick a project — you step into one, the way you would on your first day. NovaPay is a 220-person fintech whose customers are small online merchants. Today checkout is split across three legacy flows (web, mobile, and a hosted link), conversion is leaking, and the VP of Product has secured budget for a "Unified Checkout" that merges them into one flow by the end of Q3 — a hard deadline tied to a partner integration and a marketing push.

Here's the thing that makes this a program, not a project: "Unified Checkout" can't be delivered by one team running one backlog. It's an outcome ("one merged, partner-ready, fully migrated checkout, live by Sep 30") that only happens when three separate projects land in the right order — each with its own lead, its own backlog, its own definition of done, and its own ways of failing:

Constituent project	Lead	What it delivers	Runs as
Checkout-Core	Marco (Tech Lead, Team A)	The merged checkout engine: one codepath for web, mobile, and hosted-link card payments	Scrum, 2-week sprints
Partner-Integration	Lena (Tech Lead, Team B)	The PartnerPay API integration the marketing push is tied to	Scrum, 2-week sprints
Migration & Cutover	Dana (Compliance + Release lead)	PCI re-attestation, data migration off the three legacy flows, and the staged go-live	Kanban / waterfall-ish

You are the program manager who owns the outcome across all three — and on the smallest of the three (Migration & Cutover is thin early on) you also act as the hands-on project manager, so you practice both altitudes. You do not run Marco's or Lena's sprints; they do. Your job is the space between the projects: the shared roadmap, the cross-project dependencies, the resource arbitration when two leads need the same person, and the single honest health picture leadership reads. The work spans:

• Three project teams (~14 people total) each with its own lead and competing priorities
• A designer and a data analyst shared across Checkout-Core and Partner-Integration
• Legal / Compliance (this touches PCI scope) — embedded in Migration & Cutover
• The external PartnerPay API team — a dependency you coordinate but don't control
• Support, who owns the cutover comms to merchants

The catch — the kind you'll see in every real program: there's no clean spec, the three projects have competing priorities and different cadences (two run Scrum, one runs Kanban), one senior engineer (Diego) is shared between Checkout-Core and another program and is on the critical path of Partner-Integration, and the deadline is immovable while scope is still vague. Partner-Integration cannot integration-test until Checkout-Core exposes a stable payment interface, and Migration & Cutover cannot go live until both are done and PCI signs off — so the projects are chained, and a slip in one is a slip in all. You carry this whole program through every deliverable: define and scope it, build a cross-project roadmap, plan and schedule the work, run one project in sprints, manage risks and dependencies across teams, report portfolio health weekly, and close it out with lessons learned.

Project altitude vs. program altitude. A few deliverables (the WBS/schedule, the sprint kit) you write at the project level — zoomed into Checkout-Core, the project you're closest to. Others (the program roadmap, the RAID log's cross-project dependencies, the portfolio RAG dashboard) you write at the program level, looking across all three. Knowing which hat you're wearing — and saying so in the artifact — is itself a graded skill: it's the difference the title is charging for.

Canonical cast — use one set of names across all seven artifacts. Graders reward a coherent thread; reusing the same people everywhere is the cheapest way to earn it. Treat these as the canonical names (some earlier worked examples were drafted before the program was split into three projects and may use a placeholder name like "Sam" for the shared engineer or "Marcus" for the sponsor — read those as the same people below, and use the canonical names in your own work):

Role	Canonical name
Sponsor / VP Product	Priya
Program Manager (you)	you
Checkout-Core lead	Marco
Partner-Integration lead	Lena
Migration & Cutover / Compliance lead	Dana
Shared senior engineer (50% on the Ledger program)	Diego
Ledger-program PM (you arbitrate Diego's time with)	Tom

What the finished portfolio proves

A coherent capstone shows a hiring manager that you can do the actual job — at both altitudes the title names — not just recite the phases. Across the seven artifacts it demonstrates that you can:

• Turn a fuzzy executive mandate into a defined, scoped initiative — with explicit out-of-scope, named owners, and success criteria.
• Coordinate multiple projects toward one outcome — build a program roadmap that sequences three projects on a shared timeline, surface the cross-project dependencies that decide the end date, and arbitrate a shared resource two project leads both need.
• Plan against a hard deadline — break work down, schedule it with dependencies and buffers, and reason about the critical path and triple-constraint trade-offs.
• Run delivery in an agile cadence — slice a backlog, plan a sprint, and make a fixed-deadline plan land as incremental, inspectable progress.
• See trouble before it hits — score and own risks (including the shared-engineer and PCI-scope ones), manage cross-team dependencies, and keep every stakeholder informed at the right altitude.
• Communicate health to leadership — give a busy exec the true status of the whole program in ten seconds, with a portfolio-level RAG that rolls up three projects and surfaces the asks and decisions.
• Close out and reflect — confirm delivery against the charter, run an honest retrospective, and walk away with lessons learned and an interview-ready story.

Together they tell one end-to-end story about a single program of three projects you ran — exactly the narrative the program-deep-dive interview round asks you to walk through.

The deliverables (your capstone arc)

The arc is numbered in the order the topics unlock it. Two of these sit at the program altitude — looking across all three projects — and the rest at the project altitude, zoomed into Checkout-Core. The program roadmap (Deliverable 7) is the one you'll write late (after the WBS, once you can sequence real durations) but read first: it's the map every other artifact hangs off.

#	Deliverable	Unlocks after	The skill it proves	Altitude
1	Project Charter & Stakeholder Map	Topic 3 (The project lifecycle)	Defining and scoping a fuzzy initiative	Program
2	Work Breakdown, Schedule & Critical Path	Topic 4 (Scope, time, and cost)	Planning a project against a hard deadline	Project (Checkout-Core)
3	Sprint Plan & Agile Execution Kit	Topic 5 (Agile and Scrum in depth)	Turning a plan into incremental delivery	Project (Checkout-Core)
4	RAID Log & Communication Plan	Topic 7 (Risk and stakeholder management)	Managing risk, dependencies, and stakeholders	Program
5	Weekly Status Report (Portfolio RAG Dashboard)	Topic 8 (Running the team day to day)	Reporting program health to leadership	Program
6	Project Closure & Retrospective Report	Topic 9 (Tools of the trade)	Closing out and capturing lessons	Program
7	Program Roadmap & Cross-Project Dependency Map	Topic 4 (Scope, time, and cost)	Coordinating three projects toward one outcome	Program

Each builds on the others: the charter (D1) defines what "done" means for the whole program and who's involved; the WBS and schedule (D2) zoom into one project — Checkout-Core — and turn its slice into a dependency-aware plan with a critical path; the sprint plan (D3) slices that plan into agile execution; the RAID log and comms plan (D4) protect the program and keep stakeholders aligned across all three projects; the portfolio RAG dashboard (D5) rolls the three projects up into one health picture for leadership; and the closure report (D6) confirms the result against the charter and harvests the lessons. Stitching them together is the program roadmap (D7): it sequences all three projects on one timeline, names the cross-project dependencies that set the end date, and arbitrates the shared engineer — the program-altitude artifact that turns six project-and-program documents into one coordinated story. The thread is visible end to end — your stakeholder map drives your comms plan, your roadmap's cross-project dependencies show up as the worst rows in your RAID log and the amber lights in your portfolio RAG, and your charter's success criteria are exactly what you measure at closure.

What "done" looks like

A complete capstone is seven artifacts about one program — Unified Checkout, three projects — taken from mandate to closeout, each passing its rubric, assembled into a portfolio you can link from your resume and walk through in interviews. When you reach the interview prep, you'll practice presenting these artifacts the way a hiring manager will probe them: the behavioral round mines them for stories about influencing without authority and arbitrating between two project leads; the scenario-execution round drills the trade-offs you made; and the program-deep-dive round is, quite literally, "walk me through how you kept three projects landing on one date."

Tips

• Know which hat you're wearing — and say so. The roadmap (D7), the RAID dependencies (D4), and the portfolio RAG (D5) are program work (across all three projects); the WBS (D2) and the sprint kit (D3) are project work (inside Checkout-Core). State the altitude at the top of each artifact. A buyer paying for program skills is paying for exactly the cross-project coordination in Deliverables 4, 5, and 7 — make it unmistakable.
• Keep it real and specific. "Manage the risks" is weak; "Diego is 50% allocated to another program and on the critical path of both Checkout-Core and Partner-Integration — contingency: pre-agree a backfill with the EM, and arbitrate his time to Partner-Integration in W6–W8 because that's the cross-project dependency, not Checkout-Core" is a program manager thinking.
• Let the cross-project dependency be the spine. Partner-Integration can't test until Checkout-Core ships a stable payment interface; Migration can't cut over until both are done and PCI signs off. That chain is the single most important fact about this program — it should drive your roadmap sequence, the top dependencies in your RAID log, and the rollup logic in your portfolio RAG (the program is never greener than its worst project on the critical chain).
• Reuse your earlier work. The same charter outcome should drive your roadmap, your project WBS, your sprint goal, your status rollup, and your closure criteria — graders (and employers) love a coherent thread through all seven artifacts about the same program.
• Carry the constraints forward. The immovable Q3 deadline, the vague scope, the three competing projects, the shared engineer (Diego), and the PCI scope are the spine of this program. Let them surface as trade-offs in the roadmap, as dependencies and risks in the RAID log, and as honest lessons at closure.
• Use the templates in ../templates/ as starting points, and revise based on the AI feedback rather than aiming for perfect on the first try (that's the whole loop).