On a shutdown running a dozen or more concurrent permits, the interaction matrix and the cross-permit dashboard tell you which jobs conflict with which. What they don't tell the incoming shift is what changed six hours ago on the deck next to theirs, or that the isolation their permit depends on is now shared with a vessel-entry crew who came on after the previous briefing pack was printed. Visibility tools give you the picture. They don't hand it over.
That gap — between what the system shows and what the next shift actually knows — is where a meaningful amount of SIMOPS risk sits, and it's a communication and process problem before it's a data one.
What does a SIMOPS-aware shift handover actually need to cover?
A handover on a site running simultaneous operations has to communicate more than the status of each crew's own permit. It needs to cover what's changed in neighbouring or interacting work since the previous briefing: new permits raised, isolations added or removed, work suspended or extended, and any change to shared access routes, laydown areas, or emergency response arrangements that affect more than one crew. A handover that only confirms "your permit is still valid" has told the incoming shift almost nothing useful about the operations around them.
The area authority's role doesn't pause at shift change
On most permit systems, the area authority (or equivalent duty holder for that part of the plant) is accountable for judging whether concurrent activities in their area remain compatible. That accountability doesn't get suspended between shifts — it transfers, formally, along with everything the outgoing area authority knew that hasn't yet made it into a permit amendment. HSE's guidance on permit-to-work systems, HSG250, identifies shift handover as one of the points where permit control is most likely to be lost, precisely because responsibility is moving between people at the same moment as the work itself is continuing. On some assets a dedicated SIMOPS coordinator holds this picture across the whole site rather than area by area; on others the OIM or shift supervisor absorbs the function directly. Either arrangement can work, provided the accountability at handover is explicit rather than assumed.
We've written before about why isolation is usually where SIMOPS control breaks down, and shift handover is one of the clearest examples of that in practice — an isolation put in for one job can quietly become a shared dependency for a second permit raised later in the shift, without the crew relying on it ever being told.
Toolbox talks that reference the job next door
A toolbox talk built around a single crew's own task briefs the wrong scope on a multi-activity site. Where permits interact — hot work near a confined space entry, scaffold erection under a load path, vessel entry sharing an isolation with mechanical work upstream — the toolbox talk needs to name the neighbouring activity explicitly, not just the hazards of the job in hand. That means whoever runs the brief has to know what else is live in the area, which in turn depends on the handover having actually surfaced that information rather than leaving it in a system the crew hasn't opened. A toolbox talk is only as good as what the person running it was told an hour earlier.
Communicating changes as they happen, not at the next scheduled check
Interacting permits don't stay static for a shift. An emergency stop on one job, a gas detection alarm, a dropped-object exclusion zone, or a contractor calling a halt to isolate a fault can all change the risk picture for adjacent work within minutes. The question worth asking of any site's protocol is whether that change reaches the crews on interacting permits directly — by radio, by a physical stand-down, by a supervisor walking the area — or whether it waits to be picked up at the next scheduled round or the following handover. Real-time changes need a real-time route to the people affected by them, and that route has to be understood by everyone on shift, not just by the person who raised the original permit.
Where the software supports the protocol, not the other way round
Cross-permit visibility tooling earns its place here by making the current state of interacting work checkable at the point of handover — what's live, what's suspended, what isolations are shared — rather than by requiring anyone to remember it. That's a genuine improvement over a paper permit board where the outgoing shift's knowledge simply leaves the site with them. But a system showing accurate data doesn't guarantee anyone reads it before the next toolbox talk. Worth asking of any control of work system: can it show a permit's history across a shift change, and does it force an acknowledgement from the incoming area authority before the permit is treated as accepted? That acknowledgement step is where the human protocol and the software actually meet.
The wider discipline of managing contractor crews rotating through the same critical equipment raises a related question about who's competent to receive a handover on a given permit type, which we've covered in more detail in relation to closing the competency gap on critical equipment.
Getting the balance right during a turnaround
Turnarounds concentrate all of this into a shorter window with far more concurrent permits than routine operations, which is exactly why handover discipline tends to slip when it's needed most — more permits, more shift changes, more contractor crews who weren't on site for the previous briefing. A handover checklist built for routine operations often doesn't scale to that volume without deliberate redesign, particularly around how shared isolations and interacting SIMOPS activities get carried from one shift's area authority to the next.
If you're reviewing how your control of work process handles shift change during a shutdown, it's worth walking through a live turnaround scenario with your operations team and testing where the handover actually depends on someone's memory rather than a recorded, acknowledged transfer of information.
Source: Beyond the Single Permit and related SIMOPS content cluster