Claims Cycle Time at Northwind Mutual: Flow Problem or Variation Problem?
Northwind Mutual, a regional insurer with 340 claims handlers, takes 22 working days on average to settle a straightforward auto claim; its published promise is 10 days. The operations director has read about Six Sigma and wants to sponsor 15 Green Belt projects, starting with a statistical study of settlement-amount variance. Two facts sit on the table. First, a process walk shows each claim is touched by nine people across four departments, sits in queues for roughly 16 of the 22 days, and 30% of files are returned at least once for missing information. Second, settlement payouts vary widely, but the variation tracks injury type and policy limits rather than process error; only about 6% of claims involve rework that changes the payout. Staff turnover is 28%, and the training budget is capped at 40 hours per person this year. Average work in process is 120 open claims and throughput is 6 settlements per day.
1. Should the director attack cycle time or payout variation first? Justify the choice using Lean Six Sigma principles, not just the numbers.
Read the worked answer
The evidence points to flow, not payout variation. Of the 22-day cycle, about 16 days are queue time, and 30% of files are returned for missing information - classic waiting and rework, i.e. non-value-adding time. The customer CTQ is the 10-day promise, and the largest gap sits in elapsed time. Payout differences track injury type and policy limits: that is variation inherent in the claim itself, not variation created by the process. A core Lean Six Sigma principle is to reduce variation that produces defects against a CTQ; studying payout amount here would mostly model noise and could even pressure handlers toward under-settling. The defensible sequence is to map the value stream, cut queues, handoffs and the 30% returns, then apply DMAIC to the narrower variation questions that remain once flow is stable.
2. Evaluate the proposal of 15 Green Belt projects in year one and propose a defensible alternative.
Read the worked answer
Fifteen projects in one year is tool-led deployment rather than problem-led deployment. Projects should be selected from business need and data (Pareto of pain), each with a sponsor who has authority, a measurable gap, a baseline and a named owner. Capability comes from solving problems, not from headcount trained. Constraints here matter: 340 handlers, a 40-hour training cap, 28% turnover, and no evidence that 15 distinct problems exist. A stronger plan is 2-3 chartered projects (file completeness, queue and handoff design), each with tollgates and a sponsor; an 8-16 hour Yellow Belt awareness programme for supervisors so the vocabulary and basic tools stick; and Green Belt training reserved for people who will actually lead a chartered project. With 28% turnover, also build standard work and visual management so improvement does not live only in individuals who may leave. Revisit the project count after the first wave shows measurable results.
3. Using the WIP and throughput figures, what does Little's law tell you an out to do about it?
Read the worked answer
Little's law: average lead time = WIP / throughput = 120 / 6 = 20 working days, consistent with the observed 22. It reframes the problem: to reach 10 days with throughput fixed at 6 per day, average WIP must fall to about 60 open claims. Because the process is queue-dominated, pushing individuals to work faster yields little; limiting WIP, eliminating the 30% returns and cutting handoffs do. Two cautions belong in the answer. First, this is a diagnostic estimate, not a measurement - WIP and throughput must be counted on the same basis (open at a point in time versus settled per day) or the result is meaningless. Second, the average hides the tail, and the tail is what customers experience. Confirm with time-stamped workflow data before committing to a target.