Embed Size (px)
Citation preview
PRODUCT ORIENTED COORDINATION
BETWEEN DESIGN AND CONSTRUCTION
SONG HONGBIN
NATIONAL UNIVERSITY OF SINGAPORE
2004
PRODUCT ORIENTED COORDINATION
BETWEEN DESIGN AND CONSTRUCTION
SONG HONGBIN
(M. Eng.)
A THESIS SUBMITTED
FOR THE DEGREE OF MASTER OF ENGINEERING
DEPARTMENT OF CIVIL ENGINEERING
NATIONAL UNIVERSITY OF SINGAPORE
2004
ACKNOWLEDGEMENT
I would like to express my gratitude to many people who have supported me in
my study and my life at NUS.
First of all, I am deeply indebted to my supervisor, Associate Professor Chua
Kim Huat, David for his thoughtful guidance and instructive advices during the course
of study.
Appreciation is also given to the persons in the company I visited, who offered
time and data to help me understand real AEC projects.
I also wish to thank my colleagues. They have consistently provided valuable
suggestions for my research and have created a comfortable environment for work.
Finally, I appreciate the efforts of my parents and friends, who always
encourage me to work hard.
i
TABLE OF CONTENTS
ACKNOWLEDGEMENT…………………………………………………..… i
TABLE OF CONTENTS………………………………………………...……. ii
SUMMARY………………………………………………………………..…... v
LIST OF FIGURES……………………………………………………..…….. vii
LIST OF TABLES………………………………………………………..…… x
CHAPTER 1 INTRODUCTION……………………………………………... 1
1.1 BACKGROUND………………………………………………………… 1
1.2 RESEARCH OBJECTIVES……………………………………………... 3
1.3 RESEARCH METHODOLOGY………………………………………… 4
1.4 RESEARCH CONTRIBUTIONS………………………………………... 4
1.5 DISSERTATION OUTLINE…………………………………………….. 5
CHAPTER 2 LITERATURE REVIEW........................................................... 6
2.1 COORDINATION……………………………………………..………… 6
2.2 PRODUCT AND PROCESS INTEGRATION………………………..… 9
2.3 PRODUCT MODEL…………………………..…………………………. 14
2.3.1 Introduction…………………………..…………................................ 14
2.3.2 Product Models………………………………..…………………….. 16
2.4 DESIGN MANAGEMENT……………………………..……………….. 20
2.4.1 Characteristics of Design……………………………..……………... 22
2.4.2 Design Process Management…………………..……………………. 26
2.4.3 Design Change Management………………..………………………. 30
2.5 CONSTRUCTION MANAGEMENT………………………..………….. 33
ii
2.6 CONCLUSION………………………………………..…………………. 34
CHAPTER 3 MODEL DEVELOPMENT…………………………..……….. 36
3.1 WHY USE PRODUCT AS INTERFACE?................................................ 36
3.2 HOW TO REALIZE THE PRODUCT-ORIENTED COORDINATION? 37
3.3 MODEL FRAMEWORK……………………………..…………………. 41
3.3.1 Product and Parameter………………………………..……………... 42
3.3.2 Design Process and Parameter………………………………..……... 47
3.3.3 Construction Process and Parameter………………………...………. 55
3.4 COORDINATION ANALYSIS…………………..……………………... 60
3.4.1 Form Original Network…………………………………...…………. 60
3.4.2 Analyze and Manage the Network……………………………..……. 62
3.5 CONCLUSION…………………………..………………………………. 67
CHAPTER 4 CASE STUDY………………………………….......................... 69
4.1 INTRODUCTION……………………………..………………………… 69
4.2 INFORMATION FLOW ANALYSIS………………………………..….. 72
4.2.1 Internal Information Flow…………………………………..……….. 72
4.2.2 External Information Flow………………………………..…………. 74
4.3 MODEL FRAMEWORK………………………..………………………. 79
4.3.1 Identification of Key Parameters……………………..……………... 79
4.3.2 Analysis of Design Process………………………………..………… 81
4.3.3 Analysis of Construction Process……………………………..…….. 85
4.4 COORDINATION ANALYSIS………………..………………………... 86
4.4.1 Form Original Network………………………..…………………….. 86
4.4.2 Analyze and Manage the Network………………………..…………. 89
4.5 CONCLUSION………………………..…………………………………. 97
iii
CHAPTER 5 CONCLUSIONS AND RECOMMENDATIONS...………..... 99
5.1 CONCLUSIONS..……………………..…………………………………. 99
5.2 RECOMMENDATIONS FOR FUTURE WORK…………………...….. 101
REFERENCES…………………..…………………………………………….. 103
iv
SUMMARY
Design and construction are two of the most important stages in the lifecycle of
an AEC project. Traditionally, the AEC industry has separated these two stages,
resulting in numerous problems since the constraints that each stage puts on the other
cannot be fully taken into account. In recent years, design-build has been proposed as
an optimal project delivery approach aiming to integrate design and construction. The
success for design-build requires careful consideration of the interdependent
relationships between design and construction. Problems often occur due to
inappropriate management of these relationships. Thus, it is imperative to improve the
coordination between design and construction.
This thesis proposes a model to coordinate design and construction activities.
The model aims to manage the interdependence between design and construction. The
coordination model employs product as the interface since it is the common link
between design and construction. The framework of the model is composed of four
main parts, namely, parameter, product, design and construction. Parameters play an
important role in the coordination, connecting product with design and construction.
Any product component can be described by a set of parameters corresponding to
different properties of the component. At the same time, parameters are also important
to depict design and construction processes since the design activities are concerned
with the determination of these parameters while the construction activities realize
these parameters based on their values determined in the design stage. For a parameter,
it can be in different states during design and construction. Thus a state chain pictures
the evolution of the parameter. The state transformations correspond with different
process activities in design and construction. A process activity is characterized by its
information inputs and outputs which can be described using parameter states.
v
Furthermore, much related information about parameter states can be grouped to form
deliverables (drawing, as-built measurement, etc.).
The whole dependency network is formed by connecting the process activity—
parameter state relationships. The network is inherently a network of information
dependencies which represents the links between process activities and their
information constraints. The fundamental purpose of coordination is to ameliorate the
relationship between required information flows and corresponding process sequence.
This thesis suggests several practical means to deal with information coordination
problems.
This thesis also presents a case study to illustrate the working principles of the
coordination model. The coordination model should be effective in dealing with
design-construction coordination issues. This model may be of great benefit to project
managers who are always frustrated by coordination problems between design and
construction. Thus, the application of the model may improve the efficiency of AEC
projects.
vi
LIST OF FIGURES
Figure 2.1 Information Flow and Coordination of Production Processes…….....
Figure 2.2 Functional Tree of the Conceptual IA Framework…………………..
Figure 2.3 Overall Structure of the RATAS Model……………………...……...
Figure 2.4 Class Diagram of Building Entity………………………...…………
Figure 2.5 IDPM Node Tree……………………………...……………………..
Figure 2.6 Design Information Flow Model within a Level of Abstraction….....
Figure 2.7 Parameter Dependency Network………………………………...…..
Figure 2.8 Three Typical Relationships for Two Design Tasks…………...……
Figure 2.9 Design Loop…………………………………………………...…….
Figure 3.1 Relationship between Design/Construction and Product………...….
Figure 3.2 Activity and Parameter………………………………………...…….
Figure 3.3 Basic Structure of the Model…………………………...……………
Figure 3.4 Hierarchical Decomposition of Building Product………………...…
Figure 3.5 Parameter Classification………………………………...…………...
Figure 3.6 Basic Parameter and Derived Parameter………………………….....
Figure 3.7 State Chain of a Basic Parameter………………………………...….
Figure 3.8 State of a Derived Parameter………………………………...………
Figure 3.9 Typical Design Process………………………………………...……
Figure 3.10 State Transformations of a Basic Parameter in Design Stage...……
Figure 3.11 Preliminary and Check………………………………………...…...
Figure 3.12 Review and Refine………………………………………………….
Figure 3.13 Application of As-proposed State…………………………………..
Figure 3.14 Design Process……………………………………...………………
Figure 3.15 State Transformations of a Basic Parameter in Construction Stage..
8
10
17
18
21
23
24
26
27
37
39
41
42
43
44
45
46
48
49
50
51
54
56
58
vii
Figure 3.16 Construction Activity and Input/Output………………...………….
Figure 3.17 Construction Process……………………………………...………..
Figure 3.18 Original Network…………………………………………...………
Figure 3.19 Original Plan…………………………………………...…………...
Figure 3.20 Result after Re-ordering……………………………………...…….
Figure 3.21 Original Activities………………………………………...………..
Figure 3.22 Parameter Dependencies in Activity 1…………………………......
Figure 3.23 Divide an Activity into Two Sub-activities…………………...……
Figure 3.24 Use an Earlier State……………………………………...…………
Figure 4.1 Perspective Views of a Glass Wall…………………………………..
Figure 4.2 Glass Wall Project…………………………………………...………
Figure 4.3 Glass Wall Design……………………………………...……………
Figure 4.4 Information Flows in the Glass Wall Project………………………..
Figure 4.5 External Information Constraints……………………………...…….
Figure 4.6 Inter-participant Information Dependency……………...…………...
Figure 4.7 Procedure for External Shop Drawing Design…………………...….
Figure 4.8 State Chain of D(S)…………………………………………...……...
Figure 4.9 State Chain of D(G)…………………………………………...……..
Figure 4.10 Glass Wall Shop Drawing Design……………………………...…..
Figure 4.11 Glass Wall Fabrication Drawing Design………………………...…
Figure 4.12 Glass Wall Construction Activities……………………………...…
Figure 4.13 Steel Beam Construction Activities………………………...………
Figure 4.14 Original Network……………………………………………...……
Figure 4.15 General Representation of the Network………………………...….
Figure 4.16 Traditional Plan and Information Dependencies…………...………
58
60
61
63
63
64
65
66
67
70
70
71
73
75
77
78
80
81
83
84
86
86
87
89
90
viii
Figure 4.17 Solutions for the Coordination Problems………………...………...
Figure 4.18 Parameter Dependency Network after Adjustments………………..
93
96
ix
LIST OF TABLES
Table 3.1 State Description…………………………………………………………
Table 4.1 External Information Constraints…………………………………….…..
Table 4.2 Parameter Identification………………………………………………….
Table 4.3 Design Activities…………………………………………………………
Table 4.4 Construction Activities…………………………………………………..
45
76
79
82
85
x
CHAPTER 1
INTRODUCTION
1.1 BACKGROUND
The architecture, engineering, and construction (AEC) industry has a long
history. It contributed and is contributing to the development of world economy.
Meanwhile, theories and technologies in AEC have been developing and maturing. A
lot of research work has been done in managing AEC projects so as to improve the
effectiveness and efficiency.
An AEC project is very complex in that it is composed of many interconnected
stages and there are a lot of interdependent participants (Olsson, 1998; Rivard et al.,
1995; Sanvido, 1992). These stages include design, procurement, construction,
maintenance and so on, each of which contributes to the intended project based on the
predefined role. Among the participants involved in a project are client, architect,
structural engineer, service engineer, contractor, sub-contractor, supplier, facility
operator, to name a few. An essential ingredient of a successful project is good
communication and collaboration between the project participants. Due to the
fragmentation of these stages and the large number of participants required by the
increasingly complex and dynamic nature of today’s projects, the need for well-
structured collaboration and coordination has become more important than ever.
In the stages to realize a project, design and construction are of great
importance and have been the areas of much research (Luiten et al., 1998). Design
stage transforms client requirements into drawings and specifications, which are then
turned into reality through construction stage. Traditionally, design and construction
are treated as two relatively isolated processes (Anumba and Evbuomwan, 1996), each
1
of which is completed by its own team members, namely designers or contractors. This
renders many problems (Anumba and Evbuomwan, 1996) since the constraints that
each stage puts on the other are not fully considered (Austin et al., 2000a). Thus, the
integration of design and construction has been proposed to be the optimal approach to
successfully eliminate some of the major problems in the AEC industry. In recent
years, the AEC industry has witnessed a growing interest in the area of integration of
design and construction (Anumba and Evbuomwan, 1996). Furthermore, AEC clients
are looking for companies that can provide complete products to them rather than
separate ones (Luiten et al., 1998). All these promote the design/build project delivery
approach aiming to integrate these two stages. Because of its obvious advantages
compared with traditional approach, design/build has become more and more popular
in practice.
However, the success for design/build is not always as easy to reach as
expected. Design/build only aligns the interests of designers and constructors. When it
comes to production level, many efforts need to be taken to coordinate design and
construction. At the production level, a variety of constraints must be fully taken into
account in order for design and construction work to be carried out successfully. These
constraints include engineering, resources, prerequisite work and so on which come
from diverse sources such as clients, designers, contractors, and external regulating
authorities. For the coordination of design and construction, the most important
constraints are the inter-stage constraints. In other words, design provides information
as prerequisite to construction and construction may affect design by as-built
measurement information feedback. Since these constraints involve both designers and
contractors, the management of them is a formidable task. In addition, it is now
common that AEC clients are demanding that projects be delivered in greatly reduced
2
time frames (Bogus et al., 2000). This exacerbates the coordination problem. Thus, it is
imperative to deal with coordination between design and construction.
1.2 RESEARCH OBJECTIVES
The main objective of the dissertation is to develop a model to coordinate the
design work and construction work in an AEC project. The model aims to deal with
the interdependent relationships between design and construction. Since the
interactions between design and construction cannot be separated from design process
and construction process, relevant design knowledge and construction knowledge
should be included in the research to deal with the interactions. For design, the analysis
is biased toward the later stages which tend to be relatively structured and concentrates
less on the conceptual, creative or otherwise unstructured aspects. For construction, the
original network is deemed to be available. Then the main work focuses on the
management of relationships between design and construction and within design stage
while the construction stage is less discussed. However, this doesn’t mean that
construction knowledge will not be addressed. The traditional construction network
needs some changes to cater for the need of coordination. The relationships are formed
in terms of information requirement/production. However, the information involved in
AEC projects is highly complex. This study mainly deals with information produced
during design and construction while paying less attention to the various requirements
and constraints which come from clients, regulating authorities, codes and so on.
Below are the specific objectives:
1. Propose an appropriate coordination mechanism. A proper mechanism is very
important to the success of coordination between design and construction. This
mechanism should be able to effectively deal with the relationship between
design and construction.
3
2. Establish information requirement/production for design and construction. The
relationship between design and construction is formed based on information
dependencies.
3. Derive dependency network. Through information dependencies, a network
will be established which includes both design and construction. It is the whole
network that is of concern. This network is the basis for coordination.
4. Analyze and manage the dependency network. The dependence network
provides information dependences for process. Some typical approaches will be
suggested to manage the dependence relationships so as to improve the
coordination.
1.3 RESEARCH METHODOLOGY
The research was conducted as follows:
(1) Find out coordination problems existing in AEC projects;
(2) Determine the basic research direction;
(3) Detailed literature review to have an understanding of the research direction;
(4) Determine specific research scope;
(5) Propose models to solve the problems;
(6) Collect data in case study;
(7) Use the case data to testify and optimize the model.
1.4 RESEARCH CONTRIBUTIONS
Through the coordination model, the two relatively independent networks --
design network and construction network, can be connected. This insures that as much
relevant information as possible is made available to the involved party that requires it
4
in design and construction. Thus, continuous information flow is achieved so as to
improve the coordination.
This model may be of great benefit to project managers who are always
frustrated by coordination problems. In AEC projects, coordination-related problems
often occur between design and construction. Using this model, these problems may be
settled with ease. Thus, the application of the model may improve the effectiveness
and efficiency of AEC projects.
1.5 DISSERTATION OUTLINE
This chapter briefly introduces the scope of the research. Chapters 2 to 5 will
present the dissertation clearly. To enable readers to fully understand the research
concept, chapter 2 gives a detailed review of the relevant work that has been carried
out in the research area. As the main part of the dissertation, chapter 3 describes the
proposed model. After that, chapter 4 presents a case study to illustrate the working
principles of the model. Finally, chapter 5 provides conclusive remarks for the
dissertation.
5
CHAPER 2
LITERATURE REVIEW
Extensive literature review has been conducted to gain a better understanding
of the research topic. The materials reviewed cover five key research areas, namely,
coordination, product and process integration, product model, design management and
construction management, which are all related to the intended research topic.
2.1 COORDINATION
Coordination problems arise naturally in a variety of disciplines such as
engineering design, computer science, organization theory, sociology, political science,
management science, systems theory, economics, linguistics, and psychology. In
recent years, there has been a growing interest in coordination-related problems. Since
coordination is a crucial problem in almost all these disciplines, it has been an area of
much research and continues to be a focus of considerable attention.
Coordination has a variety of definitions (Malone and Crowston, 1990, 1994).
Malone and Crowston (1994) suggested that “Coordination is managing dependencies
between activities.” In an AEC project, the different tasks are interdependent in one
way or another since they are related to the same project (Olsson, 1998). This suggests
that Malone and Crowston’s definition is applicable to the AEC industry. The need for
coordination is closely related to the degree of interdependence between different
activities (Kadefors, 1995). Different kinds of dependencies need different
coordination processes to manage them (Malone and Crowston, 1994). Furthermore,
Malone and Crowston (1990) concluded that interdependence between activities can
be analyzed in terms of common objects that are involved in some way in these
6
activities. This idea is very important since it suggests a coordination mechanism
which is adopted in this research.
In addition, Albino et al. (2002) showed that the coordination of a process
mainly consists of the processing of the information necessary for the management of
interdependent activities. They proposed a methodology to describe and analyze the
information flows involved in the coordination of production processes. In their
methodology, a production process is considered as an information processing and
communication system where actors (resources) perform tasks, send and receive
messages, and process information. Information flows consist of exchanged messages
and information processing activities which are necessary for the process coordination
and deal with such issues as the agreement among decision-makers. Figure 2.1 shows
the framework of their methodology. The key factors affecting the information flow
within a production process are identified including the production process, the
coordination form, and the context. Based on these factors, the methodology can derive
a quantitative index that measures the information flows, i.e. the effort required to
properly coordinate the production process. By simulating different coordination
mechanisms of the process, the associated quantitative index can be used to select the
best options.
While the idea is accepted that the coordination of a production process is
closely related to the information flows, and indeed it is used as a fundamental basis
for the proposed model in this research, it is questionable that the methodology can be
applied to the intended research topic. The main objective of this methodology is to
measure information flows on the premise that production process network is available.
In other words, only after the task dependencies are identified, can the information
flows be derived. However, what the intended research concerns is the coordination of
7
the process based on information flows rather than the measurement of information
flows in the coordination process.
Production Form of Context coordination process
Information flow
Figure 2.1 Information Flow and Coordination of Production Processes
This research intends to deal with coordination problems between design and
construction in AEC projects. The basic ideas in coordination theory can be adopted in
this research. Thus, analysis of interdependencies between design and construction is
fundamental to coordination. Since AEC area is information-intensive, information
flow exists between design and construction. Coordination will focus on information
related dependence relationships. A proper mechanism is essential to the success of
Satisfactory?
Coordination technology taxonomy
no
yes
Coordination technology
choice
8
coordination. In an AEC project, design and construction are all related to the product
information. Thus, coordination between design and construction can use the common
object -- product as interface.
2.2 PRODUCT AND PROCESS INTEGRATION
The AEC area is information-intensive (Shahid and Froese, 1998). Over these
years, the industry has always been bedeviled with great difficulties in managing
information flow among its participants (Ndekugri and McCaffer, 1988). With the
increasing complexity of AEC projects, effective management of information has
become more and more critical throughout the life of AEC projects. The industry has
always been looking for approaches and tools to streamline the job of information
management (Rezgui, 2001).
To address information management in AEC industry, it is necessary to
develop an understanding of the information within an AEC project. Sanvido (1992)
presented an Information Architecture (IA) to picture the information contents in an
AEC project. Figure 2.2 shows an overview of all the IA elements. The Information
Architecture consists of five separate but related classes of information, namely,
product, process, process control, feedback, and constraints. Another effort in
modeling the information contents is the various project models. Project modeling
primarily deals with the overall information in a project (Luiten et al., 1993; Luiten et
al., 1998; Stumpf et al., 1996). The most important project models developed include
Unified Approach Model (Bjork, 1992a), GenCOM (Froese, 1992), BPM (Luiten and
Bakkeren, 1992; cited in a review by Luiten et al., 1993), IRMA (Luiten et al., 1993)
and ICIM (Stumpf et al., 1996).
These models provide frameworks for the overall information classes in an
AEC project. It can be seen that product and process are two of the most important
9
10
elements, which deal with different kinds of information (Platt, 1996). They are
regarded as different views about the project, while each provides a valuable
contribution. Product mainly deals with static project information. It contains
information regarding what the product looks like. Product status changes with the
progress of the process. Although a product undergoes changes as process advances, it
provides little information on how these changes can be achieved. Consequently,
product information is inadequate for dealing with the dynamics of a project. By
contrast, process is rich in information on how a product is transformed from one state
to another. It is the dynamics that are of concern. However, process itself provides
little insight into the structure and requirements of data within the product.
Traditionally, product and process have been developed independently since
the focus on them is quite different (Froese, 1996). This eases the development and
makes the model development more flexible (Dubois and Cutting-Decelle, 1996).
There is, however, a growing awareness that if these two kinds of models could be
successfully integrated with each other, there would be cumulative benefits to be
achieved throughout the design and construction process (Platt, 1996). In reality,
product and process are interrelated in that process is responsible for product change
and product provides information constraints to process, which provides the
opportunity for integration.
To make the integration possible, Dias and Blockley (1994) identified a close
structural correspondence between product and process models for design through the
definition of the role as a generic unit. A process model role has been defined as a
collection of responsibilities while a product model role is simply a collection of
functions. The organizational relationships of roles have been identified including
aggregation/decomposition and generalization/specialization. Such correspondence
11
makes the design process efficient and synergistic. However, this effort only tries to
provide structural correspondence between product and process, while
interrelationships between product and process have been given less attention.
Furthermore, Lee et al. (1996) developed an entity-based integrated design product and
process model which used product and process entities to describe design information
and design activities, respectively. In this model, the relationships among the entities
were identified including organizational, interaction, and sequence relationships.
Organizational relationships provide a logical arrangement of product and process
entities by organizing entities into hierarchies. Interaction relationships refer to the
interdependent nature among product information while sequence relationships
identify the sequences in which process entities are initiated during the design process.
In this model, the researchers present formal representation for entities and
relationships so as to provide a clear understanding of and a theoretical basis for the
computer-integrated design system. However, this model focuses on structural design,
providing a procedure for building structures design. This model cannot deal with the
design of other systems, which are also important for a building. It should be noted that
these efforts focus on product and process integration for design stage, while the
construction stage is not addressed.
As a major effort to model information classes, the various project models also
provide information to product and process integration (Froese, 1996). These models
show the relationships between the information elements including product and
process. Generally, they treat product as design results and focus on the construction
stage when it comes to process analysis. Thus they only provide mechanisms for the
integration of design results (product information) with construction process (process
12
information). The design evolution information is rarely discussed in detail in these
frameworks.
As another effort, Sanvido (1992) explored an approach to linking the different
levels of abstraction of a building design to both a product and a process model. In this
approach, design and construction are all included in the process model. Thus, design,
construction and product can be connected in this approach. For design and
construction, however, this approach only considers one-way information flow -- from
design to construction. The as-built information feedback is not taken into account
which flows from construction to design.
The integration of product and process establishes the connection between
product and process, which is considered as one necessary step for the product-
oriented coordination. As described, researchers have done much work in this area and
they employ different mechanisms to integrate product and process. While these
researches are beneficial, they all have some limitations in terms of coordination
between design and construction. Generally, process objects are at the very kernel of
these models. The linking between design and construction is performed from a
process viewpoint in that process and product are connected through process output,
which is defined as group of documents. Thus the linking only provides high-level
relationships between product and process. Detailed information links between design
and construction cannot be tracked in these models. The proposed model in this
dissertation also involves product and process integration. However, it deals with this
problem from a different viewpoint—parameter viewpoint. It is a more efficient tool
with the capability to deal with the coordination between design and construction
based on the evolution of parameters.
13
2.3 PRODUCT MODEL
In recent years, computers have been used in numerous disciplines. Because of
their apparent advantages, computers have also become prevalent in the AEC area. The
use of computers considerably improves the capacities of handling the huge amount of
information that characterizes an AEC project, which is deemed almost unbelievable
for manual, paper-based work. However, most of the applications are isolated, which
makes the information sharing and exchange impractical. Thus, computer integrated
construction (CIC) emerges with the aim to integrate the different applications.
Research and development in the area of CIC has been looking into various aspects of
fragments in the construction industry (Turk et al., 2000), exploring the sharing and
exchange of project information among all project participants and all project life-
cycle stages.
A cornerstone of CIC is the development of data standards, i.e., common
information models (Froese, 1996). Among them is the development of standards for
the description of buildings in computerized form, so called product models. The
introduction of product models represents a revolution to information handling in that
the use of product models ease information exchange and information sharing.
2.3.1 Introduction
A product model is a conceptual description of a product which includes the
necessary information for that product. Product models contain large amount of
information regarding products. Generally, a product model is developed as a common
language for a particular type of product rather than as a representation for a single
product (Bjork, 1992b).
Several scholars (Bjork, 1989; Bjork and Penttila, 1989; Rivard and Fenves,
2000) addressed the requirements for product models. Two of the most important
14
requirements are multi-view representation and dynamic extension, which are essential
characteristics for a practical product model. Multi-view representation is necessary for
a product to accommodate different disciplines (Dias, 1996; Howard et al., 1992;
Rivard et al., 1999; van Nederveen and Tolman, 1992). It is the foundation of
collaborative design (Rosenman and Wang, 1999). Functions are considered as the
basis for multi-view representation since different disciplines are interested in different
functions of a product (Rosenman and Gero, 1996). Furthermore, a product model
should be extensible since it is very difficult to develop an all-inclusive product model
(Eastman, 1992; Eastman and Fereshetian, 1994; Ekholm and Fridqvist, 1998; Rivard
and Fenves, 2000). Thus, a product model acts as a basis for application so that a user
can create new information when necessary.
The basic concepts used in almost all product models are objects, attributes and
relationships (Bjork, 1992b; Eastman and Fereshetian, 1994; Shimodaira, 1992). They
play fundamental roles in product modeling. An object may correspond to a physical
or abstract entity meaningful to the product. Objects use attributes to represent their
different aspects of properties. Relationship is used for connecting objects. The two
basic types of relationships are decomposition/aggregation and
specialization/generalization. Decomposition/aggregation is used for relating different
level objects. Generally, the low level objects have “part of” relation with high level
object in the decomposition/aggregation relationship. A given global product can have
a number of aggregation/decomposition hierarchies where objects can also display
cross-hierarchical interactions. Specialization/generalization is used to connect a class
of individual objects of similar types with a single named object. The basic idea is to
specify all general information on a class level and then to define additional
distinguishing parameters on the subclass level. Generally, “type of” relations exist in
15
the specialization/generalization abstraction. In this abstraction hierarchy, data can be
managed efficiently by using common attributes which descendent objects inherit from
a generic object. These two kinds of relationships form two kinds of orthogonal
hierarchies where generalization/specialization hierarchies are defined at each
hierarchical level in the aggregation/decomposition hierarchy (Dias and Blockley,
1994). Generally, the generation/specialization hierarchies can be treated as libraries,
members of which are instantiated to form members of various
aggregation/decomposition hierarchies, which together constitute the model of the
global product.
2.3.2 Product Models
In the AEC area, a variety of product models have been developed by both
industry and academia. All these efforts aim to provide a foundation for product
representation. However, the application scope for these models is different. Some of
them are more generic and describe the information structure for a whole branch of
industry while others are more specific and describe the information structure for a
restricted type or family of products.
RATAS (Developed by the RATAS committee in Finland) is one of the best
known product models (Bjork, 1989, 1994; Bjork and Penttila, 1989). RATAS
provides an approach to describe building products. Figure 2.3 gives an illustration of
RATAS representation. Five abstraction levels, namely, building, system, subsystem,
part and detail, are used to describe a building functionally. Objects from the higher
levels are especially useful in early design stages for defining functional requirements
and for making high-level design choices while objects from the lower levels are more
tangible so that they correspond with detail design process. Each of the objects belongs
to at least one class. Classes can be arranged in meaningful hierarchies. Two types of
16
relationships are used: part-of and connected-to. Generally, the part-of relationship
connects objects from different abstraction levels while connected-to relationships
connect objects from the same level (usually lower abstraction levels).
OBJECTS CLASSES
Building level
--------------------System level
--------------------
Subsystem level
--------------------
Part level
--------------------
Detail level
Figure 2.3 Overall Structure of the RATAS Model
Another important product model has been developed in SEED-Config, which
is one of the modules of SEED (Software Environment to support the Early phases in
building Design) (Fenves et al., 2000; Rivard and Fenves, 2000; Rivard et al., 1996).
This building representation consists of two levels of abstraction models defined on
top of the object-oriented data model. The first level is an information model, called
the BENT (Building ENtity and Technology) model, which defines a set of basic
constructs that can represent any building design domain. Figure 2.4 shows the class
17
18
diagram of the building entity and the other constructs. The second level is a
conceptual model that defines the types of objects, relationships, and data needed to
represent the information in a particular design domain. It refines the first level
representation by specifying the categories of information used in a particular domain.
SEED models provide representation for conceptual design of buildings. They store
design data as they are generated during conceptual design. The aim of these models is
to support early design exploration -- the fast generation of alternative design concepts
and their rapid evaluation against a broad spectrum of relevant and possibly conflicting
criteria. However, they are not applicable to later stages of design.
Other product models include EDM (Eastman, 1992), ICON (Ford et al., 1994),
GOOD_B (Biedermann and Grierson, 1995), CIMSTEEL (Crowley and Watson,
1997), and so on.
Most of these models are design-centric (Harfman and Chen, 1993) in that they
are closely related to the design process. They have been developed to support design
evolution and exploration (Rivard and Fenves, 2000). Since the end user’s concern is
space, spatial properties have been addressed by some authors to support the design
process (Bjork, 1992b; Eastman and Siabiris, 1995; Ekholm and Fridqvist, 1996, 2000;
Maher et al., 1997).
Although there are common objects for these different product models, each of
them has its own characteristics and application scope. The logical extension of these
models is standardization. Standard models are developed to guarantee some degree of
uniformity within different applications by using the same standards (Fischer and
Froese, 1996).
There are two most important international standardization efforts that address
the product models, namely, ISO-STEP (Burkett and Yang, 1995) and more recently
19
IAI-IFC (Kiviniemi, 1999). Standard models also include LexiCon, which has been
developed by STABU (the Dutch national building specification organization)
(Woestenenk, 2002). LexiCon can be seen as an extension to STEP and IFC. All these
provide standards libraries from which a user can select necessary entities to model a
product. Although standardization has been accepted in the industry, there are still
some limitations for standard models (Rezgui, 2001; Tolman, 1999).
This research intends to deal with product-oriented coordination which uses
product information as the interface for coordination between design and construction.
Thus, product model is closely related to this research. However, this research focuses
on the application rather than the development of product models. The various efforts
in product modeling contribute much to this research by providing an understanding of
the basic ideas and concepts for product models. In the proposed coordination model, a
product is composed of different level components with relationships among them.
The components are described by parameters which correspond to different
characteristics of components.
2.4 DESIGN MANAGEMENT
Design is a problem solving stage. In this stage, the client’s requirements are
conceptualized into solutions which are generally represented using procedures,
drawings and technical specifications. Design is extremely important for the success of
a project since the quality of design has an extensive impact on all subsequent stages of
a project’s life cycle. IDPM (Integrated Design Process Model) provides a
comprehensive view of the entire design stage (Sanvido and Norton, 1994). It
represents the major functions and activities necessary for a successful design. Figure
2.5 shows the general break-down of the IDPM through its first three levels of detail.
20
21
2.4.1 Characteristics of Design
1. Evolution
Design is generally composed of several evolutionary phases including
feasibility study, conceptual design, preliminary design and final design. In each phase,
the design problem is partially solved at a level of abstraction (Wilson and Shi, 1996).
Along the stages of design, abstract concepts are incrementally refined so that design
solutions are determined in more and more details. Throughout the evolution of the
design process, information continues to flow and accumulate. The work to capture,
store, and retrieve design information is one of the major challenges in design
management.
Shooter et al. (2000) proposed a design information flow model which
concentrates on the information that flows among individual design activities
regardless of the activities’ particular sequence. It aims to support a semantics-based
approach for developing information exchange standards. The model organizes design
information into levels of abstraction, each of which is a view of a design problem that
includes only the issue designers are considering relevant at a given time in the design
process. Then it identifies the various transformations within a level of abstraction and
between levels of abstraction. Figure 2.6 shows the design information flow model
within a level of abstraction.
As another effort, de la Garza and Alcantara Jr. (1997) suggested the
representation of design evolution information using parameter dependency network
(PDN). PDN shows how other object-parameter pairs affect a certain object-parameter
pair. Designers solve decision problems by determining required functions and
transforming these requirements into specific performance parameters. These
performance parameters then form the basis for the generation and evaluation of
22
23
Customer Needs
Family of Solutions Unbound Behavior Intended Description Model Behavior
Proposed Artifact
Bound Description
Specifications
Engineering Requirements
Observed Behavior
Evaluated Behavior
Evaluated Requirements
Refine/Revise
Refine/Revise
QFD, etc.
Refine/Revise
Brainstorming Synectics, etc.
(Re)select
(Re)bind
Simulation
Figure 2.6 Design Information Flow Model within a Level of Abstraction
design alternatives. This approach is based on a representation of object design
rationale as performance criteria. Figure 2.7 shows an example of the PDN. In Figure
2.7, the object-parameter pair Mechanical Room--Function affects the object-
parameter pair Mechanical Room--Fire Resistance Rating, which, in turn, affects the
object-parameter pairs Door--Fire Resistance Rating, Wall--Fire Resistance Rating,
and HVAC Equipment--Fire Resistance Rating. Then these performance parameters
are used to select door, wall and HVAC equipment materials.
Figure 2.7 Parameter Dependency Network
All these efforts focus on the knowledge representation. They provide
understanding for the design process evolution.
2. Multidiscipline
Design is multidisciplinary in nature in that it involves clients, architects,
designers, contractors and so on, each of which has its own area of concern. Experts
from these disciplines, loosely organized as a design team, work together to finish the
Mechanical Room Function
House HVAC Equipment
Mechanical Room Fire Resistance Rating
2 hours
Door Fire Resistance Rating
2 hours
HVAC Equipment Material Brand Z
Wall Fire Resistance Rating
2 hours
HVAC Equipment Fire Resistance Rating
2 hours
Door Material Brand X
Affected By Affects
Legend
Wall Material Brand Y
Object Parameter
Value or Constraint
24
design of a project. Communications among these participants are frequently impeded
(Rivard et al., 1999). A quality design is highly dependent upon effective collaboration
and coordination among the diverse disciplines to produce a coherent set of final
design documents. Generally, these participants are geographically distributed so that
much research work has been done related to distributed design coordination and
collaboration (Anumba et al., 2002; Brazier et al., 2001; Rosenman and Wang, 2001;
Tiwari and Gupta, 1995; Wang et al., 2002; Whitfield et al., 2002). During these years,
a variety of coordination approaches and systems have been developed in the field of
engineering design (Coates et al., 2000; Whitfield et al., 2000). More recently, lean
thinking principles have been adopted to coordinate different design disciplines
(Andery et al., 2000). Furthermore, as a step towards effective design coordination,
Hegazy et al. (1998) conducted a questionnaire survey related to design coordination at
the inter-team level and the interdisciplinary level as well. This questionnaire reveals
the coordination problems encountered and solutions to resolve them. In addition, Law
and Krishnamurthy (1996) developed a three layered data management model for
multidisciplinary collaboration design. All these efforts suggest the importance of
design coordination and collaboration.
3. Iteration
Design is distinct from other processes in that iteration and rework are
commonplace. Usually, the design work is performed in a process of iterative step-
wise refinement. Iterations represent conflicts in the flow of information within the
design process (Yassine et al., 1999). The presence of iterations leads to difficulty in
finding appropriate sequence of the design process activities (Smith and Morrow,
1999). As one of the principal causes for inefficient design, iterations drive up both
25
development time and cost. Some mathematical models have been suggested to
minimize the number of iterations between design activities (Ahmadi et al., 2001).
These inherent characteristics contribute much to the complexity of design
projects. Due to the complexity of design, research has been conducted in diverse areas
related to design improvement (Hegazy et al., 1998).
2.4.2 Design Process Management
Generally, design is based on decomposition principles in that the design
process is decomposed into many tasks (Boujut and Laureillard, 2002). Each task
involves certain problem analysis which is necessary for achieving the goal of the
design. Information is treated as connector between tasks in that each task is driven by
certain input information and produces output information. The output information of
one task may affect the input information of another task (Lee et al., 1996). Thus,
relationships exist between these tasks. However, the information relationships
between tasks are highly complex in design projects. Figure 2.8 shows three possible
relationships for two design tasks based on input/output (Eppinger et al., 1994).
A A
A B
B B
Interdependent Tasks Dependent Tasks Independent Tasks (Coupled) (Series) (Parallel)
Figure 2.8 Three Typical Relationships for Two Design Tasks
It is common that tasks are mutually dependent on each other’s information output
(Ahmadi et al., 2001). The interdependent tasks comprise a loop, which may include
many tasks (Figure 2.9).
26
Figure 2.9 Design Loop
Generally, it is easy to manage series and parallel relationships. However, the
management of coupled relationship is a formidable task. The success of a design
project requires the coordination of design tasks with complex information
dependencies between them (Ahmadi et al., 2001).
1. Tools
Streamlining design processes has always been regarded as an important step to
the success of design products. Many tools have been employed to structure processes
(Park and Cutkosky, 1999; Rogers, 1999). Traditional tools such as CPM and PERT
can be used in processes with sequential relationships. However, they are not
applicable to design process analysis since they cannot handle iterations and feedback
loops (Kusiak et al., 1995; Park and Cutkosky, 1999; Rogers, 1999; Smith and Morrow,
1999; Yassine et al., 1999). Thus, new tools have been developed to address design
process such as Incidence Matrix (Kusiak and Wang, 1993; Kusiak et al., 1995) and
DR (Design Roadmap) (Park and Cutkosky, 1999). However, IDEF0 and DSM may be
two of the most widely used tools.
As an influential tool, IDEF0 is frequently used in process modeling
(Malmstrom et al., 1999). In IDEF0 representation, the information modeling is
performed in four aspects, namely, input, output, control and mechanism. Furthermore,
IDEF0 can use top-down decomposition to break up a complex process into small sub-
processes. IDEF0 representation provides a good overview for a process, however, it
……..A (1) A (2) A (i) A (n) ……..
27
suffers from practical size limitations in that IDEF0 models tend to grow fast in
complexity for a large number of tasks. Although IDEF0 can represent a process, it
does not offer any capability to optimize it. In addition, the IDEF0 methodology gives
weak support for the modeling of iterations and feedback loops, because of its strong
feed-forward focus. Since one of the challenges in design management is to deal with
iterations, a modeling technique for design should be able to handle them. The IDEF0
technique is weak in this area, which makes it less efficient for dealing with design
problems.
Another powerful tool is DSM, which provides a simple, compact, and visual
representation of a complex system by using a matrix. DSM is a very robust technique
that can be used in many different problems (Browning, 2001). A DSM helps identify
problem areas within a process and can support restructuring of it in order to make it
more efficient. DSM representation overcomes the size and visual complexity of all
graph-based techniques. It provides a better overview than IDEF0, since the
complexity of DSMs does not grow as fast as that of IDEF0 diagrams (Malmstrom et
al., 1999). Thus it can be applied to large problems, while maintaining a relatively
good overview of the problems. The primary advantage of the DSM format is the
capability to deal with iterations commonly found in a design project. The DSM
handles iterations well and is relatively easy to understand. Due to these advantages, it
can be used in the current research proposed model to deal with network analysis.
2. Models
Many models have been developed to manage design processes. However, they
address the problem from different viewpoints and apply to different conditions.
ADePT (Analytical Design Planning Technique) is a model with the capability
to schedule the building design process (Austin et al., 1999a, 1999b, 2000a, 2000b,
28
2000c). The ADePT methodology is composed of three stages, namely, design process
modeling, DSM-based analyzing and design schedule generation. The first stage is the
creating of design process model (DPM). The model is represented using a modified
version of the IDEF0 methodology, which shows design activities and their
information flows. The data in the DPM are then linked to a DSM (Dependency
Structure Matrix) analysis tool in the second stage. DSM is used in this stage to
identify iteration within the design process and optimize the sequence of the activities
based on their information flows. This is the central part of ADePT methodology. In
order for DSM to be used as a means of controlling the design process, the analysis
result needs to be represented against a timescale. Thus the third stage produces a
design programme – a schedule for the design activities based on the optimised process
sequence determined in the second stage. DePlan is another model which combines
ADePT and Last Planner (Hammond et al., 2000). In this model, ADePT is used to
provide an improved design sequence while the Last Planner methodology will then be
used to schedule and control the design process. In addition, Clarkson and Hamilton
(2000) proposed “signposting”--a parameter-based model of design. The distinct
feature for this model is to use design parameters as a basis for identifying the next
task so as to form design process network.
These models aim to structure the design process from a process viewpoint in
that the design process is represented as a number of tasks which, when ordered
appropriately, enable successful design development. They employ different
mechanisms to order the process activities.
More recently, Chua et al. (2003) presented PPI (Process-Parameter-Interface)
model. This model is different from those activity-based models in that it is parameter-
centered. It focuses on the parameter relationships. This model can deal with the
29
iterations and improve design knowledge sharing. Furthermore, it supports the
regrouping of parameters to form new tasks and networks. This model provides a
flexible representation of design process and can improve design process management.
It can be seen that two viewpoints are available for design management --
process viewpoint and parameter viewpoint. They are complementary to each other.
Process viewpoint focuses on the inter-task information transfers, however, they ignore
many important technical interactions among the engineering parameters, which can be
explicitly described from parameter viewpoint. The proposed model in this research
provides a better management of design by combining these two viewpoints.
Furthermore, parameter evolution will be taken into account. By employing these
approaches, the design process can be improved.
2.4.3 Design Change Management
Throughout the design process, changes are frequently introduced for many
reasons. The changes inevitably and continuously affect the quality of design
documents. Thus, the effective management of design changes becomes crucial to the
success of a project.
Design changes are in fact modifications to some design data. As the design
data are interdependent, the modifications normally impact other data. Until all the
related data are adjusted accordingly, the designs remain incompatible (Mokhtar et al.,
1998). In some cases, the designer who initiated the change may forget to inform other
affected designers. Therefore, the difficulty in design change management is how to
make designers of any discipline aware of all changes which affect their own design
(Mokhtar et al., 1998). This requires full understanding of the rationale behind the
original design.
30
In recent years, a novel parametric approach was suggested to address the issue
of design changes (Soh and Wang, 2000; Wang and Soh, 2001). This approach can
facilitate the coordination of design information through managing design changes. A
parametric coordinator was proposed which provides each building component with
the linking knowledge. Then the design consistency between building components can
be achieved through the proposed linking knowledge as well as a group pattern module.
Furthermore, this study extended the technique of knowledge-based approach from
single-view 2D model to manage the relationships of entities between different views
by incorporating the projection knowledge and graphic inference. A corresponding
multiview constraint solver was developed. This knowledge-based constraint solver
can be combined with the linking knowledge between building components to
facilitate the coordination of design information for multiview models. This approach
essentially limits design changes to geometry-related information. Thus it aims at
resolving dimension-change problems.
In addition, some researchers presented information models to provide
improved design coordination through managing design changes (Hegazy et al., 2001;
Mokhtar et al., 1998; Zaneldin et al., 2001). The core idea of the model proposed by
Mokhtar et al. (1998) is to assign the task of design change propagation to the building
components themselves. Each component is equipped with the necessary linking
knowledge to identify the disciplines that are affected by a specific design change and
how they are affected. The model uses a central database to carry the building
components data and capture the linking knowledge in the form of rules. When design
change occurs to a building component attribute, the component checks all the rules
that are stored in the database. If any of these rules applies to the change, messages are
automatically sent to the relevant designers. In addition to its ability to propagate
31
design changes, the model is capable of tracking past changes and helping in the
planning and scheduling of future ones. The model uses textual data rather than
drawings as the main media for storing and communicating design information and it
does not address the issue of automation of the design change process. Furthermore, it
does not capture design rationale, which is an essential requirement for properly
managing design changes. The design rationale information is incorporated into the
information model proposed by Hegazy et al. (2001) and Zaneldin et al. (2001). This
model is built around a central library of generalized building components that can be
used to describe a complete building project hierarchy. Each component allows the
designer to store desired performance criteria and related design rationale. Each
component is also sensitive to its own changes and automatically communicates such
changes to affected parties through preset communication paths. The rationale,
however, only identifies the components related to a component attribute. The
relationships between attributes of these components cannot be tracked directly.
All these models, as such, provide improved design coordination and control
over changes, thus helping to increase the consistency and productivity of the overall
design process. A common characteristic for them is the attaching of linking
knowledge to components, which serves as the basis of change propagation. Although
design change management will not be addressed in this research, the model in this
research provides potential to deal with design changes by employing product as the
interface for coordination. Design change is product-oriented in that it is generally the
modification of product component properties. Once product information is changed,
the related process information will be affected accordingly based on the product-
process connection. Thus, the proposed coordination model can also be used to
manage design changes if necessary.
32
2.5 CONSTRUCTION MANAGEMENT
Managing construction is a highly practical profession. Demands for efficient
management and control in construction are growing due to the increasingly
complexity of construction projects. Areas in this scope include planning and
scheduling, estimating, cost control, accounting and so on. Planning and scheduling are
among the most important functions and much work has been conducted related to
these areas. The process of Planning and scheduling is typically done in a top-down
fashion. Generally, master, lookahead and commitment plan/schedule are three levels
of abstraction used by construction project managers. They are used in different
conditions and serve different functions.
Many tools have been developed to plan and schedule the construction work.
CPM and PERT are two of the most widely used tools. Other early planning systems
include OARPLAN (Darwiche et al., 1988) and MDA Planner (Jagbeck, 1994). More
recently, Fischer and Aalami (1996) suggested computer-interpretable construction
method models which support the automated generation of realistic construction
schedules. To take advantage of the increasingly accepted lean ideas, Choo et al. (1999)
suggested WorkPlan to systematically develop weekly work plans according to the
Last Planner method. Work packages are used as scheduling unit in WorkPlan.
Furthermore, Choo and Tommelein (2000) developed WorkMovePlan to address
distributed planning and coordination. WorkMovePlan can be employed to develop
lookahead plans and weekly work plans. In addition, as an effort to overcome the
limitations of traditional scheduling methods, Chua et al. (2003) proposed IPS
(Integrated Production Scheduler) as a new scheduling tool to help produce quality-
assured lookahead schedules. IPS enhances the reliability of planning by modeling two
additional types of hidden constraints on activities. In recent years, lean production has
33
been applied in the area of construction management. By adopting lean ideas, Chen et
al. (2003) presented Information Flow Integrated Process Modeling (IFIPM) technique
to incorporate information flows into CPM planning. The technique can improve
construction productivity through balancing conversion processes and information
flows. All these planning and scheduling tools are process-oriented in that they all
schedule the construction work from process viewpoint. Starting from a different
viewpoint, Chua and Song (2003) and Song and Chua (2002) suggested POST
(Product Oriented Scheduling Technique) as an alternative intelligent scheduling tool
for programming construction work from the product point of view. The POST model
can reduce errors and improve constructability analysis.
Since construction management is not the focus of this research, these efforts
can be treated as the basis of construction network in the proposed model. However,
traditional construction network is weak in dealing with as-built measurement
information, which is very important to the coordination between design and
construction. The as-built measurement information is generally considered as side-
product of construction activities in the traditional construction network. In the
proposed model, a new kind of activities is added which produces as-built
measurement information. Thus, the proposed model can improve the coordination by
explicitly representing the as-built measurement information.
2.6 CONCLUSION
The work related to the proposed research topic spans across various areas
including coordination, product and process integration, product model, design
management and construction management. From the forgoing discussion of the
literature, researchers have mainly focused on process viewpoint, with limited
consideration on parameter viewpoint when it comes to design and construction
34
analysis. Also, most of the research efforts related to parameter viewpoint dealt mainly
with design stage and treated a parameter as a whole. Although these features are
beneficial, they are not sufficient alone to meet the expectations of a coordination
model. The evolution of parameters should be taken into account from design to
construction. Another problem is the as-built measurement information feedback. Most
of the research efforts related to design-construction coordination only considered the
information flow from design to construction, while the as-built measurement
information feedback from construction to design was rarely discussed. The
shortcomings of these efforts lead to inefficient coordination. There is a clear need,
therefore, for an effective approach to address this crucial problem. The next chapter
will describe the proposed coordination model.
35
CHAPTER 3
MODEL DEVELOPMENT
3.1 WHY USE PRODUCT AS INTERFACE?
This research intends to coordinate design and construction. A proper
mechanism is very important to the success of coordination. Based on the coordination
theory which deals with the interdisciplinary study of coordination, the
interdependence between activities can be analyzed in terms of common objects
(Malone and Crowston, 1990). In reality, product is the common link between design
and construction.
Product contains static project information. The basic objects in a product are
components, which can be in different abstraction levels such as system level,
subsystem level or individual entity level. In practice, design work and construction
work are all related to these components. Designers typically break down complex
design work into many parts, each of which is concerned with a set of specific and
meaningful product components. Detailed design tasks are based on these product
components. On the other hand, the construction work is also closely related to the
product components since the completion of a component or system of components
can be considered as the result of many relevant construction activities. It can be seen
that product is the common object for design and construction. The product, thus,
serves as the interface for coordinating design and construction. Figure 3.1 shows the
relationship between design/construction and the related product information. Since
product is used to describe static project information, design and construction results
can be recorded in product as product-design and product-construction information,
respectively. Design tasks treat product-design information as input/output, which is
36
the basis to form design network. Similarly, construction network can be formed by
using product-construction information as input/output of construction tasks. In
addition, relationships also exist between design and construction in that construction
tasks need design result information as prerequisite and design tasks may require
construction result information as feedback.
produce Construction
Process
Product-Construction Information
Figure 3.1 Relationship between Design/Construction and Product
3.2 HOW TO REALIZE THE PRODUCT-ORIENTED COORDINATION?
As described, product can serve as the interface for the coordination between
design and construction. The realization of product-oriented coordination is through
parameters in that any product component can be described by a set of parameters
corresponding to different properties of the component. During the project, the design
activities are concerned with the identification, estimation and iterative refinement of
these parameters, until a sufficient level of confidence in these parameters is achieved
Product-Design Information
contain affect
produce Design Process
Product
37
while construction activities realize these parameters based on their values determined
in the design stage.
Parameters play an important role in the coordination. They are not only
closely related to product, but also important to depict design and construction. To
representing design and construction, activity-based description and parameter-based
description are introduced in this study. Both types of descriptions are very useful and
insightful in different ways.
Activity-based representation provides an overview of a process. It makes
people have a clear understanding of what should be done to achieve the goal.
However, activity-based description has some limitations such as the lack of flexibility.
In activity-based representation, all the activities are predefined. It is well known that a
design process is flexible in that a variety of design activities can be defined to achieve
the design goal. Furthermore, activity-based representation aims to form design
activities network, while the relationships among the parameters cannot be represented
clearly. In activity-based representation, a design activity is characterized by a group
of parameters as input and another group of parameters as output. For one activity, it
seems as if the group of output parameters depends on the group of input parameters.
In reality, the relationships between the individual parameters are missed. In addition,
activity-based representation may provide a “false” sense for inter-activity information
transfer. In activity-based representation, if the output parameters of some former
activities are connected to a latter activity, it means that the latter activity depends on
those output parameters of the former activities. Sometimes this may not be true. The
real parameter that the latter activity depends on may be the derived parameter of those
dependent parameters. Generally, the derivation relationship is embedded in the latter
activity.
38
P3
P1
Figure 3.2 Activity and Parameter
ACTIVITY 1 P2
P1 P3
P4
P2
P4
ACTIVITY 1
ACTIVITY 3
ACTIVITY 2
P1
P2
P5
P3
P4
P1
P2
P3
P4
P5 P
(a)
-------------------------------------------------------------------------------------------------
(b)
-------------------------------------------------------------------------------------------------
39
Figure 3.2 shows activity-based representation and the real parameter
relationships. In this figure, (a) is the representation of individual activity and intra-
activity parameter relationships. From activity-based representation, it can only be
known that (P3, P4) depends on (P1, P2), while the real dependency is missed. (b) is
the representation of several related activities and inter-activity parameter relationships.
In the activity-based representation, “P5” depends on “P3” and “P4”. In reality, “P5”
depends on “P” which is derived from “P3” and “P4”. In this case, “P” is an implicit
parameter embedded in “ACTIVITY 3”.
With regard to a construction process, the general activity-based representation
is also inadequate for design/construction coordination. In the traditional construction
network, the as-built measurement information cannot be described clearly. In reality,
the as-built measurement information can also be represented from parameter
viewpoint.
Thus, to improve coordination, parameter relationships need to be explicitly
represented in sufficient level of detail. This would depend on the interface between
the different disciplines or teams. Parameter-based description documents the
relationships between individual parameters. Parameter-based description is very
important for coordination analysis since the information transfers between design and
construction (design information or as-built measurement information) are generally
parameter-based interactions. Furthermore, parameter-based representation supports
reorganizing of parameters based on the dependencies to form new activities, which
makes it more flexible.
It can be seen that activity-based description and parameter-based description
are complementary to each other. The former is strong in providing overall view but
inflexible and ignores too many important technical details, while the latter documents
40
the detail relationships for parameters and supports flexible formation of process
elements but lacks the overall context. The combination of these two viewpoints can
enhance the coordination efficiency.
3.3 MODEL FRAMEWORK
Based on the previous analysis, the model is established which is composed of
four main parts, namely, parameter, product, design and construction. Product is
described by parameters while design determines the values of these parameters, which
will then be realized by construction. Figure 3.3 shows the basic structure of the model.
Product
describe
Parameter
realize
Design
determine
Construction
Figure 3.3 Basic Structure of the Model
A building product is composed of many inter-related components. A product
component can be a system, a subsystem, a structural frame, an individual entity such
as a column, a beam. Figure 3.4 shows the hierarchical structure of a building product.
It should be pointed out that this structure is only one option for building product
decomposition. It is possible for a building product to have other kinds of hierarchical
structures.
41
--------------
Figure 3.4 Hierarchical Decomposition of Building Product
A component can be described by a set of parameters corresponding to its different
properties. For a parameter, it goes through evolution during design and construction.
That means it can be in different conditions with the progress of a project. The concept
of ‘state’ is used to represent various status of a parameter. The state transformations
correspond with different process activities in design and construction. The state
description is useful for process analysis since a process activity is characterized by its
information inputs and outputs which can be represented using parameter states.
Furthermore, parameter states can group to form deliverables such as drawings, as-
built measurement information units and so on.
3.3.1 Product and Parameter
Parameters are used to describe product components. “Parameter” is a broad
term given to the key variables that define the product components, which provide a
Building
Structural system
Electrical system
Architectural system
……….
Foundation subsystem
Frame subsystem
Column Beam ……….
--------------
---------------
……….
Basic element
--------------Building
--------------
--------------System
--------------
--------------
Subsystem
42
better insight to the product. They cover various aspects of the product components
including physical properties (dimension, material), evaluation-related attributes (cost,
stress distributions), and so on. These key parameters are critical for the coordination
between design and construction.
Figure 3.5 Parameter Classification
Figure 3.5 shows the relationship between product components and parameters.
The parameters belonging to a component are called intra-component parameters since
they describe the properties of this component. The intra-component parameters are
classified into two types, namely, basic parameters and derived parameters. Basic
Derived Parameter
Basic Parameter
Component 1 Component 2
Derived Parameter
Intra-component Parameter Basic
Inter-component Parameter
Parameter
Derived Parameter
Derived Parameter
Basic Parameter
Basic Parameter
Component 3 Component 4
Derived Parameter
Intra-component Parameter
43
parameters are those defining the component’s basic characteristics, such as its
dimension, material properties. Derived parameters are derived from the basic
parameters. Generally, a derived parameter is the combination result of several basic
parameters. For example, weight of a component is a derived parameter. It can be
derived from dimension and material properties of the component which are basic
parameters. However, a parameter may involve several components. In that case, it is
termed inter-component parameter. Inter-component parameters are generally derived
parameters which are related to the basic parameters of different components (such as
the gap between a mechanical duct and an electrical duct). In this figure, four groups
of intra-component parameters are presented, which belong to four different
components. At the same time, interactions exist between these components in that
some inter-component parameters are produced by the parameters of these components.
A “derivation” relation is used to represent the relationship between basic parameters
and the derived parameter (Figure 3.6).
P1
Figure 3.6 Basic Parameter and Derived Parameter
All parameters undergo evolution during product design and construction,
which can be pictured by state chains. Generally, typical state chain for a basic
parameter can be described as (Initial As-proposed As-confirmed As-
designed As-built As-built measured) (Figure 3.7).
[Derivation] P3
P2 P1, P2 – Basic parameters P3 – Derived parameter
44
Initial (0) Undefined
As-proposed (1)
Figure 3.7 State Chain of a Basic Parameter
Initial represents the undefined state of the parameter, which is the starting point of
design analysis. (As-proposed; As-confirmed; As-designed) are the states in design
stage while (as-built; as-built measured) are the states in construction stage. The state
transformations correspond with different process activities in design and construction.
Table 3.1 State Description State No.
Name Description
0 Initial Starting point of design analysis Undefined
1 As-proposed Preliminary determination of parameter value
2 As-confirmed Parameter value is checked and confirmed by involved designers
3 As-designed Parameter value is ready for construction use
Design stage
4 As-built The related component is constructed
5 As-built measured Measurement value of parameter
Construction stage
As-built measured (5)
As-confirmed (2)
As-designed (3)
As-built (4)
Design Activity Design
Stage
Construction Activity
Construction Stage
45
Table 3.1 provides description for these states. For a derived parameter, its states are
defined to match those of the basic parameters that derive it. As shown in Figure 3.8,
P3 is derived from basic parameters P1 and P2. If P1 and P2 are in state n, then P3 is
also in state n. This is generally the case since it ensures a coincidence between these
two kinds of parameters.
P1
n
Figure 3.8 State of a Derived Parameter
Parameter state chain provides clear evolution information for a parameter. At
the same time, it is also important for process analysis. In the traditional process
analysis, activity input and output are parameters rather than the states of parameters.
In reality, although several different activities need the same parameter, it is possible
for them to require a different status of the parameter.
Note that only the states in design and construction are shown since this
research aims to manage the interdependence between design and construction. A
parameter may have states in other stages of the project. Furthermore, the proposed
state chain for design and construction is only one option. It does not mean that all
parameters must undergo these states in any condition. For example, as-built measured
state only exists in such parameters whose as-built measurement information is useful
in coordination analysis. The intent of this research is to develop the basic concepts
P2
[Derivation] P3 “n” -- state n of the parameter
n
n
46
rather than all the possible states. The state chain proposed can be changed based on
real conditions.
3.3.2 Design Process and Parameter
Design is flexible in that design processes vary widely from one organization to
another reflecting the cultures of design teams. Individual design teams can follow a
multitude of design process models for a same design project. As a result, it is almost
impossible to use one process representation to support a wide range of design projects.
Thus, the design process description in this research is only one choice. It allows
customization to any firm. Since process evolution is closed related to state
transformations, different process representation may require different state chain.
Designers solve a design problem through a continuous refinement where the
designers expand the problem’s description by incorporating additional detail. Figure
3.9 shows the typical design process.
Generally, the design process is composed of three stages, namely, preliminary
determination, check and confirm, and drawing review. After check and confirm,
drawings will be produced. The drawings will then undergo review activity which
intends to generate approved drawing. The review task is generally conducted by
external parties including the main contractor, architects, engineers and design
consultants. This process is represented in case 1.
However, for those components requiring shop fabrication, the design process
is slightly different. In that case, the shop drawing review will be followed by an extra
stage -- fabrication design, which produces fabrication drawings. The fabrication
drawing design is controlled by the shop drawing design. Generally, the fabrication
drawings do not need to be reviewed. The design process including fabrication design
is shown in case 2.
47
Preliminary determination
Check and confirm
Approved drawing
Drawing Drawing Drawing review
Waiting for approval
Construction
Figure 3.9 Typical Design Process
Check and confirm
Shop drawing review
Approved drawing
Waiting for approval
Preliminary determination
Shop drawing
Construction
Fabrication design
Shop drawing Fabrication drawing
(a) Case 1
(b) Case 2
48
Based on this process, a design activity itself may take the form of a
“Preliminary”, a “Check”, a “Review” or a “Refine”, which correspond to preliminary
determination, check and confirm, drawing review and fabrication design, respectively.
These activities are responsible for the state transformations of a basic parameter in
design stage (Figure 3.10).
Initial (0) Initial (0)
Figure 3.10 State Transformations of a Basic Parameter in Design Stage
A “Preliminary” transforms a parameter from initial state (state 0) to as-proposed state
(state 1), which will be turned into as-confirmed state (state 2) by a “Check”. For the
transformation from state 2 to state 3, two conditions exist which correspond with the
two design processes described previously. In case 1, the as-confirmed state (state 2)
information of parameters can be grouped into drawings. These drawings will undergo
“Review” activities, which can be performed by designers or external parties.
“Review” updates the information in drawings so as to produce approved drawings
which contain the as-designed state (state 3) information of parameters. In case 2, the
As-proposed (1)
As-confirmed (2)
As-designed (3a)
Preliminary
Check
Review
As-designed (3b)
Refine
As-proposed (1)
As-confirmed (2)
As-designed (3)
Preliminary
Check
Review
(a) Case 1 (b) Case 2
49
as-designed state (state 3) is divided into two parts, namely states 3a and 3b. State 3a is
directly related to the reviewed shop drawings while state 3b is closely related to
fabrication drawings. From state 2 to state 3a, the procedure is similar to that of case 1.
However, there is a transformation from state 3a to state 3b in case 2, which is
completed by “Refine” activities. Thus, there are two typical state chains for design
stage, namely, (0 1 2 3) (case 1) and (0 1 2 (3a 3b)) (case 2).
As described, design activities are responsible for the state transformations in
design stage. However, a design activity may require external information to fulfill the
transformation function. The external information constraints may be produced by
other design activities, construction activities (as-built information feedback), or
external influences (loads). A design activity is characterized by its information inputs
and outputs. Different types of design activities have different types of information
inputs/outputs. Figure 3.11 and Figure 3.12 show the four kinds of design activities.
Background information
Figure 3.11 Preliminary and Check
P1
P2
P3 P4
External influence
1
1
0
Preliminary
n
1
2 2
Check
50
unreviewed unreviewed
Drawing 1 Drawing 2
Figure 3.12 Review and Refine
Shop drawing
P5 P7
Shop drawing
unreviewed
reviewed
2
3a
3b
Fabrication drawing 1
5
P1 P2 P3 P4
Drawing 1 Drawing 2
reviewed reviewed
2
3
222
33 3
(a) Case 1
(b) Case 2
P6
2
3a
Review
Review
3b
Refine 1 Refine 2
Fabrication drawing 2
51
For “Preliminary”, it transforms a parameter (such as P1) from the initial state (state 0)
to the as-proposed state (state 1). Generally, it needs “Background information” such
as general project information. In this respect, there seems to be a reliance on the
experience of designers. A “Check” is concerned with the evaluation of the as-
proposed state (state 1) based on component performance such as stress, deflection,
crack and so on. Other parameter states (such as P2 at state n) and “External influence”
(such as loads) may be involved in the “Check” activity. After “Check”, the as-
proposed state (state 1) is turned into as-confirmed state (state 2). For review, its input
and output are drawings — different states of drawings, namely “unreviewed” state
and “reviewed” state. Since drawings are connected with the states of parameters,
“Review” is related to parameter states (state 2 and 3 (3a)) indirectly. For the design
process involving fabrication design, “Refine” is responsible for parameter
transformation from state 3a to state 3b. As-built measurement information may be a
constraint for “Refine”. For example, “Refine 1” transforms P5 from state 3a to state
3b, which requires as-built measurement information, namely state 5 of P7.
It can be seen that other parameters may be involved in the state
transformations of a parameter. These external parameters may come from other
project participants. The source activities and participants of these parameters should
be found so that information responsibility can be clearly determined. These
interactions mostly happen in “Check” and “Refine” activities. For “Check”, the
involved state of other parameters may be the as-proposed state, the as-confirmed state,
the as-designed state or the as-built measured state depending on the project conditions.
Generally, later states give greater confidence for the parameter value. However, it
may take a longer time to obtain the parameter value of later states so that the related
activity is delayed. For “Refine”, it may involve as-built measured state (state 5) of
52
other parameters since refine represents the fabrication design which generally requires
exact pre-design information.
Generally, as-proposed state (state 1) is not allowed to be used to produce other
parameters, since it is only the estimated value of a parameter. However, sometimes it
is necessary to use the as-proposed state of a parameter to save time. Although it
sacrifices the exactness of the parameter and is in danger of rework, it saves much time
which is considered more important in some projects. In this situation, the designed
component based on estimation will have extra capacity to buffer downstream design
parameters, although this may not be economical. An obvious case in view is
foundation design. For foundation design, the weight of aboveground structure is a
parameter. Theoretically, only after the design of the aboveground structure is
completed can its weight be obtained. However, since the construction of the
foundation precedes that of the aboveground structure, the design of foundation should
be completed as early as possible to save time. Then the weight of the aboveground
structure can be estimated so that it can be used in foundation design.
Figure 3.13 shows an example for the application of as-proposed state. This
example is about the design of a column and its foundation. D, M and W represent the
dimension, material and weight of the column, respectively. Foundation design needs
the weight of the column, which is derived from its dimension and material. In the
figure, (a) shows the relationship between column parameters and foundation design.
This is the general representation for information dependence. (b) shows the
relationship based on column parameter states. In this case, foundation design needs
the as-confirmed state (state 2) of W, which is derived from the as-confirmed state
(state 2) of D and M. In contrast, (c) shows the use of state 1 in foundation design.
Under this situation, foundation design can start with an estimation of the column
53
D
[Derivation]
54
D
M
W
D – Dimension M – Material 1 – As-proposed state W – Weight 2 – As-confirmed state
Check Foundation
Design [Derivation]
M
W Foundation Design
(a)
(b)
(c)
1
1
2
2
D
M
W Check Foundation
Design [Derivation]
2
1
1
2
2
1
2
Figure 3.13 Application of As-proposed State
weight (state 1 of W). The use of state 1 makes design flexible, which is important to
the information coordination.
The preceding section has identified the different kinds of design activities and
explained the relationships between design activities and parameter states. To better
understand design, Figure 3.14 provides an overview for design. This figure includes
four kinds of design activities and two kinds of drawings described previously. It also
shows the formation of the different kinds of design drawings. “Preliminary” is
responsible for P1 and P2’s transformation from state 0 to state 1, which requires
“Background information” to fulfill the transformation function. The state 1 of P1 and
P2 is then turned into state 2 by “Check”. “External influence” and state 2 of P3 are
external constraints for “Check”. After “Check”, state 2 of P1 and P2 will form shop
drawing which is in “unreviewed” state. The “unreviewed” shop drawing undergoes
“Review” intending to produce “reviewed” shop drawing, which is related to state 3a
of P1 and P2. Two “Refine” activities exist in this figure. “Refine 1” transforms P1
from state 3a to state 3b. As-built measurement information is involved in “Refine 1”,
which is represented by state 5 of P4. State 3b of P1 forms fabrication drawing 1.
Similarly, “Refine 2” is responsible for P2’s transformation from state 3a to state 3b,
which is related to fabrication drawing 2.
3.3.3 Construction Process and Parameter
Construction management is not the focus of this research. The construction
activity network is deemed to be available. However, the traditional network is not
enough to be used in the coordination analysis. To cater for coordination use, the
design information and as-built measurement information need to be attached to the
construction network. Design information can be treated as input to construction
55
Background information
56
Shop drawing
P1
P4 Preliminary
Shop drawing
unreviewed
reviewed
2
3a3b
Fabrication drawing 1
5
External influence
Refine 1 Refine 2 P3
20 0
P2 3a 3b 1 1
2
Check
Review
Fabrication drawing 2
Figure 3.14 Design Process
network while as-built measurement information is the output of the construction
network serving as the input for design shop and fabrication drawings.
The as-built measurement information feedback plays an important role in the
coordination. Construction is the stage of parameter realization. The realized parameter
value may be different from what has been designed. Generally, a little deviation is
acceptable since all component parameters have allowable tolerance for their values.
However, it may be very serious for work requiring exact pre-design information such
as glass fabrication design in glass wall projects. This kind of design work needs actual
as-built information of the related components. In this case, the related components
must be constructed and the parameters are measured before the detailed design can
begin. This kind of dependency increases the complexity of the network since it means
that the design of a component depends on the construction finish of other components.
As-built measurement feedback is very important for components with long
procurement and fabrication times. For these components, they need to be designed as
early as possible. However, the required as-built information may not be available
when design is to start.
To manage the as-built measurement information feedback, a new kind of
activities is added to the traditional network. Since traditional construction activities
transform the product into reality, they are called “Conversion” activities in this model.
The new activities are called “Measurement”. Thus, design information can be
attached to conversion activities which are followed by measurement activities to
produce as-built measurement information. In this case, “Conversion” turns as-
designed state into as-built state while “Measurement” is responsible for the
transformation from as-built state of a parameter to as-built measured state (Figure
3.15).
57
As-designed
Figure 3.15 State Transformations of a Basic Parameter in Construction Stage
Certainly, the as-designed state can be state 3 or the combination of states 3a and 3b.
A construction activity is characterized by its information inputs and outputs
(see Figure 3.16).
Figure 3.16 Construction Activity and Input/Output
For a “Conversion” activity, its information constraints may include design
information, precedence constraints, resources and so on. Only design information is
Conversion P2 P1
Measurement
P4
P5
P6
P7
Measurement
[Derivation]
3 3
44
4 5
4
4
4 5
Conversion P3
4
3a
3b
As-built measured (5)
As-built (4)
Conversion
Measurement
58
modeled while other inputs are deemed to be available. The design information refers
to the as-designed state of parameters, which can be state 3 or the combination of state
3a and 3b. The output of a “Conversion” activity is the as-built state of parameters. In
this figure, state 3 of P1 and P2 is transformed into state 4 by “Conversion”. This
applies to projects which do not involve fabrication design. If fabrication design exists,
the as-designed state of the parameter (such as P3) is represented by states 3a and 3b.
Under this situation, “Conversion” transforms P3 from states 3a and 3b to state 4. For a
“Measurement” activity, its input is the as-built state of the parameter and output is the
as-built measured state of the parameter. Generally, as-built measurement is geometry-
related problems which may involve one component or several components. In other
words, the measured parameter may be an intra-component parameter or inter-
component parameter. For inter-component parameter, a “Derivation” relation exists.
In this figure, P4 and P7 are involved in measurement. P4 is an intra-component
parameter while P7 is an inter-component parameter which is derived from P5 and P6
(in state 4).
The as-built measured states of parameters are grouped into many units to be
released for design use. Figure 3.17 shows the formation of one as-built measurement
information unit. This figure includes two kinds of construction activities
(“Conversion” and “Measurement”) and a “Derivation” relation. “Conversion 1”
transforms P1 and P2 from state 3 to state 4 while “Conversion 2” is responsible for
P3’s transformation from states 3a and 3b to state 4. The state 4 of P1 is turned into
state 5 by “Measurement 1”. In addition, the state 4 of P4 is derived from the state 4 of
P2 and P3. P4 is an inter-component parameter. “Measurement 2” is responsible for
P4’s transformation from state 4 to state 5. The state 5 of P1 and P4 forms one “As-
built measurement information unit” which is used by design.
59
Figure 3.17 Construction Process
3.4 COORDINATION ANALYSIS
3.4.1 Form Original Network
The original network is formed by connecting the basic process activity--
parameter state relationships, which involves both design and construction. Figure 3.18
gives an example of the network. The network is parameter state centered while
activities are embedded in the state-state relationships. Since this network intends to
show activity—parameter state relationships, other items such as drawings and
external influences are excluded. Eight parameters are included in this figure. To
simplify the representation, only some states are displayed for these parameters. P1, P2,
P3 and P4 are involved in the design state analysis while the construction states of P6,
P7 and P8 are shown. P5 is included in both design and construction analysis. These
Conversion 1 P2 P1
Measurement 1
P4 Measurement 2
[Derivation]
3 3
44
5
4
5
Conversion 2 P3
4
3b
3a
As-built measurement information unit
controlDESIGN
60
[DC1]
61
P1
0
1
2
P2
2
1
P3 2
P5 2
1
P4
3a
1
2
P8 5
3
4 4P6 4
3
P7 5
4
0
0 0
[D1][DC1]
[DC1]
[DP1]
[DP2]
[DC1]
[DP3] [DP4] [DC3]
[DC3]
[DR1]
[DC2]
DESIGNSTAGE
[CC2][CC1][CC1]
[CC1][CC1]
[CM1]
[CM2]
[CC2]
[DF1]
[D2]
--------------
[DP1], [DP2], [DP3], [DP4] – Preliminary activities in design
[DC1], [DC2], [DC3] – Check activities in design
[DR1] – Review activity in design
[DF1], [DF2] – Refine activities in design
[CC1], [CC2] – Conversion activities in construction
[CM1], [CM2] – Measurement activities in construction
[D1], [D2] – Derivation relations
[DR1]
[DR1] [DR1]
3b
3a
3b
3b
3a
[DF2] [DF1]
P5
CONSTRUCTIONSTAGE
Figure 3.18 Original Network
parameters undergo state transformations with the action of relevant activities. At the
same time, interactions occur between the states of different parameters such as P4 and
P5, which are reviewed together. Relationships are also shown between design and
construction. For example, design information (states 3a and 3b) of P5 controls its
construction. As-built measurement information feedback is also displayed between P4
and P8. The state 5 of P8 is used to produce state 3b of P4.
3.4.2 Analyze and Manage the Network
The original network is inherently a network of information dependencies,
which presents the links between process activities and their information constraints. It
enables modeling of the information flow between process activities. In this way, the
information flow can be better coordinated and managed.
The coordination should insure that the required information for process
activities can be obtained on time. Because of the complexity of the dependence
relationships, it is not so easy to solve the information constraints for these activities.
The most frequently occurred coordination problems are information delays and loops
(iterations). Thus it is necessary to adjust the activities such that the availability of
information required is maximized and the number and size of iterative loops is
minimized. Generally, several approaches can be used to solve these coordination
problems:
1. Adjust time attributes of activities (start/finish time, duration)
This approach is effective in dealing with information delays. For example, the
start and finish time of the activities in the non-critical paths can be adjusted so that
these activities can release production information earlier.
2. Re-order activities
62
Some information coordination problems are caused because of inappropriate
work sequence. By re-ordering the activities, these problems can be solved.
Figure 3.19 shows the original plan and the dependency relationships for six
activities, namely A1, A2, A3, A4, A5 and A6. It can be seen that a big loop exists in
the original plan (A1 A2 A3 A4 A5 A6). This loop is due to the
interdependence between A2 and A5. In reality, the loop can be reduced by re-ordering
these activities.
Figure 3.19 Original Plan
Figure 3.20 shows the result after re-ordering. The loop is reduced through the re-
ordering of these activities.
Figure 3.20 Result after Re-ordering
In a project, there are many activities with complex relationships. The re-
ordering can be achieved with the help of the method of Design Structure Matrix
(DSM) (Yassine et al., 1999).
A3 A4
A5A2A1 A6
A3 A4 A5 A2 A6A1
63
3. Divide an activity into several sub-activities
In practice, one activity may involve several components, each of which has its
own parameters. Thus the output of this activity includes a group of parameters.
Generally, the output parameters are released together at the end of the activity. Before
its completion, some parameters are generated which may be required by another
design activity. This provides the opportunity to divide an activity into several sub-
activities, which produce the output parameters separately to cater for different needs.
This approach is generally used to solve information delays. But before this can be
exploited, a mapping of the parameter dependencies is required to adequately design
the sub-activities.
As shown in Figure 3.21, there are two activities, namely “Activity 1” and
“Activity 2”. P1, P2 and P3 are inputs of “Activity 1” while P4 and P5 are its outputs.
“Activity 2” depends on “Activity 1” in that “Activity 2” requires P4, which is one of
the output parameters of “Activity 1”.
Figure 3.21 Original Activities
From the activity perspective, the implied parameter dependencies for “Activity 1” are
as shown in Figure 3.22 (a). This means that delay in any of the parameters P1, P2 and
P3 will affect both P4 and P5 so that “Activity 2” is also delayed. However, the real
parameter dependencies may not be the same as those in Figure 3.22 (a). For example,
Activity 1
Activity P4 2
P2
P5 P3
P1
64
the real dependencies may be as shown in Figure 3.22 (b). In this case, P6 and P7 are
embedded in “Activity 1”. Actually, the real dependency network can be divided into
two sub-networks (see Figure 3.22(c)).
P1 P1
Figure 3.22 Parameter Dependencies in Activity 1
Based on the two sub-networks, the original “Activity 1” can be divided into two sub-
activities, namely, “Activity 11” and “Activity 12” (see Figure 3.23). For “Activity 11”,
its dependent parameters are P1 and P2 while its production is P4. For “Activity 12”,
its dependent parameters are P1, P2 and P3 while its production is P5. Now “Activity
2” depends on “Activity 11”. After the division, the delays for “Activity 2” can be
resolved. For example, the receipt of P3 is delayed for some reason. In the original
plan, this will retard the production of P4 so that “Activity 2” is also delayed. However,
P6
P7 P5
P4
P2
P3
P4
P6 P4
P2
P1 P6
P7
P5 P2
P1
P3
(a)
(c)
P5
P2
P3
(b)
65
with the new configuration based on the underlying parameter dependencies, P4 will
not be affected by P3. Thus, “Activity 11” can be performed earlier so that “Activity
2” will not be delayed.
Figure 3.23 Divide an Activity into Two Sub-activities
4. Use an earlier state
For a parameter, different states represent different values of the parameter
during design and construction. Although later states provide more exact information
for the parameter value, it may take a longer time to obtain them. Thus, using later
states may cause information delays. To solve these problems, earlier states can be
used. The earlier the state is, the sooner the related value can be obtained. Although it
sacrifices the exactness of the parameter, using an earlier state can produce the
required information sooner so as to solve information delays which is considered
more serious in some projects.
As shown in Figure 3.24, the as-design state (state 3) of parameter P1 provides
more exact information than the as-confirmed state (state 2) of parameter P1 since state
3 represents the parameter value after drawing review. However, review may take a
long time in some projects. Then the activity (“Check 2”) requiring the information
Activity 11
Activity 12
Activity P4 2
P2
P5
P3
P1
66
(state 3 of parameter P1) needs to put on hold to wait for the information. In reality, the
as-confirmed state (state 2) of parameter P1 can be used in “Check 2”, which is
produced in an earlier time. Under this situation, there should be a verification process
after the state 3 of P1 is obtained. If the difference between state 3 and state 2 of P1 is
not acceptable, then there will be rework for “Check 2”.
Figure 3.24 Use an Earlier State
3.5 CONCLUSION
This chapter introduces the proposed coordination model. This is the main part
of the dissertation. The model aims to improve the coordination between design and
construction. It has been developed using product information as the interface.
Parameters play an important role in the product-oriented coordination in that they are
employed to describe the properties of the product components. Furthermore, activity-
Check 1
P1 1 2
Review 1
P1 2 3
Check 2
P2 1 2
Check 1
P1 1 2
Review 1
P1 2 3
Check 2
P2 1 2
67
based representation and parameter-based representation are combined together to
depict design and construction processes. In addition, a new kind of activities is added
to the construction network to deal with as-built measurement information.
One of the most important characteristics of the model is that states are used to
represent the different status of parameters. Through the parameter states, relationships
can be established between design and construction activities. The whole dependence
network is formed by connecting these dependence relationships. By forming the
network, the model is capable of making information flows more explicit. Based on the
network, action can be taken to deal with information coordination problems. It should
be noted that the proposed approaches are not isolated. Effective coordination will be
achieved by fully considering all these approaches.
To illustrate the working principles of this model, the next chapter will present
one case study.
68
CHAPTER 4
CASE STUDY
A case is presented in this chapter to illustrate the working principles of the
proposed coordination model. This case is about the design and construction of a glass
wall, which is one part of a building. The original data for this case was taken from
Chen (2002).
The glass wall was completed by a glass wall specialist subcontractor. As a
small-sized specialist subcontractor, its information coordination problems are
comparatively simpler than those of the other bigger companies. However, it still
encountered many difficulties with regard to the coordination between design and
construction. The glass wall is selected for the case study because it is compact enough
to show the relationships between design and construction, thus providing a good
context for the application of the model.
4.1 INTRODUCTION
The glass wall is composed of two main parts — primary steel frame and
surface glass panel. Normally, the glass panels are supported by frames. Some
auxiliary components are necessary to fix glass panels such as bolts, spider clamps and
so on. Figure 4.1 exhibits the perspective views of the glass wall from both outside and
inside.
A typical glass wall project includes three main stages, namely, design,
fabrication and installation, which are related to each other (Figure 4.2). Since glass
wall system is a high-tech, complex, and high quality item, the design-build delivery
system was adopted by the specialist subcontractor to better maintain quality and
constructability. However, the fabrication work was subcontracted to a fabrication
69
company so that the glass wall specialist subcontractor can concentrate on the design
and installation work.
Figure 4.1 Perspective Views of a Glass Wall
Design
Fabrication
Installation
Figure 4.2 Glass Wall Project
70
The design stage is information-intensive, which needs a variety of technical
information as well as financial and controlling information coming from many kinds
of internal and external sources. The designer is responsible to provide qualified
drawings for fabrication and installation use. Generally, the glass wall design is
composed of shop drawing design and fabrication drawing design, which generate the
shop and fabrication drawings, respectively (see Figure 4.3).
Preliminary determination
Check and confirm
Approved drawing
Figure 4.3 Glass Wall Design
The fabrication drawing design is controlled by the shop drawing design. The shop
drawing design includes three processes, namely, “preliminary determination”, “check
and confirm”, and “shop drawing review”. After “check and confirm”, shop drawing
will be produced. Shop drawing will then undergo a review before it is approved. The
review task is generally conducted by external parties including the main contractor,
architects, engineers and design consultants.
The main fabrication tasks include glass and steel fabrication. Generally, the
fabrication work is conducted in the factory. Since fabrication is not the focus of the
case analysis, detailed information for fabrication will not be discussed.
Shop drawing review
Waiting for approval
Shop drawing
Fabrication design
Fabrication drawing
Shop drawing
Shop drawing design
Fabrication drawing design
71
Installation follows fabrication. Glass wall installation comprises two main
tasks -- steel installation and glass installation. Installation process can be executed
successfully only with a combination of needed resources and information, such as
design information, fabrication products, technical workers, and appropriate tools and
equipment under well-prepared site conditions. It should be noted that the installation
may affect the design by providing as-built measurement information.
4.2 INFORMATION FLOW ANALYSIS
In the glass wall project, design and installation are two crucial stages which
experienced a lot of information flow problems. Figure 4.4 presents the information
flows involved in this project. This figure provides an overview of the information
flows among project processes. Two kinds of information flows can be identified,
namely, internal information flow and external information flow.
4.2.1 Internal Information Flow
Internal information flow is related to the information relationships between
different processes within the glass wall project.
For the two sub-stages of glass wall design, shop drawing design provides
“approved drawing” to control fabrication drawing design including glass fabrication
design and steel fabrication design. At the same time, “approved drawing” is also used
to direct construction activities -- glass installation and steel installation. The
fabrication design is followed by fabrication and shipment before installation work.
Thus, both “approved drawing” and “steel fabrication drawing” influence the steel
installation. Similarly, the glass installation is affected by “approved drawing” and
“glass fabrication drawing”. The conventional viewpoint suggests that construction
72
External information constraints (1)
Glass wall shop drawing design
73
Steel installation
Steel fabrication
design
Glass installation
Glass fabrication
design
Glass fabrication & check
Glass shipment
to site
Steel shipment
to site
Steel fabrication & check
Approved drawing
External information
constraints (2)
Steel fabrication
drawing
Steel installation measurement
Glass fabrication drawing
Figure 4.4 Information Flows in the Glass Wall Project
should not start until the relevant drawings are ready. In this way, the design process
becomes the key constraint to the installation process.
However, the installation process also affects the design process by providing
as-built measurement information. In this project, the as-built measurement
information of steel frame is of great importance for the glass fabrication design. In
glass fabrication, any error in the fabrication drawings leads to failure and re-
fabrication. Thus, accurate fabrication drawing information is very essential to the
glass fabrication. Since the glass panels are to be installed in steel frame, the
information of steel frame is definitely necessary to determine accurate dimension
details for glass panels. Since steel frame installation is difficult to control due to site
complexity, the steel frame information can only be verified after the installation of
steel frame. The availability of “steel installation measurement” information is crucial
to produce accurate glass fabrication design that will not pose problems on site later.
One of the difficulties for this project lies in the glass fabrication design since it has
two critical internal constraints including “approved drawing” and “steel installation
measurement”.
4.2.2 External Information Flow
External information flow refers to the information constraints coming from
other project participants. Generally, a single project involves many participants
working together to complete the project successfully. Inter-participant information
interference is inevitable. It is impossible for a participant to finish his part of the work
without relying on information of other participants.
Since the glass wall is only one part of a building, it has close relationship with
the work of some other participants. The external information constraints of Figure 4.4
are shown in Figure 4.5.
74
1. Relevant background drawings and specifications
2. Wind tunnel test report
3. Review comments
Figure 4.5 External Information Constraints
There are seven external information items. These information items are classified into
two groups, which control glass wall shop drawing design and glass wall fabrication
design, respectively. The glass wall shop drawing design is very complex in that it is
dependent on six external information items, namely, “relevant background drawings
and specifications”, “wind tunnel test report”, “review comments”, “stone fixing detail
for involved columns”, “size and location of air-con ducts”, and “size and location of
sunshade motor and housing”. The fabrication design also requires one external
information constraint -- “site measurement of steel beam installation”.
These information items come from many other participants. If the
relationships among the different participants are not well linked, effective information
coordination is difficult to achieve. Table 4.1 provides the source activities and
responsible participants for these external information items.
4. Stone fixing detail for involved columns
5. Size and location of air-con ducts
6. Size and location of sunshade motor and housing
7. Site measurement of steel beam installation
External information constraints (1) ==
==External information constraints (2)
75
Table 4.1 External Information Constraints No. Description Source activity Responsible participant
1 Relevant background drawings and specifications
Subcontract award
Main contractor
2 Wind tunnel test report Wind tunnel test RWDI consultant
3 Review comments Shop drawing review
Architect, engineer and consultant
4 Stone fixing detail for involved columns Shop drawing
design Stone work contractor
5 Size and location of air-con ducts Shop drawing design
HVAC contractor
6 Size and location of sunshade motor and housing Shop drawing deign
Facility supplier
7 Site measurement of steel beam installation Steel beam installation
Steel work contractor
It can be seen that these items are produced by seven different external activities
including “subcontract award” (main contractor), “wind tunnel test”(RWDI
consultant), “shop drawing review”(architect, engineer and consultant), “shop drawing
design”(stone work contractor), “shop drawing design”(HVAC contractor), “shop
drawing design”(facility supplier), and “steel beam installation”(steel work contractor).
Through these information links, the activities in the glass wall can be
connected with the relevant external activities. Figure 4.6 presents the task links for
inter-participant information dependencies. Since these external constraints affect the
design stage of the glass wall, only design activities are shown for the glass wall. Since
glass wall shop drawing design includes three processes, its six external information
constraints are linked to the corresponding processes. The “relevant background
drawings and specifications” provides background information to “preliminary
determination” while “review comments” is incorporated into “drawing review”. The
remaining four items are connected with “check and confirm” including “wind tunnel
test report”, “stone fixing detail for involved columns”, “size and location of air-con
76
77
ducts”, and “size and location of sunshade motor and housing”. In fabrication design
stage, the information item “site measurement of steel beam installation” affects both
“glass fabrication design” and “steel fabrication design”. Among the glass wall
processes, “check and confirm” has the most external constraints with 4 external
information items, three of which are related to the shop drawing designs of other
participants. It should be noted that the procedure of these external shop drawing
designs is similar to that of the glass wall shop drawing design stage (see Figure 4.7).
Preliminary determination
Check and confirm
Approved drawing
Shop drawing Shop
Figure 4.7 Procedure for External Shop Drawing Design
Although all the seven information items are important for the project, the
analysis will focus on “stone fixing detail for involved columns”, “size and location of
air-con ducts”, “size and location of sunshade motor and housing” and “site
measurement of steel beam installation” since problems that often occur are related to
these items.
Efficient information flows are difficult to achieve due to the complexity of the
information dependencies. Problems occurred in this project because of inappropriate
management of internal and external information flows. Thus, information
coordination is very important and necessary for the glass wall subcontractor to resolve
these problems.
review
Waiting for approval
drawingShop
drawing
Construction
78
4.3 MODEL FRAMEWORK
4.3.1 Identification of Key Parameters
Many components are involved in this project. Parameters are identified based
on these components. For the glass wall, there are two main components, namely, steel
frame and glass panel, each having one parameter. The relevant external components
and parameters are also very important since they are related to the external
information flow. All the main components and parameters involved in the project are
provided below in Table 4.2.
Table 4.2 Parameter Identification Description Component Parameter 1 Steel
frame S
D(S)
(dimension detail of steel frame) 2
Glass wall Glass
panel G D(G)
(dimension detail of glass panels) 3 Stone
work C D(C)
(Stone fixing detail for involved columns) 4 Air-con
duct H D(H)
(Size and location of air-con ducts) 5 Facility
work F D(F)
(Size and location of sunshade motor and housing) 6
Relevant external
work
Steel beam
B D(B) (dimension detail of steel beam)
Six parameters are identified based on the corresponding components. The two
parameters D(S) and D(G) are used to describe the dimension properties of the glass
wall steel frame and glass panel, respectively. The other four parameters, namely D(C),
D(H), D(F) and D(B), are related to the external work. These parameters are not all the
parameters of the relevant components. Generally, other parameters such as material
properties, have been determined in previous stages. All the identified parameters are
intra-component parameters in that each of them only involves one component.
Furthermore, they are basic parameters since they describe the basic properties of the
relevant components.
79
Initial (0)
Figure 4.8 State Chain of D(S)
These parameters undergo state transformations during design and construction.
As shown in Figure 4.8, state chain for parameter D(S) can be described as
Initial (0) As-proposed (1) As-confirmed (2) As-designed (3a-3b)
As-built (4) As-built measured (5)
As shown in Figure 4.9, state chain for parameter D(G) can be described as
Initial (0) As-proposed (1) As-confirmed (2) As-designed (3a-3b)
As-built (4)
D(S) has as-built measured state (state 5) while as-built measured state is not involved
in D(G).
As-proposed (1)
As-built measured (5)
As-confirmed (2)
As-designed (3a)
Undefined
Preliminary
Check Design Stage
Construction Stage
Review
As-designed (3b)
Conversion
Refine
As-built (4)
Measurement
80
Initial (0)
Figure 4.9 State Chain of D(G)
The external parameters, namely, D(C), D(H), D(F) and D(B), provide external
information constraints for the glass wall design. They also have state chains. Since the
evolution of these parameters is not the focus of this case analysis, their state chains
will not be shown. The involved states for D(C), D(H), D(F) are as-confirmed state
(state 2) and as-designed state (state 3), which represent design information of these
parameters. However, the as-built measured state (state 5) of D(B) is included in the
case analysis, which provides as-built measurement information.
4.3.2 Analysis of Design Process
The glass wall design is composed of two stages – shop drawing design and
fabrication drawing design. Furthermore, the shop drawing design includes three
processes, namely, “preliminary determination”, “check and confirm”, and “shop
drawing review”. Thus, all the four kinds of design activities, namely “Preliminary”,
As-proposed (1)
As-confirmed (2)
As-designed (3a)
Undefined
Preliminary
CheckDesign Stage
Construction Stage
Review
As-designed (3b)
Conversion
Refine
As-built (4)
81
“Check”, “Review” and “Refine”, are involved in the glass wall design. Table 4.3
shows all the design activities for glass wall. Since the design of steel frame and the
design of glass panels are tightly coupled in the shop drawing design stage, they are
combined together for “Preliminary”, “Check” and “Review”.
Table 4.3 Design Activities No. Name Type Description
1 DP Preliminary Preliminary determination of steel frame and glass panel dimension
2 DC Check Check and confirm for steel frame and glass panel dimension
3 DR Review Shop drawing review
4 DF1 Refine Steel frame fabrication design
5 DF2 Refine Glass panel fabrication design
Glass wall
These activities are characterized by their information inputs/outputs which can
be described using parameter states. Figure 4.10 shows the activities and their
relationships with parameter states in the glass wall shop drawing design. The
preliminary activity “DP” is responsible for D(S) and D(G)’s transformation from
initial state (state 0) to as-proposed state (state 1), which is then turned into as-
confirmed state (state 2) by the check activity “DC”. “DC” needs external information
which is represented by as-designed state (state 3) of D(C), D(H) and D(F). The state 2
information of D(S) and D(G) can be grouped into shop drawings. These drawings will
undergo review activity “DR”, which is performed by external parties. “DR” updates
the information in drawings so as to produce approved drawings which contain the as-
designed state (state 3a) information of D(S) and D(G). For review, its input and
output are different states of drawings, namely unreviewed state and reviewed state.
Since drawings are connected with the states of parameters, “DR” is related to state 2
and 3a of D(S) and D(G) indirectly.
82
D(S)
0
DP
0
D(G)
1 1
DC
DR
Shop drawing
Shop drawing
unreviewed
reviewed
D(S)
2
D(G)
2
1 1
D(S)
3a
2
D(G)
3a
2
D(C)
3
D(H) D(F)
3 3
State: Activity: State 0: Initial DP: (Preliminary) Preliminary determination State 1: As-proposed state of steel frame and glass panel dimension State 2: As-confirmed state DC: (Check) Check and confirm for steel frame State 3a: As-designed state and glass panel dimension (for shop drawing) DR: (Review) Shop drawing review
Figure 4.10 Glass Wall Shop Drawing Design
83
Figure 4.11 shows the activities and their relationships with parameter states in
the glass wall fabrication drawing design. Two refine activities exist in the glass wall
fabrication drawing design. Refine may involve as-built measured state (state 5) of
other parameters since it represents fabrication design which generally requires exact
pre-design information. The steel frame fabrication design “DF1” is responsible for
D(S)’s transformation from as-designed state (state 3a) to as-designed state (state 3b).
It needs as-built measurement information which is represented by as-built measured
state (state 5) of D(B). The steel fabrication drawing is related to the state 3b of D(S).
Similarly, glass panel fabrication design “DF2” transforms D(G) from state 3a to state
3b. The involved as-built measurement information for “DF2” is described using state
5 of D(B) and D(S). State 3b information of D(G) will form glass fabrication drawing.
Figure 4.11 Glass Wall Fabrication Drawing Design
D(G)
D(S)
3a
3b
DF2
Fabrication drawing 2
5D(S)
3a
3b
DF1
Fabrication drawing 1
D(B) D(B)
55
State: Activity: State 3a: As-designed state DF1: (Refine) Steel frame fabrication design (for shop drawing) DF2: (Refine) Glass panel fabrication design State 3b: As-designed state (for fabrication drawing) State 5: As-built measured state
84
4.3.3 Analysis of Construction Process
struction activity may be a “Conversion” or
“Measu
No. Name Type Component
As described in Chapter 3, a con
rement” activity. These two kinds of activities exist in steel work since the site
measurement of the steel frame is necessary for the glass fabrication design. However,
only conversion activity is involved in glass work because the as-built measurement
information of glass panels is not very important for the case analysis. In addition, the
steel beam construction is also relevant to this case study. Since the steel beam
supports the steel frame for the glass panels, the measurement information after steel
beam installation is crucial to steel frame and glass fabrication design. Thus, the
construction activities for the steel beam include “Conversion” and “Measurement”.
Table 4.4 shows the construction activities for these components.
Table 4.4 Construction Activities Description
1 CC1 Co n Steel frame instanversio llation
2 CC2 Conversion Glass panels installation
3 CM1 Measurem frame installation
Glass wall
ent Site measurement of steel
4 CC Conversion Steel beam installation
5 CM Measurem beam installation Steel beam ent Site measurement of steel
A “Conversion” activity transforms parameters from as-designed state (state 3
or the c
state 4. “CC1” precedes “CC2” based on the construction precedence relationship.
ombination of 3a and 3b) to as-built state (state 4), which will be turned into as-
built measured state (state 5) by “Measurement” activity. Figure 4.12 shows the glass
wall construction activities and their relationships with state transformations. The steel
installation activity “CC1” is responsible for D(S)’s transformation from states 3a and
3b to state 4, which is changed to state 5 by the site measurement of steel installation
“CM1”. The glass installation activity “CC2” transforms D(G) from states 3a and 3b to
85
Figure 4.12 Glass Wall Construction Activities
The parameter sta tivities of the steel
eam are provided in Figure 4.13. The steel beam installation “CC” is responsible for
D(B)’s
gu 3 teel Beam Construction Activities
4.4 COORDINATION ANALYSIS
.4.1 Form Original Network
Many activities are involved in this project. These activities are connected
through parameter states. A network is formed by connecting the relationships (Figure
4.14).
te transformations for the construction ac
b
transformation from as-designed state (state 3) to as-built state (state 4) while
the as-built measurement “CM” turns state 4 into as-built measured state (state 5) for
D(B).
Fi re 4.1 S
4
D(B) 43
CC
D(B)4 5
CM
D(S)43a 3b D(G)
43a3b
CC1 CC2
D(S)4 5
CM1
86
87
D(S)
5
4
3a
2
1
0
D(G)
1
0
4
3a
2
[DP]
[DC]
[DR]
[DP]
[DC]
[DC]
[CONSTRUCTION PRECEDENCE]
[DR]3b 3b
[DF2]
(1)
(2)
External information constraints for glass wall shop drawing design
(1)
(2)
[DC]
[DF1] [DF2]
D(C)
3
D(H)
3
D(F)
3
D(B)
5
External information constraints for glass wall fabrication drawing design
==
==
==
==
Figure 4.14 Original Network
The network is parameter state centered while activities are embedded in the state-state
relationships. D(S) and D(G) undergo state transformations with the action of relevant
activities. The state trans rmations within D(S) and D(G) are not own since they are
easy to understand. At the same time, i c occ between the states of these
two parameters showing the dependencies of their design and construction. D(S) and
D(G) are tight coupled in the s p d
are presented between the states of D(S) and D(G) and those of the external parameters.
It can be seen that the as ed state (state 2) of D(S) and D(G) depends on the as-
designed state (state 3) of D(C), D(H) and D(F) while the as-built measured state (state
5) of D(B) affects the as-designed state
transformations for these external parameters are not shown since they are not the
focus of the case analysis. It should be noted that a construction precedence
relationship exists between the as-built state (state 4) of D(S) and the as-built state
(state 4) of D(G).
The dependency network is very complex. To make it easier to understand,
Figure 4.15 provides an alternative representation of the network. The relationships are
classified into two ps, ly design related relationship and construction related
relationship, which are represented by solid lines and dashed lines, respectively.
Design related relationship includes design interdependence and design dependence
while const ion t
measurement feedback. In this case, the design interdependence refers to the coupled
relationships between D(S) and D(G) in the shop drawing design stage. For external
constraints, they can be design related constraints or construction related constraints. In
this case, the as-designed state (state 3) of D(C), D(H) and D(F) is design related
fo sh
ntera tions ur
ly ho rawing design stage. In addition, relationships
-confirm
(state 3b) of D(S) and D(G). The state
grou name
ruct related relationship includes construction precedence and as-buil
88
constraint while the as-built measured state (state 5) of D(B) is construction related
constraint.
D(S)
D(B)
D(F) D(H) D(C)
D(G)
5 3b
4
3
2 2
3b
5
4
Design related relati
4.4.2 Analyze and Manage the Network
1. Coordination problems
In the beginning of project plan, information dependencies among the different
tasks cannot be fully taken into consideration because of the large number of tasks and
the complexity of the information relationships. Therefore, information problems may
occur due to unreasonable project plan. Figure 4.16 shows the traditional plan and
information dependencies between these activities.
Design interdependence Construction precedence
As-built measurement feedbackDesign dependence
onship: Construction related relationship:
4 4
5
Figure 4.15 General Representation of the Network
89
90
It should be noted that the information dependencies in this figure match those in
Figure 4.14. In this figure, only the design and installation activities are shown while
the fabrication activities are excluded since this figure aims to describe the information
flows between design and construction. From the activity perspective, the fabrication
will follow the fabrication design and precede installation.
(1) Problems related to internal information flow
A problem occurred in this case because of the as-built measurement
information feedback. In glass fabrication, any error in the fabrication drawings leads
to failure and re-fabrication. Thus, accurate fabrication drawing information is very
essential to the glass fabrication. Since the glass panels are to be installed in steel
frame, the information of steel frame is definitely necessary to determine accurate
dimension details for glass panels. Because steel frame installation is difficult to
control due to site complexity, its information can only be verified after the installation
of steel frame. The availability of steel installation measurement information is crucial
to produce accurate glass fabrication design.
Generally, glass fabrication design is followed by glass fabrication, which can
proceed only after the detailed fabrication drawing information is confirmed. Normally,
the fabrication of glass panels has a long lead time. Therefore, it is necessary to start
the fabrication design and fabrication of glass panels much earlier to avoid delay. In
addition, glass panels are fragile so that damages may occur in transportation, handling,
or installation. If the fabrication is performed earlier, the contractor will have time to
replace them in case of damage or mistake.
As shown in this figure, based on the information dependency, “CC1” and
“CM1” should be completed before “DF2” starts. This means that “DF2” has to be put
on hold to wait for the as-built measurement information. Under this situation, the
91
project schedule will be affected because of the long lead time for glass fabrication.
Thus, the dilemma is that the glass fabrication design “DF2” should start early to avoid
delay, but it cannot start until the as-built measurement information of steel frame (D(S)
at state 5) is obtained. This requirement for as-built information has often led to
schedule overruns in specialist work such as the glass wall specialist subcontractor. A
.
(2) Pro
e generally generated and released at the
end of
tate (state 5) of beam dimension (D(B)),
affects
proper method is then needed to resolve this problem
blems related to external information constraints
Based on the traditional plan presented above, two groups of information
delays can be identified from external information constraints.
---- Information delays for glass wall shop drawing design
Check activity “DC” in the glass wall shop drawing design depends on the
availability of three external information items relating to the shop drawing design of
stone work contractor, HVAC contractor and facility supplier. In this project,
information delays are identified for “DC” due to the late receipt of these external
information items. These information items ar
the relevant shop drawing designs. Generally, shop drawing design includes
drawing review and revision. This means that “DC” is delayed because it cannot get
the information related to as-designed state (state 3) of D(C), D(H) and D(F) as early
as it should.
---- Information delay for glass wall fabrication design
Regarding the glass wall fabrication design, the site measurement of steel beam
installation, namely the as-built measured s
both steel fabrication design “DF1” and glass fabrication design “DF2” since
the steel beam supports the steel frame for the glass panels. In this case, both ‘DF1”
and “DF2” were often delayed because of the late receipt of state 5 of D(B).
92
93
2. Solutions for these coordination problems
The preceding section has identified and explained the existing information
coordination problems in the glass wall project. Proper measures should be taken to
improve the flows of required information. Since information flows and project
processes are closely interrelated, appropriate adjustments of processes can be an
effective approach to alleviate the information coordination problems. Figure 4.17
shows the solutions for these coordination problems.
The approaches 2 and 3 described in the last chapter, namely “Re-order
activities” and “Divide an activity into several activities”, can be combined together to
deal with the as-built information feedback in the internal information flow. In reality,
the glass wall includes many different types of glass panels. Not all the glass panels
require the as-built measurement information of the steel frame. Based on their
different conditions, the glass panels can be classified into two groups—typical glass
panels and special glass panels. This means that the glass component “G” is divided
into two components, “G1” and “G2”, which are described by “D(G1)” and “D(G2)”,
respectively. Accordingly, glass fabrication design “DF2” is divided into two tasks
“DF21” and “DF22”. For the typical glass panels “G1”, the related fabrication design
“DF21” can be performed earlier because the glass panels in “G1” are comparatively
regular and do not need the as-built measurement information. However, since the
special glass panels in “G2” are very irregular or their related steel work is difficult to
control due to site complexity, their fabrication design “DF22” should be postponed
until steel frame installation “CC1” is finished and as-built measurement “CM1” is
taken. Resulting from this adjustment, the number of glass panels requiring as-built
measurement information is decreased so that less time is needed for their fabrication
94
design and subsequent fabrication. Thus, the project schedule could be better
accomm
g reviews took a long time and
were b
original network representation in Figure 4.15, D(G) is divided into D(G1) and D(G2).
odated.
To deal with the information delays for the check activity “DC” in the glass
wall shop drawing design, approach 4 suggested in the chapter 3, namely “Use an
earlier state” can be used. The delays are caused because of the late release of the as-
designed state (state 3) information of D(C), D(H) and D(F). Actually, the external
shop drawing designs were retarded because drawin
eyond the control of the glass wall specialist. Since the glass wall shop drawing
design is not so sensitive to the external parameters as the glass fabrication design, the
as-confirmed state (state 2) of D(C), D(H) and D(F) can be used which is produced
before drawing reviews. Although it sacrifices the exactness of these parameters and is
in danger of rework, it saves much time which is considered more important in this
project.
For the information delay related to steel fabrication design “DF1” and glass
fabrication design “DF2”, approach 1, namely “Adjust time attributes of activities”,
can be employed. This delay occurred because the as-built measured state (state 5) of
D(B) cannot provide timely information to “DF1” and “DF2”. Since the steel beam
installation and subsequent site measurement are not on the critical path, it is then
possible and practical to do some adjustments on them. Then the steel work
subcontractor can shift the steel beam installation and subsequent site measurement to
an earlier time so that they can be accomplished prior to the time as required. Thus the
information delay problem can be resolved.
Figure 4.18 shows the parameter dependency network after these adjustments.
This network focuses on the interactions among these parameters. Compared with the
95
96
D(S)
D(F) D(H) D(C)
D(G2)
5
D(B)
3b
4
2 2
2
4
3b
5
Design interdependence Construction precedence
As-built measurement feedbackDesign dependence
Design related relationship: Construction related relationship:
4 4
5
D(G1)
4
2
3b
Figure 4.18 Parameter Dependency Network after Adjustments
Since the steel frame and the glass panels are tightly coupled in the shop drawing
design stage, design interdep e exis een D G1) and D(G2). Because
the steel frame should be constructed before the installation of all the glass panels, the
as-built state (state 4) of D(S) provides cons aints to the as-built state (state 4) of
D(G1) and D(G2). For the two groups of glass panels, only the fabrication design of
the special panels (G2) requires the as-built measurement information of the steel
frame. Thus, the as-designed state (sta of D(G2) depends on the as-built
measured state (state 5) of D(S). For external information items, the as-confirmed state
(state 2) instead of the as-designed state (state 3) of D(C), D(H ) and D(F) provides
constraints to the as-confirmed state (state 2) of D(S), D(G1) and D(G2) while the as-
built measured state (sta fects the as-desig e (state 3b) of D(S),
D(G1) and D(G2).
By applying the proposed approaches, all the existing information coordination
problems have been successfully eliminated. Although these amendments look simple,
they are very useful in reality. Successf prove the information
coordination to a great extent. The proposed model for representing parameter
dependencies in design and construction enables the information related flows between
design and construction activities to be better understood and represented so that the
p be exploited. approaches did
change the involved participants’ original plans and schedules to some degree.
Although this kind of changes may lead to ome delays or ex if
the damage cause on-related issues is mo
4.5 CONCLUSION
A case is presented in this chapter to show the coordination between design and
construction of a glass wall. The case study he
endenc ts betw (S), D(
tr
te 3b)
te 5) of D(B) af ned stat
ul application will im
roposed approaches can It is also evident that these
s tra costs, it is necessary
d by the informati re serious.
provides a clear understanding of how t
97
coordination model works. The suggested model makes the relationships between glass
wall design and construction explicit by using parameter states. Through parameter
dependency network, the information flows are clearly displayed for the glass wall.
Thus, the information coordination problems can be identified easily. The suggested
coordination approaches are employed to solve these problems successfully. The case
indicates that the coordination model is effective in dealing with design-construction
coordination issues so as to enhance the project efficiency.
However, this case is only about a small project. Not all the concepts are shown
for the coordination model. In reality, AEC projects may be much more complex than
the glass wall. There will be more parameters involved in the projects. Accordingly,
the parameter dependency network will become more and more complicated with the
increase in the number of parameters and states. Although the coordination model
applies
to them, more attention should be paid in the application.
Up to now, the main work for the proposed model has been described. The next
chapter will conclude the dissertation with an overview of the model.
98
CHAPTER 5
CONCLUSIONS AND RECOMMENDATIONS
5.1 CONCLUSIONS
Design and construction are two of the most important stages in the lifecycle of
an AEC project. Traditionally, the AEC industry has separated these two stages. In
recent years, design-build has been proposed as an optimal project delivery approach,
which tries to integ
and construction. The coordination model
eters play an important role in the product-oriented coordination in that any
roduct component can be described by a set of parameters corresponding to different
roperties of the component. At the same time, parameters are also important to depict
esign process and construction process. Four types of design activities are identified
r design process, which are concerned with the determination of the parameters of
roduct components. In construction, these parameters are realized into reality by
onstruction activities. To deal with the as-built measurement information, a new kind
f activities is added to the traditional construction network.
One of the most important characteristics of the model is that states are used to
eters. The state transformations correspond with
rate design and construction. The success for design-build requires
careful consideration of the constraints that each stage puts on the other. Problems
often occur due to inappropriate management of these constraints. Thus, it is
imperative to improve the coordination between design and construction.
This research attempted to develop a model to coordinate design and
construction work. The model aims to manage the interdependence between design
has been developed employing product as
the interface since product is the common link between design and construction.
Param
p
p
d
fo
p
c
o
represent the different status of param
99
different process activities in des ion. The state representation is
useful fo rmation
puts and outputs which can be described using parameter states. Through the
ndency relationships can be established between design and
construction activities. Furtherm
ameliorate the relationship between requi
construction stage. Design is very com
ign and construct
r process analysis since a process activity is characterized by its info
in
parameter states, depe
ore, parameter states can group to form deliverables
(drawing, as-built measurement, etc.).
The whole dependency network is formed by connecting the basic process
activity--parameter state relationships. The network is inherently a network of
information dependencies which represents the links between process activities and
their information constraints. By forming the network, the model is capable of making
information flows more explicit. The fundamental purpose of coordination is to
red information flows and corresponding
process sequence. Several practical means have been suggested to deal with
information coordination problems. It should be noted that these approaches are not
isolated. Effective coordination will be achieved by fully considering all these
approaches. Although these approaches may lead to some changes to the original
project plan, it is worth doing if the coordination problems are more serious.
After the model was established, it was tested with one case. The case study
provided a clear understanding of how the coordination model works. Results
indicated that the coordination model is effective in dealing with design-construction
coordination issues so as to enhance the project efficiency.
The proposed model eases coordination analysis between design and
construction through the application of “state” to parameters for both design stage and
plex in that it is composed of many interrelated
sub-stages. By recording different design states of a parameter, the changes of the
100
parameter in design stage can be traced so that a better understanding of design
evolution is achieved. This is beneficial to design improvement. Furthermore, two
more states in construction stage are added to complete the evolution chain of a
parameter and support the construction and the as-built feedback. The as-built
information feedback is critical for the coordination analysis. Thus, by using parameter
states, the evolution of design and construction and the information flows between
design
5.2 RECOMMENDATIONS FOR FUTURE WORK
This model may be of great benefit to project managers who are always
frustrated by coordination problems. In AEC projects, coordination-related problems
often occur. Using this model, these problems may be settled with ease. Thus, the
application of the model may improve the effectiveness and efficiency of AEC projects.
However, it is very difficult to develop an all-inclusive model because of the wide-
ranging aspects of the AEC industry. Since the research and case study have been done
in Singapore, this model is most applicable to the AEC projects in Singapore.
Although the basic theories are common, the model may need some modifications to
cater for different conditions when applied in other countries because of the difference
in work flow.
Parameters play an important role in the proposed model. This model focused
on the parameter dependency relationship. However, the attributes of parameters have
not been addressed, which include the range of the parameter value, the degree of ease
for estimation, and so on. These attributes provide a better understanding for
parameters and direct the parameter state utilization. Actually, the attributes of
parameters were discussed in the Process-Parameter-Interface (PPI) model (Chua et al.,
and construction are represented clearly so that the coordination between these
two stages can be achieved easily.
101
2003). The proposed model in this study can be further developed to incorporate
parameter attributes so as to improve the coordination efficiency.
It is also noted that the proposed parameter dependency network can be quite
cumbersome with the increasing number of parameters and states. Although the
conventional terms in network models can be used to define the problem, it is very
difficult to represent a dependency network clearly with so many parameters and states
using conventional network model. Consequently, an alternative more compact
representation was employed in the case study without losing information on the
parameter state dependencies from design and construction perspectives. Further work
should be done in this alternative representation so that the interdependencies of design
can be better encapsulated in the proposed model.
This research proposed the model aiming at improving the coordination
between design and construction by managing the information flows. The research
work focused on developing the ideas. However, this research did not develop
applicable software to facilitate the process of coordination. In order to realize an
extensive implementation of the proposed model, an intelligent software prototype
should be developed in further research so that the information transformations can be
achieved automatically. If the proposed framework can be further integrated with a
feature-based CAD design platform, the changes in the parameters can be
automatically captured and shared.
102
REFERENCES Ahmad
Austin,
in Proceedings of the ICE: Civil Engineering, Vol. 138(4), pp.177-182, 2000a
Austin, S., Baldwin, A., Li, B. and Waskett, P. Analytical design planning technique
process, Construction Management and Economics, Vol. 18 (2), pp.173-182,
Waskett, P. Application of the analytical design planning technique to construction project management, Project Management Journal, Vol. 31(2), pp.48-59, 2000c
iedermann, J.D. and Grierson, D.E. A generic model for building design, Engineering with Computers, Vol.11, pp.173-184, 1995
jork, B.-C. Basic structure of a proposed building product model, Computer-Aided Design, Vol.21(2), pp.71-78, 1989
Bjork, B.-C. A unified approach for modelling construction information, Building and
Environment, Vol.27(2), pp.173-194, 1992a
i, R., Roemer, T.A. and Wang, R.H. Structuring product development processes, European Journal of Operational Research, Vol. 130, pp.539-558, 2001
Albino, V., Pontrandolfo, P. and Scozzi, B. Analysis of information flows to enhance
the coordination of production processes, International Journal of Production Economics, Vol. 75, pp.7-19, 2002
Andery, P., Vanni, C. and Borges, G. Failure analysis applied to design optimisation,
in Proceedings of IGLC-8, Brighton, United Kingdom, 2000 Anumba, C.J. and Evbuomwan, N.F.O. A concurrent engineering process model for
computer-integrated design and construction, in Proceedings of the International Conference on Information Technology, Glasgow, UK, 1996
Anumba, C.J., Ugwu, O.O., Newnham, L. and Thorpe, A. Collaborative design of
structures using intelligent agents, Automation in Construction, Vol. 11, pp.89-103, 2002
S., Baldwin, A., Li, B. and Waskett, P. Analytical design planning technique for programming building design, in Proceedings of the ICE: Structures & Buildings, Vol.134, pp.111-118, 1999a
Austin, S., Baldwin, A., Li, B. and Waskett, P. Analytical Design Planning Technique:
a model of the detailed building design process, Design Studies, Vol. 20 (3), pp.279-296. 1999b
Austin, S., Baldwin, A., Li, B. and Waskett, P. Integrating design in the project process,
(AdePT): a dependency structure matrix tool to schedule the building design
2000b
Austin, S., Baldwin, A., Li, B. and
B
B
103
Bjork, B.-C. A conceptual mode aries and enclosing structures, Automation in Construction
, 1989
Chen, ordination within and among Specialty Subcontractors,
Master’s thesis, National University of Singapore, 2002
Chen, Q Proceedings of IGLC-11, Virginia Tech, Blacksburg, Virginia, USA, 2003
Choo,
hoo, H.J., Tommelein, I.D., Ballard, G. and Zabelle, T.R. WorkPlan: constraint-based
Chua, ournal of Construction Engineering and
hua, model for identifying
l of spaces, space bound, Vol. 1(3), pp.193-214, 1992b
Bjork, B.-C. RATAS project -- developing an infrastructure for computer-integrated
construction, Journal of Computing in Civil Engineering, Vol. 8(4), pp.401-419, 1994
Bjork, B.-C. and Penttila, H. A scenario for the development and implementation of a
building product model standard, Advances in Engineering Software and Workstations, Vol.11(4), pp.176-187
Bogus, S., Songer, A.D. and Diekmann, J. Design-led lean, in Proceedings of IGLC-8,
Brighton, United Kingdom, 2000 Boujut, J.-F. and Laureillard, P. A co-operation framework for product-process
integration in engineering design, Design Studies, Vol.23, pp.497-513, 2002 Brazier, F.M.T., Moshkina, L.V. and Wijngaards, N.J.E. Knowledge level model of an
individual designer as an agent in collaborative distributed design, Artificial Intelligence in Engineering, Vol.15, pp.137-152, 2001
Browning, T.R. Applying the Design Structure Matrix to system decomposition and
integration problems: a review and new directions, Ieee Transactions on Engineering Management, Vol. 48(3), pp.292-306, 2001
Burkett, W.C. and Yang, Y. The STEP integration information architecture,
Engineering with Computers, Vol. 11(3), pp.136-144, 1995
Q. Information Co
., Chua, D.K.H. and Song Y. Information flow integrated process modeling, in
H.J. and Tommelein, I.D. WorkMovePlan: database for distributed planning and coordination, in Proceedings of IGLC-8, Brighton, United Kingdom, 2000
Cdatabase for work package scheduling, Journal of Construction Engineering and Management, Vol. 125(3), pp.151-160, 1999 D.K.H., Shen, L.J. and Bok, S.H. Constraint-based planning with integrated production scheduler over Internet, JManagement, Vol. 129(3), pp. 293-301, 2003
D.K.H. and Song Y. Application of component-state Cconstructability conflicts in a merged construction schedule, Advances in Engineering Software, Vol. 34 (11-12), pp. 671-681, 2003
104
Chua, D.K.H., Tyagi, A., Ling, S. and Bok, S.H. Process-parameter-interface model for design management, Journal of Construction Engineering and Management, Vol. 129(6), pp. 653-663, 2003
Clarksodesign process, Research in Engineering Design, Vol.12, pp.18-38, 2000
omputers in Civil Engineering, Vol.12(1), pp.69-81, 1997
Darwic by reasoning about objects, actions and resources, Artificial Intelligence for
de la G dependency network to
represent design rationale, Journal of Computing in Civil Engineering,
Dias, W
in Civil Engineering, Vol.10 (1), pp.78-86, 1996
Dias, W rocess models for design, Design Studies, Vol15 No 4, pp.417-432, 1994
Dubois namic and life cycle aspects of the construction process: available formalisms and on-going work, in
78, Bled, Slovenia, 1996
n, P.J. and Hamilton, J.P. 'Signposting', a parameter-driven task-based model of the
Coates, G., Whitfield, R.I., Duffy, A.H.B. and Hills, B. Coordination approaches and
systems--part II: An operational perspective, Research in Engineering Design, Vol.12, pp.73-89, 2000
Crowley, A.J. and Watson, A.S. Representing engineering information for
constructional steelwork, Microc
he, A., Levitt, R.E. and Hayes-Roth, B. OARPLAN: Generating project plans
Engineering Design, Analysis and Manufacturing, Vol.2(3), pp.169-181, 1988
arza, J.M. and Alcantara Jr., P.T. Using parameter
Vol.11(2), pp.102-112, 1997
.P.S. Multidisciplinary product modeling of buildings, Journal of Computing
.P.S. and Blockley, D.I. The integration of product and p
, A.-M. and Cutting-Decelle, A.-F. Modelling the dy
Proceedings of the International Conference on Information Technology, Glasgow, UK, 1996
Eastman, C.M. A data model analysis of modularity and extensibility in building
databases, Building and Environment, Vol. 27(2), pp.135-148, 1992 Eastman, C.M. and Fereshetian, N. Information models for use in product design: a
comparison, Computer-Aided Design, Vol. 26 Number 7, pp.551-572, 1994
Eastman, C.M. and Siabiris, A. A generic building product model incorporating building type information, Automation in Construction, Vol. 3(4), pp.283-304, 1995
Ekholm, A. and Fridqvist, S. Modelling of user organizations, buildings and spaces for
the design process, in Proceedings of CIB W78/TG10 Workshop: Construction on the Information Highway, Publication 198, pp. 165-1
105
Ekholm, A. and Fridqvist, S. A dynamic information system for design applied to the construction context, in Proceedings of CIB W78 Workshop: The Life-Cycle of Construction IT Innovations, Stockholm, Sweden, 1998
2000
Eppingroduct development, Research in Engineering Design,
Vol. 6, pp.1-13, 1994
Fenvesborative building design environment, Artificial Intelligence in
Engineering, Vol.14, pp.233-247, 2000
Fischer
122(4), pp.337-347, 1996
Fischer Engineering, Vol.10(3), pp.174-182, 1996
formation, Microcomputers in Civil Engineering, Vol. 9(6), pp.413-423, 1994
Froese, rough Standard Object-Oriented Models, Ph.D. thesis, Stanford University, 1992
Froese,
ammond, J., Choo, H.J., Austin, S., Tommelein, I.D. and Ballard, G. Integrating
998
Ekholm, A. and Fridqvist, S. A concept of space for building classification, product
modelling, and design, Automation in Construction, Vol.9(3), pp.315-328,
er, S.D., Whitney, D.E., Smith, R.P. and Gebala, D.A. A model-based method for organizing tasks in p
, S.J., Rivard, H. and Gomez, N. SEED-Config: a tool for conceptual structural design in a colla
, M. and Aalami, F. Scheduling with computer-interpretable construction method models, Journal of Construction Engineering and Management, Vol.
, M. and Froese, T. Examples and characteristics of shared project models, Journal of Computing in Civil
Ford, S., Aouad, G.F., Kirkham, J.A., Cooper, G.S., Brandon, P.S. and Child, T. An
object-oriented approach to integrating design in
T. Integrated Computer-Aided Project Management th
T. Models of construction process information, Journal of Computing in Civil Engineering, Vol.10(3), pp.183-193, 1996
Hdesign planning, scheduling, and control with DePlan, in Proceedings of IGLC-8, Brighton, United Kingdom, 2000
Harfman, A.C. and Chen, S.S. Component-based building representation for design
and construction, Automation in Construction, Vol.1, pp.339-350, 1993 Hegazy, T., Khalifa, J. and Zaneldin, E. Towards effective design coordination: a
questionnaire survey, Canadian Journal of Civil Engineering, Vol.25, pp.595-603, 1
Hegazy, T., Zaneldin, E. and Grierson, D. Improving design coordination for building
projects. I: Information model, Journal of Construction Engineering and Management, Vol.127(4), pp.322-329, 2001
106
Howard, H.C., Abdalla, J.A. and Phan, D.H.D. Primitive-composite approach for structural data modeling, Journal of Computing in Civil Engineering, Vol. 6(1), pp.19-40, 1992
Jagbeck, A. MDA planner: interactive planning tool using product models and
construction methods, Journal of Computing in Civil Engineering, Vol. 8(4), pp.536-554, 1994
iviniemi, A. IAI and IFC—State of the art, in Proceedings of the 8th International
usiak, A. and Wang, J. Decomposition of the design process, Journal of Mechanical
Kusiak D.W. and Feng, C.-X. A structured approach for
analysis of design processes, Ieee Transactions on Components, Packing, and
aw, K.H. and Krishnamurthy, K. A configuration and version management model for
ee, C.-H., Sause, R. and Hong, N.K. Overview of entity-based integrated design
cture, engineering, and construction, in Proceedings of the First International Conference on the Management of
Luiten, .A. Project-modeling in AEC to integrate
design and construction, Computers in Industry, Vol. 35, pp.13-29, 1998
Maher, sing an activity/space model, Automation in Construction, Vol.6(2), pp.77-95, 1997
Malmsodeling of information management processes, Concurrent
Engineering: Research and Applications, Vol.7(2), pp.95-103, 1999
Maloneings of the 1990 ACM conference
on Computer-supported cooperative work, pp.357-370, Los Angeles, California, United States, 1990
Kadefors, A. Institutions in building projects: Implications for flexibility and change.
Scandinavian Journal of Management, Vol.11 (4), pp.395-408, 1995
KConference on Durability of Building Materials and Components, Vancouver, Canada, 1999
KDesign, Vol.115, pp.687-695, 1993
, A., Wang, J. (R.), He,
Manufacturing Technology, Vol. 18(3), pp.664-673, 1995
Lcollaborative design, in Proceedings of the International Conference on Information Technology, Glasgow, UK, 1996
Lproduct and process models, in Proceedings of the International Conference on Information Technology, Glasgow, UK, 1996
Luiten, G., Froese, T., Bjork, B.-C., Cooper, G., Junge, R., Karstila, K. and Oxman, R.
An information reference model for archite
Information Technology for Construction, Singapore, 1993
G.T., Tolman, F.P. and Fischer, M
M.L., Simoff, S.J. and Mitchell, J. Formalising building requirements u
trom, J., Pikosz, P. and Malmqvist, J. Complementary roles of IDEF0 and DSM for the m
, T.W. and Crowston, K. What is coordination theory and how can it help design cooperative work systems?, in Proceed
107
Malone, T.W. and Crowston, K. The interdisciplinary study of coordination, ACM Computing Surveys, Vol.26(1), pp.87-119, 1994
okhtar, A., Bedard, C. and Fazio, P. Information model for managing design changes
dekugri, I.E. and McCaffer, R. Management information flow in construction
ark, H. and Cutkosky, M.R. Framework for modeling dependencies in collaborative
ezgui, Y. Review of information and the state of the art of knowledge management
ivard, H., Bedard, C., Fazio, P. and Ha, K.H. Functional analysis of the preliminary
ivard, H., Bedard, C., Ha, K.H. and Fazio, P. Shared conceptual model for the
Rivard esign of buildings,
Journal of Computing in Civil Engineering, Vol. 14(3), pp. 151-159, 2000
Rivard inary design of buildings, in Proceedings of CIB W78/TG10 Workshop: Construction
ogers, J.L. Tools and techniques for decomposing and managing complex design
Rosenm jects in a
collaborative CAD environment, Computer-Aided Design, Vol. 28(3), pp.193-
Rosenm
Research in Engineering Design, Vol. 11, pp. 193-205, 1999
Min a collaborative environment, Journal of Computing in Civil Engineering, Vol.12(2), pp.82-92, 1998
Ncompanies, Construction Management and Economics, Vol. 6, pp. 273-294, 1988
Olsson, R. Subcontract coordination in construction, International Journal of
Production Economics, Vol. 56-57, pp.503-509, 1998
Pengineering processes, Research in Engineering Design, Vol.11, pp. 84-102, 1999
Platt, D.G. Building process models for design management, Journal of Computing in
Civil Engineering, Vol. 10(3), pp. 194-203, 1996
Rpractices in the construction industry, The Knowledge Engineering Review, Vol. 16(3), pp. 241-254, 2001
Rbuilding envelope design process, Building and Environment, Vol. 30(3), pp. 391-401, 1995
Rbuilding envelope design process, Building and Environment, Vol. 34, pp.175-187, 1999
, H. and Fenves, S.J. A representation for conceptual d
, H., Gomez, N. and Fenves, S.J. An information model for the prelim
on the Information Highway, Publication 198, pp. 435-448, 1996
Rprojects, Journal of Aircraft, Vol. 36(1), pp. 266-274, 1999
an, M.A. and Gero, J.S. Modelling multiple views of design ob
205, 1996
an, M. and Wang, F. CADOM: A component agent-based design-oriented model for collaborative design,
108
Rosenman, M. and Wang, F. A component agent based open CAD system for collaborative design, Automation in Construction, Vol. 10, pp. 383-397, 2001
anvido, V.E. and Norton, K.J. Integrated design-process model, Journal of
Shahid, S. and Froese, T. Project management information control systems, Canadian
Journal of Civil Engineering, Vol. 25(4), pp. 735-754, 1998
Shimod representing and using knowledge of buildings in CAAD systems, Artificial Intelligence in Design’92,
Shooter, S.B., Keirouz, W.T., Szykman, S. and Fenves, S.J. A model for the flow of
design information in product development, Engineering with Computers, Vol.
mith, R.P. and Morrow, J.A. Product development process modeling, Design Studies,
Soh, C etric coordinator for engineering design, Journal of
Computing in Civil Engineering, Vol. 14(4), pp. 233-240, 2000
Song, analysis, in Proceedings of the International Workshop on
Information Technology in Civil Engineering, pp.124-135, Washington, D.C.,
Stumpf, A.L., Ganeshan, R., Chin, S. and Liu, L.Y. Object-oriented model for
integrating construction product and process information, Journal of
iwari, S. and Gupta, A. Constraint management on distributed design configurations,
Tolman tion industry:
past, present and future, Automation in Construction, Vol.8, pp.227-235, 1999
Turk, Z ling for concurrent engineering, International Journal of Computer-Integrated Design and
Van Nederveen, G.A. and Tolman, F.P. Modelling multiple views on buildings,
Automation in Construction, Vol. 1(3), pp. 215-224, 1992
Sanvido, V.E. Linking levels of abstraction of a building design, Building and
Environment, Vol. 27 (2), pp.195-208, 1992
SManagement in Engineering, Vol. 10(5), pp. 55-62, 1994
aira, H. Basic structure of a building model for
pp. 241-263, 1992
16, pp.178-194, 2000
SVol.20, pp.237-261.1999
.-K. and Wang, Z. Param
Y. and Chua, D.K.H. POST: Product oriented scheduling technique for constructability
2002
Computing in Civil Engineering, Vol.10(3), pp. 204-212, 1996
TEngineering with Computers, Vol. 11, pp.199-212, 1995
, F.P. Product modeling standards for the building and construc
., Wasserfuhr, R. and Katranuschkov, P. Environment mode
Construction, Vol. 2(1), pp. 28-36, 2000
109
Wang, L., Shen, W., Xie, H., Neelamkavil, J. and Pardasani, A. Collaborative conceptual design-state of the art and future trends, Computer-Aided Design, Vol. 34, pp. 981-996, 2002
Wang, for multiview models, Journal of Computing in Civil Engineering, Vol.15(2), pp.102-111, 2001
Whitfie ation approaches and systems -- part I: A Strategic Perspective, Research in Engineering Design,
hitfield, R.I., Duffy, A.H.B., Coates, G. and Hills, W. Distributed design
Wilson, J.L. and Shi, C. Coordination mechanisms for cooperative design, Engineering
Applications of Artificial Intelligence, Vol.9 (4), pp.453-461, 1996
Woesteributing Knowledge in Building, Denmark, 2002
oach, International Journal of Production Research, Vol. 37(13), pp. 2957-2975, 1999
Zaneld on for building projects. II: A collaborative system, Journal of Construction Engineering and
Z. and Soh, C.K. Managing design changes
ld, R.I., Coates, G., Duffy, A.H.B. and Hills, B. Coordin
Vol.12, pp.48-60, 2000
Wcoordination, Research in Engineering Design, Vol.13, pp.243-252, 2002
nenk, K. The LexiCon: structuring semantics, in Proceedings of CIB W78 Conference 2002: Dist
Yassine, A., Falkenburg, D. and Chelst, K. Engineering design management: an
information structure appr
in, E., Hegazy, T. and Grierson, D. Improving design coordinati
Management, Vol.127(4), pp. 330-336, 2001
110
![Πανεπιστήμιο Πατρών › uploadedfiles › Tzes_CV_2012.… · Web view177 Y. Stergiopoulos and A. Tzes, [ST11_med], `Coverage-Oriented Coordination of Mobile Heterogeneous](https://img.pdfslide.us/doc/110x75/5f111a10e600f25371317293/f-a-uploadedfiles-a-tzescv2012-web.jpg)
