The Handover Pack That Gets Used
Most as-built documentation is written to satisfy a contract clause and read by nobody. A small amount of it, written differently, is what a technician opens at three in the morning.
Two documents get produced at the end of every industrial project. One is the contractual handover pack: a folder of PDFs, a set of drawings, the vendor manuals, a test record. The other is a page of notes somebody made for themselves, with the IP addresses on it, and it lives in a drawer in the control room.
The second one gets used. That is worth thinking about rather than laughing at, because it tells you what a handover document is actually for.
The contractual pack is fine at what it is for. It proves scope was delivered and provides the evidence an auditor or a lawyer might want. It is not designed to answer a question quickly under pressure, and it is not organised the way a person in trouble thinks. Someone whose line has stopped does not want a document structure mirroring the work breakdown structure. They want to know what this device is, what it talks to, what its address is, what a normal reading looks like, and who to call.
So write the small thing deliberately, and treat it as a deliverable rather than as somebody's private notes. What it should contain is fairly consistent across projects. A one-page system overview drawn the way the system actually behaves, not the way it was procured — boxes, arrows, protocols, directions of flow. An address and identity table: every device, its network address, its name in the SCADA, its physical location, its firmware version at handover. The credentials arrangement, meaning where credentials are held and who can get them, not the credentials themselves. What normal looks like: typical values, typical rates, what the indicator lights mean. The three or four failure modes the project team already knows about, with their symptoms — every project has these, and they live in people's heads until those people move on. And the escalation path, with names and hours.
Two properties matter more than completeness. It has to be findable — in the control room, on the network where support can reach it, and physically inside the panel where practical. A laminated sheet inside a cabinet door has saved more downtime than any document management system. And it has to be current, which is the hard part.
Currency is where documentation actually fails, and the cause is structural rather than lazy. Documents are updated when someone remembers, and nobody remembers. The only reliable fix is to attach the update to something that already has to happen: the change request cannot close until the diagram is updated, the firmware update procedure includes a step to amend the version table, the annual shutdown includes a documentation review with a named owner. Where the information can be generated from the system rather than maintained by hand — an asset list exported from the network monitoring, a tag list pulled from the controller — generate it, because generated information is the only kind that stays true without discipline.
One test tells you whether the handover worked. Six months after go-live, hand a technician who did not build the system a plausible fault and watch what they open first. If it is the folder, the pack was written well. If it is the phone, it was not — and the person they are calling is a single point of failure the project created and left behind.