Document {{ORG_PREFIX}}-014
Management of Change Procedure¶
1. Purpose¶
This procedure makes change deliberate. Whenever {{ORG_NAME}} changes what it does, how it does it, or the system that governs it, the change is assessed before it happens, executed in a planned way, and reviewed afterwards for what it actually caused. It implements the Risk, Opportunity & Hazard Methodology at the moment of change — the point where most new risk enters a small organisation — and serves both disciplines with one process: quality-side planning of changes and OH&S-side management of change are the same steps here.
2. Scope¶
Planned change is in scope whether it lands for good or only for a stated period, wherever it surfaces in the business. The people side can change: restructures, role changes, and staffing moves that shift how work is controlled and who holds which responsibilities and authorities. The tooling can change: equipment, software, technology, or materials brought in or modified. The offer can change: services, markets, or product×market sleeves added, dropped, or reshaped. The footprint can change: new sites, new field contexts, new operating jurisdictions. What {{ORG_NAME}} knows can change: hazard information that newly comes to light. What binds it can change: obligations arriving, shifting, or lapsing, whether imposed by law or taken on by commitment. And the IMS can change itself: its documents, processes, and registers. Every one of these routes through this procedure's assessment.
So does change nobody planned. Anything discovered to have changed without passing through this procedure is treated as an unintended change and pulled back into it (§3.2).
Routine document revisions that alter no process (typo fixes, clarifications) follow the PR lifecycle in the Document & Record Control Procedure without a change assessment; the reviewer's checklist is the judgement point for whether a revision is "routine".
3. Procedure¶
3.1 Change assessment¶
| Step | Action | Responsible role | Output / record |
|---|---|---|---|
| 1 | Identify and describe the proposed change: what changes, why, when, whether temporary or permanent, and who is affected. Any role may propose a change; the proposer brings it to the {{ROLE_OHS_COORDINATOR}} (changes with OH&S dimensions) or the {{ROLE_QUALITY_MANAGER}} (purely quality/system changes). | Proposing role | Change description (job file or register notes) |
| 2 | Assess before implementation: the change never precedes the assessment. The assessing role starts with what binds {{ORG_NAME}}, checking which Instruments & Commitments and Compliance Obligations register entries the change touches, per the Compliance Obligations Procedure. From there, with the proposer: what the change is for and what else it could set off; which documents, processes, and registers stop being true once it lands, and whether any process would run ahead of the document that describes it (step 5); which roles gain responsibilities and authorities and which hand them over, and whether the People register and the affected documents still name the right role for each task; when the change window falls, and who must be consulted before it opens; whether the resources are there to do it properly; and, for a temporary change, who reverts it and when (step 4). Anything else the change reaches goes in the assessment notes too. | Assessing role with the proposer | Assessment notes |
| 3 | Assess risks and hazards per the Risk, Opportunity & Hazard Methodology: identify hazards the change introduces or alters, assess inherent and residual ratings for new or changed risks, update or create Risk & Opportunity Register and Hazard Register rows, and choose controls via the hierarchy of controls. Changes are also assessed for the OH&S opportunities they open (a change is often the cheapest moment to eliminate a hazard outright). Workers affected by the change are consulted as part of this step. | {{ROLE_OHS_COORDINATOR}} with affected workers | Updated register rows |
| 4 | Decide: proceed, proceed with conditions, or don't. Changes whose residual risk sits High or Extreme, or which alter the IMS's scope or structure, are decided by {{ROLE_TOP_MANAGEMENT}}; others by the assessing role. Temporary changes get an expiry date and a named reverting role. | Deciding role per above | Decision recorded with the assessment |
| 5 | Execute in a planned way: sequence the work, update the affected controlled documents through the PR lifecycle in the same window as the operational change (a process must not run ahead of the document that describes it for longer than the change window), deliver any training the change requires, and communicate per the change's communication needs. | Proposing role with document owners | Document revisions; training rows; communications |
| 6 | Review after implementation: did the change do what was intended, and what else did it do? Answer both questions, unintended effects included, and act on every adverse effect the review turns up: put right any damage already done, and control any effect that has not yet done damage. Confirm register rows, documents, and training reflect reality. | Assessing role | Review note closing the change |
3.2 Unintended change¶
When anyone discovers that something material has changed without assessment — a process drifted, equipment was substituted, a client changed the ground rules mid-project — it is handled as an unintended change: report it to the assessing role, run steps 2–4 retrospectively at a pace proportionate to the exposure, mitigate any adverse effects already in play, and record what happened. A recurring pattern of unintended change in one area is raised as a nonconformity so its cause gets corrected.
3.3 Where change lands in the registers¶
Change assessments do not get their own register: a change either touches risk/hazard rows (updated per step 3), documents (PR lifecycle carries the trace), compliance obligations (updated per the Compliance Obligations Procedure), or objectives (adjusted at management review). The assessment itself is retained with the thing it changed — in the job file for project-level changes, in the PR description for system changes [ORG-DECISION: single change-log location if the organisation prefers one].
4. Records and Registers¶
| Activity | Register (index) | Record (evidence) |
|---|---|---|
| Risk/hazard impacts of change | Risk & Opportunity Register; Hazard Register | Updated rows (inherent → controls → residual per the methodology) |
| System/document changes | Document Register (version, dates) | The PR itself — assessment summary in the PR description, per-job records in the job file ("operational" evidence) |
| Requirement changes | Instruments & Commitments; Compliance Obligations | Per the Compliance Obligations Procedure |
5. Exceptions¶
Emergency changes (immediate action needed to protect people, data, or a deliverable) may be executed before assessment, with two hard conditions: make the situation safe first, and run the full assessment retrospectively within [ORG-DECISION: retrospective assessment window, e.g. 5 working days]. No exception is available to the post-implementation review or to consulting the workers a change affects.
6. Related Documents¶
risk-opportunity-hazard-methodology— the assessment method this procedure applies at the moment of change (implements).document-record-control-procedure— the PR lifecycle that lands document changes.compliance-obligations-procedure— requirement changes in and out of the change process.
7. Revision History¶
| Version | Date | Author | Description of Changes | Reviewed By | Review Date | Approved By | Approval Date |
|---|---|---|---|---|---|---|---|
| 0.1 | 2026-07-16 | {{ROLE_OHS_COORDINATOR}} | Initial draft | — | — | — | — |
8. Document Control
| Document | {{ORG_PREFIX}}-014 |
|---|---|
| Type | Procedure |
| Version | 0.1 |
| Status | Draft |
| Owner | {{ROLE_OHS_COORDINATOR}} |
| Reviewer | {{ROLE_QUALITY_MANAGER}} |
| Approver | {{ROLE_TOP_MANAGEMENT}} |
| Next Review | 2026-08-15 |
| Classification | Internal |
Held in the document frontmatter, mirrored to the Document Register.