Crafting Your Defect Reduction Project Charter

What is a Project Charter?

A project charter is the formal document that launches a Six Sigma project. Think of it as a contract between the project team and the organization's leadership. It provides a high-level overview of the project, clarifies its purpose, and secures the necessary resources and sponsorship. For a Green Belt, mastering the charter is a non-negotiable first step.

To get a comprehensive overview of what a charter is and what it contains, please read the following article from Smartsheet.

As the article mentions, the charter is a living document. It's not created once and filed away; it's revisited and refined, especially after the "Measure" phase provides more data.

The Core Components of a Powerful Charter

While a charter has several elements, today we'll focus on three that form its argumentative core: the Business Case, the Problem Statement, and the Scope.

1. The Business Case: The Strategic "Why"

The business case answers the question, "Why should the company invest time and resources into this project?" It links the project to strategic business goals and almost always speaks the language of management: money.

A key concept here is the Cost of Poor Quality (COPQ). This includes all costs incurred from producing defective products, such as scrap, rework, warranty claims, and even lost sales from unhappy customers. Your experience in manufacturing has likely given you a firsthand look at these costs, even if you didn't label them as COPQ.

To see how to quantify this and build a compelling business case, please watch the following video clip.

Key Distinction: The business case is different from the problem statement. The business case focuses on the consequences of the problem for the business (e.g., "We are losing $500k annually due to rework"). The problem statement, which we'll discuss next, quantifies the problem itself.

For a deeper dive into crafting the business case and understanding its distinction from the project charter, this article from SixSigma.us is an excellent resource.

2. The Problem Statement: The "What"

The problem statement provides a clear, concise, and data-driven description of the issue. A well-crafted problem statement:

• Is specific and measurable: It quantifies the problem. Instead of "too many defects," use "The defect rate on Line 2 has increased from 3% to 7% over the last quarter."
• Focuses on the problem, not the cause or solution: A common mistake is to jump to conclusions. For example, avoid phrases like "...due to poor operator training." The "Analyze" phase is for finding the root cause. A neutral statement of the facts is required here.

3. The Scope Statement: The "Where"

Scope creep is a primary reason for project failure. The scope statement prevents this by building a fence around your project. It clearly defines what is in-scope (the processes, products, or locations the team will work on) and what is out-of-scope.

Being explicit about what's out-of-scope is just as important as defining what's in. For a project focused on reducing welding defects on one product line, the scope might look like this:

• In-Scope: The welding process for the Shire 55 model on the day shift.
• Out-of-Scope: Any other product models, other shifts, or different manufacturing processes like painting or assembly.

A Practical Manufacturing Example

Theory is useful, but seeing it in action is better. Let's watch a video that walks through the creation of a project charter for a real-world manufacturing problem.

To see what a completed charter looks like, here is an example template filled out for a manufacturing project.

Notice how each section is concise but specific. The problem is quantified (72% defect-free), the business case connects it to costs ("increased remakes and strain on raw materials"), the goal is SMART (improve to 92% in 180 days), and the scope is unambiguous (Line A only).

Your Turn: Draft a Project Charter

Now, let's put this into practice. Based on your experience, you know that a clear project definition is critical before you start gathering data or brainstorming solutions. This exercise will help you formalize that initial thinking.

Scenario:
An automotive parts manufacturer has seen a 20% increase in customer returns for its premium brake pads over the last six months. The primary complaint is "excessive brake noise." This issue is jeopardizing a contract with a major automaker and has led to an estimated $75,000 per month in warranty claims and shipping costs. Initial data suggests the problem is most prevalent with pads produced on Production Line 3 during the night shift. The current first-pass yield for this specific line and shift has dropped to 65%.

Your Task:
Based on the scenario above, draft the following four components for a new Six Sigma project charter.

1. Business Case: Write 1-2 sentences explaining why the company should care about this project.
2. Problem Statement: Write a concise statement that quantifies the problem.
3. Scope Statement: Clearly define what is "in-scope" and "out-of-scope."
4. SMART Goal Statement: Define a specific, measurable, achievable, relevant, and time-bound goal for the project. (e.g., "Reduce/Increase X from Y to Z by [Date]").

Take about 15 minutes to draft your responses. This is the first step in thinking like a certified Green Belt.

Conclusion

In this lesson, you've taken the first formal step in the DMAIC process. We've established that the project charter is the foundational "contract" for any Six Sigma project.

Key Takeaways:

• A Project Charter formally authorizes a project and outlines its key parameters.
• The Business Case provides the strategic and financial justification (the "Why").
• The Problem Statement is a neutral, data-driven description of the issue (the "What").
• The Scope Statement sets clear boundaries to prevent project overreach (the "Where").
• A SMART Goal provides a clear definition of success.

Creating a solid charter is not just paperwork; it forces critical thinking upfront, aligns the team and stakeholders, and sets the stage for a focused, successful project.

Preview of the Next Lesson:
Now that we have a high-level project definition, how do we know what "good" looks like to the customer? In the next lesson, we will explore how to translate the Voice of the Customer (VOC) into specific, measurable, Critical-to-Quality (CTQ) requirements. This will allow us to move from a general problem like "brake noise" to the specific engineering characteristics we need to measure and control.