Project Scope Statement vs Project Charter: Key Differences Explained
Project managers often confuse the project charter with the project scope statement — or worse, they skip one entirely and wonder why scope creep kills their project. Scope creep affects 52% of projects, and projects without clearly defined objectives fail 37% of the time (PMI, 2024). The charter and scope statement are your two best defenses, but they do very different jobs.
This guide breaks down exactly what each document is, when you create it, what goes in it, and how the two work together. If you're unsure which one you need right now, this comparison will clear it up.
Key Takeaways
- The charter authorizes the project (created first, signed by the sponsor). The scope statement defines the deliverables (created during planning, approved by stakeholders)
- A charter is 2-5 pages. A scope statement is 5-15 pages with detailed deliverables and acceptance criteria
- You can't write a good scope statement without an approved charter — the charter defines the boundaries
- Both documents are needed — skipping either one dramatically increases failure risk
What's the Core Difference?
The simplest way to understand it:
Project Charter = "Should we do this project, and who's in charge?" Scope Statement = "What exactly will we build, and how will we know it's done?"
The charter comes first. It's a high-level authorization document that says "yes, this project is approved" and gives the PM authority. The scope statement comes second — it's a detailed planning document that breaks down exactly what the project will deliver.
| Factor | Project Charter | Scope Statement |
|---|---|---|
| Purpose | Authorizes the project's existence | Defines what will be delivered |
| Created when | Initiating phase (before planning) | Planning phase (after charter approval) |
| Created by | PM + Sponsor | PM + Team + Stakeholders |
| Approved by | Executive sponsor (signature required) | Sponsor + key stakeholders |
| Length | 2-5 pages | 5-15 pages |
| Level of detail | High-level (why, what, who) | Detailed (deliverables, criteria, constraints) |
| Changes after approval | Rarely — requires re-authorization | Through formal change control process |
| PMBOK process group | Initiating | Planning |
Think of the charter as the project's birth certificate and the scope statement as its blueprint.
What Goes in a Project Charter?
The charter answers six questions at a high level. It's deliberately brief — detailed answers belong in the scope statement and project plan.
1. Why does this project exist? (Project Purpose) The business problem or opportunity. 2-3 sentences connecting the project to business value.
2. What does success look like? (Objectives) 3-5 measurable SMART criteria. "Achieve 99.95% uptime" not "improve performance."
3. What's the boundary? (High-Level Scope) In-scope and out-of-scope lists at a category level. Not individual deliverables.
4. Who's involved? (Stakeholders) Sponsor, PM, key team leads. Names and roles, not detailed RACI.
5. How much will it cost? (Budget Summary) Total budget with major category breakdown. Not a line-item estimate.
6. When will it be done? (Major Milestones) 4-8 milestone dates. Not a task-level schedule.
For complete charter examples, see our 5 real-world project charter examples or download the free project charter template.
What Goes in a Scope Statement?
The scope statement takes the charter's high-level boundaries and breaks them into specific, measurable deliverables with acceptance criteria. It's the document the team uses every day to decide "is this in scope or not?"
1. Project Scope Description Detailed narrative of what the project will produce. Where the charter says "build a customer portal," the scope statement says "build a web application with 4 modules: invoice viewing, support tickets, order tracking, and account management."
2. Deliverables List Every tangible output with acceptance criteria:
- Invoice Viewing Module — displays all invoices from the past 24 months with PDF download. Accepted when: loads in < 2 seconds, displays correct amounts verified against ERP.
- Support Ticket Module — allows creation, viewing, and commenting. Accepted when: tickets sync with Zendesk within 5 minutes, email notifications sent on status change.
3. Acceptance Criteria How each deliverable will be verified and by whom. This prevents the "that's not what I asked for" conversation at delivery.
4. Exclusions More detailed than the charter's out-of-scope list. Specific features, integrations, or capabilities that will NOT be delivered.
5. Constraints Fixed limitations: budget ceiling, deadline, technology standards, regulatory requirements, team availability.
6. Assumptions Things assumed to be true that, if wrong, would change the scope. "We assume the existing API can handle 500 concurrent users" — if testing shows it can't, scope changes.
7. Work Breakdown Structure (WBS) Hierarchical decomposition of all work into manageable packages. The WBS is often attached to or referenced from the scope statement.
For a WBS template, see our work breakdown structure guide.
Side-by-Side Example: IT Infrastructure Upgrade
Here's how the same project looks in each document:
In the Charter:
Scope: Replace end-of-life network switches, firewalls, and core servers across New York, Chicago, and Austin offices.
Out of scope: End-user devices, application changes, WiFi access points.
Budget: $485,000
Timeline: Jan 15 - Jun 1
In the Scope Statement:
Deliverables:
- Replace 12 Cisco Catalyst 3750 switches with Cisco Catalyst 9300 across 3 offices (4 per office)
- Acceptance: Each switch passes connectivity test for all connected ports, VLAN configuration matches specification document
- Replace 3 Palo Alto PA-3020 firewalls with PA-3260 (1 per office)
- Acceptance: Firewall rules migrated and verified, IPS signatures updated, VPN tunnels re-established
- Upgrade 6 server room UPS units to APC Smart-UPS 3000VA
- Acceptance: 30-minute battery runtime test passed, monitoring agent reporting to Nagios
Exclusions:
- WiFi access points (separate project WFI-2026, starting Q3)
- VoIP phone system upgrade (depends on network completion, separate project)
- Cable re-certification in Austin (cables tested and passed Cat6a spec)
Constraints:
- Migration windows: weekends only, 10PM-6AM
- Maximum 4 hours planned downtime per site
- All hardware from approved vendor list (Dell, Cisco, Palo Alto)
Assumptions:
- Existing cable infrastructure supports 10Gbps (to be verified in discovery)
- Server room power capacity adequate for new UPS units (facilities to confirm by Feb 1)
- Cisco 9300 switches available with 30-day lead time (vendor confirmed Jan 10)
See the difference? The charter sets the boundary ("replace network equipment across 3 offices for $485K"). The scope statement specifies exactly what equipment, with what acceptance criteria, under what constraints.
When Do You Create Each Document?
The sequence matters:
Business Case → Project Charter → Scope Statement → Project Plan → Execution
↑ ↑ ↑ ↑
"Should we "Yes, go "Here's what "Here's how
invest?" ahead." we'll build." we'll build it."
Charter first: Without an approved charter, you shouldn't spend time on detailed scope definition. The charter might get rejected — and all that scoping work is wasted.
Scope statement second: Once the charter is approved and you have authority to plan, engage stakeholders in detailed scope definition. This is where you discover the real requirements behind the charter's high-level statements.
Both are living documents, but with different change tolerances:
- Charter changes require sponsor re-approval (rare)
- Scope changes go through a formal change control process (regular but controlled)
Common Mistakes
Mistake 1: Writing a scope statement instead of a charter. If your "charter" has a WBS, deliverable acceptance criteria, and a 50-row task list, you wrote a scope statement. The sponsor needs a 2-page authorization document, not a planning workbook.
Mistake 2: Skipping the scope statement. Going straight from charter to execution means your team is building against vague requirements. "Replace network equipment" doesn't tell the engineer which switches to order or how to verify the migration worked.
Mistake 3: Making the charter too vague. "Improve IT infrastructure" isn't a charter — it's a thought. The charter needs enough specificity to bound the scope statement. A clear charter makes scope statement writing 3x faster because the boundaries are already set.
Mistake 4: Not getting the charter signed. An unsigned charter is a proposal, not an authorization. If the sponsor won't sign, they're not committed — and an uncommitted sponsor is the #1 predictor of project failure. 67% of projects without engaged sponsors fail (PMI, 2025).
Which Template Should You Use?
We have templates for both:
- Free Project Charter Template — PMBOK-aligned with all 6 sections, ready to customize
- Premium Project Charter Template — adds risk assessment, assumptions log, and stakeholder analysis sections
- Statement of Work Template — for defining scope in client/vendor relationships
- Work Breakdown Structure Template — the deliverable hierarchy that supports your scope statement
For guidance on filling in the charter, see our how to write a project charter guide.
Frequently Asked Questions
Can I combine the charter and scope statement into one document?
For small projects (under $50K, single team, < 3 months), yes — a combined "project brief" with both authorization and detailed scope can work. For anything larger, keep them separate. The charter needs executive sign-off before you invest time in detailed scoping. Combining them delays the authorization decision while you figure out details that might change anyway.
Does Agile use charters and scope statements?
Agile uses a lighter version. The charter becomes a "product vision" or "project brief" (1-2 pages defining the problem, goals, and constraints). The scope statement is replaced by a prioritized product backlog that evolves through sprints. The key principle remains: authorize before planning, plan before building. See our agile project management guide for Agile-specific approaches.
Who approves the scope statement?
The project sponsor approves the scope statement, often with input from key stakeholders. Unlike the charter (which is the sponsor's authorization alone), the scope statement benefits from broader review — the technical lead verifies feasibility, the business owner confirms requirements, and the finance rep confirms the budget supports the deliverables. Get all key stakeholders to sign off or you'll face "that's not what I agreed to" later.
What if scope changes after the scope statement is approved?
Changes go through a formal change control process: the requester submits a change request documenting the change, its impact on timeline and budget, and the rationale. The PM evaluates the impact and presents it to the sponsor (or Change Control Board) for approval. Approved changes update the scope statement and project plan. Never make scope changes verbally — if it's not documented, it didn't happen.
How detailed should the scope statement's WBS be?
The WBS should decompose work into packages of 8-80 hours of effort (the "8/80 rule"). Packages smaller than 8 hours are too granular for scope management — they belong in the task schedule. Packages larger than 80 hours are too vague to estimate or assign. For a typical 6-month project, this usually results in 50-100 work packages organized into 5-8 major deliverables.
What's the difference between a scope statement and a Statement of Work (SOW)?
A scope statement is an internal planning document that defines what the project team will deliver. A Statement of Work is a contractual document between two parties (client/vendor) that defines obligations, payment terms, and acceptance criteria. SOWs are legally binding; scope statements are project management documents. For projects with external vendors, you'll often have both — the internal scope statement plus an SOW for each vendor engagement. See our SOW template guide for more.