Why Walk Through a Process?
A risk assessment can miss important exposure when it considers objectives in the abstract but not the work needed to achieve them. A process walkthrough follows that work in sequence: what initiates it, what people and systems do, where responsibility changes, what decisions are made, and what output is produced. At each point, the discussion asks what uncertainty could prevent the process from producing the intended result.
A walkthrough is a structured conversation, not an audit and not a search for someone to blame. Process owners and participants explain how work is intended to happen and, where relevant, how it actually happens. The facilitator tests the sequence with questions about exceptions, dependencies, and decisions. The purpose is to identify plausible uncertain events—not to estimate their likelihood, score their impact, or conclude that a control is effective.
Set the Boundaries Before Tracing the Work
Begin with a clear objective and a workable boundary. State what starts the process, what output marks its end, and which organizational area or time period is in scope. A boundary that is too broad produces a vague conversation; one that is too narrow may omit the handoff or decision where uncertainty arises.
For example, “manage claims” is too broad to trace usefully. “Receive a reported commercial property claim and issue an authorized initial payment” gives participants a start, an end, and an outcome to examine. Use the objective to keep the discussion relevant: an event matters in this assessment when it could interfere with that outcome or a related objective.
Invite the process owner, people who perform the work, and representatives of functions that receive or supply important information. A manager may describe the intended procedure, while a frontline participant knows where exceptions occur. If a process depends on another team, include that team or note the dependency for follow-up. Ownership means responsibility for explaining or managing the work; it does not imply personal fault if something goes wrong.
Trace Activities, Handoffs, Decisions, and Dependencies
Follow the process in chronological order. At each activity, ask what input is used, what action transforms it, who performs the action, and what output moves forward. At handoffs, ask what information or work product is transferred, who accepts it, and what could be delayed, lost, misunderstood, or rejected. At decisions, identify the decision-maker, the information used, and the conditions that lead to different routes. At dependencies, ask what another team, system, supplier, or data source must provide for the step to work.
These questions locate points where uncertainty may enter or accumulate. They do not mean that every activity is a risk. A routine step becomes relevant to risk identification when an uncertain event could affect an objective—for example, a required data field may be missing, a decision may be made using stale information, or a handoff may not reach the next owner in time.
State the trigger, intended output, and scope. Check that participants agree what process they are tracing.
Ask participants to describe each activity in order, naming the responsible role and the information or work product used and produced.
Examine handoffs, decision points, exceptions, and dependencies. Ask what could vary or fail and how that could affect the objective.
Use the earlier material on cause-event-effect risk statements to distinguish a cause, an uncertain event, and its possible consequence.
Ask participants to confirm the sequence, owners, and identified uncertainties. Record assumptions or missing information for later verification rather than presenting them as established facts.
A process walkthrough is most useful when it follows exceptions as well as the normal route. Ask what happens if an input is incomplete, a decision is delayed, a system is unavailable, or a case follows a less common route. Keep the discussion anchored to the defined process: a long list of general concerns is not a substitute for tracing where and how an event could occur.
Worked Examples
Worked Example: Tracing a Claim From Notice to Initial Payment
A hypothetical insurer wants to identify risks in the process that takes a commercial property claim from first notice to an authorized initial payment. The claims process owner, an intake representative, an adjuster, and a payment specialist take part. The objective is to issue an accurate, authorized initial payment without avoidable delay.
Step 1: Define the boundary. The trigger is receipt of a claim notice. The end point is release of the authorized initial payment. This keeps the walkthrough from expanding into the entire life of a claim.
Step 2: Trace the activities. The intake representative records the notice and creates a claim file. An adjuster reviews coverage information and available loss details, requests missing information, and recommends an initial amount. An authorized supervisor reviews the recommendation. The payment specialist enters the approved amount and releases payment.
Step 3: Examine handoffs and decisions. At intake-to-adjuster handoff, the file must contain accurate policy and contact details. At the adjuster’s decision, the recommendation depends on the reported loss facts and coverage information. At supervisor review, approval depends on the recommendation and supporting documentation. At the final handoff, the payment entry must match the approved amount and payee.
Step 4: State uncertainties as events. A plausible risk statement is: “Because required claim details may be entered inconsistently at intake, the adjuster may receive an incomplete file, delaying the initial coverage and payment decision.” The cause is possible inconsistent entry; the event is an incomplete file reaching the adjuster; the consequence is delay. Another is: “Because an approved amount is transferred manually, the payment entry may differ from the authorized amount, resulting in an incorrect initial payment.”
Step 5: Check ownership and avoid the trap. The intake lead can explain entry practices, the adjuster owns the assessment step, and the payment specialist explains release. The supervisor’s review is relevant, but its existence does not prove that every transfer is accurate. A common mistake is to label “no second review” as the risk itself. That describes a possible control weakness; the risk event should identify what might happen and its effect. The walkthrough identifies these uncertainties without concluding whether existing controls are sufficient.
Worked Example: Following Information Across a Reinsurance Renewal
A hypothetical insurer examines how exposure information is assembled for a property reinsurance renewal. The intended output is a reviewed exposure submission delivered to the reinsurance team by an agreed date. Participants include the exposure-data owner, underwriting operations, catastrophe analytics, and the reinsurance submission owner.
Step 1: Set the scope. The process begins when the renewal data request is issued and ends when the reviewed submission is delivered. The objective is a sufficiently complete and accurate submission on time.
Step 2: Follow the normal sequence. Underwriting operations extracts policy records. The exposure-data owner checks required fields and returns exceptions for correction. Catastrophe analytics receives the corrected data and produces requested summaries. The reinsurance submission owner reviews the results, resolves questions with contributing teams, and sends the final package.
Step 3: Examine dependencies. The extraction depends on policy records being available for the chosen valuation date. The analytics step depends on receiving consistent location and coverage fields. The final submission depends on analytics completing its output early enough for review. These are links between activities and teams; the walkthrough asks what uncertainty at each link could disrupt the output.
Step 4: Identify and phrase events. If teams use different extraction dates, records may not represent a consistent portfolio snapshot, which could make the submission inaccurate. If a required location field is missing and not returned for correction, catastrophe summaries may omit or misclassify exposures. If analytics delivery is delayed, the reviewer may not have time to resolve material questions before the deadline.
Step 5: Confirm the source of uncertainty. The data owner can confirm the extraction convention, and the analytics owner can explain which fields are required for the output. If participants cannot verify whether the same date convention is used, record it as an open question. Do not state that a date mismatch has occurred unless evidence supports that claim. This avoids turning a possible dependency into an asserted incident.
Worked Example: Tracing a Large-Loss Referral Decision
A hypothetical insurer walks through its process for referring a potentially large commercial liability claim for additional authority. The process starts when a claim handler records new information and ends when the claim is either referred to the designated authority or remains within the handler’s authority. The objective is to route cases requiring additional authority to the appropriate decision-maker.
Step 1: Reconstruct the route. The handler updates the claim estimate when new information arrives. A system rule flags claims above a stated threshold. The handler reviews the flag and supporting information, then submits a referral. A specialist reviews the referral and decides whether further action is required.
Step 2: Inspect the decision point. The threshold only helps if the estimate is updated and the rule uses the intended field. The handler’s review matters because an alert may require interpretation. The referral handoff matters because the specialist needs the current estimate and supporting information to make a decision.
Step 3: Identify conditional uncertainties. If a revised estimate is recorded in a field not used by the rule, the claim may not be flagged for referral. If the handler receives an alert but misunderstands the required action, a referral may not be submitted. If supporting documents are omitted, the specialist may need to return the case, delaying the decision.
Step 4: Name owners and check the result. The handler explains estimate updates and referral practice; the system owner explains how the rule is configured; the specialist explains referral requirements. A useful statement is: “Because the referral rule may not use the field updated by handlers, a claim meeting the referral threshold may not be flagged, delaying review by the designated authority.” It identifies a cause, event, and consequence rather than treating “system threshold” as a complete risk statement.
Method and trap avoided. The method follows the claim through its data update, automated decision trigger, human review, and referral handoff. The trap is to assume that an automated flag guarantees referral. The walkthrough tests the chain of conditions needed for that outcome; it does not infer that the rule is functioning merely because it exists.
Why Inspect Each Point in Sequence?
For a simple justification, consider a process with \(n\) necessary stages. Suppose, only for illustration, that stage \(j\) succeeds with probability \(p_j\), that the stages are independent, and that the process output succeeds only if every stage succeeds. The event “successful output” is then the intersection of the stage-success events. Independence gives:
For three hypothetical stages with success probabilities \(0.98\), \(0.95\), and \(0.99\), the calculation is \(0.98\times0.95=0.931\), followed by \(0.931\times0.99=0.92169\). Thus the illustrative probability of success across all three stages is \(0.92169\). This calculation is not a risk assessment of a real process; its assumptions may not hold, and a walkthrough does not require assigning probabilities. It illustrates why examining only the final activity can overlook uncertainty in earlier steps or handoffs. Where stages depend on shared information or common systems, independence is especially unsafe to assume.
Common Traps and Practical Checks
Walkthrough quality depends on distinguishing uncertainty from other observations. Use the earlier material on separating risks, causes, consequences, and issues when drafting statements. A confirmed late submission is an issue that has occurred; possible future late submission is a risk event. “Training is inadequate” may describe a cause or control concern, but it is not by itself a complete event-and-consequence statement.
Another trap is to trace only the formal procedure. Ask participants whether exceptions, workarounds, or informal approvals occur, while keeping unverified accounts clearly labelled for follow-up. A third is to stop at departmental boundaries. If an output is passed to another team, include the receiving party’s requirements or record the dependency explicitly. Finally, do not treat every hypothetical failure as equally credible or important. This walkthrough identifies plausible events; likelihood and impact assessment are separate tasks.
- Can participants state the process objective, trigger, and end point consistently?
- Has the discussion followed the work through its key handoffs and decisions?
- Are important systems, information sources, and other teams identified as dependencies?
- Does each proposed risk statement distinguish cause, uncertain event, and possible consequence?
- Are assumptions and unknowns recorded as questions rather than asserted as facts?
Check Your Understanding
For each situation, identify the useful walkthrough boundary or point of uncertainty and give a concise answer.
- A hypothetical insurer wants to examine premium collection from the monthly billing file to posting of cash. Name a suitable start and end point, and one handoff to examine. (Answer: Start with creation or release of the monthly billing file and end with cash posted to the relevant accounts; examine the transfer of payment details from the collection channel to the posting team or system.)
- In a hypothetical claim process, a claim handler records a revised estimate, but a referral rule reads a different estimate field. State the cause, uncertain event, and possible consequence. (Answer: Cause: the rule may read a different field from the one updated; event: an estimate above the referral threshold may not trigger a flag; consequence: required review may be delayed or missed.)
- A hypothetical underwriting submission depends on location data from a separate team. What should the walkthrough establish about this dependency? (Answer: Identify the data owner and receiving process owner, the required fields and timing, how exceptions are returned, and what uncertain event could prevent usable data from reaching the submission process.)
- Participants report that one payment was delayed last month. How should a facilitator distinguish this observation from a prospective risk statement? (Answer: Record the delay as an observed issue; separately state a plausible future cause-event-consequence risk only if an uncertain event could recur and affect the process objective.)
- A hypothetical approval process has three necessary stages. Under the explicit assumption that stage successes are independent, their respective success probabilities are \(0.97\), \(0.96\), and \(0.98\). What is the probability all stages succeed, and why should a walkthrough still examine each stage? (Answer: \(0.97\times0.96=0.9312\), and \(0.9312\times0.98=0.912576\); inspect each stage because uncertainty at any necessary stage can affect the output, while the independence assumption may not hold in practice.)