1.0 Define Phase

Define Phase Purpose of the Define Phase The Define Phase establishes a clear, aligned, and fact-based understanding of a process problem and the value of solving it. It sets boundaries, expectations, and a shared language before any detailed analysis or improvement work begins. In the DMAIC cycle, the Define Phase aims to: - Clarify the problem in operational and customer terms. - Identify who is affected and what matters to them. - Specify what success looks like and how it will be measured. - Bound the project’s scope so it is realistic and manageable. - Build agreement on why the project is worth doing. Everything done later in DMAIC depends on the rigor and clarity achieved here. --- Voice of the Customer (VOC) Identifying Customers and Stakeholders The Define Phase starts by clarifying who the “customer” is and whose needs drive the project. - External customers – people or organizations outside the company receiving the product or service. - Internal customers – people or functions inside the company receiving outputs or information from the process. - Stakeholders – anyone with a significant interest in the project’s outcome (e.g., finance, compliance, suppliers). Clearly identifying customers allows precise definition of requirements, expectations, and defects. Collecting the Voice of the Customer The VOC captures the stated and unstated needs of customers. In Define, collection should be purposeful and focused: - Existing sources - Complaint logs - Warranty or return data - Service tickets and help‑desk data - Customer satisfaction scores and surveys - Net promoter or loyalty metrics - Targeted input - Structured interviews - Focus groups - Direct observation of customer interactions - Short, focused questionnaires The goal is not to collect all possible data, but to gather enough reliable information to understand what customers truly value and where they experience pain. Translating VOC into CTQs VOC is often qualitative and vague. Define requires translating it into measurable terms called Critical to Quality (CTQ) characteristics. - Typical VOC statements - “I want faster delivery.” - “I need accurate invoices.” - “I can’t afford defects.” - CTQ translation steps - Identify the underlying need (speed, accuracy, reliability). - Define a measurable characteristic (e.g., delivery lead time, invoice error rate). - Specify clear performance requirements (e.g., delivery within 2 days, 99.8% accurate). This translation is commonly supported by a CTQ tree. --- CTQ Trees Purpose of CTQ Trees A CTQ tree is a structured way to convert broad customer needs into specific, measurable requirements. It ensures alignment between high-level VOC and detailed performance metrics. CTQ trees help to: - Avoid vague or ambiguous requirements. - Reveal hidden dimensions of customer needs. - Prioritize which characteristics are most critical. - Provide a measurement-ready definition of “quality.” Structure of a CTQ Tree A CTQ tree moves from general to specific: - Need – broad customer desire (e.g., “fast service”). - Drivers – major elements that support that need (e.g., “short wait time,” “quick issue resolution”). - Requirements – quantifiable performance criteria (e.g., “wait time < 5 minutes, 90% of the time”). Each level asks: “What must be true for the higher level to be satisfied in the customer’s eyes?” Using CTQ Trees in Define In the Define Phase, CTQ trees are used to: - Clarify which aspects of performance matter most to the customer. - Set up later metrics for Measure and Control. - Test whether the project is focused on customer-relevant outcomes. The resulting CTQs become the basis for defining defects, performance measures, and initial targets in the project charter and SIPOC. --- Project Selection and Prioritization Alignment with Strategic Objectives Define includes selecting and confirming that the project is worth pursuing. A project should: - Support strategic business goals (e.g., cost, quality, speed, compliance). - Address issues that significantly impact customers or the organization. - Be actionable within the available authority, time, and resources. A well-aligned project is more likely to receive support and yield meaningful benefits. Selection Criteria Common selection criteria in Define include: - Impact on customer – effect on satisfaction, loyalty, or critical requirements. - Financial impact – potential cost reduction, revenue increase, or risk reduction. - Feasibility – availability of data, expertise, and support to execute. - Time frame – achievable within a defined period appropriate for DMAIC. - Scope fit – not so broad that it becomes unmanageable, not so narrow that it has trivial effects. Conflicting proposals can be prioritized using qualitative or simple scoring criteria that stay close to these factors. Defining and Bounding Scope Scope describes the boundaries of the project: - Process boundaries - Where the process starts (input trigger). - Where the process ends (output delivered). - In-scope items - Activities, locations, or product lines addressed. - Out-of-scope items - Areas intentionally excluded to keep the effort focused. Clearly bounded scope prevents scope creep and unrealistic expectations throughout DMAIC. --- Problem and Goal Statements Characteristics of a Good Problem Statement A problem statement clarifies what is wrong, where, and how big the issue is. It should be: - Specific and factual, not emotional or blaming. - Focused on the gap between current and required performance. - Free of implied solutions. Useful elements include: - What – the defect, delay, variation, or waste. - Where – process, product, location, or customer segment. - When – timeframe for observed performance. - How big – magnitude of the problem (defect rate, cycle time, etc.). - Impact – high-level consequence (customer or business effect). A well-written problem statement creates a shared understanding of the current situation without prescribing how to fix it. Goal Statement and Targets A goal statement describes the desired future performance. It should be: - Quantitative and measurable. - Time-bound, with an expected completion date. - Realistic given data and resources, yet challenging. - Aligned with customer CTQs and strategic objectives. Key elements: - Measure – what metric is being improved (defect rate, lead time, cost). - Current level – baseline performance at project start. - Target level – desired improvement (e.g., from 8% to 2%). - Deadline – date by which the target should be achieved. Targets should be grounded in data rather than arbitrary guesses. Avoiding Common Pitfalls Common issues with problem and goal statements: - Vague wording – “too many defects” instead of a quantified defect rate. - Solution bias – “We need to implement software X” instead of describing the performance gap. - Non-measurable goals – “Improve customer satisfaction” without a defined metric. - Overly broad scope – including multiple unrelated problems in one statement. Clear statements anchor the rest of DMAIC and avoid confusion in later phases. --- Business Case and Project Justification Elements of a Business Case The business case explains why the project is important and how it supports organizational priorities. It typically addresses: - Problem impact - Customer dissatisfaction or retention risk. - Operational inefficiencies or capacity loss. - Compliance or safety exposure. - Financial significance - Estimated cost of poor quality (COPQ). - Potential savings or revenue protection. - Strategic relevance - Alignment with strategic initiatives or key performance indicators. In Define, financial estimates can be approximate but should be logically derived and clearly linked to the problem. Cost of Poor Quality (COPQ) COPQ represents the cost incurred because of defects, rework, delays, or wasted resources. It can include: - Internal failure costs - Scrap - Rework - Reinspection or retesting - External failure costs - Returns and repairs - Warranty claims - Discounts or penalties - Indirect costs - Extra handling - Overtime due to inefficiencies Estimating COPQ helps prioritize projects with the highest potential value and supports resource justification. --- SIPOC Diagram Purpose of SIPOC A SIPOC diagram provides a high-level view of a process and its context: - Suppliers – provide inputs to the process. - Inputs – items or information the process requires. - Process – major steps transforming inputs to outputs. - Outputs – results produced by the process. - Customers – recipients of the outputs. In the Define Phase, SIPOC is used to clarify: - Where the process begins and ends. - Who contributes, who receives, and what flows between them. - What key inputs and outputs are relevant to the CTQs. Building a SIPOC The steps to construct a SIPOC in Define typically follow this logic: - Start with Process - Identify 4–7 high-level steps from start to finish. - Use a simple verb-noun format (e.g., “Receive order,” “Ship product”). - Add Outputs - List primary outputs produced at or near the end of the process. - Add Customers - Identify internal and external customers who receive each output. - Add Inputs - List critical inputs needed to perform each major process step. - Add Suppliers - Identify who provides each critical input. The SIPOC should be simple, capturing the essence of the process rather than detailed workflows. Using SIPOC in Define Within Define, SIPOC helps to: - Confirm and refine the project scope and boundaries. - Connect VOC and CTQs to specific process outputs. - Identify key inputs that may later become focus points in Analyze and Improve. - Align team members on how the process is currently understood, before detailed mapping. --- High-Level Process Understanding High-Level Process Maps In addition to SIPOC, a simple high-level process map or flowchart clarifies the main flow of work: - Linear flow – main operational steps from input to output. - Decision points – major branches or routes based on conditions. - Hand-offs – key transitions between departments or functions. At this stage, the map remains high level; detailed mapping is typically reserved for later phases, unless necessary to clarify scope or problem location. Identifying Value and Pain Points The Define Phase uses this high-level understanding to: - Spot obvious delays, rework loops, or complex hand-offs that may be part of the problem. - Pinpoint where defects, complaints, or delays appear in the process. - Link customer issues (CTQs) to specific process steps. This prepares the ground for targeted data collection in the Measure Phase. --- Project Charter Purpose of the Project Charter The project charter is the central Define Phase output. It formalizes: - What problem is being addressed. - Why it matters. - What success looks like. - How the work will be bounded and structured. The charter serves as a living agreement and reference throughout DMAIC. Key Components of a Charter A robust charter created in Define typically includes: - Problem statement - Factual description of the performance gap, with data. - Goal statement - Specific, measurable target and timeframe. - Business case - Rationale, including customer impact and financial importance. - Scope - Process boundaries, in-scope and out-of-scope areas. - High-level milestones - Planned timeline for each DMAIC phase. - Key stakeholders - Essential contributors and decision-makers. While details can be refined later, these elements must be clear enough to justify proceeding. Charter Review and Refinement During Define: - The charter is drafted, reviewed, and adjusted based on: - VOC and CTQ insights. - SIPOC and high-level process understanding. - Feedback from stakeholders and sponsors. - Assumptions and unknowns are explicitly noted so they can be validated in Measure and Analyze. A charter that is too rigid or vague can hinder progress; Define aims for clarity with some flexibility for learning. --- Initial Risk and Stakeholder Considerations Stakeholder Analysis While detailed change management may occur later, Define requires initial attention to stakeholders: - Identify key stakeholders - Those who provide data, resources, or approvals. - Those heavily affected by process changes. - Assess interests - Potential benefits or concerns related to the project. - Plan engagement - How to communicate project purpose, scope, and expectations. Early engagement reduces resistance and supports smooth data collection in subsequent phases. Preliminary Risk Identification Define also includes early risk thinking related to project execution: - Data availability risk - Is relevant data accessible, reliable, and timely? - Scope risk - Is the project too broad or too narrow to be effective? - Dependency risk - Are there critical systems, people, or suppliers that might limit progress? Identifying such risks in Define allows timely mitigation planning and realistic goal-setting. --- Define Phase Deliverables Core Outputs By the end of the Define Phase, key outputs typically include: - Clarified VOC - Customer needs captured and analyzed. - CTQs defined - Measurable characteristics derived from VOC. - Problem and goal statements - Data-based, specific, and aligned with CTQs. - Business case - Justification with customer and financial impacts. - SIPOC and high-level process view - Boundaries and key elements of the process understood. - Project charter - Formal documentation of purpose, scope, and high-level plan. These outputs are interdependent and should be coherent and consistent with each other. --- How Define Connects to Later Phases Although the focus is on Define itself, understanding its connections helps ensure completeness: - To Measure - CTQs become the basis for selecting metrics. - Problem and goal statements guide baseline data needs. - SIPOC and process maps identify where to measure. - To Analyze - Clearly defined problem prevents misdirected root cause efforts. - Bounded scope narrows analysis to the most relevant areas. - To Improve and Control - CTQs and targets ensure that solutions and control plans remain customer-focused and measurable. A weak Define Phase leads to weak measurement and analysis; a strong Define Phase provides a precise and stable foundation. --- Summary The Define Phase establishes a clear, shared understanding of the process problem and why solving it matters. It: - Captures and analyzes the Voice of the Customer and converts it into measurable CTQs. - Selects and scopes projects using impact, feasibility, and alignment criteria. - Crafts precise problem and goal statements grounded in data. - Builds a compelling business case, often using cost of poor quality. - Develops a SIPOC and high-level process view to clarify boundaries and flows. - Formalizes all of this in a project charter, supported by initial stakeholder and risk considerations. Mastery of Define ensures that subsequent DMAIC work is focused, measurable, and firmly anchored in customer and business needs.