PECB Six Sigma Green Belt common mistakes
PECB Six Sigma Green Belt · Understand the traps and how to avoid them.
Treating Six Sigma, Lean, and the DMAIC cycle as interchangeable labels, so answers describe 'removing waste' when the question asks about reducing variation, or vice versa.
Candidates memorize buzzwords from summaries and never build a clean mental split between defect/variation reduction (Six Sigma, sigma level, DPMO) and flow/waste elimination (Lean, value stream, takt).
What to do instead
Before answering, classify the question stem: does it talk about consistency, spread, or defect rate (Sigma tools: capability, control charts, MSA), or about speed, inventory, and non-value-added steps (Lean tools: 5S, kanban, VSM)? Write a two-column list of tools for each and practise sorting 20 mixed scenarios.
Mixing up the belt roles and project responsibilities, for example stating that a Green Belt charters projects and allocates resources independently, or that a Champion runs the statistical analysis.
Role definitions sound similar in casual descriptions, and candidates answer from workplace intuition rather than the defined governance structure used on the exam.
What to do instead
Memorize a one-line responsibility per role: Sponsor/Champion removes barriers and approves resources; Master Black Belt provides methodology and coaching; Black Belt leads complex cross-functional projects; Green Belt leads part-time projects within their own area; team members execute. Attach each to a decision-rights verb.
Selecting or defending a project that has no clear link to a measurable business metric, no defined process boundary, or no baseline data, and then answering later phase questions as if the project were valid.
Candidates pick the most technically interesting option rather than testing the project against selection criteria (impact, feasibility, data availability, scope).
What to do instead
Apply a checklist to every project-scenario option: Is there a measurable Y? Is there a baseline? Are start and end of process defined? Is the scope doable in a few months? Is a sponsor committed? Reject options failing any criterion before evaluating tools.
Writing or interpreting a problem statement that embeds a cause or a solution, such as 'reduce defects caused by untrained operators by installing new fixtures'.
Real-world project charters often contain assumed causes, and candidates copy that style instead of the neutral, data-based phrasing the exam expects.
What to do instead
Test the statement: it should state the observable gap (metric, current vs target, time, location) with no 'because' and no 'by installing/by training'. If a cause or remedy appears, move it to a hypothesis list, not the charter.
Confusing the operational definition, the data type, and the measurement scale, for example treating pass/fail inspection counts as continuous data or using a nominal label in an X-bar chart.
Candidates classify data by how it is recorded rather than by what it represents, and skip the step of writing a precise operational definition before collecting.
What to do instead
For each measure, write: what is measured, how it is computed, the unit, and the accept/reject rule. Then label it continuous (time, weight, dimension) or discrete (count, proportion, category). Match the tool: X-bar/R or I-MR for continuous, p/np/c/u for discrete. Practise mapping 15 measures to tools.
Ignoring measurement system analysis and sampling validity, answering capability or control-chart questions without first confirming the measurement system is acceptable and the sample is representative.
Candidates jump to the headline statistic and forget that Gage R&R, bias, and sampling plan are prerequisites in the Measure phase.
What to do instead
Adopt a fixed sequence: define measure, validate the measurement system (%GRR, resolution, bias/linearity), then collect a representative sample (random or rational subgrouping), then compute capability. If a question omits MSA, flag that as the missing step.
Reading a control chart incorrectly: treating a single point inside the control limits as proof the process is stable, or reacting to a point outside the limits as if it were a specification violation.
Candidates conflate control limits with specification limits and only look for points beyond 3 sigma, missing runs, trends, and stratification rules.
What to do instead
State explicitly that control limits come from process variation, specifications come from the customer, and the chart detects instability. Check all run rules (points beyond limits, 7 in a row on one side, 6 trending, 2 of 3 beyond 2 sigma). Then, and only then, assess capability against specs.
Choosing the wrong hypothesis test or misreading the p-value, for example using a paired test on independent groups, or concluding 'p = 0.06 proves the null is true'.
Candidates memorize test names without the decision tree (data type, number of groups, paired or independent, normality) and treat p as a probability that the hypothesis is true.
What to do instead
Build a decision tree: continuous vs discrete, groups compared, paired design, normality assumption. Practise stating the null and alternative before selecting the test. Interpret p as evidence against the null at a stated alpha; a non-significant result means insufficient evidence, not proof of no effect. Also check practical significance and sample size.
Proposing solutions that address symptoms or unverified causes, or skipping piloting and risk assessment before full implementation in the Improve phase.
Time pressure and stakeholder preference push candidates toward the first plausible fix rather than the verified root cause, and they underweight the pilot and FMEA steps.
What to do instead
Tie every proposed solution to a validated root cause from the Analyze phase. Include a pilot with success criteria, an assessment of risks and failure modes, and a cost-benefit check. If an option lacks a link to verified cause or a test step, treat it as incomplete.
Designing controls that rely on reminding people or retraining, without a documented standard, control plan, or ongoing monitoring, and closing the project without transferring ownership.
Candidates treat the Control phase as a formality and confuse training with a sustaining mechanism, so gains erode after the project ends.
What to do instead
For each control question, require: updated standard work or control plan, a named process owner, a monitoring method (control chart, audit, mistake-proofing), a response plan for out-of-control signals, and a documented handover with a closure review. Reject 'retrain the team' as a standalone control.