AN INFORMATION SYSTEM FOR THE MANAGEMENT OF
CHANGES DURING THE DESIGN OF BUILDING PROJECTS
Essam Zaneldin
Department of Civil and Environmental Engineering, United Arab Emirates University
P.O. Box 17555, Al Ain, United Arab Emirates
Keywords: Construction Industry, Coordination, Information Models, Change Management.
Abstract: Design is an important stage in a project's life cycle with the greatest impact on the overall performance and
cost. For several reasons, changes introduced by design participants are imminent. Despite the importance
of coordinating these changes among the different participants during the design stage, current practice
exhibits severe information transfer problems. Since corrections to finalized designs or even designs at late
stages in the process are extremely costly, it is less costly to spend the effort in managing changes and
producing highly coordinated and easily constructible designs. To support this objective, this paper presents
an information system with a built-in database for representing design information, including design
rationale and history of changes, to support the management of changes during the design of building
projects. The components of the system are discussed and possible future extensions to the present study are
presented. This research is expected to help engineering and design-build firms to effectively manage design
changes and produce better coordinated and constructible designs with less cost and time.
1 INTRODUCTION
Undoubtedly, the quality of design has an extensive
impact on all subsequent stages of a project’s life
cycle, including construction. Producing a quality
design is highly dependent upon effective
coordination among the diverse participants
involved in the process and proper management of
changes. The constructability of a project is an
important measure of the success of the project
(Hegazy et al., 2001). Many of the design decisions
and changes made early in the design process affect
the construction of the project. It is, therefore,
important to incorporate construction expertise in
the design process to improve the constructability of
the design and help design teams to enhance the
buildability of projects (Lam et al., 2006).
Despite the importance of constructability input,
the means by which this knowledge is introduced in
construction projects is still largely rudimentary
(Pulaski and Horman, 2005). As discussed by
Pulaski and Horman (2005), current methods
typically use design reviews by construction experts.
Sometimes tools, such as checklists, are used to help
coordinate changes and systematize the process.
These methods are relatively unsophisticated,
inefficient, and often lead to rework. This, in turn,
can result in animosity among team members. While
these methods have led to project improvements, it
is clear that there have been limited advances in the
ways to manage changes more effectively during the
design process.
Also, in the current traditional practice, each
project stage is isolated and is performed by
professionals who are less experienced on
successive steps. As such, the information and
rationale behind the decisions made at each stage are
not transferred to the following stages. Despite any
cost savings made by speeding early stages,
problems are magnified and passed to other parties
later in the process, such as construction and
operation/maintenance. With late corrections being
extremely costly, it is worthwhile to spend the effort
in producing highly coordinated design changes that
improves constructability and efficient facility
operation. Often, the consequences of coordinating
design changes and constructability problems are not
discovered until during construction. Some of these
consequences include variation orders and
contractual disputes, which lead to cost overruns
and, often, client dissatisfaction. Unfortunately, with
the escalating complexity of building projects and
49
Zaneldin E. (2009).
AN INFORMATION SYSTEM FOR THE MANAGEMENT OF CHANGES DURING THE DESIGN OF BUILDING PROJECTS.
In Proceedings of the 11th International Conference on Enterprise Information Systems - Databases and Information Systems Integration, pages 49-55
DOI: 10.5220/0001865500490055
Copyright
c
 SciTePress

the tighter constraints on time and cost,
coordination-related errors increase in design
documents. In recent years, therefore, the A/E/C
industry has devoted a considerable attention to
design information representation and integration of
the design and construction information of building
components.
Various researchers have developed models and
tools to manage the large amount of design and
construction data. Accordingly, a set of product
models were developed to structure project
information. Examples of early product models
include RATAS (Bjork, 1994) and COMBINE IDM
(Dubois et al., 1995). The RATAS model, for
example, describes a building project through a
hierarchy of relations between objects and uses five
abstraction levels: building, system, subsystem, part,
and detail. The hierarchical representation of a
project’s data, such as that used in building product
models, can be used to encode the design rationale
that is fundamental for design-change management.
Examples of early research efforts that focused on
recording design rationale include the active design
document of Garcia and Howard (1991) and the
parameter dependency network of de la Garza and
Alcantara (1997). The latter effort presented an
interesting data structure that represents building
data in a hierarchy and design rationale as a
performance criteria (e.g., a certain fire rating is
used as the rationale for the design of a certain
door). Recently, Shen et al. (2003) developed a
model that organizes the construction data into a tree
structure and then retrieve information and obtain
domain views by specifying the ways of traversing
the tree. Staub-French and Nepal (2007) presented a
feature-based framework for representing and
reasoning about component similarity that builds on
ontological modeling, model-based reasoning and
cluster analysis techniques. This reasoning process is
implemented in a prototype cost estimating
application, which creates and maintains cost
estimates based on a building product model.
Along with design data representation, present
advances in computer technologies, such as
electronic mail and the Internet, allow faster and
efficient exchange of information and can
potentially improve the information-extensive
design process. Electronic media can not only
convey geometric information such as drawings, but
can also transfer text information such as
specifications, bills of quantities, conditions of
contract, and design rationale statements. Tools such
as groupware, videoconferencing, remote access,
and file sharing can be used, individually or
combined, to provide custom solutions for design
coordination and site-to-office communication.
Currently, some examples exist of systems
developed to allow the access and sharing of project
information by participants in remote locations
(Nitithamyong and Skibniewski, 2004, Li et al.,
2004).
Constructability focuses on optimizing the
construction process in terms of construction cost,
schedule, safety, and quality. While constructability
research is typically centered in the construction
community, it is essentially a design process that
should be addressed early in design (Pulaski, 2006).
Among the constructability-improvement programs
currently gaining wide acceptability in construction
are Computer-Integrated Construction and Value
Engineering. A common characteristic among
existing constructability-improvement programs is
their focus on the interaction between design, as a
single product, and other phases of a project’s life
cycle, particularly the construction phase. This,
however, seems to place less emphasis on the multi-
disciplinary nature of the design development
process. Design coordination, therefore, is an
independent effort deemed appropriate to address
the design development process and account for its
unique difficulties and challenges. In this sense,
design-coordination can be an important
complementary task to all other constructability-
improvement programs. In this context, several
researchers have developed systems to improve
constructability. The effort of Arditi et al. (2002), for
example, examines design professionals' efforts to
pursue constructability and provides
recommendations for performing constructability
reviews. The work of Chua and Song (2003), on the
other hand, incorporates construction program
knowledge for constructability analysis.
A common characteristic among existing
constructability-improvement programs is their
focus on the interaction between design, as a single
product, and other phases of a project’s life cycle,
particularly the construction phase. This, however,
seems to place less emphasis on the multi-
disciplinary nature of the design development
process and the frequent changes introduced during
design.
The objective of this research is to utilize recent
advances in information technology to effectively
manage changes during the design of building
projects. A structured information system was
developed to build building components, store
design information and rationale, and effectively
manage design changes made by each party.
ICEIS 2009 - International Conference on Enterprise Information Systems
50

Possible future extensions to the present study are
also presented. This research is expected to help
engineering firms, particularly those involved in
design-build and turn-key projects, produce highly
coordinated and easily constructible designs.
2 INFORMATION SYSTEM
The information system incorporates four main
features: 1) hierarchical representation of design
data; 2) storing design rationale; 3) storing active
building components of projects in a central
repository; and 4) identifying communication paths
for automated communication of changes and
managing changes with approval mechanism. The
main components of the proposed information
system are shown in Figure 1. Further explanation of
these features is shown in the following subsections. .
Figure 1: The Main components of the proposed
information system.
Figure 1: The Main components of the proposed
information system.
2.1 Hierarchical Representation of
Design Data
2.1 Hierarchical Representation of
Design Data
Almost all existing design representation models
separate the multidisciplinary design information at
the system level (e.g., architectural, structural,
electrical, and mechanical systems are separate).
While this representation is simple and suits the
work of individual design teams, it eventually
separates related design information and, as such,
may lead to conflicts in coordinating the
multidisciplinary work. A certain building space, for
example, has to be included four times under the
four branches of the architectural, structural,
mechanical, and electrical systems of a building
hierarchy. This indicates redundancy and can create
coordination problems. It is important, therefore, to
unify the storage and manipulation of building data
and avoid redundancy by representing building
components as smart objects that contain all their
multidisciplinary design information.
Almost all existing design representation models
separate the multidisciplinary design information at
the system level (e.g., architectural, structural,
electrical, and mechanical systems are separate).
While this representation is simple and suits the
work of individual design teams, it eventually
separates related design information and, as such,
may lead to conflicts in coordinating the
multidisciplinary work. A certain building space, for
example, has to be included four times under the
four branches of the architectural, structural,
mechanical, and electrical systems of a building
hierarchy. This indicates redundancy and can create
coordination problems. It is important, therefore, to
unify the storage and manipulation of building data
and avoid redundancy by representing building
components as smart objects that contain all their
multidisciplinary design information.
This is achieved by representing building
components in the form of a building project
hierarchy (BPH). BPH is a hierarchical
representation of design data that unifies the storage
and manipulation of building data and avoids
redundancy. The novel element in this representation
is that building floors are divided into manageable
spaces that are considered as smart objects
containing all their multidisciplinary design
information (Figure 2).
This is achieved by representing building
components in the form of a building project
hierarchy (BPH). BPH is a hierarchical
representation of design data that unifies the storage
and manipulation of building data and avoids
redundancy. The novel element in this representation
is that building floors are divided into manageable
spaces that are considered as smart objects
containing all their multidisciplinary design
information (Figure 2).
Figure 2: Proposed representation of design data. Figure 2: Proposed representation of design data.
As such, each building space in the BPH
contains all information related to its architectural,
structural, mechanical, and electrical designs. In this
representation, proper multi-user access and
modification rights were established for the unified
BPH to suit all parties. Proper database design, a
suitable interface, and powerful reporting were also
necessary to ensure the success of such unified
multidisciplinary representation and, as such,
promote coordination and improve constructability.
Also, the proposed BPH allows designers from all
disciplines to instantly view the components of all
other disciplines in the same hierarchy.
As such, each building space in the BPH
contains all information related to its architectural,
structural, mechanical, and electrical designs. In this
representation, proper multi-user access and
modification rights were established for the unified
BPH to suit all parties. Proper database design, a
suitable interface, and powerful reporting were also
necessary to ensure the success of such unified
multidisciplinary representation and, as such,
promote coordination and improve constructability.
Also, the proposed BPH allows designers from all
disciplines to instantly view the components of all
other disciplines in the same hierarchy.
Project
Level
Building
Components
Library
(BCL)
Building
Project
Hierarchy
(BPH)
Change
Management
Module
(CMM)
Information S
y
stem
General and Pro
j
ect-S
p
ecific Databases
Floor 1 Floor 2
Architectural
Space 1 Space 2
Structural
Mechanical
Electrical
Architectural
Structural
Mechanical
Electrical
Building
Level
Space
Level
Floor
Level
Part Level
(Component)
System
Level
Building 2
Project XYZ
Building 1
AN INFORMATION SYSTEM FOR THE MANAGEMENT OF CHANGES DURING THE DESIGN OF BUILDING
PROJECTS
51

Six levels are used in the proposed building
project hierarchy (Figure 2): 1) Project Level; 2)
Building Level; 3) Floor Level; 4) Space Level; 5)
System Level; and 6) Part Level. The “Part Level”,
for example, includes the majority of the detailed
building objects, such as walls, doors, windows,
beams, columns, etc., and associated attributes. A
beam component, for example, has attributes like
width, depth, material, reinforcement, code-
restrictions, and location-in-wall. The proposed
building project hierarchy, as such, provides a
unique description for each component in a building
project.
The BPH data are saved in four separate
databases for the architectural, structural,
mechanical and electrical designs, with the
architectural database having links to the other
databases to facilitate the generation of the whole
BPH tree during project loading. The structural,
mechanical and electrical databases have a similar
structure that incorporates a number of tables for
saving the sub-trees associated with different space
components in the BPH. In this way, a unified BPH
representation of the design information for all
disciplines is achieved.
2.2 Storing Design Rationale
The hierarchical representation of design data is
used to encode the design rationale that is
fundamental for design-change management. This is
important so that the reasoning behind the design is
available when any future changes to building
components are contemplated. Design rationale is
represented by recording the performance criteria for
each building component. Design rationale is
represented by four information items recorded for
each component. The four items recorded for a
window component, for example, are: (1) a
description of the desired performance criteria (e.g.,
sufficient daylight and wide external view); (2) the
minimum and maximum performance values (e.g.,
between 240 and 260 cm wide); (3) a list of
components that affect the current component; and
(4) a list of components that are affected by changes
in the current component. The third and fourth data
items represent important dependency relationships
with other components, similar to predecessor and
successor relationships in network analysis.
2.3 Central Depository of
Building Components
A central depository of all building components is
needed to serve as a library that can store
components from all design disciplines, along with
their attributes and can be accessed by all parties.
Since changes to these attributes mean changes to
the design that need to be easily monitored, the
attributes of any component need to be represented
as visible objects. To facilitate the use of the
building components library (BCL), it is necessary
to pre-identify and store default information related
to components from every discipline before putting
the library to actual use.
A BCL is, therefore, developed to serve as a
central depository of template building components
that are used by all parties to facilitate the creation
of a complete BPH for a project. Default
components from various levels (e.g., floor, space,
door, window, wall, beam, column, etc.) are stored
in the BCL. Each building component in the BCL is
assigned a default specification section, design
rationale, and communication paths. Only the
administrator can modify the BCL, while other
parties can only add components from the BCL to
the BPH.
Space: Space 1
Width
Length
Clear_Height
Floor_Finish_Thickness
Floor_Finish_Material
Floor_Finish_Color
Architecture
Structural
Mechanical
Electrical
General Objects
System Objects
Figure 3: Example of “Space” component in the BCL.
The administrator can add a new default
component to the BCL and then specify the design
discipline(s) that can use that component. Once the
default values for the specification section, design
rationale, and route of changes (communication
paths) are specified, the default component is added
to the BCL and then becomes ready for use by the
designers. The different components in the BCL are
managed by using a reference to discipline type. In
this way, each design discipline can only use the
BCL to add components related to its part of the
BPH. The information in the BCL, therefore, is
maintained with a high level of consistency and
security. An example of a “Space” component in the
BCL is shown in Figure 3.
ICEIS 2009 - International Conference on Enterprise Information Systems
52

2.4 Managing Design Changes
A change management module (CMM) is developed
in order to notify affected parties by changes made
during the evolution of the design. To facilitate this,
it is important to identify the relationships among
the different building components in a project and
among the various design parties. This helps in
determining the proper communication paths to
affected parties when a change is introduced. It is
also important that building components be active
objects that can automatically send changes made to
their values to affected parties through their preset
communication paths.
To allow for efficient management of design
changes, building components need to be active and
automatically report changes made to their own
values to affected parties. This can be done through
the development of change-management procedures
for proposing changes, sending changes, and
providing reports that can be viewed by all
disciplines, such as the history of all changes made
throughout the design evolution. These reports are
important particularly to the design administrator
who can use them to track all changes made to a
project and follow up pending changes on a daily
basis. Also, it is always recommended, throughout
the design process, to inform other disciplines of an
intended change to any building component, before
actually implementing that change. It is necessary,
therefore, to send a corresponding change proposal
to all other disciplines for approval before applying
this change. Accordingly, designers from all
disciplines should receive proposals for changes
from other disciplines. This change-proposal can
then be approved or disapprove by other disciplines.
To facilitate change management, BPH elements
are used as active objects capable of automatically
communicating changes made to their own values.
Various procedures have been incorporated to
monitor new and old values of any object attribute
(e.g., window width), allow designers to propose
new values or obtain approvals from other parties,
and track/send/find changes made to a component.
The change management mechanism also includes
other general procedures that provide effective
tracking of all changes made, allow designers to
respond to proposed changes and implement
approved change-proposals, and obtain various
reports on the changes made. These procedures
improve coordination and keep project information
up to date.
3 DEVELOPMENT OF A SYSTEM
FOR CHANGE MANAGEMENT
An information system that incorporates the BPH,
the BCL, and the CMM is developed, as shown in
Figure 4. The system stores design information and
rational for the purpose of managing design changes.
When a designer uses the system, all changes made
are stored in a temporary “today’s-changes”
database. This information is then transferred to the
project’s “changes” database at the designer’s
request. The “changes” database includes two tables;
one for “proposed changes” and the other for
“applied changes”. The reporting system queries the
databases to provide the user with useful information
regarding pending changes and the history of
changes made during the design evolution.
A BPH for a project can be created using the
template building components stored in the BCL.
The process of building a BPH for a project
continues until a complete BPH is created. During
this process, designers may introduce changes to
their initial design values. To start a new project, the
architect can use the system to create the BPH by
answering four questions related to: 1) new project
name; 2) number of buildings in the project; 3)
number of floors in each building; and 4) number of
spaces in each floor. A corresponding default BPH
with a roof component will be created along with its
underlying databases for the architectural, structural,
mechanical, and electrical designs. If the newly-
created building contains more than one floor, a stair
component is automatically added to the BPH.
To refine the initial BPH as per the detailed
project information, the architect can change the
default names of the components (nodes) and use the
BCL to add new components to the BPH. Upon
completion of this process the system’s main screen
will appear as shown in Figure 4, where the BPH is
shown in the left side of the screen, the BCL and
communication paths in the middle of the screen,
and the CMM in the bottom left side of the screen.
Adding lower-level components (e.g., door,
window, beam, column, etc.) from the BCL to the
BPH is simple as this activity relates to a single
design discipline. On the other hand, adding a higher
level component (such as “space”) requires adding
various default nodes that relate to the corresponding
architectural, structural, mechanical and electrical
systems. The “bathroom” space in Figure 4, for
example, is inserted initially as a default component
from the BCL with its sub-nodes, including the
AN INFORMATION SYSTEM FOR THE MANAGEMENT OF CHANGES DURING THE DESIGN OF BUILDING
PROJECTS
53

Information Related to Selected Item
Figure 4: Main screen of the proposed information system.
system nodes. When the “structural” node of the
“bathroom” space is highlighted, its associated
structural tree is read from the “structural” database
and automatically displayed at the bottom of the
screen. In fact, when any node is selected, all of its
values appear on the screen and allow the designer
to edit/modify information related to CAD and
specification documents, design rationale, and
communication paths (e.g., see the top right side of
Figure 4).
At the early stages of generating a new project, it
may not be practical to send every change made to
the BPH. The architect, for example, may frequently
change the dimensions of spaces or levels of floors
(Figure 5) before deciding on their final values, and
only then need the communication process start with
other disciplines. To allow this flexibility, the
proposed system permits the design administrator to
turn the send-changes action on and off.
Figure 5: Approvals of other parties to proposed changes.
Many changes are generally introduced during
the design process, and it is possible that some
designers may not implement some of them in a
timely fashion. To avoid this, a warning system
tracks all changes made to a project and
continuously reminds designers to respond to
pending change-proposals and applied-changes that
Selected
node
BPH
This area will show the
structural, mechanical, or
electrical tree, if selected
from the top pane
Communication paths to facilitate
change management
System
Level
ICEIS 2009 - International Conference on Enterprise Information Systems
54

affect them. Sequential query language (SQL)
statements are used to automatically query the
changes database and obtain the status of all change-
proposals and applied-changes. If a response to a
proposed change is not provided, different messages
(depending on the amount of delay) will be sent to
remind designers to respond. Similarly, if a designer
did not provide a date to implement (respond to) a
change or did not implement a change on time,
reminder messages will be sent accordingly.
4 CONCLUSIONS
In a multidisciplinary environment such as the
design process for building projects, changes are
eminent, and properly managing these changes is a
key to controlling the project and ensuring a
consistent and well-coordinated design. This paper
presented an information system to store design
information, record design rationale, and effectively
manage design changes. The proposed system
incorporates a central building components library
(BCL) that is used to create a complete building
project hierarchy (BPH). The novel aspect of the
proposed BPH is its representation of
multidisciplinary design data within each building
space. In addition, each building component has
preset communication paths that help to
automatically communicate changes made to any
component to all affected parties. The role of the
design administrator in this system is as a central
coordinator. The model helps the design
administrator keep track of changes, follow up on
pending changes, and coordinate proposed changes.
The use of the proposed information system to
manage multidisciplinary design changes in a
collaborative environment will be investigated as a
future work. Furthermore, the information system
needs to be validated through a case study and real-
life experimentation. An effort is currently under
way to set up the system on a design firm’s local
area network and experiment with it for actual
projects being designed by the firm. The results of
this validation work will be reported in a later paper.
ACKNOWLEDGEMENTS
The investigator would like to express his sincere
appreciation to contractors, consultants, and design
firms who participated in providing information
related to design data and coordination-related
problems that helped in developing the change
management mechanism.
REFERENCES
Arditi, D., Elhassan, A., Toklu, Y., 2002. Constructability
analysis in the design firm. Journal of Construction
Engineering and Management, 128 (2), 117-126.
Bjork BC., 1994. RATAS project: developing an
infrastructure for computer-integrated construction.
Journal of Computing in Civil Engineering, 8 (4),
401–419.
Chua, D., Song, Y., 2003. Component state criteria
representation to incorporate construction program
knowledge for constructability analysis. Construction
Research Congress, Honolulu, Hawaii, USA.
de la Garza, J., Alcantara, P., 1997. Using parameter
dependency network to represent design rationale.
Journal of Computing in Civil Engineering, 11 (2),
102-112.
Dubois, A., Flynn, J., Verhoef, M., Augenbroe, G., 1995.
Conceptual modelling approaches in the COMBINE
project. Paper Presented in the COMBINE Seminar,
Dublin.
Garcia, ABC., Howard, HC., 1991. Building a model for
augmented design documentation. Proceedings of the
1st International Conference on Artificial Intelligence
in Design, Edinburgh.
Hegazy, T., Zaneldin, E., Grierson, D., 2001. Improving
design coordination for building projects: I –
information model." Journal of Construction
Engineering and Management, ASCE, 127 (4), 322-329.
Lam, P., Wong, F., Chan, A., 2006. Contributions of
designers to improving buildability and
constructability. Design Studies, 27 (4), 457-479.
Li, Y., Shao, X., Li, P., Liu, Q., 2004. Design and
implementation of a process-oriented intelligent
collaborative product design system, Computers in
Industry, 53 (2), 205-229.
Nitithamyong, P., Skibniewski, M.J., 2004. Web-based
construction project management systems: how to
make them successful? Automation in Construction,
13 (4), 491-506.
Pulaski, M., Horman, M., Riley, D., 2006. Constructability
practices to manage sustainable building knowledge.
Journal of Architectural Engineering, 12 (2), 83-92.
Pulaski, M., Horman, M., 2005. Organizing
constructability knowledge for design. Journal of
Construction Engineering and Management, 131 (8),
911-919.
Shen, Z., Issa, R., O'Brien, W., 2003. A model for
integrating construction design and schedule data. The
4
th
Joint International Symposium on Information
Technology in Civil Engineering, Nashville,
Tennessee, USA.
Staub-French, S., Nepal, M., 2007. Reasoning about
component similarity in building product models from
the construction perspective. Journal of Automation in
Construction, 17 (1), 11-21.
AN INFORMATION SYSTEM FOR THE MANAGEMENT OF CHANGES DURING THE DESIGN OF BUILDING
PROJECTS
55