01 · Preserve the argument, not every file
Preserve the argument, not every file
Project documentation records why an improvement was undertaken, what evidence supported decisions, what changed and what remains uncertain. It differs from process documentation, which tells people how to perform current work. A closed improvement project needs both: operating instructions for execution and a traceable project record for explanation. Without the latter, a future team may reverse a carefully tested decision or repeat an unsuccessful experiment.
Organise the record around the improvement’s logic. State the customer need and problem, define the process boundary, establish measurement definitions, present baseline evidence, explain the causal investigation, record the selected countermeasure and show the evaluation. Include rejected alternatives when they reveal a material constraint or useful learning. Avoid preserving every brainstorming note with equal prominence. The record should help a reader understand the decisions without searching through dozens of disconnected presentations.
Match detail to consequence. A low-risk layout adjustment may need a concise record; a change to release permissions or customer data handling needs stronger traceability. The aim is sufficient evidence for maintenance and review rather than an arbitrary number of documents.
02 · Create a reliable evidence chain
Create a reliable evidence chain
Keep definitions and source references with the analysis. A chart copied into a slide loses meaning if nobody knows its denominator, exclusions or observation period. Record the dataset version, extraction date, transformation logic and quality checks. Retain an appropriate reproducible snapshot or controlled reference, with access and retention following the organisation’s requirements. Remove unnecessary personal information rather than spreading it through project folders.
Link a claim to its supporting evidence. “Dispatch errors reduced” should identify the error definition, before and after periods, counts, exposure and relevant operational changes. “Labour saved” should distinguish theoretical time released, actual reassignment and realised financial effect. A benefits claim with no traceable calculation becomes difficult to sustain after the original analyst leaves.
Maintain a decision record with the choice, date, owner, rationale and conditions. If a test failed, record what happened and the implications. Documentation that preserves only successful outcomes exaggerates certainty and reduces future learning. Revision control should make current conclusions clear while retaining earlier evidence in a labelled archive.
03 · Worked example: Northbank’s improvement record
Worked example: Northbank’s improvement record
Fictional Northbank improves carrier-service validation at dispatch. Its project record begins with 250 wrong-service releases among 2,500 inspected dispatches over the baseline period. It explains how inspectors classified a mismatch and why the sampled population excluded orders cancelled before release. The analysis separates service-table errors from label reprints and incomplete order data. Each category links to traceable anonymised case records.
A trial of an extra manual check reduced errors but increased queue time and was difficult to maintain during shift overlap. The record preserves that result and its workload evidence. The selected countermeasure checks the authorised service automatically and routes unresolved parcels to a visible hold area. The project documents the configuration version, test conditions and failure-mode checks, including the reprint route.
Post-change evidence is shown with the actual observation window and denominators. The team reports improved release accuracy and notes that seasonal peak demand has not yet been observed. It links the control plan, current release instruction, training evidence and named process owner. A future reader can distinguish what was demonstrated from what still requires monitoring.
04 · Separate observed benefits from projections
Separate observed benefits from projections
Record the benefit model early and revise it honestly as evidence improves. Suppose Northbank estimates that avoiding rework releases 20 staff-hours per week. A time study may support that capacity estimate, but it is not automatically a cash saving. If staffing remains unchanged and the time is used to clear existing work, the realised benefit may be improved capacity or service. If overtime actually falls, validate that effect against payroll and workload.
Document assumptions such as demand, carrier mix, pay rate and working weeks. Keep costs as well as benefits: software support, training, maintenance and additional exception handling can affect net value. Avoid multiplying a short trial result across an entire year without considering representativeness and uncertainty. Show a range or separate forecast from observed result where appropriate.
Assign future benefit verification. Northbank’s operations owner will review peak-period performance, while finance will validate any claimed overtime reduction. The project file records when those reviews will occur and what evidence is expected. Closure can therefore occur with explicit ongoing responsibilities instead of pretending that all lifetime benefits have already been realised.
05 · Make the handover record usable
Make the handover record usable
Build a compact index linking the final charter, evidence, approved change, operating standard, control plan, risks, benefits and closure decision. Use stable names and links. Distinguish active operational documents from historical project evidence. The dispatch team should not have to open an old project presentation to discover the current release rule.
Test the handover with a reader who did not participate in the project. Ask that person to identify the process owner, retrieve the current instruction, explain why the automated check was chosen and locate the remaining risk. If they cannot do so, improve navigation or explanation. This is a practical test of documentation usability rather than a review of whether every expected file exists.
Check access before the project workspace is archived. A link to a departing employee’s private folder is not a durable record. Transfer appropriate ownership, verify permissions and identify retention requirements. Northbank places the final index in its controlled project repository and links to the instruction in the operating document system, preserving each system’s proper role.
06 · Keep the story proportionate and honest
Keep the story proportionate and honest
Common errors include unlabelled screenshots, unexplained percentages, files named “final final”, retrospective editing of the baseline and benefits claims detached from source records. Another error is mixing current instructions with historic trial methods. Clear versioning and document purpose prevent people from treating an abandoned experiment as authorised practice.
Advanced projects may need reproducible analysis, configuration histories and a stronger approval trail. Document analytical choices that materially affect interpretation: excluded days, subgroup construction, adjusted case mix or changed definitions. Preserve enough detail for an independent reviewer to assess the claim. A sophisticated model without an explanation of its inputs and limits is difficult to maintain.
After closure, do not continually rewrite history to match current operation. Add later benefit reviews or corrections as dated records. Update current process documentation through its own change route. The project record should remain a dependable account of what was known and decided at the time, with later learning clearly distinguished.
07 · Record enough context for reuse
Record enough context for reuse
Include operating conditions that affect transferability. Northbank’s automatic validation depends on a reliable order-service field and a maintained carrier table. A second site without those prerequisites cannot expect the same result by copying the scan step alone. The project record therefore identifies the data controls required for the mechanism to work and the manual fallback that was tested. It also states that hazardous-goods handling was outside this project’s boundary. These details help a later team decide what to reuse, what to test and what requires separate specialist review. Useful documentation preserves the boundary of the claim as carefully as the claim itself.
Connections
Related methods and phase use
Placed under Control because of the outcome it supports. Use the method in other phases when its purpose and assumptions fit the work; the phase list is a guide to selection, not a compulsory sequence.
Sources
Professional foundations and further reading
The explanation and fictional teaching examples are written for LeanTrainingLab. Linked primary sources provide professional foundations; example values and local conventions are stated in the guide. The accepted toolset draws on Six Sigma+Lean Toolset, second edition (Lunau, editor; Springer, 2013). No book text or examples are reproduced here.