ICGB common mistakes
ICGB · Understand the traps and how to avoid them.
Treating the exam as a generic Lean Six Sigma or quality-management test and skipping the formal Define-phase toolkit (project charter elements, VOC-to-CTQ translation, SIPOC at the right altitude), then answering Define questions from intuition.
Candidates with shop-floor or project experience assume Define is 'common sense' and spend study time on statistics, so they have never seen the precise charter and scope conventions the exam uses.
What to do instead
Build a one-page Define checklist and drill it: problem statement with measurable gap and no embedded cause or solution, business case, goal statement with metric and target date, scope boundaries, team roles, milestones. Practise converting a customer statement into a CTQ with an operational definition, and drawing a SIPOC that starts and ends at the process boundary rather than the whole value stream.
Confusing the types of data and measurement scales when choosing a chart or test, for example treating an ordinal rating as continuous, or running a t-test on defect counts instead of a proportion or Poisson-based method.
Candidates memorise chart names without linking them to data type, so they pattern-match on keywords in the question stem rather than classifying the variable first.
What to do instead
Before answering any Measure or Analyze item, write down two things: data type (continuous vs discrete) and number of samples or groups. Then apply a decision rule: continuous and normal with two groups means t-test; non-normal means Mann-Whitney; proportions mean chi-square or two-proportion test; counts per unit mean Poisson or rate test. Rehearse with mixed datasets until classification is automatic.
Reporting capability indices without checking stability and normality first, or mixing up Cp/Cpk with Pp/Ppk, so the answer is numerically plausible but conceptually wrong.
Formulas are easy to memorise and candidates enjoy computing them, so they skip the assumption checks that the exam tests as part of the same item.
What to do instead
Adopt a fixed order: control chart first, then normality test, then capability. Learn that Cp/Cpk use within-subgroup variation and Pp/Ppk use overall variation, and that a process must be in statistical control for any index to be meaningful. Practise interpreting a Cpk of 0.8 versus 1.33 versus 1.67 in defect-per-million terms and in plain business language.
Reading a control chart as a run chart: reacting only to points outside the limits and ignoring runs, trends, and other sensitising rules that indicate special-cause variation.
The three-sigma limit is the most memorable feature, so candidates stop there and miss the pattern-based signals the exam deliberately builds into chart questions.
What to do instead
Memorise the standard Western Electric or Nelson rule set and practise identifying each rule on a described sequence. Also practise the reverse skill: given a described pattern, name the rule violated and the most likely type of cause. Distinguish common from special cause in words before choosing any action.
Choosing the wrong control chart for the data: using an X-bar and R chart for individual measurements, a p-chart for counts per unit, or a c-chart for a varying sample size.
Chart selection depends on subgroup size and whether the metric is a measurement, a proportion, or a count, and candidates who memorise chart names without the selection logic guess from superficial cues.
What to do instead
Build a selection tree: continuous data with rational subgroups of 2 to 9 use X-bar and R; subgroup size above about 10 use X-bar and S; single measurements use individuals and moving range. For attribute data, constant sample size with defectives uses np, varying sample size uses p, constant opportunity with defects uses c, varying opportunity uses u. Work through a dozen mixed scenarios.
Treating a statistically significant result as a practically important one, or ignoring sample size and power when interpreting a hypothesis test or a designed experiment.
Software output makes the p-value the most visible number, so candidates anchor on it and never connect significance to effect size, confidence intervals, or the cost of the decision.
What to do instead
For every hypothesis-test item, state four things: the practical question, the null and alternative in context, the decision rule, and the effect size with a confidence interval. Learn how sample size drives power and how an underpowered experiment produces a non-significant result that does not prove equality. Practise explaining a p-value and a confidence interval without using the word 'prove'.
Confusing the phases of DMAIC in multi-step scenarios, for example proposing a regression model in Improve, or validating a measurement system in Analyze, and thereby selecting a technically correct tool placed in the wrong phase.
Tools overlap across phases in real projects, and exam items often describe a situation where several tools would be legitimate, so candidates pick the tool rather than the phase-appropriate next step.
What to do instead
Anchor each phase to its deliverable: Define produces an approved charter and scoped problem; Measure produces a validated measurement system and baseline; Analyze produces verified root causes; Improve produces a tested and piloted solution; Control produces a monitored, standardised, handed-over process. For each practice item, name the phase deliverable first, then choose the tool that produces it.
Jumping to solution selection and piloting without screening and characterising the candidate causes, or designing an experiment that changes many factors at once with no replication or randomisation.
Candidates want to reach the 'fix' and treat DOE as a formality, so they skip cause-and-effect screening tools and forget the design principles that make an experiment trustworthy.
What to do instead
Practise the sequence: cause-and-effect matrix or FMEA to screen, then multi-vari or hypothesis tests to confirm, then designed experiment to optimise. Memorise the three design principles (randomisation, replication, blocking) and be able to explain what each protects against. Know the trade-offs between full factorial, fractional factorial, and screening designs in terms of runs, resolution, and confounding.
Writing a control plan that lists monitoring activities but omits the response plan, ownership, reaction to out-of-control signals, and the link back to the standard operating procedure and mistake-proofing.
Candidates equate Control with 'keep measuring' and forget that a control plan is an action document, so they choose answers that describe charts and audits but not what happens when a signal fires.
What to do instead
For every control-plan item, check five elements: what is monitored, how and how often, who owns it, what trigger prompts action, and what the documented response is. Learn the hierarchy from error-proofing to standard work to monitoring, and be able to state why poka-yoke is preferred over inspection. Also practise explaining control-plan handover and the role of a reaction plan in sustaining gains.
Misapplying root-cause and prioritisation tools: building a fishbone as a list of solutions, using a Pareto chart without a meaningful stratification, or using FMEA without severity, occurrence, and detection ratings and a risk-priority threshold.
These tools look simple, so candidates use them loosely and then cannot distinguish a well-constructed application from a flawed one in an exam item.
What to do instead
Learn the purpose of each tool and its correct inputs. A fishbone branches by cause category and contains causes, not fixes. A Pareto requires a count or cost measure and a sensible stratification, and the 80/20 split is a description, not a law. FMEA requires agreed rating scales, an RPN or action-priority threshold, and documented actions for high-risk items. Practise spotting deliberately flawed applications and naming the specific defect.