A systems approach to integrating design and delivery

The infrastructure sector has a poor record in delivering projects on time and on budget. Andrew McNaughton, director of consultancy Aczel’s infrastructure practice, says that more than 70% of large and mega-projects disappoint their owners because of cost or time overruns or because they did not deliver the intended outcome. This suggests that the traditional approach to delivering complex infrastructure projects may no longer be appropriate.

Infrastructure delivery typically involves different activities being managed separately and individual elements being designed and delivered in isolation from one other. But other sectors that deliver complex projects – such as aerospace, defence, oil and gas, and technology – adopt a ‘systems’ approach, under which assets are conceived, designed, delivered and operated as whole systems.

Our infrastructure is increasingly complex, interconnected and multifaceted. If one part fails, you get a cascading failure to the rest of the system

Anusha Shah, senior director, Arcadis

Renowned US environmental scientist Donella Meadows defines a ‘system’ as “a set of related components that work together in a particular environment to perform whatever functions are required to achieve the system’s objective”. 

Although a civil engineering structure may account for a large chunk of a project’s budget, it is not the end goal of the project – it is simply one component in a system that comprises multiple physical, digital and human components. For example, a rail tunnel exists to support a system that includes trains, stations and track; digital signalling, safety and communications; and passengers and drivers.

The civils design element of even a relatively simple project is only one component of that project. Delivering a project can therefore be viewed as a ‘system’ in which the civils design, construction, stakeholder priorities, supply chain capability and user behaviour are all elements that influence each other.

Principles of a systems approach

The overriding principles of a systems approach are:

  1. The whole is greater than the sum of its parts
  2. The whole system cannot be understood by focusing on the individual parts
  3. There is a need to understand how individual elements or activities influence one another, and the linkages, relationships and interactions between those elements and activities

A systems approach begins with understanding the outcome that the project is trying to achieve. For example, the client might want to improve links between two communities. One way to do this would be to build a road, but the road itself is not the outcome – the successful linking of two communities is the outcome. Focusing purely on delivering a road could ignore other – possibly more successful – options, lead to new and bigger problems further on or somewhere else in the system, or risk the client not achieving their desired outcome.

A Systems Approach to Infrastructure Delivery (SAID) requires engineers to focus on the operations and the services provided to customers, and may require a fundamental transformation of the leadership, culture and organisation of such projects.

The ICE has produced eight principles for improving project delivery through adopting a systems approach:

V-cycle process

The systems engineering process is often represented by the V-cycle process diagram (see image below) and supports development in physical assets and their digital twins.

Examples of the cycle’s application can be found in the ICE's 2020 and 2022 Systems Approach to Infrastructure Delivery reports.

Case study: East West Rail

Rebuilding of Bletchley flyover as part of East West Rail project

East West Rail is a programme to connect communities between Oxford and Cambridge. Construction has started on the first phase, between Oxford and Milton Keynes, with the business case currently being developed to extend the link to Bedford and then Cambridge. 

The project is being organised around a systems approach, which is helping East West Railway Company (EWR Co) to understand the impacts of its decisions on the cost and benefits of the railway on a whole-life basis and to avoid the risks that can be created by value engineering that focuses narrowly on capital cost.

A lot of schemes focus on the physical infrastructure, but before anything can be shovel-ready we have to ensure we have the end in mind and that we know what we’re trying to achieve

Simon Scott, engineering director, EWR Co

The company has ‘baked in’ systems thinking by using enterprise architecture (EA), a concept borrowed from the IT industry. EA is a way of modelling the connections and interrelationships between an organisation’s capabilities, its physical and digital assets and the strategic outcomes it is trying to achieve.

The EWR Co team uses the analogy of a Rubik’s Cube to describe the benefits of the EA model. Each element of the system – for example, civil engineering – is represented by one face of the cube. The impact of any changes made to one element of the project is immediately visible and can be analysed across all of the others.

Case study: Crossrail

The Crossrail project could have benefited from more of a systems approach

Crossrail is a large, complex programme that is integrated into Transport for London’s network as the Elizabeth Line. It opened in 2022, three-and-a-half years after the planned date. The final cost is estimated at £18.9bn, compared with an original budget of £14.8bn.

Lessons learnt from the Crossrail project include the need for ‘the owner to own’. Crossrail Ltd – the company delivering the railway – committed significant resources at the start of the project to create the Crossrail Programme Functional Requirement, which formed the basis for a robust reference design. However, this was later undermined by a procurement strategy that gave 37 lead contractors a high degree of freedom to alter the reference design without a sufficiently strong central authority to analyse and manage the consequences for the system.

Crossrail Ltd acknowledges that, during the project’s early years, it did not give sufficient attention to the rail systems integration. Its focus was on the huge expenditure and perceived risk associated with the civil engineering project to drive tunnels under London. In retrospect, it is clear that the scale and complexity of creating a functioning railway presented the larger risk than the civils work. 

Case study: HS2

Old Oak Common,  Nov 2021, HS2

High Speed 2 (HS2) is the UK’s new high-speed railway line between London, the West Midlands and the north of England. Phase 1 and Phase 2a are under construction and set to open between 2029 and 2033. A bill is currently going through UK Parliament for the section from Crewe to Manchester.  

The organisation building the line, HS2 Ltd, is adopting a systems approach to its procurement, design and delivery that includes managing a process of design integration as the programme progresses. 

HS2 is keen to ensure that the railway’s systems (such as signalling and controls) are integrated seamlessly once the project reaches that stage, so the people who are specifying those elements – and the ultimate train service operation – get involved in civils design reviews. And the early systems reference design is central to the civils development. 

HS2’s systems approach also includes modelling the railway in many different ways, including what the service will look like, the power required to best service the trains, signal modelling and ventilation models within the tunnels. 

How can projects adopt a systems approach?

A systems approach can be applied to any project by understanding that:

  • Even relatively small projects connect to or have an impact on existing systems, such as road networks
  • The delivery process of any project can be treated as a system, rather than a set of individual activities

Systems thinking can be introduced into projects by taking these steps: 

  1. Start with the end in mind and keep the end in mind throughout the entire project
  2. Focus on the outcome not the structure – there may be many different ways to achieve the outcome, some of which may be cheaper/lower-carbon options than building new
  3. Consider services, not structures, first
  4. Remove barriers to getting the right expertise to solve the right problems – get out of silo thinking
  5. Make all stakeholders partners in the enterprise
  6. Embrace the expertise of the supply chain
  7. Understand the changing demands over the project lifespan
  8. Does it have to be delivered all at once? Is it possible to create a minimum viable product and phase in more functionality over time?

Sign up to receive news from ICE Knowledge direct to your inbox.