01 · Purpose and suitability
What the charter must achieve
A project charter establishes a shared agreement about an improvement project. It connects a performance problem with a reason to investigate it, defines the intended outcome, and gives the team a mandate to use agreed resources. In DMAIC, this happens before the causes have been verified and before a solution has been selected. The charter therefore authorises a disciplined investigation and subsequent improvement within agreed boundaries.
Its practical test is whether people can use it to make decisions. If an additional product group is suggested, does the charter tell the team whether it is included? If an experiment requires extra staff time, who can approve that? If the baseline proves unreliable, what happens to the target? A document that describes an ambition but cannot answer these questions is not yet a useful working charter.
Use a DMAIC charter when an existing process has a material performance gap and the explanation or appropriate change needs investigation. If a known procedure simply needs executing, a straightforward implementation plan may be more suitable. If the process does not yet exist, consider a design approach. Agree the nature of the work before placing it into DMAIC.
Depth is not a page count
A charter may be concise when the decisions are simple and supporting evidence is readily available. More complex projects require more explanation. Keep the agreement understandable, reference supporting records, and include the reasoning needed to resolve uncertainty. The developed example below is deliberately substantial so that readers can see what each entry establishes.
02 · Preparation
Build the agreement from evidence and discussion
Start by speaking with the process owner, people doing the work, customer-facing staff and the sponsor. Bring existing performance records, examples of affected cases, the relevant service requirements and any operating constraints. Ask how each record was produced: a field called “dispatch date” might mean printing a label rather than handing goods to a carrier.
Separate information into three groups: observations supported by records, assumptions needing confirmation, and unanswered questions. Define does not require a completed statistical investigation. It requires enough credible evidence to justify the project, with the limits of that evidence visible. Measure will establish the dependable baseline.
The leader can draft the document, but should not privately decide everyone’s commitments. The process owner checks the operational boundaries and future ownership; team representatives check what is workable; the sponsor confirms the mandate, authority and resources. Approval must mean agreement to those commitments, not simply acknowledgement that the document was received.
03 · Problem statement
Describe the gap without inventing its cause
A problem statement identifies the process, the affected output, the gap, the period and the evidence. Start with what is observable. “Orders are late” leaves the reader unable to tell which orders, late against what commitment, or how often. Add an operational definition and a denominator so the result can be checked.
Do not put an unverified explanation into the statement. “Poor staff motivation causes late orders” introduces a causal claim and directs attention towards people before investigation. “Install a new scanner” prescribes a solution. Either may become a hypothesis or proposal later, but neither establishes the performance problem.
| Entry | Why it is weak or useful |
|---|---|
| Improve warehouse efficiency. | No defined gap, measure, population or period. Different stakeholders could interpret success differently. |
| Picking staff are too slow, so introduce automation. | Assumes a cause and solution; does not establish the effect on the customer output. |
| In a preliminary four-week review, 180 of 1,000 eligible standard stocked orders were handed to the carrier after the promised dispatch date. The resulting known-case late-dispatch rate is 18%. Timestamp meaning, exclusions and coverage will be validated in Measure. | Identifies a measurable gap and evidence status while leaving the causal question open. |
Clarify where an apparent gap comes from. A missed contractual requirement, a customer complaint, a comparison with an agreed internal target and a comparison with another site are different forms of evidence. A benchmark can support a question; it does not automatically establish that the same target is appropriate for your process.
04 · Justification
Explain why the gap deserves attention
The business case connects the problem with its consequences. Consider customer disruption, additional coordination, avoidable cost, capacity, risk and strategic priorities. Explain the connection: late dispatch may cause enquiries and replanning, but the number of late orders does not establish the cost of those consequences by itself.
Show how estimates are constructed. State the volume, assumed change, unit effect and time basis. Identify what is confirmed and what needs checking. Distinguish an actual reduction in spending from time released for other work. A team can free 100 staff hours without changing payroll, so the two outcomes must not be described as the same cash saving.
Do not count the same effect twice. If a labour-cost estimate values the released hours, do not add those hours again as an independent financial saving. Record non-financial benefits in their own measures rather than forcing every benefit into euros. A safety or service requirement may justify a project even when a credible return-on-investment calculation is unavailable.
05 · Objectives and acceptance
Define success that can be assessed
A goal statement names the performance measure, desired level, population and completion time. It specifies an outcome rather than the activity used to pursue it. “Train all staff” can be a deliverable, but the training is not evidence that dispatch reliability improved. “Reduce late dispatch to no more than 8%” describes an outcome; it still needs the denominator, period and measurement rules.
Justify the proposed target. Use the customer need, business priority, comparison evidence, operating constraints and preliminary feasibility discussion. In Define, the exact achievable improvement may remain uncertain. Describe the target as provisional where necessary and specify the review at which it will be confirmed. Do not promise feasibility simply because a sponsor would like the result.
Agree guardrails so the team cannot improve the headline measure by creating another problem. A timeliness project may need to protect accuracy, staff workload and customer promises. Moving the promised date later could make dispatch look more reliable without improving service; changing that date-setting rule must therefore be visible and controlled.
Acceptance requires more than one good day. State the observation window, coverage, guardrail checks and handover evidence. An operational acceptance window is a management agreement, not automatic statistical proof of stability. Select the monitoring approach appropriate to the process and distinguish the accepted result from the uncertainty in longer-term predictions.
06 · Boundaries
Choose a scope that can deliver the goal
Define the start and end events, locations, products, customer groups and working periods included. Use events that a person can recognise in a real case. “Warehouse operations” is a department label; “released order to completed carrier handover” is a process boundary. Include all shifts relevant to the claimed outcome, rather than allowing one convenient shift to represent the whole warehouse.
State exclusions and the interfaces they create. Excluding supplier-performance improvement does not make supplier availability irrelevant. The team can record an upstream condition and examine how it affects the scoped process while recognising that changing supplier agreements requires another owner and mandate.
Test the boundary against the goal. If the project covers packing but most delay occurs before release, improving packing alone may not deliver an end-to-end result. Broaden the scope with approval, change the outcome to match the boundary, or separate the work into staged projects. Avoid silently keeping an impossible goal with a convenient scope.
07 · Mandate and resources
Make responsibility and authority usable
Define the sponsor, process owner, project leader and contributing roles. The sponsor provides organisational support and decisions beyond the team’s authority. The process owner accepts the improved operating process. The leader coordinates the investigation and delivery. Subject-matter contributors supply knowledge, observations and analysis. One person may hold more than one role, but the different responsibilities still need to be explicit.
Specify what the leader may authorise and what must be escalated. Permission to organise observations does not imply permission to change customer commitments, buy equipment or alter shift staffing. Name the approval route for spending, operational trials and changes to scope or targets.
Agree availability rather than simply naming people. A team member assigned for two hours per week cannot deliver a task needing ten hours next week without a further arrangement. Record high-level effort, access needs, cash limits and who confirms capacity. Detailed work packages and scheduling belong in the project plan; the charter needs enough detail to establish a credible commitment.
08 · Uncertainty and review
Distinguish assumptions, constraints and risks
An assumption is something treated as provisionally true for planning, such as availability of usable handover timestamps. A constraint is a limit the project must respect, such as no unapproved overtime. A risk is an uncertain event or condition that could affect the outcome, such as missing records preventing a representative baseline. A confirmed access refusal is an issue, not merely a risk.
Give important assumptions a validation action and review point. “Data will be available” is too vague: identify the fields, source owner, validation sample and date. For major risks, name an owner and response. Do not use the charter as a substitute for a maintained risk register; summarise the uncertainties that affect approval.
Use phase reviews as evidence-based decisions. The first review checks the mandate and collection approach; Measure checks baseline reliability; Analyze checks support for causes; Improve checks tested effects; Control checks operational ownership and follow-up arrangements. A deadline does not make missing evidence sufficient.
09 · Developed example
A complete fictional project charter
The following is an original teaching example. The organisation, records, requirements, authorisations and financial assumptions are fictional. They demonstrate how the entries work together; they are not universal targets or a report of actual approval.
Charter · Version 1.0 · Define
Reliable dispatch of standard stocked orders
1. Background and customer need
The main warehouse supplies stocked spare parts to customers planning repair and maintenance work. Once an order is accepted, customer service communicates a promised dispatch date. Customers use this commitment to coordinate receiving and subsequent work. Recent enquiries suggest that dispatch information is not sufficiently predictable. This project addresses the warehouse’s delivery of that commitment; it does not assume that customer delivery and warehouse dispatch are equivalent events.
2. Problem and initial evidence
A preliminary review of four consecutive operating weeks identified 1,000 standard stocked orders with a recorded promised dispatch date and handover date. Of those orders, 180 were handed to the carrier after the promised dispatch date, giving a known-case late-dispatch rate of 18%. This is the provisional baseline. The analyst will verify whether the handover field represents physical carrier acceptance, whether split shipments are treated consistently, and whether missing or excluded orders change the result. The review has not established the causes of late dispatch.
3. Justification and benefit assumptions
The gap affects reliability of customer information and creates additional enquiry and replanning work. Its monetary effect is not yet confirmed. For initial planning, assume that each avoided late order prevents 12 minutes of additional administrative work. Reducing late orders from 180 to 80 per 1,000 orders would avoid 100 late cases and release 20 hours per comparable four-week period. At unchanged volume over thirteen such periods, the scenario releases 260 hours per year. At an illustrative internal value of €30 per hour, that represents €7,800 of capacity value, not a demonstrated cash saving.
Measure will validate the underlying volume and administrative effort. Finance and the process owner will confirm how released capacity would be used and whether any expenditure would actually fall. Customer reliability will be reported independently of the financial estimate. Benefits must not be claimed twice through both hours and their monetary valuation.
4. Improvement objective and guardrails
By the end of week 12, reduce the proportion of eligible standard stocked orders handed over after the promised dispatch date to no more than 8%. The target is an initial improvement ambition to be confirmed after validation of the baseline and feasibility review. Any approved revision will retain the original target, explain the evidence behind the change and record sponsor agreement.
The measurement uses one eligible order as its unit. For orders requiring complete dispatch, the final shipment handover determines the result; this rule will be confirmed with customer service. Missing handover dates will be shown separately, not counted as on-time cases. Do not obtain improvement by changing the promised-date rule without approval. Maintain or improve the independently verified order-accuracy baseline and do not introduce unapproved overtime.
5. Scope and interfaces
The project begins when a standard stocked order is released to the warehouse and ends at completed carrier handover at the main site. It includes both operating shifts and the picking, checking, packing and handover activities within that boundary. The population excludes custom assemblies and orders handled solely at the regional depot. Eligibility and exception codes will be agreed before baseline collection.
Order entry before release, supplier-contract changes and carrier transport after handover are outside the change mandate. These interfaces remain relevant: sales confirms the promised-date rules, planning explains stock conditions at release, and transport coordination confirms collection arrangements. If a verified cause requires a change outside this boundary, the leader will request an approved scope extension or a separate improvement project rather than act without authority.
6. Deliverables and acceptance
The team will deliver a validated baseline and measurement definitions, evidence supporting the selected causes, results from tested changes, and an operating control arrangement with standards, measures, response actions and named ownership. Activity completion alone will not constitute acceptance.
The process owner will evaluate the outcome over four consecutive operating weeks under the agreed post-change conditions, with at least 200 eligible orders in each week. Report each week’s counts and rate as well as the pooled rate, product and shift coverage, missing records and accuracy and overtime guardrails. The agreed pooled late-dispatch target is no more than 8%. Time-ordered monitoring will also be examined; four weekly percentages alone do not establish statistical stability. If the observation window or coverage is inadequate, extend verification and revise the completion forecast.
7. Roles, authority and resource commitment
The operations manager sponsors the project, approves changes to scope, target, spending and operating rules, and accepts responsibility as process owner. The improvement leader coordinates the work and may arrange observations, facilitate analysis and propose tests. The leader may not change customer promises, authorise additional staffing or purchase equipment independently.
The sponsor provisionally assigns up to 80 total staff hours across the leader, analyst, shift representatives and customer-service contributor, subject to a weekly availability agreement with their managers. Direct project spending is capped at €1,000 with sponsor approval of each purchase. Internal effort is valued at €2,400 using a €30 hourly planning rate, giving an initial resource-cost view of €3,400 including the direct-spend limit. These are separate views of capacity and cash; the team must report both actual use and remaining commitments.
8. Milestones and decision points
Week 1 confirms the charter, scope and draft definitions. Weeks 2–3 establish the validated baseline. Weeks 4–5 investigate and verify cause explanations. Weeks 6–8 select and pilot changes, with a documented operational risk review before testing. Weeks 9–12 establish the agreed follow-up window, confirm the effect and prepare handover. The sequence is a planning assumption; phase progression depends on sufficient evidence, and dates will be revised openly when investigations require more work.
9. Assumptions, constraints and risks
The initial plan assumes that order-event records can be linked and that both shifts can participate without weakening normal service. The analyst and shift managers will validate these assumptions in week 1. Material risks include inconsistent timestamp meanings, incomplete coverage during peak demand and a trial disrupting carrier collection. The leader maintains the risk register; the process owner approves trial stop conditions and recovery arrangements before the pilot.
10. Approval, changes and handover
In this fictional example, the sponsor approves version 1.0 after confirming resources and scope with the affected managers. The leader records the approval date and decision reference, and the process owner confirms the proposed acceptance arrangements. Every requested change to the objective, scope, resources, measurement basis or promised-date rule is assessed for its effect on the other commitments and requires sponsor agreement where it exceeds the leader’s mandate.
At handover, the process owner accepts the operating standards, monitoring responsibilities and response plan, including an eight-week operational follow-up after project closure. Remaining actions receive owners and dates. The benefits estimate is revisited against evidence; closure does not convert projected savings into realised benefits.
10 · Expert judgement
Review the logic, not just the completed headings
The example’s strength is the connection between its entries. The problem concerns late carrier handover, so the goal uses the same output and the scope includes the activities leading to that event. The benefit estimate uses the same proposed change in late-order count, while labelling its administrative-effort assumption. Authority prevents unauthorised changes to customer promises. Acceptance checks accuracy and overtime so that the result cannot be achieved by transferring cost or harm elsewhere.
Look for contradictions. A scope limited to one shift cannot support an unqualified claim about both shifts. A goal to improve dispatch reliability cannot be met simply by redefining the promised date. A €1,000 spending limit is not meaningful if the proposed pilot already depends on an unapproved €10,000 purchase. Revise the commitments together rather than treating each field as an independent answer.
| Finding during review | Decision it requires |
|---|---|
| The timestamp records label creation, not carrier handover. | Revise the measurement method and validate a new baseline. Keep the original figure identified as provisional; reconsider the target against the new evidence. |
| A major cause occurs before the agreed start boundary. | Assess whether the team can still achieve its goal. Seek scope extension, revise the outcome or create a separate project with the relevant owner. |
| The sponsor requests one week as proof of success. | Explain the coverage and variation risk. Agree verification suited to the decision, without presenting a short acceptance window as proof of sustained stability. |
| The pilot needs more capacity than authorised. | Request a resource decision, reschedule or reduce the pilot scope. Do not treat a team list as permission to consume unlimited staff time. |
11 · Use through DMAIC
Keep the charter current without rewriting history
At Measure, confirm or revise the baseline, definitions and evidence coverage. At Analyze, test whether supported causes fall within the mandate. At Improve, check that selected changes address those causes and respect requirements and resource limits. At Control, verify the agreed outcome and transfer responsibility for maintaining it. The charter remains the reference for these decisions; detailed records belong in the appropriate supporting documents.
When an important assumption changes, record the new evidence, proposed revision, consequences and approval. Keep a version history. Quietly reducing a target after a disappointing pilot conceals the decision; openly revising a target after a corrected baseline can be sound judgement. Distinguish those situations by making the evidence and approval visible.
A charter is not a causal analysis, a detailed project plan or an operating standard. Link those documents to it. Its purpose is to preserve a coherent mandate while the investigation develops, and to make clear when the team needs another decision rather than acting beyond its authority.
13 · Sources
Professional foundations and original teaching material
The professional foundations are the charter’s role in project authorisation and its place in Define. The detailed construction method, comparisons, decision examples and fictional charter above are original LeanTrainingLab teaching material.
- PMI: The Charter — Selling your Project — project authorisation and authority.
- ASQ: DMAIC Process — the charter’s role within Define.
- PMI: Managing and Leading Small Projects — adapting project documentation to the work.
The accepted toolset also references Six Sigma+Lean Toolset, second edition (Lunau, editor; Springer, 2013). Its chapters have not been available for a direct comparison during this revision. This guide does not reproduce the book’s example or prescribe a universal charter length.