The reset is structured around four formal workstreams: cost and schedule; supply chain and commercial relationships; organisational capability and culture; and governance.

Those are reasonable priorities. But information management is not visible as the cross-cutting programme capability that connects them. That is a significant omission.

A programme of this scale needs a model closer to:

asset and scope definition → information requirements → design information → schedule activities → cost → contracts → change → risk → assurance evidence → configuration status → operational readiness

These should not be treated as separate management systems. They are different views of the same programme.

If the reset improves each functional silo independently, it risks producing better silos rather than an integrated delivery model.

The NAO states that, in March 2025, HS2’s cost verification backlog averaged 21 months and was close to £5bn. Subsequent audits identified around £500m of disallowable costs, including expenditure outside contract scope or expenditure lacking records.

From an information management perspective, that raises a series of uncomfortable questions:

The fact that a cost backlog of that scale accumulated suggests that the issue was not merely insufficient commercial resource. It suggests a weakness in the information architecture connecting scope, contract, change, evidence and cost.

Adding faster technology to process more data will help, but technology cannot compensate for fragmented identifiers, inconsistent metadata and disconnected information structures.

The NAO says the May 2026 estimates still contain significant uncertainty and that the work towards the fully assured baseline includes validating assumptions, testing underlying data quality with contractors, identifying gaps and inconsistencies, and understanding interdependencies between projects.

This is one of the clearest opportunities for stronger information management thinking. I would argue that Baseline 8.1 – a revised detailed scope, cost and schedule baseline to deliver the programme – cannot be genuinely assured unless the underlying information baseline is also assured.

A cost and schedule baseline should be traceable to:

requirements → functional systems → physical assets → design deliverables → work packages → schedule activities → quantities → cost accounts → contracts → risks → assurance evidence.

Otherwise, the programme can produce an apparently integrated cost and schedule baseline while the underlying technical scope remains disconnected.

This is where the PIM should become the programme integration layer, not simply a repository of BIM models and documents.

The report describes a programme that has difficulty understanding:

To me, this is characteristic of a programme under which the information environment has remained too heavily document-centric and contract-centric. The alternative is an asset-centric model in which the primary entities are things such as:

Documents and models then become evidence and representations associated with those entities.

This is precisely why ontology and relationship management matter. A fixed parent-child taxonomy is not enough for a programme of this complexity. HS2 needs to understand relationships such as: Asset A satisfies Requirement B, interfaces with System C, is delivered by Activity D, funded by Cost Account E, changed by Change F, exposed to Risk G and assured by Evidence H. That is the foundation of a digital thread.

The report lists 10 core capability areas being assessed:

It also says the capability review will consider people, processes and systems. What is striking is that information management and data architecture are not explicitly identified as core capabilities. That concerns me more than almost anything else in the report.

Every one of those 10 capabilities depends upon trustworthy information. Yet no one appears explicitly accountable for the integration of information across them.

The report recognises systems integration as an area where capability may need to be brought forward, because of its importance to managing the programme as a whole. I strongly agree, but systems integration cannot begin when railway systems arrive on site.

The integration problem starts much earlier. Before physical systems can be integrated, the programme must integrate: requirements; interfaces; design configurations; asset information; assurance obligations; test evidence; and change history. Otherwise physical integration becomes an exercise in discovering information inconsistencies during commissioning – probably the most expensive possible time to find them.

The decision to reduce maximum speed, remove automatic train operation and simplify signalling requirements is presented as a means of reducing cost, schedule and risk.

From a configuration-management perspective, that decision creates a major information challenge. The programme needs to demonstrate, through a controlled digital thread:

changed operational requirement → changed system requirement → affected interfaces → affected design configuration → affected contracts → affected test strategy → revised safety and assurance evidence → revised benefits.

The report discusses the financial and schedule implications of the change, but an information management review would ask: can HS2 demonstrate the complete impact of that decision across every affected configuration item and every associated assurance obligation?

That is a very different question from whether a change form has been approved.

The reset workstreams do not directly cover Euston or Phase 2 closedown, according to the report’s description of the reset structure. That creates an obvious information management question: where are the information boundaries and who owns the interfaces?

With separate delivery organisations, changing programme boundaries and retained or disposed assets, the information architecture becomes even more important.

There needs to be explicit governance for:

Organisational separation must not become information fragmentation.

My interpretation of the report is that HS2 does not merely have a cost-control problem, a schedule problem or a commercial problem. It has had an integration problem, and information is the mechanism through which integration must be achieved.

The NAO identifies many of the symptoms: poor data confidence, silo working, weak understanding of costs, difficulty agreeing change, gaps in systems integration, immature scope, weak contract control and uncertainty in the baseline.

The reset will therefore be incomplete, in my view, unless it creates one integrated view of scope, assets, requirements, schedule, cost, contracts, change, risk and assurance.

That does not mean one giant software platform. It means a governed information architecture, common identifiers, clear information requirements, interoperable systems, trusted data and a PIM that acts as the connective tissue of programme delivery.

The key question I would put to the HS2 reset team is: can every significant cost, schedule, change and assurance decision be traced back through trusted information to the requirement, system, asset and configuration it affects?

If the answer is no, then the programme may be re-baselined, but it has not yet been truly reset.

The opinions expressed are the author’s own and do not necessarily reflect the views of his employer.

Keep up to date with DC+: sign up for the midweek newsletter.