All articles

Methodology

Project Charter: How to Write One That Holds Up in Month Five

A step by step walkthrough of the Project Charter tool in the Define phase of RDMAICS, built on a single fictional pizza delivery case. You will see what each field is for, how to read the finished charter, and where the tool stops being useful.

Ci Flow editorial team 4 October 2026 8 min read
Project Charter, Define phase tool guide from Ci Flow

What the Project Charter is for, and when to open it

The Project Charter is the formal document that authorises a project and defines its scope, objectives and team. It is the first substantial artefact of the Define phase in RDMAICS. Before it exists, you have an idea. After it exists, you have a project with a sponsor, a boundary and a number to hit.

Open the charter after the Recognise phase has told you something is worth fixing, and before anyone starts collecting data in earnest. That sequence matters. A charter written after measurement has begun tends to describe whatever the team already found, rather than what the business asked for.

The charter also does quiet administrative work. It records who approved the project, who owns the process, and who is leading the analysis. Six months later, when a store manager asks why a driver routing change is being piloted in their site, the charter is the document that answers.

The worked case: a pizza delivery process

Everything in this guide uses the sample data built into the tool. The case is fictional. It exists so you can see the fields filled in properly rather than looking at an empty form and guessing.

The project is named pizza delivery process, carrying Project ID 001. It sits in the Field Operations, Delivery business unit. The executive sponsor is Su Chen. The process owner and the Black Belt are both recorded as Chief. The work runs from 1 December 2025 to a target completion of 30 June 2026, and the strategic alignment is Customer Experience and Cost Reduction.

The problem statement is deliberately factual. Average pizza delivery time is 48 minutes against a promised 30 minute SLA. Twenty two per cent of deliveries are late. There are 340 complaints per month. The estimated annual loss is $186K. No cause is offered anywhere in that sentence, which is exactly right for a charter.

The sample data as the tool holds it, from project identity through to the risk table. Notice that the problem statement contains only observations, never explanations.
The sample data as the tool holds it, from project identity through to the risk table. Notice that the problem statement contains only observations, never explanations.

Setting up the identity and alignment fields

Start at the top. Project Name, Project ID and Business Unit are administrative, but they are what makes a charter findable two years later. The ID of 001 is worth using even for a first project, because the numbering habit survives longer than the enthusiasm.

The three people fields carry different weight. The executive sponsor, Su Chen, is the person with the authority to release resources and resolve blocks. The process owner holds the day to day process and will inherit the improvements. The Black Belt leads the analysis. In this sample, one person named Chief holds both the process owner and Black Belt roles. That happens often in smaller organisations. It is worth naming it in the charter rather than hiding it, because it tells the sponsor where the single point of failure sits.

Dates and strategic alignment anchor the project to the calendar and the strategy. A window from 1 December 2025 to 30 June 2026 is roughly seven months. The alignment line, Customer Experience and Cost Reduction, is the sentence a sponsor will repeat when someone asks why this project and not another one.

Writing the problem statement and the SMART goal

The problem statement field asks for fact, with no root cause. This is the field people get wrong most often. The sample statement gives four measurable facts and one estimate: 48 minutes average against a 30 minute SLA, 22 per cent late deliveries, 340 complaints per month, and an estimated $186K annual loss. It does not say drivers are slow or routing is poor. Those are hypotheses for the Analyse phase.

The SMART goal field then converts the problem into a commitment. In the sample it reads: reduce average pizza delivery time from 48 minutes to 30 minutes or less, and late deliveries from 22 per cent to 5 per cent or less, by 30 June 2026. Every element is present. The subject, the from, the to, and the date.

The primary measure fields repeat part of that goal in a structured form. Primary Measure is average delivery time. Baseline is 48. Target is 30. Unit is minutes. This separation matters, because the structured version is what later tools in the Measure and Control phases can read.

The business case field explains why anyone should care. In the sample, late deliveries are named as the leading cause of customer churn and refund costs. The project targets $360K in annual benefit and aims to raise customer satisfaction from 68 per cent to at least 88 per cent.

Scope, assumptions and risks

Scope is where charters earn their keep. The sample puts order dispatch, kitchen to driver handoff, driver routing and customer handoff across four metro stores inside the boundary. It puts cooking time, menu design and third party delivery platforms outside it.

Read that out of scope list again. Cooking time is plausibly part of a 48 minute delivery. Excluding it is a choice, and writing the choice down is what stops a team from quietly expanding into it in March. An out of scope line is a promise to the sponsor about what you will not spend their money on.

Three assumptions are recorded, and two risks with mitigations. Each risk has a named response rather than a note to monitor it.

  • Assumption one: delivery timestamps remain available from the dispatch platform.
  • Assumption two: store and driver representatives are available for pilot testing.
  • Assumption three: traffic aware routing can be piloted without changing the POS system.
  • Risk one: dispatch staff may resist automated driver assignment. Mitigation is co-design sessions, supervisor champions and a phased rollout.
  • Risk two: route API downtime may reduce optimisation performance. Mitigation is maintaining optimised static zones as a fallback and adding outage alerts.

Reading the finished charter

Once the fields are complete, the tool produces the charter as a single result. You can see the whole screen in one view, from the identity fields at the top through to the assembled document at the bottom. The tool also offers an AI review that comments on the charter you have written.

Read the result for internal consistency rather than for style. Does the primary measure match the SMART goal? In the sample it does: 48 minutes to 30 minutes in both places. Does the scope cover everything the goal depends on? Driver routing is in scope, and routing is where the SMART goal expects most of the movement, so that holds.

Then check the arithmetic of ambition. The problem statement estimates a $186K annual loss. The business case targets $360K in annual benefit. Those are different figures measuring different things, and a sponsor will ask about the gap. A charter that cannot explain its own numbers will not survive its first steering meeting.

The full tool screen, inputs through to the assembled charter. Check that the numbers in the SMART goal and the primary measure fields agree before you share it.
The full tool screen, inputs through to the assembled charter. Check that the numbers in the SMART goal and the primary measure fields agree before you share it.

The decisions this charter supports, and the mistakes to avoid

A completed charter supports four decisions. Whether to fund the project at all. Where to stop when scope pressure arrives. Which measure the team will be judged on. And who to escalate to when a store will not release a driver for pilot testing.

The common mistakes are predictable. The first is smuggling a cause into the problem statement. If the statement says routing is inefficient, the Analyse phase has been pre-decided and the team will go looking for confirmation. The second is a goal without a date, or with a date that matches the financial year rather than the work. The sample commits to 30 June 2026 and the project starts 1 December 2025, so the window is stated and testable.

The third mistake is an empty out of scope field. Scope that only says what is in is not scope. The fourth is risks without mitigations. A risk line that ends at the description is a worry, not a plan. Both sample risks name specific responses.

The last mistake is treating the charter as a one time document. Scope changes. Sponsors change. The charter should be revised and re-signed when they do, with the change visible.

Honestly, what the Project Charter will not do

The charter will not tell you whether your problem statement is true. It accepts 48 minutes, 22 per cent and 340 complaints per month because you typed them. If the baseline came from a report nobody has validated, the charter will carry that error through every later phase with full confidence. Verifying the baseline is Measure phase work, and the charter happens first.

It will not find your root cause. Nothing in the fields asks why delivery takes 48 minutes. That is deliberate. A charter that names a cause has skipped two phases. If you already know the cause, you are probably wrong, and the charter is not the document that will correct you.

It will not validate the benefit figure. The $360K annual benefit target is an input, not a calculation. The tool has no visibility of your cost model, your margin or your refund policy. A finance partner has to sign that number, and the charter does not substitute for that conversation.

It will not create authority. A sponsor name in a field is not sponsorship. If Su Chen has not read the document and agreed to the scope boundary, the charter is a wish list with a letterhead. It will also not manage the project, track progress, or tell you when the 22 per cent late deliveries figure has moved. Those belong to the Measure, Improve and Control phases.

What it does do is force a set of specific commitments into one page before work starts. That is a smaller job than it sounds, and a more useful one than most teams expect.

project charter templateRDMAICS define phaselean six sigma charterSMART goal project charterproject scope and objectivescontinuous improvement tools

Run this method inside Ci Flow

RDMAICS, A3, Just Do It and Kaizen projects with the full Lean Six Sigma toolset, AI interpretation and tollgate presentations built from your real evidence.

Keep reading

Ci Flow

Ci Flow connects improvement methodologies, guided tools, project evidence, AI support, collaboration and tollgate presentations in one operational-excellence workspace.

RDMAICS · A3 · Just Do It · Kaizen

© 2026 Ci Flow. All rights reserved.

Built for evidence-led continuous improvement