The procedure is approved. The email has gone out. Yet the night shift still has the old instruction. Who joins the dots when your management system leaves a gap?
ORR IMS is an evolving learning example, currently connecting five starter kits. It is not a complete implementation of the four standards in its intended scope.
If you coordinate an IMS, that question can feel uncomfortably familiar. A concern reaches your desk because somebody needs an answer, a missing record or a decision that crosses departmental boundaries. You chase the right people and get the immediate problem moving. Then another concern arrives through a different route.
The useful question is where responsibility gets lost between teams. This opening article follows that boundary: what leaves one person’s hands, who receives it and how an unresolved handoff reaches someone who can decide.
An integrated management system should help people recognise the relevant connections and act within clear responsibilities. When the connections depend on one person’s memory, there is something worth examining.
Begin at the workpoint
Consider Cedar Estuary Blending, the fictional company used in ORR IMS’s worked example. It operates two shifts. A customer specification changes, but the night-shift folder still contains the earlier instruction.
The case establishes exposure to an obsolete specification. It does not claim that an incorrect batch was dispatched. That distinction matters: understanding a weakness does not require inventing a disaster.
The daytime email has achieved distribution to some people. The team still needs to establish whether everyone affected can access the authorised instruction before using it. Those are different questions, with different evidence.
Who owns the specification? Who identifies the affected shifts? Who checks access? What happens if acknowledgment is missing? Who can hold the relevant decision, and who resolves the obstacle?
A document may describe each responsibility. Integration becomes visible when the answers connect during an actual change.
Follow the problem across the system
Map the handoff as a shared commitment. The sender identifies what has changed; the receiver confirms what they need to act; the responsible owner resolves missing information. If nobody can name the receiving role, the coordinator has found a gap that another reminder will not close.
Then agree how both sides will recognise that the handoff is complete, and who receives the question if they disagree.
That trail connects the work to the management system’s objectives, risk arrangements, document control and review. It also reaches resource decisions. If the night shift needs time to be briefed, someone with authority must make that time available.
ISO’s overview of management systems describes the system in terms of interrelated business activities and objectives. Its complexity depends on the organisation. That gives us a useful starting question: what does this particular organisation need to manage its work reliably?
Combining several manuals might make information easier to navigate. It does not, by itself, answer who receives a change or what happens when the handoff fails.
Do we need certification before starting?
You can begin learning, mapping work and improving your management arrangements before seeking certification. Implementing a management system and obtaining an independent certificate are separate activities.
Certification may matter because of customer expectations, contracts or other applicable obligations. Establish those needs for your organisation rather than assuming they are irrelevant. ISO explains that certification is performed by external certification bodies; ISO itself does not issue the certificates.
A learning example cannot confer certification or establish that your organisation meets a standard. It can help you ask better implementation questions and identify evidence you still need.
For an ISO enthusiast, that makes room for useful work immediately: understand the process, bring the right people into the discussion and make one important connection explicit.
Why I am sharing ORR IMS
ORR IMS is a public learning concept with connected procedures, worksheets and fictional records. I am sharing it so people can examine how requirements and management intentions might become everyday decisions.
The current starting loop connects five kits: context and scope, risks and controls, objectives, document control and management review. The wider library is still developing. It does not provide a complete implementation of the standards it intends to help people explore.
Cedar Estuary is deliberately imperfect. Its example includes a held release, a missed execution, a corrected result and a reopened risk. That gives us something more useful to discuss than an unexplained row of successful ticks.
Would the instructions make sense to a new implementer? Is the owner clear? Is the evidence proportionate? Where might someone follow the procedure and still misunderstand the intended decision?
Those questions can improve the concept.
Map one handoff
A fictional design studio agrees a new delivery format with a customer. The account manager updates the brief, but the freelance designer still has the earlier version. The useful question is who confirms that the changed requirement reached the person producing the work.
Write a four-line handoff map: intended outcome, receiving person, confirmation needed and response if confirmation is missing.
Start with the context-and-scope worksheet. Which handoff would you map first? Leave a comment below; a question or fictional example is enough. If you want to propose a document change, the contribution guide explains the optional GitHub route.
Use fictional examples only. Do not share employer or client records, personal information or copied standards text.
Images are AI-generated illustrations, not photographs or evidence of actual implementation.
Part 1 of 12 in Making IMS Work with ORR IMS. Explore the series.
Leave a Reply