Project Documentation

Project Documentation

Quick Answer: Document the data and inputs your DMAIC project uses, maintain a living storyboard of the project narrative, and bring spreadsheet or dashboard summaries to each phase review. Documentation proves rigor, speeds tollgates, and preserves methods after the Green Belt rotates off the process.

Why Documentation Is a Belt Skill

ASQ CSSGB BoK II.C.6 asks Green Belts to apply project documentation: identify what must be recorded, organize phase evidence, and present concise packages for reviews. Documentation is not bureaucracy for its own sake. It:

• Makes analysis reproducible (another analyst can rebuild the baseline)
• Supports tollgate decisions with facts instead of memory
• Enables handoff to process owners and future audits
• Feeds lessons learned and replication across sites
• Protects the organization when personnel change mid-project

Weak documentation is a leading indicator of projects that “worked once in a meeting” and then silently regressed.

Data and Input Types Green Belts Document

Think in categories so nothing critical lives only in email threads.

Input vs. output documentation

• Inputs: What the team received or collected (VOC, extracts, SME interviews)
• Working analyses: Intermediate calculations and candidate models
• Outputs / deliverables: Charter, MSA report, root-cause package, control plan, closure report

Label status clearly: draft / in review / approved. Ambiguous “final_v7_REAL.xlsx” is how organizations lose the approved baseline.

Principles of Useful Project Docs

1. Traceability: Every metric on a slide should point to a defined field, period, and filter.
2. Version control: Date, author, version; one source of truth location (SharePoint, PLM, QMS, project folder).
3. Operational definitions first: Numbers without definitions are not evidence.
4. Right altitude: Executives need summaries; analysts need appendices—do not force either audience into the wrong layer.
5. Security & privacy: Mask customer PII, patient data, or regulated fields; document redaction rules.
6. Living, not archaeological: Update when the plan or baseline changes; do not only archive at the end.

Storyboards

A project storyboard is a structured visual summary of the DMAIC journey—often one page per phase or a single multi-panel board. It tells the story: problem → measure → causes → solutions → controls → results.

Typical storyboard panels

Why storyboards work at reviews

• Leadership can follow logic in minutes
• Gaps become obvious (e.g., solutions without verified causes)
• Replication teams get a portable template
• Storyboards force selection: only the vital evidence stays on the board

Storyboard anti-patterns

• Walls of unreadable statistical output with no “so what”
• Solutions appearing in Define before any Measure
• Before/after charts with unlabeled axes or cherry-picked weeks
• No link back to the charter goal statement

Worked example — Measure panel one-liners:

• Y: % invoices with coding defect (operational definition v2.1)
• MSA: attribute agreement κ = 0.82 after recalibration (was 0.51)
• Baseline: 6.4% defect rate (n = 1,240 invoices, Jan–Mar), stable mean on p-chart
• Stratification: Vendor family C at 11.2% drives ~48% of defects

That panel is review-ready; a 40-tab workbook alone is not.

Spreadsheet Summaries for Phase Reviews

Tollgates need decision packages, not raw dumps. Spreadsheet (or BI dashboard) summaries typically include:

Formatting that helps Champions

• One dashboard tab with red/yellow/green vs. exit criteria
• Frozen header rows; units on every column
• Explicit “as of” date
• Separate appendix tabs for supporting pivots—do not clutter the decision view

Phase-review checklist (documentation view)

• Exit criteria listed with pass/fail evidence cells
• Metric definitions match the charter (or approved change log)
• Sample sizes and time windows stated
• Open risks and resource needs highlighted
• Decisions requested (go / conditional / recycle) written in advance
• Links to full analyses available for deep dive

Documentation Rhythm Across DMAIC

Common Documentation Failures

1. Hero laptop only — Project dies when the belt changes jobs
2. No operational definitions — Later teams cannot reproduce Y
3. Screenshot graveyards — Images without source queries or dates
4. Storyboard theater — Pretty boards that contradict the data appendices
5. Finance afterthought — Benefits claimed with no documented assumption trail
6. Ignoring consequential metrics — Only the primary Y appears in summaries

Green Belt Documentation Starter Kit

Create these shells on day one:

1. Project charter (approved)
2. Shared folder with phase subfolders
3. Data dictionary + operational definitions
4. Risk/issue/action log
5. Metric tracker spreadsheet
6. Storyboard template
7. Tollgate decision log

Fill them continuously. Documentation applied this way is a management system for the project—not a final scramble the night before the gate.

Strong II.C.6 practice means anyone reviewing your storyboard and summary pack can answer: What was wrong, how do we know, what changed, who owns sustainment, and where is the evidence stored?