Digital Twin

Definition

A Digital Twin is a synchronised digital model of a physical asset, system, or process — fed by real-time data from sensors, control systems, and operational logs — used to monitor condition, simulate behaviour, and optimise performance over the lifecycle. It is the operational successor to the design-stage Building Information Model (BIM) and the production-stage as-built. The full vocabulary is catalogued in the PMMilestone PM Glossary.

History

The term was introduced by Dr. Michael Grieves at the University of Michigan in 2002 in the context of product lifecycle management. NASA formalised the concept in 2010 for spacecraft simulation, where physical access to the asset was impossible. Construction and infrastructure adoption accelerated after 2017 with the convergence of BIM, IoT sensor cost reductions, and cloud-scale computation. The U.K. National Digital Twin programme, launched in 2018, set the policy benchmark for connected national infrastructure twins.

Principles

• Three layers: physical asset, digital model, and a bidirectional data link.
• Continuous synchronisation rather than a one-time as-built snapshot.
• Federated data — geometric, semantic, operational, and contextual — bound together by a common identifier scheme.
• Simulation capability that adds predictive value beyond visualisation.
• Defined use-cases — without them a twin is a very expensive 3D viewer.

Real-World Construction Example

On a 320 MW combined-cycle power plant, the EPC contractor delivered a digital twin at handover linked to 18,000 instrument tags. During the first year of operation, the operator ran what-if simulations on the twin before adjusting load-following profiles in the live DCS. One simulation predicted an HRSG tube-life reduction of 4,200 operating hours under a proposed cycling regime — the operator changed the strategy and avoided an estimated USD 6.2 million unplanned outage. The twin paid for itself in eight months.

IT / Agile Example

Digital twins are not limited to physical plant. A global e-commerce platform built a "system twin" of its checkout flow — a real-time graph of services, queues, and dependencies fed by OpenTelemetry. When the platform team proposed migrating the payment service to a new region, they replayed Black Friday traffic against the twin first. The simulation surfaced two cascading-failure modes that would have caused a 14-minute outage on the live system. Both were fixed before cutover.

Project Controls Perspective

From a controls standpoint, the digital twin is both a deliverable and an instrument. As a deliverable, it must be scoped, costed, scheduled, and quality-assured like any other engineering package. As an instrument, it should feed back into earned value, productivity reporting, and risk re-baselining throughout execution. Validate twin handover deliverables with the Schedule Health Checker and benchmark cost against industry data in the Failure Database.

Practical Lessons Learned

• Twins delivered without a funded operations-and-maintenance plan rot within 18 months. Sensor drift, tag changes, and software updates need ongoing investment.
• The biggest cost driver is data integration, not the 3D model. Plan for it in the budget.
• Operators rarely use twins they were not consulted on. Bring operations into the design process from day one.
• Open standards (IFC, COBie, ISO 19650, Asset Administration Shell) protect the owner from vendor lock-in.

Common Mistakes

• Equating BIM with a digital twin — BIM is static design data, the twin is operational and dynamic.
• Underestimating the cost of data integration and governance over the asset life.
• Building over-engineered twins that no operator uses because the use-cases were never defined.
• Treating the twin as an IT project rather than an asset-management capability.

Expert Tips

• Start with one or two high-value use-cases — predictive maintenance, energy optimisation, or operator training — and earn the right to expand.
• Govern the tag-naming convention obsessively. A twin with inconsistent tags becomes unusable within two years.
• Insist on contractual handover criteria for the twin — data completeness, model accuracy, and acceptance tests. "Best endeavours" guarantees nothing.

Key Takeaways

• A digital twin is a living model — continuous synchronisation is the defining feature.
• Value comes from use-cases, not from the model itself.
• Governance, standards, and funded operations are mandatory, not optional.
• The twin is an asset on the books — treat it as one.

Further Reading

Recommended texts and case studies are in PMMilestone Books & Publications; structured curricula are available in the Digital Delivery learning tracks.