Writing a Project Charter That Gets Approved

The project charter is the least glamorous document in Six Sigma and the most consequential. It is one page, sometimes two. It contains no analysis, no statistics, no clever solutions. And yet it decides whether your project gets resources, whether your team knows what it is doing, and whether — months from now — anyone can say the project succeeded. Weak charters do not merely delay approval; they launch projects that drift, balloon, and quietly die.

The good news is that charter writing is a learnable craft with known failure modes. Sponsors send charters back for the same handful of reasons everywhere, and each one is avoidable. This article walks through the sections that matter, what a sponsor is actually reading for, and the red flags that reliably trigger a rewrite.

What a sponsor is actually looking for

A sponsor reading a charter is answering three private questions. Is this problem worth the organization’s attention and this team’s time? Is the project defined tightly enough to finish? And will I be able to tell whether it worked? Every section of the charter exists to answer one of those questions, which gives you a simple editing test: any sentence that does not help a sponsor answer one of the three is decoration, and any of the three left unanswered is a returned charter.

Notice what is not on the list: the solution. A charter that promises a specific fix — new software, a reorganization, an extra inspection step — is asking the sponsor to approve a conclusion before the evidence exists. Experienced sponsors read embedded solutions as a warning that the team has already stopped thinking.

The problem statement: symptoms, not solutions

The problem statement describes what is wrong in observable, measurable terms — what is happening, where, since when, and what it costs in the currency the organization cares about: time, defects, rework, complaints, missed commitments. It names no causes and proposes no fixes. The discipline sounds simple and is violated constantly, because most projects are born from someone’s theory about a fix, and the theory leaks into the writing.

Compare two versions. “We need to automate invoice intake because manual entry causes errors” is a solution with a problem attached. “Invoices returned for correction have risen for three consecutive quarters, delaying supplier payment and consuming accounts-payable capacity in rework” is a problem a team can investigate honestly — and if the real cause turns out to be a missing purchase-order field rather than manual entry, the charter does not have to be rewritten to permit the truth.

The goal statement: direction, magnitude, deadline

The goal statement says what improvement the project will deliver: which metric moves, from what baseline, to what target, by when. Reduce cycle time from the measured baseline to an agreed target by end of second quarter. The baseline may be provisional this early — Measure will firm it up — but the structure must be there, because a goal without a number is a wish, and a goal without a date is a hobby.

Resist the urge to promise the moon to win approval. Sponsors approve credible goals, and they remember who delivered. A defensible target beats an impressive one — and if the honest answer is that you cannot yet say what is achievable, say that, and commit to setting the target when the baseline is established. That sentence has saved more careers than any inflated percentage ever did.

Scope: the fence that saves the project

Scope defines the fence: which process, from what first step to what last step, and — just as important — what is explicitly out. Out-of-scope lines feel impolite to write and are the most protective sentences in the document. They are the reason your invoice project does not slowly absorb supplier onboarding, the payment platform, and the procurement policy review, each addition arriving as a reasonable-sounding request from someone important.

A useful test for scope is the one-team, one-quarter question: can the named team, with its actual availability, complete this in roughly the stated timeline? If not, the answer is a smaller fence — one site, one product family, one segment of the flow — with a note that success will justify expansion. Sponsors approve small fences readily, because small fences produce finished projects.

Business case, team, and timeline

Three shorter sections round out the document. The business case answers why now, in one honest paragraph: what the problem costs, what continuing to live with it means, and how the project connects to something the organization has said it cares about. The team section names the leader, the members, the sponsor, and the rough time commitment — vagueness here is where projects go to starve. The timeline lays out the DMAIC phases with expected dates, understood by everyone as a forecast to be revised, not a contract to be litigated.

Red flags that get charters sent back

• A solution hiding in the problem statement — the word “because” is usually the tell
• A goal with no number, no baseline, or no date
• Scope described only by what is in, with nothing declared out
• A problem the organization does not measurably feel — no cost, no customer, no consequence
• A team list of names without stated availability, or a sponsor listed who has not actually agreed
• Ambition sized for a program, submitted as a project

A charter is not paperwork before the project — it is the first test of whether the project can be finished.

Where charter writing is taught properly

Charter writing improves fastest with structured practice: drafting, getting critique, and seeing how the document holds up as a project unfolds. That is how certification teaches it. Our free White Belt program covers the charter’s role in DMAIC in about six hours, ending with a 30-question exam and a verifiable certificate. Green Belt has you build one inside a full simulated project — 35 hours, a 100-question proctored exam, one free retake, lifetime access. The next process that everyone complains about and nobody fixes is one well-written page away from becoming a project.