There is a particular kind of quiet that happens on the first morning after handover. The site sheds are gone, the last of the temporary fencing is on a truck, and someone from the operations team sits down and opens the folder they were given.
Sometimes it is a good folder. More often it is 4,000 PDFs in a structure that made sense to whoever uploaded them, a spreadsheet of assets with three different naming conventions in it, and a warranty schedule that refers to model numbers nobody can find on the equipment.
Nothing here was done badly. Everyone did their job. The commissioning engineer commissioned, the subcontractor submitted, the document controller filed. And still, the person who now has to run the building for the next thirty years is starting with a reconstruction project.
Handover is not the last activity on the programme
We tend to draw handover as a milestone. One diamond, near the right hand edge of the bar chart, usually with a few weeks of "O&M compilation" leading into it.
That drawing is the problem. It says the information gets assembled at the end, out of whatever happens to exist by then. And what happens to exist by then is decided by hundreds of small choices made months earlier, by people who had no idea anyone downstream would care.
The pump gets installed. Someone photographs the nameplate on their phone, because they needed it for a different reason. Twelve months later, that photo is the only record of the serial number, and it is on a phone belonging to someone who has moved to another company.
Nobody made a mistake. There was simply no place for that number to live at the moment it existed.
The gap is a specification gap first
The most reliable predictor of a good handover is not the software used to compile it. It is whether the information was named as a deliverable in the first place, in enough detail to be checked.
If the contract says "provide O&M manuals", you will get manuals. If it says which asset attributes are required, in what format, validated at agreed points during construction rather than at the end, you get something an operations team can actually load into a maintenance system.
This is the whole logic behind the asset information requirements in ISO 19650, and it is the part that most often gets skipped, because writing those requirements takes real work at the front of a project when everyone is busy with other things.
The pattern repeats across the industry. A requirement asked for at commissioning is a request for reconstruction. The same requirement asked for at procurement is a line in someone's scope.
What the 2026 revision is aiming at
The draft revision of ISO 19650 currently working its way through consultation makes this explicit in a way the original did not. The proposals fold the delivery-phase and operational-phase processes into a single information management process, rather than two workflows meeting at a wall.
It is a small change on paper. In practice it says something quite direct: the handover is not a transfer between two worlds, it is a continuation. The information does not change hands so much as change custodian.
We think that is right, and we would go one step further. The reason the wall exists is rarely philosophical. It exists because during construction, the information lives in the tools that suit construction, and none of those tools were built to hand anything over.
Four things that make handover boring
Boring is the goal. A boring handover is one where nothing is discovered in the last month.
Name the asset attributes at tender, not at practical completion. Even a short list beats a long one written too late. Asset ID, location, manufacturer, model, serial, install date, warranty period, maintenance interval. Eight fields, agreed early, is worth more than forty fields requested in the final fortnight.
Attach the record to the thing, not to the phase. If a test certificate lives against the piece of plant rather than in a folder named after the month it was issued, it survives every reorganisation of the folder structure that will inevitably follow.
Validate at gates, not at the end. Check a sample of asset data at 30 percent complete, when correcting it costs a conversation. The same correction after demobilisation costs a procurement exercise.
Give the operations team a seat while the decisions are still cheap. The people who will live with the outcome are usually the last to be consulted, and they are the only ones who know which of the forty fields they will genuinely use.
The part that is hard to say out loud
Handover is the one part of a project where the people doing the work are not the people who benefit from doing it well. The contractor who compiles an excellent asset register has spent money to make someone else's job easier, after their own job has finished.
That is not a moral failing, it is an incentive problem, and it will not be solved by asking people to care more. It gets solved by making the information a deliverable that is priced, scheduled, and checked like any other, and by making it cheap enough to produce as you go that nobody has to choose between doing the work and recording it.
ReqTwin exists partly because of that second half. If a requirement, the inspection that proves it, the part it applies to, and the milestone it sits under all live in the same place, the handover pack is mostly a filtered view of work that already happened, rather than a project of its own.
Not a perfect answer. But a better starting position than a folder.