A project charter is a short document that says what a project will do, why it matters, and what is in and out of bounds. It is the agreement between the team and its sponsor, and the reference point that keeps the project on track.
This guide covers the eight elements of a charter, how to write a problem statement that leaves the cause open, how to set a measurable goal, and a worked example that turns a scrap problem into a signed charter with a financial case.
Why a Charter Matters
Agrees the Target Before the Work
A charter forces the team and sponsor to agree on the problem, the goal, and the boundaries before anyone starts collecting data.
Prevents Scope Creep
A written scope with an explicit out-of-scope list gives the team something to point to when new requests arrive.
Secures Resources and Support
A signed charter commits the sponsor to give the team time, access, and help removing barriers.
Provides a Reference for Review
At each phase gate the charter is the yardstick for whether the project is on track and still worth doing.
The Elements of a Charter
| Element | What it should contain | Test of a good one |
|---|---|---|
| Problem statement | What is wrong, where, since when, how big, and the impact in numbers | It states a gap, and contains no cause or solution. |
| Goal statement | The measure, the baseline, the target, and the date | It is specific, measurable, achievable, relevant, and time-bound. |
| Business case | Why this matters now, tied to a business objective, with estimated benefit | A leader can see why to fund it. |
| Scope | The process boundaries (start and end), and what is excluded | It could settle an argument about whether a request belongs. |
| Timeline | Milestones by phase, such as DMAIC | It has dates, and the sponsor reviews at each gate. |
| Team and roles | Sponsor, project leader, members, subject experts, and time committed | Each person has a named role and agreed time. |
| Stakeholders | Who is affected, and how they will be involved | Key groups are identified early. See the Stakeholder Analysis Builder. |
| Risks and assumptions | What could stop the project, and what is assumed | Each risk has an owner and a response. |
Writing a Good Problem Statement
A good problem statement describes a gap between current and desired performance and leaves the cause open. It answers what, where, when, and how much.
| Example | |
|---|---|
| Weak | "We need a new fixture on Line 4 because operators keep scratching parts." (It contains a solution and a cause.) |
| Better | "Since April, 4.8% of units on Line 4 are scrapped for cosmetic damage, against a 2.0% target, costing about $179,000 a year." |
If you already know the solution, you probably do not have a project charter; you have an action item. Charter work when the cause is unknown and the answer needs analysis.
Worked Example: A Scrap Reduction Charter
A plant chartered a project to cut scrap on Line 4. The figures are illustrative.
| Element | Entry |
|---|---|
| Problem statement | Since April, 4.8% of the 1,200,000 units built each year on Line 4 are scrapped for cosmetic damage. |
| Baseline cost | 1,200,000 × 4.8% = 57,600 scrapped units. At $3.10 per unit, that is $178,560 per year. |
| Goal statement | Reduce cosmetic scrap on Line 4 from 4.8% to 2.4% or lower by December 31. |
| Business case | At 2.4%, scrap falls to 28,800 units, saving 28,800 × $3.10 = $89,280 per year. The line is also the one with the longest customer backlog. |
| Scope in | Assembly and pack-out steps on Line 4. |
| Scope out | Upstream molding, and other lines. |
| Team | Sponsor: plant manager. Leader: quality engineer. Members: two operators, a maintenance technician, and a supervisor (about 4 hours per week each). |
| Balancing measure | Throughput must not fall, and no increase in customer returns. |
The goal statement halves the scrap rate, a big improvement that is still reachable, and the savings depend on the scrap rate falling as planned. Note what the charter does not say: it does not name a fixture, a training program, or a supplier. Those come from the analysis. When the team's data show that most scratches occur at one transfer point, the charter's scope already covers it, and the sponsor sees at each gate whether the savings are on track.
The DMAIC Project Files workbook carries a charter tab, and the Kaizen Event Charter Template covers short events. Rank candidate projects first with the Project Prioritization Matrix.
From Idea to Approved Charter
A charter is the output of a short negotiation, not a form to fill in alone. The path from a vague problem to an approved charter usually has a few stages, and skipping them is a common reason projects drift.
Get the facts first. Before drafting, collect enough data to state the problem in numbers: how often, how large, since when, and what it costs. A charter built on anecdote is likely to be argued about later.
Test the charter with the people who will live with it. The sponsor should confirm that the project matters and commit the people and time. The process owner should confirm that the scope is workable. Team members should say whether the timeline is realistic. Each conversation usually changes something.
Narrow the scope. A scope that is too wide is the most common fault. Define start and end points of the process, name what is outside, and choose a problem that can be solved in a few months. Large problems can be split into several projects.
Set the goal using a baseline. A goal such as “reduce scrap from 4.8% to 3.0% by June” can be checked. “Improve quality” cannot.
Reviewing a Charter and Keeping It Alive
A review checklist helps the sponsor and the project leader to spot weak charters before work starts. A charter that answers these questions is likely to be useful.
| Question | Good answer looks like |
|---|---|
| Is the problem stated in numbers, without a solution in it? | Baseline, size, and time frame are given; no assumed cause |
| Is the scope clear? | Process start and end, and explicit exclusions |
| Is the goal measurable and dated? | Metric, baseline, target, and date |
| Is the business case credible? | Benefit estimate with its basis; finance has reviewed it |
| Are roles and time committed? | Sponsor, leader, and members named, with time agreed by their managers |
| Are risks and constraints named? | A short list with owners |
A charter is a living agreement. Revisit it at gate reviews. If data show that the real problem is elsewhere, change the scope by agreement and record the change, rather than letting the project drift. Keep the approved version and each revision, so that the reasons for changes are clear later.
Common faults: a solution disguised as a problem (“install a new machine”), an unbounded scope, a goal with no baseline, a benefit number no one has checked, and team members who did not agree to the time. See the DMAIC Roadmap for how the charter feeds the Define phase, and the Kaizen Event Charter Template for a shorter format.
Self-Assessment Questions
- Does the problem statement describe a measurable gap with no cause or solution?
- Does the goal have a baseline, a target, and a date?
- Is the scope written down, including what is excluded?
- Has the sponsor signed, and committed the team's time?
- Do we revisit the charter at each phase gate, and change it only in writing?
Common Mistakes
Solution in the Problem Statement
Naming the fix before the analysis locks the team into an answer and skips root cause.
A Goal Without a Baseline
"Improve quality" cannot be checked. State the current number, the target, and the date.
Unlimited Scope
Trying to fix an entire plant in one project ensures none of it is fixed. Bound the process and say what is out.
Charter Filed and Forgotten
If the charter is not used at reviews, it is paperwork. Use it as the yardstick at every gate.
Project Charter: Frequently Asked Questions
What is a project charter?
A project charter is a one-page document, agreed with the sponsor before work begins, that states the problem, the goal, the business case, the scope, the timeline, the team and roles, the stakeholders, and the risks. It authorizes the project and serves as the reference for reviews.
What makes a good problem statement?
A good problem statement describes a measurable gap between current and desired performance, including what, where, when, and how much it costs, and it contains neither a cause nor a solution. That leaves the team free to find the root cause through analysis.
How is a project charter different from a project plan?
A charter defines why and what, and asks for authorization and resources. A project plan defines how and when, with detailed tasks and schedules. The charter is short and stable, while the plan is more detailed and changes as the work proceeds.
Sources and Further Reading
- ASQ Certified Six Sigma Black Belt Body of Knowledge, project definition and charter.
- Thomas Pyzdek and Paul Keller, The Six Sigma Handbook.
- Project Management Institute, A Guide to the Project Management Body of Knowledge, on the project charter.
- Forrest W. Breyfogle III, Implementing Six Sigma.