Lesson 3: Selecting a project, building the charter, and proving the payoff

Not every problem worth grumbling about is worth a Lean Six Sigma project. This lesson covers how a project actually gets selected and started: the business case that justifies spending time on it, the charter that defines it, and the financial case that proves, in a way leadership can verify, that it was worth doing.

Building a business case and project charter

A business case answers one question before any team time is spent: why does this problem matter enough to fix now? It typically states the problem in terms of business impact, cost, risk, customer dissatisfaction, missed deadlines, and ties it to organizational priorities rather than describing it as an abstract inconvenience.

Once a business case justifies starting a project, the project charter is the document that actually defines it, and typically includes:

• Problem statement: a specific, factual, measurable description of what is wrong, with no assumed cause and no proposed solution baked in.
• Goal statement: what improvement the project is aiming for, ideally with a specific, measurable target.
• Scope: the boundaries of what the project will and will not touch, which prevents the common failure mode of a project quietly expanding until it can never finish.
• Project team and roles: who is on the team, who sponsors it, and who the process owner is.
• Timeline: target dates for each DMAIC phase.

A charter is a living agreement between the team and its sponsor, not paperwork filed away once signed. When a project's scope or goal changes mid-stream, the charter should be revised and re-approved, not silently ignored.

Developing project metrics

A charter's goal statement is only useful if it is tied to a metric that can actually be measured before and after the project. Project metrics typically separate into primary metrics, the Y in Y = f(x), directly tied to the CTQ the project is meant to improve, and secondary or consequential metrics, which track whether fixing the primary metric accidentally made something else worse. A project that improves cycle time by 30 percent while quietly doubling the defect rate has not actually succeeded; the consequential metric caught what the primary metric alone would have missed.

Financial evaluation and benefits capture

A Lean Six Sigma project has to translate its result into terms the organization's leadership can verify and trust, which almost always means dollars. Financial evaluation typically separates benefits into two categories:

• Hard savings: a direct, verifiable reduction in spending or increase in revenue, such as reduced material waste, reduced overtime, or fewer returns processed. Hard savings show up in the budget.
• Soft savings: real but less directly verifiable benefits, such as improved employee morale, avoided future cost, or improved customer satisfaction that has not yet been tied to a specific dollar figure. Soft savings matter but typically carry less weight with a financial sponsor than hard savings do.

Benefits capture is the discipline of actually confirming, after a project closes, that the projected savings materialized and held, usually through a follow-up review some months after the control plan takes effect. A project whose savings were never verified after the fact is, in Six Sigma terms, an unproven project no matter how good the improvement felt at the time.

Writing a SMART goal statement

A charter's goal statement is only as useful as it is specific. The widely used test for a well-written goal, in Six Sigma and well beyond it, is the SMART framework, a mnemonic traced to a 1981 management article by George T. Doran, whose exact wording has shifted over the years. In its commonly taught form, a goal should be Specific (naming exactly what will change, not a vague direction), Measurable (tied to a metric the team can actually collect), Achievable (a real stretch, but not a target the team has no realistic path to), Relevant (tied to the business case and the CTQ the project is meant to improve), and Time-bound (with a target date, not an open-ended aspiration).

"Improve permit turnaround" is a direction, not a goal. "Reduce the average number of days between GCHS submitting a rehab permit application and county approval, from 21 days to 12 days, by the end of the third quarter" is a SMART goal: it names the metric, the current baseline, the target, and the deadline, all in one sentence. A goal statement missing any of the five elements tends to produce exactly the kind of dispute a charter is supposed to prevent, usually surfacing months into the project when someone asks whether the team actually met its target and nobody can agree on what the target was.