The Improve Phase, deep-dive course
From confirmed root causes to a piloted, statistically validated fix — solution generation, selection, cost-benefit analysis, poka-yoke, and rollout, worked through the same mid-sized IT project.
What is the Improve phase?
Analyze found and statistically confirmed the vital few root causes. Improve is where the team turns those confirmed X's into an actual fix — generating real solutions, picking the best one with evidence rather than opinion, proving it works on a small scale, and rolling it out for real.
Improve typically runs 8 to 10 weeks — the longest phase in DMAIC, because it covers everything from brainstorming to a live pilot to full implementation.
Identify feasible solutions
Generate real options for each confirmed root cause — not just the first idea anyone suggests.
Select the best solution
Use statistical tools and structured criteria — not the loudest voice in the room — to pick what to build.
Cost-benefit analysis
Prove the selected solution is worth the investment before committing real budget and time.
Test
Pilot the fix on a small scale and confirm — statistically — that it actually moves the Y before rolling it out everywhere.
Where the Service Desk Project stands
- Define: validated problem (3.6-day average resolution vs. 1-day SLA) and goal (get to 1 day within 6 months).
- Measure: validated baseline; MSA confirmed the data is trustworthy; ticket times are right-skewed.
- Analyze: confirmed vital X's — queue wait time (strong driver, R²=0.99), ticket category (hardware tickets take significantly longer), and an interaction effect between auto-routing and triage training that cuts resolution time far more than either change alone.
- Now — Improve: turn those three confirmed X's into real solutions, pick the best combination, prove the cost is worth it, mistake-proof it, pilot it, and roll it out.
Tools Used in the Improve Phase
| Category | Tools |
|---|---|
| Generating solutions | Brainstorming, benchmarking, best-practice research |
| Organizing & filtering | Affinity diagram, feasibility/impact screening |
| Selecting the best solution | Pugh matrix, weighted criteria matrix, DOE results, hypothesis testing |
| Justifying the investment | Cost-benefit analysis, payback period |
| Mistake-proofing | Poka-yoke, updated FMEA |
| Testing the fix | Pilot studies, before/after hypothesis testing |
| Rolling out | To-be process map, implementation plan, training plan, standard operating procedures |
1. About how long does the Improve phase typically take?
2. What does Improve start with?
From Root Cause to Piloted Fix
Every tool in this course fits into one repeatable flow. This is the backbone of the whole Improve phase.
Generate potential solutions
Brainstorm and benchmark real options for each confirmed root cause.
Organize and filter the solutions
Group related ideas with an affinity diagram, then screen out the clearly infeasible ones.
Select the best solution(s)
Score the shortlist against criteria and statistical evidence — a Pugh matrix, DOE results, hypothesis tests.
Perform a cost-benefit analysis
Confirm the selected solution is worth the investment before committing budget.
Mistake-proof the solution
Build in poka-yoke controls so the old failure modes become impossible, not just less likely.
Pilot and statistically validate
Test on a small scale and confirm — with a real hypothesis test — that the fix actually works.
Build the implementation plan and roll out
Train, document, and deploy broadly with a clear timeline.
Monitor early results
Confirm the full-scale rollout is holding, then hand off to Control.
1. What comes right after "select the best solution(s)" in the Improve flow?
2. Why does piloting happen before full rollout?
Brainstorming and Affinity Diagrams
For each confirmed root cause from Analyze, the team brainstorms every plausible fix — quantity first, judgment later — then uses an affinity diagram to group the raw ideas into natural themes before evaluating any of them.
IT example — brainstormed solutions
Given the three confirmed root causes (queue wait time, hardware-category delays, and the auto-routing/training interaction), the team generates ten candidate solutions in a single brainstorming session — everything from rules-engine routing to hiring more staff.
Try it: sort the ideas into an affinity diagram
Assign each brainstormed idea to the theme it belongs with. A correct match turns green.
Routing & Assignment
Staffing & Scheduling
Category-Specific Handling
Data Quality & Mistake-Proofing
0 of 10 sorted correctly.
1. What is the main rule of a good brainstorming session?
2. What does an affinity diagram do with a large set of brainstormed ideas?
TRIZ, 5S, and Takt Time
Before scoring the brainstormed list, three more tools help sharpen or size the solutions themselves.
TRIZ (Theory of Inventive Problem Solving)
TRIZ is a systematic approach to breakthrough solutions, built around resolving contradictions — improving one factor without making another one worse — using a library of proven inventive principles instead of random brainstorming.
IT example — TRIZ
The contradiction: the team wants tickets resolved faster (less time) without adding headcount (more cost). TRIZ's "segmentation" principle — breaking one thing into independent parts — points directly at splitting the single generalist queue into specialized sub-queues (hardware fast-track, auto-routed categories). TRIZ didn't invent a new idea here so much as it explains, systematically, why that idea works.
5S
5S is a workplace-organization method: Sort, Set in Order, Shine, Standardize, Sustain. It's usually applied to physical workspaces, but it maps cleanly onto a digital one.
| Step | IT example |
|---|---|
| Sort | Remove unused shortcuts, tabs, and tools from the agent desktop |
| Set in order | Arrange the most-used tools and ticket views front and center |
| Shine | Keep dashboards and knowledge-base articles current, not stale |
| Standardize | Every agent uses the same tool layout and naming conventions |
| Sustain | A recurring monthly audit keeps the setup from drifting back to clutter |
This directly attacks the Motion waste flagged in Analyze — agents switching between three tools just to see one ticket's history.
Takt Time
Takt time is the pace work needs to move at to match customer demand: Takt time = Available working time ÷ Customer demand.
IT example — takt time
The service desk runs 8 hours/day (480 minutes) and receives about 40 new tickets per day. Takt time = 480 ÷ 40 = 12 minutes. On average, the desk needs to start work on a new ticket every 12 minutes just to keep pace with demand — a concrete target for right-sizing the staffing schedule, not just a vague sense that "we're understaffed."
1. TRIZ is primarily built around resolving:
2. If a desk runs 600 minutes/day and receives 50 tickets/day, what's the takt time?
Matrix Diagrams and the Prioritization Matrix
A matrix diagram lays two or more sets of items against each other in a grid to show how they relate — solutions against criteria, causes against effects, and so on. The Prioritization Matrix is the specific version built for this step: it scores every candidate solution against a shared set of weighted criteria, so the "best" solution is a calculated result, not a vote or a gut feeling.
Why and when to use a prioritization matrix
Use it whenever there's more than one viable solution and more than one criterion that matters — cost, impact, speed, risk — especially when stakeholders disagree about priorities. Agreeing on the criteria and their weights before scoring anything is what keeps the result objective instead of political.
| Solution | Impact (40%) | Cost (20%) | Speed (20%) | Risk (20%) | Weighted score |
|---|---|---|---|---|---|
| Auto-routing rules engine | 5 | 3 | 3 | 4 | 4.0 |
| Extra triage training | 4 | 4 | 4 | 5 | 4.2 |
| Realign staffing schedule | 4 | 5 | 3 | 4 | 4.0 |
| Hardware fast-track queue | 3 | 2 | 2 | 3 | 2.6 |
| Poka-yoke ticket-form controls | 3 | 5 | 5 | 5 | 4.2 |
Scores are 1 (worst) to 5 (best) on each criterion, weighted and summed. All four leading solutions score close together and get bundled together; the hardware fast-track queue scores lowest — mainly on cost and speed to implement — and is deferred to a later round.
Backed by Analyze's statistics, not just the matrix
The matrix isn't the only evidence: Analyze's DOE already proved auto-routing and training together cut resolution time from 86 to 42 hours — a genuine interaction effect. The prioritization matrix and the DOE point at the same bundle, which is exactly the kind of agreement that makes a selection defensible at a gate review.
1. What makes a prioritization matrix more objective than an open group vote?
2. In the IT example, why was the hardware fast-track queue deferred?
Cost-Benefit Analysis
Before anything gets a pilot budget, each solution — and the bundle as a whole — gets priced against what it saves. The simplest useful metric is the payback period: one-time cost ÷ annual benefit, expressed in months.
| Solution | One-time cost | Annual benefit | Payback period |
|---|---|---|---|
| Auto-routing rules engine | $18,000 | $52,000 | 4.2 months |
| Extra triage training | $9,000 | $31,000 | 3.5 months |
| Realign staffing schedule | $4,000 | $19,000 | 2.5 months |
| Poka-yoke ticket-form controls | $6,000 | $24,000 | 3.0 months |
| Full bundle (all four) | $37,000 | $126,000 | ~3.5 months |
Cost vs. annual benefit, at a glance
IT example — reading the numbers
Every solution pays for itself in under five months, and the full bundle returns roughly $89,000 in net benefit within the first year against a $37,000 investment — an easy case to bring to the Improve gate review, especially paired with the DOE's statistically confirmed 86→42 hour improvement.
1. How is payback period calculated?
2. Roughly what net benefit does the full bundle return in year one?
Poka-Yoke (Mistake-Proofing)
Poka-yoke — Japanese for "mistake-proofing" — designs a process so an error either can't happen at all, or is caught immediately if it does. It's the difference between training people to be careful and building a system where carelessness has nowhere to go.
| Type | What it does | IT example |
|---|---|---|
| Prevention control | Makes the error physically or logically impossible | Ticket category field is a locked dropdown, not free text — an invalid category can't be typed in |
| Detection control | Catches the error the instant it happens, before it propagates | The form blocks submission and highlights any missing required field |
IT example — poka-yoke ticket-form controls
This is the same solution that tied for the top prioritization-matrix score. The redesigned intake form: (1) forces category selection from a validated list instead of a free-text field, (2) auto-populates the asset tag from the requester's known device inventory instead of manual entry, and (3) won't submit without a priority level. Together, these remove the single biggest source of the mis-categorized tickets that were driving the ANOVA and chi-square differences confirmed in Analyze.
1. What is the core idea behind poka-yoke?
2. Locking the ticket category to a dropdown menu is an example of a:
Pilot Plan
A pilot plan is an experimental or preliminary trial or test of your solution on a limited scale — proof before commitment, run on the exact project this course has been building throughout Define, Measure, and Analyze.
Building the pilot on this project
| Pilot element | IT example |
|---|---|
| Scope | Run the solution bundle (auto-routing, extra triage training, poka-yoke form, realigned schedule) on the Tier-1 hardware queue only — not company-wide |
| Duration | 3 weeks — long enough to smooth out a first-week learning curve, short enough to limit exposure if it underperforms |
| Baseline to beat | The Measure-phase baseline of 3.6 days average resolution against a 1-day SLA, and the Analyze DOE's confirmed 42-hour result for the routing × training combination |
| Success criteria | Pilot-queue average resolution time statistically lower than baseline (2-sample t-test, α = 0.05), with no rise in reopened-ticket rate |
| Rollback trigger | If reopened-ticket rate rises more than 2 points, pause the pilot and investigate before continuing |
IT example — validating the pilot statistically
At the end of the 3-week pilot, the team runs the same kind of 2-sample t-test used in Analyze: pilot-queue resolution times vs. the pre-pilot baseline. A statistically significant drop — not just a lower average by chance — is what earns the solution a green light to scale past the pilot queue.
1. A pilot plan is best described as:
2. Why compare pilot results with a formal statistical test rather than just eyeballing the average?
Process Decision Program Charts (PDPC)
A Process Decision Program Chart maps out a plan step by step, then asks "what could go wrong here?" at each step and pre-plans a countermeasure — so the pilot doesn't stall the first time reality disagrees with the plan.
IT example — pilot PDPC
Launch auto-routing on the pilot queue
What could go wrong: rules engine misclassifies an unusual ticket. Countermeasure: automatic fallback to manual triage queue for anything the engine flags as low-confidence.
Roll out triage training
What could go wrong: some agents can't complete training before pilot start. Countermeasure: pair untrained agents with a trained mentor for their first pilot week.
Switch on the poka-yoke ticket form
What could go wrong: the new required fields slow down intake at first. Countermeasure: monitor intake time daily for week one; simplify the form if it exceeds a 90-second threshold.
Realign the staffing schedule
What could go wrong: a shift gap opens during the transition. Countermeasure: keep the old schedule as an on-call backup for the first pilot week.
1. What is the main purpose of a PDPC?
2. In the example, what's the countermeasure if the auto-routing engine misclassifies a ticket?
Implementation Plan
Successful implementation of a Six Sigma initiative requires thorough planning. An implementation plan covers five categories the project owner needs to consider for a fool-proof rollout.
| Category | IT example |
|---|---|
| Work Plan | Sequenced tasks and timeline for rolling the pilot bundle out past the Tier-1 queue to the full service desk over 4 weeks |
| Resource Plan | Budget ($37,000), the rules-engine vendor, training-room time, and the agents' hours needed to deliver it |
| Stakeholder Management Plan | Weekly rollout updates to the IT director and desk supervisors; a go-live announcement and quick-reference guide for all agents |
| Risk Assessment Plan | The same risks captured in the pilot's PDPC, now scaled: routing misclassification, training gaps, form slowdowns, schedule gaps — each with an owner and a countermeasure |
| Quality Control Plan | Daily resolution-time and reopened-ticket dashboards for the first 60 days post-rollout, with a defined escalation trigger if performance drifts back toward baseline |
1. Which of these is NOT one of the five implementation plan categories?
2. Ongoing dashboards that watch resolution time and reopened tickets after go-live belong to which category?
Improve Phase of DMAIC Deliverables
Checks are saved in your browser as you go.
Improve Phase Survival Challenge
Three hearts. Answer wrong three times and it's game over — survive all the questions to earn the badge.
Final score:
20-Question Final Quiz
Everything above builds toward this. 70% (14 of 20) or better is a pass.
Quiz complete
Score: / 20