Handover that leaves operations able to run the plant

Handover is normally treated as a documentation transfer and a signature. The substantive question is whether the people who will run and maintain the system for the next fifteen years are able to do so, and that is rarely what is tested.

What operations actually needs

• Documentation that matches what was built, not what was designed.
• Access: accounts, permissions, and the ability to make changes without calling the integrator.
• The engineering tools, licences and the knowledge to use them.
• Source configuration, not just the running system: logic source, graphics source, database definitions.
• A tested backup, and a restore procedure that has been performed.
• Spares, with part numbers, and knowledge of lead times.
• Support arrangements, with what is covered and what is not, in writing.
• Training that happened close enough to startup to be remembered.

The fourth item is where sites are most often caught. A system handed over as compiled configuration, without the source, cannot be modified without the original integrator. This is sometimes deliberate on the vendor's part and more often an oversight, and it is very expensive to correct afterwards.

Training timing

Vendor training is frequently delivered when the trainer is available, which can be months before startup. By the time the plant runs, most of it has been forgotten.

The arrangement that works is training close to startup, with a refresher afterwards once people have had contact with the real system and know what they do not understand.

The second session is the valuable one and is the one usually not purchased.

The support period

A defined period of vendor support after startup — with someone on site or immediately available — is standard and its terms deserve attention.

What is covered: defects only, or also changes and tuning? What response time? Who decides whether an issue is a defect or a change request, since that determines who pays?

The ambiguity around defect versus change is the most common source of dispute in the months after startup, and defining it before signing is considerably easier than arguing it afterwards.

Documentation that matches reality

The single most common handover failure is documentation describing the design rather than the installation. Commissioning always generates changes, and updating drawings is deferred.

The mitigation is to make marked-up drawings a commissioning deliverable in real time — updated as changes are made rather than reconstructed afterwards — and to withhold a portion of payment against final as-built delivery.

Reconstructing as-builts six months later from memory produces documents that are approximately right, which is worse than obviously wrong because they are trusted.

A punch list with an owner

Handover with outstanding items is normal. Handover with an outstanding list that has no owner, no dates and no closure process is how items remain open for years.

Each item needs a category — must fix before startup, fix during the support period, accept — an owner and a date. The categorisation conversation is uncomfortable and it is where the real decisions get made.

Test the handover

The practical test is whether the operations team can perform a set of realistic tasks using only what was handed over: make a configuration change, restore from backup, add an alarm, produce a report, diagnose a communication fault.

Running that exercise while the integrator is still on site, with the client's own staff, reveals gaps while they are still someone else's obligation to fill.

Staffing the transition

Handover assumes an operations and maintenance organisation ready to receive the system, and that organisation frequently does not exist yet at handover — positions unfilled, people not yet trained, roles not defined.

Where that is the case, handover transfers responsibility to nobody in particular, and the vendor's support period is consumed by tasks the site should be doing.

Identifying the receiving roles early, and having those people involved during commissioning rather than arriving afterwards, is the single change that most improves the first year of operation.

The knowledge that only exists in people

Commissioning generates a great deal of understanding that never reaches any document: why a particular tuning was chosen, which measurement is unreliable at low flow, which sequence step is sensitive.

Capturing it requires deliberate effort while the commissioning team is still present — a structured debrief, a list of known quirks, a session where the incoming engineers ask questions.

This is worth scheduling explicitly. It does not happen spontaneously, because everyone involved is busy finishing.

The first-year review

A review a year after handover — what has needed fixing, what was missing from the documentation, what training was inadequate — produces lessons while they are still recoverable and informs the next project.

It is also the natural point to close out the remaining punch list items, or to accept them formally rather than leaving them open indefinitely.

Access and accounts at handover

A recurring handover deficiency is that the site receives the system without full administrative access: accounts held by the integrator, undocumented service accounts, licence portals registered to a contractor's email address.

Six months later, when a change is needed, the site discovers it cannot make it without contacting a company whose contract has ended.

An explicit account and credential handover — every account listed, ownership transferred, contractor accounts disabled — belongs on the handover checklist and is one of the items most often omitted.

Defining what complete means

Handover disputes usually arise because completion was never defined in objective terms.

Defining it as a list of verifiable conditions — these tests passed, these documents delivered in these formats, these accounts transferred, this restore demonstrated — converts a judgement into a checklist.

That definition belongs in the contract, agreed at the start, rather than negotiated at the point when the contractor wants to leave.