Project Handover: From Installed to Ready for Operations

101: installed, accepted and ready are different questions

A major project can look almost finished while the receiving team is still waiting for usable drawings, resolved defects or evidence of what has been checked. Those gaps matter even when the construction dashboard shows little work remaining. Handover is where the project must make its claims about completion usable to someone else.

Omar’s model-review example exposes a common ambiguity: one person uses done to mean installed, while another is waiting for the final activities. Agree the states you will report and what evidence changes each state. Use the project’s actual acceptance terms and keep the distinction visible in everyday reporting.

Scroll sideways or use the arrow keys to see all columns.

These are useful reporting distinctions, not interchangeable signoffs. A construction handover, permission to start a system, contractual acceptance and project closeout can each have their own requirements and decision owners. Map those decisions before putting a single handover milestone in the schedule.

Start with the people who will receive the work

Name the receiving owner for each system, facility or package while its requirements are being developed. Operations, maintenance, the client and a follow-on contractor may need different things from the same delivery. Bring them into the discussion early enough to change what is requested, produced and demonstrated.

Choose a representative package and ask its receiver to describe the first job they will do with it. What will they need to locate, understand, inspect or maintain? Turn the answer into clear acceptance and information requirements, with an agreed format and a responsible supplier. This makes handover specific enough to plan.

• Identify what transfers, who supplies it, who reviews it and who can accept it.
• Agree the boundary of each package and its interfaces with work that stays under construction.
• Name the records and demonstrations needed, alongside the physical deliverables.
• Give each requirement a due date tied to the receiving team’s actual need.

Put transition work into the delivery plan

Plan backward from the receiving activity. A package cannot arrive ready if its final walkdown, evidence review and defect correction only begin on the promised handover date. Put those activities and their dependencies into the schedule, with the people and time needed to perform them.

HS2’s enabling-works case also makes an important distinction for megaprojects: the receiver may be the next contractor. A usable transfer can mean giving that team a clearly defined work area and accepted information before the eventual asset operator takes over. Make each transfer visible instead of hiding the whole chain inside one completion milestone.

Review handover constraints in the same planning conversations as equipment and construction constraints. Identify a missing approval, specialist or record while there is still time to obtain it. The transition owner needs authority to bring the producing and receiving disciplines together.

Build the evidence as the work happens

Grant’s turnaround example starts with an identifiable item and its checked steps. Apply that traceability to your handover packages: someone should be able to move from a system or asset identifier to the work performed, the inspection or test record, the relevant revision and the acceptance status.

Give field records a destination from the start. Collect and review them while the people who did the work can answer questions. When a record is rejected, return it to a named owner with the reason and required correction. A folder full of unreviewed attachments is a review queue, not an accepted package.

Keep the controlled records connected when information moves between a contractor’s system, the project repository and the operational system. Preserve identifiers, revision history and acceptance status. Test a sample transfer and check that the receiver can follow the evidence without access to the original author’s private files.

Make the progress system care about finishing

Travis describes the uncomfortable plateau where a system earns most of its progress early and then waits for final signoff. Review whether your rules of credit make finishing work visible and worth attention. The weights should reflect the actual work and the agreed measurement basis.

Show installed, checked, accepted and outstanding status separately where those distinctions affect readiness. Use quantities and package-level evidence to explain the remaining work. A total percentage should lead to the packages preventing handover, not conceal them.

Do not treat the controls team’s progress calculation as authority to accept the asset. Keep measurement, technical verification and formal acceptance connected, with a clear owner for each. The schedule forecast should respond when a supposedly small remaining item blocks a whole system.

Hand over information people can use and maintain

Leanne’s point is practical: the project’s information keeps working after the project organisation shrinks. Agree who will maintain the operational drawings, procedures and asset records, including how field corrections are reviewed and incorporated. Make that responsibility part of the transition plan.

Ask the receiving team to find an asset, identify its current drawing, locate the relevant operating information and explain how they would request a correction. Run the exercise with the permissions and systems they will actually have. Record where they cannot find, open or interpret what has been delivered.

Reconcile the handover package against the agreed information requirements. Check identifiers, required fields, revisions, file accessibility and the relationship between records. Preserve a controlled record of what was accepted while giving operations a defined route for subsequent changes. The Data and Document Control guides cover the foundations for that continuity.

Give every remaining item a route to closure

A long punch list becomes more useful when it shows the receiving consequence of each item. Identify what prevents the proposed next activity, what requires a specific decision and what has an agreed completion route. Use the project’s approved categories and acceptance authorities.

Bring the producing and receiving teams together to confirm the list against the field and the records. Remove duplicates, resolve vague descriptions and identify the evidence that will close each item. A promised date without a responsible person and a closure check will keep returning to the meeting.

Scroll sideways or use the arrow keys to see all columns.

If work is transferred with agreed outstanding items, keep those items visible after the transfer. Any exception needs an explicit decision by the authorised people and a funded route to resolution. A handover meeting should not quietly turn unfinished obligations into someone else’s problem.

Check the receiving team as carefully as the package

The receiver needs more than a notification that the package is ready. Confirm that the right people will be available, have access to the accepted information and know where to obtain support. Identify any training, staffing or supplier assistance that must be in place for the intended activity.

Use a realistic work scenario to check the transfer. For example, ask an incoming maintenance planner to locate an asset record, find its current instructions, identify the responsible support contact and raise a document correction. Capture the obstacles and resolve them before the project experts disperse.

Preserve continuity where it matters. Arrange an overlap between outgoing specialists and incoming owners, identify deputies, and keep a clear route for questions discovered after transfer. Judge the handover by whether the receiver can do the agreed work, not by attendance at a presentation.

Make the readiness decision explicit

Bring a decision pack organised around the proposed transfer. Show its boundary, acceptance evidence, unresolved items, receiving capability and the consequences of proceeding or waiting. The accountable decision-maker should be able to see what is being accepted and which responsibilities change.

• What exactly are we proposing to transfer, and to whom?
• Which evidence supports the required state of completion and acceptance?
• What remains unresolved, and how does it affect the next activity?
• Can the receiving team use the information and support arrangements now?
• Who has authority to decide, and where will the decision and its conditions be recorded?

Record the result and communicate it to the people who will act on it. If the package is not ready, identify the work and evidence needed for reconsideration. If the approved arrangement includes conditions, assign their owners and make the restrictions visible in the systems and instructions used by the affected teams.

Keep staged handover and final closeout connected

Large projects often transfer packages at different times. Keep a map of what has transferred, who now controls it and where interfaces remain open. A later design change or correction can affect an already accepted package, so route it through the receiving owner as well as the delivery team.

Agree the support period and the destination of remaining actions before demobilisation. Name who handles defects, missing information, outstanding commercial matters and lessons that affect the next package. Keep the resources needed to complete those commitments.

A useful transition review looks for repeat problems: the same missing record, unclear boundary or rejected submission across several packages. Fix the producing process before the next handover. Close the project only when its remaining responsibilities have been completed or explicitly transferred through the agreed arrangements.

A handover-readiness check for the next package

Use this check with the people producing, verifying and receiving the work. For each item, point to the evidence or record the action needed. Keep the questions alongside the project’s detailed acceptance requirements.

• The package boundary, intended use and receiving owner are clear.
• The project’s completion, testing and acceptance requirements are identified, with the right authorities involved.
• The field status and the reported status have been reconciled.
• Required inspection, test and approval records can be traced to the relevant items.
• Remaining work has an owner, receiving consequence, due date and closure evidence.
• The receiving team can find and use the accepted drawings, procedures and asset information.
• Information ownership and the route for future corrections are agreed.
• The necessary people, training, access and support arrangements are in place for the intended activity.
• The decision and any conditions are recorded and communicated to the affected teams.
• Post-transfer support and remaining responsibilities have named owners and resources.

Start with one approaching handover and follow an item all the way through: from the field, to its evidence, to the receiving person. The gaps in that journey tell you where the wider handover process needs attention.