Project Charter Example Lean Six Sigma

Standard Operating Procedure: Lean Six Sigma Project Charter Development

1. Document Control Block

• Document ID: SOP-TR-LSS-042
• Effective Date: October 24, 2023
• Version: 2.1.0
• Review Cadence: Annual
• Owner: Chief Architect, Template Registry

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional requirements for authoring, validating, and approving a Lean Six Sigma (LSS) Project Charter. The purpose is to eliminate scope creep, secure stakeholder alignment, and establish measurable baseline metrics before committing capital or engineering resources to Define-Measure-Analyze-Improve-Control (DMAIC) cycles. Adherence to this SOP is mandatory for all continuous improvement initiatives across Template Registry operational units.

---

3. Scope & Prerequisites

• Scope: Applies to all Green Belt, Black Belt, and Master Black Belt practitioners initiating DMAIC or Design for Six Sigma (DFSS) projects within Template Registry.
• Prerequisites:
  • Completion of Lean Six Sigma Green Belt training or equivalent certification.
  • Access to Template Registry Enterprise Process Repository (EPR).
  • Validated Voice of the Customer (VOC) or high-level business case ticket.
• Required Tools & Software:
  • Minitab Statistical Software (v21 or higher)
  • MS Excel / Enterprise Project Management (EPM) Suite
  • Template Registry LSS Charter Template (TR-SOP-042-FormA)

---

4. Roles & Responsibilities

---

5. Step-by-Step Procedure

Phase 1: Business Case & Problem Statement Formulation

• 1.1 Extract high-level business drivers from the Enterprise Strategic Plan or direct customer escalation tickets.
• 1.2 Draft the Business Case addressing the "burning platform"—quantify the financial or operational cost of inaction within a 12-month horizon.
• 1.3 Formulate the Problem Statement utilizing the mandatory syntax: [What is wrong], [Where it occurs], [When it started/frequency], and [Magnitude of the defect]. Ensure zero assignment of blame or root causes.
• 1.4 Formulate the Goal Statement following SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound). Example: "Reduce cycle time of template ingestion from 14 days to 3 days by Q3."

Phase 2: Project Scope & Boundary Definition

• 2.1 Establish SIPOC (Suppliers, Inputs, Process, Outputs, Customers) boundaries to define exact process triggers and endpoints.
• 2.2 Document In-Scope parameters (e.g., specific geographical sites, asset classes, software versions).
• 2.3 Document Out-of-Scope parameters to explicitly manage stakeholder expectations and prevent scope creep.
• 2.4 Verify resource availability against out-of-scope boundaries to ensure zero dependency conflicts.

Phase 3: Milestone Scheduling & Financial Validation

• 3.1 Map out preliminary DMAIC gate review dates corresponding to corporate fiscal quarters.
• 3.2 Define hard deliverables for each gate (e.g., Gate 1: Define; Gate 2: Measure; Gate 3: Analyze; Gate 4: Improve; Gate 5: Control).
• 3.3 Collaborate with the Finance Representative to calculate Hard Savings (reductions in headcount, scrap, rework) vs. Soft Savings (capacity release).
• 3.4 Input projected cost-benefit metrics into the Template Registry Financial Tracking Module.

Phase 4: Sign-off & Gate Review

• 4.1 Compile all charter sections into the standardized TR-SOP-042-FormA artifact.
• 4.2 Convene a 30-minute Gate 1 Review meeting with the Project Sponsor and Process Owner.
• 4.3 Secure digital signatures within the Enterprise Process Repository to formally baseline the project.

---

6. Quality Assurance & Pro-Tips

Best Practices

• Data-Driven Baselines: Never draft a goal statement without historical baseline data pulled directly from system logs or certified data lakes.
• Process Owner Inclusion: Involve the Process Owner during Phase 2 to guarantee operational buy-in and prevent post-implementation abandonment.

Common Pitfalls to Avoid

• Root Cause Creep: Inserting solutions or premature root causes directly into the Problem Statement. The charter defines what is broken, not why.
• Vague Metrics: Using qualitative goals (e.g., "improve customer satisfaction") instead of quantitative metrics (e.g., "increase CSAT score from 72% to 88%").

Metric Thresholds

• Charter Approval Cycle Time: $\le 5$ business days from initial draft submission to final sponsor sign-off.
• Scope Variance: $\le 0%$ unauthorized drift post-Gate 1 sign-off without a formal Change Request (CR).

---

7. Frequently Asked Questions

Q1: What should I do if the Project Sponsor refuses to sign the charter due to unaligned financial targets?

A: Re-engage with the Finance Representative to re-evaluate the cost-benefit analysis. If hard savings cannot be proven, pivot the project focus to risk mitigation, compliance, or customer safety, adjusting the financial metrics to reflect risk-avoidance value rather than direct cost reduction.

Q2: How do I handle mid-project scope expansion requested by stakeholders?

A: Any request to expand boundaries post-Gate 1 requires the submission of an LSS Change Request Form (TR-CR-02). The Project Lead, Sponsor, and Process Owner must review the impact on timeline and resources before updating the charter version control block.