Project Charter & Stakeholder Map

What you'll produce

A one-page project charter plus a stakeholder map for the Unified Checkout program at NovaPay. Remember the shape of this program: it's one outcome delivered by three constituent projects — Checkout-Core (Marco), Partner-Integration (Lena), and Migration & Cutover (Dana) — so you're chartering at the program altitude, across all three. The charter converts a fuzzy executive mandate ("merge our three checkout flows by end of Q3") into a signed-off agreement everyone can point to: the business case, one SMART goal, an explicit in-scope / out-of-scope line, key milestones, measurable success criteria, named roles, and the assumptions and constraints the plan rests on. The stakeholder map then places every named stakeholder on an influence × interest grid with a tailored engagement approach for each. This is the single most important thing a project/program manager does at initiation (Topic 3): without an agreed goal and scope, every later deliverable — the schedule, the sprints, the status reports, the roadmap — is built on sand, and scope creep has nothing to push back against. The charter is also where you first write down the canonical cast — the sponsor, the three project leads, the shared engineer — that you'll reuse verbatim in Deliverables 2–7. The charter is your authority. You have no direct power over the three teams, the shared designer, or Compliance; the charter and the relationships in the stakeholder map are how you lead without it.

Instructions

1. Write the business case in two or three sentences, with a number. State the problem (checkout is split across three flows, conversion is leaking) and the cost of inaction or the prize. Don't write "improve checkout" — write what the business loses today and why Q3 specifically. The number makes it real and gives you something to defend scope against later.
2. Compress everything to one SMART goal. Specific, Measurable, Achievable, Relevant, Time-bound — one sentence. A program will have many tasks, but only one goal. If you can't name the metric and the date in the goal, it isn't SMART yet. The immovable Q3 date and a conversion target belong here.
3. Draw the scope line explicitly — and list what's OUT. In-scope is easy; the value is in out-of-scope. Name the tempting things you are deliberately not doing (e.g., redesigning the merchant dashboard, adding new payment methods). Out-of-scope is your single most powerful tool against scope creep — you can only say "that's out" if you wrote it down on day one.
4. List 4–6 key milestones with target dates — and attribute each to a constituent project. Not a full schedule (that's Deliverable 2). Anchor them to the hard external dates (the partner integration window, the marketing push) and tag each milestone with the project that owns it (Checkout-Core, Partner-Integration, or Migration & Cutover) so the cross-project chain is visible at initiation: Checkout-Core's stable interface must land before Partner-Integration can test, and Migration & Cutover can't go live until both are done and PCI signs off. Milestones are checkpoints leadership tracks you against — and the program-altitude reader needs to see which lane each one sits in.
5. Define success criteria you could actually measure at closure. Each should be verifiable with a yes/no or a number — "conversion uplift measured in A/B test," not "checkout is better." These become the bar you confirm against in the closure report (Deliverable 6), so write them as if a skeptic will check.
6. Name every role with a real person and a clear responsibility — and use the canonical cast. Sponsor (Priya), PM (you), the three project leads (Marco / Lena / Dana), the shared senior engineer (Diego), and the partner (PartnerPay) come straight from the capstone brief — copy these strings exactly; don't invent a parallel cast, because reusing them verbatim across all artifacts is the rubric's most-graded criterion. Use a RACI-style lens: for the program, who is Accountable (one name), who is Responsible, who must be Consulted and Informed. Ambiguous ownership is the #1 cause of dropped work.
7. State assumptions and constraints honestly. Assumptions are things you're taking as true that, if false, break the plan (e.g., "the partner's sandbox is ready by July 1"). Constraints are fixed limits (fixed deadline, PCI scope, one shared senior engineer at 50%). Naming them now is what lets you raise them as risks later (Deliverable 4) instead of being blindsided.
8. Build the stakeholder map. Take every named stakeholder and place them on a 2×2 of influence (low/high) × interest (low/high). For each, write a one-line engagement approach matched to their quadrant: high-influence/high-interest = manage closely; high-influence/low-interest = keep satisfied; low-influence/high-interest = keep informed; low-influence/low-interest = monitor. Tailor the message — execs get the headline and the risks, the team gets the detail (Topic 7).
9. Keep the charter to one page. If it spills over, you're planning, not chartering. Brevity is the discipline: an exec must be able to read it and sign it.

            HIGH INTEREST                         LOW INTEREST
          ┌───────────────────────────┐   ┌───────────────────────────┐
   HIGH   │  MANAGE CLOSELY           │   │  KEEP SATISFIED           │
INFLUENCE │  • Priya (Sponsor/VP)     │   │  • Tom (Ledger-prog PM —  │
          │  • Marco (Checkout-Core)  │   │     owns Diego's other    │
          │  • Lena (Partner-Integ.)  │   │     50%)                  │
          │  • Dana (Migration/PCI)   │   │  • PartnerPay (ext. API)  │
          └───────────────────────────┘   └───────────────────────────┘
          ┌───────────────────────────┐   ┌───────────────────────────┐
   LOW    │  KEEP INFORMED            │   │  MONITOR                  │
INFLUENCE │  • Sofia (Design, shared) │   │  • Maya (Support)         │
          │  • Tomás (Data, shared)   │   │     until rollout nears   │
          │  • Diego (shared eng)     │   │                           │
          └───────────────────────────┘   └───────────────────────────┘

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.

• Business case & SMART goal — 1: vague mandate restated, no metric or date · 2: clear problem plus one goal with a metric and the date · 3: quantified business case ($ / conversion gap) and a single, genuinely SMART goal an exec would sign.
• Explicit in-scope vs. out-of-scope — 1: only lists what's in, or no scope line · 2: both lists present and clear · 3: out-of-scope deliberately names the tempting extras (and why), creating a real defense against scope creep.
• Milestones & measurable success criteria — 1: no dates, or success unverifiable ("make it better") · 2: dated milestones and checkable success criteria · 3: milestones anchored to real external dependencies and success criteria a skeptic could verify at closure.
• Program structure: three constituent projects established at initiation — 1: chartered as a single project, or as a two-team (Team A / Team B) split, with no constituent projects named — the learner has built a project, not the program the capstone requires · 2: the three projects (Checkout-Core, Partner-Integration, Migration & Cutover) are named, each with its own lead · 3: each project is genuinely distinct — its own lead (Marco / Lena / Dana), its own deliverable, its own cadence (two Scrum, one Kanban) — and the charter's roles, milestones, and constraints make clear why this is a program, not a project: an outcome only all three together deliver, chained so Partner-Integration can't test until Checkout-Core ships a stable interface and Migration can't cut over until both are done and PCI signs off. The three-project structure that Deliverables 5 and 7 depend on is set up here, at initiation — not retrofitted into the roadmap later.
• Named roles with clear accountability (your canonical cast) — 1: roles unnamed, ownership ambiguous, or a cast that contradicts the capstone brief (e.g., a two-team split instead of the three constituent projects, or invented sponsor/lead names) · 2: every role named with a responsibility, using the canonical names (Priya sponsor; Marco / Lena / Dana as the three project leads; Diego shared engineer; PartnerPay partner) · 3: RACI-style clarity — exactly one Accountable owner, no dropped ownership, the three-project structure visible, shared/constrained resources flagged (Diego at 50%, arbitrated with Tom), and the names are locked as the cast you will reuse verbatim in Deliverables 2–7 (the same sponsor, three leads, and shared engineer appear unchanged in your WBS, sprint kit, RAID log, status reports, closure, and roadmap — one coherent program, not a new cast per artifact).
• Assumptions & constraints — 1: missing or generic · 2: real, scenario-specific assumptions and constraints listed · 3: honest assumptions that map directly to later risks, plus the triple-constraint reality (fixed date, flex scope) stated explicitly.
• Stakeholder map with tailored engagement — 1: a list, no grid, or one-size-fits-all messaging · 2: every named stakeholder placed on the influence×interest grid with an approach · 3: placement is defensible and each approach is genuinely tailored (right cadence, right message, escalation logic for the sponsor and the PCI/partner blockers).