Handover: The Last-Mile Problem in Engineering Documentation

A capital project ends twice. It ends operationally — when the asset is commissioned and handed to the operator. And it ends documentarily — when the engineering record set is transferred, accepted, and verified as complete.

In most projects, these two endings are misaligned. Operational handover is planned years in advance. Documentary handover is treated as a consequence of it.

The result is a period of intense, often chaotic activity in the final weeks of a project: drawings being hunted down, revision statuses being corrected, as-built marks being applied under pressure, documentation packages being assembled by people who weren't part of the project when the drawings were produced.

Why handover fails

Handover fails for several reasons that are distinct but compounding.

Scope creep in the record set. Projects produce drawings throughout their lifecycle. Not all of them are handover deliverables. But without a clear, maintained schedule of what is required at handover — and which drawings satisfy those requirements — teams frequently discover gaps in the final weeks that have been accumulating for years.

Status confusion. "As-built" is one of the most contested terms in engineering documentation. Owners define it one way. Contractors interpret it another. EPC contracts specify it, but the specification is often too abstract to be actionable. When handover comes, the drawings often have three different as-built statuses applied by three different parties with three different understandings of what the term means.

No continuous verification. Because handover is treated as a terminal event rather than a process, there is no mechanism for ongoing verification that the record set is in the state it needs to be. Problems discovered at handover have been accumulating since the first drawing was issued.

The cost is asymmetric

The cost of a handover deficiency is not proportional to the size of the deficiency. A single missing as-built drawing can hold up practical completion. A discrepancy between the drawing register and the contractor's document control system can delay acceptance by weeks.

These delays occur at the worst possible time: when the project team is demobilising, when the operator is under pressure to take possession, and when the commercial and contractual consequences of delay are at their highest.

What handover-ready looks like

Handover-ready is a state, not an event. It requires that at any point during a project, you can answer:

• Which drawings are required at handover, and which of those are current?
• Which drawings have been approved as-built, and by whom?
• Which transmittals have been accepted by the client, and which are outstanding?
• What is the completion percentage of the handover package, and what is blocking it?

These are answerable questions. They are not answered in most projects because the system of record is not structured to answer them — the data is distributed across document management systems, email threads, revision tables, and individual hard drives.

The shift that's required

The industry does not need a better checklist for handover. It needs the drawing record to be structured from the beginning as something that will eventually be handed over.

That means the handover schedule is part of the project setup, not the project close-out. It means as-built status is a governed workflow, not a revision suffix. It means transmittal tracking is a live view, not a retrospective log.

The firms that will handle this well in the next decade are not the ones with the most rigorous close-out procedures. They are the ones that have built the end state into the beginning.

Conclusion

The issue is not isolated to one drawing, one review, or one handover event. It reflects how engineering control either holds together across delivery or breaks down when the record is forced to be reconstructed after the fact.

For teams working in handover, the practical requirement is the same: decisions, revisions, and issuance states need to remain attributable, traceable, and defensible all the way through the project record.