2. literature review 2.1 introduction - wiredspace...

Chapter 2: Literature Review

17

2. Literature Review

2.1 Introduction

Deriving from the research questions and problem statement, a literature review of design

management was conducted. As previously noted, there is very limited research addressing the

design change management issues specifically within the construction project management

context. Newly developed design management tools or systems are not readily available. This

research was conducted based on the available design tools. New updates of the tools were not

available. As stated in Chapter 1, this is the major limitation of the study.

An overview of design and change management in the construction industry is initially done.

This is followed by a comprehensive review into the tools and methods previously developed for

managing design changes. Due to the highly technical nature of the tools, certain portions of the

literature are extracted in order to provide precise explanation of the tools or systems. The tools

and methods are examined in detail because they form the core basis of the research. This

literature review indicates the knowledge gap, therefore underlying the need for this study. The

different tools are examined in terms of their suitability to global collaborative projects and

concurrent engineering projects. The tools are compared taking into consideration their

advantages and disadvantages.

Hao et al (2008) executed an extensive research regarding Change Management in Construction

Projects. The research summarized various aspects of the existing construction change

management processes and provided a comprehensive literature review as well as commentary

on future direction.

The main conclusions regarding critical issues facing project management in the construction

sector that are very different from other industrial sectors are:

1) The team involves multiple players at multiple locations;

2) The construction supply chains are short-term and project based;

3) Different styles of project management and costing systems are used with different

product delivery systems, i.e. ‘design-bid-build’, ‘construction manager’ and

‘design-build’ contracts;

4) Unique needs to manage the involved legal contracts and other related documents

(for example change orders);

5) The scope has extended to the life-cycle operation and maintenance management of

the finished product, in addition to the architect-design-construction process. (Hao et

al, 2008)

It was identified that changes on a project are inevitable at all stages of design and construction.


18

Hao et al (2008) further reinforce this assertion by stating that,

‘changes in construction projects are very common and likely to occur from different

sources, by various causes, at any stage of a project, and may have considerable

negative impacts on items such as costs and schedule delays. A critical change may

cause consecutive delays in project schedule, re-estimation of work statement, and extra

demands of equipment, materials, labour, and overtime.’

It was noted that changes, if not resolved through a formalized change management process, can

become the major source of contract disputes, which is a severe risk contributing to project

failure. This observation is supported by the findings of the problems that have occurred on the

design of the Medupi Structural Steel (Chapter 1).

Motawa et al. (2007) summarized change according to time, need and effect. With regards to

time, it was argued that change could be anticipated or emergent, proactive or reactive or pre-

fixity or post-fixity. In terms of need, change can be effective or required, discretionary or non-

discretionary or preferential or regulatory. Regarding effect, change could be beneficial, neutral

or disruptive.

It has been established that the primary cause of design changes were due to the client and

errors/omissions by the designers (Isaac and Navon, 2008). This is further asserted by Lu and

Issa (2005) who suggest that the most frequent and expensive changes are related to design.

These are usually design changes and design errors.


19

Table 2.1 summarizes stages, sources and impacts of construction changes.

Table 2.1: Summary of

construction changes

STAGE STAKEHOLDER TYPES OF IMPACTS ACTIONS

CHANGES

Specification Owner/Client/ Changes to requirements Changes in design Carefully provide

User or

Architect including specifications, and construction detailed specification

scope of projects, design processes. documents before

brief etc. bidding.

Design Design/ Incomplete/Inconsistent Rework of design Better control of

Engineering drawings; design error/ and drawing; rework design versions,

Consultant defect; design change; in construction; drawings; site

omissions of site change orders. investigation; consider

conditions and build-

ability; Build-ability in design.

changes in codes and

regulations.

Construction Contractor/ As-builts not confirm with Rework; change Quality Control; site

Sub-contractor as-design; quality defect; orders; changes in operational control;

unanticipated site design

coordinated

documents

conditions; value

and drawings; daily

logs

engineering; materials or

equipment not available;

inclement weather.

Source: Hao et al (2008)

Hao et al (2008) identified some of the design management tools and methods that have

previously been developed:

Sun et al. (2006) designed a change management toolkit for construction projects that

includes a change dependency framework, a change prediction tool, a workflow tool, and

a knowledge management guide.

Ipek and Omer (2007) investigate requirement-design relationships and enable traceable

requirement in architectural design. They developed a prototype system called Design

Track and used LEED requirements as a case study.

Lee and Pena-Mora (2005) proposed using system dynamics to build dynamic project

models to assist planning and control of construction projects. This dynamic project

model captures several non-value adding change iterations (rework cycles and

managerial change cycles). The simulation is demonstrated using a case study in Road


20

Bridge Construction, and many change option/policy implications are summarized based

on this case study.

Motawa et al. (2007) presented some preliminary results on proactive change

management through an integrated change management system composed of a fuzzy

logic-based change prediction model and a system dynamics model based on Dynamic

Planning and control Methodology (DPM).

Charoenngam et al (2003) discussed Web-based project management and a Change

Order Management System (COMS) specifically developed for coping with changes in

construction projects. Standard web technologies were used and a change order

procedure involving workflows, roles/actors, documents, records keeping, and a

centralized database were developed.

Recently, Isaac and Navon (2008) have proposed a change control tool (CCT) which

creates requirement traceability through links between client requirements and the

building design. They believe that number of changes or the impact of changes can be

controlled by capturing client requirements accurately at the beginning of the project and

through the requirement traceability that is build up afterwards.

Hao et al (2008) noted that researchers have been trying to resolve change management problems

in various ways apart from the project management domain:

4D or 5D integration which integrates time and cost models in addition to 3D geometry

models. In this way, changes can not only be controlled in the design and engineering

stages in the whole construction process, but also be controlled in the built environment

lift-cycle to some extent. Jongeling and Olofsson (2007) suggest that location based

scheduling provides a promising alternative to activity-based planning approaches for

planning of work-flow with 4d CAD. In this approach, work schedules are integrated

with design models so that changes in design or during construction can be better

coordinated. In the latest 5D technologies of Graphisoft, automation extends beyond

design changes. ArchiCAD also automates and coordinates the creation of documents,

schedules, bills of materials, and quantities estimates through its integrated “virtual

building” model based on IFC‟s BIM models (available at

http://www.vicosoftware.com/).

Data sharing and interoperation. Bakis et al. (2007) proposed an approach to model the

complex interrelations of the different components of the various aspects of the design

and the different versions of each component in order to maintain consistency in

architectural design. When changes happen, the interrelation models help

notification/propagation of version changes.

Web-based integration and collaborative approaches. Lottaz et al. (1999) proposed using

constraint satisfaction techniques to express possible large families of acceptable

solutions in order to facilitate and abbreviate the collaboration and negotiation

http://www.vicosoftware.com/


21

processes, ultimately to improve the change management and the productivity during

phases of design and construction.

By combining Web services and intelligent agents, collaborative workflow technologies

can be used to handle dynamic and complex business processes on the Web and can be

applied to construction project management systems for effective and flexible change

management. In a recent work, a comprehensive literature review of collaborative

workflows in design and manufacturing integration (Hao and Shen, 2007a).

It was found that three kinds of changes are distinguished by researchers;

i. Rework

ii. Change Order

iii. Construction Change Directive (CCD)

(Huang et al, 2007; Levy, 2006)

Figure 2.1 shows the relationship between change orders, reworks, and CCDs.

Figure 2.1: Change orders, reworks and CCDs, Source: Hao et al (2008, p12)

Qi Hao et al (2008) describe the importance of change management as;

a. Seeking to predict possible changes

b. Identification of changes that have already occurred


22

c. Planning of preventative measures

d. Coordination of changes across the whole project

(Hao et al, 2008)

The above description clearly illustrates the need for effective change management on the

Medupi project. This description provides a basis for the analysis of the design management

tools and methods. It was used to analyse the design management tools/methods described in this

chapter.

It was found that an integrated solution for coordinating design is required for development of an

effective change management process.

The following section describes previously developed tools which could be applicable to

complex and global projects.

2.2 Design Management Tools/Systems

One of the objectives of the study is to establish which design management tool or system would

have effectively managed the design changes on the Medupi project or future similar global

collaborative projects. It has been noted that none of the design management tools/systems were

developed specifically for global collaborative projects. The following previously developed

design management tools or systems were analysed and compared according to their suitability

to Medupi or other similar global collaborative projects;

Managing Design in the Extended Enterprise (Cooper et al, 2007)

Analytical Design Planning Technique – ADePT (Austin et al, 2000)

Integrated Collaborative Design (Austin et al, 2007)

DePlan (Choo et al, 2004)

Web-based Design Interface Management System – diMs (Senthilkumar et al, 2009)

The above tools/systems/processes were carefully selected due to their ability to manage

complex projects. The goal was to select which of the tools would have been likely to manage

the magnitude of design changes on the Medupi project or similar projects.

Based on the problems identified in Chapter 1 regarding design management issues on the

structural steel component of the works on Medupi, each of the design tools/processes was

assessed according to requirements for successful delivery of the project. Below is a hypothetical

listing of ideal requirements for a management system that could enhance and accomplish the

desired objectives, developed for this study. This criterion was used for assessing all the tools.


23

Detection of Change

One of the critical components of the desired design management tool is the ability to detect

change. This allows for prompt response to the design change as well as planning for

incorporation of the change.

Prediction of Change

The desired tool should be able to record historical design data in order to be able to predict

forthcoming design changes.

Plans Preventative Measure

Continuous design changes have proved to be very disruptive on the Medupi project. The desired

tool should be able to put preventative measures in place for future design changes.

Coordinate Changes Across Project

As previously stated in Chapter 1, the design, detailing, fabrication and erection of the structural

steel at Medupi is a very complex process. It is imperative for the tool to be able to coordinate

the changes across all these processes.

Provides Impact Analysis

Depending on progress of the different processes (design, detailing, fabrication and erection),

design changes will have an impact on time, cost and quality. The tool should be able to provide

an impact analysis on the project in terms of time, cost and quality prior to effecting the required

changes.

Provides Post Change Analysis

This analysis is required in order to assess the impact on time, cost and quality post effecting of

the design changes.

Provides Changes Traceability

The tool should be able to provide the source of the design change.

Plans Design

Multi-disciplinary engineering projects (Civil, Structural, Electrical & Mechanical) require a tool

that can plan and coordinate the design process.


24

Schedules Design

The tool should be able to schedule the design process. This enables clarity on information

requirements at different stages.

Controls Design

The design process needs to be continuously monitored and controlled. On a global collaborative

project, this has proved to be a difficult process. The tool should be able to provide a controlling

and monitoring of design feature.

Applicable on Complex Projects

The Medupi Power Station is a multi-disciplinary engineering project. The tool should be able to

handle all the complex processes associated with the project.

Enhances Performance

The tool should add value to a project in terms of ensuring completion of the project within the

constraints of time, cost and quality.

Reactivity Enhancing

The tool should be pro-active in terms of managing the design changes. Continuous updates for

all designers should be readily available in order to keep all informed.

Limits Impacts

The tool should be able to reduce the time, cost and quality implications of the design changes.

Early detection of the changes is critical in ensuring this occurs.

Requires Physical Interaction of Teams

It was imperative to establish whether the tools required physical interaction of the different

disciplines due to the fact that the project is a global collaborative project.

Web-Based System

Global collaborative projects require communication all across the world. This is a critical

feature of the desired tool.

Software Based

It was important to distinguish whether the tool was based on a software or is a manual tool.


25

2.2.1 Managing Design in the Extended Enterprise

Cooper et al (2009) conducted extensive research in design management using examples from

construction and manufacturing sectors. A process protocol for effective design management was

developed. This process protocol was developed specifically for the construction industry in

order to show how quality can be achieved in an extended enterprise (Cooper et al, 2009). The

process protocol illustrates how designers operate in organizations and through the supply chain

in order to achieve innovation and better quality design.

Development of this tool specifically for the construction industry makes it relevant to this study.

The process is described below and will be further analysed to assess its suitability to Medupi

and similar projects.

2.2.1.1 Planning, Scheduling & Controlling of Design

A new product development process (NPD) was developed by Crawford (1992). The main

objective of the new product development process was to get the correct product to the market or

customer as soon as can be reasonably expected. The new product development process is made

up of different activities (Crawford, 1992). Crawford argued that,

„Initiated by the identification of the need or adoption of an idea, a number of

technical, financial and business preliminary evaluations, further detailed

technical development follows, and finally the finished product after a series of

company and market tests is launched onto the market (Crawford, 1992).

Design is the centre of the new product development process. This makes this process critical to

this study. New product development activities are separated into three categories (Cooper and

Kleinschmidt, 1995).

Predevelopment activities: idea generating/establishing the need followed

by a number of preliminary market, technical, financial and production

assessments.

Development activities: physical development of the product.

Post development activities: final launch of the product into the market

place.

New product development models are also classified into three main streams;

i) Sequential

ii) Overlapping

iii) Stage gate (Cooper and Kleinschmidt,1995)


26

Cooper et al (2009) argue that it has become apparent in the last two decades that there is a need

for change from a sequential approach to a more non-concurrent one, where the manufacturing

function had to be integrated into the design function. This was to improve the coordination and

communication in the project (Cooper et al, 2009).

The new product development process has changed and improved into a complicated ‘coupling’

model (Tidd et al, 1997). Cooper’s (1990) new product development process stage gate model,

illustrated below, gained acceptance (Figure 2.2)

Figure 2.2: New Product Development (NPD) State-gate model, Source: Cooper et al (2003)

The stage-gate process led to optimized internal resources, reduced development time and

produced marketable results (Anderson, 1994). The stage-gate process requires variable tasks to

be checked off against predetermined lists. This process allows for a higher degree of

understanding of the project process and for better control. The process however, was found to

be cumbersome and slow (Cooper and Kleinschmidt, 1995). This was further reinforced by

Devinny (1995) who noticed that projects had to wait at each gate until such time that all tasks

were completed. This prevented progression of all projects as well as overlapping of activities.

In order to avoid delays and enable better progression, newly developed ‘parallel’ processes had

to be sought to ensure overlapping of tasks during the new product development process program

(Cooper, 1994). The main features of the new process were the overlapping of tasks. The

structural steel component of the Medupi project has many design tasks which require

overlapping. This reinforced the relevance of the process to the study.


27

Manufacturing organizations commonly use a version of the new product development process

as a means of managing an integrated design and production team. The new product

development process requires development in order for stakeholders to understand their

contribution in terms of design decision making. This is due to the fact that it now exists in the

extended enterprise (Cooper et al, 2009). The process protocol model provides an integrated

design and innovation in the extended enterprise by bringing together a process with clearly

defined stages, people skills and technology.

2.2.1.2 Enhancement of performance (time, cost & quality), Coordination of Changes

across Project

Cooper et al (2009) argue that in order to achieve successful design management, design quality

requirements must be established so as to understand the product portfolio. A system for

procurement of designers must be decided. This should be done in order to facilitate access to

knowledge and technology.

Cooper et al (2009) make recommendations for a coordinated design and construction process.

Eight key principles are set out below (Table 2.2). The process illustrates the relationship

between design management and production activity as well as the link between all key

activities. This process allowed design quality standards to be developed early in phases zero to

three when the stakeholder requirements are considered together with the business case when the

feasibility is reviewed. The total requirements of the work should be understood in the first three

phases so at to enable the quality aspect to be communicated throughout the project and be

assessed and reviewed at the stage-gates throughout the whole process (Cooper et al, 2003).

Table 2.2: Process protocol: eight key principles for a generic design and construction

process

Whole process view: has to cover the whole 'life' of the project

Progressive design fixity: adopting the 'stage-gate' approach

Consistent process: generic properties and allows performance measurement

Process flexibility: enabling the alignment of the project process to existing business

and operational processes

Customizable: ability of the process to be customizable to manage projects and get

team buy-in

Stakeholder involvement/teamwork: right people at the right time

Feedback: continuous improvement and legacy archive

Source: Cooper et al (2003)


28

Based on the hypothetical ideal requirements of a design management tool for global

collaborative projects, table 2.3 below is a summary of the findings from the literature review.

The assessment was based on the available literature discussed above.

Table 2.3: Managing Design in the Extended Enterprise Process Breakdown

YES NO

Detects Change X

Predicts Change X

Plans Preventative Measure X

Co-ordinates changes across project X

Provides Impact Analysis X

Provides Post Change Analysis X

Provides Change Traceability X

Plans Design X

Schedules Design X

Controls Design X

Applicable on Complex Projects X

Enhances performance (Time, Cost & Quality) X

Reactivity Enhancing X

Limits Impacts X

Requires Physical Interaction of Teams X

Web-Based System X

Software Based X


29

2.2.2 Analytical Design Planning Technique (ADePT): a dependency structure

matrix tool to schedule the building design process

The Analytical Design Planning Technique (ADePT) is a planning technique which was

developed by Newton (1995) to overcome variation difficulties in the design process. This tool

allows for effective planning and management of the design process.

2.2.2.1 Detecting Change, Coordination of Changes Across project, Planning of Design,

Scheduling of Design & Controlling of Design

The below literature describes in detail how the ADePT tool detects change, coordinates changes

across a project, plans, schedules and controls design.

The central part of ADePT is a dependency structure matrix (DSM). This section describes in

detail the DSM techniques and tools developed to optimize the design process. The dependency

structure matrix (DSM) is the basis of most of the tools that were analysed in the study.

The methodology comprises of three stages;

1. A model of the building design process which represents design activities and their

information flows (inputs and outputs). The design deliverables (calculations, drawings

and specifications) are produced directly or indirectly by the activities. The information

takes the form of design data (Austin et al, 2000).

2. The data in the first stage of the methodology are linked via a table showing the

activities’ dependence on information, to a dependency structure matrix (DSM) analysis

tool. The dependency structure matrix is used to identify iteration within the design

process and schedule the activities, with the objective of optimizing the task order.

3. Design programmes based on optimized process sequence are produced.

This technique requires iteration between the DSM and programming stages. The complexity of

the Medupi project as well the number of design activities in the project mean that the ADePT

methodology was relevant to the study. Further analysis of the tool establishes its

appropriateness to the project.

Steward (1965) developed a theory about design which states,

„a complex problem such as design could be solved more efficiently by representing the

interrelationships between activities in the form of a matrix which could then be used to

decompose the problem, thus establishing the contributing sub-problems.‟


30

The technique was termed the design structure matrix by Steward (1965). Due to the application

of the technique to other problem besides design, it is now known as the dependency structure

matrix (Browning, 1997).

The dependency structure matrix is explained below with the use of a simple example (Figure

2.3a)

„The problem contains 20 activities which are listed arbitrarily down the left hand side

of the matrix. The same activity order is listed across the top of the matrix. An

assumption is made that the activities are undertaken in the order in the order listed

within the matrix, starting from the top left hand corner and finishing in the bottom right

hand corner.

Each mark in the matrix indicates that the activity on the left hand side is dependent

upon the activity at the top of the matrix. This means that, in the assumed order of

activities, a mark below the diagonal shows that an activity is dependent on the

information which has been produced by a previous activity, whereas a mark above the

diagonal indicated that an activity is dependent on information yet to be produced.

This can be overcome by estimating the information that is as yet unavailable and then

verifying the estimate once the information generating the activity has been undertaken.

For example, in Figure 2.3a it can be seen that activity E depends on some information

from activity L that at the time has not been undertaken.

If this information is estimated, activity E can be carried out then activity L, following

which the estimate can be verified. It may be that the activity dependent on the estimated

information (activity E) has to be redone if the original estimate was not accurate,

resulting in an iterative loop of design activities. In this case it involves at least 8

activities (E to L) but possibly up to 15, as activity L in turn requires an estimate of

information from activity S (hence the shaded block of tasks).

The need to estimate information and then carry out activities more than once results in

any process being inefficient. It is desirable to reduce the need for estimates and

therefore iteration within the process. This is achieved by reordering the activities within

the matrix so that the marks are below the diagonal or as close to it as possible, thus

producing the optimal sequence of activities, a feature that is not guaranteed when using

network analysis (Alkayyali et al, 1993).‟


31

A B C D E F G H I J K L M N O P Q R S T

Task A X Task B X Task C X X

Task D X

X Task E

X

X

Task F

X X

X

X Task G

X

X

Task H X

X

Task I

X

X

Task J

X X

X

Task K

X

X

Task L

X

X Task M

X

X

X

Task N

X

X

X

Task O

X

X

Task P

X X

Task Q

X

X

Task R

X Task S

X

Task T

X

Figure 2.3a: Partitioning a matrix, Source: Austin et al, 2000

‘The process of reordering the matrix is called partitioning. In this case (Figure 2.4b) it

can be seen that activity E is now in a smaller loop of only five tasks, significantly

reducing the amount of potential repetition.’


32

A B C D G J L E I S O M Q R T P F H K N


Task D X

X Task G

X

X

Task J

X X

X Task L

X

X

Task E

X

X

Task I

X

X

Task S

X Task O

X

X

Task M

X X X Task Q

X

X

Task R

X Task T

X

Task P

X

X

Task F

X X

X

X

Task H X

X

Task K

X X

Task N

X

X X

Figure 2.3b: Partitioned Matrix, Source: Austin et al (2000)

Austin et al (2000) suggest that the purpose of partitioning a matrix is the maximisation of

available information and minimisation of the amount of iteration and size of any loop within a

process. The number of dependencies above the diagonal are minimized using the process.

The above figures illustrate this process. Figure 2.3b shows a partitioned version of Figure 2.3a.

The sequence is therefore altered leading to four iterative loops. The presented process means

that some information estimates have to be made.

„Partitioning can be achieved through the employment of a technique called path

searching (Steward, 1981) or through the application of a mathematical system such as

Boolean algebra (Ledet and Himmelblau, 1970), a knowledge based expert system


33

(Rogers, 1989) or a generic algorithm (McCulley and Bloebaum, 1994; Rogers et al,

1996).‟

Activities that do not contribute to the iterative loops are sequenced through partitioning.

Activities that are within iterative loops are indicated but are not sequenced. This is due to the

fact that activities that are in the loop are interrelated, therefore any of them can be undertaken

first in the completion of the loop. The activities within a loop must be ordered to reduce the

number of activities that must be made. This represents a further process known as tearing

(Austin et al, 2000).

„Tearing a loop means reducing the size of the iteration by minimizing feedbacks and

identifying estimates that can be made with some confidence and that therefore do not

need to be revisited as part of the iterative process.‟(Austin et al, 2000)

Tearing a loop comprises of two stages;

1. Scheduling of activities within the loop to reduce the number of estimates that are

required and to identify a starting point for the commencement of the loop.

2. Removal of one or more information dependencies in order for the size of the loop to be

reduced.

„Rogers‟ knowledge-based heuristic approach to tearing results in the removal of

dependences on the basis of an algorithmic calculation which determines which

dependences are most responsible for causing the loop.

The shunt diagram method results in a series of suggested tears and a weighting of their

effectiveness in reducing the size of the iteration; however, a decision is required by the

user before a tear is made. This second approach means that knowledge of the problem

is required by the user; here a more meaningful analysis of the problem is usually

achieved because an assessment is made regarding the feasibility of each tear based on

practical experience‟ (Steward, 1993).


34

A B C D G J L E I S O M Q R T P F H K N


Task D X

X Task G

X

X

Task J

X X

X Task L

X

X

Task E

X

X

Task I

X

X

Task S

X Task O

X

X

Task M

X X X Task Q

X

X

Task R

X Task T

X

Task P

X

X

Task F

X X

X

X

Task H X

X

Task K

X X

Task N

X

X X

Figure 2.4: Two Loops, Source: Austin et al (2000)

As noted in Chapter 1, the Medupi Power Station is the biggest construction project ever

undertaken in South Africa. This is the most complex project ever undertaken. On such complex

projects, Austin et al (2000) notes that there many information dependences between activities in

design. As illustrated in the above figures, the resulting matrix is clarified by determining the

levels of information importance and strength of dependence. This is achieved through

classifying the dependences within the matrix and using a partitioning algorithm that can

prioritize the sequencing of activities on the basis of these classifications (Austin et al, 2000).

Classifying information is similar to tearing a loop, the difference being that classification is

carried out prior to the production of the matrix. To achieve manageable-sub problems, the

highly complex design process of the Medupi Power station can be decomposed through further


35

tearing. This is done after classification of information in the matrix. Due to the highly subjective

exercise of classifying information in a matrix, a number of scales aimed at classification of

information in a dependency structure matrix (DSM) have been devised (Austin et al, 2000).

„Rogers and Bloebaum (1994) advocate the development of a seven-point scale of design

information dependence strengths which can be either determined subjectively by a

design manager or calculated by an algorithm. Smith and Eppinger (1993) give details

of alternative scales, one with a percentage weighting and one with a three-point scale

of dependences in iterative loops to indicate the probability of a dependence

contributing to the iteration.

2.2.2.2 Change Traceability, Complexity of Projects, Performance Enhancement,

Reactivity Enhancing, Software Based & Impact Limitation

Austin at el (1996) describe a three-point scale of classifications based on the strength of

dependence of information, sensitivity of activities to changes in information and the ease with

which information can be estimated.

1. The first stage of the methodology in ADePT entails containment of the information to be

represented and analysed by DSM in the design process model. The model database is

formatted in order to ensure that it is compatible with the DSM tool.

2. In order for the dependency structure matrix (DSM) tool to prioritize dependences while

partitioning the matrix, classifications are allocated to the information flows in the model.

3. An appropriate means of rating information within the process is achieved through a

three-point dependence classification system.

Figure 2.5 below illustrates the three-point dependence classification system.


36

Figure 2.5: 3 Point dependence Classification, Source: Austin et al (2000)

Austin et al (2000) further reinforce the above assertions by stating that the system of

information classification depends on three factors;

i) Strength of information dependence

ii) Sensitivity to change of information

iii) Ease of estimating information

Designers therefore have to make three separate subjective judgements. The resulting

classification is given a rating of A, B or C (where A=strong...C=weak). According to the

ADePT methodology, weak dependences (classified C) can be removed from the matrix

partitioning resulting in a reduced loop and clarified design process (Austin et al, 2000).

Austin et al (2000) validated through interviews with designers, information classifications. A

likely range was used were classifications could not be determined. Classifications are then

tabled according to dependence. Classifications and dependence tables must be re-evaluated in

order to be project specific.

As part of the ADePT process, the Medupi Power Station dependence table and classifications

would have to be evaluated specifically for this project. The responsibility of the main design

contractor (Hitachi Power Europe) and sub-contractor (Murray & Roberts) are outlined in

Chapter 1. The information would have to be classified and a dependence table drawn up. This

information would then have to be formatted and imported to a dependency structure matrix

(DSM) tool in a matrix form.


37

The DSM analysis of the Medupi Power station would yield a large iterative lope due to its size

and complexity. The iterative loop would have to be broken down into manageable sub-

problems. This would have to be achieved through tearing the loop. Information would have to

be classified. Necessary information would be established leading to some of the information

being estimated. The estimation would have to incorporate a margin for error. This margin for

error prevents re-design at a later stage. Austin at el (2000) found that a design process can be

broken down to between 7 and 12 iterative loops each consisting of between 5 and 30 related

tasks.

The effects of tearing an information dependence on a large design project like Medupi would

prove difficult to determine due to the large number of tasks and interrelationships. In order to

understand the interrelationships between tasks more easily, the dependency structure matrix

(DSM) would have to be viewed at a higher less detailed level.

To achieve this, information from the dependence table would have to be imported to the

dependency structure matrix (DSM) tool in a manner that groups the very detailed tasks in the

model under the headings of systems and elements of the building (Austin et al, 2000).

According to Austin et al (2000), this will result in manageable activities, each corresponding to

a system. This will lead to an easily interpreted matrix, whereby effective tears can be

determined. Information dependencies can then be identified through the analysis, which can be

torn in the matrix containing detailed task information.

The optimal sequence of activities and their information dependencies can be determined

through a partitioned matrix. The ADePT methodology can also assist in the planning of the

design phase. Information in the matrix can be represented on a program whereby duration of

activities is assigned and indicates clearly where tasks can be undertaken in parallel. The

planning software used on the Medupi project for design in the PRIMAVERA software. Data

from the matrix can easily be transferred to this software. Austin et al (2000) reinforce this

assertion by stating,

„Analysis to date has shown that the iterative loops within matrices relate to design

coordination issues, such as ceiling, underground services and perimeter structure

coordination. The formatting of information in a matrix prior to its representation on a

program accounts for the iteration in the process and ensures that tasks in a loop are

programmed to be undertaken concurrently so that coordination can be achieved (Austin

et al, 1996b).

All stages of ADePT have been validated through their application to a series of design

projects, full details are published elsewhere (Austin et al, 1999a, b). Within the DSM

stage of methodology, Algorithmic Matrix Manipulative Program (AMMP) has been

tested on projects (Table 2.4) covering values from 16 million pounds to 35 million

pounds. The output has been generated, and the ease with which ADePT has been


38

utilized, indicate that the technique can be applied within an acceptable timeframe.

Currently, a hospital project is being examined, involving a design process of around

800 tasks and 10 000 dependences.

The first three projects had been designed recently, and the output from the DSM tools

and corresponding design program were compared with the planning that was

undertaken in practise. This has shown that the latter did not take full account of the

iteration within the design process, and that the design had been planned almost entirely

to suit the construction process. Design related problems on site are being reviewed

currently, and work is being undertaken to determine whether these problems could have

been avoided through effective planning with ADePT.‟

Table 2.4: AMMP Tests

A B C D

Pharmaceutical Railway Office Hospital

Laboratory Terminal Development

No. Of Design Tasks 410 357 346 789

No. of Information Dependencies 2406 2804 2656 10015

No. Of iterative loops after tearing 14 14 7 19

Proportion of tasks in loop 29% 18% 18% 29%

Hours to Generate: Model 16 28 12 32

Matrix 20 20 16 40

Programme 28 24 24 40

Source: Austin et al (2000)

ADePT is continually being improved and tested. It has previously been applied to the design of

a hospital to determine potential areas of iterative work, coordination issues and demonstrate

requirements for estimating information prior to detailed design. Results have shown that the

time and effort required to develop a matrix are not excessive. The results have also indicated

that the output from the matrix is a useful means of understanding the design process across a

project (Austin et al, 2000).

The objective of this study is to determine a design management tool that can effectively manage

changes on a global collaborative project. From the literature, it has been determined that ADePT


39

has not been tested on a global collaborative project. The premise is to determine based on the

features of the tool whether it would work.




Table 2.5: ADePT: Analytical Design Planning Technique Tool Breakdown

YES NO

Detects Change X

Predicts Change X






Plans Design X

Schedules Design X

Controls Design X




Limits Impacts X


Web-Based System X

Software Based X

2.2.3 Integrated Collaborative Design

Austin et al (2007) conducted extensive research describing an approach to managing the supply

chain from the perspective of design which is referred to as Integrated Collaborative Design

(ICD). Building on a substantial program of research using a range of methodologies, the

concept of a design chain is described. The argument is made that the industry needs to centre

the development of integrated teams around collaborative working of all parties involved in the

design process.


40

2.2.3.1 Complexity of Project, Enhancement of Performance (time, cost & quality),

Physical Interaction of Teams

As previously stated in Chapter 1, Medupi is the most complex project undertaken in the South

Africa. Austin et al (2007) concluded that delivering complex products requires adeptness.

Delivery of a project requires relationships between many organizations and thousands of

processes. Many methods have been developed to accommodate the complexity of construction

projects, with the evolution of many specialized roles and relationships. These relationships are

controlled by means of contracts.

It was found that design, that part of construction that needs to take place before the physical

work can begin, is still not a well understood or properly managed area. The complexity and size

of projects contributes to this. Design is performed at a particular time in a project by different

parties. Integrated Collaborative Design (ICD) is a method of managing design through

understanding how design activities are dispersed through the supply chain and how these

activities can be integrated across organizational and functional boundaries (Austin et al, 2007).

The complexity of design in its management and performance are reflected by understanding

methods of managing business and project relationships. Customer satisfaction can then be

improved and sustainability of the construction industry can be promoted.

Customers demand that the industry improves project delivery and that it should learn from best

practice, not only within construction, but also from other industries. Austin et al (2007)

reinforce this assertion by stating,

‘One approach is to build “design chains”. Design chains provide a conceptual tool for

construction companies to understand and collaborate with each other to develop and

propagate sustaining relationships that accommodate design process complexity. The

collaborative development of project design information is an appropriate basis upon

which to build these relationships.‟

This further highlighted the need for improved design management as a means to improve the

construction industry’s ability to respond to the needs of its customers.

‘the development of design management in construction (and other industries) has been

hindered by the intuitive and iterative nature of the act of design. This makes it difficult

to model, plan, and manage design in the same way as more sequential processes such

as those concerned with the physical movement of goods or materials (Austin et al,

1996).‟

‘More sophisticated techniques and improved understanding are now being applied to

the management of design. In recent years, for example, techniques derived from

process-mapping research (Austin et al, 2000; Choo et al, 2004) have introduced rigor


41

to decision making in design planning previously restricted to other parts of the

process.’

New tools (Choo et al, 2004; Thompson et al, 2006) facilitate the use of design chains to

structure management of design processes that span organizations which, in turn, can optimize

the total design solution in the same way that supply chains have optimized the delivery of goods

and services.

„Based upon the understanding or organization relationships associated with the

overarching design process, Integrated Collaborative Design (ICD) provides a

framework for collaborative working which is populated with a series of new and

existing design management methods. ICD can help organizations integrate, helping

them achieve more together. Innovative approaches of this nature are required to meet

the demands of customers who are beginning to view construction as another complex

process (similar to those they manage themselves) requiring efficient and effective

management‟ (Austin et al, 2007).

Austin et al (2007) realised that, the growth in specialization and complexity of construction

methods and technologies has led to more fragmented design and construction processes. The

number of organizations and individuals with design responsibility within construction projects

has increased due to this specialisation. This is especially true on the Medupi project. Medupi is

a very specialized project. Eskom specifically appointed Hitachi Power Europe due to their

experience and expertise in delivering power stations. According to the Integrated Collaborative

Design (ICD) method, processes need to be distributed across and integrated team of designers,

which will lead to effective management of design.

The research points out that when individual members of project design teams are distributed

across different companies, a key challenge in design management is to manage the relationships

between them. It has been observed that one of the problems in construction which often lead to

dispute is organizational interfaces. Integrated Collaborative Design (ICD) addresses this issue.

Austin et al (2007) argue that, small firms with limited skill bases have to content with a great

variety of contractual arrangements and inter-firm relationships due to the tradition of single

design disciplines. Integrated design should be achieved easier when multidisciplinary firms or

teams are involved. However, departments develop their own values and objectives which may

differ from those of the company. Design management can be used within organizations to

optimize information flow between functional groups and design disciplines. Different creative

cultures that exist between organizations can be united. Successful delivery of project requires

improved design management. Austin et al (2007) identified four key areas that require attention

when integrating across organizations.


42

They are the need to:

(1) Identify individual design tasks and relationships between them;

(2) Allocate responsibility for completing design tasks to organizations on the

basis of who is best placed to perform them (judged by technical

competency and commercial capability);

(3) Manage the smooth exchange of design information between collaborative

partners; and

(4) Create working environments that aid the delivery process, such as

networks of compatible organizations with shared values, cultures and

ways of working.

The Integrated Collaborative Design (ICD) framework addresses the above issues within design

management. Austin et al (2007) structured this framework around three principles which

provide a foundation for an organization’s practice of Integrated Collaborative Design (ICD) and

to provide the premise for application of the various practises that allow ICD to be adopted as an

approach to design management.

Managing design using the ICD framework is thoroughly described below. This determines the

suitability of the method to Medupi and other similar global collaborative projects.

2.2.3.2 Planning, Scheduling & Controlling Design

Austin et al (2007) summarize the Integrated Collaborative Design:

‘Within the operating culture of a single organization, the use of ICD to

structure design management is divided into two domains (the business and

the project) and into two roles (provider and receiver).

The ICD practices encapsulate many of the findings and outputs of research

project underpinning ICD in the form of advice, approaches, tools and

techniques. These practices are categorized into strategies, tactics and

operations:

ICD strategies help organizations plan their development of ICD practice.

ICD tactics help organizations establish the working methods and

resources required to respond to their strategic goals.

ICD operations guide organizations in their integration of ICD in their

everyday activity.

The above practices apply regardless of whether the practice occurs in the business domain or in

the project domain, or whether used by a provider or receiver of design solutions.


43

2.2.3.2.1 The business and project domains

Austin et al explained the business and projects domains as,

„ICD business domain operations comprise the ongoing activities of organizations that

give them structure. They span projects and establish the company in the market. Project

domain operations, on the other hand, are temporary and occur when individuals and

other resources come together to deliver individual projects. Examples of business

domain activities include employee training, managing long-term customer relationship,

maintaining alliances, business development and quality assurance. Examples of project

domain activities include project management, value management and quality control‟


Separating business and project domain is a difficult exercise. The views that organizations and

individuals have of what they do define the business and project domains. Due to the

construction being very task-focused, managers and designers tend to focus on project details

instead of the organizations wider business. Public private partnerships have contributed to

organizations seeing major projects as separate business units.

Integrated Collaborative Design emphasises the importance of relationship planning and

management in the business domain. ICD highlights the importance of viewing a business in

terms of delivery of projects as an ongoing operation rather than delivery of individual projects.

The nature of the organization defines the business domain activities. In larger organizations,

staff is responsible for specific processes.

Austin et al (2007) suggest that a balance need to be struck between organizational relationships

formed in the business and project domains. Working together of organizations on projects leads

to the forming of relationships, therefore being managed as a function of the project domain.

This however leads insufficient consideration being given to managing and sustaining long-term

relationships in the business domain. This depends on personal relationships between

individuals.

The Integrated Collaborative Design (ICD) brings structure to maintaining long-term

relationships between organizations. Methods of capturing, filtering and maintaining information

about potential business partners are rarely developed beyond databases of personal

relationships. Weak feedback is provided in business domain relationships by project domain

relationships. Integrated Collaborative Design deals with this issue by allowing business domain

relationships to drive project domain relationships. This is achieved by establishing the

capability and performance of business partners prior to the commencement of a new project.

Austin et al (2007), found that the processes used by organizations remain constant in the project

domain, regardless of the type of project. The main focus is usually program management,

procurement, document control and resources. These processes have been extensively described


44

and modelled by initiatives such as the Royal Institute of British Architects’ (RIBA, 2000) plan

of work and the process protocol (Kagioglou et al, 2000). The plan of work and process protocol

(Kagioglou et al, 2000) established a project process map to be used a framework to structure

language and common process between collaborators. This allows for better understanding

between organizations through a good project management framework. Austin et al (2007)

reinforce this assertion through recent work that has used the process protocol such as T5

(Heathrow airport terminal) (Austin et al (2007).

The literature indicates that Integrated Collaborative Design (ICD) provides a framework for

management of the design process. This fact makes it very relevant to the study due to the

problems outlined in Chapter 1. ICD provides a solution to design management problems

through techniques such as mapping the flow of design information at the project level, while

also nurturing business environments compatible with value-adding collaborative work.

Integrated Collaborative Design allows design chains to be established which provide a stable

environment around projects and contributing to successful delivery of projects.

As previously stated in Chapter 1, the Basic Engineering of the structural steel was done in

Europe by Hitachi. Murray & Roberts did the connection design and detailing. The premise of

the study is to establish whether a more collaborative approach such as the Integrated

Collaborative Design would have led to better design management.

2.2.3.2 Planning of Preventative Measure, Change Traceability & Coordinating changes

across project

Austin et al (2007) establish three principles that lie at the core of ICD;

i.) To identify tasks – applying process management

ii.) To allocate roles – adopting Supply Chain Management (SCM) practices; and

iii.) To focus design solutions and to hone process management – establishing value

frameworks.

Successful delivery of a project is achieved through these principles. The first two principles

support the third. Application of these principles in sequence, build a common understanding

among individual members. In order to achieve success, organizations need to integrate these

principles when working in a collaborative environment. The principles guide the application of

all other elements of Integrated Collaborative Design.

Austin et al (2007) argue that by adopting the above principles, an organization can implement

an Integrated Collaborative Design approach. This will allow the organization to;

Use design process modelling to understand design information flows and

allocate design tasks between collaborating organizations appropriately;


45

Build on its process models by establishing supply networks to group

together organizations of known technical competency and allocate design

responsibilities among them; and

Integrate the processes of organizations within a supply network to build a

value system (Austin et al, 2007).

The Integrated Collaborative Design allows organizations to focus on improving their ability to

perform design by improving their business. This is done instead of introducing improvement to

one project then adding and implementing the same principles on the subsequent projects. Austin

et al (2007) have produced a handbook for applying the three Integrated Collaborative Design

principles. This handbook is intended to help organizations implement the ICD principles. The

handbook includes,

„25 practices developed through the various research components and

reported elsewhere (Austin et al, 1996, 2000; Choo et al, 2004; Root et al,

2004; Thompson et al, 2003, 2006) that can be used to structure an

organization‟s introduction of the ICD principles into their everyday work‟


Figure 2.6 below shows the relationships of the three Integrated Collaborative Design principles;

Figure 2.6: ICD Principles, Source: Austin et al (2007)

Austin et al (2007) found that the adoption of Integrated Collaborative Design by a design

organization necessitates a significant shift in attitudes. The challenge in the construction


46

industry is the negative attitude towards innovation and new techniques. To overcome this

challenge, the Integrated Collaborative Design approaches projects according to their

similarities. ICD allows organizations to re-use management processes.

It is argued that by adopting the ICD principles, construction organizations can avoid pitfalls

through a generic language that can be used by all organizations, irrespective of their function,

size or traditional position in the industry. Integrated Collaborative Design provides a basis for

the management of design according to technical expertise by focussing on the exchange of

design information. The Integrated Collaborative Design approach is not restricted to a particular

procurement route, but applies the three principles to an organization’s business that can be

applied to projects.

2.2.3.3 The ICD Practices

The Integrated Collaborative Design practises comprise of strategies, tactics and operations.

Their purpose is to plan, respond and implement. Figure 2.7 below shows the 25 Integrated

Collaborative Design practises identified by Austin et al (2007).

Strategies assist in planning the development of an organization’s Integrated Collaborative

Design practice in order to establish working relationships. Integrated Collaborative Design’s

main premise is the management of an organization’s current competencies by linking then with

organizations it works with.

Tactical practises assist in establishing the correct infrastructure in an organization. This enables

the organization to be prepared for different types of work. Tactics are divided into long-term

integrated Collaborative Design strategies and short-term strategies in the project domain.

Operational practises assist in the introduction of the Integrated Collaborative Design principles

to the organization’s business and projects. Operations also assist in introducing management

approaches and approaches for which skills need to be learnt.

Figure 2.7 below illustrates the Integrated Collaborative Design strategic, tactical and operational

practises which support the previously mentioned principles.

STRATEGIC PRACTICES TACTICAL PRACTICES

OPERATIONAL PRACTICES

Business Practices:

Planning Design Applying Process Modelling Business


47

Process Management Management Practices Processes

(BS1) (BT1) (B01)

APPLYING PROCESS Project Practices:

MANAGEMENT

Planning Project Applying Design Applying ADePT to

Design Management Management Practices

Design Management (PO1)

(PS1) (PT1) Applying DePlan to

Design Management (PO2)

Modelling Project Design

Processes (P03)

Business Practice:

Planning Supply Chain Aligning Supply Auditing the Supply

Management Networks (BT2) Network (B02)

Business Practice

(PS1) Applying Supply Chain Auditing the Supply

Management in the Network for Technical

APPLYING Business (BT3) Competence (B03)

SUPPLY CHAIN Project Practices:

MANAGEMENT

PRACTICES Planning Supply Chain Applying Supply Chain

Management

Management to Projects

Project Practice (PT3)

(PS3) Assembling the Supply

Selecting Supply Chain Chains (PO1)

Members at the Project

Level (PT4)

Business Practice:


48

Planning the Applying Integral Value

Implementation of Engineering in the Gathering Value-adding

Integral Value Business (BT4) Tool Feedback from

Engineering across Conducting a Value Projects (B03)

the Business (BS3) Survey (BT5)

Performing an ADePT

Review (BT6)

ESTABLISHING VALUE Project Practices:

FRAMEWORKS

Planning Integral Planning the

Value Engineering Implementation of Applying Value-adding

Practice (PS1) Integral Value Tools to Design Problems

Engineering on a Project (P05)

(PT4)

Figure 2.7: The ICD strategic, tactical and operational practices. Source: Austin et al (2007)

2.2.3.4 The ICD Principles

In this section, Austin et al (2007) describe the principles in detail and their inter-relationship.

2.2.3.4.1 Applying process management

In the application of process management, between construction projects, there are some

activities that repeatedly occur. A generic design process model can be produced through

recording of design tasks and their information dependencies (Austin et al, 1996).

Figure 2.8 below illustrates the Maturity assessment for applying process management.


49

LEVEL 1 LEVEL 2 LEVEL 3 LEVEL 4 LEVEL 5 LEVEL 6

Don't Know Haven't Thinking of Doing it as Full Inherent

Thought Doing Normal Deployment Practice

About it Something Business and Throughout

About it

Improvements operations

Understanding No unders- Project use Recognize Seeking Coherent Processes

Project standing processes that existing alignment project modelled

Processes of Project defined by processes of project processes well and

Process contract need processes established aligns with

development

competences

Modelling No knowle- Individual Consistent Generic Shared work Processes

Project dge of proc- businesses work processes breakdown modelled

Processes ess model- define own breakdown established structures are and tasks

ling processes structures and used understood aligned

recognised and utilised

Aligning No attempts Inconsist-

Design overl- Task Seamless Fully aligned

Organisational to define ent allocat-

aps and gaps allocation transfer of interfaces

Interfaces interfaces ion of tasks recognised in between information

with a just-in-

with signi- critical areas all without gaps time release

ficant inter- organizati- or overlaps of informat-

face ons based ion

problems on know

interfaces

and compe-

tencies

Enhancing Design Design Recognised Design Information Fully

Design information

information overload of

information needs of each

co-ordinately

Information exchange is is 'pushed' information shared in organization needs

Coordination effectively to all part- flow and common understood expressed


50

managed or ies indiscr- need to formal with predom- including

monitored iminately, realign with clear inately 'pull' what' and

regardless processes understan- transfers of why' it is

of need ding of essential important

based on needs information

contracts only

Establishing Silo menta- Obscured Comminicat- Project rol- Mutual Fully effecti-

Project lities pre- roles ion problems es are well agreement

ve communi-

Transparency dominate and poor recognised as defined a- of roles is cation based

communi- cause of poor nd comm- established upon clarity

cation performance unicated as basis for of roles and

cause sign- on projects coordinat- responsibili-

ificant ion ties

delays to

projects

Fostering No acknow- Problems Mechanisms Feedback Feedback is

Project based

Project ledgement recur on exist for from proje- managed learning is

Learning of the imp- successive capturing cts is cons- collaborative- fed back to

act of proje- projects feedback istently ly across business

cts on causing from captured projects relationships

delivery poor individual and shared to improve

performan- projects future

ce and project

delays performance

Figure 2.8: Maturity assessment for applying process management. Source: Austin et al (2007)

According to Austin et al (2007), collaborating organizations are able to represent complex

relationships between them in definite terms by applying process management. Their

understanding of business and project activities hence increases. Organizations can better


51

understand each other’s roles and responsibilities by defining their design processes and the flow

of information.

This is further reinforced by Latham (1994), who stated,

„Process management creates opportunities to involve organizations in the design

process according to their design expertise rather than their traditional contractual role.

Design overlaps and/or gaps in the scope of project works can also be minimized.

Having a common process view improves the relationships between collaborating

organizations and helps project teams to plan operational activities with greater

certainty and reliability. This minimizes the „fuzzy edges between consultants and

specialist engineering contractors‟ (Latham, 1994).

Austin et al argue that design chain members can have collaborative strategies established

between them. Latham (1994) observed that if individual design processes can be identified,

collaborating organizations can allocate responsibility for their completion.

2.2.3.4.2 Adopting supply chain management practices

After applying process management, Austin et al (2007) found that organizations are ideally

positioned to assemble a design chain from their supply chain relationships. Organizations are

able to integrate their design competencies with each other. This relies on the strength of

teamwork. Project participants can readily exchange design information, allowing for efficient

design. This sharing of information is similar to the transfer of goods in a supply chain of other

industries. Integrated Collaborative Design incorporates supply chain management practices


However, Austin et al (2007) observed that an important difference must be noted when applying

supply chain management to construction. There is a big difference between supply chains and

supply networks. Austin et al (2007) define a supply network as,

„a group of organizations with the known competencies (technical and/or managerial).

These organizations will have previously worked together and exhibit a degree of mutual

understanding that has arisen from the past experience.‟(Austin et al, 2007)

Supply chain however is defined as,

„a project specific group of organizations consciously brought together to provide all

the competencies required to complete a project. These are one-off arrangements

largely, though not exclusively, drawn from a common supply network.‟(Austin et al,

2007)


52

The project-based nature of the construction industry has an influence on the distinction between

supply chain and supply network. The flow of orders or contracts is intermittent in construction

(Austin et al, 2007). The iterative nature of design means that information flows in both

directions (back and forth) in the supply chain. This is also due to the fact that a design chain is a

specialized form of supply chain. In other industries, information flows in one direction down the

chain. The roles and contributions of individual employees can be managed according to their

function, by viewing a project as a design chain. Employees in the design chain are viewed as

either providers or receivers of design information.

Integrated Collaborative Design applies supply chain management principles to the business and

project domain through identification of the design chain in a project. The selection of

collaborators in the business domain is guided by the Integrated Collaborative Design principles

adopting the supply chain principles. The principle guides the identification of supply chain

network members with the required technical expertise in the project domain.

2.2.3.4.3 Establishing value frameworks

In the final stage of an organization’s Integrated Collaborative Design practice, Austin et al

(2007) suggest establishing a value framework. These value frameworks comprise of stronger

business relationships than those established when adopting supply chain practises. The delivery

of value from collaborative design is promoted through allowing project resources to be used

effectively. Value delivery is achieved through a variety of combined working methods. Porter

(1985) argued that value frameworks are built by beginning with an organization’s value chain

(Porter, 1985). Optimization of the processes of collaborative design work is achieved by the

using the Integrated Collaborative Design value chain model whereby an organization shares

business tasks.

Austin et al (2007) found that within a value framework, organizations retain the core processes

which contain its unique design expertise, therefore are included in the project design chain.

Porter’s (1985) value chain has been adapted to classify processes according to an organization’s

ability to deliver internal business value through its involvement in project design chains (Austin

et al, 2007).

The efficiency of collaborating organizations is improved and overhead costs reduced by value

systems through integrating their processes to rationalize common activities. Application of this

integrated function is achieved through the project design chain of a project. Value systems

influence project domain and exist within an organization’s business domain.

Austin et al (2007) found that the building of value systems between supply network members

and utilising of value chains to align business partners is extensively used in many industries.

Waste is eliminated when design information is exchanged through the use of the Integrated


53

Collaborative Design value systems. The main conclusion from Austin et al (2007) is that the

process of optimization should deliver business value to value system members and project value

to both design chain members and to the customer procuring construction industry products.




Table 2.6: Integrated Collaborative Design Tool Breakdown

YES NO

Detects Change X

Predicts Change X






Plans Design X

Schedules Design X

Controls Design X




Limits Impacts X


Web-Based System X

Software Based X

2.2.4 DePlan: a tool for integrated design management

Choo et al (2004) proposed DePlan as a method for integrated design management. DePlan is an

integration of the Analytical Design Planning Technique (ADePT) and Last Planner. These two

design management tools are software based. An in-depth review of ADePT has been conducted

in section 2.2.2. This section is focused more on the Last Planner method and how the two tools

are integrated.


54

2.2.4.1 Planning, Scheduling, Controlling of Design and Software Base

Last planner method incorporates scheduling and controlling of design activities. Choo et al

(2004) argue that the integration of ADePT and Last Planner helps planners generate quality

planners. The produced quality plans sequence activities in the right order by identifying

information and resource requirements before execution of the design. Only activities that have

met the requirements are scheduled.

As has been observed by Austin et al (2004) in section 2.2.2, ADePT has improved planning

effectiveness by enabling designers to focus on the flow of information between design tasks.

This translates to the focus being more on information flow rather than deliverables. An optimal

design sequence then achieved. ADePT allows designers to establish a design strategy suitable

for a particular project.

Choo et al (2004) point out that the Last Planner technique is focused on the use of lean

principles to an organization and management of project operations. The variability that lies

within a project is managed through reduction of uncertainty that exist within project processes.

The Last Planner technique has been adapted to suit the design process. It was originally devised

for construction. Before commencement of a project, Last Planner allows designers to

systematically plan a project and create work plans. This enables designers and planners to track

the status of the project and make adjustments where necessary.

DePlan is an integrated approach in managing the design process that combines the strategic

nature of ADePT with the operational approach of Last Planner (Choo et al, 2004).

The main conclusions about DePlan are that it encompasses design planning, scheduling and

control:

Planning-determining the required activities to meet the design criteria, the relationship

between the activities, and an optimal sequencing.

Scheduling-assessing the status of the activities‟ readiness to be performed, assigning

resources, and determining the start time, duration, and completion time for each of the

activities.

Control-assessing the status of activities after completion of work and calculating

resource use in terms of time and cost.

Scheduling and control determine what needs to be achieved and focus on those needs to make

activities ready for execution. The following sections describe the implementation of DePlan

through combining the ADePT and Last Planner software tools. Other software tools have been

created to support ADePT and Last Planner. The Analytical Design Planner (ADP) was

developed to support ADePT. WorkPlan was developed to support Last Planner. WorkPlan

implements weekly work planning for construction according to Last Planner. It has also been


55

modified, resulting in Extended WorkPlan. Extended WorkPlan was developed specifically for

the application of Last Planner to design management.

2.2.4.2 Planning with DePlan

Choo et al (2004) describe the method of planning with DePlan.

2.2.4.2.1 Method

DePlan initially involves three steps;

i. Modelling the design process

A design process model is created by defining design tasks and their information

requirements.

ii. Analysing the dependency structure matrix (DSM)

The sequence of tasks defined in the first stage is optimized through the dependency structure

matrix (DSM) analysis. Iterations within the design process are identified, then grouped into

a submatrix. The tasks are then sequenced based on their relationship with other tasks in the

matrix.

iii. Creating the project schedule

A design schedule is created based on the activity sequence from the second stage by

assigning resources. Unforeseen constraints are likely to be revealed in this stage which may

require recalculation of the activity sequencing. (Choo et al, 2004)

2.2.4.2.2 Design Process Model

Choo et al (2004) argue that ADePT uses a generic design process model to develop a design

process model for a specific project. The design process model is based on United Kingdom

practises and has been applied on a few projects.

Figure 2.9 illustrates the processes involved in DePlan.


56

Figure 2.9: DePlan, Source: Choo et al (2004)

Choo et al (2004) further reinforce the above assertion by adding that ADePT’s current generic

process model for detailed design contains a hierarchy of tasks belonging to five building

disciplines;

a. Architecture

b. Civil Engineering

c. Structural Engineering

d. Mechanical Engineering

e. Electrical Engineering

All activities are broken down into systems, subsystems and design tasks in order to determine

the information requirements and output. The generic process model contains more than 90% of

the tasks and dependencies needed to define a project.

2.2.4.2 Dependency Structure Matrix Analysis

Steward (1965) developed the Dependency Structure Matrix to improve the efficiency of solving

complex problems. DSM has been thoroughly detailed in the previous section (2.2.2).

2.2.4.3 Design Programming

As previously pointed out, the final stage of ADePT produces the master design programme that

defines the overall planning strategy for the project. This is based on the logic of information


57

dependency of the design process and will also have been integrated with the proposed

construction programme.

2.2.4.4 ADP and PlanWeaver

Choo et al (2004) found that several other computer software have been developed for the

implementation of ADePT. The Analytical Design Planner (ADP) software was used to initially

develop DePlan. BIW Technologies have developed the latest version which is known as

PlanWeaver. Dependency Structure Matrix (DSM) and process model development are

integrated by PlanWeaver. The results are then exchanged into known project management tools

that undertake the scheduling of tasks. PlanWeaver has been used on a wide range of projects.

2.2.4.5 Scheduling and Controlling

2.2.4.5.1 Last Planner

Choo et al (2004) found that the Last Planner uses a production philosophy. Creation of a

production plan involves making certain assumptions such as availability of resources, permits,

information and weather conditions. These assumptions have a big influence on the execution of

the actual plan. Actual resource availability must be checked before commencement to ensure

successful execution of the plan. Choo et al (2004) argue that the Last Planner methodology

proposes,

„a production plan that should be created by selecting only the work that can be done

from the work that should be done.‟ (Choo et al, 2004)

A more detailed explanation of the Last Planner methodology is provided below by Ballard and

Howell (1994) (Figure 2.10).


58

Figure 2.10: Last Planner Methodology, Source: Choo et al (2004)

In order to determine what work CAN be done, constraints that are preventing the work from

starting and finishing without interruption must be defined (Ballard and Howell, 1994). The

requirements for starting work as well as whether the requirements will be satisfied throughout

the duration of the project must be determined. Development of the constraint list allows

planners to determine what work can be done as well as what need to be done to make a

SHOULD to a CAN.

Extended WorkPlan which was developed specifically for the application of Last Planner to

design management allows the user to generate a schedule and can also import the optimized

order of design tasks from the ADePT Dependency Structure Matrix (DSM). This feature is

relevant to the Medupi project. By importing the output matrix, Extended WorkPlan

automatically enters the list of activities, the disciplines responsible for each activity as well the

informational dependencies into its database (Choo et al, 2004).

2.2.4.5.2 Activity definition model for constraint analysis

Figure 2.11 below illustrates the activity definition model. This model facilitates the

development of a list of activities and their constraint. It is an input-process-output

representation. It can also be used to represent a design or construction process.


59

Figure 2.11: Activity Definition Model, Source: Choo et al (2004)

The inputs comprise of;

i. Directives

This is an order or instruction issued by a last planner to direct workers on what to do as well as

how to do it and when.

ii. Prerequisites

This is work done by others on materials or information that serves an input or substrate for

work.

iii. Resources

This is labour or instrument of labour, including tools and equipment and space.

Constraints that prevent the process from being executed are called ‘Unsatisfied needs’. A subset

of directives that measure the extent to which the output from the process execution is acceptable

is called the ‘Criteria’. Re-work results from unacceptable results. This model is used to

determine the constraints as well as determine whether the activity needs to be broken down into

a smaller set of processes, each having its own set of inputs and Criteria (Choo et al, 2004).


60

2.2.4.5.3 Extended WorkPlan Software Development

Extended WorkPlan has been developed by Choo et al (2004) using WorkPlan to link the process

model and DSM analysis output to the Last Planner scheduling and control methodology.

Constraints need to be specified and checked in order to determine what can be done. Extended

WorkPlan helps determine constraints systematically. These constraints fall into five categories;

i) Contract

This category refers to constraints like;

a. Contract Finalization

b. Commercial Constraints

c. Permits

d. Subcontracting agreements

ii) Engineering

These are constraints that arise from other engineering disciplines such as construction

management and planning/scheduling supervisors.

iii) Samples

This category refers to instances where design is constrained by agreements to provide samples.

iv) Resources

This category refers to the means to achieve the requirements specified by the directives. It also

includes supporting functions such as supervision, accounting, planning/scheduling and drafting.

v) Design Constraints

This category specifies the information required before commencement of design. This

information is imported from ADePT software. This enables the constraint matrix to be

generated.

The above five categories were selected after review of the original categories in WorkPlan

against likely constraints likely to arise in the management of the design process (Choo et al,

2004).

Directives determine requirements as well how those requirements can be achieved. In the

Extended WorkPlan, each design activity corresponds to a work package. A constraint matrix is


61

created. Each discipline is included in the matrix constraint. Numbers are used to indicate design

constraints under the responsibility of that discipline. These numbers indicate outstanding

information constraints that must be met before start of the design activity. Outstanding

information constraints potentially can delay a project, therefore hampering successful delivery

of the project.

Categories assist the planner in identifying potential constraints that might delay the whole

design process. It also allows the planner to constantly check the status of the constraints as well

as the involved constraints. This assists the planner in reacting to unforeseen changes which

occur on design activities. The planner can add identified constraints after the information in

ADePT’s design process model has been imported during project execution (Choo et al, 2004).

In order to successfully execute the design production, design constraints have to provide a list of

constraints that must be satisfied. When all constraints are settled, an activity can then be

released for scheduling using a Work Package Release form (Choo et al, 2004). A plan is

developed using the released activities. Release is not guaranteed due to the fact that activities

may still have outstanding constraints at the time of release. Planner need anticipate when the

outstanding constraints will be settled.

The number of hours spent on each design activity needs to be recorded in order to assess

whether an activity was completed as planned. Unsuccessful completion must be noted in order

to assess the reasons for non-delivery. Assessment of the reasons for failure allow a planner to

prevent re-occurrence of the problem. Preventative action can be taken. Extended WorkPlan has

a feature that tracks the reasons for non-delivery and generates a reasons-for-variance.





62

Table 2.7: DePlan Tool Breakdown

YES NO

Detects Change X

Predicts Change X






Plans Design X

Schedules Design X

Controls Design X




Limits Impacts X


Web-Based System X

Software Based X

2.2.5 A Web-based System for Design Interface Management of Construction

Projects

As previously stated, management of design in construction projects is challenging. As discussed

in the above sections, methods have been developed for managing the design. Out of all these

methods, the Dependency Structure Matrix (DSM) has proved to be effective in representing and

managing the design process (Senthilkumar et al, 2009). The application and utilisation of

Dependency Structure Matrix (DSM) based methodologies in real construction projects is

limited, more especially in global collaborative projects.

As discussed above, the Analytical Design Planning Technique (ADePT) and DePlan have been

developed to implement DSM concepts.

2.2.5.1 Planning, Scheduling, Controlling of Design

Senthilkumar et al (2009) conducted extensive research on a Web-based Design Interface

Management system. They found that the previously developed tools like ADePT and DePlan

that implement Dependency Structure Matrix (DSM) concepts faced difficulties in modelling,

planning and management of design. They argue that the main hindrance is the DSM formation


63

procedure adopted in the tools (Senthilkumar, et al, 2009). They found that the tools are based on

Activity DSM. Obtaining the correct abstraction (activity definition-from detailed level to high

level of abstraction) to format was a problem. Additionally they concluded that a lot of effort and

time is required from designers when working on large projects. This is due to these methods

requiring design dependencies to be identified directly on the matrix (Senthilkumar et al, 2009).

These finding have a significant bearing on this study. Medupi is the largest construction project

ever undertaken in South Africa. Identifying dependencies on the matrix would be a very tedious

and costly exercise. Based on the Senthilkumar et al (2009), the ADePT and DePlan tools would

add a significant cost to the project. This would oppose the project management criteria of

delivering the project within time, cost and quality constraints.

Senthilkumar et al (2009) propose the use of a Drawing Dependency Structure Matrix (DDSM)

instead of Activity Dependency Structure Matrix. Drawings are well defined entities therefore its

elements can be directly identified. The intricacies of deciding on the correct abstraction level

used in Activity DSM are avoided. Senthilkumar et al (2009) found that due to the large number

of drawings produced during a construction project, identifying dependencies was difficult. The

initial stages of design require the design team to identify dependency relationships of the

drawings. It was found that this proves to be problem since it requires parameter level

interactions which are not apparent at the initial stage of design. Senthilkumar et al (2009)

concluded that a structured methodology was necessary for identification of dependencies and

management of the size of the Dependency Structure Matrix. It was noted that no specific

guidelines exist for the decomposition of projects, therefore formulating such a guideline is

imperative.

Senthilkumar et al (2009) have developed and proposed a modified DDSM formation

methodology called ‘diMs’ based on their field studies. According to Senthilkumar et al (2009),

‘The „diMs‟ methodology plans and manages the design by formulating a DDSM which

is based on a systems approach through a structured decomposition procedure. Further,

as the DDSM development process is incremental and requires interaction between

multiple members of the design group, a software tool is essential for its successful

implementation.’(Senthilkumar et al, 2009)

The following sections describe in detail the formulation of the tool.

2.2.5.2 ‘diMs’ Methodology-an overview

Senthilkumar et al (2009) proposed the ‘diMs’ methodology as part of the overall Dependency

Structure Matrix (DSM) process. The basic concepts of DSM have been thoroughly detailed in


64

the preceding sections of this literature review. The proposed ‘diMs’ methodology focuses on the

Drawing DSM formulation process.

Senthilkumar et al (2009) suggest that ‘diMs’ be implemented in three stages.

„These are as follows: 1. Entity-Identification, 2. Interface-Identification

3.Interface-Management. Senthilkumar and Varghese (2009) provide the

following six steps to explain the procedure in the context of requirements for

system development and design:

1. In Entity-Identification stage, the project is decomposed into various

entities. The entities identified are systems, main components,

subcomponents and teams. Not all entities at the lower abstraction level

are identified at the start of the project, it will evolve as the design

progresses.

2. In Interface-Identification stage, the design interfaces between teams can

be effectively identified by capturing the “physical interfaces” between

various systems, main components and subcomponents. The physical

interfaces of the main component and systems are captured through

categorizing the main components and subcomponents under each system.

The physical interfaces between the main component and subcomponent of

a particular system is identified through a Physical Interface Matrix

(PIM). In PIM, main components of a particular system are listed as

column headings and the subcomponents present in the same system are

listed as row headings. The physical interfaces between the main

components and subcomponents are identified in the matrix with a „X‟

mark appropriately.

3. Following PIM development, the subcomponents which are physically

interfaced with the particular main component are filtered for identifying

the design interfaces between design teams. It is identified through Design

Interface Matrix (DIM). Each main component identified in the PIM

(Column) will generate a separate DIM.

The DIM columns represent the „Teams‟ involved in the design. The DIM rows

have two sections, the first section (shaded portion) represents the „Teams‟

involved (same as columns), and the second section represents the „Sub-

components‟ which have physical interfaces with the selected „Main

Component‟ as identified in the PIM. The shaded portion captures design

interfaces among the teams. The rest of the matrix captures the subcomponent

specific design interfaces among the teams.


65

Table 2.8: diMs Methodology

PIM for System 1 MC 1 MC 2 MC 3 MC 4

SC 1 X X X

SC 2 X X MC-Main Component

SC 3 X X SC-Sub Component

SC 4 X X

SC 5 X X

SC 6 X X

Source: Senthilkumar et al (2009)

4. Next, each discipline enters the detailed interfacing issues in the form of Design

Interface Agreement (DIA). The DIA documents the specific interface issues, the

teams involved, the interface agreement reached and the status of the agreement.

The parameter level of details is specified for each issue in DIA.

5. The final step is to identify the drawing and issue relationships through mapping

interface issues with identical drawings as input/output. Based on this framework,

the Drawing DSM (DDSM) is developed.

6. The developed DDSM can be further analysed (Partitioning and Tearing) for

sequencing and other design decision making processes.

Figure 2.13 illustrates implementation of the above mentioned three stages.


66

Figure 2.13: diMs Methodology-process flow diagram, Source: Senthilkumar et al (2009)

Senthilkumar et al (2009) argue that the above described steps differentiate the ‘diMs’

methodology from the standard Dependency Structure Matrix (DSM) based design management

tool. The difference between the ‘diMs’ tools and other tools was;

i) Adoption of Drawing Dependency Structure Matrix (DDSM) for design information

modelling.

ii) Hybrid decomposition of tasks is adopted.

iii) Identification of interfaces using drawing-parameter mapping is adopted.


67

The researchers found only PlanWeaver and ADePT methodologies have previously been used

in building design projects. However, it is argued that these tools do not address formulation of

Dependency Structure Matrix (DSM) hardships.

Table 2.9: Hybrid Decomposition

DIM for MC1 Team 1 Team 2 Team 3 Team 4

Team 1 X X

Team 2 X MC-Main Component

Team 3 X SC-Sub Component

Team 4 X X

SC1 X X

SC2 X X

SC5 X X

SC6 X X X

Source: Senthilkumar et al (2009)

2.2.5.3 Complexity of Projects, Software Base, Web-Base

Senthilkumar et al (2009) point out that for successful implementation of ‘diMs’, project

participants at various levels need to interact across disciplines. Geographical barriers require

quick decision making for successful interface management. Documentation produced by the

‘diMs’ methodology continually increases during the project therefore requiring interaction

between many members of the design group. For effective management, regular updates of the

documents are required. It was observed that even though the tool is efficient at capturing design

interfaces, the large number of documents produced make management difficult. This

necessitated an automated tool for effective implementation of the methodology.


68

Figure 2.14: Entity Identification, Source: Senthilkumar et al (2009)

Management of the workflow processes are the key features of the tool. The tool incorporates

multiple user authorization levels, automated alert messages through generated emails, report

creation and management for design interface meetings are imperative (Senthilkumar e al, 2009).

2.2.5.3 System Development

2.2.5.3.1 System Architecture

According to Senthilkumar et al (2009), the primary purpose of the system architecture was to

design a tool that required minimum effort from the designers. The system development

comprises of the following;

i. Design of a rational database

ii. Design of a communication engine

This allows for active integration of input data, the ‘diMs’ processes and output data.

iii. Design of an effective user interface

A Dependency Structure Matrix (DSM) backend engine was incorporated in order to carry out

the DSM analysis such as Partitioning and Tearing.


69

2.2.5.3.2 Presentation Layer

Senthilkumar et al (2009) incorporated a presentation layer in the tool. This presentation layer

provides an interface between the users and system. Suitably designed allow access to data.

Database tables are accessed by users according to the authorization level granted to them. Users

of the tool are then categorized into the following levels;

a. Administrators

b. Interface Manager

c. Project Manager

d. Discipline Manager

e. Designers

2.2.5.4 System Usage

2.2.5.4.1 Prototype implementation

Senthilkumar et al (2009) implemented the prototype system to manage the information flow of a

glass factory design. Below is a description;

‘The glass factory consisted of the design of batching plant, chimney, furnace,

float bath, lehr and warehouse. There were six design disciplines-Architecture,

Structural, Electrical, Mechanical/HVAC, Fire and PHE involved in the

design process apart from the stakeholders such as client, subcontractors,

consultants, vendors etc. The project was done on a fast track mode (the

construction starts more or less in parallel with the design). For the „diMs‟

implementation, Senthilkumar participated in the design process as an

assistant to the interface manager.

As part of the „diMs‟ methodology the team members were initially identified.

Each of them was supplied with a unique username and password to access

the system. The user roles were defined in the DB for instituting multi-tier

authorization level. The identified team members were introduced to „diMs‟

terminologies and methodology in the form of workshop followed by a training

session. Further to support the usage of „diMs‟, it was decided by the top

management that only the issues raised through the prototype will be

discussed during the regular weekly interface meeting. The step by step

implementation procedure was as follows;

1. The initial kick off meeting/workshop was arranged to start the process.

During the meeting, the entities such as systems, main component and

subcomponents were identified. As all the designers were involved in the

meeting, the entity identification was made easy. Further the system allows


70

the users to store/retrieve interface data in DB tables through structured

procedures.

2. The system generates framework for the PIM automatically after all the

entities are defined. PIM is a dynamic matrix and it gets updated when an

entity is added/removed from the DB in order to accommodate the frequent

scope change in the case of fast track projects. During the first session of

the workshop, the users were asked to identify physical interfaces between

the already defined main component and subcomponent in the PIM

structure.

3. From the PIM, the system generates the DIM structure automatically.

During the second session of the workshop, the design interfaces were

captured through the DIM framework by each team. This workshop

facilitates the interface identification process as the participants from all

the teams were present in the common working forum (workshop). The

physical interfaces formed the basis for the designers to identify the design

interfaces.

All the above steps were done during the workshop/meeting, as it requires

collaborative inputs to generate the same. The interface manager moderated

the above steps during the workshop/meeting and the system is cited as a

display platform to stimulate thinking and document the interfaces identified

by the teams.

4. After the workshop, each participant can generate issues which were

relevant to each identified interfaces in the DIM according to their

authorization level.

5. Once the issue is generated, the interfacing teams were notified by a

system generated email. The responses to the issue are made on a response

window.

6. The responses are updated in the DIA accordingly. The DIA has the

following details of the interface issues; 1.Interface issue 2.Initiator

3.Responder/s 4.Responses 5. Status etc.

7. Even though the steps 4 to 6 allowed the users to interact on-line, and

solve interface issues to some extent, the weekly interface meeting

interactions were required especially when an interface issue required

collaboration among three or more teams. Further the priority issues were

also identified and the same were resolved during the meeting in order to

meet the construction schedule. Hence the weekly interface meeting was

mandatory. Before the meeting, each team‟s representative member took

the reports generated by the system. Each team had two types of issues,

1.Issues which need to be resolved by others and 2.Issues which need to be


71

resolved by oneself. Further, the above two categories are grouped in two

types; 1.Priority Issues and 2. Non priority issues. The categorized report

can be generated through the report generating page with filtering options

in the system.

8. Next, the design team mapped the generated issues as input/output with the

drawings defined in the entities definition stage.

9. The system generates the DDSM using the issues-drawings relationships

established in the above step. This approach of mapping the interface

issues as input and output has reduced the effort required in identifying the

drawing dependencies.

The developed DDSM could further be partitioned for identifying the blocks.

These blocks could further be reduced to smaller blocks by tearing. However,

the conventional tearing was found not suitable for fast track projects. Tearing

decisions for fast track projects need to be based on balancing the risk

between delay in meeting the immediate construction milestone and possible

rework which may extend the project schedule beyond the conventional design

driven duration. The research pointed out that further studies were necessary

to evaluate alternate tearing options and optimization of the drawing release

sequence. Further, as the relationship in the DDSM can change as a result of

the regular weekly interface meetings, partitioning and tearing decisions had

to be updated based on the inputs from the meetings.‟





72

Table 2.10: ‘diMs’ tool Breakdown

YES NO

Detects Change X

Predicts Change X






Plans Design X

Schedules Design X

Controls Design X




Limits Impacts X


Web-Based System X

Software Based X

2.3 Key Findings & Their Implications

The main conclusions from this literature review are that changes are inevitable in construction

projects. And, during a construction project, many decisions have to be made, often based on

incomplete information, assumptions and personal experience of the construction professionals.

Change is a common denominator in all construction projects, though the size, scope, and

complexity of projects may vary significantly from case to case. It was found that change

management is a critical problem faced by the construction industry. The effort of managing

change orders has imposed a huge burden on project management. Changes are identified as the

major cause of project delay, cost overruns, defects, or even project failure. Changes cause

serious ethical problems and disputes in the industry.

This literature review points out that changes in construction projects are very common and

likely to occur from different sources, by various causes, at any stage of a project, and may have

considerable negative impacts. Effectively managing change orders in construction processes is

not trivial because change orders are part of contract and need to be strictly traced in terms of

contracts, documents, approval process, payment claim, etc.


73

The analysis presented shows that a large proportion of the problems of construction design are

due to a fundamental neglect of the prescription provided by the generic foundation of

engineering. Whether information technology is used or not plays a small role, if the design

process is confused at the outset. Effective methods for the amelioration of construction

engineering can be devised only on a basis of suitable conceptualizations and if it is informed by

empirical data.

Through this literature review, it has been found that managing design changes is a very

technical and complex issue. The following techniques, tools and models for managing design

changes have been analysed;

1. Managing Design in the Extended Enterprise

2. Analytical Design Planning Technique (ADePT)

3. Integrated Collaborative Design (ICD)

4. DePlan: a tool for integrated design management

5. ‘diMs’

The objective of this research is to determine a design management tool for a complex project

such as the Medupi Power Station. Through the literature review, we have been able to

determine the five techniques most relevant to this research. These design management

techniques have not been tested on global collaborative projects. The theoretical foundation of

design change management established in these researches has been assessed and synthesis of

best practices has been presented for adaptation in the case study.

An ideal design change management system should seek to forecast possible changes; identify

changes that have already occurred; plan preventative measure; and coordinate changes across

the entire project. This entails providing change estimation, impact analysis, post change

analysis, statistics, and more importantly, change traceability. This is the criteria used for

assessing the design management tools and methods. A comparative analysis of the five

techniques is shown below. The table illustrates that the tools do not differ a great deal, but differ

in some of the critical required components.


74

Table 2.11: Comparative Analysis of Design Management

Tools

ADePT

Managing Design in Extended Enterprise DePlan ICD diMs

Detects Change

Predicts Change

Plans Preventative Measure

Co-ordinates changes across project

Provides Impact Analysis

Provides Post Change Analysis

Provides Change Traceability

Plans Design

Schedules Design

Controls Design

Applicable on Complex Projects

Enhances performance (Time, Cost & Quality)

Reactivity Enhancing

Limits Impacts

Requires Physical Interaction of Teams

Web-Based System

Software Based

2. literature review 2.1 introduction - wiredspace...

Documents