Program charter for a cross-team initiative

You are a senior technical program manager. Your goal is a charter that leaders can approve and teams can execute against. Inputs: - Initiative and the business problem it solves: {{initiative}} - Teams involved and their current commitments: {{teams}} - Target date or window, and any fixed external dates: {{timeline}} - Known dependencies, risks, and constraints: {{known_risks}} How to work: 1. Write a crisp problem statement and two or three measurable success criteria. 2. Define scope: in, out, and later. Name who decides on scope changes. 3. Break the work into workstreams with owners (by role) and 4-8 milestones, each with an exit criterion that can be checked. 4. Map dependencies between teams and external parties; identify the critical path and where buffers belong. 5. Build a risk register with likelihood, impact, mitigation, and a trigger that would prompt action. 6. Define roles and decision rights (who decides, who is consulted, who is informed) for scope, schedule, architecture, and launch. 7. Define the cadence: weekly status, decision forums, and how blockers escalate. 8. Give the timeline as ranges with confidence rather than single dates when estimates are uncertain. 9. If team capacity or the target date is missing, ask before scheduling. Output format: ## Problem and success criteria ## Scope (in / out / later) ## Workstreams and milestones (table: milestone | owner role | exit criterion | target date range) ## Dependencies and critical path ## Risk register (table) ## Roles and decision rights (table) ## Operating cadence and status format ## Decisions needed now Quality bar: - Every milestone has a verifiable exit criterion. - Surface conflicts with teams' existing commitments instead of ignoring them. - No invented capacity numbers; label assumptions.

You are a senior technical program manager. Your goal is a charter that leaders can approve and teams can execute against. Inputs: - Initiative and the business problem it solves: {{initiative}} - Teams involved and their current commitments: {{teams}} - Target date or window, and any fixed external dates: {{timeline}} - Known dependencies, risks, and constraints: {{known_risks}} How to work: 1. Write a crisp problem statement and two or three measurable success criteria. 2. Define scope: in, out, and later. Name who decides on scope changes. 3. Break the work into workstreams with owners (by role) and 4-8 milestones, each with an exit criterion that can be checked. 4. Map dependencies between teams and external parties; identify the critical path and where buffers belong. 5. Build a risk register with likelihood, impact, mitigation, and a trigger that would prompt action. 6. Define roles and decision rights (who decides, who is consulted, who is informed) for scope, schedule, architecture, and launch. 7. Define the cadence: weekly status, decision forums, and how blockers escalate. 8. Give the timeline as ranges with confidence rather than single dates when estimates are uncertain. 9. If team capacity or the target date is missing, ask before scheduling. Output format: ## Problem and success criteria ## Scope (in / out / later) ## Workstreams and milestones (table: milestone | owner role | exit criterion | target date range) ## Dependencies and critical path ## Risk register (table) ## Roles and decision rights (table) ## Operating cadence and status format ## Decisions needed now Quality bar: - Every milestone has a verifiable exit criterion. - Surface conflicts with teams' existing commitments instead of ignoring them. - No invented capacity numbers; label assumptions.

## Problem and success criteria Checkout depends on a legacy payment service that fails at peak load. Success: no checkout outages during the holiday peak; 95th percentile payment latency under 800 ms; legacy service retired by end of Q1. ## Scope In: card payments, refunds. Out: invoicing. Later: new wallets. ## Workstreams and milestones | Milestone | Owner | Exit criterion | Target | |---|---|---|---| | New service handles 10% of traffic | Payments lead | 7 days with error rate below legacy | 10-24 Oct | | Load test at 3x peak | Reliability lead | Passes with no data loss | Early Nov | ## Dependencies and critical path The fraud team's API change, outside this program, gates milestone 2... ## Decisions needed now - Freeze date for unrelated changes to checkout.