Hello. This first lesson begins at the handoff from assessment to planning. The task is not to convert every finding into a change activity. It is to decide what must be different in operational work, what could prevent that difference, and who is best placed to address it.
We will use an anonymised digital isolation-planning case throughout. A tool is being validated to generate proposed isolation designs; qualified personnel would still review, verify, amend where necessary, and authorise plans. Some future workflow and integration decisions remain open. By the end of this lesson, you will have a provisional two-impact Impact-to-Intervention Matrix and a rule for deciding whether each finding calls for change support, project or technical action, monitoring, or no additional action. Allow about 35–40 minutes, including the readings and time to adapt the example to your assessment.
Start with the work, not the activity
A useful planning chain begins with an intended project outcome, then asks what operational work must change to achieve it. For this case, an intended efficiency benefit might depend on qualified reviewers being able to assess a generated proposal effectively. That does not mean fewer technical corrections are inherently better: a justified correction or safety challenge is evidence that review is functioning, not resistance to the change.
An assessment might record “designers are concerned about the tool.” That is not yet an intervention brief. What are they concerned about: the proposal’s technical quality, visibility of its source information, time available for review, authority to amend it, or something else? Each answer points to a different owner and response. A technical defect needs a technical fix and assurance. An unclear review hand-off needs a process decision. A demonstrated gap in applying an agreed review method may need capability support.
The Health and Safety Executive’s task-analysis questions offer a compact way to get beneath labels such as “resistance” or “training need.”
[PDF] Reducing error and influencing behaviour - HSE Books
Read this Health and Safety Executive guidance to sharpen the distinction between how a task is designed and how people are expected to perform it.
In Chapter 5, “Human factors in risk assessments,” go to Step 2 and Box P, “Analysing an activity,” on p. 43. Read the task questions. Focus on decisions, information sources, competence, time constraints, and how errors are detected and corrected. Immediately below Box P, in Step 3, read the control guidance. Notice why asking people to be more careful cannot substitute for sound task and system design.
For isolation planning, a walkthrough with a qualified reviewer should therefore ask not only whether they will check a generated proposal, but what information they need to verify it, where that information comes from, how they record a correction, and what happens if the proposal cannot be verified. Compare the walkthrough with the designed process. A difference may reveal a design issue, an adoption issue, or both.
Choose a response lane before choosing an intervention
Use the following rule for each assessment finding. Choose a lead response, while recording any supporting dependencies separately.
| Lead response | Decision rule | Illustrative isolation-planning finding |
|---|---|---|
| Active change intervention | A material future behaviour, decision or capability is sufficiently defined, and targeted engagement or performance support can address an evidenced or credible barrier. | Qualified reviewers need to help test how proposed designs will be scrutinised and amended in actual work. |
| Project or technical action | The process, interface, information, accountability or safety-related design is unresolved or defective. People cannot reasonably adopt the intended work until it is settled. | The source-document workflow is undecided; the project must define and test it before issuing instructions. |
| Monitor | An uncertain, lower-consequence issue has a clear indicator and review point; there is no present basis for a larger response. | A minor usability concern is logged for observation during a bounded trial. |
| No additional action | Evidence shows existing arrangements already address the impact, with no material new behaviour or gap. Record the reason. | An unchanged task is already covered by a verified, usable procedure and current competence arrangements. |
Consequence matters. Do not put an unresolved safety-critical question into “monitor” merely because evidence is incomplete. Route the design or assurance question to the appropriate owner and make its resolution a decision gate. Change support can help people adopt an approved process; it cannot validate an isolation design or replace existing safety accountability.
These lanes also prevent a familiar planning error: prescribing training because a template has a training row. First establish the task and proficiency required, check what current isolation and permit-related training already covers, and identify any actual gap. The eventual answer may be practice, a job aid, coaching, supervision, a design change, formal training, or a combination.
The next reading reinforces why a usable, tested procedure is a project deliverable—not something a communications campaign can repair afterward.
Effective Integration of Human Factors into HSE Management Systems
Read this Working Group 5 paper for its treatment of procedure usability and validation. Apply it to the still-unsettled isolation-planning workflow.
In Section 5.3, “Procedures and Work Instructions,” under “How Does Human Factors Relate to Procedures and Work Instructions?” (p. 40), start at the bullet on procedure suitability and stop at the verification-and-validation bullet. Focus on the difference between publishing an instruction and establishing that people can use it correctly in the intended work setting.
A worked two-impact matrix
The matrix is a decision record, not a promise that the future workflow is final. In the example below, given information comes from the case description; a hypothesis is something to investigate; and an assumption is a provisional choice made to progress planning. Keeping those labels visible prevents a plausible story from hardening into a false fact.
| Matrix field | Impact 1: reviewing generated proposals | Impact 2: source-information and hand-off workflow |
|---|---|---|
| Impact or requirement | Given: planning shifts from predominantly manual design to tool-generated proposals that qualified personnel review, verify, amend where needed, and authorise. The tool is still being validated. | Potential material impact: the way source documents or connected systems supply and update information for a proposal may alter hand-offs. Its scope and future workflow are not yet decided. |
| Affected stakeholder | Qualified isolation designers/requesters; the process owner responsible for the review method. | Operational representatives, relevant engineering specialists, qualified reviewers, and the process/tool owners—subject to the agreed scope. |
| Required future behaviour or capability | Review a proposal against the required technical information; challenge it; make and document justified amendments; retain qualified authorisation. The precise review steps await process approval. | Conditional: if the workflow changes, people must know which source is authoritative, who resolves discrepancies, and how exceptions reach a qualified decision-maker. Do not assign new duties yet. |
| Barrier or uncertainty | Hypotheses: information may be hard to inspect, reviewers may lack a practical method for recording amendments, or time pressure may discourage thorough review. No capability deficit has yet been demonstrated. | Unresolved design question: document and system interfaces, ownership of discrepancies, and some use cases remain open. A briefing cannot resolve these. |
| Lead response and reason | Active change intervention: involve qualified reviewers in realistic workflow walkthroughs and feedback before finalising the review support. Project/technical dependency: validate proposal quality and the review interface through the appropriate assurance processes. | Project/technical action: decide scope, information sources and exception ownership; test the resulting workflow with affected roles. Defer rollout communications and any training design until those decisions exist. |
| Provisional owner | Change lead owns the walkthrough and feedback record; process owner owns the review procedure; technical/assurance owners retain their respective validation responsibilities. Confirm named accountability locally. | Project process owner, with the relevant interface and information owners, owns the decision. Change lead tracks the dependency and revisits impacts after it closes. |
| Timing or gate | During tool and process validation; agree the review method and any support before readiness is declared. | Resolve or explicitly exclude the relevant workflow before committing to role instructions, capability support or deployment for that scope. |
| Evidence it worked | In observed, representative trials, qualified reviewers can locate necessary information, identify and justify corrections, record amendments, and explain authorisation boundaries. Unresolved usability or assurance findings are acted on—not counted as “adoption.” | A documented scope and hand-off decision, a tested procedure for applicable scenarios, and affected-role confirmation that exceptions have a workable route. If excluded, the boundary is explicit. |
| Validation before commitment | Walk through normal and difficult examples with qualified reviewers; check existing training and competence requirements; examine trial feedback and assurance findings before choosing job aids, practice or formal training. | Confirm which interfaces and document workflows are in scope; map actual hand-offs with affected roles; obtain the required process and technical decisions, then reassess the change impact. |
The two rows deliberately lead to different responses. Impact 1 contains a sufficiently clear change in the reviewer’s work to justify involving reviewers now, even though the final support package is undecided. Impact 2 may be consequential, but its future state is too uncertain to teach. Its immediate Plan-phase value is as a tracked decision gate, not a speculative training commitment.
“Evidence it worked” should test the claimed outcome, not merely record that an activity happened. A completed walkthrough establishes participation; it does not establish that reviewers can detect an incorrect proposal. Likewise, reducing every amendment would be a poor success measure: separate justified technical or safety corrections from avoidable preference-based rework before drawing conclusions about efficiency.
Pressure-test the logic before it enters a plan
Suppose an early draft says: “Designers may distrust the tool; send an email explaining its benefits and require everyone to complete training.” It makes three unsupported jumps. “Distrust” has not been diagnosed; an email cannot demonstrate proposal quality or settle review authority; and no specific competence gap has been established. A stronger record would retain trust as a hypothesis, identify what evidence could confirm or disconfirm it, and distinguish assurance of the proposal from support for the reviewer’s task.
For each row you retain, apply four checks:
- Materiality: What project outcome or essential control depends on this impact being handled? If none is identifiable, why is it in the priority matrix?
- Behaviour: Could you observe the future action or decision? “Understands the change” is weaker than “checks the proposal against specified information and records a justified amendment.”
- Response fit: Does the proposed owner have the means and authority to remove the barrier? Escalate design and assurance defects rather than relabelling them as engagement problems.
- Commitment test: What must be confirmed before you spend effort or announce a solution? Name the evidence, decision-maker and gate.
A useful working convention is to mark every matrix entry G (given or evidenced), H (hypothesis to test), or A (assumption made for planning). Where a row depends on an open project decision, put that decision in the timing field. This makes the matrix useful now without presenting it as implementation-ready.
Closing perspective
Good Plan-phase thinking is selective. It connects an intended outcome to a material change in work, describes the required behaviour, investigates the barrier, and assigns the response to an owner who can actually address it. The two example rows show why one impact can warrant early reviewer involvement while another must wait on a process or technical decision. In both, qualified review and safety accountability remain non-negotiable.
Use the worked matrix as a provisional draft against your assessment findings: retain what the evidence supports, replace the hypotheses with what you learn from operational walkthroughs, and leave unresolved scope visible as gates. In the next lesson, you will draw strategic choices from these impact decisions—without turning the Change Strategy into a longer list of activities.