01 · Document the operating logic
Document the operating logic
Process documentation explains how work should proceed, what conditions must be present and what to do when those conditions fail. A useful document preserves the reasoning behind critical checks rather than recording every motion indiscriminately. In the Control phase, its purpose is to make the tested improvement reproducible after the project team leaves. A process map describes the route through the work; an operating procedure defines responsibilities and decisions; a work instruction explains a particular task. These documents can link to each other without repeating all their content.
Begin at the point where an input becomes the team’s responsibility and finish when the next customer accepts the output. Identify information, physical materials, equipment, authorisations and quality requirements along that route. Distinguish mandatory requirements from convenient habits. Write a critical control so someone can determine whether it passed. “Check label” is ambiguous; “scan the parcel identifier and compare the returned carrier service with the authorised order record before sealing” identifies an observable action and its acceptance condition.
02 · Prepare the current standard
Prepare the current standard
Observe the actual improved method with experienced operators on more than one shift. Include a difficult but legitimate case, a system interruption and a normal handover. Compare those observations with the method tested during Improve. If different groups use incompatible approaches, settle the operating decision before publishing a single apparently authoritative instruction. Documentation cannot repair an unresolved process design.
Agree the owner, reviewer, approval authority and release date. Give the instruction a stable identifier and a visible revision. Link it to relevant training, the control plan and the system configuration it assumes. A screenshot should identify the interface version or be replaced by a durable description when screens change frequently. Use language understood at the point of use. Where translation is needed, validate the meaning with someone who performs the work; a grammatically correct translation can still describe the wrong operational decision.
Structure the procedure around trigger, action, acceptance, exception and record. Keep safety restrictions near the step they govern. Explain when the operator should stop and who can authorise resumption. A document that only describes the happy path encourages unofficial workarounds precisely when control is most important.
03 · Worked example: the dispatch release instruction
Worked example: the dispatch release instruction
In the fictional Northbank warehouse, a dispatch improvement replaces free-text carrier notes with a scanned release check. Previously, staff sometimes copied yesterday’s carrier service into today’s order. The new instruction starts when a packed parcel enters the release lane. The operator scans its identifier, verifies that the order status is ready, confirms the displayed carrier service, and applies the generated label. A second scan verifies that the label belongs to the same parcel.
During observation, a supervisor discovers that a reprinted label can remain beside the printer. The instruction therefore includes a specific exception: move the parcel to the marked hold position, cancel the superseded label in the dispatch system, destroy the physical copy according to the approved information policy, and record the reason for reprint. The authorised supervisor checks identity before release. The procedure does not tell workers to invent a replacement address.
A new starter follows revision 3 on the late shift while a trainer observes. The starter successfully processes ordinary parcels but hesitates when the carrier service is unavailable. This exposes a missing decision. The team adds the escalation route and the permitted hold status, tests that route, and then releases revision 4. The teach-back test has improved the process document before it becomes the operational standard.
04 · Separate standards from evidence
Separate standards from evidence
A standard says what should happen. A record shows what actually happened. Confusing them creates misleading assurance: an employee’s signed acknowledgement proves receipt of an instruction, not successful execution of every release check. Retain the scan event, exception reason and authorised override as operating evidence, while retaining the procedure’s revision history as evidence of how the standard changed.
For Northbank, the standard owner is the dispatch manager. The system administrator maintains the scan configuration but cannot independently alter the release decision. The trainer maintains competency evidence. This separation clarifies accountability without requiring three people to approve each parcel. The document references the electronic record location rather than creating a second paper log. Duplicate records invite conflicts about which version is correct.
Decide retention and access according to the organisation’s actual requirements. A quick-reference card can omit background explanation, but it must show the revision and link to the governing instruction. Remove obsolete cards from workstations when releasing a revision. An archived document should remain retrievable for investigation while being clearly unavailable for current operational use.
05 · Use review triggers and change control
Use review triggers and change control
Periodic review is useful, but explicit triggers catch changes sooner. Review the instruction after a software release, a carrier rule change, repeated override, new equipment, a serious incident or evidence that a step cannot be followed. An operator suggestion is also a legitimate trigger. Describe the proposed change, the affected risk and the evidence required before adoption. A controlled standard remains open to improvement; it is not a ban on questioning the method.
Suppose Northbank introduces a mobile scanner. The sequence looks similar, but the device caches carrier data during a network interruption. The owner checks whether stale data can authorise release, tests the failure mode and updates both the instruction and configuration. Training occurs before the new device enters general use. The revision record explains why the offline release permission was removed, helping future teams avoid reintroducing the same failure.
If an emergency departure is necessary, specify temporary approval, duration, compensating controls and restoration. Do not let a temporary exception silently become a permanent standard. Afterwards, compare actual results with the intended protection and decide whether to formalise a new method or restore the established one.
06 · Interpret documentation failures
Interpret documentation failures
A document can be accurate yet unusable. Long paragraphs at a busy station may conceal the critical decision, while a beautifully designed one-page sheet may omit an essential exception. Assess retrieval time, readability, task completion and exception handling. Ask operators to demonstrate the process rather than recite the document. When people repeatedly depart from the standard, investigate workload, equipment, sequencing and access before assuming careless behaviour.
Northbank’s weekly review finds repeated manual carrier selection. The instruction is clear, but the default service list includes an obsolete option. The corrective action removes that option and checks affected orders; another warning paragraph would add clutter without correcting the cause. The document is updated only where the operating method actually changes.
Common errors include documenting an untested ideal, copying generic instructions, allowing multiple active revisions, hiding stop criteria and treating a signature as competence. Advanced document systems can integrate approvals and revision alerts, but automation does not establish correctness. The final test is whether the instruction helps a qualified person perform the intended work and respond safely when reality differs.
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
- Lean Enterprise Institute: Standardized Work
- Lean Enterprise Institute: Standardized Work for People and Process
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.