APMG LSS Green Belt common mistakes
APMG LSS Green Belt · Understand the traps and how to avoid them.
Treating the Define phase as a place to propose solutions, writing a charter that already names the fix (e.g., 'implement a new scheduling tool') rather than stating the problem, goal, scope, and business case.
Candidates carry over a project-management or 'solution-first' mindset and want to show they can solve the problem, so they embed the answer in the charter; the exam then tests whether the problem statement is measurable and solution-free and they miss it.
What to do instead
Before answering any Define question, check whether the artefact describes the problem (symptom, location, magnitude, timing, gap to target) or the remedy. A valid charter/problem statement contains no verb that commits to a countermeasure; rewrite any draft that does.
Confusing the voice of the customer with the voice of the business, or writing CTQs that are not measurable, so critical-to-quality requirements end up as vague adjectives like 'fast', 'reliable', or 'user-friendly'.
Candidates blur who the requirement belongs to and skip the operational definition step, because translating a customer need into a specification with a metric, target, and specification limits feels like extra work not shown in the case.
What to do instead
For every CTQ, force three elements: the measurable characteristic, the target/specification limits, and the data source. If any is missing it is a need, not a CTQ. Practise converting one customer statement into a full CTQ tree until it is automatic.
Selecting a measurement approach without first confirming the metric is operationally defined, the measurement system is capable, and the data type (continuous vs discrete) matches the analysis planned later.
Candidates jump from problem to data collection and want to 'get measuring', so they skip operational definitions and MSA, then choose analyses that do not fit the data they actually have.
What to do instead
Use a fixed sequence for Measure questions: operational definition -> data type -> sampling plan -> MSA -> baseline capability. If a question offers an analysis, first ask whether the data type and measurement system support it; reject options that assume capable measurement without evidence.
Treating a high MSA %agreement or a passing gauge R&R as optional, or misreading an unacceptable measurement-system result as a process problem and moving on to capability anyway.
Candidates underestimate how much variation the measurement system contributes and assume the gauge is 'fine' because it is calibrated; they also confuse calibration (accuracy/bias) with gauge R&R (precision/repeatability and reproducibility).
What to do instead
Memorise the decision rule: if the measurement system consumes too much of the tolerance or process variation, fix the measurement system before any capability or improvement work. Distinguish bias/linearity/calibration from repeatability/reproducibility, and never accept a capability index computed on an unqualified measurement system.
Computing or interpreting process capability (Cp/Cpk/Pp/Ppk) without checking stability and normality first, or mixing up the indices (e.g., using Cp when the process is off-centre).
Candidates memorise formulas but not preconditions, and the symbols look interchangeable under exam pressure; they forget that Cp ignores centring while Cpk penalises it, and that capability is meaningless for an unstable process.
What to do instead
Apply a checklist before any capability answer: is the process in statistical control, is the data (or transformed data) approximately normal, is the measurement system adequate? Then map the index to the question: centring -> Cpk/Ppk; spread only -> Cp/Pp; long-term vs short-term -> P vs C.
Choosing the wrong analysis tool for the data and question, e.g., running a hypothesis test on non-normal or attribute data with a continuous-data method, or using correlation to claim causation.
Candidates pattern-match on keywords ('compare two groups' -> t-test) without checking assumptions, sample size, independence, and data type, and they conflate statistical association with a causal mechanism.
What to do instead
Before selecting a tool, state four things: the question (difference, relationship, distribution), the data type, the number of groups/samples, and the assumptions. Then match. Separately, treat any causal claim as requiring design evidence (designed experiment, stratification, or process knowledge), not a correlation coefficient.
Misreading hypothesis-test results: treating a p-value as the probability the null is true, or as the probability the result is due to chance, and ignoring practical versus statistical significance.
The p-value definition is counter-intuitive and candidates learn the rejection rule without the meaning, so they invert the conditional probability or overstate the conclusion when the sample is large.
What to do instead
State the p-value correctly in words: the probability of data at least this extreme if the null were true. Then always pair it with effect size and confidence interval before concluding practical importance. If a question asks 'what can we conclude', the answer must reference both statistical and practical significance.
Confusing root-cause analysis with brainstorming fixes: producing a fishbone of possible causes and then jumping straight to a countermeasure without verifying which causes are real.
Candidates want to reach the Improve phase and treat cause-and-effect diagrams as the deliverable rather than a hypothesis-generation step; verification (stratification, data, designed experiments) is skipped.
What to do instead
Insert a verification gate: every candidate cause must be tested against data before a countermeasure is selected. If an answer option proposes a fix while causes remain unverified, it is premature. Use stratification or a designed experiment to confirm the dominant cause.
Selecting countermeasures without prioritising or piloting them, and failing to show how the chosen solution addresses the verified root cause and the CTQ.
Candidates equate 'improve' with 'list good ideas' and overlook solution selection criteria (impact, effort, risk, cost) and the need for a small-scale trial before full implementation.
What to do instead
Use a structured selection step (impact/effort matrix or similar) and require a pilot with a defined success measure tied back to the CTQ. For any Improve question, check that the proposed action maps to a verified cause and has a measurable test plan.
Building a control plan that relies only on training or 'heightened awareness', omitting the metric, owner, monitoring frequency, response plan, and control chart, and failing to hand over ownership.
Candidates treat Control as documentation to finish the project and underestimate how gains decay; soft controls feel sufficient and the operational definition of who-does-what-when is left implicit.
What to do instead
For every control plan, verify five elements are present: what is measured, who owns it, how often it is monitored, what triggers action, and what the response is. Reject options that rely solely on training or reminders. Confirm ownership transfers to the process owner, not the project team.