Concurrent Engineering Implementation in Design-Build Railway Projects

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].

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.

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

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

   Ts=∑i=1ntiE1

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

Tc=maxti∣i=1,…,nE2

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 = Ts − Tc

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.

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.

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 ts and is continuously modified until the end of the activity. Activity 2 can start at any time between ts and tf. 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.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.

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.