Home / Knowledge centre / Improve

Improve · Teaching guide

Risk Analysis

Identify how an improvement could fail, prioritize consequences and uncertainty, and assign prevention, detection, contingency, and review.

Read the method, follow the developed example, and examine the assumptions and decisions before applying the tool.

01 · Purpose and scope

Purpose and scope

Risk analysis examines uncertain events or failure modes that could prevent an improvement from meeting its objectives or create harmful consequences. Its purpose is to inform design, controls, contingency, and acceptance decisions before problems occur. In dispatch improvement, risks include wrong-carrier loading, untraceable fallback records, congestion, scanner outage, and a change that improves one lane while delaying another.

Use it during design, pilot preparation, implementation, and rollout review. Prerequisites include a clear process boundary, a proposed operating sequence, people with knowledge of failure and recovery, and explicit criteria for judging consequence and likelihood. The analysis should distinguish causes, failure modes, and effects. “Network interruption” is a possible cause; “confirmation unavailable” is a failure mode; “unverified loading or missed collection” is an effect. Combining them into one vague risk statement makes the response difficult to design.

02 · Build the risk picture with process knowledge

Build the risk picture with process knowledge

Fictional Northbank Dispatch reviews the future-state map step by step. At early assignment, it considers stale carrier data. At label printing, it considers an unreadable or duplicate identifier. At staging, it considers a carton placed in an obstructed lane. At confirmation, it considers network loss or bypass. At recovery, it considers a manifest that is not reconciled before normal operation resumes.

Operators contribute actual failure situations, systems staff explain dependencies, the safety representative reviews movement, and the transport coordinator reviews customer exposure. Existing controls are described as they operate, not as policy says they should operate. The team records uncertainty where incident data are sparse. A risk review that includes only project staff can miss the awkward conditions experienced on nights, during temporary staffing, or in a collection rush.

03 · Use ratings without false precision

Use ratings without false precision

Northbank uses a local consequence scale from one to five and a likelihood scale from one to five for screening. It defines consequence categories in words, including customer impact, traceability, safety, and recovery burden. Likelihood categories are tied to the expected operating context rather than invented probabilities. A five-by-five matrix helps prioritize discussion, but an ordinal product is not a measured expected loss.

The team treats severe traceability or safety consequences as requiring review regardless of the numerical product. It also considers detectability separately: a failure caught before loading has a different exposure from one discovered after the vehicle departs. If an FMEA-style priority number is used, its convention is stated locally and it does not override severity rules. A low score can reflect low assumed frequency rather than acceptable consequences. Rating disagreement is recorded as uncertainty to investigate, not averaged away automatically.

04 · Worked risks and controls

Worked risks and controls

For stale carrier data, the team estimates consequence four and likelihood three under the unmodified design, giving a local screening product of twelve. It adds a reassignment status and carton-to-lane check before loading. For scanner outage, it uses consequence three and likelihood three, product nine, and prepares an approved manifest fallback. For duplicate manifest records, it uses consequence four and likelihood two, product eight, with reconciliation and controlled identifier handling.

After controls, the team judges stale-data likelihood lower, but it does not simply mark the risk closed. The pilot must demonstrate that alerts appear on every shift and that operators act on them. The systems owner owns alert verification; the dispatch owner owns response capability. The manual fallback remains conditional on a successful rehearsal. Controls reduce exposure only if they are effective, available, and used under the conditions where the failure can occur.

05 · Quantify only where the assumptions support it

Quantify only where the assumptions support it

For a financial sensitivity check, Northbank considers an outage scenario with a 0.10 annual probability and a £2,000 incremental disruption cost if it occurs. The simple expected annual loss is 0.10 × £2,000 = £200. Both inputs are local hypothetical assumptions, not values inferred from the ordinal matrix. The team compares the estimate with incident history and examines a worse scenario where the outage affects a major collection wave.

Expected value is useful for an appraisal line but does not describe the tail consequence or determine acceptability. Two risks may share a network dependency, so adding their independent-looking expected losses can misrepresent their joint behavior. Northbank therefore records a combined outage scenario and checks fallback capacity. For safety and traceability, it does not reduce the decision to a pound value. The responsible owners assess whether the operating controls meet the actual requirements.

06 · Weak versus strong analysis and advanced adaptation

Weak versus strong analysis and advanced adaptation

Weak practice creates a register once, assigns reassuring residual scores before controls are tested, or treats a product threshold as automatic permission to proceed. Strong analysis links failure modes to the map, names control owners, distinguishes prevention from detection, and requires evidence before accepting residual risk. It updates the review when configuration, demand mix, staffing, or carrier conditions change.

Advanced teams examine common-cause failures and control dependencies. An alert and a confirmation screen may both depend on the same network, so they are not independent layers of protection. A manual fallback may rely on a printer affected by the same outage. Northbank tests those dependencies and keeps contingency equipment appropriately available. During rollout, each new lane reviews whether the pilot’s risk assumptions still apply. Risk analysis remains a living design and decision process, with explicit review triggers and recorded acceptance of the remaining uncertainty.

07 · Operating conditions and evidence

Operating conditions and evidence

A residual-risk decision belongs to an authorized owner, not to the person who calculated the score. Northbank documents the control evidence, remaining uncertainty, scope, and review trigger when accepting a lane for operation. If a fallback works only with a trained shift lead, the staffing condition is part of acceptance. A later staffing change therefore triggers review rather than silently invalidating the assumption.

Risk analysis also asks whether a control creates a new failure mode. A confirmation step can improve identity checking while producing a queue that obscures aisle access or encourages bypass. A stricter assignment rule can protect traceability while trapping cartons in an exception status nobody owns. The team evaluates these consequences with the process map and pilot guardrails. This keeps the analysis from becoming a list of original risks with reassuring controls attached. Effective controls must be examined as operating changes with their own dependencies and failure modes.

08 · Decision record and next step

Decision record and next step

The risk register records the basis of each likelihood judgment. Northbank distinguishes incident history, expert judgment, and an untested assumption. If two years of reliable records exist, they may inform a frequency estimate; if the failure mode is introduced by new software, historical absence may say little. This distinction helps the team allocate investigation rather than treating every rating as equally informed.

Review frequency follows change and exposure. The team reviews risks before the pilot, after a significant design revision, before each rollout wave, and when operating conditions change. It does not wait for a scheduled annual review when a new scanner bypass appears. Open controls have owners and evidence dates, while accepted residual risks retain their scope and review trigger. The register becomes useful when it informs real choices about design, readiness, and response. A polished table without those links is only a record of a meeting.

Failure mode → controls → residual reviewThe sequence is Describe exposure, then Verify controls, then Accept within scope.Describe exposureVerify controlsAccept within scope
Failure mode → controls → residual review. The diagram shows decision logic, not proof of effect.
Risk Analysis decision record
Failure modeControl approachResidual review question
Stale assignmentVisible revision status and identity confirmationDo alerts work across all shifts and configurations?
Confirmation unavailableApproved manifest and reconciliationCan the fallback preserve traceability at peak volume?
Queue and bypassPeak capacity plus operating observationDoes added checking create pressure to skip the control?

Connections

Related methods and phase use

Placed under Improve 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.