Prove
All outcomes
Teams

Complete Six Sigma Green Belt

16 weeks · 0 milestones

Pass a Six Sigma Green Belt examination and complete a DMAIC project with measurable process improvement documented.

Milestone map

Milestone map

3 milestones

Define a Real Process Improvement Problem Using DMAIC

2–3 weeks

Six Sigma Green Belt is tested through a real project, not curriculum knowledge. Select a genuine process with a measurable quality or efficiency problem. Use the Define phase of DMAIC to produce a project charter: problem statement (with baseline data), measurable goal, scope boundaries, SIPOC diagram, and voice-of-customer summary.

Proof required

Submit: (a) the project charter (minimum 800 words) with all five components: problem statement with baseline data, measurable and time-bound goal, scope boundaries, SIPOC diagram, and voice-of-customer summary, and (b) confirmation from your project sponsor (manager or relevant stakeholder) that the problem and scope are real and approved — name and role required.

What gets checked

  • Problem statement includes specific baseline data — 'defect rate is 12% vs a target of 3%' not 'quality is poor'
  • Goal is specific, measurable, and time-bound
  • Project sponsor confirmation is from a real named stakeholder with a verifiable role

Common mistakes

  • Project selected because data is easy to collect rather than because the problem is significant
  • SIPOC drawn at too high a level to be actionable

Resources

What a verifier looks for

  • Is the problem statement specific and measurable? Without baseline data, improvement cannot be demonstrated.
  • Is the project sponsor confirmation genuine? Check that name and role are consistent with the organisation described in the charter.

You'll sign in first, then come straight back here.

Measure and Analyse the Process Using Statistical Tools

6–8 weeks

Complete the Measure and Analyse phases. In Measure: collect baseline process data, calculate process capability (Cp/Cpk or DPMO), and conduct a measurement system analysis. In Analyse: identify root causes using at least two tools — one qualitative (fishbone) and one quantitative (Pareto, hypothesis test, regression, or control chart).

Proof required

Submit: (a) baseline data (minimum 30 data points for continuous or 100+ for attribute data), (b) process capability calculation (Cp/Cpk or DPMO with sigma level and interpretation), (c) measurement system analysis (gauge R&R or attribute agreement results), and (d) root cause analysis using both a fishbone and a quantitative tool — with a clear statement of the verified root cause(s).

What gets checked

  • Baseline data meets the minimum volume
  • Root cause analysis distinguishes verified from suspected causes — fishbone branches must be data-tested
  • Process capability calculation includes interpretation of what the Cp/Cpk value means for this process

Common mistakes

  • Root causes identified through brainstorming alone without data verification — a fishbone is a hypothesis generator, not evidence
  • Data collected non-randomly — sampling bias invalidates the capability analysis

Resources

What a verifier looks for

  • Was each fishbone hypothesis actually tested with data? 'The most likely root cause is X' is not the same as 'We verified X is the root cause — the p-value was 0.03'.
  • Check the measurement system analysis: did gauge R&R show acceptable repeatability (% Contribution < 10% is the Six Sigma standard)?

You'll sign in first, then come straight back here.

Implement the Improvement, Build a Control Plan, and Document Results

6–8 weeks

Complete the Improve and Control phases. Implement the improvement solution addressing the verified root cause(s). Collect post-improvement data and calculate the new process capability. Implement a control plan to sustain the improvement. Document before-and-after results and obtain sponsor sign-off.

Proof required

Submit: (a) a description of the improvement solution implemented (minimum 400 words) explaining how it directly addresses the verified root cause(s), (b) post-improvement data (minimum 20 data points) with before-and-after capability comparison, (c) a control plan specifying who monitors what, at what frequency, and with what response threshold, and (d) sponsor sign-off confirming the results and that the control plan is in place — signed and dated.

What gets checked

  • Improvement solution is causally linked to the verified root cause(s) — not a solution addressing a symptom
  • Before-and-after comparison shows measurable improvement against the original project goal
  • Control plan specifies concrete monitoring responsibilities with a named owner

Common mistakes

  • Improvement implemented but control plan treats it as a one-time fix — sustaining improvement requires an ongoing control mechanism
  • Before-and-after comparison uses different conditions that introduce confounds

Resources

What a verifier looks for

  • Was the improvement target from the original project charter met? If the goal was 12% → 3% defect rate, what is the post-improvement rate?
  • Sponsor sign-off confirms this is real — verify it is the same named stakeholder who approved the project charter in milestone 1.

You'll sign in first, then come straight back here.

We use analytics to improve Powstik. No ads, ever.