One engineer holds each plant in their head: HR for SCADA systems companies

Shortly after midnight, the historian at a municipal water works stops logging and the reservoir trends freeze on the control room screens. The shift operator rings the number taped beside the SCADA workstation. It belongs to the engineer who built the system six years ago. He is at a family wedding in another state, his phone on silent. By the time anyone else from the firm is reached, the operator has run the night on manual level readings, and the utility's manager has written a sharp email.

Every SCADA company has plants like this. The SCADA systems companies page names it plainly: one engineer holds each plant in their head.

Nobody chooses it. The engineer who configured the screens, built the tag database and sat through the site acceptance test becomes the customer's contact. The customer saves that number. Small changes, such as a new alarm or an extra report, go to the same person because it is quicker. Over the years the system drifts from its as-built drawings, and only that engineer knows how far. The firm sees a happy customer. It does not see that the support contract rests on one mobile phone.

• The tag database as it really is. Including tags added on site and never merged back into the master list.
• The communications map. Which RTUs talk over radio, which over a leased line, and which drop out in monsoon storms.
• The alarm logic. Why some alarms are suppressed at night, and who asked for it.
• The servers. Where the backups sit, who holds the credentials, how the redundant server pair fails over and which patch broke the historian last time.
• The people. Which shift operator calls about real faults and which one calls about a forgotten login.
• The process. How the plant behaves at low reservoir level, during a pump changeover, with a falling chlorine residual or after a power dip.

1. 1

   List live systems against names

   For each customer system, write down the engineer the customer actually calls. That is the primary, whatever the contract says.

2. 2

   Name a backup

   A second engineer, ideally one who knows a similar plant or the same SCADA platform.

3. 3

   Put the backup on the next visit

   A patch window, an alarm change or an annual check. The backup drives and the primary watches.

4. 4

   Give the customer both names

   On the control room card and in the support contract, so the operator knows who else to ring.

5. 5

   Review pairings each quarter

   Check that each backup has logged into the system recently. A backup who never logs in is a name, not cover.

The SCADA role design notes set out primary and backup duties, so neither role is left vague.

System summary: customer, sites, platform, server layout, RTUs and PLCs connected.
Tag list: the current master, with site additions merged and dated.
Alarm philosophy: priorities, suppressions and who approved each one.
Communications map: links, media, known weak spots and what to check first.
Servers and backups: locations, schedule, custody of credentials and a tested restore procedure.
Process notes: how the plant behaves in normal, low-level and upset conditions.
Known quirks: recurring faults, their causes and the fix.
Change log: every change after go-live, with date, requester and engineer.
Owner: primary engineer. Reviewer: backup engineer. Updated after every site visit.

As-built drawings, tag lists and operator guides often wait until after go-live, when the site team has moved on. Make the file a project stage that a named person completes before the payment milestone. The SCADA handover documentation guidance treats it as deliverable work rather than an afterthought.

After-hours alarm calls go to whoever the customer knows, which means the same few engineers. Spread them across a weekly roster that shows the on-call name, set a rule for rest after a night call-out, and recognise on-call weeks in pay or time off. Pairing makes this possible, because the engineer on call has at least seen the plant. The on-call and leave rules for SCADA teams include rest rules for commissioning stretches too.

Software engineers new to water, power or process plants often learn the process by making mistakes on a live system. A short learning plan prevents much of that. It covers how a pumping station runs, what a feeder trip means and why a dosing pump interlocks with flow. Pair each new engineer with a senior, and let them shadow a commissioning before they lead one. The learning plans for SCADA engineers lay out such a plan.

Write down every live system and the name the customer would ring tonight. Count how many systems sit on each name. Start with the engineer carrying the most systems and name backups for those first. Start a plant knowledge file for the oldest of them this month. Our sector hub covers the related risk of project knowledge leaving with one engineer.