The Six Sigma Project Charter, Field by Field

Search for a Six Sigma project charter template and you get a blank grid: a Word table or a spreadsheet with labeled boxes and no guidance on what a strong entry looks like. The labels are not the hard part. The hard part is knowing what belongs in each box, what a sponsor will challenge, and which entries quietly doom a project four months later.

This post walks through the charter field by field. For each one: what it is for, what a defensible entry contains, and the mistake reviewers see most often.

What the charter does

The charter is the contract between the project team and the sponsor. It is written in the Define phase, before any data collection, and it answers four questions: what problem the project attacks, what result counts as success, why the organization should spend resources on it, and where the boundaries sit. GoLeanSixSigma describes it as the project's road map and the reference point every later phase returns to.

Treat it as a living document with a hard cutoff. The charter is expected to sharpen during Define and Measure as baseline data comes in. After the sponsor signs off at the Define tollgate, changes require the same sign-off. A charter that drifts silently is not a charter; it is a suggestion.

In SixGrid, the charter is a structured form on its own tab of every project, with a Charter Status field that moves from Draft to Final. That status is deliberately separate from project status. A project can be Active while its charter is still Draft, and the open Draft flag tells everyone the contract is not yet locked.

Problem statement

The problem statement describes the gap between current performance and required performance, in neutral, quantified terms. A complete one names the process, the metric, the size of the gap, how long it has persisted, and what the gap costs.

Weak: "Invoice processing is slow and causes customer complaints."

Strong: "Invoice processing averaged 11.4 days from receipt to payment between January and June, against a contractual standard of 5 days. Late payments generated $118,000 in early-payment discounts forfeited over the period."

The most common failure is smuggling a cause or a solution into the statement. The phrase "due to" is the tell. "Invoices are late due to understaffing in AP" has already skipped Measure and Analyze and landed on an answer. State the pain, not the diagnosis. The analysis phases exist to find the cause; a problem statement that presumes one biases the whole project toward confirming it.

Goal statement

The goal statement says what the primary metric will do, by how much, and by when. The standard test is SMART: specific, measurable, attainable, relevant, time-bound. Smartsheet's charter guide documents the same structure.

Strong: "Reduce average invoice processing time from 11.4 days to 5 days or less by March 31."

Two rules keep goal statements honest. First, the goal moves the process metric, not the financial result. "Save $118,000" is an outcome of fixing the process, and phrasing the goal as a savings figure confuses the primary metric with the financial metric, a mistake iSixSigma flags in its guidance on metric selection. Second, the goal names no solution. "Implement automated invoice routing" is a solution masquerading as a goal, and it commits the team before the analysis is done.

Business case

The business case answers the question the sponsor's boss will ask: why this project, and why now. It links the problem to something the organization already cares about, in money or in strategic terms. Quantify what closing the gap is worth annually, and state what continuing to live with the problem costs.

The discipline here is separation of concerns. The problem statement quantifies the gap. The business case argues the gap matters. Teams that merge the two produce a paragraph that does neither job well. Keep the business case short, and write it for a reader who will never open the project again.

Primary metric, baseline, and target

The primary metric is the single measure the problem statement and goal statement share. Everything hangs on three numbers: the baseline (performance before the project), the current value (performance now), and the target (the goal statement's commitment).

Recording all three, dated, is what makes the final report defensible. A project that cannot show its baseline cannot prove improvement, and rough but honest baseline numbers established early are what ground the charter in reality rather than aspiration. SixGrid's charter form captures baseline, current, and target for the primary metric and renders progress against them as the project runs, so the Define-phase numbers are still there, unedited, at close-out.

Expect the baseline to be refined during Measure. That refinement is normal and should be visible, not overwritten.

Secondary metrics

Secondary metrics are the guardrails. They catch the failure mode where the primary metric improves by exporting damage somewhere else: cycle time drops while error rate climbs, cost falls while customer satisfaction follows it down.

Choose one or two. A charter with six secondary metrics has an unfocused problem statement upstream. For each, note the current level and the constraint, for example "first-pass yield holds at or above 94 percent." In SixGrid these sit directly under the primary metric on the charter, so a tollgate review reads the trade-offs on one screen.

Scope

Scope defines where the project starts and stops: which process steps, which sites, which product lines. The practical technique is two explicit lists, in-scope and out-of-scope, because the out-of-scope list is the one that settles arguments in month three. Lean Six Sigma practitioner guides consistently identify a vague scope statement as the setup for scope creep, one of the most common reasons improvement projects fail.

Scope the project to the team's authority. If the fix will require another department's process to change, either that department is represented on the team or that process is out of scope.

Project type and level

Two classification fields do quiet portfolio work. Project type records the methodology: DMAIC, Lean, Kaizen Event, PDCA, A3 Problem Solving. Project level records who is running it, from Yellow Belt through Master Black Belt. Neither changes how the project runs day to day. Both are what allow a program office to answer "what kinds of projects are we running, led by whom" without a survey. In SixGrid these fields feed the organization-wide Reports view directly.

Charter status: the draft-to-final lifecycle

The last field is the lifecycle itself. A charter in Draft is a working hypothesis; edits are expected. Marking it Final is the sign-off act, the point after which the charter is the agreed contract and changes go back through the sponsor.

A blank downloadable template cannot enforce this distinction. A document on a shared drive is always silently editable, which means the version the sponsor approved and the version the team is working from can diverge with no one noticing. This is the structural argument for running the charter as a governed form rather than a file: the status is visible to everyone, and the Continuous Improvement program can see at a glance which active projects are still operating without a locked contract.

The template question

None of this means templates are useless. It means the template is the least important part. The value is in the standard of evidence each field demands: a quantified gap, a SMART goal, an honest baseline, an explicit out-of-scope list, a visible sign-off. Hold your next charter to that standard, whatever tool it lives in, and the document stops being paperwork and starts being the project's spine.