Demo project: Seal thickness, from complaint to control

A complete Black Belt project run end to end in Analytics. You load each file, click where this guide says, and you should see the same numbers. If you do, you have learned the app and the method together. If you don't, the If something doesn't match section at the end tells you where to look.

Who this is for. A Green or Black Belt whose training went quickly and who still has questions such as "why am I checking normality?", "my data is text, so what now?" or "the data doesn't say what the team was sure of". Every stop answers those questions for this project, and the answers carry over to yours.

How each stop is laid out

• The question the stop answers, in plain words.
• Do this: the file and the clicks.
• You should see: the numbers. Exact means they should match to the digits shown. Close means the app's approximation may differ in the last decimal.
• Why this step: what goes wrong if you skip it.
• What if your data isn't like this: where to go instead.
• Show the math: the formula with this project's numbers in it.
• The trap: the mistake belts most often make at this point.

One rule for the whole project. Call the characteristic Seal_Thickness_mm everywhere. The project board matches records by that name, and a different spelling in one study makes the board look broken.

Eight words you will meet

Read these once before you start. Every stop uses them.

The files

Get them with Download the demo files on the app's front page. They are listed here in the order you use them.

DP2 and DP6 are the same data as the Seal thickness worked example, so the numbers in that example and in this guide agree.

The scenario. An injection-moulded gasket line. Seal thickness is the customer characteristic. Specification 2.000 ± 0.150 mm, so LSL 1.850, USL 2.150, target 2.000. About 5,400 seals were made in June.

DEFINE

Stop 1: What is actually going wrong?

Do this. Load DP1_define_reject_log_june.csv. Open Pareto. Category variable = Reject_Reason. Leave the count variable on None (count occurrences). Generate.

You should see eight bars, with "Too thick" appearing twice: 162 in one bar and 9 in another, near the end. (exact)

That's not an app fault. Nine rows were typed as Too thick with a space at the end, and to a computer that is a different word. Go to Reshape, filter and clean → Clean, tick Trim whitespace from text, apply, and use the cleaned data. Run the Pareto again:

(exact)

Why this step. A project needs one Y. The Pareto chooses it from evidence rather than from whoever complained most recently. Here one reason is more than half of all rejects, so the project is about seal thickness running high. It is not about thickness in general: one seal in 312 was too thin.

What if your data isn't like this.

• My data is text (reasons, defect names, locations). Then it is counted, not measured. Use a Pareto, never a t-test or a capability study. Text data becomes numbers only by counting it.
• I have counts already (reason plus a number). Put the number column in the count variable.
• My categories are spelled differently ("Too thick", "too thick", "Thick"). Trimming fixes stray spaces. Different spellings must be fixed in the source sheet before loading. Agree a short fixed list of reasons with the inspectors: it saves you this step on every project.
• No bar is bigger than the others. The problem may be split wrongly. Try another category (by product, by line, by shift) before choosing a Y.

Show the math. % = count ÷ total = 171 ÷ 312 = 54.8%. Cumulative % adds the bars from the left: 54.8 + 18.6 = 73.4.

The trap. A split bar makes the top reason look smaller than it is. Before trimming, "Too thick" showed 51.9% and 2.9% in two places. Always read the whole category list before trusting the order.

The project card

On the Project (DMAIC board), fill the project card:

Problem statement (for the report): "In June 2026, 171 of about 5,400 seals (3.2%) were rejected as too thick, over the 2.150 mm upper limit. Too thick is 55% of all rejects. The goal is Cpk ≥ 1.33 and thickness rejects below 0.1% by the end of August."

A good problem statement names what, how much, when and where, and does not name a cause. "Rejects are high because the night shift is careless" is a conclusion wearing a problem statement's clothes. Keep it out, because the data at Stop 6 will disagree with it.

MEASURE

Stop 2: Can I trust the gauge?

Do this. Load DP2_measure_gauge_study.csv. Open the Gage R&R Guide. Part = Part, Operator = Operator, Measurement = Seal_Thickness_mm, tolerance 0.300 (or LSL 1.850 and USL 2.150).

You should see

%GRR 5.50% · %Tolerance 8.20% · ndc 25 · ACCEPTABLE (exact). The part × operator interaction has p = 0.835, so it is pooled into repeatability.

Why this step. Every number from here on is a number the gauge gave you. If the gauge is poor, the process will look worse than it is, and you may spend months "improving" a process that was never the problem.

What if your data isn't like this.

• Pass/fail by eye, not a measurement. Use Attribute agreement, not Gage R&R.
• The test destroys the part (tensile, burst, chemical). Nobody can measure the same part twice, so it is a nested study. The guide asks and routes you there.
• My "operators" are really shifts. The guide checks for this. Shifts are not people, and the study will blame the wrong thing.
• Only one gauge and one person. A Type 1 gauge study (MSA tools) checks repeatability and bias against a reference part.

Show the math. %Study Var = GRR SD ÷ total SD = 0.00410 ÷ 0.07453 = 5.50%. The number of distinct categories is ndc = 1.41 × part SD ÷ GRR SD = 1.41 × 0.07442 ÷ 0.00410 = 25.6, truncated to 25. Below 10% is acceptable and ndc of 5 or more lets the gauge tell parts apart. This gauge passes both comfortably.

The trap. %Contribution (0.30%) and %Study Var (5.50%) describe the same gauge on different scales, with different thresholds. Quoting 0.30% against a 10% rule makes a gauge look better than it is. The app keeps them in separate columns for that reason.

Stop 3: Is the process stable?

Do this. Load DP3_measure_baseline_june.csv. Open the Control Chart Guide. Column = Seal_Thickness_mm, group column = Subgroup, rows are in time order. Subgroups of 5 → the guide names X̄-R.

You should see

(exact). The X̄ points out are subgroups 10 and 15 (above) and 12, 21 and 23 (below). Verdict: not stable.

Why this step. Read the range chart first. It shows whether spread within a subgroup is steady. It is (0 out), so the X̄ limits can be trusted. The X̄ chart then says the average moves from day to day far more than five seals made together would suggest. Something changes between subgroups. Find it and the project is largely solved.

What if your data isn't like this.

• One reading at a time, no subgroups. The guide names I-MR. That's correct, not second best.
• Counts of defects or defectives, not measurements. The guide asks, and names p, np, c or u.
• The range chart is out of control. Stop reading the X̄ chart. Its limits are built from the ranges, so they are wrong. Fix the inconsistency within subgroups first. The guide calls this LIMITS NOT RELIABLE.
• Rows are not in time order. A control chart is a time series. Sort by date and time first, or the chart means nothing.

Show the math. X̄ limits = X̿ ± A2 × R̄ = 2.05426 ± 0.577 × 0.07816 = 2.05426 ± 0.04510, giving 2.00916 to 2.09936. R upper limit = D4 × R̄ = 2.114 × 0.07816 = 0.16523. A2 and D4 are table constants for subgroups of 5.

The trap. Drawing the specification limits on an X̄ chart. The specification is for single seals, but an X̄ chart plots averages of five, which vary much less. Every average can sit inside the spec while individual seals fall outside it. The app does not draw them, deliberately.

Stop 4: What can the process hold today?

Do this. Same file. Open the Capability Guide. Column = Seal_Thickness_mm, LSL 1.850, USL 2.150, target 2.000. Step 2: in time order, readings taken as a group, group column = Subgroup. Leave the within-sigma selector on Pooled standard deviation.

The guide will warn that the process is not stable before it shows any index. That warning is correct and is the point of this stop. Continue to see the numbers, and read them with the warning in mind.

You should see

Why this step, and how to read four indices without getting lost. Ask two questions in turn:

1. Cp against Pp (1.50 against 0.97): is drift the problem? Cp uses the short-term spread within a subgroup. Pp uses the whole month. The machine's short-term precision is good enough for the job (Cp 1.50), but over the month the product spreads far wider. That gap is the day-to-day movement you saw on the X̄ chart.
2. Pp against Ppk (0.97 against 0.62): is centring the problem? The process runs at 2.054 against a target of 2.000, so the upper limit is close and the lower one is far away.

So the customer receives Ppk 0.62, the machine is capable of Cp 1.50, and the whole difference is drift plus off-centring. Neither needs a new machine. That one sentence tells the sponsor what kind of project this is.

The expected 3.2% out of spec agrees with the reject log: 171 of about 5,400 seals is 3.2%. When two independent sources agree, you can trust both.

What if your data isn't like this.

• Normality fails. Don't transform first. Ask why. A skewed process may be naturally skewed (flatness, roundness, impurity near zero), so use the Non-Normal Capability Guide. Or it may be two processes mixed together, which the control chart usually shows.
• Only one limit (a maximum, say). Enter only that limit. Cpk becomes CPU (or CPL), and Cp does not exist.
• My data is pass/fail. Capability is then the defect rate (ppm or %), not Cpk.
• The process is not stable, as here. Report Ppk as what the customer gets today. Don't quote Cpk as a promise: it describes a process you don't yet have.

Show the math.

• Pooled within σ = Sp ÷ c4 = 0.03327 ÷ 0.99750 = 0.03336.
• Cp = (USL − LSL) ÷ 6σ = 0.300 ÷ (6 × 0.03336) = 1.499.
• CPU = (USL − mean) ÷ 3σ = (2.150 − 2.05426) ÷ (3 × 0.03336) = 0.957. This is Cpk, because the upper side is the near one.
• Ppk uses the overall SD instead: 0.09574 ÷ (3 × 0.05162) = 0.618.
• The Cpk interval: SE = √(1 ÷ 9N + Cpk² ÷ 2ν) = √(1 ÷ 1125 + 0.9152 ÷ 200) = 0.0739, where ν = N − subgroups = 100. So 0.957 ± 1.96 × 0.0739 = 0.812 to 1.102. The whole interval is below 1.33: this process is not capable, and that is not in doubt.

The trap. Reporting Cpk 0.96 as "nearly capable". On an unstable process, Cpk describes a process that exists only in short bursts. The customer receives the Ppk process.

ANALYZE

Stop 5: What could cause the drift? Pick the test by the type of X.

The team's fishbone produced three suspects, and each of them has a supporter:

This table is the most useful thing a shaky belt can learn. The test is chosen by the type of Y and the type of X, never by which test you learned last:

The Which test? Guide asks you these two questions and names the test.

Why a new file with 25 rows, not 125? Look at DP3. All five seals in a subgroup share one die temperature, one speed and one shift, because they were made together. For temperature, speed and shift, June gives you 25 observations, not 125. Testing on 125 rows counts every day five times and makes weak effects look significant. DP4 holds one row per subgroup, with the average thickness.

This is the assumption called independence. It appears in every test's list of assumptions and is the one belts skip most often. Ask: "Does each row carry new information about the X I'm testing?"

Stop 6: Is the night shift worse?

Do this. Load DP4_analyze_by_subgroup.csv. Which test? Guide:

• What are you comparing: Two independent groups
• Response: Continuous
• Sample size per group: Fewer than 15

Y = Avg_Seal_Thickness_mm, group = Shift.

You should see

• Normality is not rejected in either group (AD p ≈ 0.52 and 0.76, close).
• Equal spreads, Brown-Forsythe p ≈ 0.73 (close).
• Welch t = 0.789, df = 23.0, p = 0.438 (exact).
• Difference Day − Night = +0.0136 mm, 95% CI −0.0220 to +0.0491.

Read it like this. p = 0.44, so the data cannot tell the shifts apart. If anything, the day shift runs slightly thicker, the opposite of the story.

Say it correctly. Not "the shifts are the same". The interval runs from −0.022 to +0.049 mm, and a 0.049 mm difference would matter. The honest sentence is: "June's data gives no evidence that shift matters, and shift cannot explain the day-to-day swings we saw, which are larger than this whole interval." The second half of that sentence is what closes the question.

Why this step. Blaming people is the easiest root cause to reach for and the most damaging one to get wrong. Testing the belief with data, then publishing the result, protects the night shift and keeps the team's trust.

What if your data isn't like this.

• Normality fails with small groups. The guide switches to Mann-Whitney and says so.
• The spreads differ. Welch handles it, which is why it is the default. Report the spread difference too: it may be the finding.
• Three or more groups (three shifts, four lines). ANOVA, or Welch ANOVA if spreads differ, then comparisons to find which groups differ.
• Same items measured twice (before and after on the same parts). That's paired, a different test. Choosing two-sample by mistake loses most of the power.

Show the math. t = difference ÷ √(s₁²/n₁ + s₂²/n₂) = 0.01355 ÷ √(0.04542²/13 + 0.04051²/12) = 0.01355 ÷ 0.01719 = 0.789.

The trap. Running this test on the 125-row file. Every day counts five times, the p-value shrinks, and a real-looking "shift effect" can appear from nothing.

Stop 7: Is it line speed?

Do this. Same file. Regression & correlation → Regression, simple linear. Y = Avg_Seal_Thickness_mm, X = Line_Speed_m_min.

You should see slope +0.00107 mm per m/min, p = 0.736, R² = 0.5% (exact). Practical significance: EXPLAINS ALMOST NOTHING.

Read it like this. Across June, speed ran from 42 to 50 m/min and thickness did not follow it. Knowing the speed tells you nothing about the thickness. The belief was reasonable, and the data doesn't support it.

The good news in a "no". If speed doesn't affect thickness, speed may be a free lever: the line could run faster without hurting quality. Stop 9 tests that directly.

Stop 8: Is it die temperature?

Do this. Same file and tab. X = Die_Temp_C.

You should see

(exact)

Read it like this. Each degree hotter makes the seal about 0.010 mm thicker. June's die temperature wandered from 204.5 to 219.8 °C, which alone moves thickness by 0.16 mm, more than half the whole tolerance. Subgroup 10, the highest point on the X̄ chart, was the hottest day (219.8 °C).

To centre the process at 2.000 mm: (2.000 + 0.1263) ÷ 0.010355 = 205.3 °C. June averaged 210.6 °C.

Why this step, and why it isn't the end. This is June's data as it happened, not an experiment. It shows that temperature and thickness move together. It cannot prove that changing the temperature will change the thickness: something else could drive both. Stop 9 proves it by setting the temperature on purpose.

What if your data isn't like this.

• The plot curves. A straight line is the wrong model. Try polynomial regression, and check the residual plot either way.
• Several Xs at once. Multiple regression, but check that the Xs are not strongly related to each other. Here temperature and speed have r = 0.16, which is fine.
• Y is pass/fail. Logistic regression.
• R² is high but the verdict is weak. Believe the verdict. It measures how much the model narrows the prediction you would quote, which is what you use it for.

Show the math. Practical significance = 1 − S ÷ SD(Y) = 1 − 0.0155 ÷ 0.0428 = 0.638. The model removes about 64% of the spread you would have to quote. The ±0.030 band is 1.96 × S.

The trap. Stopping at "p < 0.05, root cause found". A p-value says an effect is real, not that it is big. Line speed could have been "significant" with enough data and still been useless. Read R² and the practical-significance verdict alongside p.

IMPROVE

Stop 9: Prove it, and find the settings. A designed experiment.

The team agreed to test three factors on purpose in one day. Each run made five seals and recorded their average.

That is 2³ = 8 combinations, each run twice (16 runs), plus 4 runs at the centre = 20 runs in random order.

Do this. Open the DOE Guide. Under Or bring completed data, upload DP5_improve_doe_july.csv. Map the columns:

• Factors: Die_Temp_C, Line_Speed_m_min, Cooling_s
• Response: Seal_Thickness_mm
• Block: Blocks
• Centre-point column: CenterPt

Fit the full model.

You should see (full model with the centre-point term)

S = 0.0216, R² = 90.4%. Effects and coefficients are exact. p-values are close, because they depend on which terms are in the model.

Remove the terms that are not significant (by hand, or with backward elimination). The model keeps temperature and cooling:

Thickness = 0.0434 + 0.01006 × Die_Temp_C − 0.01075 × Cooling_s, with S 0.0185 and R² 89.2% (close).

Read it like this.

1. Temperature is confirmed as a cause. When it was changed on purpose, thickness followed, by 0.0101 mm per °C. June's regression said 0.0104. Two independent methods agree.
2. Cooling time is a second lever that June's data could not show, because nobody changed it in June. Longer cooling gives a thinner seal.
3. Speed does nothing to thickness, now tested on purpose. The line can run at 50 m/min.
4. No curvature (p = 0.57), so straight lines between the settings are good enough.

The new settings: die temperature 205 °C, cooling 10 s, speed 50 m/min. Predicted thickness 1.998 mm. Temperature to be controlled, not just set: June's problem was that it wandered.

Why this step. Data you collect by watching (Stops 7 and 8) shows association. Data from an experiment shows cause, because you set the X and nothing else could have moved it. Tollgate reviewers ask "how do you know?", and this stop answers them.

What if your data isn't like this.

• Too many factors (6 or more). Screen first with a fractional factorial or Plackett-Burman, then study the few that matter.
• Curvature is significant. Straight lines are not enough. Add axial runs (central composite) to find the true best point.
• A factor is hard to change (a furnace temperature that takes hours). Use a split-plot design. Randomising it anyway ruins the error estimate.
• You need to balance several responses (thickness, cycle time, energy, cost). That is an optimisation problem, and it is where the companion Optimisation app comes in. [Link to follow: the Optimisation app is in development.]

Show the math. Effect of temperature = average at 210 °C − average at 200 °C = 2.04689 − 1.94630 = 0.10059 mm over 10 °C. Coefficient = effect ÷ 2 = 0.0503, because coded units run from −1 to +1, a distance of 2.

The trap. Running the experiment in standard order (all low temperatures first, then all high). If the machine warms up during the day, the warm-up looks like a temperature effect. Randomising the run order is what makes a designed experiment trustworthy.

Stop 10: Did it work? The pilot.

August ran at the new settings with the temperature controller retuned.

Do this. Load DP6_improve_pilot_august.csv. Capability Guide, same entries as Stop 4, group column Subgroup, pooled standard deviation.

You should see

(exact, except the ppm, which is close)

Read it like this.

• Cp didn't move (1.50 → 1.50). The machine's short-term precision is exactly what it was. The project didn't touch it, and didn't need to.
• Ppk went from 0.62 to 1.38 because the drift is gone (overall SD fell to meet within σ) and the process is recentred. That is exactly what Stop 4 predicted, which is a strong sign the diagnosis was right.
• The reject goal is met clearly: about 18 ppm against a goal of 0.1% (1,000 ppm).
• The Cpk goal is met on the estimate but not yet proved. The interval 1.22 to 1.60 contains 1.33. The honest sentence for the sponsor is "we cannot yet show this clears 1.33". Roughly 400 readings at this performance would settle it.
• The pilot runs at 2.009, which is 0.011 mm above the DOE's prediction of 1.998. Using the slope of 0.010 mm per °C, lowering the set point by 1 °C to 204 °C should bring it onto 2.000. That is a free improvement worth trialling.

CONTROL

Stop 11: Show the before and after on one chart

Do this. Load DP7_control_before_after.csv. Control Chart Guide, column Seal_Thickness_mm, group Subgroup, and use Phase as the stage column.

You should see two sets of limits, one per phase:

(exact). The guide's stage test should report that the stages differ.

For numbers to go with the picture, use the Which test? Guide: two independent groups, More than 40, Y = Seal_Thickness_mm, group = Phase. You should see the difference Before − After = +0.0451 mm (95% CI 0.0345 to 0.0557, Welch p < 0.001) and the spread falling 0.0516 → 0.0339, Brown-Forsythe p < 0.001 (close).

A note on rigour. Before-phase readings share a day's temperature (the independence point from Stop 5), so these p-values are smaller than they should be. The conclusion doesn't depend on them: the staged chart shows the change plainly. The staged chart is the evidence. The p-values are the footnote.

Why this step. A staged chart is the picture a sponsor understands in five seconds: the old process, the change, the new process, each with its own limits. It is also what the next person looks at when someone asks "did that project last?"

Stop 12: Hold the gain

Do this.

1. Load DP6_improve_pilot_august.csv again. Control Chart Guide → X̄-R → verdict STABLE (0 points out, longest run 5 against a rule of 9).
2. On Step 4, save these limits as the standard. The card shows centre 2.00914. This also puts the characteristic on the control plan.
3. Open Control plan & handover. Seal_Thickness_mm carries three chips: gauge, capability and chart.
4. On Step 2, type the five things no guide can know, and press Save this row:

The row should now read COMPLETE: charted, capable, measured with a studied gauge, and filled in. 5. On Step 3, type the reaction plan below into the table and press Save this reaction plan, then paste the recommendations further down into the Recommendations box and press Save recommendations. 6. Download the handover pack. It should open with HANDOVER READY on the cover and carry the gauge bar, the histogram and the X̄ and R charts.

A reaction plan that works on the shop floor

Why this step. Improvements fade because the reason for the new settings leaves with the belt. A control plan written in "when you see, do this" form stays with the line.

Recommendations (this is the text box on the final report):

1. Collect about 400 readings at the new settings to confirm Cpk ≥ 1.33. The current interval (1.22 to 1.60) cannot yet settle it.
2. Trial a die temperature set point of 204 °C. The pilot runs 0.011 mm above target, and the slope is 0.010 mm per °C.
3. Keep the line at 50 m/min. Speed has no effect on thickness, so the extra throughput is free.
4. Next project: surface flash, 18.6% of rejects and the second Pareto bar.

The project on one page

What the project taught, in five lines

1. Text data is counted (Pareto). Measurements are tested.
2. Read the range chart before the X̄ chart, and stability before capability.
3. Cp against Pp shows drift. Pp against Ppk shows centring.
4. Choose the test by the type of Y and X. Count your real observations, not your rows.
5. Watching shows association. An experiment shows cause.

Check yourself

Cover the answers and try these. Each one is a decision a belt makes on a real project.

1. Your reject log is a column of typed reasons. Which tool?
2. The range chart has two points outside its limits. Do you read the X̄ chart?
3. Cp is 1.6 and Ppk is 0.7. What kind of problem is it, and which number splits it further?
4. You have 30 oven batches, 10 samples from each, and one oven temperature per batch. How many observations do you have about oven temperature?
5. Cpk is 1.41 with a 95% interval of 1.22 to 1.60, and the goal is 1.33. What do you tell the sponsor?
6. A regression gives p < 0.001, but the verdict reads TOO SMALL TO PREDICT WITH. Do you build the control plan on it?

Answers

1. A Pareto. Text is counted, not measured.
2. No. The X̄ limits are calculated from the average range, so they are wrong until the ranges are steady.
3. Not machine precision: drift, off-centring, or both. Look at Pp. If Pp is close to Cp, it is centring. If Pp is well below Cp, it is drift.
4. 30, not 300. The 10 samples of a batch share one temperature.
5. "The estimate is above the goal, but the data cannot yet prove it." Then say how much more data would settle it.
6. No. The effect is real but too small to steer the process with. Look for the X that explains more.

If something doesn't match

Work backwards.

• Wrong Cpk? Almost always the wrong σ. Check the basis line: it names the estimator. Pooled SD is the default. Average range over d2 gives Cpk 0.950 in June and 1.417 in August.
• Wrong control limits? Almost always the wrong subgroup size, or rows not in time order.
• Wrong Pareto? Check for the trailing-space rows (Stop 1).
• Shift test p is tiny? You used the 125-row file, not DP4.
• DOE p-values differ slightly? Check which terms are in the model. Effects and coefficients must match exactly whatever the model.

Every number here was computed independently of the app, from these same files, with the published formulas. The data were generated once, with a fixed seed, and are plain CSV files, so nothing on your side is random.

© 2025–2026 Dr. Mahmood Al Kindi