Project Charter & Problem Statements
Key Takeaways
- A project charter authorizes and aligns the team on problem, goal, scope, metrics, roles, timeline, and business case—functioning as a short contract with the Champion.
- Strong problem statements state what is wrong, where/when, baseline performance with units, and impact—without embedding root causes or preselected solutions.
- Goal statements are SMART targets on the same primary Y used in the problem statement, with a clear deadline and often a sustain period.
- Charter elements typically include business case, problem, goal, scope, primary and consequential metrics, team/roles, milestones, stakeholders, and constraints.
- Update the charter formally when baseline, scope, or goals change; silent scope creep and solution-jumping are common Define failures.
Project Charter & Problem Statements
Quick Answer: A project charter is the one-page (or short) contract among Champion, process owner, and team that states the problem, goals, scope, metrics, team, and timeline. A strong problem statement includes what is wrong, where/when it occurs, the baseline performance, and the business or customer impact—without naming the solution.
Why the Charter Exists (BoK II.C.2)
ASQ expects Green Belts to apply charter and problem-statement skills because vague launches produce scope creep, political thrash, and unfinished projects. The charter is not bureaucratic wallpaper. It is the authorization and alignment document that:
- Confirms leadership wants this work now
- Defines success in measurable terms
- Bounds what is in and out of scope
- Names who owns decisions vs. who does analysis
- Creates a baseline against which Control will prove results
Without a signed (or formally approved) charter, teams often “start measuring” only to discover later that the Champion wanted a different Y, a different product family, or a pre-chosen solution.
Core Elements of a Project Charter
Exact templates vary by company, but CSSGB-level charters consistently include these elements:
| Element | Purpose | Quality test |
|---|---|---|
| Business case / opportunity | Why the organization should care (strategy, CoPQ, risk, VOC) | Ties to a real enterprise priority |
| Problem statement | Neutral description of the gap with baseline data | No solution embedded; data present |
| Goal statement | Target performance and timeframe (SMART) | Measurable, time-bound, linked to Y |
| Scope | In / out boundaries (process, product, site, customer segment) | Start/stop points clear |
| Primary metric (Y) | The defect, cycle time, cost, or satisfaction measure to move | Operational definition exists or planned |
| Consequential metrics | What must not get worse | Guardrails listed with baselines |
| Team & roles | Champion, Black Belt coach, Green Belt, process owner, SMEs | RACI-ready names, not only titles |
| Timeline / milestones | Target tollgate dates and expected duration | Realistic for Green Belt capacity |
| Stakeholders | Who is affected or must support | Communication needs implied |
| Assumptions & constraints | Budget, systems, freeze windows, policy limits | Risks of false assumptions noted |
| High-level plan | DMAIC phase outline or key deliverables | Not a 200-line WBS yet |
Some templates also include estimated financial benefit, SIPOC summary, and risk highlights. Keep the charter short enough to read in a tollgate—detail lives in supporting project documents.
Writing a Strong Problem Statement
A problem statement describes the current undesirable condition with enough evidence that a stranger could understand the pain. Use this pattern:
From [start date/period] to [end date/period], [process/product] at [location/segment] has experienced [defect or performance issue] at a rate of [baseline metric with unit], resulting in [customer, safety, compliance, or financial impact]. The gap versus [target/specification/benchmark] is [size of gap].
Include
- What is failing (defect type, delay, cost, complaint theme)
- Where / which process (line, product family, channel, region)
- When / how often (time window, trend direction)
- Baseline data (rate, mean, DPMO, cycle time, $ CoPQ)
- Impact (customer, regulatory, financial, employee)
Exclude (or move elsewhere)
- Root causes (“because training is bad…”)
- Solutions (“we will buy software X…”)
- Blame of individuals
- Multiple unrelated problems jammed into one sentence
Weak vs. strong examples
| Weak | Stronger |
|---|---|
| “Shipping is broken and we need a new WMS.” | “In Q1–Q2 2026, finished-goods ship confirmation for Product Family A averaged 92.1% on-time (customer dock date), versus a contractual 98% OTIF, generating 186 expedites and ~$94k premium freight.” |
| “Customers are unhappy.” | “From Jan–Mar 2026, Product Support Tier-1 first-contact resolution for Plan Renewals was 61% (baseline n=4,120 tickets) against a target of 80%, driving a 12-point drop in post-contact CSAT.” |
| “Defects are too high because operators rush.” | “Paint Line 3 first-pass yield for SKU class M was 88.4% over 12 weeks (target ≥96%), producing 1,420 rework hours and three late OEM shipments.” |
Notice the strong versions give baseline numbers and impact without prescribing the Improve solution.
Goal Statements That Match the Problem
The goal statement converts the problem into a SMART target:
- Specific — Same Y as the problem statement
- Measurable — Numeric target and operational definition
- Achievable — Credible given time, authority, and method
- Relevant — Linked to business case and CTQ
- Time-bound — By when (and sometimes for how long sustained)
Example goal: “Increase Paint Line 3 first-pass yield for SKU class M from 88.4% to ≥96% by 30 November 2026, sustained for four consecutive weeks under the Control plan, without increasing scrap cost per unit or OSHA recordable rate.”
Goals should not secretly change the metric midstream (“we’ll track operator morale instead of FPY”) without a charter revision.
Problem Statement + Goal + Scope Alignment
These three must tell one story:
- Problem: baseline bad performance on Y
- Goal: improved target on the same Y
- Scope: the process portion that can move Y without boiling the ocean
If the problem is enterprise-wide OTIF but scope is only one packing cell, either narrow the problem statement to that cell’s contribution or widen scope/resources. Misalignment is a classic tollgate failure.
Charter as a Living Contract
Approve the charter in Define, then update formally when facts change: new baseline after MSA, scope cut after Pareto analysis, or goal reset after capability discovery. Silent edits destroy trust. Version the document and record Champion approval of material changes.
Common Charter Defects
- Solution-disguised problem — “Implement 5S” is a solution, not a problem
- No baseline — “Defects are high” without rate, period, or sample
- Multiple Ys with no primary — Team cannot prioritize trade-offs
- Scope = “everything quality-related” — Unfinishable
- Missing consequential metrics — Primary improves while safety or cost collapses
- Champion name without engagement — Rubber-stamp sponsorship
- Unrealistic timeline — Full MSA + DOE + validation in three weeks
Green Belt Charter Checklist
- Problem statement has baseline data, location/time, and impact
- Goal is SMART on the same primary metric
- Scope has start/stop and explicit outs
- Primary and consequential metrics listed
- Roles named; Champion committed
- Timeline matches Green Belt capacity
- No solution locked in before Analyze (unless a pure just-do-it was mis-chartered as DMAIC)
When a stranger can read your charter and know what success looks like—and what is out of bounds—you are operating at the Apply level for BoK II.C.2.
Which problem statement best meets Green Belt expectations for baseline data and neutrality?
A charter lists a goal to “reduce customer complaints” but the problem statement baselines on-time delivery at 91% versus 98%. What is the main defect?