EXIN LSSA Six Sigma Green Belt common mistakes
EXIN LSSA Six Sigma Green Belt · Understand the traps and how to avoid them.
Answering DMAIC questions by reciting the phase names and generic tool lists instead of stating the project's decision gate and deliverable for each phase.
Candidates memorise the acronym and the tool inventory but never build the mental model of what each phase must produce (charter and business case in Define, validated measurement system in Measure, statistically supported root causes in Analyze, pilot and FMEA in Improve, control plan and handover in Control), so questions framed around 'what must be complete before phase X ends' feel ambiguous.
What to do instead
For each phase write a one-page card listing: key deliverable, exit criteria, typical tools, and the most common reason a project is sent back. Practise by reading a short project scenario and naming the phase gate that would fail first, then justify with one sentence citing the deliverable.
Writing problem statements that embed a cause or a solution, such as 'the line is slow because the conveyor motor is undersized and needs replacing', and then defending that statement as a valid charter element.
Candidates conflate the symptom they observe with the diagnosis they suspect; in real projects this shortcut is common and feels efficient, so it reads as correct. The exam tests whether the problem statement is measurable, time-bound and cause-free.
What to do instead
Apply a three-part test to any problem statement: does it state a measurable gap (baseline versus target), does it specify where and when, and does it avoid naming any cause or remedy? Rewrite five deliberately flawed statements to pass the test, then check that each rewritten version could be copied unchanged into a charter.
Confusing VOC, CTQ and Kano classification, for example labelling a basic expectation as a delighter or writing a CTQ that is not measurable.
The three concepts are learned together and share vocabulary about customer needs, so candidates answer from surface wording rather than from the definition of each: VOC is raw input, CTQ is the translated measurable requirement, and Kano classifies satisfaction behaviour.
What to do instead
Learn one worked example end to end: a customer comment, its translation into a measurable CTQ with operational definition and specification limits, and its Kano category with the reasoning. Then classify ten short customer statements and write the CTQ each implies, checking that every CTQ has a metric, unit and spec.
Reading an X-bar and R chart as if the limits were specification limits, and concluding the process is incapable whenever a point sits outside the control limits.
Control limits and specification limits look similar on a page, and candidates who learned chart construction mechanically never internalise that control limits come from the process's own variation (voice of the process) while specifications come from the customer (voice of the customer).
What to do instead
For every chart question, write two labels before answering: 'voice of the process' for control limits (computed from subgroup variation, typically three sigma of the plotted statistic) and 'voice of the customer' for specification limits (given externally). Then classify each out-of-limit point as a signal of special cause, not of nonconformance, and check the two conclusions separately.
Choosing a hypothesis test by the metric's name rather than by its data type, independence and distributional assumptions, e.g. running a paired t-test on two independent groups or a chi-square test on continuous data.
Test selection is taught as a table of names, and under time pressure candidates match keywords such as 'compare two' to 't-test' without checking whether samples are paired, whether variances are assumed equal, or whether the response is continuous or categorical.
What to do instead
Build a decision tree keyed on four questions: how many groups, are observations paired, is the response continuous or attribute, and are normality or equal-variance assumptions met. Work twenty short scenarios through the tree aloud, writing the assumption check before naming the test, and note the nonparametric alternative for each parametric branch.
Treating a low p-value as proof that the improvement is large or important, and ignoring practical significance and confidence intervals when recommending action.
Statistical significance is the headline output of most software, and candidates equate a small p-value with a strong effect. The exam tests the distinction between statistical and practical significance, and between failing to reject a null and proving it true.
What to do instead
For every test result, report three things: the p-value, the effect size or confidence interval, and the comparison against the practical threshold agreed in the charter. Practise phrasing conclusions in the correct form, 'insufficient evidence to conclude a difference' rather than 'no difference exists', and check whether the interval excludes a meaningful effect.
Building a control plan that lists monitoring charts but omits reaction plan, owner, specification, sample frequency and the response to an out-of-control signal, and then declaring the project closed without a handover.
Control is treated as paperwork at the end of a project, and candidates reproduce the column headings they remember rather than the operational content. The exam tests whether the control plan would actually work in the absence of the Black Belt.
What to do instead
Draft a complete control plan for a simple process with every required column filled, including a reaction plan naming who does what when a point signals special cause. Add a handover checklist covering updated procedures, training records, control chart ownership and a defined audit interval, then test the plan by asking whether a new operator could act on it unaided.
Ignoring measurement system capability and data type when planning data collection, for example proposing an attribute check sheet where a continuous gauge study is needed, or trusting data without checking repeatability.
Candidates focus on the process being measured and not on the instrument or definition collecting the data, so measurement-system items feel like a separate topic.
What to do instead
Before any data plan, answer four questions: what is the operational definition, is the data continuous or attribute, who and how will it be recorded, and how do we know the measurement is repeatable and reproducible. Drill the distinction between precision, accuracy and agreement.
Reading a process map as a diagram to describe rather than a diagnostic, so waste, handoffs and rework loops drawn in the map are not identified in the answer.
Candidates reproduce the shape of a flowchart instead of interrogating each step, and they confuse a value stream map's data boxes with a simple sequence map.
What to do instead
Annotate every map you draw with three markers: decision points, handoffs between owners, and loops back to an earlier step. Then state one waste or delay risk per marker. Practise spotting non-value-adding steps in a short written process description.