2. literature review 2.1 introduction - wiredspace...
TRANSCRIPT
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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)
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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)
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.‟
Chapter 2: Literature Review
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).‟
Chapter 2: Literature Review
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.’
Chapter 2: Literature Review
32
A B C D G J L E I S O M Q R T P F H K N
Task A X Task B X Task C X X
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
Chapter 2: Literature Review
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).
Chapter 2: Literature Review
34
A B C D G J L E I S O M Q R T P F H K N
Task A X Task B X Task C X X
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
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.
Based on the hypothetical ideal requirements of a design management tool for global
collaborative projects, table 2.5 below is a summary of the findings from the literature review.
The assessment was based on the available literature discussed above.
Table 2.5: ADePT: Analytical Design Planning Technique Tool 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
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.
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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‟
(Austin et al, 2007).
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
Chapter 2: Literature Review
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;
Chapter 2: Literature Review
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‟
(Austin et al, 2007).
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
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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:
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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
(Austin et al, 2007).
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)
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.
Based on the hypothetical ideal requirements of a design management tool for global
collaborative projects, table 2.6 below is a summary of the findings from the literature review.
The assessment was based on the available literature discussed above.
Table 2.6: Integrated Collaborative Design Tool 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
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.
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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).
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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).
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.
Based on the hypothetical ideal requirements of a design management tool for global
collaborative projects, table 2.7 below is a summary of the findings from the literature review.
The assessment was based on the available literature discussed above.
Chapter 2: Literature Review
62
Table 2.7: DePlan Tool 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
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
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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
Chapter 2: Literature Review
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.‟
Based on the hypothetical ideal requirements of a design management tool for global
collaborative projects, table 2.10 below is a summary of the findings from the literature review.
The assessment was based on the available literature discussed above.
Chapter 2: Literature Review
72
Table 2.10: ‘diMs’ tool 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
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.
Chapter 2: Literature Review
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.
Chapter 2: Literature Review
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