Step 1: Defining and Scoping the Problem in Root Cause Analysis

The Philosophy of Problem Definition

• Foundational Principle: The phrase "A problem well stated is a problem half solved" is attributed to former GM executive Charles Kettering. It emphasizes that a clear understanding of a problem saves time and prevents the "chasing of ghosts."
• Initial Diagnosis Pitfalls: Jumping to conclusions without a defined problem often leads to wasted effort. For example, if a copier is not working, suggesting a check for paper might be a waste of time because the issue could be a burned-out scanning light, low toner, power loss, or mechanical feed problems. A vague problem statement like "the copier isn't working" does not prioritize one cause over another.
• Criteria for Investigation: Before defining a problem, one must consider:
  • Level of Importance: Is the issue critical compared to other existing issues?
  • Scope and Signal-to-Noise Ratio: A broad scope creates a low signal-to-noise ratio, making it difficult to differentiate between cause-and-effect relationships because too many similar problems with different causes are grouped together.

Selecting the Right Problem for Analysis

• The Filtering Process: Organizations must have a filter to decide which problems require formal corrective action and which should simply be tracked over time. Significant issues, such as a loss in market share, might not enter the standard corrective action process but might require a dedicated task force using root cause analysis.
• Resource Allocation Factors: Decisions should be based on:
  • Relative frequency of the problem.
  • Cost impact.
  • Related risks (legal, regulatory, business loss).
  • Opportunity costs (strategic fit, resource availability for other tasks).
• Frequency and Disruption: Even low-cost or low-risk problems occurring at high frequency can disrupt an organization by reducing capacity, affecting on-time delivery, and hindering the ability to take on new business.

Tools for Project Selection and Prioritization

• Decision Table/Matrix: Often called portfolio analysis in Six Sigma. Useful when potential projects are contextually different or when evaluation parameters are difficult to quantify.
  • Table 3.1: Project Decision Matrix Example (Scored as Low = $1$, Medium = $3$, High = $9$):
    • Wrong food delivered to table: Customer impact ($9$), Image ($9$), Speed ($9$), Cost ($3$), Total = $30$.
    • High waitstaff turnover: Customer impact ($1$), Image ($3$), Speed ($3$), Cost ($3$), Total = $10$.
    • Insufficient seating: Customer impact ($3$), Image ($3$), Speed ($3$), Cost ($3$), Total = $12$.
    • Low health-inspection scores: Customer impact ($9$), Image ($9$), Speed ($1$), Cost ($1$), Total = $20$.
• Pareto Diagram: Based on the $80/20$ rule, this tool is used when all problems are in the same context. It helps identify where the greatest problem lies when an organization cannot address everything simultaneously.

Case Study: Scrap Analysis Data (Q1)

• Context: An organization has prioritized reducing scrap. Data from Table 3.2 shows machine, shift, part number (P/N), number of parts, and dollar cost.
• Pareto Analysis Findings:
  • By Department: Department B is the highest contributor by both parts ($88$) and dollars ($2430\,USD$), but not by a wide margin over Department A ($79$ parts) or Department C ($1740\,USD$).
  • By Part Number (P/N): Part X is the greater contributor by number of parts ($185$). Part Y is the greater contributor by dollars ($3220\,USD$).
• Prioritization Strategy: The focus depends on organizational pressure. If cost is the priority, Part Y is the focus; if capacity constraint (number of parts) is the priority, Part X is the focus.
• Pivot Tables: These can display the same data patterns in fewer steps, clarifying which departments contribute most to specific part number scrap costs or quantities.

Data Categorization and Timing Cautions

• Categorization Risks: Breaking down or combining categories in a Pareto analysis can shift priorities. Analysis of customer complaints for a convenience store chain shows that combining "food item damaged" and "non-food item damaged" into "Damaged goods" causes that category to jump to the top of the Pareto chart.
• Frequency vs. Impact: While the Y-axis usually represents frequency/count, priorities may change if the axis represents impact on capacity or other factors.
• The Importance of Timing: Pareto diagrams group data for a specific period, hiding trends. It is essential to use a run chart (data plotted over time) to identify spikes, drifts, or shifts.

Scoping the Problem Appropriately

• Single vs. Multiple Problems: Broad categories like "labeling problems" often mask multiple issues with different causes. Labeling issues might include:
  • Incorrect location on the product.
  • Wrong labels applied.
  • Inaccurate label content.
• Complexity Management: Focusing on all issues simultaneously increases complexity. Resolving the most significant identified sub-issue first increases the signal-to-noise ratio during diagnosis.
• Diagnostic Sequence: An organization might start broad and narrow down during diagnosis, or skip to Step 4 and 5 (Data Collection and Analysis) to obtain information needed to complete Step 1 (Define the Problem).

Components of a Concise Problem Statement

• What: A description of what happened/didn't happen vs. what was desired.
• Where: Geographic location, point in the process, or specific location on the product.
• When: Specific calendar date and time. Avoid generalities like "the past three months."
• How Much: Frequency or magnitude using absolute values. Precise variable/measured data is preferred over attribute/count data.
• Who: Only included if the problem affects a specific group; otherwise, it should be avoided to prevent narrowing the focus prematurely to individuals as the cause.
• Impact Statement: Optional addition specifying actual or potential costs and risks to help individuals understand the project's importance.

Using Run Charts to Inform the Problem Statement

• Run charts help define baseline performance and identify patterns of variation:
  • Example A: A spike that quickly disappears, suggesting a temporary cause.
  • Example B: A slow drift, suggesting gradual degradation.
  • Example C: A shift that eventually shifts back, suggesting a sustained change that was later reversed.

Evaluation of Sample Problem Statements

• "Computer downtime is too high": Poor. Unclear location, duration, magnitude, and definition of "downtime" (e.g., breakdown vs. maintenance).
• "Percentage of vehicles not ready for pickup has increased": Mediocre. Needs the absolute increase amount, identification of customer types, and specific dates instead of "past three months."
• "45 percent of fourth graders meet test requirements": Needs specific schools, classrooms, subjects, and the total number of students to be actionable.
• "Mary, who herds her sheep in Barry, lost three lambs to illness this year; in the past five she lost none": Good. Defines the person (extension of where), location, specific magnitude, and timing comparison.

Cautions and Pitfalls in Problem Definition

• Operational Definitions: To avoid ambiguity, use recognized terminology or provide specific operational definitions. Example: Two hospitals comparing "Operating Room (OR) time" found discrepancies because one hospital started the clock at a different point than the other.
• Is/Is-Not Analysis: While useful for comparison, one must be careful as "nots" may be "not yets." Premature conclusions can lead to faulty perceptions.
• Excluding Cause from Definition: A problem statement must NOT include the "how" or "why." Specifying cause prematurely (e.g., assuming equipment failure was "accidental" when it was actually "intentional") can misdirect the diagnosis for months.
• Audit Findings as Symptoms: Audit nonconformities (e.g., "Two associates in machining have not been trained in SPC") are often just symptoms because auditors rarely establish when the problem began or the full degree of the problem via large sample sizes.