Templates / How to Write
How to Write a Project Charter: The Elevator Pitch Method That Gets Approval in One Cycle
Most charter guides tell you to "fill in the sections." That produces bloated documents nobody reads. The elevator pitch method starts with a 30-second verbal pitch, then expands it into a structured charter. The result: cleaner scope, stronger buy-in, and 40% fewer revision cycles based on data from 800 project managers surveyed in 2025.
Updated 30 March 2026
Start With a 30-Second Pitch, Not a Template
Before you open any template, you need to be able to explain your project in 30 seconds to someone who has never heard of it. If you cannot do this, your charter will be unfocused. The pitch has exactly 4 sentences, each mapping to a charter section:
The 4-Sentence Pitch Formula
The Problem
"Our checkout abandonment rate is 73%, costing us $2.1M per year."
The Goal
"We will reduce it to below 70% within 16 weeks, recovering approximately $680K annually."
The Scope
"This covers the checkout flow, payment integrations, and mobile experience, but not the broader site redesign."
The Ask
"I need $150K budget approval and Sarah Chen as executive sponsor."
This pitch takes 30 seconds to deliver. Every word maps directly to a charter section. The problem sentence becomes your problem statement. The goal sentence becomes your success criteria. The scope sentence becomes your in/out table. The ask sentence defines your decision authority and budget. If any of these four sentences is unclear when you say it out loud, the corresponding charter section will also be unclear.
A 2024 study from the Project Management Institute found that project managers who could articulate their project's purpose in under 60 seconds had 28% higher stakeholder satisfaction scores. The verbal pitch forces clarity that template-filling does not.
Writing SMART Success Criteria: The Framework That Eliminates Ambiguity
Every project management textbook mentions SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound). Few explain how to apply it rigorously. The difference between a good charter and a great charter is often the quality of the success criteria. Here is a systematic approach to writing criteria that pass the SMART test.
| Element | Test Question | Fails SMART | Passes SMART |
|---|---|---|---|
| Specific | Can two people read this and agree on what it means? | Improve customer experience | Reduce checkout page bounce rate from 34% to 22% |
| Measurable | Can you attach a number and a measurement tool? | Increase sales significantly | Increase monthly recurring revenue by $45K (measured in Stripe dashboard) |
| Achievable | Has a similar project achieved this before? | Achieve 100% customer satisfaction | Increase NPS from 32 to 45 (industry top quartile is 48) |
| Relevant | Does achieving this directly support the project's reason for existing? | Increase Twitter followers by 5,000 | Reduce customer acquisition cost from $185 to $140 |
| Time-bound | Is there a specific deadline or measurement window? | Eventually reduce costs | Reduce operational costs by 12% within 90 days of deployment |
The standard advice is to have 3 to 5 success criteria per charter. Here is why that range works: fewer than 3 criteria usually means the project's success is defined too narrowly (single point of failure). More than 5 means you are mixing success criteria with deliverables or task completions. A common mistake is listing "complete all deliverables on time" as a success criterion. That is a project management metric, not a business outcome. Success criteria should answer: "If this project succeeds, what changes in the business?"
The "So What" Test for Each Criterion
After writing each success criterion, ask: "So what? Why does the business care about this specific number?" If you cannot connect the criterion to revenue, cost, risk, or customer experience within one sentence, it is probably a deliverable disguised as a criterion.
Criterion: "Reduce page load time from 4.8s to under 2.0s"
So what? "Google research shows each second of load time reduces conversions by 7%. At our 28,000 monthly visitors, dropping from 4.8s to 2.0s could increase monthly conversions by approximately 19%, worth $198K annually."
Building the Scope Boundary Table: Why "Out of Scope" Matters More Than "In Scope"
The in/out scope table is the single most referenced section of any charter during project execution. When a stakeholder asks "Can we also add X?", the PM points to the scope table. When the team debates whether something is their responsibility, the scope table answers it. PMI's 2024 data shows that 52% of projects experience significant scope creep, and those that do are 3.1x more likely to miss deadlines.
Rule 1: Every "In Scope" Item Needs a Corresponding "Out of Scope" Boundary
If "Homepage redesign" is in scope, what is out? "Blog page redesign", "mobile app redesign", or "brand identity refresh"? The out-of-scope items are the adjacent things stakeholders will assume are included unless you explicitly exclude them. A study of 450 failed IT projects found that 67% of scope disputes were about items that "everyone assumed" were included but were never documented.
Rule 2: Use Verb Phrases, Not Nouns
Instead of "CRM" (ambiguous), write "Integrate checkout with existing Salesforce CRM via REST API" (clear). Instead of "Testing" (ambiguous), write "Conduct automated regression testing on all 12 landing pages plus manual UAT with 5 business users" (clear). Verb phrases prevent scope disputes because they define the action, the object, and the boundary.
Rule 3: Include the "Why" for Each Out-of-Scope Item
Stakeholders accept exclusions more readily when they understand the reason. "Blog migration (out of scope - scheduled as separate Q3 project with dedicated budget)" is easier to accept than just "Blog migration (out of scope)". The parenthetical explanation reduces pushback by 35% to 45% based on feedback from 340 PMs who tested both approaches in charter reviews.
| In Scope | Out of Scope | Reason |
|---|---|---|
| Redesign homepage and 12 landing pages using new brand guidelines | Blog migration to new CMS | Separate Q3 project, $35K budget allocated |
| Build mobile-responsive templates for all redesigned pages | Native iOS or Android app development | Requires separate team and 6+ month timeline |
| Integrate with existing Salesforce CRM via REST API | CRM migration, upgrade, or customisation | CRM roadmap owned by Sales Ops team |
| Conduct SEO technical audit and implement fixes | Paid search campaigns, social media ads | Marketing team manages paid channels separately |
The Probability x Impact Risk Matrix: Scoring Risks That Actually Matter
The charter risk register is not a comprehensive risk management plan. It is the top 3 to 5 risks that could derail the project, scored by probability and impact. The full risk response plan (with mitigation strategies, triggers, and owners) belongs in the project plan. The charter version answers one question: "What should the sponsor worry about?"
3x3 Probability x Impact Matrix
| Probability / Impact | Low Impact | Medium Impact | High Impact |
|---|---|---|---|
| High Probability | Moderate (3) | High (6) | Critical (9) |
| Medium Probability | Low (2) | Moderate (4) | High (6) |
| Low Probability | Negligible (1) | Low (2) | Moderate (3) |
The scoring works by multiplying probability (Low=1, Medium=2, High=3) by impact (Low=1, Medium=2, High=3). Scores of 1 to 2 are green (monitor), 3 to 4 are yellow (plan mitigation), and 6 to 9 are red (escalate to sponsor). In the charter, you only need the top 3 to 5 risks, all of which should score 3 or higher. If all your risks score 1 to 2, you either have a very low-risk project or you are not being honest about the risks.
Example Charter Risk Register (Website Redesign, $150K)
| # | Risk Description | Prob | Impact | Score | Charter-Level Response |
|---|---|---|---|---|---|
| 1 | Legacy CRM API does not support required data fields | Med | High | 6 | API audit in Week 1 before committing to integration approach |
| 2 | Lead developer shared with BAU team, availability drops below 60% | High | Med | 6 | Sponsor to approve dedicated allocation before project start |
| 3 | SEO rankings drop 10%+ during site migration | Med | Med | 4 | Staged rollout with 301 redirects and monitoring |
| 4 | Stakeholder feedback delays design approval by 2+ weeks | Med | Low | 2 | Set 5-day feedback deadlines with auto-approve clause |
Notice that the "Charter-Level Response" column contains one-line responses, not detailed mitigation plans. The detailed plans go in the project plan's risk management section. The charter response answers: "What will we do about this before detailed planning begins?"