projects

Sizewell C: Requirements Management

The project 

Sizewell C is a £20bn new build nuclear power station to be constructed in East Suffolk, UK, consisting of two UK EPR reactors. Each EPR will have an operating design life of 60 years and a rated thermal power of 4,500 Megawatt (MW) and an electrical power output of around 1,630 Megawatt (MW). The project is expected to generate low-carbon electricity for around 6 million homes, an estimated 7% of the UK’s power need.

The challenges  

The Sizewell project, like many large-scale nuclear infrastructure programmes, faced a familiar challenge in its early stages, progressing design development while navigating a complex regulatory consent process. The immediate priority was securing Development Consent Order (DCO) approval and maintaining programme momentum. At that time, formal requirements management wasn’t a primary concern. The focus was firmly on responding to regulatory and stakeholder needs, producing consentable designs, and keeping the programme moving. As the project advanced, two parallel but largely independent workstreams naturally emerged:
• Design development at risk: Design teams continued progressing solutions, often at commercial risk, to meet programme milestones even though the full regulatory picture was still evolving.
• The DCO process workstream: In parallel, the DCO process generated a growing body of commitments, legal obligations, stakeholder agreements, and planning conditions, all captured across numerous documents and supporting submissions.

Over time, these streams matured in isolation. Without a structured requirements framework in place, much of the emerging scope became embedded in narrative documents, legal texts, and supporting reports. The link between ‘what needs to be achieved’ and ‘what is being designed’ was often implicit, undocumented, or dispersed across multiple sources.

The solutions

Reconstructing Requirements Control

It was only after DCO approval that a systematic process was introduced to address this growing complexity. This effort focused on:
• Isolating and extracting individual requirements from across a wide range of documents and commitments.
• Allocating these requirements to specific work packages.
• Developing clear acceptance and assurance criteria.
• Building full traceability between requirements, design solutions, and eventual delivery.

Cultural and Behavioural Barriers
For many, requirements management had historically been document-driven, tracking which documents applied to each work package, rather than identifying discrete, verifiable requirements with clear acceptance and assurance criteria. Responsibility for isolating relevant requirements was often passed to individual design managers, who were left to interpret extensive documentation and extract applicable content for their scope. Given that even subject matter experts found it difficult to isolate specific requirements from these complex documents, this approach placed a significant burden on design managers and their teams.

Without the establishment of a requirements driven approach, each design manager would have been left to spend considerable time independently trying to identify relevant requirements for their respective work packages. As new packages were initiated, this process would have been repeated across multiple managers, creating significant duplication of effort. This approach risked not only wasting time, but introducing inconsistency, with different managers likely to extract varying interpretations of requirements, apply different acceptance criteria, and develop inconsistent verification approaches. Left unchecked, this fragmented process would have increased workload across both client and supply chain teams, while exposing the programme to delivery risks through inconsistent standards, duplicated activity, and misaligned expectations. Typically, such issues only become fully visible much later, often surfacing at design approval for construction or at final handover and acceptance stages, when resolution is significantly more costly and disruptive.

Building Capability and Confidence
Over time, sustained engagement and practical demonstration of value have helped shift the project towards a more mature, requirements-driven approach. This has involved:
• Building understanding across teams of how structured requirements management directly supports assurance, design integrity, procurement efficiency, and delivery confidence.
• Demonstrating how traceability reduces risk, strengthens control, and provides better oversight for regulators and stakeholders.
• Providing tools, frameworks, and training to enable teams to move from document-driven processes to disciplined requirements-based control.

The results

Re-Establishing Control and Confidence
The introduction of structured requirements management has now created a significantly stronger foundation for delivery. By reconstructing traceability and aligning design solutions to clearly defined, verifiable requirements that can be validated, the project has:
• Strengthened assurance confidence that delivery remains compliant with regulatory obligations.
• Reduced ambiguity over scope and design intent.
• Provided a structured platform for managing change, assessing impacts, and supporting downstream delivery with greater certainty.
• Increased confidence that what is ultimately delivered and handed over into operation will meet the programme’s long-term expectations for safety, performance, functionality, and regulatory compliance.

Lessons Learned
• Start requirements management early: Once design and regulatory workstreams have diverged, reconstructing alignment is significantly more complex and resource-intensive.
• Documents are not requirements: Tracking which documents apply is not a substitute for isolating discrete, verifiable requirements that can be validated.
• Hearts and minds matter: Shifting from document-driven to requirements-driven approaches requires sustained engagement and cultural change.
• Traceability strengthens assurance: Clear, validated links between requirements, design, and delivery build confidence across all levels, from design teams to regulators