Hello. Last lesson used two isolation-planning impacts to make different Plan-phase decisions: involve qualified reviewers in testing the proposed review work, but hold instructions about unsettled information hand-offs until the project decides and tests them. This lesson turns those decisions into a Change Strategy. The aim is a one-page statement of how you will pursue safe, effective adoption and why—not a longer list of activities.
Allow about 35–40 minutes, including the readings and a short drafting period. The case remains provisional: a digital tool is being validated to generate proposed isolation designs, while qualified personnel continue to review, verify, amend where necessary and authorise plans under the applicable accountabilities. Neither the final workflow nor every use case has been settled.
A strategy makes choices that plans can implement
A change plan says what will happen and when. A communications plan specifies a subset of those actions. A strategy sits above both: it states which adoption problems matter most, what approach will address them, and what conditions must hold before that approach can proceed.
Consider the draft statement, “Communicate the benefits, train all users and obtain leader support.” It is not yet a strategy. It does not say whether the review method is usable, which roles need a new capability, what leaders would actually do, or which decisions must be made first. More importantly, it treats every concern as though change activities could solve it.
Start instead with the intended business outcome and the work on which it depends. The isolation-planning change seeks to free planning capacity and reduce avoidable rework. Those benefits depend on generated proposals being fit for qualified scrutiny and on a workable process for checking, correcting and authorising them. Faster preparation must not be achieved by discouraging legitimate technical corrections or safety challenge. A preference-based redraw and a justified amendment are different phenomena; the strategy must not conflate them.
The following paper provides a useful discipline for defining the current baseline and a proposed end point before committing to implementation.
Making a Change, Managing Hazards, Protecting People
Read this IChemE symposium paper to connect strategic choices with the current work, the proposed end point and the implications of treating linked changes separately.
In “Change Management Process Model,” read Step 2, “Understand Current Organisational Capability,” and Step 3, “Define End Point,” on pp. 8–9. Begin with the baseline and end point, stopping immediately before Step 4. Focus on authorities, safety functions, consultation and the questions used to define the future state. Then, in Step 4, “Production of a Change Proposal,” find the “Salami Slicing Effects” explanation accompanying Figure 2 on pp. 9–10. Read the dependency warning. Apply it to connected permit, work-order and document workflows without assuming they are all in the first release.
There is an important limit to the analogy with organisational restructuring in the paper: this case is not a confirmed headcount or role-reduction change. Freeing capacity is an intended benefit; any workforce implications belong to a separate, later review. The paper is useful here because changing a workflow can still affect authority, capability and interfaces, even when positions do not change.
Derive each strategic choice from an impact and its uncertainty
Use your Impact-to-Intervention Matrix as a filter. For each material row, ask: What must be true for the intended outcome to occur? What currently prevents us from knowing or achieving that? Which response lane owns the problem? A strategy should concentrate on the few answers that govern multiple later decisions.
| Assessment input | Strategic inference | What the strategy should not assume |
|---|---|---|
| Established change: qualified people would review, verify, amend as needed and authorise generated proposals; validation is ongoing. | Prioritise a usable, demonstrable review method before expecting routine use. Involve qualified reviewers in realistic trials, while technical and assurance owners remain responsible for proposal quality and safety-related validation. | That a demonstration or favourable reaction proves the proposals are sound—or that fewer amendments always means better performance. |
| Open workflow: source-document handling and some system hand-offs are unsettled. | Make approved scope, authoritative information and exception ownership decision gates before role instructions are finalised. | That communication or training can compensate for an undefined process. |
| Stakeholder evidence still needed: role clarity, trust, consistency between operational groups and leader reinforcement may matter. | Test each as a distinct hypothesis and choose support only where findings warrant it. | That all groups share one concern or need the same intervention. |
This is the difference between a strategic choice and an activity. “Establish a review method people can use and challenge” is a choice that governs process design, assurance, engagement and later capability support. “Hold three workshops” is one possible activity; its number, format and timing belong in a plan.
The Health and Safety Executive’s organisational-change principles help set guardrails for those choices, particularly where a seemingly local workflow adjustment could affect hazard control through another role or interface.
Read the Health and Safety Executive’s ten principles as a check on the boundaries of an operational change strategy—not as a list of activities to copy.
On the “Organisational change” page, read the numbered principles 1–10 immediately above “More information on organisational change.” The range begins with the ten principles. Pay particular attention to direct and indirect effects on hazard control, consultation, successful transfer of responsibilities, and experienced support for changed roles. Ask which principles constrain a strategic decision now and which would become actions only after the future workflow is defined.
A useful principle for this case is: preserve qualified challenge and existing isolation accountability while testing whether the new workflow works in practice. It constrains every downstream plan. By contrast, “provide training” is not yet a defensible universal principle or commitment. First define performance requirements by role, check existing competence arrangements, and establish whether any gap calls for training, supervised practice, coaching, a job aid or a process redesign.
Worked example: a provisional one-page strategy
The following is a planning draft, not a claim that stakeholder concerns or process decisions have been validated. Notice how it names choices, stakeholder outcomes and gates without specifying a calendar of events.
Purpose and boundary. Seek a more efficient isolation-planning workflow within an approved scope, without weakening qualified verification, justified amendment, authorisation or existing safety accountabilities. Capacity release is an intended benefit; workforce implications are unconfirmed.
Priority 1 — Prove the review work is viable. Qualified isolation requesters/designers need to assess a generated proposal against the information required for the task, challenge it, document justified changes and use the applicable authorisation route. Prioritise realistic operational review alongside project-led tool validation. Do not treat justified technical or safety corrections as failed adoption.
Priority 2 — Settle interfaces before asking people to adopt them. Operational representatives need a workable path for discrepancies and exceptions; process owners and relevant engineering specialists need to confirm information sources, hand-offs and decision rights for their applicable scope. Keep unresolved permit-to-work and work-order integrations, document handling, turnarounds or nested isolations, and electrical cases as explicit scope decisions or gates—not promises embedded in instructions.
Priority 3 — Make support role-specific and evidence-led. Compare required proficiency with existing competence arrangements before choosing practice, job aids, coaching or formal training. Test whether role ambiguity, confidence in proposals, variation between operational groups or inconsistent leader reinforcement is actually impeding progress. Where leader action is needed, define it as protecting review time, inviting challenge and resolving escalated barriers—not merely promoting speed.
Decision conditions and assumptions. The review method and in-scope workflow require process and assurance approval before readiness claims. The extent of capability gaps and adoption barriers is unknown; use observed trials, affected-role feedback and existing training evidence to decide the response.
This draft makes three priorities, each with a reason. Its provisional nature is a strength, not an excuse for vagueness: it says precisely which unknowns could change the approach. It also leaves room for a finding of no additional change support where an existing arrangement demonstrably covers an unchanged task.
Notice how the stakeholder outcomes differ. Qualified reviewers must be able to exercise judgement on a proposal; operational representatives must be able to work with its practical hand-offs and exceptions; process and engineering owners must resolve design and information questions within their authority. Leaders’ contribution is conditional on what the assessment and trials show, rather than an assumed campaign role.
Drafting clinic: make the page withstand challenge
Set aside 10–12 minutes to write or revise your own one-page version using your assessment and the two-impact matrix. Keep the purpose to one or two sentences and limit yourself to roughly three strategic choices. For each choice, write a short margin note identifying its source—an intended outcome, a matrix row, stakeholder evidence or a clearly labelled hypothesis. The margin notes need not appear on the final page.
Before treating the draft as usable, review it against these criteria:
- Traceability: Can you identify the outcome and material impact behind each choice? Remove an activity that exists only because a template expects it.
- Stakeholder specificity: Does the page describe what different groups must be able to do or decide, rather than saying everyone must “understand and support” the change?
- Correct ownership: Are process, technical and assurance decisions left with their proper owners? Does the change approach address adoption without pretending to be a safety control?
- Evidence discipline: Are facts, hypotheses and planning assumptions distinguishable? Is there a way to test any claimed need for trust-building, role clarification, consistency or leader reinforcement?
- Gates and boundaries: Would a reader know which unresolved scope or interface decisions block instructions, capability commitments or readiness? Does the page preserve qualified review and avoid implying a confirmed workforce reduction?
A strong practitioner would also challenge what the page rewards. If it celebrates reduced review time or fewer amendments without distinguishing justified corrections from preference-based rework, it could create pressure against the very scrutiny the future process requires. If it promises uniform adoption before representative work has been tested, it hides variation rather than managing it.
You can bring your draft back for critique against these criteria. The most useful critique will identify a consequential unsupported assumption or missing decision—not just edit its wording.
Closing perspective
A defensible Change Strategy is a compact set of prioritised choices under explicit constraints. Here, the choices are to establish a viable qualified-review method, hold undefined interfaces at decision gates, and tailor support to demonstrated role needs. They derive from intended benefits and assessed impacts, while leaving unresolved evidence visible.
The next lesson will examine the risks and barriers behind those choices more rigorously. In particular, it will distinguish an adoption barrier that change support can address from a process, technical or operational risk that requires another owner.