Due diligence is often treated as something that happens before delivery begins. The deal team investigates, advisers report their findings, risks are understood and the programme moves forward on the basis of that evidence.
But on acquisition and establishment programmes, due diligence does not disappear once the transaction progresses. Its conclusions become assumptions inside the delivery plan, which means parts of due diligence become programme dependencies whether they are labelled that way or not.
The plan inherits the evidence behind the deal
On a cross-border acquisition and operational-establishment programme I led, the acquired site was intended to support critical infrastructure and a new operational hub. The programme connected property, construction, data-centre infrastructure, legal and regulatory work, workplace, recruitment and operational transition.
Delivery therefore depended on more than the transaction completing. It depended on the acquired asset being capable of supporting the plan built around it.
When a structural issue later emerged in an annex to the property, several assumptions became invalid at the same time. The annex did not meet the required seismic standard and needed to be demolished and rebuilt, affecting available space, infrastructure sequencing, dependencies, cost exposure and confidence in some of the evidence the programme had relied on.
That was not simply a new construction issue. It was a reminder that the delivery model had inherited assumptions from work completed earlier in the transaction.
A finding can become a critical-path input
This is why I think due-diligence outputs should be treated differently depending on how much downstream delivery depends on them. Some findings are useful background information; others are effectively inputs to the critical path.
If a programme assumes that a building can host infrastructure, that a supplier can transfer a capability, that a licence can be used in a particular way or that a system can be integrated without material remediation, those assumptions deserve explicit ownership and evidence.
The important question is not simply, “Was due diligence completed?” It is, “Which conclusions from due diligence does the delivery plan now depend on?”
That changes the handover between transaction and delivery teams. Instead of treating the due-diligence report as an archive, the programme can identify the conclusions that still have operational consequences.
Verification should follow dependency, not organisational boundaries
One problem with complex acquisitions is that different teams own different parts of the evidence. Legal advisers may understand the contractual position, technical specialists may understand the asset, Finance may understand the exposure, while the programme team is often the place where those conclusions become one integrated delivery plan.
That means programme governance has to identify which external or specialist conclusions are carrying material delivery weight. Where the consequence of being wrong is high, stronger acceptance or verification controls are justified.
After the structural issue in Colombia emerged, I strengthened evidence and acceptance controls around third-party deliverables so that the programme was less exposed to unverified assumptions later. The point was not to re-perform every specialist review centrally, but to make sure the programme knew which conclusions it could not afford to leave untested.
Accountability does not remove the delivery problem
In the structural case, the seller ultimately carried the cost of demolition and reconstruction. That was commercially important, but it did not solve the programme by itself.
The delivery plan still had to change. Critical infrastructure was moved into the compliant main building, the annex scope was reduced and dependencies were re-baselined around the new sequence.
This is an important distinction: commercial accountability determines who carries an exposure; programme leadership still has to determine how the outcome will be protected.
A contract can allocate liability without removing the operational consequences of a problem that has already appeared on the critical path.
Due diligence should feed the integration plan
The same principle applies beyond property transactions. In platform or business acquisitions, assumptions about systems, suppliers, operational processes, data, compliance and support arrangements can all become integration dependencies.
If those assumptions remain buried inside reports, the programme may not discover their importance until a workstream reaches them. A stronger approach is to convert the material conclusions into explicit readiness conditions, dependencies or risks in the integration plan.
That does not mean importing every due-diligence finding into the RAID log. It means identifying the findings that the delivery model cannot tolerate being wrong about and keeping those visible for as long as the programme depends on them.
The transaction and the programme are connected by assumptions
Due diligence is not simply an upstream activity that hands over to delivery. It creates part of the evidence on which delivery is based.
When that evidence supports a critical assumption, it should remain visible for as long as the programme depends on it. Sometimes the most expensive delivery problem is not a new risk at all; it is an old assumption that nobody realised was still holding up the plan.