CSSYB common mistakes
CSSYB · Understand the traps and how to avoid them.
When a scenario asks what the team should do next, the candidate selects a Black Belt–level technique - a hypothesis test, a designed experiment, or a regression model - because it sounds more rigorous than the basic tool the stem actually supports.
Belt-level tool lists are studied as one undifferentiated catalogue, so candidates equate 'more advanced' with 'more correct' and pick the most technical option offered.
What to do instead
Before choosing, ask which belt role owns the action. A Yellow Belt works with flowcharts, check sheets, Pareto charts, cause-and-effect diagrams, 5 Why, run charts, and basic control charts, and escalates statistical design and formal analysis to Green/Black Belts. Strike out any option that requires designing an experiment or running a test of significance unless the stem says the belt is leading that analysis.
Reads the sigma-level scale backwards - treats a higher sigma level as meaning more defects, or recalls six sigma as 'six defects per million' or '3.4%' instead of 3.4 defects per million opportunities.
Sigma level is an inverse-scale metric, so the number and the defect rate move in opposite directions, and the 3.4 DPMO anchor is easy to garble when recalled under time pressure.
What to do instead
Memorize one anchor pair and the direction: 6 sigma equals 3.4 defects per million opportunities, roughly 99.99966% yield. Then sanity-check every option: as sigma level rises, DPMO, cost of poor quality, and rework all fall. Any answer implying the opposite is wrong regardless of how familiar the wording sounds.
Selects a problem statement that names a cause or an implied solution ('the cell is slow because the conveyor jams, so the conveyor needs replacing') rather than describing the observed effect with a metric, magnitude, location, and time frame.
Real-world problem descriptions arrive already diagnosed, and candidates copy that phrasing; answer sets also include smooth-sounding statements that quietly smuggle in a cause.
What to do instead
Apply a four-part test to every candidate statement: does it quantify the gap between actual and target, name the process or location, state the time period, and describe the business impact - and does it avoid 'because' plus any proposed remedy? If a cause or fix appears, the statement belongs to a later phase, not to Define.
Treats a raw customer comment ('I want it to feel faster') as if it were already a critical-to-quality requirement, or treats an internal engineering tolerance as if it were the voice of the customer.
VOC, CTQ, and specification are taught in the same lesson and are all described as 'requirements', so they collapse into one idea, and a tolerance is usually the most concrete-looking option in the list.
What to do instead
Keep the chain explicit: VOC (the customer's words) becomes a need, which becomes a CTQ (a measurable characteristic with units and a stated measurement method), which then has a specification (target and limits). A CTQ must be quantifiable and traceable to a customer need; a limit with no VOC link behind it is an internal requirement, not a CTQ.
Classifies data by how it looks instead of how it was counted - placing a defect count on a p chart, or treating a 1-to-5 satisfaction rating as continuous data.
The attribute and continuous branches of the toolset cover the same topics (charts, capability, metrics), so candidates skip the classification step and reach for the chart name they recognize.
What to do instead
Ask one question first: was the value measured on a scale (time, weight, length, temperature), or counted and classified (pass/fail, number of defects, category)? Measured values are continuous, suited to histograms, X-bar/R or I-MR charts, and capability indices. Counts and categories are attribute data, handled with proportion- and count-based metrics and the corresponding attribute charts.
Reports Cp alone, or picks whichever of Cp and Cpk is larger, and declares the process capable - even when the process is visibly off-center or is not in statistical control.
Cp and Cpk look like interchangeable capability numbers and both appear in the answer options; the centering distinction and the stability precondition are the parts most often skimmed.
What to do instead
Hold two facts: Cp reflects spread only (specification width divided by six sigma), while Cpk reflects spread and centering (distance to the nearer specification limit divided by three sigma), so Cpk can never exceed Cp. A large Cp-to-Cpk gap means an off-center process where shifting the mean is the cheapest improvement. Check the control chart first: capability indices are meaningless for an unstable process.
Accepts the first plausible cause on a fishbone or the tallest bar on a Pareto chart as the verified root cause and moves directly to selecting a solution.
Cause-and-effect and Pareto diagrams are the most practiced and most visual tools in the course, so using the tool gets confused with proving the cause - and the exam distractors are written to be exactly those plausible causes.
What to do instead
Keep the sequence explicit: potential causes (brainstorm and fishbone), then narrowing (Pareto, stratification), then verification with data (check sheet, run chart, or a before/after comparison). If the stem contains no evidence, an asserted cause is a hypothesis, not a conclusion. When using 5 Why, keep going past symptoms until the answer is a controllable process cause.
Picks a countermeasure because it is familiar or technically impressive and jumps from root cause to full implementation, skipping the limited trial and the re-measurement step.
The Improve phase gets memorized as a list of tools (FMEA, poka-yoke, 5S, kaizen) rather than as a decision sequence, and the pilot step is a single bullet that is easily lost.
What to do instead
Look for the option that ties the countermeasure to the verified root cause, compares candidates on impact versus effort and risk, tests on a limited scale first, and then re-measures with the same metric defined in Define and Measure. In a scenario, 'train everyone and roll it out Monday' is almost never the credited answer.
Assigns control charts without matching them to the data - plotting a defect-count metric on a p chart, or putting individual readings on an X-bar/R chart - and never states who responds and how when a signal appears.
Chart names are memorized as a list only loosely tied to data type, and the reaction plan is treated as paperwork rather than the reason the chart exists.
What to do instead
Use a selection key: measured values give I-MR for one reading per period or X-bar/R for rational subgroups; defective units give p with varying sample size or np with constant sample size; defect counts give c with constant opportunity or u with varying opportunity. Then require every control plan to name the metric, the chart, the owner, and the documented response to an out-of-control signal.
Declares the project complete the moment the fix is installed - no updated standard work or SOP, no training and ownership handover, no ongoing monitoring plan, and no confirmation that the gain held against the original target.
Implementation feels like the finish line, so the Control-phase deliverables (standardization, mistake-proofing, response plan, benefit validation, closure and handover) look administrative and get deprioritized.
What to do instead
Treat Control as the phase that makes the gain permanent. The credited answer will document the new standard, train and communicate, assign ongoing monitoring with a response plan, verify sustained results against the target and metric set earlier in DMAIC, and confirm the process and financial benefit with the sponsor before the project is closed.