ICBB common mistakes
ICBB · Understand the traps and how to avoid them.
When asked to define a process metric, the candidate writes a vague goal such as "improve customer satisfaction" instead of a measurable CTQ with a stated operational definition, data type, and target.
Candidates carry over business-objective language from project charters and do not convert it into a measurable characteristic with a clear operational definition, so the metric cannot be tied to a baseline or a specification limit.
What to do instead
Force every metric answer into four parts: the characteristic being measured, how it is calculated or observed, the data type (continuous or discrete), and the target or specification. Reject any metric you cannot measure on a defined scale with a stated unit.
The candidate labels a project's problem statement with a pre-judged cause, e.g. writing that defects occur "because operators are poorly trained" in the Define phase deliverable.
Problem statements are often drafted from shop-floor opinion, and candidates confuse the symptom with a verified root cause; the exam tests whether the candidate can keep the Define phase free of unverified causal claims.
What to do instead
Write the problem statement as observable gap only: what is wrong, where, when, how much, and the business impact. Move every suspected cause into the Analyze phase and require data before it appears in any deliverable.
When asked to select a sample size or interpret a capability index, the candidate treats a discrete proportion as if it were continuous data and applies X-bar/R chart logic or a normal-based capability calculation.
Candidates memorize formulas without checking the data type and distributional assumption behind them; discrete data (pass/fail, count of defects) requires attribute methods such as p, np, c, or u charts and binomial or Poisson reasoning.
What to do instead
Before choosing any tool, classify the data: continuous vs discrete, and check normality for continuous data. Match the chart and capability method to the data type, and state the assumption explicitly in the answer.
The candidate computes measurement system variation from a single operator or a single trial, or reports gauge R&R as a percentage without stating whether it is percent of tolerance or percent of process variation.
The two denominators give very different verdicts, and candidates often skip repeatability versus reproducibility decomposition, so they cannot say whether the variation is equipment or appraiser driven.
What to do instead
Always run a crossed design with multiple operators and trials, report both percent contribution and percent study variation, and state the denominator. Then interpret: repeatability points to equipment or method, reproducibility points to appraisers or training.
The candidate runs a hypothesis test and reports a p-value as the probability that the null hypothesis is true, or concludes that a non-significant result proves the groups are equivalent.
The p-value definition is routinely misstated, and candidates conflate failure to reject with evidence of no difference; they also ignore power and sample size when interpreting a non-significant result.
What to do instead
State the p-value correctly as the probability of observing data at least as extreme if the null were true. For non-significant results, report power and confidence intervals, and explicitly say the test failed to detect a difference rather than proving none exists.
In a multi-factor experiment, the candidate interprets main effects without checking interactions, or ignores confounding and randomization order when the design is fractional or run in blocks.
Candidates analyze the main-effects table first and stop there; fractional factorial designs alias effects, and unrandomized runs let nuisance variables masquerade as factor effects.
What to do instead
Always inspect the interaction plots and the design resolution before interpreting main effects. State the alias structure for fractional designs, confirm randomization and blocking, and only claim an effect when it is unaliased and practically meaningful.
The candidate proposes a solution and declares improvement without a pilot or a before-and-after comparison that controls for the baseline and for common-cause variation.
Teams are under pressure to show results, so they compare a post-change average to a pre-change average without accounting for normal variation, seasonality, or regression to the mean.
What to do instead
Design a pilot with a defined success criterion, compare against the baseline using a control chart or a formal test, and report the effect size with a confidence interval. Separate the improvement claim from the implementation plan.
The candidate treats a designed experiment or a DOE-based optimization as the whole Improve phase and omits the implementation plan, risk assessment, and verification that the change works under real operating conditions.
Candidates equate Improve with statistical optimization and forget that the phase must deliver a validated, implemented change with owners, timing, and failure-mode thinking.
What to do instead
Pair every proposed change with a pilot or verification plan, an FMEA or risk review of the new process, named owners, and a measurable acceptance criterion before declaring the phase complete.
The candidate builds a control chart with limits recalculated from post-improvement data or from too few subgroups, then declares the process stable because all points fall inside those limits.
Recalculating limits after a shift hides the shift, and short baseline periods produce wide or unstable limits; candidates also confuse control limits with specification limits.
What to do instead
Freeze control limits from a stable baseline of at least 20 to 25 subgroups, apply them to new data, and interpret runs and trends. Keep specification limits separate and never plot them as control limits.
The candidate answers a control-plan question with a generic statement such as "monitor the process" and omits the specific metric, sampling frequency, sample size, reaction plan, and owner.
Control plans are often written as narrative rather than as an operational document, and candidates underestimate how much specificity the exam expects for sustaining gains.
What to do instead
Write the control plan as a table: characteristic, specification, measurement method, sample size and frequency, chart or check, reaction plan for out-of-control or out-of-spec, and responsible role. Include a response for each failure mode identified in the FMEA.