EXIN LSSA Black Belt Practical common mistakes
EXIN LSSA Black Belt Practical · Understand the traps and how to avoid them.
Presenting a DMAIC project as a chronological diary of what the team did (kickoff, meetings, tools used) instead of a logical argument from problem to verified result.
Candidates are usually practitioners who lived through the project and write it as a narrative report. The practical exam assesses whether you can defend a project as a Black Belt reviewer would, so evidence of reasoning matters more than chronology.
What to do instead
Restructure into a claim-evidence chain: problem and its business impact, baseline capability, root causes with proof, chosen countermeasures with rationale, post-improvement capability with statistical verification, and control plan. Every section should answer 'so what does this prove?' before moving on.
Stating a root cause as a cause without showing data that discriminates it from alternative explanations (e.g., 'the cause was operator error' with no stratification, hypothesis test, or process observation).
Teams often arrive at causes by consensus in a workshop, so the written reasoning feels obvious to the author. Reviewers, however, only see the text and cannot accept assertion as evidence.
What to do instead
For each root cause, write one sentence naming the competing explanations you considered and the specific evidence that eliminated them (stratified defect rates, a hypothesis test with its p-value and practical significance, or a designed experiment). Include the data source and sample size.
Reporting a hypothesis test result by p-value alone, without stating the practical effect size, confidence interval, test assumptions, or whether the difference matters to the customer or business.
Statistical software output encourages copying the p-value. Candidates also conflate statistical significance with practical importance, which is a classic Black Belt trap on scenario questions.
What to do instead
For every test, report the statistic, degrees of freedom or sample size, p-value, and a confidence interval for the effect. Add one sentence on assumption checks (normality, equal variance, independence) and one on whether the effect is large enough to justify action.
Choosing the wrong tool for the data type or question, such as a paired test on unpaired data, a t-test on heavily skewed or ordinal data, or a capability index on a non-normal process without transformation or an alternative method.
Candidates memorize tool names and formulas but under-practise the selection logic under time pressure. Exam scenarios deliberately include distractors that look statistically impressive but violate assumptions.
What to do instead
Before selecting a tool, write down three things: the response variable type (continuous, ordinal, attribute), the data structure (paired, independent groups, counts), and the question (difference, association, prediction). Then match. For capability, check normality first and state the alternative used (Box-Cox, non-normal capability index, or attribute capability).
Treating the control phase as a document list (updated work instruction, training record) without a monitoring mechanism, response plan, or ownership that would actually detect drift.
Projects often end when the improvement is achieved and the team disbands. Candidates then write control plans that describe intent rather than a functioning feedback loop.
What to do instead
Specify the control metric, chart type and sampling plan, control limits and reaction rules, who responds and within what time, and how the control plan was validated (e.g., a period of monitored data showing stability, plus a documented response to a triggered signal). Name the process owner and review cadence.
Confusing Voice of the Customer with internal requirements, so CTQs are written as specifications the team already meets rather than translated customer needs with measurable performance standards and spec limits.
Candidates work from existing internal specifications and reverse-engineer the CTQ tree to match them. This makes the project look successful but disconnects it from customer value.
What to do instead
Show the translation explicitly: raw customer statement, interpreted need, CTQ characteristic, operational definition, measurement method, and specification limits with their source. If internal specs differ from customer-derived limits, say so and justify which governs.
Presenting a measurement system analysis as a single percentage (e.g., 'GR&R was 12%') without stating the study design, the variation it was compared against, or whether that variation is the process variation or the tolerance.
Software reports a number and candidates paste it. The distinction between %study variation and %tolerance changes the conclusion entirely, and reviewers test exactly this.
What to do instead
State the study type (crossed, nested, attribute agreement), number of appraisers, parts, and trials, the reference variation used (process sigma or tolerance), the resulting %GR&R or agreement statistic, and the acceptance criterion applied. Note whether the measurement system is adequate for the decision the project will make.
Using lean tools as a checklist (value stream map, 5S, kaizen) without linking the identified waste to the quantified problem or showing the before-and-after effect on flow or lead time.
Candidates trained in lean toolkits want to demonstrate breadth. In a practical exam, tool coverage without a causal link reads as activity rather than improvement.
What to do instead
Tie each lean tool to a measured waste: show the baseline value stream with cycle time, wait time, and queue, identify the constraint or largest waste with data, then show the post-improvement state with the same measures and the resulting change in lead time or throughput.
Ignoring the financial and stakeholder dimensions, so benefits are claimed as hard savings without a validated basis, and resistance or change-management actions are absent from the story.
Black Belts are often measured on project delivery and assume finance will accept the numbers. Practical scenarios frequently ask who must approve benefits or how adoption was secured, and candidates have no prepared answer.
What to do instead
Include a benefit validation section: how savings were calculated, what baseline they are measured against, who in finance confirmed them, and whether they are hard or soft. Add a short stakeholder and change plan covering the affected groups, their concerns, the actions taken, and evidence of adoption.
Answering scenario questions with a definition of the correct tool instead of the decision the scenario requires, or selecting the statistically sophisticated option when the question asks for the simplest adequate approach.
Candidates revise definitions and formulas, so under time pressure they retrieve the definition rather than parse what the scenario is asking. Exam items often reward fitness for purpose over sophistication.
What to do instead
For each scenario, first identify the decision being made and the constraints (data available, sample size, cost, time). Then choose the simplest method that supports that decision and state why the alternatives are inferior here. Practise explaining choices in two sentences, as the exam expects.