Picture the 06:00 shift change. The night operator has had a trip on a feed pump, a permit job that overran, and an inhibit put in at 03:00 so a transmitter could be swapped. The day operator has been on site for ten minutes. Whatever gets passed across in the next quarter of an hour decides how the day starts.
If you’re looking at shift handover software for a power station, an offshore platform, a terminal or a chemical plant, that quarter of an hour is what you’re buying for. I’ve worked with control room teams on handover for a long time, and these are the questions I’d want answered before choosing any system. Ours included.
I’ve often seen handover treated as an afterthought. Just a quick hello and goodbye as one team leaves and the other arrives, or a chat in the kitchen, and a few Post-it notes on the desk. Not enough time or formality is given to it, because the organisation doesn’t recognise how important it is.
First, though, the part a feature list won’t tell you. Software is only part of the answer. If the handover procedure is vague, a new system will record a vague handover very neatly. Sort the procedure out first, then pick software that makes it easier to follow on a busy night.
What the investigations keep finding
HSE describes handover as the accurate, reliable communication of task-relevant information across shift changes. It also says many accidents have followed a failure of communication at handover, most of them involving planned maintenance, and that the Cullen Report found failure of information transmission at shift handover was one of the factors in Piper Alpha. (HSE: Shift handover)
At Texas City in 2005, the US Chemical Safety Board found the refinery had no policy for shift communication or turnover. An instruction given by phone never made it into the logbook. (CSB investigation report)
At Buncefield the same year, supervisors were confused about which pipeline was filling which tank, and the investigation put that partly down to deficiencies in the shift handover procedures. It also lists poor communication at shift handover among the factors Buncefield shared with Longford. (Buncefield: Why did it happen?)
The fuel storage report that followed Buncefield is worth reading if you run any 24/7 site. It found some sites relied on event-type or unstructured logbooks that didn’t say what information had to be handed over. The minimum it sets is a handover procedure with simple, unambiguous steps, structured logbooks or displays that are easy to read, information passed on verbally and in writing, and two-way communication. (Safety and environmental standards for fuel storage sites, paras 119 to 123)
The Energy Institute’s briefing note on communications names Piper Alpha, Grangemouth, Texas City and Buncefield. It also describes HSE research on offshore handover where some companies hadn’t defined responsibilities or information needs, gave little training or written guidance, and hardly checked handovers at all. (EI Human factors briefing note no. 10)
None of that gets fixed by buying software. A good system just makes the right habits easier and the shortcuts harder.
Write the procedure down first
Before any demo, get these on paper.
Who hands over to whom. The control room operator to the next control room operator, obviously, but also field operators, the shift manager, maintenance, and day staff handing back to shifts at 17:00.
What each position must pass on. The fuel storage guidance has a useful list to start from: product movements, control systems bypassed, equipment out of service, maintenance and permits, isolations, trips defeated, critical alarms and what was done about them, incidents, modifications, and who is on site.
Which handovers carry more risk. HSE and the Energy Institute point to work running over the shift change, overridden safety systems, unusual running such as a start-up, unscheduled maintenance, and someone coming back after a long spell away. (HSG48, HSG256)
How it’s done. HSE’s answer is face-to-face, two-way, spoken and written, built around what the incoming person needs, with enough time to do it properly.
And how the incoming shift accepts. Who signs, and what happens if they’re not happy with what they’ve been given.
That’s your specification. The software has to fit it.
If you want somewhere to start, our free shift handover checklist covers preparation, the handover itself, acceptance and the higher-risk cases. Two pages, based on HSE guidance, no sign-up.
What to look for
Before any features, one thing I’d say: the decision has to be led by the operations team. In these plants nobody wants to be told to use a new system. They need to be part of the decision-making process.
The handover has a structure. Sections that match your plant, such as plant status, safety and permits, equipment out of service and significant events, for each area. A single free-text box is how you end up with “all OK, see logbook”.
It builds up during the shift. The worst handovers are written at 05:40 from memory. Check that an entry made at 23:15 can go straight into the handover, either automatically or because the operator chooses to share it.
Open items carry forward. If the cooling water pump is still waiting for a fitter, it should still be on the screen tomorrow night, and the night after, until someone closes it. Ask to see that happen, not just hear about it.
Sign-off and acceptance are options you control. Can a shift be locked and signed off with names recorded? Can you make the incoming team accept the handover before their shift starts? Some sites want both, some neither.
Overrides and isolations are tracked. Inhibits, overrides, isolations, locked valves and defeated trips should be kept in registers the incoming shift can check at handover, with approval where your procedure needs it and a record of who did what.
Plant data turns up where it’s useful. If you run a historian, ask whether process values can go into entries, whether the system can write back, and whether it can create entries from events. Then ask which of those interfaces are standard and which would be a project. You want a straight answer to that.
Field and control room share one record. A leak spotted on the 02:00 round should reach the handover without someone copying it out of a notebook.
There’s a full audit trail. Every entry and every change, with who and when. You’ll want it after an incident, and auditors will ask for it anyway.
You can change it yourselves. Logbooks, categories, forms and workflows change as the plant changes. Trained superusers on site should be able to make those changes without programming or a support ticket.
It runs where your security team needs it to. Plenty of operators want operational records inside their own boundary. Ask whether it can run on your own servers or in your own private Azure or AWS environment, and what that means for upgrades.
It works across sites. One standard, with each site keeping its own equipment, terms and access.
Questions to put to suppliers
- Show me a handover being built during a shift, not just the finished report.
- How do open items carry forward, and who can close them?
- Can we require incoming acceptance before the shift starts? What happens if someone refuses?
- How does the incoming shift check what’s overridden or isolated?
- Which interfaces are standard (historian, OPC, API, single sign-on) and which would be project work?
- How does field data get into the control room logbook and the handover?
- After go-live, who sets up a new logbook or form: us or you?
- Where is our data held, and can we host it ourselves?
- What does the audit trail record, and can we report on it?
Warning signs
A demo that only ever shows the polished final report. Every new form needing the supplier. “It integrates with everything”, with nobody able to say what’s standard. A handover that is one text field. No mention of acceptance, sign-off or carry-forward. Vague answers about where the data lives. No reference sites that look anything like yours.
Take this to your supplier demos
Print it, take it to each demo, and tick what they actually showed you.
| What to look for | Ask them to show you | A good answer | Warning sign | Shown? |
|---|---|---|---|---|
| Handover structure | A handover for one area of a plant like yours | Sections for plant status, permits, equipment out of service and events | One free-text box | |
| Builds during the shift | A 23:15 entry going into the handover | It’s added automatically or shared by the operator | Only the finished report | |
| Open items carry forward | An item still open three shifts later | It stays until someone closes it | “It can do that” without showing it | |
| Sign-off and acceptance | A locked, signed shift with the incoming team accepting it | Names recorded, and you choose the rules | No mention of acceptance | |
| Plant data | A historian value inside an entry | They say clearly what’s standard and what’s a project | “It integrates with everything” | |
| Field and control room | A round finding reaching the handover | One record, with no copying out | Re-typed from a notebook | |
| Audit trail | Who changed an entry, and when | Every change recorded and reportable | Gaps or edits that leave no trace | |
| You can change it | A superuser adding a new form | Done on site, with no code | Every change needs the supplier | |
| Hosting | Where the data would live | Your servers, or your own Azure or AWS | Vague answers | |
| Multi-site | Two sites under one standard | Shared standard, with local equipment and access | A separate system per site |
Bring it to your Opralog demo and we’ll go through every row.
Rolling it out
Change management is a really important consideration. Many of the plants where we implement Opralog have been running for years. They have processes, a way of doing things and a culture, sometimes good, sometimes bad. But an implementation is always much more likely to succeed with early engagement from the operations team. Get users onside. Very few people like change, so it has to be carefully managed.
The projects that struggle are the ones that are heavily IT-driven, where the system can become a black box to operators. It’s essential they understand the capabilities of the tool and why it’s set up the way it is. HSE says the same: involve end users when you change how handover works.
The other thing is to get early benefits. Prove the value as soon as possible. Show users it will make their life easier, then expand and get more complex later. It will be easier this way.
The software can show you whether handovers are happening. Only people can tell you whether they’re any good.
So agree the procedure with the people who actually hand over, set it up in the system, and pilot it on one unit for several weeks. Change what doesn’t work. Train a few superusers so the site can look after it. After go-live, keep checking the quality of handovers, as the Energy Institute recommends. The software can show you whether handovers are happening. Only people can tell you whether they’re any good.
Common questions
What is shift handover software? It records what happened on a shift, what’s still open and what the incoming team needs to know. Usually that means logbooks, a structured handover report, sign-off and an audit trail.
Can’t we just use a spreadsheet? You can. It’s hard to enforce a structure, carry open items forward, control changes or show who accepted what, though. The fuel storage guidance after Buncefield warns specifically about unstructured logbooks.
Does it replace the face-to-face handover? No. HSE says handover should be face-to-face and two-way, using both spoken and written communication. The software handles the written part, and gives the conversation something solid to work from.
How long does it take to put in? That depends on how many areas and interfaces you have. Start with a pilot on one unit for several weeks, change what doesn’t work, then extend it to the rest of the site.
Where we come in
At Infotechnics we make Opralog, operations logbook and shift handover software used in power, oil and gas and other 24/7 process industries. The sites that get the most from it are the ones that sorted their handover procedure out first. Most of our customers are surprised that pretty quickly they’re able to make significant performance and efficiency improvements. It becomes much easier, and earlier, to spot trends and problems, and to get that bird’s-eye view of operations.
There’s more on how digital handover works on our shift handover page, and the checklist is free.