Systems Engineering in the Business Case Phase to Reduce Risk in Megaprojects

Abstract

One of the main Frequently Asked Questions (FAQs) in project management for built environment or physical infrastructure projects is “How will this project scope be delivered on time and under budget, addressing health and safety in a sustainable way?” This article presents a parallel point of view summarised in a competing question: “Have you followed a systems engineering methodology to detail interfaces and integrations in the business case?” Megaprojects face multiple risks that incur project delays and cost overruns; hence, this article proposes a simple but nevertheless innovative model that incorporates a systems engineering framework at the start of the built environment or physical infrastructure project: the business case phase. This proposed approach seeks to derisk megaprojects composed of complex systems of systems (SoSs) in their earliest stage when financial decisions based on cost estimations have to be made. The scope of this article covers built environment and physical infrastructure projects and their associated ICT, digital, and technology programmes, rather than purely IT developments. The inconvenient truth is this additional systems engineering task embedded in the business case comes at a further project CAPEX cost that decision makers or stakeholders should be willing to accept as it provides a wider technical vision of the project and better quantifies the Return on Investment (ROI).

1. Introduction

1.1. Built Environment and Physical Infrastructure Risks and Issues

Built environment projects have gradually acquired more complexity from additional layers of regulation such as health and safety (H&S) and sustainability. In addition, traditional individual systems have become more intricate with the addition of sensors, hardware, and software providing enhanced user functionality. Finally, technology, digital, and data such as BIMs and Digital Twins have added the purely software dimension to projects and assets. Megaprojects within the built environment are naturally complex, where governments, backed by society, are committed and willing to accept the risks of delivery due to their outcomes that will benefit generations. A single human cannot fully control the different components of a megaproject, due to their complexity, not even a super project manager who can fly through the whole life cycle of the project. This whole life cycle starts from the Capital Expenditure (CAPEX) cost side covering design and procurement to installation, testing, commissioning, and handover, and ends on the Operational Expenditure (OPEX) cost side covering operations, maintenance, decommissioning, and recycling considerations from sustainability and circular economy requirements. Megaprojects are usually financed with a mixture of private and public money combined at different percentages.

Due to these properties, it is straightforward to determine the specific issues and risks megaprojects face throughout their life cycle. From the governance perspective, the defined accountability and responsibility provide clarity in the different roles and transparency to users, citizens, and auditors. The conflicts of interest from multiple stakeholders must be adequately documented to promote impartiality in the decision making. Variable policy and regulation present risks to be documented, forecasted, and mitigated as practically as possible, which also includes the lack of defined planning or an ambiguous one. Finally, laws must protect infrastructure projects against unnecessary government interventions and political short-term decisions. From an economic point of view, megaprojects are normally financed by mixed private and public investment, thus with varied ownership that may develop into ambiguous decision making serving opposite interests such as customers versus shareholders, specifically in asset management. The economic viability of CAPEX and OPEX costs versus revenues needs to balance the likelihood of fixation on operational price, interest rates, and currency fluctuations. This is made further severe by optimistic utilisation and viability forecast cost models and unrealistic contractor price estimations due to the lack of enough detail. From the technical angle, governance and economic risks generate the enforcement of non-optimal technical solutions where ambiguous technical requirement goals have the potential to deliver a solution that is not fit for purpose. Furthermore, individual elements within the megaproject infrastructure are produced by different organisations with some conflicting interests. In addition, obsolescence due to the fast change of technology generates a shortened technology cycle time embedded within a larger civil engineering programme. Finally, from a management position, all the above risks need to be proactively managed as they generate change on a defined price and schedule and have a cost impact on design, construction, installation, maintenance, and operation. In addition, the fact that organisations evolve and individuals move on coupled with a lack of relevant skills and communications provides additional management risks.

1.2. Systems Engineering

The systems engineering discipline was developed as a reaction to technically manage and integrate complex systems of systems projects, where single individuals cannot fully manage their complexity on their own, to increase the likelihood of success while reducing the risk of expensive failure and disastrous accidents. One of the first adopters was NASA in its handbook [1] describing the best practises of systems engineering for the development and implementation of large and small National Aeronautics and Space Administration (NASA) programmes and projects. The technical engineering of NASA systems required a methodical and orderly set of recursive and iterative procedures enforced in the design, development, operation, maintenance, and commissioning throughout their life cycle. The International Organization for Standardization (ISO 15288:2023) [2] defines systems engineering as a common framework of process descriptions within a set of terminology and procedures for the whole life cycle of systems. These processes are then applied to system elements, wider systems, or even systems of systems (SoSs). In addition, the ISO standard facilitates the transaction of system development and information between customers, suppliers, and other stakeholders in the system’s whole life cycle. Finally, the International Council on Systems Engineering (INCOSE) [3] guides the development, implementation, use, measurement, and improvement of systems engineering capabilities, processes, and activities based on suitability, effectiveness, and efficiency. This guidance ensures systems engineering processes and activities are scaled and measured while meeting the needs of the enterprise, organisation, programme, and project with acceptable levels of risks.

As a consequence, systems engineering has been developed to address built environment and physical infrastructure risks and issues, from a technical side. Systems engineering manages how the design of the complex systems of a project integrates through their whole life cycle via systems thinking principles. This harmonious integration of the different components and processes works collectively to perform the designed function. One of the most difficult outcomes of systems engineering is the establishment of processes that preserve stability while responding dynamically to unclear and variable conditions. The discovery of potential issues and gaps within the process highlights events that could become real issues if not properly addressed and solved by the related functional or non-functional components.

Systems Engineering presents some overlaps with project management. Both address the leadership of the project, although systems engineering targets the products such as the technical components, risks, and scope aspects, whereas project management focuses on the project and its managerial activities including finance, activity planning, and programmes. Normally, a Project Management Plan (PMP) based on the Project Management Institute (PMI) [4] and ISO 21500 [5] and a systems engineering management plan (SEMP) define the respective roles, processes, responsibilities, and methodologies. The main issue is that systems engineering is actually considered a design activity rather than an additional tool in a business decision, hence the research proposal of this article.

1.3. Research Proposal

Megaprojects face multiple risks that incur project delays and cost overruns. This article proposes a systems engineering methodology embedded into the first phase of a built environment or physical infrastructure project: the business case. Specifically, requirements management; interface management; systems architecture; the supply chain landscape; and Reliability, Availability, Maintainability, and Safety (RAMS) targets are included in the business case to provide a wider technical vision of the project. This proposed approach seeks to derisk megaprojects composed of complex systems of systems (SoSs) in their earliest stage when financial decisions based on cost estimations have to be made. Although intrinsically simple, this innovative idea has not been presented before; therefore, it grants publication due to its added value. With this model, it can be guaranteed that a thorough qualitative and quantitative method has been included in the business-case-phase decision-making stage to exhaustively consider technical systems interfaces and integrations, thus guiding risks and costs. A high-level qualitative analysis is performed to confirm the application of systems engineering in several project phases.

1.4. Research Structure

Section 1 has presented risks and issues present in the built environment and physical infrastructure, systems engineering, and the research proposal. Section 2 compiles a systems-engineering-related research literature review based on systems definitions and thinking, systems of systems, systems engineering in megaprojects, model-based systems engineering, information and service systems engineering, Artificial Intelligence (AI), and Digital Twins (DTs) for systems engineering. Section 3 defines the proposed model of systems engineering embedded in the business case phase, the outcomes of this phase as the Target Operational Model (TOM), and the design stage and associated risks covering quality, bias, assessments, rigour, and methodology. Section 4 presents a qualitative analysis to assess the current application of systems engineering in several business cases covering transportation, rail, airports, sports, energy, and urban regeneration. Section 5 initiates a discussion covering systems engineering related to the physical and digital built environments; Environmental, Social, and Governance (ESG); and other related technologies such as Building Information Models (BIMs), Digital Twins (DTs), Artificial Intelligence (AI), and blockchain. Finally, Section 6 shares the conclusions of this research.

2. Research Background

This section provides the literature review for systems engineering of the built environment and physical infrastructure including its application in megaprojects. In addition, systems engineering in information systems and services, Artificial Intelligence, and Digital Twins for Systems Engineering are also included to provide a wider context.

2.1. Systems Definition

The roles and responsibilities of systems engineering in a project, including its end-to-end involvement and the connection between systems and design engineering, are clarified for the technical aspect of the project cycle [6]. There are several graphic representations such as the waterfall, V, and even spiral that imply that work downstream cannot begin until the major reviews from the upstream have been satisfied. The clarification also includes topics such as decomposition and definition, incremental development, concurrent engineering, technology insertion, integration and verification, system analysis, the design process, system verification, the integration process, systems engineering definitions, and system development definitions. Systems engineering is divided into three simpler methods, namely discovery, programme systems engineering, and the approach [7]. Discovery involves significant analysis for high complexity in a problem space to verify that the problem can be solved via a feasible solution. Programme systems engineering focuses on the customer needs, trading off solutions and finally providing a cost-effective solution on time and under budget. The approach focuses on the specific needs and requirements of customers, ensuring integration. The application of systems engineering techniques to large infrastructure projects includes three stages [8]. These cover the design stage, the details for the planning and management of the construction stage, and finally the recommendations for the transition into service, operation, and maintenance of the resulting built product.

2.2. Systems Thinking

A general process closely aligned with human reasoning is applied such as systems thinking for a requirements discovery stage and a system design stage [9]. The proposed processes eliminate redundancies while ensuring the inclusion of the necessary functions based on the problem statement, investigation of alternatives, system modelling integration, system launching, performance assessment, and final re-evaluation. Rather than being linear, the process is repetitive with multiple feedback loops and parallel activities. Although the definitions for systems thinking diverge, there is agreement in the main methods that either support or limit systems in the development of systematic thinking within engineers [10]. These cover experiential learning, specific individual properties, and a supportive environment. The outcome is reflected in a systems thinking framework consisting of five foundational components: componential, relational, contextual, dynamic, and modal elements. The sustainability of the built environment is a developing element in the already-complex systems involved [11]. To successfully deliver sustainable built environments, systems thinking is proposed to collaborate and integrate processes via modelling, frameworks, and measurement that include economics, engineering, the environment, and social considerations. The method includes top-down processes that connect the policy level to the project level and bottom-up post-occupancy modelling and measurements via systems dynamics and agent-based approaches. Actually, equivalent to systems thinking, system theory also lacks a universally agreed definition [12]. There is no one specialised field of titled systems from which a systems theory can be developed. A formal definition of systems theory is composed of a taxonomy of seven axioms (centrality, contextual, design, goal, information, operational, viability) and forty-two knowledge topics where the fields of science are grouped into natural sciences, engineering, medical and health services, agricultural sciences, social sciences, and humanities.

2.3. Systems of Systems

The concept, foundations, research directions, and practical connotations for System of Systems Engineering (SoSE) include the integration of future complex systems with the development of traditional systems engineering approaches while maintaining its methodology, discipline, and rigour [13]. Four main areas are considered to improve the understanding and success of SoSE: the delivery of a new SoS into existence, the operation and maintenance of an existing SoS, the provision of effective transformation of an existing SoS, and the establishment of an assessment with performance evaluations for SoSs. An SoSE management framework considers the demands of continuous technological development in complex dynamic environments [14]. Based on SoS properties including autonomy, belonging, connectivity, diversity, and emergence, five management conceptual areas are defined based on risks, configuration, performance, policy, and business. Object-oriented software methods, object management groups, and unified modelling languages have been applied to large-scale complex software projects SoSs for object-oriented analysis and design [15]. Object management groups, system modelling languages, and more traditional systems engineering modelling techniques are deployed in several stages of the complex SoS projects. These techniques include problem definition, identifying and profiling stakeholders, analysing stakeholder functional viewpoints, modelling stakeholder interactions, determining goals of the stakeholders or stakeholder classes, analysing goals, creation of a use case architecture, realisation of the as-is and to-be use cases with activity diagrams, and model structures from norms identified in the behavioural model. The built environment is modelled as a complex social-ecological SoS based on the interaction of metabolisms at different scales [16]. Ecological models integrate several time scales, past and future, thus allowing assessments of adaptive capacity and additional characteristics of system resiliency. From this SoS model perspective, the dividing line between nature and built environment definitions becomes a cultural characteristic that adapts along the historical background. Artefacts, flows, and users are linked over time with a common framework via life cycle-oriented product modelling methods. The management of the long-term evolution of this social-ecological SoS is guaranteed by including ecological concepts of time, and the integration between the histories of nature and human culture.

The London Olympics 2012 construction programme demonstrated that systems integration was one of the main difficulties in the delivery of complex projects [17]. This type of SoS project requires meta-systems integration at an organisational level to manage multiple external interfaces and stakeholder and system integration levels to manage internal interfaces between systems. A holistic and integrative method for SoS analysis models urban structures and simulates partial scenarios for the long-term development of sustainable and liveable urban structures [18]. The robustness and risks of different built environment configurations are determined via scenario-based experiments for the development paths. These scenarios were established from the interconnection between expert assessment in design and planning with an SoS model, including its variables, interdependencies, and their role within the system. The role of model-based techniques within the SoS is analysed in several phases from modelling and architectural description to simulation, verification, and final testing [19]. The assessment includes elements such as autonomy and independence of the elements, distribution, evolution, dynamic reconfiguration, emergence of behaviour, and interoperability. A method to capture extreme event infrastructure within the complex built environment SoS interdependencies is based on recent catastrophic infrastructure system losses [20]. The method enhances the built environment system resiliency via a causal loop diagram and the Pearson moment correlation matrix. The causal loop diagram represents the interdependency behaviour, interactions, and feedback loops of the built environment functionality and restoration over a certain period to reveal the structure of a system via the system dynamics methodology. The Pearson moment correlation matrix determines individual infrastructure system recovery function parameters. These resulting interdependencies between isolated infrastructure systems provide situational awareness for future decision analysis about built environment disaster resiliency.

2.4. Systems Engineering in Megaprojects

Strong leadership with a coherent vision, the use of performance indicators, and organisational change programmes are essential for a successful outcome in megaprojects [21]. This is due to megaprojects possessing their own temporal internal economy, governance structure, and production systems. Although megaprojects create unique products, the processes involved in their production are increasingly standardised, simplified, and repeated to enhance performance. These processes are divided into systems integration for design and engineering coordination; project and programme management for supply chain integration; digital design technologies for design, construction, integration, and maintenance support; off-site fabrication, pre-assembly, and modular production for productivity, predictability, and health and safety improvements; just-in-time logistics for the supply of materials efficiency; and systems testing and trials for operational integration. The requirements for design organisations regarding megaprojects are determined from two principles commonly applied in economics: the principle of individuality covers data collected from individuals or employees and the principle of a non-individualistic view includes the description of group behaviour or a firm [22]. The determination of requirements for megaprojects demands experience where integration is the most difficult activity. This required experience covers several areas: megaproject, international, local, management, system, and specific design. All these different experiences are necessary for integration via technical interfacing, cooperation, coordination, and communication where a balance is required between generalist and specialist experience.

A supplier stakeholder management framework based on an integrated systems engineering project management approach strengthens collaboration between main contractors and suppliers [23]. This framework decreases technology and supply risks, overcoming the lack of skills and know-how via collaboration, and reduces the opportunistic behaviour of suppliers while improving communication and coordination between organisational levels and supplier commitment and performance. This supplier process covers its selection, performance evaluation, and final satisfaction analysis. The inputs of the process include the strategic guidelines for supplier management, analysis of the items, analysis of the criticality, analysis of marketplace context, and finally the stakeholder network. The outputs provide a selection of suppliers, the evaluation of the commitment for each supplier, an analysis of supplier and stakeholder networks, measurement of the supplier satisfaction, tools and methodologies, a ranking of suppliers, an updated list of suppliers, an evaluation of supplier partnership and opportunity cost, and the final benefits analysis. Systems engineering approaches and techniques can transform governance from project governance to system governance to improve the performance of projects delivered in a complex environment [24]. Systems engineering approaches include systems thinking, an open systems approach and modular design, a multidisciplinary approach, top-down and bottom-up approaches, and V models. Systems engineering techniques cover integrated product teams, systems integration processes, modelling and simulation, trade-off analysis, systems engineering management plans, and requirements management tools.

The model dynamics of Complex Adaptive System (CAS) theory and its potential for understanding complexity in management and organisation science are applied to the megaproject Hinkley Point C nuclear power plant [25]. This study focuses on patterns of complexity, nonlinear and non-deterministic mechanisms of planning and control, or decisions and implementation based on agents with diagrams, self-organising networks, coevolution to the edge of chaos, recombination, and system evolution. Users and technologies jointly create value for society over the system life cycle via organisational platforms that combine knowledge from research on different platforms, ecosystems, and networks [26]. The practical application is based on a megaproject for the renewal of Tapiola city district in the metropolitan area of the city of Espoo in Finland. The users’ joint activities contribute to cooperative project processes, solutions, and outcomes that generate tangible and intangible benefits. These mutually planned and governed design principles include inter-organisational coordinating bodies and combined activities that share ownership and decision making.

A soft systems methodology is applied to understanding stakeholder concerns and is supplemented with a theory of inventive problem-solving for identifying innovative solutions to address inconsistent stakeholder objectives [27]. This combined method shifts stakeholder management to a more holistic approach based on stakeholder engagement, specifically applicable for complex multi-stakeholder scenarios intrinsic to megaprojects. Systematic inventive thinking supports the entire stakeholders in going beyond trade-offs and compromises based on power equations that resolve conflicts among the stakeholder requirements. The paradigm “think big, start small and learn fast” releases the benefits of technology systems for the planning and delivery of megaprojects in highly innovative and collaborative environments [28]. To embrace this paradigm, five actions are required: create and develop positive business-to-business relationships, understand Systems Engineering to integrate project systems, be aware of the architecture of the new digital tools, learn knowledge and competence, and apply agile and hybrid models.

The management of major power generation and transmission projects encounters several challenges such as large scales, technical complexity, high-quality standards, and frequent coordination [29]. A new method of management performance evaluation of power projects is based on systems thinking combined with the G1 method and a cloud model. The systems thinking approach is based on four dimensions, construction entity, objective management, organisation, and technical support, as well as eight subsystems: project breakdown structure, quality management, safety management, schedule management, cost management, environmental protection, organisation/coordination, and technical innovation. The G1 model determines the order relationship and the relative importance as indicator weights. Finally, the cloud model method classifies the evaluation criteria to evaluate the performance of power project management. A systems thinking-based framework captures the project relationships and prioritises the operation and maintenance complexity of mega-transportation projects via social network analysis [30]. Systems thinking depends on distinction and conjunction to model the network and prioritise operation and maintenance complexity by assessing the direction and strength of links between indicators with the largest impact on the behaviour and features. This prioritisation of results enables the development of effective management strategies. Forty-seven complexity indicators were identified through a literature review, semi-structured interviews, and a Delphi survey based on a conceptual system model. These indicators were applied to map the operation and maintenance complexity network with the structure, function, and environmental characteristics analysed via social network analysis.

2.5. Model-Based Systems Engineering

To manage complexity, ensure traceability, and identify risks in systems development, model-based systems engineering (MBSE) approaches and tools formalise the application of methods of large, complex, interdisciplinary, and socio-technical systems for the entire life cycle [31]. Different MBSE-interacting dimensions need to be integrated to develop an environment that enables structured applications within a successful system. MBSE unifies and integrates standards, formalisms, processes, methods, modelling tools, organisational change, educational training and certification based on modelling tools such as brain thinking, and graphical modelling languages facilitated by continuously evolving information technologies. Required perspectives, related roles, and competencies for the successful and practical application of MBSE are based on the identification, categorisation, and association of stakeholders [32]. The identification and analyses of role models within the management layers include systems engineering, enterprise management, organisational management, and project management. These resultant roles are then categorised into homonyms and synonyms where an analysis of the semantic similarity finds their taxonomic relationships and their relation to MBSE. Finally, these roles are grouped against their relevance for MBSE key activities and associated with an implementation process.

A model network algorithm iteratively analyses the model’s input parameters, system structure, relationships, and signatures, automatically returning the entire valid model networks [33]. These valid model networks are continually revised and suggested to the product developer through the development of the product. The technique supports the systematic analysis of the relationships between the models due to their integration following the model classification structure and the definition of the input and output parameters. The method uses unified modelling language (UML) profiles and extends the SysML class block with an added attribute for the algorithm. The effects of extreme weather situations, characterised by their cascading effects with global and local interdependencies, are modelled via several scenarios, requirements, information systems, and validation methods as a systems engineering approach [34]. The conceptualisation and abstraction of these scenarios cover the entire chain from domain exploration to the evaluation of the impact in terms of technology and the assurance of the traceability of results. This mapping model includes their influence on stakeholders for decision making in emergency management that requires diverse, multidisciplinary competencies to interpret information.

2.6. Information Systems Engineering

A general-purpose multiagent systems engineering methodology develops heterogeneous multiagent systems via graphically based models through the whole life cycle of the agent [35]. The methodology specifies a detailed architecture-independent definition that describes the objectives of the system, behaviours, types of agents, and the communication interfaces of the agents. Specifically, it is composed of an analysis stage that captures the system goals, applies use cases, and refines roles followed by a design stage that creates agent classes, constructs conversations, and assembles asset classes and the final system design. The role of systems engineering in enterprise management for information-intensive organisations comprises three major roles or levels founded on complex SoS integrators [36]. The top-level process covers the enterprise-wide SoS architecture and the strategic development plan in an adaptable methodology. The middle-level process evaluates possible solutions, chooses a solution based on its fitness to the enterprise-wide SoS and defines its associated cost, schedule, benefits, and technical baselines. The lower-level process implements the selected solution following the accepted baselines.

A software development methodology for information system development models concept requirements based on users, positions, resources, roles, tasks, goals, and dependencies via an agent-oriented programming platform [37]. This method enables the inclusion of organisational and social considerations into the operational functionality which is then applied to determine detailed requirements and architectural and detailed design. The modelling framework includes software system design models from five complementary perspectives: social, intentional, communicational, process-oriented, and object-oriented. The adoption of a socio-technical methodology to systems engineering development develops systems more accepted by end users and delivers greater value to stakeholders based on workplace design, information systems, computer-supported collaborative work, and cognitive systems engineering [38]. The framework integrates the traditional gap between organisational change and systems and software engineering development approaches via stakeholder sensitisation, system awareness, and constructive integration with systems development and change management procedures.

2.7. Service Systems Engineering

Service systems engineering is a branch of systems engineering that enhances the design and production/delivery of services rather than products by applying systems engineering methods and approaches [39]. The intrinsic properties of services, such as real-time, privacy, information-driven, customer-centric, e-oriented, and productivity, evolve as technology innovates, whereas systems engineering needs to adapt to them. Service-oriented systems engineering targets the specification, analysis, fault-tolerant computing, verification and validation, model checking, testing, and dependability evaluation tasks of service-oriented software and hardware projects [40]. This is accomplished via collaborative methods of the specification and modelling, verification, design, implementation, validation, run-time evaluation, operation, and maintenance stages. Service systems co-create value by the combination of their complex socio-technical components including service architecture, technology, information, and physical artefacts founded on information systems [41]. Service systems engineering focuses on leading to actionable design theories, methods, and approaches for the systematic design, development, and pilots of service systems. This requires an understanding of the original principles of service systems where the challenges are engineering service architectures that enable improved business models, engineering service systems interactions that enhance contextualisation and collaboration, and engineering resource mobilisation via ubiquitous information systems.

2.8. Systems Engineering in Artificial Intelligence

Software systems are deterministic and can be built and tested to a specification; however, Artificial Intelligence (AI) and Machine Learning (ML) systems are commonly probabilistic, thus presenting a high margin of error [42]. This uncertainty for predictive algorithms makes it difficult to test and verify. The specification, design, dependencies, analysis, system change propagation, frameworks, and verification of reliable AI-enabled systems must include the uncertainty and unpredictability introduced by the AI/ML behaviour. A graph-based method and tool for systems engineering applies AI to complex development projects including organisation structures as well as risk management [43]. The method manages the complexity of products and processes, ensuring effective communication between stakeholders in product development. The model analyses, links, and harmonises diverse data landscapes, establishes a foundation for data path analysis, prevents incompatible data transmissions, and enhances traceability via its analysis and links. The extension of a failure mode taxonomy facilitates the integrated analysis of complex intelligent systems with embedded AI/ML and enables the logical analysis of the system [44]. This approach underpins the early stages of design and development based on the systems engineering methodology. The premature consideration of failure modes in the feature development procedure identifies and traces risks among the physical and embedded AI components of intelligent systems, thus enhancing the strength of the feature delivery alongside confidence in AI. The seven types of potential failure modes include no or loss, partial, degraded, intermittent, unintended, exceeding, and delayed functions plus the proposed early function.

2.9. Digital Twins for Systems Engineering

The latest foundations for thorough simulation-based systems engineering in virtual testbeds are based on Digital Twins [45]. These simulations include complex, interdisciplinary, and distributed systems of systems for their networking, commissioning, diagnosis, and optimisation for shorter development time frames. Digital Twins enables innovative agile development methods from an experimental knowledge base, communication, collaboration, documentation, and test infrastructures that cover the whole life cycle. The integration of Digital Twins with system simulation, Internet of Things (IoT), and experimentation testbeds supports model-based systems engineering [46]. Four different Digital Twin levels based on a gradual sophistication from data acquisition in the physical twin to the machine learning Digital Twin are denoted as the pre-Digital Twin, Digital Twin, adaptive Digital Twin, and intelligent Digital Twin.

The application of Digital Twins for asset management presents issues due to the discrepancy between design, construction, operation, and maintenance due to their complex technical systems [47]. The management of the asset life cycle and its technical systems via a Digital Twin reduces time and therefore costs from traditional siloed trial operations and documentation updates. In addition, the inclusion of the potential owner of the asset, the investor, and the organisation operating and managing the facility alongside human factors in the design stage enhances the final quality of the product. An implementation framework for manufacturing systems applies a reduced version of a Digital Twin for model-based systems engineering and the systems engineering V model [48]. The modelling of the systems defines the Digital Twin components, functionalities, and structure based on the framework and general configurations with physical, virtual, and information spaces. The physical spaces present physical and perception layers. The information spaces host a unique layer called middleware. Finally, the virtual spaces include an application and a model layer. The framework incorporates other elements from digital threads, data, and ontologies to enabling technologies. The model classifies these concepts into classes, spaces, or layers; analyses them and their relationships, properties, and functions; and finally generates a systems structure based on their taxonomy.

3. Systems Engineering Model in the Business Case Phase

The proposed model includes a systems engineering framework from the start of the project: the business case phase. These additional activities establish a systems thinking methodology to better define the scope and programme, thus reducing risk while addressing other dependencies such as planning, sustainability, and health and safety. This approach ensures the built environment or physical infrastructure megaproject will receive the required buy-in from the stakeholders based on qualitative and quantitative analysis to raise the necessary budget. Specifically, the systems engineering deliverables include requirements management; interface management; systems architecture; supply chain landscape; and Reliability, Availability, Maintainability, and Safety (RAMS) metrics. These additional deliverables are validated with a benefits analysis that shall also provide performance metrics in terms of cost overruns or construction delays with and without systems engineering in the business case phase (Figure 1).

The proposed open system methodology gradually interacts with its project environment, continuously adjusting and evolving to variable requirements throughout the project’s life cycle to cope with changes (Figure 2). Therefore, optional change management and configuration management are considered part of the next phase—design—when changes from this adaptation and associated versions start affecting the original project requirements and architecture.

3.1. The Business Case with Systems Engineering

Business cases methodologically define the value proposition and reasons to initiate a project while justifying resources such as time, money, or effort to make a justifiable decision based on evidence. These reasons need to support specific business (hence the name) needs, drivers, or requirements as objectives quantified in financial and non-financial benefits. Traditionally, content included in the business case includes the project background, the expected business benefits, the different options considered (including the cost of doing nothing), criteria for rejection or success, a gap analysis between the current state and the future state, the expected costs cash flows, assumptions, and the forecasted risks.

Other additional content includes stakeholder alignment within an organisation’s structure; the culture to assign the right resources supporting the initiative; feasibility studies to assess the practicality of a project or system based on strengths, weaknesses, opportunities, and threats (SWOT) and cost-versus-value basic criteria, Key Performance Indicators (KPIs) to track and measure success along with and continuous improvement, implementation plans, and business processes. Benefits, business drivers and require-ments are easy to elicit, however, the challenge normally sits within the cost models and the risk quantification, thus providing return of investment (ROI) issues. Although this section presents the complexity of a business case, the mind map is the answer to the questions of why, what, how, who, where, and when.

3.1.1. Requirements Management

Requirements management covers the methodology to identify, determine, and manage the stakeholder, system, and subsystem requirements during the project. In addition, requirements must be determined in the business case phase. Requirements need to be Verified and Validated (V&V), due to these processes and assessments varying, and they have the potential to add costs to the supply chain and risks to the project. The verification of requirements evaluates their inclusion in the final outcome, whereas the validation of requirements confirms their functionality within the final product. This added transparency and clarity based on standardised approaches and methods in the business case phase augment the control and management of the project, minimise project risks, reduce the costs of the project and product, and improve the quality of the product through its whole life cycle.

The management of the requirements throughout the life cycle is supported by the V model that graphically depicts the activities and outcomes or deliverables. This model maps the calculation, estimation, and control of the product development, whereas deviations and changes are recognised in an early stage. The final outcomes and results are ensured to be complete and uniform and, therefore, capable of being recreated and retraced. Traditionally, V models are associated with linear waterfall strategies in built environment projects rather than iterative agile methodologies based on circular sprints, although the Minimum Viable Product (MVP) approach is changing this strategy.

3.1.2. Interface Management

Interface management includes the leadership of technical relationships between the different stakeholders of the project to obtain and record information between two elements of the project. These elements include users, systems, subsystems, and devices. Users must represent all the stages of the project and include stakeholders, designers, installers, managers, operators, maintainers, and customers. External and internal interfaces include technical, digital, and physical inputs and outputs. Interface records must include the owner of the interface and the input and output definition for each system and user. The objective of interface management is the confirmation that all interfaces have been considered, integrated, and included within the project requirements in the business case phase, and that the appropriate effort to manage and address them is costed accordingly.

3.1.3. Systems Architecture

The systems architecture provides a conceptual and visual representation of the organisation and relationships between the users, systems, subsystems, and devices of a project, including its external environment arranged in a spatial order. The mapping and description of the systems functions must include all the interfaces and provide a standardised and uniform representation of the entire project. The system architecture corresponds to the single source of truth in the business case phase for the common understanding between all users and stakeholders of the project.

3.1.4. Supply Chain Landscape

The supply chain landscape maps the complex logistics systems that produce and distribute the resources to deliver the project including the flow of humans, the materials, and its management based on tiers. The supply chain processes and flows, including procurement, contracts, information, and finance, also need to be included in the business case phase as it adds risks and associated costs. This is due to all parties within the supply chain seeking to maximise revenue and reduce costs. Requirements that include procurement, sanctions, circular economy, policies, regulations, recycling, safety, governance, the environment, ethics, and sustainability need to be considered and costed before a project starts. These requirements can be used as a traceability tool to audit the supply chain.

The supply chain varies as the project progresses during its life cycle, albeit contributing to the project’s success. This additional clarity will not only reduce risks and costs while fomenting competition, but also support resilience in the supply chain to manage expectations and adapt to change via the support of demand forecasting, accuracy, and planning for functional, efficient, responsive, and innovative outcomes, resulting in better quality, auditing, and traceability of the supply chain.

3.1.5. Reliability, Availability, Maintainability, and Safety (RAMS) Targets

Reliability, Availability, Maintainability, and Safety (RAMS) metrics define the quality of the project and ensure the functionality and compliance of service performance of the outcome during its operational phase. Reliability defines the capability to perform a defined function, Availability is the capability to retain an operative state, Maintainability is the capability to be easily looked after on time, and Safety is the capability to not injure users, affect the environment, or damage any assets. High-level metrics and guidelines in redundancy; mathematical and statistical methods; and lifetime Reliability, Availability, Maintainability, and Safety requirements have a large impact during the design stage, therefore potentially increasing its costs. The definition of these metrics in the business case phase, even at a high level, decreases the risks of the project as it reduces the disambiguation of the methods, methods, tools, and techniques.

3.2. Outcomes of the Business Case with Systems Engineering

3.2.1. Target Operational Models

The Target Operational Model (TOM), or Concept of Operations (ConOps), describes the desired state of the operating model of the asset the project is going to deliver. TOMs orchestrate People, Processes, and Technology to achieve the strategic vision, transformation, or business case of the infrastructure project based on effectiveness and performance. People include the different asset users, customers, and departments such as management, operations, maintenance, IT, legal, and HR. Processes cover the different locations, products, services, capabilities, functions, and interactions defined by Key Performance Indicators (KPIs). Technology includes Information Technology (IT), Operational Technology (OT), Artificial Intelligence, digital, and data. The TOM also needs to ensure resilience, agility, adaptability, and flexibility in evolving market and customer dynamics and drive efficiency and innovation. The TOM follows the system architecture model in the business case phase addressing the how, who, where, and when, and removing the why and what. The TOM needs to be aligned with the project requirements for a successful project.

3.2.2. Design Stage

The concept and detailed design stage continue the business case and TOM where the difference between these two designs is the level of technical detail. The design stage includes the determination of functional and technical requirements, performance specifications, and other design deliverables such as drawings and schematics for every system that forms the infrastructure to detail and constrain the final outcome. The design provides a method and processes to include the project requirements where possible solutions iteratively tune and optimise themselves based on a gradual trade-off between the different requirements, which can be contradictory, and collaboration between disciplines. These optimisations seek to reduce cost, enhance quality and functionality, facilitate constructability, and increment RAMS. These gradual iterations create issues that need to be creatively solved via comprehensive reflection and rational decisions. The major risks are that human designers need to make rational decisions after comprehensive reflection, unrealistic assumptions, and finally continuous requirements and finally requirements are continuously added and changed.

Normally, the design follows design frameworks, such as RIBA, to standardise the design competences, level of technical detail, roles and disciplines, design stages, and inputs and outputs. Traditionally, systems engineering processes and tools have started in the design stage based on technical interface registers, system architecture, requirements verification, methodological discipline coordination and alignment, change management, and configuration management.

3.3. The Risks of Systems Engineering in the Business Case

3.3.1. Cost versus Quality

Quality, in terms of Reliability, Availability, and Maintainability, is assigned to a cost and therefore subject to the traditional project and product compromise of their balance and optimisation. The risk is the addition of systems engineering to provide quality in the delivery of the project, and the product itself incurs an additional effort and therefore cost. Decision makers and leadership need to justify in the business case the decision process for the inclusion of systems engineering and the risks associated with its exclusion.

3.3.2. Bias versus Impartiality

Systems Engineering, equivalent to other consulting activities, needs to be impartial to the various stakeholders, users, products, and solutions, although considering entirely their requirements. The risk is the influence of stakeholders in systems engineering for their benefit and political agenda. Furthermore, product or solution suppliers or manufacturers providing systems engineering services are a conflict of interest that reduces the value of impartiality due to the economic bias of their organisations.

3.3.3. Qualitative versus Quantitative

It is essential for systems engineering to apply qualitative reasoning in capturing interfaces and technical dependencies based on experience and rigorous processes, which is known as systems thinking. Additionally, quantitative assessments need to back these qualitative assessments in Reliability, Availability, and Maintainability targets based on real performance data provided by the suppliers or similar equipment already in operation in other assets. The risk is considering systems engineering as a routine exercise that needs to be performed to tick a box rather than a valuable framework that will reduce project risks while enhancing the product.

3.3.4. Too Much versus Too Little

Crucially, systems engineering tools, processes, and produced deliverables need to provide the right level of detail in terms of length and technical descriptions and a short, succinct, and specific methodology. Humans are the users and receivers of the tools which need to process and comprehend the information to make rational decisions at strategic, tactical, and operational levels. The risk is systems engineering delivered as a consultancy fee justification, rather than value-added-driven, with extensive unnecessary wording and complexity that defocuses the audience or beautified presentations that do not provide specific content.

3.3.5. Human versus Machine

Finally, systems engineering needs to combine humans with machine tools based on hardware, software, data, and integrations to augment its benefits. Built environment infrastructure projects are becoming more complex in size, duration, systems, and regulation; therefore, machine tools that support collaboration and systems thinking and systems engineering processes such as requirements validations and verification will expand the reach of humans. The risk of systems engineering being delivered only by humans is the intrinsic human weakness such as involuntary error and voluntary bias, tiredness, lack of interest, or competition.

4. Qualitative Analysis of Systems Engineering in the Business Case Phase

This section provides a high-level qualitative assessment to validate whether systems engineering has been included in the business case phase for some UK megaprojects that cover transportation, rail, airports, energy, sports, and urban regeneration. These megaprojects were selected based on their complex systems of systems nature with a built environment background. The analysis was conducted and limited by the information gathered from publicly available sources, which has been proven scarce, and is rigorously referenced.

Table 1. Qualitative analysis of systems engineering in the business case phase.

Project	Schedule	Cost	Systems Engineering
Canary Wharf Development	Start: 1988 End: 1991	Initial: N/A Final: N/A	Business case: No Design and build: No
Channel Tunnel	Start: 1988 End: 1994	Initial: GBP 5.5 bn Final: GBP 9.0 bn	Business case: No Design and build: Yes
Heathrow Terminal 5	Start: 2002 End: 2008	Initial: GBP 4.0 bn Final: GBP 4.3 bn	Business case: No Design and build: No
Wembley Stadium	Start: 2003 End: 2007	Initial: N/A Final: GBP 789 mn	Business case: No Design and build: No
London 2012 Olympics Games	Start: 2005 End: 2012	Initial: GBP 4.0 bn Final: GBP 8.9 bn	Business case: No Design and build: Yes
CrossRail 1	Start: 2009 End: 2022	Initial: GBP 6.9 bn Final: GBP 18.8 bn	Business case: No Design and build: Yes
Battersea Development	Start: 2013 End: 2022	Initial: GBP 9.0 bn Final: N/A	Business case: No Design and build: No
High Speed 2	Start: 2017 Expected 2033	Initial: GBP 50.1 bn Expected: GBP 98 bn	Business case: No Design and build: Yes
Thames Tideway Tunnel	Start: 2016 Expected End: 2025	Initial: GBP 3.8 bn Final: GBP 5.0 bn	Business case: No Design and build: Yes
Hinkley Point C	Start: 2017 Expected End: 2030	Initial: GBP 18 bn Final: GBP 35 bn	Business case: No Design and build: No
CrossRail 2	Expected Start: 2023 Expected End: 2030s	Initial: GBP 32.6 bn Expected: GBP 45 bn	Business case: No Design and build: N/A

summarises the different projects in terms of a high-level schedule for the start of the construction and final project delivery, the initial estimated and the final calculated costs, and whether evidence was found of systems engineering applied in the business case phase or the design and build phase.

Previous quantitative analyses to assess the cost and the Return on Investment (ROI) in megaprojects provide statistically significant results for the cost overrun in transportation infrastructure projects based on a sample of 258 transportation infrastructure projects in twenty nations on five continents worth USD 90 billion at 1995 prices [49]. This study concludes, with a large statistical significance, the cost estimates and cost–benefit analyses that justify that the final go/no-go decision is highly and systematically optimistic due to strategic distortion. Specifically, for rail and road projects, the actual costs are on average 45% and 20% higher than the estimated costs, respectively. What causes this cost increase is assessed based on three variables: the length of the construction phase, the size of the project, and the type of ownership [50]. Cost increments are highly dependent on the duration of the construction phase where, for every lapsed year from the decision to build until operations begin, the average increase in cost is 4.64%. The risk of cost rise is high for all project sizes and types where projects’ schedules and scope increment over time. The general assumption that public ownership is problematic and private ownership is effective in limiting cost overruns is an oversimplification. In megaprojects, once the asset is operational, cost overruns are measured between 50% and 100% in real terms, and demand forecasts are corrected by 20% to 70%; thus, the actual viability of megaprojects does not correspond with forecasted over-optimistic viability [51]. The proposed mitigations for these large deviations include the assignment of the risk and accountability in the decision-making structure; the rearrangement of public and private responsibilities to remove conflicts of interest; and four basic instruments of accountability, namely transparency, performance specifications, explicit formulation of the regulatory regime, and the involvement of risk capital. Total global megaproject spending is estimated between USD 6 and 9 trillion annually, or 8% of the total global gross domestic product at 2014 prices [52]. Performance data for these megaprojects demonstrate that nine out of ten present cost overruns where increases of up to 50% in real terms are common and over 50% are not uncommon. Large-scale ICT projects are even more risky where one in six such projects becomes a statistical outlier in terms of cost overruns, with an average increment for outliers of 200% in real terms. A study of approximately 16,000 major projects in 2023 identifies that only 8.5% of those projects were delivered on time and budget; moreover, a mere 0.5% were completed on time and budget and produced the expected benefits [53].

These quantitative analyses evidence that megaprojects face cost and revenue discrepancies. Although the authors highlight issues, provide some recommendations, and suggest possible causes, systems engineering and integration methodologies and tools to provide a greater technical representation of the project before estimating the cost have not been considered. Moreover, a quantitative analysis that measures the ROI of systems engineering in seventy large infrastructure engineering projects executed between 2010 and 2019 shows that there is a significant correlation between the application of systems engineering and the final cost deviation of projects, whereas for projects with a small amount of systems engineering, the Return on Investment can be up to 7%. In addition, the optimal cost ratio occurs when 6.5% of the project hours is applied to systems engineering. The calculations were based on the initial cost and final margin based on the ratio between hours dedicated to systems engineering, the total hours used in the project, and the ratio between actual and expected cost [54].

4.1. Canary Wharf Development

The Canary Wharf project redeveloped the Docklands from an abandoned industrial area by the 1980s into a financial district serving the City of London with improved access via a new light metro link: the Docklands Light Railway (DLR) that used a large amount of existing railway infrastructure. The government stimulated the conversion of the area via supporting policies, first creating the London Docklands Development Corporation (LDDC) in 1981 and then granting Urban Enterprise Zone status to widen the Isle of Dogs in 1982. This made Canary Wharf consist of 97 acres with land values of GBP 400,000 per acre for land and GBP 10,000 per acre for water sold at 1985 prices [55]. Canary Wharf changed ownership in 1987 for approximately GBP 80 million where construction started in 1988, delivering the first completed buildings in 1991, including One Canada Square, the UK’s tallest building at the time, at a cost of GBP 624 million. One Canada Square became the symbol of the successful urban regeneration of the Docklands with a height of 235 m and fifty stories. After this initial success, Canary Wharf Limited went bankrupt in 1992 due to the global property recession. Eventually, Canary Wharf Group bought the development for approximately GBP 800 million in 1995. There is no business case available; nevertheless, evidence of systems integration was considered; however, the original bankruptcies and change of ownership prove the difficulties and complexities of the project for the initial investors.

The area is readapting once more from a mainly services-driven economy based on working in the office building and shopping in the underground complex to a hybrid workplace, expanding into “Live–Work–Play” services. Furthermore, Canary Wharf is successfully diversifying its tenants, attracting other businesses such as life sciences in addition to the original financial institutions. Additionally, Canary Wharf is transforming its office portfolio to more agile tenancy strategies based on flexible floors rather than entire buildings to meet current and future occupier’s demands for shorter and reduced leases. Initially, Canary Wharf industrial leases consisted of acres for warehouses before its transformation. Finally, Canary Wharf is embracing a Smart Cities approach, expanding its residential units, parks, nurseries, leisure, sports, and social events driven by a mobile app with several cases including social permeability and local interconnections served by the Jubilee and Elizabeth Line, DLR, buses, Thames Clipper, and London City Airport. Canary Wharf is becoming the symbol of a gradual and successful series of organic adaptations and regenerations from an original industrial to a current work-centred office environment and into a future human-centred smart city.

4.2. Channel Tunnel or High Speed 1

The Channel Tunnel or High Speed 1 project is a 50.46 km railway tunnel under the English Channel inaugurated in 1994, connecting Kent (England) with Pas-de-Calais (France). High Speed 1 trains travel at up to 300 km/h with a speed limit inside the tunnel at 160 km/h separating London and Paris by two hours and fifteen minutes, whereas London and Brussels is separated by one hour and fifty-five minutes. Construction began in 1988 with an estimated budget of GBP 5.5 billion in 1985, though it ended up costing GBP 9 billion due to changes to the original electromechanical equipment (track, power, signalling, cooling) and rolling stock specifications to improve security and safety [56]. Although early investors and banks lost their original money, the outcome of the project is generating an economic rate of return over the life of the concession estimated between 3 and 6%, providing a fast, reliable, and low-carbon connection between two capital cities in a continent and an island. There is no official business case or detailed costs publicly available. The Channel Tunnel rail link case study [57] confirms that the British government advised British Rail to consider its estimated cost of GBP 400 m as the limit for the project, although there is no public evidence to validate this based on completed site surveys, systems engineering, or integration to assure all possible technical users, systems, and interfaces have been considered. Nevertheless, systems engineering and integrations were considered within the management plan in the delivery stage of the project, specifically design coordination and interface management and systems integration model and requirements traceability [58,59].

4.3. Heathrow Terminal 5

Heathrow Airport Terminal 5 was inaugurated in 2008 as the largest free-standing structure in the United Kingdom designed to handle 72.29 million passengers a year. The original budget for the project was GBP 4 billion and took almost 20 years from conception to completion with a final cost of GBP 4.3 bn, almost on time and within budget by megaproject standards. The reason for this extended schedule was the rigorous planning stage as Heathrow is next to urban areas. BAA embraced the ethos of partnering and integration with their suppliers and procured approximately fifty construction and consultancy framework agreements via the European Procurement Journal. The procurement route based on the T5 Agreement contract supported multiple suppliers and interfaces [60]. There is no publicly available business case or evidence of how systems engineering or systems integration was considered, although the concept of integration was present. Unfortunately, issues experienced with the baggage system, car parking, security searches, and the terminal itself were caused by insufficient communication between owner British Airports Authority (BAA) and operator British Airways (BA), low staff training, or system testing [61]. The difficult decision to open the terminal on time rather than delaying its inauguration shortened the testing and commissioning programme. To mitigate this risk, reasonable series of public trials were conducted to identify and resolve any faults in the operation of Terminal 5. The main lesson learnt was to gradually open an asset to the public and get it to fully operational speed once ready.

4.4. Wembley Stadium

Wembley Stadium opened in 2007, replacing the original Wembley Stadium with 90,000 seats and a height of 134 m due to its Wembley Arch which structurally supports the roof load while providing an aesthetic landmark across London. The original plan for the demolition of the existing stadium was in 2000, and for the new stadium to be commissioned in 2003. This project was behind schedule by a cascaded series of financial and legal difficulties, moving the beginning of construction to 2003. The stadium was eventually built at a cost of GBP 798 million in 2007 albeit at a significant loss. Reasons include the finding of unexpected heritage foundations from a Victorian building, subcontractors pulling off the project, legal health and safety breaches, issues with the steel rafter in the roof, and sewage pipe drifting [62]. Even though the project suffered these issues and delays, the stadium now creates revenue while providing a venue for football matches and other local events. Furthermore, Wembley Stadium is the centre of a wider mixed-use regeneration area, Wembley Park, consisting of residential, offices, retail, leisure, and parking spaces with a further GBP 3 billion investment [63].

4.5. London Olympics 2012 Games

The London Olympic 2012 Games consisted of a combination of new venues, existing and historic facilities, and temporal sites. Most of these places were scattered into three zones within Greater London: the Olympic, river, and central zones. The official cost estimates for hosting the Olympics also increased from an initial estimated gross cost set for GBP 4 billion in 2003 up to a total budget of GBP 9.325 billion for the Games Olympic Park, other venues, and infrastructure associated in 2007 [64]. Including the East End regeneration costs, the breakdown was building the venues and infrastructure at GBP 5.3 billion, elite sport and paralympic funding at GBP 400 million, security and policing at GBP 600 million, regeneration of the Lower Lea Valley at GBP 1.7 billion, and a contingency fund at GBP 2.7 billion. In 2012, the final cost of the Olympics was estimated at GBP 8.921 billion, including a contingency for the Olympic Delivery Authority (ODA) and the London Organising Committee of the Olympic Games and Paralympic Games (LOCOG). There is no mention of systems engineering and systems integration approaches in the cost estimations, nor the actual costs for the integrations. The success of the London Olympic 2012 Games and the regeneration of Stratford was estimated between GBP 28 billion and GBP 41 billion in benefits over the period from 2004 to 2020 [65]. This estimation included the overall economic impact directly from the 2012 Games; the access from different businesses to the project and its outcomes; the promotion of the United Kingdom as a place to invest; the promotion of exports and trades; the development of tourism, employability, and skills; the promotion of sustainable business; and the opportunities for disabled people in business and access to transport.

4.6. CrossRail 1

CrossRail 1, or the Elizabeth line, is an operational hybrid commuter rail and rapid transit system project in Central London that delivers at a high frequency, up to 24 trains per hour, in each direction crossing the capital from the suburbs on the west and east. CrossRail 1 was the solution to alleviate capacity issues in the National Rail and London Underground networks during the peak periods. The project was accepted in 2007, and construction started in 2009, opening in 2022. The business case provides an estimate for the base capital cost for the project of GBP 6.9 bn at 1st quarter 2002 prices, which increases to GBP 10.1 bn when contingency is included [66], although the total estimated cost rose to GBP 18.8 billion by December 2020. The project costs were divided into land and property, tunnels, surface route infrastructure, trackwork, stations, railway systems, stabling, depots, maintenance vehicles, and project teams and commissioning. Although it provides railway systems, there is no information available detailing specific costs for the external systems interfaces and integrations with existing systems, such as Network Rail and London Underground infrastructure, nor a methodology to identify these costs. The contingency analysis already identifies two main reasons for optimism bias, namely poor identification of the scope and objectives both because of the poor identification of stakeholder requirements. The business case includes external integration of the transport network rather than systems engineering and integration.

CrossRail 1 was delivered with a systems integration management plan [67] that covered the V life cycle, requirements management, verification and validation, assumption management, interface management, configuration management, RAM management, engineering safety management, human factors management, electromagnetic compatibility and testing, and commissioning management. Even though CrossRail 1 had a systems integration management plan, the main lesson learnt and recommendation from the legacy of CrossRail 1 is the deployment of a systems integration team within the client’s programme partner organisation, rather than in the programme delivery team. This systems integration team should have the technical authority within the technical directive to manage the required systems integration activities for the entire work, from the initial phase of contract formulation through to commissioning and handover [68]. The benefits CrossRail 1 has provided to London and Londoners have been widely accomplished and acknowledged, therefore endorsing current considerations to expand the line, just two years after it opened. This expansion reinforces the concept of the Minimum Viable Product (MVP), where benefits are delivered gradually, and additional costs can be funded with current revenues.

4.7. Battersea Power Station Development

Battersea Power Station is a decommissioned coal-fired power station located on the south bank of the River Thames in Nine Elms, Battersea. The building comprised two power stations, A and B, built in two stages with two chimneys each. In 2007, its listed status was upgraded to Grade II, although the building remained empty, falling into near-dereliction. In 2012, its administrators agreed with the developers to transform the building and the overall 42-acre (17 ha) site, blending residential, cafes, bars, restaurants, office space, shops, art, leisure facilities, and entertainment spaces. The net price for the site was GBP 400 million, which would include GBP 325 million to cover the debts and a GBP 100 million contribution to the TfL Northern Line extension. The successful restoration from dereliction of the historic power station has kept London’s iconic landmark while creating a new riverside park and a new high street. The GBP 9 bn redevelopment project was mainly divided into three phases, namely Circus West Village; restoration of the power station; and Electric Boulevard, Battersea Roof Gardens, and Prospect Place. There is no publicly available information about project delays or cost overruns or any references to systems engineering.

4.8. High Speed 2

High Speed 2 is a planned high-speed railway in the United Kingdom originally planned to connect London, Birmingham, Manchester, Leeds and other cities. Despite its name, rather than speed, the project seeks to alleviate capacity issues on the already-congested east and west coast main lines while increasing city connectivity. The project was split into three phases following a Minimum Viable Product (MVP) approach: Phase 1, between London Euston and the West Midlands; Phase 2a, between the West Midlands and Crewe; and Phase 2b, completing the full network to Manchester and Leeds. Other additional phases included connections to the existing High Speed 1 and Scotland, which are expected to materialise once the project starts delivering benefits and revenues. The economic case for HS2 divides the estimated cost into capital construction, rolling stock, and operation [69]. The construction costs estimation divides the railway into contracts and delivery teams, tunnels, civil engineering, stations, depots and stabling, railway systems, on-network works, land and property, and corporate overheads. The spending round in 2013 fixed the funding envelope at GBP 21.4 billion for phase one, GBP 21.2 billion for phase two, and GBP 7.5 billion for rolling stock based on an agreed SR2013 budget at P95 and P50 levels of confidence. Furthermore, the document acknowledges extensive survey work performed over the previous 18 months during the design development work to upgrade an already-2012 cost. Although the cost is detailed and robust in the references, it does not confirm the detail and scope of the surveys, or where systems engineering and systems integration were part of the methodology for its calculation. The full business case, high speed 2 Phase One [70], subdivides the business case into strategic, economic, financial, commercial, and management cases, where the funding envelope was updated to GBP 45 bn. Although systems integration was considered within the railway systems package, it does not confirm if systems engineering and associated interfaces and integration were part of the methodology to detail costs such as the integration with the existing Network Rail infrastructure.

4.9. Thames Tideway Tunnel

The Thames Tideway Tunnel is a 25 km long and 7.2 m in diameter combined sewer to capture, store, and transport almost entirely the raw sewage and rainwater that currently overflows into the estuary of the River Thames. Construction started in 2016 with a planned completion in 2024, although COVID-19 has delayed it to 2025. The estimated CAPEX cost was GBP 4.1 bn at 2014 prices with an expected 120-year economic life, although the final cost has increased up to 5 bn mostly due to the COVID-19 pandemic and other scope changes mitigating the risk of planning consents. The expected benefits range between GBP 7.4 billion and GBP 12.7 billion [71]. The National Audit Office already highlights, based on the previous audits of major projects, that several common causes of project failure or cost overruns include over-optimistic assumptions, technical challenges not recognised, and a limited understanding of interdependencies and related projects [72]. There is no public evidence that systems engineering and integrations have been considered to support the costing figures, although there is a role for a Systems Integrator responsible for installing, testing, and maintaining communications and monitoring equipment.

4.10. Hinkley Point C

The Hinkley Point C nuclear power station is a two-unit, 3200 MWe Evolutionary Power Reactor in Somerset, England, with the ambition to produce 7% of Great Britain’s estimated electricity requirement by the mid-2020s, although it is currently still under construction. The project was initially approved in 2016 with an estimated cost of £18 bn (in 2015 prices) and an expected 9% ROI based on an operating lifetime of 60 years. The total CAPEX cost included design and built activities and other ancillary items such as spare parts, facilities management, and construction insurance [73]. The project has already been delayed for several reasons, including the COVID-19 pandemic and the fact that the reactor design is unproven based on complex electromechanical systems and piping. The estimated final cost is in the range of GBP 31–35 billion. The developer is responsible for the construction risks, which isolates taxpayers and consumers from costs overrunning, although consumers could end up paying more for its electricity than if the government had shared these risks [74]. Ultimately, these risks could be transferred back to taxpayers or consumers if the project collapses, as the government may need to fund alternatives to ensure a secure supply or renegotiate a new deal. The cost model does not provide the methodology to assess the cost for internal and external systems’ technical interfaces and integration.

4.11. CrossRail 2

CrossRail 2 is a project proposal for a hybrid commuter rail and rapid transit north–south link in Greater London, connecting nine stations in Surrey to three in Hertfordshire via Central London with an option for driverless trains. CrossRail 2 plans to alleviate severe overcrowding that would otherwise occur on commuter rail routes into Central London with an estimated cost by Transport for London (TfL) in 2016 to be GBP 32.6 billion [75]. However, TfL already considered that the full cost of the project could be GBP 45 billion in 2017. The costs are divided into land and property, tunnels, stations, systems, surface works, indirect costs, and rolling stock with an optimism bias at 66% [76]. The business case provides no specific mention of systems integration or interfaces.

5. Discussion

This section provides a discussion about other considerations of systems engineering in the built environment and physical infrastructure megaprojects and related technologies including Building Information Models, Digital Twins, Artificial Intelligence, and the blockchain.

5.1. Systems Engineering for the Physical Built Environment: The Systems Architect

Traditional systems engineering for the physical built environment has been delivered by the systems engineer or architect. The core elements of physical system integrations are eventually mostly formed of spatial provision, physical support, containment, power, energy, water, cooling, heating, and data. These elements can be directly provided by the infrastructure’s internal systems via cascaded and interconnected interactions or external service providers.

5.2. Systems Engineering for the Digital Built Environment: The Master Systems Integrator

However, the systems engineering for the digital built environment is covered by the Master Systems Integrator that blends Information Technology (IT) and Operational Technology (OT). These Digital System Integrations via the Information and Communications Technology (ICT) networks include data protocol translations, such as Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), Hypertext Transfer Protocol Secure (HTTPS), Modbus, BACnet, KNX, Dali, and Niagara; data translations such as Extensible Markup Language (XML), Comma-Separated Values (CSV), JavaScript Object Notation (JSON), and Hypertext Markup Language (HTML); and nomenclature translations Brick Schema and Haystack. The role also includes the integration of the systems into a Digital Twin, a mobile app via a middleware layer based on open protocols, and standards integration processes such as RESTful APIS. Finally, the provision of an integrable data storage in a shared but unique data lake sources the single source of truth.

5.3. Systems Engineering in Environmental, Social, and Governance (ESG)

Although the main impact of Environmental, Social, and Governance (ESG) is on corporate leadership and investing criteria, systems engineering also supports ESG by addressing and capturing stakeholders’ requirements and depicting their relationships and interfaces applicable to the infrastructure, thus providing evidence that the asset aligns with ESG and therefore investors and leadership. Concepts such as carbon, resource utilisation, circular economy, human rights, and health and safety can be embedded into the requirements and design iterative processes.

5.4. Building Information Model/Digital Twin in Systems Engineering

The Building Information Model and Digital Twin, as the single source of truth, also support systems engineering. The role of the Digital Twin in the simulation, integration, testing, monitoring, and maintenance stages of the project aligns with the systems engineering activities such as the discovery process of internal and external interfaces, determination of the requirements, and sketching of the system architecture. Furthermore, digital commissioning and the validation and verification of requirements can be embedded in a BIM/Digital twin to streamline the evidence gathering processes. The main current issue of the BIM/Digital Twin is its ownership and governance which needs to be regulated, equivalent to the freehold or leasehold of an infrastructure asset.

5.5. Systems Engineering in Artifical Intelligence

The rapid implementation of AI embedded within the software of the systems raises another dimensional complexity in systems engineering. Traditionally, software outcomes have been elucidated based on cause and effect and repeatable and standardised processes for decision making. AI decisions are dependent on previous learnings under a specific model defined by several parameters. These intrinsic properties make AI easy to evaluate, yet difficult to replicate or compare. The demarcation of responsibilities for the software engineer, software developer, data owner, data custodian, and users still needs to be embedded into traditional legal frameworks or regulatory compliance, although some progress is being already conducted based on explainable AI.

5.6. Artifical Intelligence in Systems Engineering

On the other hand, AI can also support systems engineering in qualitative and quantitative analysis. Rather than starting from the ground up, AI can pre-populate systems engineering from different, previous infrastructure projects embedded into large models. AI can learn and provide templates for the systems engineering interfaces such as interface registers or system architecture for new projects. If systems engineering is deployed in a platform easily integrated with AI, such learning and suggestions can even be made in real-time.

5.7. Blockchain in Systems Engineering

The blockchain, or Distributed Ledger Technologies (DLTs), provides an irreversible record of transactions without the need for a trusted authority or central server. This anti-tampering property makes the blockchain valid in the validation and verification of systems engineering requirements where Smart Contracts provide automatic processes and information being stored in Non-Fungible Tokens (NFTs). Equivalently to the BIM/Digital Twin, the blockchain needs to be regulated with clear demarcations of ownership and responsibility.

6. Conclusions

The qualitative analysis of several UK megaprojects consisting of complex systems of systems has revealed that although integration concepts are included and systems engineering is considered in the design stage, there is no evidence of a methodology to assess possible technical internal and external interfaces and integrations in the business case phase. The National Audit Office already highlights that common causes of project failure or cost overruns include over-optimistic assumptions, technical challenges not recognised, and a limited understanding of interdependencies and related projects. Furthermore, costing models from the business case do not provide evidence that interfaces and integration costs are exhaustively considered and included. Moreover, results from detailed surveys to justify the cost are not publicly accessible. The supply chain could be left with the responsibility to determine and detail technical interfaces and integrations in the design stage, with the potential to add delays and costs to the megaproject, in addition to a bad reputation and social frustration. To mitigate these issues, this article has proposed a systems engineering methodology embedded into the first phase of a project, i.e., the business case: requirements management; interface management; systems architecture; supply chain landscape; and Reliability, Availability, Maintainability, and Safety (RAMS) metrics. This methodology guarantees a thorough qualitative and quantitative analysis in the business case phase to exhaustively consider technical systems integrations, thus guiding risks and costs. For the selected UK megaprojects, the social and economic benefits provided once the infrastructure or asset is built and operational and revenues are collected eventually overwhelm any incurred additional costs, although this cannot be taken for granted for every megaproject.

Future research work will assess the role of systems engineering and digital technologies to expand the whole life cycle of the assets, infrastructure, or built environment products delivered by the megaprojects while reducing their OPEX cost. As business cases balance CAPEX and OPEX costs against operational revenue with an optimistic trend of lower costs and higher revenues, they are perhaps pessimistic about the life expectancy. Assets may last longer than their designed life expectancy and technology can reduce the OPEX, thus finally providing a positive Return on Investment.