Concurrent Engineering Implementation in Design-Build Railway Projects

Abstract

Design-build as a procurement method is increasingly being used in the design and construction of greenfield rail networks, and that is despite the complexities that characterise rail networks—rail infrastructure projects involves significantly more complex systems such as safety, telecommunications, signalling and electrification. One of the key drivers for this choice of procurement method for the delivery of rail networks is that the design-build contractor commits to an aggressive schedule and implements strategies to enable the works to be completed to time and cost. One of such strategies is the application of concurrent engineering principles to the design and construction works. This Chapter gives an overview of concurrent engineering as applicable to design-build rail projects, focusing mainly on the design as an activity. It identifies factors that impact the application of concurrent engineering as well as mitigations that can be applied for the successful application of concurrent engineering principles in design-build rail projects.

1. Introduction

Rail transportation is perhaps the most dependable form of transportation and thus it is not surprising that over the last decade there has been a steady growth in the number of green field rail projects. This is particularly true in Asia, Africa and the Middle East where new rail networks have been commissioned and new rail networks are being designed and constructed. Railways are complex distributed systems with capital expenditure ranging from a few $100’s million to billions of dollars. Rail projects usually consist of two main disciplines—civil and systems, with the civil component costing anywhere between 60 and 80% of the contract value. It is not unusual for rail projects, particularly transit/metro projects, to engage the services of technical specialist from a variety of technical disciplines such as architecture, landscape, fire and safety, roads, utilities, etc.

The integration of ‘vertical’ construction elements such as stations, parking facilities with ‘horizontal’ construction elements, such as track, bridges, and roadways, creates a need for a comprehensive set of design and construction services that is not normally found in other transportation projects. The nature and specialisation of these components usually requires two different entities to lead the design and construction efforts of each component. However, and in recent times, it is more common to award rail projects as a design and build contract in which the design and build contractor is a consortium comprising civil and system solution providers. Design and Build is a method of procurement in which a single legal entity takes full responsibility and sole liability for both design and construction [1]. The single legal entity may be a multi-disciplinary firm with in-house design capabilities or a consortium capable of providing a total solution. The design and build contractor is liable for all design and construction cost and must usually provide a firm fixed price in its proposal—these are typically lump sum contracts. In these type of projects, the design and build contractor commits to an aggressive schedule and implements strategies to enable the works to be completed to schedule and cost [2]. The design phase of any construction project is cyclic, repetitive and evolutionary involving designers from various design groups such as structural, mechanical, electrical and plumbing, architecture, road works. Often, these designers perceive their design scope with a unique and independent view neglecting the holistic view of the project. It is therefore not surprising that evidence exist that suggest that the design and construction failures originate from this ill-structured design process. It is therefore important that adequate effort must be taken to ensure a robust design strategy is in place from the onset and that all relevant stakeholders buy in the strategy [3]. One strategy implemented to reduce project delivery time is to reduce the design delivery time through the parallelism of sequential activities and it is not surprising therefore that many researchers have explored this aspect [4, 5, 6, 7, 8, 9]. In this Chapter, a synopsis of the application of concurrent design principles and its applications to railway design and build projects is provided.

2. Engineering management

In a typical design and build project, the owner would have undertaken a 30% design effort. This design effort enables the owner to develop specific functional and performance requirements, establish preliminary stakeholder agreements, establish the alignment, secure land requirement, establish the capital cost estimate, minimise residual owner residual risk, etc. The owner’s 30% design is usually supplied as part of the Request for Proposal (RFP)/Invitation To Tender (ITT) on an information basis with some components of the same, such as the alignment, supplied as owner’s requirement. The design and build contractor is expected to complete the 70% design effort through a staged process that includes preliminary, detailed and final design. The completion of these design phases represents major milestones in the design life cycle and thus are typically referred to as design control points. The design and build contractor is expected to have performed a 100% design effort to complete the design delivery. To eliminate rework, it is preferable that design is complete or substantially complete before construction commences, thus an effective management of the design process is crucial to minimise cost and schedule overrun.

The design team is required to complete the design effort in earnest such that construction activities can proceed much earlier. This pressure on design has the objective of reducing the delivery time and minimising delivery cost. This task becomes more difficult as in most cases Systems design tends to follow a sequential progression of plans, specifications and products that are baselined and placed under configuration control. This sequential process, referred to as the Vee Model (also known as Verification and Validation Model), is usually specified in the Contract and mandated by International Standards such as IEC 62278 [10]. Furthermore, infrastructure owners are placing increasing emphasis on quality and reliability as well as the value proposition of the design and build contractor. The ability to deliver to schedule and cost is becoming a major differentiator in railway infrastructure projects.

The parallelism of sequential activities is in effect the application of concurrent engineering principles. There are numerous definitions for concurrent engineering, but the common theme in all such definitions is a holistic approach to product development that considers all life-cycle components and influences from the onset. For the purpose of this Chapter, the following definition by Cleetus [11] and Winner et al. [12] is preferred:

Concurrent engineering as a systematic approach to integrated product development that emphasises response to customer expectations and embodies team values of cooperation, trust and sharing in such a manner that decision making proceeds with large intervals of parallel working by all life-cycle perspectives early in the process.

Concurrent engineering is intended to ensure that contractors, from the onset of a railway infrastructure design-build project, consider all elements of the final system from conception through disposal, including quality, cost, schedule and user requirement [13, 14]. However, the overlapping of design activities may result in serious consequence if not managed effectively. Concurrent design is a holistic design approach that considers the constructibility of the product as part of the design and avoids design changes to enhances its constructibility.

2.1. Design management

The main objective in applying concurrent engineering to design is to reduce waste that may occur in the design cycle and to achieve continuous improvements in the design flow and output. This is achieved by viewing ‘design’ as [15]:

• A transformation of inputs to outputs;

• A process of information flow from one activity to another;

• A process of value generation.

Design is performed by a group of subject matter specialist whose main objective is the transformation of a client’s requirements into outputs that comprise design decisions and actionable design documents. Tzortzopoulos and Formoso [16] identified three perspective of design:

• Conversion: In this view, the design is apportioned into sub-elements and assigned to a specialist who interpreted the client’s requirements and converts the same into design decisions. Deshpande et al. [15] notes the tendency of occurrence of non-value adding components in the design when it is analysed simply as a conversion of inputs to outputs. Deshpande et al. postulated that such occurrence results in an increase in the time to complete design and/or insufficient time to generate optimal design solutions [17].

• Information Flow: Another school of thought, first proposed by Huovila et al. [18], suggest that the design process be viewed in terms of bi-directional information flow from stakeholders to the designers. A key principle of this thought is the identification and eradication of non-value adding activities from the design process.

• Value Generation: This school of thought on design is driven by the desire to achieve the best possible design outcome for the client. Huovila et al. [18] suggest that the process of value generation is dependent on the quality of information available to the designers, as well as the ability of the design team to transform complex, uncertain, and conflicting requirements into solutions that generate value for the client.

Ballard and Koskela [19] argued that it is necessary to integrate the three thoughts expressed above for effective design management. The quality of design can be improved by increasing the quantity and quality of available information with respect to customer needs and requirements. Requirements management in terms of apportionment, assessment, analysis and traceability is therefore a key component of design management. Tzortzopoulos and Formoso [16] provided practical guidelines for the implementation of lean concepts in the design process, these guidelines include:

• Identification and elimination of non-value adding activities in design;

• Increment of output value through detailed assessment of client requirements;

• Reduction of variability in the design process;

• Limiting the approval cycle times for design documents;

• Implementing design freeze and gate review concepts; and

• Establishing meaningful Key Performance Indicators (KPIs) and implementing continuous improvement in the design processes.

The design life cycle is typically separated into four stages – conceptual, preliminary, detailed and final design. Some projects specify a three-stage process consisting of preliminary, detailed and final design—thus for such projects, the initial design effort required represents a 60% design effort. Irrespective of the design life cycle, the Contractor is required, at the onset of the project, to assess and plan the works in terms of work breakdown structure that represents a detailed level at which appropriate reporting and earned value can be assessed [4]. The first step is to break down the design project into appropriate level of detail for budgeting and measuring progress. In this step, the work is broken down to level of details consistent with the requirements for scheduling and determining earned value. In most cases, an experienced rail design-build contractor will implement a breakdown, gained from experience on similar projects, based on an estimated number of design documents to be produced. The output of this first step, among others, is an estimate of the total quantity of design efforts in terms of configurable items (i.e. drawings, calculations, reports, software, specifications, etc) and identification of the design stages at which each configurable item will be delivered. Such a list is referred to as a Document Submittal Register (DSR) or as a Contract Data Requirement List (CDRL). It is acknowledged that the DSR is a live document that is updated throughout the life of the project as the design matures, however in reality attempts are made to freeze the DSR at final design.

The second step is to identify the design interfaces between the design work packages. These design interfaces determine the sequential dependency among design tasks. A matrix may be used to illustrate the dependencies between design work packages and between design tasks. In such a matrix, the columns represent predecessors awhile the rows represent successors. The matrix can be used to identify sequential relationships between design tasks. The third step is to separate the systems into independent groups. This involves grouping objects into homogenous groups, based on a set of common features. The goal of this process is to group dependent systems into manageable packages. The final step is to develop a network schedule, this may be represented using the precedence diagramming method or probabilistically using Programming Evaluation and Review Technique (PERT) [20]. A Graphical Evaluation and Review Technique (GERT) may be used to simulate and assess alternative branches of design activity loops [21].

A sequential design life cycle is illustrated in Figure 1 below. In this life cycle, the development progresses through several defined phases. A detailed review of the differences and similarities between a sequential and concurrent logic is provided in [22].

Figure 1.

Sequential design logic.

This design logic is characterised by a sequential pattern where information about the product is slowly accumulated in consecutive stages. A stage commences only when the preceding stage is completed and has supplied complete and final information. This design life cycle is aligned with systems engineering principles and best suited for the system design component. Each stage must be completed before the next stage begins.

2.2. Concurrent engineering

Concurrent engineering involves reducing the total delivery time and cost of a project by overlapping activities (parallelisation of design activities) that are normally performed in a sequential manner. A core principle of the concept is the need to proceed at risk with an assumption that a specified performance will be obtained from a component, even before that performance has been demonstrated. The risk is managed on the basis of the integrity and certainty of the available information.

The extent of the overlap between two activities depends on the nature of the information exchange between these activities because it is the exchange of information that determines what work can start on the downstream activity. The extent to which two activities can be effectively overlapped depends on the relationship between those activities [22, 23]. Prasad [22] identified four types of relationships that are possible between design activities: (1) dependent activities, (2) semi-independent activities, (3) independent activities, and (4) interdependent activities. For dependent activities, the commencement of a downstream activity is dependent on the receipt of information from an upstream activity. Semi-independent design relationships commence upon the receipt of partial information from other activities. Independent design relationships are characterised by those activities that require no information from another before another activity can start. Interdependent design relationships are characterised by a bi-directional exchange of information between activities before either can be completed [24].

With respect to the identified design relationship types, only independent design activities can be overlapped without the risk of incurring delay or rework. There is an inherent risk in the overlapping of dependent activities. This inherent risk is due to the fact that a downstream activity, in a dependent activity relationship, must commence before all necessary information is available from a upstream activity. Thus changes in the upstream activity that impact assumptions made at the commencement of the downstream activity may increase the severity of the risk of delay or rework. This risk can be mitigated, in part, through increased communication and exchange of preliminary information between the upstream and downstream design activities. In other words, it is preferable not to concurrently design systems that belong to the same package.

2.2.1. Concurrent engineering characterisation

One way that concurrent engineering characterises the exchange of information is through the concept of information evolution of the upstream activity and the sensitivity of the downstream activity or activities to that information evolution [25]. Information and knowledge in an upstream activity can develop rapidly or slowly. For the downstream activity, the sensitivity to changes in the upstream information can be significant depending on the level of rework required. Figure 2 illustrates the concept of a concurrent design logic. While applying concurrent design logic, there are a number of conditions that need to be taken into consideration; the information exchange between a potential overlapping pair of activities, the management strategy used to facilitate the overlap between the pair(s), the likelihood of rework relative to the degree of overlap, and the impact of the rework on cost and schedule. These factors are analysed in the proceeding sections.

Figure 2.

Concurrent design logic.

Concurrent engineering can be viewed as comprised of three basic components:

1. Simultaneity of Activities: In a sequential design flow, the total time, T_s, required to complete the design activity is given as:

   $T_s=\sum _{i=1}^n{t}_i$E1

   In the case of simultaneity of activities, the total time, T_c, required to complete the design activity is equal to the time duration of the activity with the maximum time duration:

   $T_c=\mathit{max}\left(t_i\right)\mid i=1,\dots ,n$E2

   Figure 3 illustrates the time required to execute the design activities in a concurrent design logic. Comparing the time required to complete the design activity in sequential design logic with a concurrent design logic, it is clear that a concurrent design logic offers a time saving of ΔT = T_s − T_c

2. Concurrency: The multifunctional design teams implement design concurrently (i.e. Activities 1, 2 and 3 are performed concurrently by different design teams) and interactively make decisions on works. Simultaneity of design activities without dynamic interaction of the various design teams does not assure concurrency. For example, consider a case of a simple overlapping of design activities in which communication is an acknowledgement of the conditions for commencing a task and those that underpin its completion. True concurrency of design implies interaction between the two activities in order to obtain the best decision, i.e. the two design activities ‘concur’ simultaneously for the best decision through dynamic interactions (communication), or solutions.

3. Simultaneity and concurrency need to occur at the onset or in the early stages of design process to ensure effective implementation of a concurrent design logic.

Figure 3.

Time saving due to concurrent design logic.

3. Factors impacting concurrent design logic

The greatest impact and benefits of concurrent engineering is evident at the design stage. The design decisions made in the early design stages (i.e. conceptual and preliminary design phases) have a significant impact on the constructibility of a product, as between 70 and 80% of the construction cost is determined by design [26, 27]. Thus, cost reduction efforts must be an integral component of the design effort. In the following, we review factors that need to be considered to achieve a successful concurrent design output.

3.1. Information evolution

As previously mentioned, concurrent design logic can be viewed as an information processing system in which individual design activities are modelled as information processing units that receive information from proceeding activities and transform the information received into new information to be passed on to subsequent activities. With reference to Figure 2, preliminary information of the design Activity 1 is available t_s and is continuously modified until the end of the activity. Activity 2 can start at any time between t_s and t_f. Evolution describes the rate at which design information is generated from the start of an activity through the completion of the activity. It is acknowledged that in practise a quantitative assessment of information evolution may be impracticable and thus a qualitative approach is favoured. There are four key determinants of evolution:

• Design optimisation: The level of optimisation performed on design elements or the number of design alternatives evaluated

• Constrain satisfaction: The flexibility of design elements in satisfying constraints

• External information exchange: The amount of information received from or reviewed by external sources; and

• Standardisation: The level of standardisation in the design process and/or design product

Each of the determinants of evolution listed above relies on activity iteration as a determining factor. Design information in those activities with iteration evolves slower than activities without iteration. It goes without saying that an activity without constraint or pressure will evolve naturally and that this natural evolution tends to produce the best design outcome for that activity, however, most design is performed under some constraint, and this is particularly true under a design and build project. Such constraints results in actions that alter the natural evolution of an activity; for example, actions resulting from time constraint may results in the reduction of the time taken to complete an individual activity or a reduction in the overall design schedule.

However, the gains from overlapping must be balanced against the potential of rework (cost and time) which results from the modification of the upstream information. When preliminary upstream information is utilised by the downstream activity too early, future changes may have to be incorporated in time consuming subsequent iterations that result in an increase downstream duration and effort. The amount of rework required, if preliminary information changes, is a function of the sensitivity of the downstream activity to changes in the upstream information.

3.2. Sensitivity

Krishnan et al. [28] qualified sensitivity as a measure of the amount of rework required in a downstream activity as a result of information evolution in an upstream activity. The following conditions impact the sensitivity severity of the downstream activities to changes in upstream information and thus increase the risk of rework:

• The downstream design is near a constraint or boundary;

• The downstream design depends on one key upstream input; or

• The downstream design is integrated such that changes cannot be isolated.

Small changes in the upstream information could result in extensive rework with a major cost and schedule impact to a highly sensitive downstream activity. On the contrary, a low sensitivity downstream activity can accommodate changes in information from an upstream activity such that minimum or no rework is required with minimal cost and/or schedule impact. Bogus and Molenaar [29] identified three determinant factors that influence the sensitivity of an activity:

• Constraint sensitive: The proximity of the downstream design to a constraint or boundary;

• Input sensitive: The level of dependence of downstream design on specific inputs from other activities; and

• Integration sensitive: The ability of the downstream design element to be separated from the entire system.

The combination of an upstream activity with a fast or slow evolution and a downstream activity with a low or high sensitivity results in four possible combinations of evolution and sensitivity. These four possible combinations are major considerations in the assessment of the probability of rework for an activity pair. Roemer et al. [8] and Bogus and Molenaar [29] defined rework as the “increase in time and costs, direct and indirect, that are required to correct some of the work in the downstream activity due to incorrect or changing information received from the upstream activity”. This definition highlights the importance of the need to ensure the integrity of the underpinning assumptions and information flow from the upstream activity.

4. Risk mitigations

The need to commence railway construction activities in earnest serves to meet the aggressive schedule imposed through the contract. These projects, typically structured under International Federation of Consulting Engineers (FIDIC) rules, place the Contractor as the majority owner of associated risk. The design and build contractor therefore needs to put in place adequate processes and control to manage the delivery and in particular the cost. It is beneficial to apply the principles of concurrent design at the commencement of the project, with due consideration of requirement management, design freeze, over-design, etc.

4.1. Design freeze

Eger et al. [30] defines design freeze as a “binding decision that defines the whole product, its parts or parameters and allows the continuation of the design based on that decision”. Design freeze allows structuring and planning of the design process [30]. Freezing a design or key components of a design aims to reduce the likelihood of engineering changes, however, any change required to be implemented after a design freeze may result in high rework cost and potential delays. Design freeze can apply to different stages of the design life cycle. Figure 4 shows a typical design gate review process; it is easily recognised that the logic shown in Figure 4 is a sequential logic, however in reality it is possible to apply design freeze in a concurrent design process to facilitate the early commencement of a downstream activity, however, depending on how it is implemented, design freeze in a concurrent design logic can be viewed as performing the design activities in sequential manner using incomplete preliminary information from upstream activities. In this case, the risk of possible design changes increases with greater degrees of overlap. There are many advantages of the application of the concept of design freeze; it can facilitate the early procurement of long lead items; it can also assist in the reduction of the risk of rework and can set preliminary information from an upstream activity as a basis for further work. Once design freeze has occurred, changes to downstream activities resulting from evolution of preliminary information of the upstream activities needs to be carefully analysed before proceeding. Alternative implementation strategies should be considered and all changes should follow a change control process.

Figure 4.

Design gate review.

4.2. Overdesign

Unlike design freeze, overdesign adds a margin of safety to the design as an attempt to mitigate potential errors in the information flow during overlapping periods. It can be defined as the process of implementing conservative assumptions, in the downstream activity in lieu of incomplete preliminary information transfer from the upstream activity. As an example, one may make conservative assumptions on the required size of technical rooms, while the systems design is still in its infancy, with the view to allow construction of a station or depot to proceed. There is, however, an inherent risk that the margin of safety applied might not be adequate and thus resulting in an underdesign scenario. This may result if the initial assumption is based on previous project experience without adequate analysis and resolution of the current contract’s requirements, particularly those concerning the civil-system interfaces. Such a scenario may result in rework with cost and time impact. There is therefore a balance to be maintained between the robustness and integrity of the underpinning design assumptions and the cost of implementing the design. A trade-off also exist between the degree of overlapping and the certainty of upstream information.

4.3. Standardisation

Standardisation is the process of adopting a design solution to be used repetitively on a project. Such practice speeds up the evolution of upstream activities and enables early information transfer from the upstream activity to the downstream. There is a likelihood of cost increases due to lack of design optimisation. In recent applications of this technique on a design and build project with 22 stations comprising of elevated and underground stations, two archetypes stations representing an elevated and underground stations where processed through design completion and these archetypes acted as the design standards for the remainder of the stations designs. This approach resulted in increased construction productivity. It should be noted that subtle difference between stations—in terms of size, layout etc.—may require additional design effort over and above that established in the standard design. It is to be recognised that standardisation in terms of design processes and procedures further contributes to an increase performance of the construction output and the overall project schedule.

5. Systems design

As mentioned in Section 2.1, the tendency is for Systems design to follow a sequential design logic, partly because of the safety-critical nature that rail systems serves within the railway infrastructure and partly because the systems assurance process forces a sequential logic review. That said, in most design and build projects, the initial delay manifest from the civil design and construction phases. Systems, being the last major component of the Works, therefore are under constant pressure to mitigate the delays incurred from a predominate civil upstream activity. The systems activities under such pressure tend to be Systems installation and Test & Commissioning. The fact that systems design tends to follow a sequential design logic does not exclude the application concurrent engineering to the elements of the systems design. In fact, applying concurrent engineering principles of systems design ensure the timely resolution of interface issues between civil and system. Zhang and Chen [31] demonstrated the successful application of concurrent engineering on the design and fabrication of a rolling stock. The driver for applying concurrent engineering was stated as to shorten product engineering delay, improve locomotive design and capitalise knowledge. Park [32] demonstrated that concurrent design principles can be applied to safety-critical system using a model-based approach. Furthermore, while IEC 62278 implies a sequential logic, ISO/IEC 24748 [33] emphasises that projects should integrate the concurrent design of products and their related life-cycle processes. It goes on to state that ‘concurrent engineering should integrate product and process development to ensure that the product(s) are producible, usable, and supportable’.

6. Conclusion

This Chapter discusses the application of concurrent engineering concept and principles to the design process of a design-build rail project. It is identified that concurrent engineering is a logical approach to achieve a reduction in project delivery time and cost. It is highlighted that the key objective of meeting the desired project duration and cost expectations is through the overlapping of dependent activities. It is noted that overlapping should be approached in a systematic manner to reduce costs and risks. While concurrent engineering is not a term typically associated with design and build rail project, the concept is not alien to the rail construction industry as attempts at mitigating delays, avoiding potential delay penalties and cost overrun due to retrofits and delays always results in an ‘accelerated’ schedule which typically exhibits the application of concurrent engineering logic in what was otherwise a sequential logic. It is highlighted that executing the design activities of a railway design and build project concurrently will result in improvements in quality, time to deliver, cash flow and profitability, etc. It is crucial that the designers, schedulers and planners work together from the onset to develop the project schedule reflective of concurrent engineering logic.