Lean Six Sigma Foundations: Problem Solving with DMAIC

A practical introduction to Lean Six Sigma for supervisors, managers and improvement leads in small and mid-sized businesses. You will learn the eight wastes and why variation matters, then work through the DMAIC roadmap: chartering a project, measuring a reliable baseline, finding and verifying root causes, piloting and proving solutions, and holding the gain with control plans and control charts. It covers the foundations a Green Belt uses on a project; it is not a certification.

Course structure

• Module 1: Lean Six Sigma Foundations (4 lessons). How Lean and Six Sigma fit together, the eight wastes, why variation matters more than averages, and how to choose and charter a project.
• Module 2: Define and Measure (4 lessons). Turning customer needs into measurable CTQs, mapping the real process and value stream, collecting trustworthy data and setting the baseline.
• Module 3: Analyze (4 lessons). Narrowing the problem with Pareto charts, listing causes with a fishbone, digging with 5 Whys and verifying causes with graphs and simple tests.
• Module 4: Improve (4 lessons). Generating and selecting mistake-proof solutions, Lean tools for flow, piloting with FMEA and proving the result against the baseline.
• Module 5: Control (4 lessons). Control plans, standard work, control charts, handover to the process owner and a 12-week plan for your first project.

Interactive labs

• Value, necessary or waste?: Sort twelve activities from an order-to-delivery process into value-added, business-necessary or waste, then check your answers. It trains your eye for waste before you map your own process.
• Baseline calculator: DPU, DPMO and sigma level: Enter the units checked, defect opportunities per unit and defects found to calculate DPU, yield, DPMO and process sigma for your baseline.
• Impact and effort: choosing solutions: Place seven possible solutions for an order-error project on an impact/effort grid to see which to do first, which need a plan and which to park.

How it works

• Work through 20 short lessons at your own pace. Each has key takeaways, an exercise for your own workplace and a quick knowledge check.
• Try the three interactive labs as you reach them in the course.
• Pass the 20-question final exam (70% or higher, unlimited retakes) to unlock your Chmltech certificate of completion.
• Free, with no sign-up. Your progress is saved in this browser.

Lean Six Sigma combines two improvement traditions. Lean, which grew out of the Toyota Production System, is about flow: delivering what the customer values with as little waste and waiting as possible. Six Sigma, developed at Motorola and popularized by large manufacturers, is about variation: making a process consistent enough that it rarely produces a defect. Together they ask two questions of any process: where does time and effort go that the customer would not pay for? and why does the result vary from one day, shift or person to the next?

The two traditions share one problem-solving roadmap, DMAIC: Define, Measure, Analyze, Improve and Control. Each phase answers a question before the next one starts, so a team does not jump from a complaint straight to a pet solution.

Why it suits small and mid-sized businesses

You do not need a statistics department. Most SME problems, such as late shipments, rework, quoting errors or long changeovers, yield to simple tools used with discipline: a clear problem statement, a process map, a tally sheet, a Pareto chart and a check that the fix held. The heavier statistics in Six Sigma matter when the easy causes are gone. This course focuses on the tools that pay off first and tells you when to bring in deeper methods.

A word on belts: White, Yellow, Green and Black Belt are training levels that companies and training bodies define in different ways. This course covers the foundations a Green Belt uses on a project. It is not a certification, but it prepares you to run your first DMAIC project well.

Lean sorts every activity into three groups. Value-added work changes the product or service in a way the customer cares about and would pay for, and is done right the first time. Business-necessary non-value-added work does not add value but is required for now, such as legal records or safety checks. Everything else is waste, often called muda.

A handy way to remember the eight wastes is TIMWOODS:

Overproduction is often called the worst waste because it creates several others: extra inventory, transport, storage and the risk that the items become defects or obsolete.

Seeing waste: the gemba walk

Waste is easiest to see where the work happens, which Lean calls the gemba. Walk the process from start to finish, follow one order or one part, and note every stop, move and correction. In many processes the value-added time is a small fraction of the total elapsed time; the rest is waiting and handling. That gap is where Lean finds its biggest and cheapest gains.

Every process varies. Delivery times, fill weights, quote turnaround and machine cycle times are never identical twice. Six Sigma's insight is that customers feel the variation, not the average. If your average delivery is three days but one order in five takes eight, the customer remembers the eight.

Imagine two shipping teams that both average three days. Team A ranges from two to four days. Team B ranges from one to nine. Their averages match, but Team B produces many more late orders. Reducing variation, not just shifting the average, is often what fixes the complaint.

Common cause and special cause

Reacting to common-cause noise as if every bad day had a special reason is called tampering. It usually makes a process more variable, not less, because each adjustment adds its own disturbance.

Look at the data over time

A single average hides both kinds of variation. Plot the data in time order, a run chart, before you summarize it. Patterns such as a steady drift, a sudden shift after a change, or a repeating Monday spike tell you far more than one number. Later lessons add control limits, which turn a run chart into a control chart that separates common from special causes.

Lean Six Sigma works through projects, and projects need clear roles. In an SME one person may wear several hats, but each role should be filled.

Choosing a good first project

Good first projects are important, measurable and contained. They are tied to something the business cares about (cost, delivery, quality, safety or cash), have data you can collect within weeks, and sit mostly within one team's control. Avoid problems where the solution is already decided ("we just need new software"); that is an implementation project, not a DMAIC project.

The project charter

The charter is a one-page agreement between the sponsor and the team. It includes:

• Problem statement: what is wrong, where, since when and how big, with no cause or solution in it.
• Goal statement: the measurable target and the date, such as "reduce quote errors from 8% to below 3% by June 30".
• Scope: where the process starts and ends, and what is out of scope.
• Business case: why it matters now, in money or customer terms.
• Team, roles and timeline: including dates for each DMAIC phase review.

A weak problem statement says "customers are unhappy with shipping". A strong one says "In Q3, 14% of standard orders shipped later than the promised date, up from 6% in Q1, generating about 40 complaint calls a month."

Improvement starts with what the customer needs. The voice of the customer (VOC) is what customers say, through complaints, surveys, returns, sales feedback and interviews. VOC is usually vague: "fast delivery", "accurate invoices", "easy to order". The team translates it into critical-to-quality (CTQ) requirements that can be measured.

Each CTQ needs an operational definition: exactly what counts as a defect. For "on time", decide whether you mean shipped or delivered, which date counts as promised, and how to treat partial shipments. Without this, two people counting the same orders get different answers.

The SIPOC: one page that frames the process

A SIPOC lists Suppliers, Inputs, Process, Outputs and Customers. The process column has only five to seven high-level steps. Its value is agreement: it shows where the project starts and stops, and who supplies and receives what.

Build the SIPOC with the team in under an hour. Disagreement about where the process starts is common and useful: settle it now, not halfway through Analyze.

The SIPOC shows the big picture. A process map shows how the work really flows, step by step, including decisions, handoffs, loops and waits. Map the process as it is today, not as the procedure says it should be. The best way is to walk it with the people who do the work.

A swim-lane map puts each role or department in its own lane. It makes handoffs visible, and handoffs are where delays and errors gather. Every time work crosses a lane line, ask: does it wait here, can information be lost, and does anyone own the handoff?

Value stream mapping

A value stream map (VSM) adds time and flow data to the steps. For each step record the process time (hands-on work) and the waiting time before it. Two summary numbers come out of a VSM:

• Lead time: the total elapsed time from start to finish, for example from purchase order received to order shipped.
• Process cycle efficiency: value-added time divided by lead time.

Suppose an order takes 5 working days from receipt to shipment, but the actual hands-on work is 50 minutes. Almost all of the lead time is queue time: orders waiting in inboxes, for approvals, for stock checks or for a pick wave. That tells the team to attack waiting and batching first, rather than making each step faster.

Find the constraint

In any flow, one step limits the output of the whole process: the bottleneck or constraint. Work piles up in front of it and steps after it wait. Improving any other step does little until the bottleneck improves. Look for the step with the biggest queue in front of it and the highest workload relative to capacity.

Decisions are only as good as the data behind them. Before collecting, write a short data collection plan: what you will measure, the operational definition, where and how it will be recorded, who records it, how many data points and over what period, and which factors to record alongside (shift, product, customer, machine, operator). Those extra factors, called stratification factors, are what let you find causes later.

Types of data

If you can measure "minutes late" instead of just "late or on time", do it. Continuous data shows how far off target you are, not just whether you missed.

Sampling

You rarely need every record. Take a sample that represents the process: across all shifts, days, products and people involved, not just the convenient Tuesday morning. Pull records from the system where possible, since manual tallies drift when people are busy.

Is the measurement system trustworthy?

Measurement system analysis (MSA) checks that the way you measure is reliable before you trust the numbers. For continuous gauges, a gauge R&R study measures how much variation comes from the gauge (repeatability) and from different people (reproducibility). For pass/fail judgements, an attribute agreement check has several inspectors classify the same items, including known good and bad ones, and compares their answers. If two inspectors disagree on a third of the items, fix the definition and training before measuring the process.

With reliable data, establish the baseline: how the process performs before any change. The baseline is what you will compare your results against at the end, so record how and when it was measured.

Measures for defects

• Defects per unit (DPU): total defects divided by units. 46 defects on 2,000 orders is a DPU of 0.023.
• Opportunities: the number of ways one unit can be wrong that matter to the customer. An order line might have four: product, quantity, price and delivery address.
• DPMO: defects per million opportunities = defects ÷ (units × opportunities) × 1,000,000. Here 46 ÷ (2,000 × 4) × 1,000,000 = 5,750 DPMO.
• Sigma level: a conversion of DPMO to a single number using the normal distribution. By convention it includes a 1.5 sigma shift for long-term drift, which is why "six sigma" corresponds to 3.4 DPMO. 5,750 DPMO is about 4.0 sigma.

Be honest about opportunities. Counting trivial ones inflates the denominator and makes performance look better than the customer experiences it. Many teams report DPU or percentage defective to managers and keep DPMO for comparing very different processes.

Capability for continuous data

For continuous CTQs with specification limits, process capability compares the spread of the process with the width of the specification. Cp looks at spread only. Cpk also accounts for how well centred the process is, using the distance from the mean to the nearer specification limit, divided by three standard deviations. A Cpk of 1.33 or higher is a common target; below 1.0 means the process routinely produces output outside specification. Capability only means something if the process is stable, which the control chart lesson covers.

Use the lab after this lesson to calculate DPU, DPMO and sigma level from your own counts.

Analyze begins by narrowing the problem. A Pareto chart sorts defect categories from most to least frequent, with a line showing the cumulative percentage. It applies the Pareto principle: a few categories usually account for most of the problem. The team then focuses on the tallest bars.

Suppose a distributor logs 200 order errors over a quarter: wrong quantity 84, wrong item 52, wrong price 30, wrong address 20, other 14. The first two categories make up 68% of errors, so they become the focus. Two tips: chart by cost or customer impact as well as by count, because a rare error can be the most expensive; and break a large bar down further, for example wrong quantity by product family or by order channel.

The fishbone (cause-and-effect) diagram

Once the focus is clear, the team brainstorms possible causes on a fishbone diagram. The problem sits at the head. Causes branch off categories, often the 6 Ms for manufacturing:

For office processes, categories such as Policies, Procedures, People, Systems and Information often fit better. Keep in mind that a fishbone lists possible causes. It is a map of ideas to test, not a conclusion. The team then picks the most likely causes, by vote or by data, to verify.

5 Whys is a simple way to dig below a symptom. Ask why the problem happened, then ask why that answer happened, and keep going until you reach a cause you can act on, often around five levels.

Example: Orders shipped with the wrong quantity. Why? The picker picked the quantity in eaches instead of cases. Why? The pick ticket shows a quantity without a unit. Why? The ERP field for unit of measure is not printed on the ticket template. Why? The template was set up for a product range that was sold only in eaches. Why? Nobody owns the ticket template, so it was never updated when case products were added. The action is to fix the template and give it an owner, not to "remind pickers to be careful".

Two rules keep 5 Whys honest. First, each answer must be a fact you can check, not a guess. Second, if you reach "human error" or "they didn't follow the procedure", ask why once more: what made the error easy to make?

Verify before you act

A cause is only a root cause when evidence supports it. Ways to verify:

• Stratify the data: if the cause is real, defects should concentrate where it is present, for example on case-pack products or on the night shift.
• Observe: watch the process at the gemba and see the cause happen.
• Turn it on and off: where safe, test whether removing the cause removes the defect and restoring it brings the defect back.
• Check the timing: did the problem start when the suspected cause appeared?

Record each suspected cause with its evidence and a verdict: verified, rejected or not yet tested. This table is the main output of the Analyze phase and the bridge to Improve.

Pictures of data reveal patterns that tables hide. Four graphs cover most of what an SME project needs.

Reading them well

A histogram with two peaks often means the data mixes two different conditions, such as two machines or two order types. Split the data and look again. Box plots are the quickest way to compare groups: if the night shift's box sits well above the day shift's for cycle time, you have a lead worth verifying.

Scatter plots need care. A pattern shows correlation, not causation. Ice cream sales and sunburns rise together because both follow hot weather. In a plant, scrap and overtime may rise together because both follow high volume. Confirm the mechanism through observation or a controlled test before acting.

Example

A food packer finds fill weights vary more than expected. A histogram shows two humps. Box plots by filling head show that one of six heads runs consistently heavy. A check of that head finds a worn seal. The fix is maintenance on one head, not tighter control of all six. Total analysis time: an afternoon with a spreadsheet.

Sometimes the graphs are not conclusive. Is the new supplier's material really better, or did we just have a lucky week? Hypothesis testing answers that question with a known risk of being wrong.

The logic

Every test starts with a null hypothesis: there is no difference or no effect. The test calculates a p-value, the probability of seeing a difference at least as large as the one observed if the null hypothesis were true. A small p-value, commonly below 0.05, means the observed difference would be unlikely if there were really no effect, so you reject the null hypothesis and treat the difference as real.

Two cautions. A p-value is not the probability that your conclusion is right. And "statistically significant" does not mean "important": with enough data, a difference too small to matter can be significant. Always ask whether the size of the difference matters to the customer or the business.

Choosing a test

Spreadsheet tools and statistics packages run these in seconds. The skill is in setting up the question, collecting enough representative data and interpreting the result alongside the graphs. If your project hinges on a subtle difference or many interacting factors, such as setting several process parameters at once, bring in a Black Belt or statistician; designed experiments (DOE) are the right tool there.

Improve starts with the verified root causes from Analyze. Each solution should remove or weaken a verified cause. A solution that does not link to a cause is a guess.

Generating ideas

Involve the people who do the work. Brainstorm many options before judging any. Useful prompts: How would we eliminate this step? Combine it with another? Change the sequence? Simplify it? Make the error impossible? Look at how other teams or industries solve the same problem, and at simple low-cost fixes before technology.

Mistake-proofing (poka-yoke)

The strongest solutions make errors impossible or immediately obvious rather than relying on attention. In order of strength:

1. Eliminate the step where the error can happen.
2. Prevent: design so the error cannot be made, such as a connector that fits only one way or a required system field with a drop-down list.
3. Detect: catch the error at once, such as a scale that alarms on a short pick or a system check that blocks an invoice price that differs from the quote.
4. Mitigate: reduce the impact when it slips through.

Training and reminders are the weakest controls. Use them, but not alone.

Selecting solutions

Score options on impact on the CTQ and effort (cost, time, risk). Plot them on an impact/effort matrix: high-impact, low-effort ideas are quick wins to do first; high-impact, high-effort ideas need planning and a business case; low-impact ideas are parked. For bigger decisions, a weighted criteria matrix scores each option against agreed criteria such as cost, time to implement, customer impact and risk. Use the lab after this lesson to practise.

Many verified causes point to how work flows. Lean offers a toolbox for that.

Batching: the hidden cause of long lead times

Batching feels efficient: approve all quotes on Friday, run all of one product before switching, release picks in two waves a day. But every item in a batch waits for the whole batch. If quotes are approved once a week, the average quote waits two and a half days just for approval. Approving twice a day, or giving a clear authority limit so most quotes need no approval at all, can cut quote turnaround dramatically without anyone working harder.

SMED in brief

Film a changeover. Separate internal tasks (machine must be stopped) from external tasks (can be done while it runs, such as fetching tools and pre-heating dies). Move external tasks out, then simplify internal ones with quick clamps, standard heights and pre-set settings. Shorter changeovers let you run smaller batches, which reduces inventory and lead time.

Before rolling a solution out everywhere, pilot it: one line, one shift, one product family or one customer segment, for long enough to see normal variation. A pilot tests whether the solution works, uncovers side effects and builds confidence among the people who will use it.

Plan the pilot like a small experiment: what you will change, where and when, the measure you will track (the same one as the baseline), what result would count as success, and what you will do if it fails. Keep a log of anything unusual during the pilot.

FMEA: think about what could go wrong

A failure mode and effects analysis (FMEA) looks ahead at how the new process could fail. For each step, the team lists possible failure modes, their effects and causes, and rates three things, usually from 1 to 10:

• Severity: how bad the effect is for the customer or safety.
• Occurrence: how likely the cause is.
• Detection: how likely the current controls are to catch it before it reaches the customer (10 = almost certainly not caught).

Multiplying the three gives a risk priority number (RPN). Many teams now also use an action-priority approach that gives severity extra weight, because a rare but severe failure can deserve action even with a modest RPN. Either way, the team adds actions for the highest risks and re-rates them after the actions are done.

Change is about people too

Explain why the change is needed, involve users in designing it, train before go-live and make it easy to raise problems during the pilot. Most failed improvements fail on adoption, not on technical merit.

At the end of Improve, the team must show that the change worked. That means comparing after data with the baseline, collected the same way: same definition, same source, similar conditions and a long enough period to include normal variation.

Ways to show the change

• Before-and-after run chart: plot the measure in time order with a marker where the change went in. A lasting shift after the marker is strong evidence.
• Before-and-after histograms or box plots: show changes in spread and centring, not just the average.
• A statistical test: where the change is modest, a two-sample or two-proportion test confirms it is more than noise.

Quantifying the benefit

Translate the improvement into money and customer terms the sponsor recognizes. Separate hard savings that reach the financial statements, such as less scrap, lower overtime, fewer credit notes or freight savings, from soft benefits such as freed capacity or better customer experience. Freed capacity is only cash if it is used: to take on more work, avoid a hire or reduce overtime. Ask finance to review the savings method; a credible number protects the project's reputation.

Example

A fabricator's quote error rate was 8.2% over 12 weeks before the project. After adding a quote template with required fields and an automatic price check, it averaged 2.1% over the following 12 weeks, with no week above 3.5%. Fewer errors meant fewer credit notes and less rework of quotes; finance agreed the method for valuing both. The run chart and the savings summary went into the project report for the sponsor's sign-off.

Most improvements fade. People drift back to old habits, new staff are trained the old way, and a system change quietly removes a check. The Control phase builds the habits and safeguards that keep the gain.

The control plan

A control plan is a table that the process owner keeps. For each critical step or CTQ it states:

The reaction plan is the part most often missing. It says exactly what to do when the measure goes out of bounds, so problems are handled the same way every time.

Standard work

Standard work captures the current best way to do a task: the steps in order, key points for quality and safety, and the time each takes. Write it with the people who do the work, keep it short and visual (photos beat paragraphs), and post it at the point of use. Standard work is not frozen. It is the baseline for the next improvement: when someone finds a better way, test it and update the standard.

Training and onboarding

Update training materials and onboarding checklists so new people learn the new method from day one. Many gains are lost at the first staff change.

A control chart is a run chart with a centre line and control limits calculated from the process's own data, usually at three standard deviations of short-term variation either side of the average. Points inside the limits, with no unusual patterns, reflect common-cause variation. Points outside the limits or certain patterns signal a special cause worth investigating.

Control limits come from the process; specification limits come from the customer. Never draw specification limits as control limits. A process can be in control and still not capable of meeting the specification, which is a job for a DMAIC project, not for daily reaction.

Choosing a chart

Common signals of a special cause

• One point outside a control limit.
• A run of eight or so points in a row on one side of the centre line.
• A steady trend of six or so points rising or falling.
• Patterns that repeat, such as every Monday.

Rule sets vary slightly between references; pick one set, write it on the chart and use it consistently. When a signal appears, follow the reaction plan, find the cause and note it on the chart. When there is no signal, do not adjust the process; that is tampering.

Recalculate control limits only after a deliberate, verified change to the process, not every month.

A DMAIC project ends with a formal handover to the process owner. The project lead does not keep running the new process; the owner does. The handover meeting confirms:

• Results against the goal, with the before-and-after evidence.
• The control plan, standard work and updated training, all in their permanent home.
• Who reviews the key measure, how often, and at which meeting.
• Open actions, owners and dates.
• Lessons learned and ideas for the next project.

The sponsor signs off the project and the savings method. Celebrate the team's work; recognition is one of the cheapest ways to build an improvement culture.

Visual management

Make the key measure visible where the work happens: a whiteboard, a screen or a simple chart updated daily. Good visual management lets anyone see within seconds whether the process is on track and what is being done about problems. Pair it with a short daily or weekly team huddle that reviews the board, logs issues and assigns actions.

Check that it held

Schedule follow-up reviews, for example at 30, 60 and 90 days after handover, comparing performance with the improved level. If performance slips, use the reaction plan and find out why: often a new person, a new product or a system change has bypassed a control. The 90-day review is also a good time to confirm the savings with finance.

From project to habit

One successful project proves the method. A habit forms when leaders ask about data and root causes at regular meetings, when staff ideas are welcomed and acted on, and when each project's lessons feed the next selection of problems.

A first DMAIC project in an SME typically takes 8 to 16 weeks of part-time effort, depending on how fast data can be collected and how big the changes are. A 12-week plan is a good starting shape.

Habits of successful first projects

• Keep scope tight. It is better to fix one product family or one order type well than all of them halfway.
• Meet weekly for 45 to 60 minutes with a short action log, and hold a brief gate review with the sponsor at the end of each phase.
• Collect data early. Data collection is the most common cause of delay; start it in week 2 or 3.
• Do safe quick wins as you go. If the team finds an obvious, low-risk fix, implement it and note it, rather than holding it for Improve.
• Tell the story simply. A one-page summary, often called an A3, shows the problem, baseline, causes, actions and results on one sheet.

After your first project, take stock: what worked, what slowed you down and which problem should come next? Practice tests on the Training page can help you and your team check your understanding as you build skills.