Project Charter Template Lean Six Sigma

Standard Operating Procedure: Lean Six Sigma Project Charter Development

1. Document Control Block

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the mandatory engineering protocol for authoring, validating, and approving a Lean Six Sigma (LSS) Project Charter within Template Registry. The purpose of this procedure is to eliminate ambiguity, scope creep, and resource misalignment by establishing a rigorous, data-driven contract between project sponsors and execution teams prior to DMAIC (Define, Measure, Analyze, Improve, Control) phase initiation.

---

3. Scope & Prerequisites

3.1 Scope

This SOP applies to all Black Belts, Green Belts, and continuous improvement practitioners initiating operational excellence projects across all divisions of Template Registry.

3.2 Prerequisites & Required Tools

• Software Stack: Enterprise Process Management Suite (EPMS), Statistical Analysis Toolset (Minitab v21+ or Python scipy/statsmodels), and Template Registry Document Repository.
• Data Inputs: Voice of the Customer (VOC) transcripts, historical process yield data, and initial financial ledger extracts.
• Certifications: Active LSS Green Belt or Black Belt credential for the designated Project Lead.
• PPE: N/A (Administrative and digital engineering process).

---

4. Roles & Responsibilities (RACI Matrix)

(Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed)

---

5. Step-by-Step Procedure

Phase 1: Problem Definition and Business Case Architecture

• 1.1 Extract enterprise strategic objectives from the annual Balanced Scorecard to ensure vertical alignment of the proposed project.
• 1.2 Conduct a Voice of the Customer (VOC) analysis to translate qualitative customer complaints into quantifiable Critical to Quality (CTQ) parameters.
• 1.3 Draft the Business Case detailing the financial and operational penalty of non-conformance (Cost of Poor Quality - COPQ).
• 1.4 Formulate the Problem Statement using the strict syntax: [Process/System] is experiencing [Defect/Symptom], resulting in [Quantified Impact] as of [Baseline Date], which adversely affects [Business Metric/Customer].
• 1.5 Formulate the Goal Statement ensuring compliance with SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound).

Phase 2: Scope Boundary and SIPOC Mapping

• 2.1 Construct a high-level SIPOC (Suppliers, Inputs, Process, Outputs, Customers) diagram to bound the operational process ecosystem.
• 2.2 Establish explicit In-Scope boundaries (specific subprocesses, shifts, geographical nodes, or IT modules included).
• 2.3 Establish explicit Out-of-Scope boundaries to explicitly protect against scope creep during the Analyze and Improve phases.
• 2.4 Identify macro-level process triggers (inputs) and final deliverables (outputs) tied directly to the goal statement.

Phase 3: Financial Validation and Resource Allocation

• 3.1 Partner with the assigned Finance Representative to calculate projected Hard Savings (direct cost reduction, headcount reallocation) and Soft Savings (capacity unlock, risk mitigation).
• 3.2 Define resource commitments, detailing labor hours per week, capital expenditure requirements, and required software license access.
• 3.3 Map out the high-level DMAIC project milestone schedule with strict gate review deadlines.

Phase 4: Review, Validation, and Gate Sign-Off

• 4.1 Execute a peer review of the draft charter using the Template Registry LSS Quality Checklist.
• 4.2 Present the charter to the Project Sponsor and Business Process Owner for a formal Gate 0 (Define Phase) review.
• 4.3 Secure digital signatures from all accountable stakeholders within the EPMS platform.
• 4.4 Archive the baseline-approved charter document in the Template Registry repository with metadata tags reflecting the project ID.

---

6. Quality Assurance & Pro-Tips

6.1 Best Practices

• Quantify the Baseline: Never accept subjective problem statements. Ensure baseline Sigma levels or defect rates are backed by at least 30 historical data points.
• Boundary Enforcement: Revisit the In/Out of Scope section at every DMAIC gate review to prevent scope expansion.

6.2 Common Pitfalls to Avoid

• Solutionizing in the Charter: Do not state the intended solution in the problem or goal statements (e.g., avoid "Problem is we need a new software system"). Focus strictly on the symptom and metric.
• Vague Financials: Avoid projecting savings without sign-off from corporate finance; unvalidated savings will cause project rejection at financial audits.

6.3 Metric Thresholds

• Target ROI: Minimum 3:1 return on project resource investment.
• Charter Approval Cycle Time: Must not exceed 10 business days from initial draft submission to final sign-off.

---

7. Frequently Asked Questions (FAQ)

Q1: What should I do if the Project Sponsor refuses to sign the charter due to disagreement on the financial savings projection?
A: Reconvene with the Finance Representative to re-audit the COPQ calculations. Adjust the projected savings to a conservative, defensible baseline supported by historical ledger data, then resubmit the charter through the EPMS workflow.

Q2: Can the project scope be modified after the charter has been signed at Gate 0?
A: Yes, but only through a formal Scope Change Request (SCR) attached to the charter document, which requires re-signature from both the Project Sponsor and the Business Process Owner.