. THEats

a "Immmtl‘li‘l’li’lllllllillllilIlium "'

31293 017721196

This is to certify that the

thesis entitled
5+rucl-uvecl Mefixoaoloar {our Devclorind.
Comma“ mquamaK-osl- (mm: 573m

presented by

Panka-j A- 3 nah-r

has been accepted towards fulfillment
of the requirements for .

Mam men-1'

Ca..- Major rrop oflof

Date é/ ”/61?
r I b//’~’/7 12/“

5’

0-7639 MS U u an Affirm“: ivc Act! (ion/Equal Opportunity Institution

 

 

 

 

V—v- - WWW —W'—‘Ifl--—

._...-‘

 

 

LIBRARY
Mlchigan State
University

 

 

 

‘-

PLACE IN RETURN BOX to remove this checkout from your record.
To AVOID FINES return on or before date due.
MAY BE RECALLED with earlier due date if requested.

 

DATE DUE DATE DUE I DATE DUE

 

I ma trim}
n‘g APR 2 l 2007

 

 

 

 

 

ram {3 mt.

 

 

 

APR 0 9 2003

 

 

 

 

 

 

 

 

 

 

 

1/90 W14

STRUCTURED METHODOLOGY FOR DEVELOPING
CONSTRUCTION MANAGEMENT COST CONTROL SYSTEM

By

Pankaj A. Jagtap

A THESIS
’ Submitted to
Michigan State University

In partial fulfillment of the requirements
For the degree of

MASTER OF SCIENCE

Department of Agriculture Engineering

1 998

ABSTRACT

"STRUCTURED METHODOLOGY FOR DEVELOPING CONSTRUCTION
MANAGEMENT COST CONTROL SYSTEM"

By
Pankaj A. Jagtap

The complex nature of construction projects generates a significant
amount of information which needs to be captured and analyzed for decision
making in construction project management. An information system (IS), which
manages these information handling requirements should be developed using a
structured methodology. This thesis streamlines the IS development process in
the construction project environment.

The objective of this research is to design a structured methodology for
developing information systems in the construction project environment and
apply that methodology to develop a cost control system for construction project
owners. This cost control system is envisioned for a management team headed
by a construction management firm in a construction management contract
delivery system. An information system environment along with the phases and
activities involved in a structured methodology are described in this research.
This derived methodology is applied to develop a cost control system. Modeling
techniques are used to represent the data flow and processes involved in
different aspects of an owner’s cost control system. The functioning of the cost

control system is demonstrated by applying it to two case studies.

To My Parents. . .

iii

ACKNOWLEDGEMENTS

The author would like to thank following people for their help during this
research.

Dr. Thomas Burkhardt, for his cooperation and assistance in completing
this thesis.

Dr. Matt Syal, for his continuous encouragement and guidance which
helped in finishing this thesis on time.

Dr. Severin Grabski, for his invaluable guidance and cooperation in the
field of information systems.

The students, faculty and staff of the Building Construction Management
program for their cooperation and support.

Finally, the author also wishes to thank all those who helped him directly

or indirectly to complete this thesis.

TABLE OF CONTENTS

LIST OF TABLES ................................................................................. ix
LIST OF FIGURES ................................................................................. x
LIST OF ABBREVIATIONS .................................................................... xi
CHAPTER 1
INTRODUCTION
1.1 ResearchArea... .. 1
1. 1.1 Complexity In Construction Projects
1. 1.2 Information System in Construction
1.1.3 Application of Information Technology in Construction
1.1.4 Structured Methodology
1.1.5 Domain Construction Environment
1.2 Problem statement. ...9
1.2.1 Requirements of MIS“.
1 ..2 2 MIS Implementation Difficulties
1.3 ResearchObjective.....................................................................14
1.4 Research Methodology... .. 15
1.5 Expected Results......... . ..............19
CHAPTER 2
LITERATURE REVIEW
2.1 Introduction... .. ..20
2.2 Information System In ConstructIon Management ....22
2.2.1 Information System Applications
2.2.2 Information Technology Applications in Construction
2.2.3 IT Application Issues in Construction Management
2.3 System Development in Construction... ....26
2.4 Cost Control System... .. .....28
2.5 Computer Applications for Cost Control System EXPEDITION.............29
2.6 Summary... . . .. .. ...34

CHAPTER 3
INFORMATION SYSTEM DEVELOPMENT ENVIRONMENT AND
CONSTRUCTION PERSPECTIVE

......35
...36

...43
.46

...53

58

......59
......60
...63

.72

3.1 Introduction... ..
3.2 Information System in ConstructIon Project Management
3.3 Classification of CM subsystems...
3.3.1 Project Life Cycle Classification.
3.3.2 Functional Classification
3.3.3 Managerial Activity Classification
3.3.4 Hybrid Classification
3.4 People involved in Information System Development... ..
3.5 Information System Architecture..............
3.5.1 IS Building Block: DATA
3.5.2 IS Building Block: Processes
3.5.3 SI Building Block: Interface
3. 5. 4 IS Building Block: Geography
3.6 System Initiation Process...
3.6.1 Reason for System Development
3. 6. 2 System Development Project Selection
3.6.3 System Development Instances in Construction
3.7 Summary................
CHAPTER 4
STRUCTURED METHODOLOGY FOR CONSTRUCTION INDUSTRY
4.1 Introduction... .
4.2 Structured System Development Methodology
4.3 Contents of Structured Methodology...
4.3.1 Selection of System Development Process
4. 3. 2 System development Processes
4.3.3 System Development Techniques (strategies)
4.3.4 CASE (Computer-Aided Systems Engineering) Tools
4.4 Construction Management System Development Methodology ..
(CMSDM)

4.4.1 Construction Project Variables
4.4.2 Construction Project Environment
4.4.3 CMSDM Phases and activities
4.4.3.1 Survey Phase
4.4.3.2 Study Phase
4.4.3.3 Definition Phase
4.4.3.4 Configuration Phase
4.4.3.5 Procurement Phase
4.4.3.6 Design and Integration Phase
4.4.3.7 Construction Phase

vi

4.5
4.6

4.4.3.8 Delivery Phase

4.4.3.9 System Support
Major Variations in CMSDM... ....116
Summary...... ....123

CHAPTER 5
COST CONTROL SYSTEM

5.1
5.2

5.3
5.4

5.5

Introduction. .. 125
CM ContractAdmInIstratIon System 125
52.1 CM Services

5. 2. 2 Cost Management Activities

CM ProjectEnvironment... .. 132
Application of CMCC System using CMSDM133
5..41 Survey Phase

5.4.2 Study Phase

5.4.3 Definition Phase

5.4.4 Configuration Phase

5.4.5 Procurement Phase

5.4.6 Design and Integration Phase:

5.4.7 Construction Phase

5. 4.8 Delivery Phase

5.4.9 System Support
Summary179

CHAPTER 6
CASE STUDY

6.1
6.2

6.3

6.4

Introduction” 177
Casel: Program Management Pr0ject 181
6. 2. 1 System Development Process

6.2.2 System Data Model and Process Models

6.2.3 Possible Changes in BPFT L due to the application of CMSDM
6.2.4 Evaluation of recommendations and CMSDM by industry

Case II: Small Scale Construction Management Project... .194
6.3.1 Project System Development

6.3.2 Cost Control System

6.3.3 Possible Changes in the cost control system

6.3.4 Evaluation of recommendations and CMSDM

Summary... .............200

vii

CHAPTER 7
FUTURE RESEARCH AND SUMMARY

7.1 Summary...
7.2 Conclusion

7 2. 2. Cost Control System Related Conclusions
7.2.3 Case Study Related conclusion

7.3 Future Research... ..

APPENDIX

APPENDIX A: Data Flow Diagram...
APPENDIX B: Entity Relationship Diagram

BIBLIOGRAPHY ..........................................................................

viii

...201
.. ......204
7. 2.1 System Development Methodology Related Conclusmns

212

.214
...216

...... 218

Table 3.1
Table 3.2
Table 3.3
Table 3.4
Table 3.5
Table 4.1

Table 5.1
Table 5.2
Table 5.3
Table 5.4
Table 5.5
Table 5.6
Table 5.7
Table 6.1
Table 7.1
Table 7.2
Table A1
Table 81

LIST OF TABLES

Construction Management Information Subsystems... ..
Functional and Managerial Activity Subsystem Matrix

....37

40

Hybrid Classification of Construction Information Subsystems ..... 42

Matrix of System Building Blocks and Information System...
Owner and User Perspective of Cost Control System...

System Development Processes and Decision-Making
Parameters...

Services Provided by CM Firms .

Cost Control System: Problem Statement

Cost Control System: Scope Statement...

Entities In E- R Diagram...
Candidate Solutions for Cost Control System
Matrix of Feasibility Study...

BPFTL: Financial Analysis report for IndIVIduaI bid packsI....:..
...210
.211
.215
.217

Range of Construction Project and System Solutions...

System Developer SelectIon
DFD Legends: Prepare Inv0Ice
ERD Legends: Contract and Invalce

ix

.47
.52

..68
......129
......136
......137
.....158
......160
....164

...166

.189

LIST OF FIGURES

Figure 2.1 Cost Management Process in EXPEDITION... ....32
Figure 4.1 System Development Process... ....60
Figure 4.2 Waterfall Life Cycle Model...... .........66
Figure 4.3 Project Organizational Structure... ........75
Figure 4.4 CMSDM: Phases and Data Flow ......76
Figure.4.5 Survey Phase of CMSDM...... ....78
Figure.4.6 CMSDM: Bar Chart83
Figure 4.7 Study Phase of CMSDM....... ......85
Figure.4.8 Definition Phase of CMSDM ......90
Figure 4.9 Configuration Phase of CMSDM .......95
Figure4.10 ProcurementPhase of CMSDM ..98
Figure 4.11 Design & Integration Phase of CMSDM 103
Figure.4.12 Construction Phase of CMSDM 109
Figure4.13 Delivery Phase ofCMSDM... 1.15
Figure 4.14 Process Flowchart for CMSDM .. .. .118
Figure 5.1 Construction Management Versus General ContractIng .....126
Figure 5.2 Cost Management Activities Performed by CM Firm... .. 130
Figure 5.3 Cost Control System Development: Phases and Data Flow ....... 134
Figure 5.4 Baseline Schedule for System Development Project ................. 137
Figure 5.5 Decision Making Process while Managing Cost Control System.141
Figure 5.6 Context Level Data Flow Diagram for Cost Control System... .149
Figure 5.7 Process Decomposition Diagram for Cost Control System ......... 150
Figure 5.8 Cost Control System Domain: DFD... ...151
Figure. 5.8.1 Cost Control System- " Loading Initial Data"... 152
Figure. 5.8.2 Cost Control System- " Update and Distribute" .. 153
Figure. 5.8.2.1 Cost Control System-" Process Invoice and Requisition"..154
Figure. 5.8.2.1 Cost Control System-" Process Proposals & Change
Orders"... . 155
Figure. 5.8.2.3 Cost Control System- " Process Trends"... .... ..156
Figure. 5.8.3 Cost Control System-" Prepare Reports"... .156
Figure 5.9 Data Model for Cost Control System... .. .. ..157
Figure 5.10 Network Decomposition Diagram for Cost Control System .157
Figure 5.11 Data and Process Distributed Network Diagram... .. ....173
Figure A1 DFD: Prepare Inv0Ice215
Figure 8.1 ERD: Contract and Invoice...... 217

IS

CM
CMCC
CMCCS
CMSDM
MIS
ABC/CM
DFD
ERD

LIST OF ABBRIVIATION S

Information System

Information Technology

Construction Management

Construction Management Cost Control

Construction Management Cost Control System

Construction Management System Development Methodology
Management Information System

Architect Engineer Contractor/Construction Management
Data Flow Diagram

Entity Relationship Diagram

xi

CHAPTER 1

INTRODUCTION

1.1 Research Area

1.1.1 Complexity in Construction Projects

Projects in the architecture/engineeringlconstructionlconstruction management
(AECICM) industry have significant information handling requirements for several
reasons. They are complex, having many physical components such as
structural elements, equipment and furnishings, and non-physical components
such as schedules, construction methods and code requirements. Every new
project is set in a new environment, resulting in new components and new
construction methods. AECICM projects can last anywhere from a few months to
several years. This means that information created at one point has to be
represented and stored in some way until it is used later. AECICM projects are
also characterized by the large number of organizations and professionals
involved. Not only do some organizations generate information, which others
use, but they also frequently exchange information back-and-forth. Finally,
information from lessons learned in previous projects can be very useful for

future projects [Breuer et al. 1994].

1.1.2 Information System in Construction
The timely acquisition and analysis of information becomes critical to the success

of a project due to their magnitude and complexity. Managing such complex
I

AECICM projects is very difficult without a comprehensive management plan and
a functional management information system (MIS). The management plan will
establish the method for obtaining the program's schedule and cost goals, and
determine the most efficient allocation of resources to achieve these goals. The
MIS will provide the scorecard to determine how the project management team is
progressing towards realizing the program's goals.

MIS is a very loosely used term in the construction literature. A
management information system is an information system application that
provides for management-oriented reporting, usually in a predetermined, fixed
format [Whitten et al. 1998]. During the life cycle of a project, project plans are
developed in the project planning phase and they become the basis for
monitoring and controlling progress in the project control phase. Therefore, the
project control system, which collects and analyzes information and helps
management in decision making, is nothing but the project level MIS. More
detailed classification of different information systems in construction is done in
later chapters.

The project level MIS should be able to manage the enormous and
complex sets of information generated in AECICM projects. Effectively managing
this bulk of information to insure its availability and accuracy is an important
managerial task. Poor and missing information could easily lead to project
delays, uneconomical decisions, or even a complete failure at some point during
the project life cycle. The accurate and timely information generated by the MIS

becomes key to the success of any construction project. At the same time, too

much unorganized information presented to mangers can result in confusion and
paralysis of decision making. A listing of the most important information sets
would include [Hendrickson et al. 1989]:
0 Cash flow and procurement accounts for each organization
0 Intermediate analysis results during planning and design
0 Design documents, including drawings and specifications
0 Construction schedules and cost estimates
0 Quality control and assurance records
c Chronological files of project correspondence and memoranda
0 Construction field activity and inspection logs
0 Legal contracts and regulatory documents

Some of these sets of information evolve as the project proceeds.
Different project participants use information from different viewpoints. For
example, a construction management firm may utilize cost related information at
the cost accounts level while a general contractor may look into productivity and
cost of equipment. Different departments of the same organization use different
types of information or they may use the same information in different ways. For
example, an accounting department of the owner's organization would look into
requisitions and cash flow forecasts, while an operations department would look
into the overall project schedule and cost. Different levels of management use
different levels of information such as a senior project manager who looks only at
the multiple project milestone level schedule, while individual project managers

look into project specific activity level schedules. Due to these different

applications of an information system in project management, successful
development of an information system which would achieve its clients objectives,
is one of the most essential tasks for effective project management. The
construction industry is counting more and more on new developments in
information technology (IT) for application and development of more project

specific information systems.

1.1.3 Application of Information Technology in Construction

Information technology has become an integral part of construction project
management. A computer on the project manager's desk has become a common
sight in many construction organizations. Use of electronic mail is increasing day-
by-day. Field managers are using portable computers to record field reports
[VVIlliams 1994]. Project managers are getting project information related to cost,
time, quality and safety at their finger tips due to the development of the intemet
and company intranets [Mead 1997]. Computer integrated construction has
become a buzzword in universities and project control departments of large
construction organizations. More and more software packages are coming into
the market to capture the industry requirements of information and
communication between the project team members. Sales people are chasing
the project controls professionals for demonstration of new software and
technology. It’s the start of a new era in construction history where projects are
becoming more and more dependent on the information system [Schultz 1997].

But are we getting the results of the technology revolution? Are we successful in

actual implementation of this technology? Have we achieved the dream of a
paperless office? Has the computerized integrated system come to reality? Are
we sharing the project documents electronically among all the project
participants? Unfortunately the answer to these questions is frequently "NO".
Companies are spending thousands of dollars on software and hardware on the
basis of promises made by sales people. After facing problems with the
implementation of software, companies are signing technical support contracts
and paying more money to the software companies and hiring more people to
make the software work for them. Most of the information systems are
underutilized or overused to satisfy the information requirements. Most of the
project teams are not satisfied with the state of the information system they have
and have reverted back to the old way of hard copies and written notes.

On the basis of the author's experience in the construction industry, the
problem seems to be more with the implementation of technology than with the
technology itself. Keeping up with the pace of an ever-changing computer
technology is the construction industry's greatest challenge. Past decades were
spent in convincing the construction community about the advantages of
computerized information systems. It is the researcher's belief that most people
in the construction industry are convinced of the advantages of using information
technology, but are not successful in its implementation. Now it’s an era of
technology implementation. Most problems of inefficient information systems
have origin in the "Ad hoc" methods of system development. Successful

implementation of IT solutions requires a methodical approach in system

development for the construction industry. The construction industry needs to
consider technical as well as managerial issues while implementing IT. It requires
understanding of the unique requirements of the construction industry and a

grasp of the ever changing IT industry. [Breur 1993, Sadri et al. 1925]

1.1.4 Structured Methodology

System problem solving is the act of studying a problem environment in order to
implement corrective solutions that can form a new or improved system. Most
system analysts use some form of system problem-solving approach called a
system development life cycle. A system development life cycle is a systematic
and orderly approach to solving system problems. While a wide variety of
problem solving approaches have been tried, it usually incorporates the following

problem-solving steps [Whitten et al. 1998].

Survey phase includes activities such as defining the scope of the system,

identifying the time required for development of the system and allocating the
budget for the system development.

0 Study Phase includes activities such as understanding the current system
and understanding the user requirements for the new system.

0 Definition phase includes accurate representation of user requirements in
terms of data and process flows within the information system.

0 Configuration phase includes identifying candidate solutions, evaluating

feasibility of these solutions and identifying the target system.

0 Procurement phase includes purchase of software and hardware.

0 Deslgn phase includes designing of reports, user interfaces and interfaces
between different sub-systems for developing an integrated system.

a Construction phase includes installation of software and hardware,
developing user interfaces, and customizing the system for the project
requirements.

0 Delivery phase includes testing the new systems for required performance
and transferring day-to-day business information.

. Support phase includes activities such as training employees for the new
system, documenting procedures and fixing implementation bugs.

Structured methodology is a systematic problem solving approach for

development of information systems. Every industry and system analyst uses

some variation of structured methodology, which is based on the system
development life cycle. Successful development of an information system in the
construction industry depends heavily on development of such a structured

methodology, which is most applicable to the construction industry.

1.1.5 Domain Construction Environment

The domain construction environment needs to be explained to facilitate
understanding of the project variables for the targeted industry. The domain
construction project is a typical mid-size building construction project with a dollar
value of more than $50 million, and spanning more than two years for

construction. The project delivery system for this project uses a professional

construction management (CM) organization. In this contractual system the
construction manager leads the team of owner, designer and construction
manager, and therefore becomes responsible for the overall coordination of the
construction operation while controlling cost, time, quality and safety of the
construction project [Barrie et al. 1993].

A project control system should have two levels with separate orientation
[Burger 1973]:

1. Project control system level, which will cover all central and operational
aspects of the project

2. Management information system, which provides both the upper structure
of the system, used by senior project manager, and reporting, which interfaces
with the client, architect/engineer, and other outside project groups.

The owner‘s level MIS, which helps higher level management in decision
making and interfacing with other external entities, is as important as the
operation level MIS. In case of construction projects managed by a construction
management contract delivery system, the owner's level MIS helps the owner's
management team headed by a construction management organization in
decision making. The owner's level MIS can consist of different integrated
subsystems such as cost control, progress control, contract administration and
cash flow management systems. For example, an owner's cost control system
will look at the cost control from the owner's point of view rather than the

accounting details of the contractors.

1.2 Problem Area

1.2.1 Requirements of MIS
The successful execution of construction projects depends heavily on the project
specific management information system for accurate and timely information
used in decision making. A project level MIS that can effectively manage all
administrative work, progress control information, and cost control operations is
essential for successful management of construction operations. Many
construction projects run over budget or over time due to their poor information
systems.

Capturing data at the right time and place is essential for generating useful
MIS reports. For example, consider an activity such as "pour concrete for slab-
on-grade". One needs to capture the amount of concrete poured for that activity
at the right time and report that information to the upper management in terms of
consumption reports so that appropriate actions can be taken. But if the reports
are generated once per month, then any necessary corrective action could not be
taken in time to prevent the possible extra consumption of concrete. Also, if the
excess consumption is not attributed to the detailed cost account, it would be
difficult for management to identify the problem area precisely and the
consumption of extra concrete will go unnoticed. This example shows the
importance of designing an information system which can capture data and
produce accurate and timely information for decision making.

Let's analyze one more example. No construction project is completed

without change orders and extra work. In the case of change orders, the owner‘s

9

level MIS should report to the management team that works on behalf of the
owner about the possibility of extra work, and any extra work should reflect in the
budget and cash reports. If such information is not transformed and reported to
the management team, project costs would increase without knowledge of the
management team. These examples show how important it is to have an MIS
which can report timely and accurate information to the management team for
decision making. Absence of an effective information system can contribute to
time and cost overruns of construction projects. Therefore, one needs to identify
a structured MIS development process, which can lead to development of a
successful project specific information system to provide timely and accurate

management reports for decision making.

1.2.2 MIS Implementation Difficulties

In the present competitive environment, construction organizations are
depending on information systems for a competitive advantage and quality
customer service. Therefore, upper level management is promoting the use of
information technology to develop a state-of-the-art information system for
construction projects. But in spite of management support, organizations are not
achieving the expected results [Breuer et al. 1994]. The reasons for this
mismanagement of information systems are the implementation methodologies
used by the developers. The implementation depends substantially on
information requirements, which are both project and company specific. On the

basis of these requirements, one needs to determine the information flow among

10

the organizations, as well as the information architecture and IT tools which will
satisfy these requirements. The complexity involved with development of an MIS
should be examined in detail to understand the problem areas.

Depending on the type of project, different types of IT tools need to be
selected. For example, estimating software, which is effective for building
construction, may not be the best option for highway construction. The size of a
construction project affects the amount of data generated by the information
system even if projects are of same type. Therefore, the selected IT tools should
be able to manage the amount of data for a given project without being an
overkill for the project. Construction projects have different delivery systems such
as traditional AECICM, construction management system, and program
management or design-build. Depending on these delivery systems, the number
of organizations involved in a project and their roles and responsibilities vary.
This variability leads to changes in information flow among the agencies
involved. Therefore, the selected IT tools should be able to manage these
process requirements.

Different organizations have different management styles. Some
organizations rely on a centralized system, while others believe in project level
management. Also, team members on a given project have different methods of
performing their work. The organizations also have different approaches toward
information technology. Management support affects the implementation of an
information system considerably. While selecting a management information

system, It is also important to consider technical knowledge available in the

11

organization. Otherwise much time is spent on training people which leads to a
slow rate of system implementation. The difficulties in accepting new technology,
changed working conditions and the company culture also affect the system
implementation.

When selecting software and hardware based on the project
requirements, one also needs to consider different technical and monetary
issues. The most important decision is whether or not the return on this
investment justifies the benefits. One needs to conduct a detailed return on
investment analysis to see if selected tools will provide the optimum solution.
Also, system analysts need to study software and hardware related issues such
as availability of technical support and training manuals, as well as long term use
of software. One also needs to decide if the proposed IT solution should be
developed in—house or whether commercially available software solutions should
be implemented. In the case of a system where multiple tools are utilized, one
needs to analyze whether a computer integrated system or "stand-alone"
function-specific system would be a better choice. Also, different data-related
issues such as reporting related features and the format in which data is
generated become a part of the system selection process. If an organization has
projects at different geographical locations, then networking needs to be
implemented to achieve data transfer between the head-office and various
project locations. In the case of networking, different issues related to data
security, data access, and data transfer need to be resolved for a successful

network implementation.

12

In an industry where so many variable factors exist related to selection
and implementation of an information system, one needs to use a methodical
approach in the system development and implementation process. Most of the
time these factors of system design and implementation are not considered while
developing an information system. Typically proven software solutions available
in the market are used for the development of information systems. These
solutions are designed to support general user requirements, however they
typically are not able to satisfy user specific requirements of an MIS. This
strategy leads to an unsatisfied project team with an inefficient disintegrated
information system. Therefore, a precise solution for the requirements of an
information system requires a systematic, methodical approach of system
development. It's essential to follow the different phases of "system development

life cycle"; to achieve the results required of an information system.

13

1.3 Research Objectives

This research is an attempt to streamline the process of successful development
and implementation of IT solutions in the construction industry. The objectives of
this thesis are threefold -

[A] Apply an information system framework to define a structured
methodology for developing information systems in the construction industry.

[B] Apply the newly developed structured methodology to the
development of an owner's cost controls system for the domain construction
project. Development of this cost control system will demonstrate the application
of the newly developed structured methodology in the construction industry.

[C] Evaluate the functioning of the cost control system and proposed
system development methodology by applying it to two case studies and
demonstrating its benefits compared with the traditional systems. This will show
the application of a cost control system and system development methodology in

the constniction industry.

14

1.4 Research Methodology

The first step in this research is to define the information system environment in
the construction industry. Based on the literature review, different types of
information systems such as cost control, progress control, contract
administration, design and estimation, in the construction industry will be
identified. The project environment in which systems are developed will be
described. Also, different possibilities of system development such as
implementing a new system, or implementing changes and modifications to an
existing system will be identified. People involved in the development such as
system users, system owners, system analysts, and the project support group
will be identified and their functions will be described. This step will also include
identification of building blocks for information systems in the construction
industry such as data generated, processes involved, interfaces and geography
involved in development of information systems.

After understanding the system development environment, a complete
literature review will be conducted to identify different system development
methodologies. A methodology, which can be applied to construction projects,
will be selected based on the literature review. A system development life cycle
of the selected methodology and all its phases and activities will be applied to the
construction environment to develop a structured methodology for the system
development process in the construction industry.

This structured methodology will identify the critical phases and activities,
which are critical for development of an information system in the construction

15

industry. The modified system development life cycle will guide professionals
involved in systems development in the construction industry by explaining
different phases and activities involved in system development. It will define
people involved, their responsibilities, and activities in each phase. It will also
explain the decision making required in each of these phases.

After defining the structured methodology, this methodology will be applied
to the domain construction project to develop an owner’s level cost control
system. The owners cost control system is selected mainly due to the
importance of cost control operation in successfully completing consthction
projects of large size. While applying this methodology a literature review will be
conducted to get more understanding of the construction management type of
contract administration system. This literature review will give details about the
construction environment, system users, system owners and the information and
data requirements for cost control system.

A leading off the shelf software package, EXPEDITION‘, by Primavera
Systems Inc. will be studied in detail to understand the functioning of a
commercially available, state of the art software package. This software will be
analyzed for different types of information handling, data flows, process flows,
decision making and basic activities involved in the cost control operation.
EXPEDITION is a multiuser, multiproject, client/server database product that

helps project participants control contract changes and submittals.

 

' Trade names are used in this thesis solely to provide specific information Mention of a product name
does not constitute an endorsement of the products by the author to the exclusion of other products not
mentioned

16

informati

A
and will
orders,
An Enll
will als
develop
system

pr090$
Consln
and (h.
and [r

It provides a centralized way to store, organize, and track project
information.

As a part of a structured methodology, data and information flow between
and within different parts of a cost control system such as contracts, change
orders, invoices, and requisitions will be represented using data flow diagrams.
An Entity-Relationship (E-R) diagram, which shows relationships among data,
will also be developed [Appendix A]. An E-R diagram can be used for
development of database cost control applications. The intended cost control
system is envisioned to include:

0 Development of project budgets from estimates

. Development of contracts and purchase orders

. Development of cost codes in cost worksheets

0 Cost updating with requisitions, invoices, and material delivery

0 Budget changes with change orders, proposals, and trends

0 Reporting variances, forecasting and status reporting

0 Links from a scheduling system

Two case studies will be conducted to evaluate the functioning of
proposed system development methodology. In these case studies, two
construction projects similar to the domain construction project will be selected
and their cost control systems will be analyzed. The owners cost control system
and the system development process employed will be studied in detail to

understand the structure and method of their cost control system. This study will

17

identify the functioning of cost control systems and their relationships with the
system development methodology. After studying and defining the cost control
systems in these case studies, some examples of data and information flow such
as processing change orders or possible rises in fuel prices will be selected to
evaluate the functioning of the system. The response to these examples by cost
control systems will be studied to evaluate the performance of the system. If
those systems fail to process the data and generate adequate decision-making
information, the same examples will be tested in the newly developed cost
control system. This test will demonstrate the benefits of the proposed cost
control system and system development methodology over traditional systems
and processes. These observations related to the application of the proposed
system development methodology and cost control system will be discussed with
the system developers for the case study projects. Their comments will be
summarized to get industry response to the proposed system development
methodology. On the basis of case studies, some adjustments may be done to

the proposed structured methodology and cost control system.

18

1.5 Expected Results

This research is an effort to define the information system framework in the

construction industry and to state the phases and activities involved in a

structured methodology for developing information systems in construction. It

also demonstrates the application of a structured methodology by developing a

cost control system for a construction management delivery system.

The following items will be developed through this research:

An information system framework for the construction industry which will
include different information systems as well as their applications, owners,
users and interrelationships in the construction industry.

A structured methodology with all phases and activities of a system
development life cycle for developing an information system in the
construction industry.

A description of the process of information system development for cost
control systems. This includes representation of data and information flow
within a cost control system and its components using flow charts or data flow

diagrams.

A design of a database application using an Entity-Relationship (E-R)
diagram. An E-R diagram gives relationships between different data elements
which can be used for database application development.

A decision making model for setting up a cost control system. This includes
all the decisions that a project team needs to make while developing a cost

control information system.

19

CHAPTER 2

EXISTING RESEARCH AND COMPUTER APPLICATIONS

2.1 Introduction

Construction projects have been using computerized information systems for
almost four decades. The selection of the medium for managing information has
depended primarily on the amount of information, the available technology and
the technical knowledge of the organization. As the size of thir construction
projects started to grow, construction organizations have started to move towards
computerized information systems. [Paulson 1996]

The computer applications in construction began evolving in the late
19505, and have evolved steadily ever since. The next two decades saw steady
progress, particularly in the home-office applications such as accounting and
finance, though the impact did not match the revolutions that took place in
banking, airlines and telecommunications. The project-oriented applications such
as CPM scheduling, estimation and simulation continued to evolve. But these
applications did not become popular because of the associated large data
handling requirements, initial problems related to costs of and access to
computer hardware, complexity of the software, difficulties with interpreting
output, as well as gaps in training for site-level people who were almost totally
unfamiliar with computers. In the 19805, microcomputers became widespread

and rapidly decreased in cost. Also, some powerful but easy-to-use application

20

development software, such as spreadsheets and databases, was introduced.
This new software greatly increased the number of people who could
economically create applications, which, in turn, lead to general awareness and
knowledge of computers in the construction industry [Paulson 1992, Syal 1992].

Application of a computerized information system has been a major area
of research in construction management. With new developments in information
technology, other industries such as manufacturing and retailing were the first
ones to take advantage of technological applications. After observing these
applications, researchers in the construction industry started concentrating on
different applications of information technology in the construction industry. As
the applications started to increase, construction firms started to find more and
more problems with various issues related to management of computerization. A
significant amount of research has already been done to show problem areas
and the possible solutions in those areas such as training, quality standards,
vendor-user relations and purchasing of software. Some researchers have also
focussed on the core issue of the system development process which involves all
the above mentioned issues.

The objective of this literature review is to summarize the already
accomplished work and existing software in the fields of system development,
information technology applications and application-related issues in construction

management.

21

2.2 Information System in Construction Management

2.2.1 Information System Applications

Considering the enormous amount of information flow among different personnel
involved in construction, research was conducted to identify their information
requirements [T enah 1986, Tenah 1984]. This research defined the information
requirements, functions and the required types of reports for most positions in a
construction company including president, directors, project managers and site
superintendents.

Most computer application development has taken place in a fragmented
fashion and, as a result, different developers have focussed on different tasks
associated with the project planning process such as cost estimation and
construction scheduling [Syal 1991]. Computer Integrated Construction (CIC)
appliwtions started to emerge in the early 905 and became a major area of
research in construction management. Many researchers have shown the
appliwtion of information technology in the integrated applications for design and

construction [Ahmed 1995].

2.2.2 Information Technology Applications in Construction

This is more of an applied area of research where researchers from both
academia and industry have contributed to the application of information
technology (IT) in construction management. Work has been done in different
segments of IT such as microcomputers, networking and the latest technology

such as Internet.

22

When the microcomputers became popular in mid 805, work was done to
list different possible applications of microcomputers in construction operations
done [ASCE Task Committee 1984, Barnes 1993]. Some database applications
were suggested to generate daily site reports [Russel 1993]. Some researchers
showed the application of microcomputers and networking for managing
computerized specifications and sharing them with other project partners
[Bosserman 1985]. Some researchers showed the possible applications of
computers to keep safety records [Stanton 1990].

Inspired by the application of IT in some other industries, researchers tried
to demonstrate IT applications of bar coding and electronic data interchange
[EDI] technology in the construction industry. Bar coding [Stukhart 1989] can be
utilized for inventory control at a job site where EDI can be used to exchange
project related data such as purchase orders, invoices, and requisitions
electronically among project participants [Gibson 1991]. Some researchers
showed the application of portable computers and hypermedia in construction
management [Williams 1994]. Considering the new trend in networking, a case
study was developed to demonstrate the process of transferring from a
microcomputer environment to a client-server networking environment [Zeremba
1993]

The latest focus on IT applications is on the intemet/intranet applications
in construction management. Internet is perceived by some as a channel of
communication which can solve most of the communication problems in

construction management [Schultz 1997]. Researchers in the AEC environment

23

are working to define the communications problems and possible solutions using
different intemet tools such as project level intranet, email, FTP, VRML,
GroupWare, virtual white board and video conferencing. Some work has been
done in the development of a detailed design for a project level intranet [Mead
1997]. This work proposed two models of project level intranet:

1. Basic Model, which can be used for description and marketing purposes, and
also can be accessed by anyone on the internet.

2. Expanded Model, which can be used to enhance the performance of the
project team. This model can be accessed only by the project team, and can

contain information about schedules, budget and project progress.

2.2.3 IT Application Issues in Construction Management

Researchers have tried to address various issues related to successful
application of IT tools in the construction industry. People in the construction
industry and especially in the construction-consulting environment have
contributed most to the work related to actual application issues, which is evident
from the following literature review.

Some researchers have focussed on fundamental issues such as strategic
planning of IT resources for construction [Terry 1993]. This research includes
discussions of issues such as timing of computerization, identification of
objectives of computerization and the overall business-focussed strategy. It
emphasized the importance of understanding the expectations from

computerization and planning for it.

24

Some researchers have focussed on the issues involved in transferring
from one IT platform to another such as, microcomputers-tometwork
workstations and possible problems with it [Kostem 1993].

Research has been done in several different implementation areas such
as vendor-user relations in which the authors describe the issues related to
technical support, service and quality of software [Tonias 1992]. Some work has
been done on the usage of IT resources and procedures for better management
of these IT resources [Pixley 1992]. Some work has been done in the area of
acquisition of hardware resources for IT applications [Lackowitz 1992] and its
usage [Jan 1991]. Some researchers have investigated the legal aspects of
software usage [Najafi 1991]. Some work has been done in quality assurance
procedures while using IT software [Fenves et al. 1979]. Other research has
been done in computer selection process, while some work has been done on
issues related to providing in-house computer services [Brown 1980].

Some researchers have studied the managerial issue related to IT
implementation and discussed its importance [Breuer et al. 1994]. They
discussed different issues related to planning, organizational, development and
management. This work gives a good insight into all the possible managerial
issues such as:

. Planning which includes the roles of IT, leadership, identifying IT

opportunities, resource commitment and innovation versus imitation.

25

. Organizational issues which include different perspective on IT, changes in
organizational structure, role of user versus role of IT specialists, and the
threat of IT

0 Development and Managerial issues which include make or buy,
implementation process, result control system, training and education, and

operational dependence.

2.3 System Development in Construction

Not much construction management research literature is available related to the
process and methodology of information system development. Some researchers
have pointed out the importance of following different phases of system
development such as planning, analysis, design, construction and support
[Paulson 1995]. But these steps are very generic steps involved in any project
management operation. Most of these recommendations are based on the
extensive research done in the field of MIS, which has not focused on the
requirements of the construction industry. Also, no work has been done in the
field of selection of appropriate methodologies for different project environments.
Sadri et al. [1993], described the requirements of information systems and
system development phases and activities. Their work proposed the following
minimum requirements of design specifications for development of information

systems.

26

Timeliness: Information systems should be able to generate information that
is available at different levels of abstraction and can be generated at the
required time.

Quality: Information produced should be accurate.

Integrity: Information should be correct and validated by business rules.
Value: Information should be produced in an understandable format.
Effectiveness: Information should be generated using technically efficient and

effective manners.

Their work also proposed the following "conceptual integration system" for

development and implementation of information systems. This information

system development is specifically for construction organizations.

Planning: This phase includes activities such as defining business strategy,
assessing existing information systems, developing information needs
reports, bench marking best practices and developing information system
plans.

Operation Analysis: This phase includes activities such as defining
operational departments, identifying data sources, modeling future business
operations, documenting technical requirements and doing a cost-benefit
analysis.

System design: Identifying technology, developing a process and information
model, deciding procedural and cultural changes, designing system tests, and

designing training.

27

0 Implementation: Developing implementation procedures, implementing design
specifications, testing systems, conducting training, and monitoring

performance.

2.4 Cost Control System

Although construction project management can be divided into a number of
functions, planning and controlling are considered to be the primary ones
responsible for the success of a construction project. The planning and controling
functions related to the cost and time aspects of construction projects have
always been of interest to construction researchers and practitioners.
Construction project planning provides the performance standards against which
project progress is measured and analyzed during the construction project
controlling stage [Syal 1992].

Project control systems should have two levels with separate orientations
[Amadeus et al. 1973]:
1. Project control system level, which will cover all control and operational
aspects of the project
2. Management information system, which provides both the upper structure
of the system, used by a senior project manager, and reporting, which interfaces
with the client, architect/engineer, and other outside project groups.

Zapalac et al. [1994] explained the process of MIS development for a
management team headed by a construction manager] program manager in

multiproject programs. Development of a program schedule and loading that

28

I]

schedule with project costs and funding sources is explained. The process of
managing and updating cash flows using both cost and funding loaded schedules
is also explained.

Some work has been done in defining the reporting and analysis required
for cost management at the job or management level. Some of these
requirements are as shown below [Paulson 1976]:

o Selectivity and subreporting: Required information at the required level of
details

0 Variances: Deviation between expected-at-completion cost and budgeted
cost of a project.

. Management by Exception: Identify and isolate the most important
information for immediate management action.

. Forecasting and Trending: Use forecasting of time and cost for the project to
anticipate problems before they arise.

0 Feedback Time: Prepare reports which provide useful information in time to

make critical decisions.

2.5 Computer Applications for Cost Control System: EXPEDITION

"EXPEDITION: Contract Control Software" by Primavera Systems Inc. has the
largest share in the market for contract administration software [Expedition 1996].
A cost control system is a part of the total contract administration system. Cost

control systems for the owner's management team headed by a construction

29

management (CM) firm, needs only cost information for the different bid

packages or contract levels.

EXPEDITION is a multiuser, multiproject, and client/server database
product that helps to control contract changes and submittals. It provides a
centralized way to store, organize, and track project information. Expedition
consists of many interrelated "logs" that store information about construction
projects such as submittals, transmittal letters, meeting minutes, contract terms,
contract prices, invoices, requisitions, and changes. The whole structure of
EXPEDITION can be divided into two parts. The first part is for managing
documents such as letters, submittals, and reports. The second part is for
organizing, managing and controlling project cost related items such as
contracts, purchase orders, invoices, requisitions and change orders. This
research work will design a cost control system, which will focus on these cost
related items of EXPEDITION. The following is a list of cost related modules in
expedition and their applications:

0 Contract! Purchase Order. EXPEDITION helps to organize and manage lump
sum and unit price contracts and purchase orders (POs). Once a contract or
PO is set in EXPEDITION, it can generate related submittals and requisitions,
track changes, and monitor charges.

0 Material delivery: EXPEDITION helps to manage construction material
delivery and its effect on managing pay requisitions.

- Invoices: EXPEDITION helps to keep track of billing information by generating

invoices for suppliers or contractors.

30

Change Process: EXPEDITION helps to manage all types of changes in
construction conditions by generating change orders, requests, notices and
proposals

Requisition: EXPEDITION helps to create requisitions and manage
calculations related to contractor payments.

Cost Worksheet: EXPEDITION's cost worksheet provides a central location
where all of this information can be collected and tracked, and where financial
status of the project can be quickly checked. The cost worksheet tracks
proposed changes, actual changes, and trends as well as costs distributed
from contracts purchase orders, invoices, and requisitions. The cost
worksheet is used to closely track budgeted costs, committed costs, funding
costs, actual expenditures, and budget revisions caused by changes.

Cost Management Process: Figure 2.1 shows the flow of activities and the

actions, which need to be taken during the cost management process while using

EXPEDITION. Contract cost management activities can be divided into two

phases. The first phase includes preconstruction activities such as setting up the

projects, contact of project participant organizations, and contract information.

The second phase includes updating of contracts and cost related documents

such as material delivery reports, requisitions, invoices, and change orders.

31

 

Create New Project: Add project information: cost, duration,
description, owner information,

i

Expedition Setup: Define software setup information such
as specification numbers, status, and roles for the project

1

Define Scheduling Activities: Assign the appropriate P3
project to the EXPEDITION project (Optional)

l

 

 

 

 

 

 

 

 

 

 

 

 

Define and add cost codes in Cost Worksheet: Cost codes are used to distribute,
monitor and control cost from different documents

 

 

 

l

Develop Project Contact Directory: List all the Agencies
involved in the project with general information and Key
Personal.

I

Define Contracts and Purchase Orders: Add all information such as
agencies involved, Lump Sum/ Unit Rate, and Material Code.
Activities Linked to the contract and requisition procedures.

l

Generate Invoices: Generate Invoices for all purchase orders
and contracts.

J,

Generate Material Delivery reports using material codes from
the conUacts/ purchase orders on the basis of each unit rate
material item.

I

Distribute cost from contract] P0 to cost worksheet. Update
original budget and original commitments.

l

A

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 2.1 Cost Management Process in EXPEDITION

32

 

 

Start updating contract information periodically for payments or

continuously whenever changes occur.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Update invoices/
Requisitions for
particular
comma or
purchase order.

 

 

 

 

 

 

 

 

 

 

 

 

Prepare periodic Prepare Prepare
requisitions for Change Change
the contract or Orders Notices
purchase order.
V V
Update Update
Material Trends
Delivery
7 7
Distribute Cost to the Cost Worksheet.

 

l

 

 

Monitor and control Budget in
Cost Worksheet.

 

 

Figure 2.1

33

Cost Management Process in EXPEDITION (Continued)

2.6 Summary

This literature review describes the research work related to information systems
and technology applications in construction management, and is a background
for the work done in the remaining part of this research.

One needs to observe that a sizable amount of work has been done in the
areas of IT applications in construction and in implementation issues related to
information systems in construction management. It should also be observed that
all of this work has been done in a very fragmented manner without looking into
the core issue of information system development in construction management. It
is this researcher‘s belief that all issues related to IT applications and IS
implementations are sub-parts of the core issue of information system

development, which has not been addressed by most research in the past.

34

CHAPTER 3

INFORMATION SYSTEM DEVELOPMENT ENVIRONMENT AND
CONSTRUCTION MANAGEMENT PERSPECTIVE

3.1 Introduction:

Information systems are made up of four building blocks which are business
data, the processes that mobilize data, interfaces that interact with the humans
and other systems, and networks which connects users and system resources
[Whitten et al. 1998]. People with many different perspectives interact with an
information system. Therefore, before understanding the system development
process, one needs to understand and analyze the system development
environment, which is made up of system building blocks and the users. This
chapter is aimed at providing that understanding of generic system development
environment and its construction management perspective to understand what it
means to the construction industry.

The next section describes various information subsystems involved in
construction project management based on their primary functions. After defining
these subsystems, they are classified in terms of different variables such as core
functions and managerial activities as well as their place in the construction
project life cycle to clarify the role of these subsystems in the formation of

construction management information systems. Before describing the reasons for

35

system development, the basic contents of system development environments
such as information system architecture and which people use information

systems are discussed.

3.2 Information Systems in Construction Project Management

Construction project management is a part of almost all phases of a construction
project life cycle. Information systems are used in different parts of a project life
cycle to collect and analyze data and to help managers in decision making.
These information systems which have emphasis on particular types of activities
such as cost control and time control, can also be called information subsystems.
Various combinations of these function-oriented subsystems form a construction
management information system. Table 3.1 shows the list of information
subsystems used in construction management as well as their contents and

appliwfions in construction management.

3.3 Classification of CM subsystems:

After identifying construction management subsystems, these subsystems are
classified in four different ways on the basis of various parameters to identify
their role and application in construction management. This information can help
in identifying application of these subsystems in different construction project
environments. The following sections describe these classifications which
include:

0 Project Life Cycle Classification 0 Managerial Activity Classification

0 Functional Classification 0 Hybrid Classification

36

Table 3.1 Construction Management Information Subsystems [Modified

from Paulson 1995].

 

 

Information Subsystem Contents Function

Project Cost Estimating All cost items including Detailed cost estimates

and Budgeting direct and indirect costs. are generated which are
used to prepare a project
budget

 

Project Time Planning

All activities, durations,

Used to prepare a project

 

and Control: relationships, and time plan, which is also
resources required to used for progress
complete those activities monitoring.

Job-costing and Cost Cost accounts, and Used to control

Engineering expected consumption consumption of

and actual consumption
of resources for each
cost account.

resources compared to
budget and helps
managers to make
timely and appropriate
operational decisions.

 

Accounting and Payroll

Different charts of
accounts

Works as an accounting
system for internal and
external management
and reporting.

 

Material Management

Different material items,
delivery schedule, and
accounts payable
information

Used to manage material
acquisition and
consumption processes.

 

Equipment Management

Equipment information,

Used to manage the fleet

 

depreciation, cost of equipment throughout
the organization.
Contract Administration Information about Used to keep track of all

contracts, purchase
orders, invoices, change
orders, payments,
requisitions, and

contract related costs
and documents.

 

submittals
Company and project Company financial Analyzes the project
Finance information, cash flow, performance in terms of
target profits organizational goals and

targets.

 

 

Human Resource
Management

 

Employee information,
wages and training data.

 

Used to manage human
resources and training for
better productivity.

 

37

 

3.3.1 Project Life Cycle Classification

Information subsystems can be classified on the basis of their position in a

project life cycle. The subsystems can be divided into two major parts within

construction project management. These are:

0 Project Planning: Includes estimating, budget preparation, and time planning
systems, as well as the quality plan, safety plan, and financial plan.

0 Project Control: Consists of cost control, time control, project administration
and resource management subsystems which include material management,

equipment management, and human resource management (HRM).

3.3.2 Functional Classification:

One of the other common parameters is the functional subsystem. This
classification is based on the principal functions performed by the system. People
in the construction industry have been using and developing functional
subsystems for last four decades. Some examples of functional subsystems are
time planning and control, cost planning and control, project administration and

resource administration subsystems.

3.3.3 Managerial Activity Classification:
Another way of classifying these subsystems is by the management activities
performed by each subsystem. Overall functional management can be divided

into four levels [Davis 1985].

38

0 Strategic Planning: This level involves management of organizational
resources, setting the organizational mission, goals and objectives, and
monitoring performance against these set targets. At this level, managers look at
a construction project as a business profit center and monitor project progress in
terms of organizational goals and objectives. A company and project financial
management system is an example of a strategic planning system.

0 Management Control: This includes overall management of construction
projects without getting into the operational details. This is a higher level of
abstraction of project data to achieve project goals.

0 Operational control: This is an actual activity level management of a
construction project. This requires an information system, which can help in
managing day-to-day operations at the construction site. Information subsystems
such as job costing, scheduling and contract administration are some examples
of subsystems required for operational control.

0 Transactional Processing: This captures and processes data about
construction operations. It includes actual data acquisition such as time cards,
activity progress, payroll and accounting data.

All subsystems involved in construction management as described in
section 3.2 can be classified in terms of functional and managerial activity
subsystems. Table 3.2 shows the position of various subsystems in terms of
managerial and functional subsystems. The rows in this matrix represent

managerial activities while the columns represent functions of subsystems.

39

Table 3.2 Functional and Managerial Activity Subsystem Matrix

 

 

 

 

 

 

Time Planning Cost Planning Administration Resource
a_nd Control and Control Management
Strategic Time bound Organizational Safety, quality Organizational
Planning growth planning cost planning and procedural financial
standards management
Management Milestone Estimation and Contract Project
Control schedule cost control administration financial
management
Operational Detailed Job-Costing Contract Accounting
Control schedule and cost administration and payroll,
engineering material
management,
equipment
management,
human
resource
mana ement
Transactional Progress entry Resource Document data Data entry for
Processing consumption entry operating
entry systems

 

 

 

 

 

 

This matrix can be used to identify the required subsystems for a particular

type of organization. For example, a management team headed by a

construction management organization is most interested in management control

and some amount of operational control. Whereas, specialty contractors are

more interested in operational control. Therefore, we can use the matrix shown in

table 3.2 to identify functional and managerial subsystems used by different

organizations. Some examples of applications are:

° A CM firm would use a scheduling system which can plan and control

progress at the milestone level and get the detailed schedule from specialty

contractors

4O

o A CM firm would use a cost control system which can develop a budget and
monitor costs at the level of cost centers, and use job-costing and cost
engineering data from specialty contractors.

. A CM firm would use a contract administration system to control contract
documents and contract change documents, and make specialty firms use
and share the same type of data.

0 A CM firm would use a project financial system to control cash flow and for
financial management of project costs and funding. The specialty contractor

would be interested more in detailed accounting data.

3.3.4 Hybrid Classification

Construction management information subsystems can also be classified as a
combination of users using these subsystems, technologies used for these
subsystems, and the managerial purpose of these subsystems. Table 3.3
describes these different types of subsystems. The second column describes the
functions of these subsystems. The third column elaborates the subsystems
giving examples from the construction industry, and the last column
demonstrates how time management systems include all types of hybrid system

classifications [Modified from Whitten et al. 1998].

41

Table 3.3 Hybrid Classification of Construction Information Subsystems

[Modified from Whitten et al. 1998].

 

 

 

 

 

 

 

 

Activities Application in Time
Construction Management
Management Application

Transaction Captures and Invoices, Capturing actual
Processing processes data purchase orders, progress of an
System about business time cards activity

transactions
Management Provides Weekly Periodic cash flow
Information management consumption and progress
System oriented reporting, reports, monthly report

usually in a accounting reports

predetermined

format.
Decision Support Provides users Job costing report Custom report to
System with decision to identify identify the person

oriented variations with responsible for

information expected progress delay.

whenever decision consumption of

making situations resources.

arise
Expert System Captures the Forecasting Forecasting

knowledge and productivity of activity duration

expertise of the crews on the basis on the basis of

expert and uses it of various project project

in decision malmg parameters parameters
Office Supports a wide Electronic mail, Progress updating
Automation range of business Imaging using electronic
System office activities technology for mail.

which improves digitizing plans

communication and specifications

between project

participants
Personal and Designed to meet Project level All the project
Workgroup needs of a single intranet participants can
Information user of a group have access to
System sharing common the schedule data

 

interest.

 

 

over the project
level intranet

 

42

 

3.4 People Involved in Information System Development

After identifying the subsystems of a construction management information
system, there is a need to focus on the people involved in development and
appliwtion of such an information system. Information systems are developed
essentially to achieve organizational goals by making people working for an
organization more productive. Therefore, whenever an information system is
developed, different people look into different aspects of the information system.
All these people give different suggestions for the information system, and it’s a
system analyst's role to develop a system which satisfies all system
requirements. All these stakeholders in the system can be broadly classified into

four categories [Whitten et al. 1998]: System owner, users, designers & builders

1. System Owners: This can be a single person or a management
team. System owners sponsor a system development project and hence control
the time and cost of a project. System owners are least interested in the technical
side of system development process. System owners are chief advocates of the
system and need to justify requirements to higher management. Examples of
system owners are senior project managers, or program directors, or project
managers who are in charge of the whole construction project in the case of a
small project. Any system development project can start only after the system
owner‘s permission and approval, and after the system owner becomes a

sponsor for such a project.

43

2. System Users: System users are always very close to the system
because they frequently use the system. They define the problem to be solved;
opportunities to be exploited; requirements to be fulfilled; and business
constraints to be imposed. System users know most about the system and are
the biggest source of system information. They can be subdivided into internal
users and external users.

A Internal Users: This category includes all employees of the
business for which the information system is developed. Good examples of
internal users are project managers and project engineers who actually use an
information system such as time and cost control. Some internal users function
from geographically separate locations but still use the same information system.
They are of two types: remote users & mobile users

Remote users use information system from geographically separate static
locations. A project office supporting different locations for an information system
is an example of remote users. In this case, all project managers of individual
projects would access data from the information system at their own project
office.

Mobile users work from different mobile locations and share the same
information system. This type of user is common in construction management
firms where company executives travel around the country selling CM services to
clients and using project information on the intemet. Members of a virtual team

supporting more than one project at a time are also an example of remote users.

44

B External Users: These users don’t work for the organization for
which the information system is developed. If an information system developed
for a construction management firm is accessed by architects, owners, general
contractors and subcontractors for contract administration communication, then
they become external users for the information systems. These users usually
influence the system development work.

3. System Designers: They translate users' business requirements
and constraints into technical solutions. The system designer is responsible for
identifying technological solutions, designing networks, databases, user
interfaces and reports.

4. System Builders: They construct the information system
components based on the design specifications. System designers and builders

can be external consultants or members of an in-house IT department.

For most cases in the construction industry the same person performs the
functions of both system designer and system builder. The person known as a
systems analyst performs the task of system analysis. A systems analyst works
from a corporate office to support their information system requirements. A
systems analyst facilitates system development and works with people from the
business and technology sides. In ideal conditions, the systems analyst identifies
system requirements from system owners and users, and then works with the

system designers and builders in constructing an actual information system.

45

3.5 Information System (IS) Architecture

An information system architecture presents a framework for defining all types of
information systems and their contents. An information system is made up of four
distinct building blocks. These are data, process, interface and geography. The
data aspect of IS is managed by database technology, the process part by
software technology, the interface by interface technology, and geography by the
networking technology. Any information system can be defined in terms of these
four building blocks. Each user of information systems as defined earlier has a
different focus on these building blocks of information systems. Table 3.4 shows
the information system framework and different users' perspectives of an
information system [Whitten et al. 1998]. The following section shows the

different system focuses and users' perspectives of those system building blocks.

3.5.1 IS Building Block: DATA

Data represent core content of a business, and are managed by database
technology. Data are in various different formats in the construction industry due
to their complex nature. Some examples of construction industry data are
construction material items, their prices, suppliers, the total value of the

purchase, and the percentage of work completed.

46

Table 3.4 Matrix of System Building Blocks and lnfonnation System

 

 

 

 

 

 

 

 

 

 

 

Workers [Whitten et al. 1998].

Users Data Process Interface Geography

Focus Focus Focus Focus
System Business Business System Operating
Owner Subjects Functions Context Locations
System Data Business Interface Communication
Users Requirements Process Requirements Requirements
System Database Application Interface Network
Designer Scheme Schema Schema Schema
System Database Application Component Networking
Builder Programs Programs Programs Promams
Technology Database Software Interface Networking

Technology Technology Technolggy Technology

 

Most of the time system owners are not interested in core construction
data; but rather in the business resources and managing data about system
resources. System owners are interested at a higher level of abstraction where
data can be processed to generate information. Therefore, system owners help
in identifying business entities such as contracts, change orders, schedule of
values, and relationships between them.

System users capture, store, process and use most of the data. So they
know most about the format in which data are edited, processed and stored.
System users supply information about different data attributes and formats, and
sometimes also add some entities and relationships. For example, different fields
required for capturing complete work such as actual start, actual finish, early start
early finish, remaining duration, and percent complete are provided by the

system users.

47

 

System designers convert a data model, which represents the user's view
of data relationship, into a database structure which can be implemented by
system builders using selected technology. System designers develop "database
schema" in terms of a selected database platform. On the basis of this database

schema, a system builder develops a database.

3.5.2 IS Building Block: Processes
Processes represent the functions and activities that take place in achieving
business objectives. These processes are managed by software technology.

Most of the time system owners are interested in business functions rather
than the actual tasks involved in them. System owners can identify different
required functions of a system and the expected results. Time control, cost
control, and contract administration are some examples of system functions.

System users know most about the details of "business processes" and
the policies and procedures underlying these business processes. System users
add most of the information about procedures and process models, and work
flow models can be used to express business processes in nontechnical, strictly
business terms.

System designers convert system users' views expressed in data flow
models to technology dependant "application schema". This conversion includes
decisions about which processes to automate, how to automate them, and which

technology to be used for automation. System builders represent processes

48

using application developing language that describes inputs, outputs, logic and

control.

3.5.3 IS Building Block: Interface

The interface part of information systems includes an effective and efficient
interface to the system users and to other information systems. These other
information systems can be within the business or with other outside business
organizations. Interfaces become crucial in the case of computer-integrated
construction management systems where common data are shared using
interfaces between different subsystems. Data and processes utilized to share
information by cost estimating and progress planning software during the project
planning phase are a good example of system interfaces.

System owners are usually interested in the "Big Picture". System owners
are interested in internal and external business units, external information
systems, and users which have an interface with the system. System owners
look into the inputs and outputs related to these interfaces, as well as any
government or corporate policies about interfaces. For example, senior project
managers of a construction management firm may be interested in identifying the
interface of a contract management system with information systems of different
contractors, and owners.

System users actually work with a system and, therefore, give
specifications about user interfaces, input forms and output reports. For example,

the users provide the data entry format with which they are most comfortable for

49

feeding in percentage completion of work. System users also give specifications
for tabular or graphical reports.

System designers design user screens on the basis of users'
requirements. This process includes designing graphical user interfaces, screen-
to-screen movement and help screens which can result in the most efficient user
movements in the application. They also design interfaces between systems
such as scheduling and estimating systems where some custom programming
needs to be done to match the data format. System builders construct, install,

test, and implement both user interfaces and system interfaces.

3.5.4 IS Building Block: Geography

Geography refers to the distribution of data, processes and interfaces to
appropriate business locations, and movement of data and information between
these locations. Geography becomes a major backbone of an information system
when users are at different locations. Networking technology is used to solve
problems related to geographic distribution of data and information. Considering
geographic distribution of construction projects, networking provides a major link
of communication, and tries to solve most of the communication problems. In a
construction scenario where a number of remote sites are supported by one job
office, networking between these locations becomes a key to communication with
different locations. Along with Local Area Networks (LAN) and Wide Area
Networks (WAN), internet and project level intranets are developed to improve

communication between system users. Even in project offices, a number of users

50

such as project managers and project engineers, share the same database, and
the implementation of such a system depends on successful LAN
implementation.

System owners are mainly interested in the operating locations and
connecting business partners. System owners also look into data access from
these locations, system security and external users.

System users give more detailed information about locations, workstation
positions, and data processing and interface requirements. More importantly,
system users define communication requirements at different locations.

On the basis of communication requirements defined by users, system
designers develop a network schema which includes computer centers,
computers, and networking hardware that will be involved in a computer network.
This design is based on user communication requirements and a networking
technology selection. On the basis of the network schema, system builders
develop networks using physical networking elements such as cables, network
operating systems, network interface cards, and networking programs to manage
the data flow over networks.

Table 3.5 shows the roles of system owners and users in development of
cost control systems for an owner's management team. A project owner uses a
cost control system to monitor the overall performance of a project in terms of
cost. The actual expenses are compared with the work performed and changes

in the scope of a project are compared with the initial budget.

51

 

 

 

 

 

8 5888 .3328
Mo 82883 05835.“
8 :26 8258.88
5:26 9 $555. 8:338 523 85:585.
88 896888 80¢ 8 5:88 .855. 35:50 85 458.25
wcmmmooca 52° «5385 355., meta—3.5 .3858.“ 83585 w8>o85
omega .58.” com me 53 355. 96505 £53585. £8 o\.. .8280
80¢ .95 8% 8 89.3 .528 >55 mo 3:35.85 8 53m 8085a fleets—5.5
58 £05. “55%;. 8% 5888 we :25 $38.. 55 8 53oz: 80:58.5. 3 :63 .55
5 $88 3850 285—3 505m 59: 52358 :83. .98.".— 55 Scam 285G 889mm
82585.2:
8:25:98 com 839$
mas—35:8 we gates:
8?. .838? on. $88
.38 on? 38:55 88:85
805888 85 88 890888 85 5:3:ng 88
88:55 .5856 038 we 58 55:5 a58>8 5:585. 80:38.58
.87. no.“ 2 88.5 .8585 £5558 8085558 .8580 omega .8280
03589 .5558 58.68 .55.:8 580 owcmzo 885:8 $5888 .5830
50.85 com 3 mmooo< mo segues—53 8 :03 825:5 8 58 52.5 @353 889$
agngwoomv 8&5...— mmooeam «:5

 

 

 

 

 

8826 .288 500 no 338820.. 5o: use 5:30 ad 29:

52

 

This example elaborates the role of a system owner and users in system
development. Roles of designers and builders are not included in this table
because they are highly dependent on the application architecture selected for

the development of each system.

3.6 System Initiation Process

Since details about system users and building blocks of an information system
have been presented, the following sections describe the process of system

initiation.

3.6.1 Reason for System Development

As discussed earlier, information systems are used for various functions and they
are developed primarily when users feel a need for it. The motivation for system
origination is always a combination of problems, opportunities, or a directive
[Whitten et al. 1998].

Problems cause an undesirable situation, which prevents organizations
from achieving organizational purposes, goals and objectives. For example, if
project managers start spending excess time in sending letters, then that
problem has to be solved by developing an automated system which can get
addresses from the central database and send memos electronically.

An opportunity is a chance to improve organization events even in the

absence of specific problems. Developing an organizational level intemet that

53

can be used to communicate between central offices, regional offices and job
sites for better organizational communication is an example of system
development for a technology-led opportunity.

A directive is a new requirement imposed by company management,
government regulations, or some other external influence. For example, If a
project owner asks for better transparency with the project data, then a
networking project can be initiated to connect the owner directly to a project
server so that the owner can get access to the project data. Access to project
data can improve transparency between the construction management firm and
construction project owner.

Some reasons for initiation of an information system project are as follows:

Current system can not cope . Cost saving

Better service to external users . Better internal information for

decision making

External forces . The opportunity provided by new

technology

High technology image

3.6.2 System Development Project Selection
In a large organization with various functional departments and users, numerous
system requirements are generated every day. All of these requirements need to

be screened and prioritized to see which ones are most critical for the business

54

functioning. System development projects are initiated according to those

requirements and priorities [Davis et al. 1985]

This activity of planning and controlling of computer system development
is done by an Information System Steering Committee. The size and
membership of this committee depend on the size of the organization and its
computer applications. The following activities are usually performed by a
steering committee [Curtis 1995].

c To recommend an overall business focus strategic policy for information
system development.

c To ensure that individual department information needs are being satisfied.
This is where the user's requests are initiated and transferred for approval to
the committee.

. To screen, prioritize, initiate and monitor individual projects. This process
includes formation of a project team, and developing the project scope and
budget

0 To coordinate individual projects to improve general coordination

. To report progress of various systems projects "upward" to top management.

All the systems initiated can be classified as planned system initiation and
unplanned system initiation. When system owners, users, or system analysts
initiate a project, it is called unplanned system initiation. Unplanned system
initiation gets lower preference over a planned system initiation that is a result of

one of the following projects.

55

1. An Information Strategy Planning Project: This project results in an
information strategy plan that has examined the core business of an organization
as a whole to identify those systems and application development projects that
will return the greatest strategic value to the business. Information system
development for a new construction project during the mobilization phase is an
example of a strategically identified information systems project.

2. Business Process Redesign Project: A business process redesign project
thoroughly analyzes a series of fundamental business processes to eliminate
redundancy, bureaucracy and to improve efficiency. The next step in this project
is to redesign an information system for those business processes. If an
organization finds that the process of handling change orders is very long and
time consuming, and decides to improve the process, then appropriate
modifications need to be done in the information system, which supports the

change order process.

3.6.3 System Development Instances in Construction

In a construction environment, all the instances of system development can be
classified into the following three scenarios.

1. New Construction Project: Every project has its specific requirements on
the basis of project plans, specifications and management. Therefore, the
information system development process starts along with the mobilization
process, and normally takes one to two months for development. This project is

initiated by the senior project manager or project director who is responsible for

56

the performance of the project and who acts as a system owner. Project
managers, site engineers, schedulers, and contract engineers act as system
users. This system is normally set in the project office with access from different
project locations.

2. New Organizational System: Construction organizations usually use
different project planning and control software, which support more than one
project. A number of strategic decisions needs to be taken while selecting
software products and designing information systems. Typical functional
information subsystems which become part of a corporate information system
are designing, cost estimating, progress planning and controlling, job costing and
accounting.

3. Modification of an Existing Information System: These projects can be at
the organizational level or project level. The main reason for these modification
projects is the changing system requirements from the system users and owners,
or inefficiency of an existing information system. This inefficiency can happen
due to changes in project environment or external requirements such as an
owner asking for reports which the present system is not capable of generating.
Different issues such as customization, reengineering or system integration may

be involved in these system development projects.

57

3.7 Summary

This chapter is aimed at explaining the information system development
environment, the basic contents or building blocks of information systems, and
who is involved in developing and using information systems in the construction
industry. Along with the description of generic theory of information systems, this
chapter gives a construction management perspective of a system development
environment and the importance of information systems to the construction
industry. This chapter also presents the different types of construction
management systems and their classification. These classifications can be
utilized to identify the required construction management information system for
a particular type of organization. At the end, this chapter describes the reason for
new system development and provides examples of such instances in
construction industry. The next chapter is aimed at defining a structured
methodology for developing information systems in a construction project

environment.

58

CHAPTER 4
SYSTEM DEVELOPMENT METHODOLOGY FOR CONSTRUCTION
PROJECT MANAGEMENT ENVIRONMENT

4.1 Introduction

After describing the information system environment in general and for
construction management in particular, there is a need to concentrate on the
information system development process. Information systems are a product
similar to a building, highway or dam. Therefore, development of an information
system follows same steps as any other project development. The basic steps in
project development are planing, analyzing, designing, constructing and
supporting. The information system development process also follows these
processes and uses project and process management techniques to plan, monitor
and control the system development process. Figure 4.1 shows the process of
project development. The boxes show the phases involved in project development,
whereas the arrows show the precedence relationship between them.

As explained in the previous chapter, the system development process
becomes very complex and complicated due to the number of people involved and
the interaction between them, as well as the large amount of data and process
management, technology selection, and technology management involved in

system development.

59

Project
Request —:[ 1

 

System
Planning

 

 

 

 

 

 

Y

System System
Support Analysis
System System
Construction Design

Figure 4.1 System Development Process

 

 

 

 

Therefore, system developers need to use structured development methods or
methodologies which can guide them in the system development process. This
chapter focuses on the different components of methodology, selection processes
and phases, activities, deliverables and tools used for accomplishing system
development in a construction environment. This chapter explains the importance
of a structured methodology, its components and selection criteria for those
components before defining the system development methodology for a

construction project management information system.

4.2 Structured System Development Methodology
A system development methodology is a business process used to develop an
information system. A methodology consists of three components. The first

component is a system development process, which defines the phases, or

60

groups of activities, which lead to system development. All methodologies are
derived from a logical problem solving process that is called a system development
life cycle. This life cycle is essentially a project management tool used to plan,
execute, monitor and control system development projects. Models of system
development life cycle (SDLCs) are used to describe the system development
process. The second part of a methodology is the technique used to execute
phases or groups of activities described in the system development process.
These techniques are the "how" of software processes. The third element of
methodology is the CASE (computer-aided systems engineering) technique. CASE
tools are software programs developed to automate some of the phases and
activities of structured methodology.

Therefore, one can define methodology as a physical implementation of a
logical life cycle that incorporates (1) Step-by—step activities for each phase, (2)
Individual and group roles to be played by each activity, (3) deliverables and
quality standards for each activity, and (4) tools and techniques to be used by each
activity. [Whitten et al. 1998]

Various organizations involved in system development use different
methodologies. Some are still using unstructured, "Ad hoc" methods of system
development. Most of those methodologies are available in the market which
organizations can buy and use in their development efforts. Organizations can
even develop an in-house methodology and tailor it to the skills, experiences and
requirements of the employees. In any case, organizations need to consider issues

related to methodology such as market assessment, selection criteria, and

61

adoption [Topper et al. 1994]. The following list illustrates some of the reasons for
companies to use structured methodologies:
1. Consistent reproducible approach 6. Reduced risks associated with

which can be applied to all the projects shortcuts and mistakes

2. Complete and consistent 7. Standardized deliverables produced
documentation from one project to during development effort.

other

3. Efficient maintenance 8. Project measurement

4. Project management 9. CASE tools support

5. Training 10. Technique Improvement

Even with all these advantages, there is still a price tag associated with each of
them. In practice, a structured methodology is required for development of
complex systems consisting of a number of functional subsystems used by
different users interacting with each other to achieve common organizational goals.
A structured methodology may not be required in the case of a small business with
standard procedures and clearly defined needs.

After initialization of an information system project, the system analyst
needs to make decisions about the selection of appropriate paths available within

the selected methodology for system development.

62

4.3 Contents of Structured Methodology

A system development methodology consists of processes, techniques and CASE
tools to help in achieving system development goals. Each methodology consists
of different variations for different types of project environments. These variations
consist of different combinations of processes, techniques and CASE tools. The
following section will identify different types of processes, techniques and CASE

tools that become part of a methodology and part of its selection criteria.

4.3.1 Selection of System Development Process

Selection of an appropriate system development process depends mainly on the
project variables. These project variables are project size, degree of
structuredness of the system, user task comprehension and developer task
proficiency [Davis 1985].

1. Project Size: Normally project size is measured by two components. One is
project duration and the other is total cost. Normally projects with a longer duration
have more people involved in the system development process. Also, more people
get involved in establishment and modification of system requirements, and
involvement of additional people results in an increase in volume and complexity of
communication. There is also a higher possibility of changes in users and
developers involved during the system development.

2. Degree of Structuredness: This variable refers to the relative amount of
structuredness for the decisions to be taken using an information system. Due to

the lack of structuredness, there exists an uncertainty about the initial

63

requirements and alterations of those requirements. A system with more
structuredness results in better capturing of user requirements without further
changes in those requirements.
3. User Task Comprehension: This variable refers to the user‘s
comprehension of the tasks expected to be performed by the information system. If
users have better understanding of the tasks expected to be performed by an
information system, then the level of uncertainty about initial requirements and
modifications is reduced considerably.
4. Developer Task Proficiency: This variable refers to the degree of certainty
with which the developer will be able to understand requirements accurately and
completely and develop an application to achieve them. This proficiency depends
on the training and experience of the system development team for a particular
type of project.

Based on these factors, the selection of a system development process can

be divided into two parts.

1. Determine the level of development uncertainty

2. Select a system development process suitable for the observed level of
uncertainty.

4.3.2 System Development Processes

Based on the uncertainty involved in system development, the following four
processes are identified as suitable for a particular class of projects. Again

different authors and researchers have identified different versions or variations of

64

these development processes, but the primary concept remains the same
[Modified from Davis 1985, Yorden 1989]

1. The Classical Project Life Cycle: The user statements of requirements are
accepted as complete, correct and firm, and the system is based on those
requirements. It consists of the main phases of system development such as
survey, analysis, design and construction, which take place one after another. No
changes are done in requirements in later part of the system development and no
procedures are used to gain assurance about the correctness of initial
requirements. This process is used for small projects with a high degree of
structuredness, a high level of user understanding of the system, and experienced
system developers. This method adds to greater user responsibility and to
increases in development efficiency.

2. Structured Project Life Cycle: Also called the waterfall life cycle, this is the
most formal traditional system development process, which is most widely
accepted and practiced. Figure 4.2 shows the waterfall model of system
development. The boxes show the phases involved in system development
whereas the arrows show the precedence relationships between these phases. It
proceeds from requirements to the final development phase in a top-down manner
without many changes in initial requirements. Each phase culminates in a
document, which becomes the basis of the next phase. Normally, only one activity
or phase takes place at a given time during the development. An assurance
procedure is used to ratify conformance with the requirements after every phase.

This method is used for a medium size structured system with very high user task

65

comprehensiveness and high developer task proficiency. Some of the basic
deficiencies of this model are long feedback cycles, high level of rigidity, very

unrealistic flow, bottoms-up testing and no variation in levels of abstraction.

 

Requirements
Specification

 

 

 

 

Preliminary

Design Q

Detailed Design

 

 

 

 

 

 

 

Coding ‘

Unit testing

 

 

 

 

 

 

 

 

%

Integration

Testing %

System Testing ‘

 

 

 

 

 

 

 

 

ES

Maintenance

 

 

 

 

Figure 4.2 Waterfall Life Cycle Model [Topper et al. 1984]

66

3. Iterative Structured Project Life Cycle: In the case of high requirement
uncertainty, iteration is added to the structured project life cycle. In this process,
requirements are changed during the development stages and, therefore,
developers have to go back and work on the requirement gathering phase. Hence,
a number of activities may take place simultaneously. This method is normally
used in the case of large multi-user systems where application areas are new to

the users and developing organizations.

4. The Prototyping Life Cycle: In the case of extreme uncertainties where
users are not able to state requirements without having a look at the developed
system, a prototype system is developed and then user feedback is collected to
get better requirements for the system. Such a method is also called an
experimental assurance process. This method is utilized in the case of an
unstructured system used by multiple users without system task comprehension.
Decision support systems developed for upper management are an example of a
type of system which uses a prototyping methodology.

Table 4.1 shows the decision-making variables corresponding to different
system development processes. In this table, different system development
processes are shown as rows and decision-making variables are shown as
columns. For example, the system development process, which is a "classical
project life cycle" is used for projects with small project size, high degree of

structuredness, high task comprehensiveness and high developer task proficiency.

67

Therefore, one can conclude that this process should be used when overall degree
of uncertainty is low.

Table 4.1 System Development Processes and Decision-Making

 

 

 

 

 

 

 

 

 

 

 

 

 

Parameters
Process Project Degree of User Developer Uncertainty
Size Structured Task Task
ness Compre Proficiency
hension
Classical Small High High High Low
Project Life
Cycle
Structured Medium High High High Medium
Project Life
Cycle
Iterative Large Medium Medium Low High
Structured
Project Life
Cycle
Prototyping Medium Low Low High Extreme
Life Cycle -Large
4.3.3 System Development Techniques] strategies

As described earlier, techniques are the "how" of a system development
process. The system analyst needs to select a technique after identifying the
process of system development. Techniques make use of notations and
diagramming tools for modeling, specifying, and designing an information system
and these programs or specifications become the representation of the system.
Different techniques have different orientations and they emphasize different parts
of a system. The following list includes the most dominant techniques used in the

industry [Topper et al. 1994].

68

1. Modern structured analysis (a function-oriented technique) stresses the
processing or functionality of an information system. Typically, in these techniques,
processes are defined first and data follow these processes.

2. Data-oriented techniques accent the data component of a system. Typically in
these techniques, data are defined first and then the processes.

3. Control-oriented techniques are an extension of process-oriented techniques
that focus on the control behavior of a system.

4. Information Engineering (Information-oriented system) is a data-centered, but
a process sensitive technique that is applied to the organizations as a whole. It
includes high level data and process models, and the integration of application via
these models.

5. Object-oriented techniques feature the integration of data and the valid
processing (encapsulation) of that data into a construct called an object. These are
the newest approaches and they attempt to address some inadequacies of earlier
techniques.

6. Prototyping techniques underscore the use of system simulation prior to
building and maintaining an information system. System developers should still

use the model driven techniques for developing prototypes.

Along with these techniques which are associated with application development
projects, there are techniques such as Information engineering which can be
applied to strategic information system projects and business process redesign for

redesign of business processes. Some techniques are a combination of the above

69

mentioned techniques such as joint application development (JAD) which
combines the model-based technique and the prototyping technique to bring
together system owners, users, analysts and builders to jointly define and design
systems. Some developers are extending the prototyping technique along with
JAD and model based techniques to perform "rapid application development
(RADI'

All the above mentioned techniques were originally created by an individual or
group of individuals, and many techniques are often identified with the people who
created them. These techniques are often viewed as competing alternatives, but in
reality certain combinations complement each other. The application and selection
of a particular technique depends on the development environment. A developer
can adopt a commercially successful technique and then tailor it to the way

organizations already develop systems.

4.3.4 CASE (Computer-Aided Systems Engineering) Tools
CASE is an application of information technology to systems development
activities, techniques and methodology. CASE tools are programs that automate or
support one or more phases of a system development life cycle. The technology is
intended to accelerate the process of developing information systems and to
improve the quality of the resulting system. It is an enabling technology that
supports a methodology’s preferred strategies, techniques, and deliverables.
CASE tools can be classified on the basis of life cycle phases that they

support. The tools that automate or support upper or earlier phases of system

70

development such as survey, study, definition, and design phases, are called
upper-CASE. Similarly, the tools that automate or support lower or later phases of
system development such as detailed design, construction and delivery are called
lower-CASE. The center of a CASE tools architecture is a database called a
repository. A CASE repository is a database where developers can store
diagrams, descriptions, specifications, and other by-products of system
development. A repository can be formed at different levels such as one for the
whole organization where all system documentation can be stored for all projects
that used CASE tools. Another repository can be formed at the workgroup level
where a project team can share the repository and transfer information back and
forth between the corporate and workgroup repository. CASE tools normally
provide some of the following facilities:

1. Diagramming: Helps to draw system models

2. Description tools: Help to managing non-graphic documentation.

3. Prototyping: Helps to create system components such as inputs, outputs and
programs

4. Inquiry and reporting: Help to extract models, description, and specifications
from the repository

5. Quality management: Helps to assess models, descriptions and prototypes for
consistency, completeness, or conformance with accepted methodologies.

6. Other facilities include decision support tools, documentation organization
methods, code generators, design generation, code generator, testing tools, data

sharing tools, version control tools, and housekeeping tools.

71

Some of the most commonly cited benefits from using CASE tools include
improved productivity, improved quality, better documentation, and reduced
lifetime maintenance. All methodologies do not require CASE but most of the
methodologies do benefit from CASE tools and do recommend CASE tools. After
identifying the different components of methodology, the following section identifies

the core methodology applicable in a construction project environment.

4.4 Construction Management System Development Methodology
(CMSDMh

CMSDM defines the system development methodology for developing construction
management information systems in a construction project environment. There are
two possibilities for system development in a project environment. The first is
developing information systems for a new construction project, and the second is
replacing existing non-performing information systems. As discussed earlier,
before defining a methodology there is a need to identify the processes,

techniques and CASE tools that should be used as a part of that methodology.

4.4.1 Construction Project Variables

Before developing a structured methodology for developing an information system
in a construction project environment, one needs to analyze the project
environment to identify the processes, techniques and CASE tools that can

become part of the methodology. Again, it is very difficult to generalize any project

72

characteristic due to the diverse nature of construction projects. But even in that
case, some characteristics are observed as common among all construction
projects.

Investment in system development takes place in almost all types of
construction projects. In most of the construction projects, a significantly high
number of organizations are involved, and they generate a huge amount of data
and information. Generally, in a construction project all processes related to project
control are defined according to the organizational manuals and in consultation
with the owner, architects, contractors, and CM firm. Therefore, one can conclude
that the information systems developed are quite structured in their format.
Considering the emergence of systems development in the construction industry,
the developers are not very experienced with the system development process.
The users are very knowledgeable about system processes, but also very
conservative about the possible changes in their performance. Also, they may
know the system very well but may not be able to explain the requirements.

Based on all of these variables related to the system development process
selection, one can conclude that the development environment consists of a high
degree of uncertainty. In such an environment, the selected methodology should
use an iterative structured system development life cycle using prototyping for the
analysis and design phases. Again this conclusion is based on the majority of
construction projects where significant investment is made in the development of

an information system.

73

4.4.2 Construction Project Environment

The system development environment in the case of new construction projects
depends on the client of the information system. The project's client can be an
owner, CM firm or contractor. The role of people involved in the information system
development changes according to the project size, type of project, organizational
structure, and management style of the client organization. As described in section
3.4, the senior project manager or project director who is responsible for the
overall performance of a construction project always acts as a system owner. A
user manager, known as the project controls manager heads the system user
team. This person acts as a coordinator between system developers and users. All
other positions such as scheduler, contract engineer and project managers act as
system users. Figure 4.3 shows the organizational structure for a system client
[modified from Barrie & Paulson, 1995]. In the case of small projects, a project
manager becomes the system owner as well as a system user along with project

engineers, and the contract expediter becomes the main system manager.

74

 

Plecictl

Manager

 

 

 

 

Figure 4.3 Project Organizational Structure

4.4.3 CMSDM: Phases and activities

Construction Management System Development Methodology (CMSDM) does not
impose a single process or technique or CASE tool on a system developer. This
methodology integrates all of the popular techniques including stmctured analysis
for process modeling, information engineering via data modeling, prototyping via
rapid application development, and joint application development for all methods. It
is very much influenced by the project characteristics of the construction industry.
Considering the different project characteristic and system parameters, system
analysts need to make appropriate changes to this generic methodology. Figure
4.4 shows the system development phases and the data flow between them. The
boxes in figure 4.4 represent the phases and arrows represent the data flow
between them. The dotted lines connect the phases and the activities involved in

individual phases.

75

8.89.... 5.3%:
85>

.358 ...a 85:8 .53.
095—8080..

..8 25% 39.2, 28...;
8005.»

52. “.882. 8:8
2.08.0 8.:

82.5 5.5.8. .888:

2:50....

Bu: 5. d 8:3
ems—on— 953:8
>6: 5. 6 :89:
838:: .3. 6 28m
..5352 .8... 6 28m

889R
.5: 0. 52.00
88: .53.? 88,—.

5.8350 5:0...
35. 829$ 6:880

  

     
      

. :35: @608 1:. 882.. o 80.8.8 .53.? 958 d
888.... 25-8 5.8: . a 88.583. . S... .85... 8.32 .
o .38 80:28 85.5885.
:5. ...95: 5.8.88 5.8a o 2555:: ..0 20 88.2.... o
. 8358 8.3: . 8:35. 3:92 . 8.5.8.... .25 .
388.. 335... ..5 iii . 2.828 “228...?
o 8:: 0.3.58: :5 3.253. a 8:285 9.qu .- 889:. 20 5.102 . 5:525:82
uuuuuuuuuuuuuu a £020: :33 o m magnum-=5.— .Q mafia—Xe «:89:— o
o A u o
. 8.2.23.8... .20 . 20 8:50 fieflfim .
3588:83— . 888.88 d
52929: l 8280...... 55... .
8:83.030
e 532.. 3:92 .
802w
35888.61 " .556 .302 o
5:85.:— 3582803— u

             

52228.. 8.8: Eu

5:85.83
5.3: .20

  

30E 8ND .25 moan—E ”EDwEO vi 2:2“.—

W60_.2:2=.:o8& o

m 53.0... 88.052 o
H 5.352%
m 8:. 528.530
m .9530... .325 .

 

    

82.8.30
22% 20

 

 

    

2.00m 805mm
20 a .88..

76

Each phase in CMSDM consists of multiple activities, and each activity in
this methodology is divided into four sections. The first section explains the
purpose of each activity. The second section explains the inputs, processes and
deliverables of each activity. The third section includes examples applicable from
the constmction industry which relate some of these activities to the construction
environment. The fourth section identifies the possible variations of the same
activities with respect to project and system variables. The primary system
variables are number of system users, use of commercially available software
solutions or custom solutions. or use of built-in report writer or external report
writer. The basic project variables are project origination and the urgency of a

project. These variables are explained in detail in section 4.5.

77

4.4.3.1 Survey Phase

This is the first phase of the system development life cycle. It is mainly focused on
identifying problems, defining the system's scope of the system, developing the
project team, and planning the system development project regarding project
budget and cost. The project director and system analysts are involved in all
activities of this phase. Fact-finding techniques such as interviewing are used in
this phase. The following sections describe the activities involves in the study
phase along with an example from the construction project management field
related to each activity. Figure 4.5 shows the deliverables generated from each

activity and the relationships between these deliverables.

 

Service
Request

l

Problem
Statement

l

Scope
Statement

l

Project
Plan

l

Project Feasibility
Assessment Report

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure. 4.5 Survey Phase of CMSDM

78

4.4.3.1.1 Survey problems, opportunities, and directives

Purpose: The purpose of this activity is to quickly survey and evaluate each
identified problem, opportunity, and directive with respect to urgency, visibility,
tangible benefits, and priority.

Inputs! Process! Deliverables: Generally, a project director or project manager,
who is ultimately responsible for the performance of the project, initiates the
system with a request for system service. This request is converted into a problem
statement which lists all problems, opportunities and directives in terms of urgency,
visibility and tangible benefits. Based on these factors all items in a system request
are prioritized and possible solutions are identified.

CM Example: Ideally, after signing the contract, a project director identifies the
system development requirements such as the time and cost monitoring system
and the contract administration system. Based on these requirements, a system
request is generated which lists all system requirements. System analysts working
out of a regional office handle the job of system development. It is always
preferable to employ a system analyst from within the organization, as that person
is knowledgeable about the organizational procedures and can be used during the
support phases. The system analyst converts this system request into a problem
statement.

Variations: All types of projects need to go through this activity.

79

4.4.3.1.2 Negotiate Project scope

Purpose: The purpose of this activity is to define the boundary of the system and

project. The boundary should be defined as precisely as possible to minimize the

impact of a creeping scope. The project's scope may increase in the future but the

budget and schedule should also be changed according to any changes in scope.

Inputs! Process! Deliverables: Based on the system request and problem

statement, a scope statement is developed. The scope statement consists of the

following four components that correspond to four building blocks.

0 Business Subjects: List of data elements about which the system needs to
provide information

. Business Function: List of business functions that would be included in or
affected by this system

. System Context: List of external people, organization units, organizations, or
other systems with which the system might have to interact.

0 Operating Location: List of specific business operating locations that will be
included within the scope of the project.

The system scope is developed after discussing the proposed solution for each

item in a problem statement with the project director. The project scope is defined

in terms of a list.

CM Example: The scope statement might include:

0 Business subjects such as contracts, purchase orders, and change orders

0 Business Functions such as approving change orders

80

. System context such as sharing "percent activity complete" data between
scheduling and contract administration system
0 Operating locations such as job office and site office.

Variations: All types of projects need to go through this activity.

4.4.3.1.3 Plan the Project

Purpose: The purpose of this activity is to develop the initial project schedule and
resource assignments.

Inputs! Process! Deliverables: Based on the initial two activities, project costs
and time are estimated and the project budget and schedule are developed. This
schedule and budget are negotiated with the project director and finalized. A
project schedule developed at this point should consist of the main system
development phases. A detailed schedule may be developed for the next phase.
Considering the project environment, a system analyst has to decide which
variation of the system development methodology is most applicable to the project
environment. Also, a project team is identified and specific roles are assigned to
the people. Henceforth, the whole team works as a group to achieve the system's
goals. Figure 4.6 shows the detailed schedule of the activities and phases involved
in CMSDM in bar chart format.

CM Example: The system analyst negotiates and finalizes the project budget and
schedule with the project director. This schedule should be consistent with the start
of the construction phase of the project, and the budget should be consistent with

the budget of the whole construction project. The project plan may also include

81

different parts of an information system based on system priorities. For example,
development of a project intranet will be considered as a second phase of the
system development project.

Variations: This activity can be expedited in case of urgent system requests.

4.4.3.1.4 Present the Project

Purpose: The purpose of this activity is to communicate the project and its goals
to all staff members, and to secure any required approval to continue the project.
Inputs! Process! Deliverables: A Project Feasibility Assessment Report is
developed using all inputs to the previous activities. This report acts as a internal
contract between the system analyst and the project owner. This report may also
be presented to the project support group working out of the regional office to
communicate the progress of the system development project. This report may
also be communicated to all concemed parties in order to develop transparency
and coordination.

Variations: This activity can be expedited in case of urgent system requests.

82

:20 am "20020 ...123...

 

c0230. 50.0». 0 3.0.5.8001 %
02022—00 0.03.2.3 .0 553.000. 0533 3
0.33300 803.230 05—00%

 

 

32(3— — gin-0:15:30...
g— N 5283;33 08:05,
825,3. seizes-0.050238.

 

 

 

 

 

55.0w .090.— 033000 0 052.600

 

02000 80.26

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Eves... 555......on a 285.8 2.3...—
.aou. ....- ..a... 328.. 2.32% 825.... . 2.8. a... ...... «12.. 2.3:
5555...! .352... .£=€u% 825,2 . £25.38. 38.3.. .023...
3.582.. E268... 330% 825.8 . 80.38... 2.38... 2.3—
asosoive 5...... =2_.!. 732E 325.8 v . 05.53.! :33». 88.3.. .83.—
acoeosaee :23... 8.30% 825.8 . £283.... 32.3.. .550
020502200: 00052.0 03.20:... t... 0:200
:83. .380 59¢ .630
.910... 2.. 203.0% .38.. 2. .58.“.
5......8. 238...... 2.85% 3383:3323;
003.9030 .3535. E03: gags-mg 2.052836. .2890 33m
32:33.80 0..- .Ezaoi 32.5% 3.5.39.0 a... 3:22.. .222.
£82.. 30:3 2.. 782E as“: ......8 .5 18.2
E0.u>w 2.0.2.0 05 330.2 0...- >36
2.0.5.8.. 3.3.3000 21:38 €3.30“. ,
30.0.0 05 20.05% «00.0... 05 2.0005.
30?... 05 5.0%. 60,—0.0 0.... :10.
00000 50,—0.0 0.3.0002 .. 0000.. «00.0... 0.3302
002:3:000 van E050... 3.56%. 3255—!— noficénao 0.... E030... >0>.:w
30.0.0 0... :0... 0:0 >023...»
£02.22 80.0.5
80.3.... .coqu_0>0o E0.m>m
am. 2 mm. m in. a Q. a. 25. a. m _ can 50 83.830
3... a ...-w 0.5 2.2.3

 

 

 

 

 

 

83

 

 

 

...:oo. :20 ..0 "20020 ......2:0...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5...... 1:82.000 .80.: o a..... 1:358
%§£.3292.>80 800.: 800.: . 58...;22;
co... 5...... ...-0E .80.... 30008 n ...... as... ......
...-..5... =5.5% 800.8 800.8 . .388... ..fi...
...... 8.82.8 ......E% 30008 800.8 . ...... 5.9:... 2......
.... 5....- o... .8!.o0% a? .... Es... .... .8080,
2020.000 0.2. 2.0.50 0... .0500

..8... :3...>O 5...... 8.2;;

220.005 5!. ..8 020 02.3% 3.0505 5.0.. .00. 0:0 8E
003.0... 2.2.8 .... 0:. 3.5% 35.8.. 2.2.8 as u... ..8...
82...... .... ...... ......mb 33...... .... ...... ......0
2.2.2 .... ....- .._.=0E .....Eoz .... v... a.....
503.6 30.. 0... «0.....200

20.....20E_52._ 2.0....m
20.000 3030.. 020 50.85% 20.000 31>! 020 .2000...

000.00.... .0... 02.13 29.00%
20.30 02:0.000

 

00.00.... .0... 02.720 20.000

 

 

002.500 22.00%
30.0005 050.20... 020 0~>_02(%
a... ...53... 0:. 05.5%
...02202 22.00%
......c. 0:. 52...... :23H

508 2:88

 

81...... :93

 

00000005 0.3.20.0 0... 0020.2

 

5.... .53.... u... .52..

 

E02580

 

 

0...... u... "5...... :93...

 

2.0.0.00. 30.. 0... 0.050.... 200 20.000

 

 

 

 

 

 

 

 

 

2000020EE000. 2.0.2.00 32(3. 0 200002085000. 2.89m
. o. a. a. ...... ...1 a.. a .. .
mum L 5.. _ own 2...... ..5... .00 20.. ..0 00
...... T ..8. .....w ...-m 0:0 2.2.00

 

 

 

 

 

 

 

 

84

4.4.3.2 Study Phase

The main objective of the study phase is to understand the business processes
better. Time spent on this phase depends mainly on the experience of the system
developer about the system environment and the unique project requirements.
This phase is used to understand the business vocabulary so that a system
analyst can have effective communication with the system users. Some modeling
techniques are used but detailed models of an existing system are not developed
because the real purpose is to understand the existing business processes. The
system analysts work with the user managers and the system owner to accomplish
these activities. The following sections describe the activities involved in the survey
phase along with an example from the construction project management field
related to each activity. Figure 4.7 shows the deliverables generated from each

activity and the relationships between these deliverables.

 

 

 

 

 

 

 

 

 

System Cause & Effect
Models Analysis
System Objectives &

Constraints

J

New System
Plan

l

Detailed Study
Phase

 

 

 

 

 

 

 

 

 

 

 

Figure 4.7 Study Phase of CMSDM

85

4.4.3.2.1 Model the Current Construction Management (CM) System
Purpose: The purpose of this activity is to learn enough about the current system's
data, processes, interfaces, and geography to expand the understanding of scope
and to establish a common working vocabulary for that scope.

Inputs! Process! Deliverables: The principal deliverables of this activity are the
system models. The system analyst develops system models by using fact-finding
techniques with the user managers, and holding joint application development
(JAD) sessions with all key people. Relevant information is also captured through
company manuals. This study helps the system analyst to understand the
business and processes involved in it. Based on this study, data, process, and
interface models are developed. These system models are verified by system
users to achieve consensus on the construction management processes.

CM Example: Typically, a system analyst would discuss different data types such
as change orders and proposals with the project controls manager to get a better
understanding of these data elements. In the case of processes, a system analyst
would refer to organizational manuals to understand the processes involved with
data elements such as document flow during acceptance of change orders.
Variations: If a system development is triggered by a need to modify the existing
project system, then it is essential to model and understand the existing system to
make appropriate changes. In the case of a new system, only a generic model
needs to be developed which can give a basic idea about the data, processes, and

interfaces of the generic construction project control system. Again, this activity

86

would take much less time if a system developer has had experience in developing

this type of system.

4.4.3.2.2 Analyze Problems and Opportunities

Purpose: The purpose of this activity is to understand all underlying causes and
effects of all problems and opportunities.

Inputs] Process! Deliverables: Based on the problem statement, each problem
and opportunity are analyzed strictly in a business sense to identify the causes and
effects of those problems and opportunities. This study helps to understand issues
related to the problem or opportunity before one can make decisions about solving
them. This step is more important in the case of replacing an old information
system by a new one.

CM Example: Consider a problem such as a situation where schedules need to be
updated and analyzed more frequently but the scheduler is too busy with updating
past data in the system.

Variations: While developing a new system, one needs to analyze technology

driven opportunities rather than existing problems.

4.4.3.2.3 Establish System Improvement Objects and Constraints
Purpose: The purpose of this activity is to establish criteria against which the
developed system can be measured and to identify any constraints that may limit

flexibility in achieving those improvements.

87

Inputs! Process! Deliverables: An objective is a measure of success. Objectives

should be measurable statements of business performance that define the

expectations for the new system. Objectives must be tempered by identifiable

constraints. Constraints fall into four categories: schedule, cost, technology and

policy. The main deliverables of this activity are system improvement objectives

and constraints.

CM Example: A system can have different objectives such as on-line data entry or

on-line publishing of reports. The following list illustrates possible constraints for

information system development.

0 Schedule: The system has to be running before the actual construction starts.

0 Cost: The system has to be within budget. Therefore, all expensive system
solutions should be evaluated against this constraint.

. Technology: Technical sophistication of organizational staff can be a big
constraint before selecting a technology tool.

0 Policy: All systems should use "MS Project" as scheduling software

Variations: All types of projects need to go through this activity.

4.4.3.2.4 Modify Project Scope and Plan

Purpose: The purpose of this activity is to reevaluate project scope, schedule and
expectations. The overall project plan is then adjusted as necessary, and a
detailed plan is prepared for the next phase.

Inputs! Process! Deliverables: System analysts need to make decisions on the

basis of findings in the study phase to determine if the system objectives can be

88

accomplished within time and budget. Based on this decision, a revised project
plan is developed. This revised plan takes all facts about the system, objectives
and constraints under consideration and negotiates scope of the system with the
system owner. Objectives are also prioritized to identify the higher priority issues.
CM Example: A System analyst may decide to go ahead with a scheduling and
cost control system and consider document management as a part of a second
phase.

Variations: All types of projects need to go through this activity.

4.4.3.2.5 Present Finding and recommendations

Purpose: The purpose of this activity is to communicate the project plan and goals
to all staff members.

lnputsl Process] Deliverables: The key deliverables of this activity are the
detailed study findings. It usually includes a feasibility update, which consists of
problems, opportunities, cause-effect analysis, system objectives and constraints,
and a revised project plan. This activity helps to communicate to everyone related
to the project about the revisions and the new project plan. It also acts as an
agreement between the system owner and system analysts. It also helps to
document changes and the new scope of the project.

Variations: This activity can be expedited in case of urgent system requests.

89

4.4.3.3 Definition Phase

The definition phase is used to define the system business requirements in a
strictly logical manner. Different modeling techniques are used to represent the
system requirements. These models are later used for selecting the application
architecture and for designing the system. Examples of models typically used for
this purpose will be defined and described in this section. Models identify the user
requirements in a logical manner, which helps in identifying and verifying the IT
tools as a part of the information system. The following sections describe the
activities involved in the definition phase along with an example from the
construction project management field related to each activity. Figure 4.8 shows
the deliverables generated from each activity and the relationships between these

deliverables.

 

Outline Business
Requirements

l

Detail Requirement ‘— Discovery
Models Prototypes

l

Prioritized Business
Requirements

1

Revised Plan &
Requirements Statement

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure. 4.8 Definition Phase of CMSDM

90

4.4.3.3.1 Outline CM Requirements

Purpose: The purpose of this activity is to identify, in general terms, the business
requirements for a new or improved information system.

Inputs! Process! Deliverables: Based on the system improvement objectives a
requirement statement outline is developed. Each objective is associated with the
corresponding system input, process and output. This framework acts as a
guideline for future activities in the definition phase. A business requirement outline
is more of a guideline than an exhaustive list of business requirements. It should
be utilized more for organizing the system requirements in a structured manner to
make sure that all requirements are covered.

CM Example: System requirements from the different project control subsystems
such as cost control and time control can be outlines to make sure that all system
requirements are identified at a higher level of abstraction.

Variation: This activity is very essential in the case of developing an integrated
system consisting of different applications such as time, cost, and contract

monitoring system.

4.4.3.3.2 Model CM System requirements

Purpose: The purpose of this activity is to model business system requirements
such that they can be verified by the system users and are subsequently
understood and transformed by the system designers into a technical solution.
Inputs! Process! Deliverables: Based on the outline of the business

requirements, logical models are developed. Logical models depict what a system

91

must do, and not how the system should be implemented. The deliverables of this
activity are the system models. System models are of four types, consistent with
the system development building blocks.

Data Models (such as Entity-relationship diagrams) are used to model the data
requirements of the new system and the relationships between the different data
elements. These data models eventually serve as the starting point for designing a
database.

Process Models (such as Data Flow Diagrams) are used to represent the
workflow through business systems. These process models serve as a starting
point for designing computer applications and programs.

Interface Models (such as context level diagrams) are used to depict net inputs to
the system, their sources, net outputs from the system, their destinations, and
shared databases. These interface models serve as the basis for designing user
and system interfaces.

Distribution models are used to represent system communication requirements
for distributing the data, processes, and interfaces to different geographical
locations.

Variations: All types of projects need to go through this activity.

4.4.3.3.3 Build Discovery Prototype
Purpose: The purpose of this optional activity is to (1) establish user interface
requirements, and (2) discover detailed data and processing requirements

interactively with users through rapid development of sample inputs and outputs.

92

lnputsl Process! Deliverables: This activity is very relevant to the construction
industry as the people in the construction industry are very aware of their
requirements but most of them cannot express them without actually seeing them.
Requirement prototypes are used to understand the user interface requirements.
Requirement prototypes are a simple mock-up of screens and reports that are
intended to help system analysts discover their requirements. Discovered
requirements are added to the information system logical models. This activity
occurs in parallel with the system modeling activity and it occurs, as deemed
appropriate or desirable, by the system analysts.

Variation: Prototypes are very helpful to identify user requirements for user
interfaces, reports and input forms, especially while developing a customized

systems.

4.4.3.3.4 Prioritize CM Requirements

Purpose: The purpose of this activity is to prioritize requirements for a new
information system. It is not the intent of this activity to eliminate some
requirements. It is only to recognize that some requirements can be implemented
later than others.

lnputsl Process! Deliverables: The deliverables of these activities are the
business requirements' priorities. Prioritizing helps system analysts to make
decisions about implementation of business requirements in case the project goes
over budget or behind schedule. In such cases, based on the priorities, system

analysts can make decisions about implementing some of the requirements of a

93

later stage. All business requirements can be prioritized in terms of mandatory,
desirable or optional categories.

CM Example: Development of a project intranet can be prioritized and may be
developed after all essential systems are up and running.

Variations: All types of projects need to go through this activity.

4.4.3.3.5 Modify the Project Plan and Scope

Purpose: The purpose of this activity is to modify the system development project
plan to reflect changes in the scope that have become more apparent during the
requirement definition.

Inputs] Process] Deliverables: After completing all activities in the definition
phase, a revised project plan is developed which covers the remainder of the
project. The project schedule and budget are reevaluated and new changes are
negotiated with the project director. This process is the last activity of the project
analysis part of the system development. Therefore, a requirements statement
which is a consolidation of all documents generated in the survey, study and
definition phases is developed and stored in a project repository as a reference.
The requirement statement should not be frozen as the requirements may change
during the life cycle of the project and some changes may need to be made. The
requirement statement should act as a guiding document for the future activities
and project plans. At the end of the analysis phase, the system development goes
smoothly into the design part of the system development process.

Variations: All types of projects need to go through this activity.

94

4.4.3.4 Configuration Phase

The primary objective of the configuration phase is to identify and research
alternative manual and computer-based solutions to support a target information
system, to evaluate the feasibility of alternative solutions, and to recommend the
best overall alternative solution. This is the first time that the focus of the
information system development shifts from the business requirements to physical
implementation. The following sections describe the activities involved in the study
phase along with an example from the construction project management field
related to each activity. Figure 4.9 shows the deliverables generated from each

activity and the relationships between these deliverables.

 

Candidate
Solution

l

Feasibility
Analysis

l

System
Proposal

 

 

 

 

 

 

 

 

 

 

 

Figure 4.9 Configuration Phase of CMSDM

9S

4.4.3.4.1 Define Candidate Solution

Purpose: The primary purpose of this activity is to identify alternative candidate
solutions for the business requirements defined during system analysis.

Inputs! Process] Deliverables: Based on the business requirements, candidate
solutions are identified. Most of the time these solutions define the application
architecture of the system. Normally a particular software solution is not selected.
But in the case of an existing corporate application architecture, the selected
architecture is tested for business requirements and the design activities are
started using the same solution.

CM Example: The system analyst needs to make decisions such as whether the
project needs a networked solution or a single user system. A typical solution can
be a progress planning and cost control system installed on a client-server
platform with multiple and remote access to cost and time data.

Variations: All types of projects need to go through this activity.

4.4.3.4.2 Analyze Feasibility of Alternative Solutions

Purpose: The purpose of this activity is to evaluate the alternative candidate
solutions according to their economic, operational, technical, and schedule
feasibility.

lnputsl Process! Deliverables: The characteristics and features of the solutions
identified earlier are compared to each other and evaluated against four sets of
criteria. A first criterion, technical feasibility, identifies the technical practicability

of the solution. It looks into the issues such as whether or not the staff has

96

technical expertise to build and operate this system. The second criterion,
operational feasibility, identifies whether or not the solution can satisfy the
business requirements. The third criterion, economical feasibility, evaluates the
solutions for cost-effectiveness. The fourth criterion, schedule feasibility,
evaluates the time required to finish the system development project.

CM Example: Identification of a time control software that best suits the project
requirements based on a feasibility study.

Variations: All types of projects need to go through this activity.

4.4.3.4.3 Recommend a CM System Solution

Purpose: The purpose of this activity is to select a candidate solution having "best
overall" operational, technical, economical, and schedule feasibility.

lnputsl Process! Deliverables: Based on the analysis done in the study phase, a
solution having best "best overall" operational, technical, economical and schedule
feasibility is selected. Based on the recommended solution, a written and verbal
system proposal containing an analysis of altemative systems is presented to the
project director. Then the project director makes the final decision about
acceptance of the proposal. Generally, a proposal is selected considering the
trade-off between time, cost and features offered by the solution.

Variations: All types of projects need to go through this activity.

97

4.4.3.5 Procurement Phase

The procurement phase includes identification of software and hardware criteria
that can satisfy the recommended solution for the target information system. On
the basis of these criteria, vendor proposals are solicited, evaluated, ranked,
selected and recommended to the system owner. After awarding the contract to
the vendors, system integration criteria are developed. Design of the information
system starts after the procurement phase is finished. The following sections
describe the activities involved in the procurement phase. Figure 4.10 shows the
deliverables generated from each activity and the relationships between these

deliverables.

 

List of Product Options &
Technical Criteria

l

Request for Proposal OR
Request for Quotation

l

Validated
Proposals

J,

Hardware and/or Software
Recommendations

l

Contract
Order

l

Integration
Requirements

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 4.10 Procurement Phase of CMSDM

98

4.4.3.5.1 Research Technical Criteria and Options

Purpose: The purpose of this activity is to research technical alternatives to
specify important criteria and options that will be important for the new software
and/or hardware that are to be selected.

Inputs! Process! Deliverables: The primary deliverables of this activity include
lists of potential vendors, product options and technical criteria. Technical criteria
are identified based on the hardware and/or software requirements identified in the
configuration phase. Product options and potential vendors are identified using
various sources such as trade magazines, trade shows and sales persons. lntemal
organizational standards can also influence the software and/or hardware options.
CM Example: Considering the tight schedule requirements for delivering system
solutions for construction projects, one can hardly go through all of the different
product options. Therefore, it is always a better option to select a product based on
the research and survey done at the organizational level.

Variations: All types of projects need to go through this activity.

4.4.3.5.2 Solicit Proposals from Vendors

Purpose: The purpose of this activity is to solicit product proposals or quotes from
candidate vendors.

Inputs! Process] Deliverables: The primary deliverables are requests for
proposal (RFP) or requests for quotation (RFQ) that are to be received by the
candidate vendors. RF Ps are used when the product has not been selected, while

RFQs are used when product has been selected. The primary purpose of an RFP

99

is to communicate requirements and desired features to prospective vendors.
Requirements and desired features should be categorized as mandatory (must be
provided by the vendor), extremely important (desired from the vendor but can be
obtained in—house or from a third party vendor), or desirable (can do without it).
The primary purpose of RF Q is get quotations for the selected product

CM Example: Proposals can be accepted from different scheduling product
distributors such as Primavera Project Planner and MS Project.

Variations: All types of projects need to go through this activity.

4.4.3.5.3 Validate vendor Claims and Performance

Purpose: The purpose of this activity is to validate requests for proposals and/or
quotations received from vendors.

Inputs! Process! Deliverables: Vendor proposals are validated on the basis of a
demonstration of software packages and references to the manuals. Based on
these validations, vendor proposals are selected for further evaluation.

Variations: All types of projects need to go through this activity.

4.4.3.5.4 Evaluate and Rank Vendor Proposals

Purpose: The purpose of this activity is to evaluate and rank all validated vendor
proposals.

inputs! Process! Deliverables:: A cost-benefit analysis is used to evaluate and
rank the validated proposals. Based on the rankings, the proposals are

recommended to the project director for a final decision.

100

Variations: All types of projects need to go through this activity.

4.4.3.5.5 Award Contract and Debrief Vendors

Purpose: The purpose of this activity is to negotiate a contract with a vendor who
supplied the winning proposal and debrief those vendors with losing proposals.
Inputs! Process! Deliverables: After getting a final approval of the selected
proposal, the system analyst should negotiate the contract with the vendor.
Negotiations should include issues such as final price, site licensing fees,
corporate license fee, corporate discounts, maintenance terms and technical
support.

Variations: All types of projects need to go through this activity.

4.4.3.5.6 Establish Integration Requirements

Purpose: The purpose of this activity is to establish the requirements necessary
for integrating the awarded vendor's products into the existing information system
or in to other parts of the information system

Present Finding and recommendations: This step is accomplished by reviewing
the data, and process models, and the hardware and software specifications of the
awarded vendor's products. Based on this study, sets of integration requirements
are developed to ensure that a system works in harmony with other systems.

CM Example: When a spreadsheet based scheduling system is replaced by
Primavera Project Planner, one needs to identify the technical requirements of

integrating the schedule and cost data.

101

Variation: When a new system is developed, some integration requirements need
to be developed between commercial systems and/or customized systems to

ensure that they work together as a single system.

102

4.4.3.6 Design and Integration Phase

The central idea behind the design and integration phase is to convert the models
developed in the definition phase to models in terms of the selected technology so
that the system builder can build a new system on the selected platform that can
satisfy the business requirements. The following sections describe the activities
involved in the design and integration phase. Figure 4.11 shows the deliverables

generated from each activity and the relationships between these deliverables.

 

Network Design

 

 

 

1

Normalized Distributed
Data Models
l ,

Distributed
Process Models

 

 

 

 

 

 

 

 

 

 

 

Database Design Input and Output Design
Specifications Specifications

 

 

 

 

 

V
Interface Design
Specification

 

 

 

 

 

 

 

Figure 4.11 Design & Integration Phase of CMSDM

103

4.4.3.6.1 Design Networks

Purpose: The purpose of this activity is to design network topography and network
components.

Inputs! Process! Deliverables: A network is designed based on the network
decomposition diagram and on the network connectivity diagram developed in the
system analysis phase. This activity involves identification of the network
topography based on the geographical position of the project office, as well as on
selection and configuration of network components such as bridges, hubs,
switches, and cables.

Variations: This activity need not be performed in case of a stand alone system.

4.4.3.6.2 Analyze and Distribute Data

Purpose: The purpose of this activity is to develop a good data model.

Inputs! Process! Deliverables: An initial data model is developed in the definition
phase. But that data model does not consider issues such as the selected
database development platform or the constraints related to this platform. System
users are involved in the development of the data models and the data
characteristics. After developing improved data models, a network topology
diagram is developed. After that data stores are distributed to different locations.
The process models may also be changed with respect to new data models. The
principal deliverables of this activity are normalized distributed data models and

revised process models.

104

CM Example: If a scheduling system is used as a shared application, then the
project data is stored on a server while in the case of a single user system, it's
saved on the user machine.

Variation: The normalized data models are required only when a customized
system is developed using system development tools. In the case of networked
solutions for construction projects data are stored on a single server for most of the
shared applications. For single user applications, one needs to identify which users

are using each application, and then distribute the data accordingly.

4.4.3.6.3 Analyze and Distribute Processes

Purpose: The purpose of this activity is to analyze and distribute system
processes to fulfill the network requirements of the new system.

Inputs! Process! Deliverables: Processes are distributed throughout the network
based on the data model, process model and application architecture.

CM Example: When a scheduling system is designed, one needs to identify the
locations where the scheduling data will be stored and the workstations from which
that data will be accessed.

Variations: In the case of networked solutions, most processes are performed on
client computers. For single user applications, one needs to identify which users

are using each application and then distribute the processes accordingly.

105

4.4.3.6.4 Design Database

Purpose: The purpose of this activity is to prepare technical design specifications
for a database that will be able to adapt to future requirements and expansions.
Inputs! Process! Deliverables: Database schema are developed based on the
data models and the selected development platform. The database schema are
structural models for a database. They are models of records and relationships to
be implemented by the database. Technical design specifications include data
tables, data fields, and relationships between the tables and indexes.

Variations: No database design is required when commercially available solutions
are purchased. In the case of commercially available applications, one needs to
analyze the database schema of the ready solution to understand possible
customizations for certain data elements or reporting requirements. The data
structure of commercially available solutions also need to be analyzed to identify
any attributes, which may be missing compared to data models developed in the
analysis phase. In such a case, those attributes need to be added as a custom

data item within the same application or within the customization environment.

4.4.3.6.5 Design Computer Output and Input

Purpose: The purpose of this activity is to prepare technical design specifications
for user inputs and outputs.

Inputs! Process! Deliverables: This activity is based on the input and output
design requirements specified in the system analysis. Design of the computer input

consists of three processes. The first is a data capture mechanism, which identifies

106

the data to be inputted. The second is data conversion, which is the process of
translating the source document into a machine-readable format. The third is data
input, which is the actual entry of data in a machine-readable format into the
computer. A system analyst needs to design source documents, which are paper
forms used to record data that will eventually be entered into the computer. A
system analyst also needs to design a data capture mechanism and computer
input screens based on the user requirements identified in the data flow diagram.
The input screens should be designed similarly to the source document to make
data entry easier. A system analyst also needs to design output related
specifications such as the format and layout of reports. A system analyst needs to
work closely with the system users to identify user requirements and preferences.
Prototyping is used predominantly in designing the system inputs and outputs.

CM Example: In most construction subsystems, data such as requisitions sent by
a contractor, are captured on a piece of paper and then recorded in a computer in
a batch or on-line format.

Variations: Input screens need not be designed for ready commercially available
solutions. In the case of a ready commercially available solution, custom reports
are designed based on user requirements. If none of the commercially available
solutions can satisfy the unique reporting requirements, then custom reports need
to be developed using report writing tools. This generally requires accessing
databases in those applications. The data structure of the commercially available
software identified in the database design phase can be helpful in developing

customized reports.

107

4.4.3.6.6 Design On-line User Interface

Purpose: The purpose of this activity is to prepare technical design specifications
for the on-line user interfaces.

Inputs! Process! Deliverables: The basic component of a user interface consists
of a menu which facilitates user movement from one screen to another. A state
transition diagram is used to represent the possible movements among the
different screens. This component is developed based on the interface design
requirements identified in the system analysis phase. A system designer needs to
work closely with the users to make easy-to learn and easy-to-use interfaces.
Human engineering plays a major role in designing the interfaces.

Variation: This activity is required only for customized system development

projects.

4.4.3.6.7 Present and Review Design

Purpose: The purpose of this activity is to present final design specifications and
plan future project activities.

Inputs! Process! Deliverables: A technical design statement is prepared after
completing all design activities. This acts as a guiding source for the activities in
the construction phase. A project plan is revised and a detailed project plan is
developed for all of the remaining activities of the project.

Variation: This activity can be expedited in case of an urgent system request.

108

4.4.3.7 Construction Phase

System implementation involves the construction of a new information system and
the delivery of that system into production. The purpose of the construction phase
is two.fold: A

c To build and test a functional system that fulfills the business and design

requirements.

0 To implement the interfaces between the new system and an existing system.
The following sections describe the activities involved in the construction phase
along with an example from the construction project management field related to
each activity. Figure 4.12 shows the deliverables generated from each activity and

the relationships between these deliverables.

 

Installed
Network

l

Database
Structure

l

Installed Software
Packages

l

New Programs

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 4.12 Construction Phase of CMSDM

109

4.4.3.7.1 Build and Test Network

Purpose: The purpose of this activity is to build and test the new network.

Inputs! Process! Deliverables: This activity is based on the network design
requirements identified in the design phase. The networks are implemented
according to these requirements. This activity includes installation of hardware
such as the server, workstations, network interface card, and cabling. It also
includes software-related activities such as installing the network operating
systems on the client and server machines. This network is tested after installation
is done for the expected business requirements.

Variations: This activity is applicable only to the networked solutions. In single
user systems, peer-to-peer networks are developed to share data and resources.
But in that case only cabling needs to be done. In the case of a single user system,

only hardware related to workstations is installed and tested.

4.4.3.7.2 Build and Test Databases

Purpose: The purpose of this activity is to build and test databases.

Inputs! Process! Deliverables: The database is developed based on the
database design requirements specified in the technical design statement. The
deliverable of this activity is an unpopulated database structure. A database
platform is installed before developing the database structure. This database
structure is tested with some test data.

Variations: This activity is applicable only to the custom application development.

110

4.4.3.7.3 Install and test New Software Packages

Purpose: The purpose of this activity is to install the software packages.

Inputs! Process! Deliverables: After receiving the software packages and
documentation from the software vendor, they can be installed. The installed
software packages are tested for expected system performance.

Variations: This activity is not applicable for customized system solutions. In the
case of a ready commercially available solution, this activity also includes the

development of source documents and custom reports.

4.4.3.7.4 Write and Test New Programs

Purpose: The purpose of this activity is to develop all of the programs which need
to be developed in-house.

Inputs! Process! Deliverables: All customized applications are developed using
technical design statements. The plans for programming and test data are
previously developed in the system design stage.

CM Example: This activity is used to develop customized applications to link
different functional subsystems to provide a common working environment. It is
also used to develop customized reports using report-writing tools.

Variation: This activity is required only for customized system development

projects.

111

4.4.3.8 Delivery Phase

The purpose of the delivery phase is to facilitate a smooth conversion from the old
system to the new system. The following sections describe the activities involved
in the delivery phase along with an example from the construction project
management field related to each activity. Figure 4.13 shows the deliverables

generated from each activity and the relationships between these deliverables.

 

Successful
System Test

1

Conversion
Plan

l

Restructured
Existing Data

l

User Training and
Documentation

1

New Functioning
Information System

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 4.13 Delivery Phase of CMSDM

112

4.4.3.8.1 Conduct System test

Purpose: The purpose of this activity is to test all of the software packages and
custom-built programs to ensure that they work together.

Inputs! Process! Deliverables: System tests are conducted using test data.
System tests may result in the modification of system programs. After
modifications, system tests are conducted again and this iteration continues until a
successful system test is developed.

Variation: This activity is required only in the case of systems consisting of

multiple subsystems sharing data and information with each other.

4.4.3.8.2 Prepare Conversion Plan

Purpose: The purpose of this activity is to prepare a conversion plan for smooth
transition from the old system to the new system.

Inputs! Process! Deliverables: A conversion plan including a schedule for
populating the databases, end-user training and documentation, and a strategy for
converting from the old system to the new system are produced by this activity.
There are four types of conversion strategies. The first is an abrupt cut-over where
the whole system is replaced by a new system at the same time. The second is a
parallel conversion where both the old and new systems are run at the same time,
and after fixing all problems the new system can be introduced gradually or
abruptly. The third is a location conversion where systems are replaced gradually
at different locations. The last is a staged conversion where each successful

version of the system is converted as it is developed.

113

Variation: In a new project environment, an information system is introduced

abruptly after training the users.

4.4.3.8.3 Install Databases

Purpose: The primary purpose of this activity is to populate a new system with
existing data from the old system.

Inputs! Process! Deliverables: Normally some form of data restructuring is
required while transferring the data. Data are transferred manually or by
developing some transition programs which can populate data automatically to the
new system.

Variations: In the case of a new information system development effort, the
system is normally planned to be delivered before the actual start of construction
and the generation of substantial data. In the case of system modification, the old
data are transferred using general tools such as spreadsheets or database

applications.

4.4.3.8.4 Train System Users

Purpose: The primary purpose of this activity is to provide training and
documentation to the system users and to prepare them for a smooth transition to
the new system.

Inputs! Process! Deliverables: Training can be provided in-house or through
external sources to all users. System vendors provide training for most of the

commercially available packages, while system analysts provide training for all the

114

customizations. User-friendly, step-by-step system documentation is very essential
for successful system implementation. User manuals should be developed and
made accessible to all the users.

CM Example: System users such as project managers and project engineers
need to be trained on the new system. Training is essential, especially in a
construction project environment where user computer literacy is not very high.

Variation: All types of projects need to go through this activity.

4.4.3.8.5 Convert to New System

Purpose: The primary purpose of this activity is to convert to a new system from
the old system.

Inputs! Process! Deliverables: A conversion plan and all activities mentioned
above are followed to complete a system development process. The whole system
development process and experience are evaluated with the team members and
used for future development efforts. From here onwards, the system support
phase starts.

Variation: All types of projects need to go through this activity.

4.4.3.9 System Support
The system support phase includes activities such as monitoring system
performance, solving system performance issues, documenting changes and

supporting system users on working with the system. One of the main issues

115

related to the system support in a construction project environment is change
management.

Change Management: The construction project team is very dynamic in nature.
People are frequently replaced from or added to the project team. New members
of the project team need to get accustomed to the project information system. A
user-friendly system, user system documentation, and early quality training could
help new team members in getting familiar with the project information system
quickly. As the project progresses, new user requirements are identified. These
new system requirements need to be justified on the basis of tradeoffs between
the new system features and resources spent on system modification. If these
requirements are found justifiable, then a fresh system request should be filed and
the system should go through the process of system modification using phases

and activities of CMSDM.

4.5 Major Variations in CMSDM

CMSDM describes the core framework of information system development in a
construction project environment. Figure 4.14 which is formed by the combination
of figures related to individual phases, shows the deliverables produced in the
different phases of CMSDM and the interdependence among these deliverables.
CMSDM is a generic methodology for projects in the construction industry, which
needs to be applied to a particular project and is based on the project and system
variables. Combinations of these variables form a unique project environment,

which needs a different approach for developing an information system. In those

116

variations some of the activities may be merged or exploded in order to get details
according to the project requirements. For example, if a commercially available
software solution is identified, then activities such as design of input screens,
design of databases, development of normalized data models and writing
programs can be replaced by detailed activities such as design of source
documents, design of reports, and software customization. Some of the most
important variables which affect these deviations of methodology are identified
rather than describing the different deviations of the methodology itself. All of the
variables are divided into two categories.
0 Project specific variables . System specific variables

The project variables influence all stages of a project life cycle while the system
variables have an effect after the system architecture is decided in the system
configuration phase. Based on the decisions taken in the configuration phase, the

scope and content of the activities in the remaining phases change considerably.

117

Existing System

 

 

Service
Request

‘— Project Director

 

 

1

 

 

Problem
Statement

 

 

l

 

 

Scope
Statement

 

 

 

l

 

 

Project
Plan

 

 

I

 

 

Project Feasibility
Assessment Report

 

 

 

Y

 

_p

System
Models

 

 

 

l

 

l.

 

 

Cause & Effect
Analysis

 

 

l

 

 

System Objectives &
Constraints

 

 

 

l

 

 

New System

Plan

 

 

l

 

 

Detailed Study

Phase

 

 

l

 

 

Outline Business
Requirements

 

 

 

Figure 4.14 Process Flowchart for CMSDM

118

 

Survey
Phase

 

 

a4

 

Study
Phase

 

Y

i

Definition
Phase

 

Outline Business

 

 

"——* Requirements

 

Requirements

1

 

 

 

 

Models

l

Prioritized Business

 

 

 

 

 

 

 

l

Detail Requirement ‘...

 

Revised Plan &
Requirements Statement

 

 

 

 

Candidate

.____, Solution ‘____ Software Option

 

 

 

l

Feasibility
Analysis

1

System
Proposal

1

 

 

 

 

 

 

 

 

 

 

Discovery
Prototypes

 

 

 

 

List of Product Options &
Technical Criteria

 

1

Definition
Phase

Hardware and

 

Configuration
Phase

 

—X-—
Vendor and

 

 

 

l

 

Request for Proposal OR
Request for Quotation

 

 

 

l

Validated
Proposals

l

 

 

 

 

Product Facts

 

Procurement
Phase

4

Figure 4.14 Process Flowchart for CMSDM (Cont)

119

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

l A
Hardware and/or Software
Recommendations
Contract
Order P mm
i I Phase
Integration System Network
Requirements Architecture Models .41:—
i 1
Design Networks
Data Models
Normalized Distributed S tl
Data Model 13115 in:
o e 8 Procurement
* I Phase
Distributed
Process Models Interface Model
, l
Database Design Input and Output Design
Specifications Specifications

 

 

 

 

 

l

System Proposal

1 ,

 

 

 

7

 

 

Interface Design
Specification

 

 

Figure 4.14 Process Flowchart for CMSDM (Cont.)

120

 

 

 

 

 

 

 

 

 

 

Installed
Network
Database
Structure
j Construction
Phase

 

Installed Software
Packages

I

New Programs
Successful
System Test

I

Conversion
Plan

1 Delivery
Phase

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Restructured
Existing Data

I

User Training and
Documentation

New Functioning
Information System i

 

 

 

 

 

 

 

 

 

 

 

 

Figure 4.14 Process Flowchart for CMSDM (Cont.)

121

4.5.1 Project specific variables
These variables are based on the characteristics of the construction project.

These variables are identified before the start of the system development process

and corresponding changes are done in the system development methodology.

. Project Origination: An information system development project can be
originated as a new system development for a new construction project or as a
modification to an existing system. In the case of the modified system, the
original system needs to be studied and documented in order to understand the
system itself and the integration requirements with respect to the new system.
But in the case of the new project environment, only generic construction
practices need to be studied.

0 Project control: There are many activities such as plan and present the project,
and present the findings, which are important from a project management point
of view. These activities can be altered in case of an urgent system
development requirement. But again, an experienced project developer should
manage the alteration of these activities as this may lead to a lack of project

planning and control.

4.5.2 System specific variables

These variables are identified during a system development effort

depending on the decisions taken during the system configuration phase.

122

4.5

User Access: Single user or multi-user system. In the case of multi-user
access, a networked system needs to be developed. Such a system needs to
go through all of the network development activities.

Applications: Commercially available ready application, customized application,
or Hybrid system. Commercially available ready solutions do not need activities
such as development of a normalized data model, database design or
designing on-line user interfaces. In the case of a custom application, all
activities need to be followed, while in the case of hybrid solutions commercially
available solutions are customized to the user requirements and, therefore,
only some of the activities are followed. 9

Reports: Reports generated within a commercially available solution or a using
reports writing tool. If reports are generated using commercially available
reporting tools then the data structure of the commercially available application

package needs to be analyzed to customize it and generate reports.

Summary

This chapter describes the phases and activities involved in the system

development methodology for developing a construction management information

system in a project environment. Different contents of the methodology such as

process, technique or strategy and CASE tool are described. Issues related to the

selection of an appropriate system development process and selection criteria are

also discussed in detail.

123

The CMSDM can be applied to different project environments with
appropriate modifications according to the project and system variables. It is not
the intent of this thesis to describe all variations of the information system
development methodologies. The intent is to describe the core framework of
system development and the variables which govern different variations. The next
chapter demonstrates the application of CMSDM for development of a cost control
system for a management team headed by a construction management firm using

one variation of CMSDM.

124

CHAPTER 5

DEVELOPMENT OF COST CONTROL SYSTEM

5.1 Introduction
Chapter 4 describes the phases and activities involved in the development of
information systems in a construction project environment. Even after following
the steps described in the core methodology, one needs to apply and make
appropriate changes according to the project and system variables. This chapter
demonstrates the application of CMSDM for development of a cost control
system. This cost control system is intended for a construction management firm
coordinating a management team for a large commercial construction project.
The following sections describe the construction management contract
delivery systems, CM (Construction Management) firms, and the services

provided by them before demonstrating the application of CMSDM.

5.2 CM Contract Administration System
Clients of this information system are Construction Management (CM)
organizations. Therefore, before developing a system for them, one needs to
understand the functioning of construction management organizations to
understand the details of construction management cost control requirements
from the cost control system.

CM is a process by which a potential project owner engages an agent,

referred to as CM, to coordinate and communicate the entire construction

125

process, including project feasibility, design, planning, letting, construction, and
project implementation, with the objective of minimizing the project cost and time,
and maintaining the project quality [Adrian 1981].

The definition of four important terms needs to be studied in detail to
understand the exact difference between general contracting, turnkey
construction and design-build contract delivery system.

Agency: Figure 5.1 shows the difference in the contractual arrangement
between general contracting and CM. Unlike the general contractor, an agent
(the CM) has an obligation to serve the owner as if the CM were the employee of
the owner. An agent has legal authority to represent the owner and to carry out
construction management cost control dealings on the owner’s behalf. Legally,
an agent has the following contractual obligations to its employers: loyalty,
obedience, performance, reasonable care, accounting, and information.
Therefore, an information system developed for a CM firm should be focused on
the owner’s information requirements. Levels of data extraction should be high

enough to manage the owner’s information requirements.

Construction Management General Contracting

Project Preject
Owner Owner
Construction Designer

General
Contractor

l |

[Sub-Contractorl ub-Contractor rub-Conuactoj

Figure 5.1 Construction management versus general contracting

 

 

 

Contractor

 

l Contractor

 

 

 

l Conuactor

 

 

126

Coordination and Communication: A CM firm acts as a leader of the owner's
construction management team consisting of the owner’s representatives,
designers, engineers, inspectors, govemment agencies, material and equipment
vendors, and lending agencies. The CM firm has the responsibility to coordinate
all parties and communicate project relevant information to the concerned
parties. Therefore, an information system developed for a CM firm should focus
on data accessibility, data communication and data transparency among all the
concerned parties to improve coordination through better communication.
Involvement in the Entire Project Process: The CM firm is involved in the
entire project process, including project feasibility, design, planning, bidding,
construction and implementation. The CM process is consistent with the systems
approach to management. The systems approach indicates that in order to
optimize the solution to a problem, one must first interrelate all the component
parts. It may follow that some or all of the component parts may have to be
performed sub-optimally to achieve optimal performance of the entire system. An
lnfonnation system developed for a CM firm should have different functional
capabilities required in different stages of a project and all sub-systems should
share data to achieve data and process integration. Therefore, one needs to look
into the interfaces between the functional subsystems while designing an
information system.

Minimize Project Time and Cost and Maximize Quality: The three variables:
time, cost and quality are essential for successful completion of the project. A CM

firm has to manage all phases of construction with an objective to minimize cost

127

and time, and to maximize quality. The time and cost planning and control
applications become core applications for the whole management information

system for CM firms.

5.2.1 CM Services

As discussed earlier CM firms are involved in all phases of construction projects.
Again, services provided in different phases vary according to the project
characteristics and owner requirements. An information system requirement of a
CM firm depends on the services provided by the firm. Table 5.1 shows the list of

services typically provided by CM firms.

5.2.2 Cost Management Activities

Considering the importance of managing costs for success of construction
projects, CM firms are involved in many different cost management activities.
Cost related activities start from the project conceptualization to maintenance of
facilities after construction is completed. Figure 5.2 shows the activities in which
CM firms are involved and the dependency between these activities. The bold
box in figure 5.2 represents the activity of developing cost control systems
whereas the last four activities represent the core processes involved in the cost
control operation. The following list includes a brief description of different

activities performed by CM firms.

128

Table 5.1 Services Provided by CM Firms [Adrian 1984)

 

Ereconstruction Phase
Owner-needs identification study . Value Engineering
Project feasibility study 0 Parameter Estimating
Tax analysis of project . Scheduling of Design and
preconstruction

0 Marketing research for proposed
Project
Assistance in obtaining finance Bid Packaging and Phasing
Assistance in obtaining permits Awarding contract & Process Paper
and zoning Work
0 Budgeting 0 Setting out operating procedures and
responsibilities

Identification of long-lead items

Construction Services

0 Detailed Planning and . Cost and time control system
Scheduling

0 Construction Phase Estimation . Process contractor payment
0 Operating Procedures . Testing the completed project
0 Supervision . Marketing the project

0 Inspection 0 Property management

0 0

Handling Paperwork Testing Material

Unit Estimates: The project budget is developed based on the unit cost, historic
cost data and component cost. This is a small two-page project budget, which is
considered a baseline budget [CRSS Constructors, 1992].

Schematic Design Estimate and Design development estimate: As design
progresses, estimates are developed and corresponding suggestions are made
to the designers. Value engineering is also performed which leads to some
changes related to better use of material and construction processes.
Construction Document Estimates: Estimates are prepared once the detailed
plans and specifications are developed. This estimate is used to negotiate bids

with the lowest bidder.

129

 

Unit Estimate! Initial
Project Budget

I

Schematic design I

 

 

 

 

 

Estimate

 

 

 

j Design Phase

 

Design Development
Estimate

I

Construction Document
Estimate

i Procurement Phase

 

 

 

5‘

 

 

 

 

 

 

Definition Estimate

I

Decide Cost Control f
Format

- I ~

I Develop Cost ControlJ project Mobilization

 

 

 

 

 

 

 

 

 

System phase

I

Load Budget, Commitment
Information

1 A

Update Cost Data

I

Distribute & Analyze Construction Phase
Cost Data

I

Report Cost Data

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 5.2 Cost Management Activities Performed by CM Firms

130

Definition estimate: After awarding all contracts, the committed cost is
calculated and that becomes a definition or control estimate.

Develop cost control format: Depending on the scope of cost control activities
and owner expectations, cost control formats are developed. Cost control formats
include entities such as data to be captured (contracts, purchase orders, change
orders, cost codes), process of data flows (process of data transmission), reports
generated (variance analysis, cash flows). All of these formats need to be
communicated to all concerned organizations to achieve communication.
Develop Cost Control System: After identifying the data, processes, interfaces
and geographical requirements of a cost control system, the cost control system
is developed using appropriate system development methodology.

Load Data: After successful development of a cost control system, cost data
such as budget and commitments are loaded into the system. These data
become the baseline for monitoring cost performance.

Updating Cost data: With the progress of a construction project, new data are
updated in the cost control system and the project status is updated.

Distribute and analyze cost data: Cost data are distributed to cost accounts
and analyzed to monitor and control project costs.

Report cost data: Periodic reports are generated to aid decision making and
reports are submitted to the project owner to keep the owner informed about the

project performance.

131

5.3 CM Project Environment

This section is intended to describe the domain project environment, which will
guide the entire process of system development. This is a hypothetical project
domain, which is very close to an actual large commercial construction project
managed by a CM contract delivery systems. This project uses the best practices
in the industry. [Adrian 1984, Barrie et al. 1982]

It should be noted that the intent of this chapter is to demonstrate the
appliwtion of CMSDM defined in Chapter 4 and not to comment about the
fictitiousness of the domain project environment. The project environment
described below is a large size commercial construction project managed by a
CM contract delivery system. This project environment is used to develop a
problem statement as a starting point of a system development process. The
focus is on the process of system development and not on facts about the project
environment.

0 The domain project is a typical commercial construction project with an
estimated cost of $250 million managed by a CM contract delivery system

0 A cost control system needs to be developed as a part of the project initiation
efforts.

. The system should be developed in six weeks of limited project mobilization
time available due to the "fast track" nature of project. The allotted budget for

system development is $25,000.

132

5.4

The owner has given directions to use Primavera Project Planner (P3)
[Primavera 1997] as a scheduling system. Therefore the developed cost
control system should be able to share data with P3.

System users include the project director, a number of project managers, a
project controls manager, a contract engineer, a scheduler and an estimator.
The project director acts as a system owner and the project controls manager
acts as a user manager who coordinates the interaction between the system
analyst and the system users. The contract expediter is a system user who
maintains the system, takes reports and updates data. Project managers
update data and use reports for their decision making.

The time and quality of the system has higher priority compared to the cost
aspect.

A service request is placed with the regional project support group for
developing a cost control system and a system analyst is assigned to the

development work.

Development of CMCC System using CMSDM

This section demonstrates the process of construction management cost control

(CMCC) system development using the CMSDM within the described project

domain. All phases and activities included in this section are derived from the

CMSDM described in Chapter 4. Figure 5.3 describes the phases and activities

used in development of construction management cost control (CMCC) systems.

133

5.86 .EveE ..5 E82; o ...95—..8 Eofih o;8m d

 

=2. 550:: 5.3-am o 5;... a vague—80¢
. I
nae—...9, Ya 3;..6 559—50 :33 o nee—5.8 =8; _ .8; b: _ _ o
avenue Ea Una—.8 «:95. o . 3:25:32
8558 o; 2:623 88 953.9. 08:92 . 3:55.? 3
t 0020 335:; o
338; 8.553. in 3:92 o 5:31.86.— ofibfla 0
v5 m..—Eu 89.3 28...; 0 895.32; 23m o
E us 33 235% can ans—92 o 5528 3.8.5.53. Eon? Massage—82
523338... .28 . .. ......v.=:ms_.a . gain 2.. a . ooze .982 . e hag?“ .
228° v.3 _ .. u 3.839533— UUZU wig—2.33.. 80.3.; .932 o

22.5 3.5.8. 5.8%”.

m «22:238.; 0020 95:5 o BEE-950%

       

 

            

 

 

ems—8; " 32928... 82.83.. @352 o
:8 in: no. u mesa—55;? d
d adieu-5 £82. . 9:032; «552 o
. E29?
958 ..8 ...
at Z P d E. m .. m..—2:23:3— . "..9—30¢ 332 o
5393 u ..8—mug... m..—2:233; . u
Bu: e. 5250 o m awe—928;. :33 0020 5&2; 2: E32; 0
E9... 5390 ENE. o m m 69.8; 95 5.; o
832% =82. . n ............................. 98%
ENE m ,.. , . , W «Co—.95 o-EEMDZ e
gig—.8 232; o m . 3262:.
$8. . .HVSEquu...» Ba 8255;?
Eofiam 6:980 . 2522; an 3.3: _ .2532; Stem .

    

8.558% 858.30
5:8 820 52% 820

    

  

gm

8.552s
9.3.32.5 .
_ Qixa— ,

  

Eufihm UUEU 88m E893
.2883. 820 a. .89..

3009.; Essie—goo £33m .9550 300 :0 Rm 059;

134

The boxes in figure 5.3 represent the phases involved in development of the
CMCC system and arrows represent the data flow between them. The dotted

lines connect the phases and the activities involved in individual phases.

5.4.1 Survey Phase

Survey Problem Opportunity and Directive: This system is triggered by a high
priority system request. After a number of interview sessions with the project
director, the system analyst has developed a problem statement. These
requirements are prioritized on the basis of urgency of these requirements,
visibility to the construction project owner and annual benefits. Table 5.2 shows

the sample problem statement and requirements are listed in order of priority.

Negotiate the Project Scope: After discussing the problem statement with the
project director and analyzing the priorities and possible solutions, the system
analyst has developed a scope statement. Table 5.3 shows the scope of the

system in terms of four system building blocks: data, process, interface and

geography.

Plan the Project: After defining the scope of the project, system analysts need
to prepare a schedule and budget for the project and get it approved from the
project director. The budget is developed based on past experience in
developing similar projects and studying current industry trends. The schedule is

developed based on the available mobilization time. Figure 5.4 shows the

135

baseline plan for the future phases. The system analyst also needs to identify the
appropriate deviations of the system development methodology, which can be

used for this project.

Table 5.2 Cost Control System: Problem Statement

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

No. Requirements Urgency Visibility Priority Proposed
Solution
1 Manage cost related High High High Cost control
documents such as application
contracts, purchase
orders, change
documents
2 Multiple access to High Medium High Client! server
cost data! security application
(client access)
3 Periodic reporting High High High Reporting tool
4 Custom reporting High Medium Medium Custom
reporting
package
5 Online updating High Medium High Networked
access
6 Remote access for Low Low Low Remote dial-in
contractors access
7 Automated interface Medium Low Medium Interface with
with scheduling scheduling
system system

 

Present the Project: Even though in the construction environment, the project
director is not interested in the details of system development, it is a good
practice to communicate the system scope and goal in a written format to the
project team and get written approval from the project director for the
corresponding project plan to avoid future conflict. A feasibility assessment report

should be developed to communicate developments with the regional project

136

support group and other system developers to present and discuss possible

system solutions.

Table 5.3 Cost Control System: Scope Statement

 

System Focus

Scope

 

Construction

Contracts, Purchase Orders, Change Proposals, Change

management data Orders, Invoices, Requisition, Trends, Material Delivery

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Construction Loading, Updating all construction management cost control

management subjects, analyzing the performance by distributing cost to

processes cost accounts, periodic reporting and custom reporting with
ability to produce online reports.

Interface User friendly interface, Automated interface with scheduling
system

Geography Multiple workstations at office location, Remote access for
contractors

Description Duration Barchart
(daYSI

Survey 3 [:1

Study 3 I:

Definition 5 [:3

Configuration 4 I:

Procurement 4 [:2

Design 5 [2:]

Construction 8 [3:]

Delivery 6 1::

 

 

 

Figure 5.4 Baseline Schedule for System Development Project

137

 

 

5.4.2 Study Phase

The scope of the study phase depends on the unique requirements of the
construction project and the developer’s past experience with developing such
systems. If the system developer is new to the domain industry, it is very
important for the system developer to understand the data flow and decision
making process involved in a cost control system considering the decision

support characteristic of this system.

Model generic system: This activity is used to describe the data and processes
used while managing construction projects. Most of the time, a CM firm identifies
the project processes in consultation with the owner and communicates them
with all other organizations involved in a project. Therefore, the system analyst
needs to identify and understand the accepted processes. The system analyst
would most probably have discussions with the project control manager to
understand the processes. Organizational manuals may be used to identify the
processes and develop the vocabulary. Most probably, a CM firm identifies the
project processes in consultation with the owner and communicates them with all
other entities involved in project. One-page data, process and interface models
are developed to understand and validate the intended system behavior. Other
modeling techniques such as flowcharts can also be used to represent the
decision-making process. These models are further developed to represent user
requirements. More information about the construction management cost control

objects gathered by a system analyst are given below.

138

Construction management cost corirol objects

Contract! Purchase Orders: Lump sum or unit price contracts and purchase
orders form a binding agreement between the owner and contractors.
Contracts and purchase orders define the original budget and commitments
for the construction project.

Proposal! Change Order: In the case of a change in conditions, the owner
asks the contractors to submit a proposal for additional work or for a reduction
in work scope. This proposal, after negotiations, becomes a change order,
which is contractually binding on both parties. Proposals and unapproved
change orders define the pending changes in budget and commitments.
Approved change orders define the approved revisions to the budget and
commitments.

Invoice! Requisition: Contractors and suppliers submit invoices or requisitions
for the amount of work performed in a particular period. After identifying the
actual work done, the owner approves the requisition amount. Invoices and
requisitions define the actual amount paid to the contractors.

Trends: The owner makes changes in the budget or commitment on the basis
of possible changes in a project environment. These trends define the
estimated revisions to budget and commitment.

Cost Codes: Cost codes define the level of abstraction at which the CM firm
wants to monitor cost performance of the project. All cost objects such as
contracts, purchase orders, requisitions, invoices, change orders, and

proposals are distributed to the appropriate cost code based on the scope of

139

that cost object. After distribution, the owner analyzes performance at these
cost codes. For example, the contract for sitework related activities can be
divided into three different cost accounts such as demolition, project sitework,
and building sitework. This distribution helps to monitor cost performance at a

detailed level.

Construction management cost control anctions

Load database: Before the start of construction, the CM firm needs to load
cost objects such as contracts, purchase orders, and cost codes, and
distribute these costs to the appropriate cost codes. This database becomes
a baseline against which the cost performance can be monitored.

Update & distribute database: As the construction starts, new cost objects 9
such as proposals, change orders, requisitions, and invoices are developed.
These cost objects need to be updated during construction and distributed to
the appropriate cost code.

Prepare reports: After updating cost objects as soon as possible after their
origination, periodic decision supporting reports need to be generated for

internal as well as external users at different levels of management.

140

Qecisigg Making Prgcess
The following flow chart (Figure 5.5) presents the general process of the cost
control system in a generic manner. Changes will need to be made according to

specific project requirements.

 

After completing design phase, identify bid packs
(contracts) and estimate prebid cost per bid pack.

I

Prepare project budget per bid pack
including project contingency.

I

Decide the level of cost control: bid
pack or cost codes.

I

Identify the cost documents such as bid packs, field
orders, change proposals, change orders,
requisitions, and invoices to be monitored.

I I I
Identify data capturing Develop project cost

documents such as control file (database or
requisition forms. spreadsheet) with budget at

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

appropriate level of detail.

 

 

Communicate procedures
and rules of cost control
and monitoring to all the

concern parties.

I

 

 

 

 

l

141

Assign commitment cost to
each bid pack after award
of bids

 

 

 

 

 

Figure 5.5 Decision Making Process while Managing Cost Control System

 

 

A

I

Update cost data

I
I I

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Send request for proposal Accept requisitions & invoices
Accept & negotiate proposal Verify progress with percent
from contractor complete from time control system
Prepare change order and update Negotiate and issue checks to the
project cost at completion contractors. Update actual spend
on project

 

 

 

 

 

 

I I

Update actual, proposed changes and
changes to the project status

I

Develop reports showing budget, commitments and actual
cost of the project status at identified level of details.

 

 

 

 

 

 

 

 

Figure 5.5 Decision Making Process while Managing Cost Control System

(Continuied)

142

lnterfages

Scheduling System: The cost control system has an interface with system users
such as the contract expediters, the project managers, the project directors, and
the contractors. It also has an interface with the scheduling system with which it

exchanges data such as dates and completed percentages of activities.

Analyze Opportunities: Again considering the fact that this development is
intended for new system development, only technology~enabled opportunities are
identified. Some of these opportunities are described below.

0 Online data entry through client/server application architecture

This can help to keep data current and also allows for data to be updated in the
system soon after its origination. Project managers can access data from their
own workstations rather than requesting data from the system operator. All
project users need to be trained in how to update data. Also, a system manager
must be available and is responsible for managing system functioning, access,
and security on the multi-user client server system.

0 Remote log-in for contractors to send and receive data electronically

This can help to capture data faster from contractors. Contractors will need to
install the selected system on their information system. Contractors may need to
be convinced about the advantages and should be treated as part of the team.
Also, security issues need to be studied. Again, there are always going to be
some organizations that cannot participate in such technology sharing. In that

case, an alternative batch processing system has to be continued.

143

Online reporting on a project intranet or some other medium to improve owner

visibility.

Such a system can improve the owner's visibility and get the owner involved in

the management operation. It would also help other team members to access

data instantly from their work location for decision making. This will not only

reduce paperwork considerably but also leads to development and management

of a new component of the system.

Establish System Development Objective & Constraints: Based on the

discussed opportunities, the following system objectives are identified. These

system objectives will be used to evaluate the system performance.

The system should be able to load, update and manage all construction
management cost control data

All relevant costs should be in the system within 24 hours of receipt.

Reports should be updated according to the CM requirements. The system
should be able to develop custom reports anytime. Some other shared media
such as a project intranet should be explored to share project information with
management teams.

Data entry should be automated as much as possible.

The system should be able to update schedule data automatically after entry.

144

The following constraints were observed:

. Schedule: System development should be completed in six weeks.
. Budget: Cost should not exceed $25,000.

0 Technology: All workstations should be IBM compatible.

. Policy: Use P3 for the scheduling system.

Modify Project Scope and Plan: The project scope and plan need not be
changed considering the fact that all findings in this phase have not changed the
scope considerably. The only thing added to the scope is the possible
development of a shared medium such as a project intranet to share project

reports with the owner and other project teams members.

Present Findings and recommendations: A Joint Application Development
(JAD) session may be organized to ensure that all issues have been identified
and resolved. JAD sessions should be attended by the entire construction project
team. Team members will subsequently be informed about the identified facts,
possible change in the scope and a new project plan for the remaining system

project.

5.4.3 Definition Phase
After finishing the study phase, a definition phase is used mainly to define,

document, and validate user requirements.

145

Outline Construction Management Cost Control (CMCC) Requirements: The
first activity in the definition phase is to make a list containing the construction
management cost control requirements. This list is developed from the system
objectives and it is used to develop process models.

1. All cost documents should be captured in the system as soon as possible.

1.1 Online data entry from the project office.

1.2 Remote data entry by contractors.

2. Distribute cost data in the required format for analysis.

2.1 Identify cost codes

2.2 Distribute data to appropriate cost codes.

3. Prepare custom, online and possibly paper-less reports.

3.1 Customize reports

3.2 Periodic updating

3.3 Information shared on the sharing device

4. Periodic automatic updating of schedule data

Model CMCC system requirements: The system analyst needs to use fact
finding techniques such as interviewing to identify and model user requirements
for the cost control system. These models are drawn in a strictly logical manner
in order to look for more technical solutions in later phases. These models
represent the required system data, process, interface and geographical
requirements of the system users. These models are developed based on the

models developed in the study phase.

146

Process Models: Process models represent the workflow through the cost
control system. Process models are often represented using data flow diagrams.
This model includes the processes, data flows, data stores and external entities,
which generate or receive data. Appendix A shows the modeling legends used
for data flow diagrams and their application. Figure 5.6 represents the context
level data flow diagram (DFD). This diagram defines the cost control system
domain, system boundaries, and its interaction with other entities. Table 5.4
describes the processes, external agents, and data flow represented by the
context level DFD (Figure 5.6). Figure 5.7 defines the process decomposition
diagram for the system. This diagram is represents the decomposition of the cost
control process shown in context level diagram (Figure 5.6). Cost control system
is decomposed primarily into three processes:

1. Load initial data

2. Update and distribute data

3. Prepare reports

Figure 5.8 is a first level DFD which represents these three processes. Each of
these three processes are further decomposed as shown in decomposition
diagram to get more processes. Figure 5.8.1, figure 5.8.2, and 5.8.3 represent
the detailed DFD for those three processes respectively. The second process,
update and distribute data, are further decomposed into three processes. Their
DFDs are represented by Figure 5.8.2.1, Figure 5.8.2.2, and Figure 5.8.2.3.

Data Model: Data models represent the data stores identified in the process

models and the relationships between these data stores. Data models are

147

represented by the entity relationship diagram (E-R Diagram). Appendix B shows
the legends used in drawing E-R diagrams. Figure 5.9 represents the data model
of a cost control system. It should be observed that entities such as "schedule"
and "estimates" are external entities and could be linked through interfaces.
Entities such as "cost worksheet" and "trends" do not have relational link with
other entities. Table 5.5 describes all entities represented in the E-R diagram.
This table also illustrates all main attributes of these entities with examples.
Interface Model: Interface models depict the net input to the system, their
sources, net output from the system, their destinations, and shared databases.
Fig. 5.5 which shows a context level diagram also represents the interface of the
cost control system with external people and systems.

Distribution Model: Distribution models help to represent the communication
system for distributing the data, processes, and interfaces to the various
geographical locations. Fig. 5.10 represents the distribution model of the cost

control system.

148

Amal-of-
Changes
/Proposals

A/pproval-
Decisionreads
PM/ information

Contract-

Information

—Contact
Information

Cost-

 
  

 

 

Codes
Internal-decision
making-reports

Proposed-Changes

 

 

Project Schedule

 

 

Cost Estimate

 

/

Project-
Budget

 

Request-For
W ; Contractor

 

 

 

 

 

 

 

Negotiations /
Proposals-for-
Changes
Requisition-Invoices
9::i 1.0081-,
Reqmremen' ts
External-
NW- 0053- CM
M”; II; control-
Owner- \ ' W
Recommendations- I
and-General- \
D“ Owner

 

 

 

Figure 5.6 Context Level Data Flow Diagram for Cost Control System

149

 

Cost Control System

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

V l
U ate & Distribute
Load Inital Data 1):: 1’!ch reports
r j j I
Preposals Invoices
and Change and Trends
Orders Reqisitions
Develop Load Distribute Prepare Prepare
Project File Congas Contract and External Internal
Purchase Order Reports Reports

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Load Cost Load Contracts/
Accounts Purchase Orders

 

 

 

 

 

Figure. 5.7 Process Decomposition Diagram for Cost Control System

150

 

“Cost-Codes Owner

\ \ Owner- /
Schedule-Data '

- . mmendations-and-General-Data

 

 

 

  

 

  
    

General-Pro t- '
Data 1°C ’ Preject

 

Project-Budge

 

   
 

  
  
   
   

 

 

 

 

  
     
 

  

 

  
  
 

 

Database
Load Initial Data f
Contract-Information Updated-
/ Distributed-

Contact- Data

Information General-

Project- \
/ Data Proposals
\ General-
Trends-information Project-Data
Proposals-for-Chang Update and
Contractor uisition-Invoices D'SMb‘m Data gpdated-
818
Negotiations
A
\ Percent-
Request-For-Proposal Complete-
of-line-
items 3
Approval-Decision /
New-reports- Report Generation

/‘°“"°“

Owner External-cost-control- Internal-
F—reports decision-

making-

reports

 

 

 

 

 

PM

 

 

 

Figure. 5.8 Cost Control System Domain: DFD

151

General-Project-I
Data
General-Project
Inforamtion

 

 

Project

f \

Project-Infor. Contact

‘ 2 f
___Contact- ' Contact-Info.
Information W

Contact Participant-Info.

 

 

 

    
 
 

 

\Contract-

Information

 

\Project-Budget

 

 

 

 

 

 

Schedule Data

 

 

Schedule ... -—

 

Figure. 5.8.1 Cost Control System-" Loading Initial Data”

152

   
  
 
 
  

Negotiations

 

'——Proposals-fm-Chmg «-

 

 

 

 

 

 

 

 

Contractor
/ k—Request-for-proposal—
Requisition-
Invoices Framed-Changes Distributed-
/ ‘/ Changes
Cost Worksheet
Estimated-
Process Invoice Cost- Proposals
and Requisition Change CM-
2. 3 Approval
Process Trends
Complete- CM-Approval
of-line-
items
Trends-
information
Schedule \
CM

 

 

 

 

Figure. 5.8.2 Cost Control System-" Update and Distribute"

153

  

—Negotiations

 

 

 

  

 

Pmposals-for-Chang -<
‘——Reqnest-for-proposaI——

Contractor

 

 

/
Requisition-
Invoices

 

  
  

Proposed-Chanss Distributed-

 

 

 

 

 

 

 

 

4/ Changes
Cost Worksheet
Estimated-
Process Invoice Cost- Proposals
and Requisition Change CM-
2 . 3 Approval
Process Trends
Percent-
Complete- CM-Approval
of-Iine-
items
Trends-
information
Schedule \
CM
Figure. 5.8.2 Cost Control System-" Update and Distribute"

153

 

 

Invoice PM

 

 

 

 

2.1 . 1
Processed-‘7 /
Prepare Invoice voice T \
Approved-
Invoice

 

/ \ ......

Invoices Contract- Approved
Info.

    

Distribute

 
 

 

Contract Purchase
Order

I “am“ Actual-Cost
I . Cost Worksheet

 

 

 

 

Schedule File

 

 

Percent-
Complete-
of-line-
items

 

  
 
  

Contract-Info

   

2.1.5

Approve
Requisition

    
 
 

   

 

 

 

 

 

 

 

 

Processed-
Requisition Requisition
Requisition ‘___Approved-
Requisition
Decision
CM
Figure. 5.8.2.1 Cost Control System-" Process Invoice and Requisition"

154

 

 

 

 

  
    
 

  

2 . 2 . 6
Distribute
Proposal

  

 

 

 

 

 

 

 

       

 
 
 
 

Approve 3
Change Ord

Distributed-
Changes

 
 
  
  
  
   
   

 
 

 

 

 

Change-Order- 0: l 8f.

”0905" Change Order ‘_Pro a1
Approved- + pos
“”80““ \Distributed-

Changes
2 . 2 . ‘I
Distribute

Change Or

  

Figure. 5.8.2.2 Cost Control System-" Proposals 8 Change Orders”

155

 

 

 

 

PM Trends File Cost Worksheet

 

 

 

 

\ 7 I... .....Z'...

Trends- Trends
information Trend . Cost-

2.3.1

Prepare
Trends

 

Figure. 5.8.2.3 Cost Control System-" Process Trends"

 

 

 

 

 

  
    

 

. CM F irm
Project Database
\ -
decrsron-making-reports
Updated-
Data
Owner

 

 

 

Decision Reports

Figure. 5.8.3 Cost Control System-" Prepare Reports"

156

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

------------‘

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

i am: a
: Entities :
Reqursrtions Contract I Schedule I
N N I . :
l l '3 ................... 4'
l N
Invoice <> , Contract! Change Order 1
Purchase Order
N I
I N
Cost E
Worksheet I N 1
Trends 5 Proposals Project File
Figure.5.9 Data Model of Cost Control System
Cost Control System
Geography
Project Office Remote Locations
Architect!
Connectors (N) En - (N)
Project Contract Project

Manager (4) Expediter Director

 

 

 

 

 

 

 

 

Figure.5.10 Network Decomposition Diagram

157

Table 5.4 Data Flows, Events and External Agents in ERDs

 

Dataflow

Explanation

 

Project budget

Budget information is added from the
estimation system to corresponding
contracts

 

Proposals

Proposals are invited from contractors
in case of change in construction scope

 

Trends information

CM firm may document trends to note
possible changgs in cost of project.

 

Contact information

Information about all organizations
involved in the construction contract

 

Internal decision making reports

Reports generated for decision making)
by the CM firm

 

Owner recommendations

Owner recommendations about scope
and requirements of the cost control
system

 

External cost control reports

Reports sent to owner

 

Proposal for changes

Contractors’ reply to the proposals sent
by the CM firm

 

Approval decisions

Approval of proposal or change order ,
by the CM firm

 

Contract Information

Contract related financial and general
information

 

Cost codes

Codes at which cost is monitored. Cost
is distributed into these codes from all
other cost entities such as contracts,
invoices, requisitions, change orders,
proposals

 

Schedule data

Data transferred from scheduling
system such as start dates, finish
dates, and percent complete of the
activity.

 

New report request

Owners may ask for new reports

 

Requisition invoices

Contractors sent requisitions and
invoices periodically to the CM firm for
their approval

 

 

Request for proposal

 

Proposals sent to contractor for review
and reply

 

158

 

Table 5.4 Data Flows, Events and External Agents in ERDs (Continued)

 

Processes

Explanation

 

Load initial data

This process includes processes such
as initiation of project, loading general
project data, loading organizations
involved in contract and contract
information, loading cost accounts and
scheduling information.

 

Update and distribute data

This process consists of 3 sub
processes:

A. Process invoices and requisitions:
This includes accepting invoice and
requisition from contractor, approving
invoice and requisitions and distributing
them to appropriate cost accounts.

B. Process proposals and change
orders: This includes sending
proposals to contractors, receiving
contractor responses, negotiating and
approving proposals, initiating fresh
change orders or from approved
proposals, approve change orders and
distribute proposals and change orders
to the cost work sheet.

C. Process trends: Prepare trends and
distribute trends to appropriate cost
accounts.

 

 

Generate reports

 

This process includes processes such
as generation of internal reports for
decision making and external reports
for owner or other external agency.

 

 

External Agents

Explanation

 

 

 

 

 

Contractors Number of organizations contracted by
the owner for various kinds of work

Owner Owner of the facility for which
construction is performed

PM Project Managers who manage and
use cost control system

CM Construction Management organization

 

in change of managing construction
aspects of the project.

 

159

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Table 5.5 Entities in E-R Diagram
Entities Attributes Example
Contract! Contract # A0001
Purchase
order
Contract To Sitework Contractor
Contract From Owner
Amount $ 30,000
Description Sitework related to building and utilities.
Start Date 15 January, 1999
Finish Date 15 March 1998
Project Name BLDG
Title Buildinflroject
Location East Lansing, MI 48823
Description Construction of two story research
laboratory
Start Date 1 January 1999
Finish Date 1 June 2001
Owner Michigan State University
CM Construction management Consultants
Schedule Activity ID 10100001
Data
Description Clear topsoil
Start Date 1 February, 1998
Finish Date 4 February 1998
Percent complete 50
Contact Contact ID S‘IWK
Company Name Sitework Contractors
Address 1, Spartan Spirit, East Lansing, MI 48823
Tax ID 10558-6532
Invoice Invoice # 001
Contract # A0002
Date 1 February 1998
Title Purchase of dewatering pump
Amount $4,000
Check # 2345167
Amount paid $4000

 

 

 

160

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Table 5.5 Entities in E-R Diagram (Continued)
Requisitions Application # 0001
Contract 0001
Date 30 Jan 1998
Description of work Clearingsite
Schedule of values $3000
Previous application 0
Work done this $2500
penod
Material stored on $0
site
°/o work done 83.33%
Retainagg 10%
Proposals Proposal # 001
Contract # 0001
Date 1 Feb 1998
Description Dewaterinflf foundation
Proposed amount $5000
Negotiated amount $4500
Change Change Order # 0001
Order
Contract # 0001
Date 15 Feb 1998
Description Dewatering of foundation
Amount $4500
Trend Trend # 001
Description Possible increase in gas price
Amount $20000
Cost Cost Account 010101
Worksheet
Description Building related sitework
Original Budget $50000
Approved Revised $5000
Budget
Pending Revisions $2000
in Btgqet
Estimated Revisions $0

 

in budget

 

 

161

 

Table 5.5 Entities in ER Diagram (Continued)

 

Original $45000
Commitments

 

Approved Revised $4500
Commitments

 

Pending Revisions $0
in Commitments

 

Estimated Revisions $0
in Commitments

 

Actuals Received $0

 

 

 

 

Actuals Issues $3000

 

Build discovery prototypes: Construction managers have a very good idea
about the information needed. Unfortunately, some may not know all of the
information that is possible to be obtained through a construction management
cost control system. Therefore, discovery prototypes using prototyping tools such
as MS ACCESS may be used to verify and update user requirements.
Prototyping is a good approach for identification of unique user interface

requirements.

Prioritize CMCC requirements: Based on the construction management cost

control requirements identified in previous activities, the following priorities are

developed. These priorities may be used if the project lags behind the target.

0 The first priority is for a functional cost control system which can manage cost
related documents like contracts, purchase orders, change proposals, change
orders, invoices, and requisitions. This system should distribute data in the

required cost account format and develop predefined reports.

162

 

o The second priority is that the system should try to handle material delivery
documents and the documents showing probable trends in project cost. The
system should have multiple access, which can facilitate online data entry.
The system should also have links with scheduling system

c The third priority is to get remote access to the system so that contractors and
suppliers can access the system. Reports should be generated and posted
online so that all the project participants including the owner can access the

reports.

Modify Project Plan and Scope: The system analyst should negotiate scope,

schedule and budget after understanding the detailed scope of the project.

5.4.4 CMCC system configuration phase
In the configuration phase, different technical alternatives are explored to achieve

system requirements.

Define candidate solutions:

Table 5.6 shows the three possible solutions for a cost control system. The rows
represent different features whereas the columns represent three candidate
solutions. These solutions are organized side-by-side to compare different

features so that these can be used to identify a target solution.

163

 

 

 

 

 

 

 

 

 

 

 

Table 5.6 Candidate Solutions for Cost Control System.
Characteristics Candidate 1 Candidate 2 Candidate 3
Stand-alone Networked Networked
Commercial Commercial Custom Made
Packgge Package System
Computerized Commercially Commercially Customized
System available solution available solution client-server
would be purchased would be system will be
and customized to purchased and developed
project customized to using
requirements. project application
Would work only on requirements. development
one workstation Would work on tool such as
client-server MS Access
environment
Benefits Can be Same as 1 & client- Customized
implemented quickly server computing solution
because it's a gives online access according to
purchased solution to system data. project
requirements.
Server 8 High-end : Current High-end : Current Same as 2
Workstation technology. technology. 59:
Eg. Pentium II, MS
Pentium II Windows NT class
workstation with server and Pentium
windows 95 Il, MS \Nindows NT
installation workstation
Software Tools MS Access to Same as 1 MS Visual
provide Basic with MS
customization of Access for
package to provide developing
report writing and client-server
intelation. application.
Application Package Solution Package Solution Custom
Software Solution
Method of Data- Batch processing on Client-server Client-server
Processing stand-alone
workstation
Output Devices A laser printer Networked Laser Networked
and Implications printers Laser printers
Input Devices Keyboard & Mouse Same as 1 Same as 1
and Implications
Storage Devices Hard disk required Server storage Server storage

 

memory and zip
dnves

 

 

 

164

 

Analyze Feasibility of Alternative Solutions:

Based on the solutions identified, a cost-benefit feasibility analysis is conducted
and a feasibility matrix is developed to compare three solutions identified in
previous step. Table 5.7 shows the feasibility matrix. Rows in this table
represents the four feasibility criteria where as the columns represents the

candidate solutions.

Recommend a system solution

On the basis of the feasibility matrix, solution 1 does not satisfy many system
development objectives even though it's the most inexpensive and fastest to
implement. it may be noted that those who try to develop systems without going
through system development methodology tend to go for quick and dirty
solutions. Such a stand-alone system cannot satisfy the system objectives for a
large commercial construction project. Therefore, the system analyst has to look
for a networked solution.

The basic difference between solutions 2 and 3 is that one solution
promotes custom system development while the other is based on a ready
commercially available solution.

Technical feasibility: Normally in the construction industry it is difficult to find
people with skills who can build customized applications on system development
platforms like MS Access. Also, it is very difficult to find experienced users who

can manage and develop custom reports in these environments.

165

Table 5.7 Matrix of Feasibility Study

 

 

 

 

 

 

 

 

 

 

Feasibility Candidate 1 Candidate 2 Candidate 3
Criteria
Operational This will result in a Fully support user System developed
Feasibility greater delay in required according to the
system status and functionality by unique project
actual status. All customization requirements.
the users will not efforts.
get access to data
Technical Need to hire and Need to hire and Need to have very
Feasibility train system train system high system
operator with operator with a development skills
ready ready in developing
commercially commercially environment.
available solution. available solution. Users need to
Plus need Plus need have some
expertise to expertise to amount of skills in
customize customize that environment.
commercially commercially
available product. available product.
Economical Least expensive Moderately Most expensive
Feasibility expensive
Schedule Least time Moderate time Maximum time
Feasibility
Most Feasible Small project with Medium to large Large size
Environment single project size project with projects with
manager typical system unique system
requirements requirements

 

This may also lead to having a very high level of involvement of the system
analyst during the support phase, which may result in high system maintenance
cost.

Operatlonal Feasibility: In case of projects with unique requirements, it may be
difficult to customize the commercially available solution. But for most of the
typical construction projects, commercially available solutions can be customized

to satisfy all operational requirements.

166

 

Economical Feasibility: It is generally less expensive to buy a ready solution
compared to building it from scratch. The cost of building a new custom solution
includes the cost of the development platform, system analyst's time, training and
user's training on the development platform. These systems cannot be used in
other projects as they are made according to the requirements of the specific
project. The ready commercially available solution is comparatively inexpensive
and takes time only to customize according to the requirements. The expertise
developed in one project can also be used in other projects. The same product
can be used for future projects. Also a fair number of people may already have
knowledge about the software package which would help in the recruiting
purposes.
Schedule Feasibility: Ready packages take very little time compared to custom-
made systems. Therefore, considering all these factors, commercially available
ready software packages which can satisfy all operational requirements are a
better alternative for a construction project environment, unless the project
requirements are unique.

After identifying the system solution, a formal presentation should be
made to the project director and the user team about the details of the target
solution. A written system proposal should include all the outputs in the

configuration phase with details of the recommended solution.

167

5.4.5 Procurement Phase

Research Technical Criteria 8 Option:

In this activity, different options are identified on the basis of the recommended

system architecture. In the CM contract delivery system, the owner reimburses

all expenses for the system development. Therefore, some constraints may exist

about the vendor from whom all the software and hardware can be purchased.

The system architecture can be divided in terms of hardware and software.

Hardware: The hardware part of system architecture includes a server,

workstation and networking. The workstation and server hardware should be

selected to support data requirements. A tradeoff between features offered by

the hardware and money spent for that should also be studied while selecting the

hardware configuration.

Networking: After identifying the networking requirements and designing the

network configuration, a networking consultant can be employed to do the

required wiring.

Software: The system analyst needs to identify the technical criteria for selecting

the commercially available cost control system.

The following list illustrates the technical requirements for the cost control

software:

0 Should be able to mange all contract documents.

0 Should be able to develop cost codes and distribute costs to these cost
codes.

0 Should have a customizable environment.

168

0 Extensive reporting features including a custom report writer.
0 Should work in a client-server environment.
0 Should have good security features.
0 Possible integration with Primavera scheduling software.
Based on these criteria and an industry survey on the cost control system,
two software packages are identified as possible solutions. Possible vendors are

also short-listed.

Solicit proposals from vendors:

After identifying the product options, technical criteria and possible vendors,
proposals are invited from the short-listed vendors. For the hardware part,
quotations are invited based on the required specifications. For the software part,
a list of technical criteria is provided to the vendors and they are asked to supply

their proposals satisfying these criteria.

Validate vendor claims and performance:

Considering the limited time available for developing information systems in a
construction project environment, it may be very difficult to go through the
proposal validation process. Consequently, the cost control software is often
selected based on past experience both within the firm and from interviews with
other users. If no experience is available about a product, then it is generally

better to go for a well-tested product than an experimental one. Vendor

169

proposals, demonstration packages, manuals, and consultation with other users

can be used to solicit vendor claims.

Evaluate and rank vendor proposals: After validating the vendor proposals, all
proposals will be ranked on factors such as the features provided, costs of the
products, licenses for multiple copies, technical support, and training. A cost
control system such as EXPEDITION developed by Primavera Systems Inc. may
be recommended based on the features provided by the software. The project

director makes the final decision after recommendations.

Award contract: A contract will be awarded on the basis of ranked product
proposals. Negotiations with vendors would include issues such as technical

support, training and site licenses, which can be used for other projects.

Establish Integration Requirements: This activity includes development of
requirements for integration between EXPEDITION, a contract control software
and Primavera project planner (P3), which is a scheduling system.

0 Data transferred from P3 to EXPEDITION: Various cost documents such as
contracts, purchase orders, change orders, proposals share start and finish
dates with the scheduling activities. The line items in the requisition collects
the percentage work done from the corresponding activity in the scheduling

system.

170

0 Data transferred from EXPEDITION to P3: P3 accepts cost related data such
as budgeted cost and actual money paid to the contractor from the requisition
line items.

For using EXPEDITION and P3, one needs to make some early decisions.

One of the decisions is to have identical cost accounts so that data can be

transferred and compared against similar codes.

5.4.6 Design and Integration Phase:
The design phase is mainly focused on customization of commercially available

solution to the project requirements.

Design networks: The network is designed based on the network connectivity
diagram, selected system architecture and geographic requirements of the
system users. Network design includes network topography and network

component design.

Analyze 8 distribute data: Considering the two tier client-server architecture, all
data will be stored on the server and can be accessed from connected

workstations.

Analyze and distribute processes: After identifying the network layout, system

processes need to be distributed to fulfill network requirements. Figure 5.11

shows the network topography and the corresponding distribution of data and

171

processes. Rounded rectangles in figure 5.11 represent the central project job
site server and workstations of system users. The PRIMAVERA AND

EXPEDITION systems are stored on project server.

Analyze Software Data-structure: Due to the application of a ready package no
database design is required. Nonetheless, the system analysts need to
understand the underlying data structure and identify whether or not the data
elements satisfy the entire systems requirement. If some data requirements are
not satisfied by the commercially available solution, then custom data items
should be designed. These custom data items can be added to the existing data
structure and can be used during report generation. The underlying data
structure can also be used for custom report generation using report-writing

tools.

172

 

 

EXPEDITION Cost
Control Database

 

 

f

P I

 

Project Office

 

 

I

 

 

 

PRIMAVERA Schedule
Database

 

NT Server
Pentium II

 

_10 MB/Sec_

TCPIP

 

L—_/

 

 

 

 

 

 

f—_——\
hProject—
U atin ’ Managers NT
—Cu':tom§—N Client
Reporting Pentium 11
K____/
—Project—
RCVIBW Control
_R¢P°“5_' Mngr. NT
Client
Pentium 11
”Contract
Loading -
_ - Expediter NT
”a“, Rem” Client
Pentium 11
K_______/
_Project_’
Approving, Director NT
_Summary Client
Reports Pentium II

 

 

 

Figure 5.11 Data and Process Distributed Network Diagram

173

Design Computer Input 8 Output:

Computer Inputs: Design of the computer inputs consists of two components.
The first is the data capturing mechanism. Considering the client-server
architecture, the data capture mechanism is on-line data entry. This method
encourages entering the data in the system as Soon as it is generated.
Therefore, all system users are expected to enter relevant data in the system as
soon as possible. Another part of data entry is the source document, which is
used to capture data from its source. This is normally a form in which data is
stored and then processed into the system. The system analyst needs to design
forms to collect information about cost related data items such as change orders,
change proposals, requisitions and invoices. It is generally better to design forms
which are in the same format as the screen layout. Therefore, the source
documents designed should be identical to the data screen display forms of the
EXPEDITION software.

Computer Outputs: The first step is to identify the system outputs. The system
outputs of the cost control system are the reports developed from the system.
These reports are of two types. One is an internal report and the other is
external. lntemal reports are meant for the project director and the project
managers as decision support tools. External reports are meant for the project
owners or other external organizations such as financial institutes. Reports can
be of a tabular or a graphic nature. Graphic reports are developed especially for

higher management. The following list illustrates possible reports.

174

A Detailed reports: The cost control system needs to develop detailed
reports of various cost items. Examples of detailed report are details about a
particular contract, invoices, purchase orders, change orders, and proposals
related to that contract. Such reports can help the project manager get an overall
understanding of the status of that contract.

B. Summary reports: The most important summary report for the cost
control system is the report explaining the budget, amount committed, and the
actual money spend for each cost account. The project director can use this
report to analyze performance of the whole project.

C. Exception reports: These reports can be generated only for those
contracts which show considerable variances. This helps upper management to
concentrate only on contracts which need special attention. This report can be
developed on the basis of variances.

D. "Ad Hoc" reports: These are generated based on the situational
requirements and therefore, they cannot be planned beforehand. But report
designers need to identify the way of generating these reports using a report
writer or opening a database in a reporting environment such as MS ACCESS.

External reports include the reports sent to the owner, and to external
agencies such as banks. These reports are predefined by the CM firm and the
external agency, and generated periodically according to the predefined format.

After identifying the contents of the reports, the system analyst needs to
identify the medium and format of these reports. Reports printed on paper are

considered a standard format for preparing reports. Reports can also be

175

published on the intranet. This can reduce paperwork, give instant access to all
the project participants including owner access to the project information and this
will represent the status of the project close to reality. But intranet development
and management involves cost, and firms need to have expertise for developing
an intranet. Also after developing a project intranet, someone needs to manage it
and update the reports. Therefore, this activity gets least priority and project
intranets are developed after the whole cost control system is developed.

To identify report format, some prototype reports may be developed using
prototyping tools like MS EXCEL. After identifying the reporting format, the
system analyst needs to check if EXPEDITION can develop reports in that format
with those contents. If not, customized reports need to be developed to satisfy
the reporting requirements. Designing reports is an iterative process where more

reports are developed and original designs are changed.

Present 8 Review Design: Present deliverables from the design phase and

develop a schedule for the next project activities.

5.4.7 Construction phase
After designing the system, the next step is to construct different components of

the system.

Build and test network (Hardware): The first activity is to develop the network.

Network development depends on whether the owner is providing cabling and a

176

server facility. In case of an absence of any networking facility, the system
analyst needs to start this activity with delivery and installation of a server and
workstations. The network operating system is installed on the server and client
machines and the cabling is done. Then the network is configured and tested for

connectivity, access and security.

Install, customize and test new software package: After developing the
network, commercially available software is installed on the client and server
ends. The software is tested for network connectivity, data sharing and data
access. Software is configured for multiple access. Custom reports are
developed in EXPEDITION. For more complex reports, the report writing tool
provided with EXPEDITION software "Crystal Report Writer" is used to construct

custom reports.

5. 4.8 Delivery Phase
Conduct system test: After installation, customizing and testing individual
pieces, the whole system is tested using test data. It is preferable to have test

data from the same project or a similar project.

Prepare conversion plan: The conversion plan is critical for the successful
completion of the development process. The conversion plan identifies the way
of populating the application with data, end-user training, documentation and the

actual start of application usage. The project team is also given an opportunity to

177

test the system and to accept or reject a system before actually starting to use it

in the project.

Install database: The application software is populated with the project data.
This data includes contact, contract, and purchase order information. The
budgeted and committed costs are distributed to the cost codes. Also, other
kinds of data such as general project information, all organizations involved in the

project, and schedule related information are loaded.

Train system users and prepare documents: Training and documentation are
essential for a successful implementation. Training can be offered in-house to all
project team members. Some system users, such as the contract expediter who
manages and maintains the system, may get training from the software
manufacturer because these people become responsible for day-to-day problem
solving. The system analysts should train all other users in the group. The
documentation often contains user references provided by the system
manufacturer. Unfortunately, these reference books are not written from the
user's perspective and normally users don't want to search these manuals.
Therefore, a working document should be prepared which can guide users in a
stepoby-step fashion for performing their task. Separate documentation should be
prepared for project managers and the contract expediter according to their

interaction with the system.

178

 

Convert to new system: After completing the training, system users are asked
to use the system, and start updating and reporting cost related data. System
analysts should meet with all users, more frequently initially, to discuss issues
related to the application of the system, and the system development process.
This feedback can help clear up any confusion over the use of the new system,

and also help the system analyst in developing future systems.

5.4.9 System Support

After finishing the development process, the system analyst generally presents
all documentation developed during the system development process to the
project owner and gets the system approved from the project owner. The system
analyst should provide support for solving all future problems. The system
analyst may now start the second phase of the system development project,
consisting of lower priority features such as providing remote access to the
project team members and development of the project intranet. If new system
requirements are observed in the future, then a request needs to be made and

the system analyst should follow all phases and activities of CMSDM.

5.5 Summary

This chapter demonstrated the application of CMSDM in a project environment
managed by a construction management contract administration system for
development of a cost control system. The cost control system is developed

using CMSDM making appropriate changes according to the project and system

179

 

variables. This cost system is only in a model format and can be implemented
physically if required. The purpose of this chapter was to demonstrate the
application of CMSDM and understand the phases and activities involved in
system development.

The next chapter consists of two case studies where a system
development process used in industry for developing a cost control system is

tested, evaluated and compared with CMSDM.

180

CHAPTER 6

CASE STUDY

6.1 Introduction
This chapter applies and evaluates the CMSDM in two actual construction project
management information systems. Two construction projects managed by CM
contract delivery systems were selected and the cost control systems used in
those projects were analyzed. The system development methodology applied by
the construction organizations was also examined. This methodology was
understood through interviews with the developers, users and system owners of
the organizations. After identifying the systems development process and the
existing cost control system, the process and product were evaluated based on
the CMSDM and the developed cost control system. Industry professionals were
requested to evaluate the CMSDM and its possible applications in real project
environments.

This chapter is divided into two sections, one for each case study. Each
case study includes an introduction, the system development process, the cost
control system, features of system development and possible application of

CMSDM.

6.2 Case I: Program Management Project
Case I is a project financial tracking system for a project being coordinated by a

program manager. This system is called Bid Pack Financial Tracking Log

181

(BPFTL). This project consists of deferred maintenance work for a school district.
The school district has about 40 schools, which are on an average 100 years old.
Therefore, the school district floated a bond program for financing the deferred
maintenance of the schools. The bond program was for $ 135 million, and it was
successfully funded through different investment agencies. The school district
developed an estimate of all required deferred maintenance work for all of the
schools through a consulting firm. The school district then employed a CM firm to
manage the bond management program. The CM firm is acting as a program
manager and its duties include managing finance, design, document preparation,
bidding and the construction process. The CM firm reports to the facilities
department of the school district.

After identifying the total estimates of required deferred maintenance
work, all work was prioritized and the CM firm decided which maintenance work
should be included in the bond management program. After identifying the scope
of the work under the bond management program, about 90 bid packs were
developed for managing construction. All of the bid packs were divided among
the project managers who managed their corresponding bid packages
independently. Each project manager manages around 10 to 15 bid packs
consisting of about 10 schools. The scope of the work varies from replacing
windows to adding classrooms. Each project manager was initially managing
individual bid packs on a spreadsheet according to the project requirements. But
a need was observed to manage and store the progress of all bid packs in a

central database environment to monitor and control progress of the bond

182

management program. This need triggered the development of the BPFTL
system. The facilities department of the school district is the construction project
owner, the project director of the CM firm is acting as system owner and all

project managers of the CM firm are system users.

6.2.1 System Development Process

After identifying a need for a financial tracking system for the bond management
program, the system owner and the system users had brain-storming sessions to
identify the system requirements. System requirements were identified based on
reports required for decision-making. A system support request was filed with the
regional project support group. Figure 6.1 shows the system development
process. The following list includes the salient points of the system development
process employed by the system analyst.

o The system scope was not defined with respect to the budget and schedule.

0 No time was spent on understanding the generic cost control system.

0 User requirements were not represented by any modeling technique.

a Data input screens were designed without much user input.

0 Users were not provided enough training.

0 No system documentation was provided.

183

 

System requirements were
identified by the system users.

I

System request was placed with
regional office.

I

System analyst was assigned
for system development.

I

 

 

 

 

 

 

 

 

 

 

 

 

0 System analyst identified system requirements through
interview with system users.
0 Expected reports were used to identify system requirements

 

 

 

I

 

System requirements were identified as very unique and MS
ACCESS was selected as a development environment.

 

 

 

I

System analyst used prototyping system development process
for developing cost control system.

 

 

 

 

I

 

0 Input forms and reports were developed using prototyping
approach.
0 Corrections are made according to the user feedback.

 

 

 

I

0 Network server provided by owner was used to develop

project LAN.
0 User workstations were bought based on the user

requirements.

System was installed on the server and users started to use the
system after initial system tests.

 

 

 

 

 

 

 

Figure. 6.1 Case I: System Development Process

184

 

The absence of training did not have a significant effect initially because all users
at the time of system implementation were also involved in system development
and had a good idea about the system structure and processes. During the
course of the project, users were replaced and some new users were added to
the project team. Due to the lack of training, documentation and a user-friendly
system, new users had considerable difficulty in using the system. Also, some
users identified new requirements for the system, and initiated a system revision,
the system again went through a development process. Even though this new
revision did not contain a lot of changes in the basic data structure, it made it
difficult for system users to comprehend the system in totality and to make use of
the system for decision making due to continuous changes and the testing
process. An external system developer was used for the system modification.
The project owner found the local system developer to be better from the time,
cost and efficiency point of view. Some system users drew diagrams in the form
of flow charts to show processes and user navigation within the system to the
system developer. This resulted in a change in the system and it remained under
construction.

The following section describes the processes involved in the BPFT L by
using data flow diagram as explained in appendix A, and in the BPFT L data

structure by using an entity-relationship diagram as explained in appendix B.

185

6.2.2 System Data Model and Process Models

The processes involved in the BPFTL system can be described most efficiently

by using a data flow diagram. The data stores represented in this data flow

diagram are used to develop an entity relationship diagram which represents

relationships between these data stores.

A. Process Model:

This system involves five main processes.

Load program data: This includes loading initial project related information
such as list of schools, architects, contractors, project managers and different
project phases.

Load bid pack data: Prepare change orders: This includes loading information
about individual bidpacks.

Update proposal request: This includes receiving proposals from the
contractors and negotiating a price for the change in scope of work.

Prepare change orders: This includes preparation of change orders.

Prepare reports: This includes producing internal reports for decision making

and external reports according to owner requirements.

Figure 6.2 shows the data flow diagram for BPFTL system.

186

 

 

Financial-Info

 

 

 

   
  

I /’
I / Schools
Program \ /
Manager Program- SChOOl- School
I‘—I_} Data information/”E
. . Architect- Architects \ V

Details __ Architect

Contractor—)
Details

  
  
 

 

4‘Contract-g
Contractors momma» Load Bid Pack

Data
Project-/'

Project- Project Manager

 

 

 

 

 

 

 

 

 

I Niagotiated- Manager-details ’ Managers /

Rm Phase-\ Bid-

] I Informationfi— Phases Pack-

} I Phases ' M0

I . Change Orders

. l v

a f Proposal

I I Ch Request Logs Bid P3016
. ange-

l \ Order / fi

Pro sals Proposal-
Request

   
   

 

   
  

 

  

Prepare Change

Bid-Pack-
Orders

Info

 

 

 

 

 

\ PTO 81
\_ Reports T08
\, .
\ f Contractor Mm?“
Report- Generated- Proposal
request reports
5
Generate
Reports

 

 

Bid-Pack-Data

Figure. 6.2 Data Flow Diagram for BPFTL System.

187

B. Data Model:
The underlying data model of the BPFTL system is represented using an entity
relationship (E-R) diagram. Figure 6.3 shows the E-R diagram for the BPFTL

system.
School PR Log _l<>l_ Change
1 . Order

1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

l N I N 1
Architects __<> Bid Packs /\ Project
V Manager

 

 

 

 

 

 

 

 

N N
1 1
I N
Minority _O_ Contractors Phases
Status

Figure 6.3 Data model in BPFT L system.

 

 

 

 

 

 

 

 

 

 

 

 

 

188

C. Cost Control Reports
Table 6.1 shows the financial analysis screen for one of the bid backs. This

screen shows the cost control analysis done by the system for an individual bid

packs.

Table 6.1 BPFTL: Financial Analysis Report for Individual Bid Packs

 

 

 

 

W Tuekpolnalg
Project Manager: Cheryl Humenn Actual Armin

Architect: SmileyGIotterNyberg 7"“ 8M5” ‘ so
0 l I . McPherson-Tm Orto'deomactAmount + $13.59
Pine: 10 Approved Change Orders s $2.122
Curran Germination Amomt a $1§,w1
Pending Change Orders + fl
Original Budget Forecaster! Total Constr. Coat = $125.Q1
Orlghal NE Fees + 311,“
Construction Budget $15.81) NE Changes + 50
NE Fees + $13.21 Soft Costa To Dds + races
SeltCosta(errcl.AlEFees) + $3.61 satcg‘Eguocm + m
Orthontigeney + so Entitled Contigeney + $0
Total Project Budgd = 8161.812 Forecasted Tctl Project Cost ' 8140.067

 

189

6.2.3 Possible Changes in BPFT L due to the application of CMSDM

The previous two sections described the cost control system and the system

development process. This section analyzes the system development process

and the cost control system in order to evaluate the system development

success in this case study. This evaluation is classified in terms of two sections.

The first is about the system development process and the second is about the

cost control system.

System Development and Management Related Changes

Absence of Initial Budget and Schedule: The initial budget or schedule was
not developed for developing the BPFTL system. This lead to the absence of
monitoring and control over expenses and schedules during the system
development.

Absence of well-defined system scope: The system scope was not defined
in relation to schedule and budget. This lack of monitoring and control of
expenses and schedule with respect to the system scope may not be possible
in tight economical conditions. However, this generally leads to "creeping
scope" during and after the system development process.

Absence of study phase: The study phase improves the system developer's
understanding of the generic construction management information system,
and that helps in understanding the user requirements quickly and
comprehensively. Absence of a study phase led to more time in system

development.

190

No use of modeling techniques: Systems developed without modeling the
user requirements result in a more time consuming development process,
more confusion about the user requirements and about the developer‘s
understanding. It also results in a system without any contemporaneously
developed documentation. phase.

Prototyping used without modeling: This results in longer system
development time

No exhaustive market survey: No study was conducted to determine if
market available software could satisfy program management requirements.
Such a study could also help in identifying corporate lnfonnation system
architecture.

No comprehensive system test: This resulted in frequent system failures
and in a more time consuming system support phase.

Not enough training: System users were not trained before system
installation. System training should be better in quality, should be conducted
earlier and should be more in quantity especially for system users with less
computer experience and for system users who were not involved in system
development.

No user documentation: User documentation helps users in understanding
the system. It also helps for new project team members to get used to the
system quickly.

New changes without training: System users should be trained for new

system changes. This also includes training for new team members.

191

Solicit user requirements and problems during system support phase:
User requirements and problems should be solicited at the time of making
any changes during the system support phase.

Cost savings related to system development:

Considerable extra costs were caused by not following the structured

methodology. These extra costs can be divided into two parts.

A. Direct Costs

Time spent by a system analyst in development efforts.
Travel expenses including lodging and boarding of a system analyst.

Expenses incurred on a system analyst during the project control phase.

B. Indirect Costs

Time spent by project team with system analyst

Non availability of information

Time spent to get information by other means

Possible wrong decisions

Time spent in trying to solve problems with functioning of the system.

Prolonged system support phase

Cost Control Related Changes

Inaccurate Summarization: The summarized reports developed for the

entire program are artificially generated without considering the detailed

192

values in the bid packs. Therefore, these reports can be very misleading and
the system cannot represent the status of the program correctly.

No monitoring of actual expenditure: This system does not include any
provision to monitor actual expenditures on the program. This system does
not monitor requisitions submitted by contractors and, therefore, the program
management firm cannot check the status of the actual money spent on the
program at any time. This also leads to a time consuming process of project
managers having to individually use spreadsheets to monitor payments to the
contractors for individual bid packs.

Inconsistent data redundant activities: This lack of an interface leads to an
information system consisting of various subsystems which cannot share
information with each other and cannot show the different stages of project
progress. This weakness also leads to a time consuming repetitive updating

of two systems.

6.2.4 Evaluation of recommendations and CMSDM by industry

The following observations were made by the industry professionals from the

program management project.

The professionals accepted most of the recommendations related to system
development. They observed that all phases and activities involved in the
CMSDM would be followed only in large size projects with unique project
requirements. Professionals observed a need to have a well developed

corporate information system architecture.

193

6.3

Professionals agreed to the recommendation about user training,
documentation and development of a user friendly system for better user
involvement in the system.

The system owner accepted that about 25% of the information system
development cost could be avoided by following structured system
development methodology.

The system owner stressed the importance of the support phase while
developing an information system for the construction projects. It was
observed that all of the initial phases need to be done in a structured manner
to avoid a lengthy system support phase which can really take excessive time
of the project team. A need was also observed to train one of the users to
solve most of the unexpected system performance problems.

The issues related to the cost control aspect of the system were not fully
accepted by the professionals. They noted that the system was developed
according to the requirements, and that identification of the system

requirements is a very subjective process.

Case Il: Small Scale Construction Management Project

This is a small size construction project managed by a construction management

contract delivery system. This project was selected for the second case study

primarily to identify the broad spectrum of computer applications in the

construction project environment and the system development process employed

by this broad spectrum.

194

Project Facts: This construction project involved construction of an educational
classroom building with research facilities, and a construction cost of $9 million.
The CM firm was employed by the owner to manage the construction aspect of
the work. The CM firm developed initial estimates on the basis of historical data
and the owner‘s requirements, and on the basis of these estimates, a project
budget was formalized. On the basis of this budget, the owner obtained funding
for the project. After assurance of funding, an architectural firm was employed to
prepare the design documents. The CM firm was involved in some value
engineering activities. A detailed project budget was developed after producing
more detailed plans. The owner decided to procure this project in a "fast track"
method and hence the whole project was procured in three phases including a
total of 25 bid packs soon after the design specifications were acquired. After
completing the bidding process, the project commitment cost was identified and
this commitment cost was used in the cost control operation.

Organizational Structure: The organizational structure includes a project
director who looks after a number of small size projects, a project manager who
is the main and only decision making entity on the project and a project
superintendent, who controls all activities of the specialty contractors. The
company decides the project level organizational structure on the basis of the
size of the project and the owner requirements. All the day to day decisions are
made by the project manager who in turn reports periodically to the project

director.

195

Information System: The organization has a number of small to medium size
jobs and is trying to standardize the applications for particular types of functions.
They are experimenting with software products such as EXPEDITION and
ProLog MANAGER. Presently, no standardized application architecture exists in
the organization and the decision about selecting software tools for developing a
project level information system is left to the discretion of the project manager.
There is no governing decision making body in the organization which is
responsible for selecting and developing an information system. The project
managers normally use spreadsheets to manage most of the project control
operations. The selection of the system depends mainly on the seniority of the

project manager and the past experience of the project manager with IT tools.

6.3.1 Project System Development: After taking charge of this project, the
project manager identified the reporting requirements and then developed
spreadsheets to track and monitor costs related to the project. No other ready
software package was evaluated or no one else was involved in development of
this system. The project manager has one computer with a laser printer as
hardware tools. All system related activities such as system development, data
entry, and report generation are done by the project manager. The project
manager on this project uses spreadsheets extensively for cost control
operations. The progress control is done using ready market software, SureTrak,

by Primavera Systems.

196

6.3.2 Cost Control System

The following is a list of spreadsheets used for cost control operation.
Spreadsheet #1: The first spreadsheet monitors the project level cost such as
total budget, total commitments, CM costs, Architect/Engineer (NE) costs, and
cost to complete. This spreadsheet gives a summarized status of the project.
This spreadsheet is not linked to the other spreadsheets and data is manually
input into the spreadsheet based on the values in other spreadsheets.
Spreadsheet # 2: This includes a summary of cost data for individual bidpacks.
This has committed cost, cost after change orders, and the variance between
them. This variance column is used to identify the total change in the project cost
and individual bid packs.

Spreadsheet # 3: This spreadsheet monitors the proposals received from
contractors, negotiated amount from CM firm, decision taken by the owner and

NE, and the final change order amount.

197

6.3.3 Possible Changes in the cost control system

The following points are observed as possible changes in the system

development process if the same system would have been developed using

CMSDM.

System Development and Management Related Changes

For a project of this size, the decisions regarding appropriate selection of IT
tools are made by the project managers. Therefore, project managers should
be trained and educated with the available IT tools.

The responsibilities of construction management projects of this size are
more or less similar, and, therefore, organizations need to develop an
organizational application architecture. This architecture can include
appropriate IT tools for the particular types of projects and functions. It would
help project managers in making consistent, appropriate decisions, related to
selection of IT tools.

The spreadsheets are very time consuming to create as well as to update and
do not allow manipulation of data for decision making. Therefore, a ready
software application such as EXPEDITION by Primavera systems, Inc. should
be used on projects like this one which could facilitate better organized data

capture at one place.

198

Cost Control Related changes

A spreadsheet based system is not flexible enough for data manipulation and
reporting compared to a database system. Spreadsheet based systems also
take more time for reports generation compared to database systems.

This spreadsheet based cost control system does not monitor requisitions
and invoices. Therefore, this system cannot monitor the actual amount paid to
the contractors and the actual progress of the project without entry of that
data. This system also does not summarize change proposals, which are not

converted to change orders, in the summary report.

6.3.4 Evaluation of recommendations and CMSDM

The following observations were made about the recommendations by the

project manager.

It was observed that all phases and activities of the CMSDM cannot be
followed for a small project.

The project manager agreed to the recommendation about development of
corporate information architecture and educating project managers with the
available lT options to manage their projects in a most efficient way.
Observations about a cost control system were accepted in part. The project
manager agreed that a use of ready software would make the whole process

of cost control along with document management more efficient.

199

6.4 Summary
The case studies were aimed at evaluating application of CMSDM to real
construction projects. Two construction projects managed by a construction
management contract delivery systems were selected and their process of
development of a project level information system was identified. The ultimate
product of the system development process, the cost control system, was
analyzed and evaluated on the basis of project requirements and the process
used to develop that system.

A considerable amount of potential cost savings were observed by
application of CMSDM for developing information systems. A need for corporate
information technology architecture was observed in the case of small size

projects.

200

CHAPTER 7

SUMMARY, CONCLUSION AND FUTURE RESEARCH

7.1 Summary

This thesis was inspired by the researcher's observations about the use of
information systems in the construction project environment. The researcher
observed a great amount of research done in the area of information systems
development in the management information systems field. But this research
was not communicated or applied in the construction industry, which uses
information systems in different forms to manage multi-million dollar projects. An
efficient information system is one of the major factors involved in the successful
management of a construction project, unfortunately information systems are
developed in the construction environment in a very “ad hoc" manner. This
research was aimed at developing a system development methodology for a
construction project environment. The research objectives were to define a
structured system development methodology applicable to a construction project
environment and to demonstrate its application by developing a cost control
system for a domain construction project environment. This system development
methodology was also evaluated by applying it to two case studies involving
system development in a construction environment. The purpose of the case
studies was to evaluate practical application of the proposed system

development methodology to a cost control system.

201

This research was initiated with a literature review, which covered
different system development methodologies proposed by various researchers.
No system development methodology was found to be tailored for a construction
project environment. The literature review found discussions on different issues
related to computer applications and management of computer resources in
construction. It was observed that all of the research work in this area has been
done in a very fragmented manner without looking into the core issue of system
development.

The information system development environment in the construction
industry was described before defining the system development methodology.
Different subsystems that make up a construction management information
system were identified, and were classified on the basis of various parameters
such as managerial activities and the core functions of those subsystems. This
classification can be used to identify the combination of the subsystems required
in a particular project environment for a particular system owner. The different
people involved in system development such as the system owner, the system
users, the system designer and the system builder were identified from the
construction project perspective and their roles and activities were explained.
Different constituents of an information system such as data, process, interface
and geography were described from a construction project perspective.

After identifying the system development environment, reasons for system
development and instances of such development efforts in the construction

industry were identified. After identifying the reasons for information system

202

development, a structured system development methodology was defined and its
components were identified. This methodology consists of the processes of
system development, techniques used in those processes, and the CASE tools
used to facilitate a system development process. Different types of processes
and techniques were identified, and the process, technique and CASE tool most
applicable to the construction project environment were selected.

A Construction Management System Development Methodology
(CMSDM) was developed in the form of phases and activities. It was observed
that this methodology might not be applicable to all project environments and
that changes need to be made based on project and process variables. These
variations for each activity in different project environments were identified. After
defining the CMSDM, this methodology was applied to a hypothetical
construction project environment to develop a cost control system. In order to
understand the domain project environment, a Construction Management (CM)
contract delivery system was defined and services provided by CM firms were
identified. This demonstration included each system development activity and
the deliverables from those activities.

Two case studies were conducted to evaluate the application of CMSDM
in real construction project environments. The process of the system
development and the cost control system were observed on these projects and
the processes and products were evaluated on the basis of performance of the

system. Then the professionals on these construction projects reviewed the

203

CMSDM and their views about the application of CMSDM were noted in this

thesis.

7.2 Conclusions

On the basis of this research work including literature review, structured system
development methodology and the case studies, the following conclusions can
be derived. These are divided into the following three parts.

a System development methodology

0 Cost control system

0 Case Studies

7.2.1 System Development Methodology Related Conclusions

0 Every construction project has unique information system requirements.
Based on these unique requirements, an information system should be
developed as a combination of information subsystems such as document
management, cost control and time control.

0 In most cases, an information system is not developed in a structured
manner. An information system is developed according to the organizational
standards based on past experience rather than on the unique requirements of
the project. This results in an inefficient system which generally does not satisfy
all project requirements in an efficient manner. The CMSDM developed in this
thesis should be applied to all system development efforts with some changes
based on the project and system variables. It is more important to go through all

204

detailed phases and activities of CMSDM for a large size project, which has
more unique project requirements. This methodology also acts as a check list for
new project managers for designing information system. Project managers can
save considerable amounts of time during construction operations by spending
some more time on following a structured approach of system development
during the project mobilization period.

0 The structured system development methodology can not only help the
system analyst in developing an information systems for construction projects,
but also educate system owners and system users for better communication
related to system requirements with system developers.

0 Considering the general trend of using commercially available software
products in other industries, the construction industry should also start using
more of the commercially available software products. There are advantages in
using commercially available software packages. Most importantly it
standardizes the process of doing business in the industry. This would help
everybody by reducing the efforts required to coordinate procedures between
different organizations. But software packages, which use the best practices in
the industry, need to be evolved so that all can follow best practices. These off
the shelf packages are economical and take less time to configure to the unique
project requirements compared to developing a completely customized system.
Also, these packages can be used in multiple projects which can help
organizations in standardizing their application architecture. Recruiting also

becomes easier due to the availability of the required skill-set in the market.

205

0 System development methodology in a complex and unique construction
project environment should use an iterative system development process. The
methodology should use data oriented techniques due to the emphasis on
reports generated for decision making. CASE tools need not be used, as scope
of the system development is generally too small to justify usage.

0 One of the reasons behind this thesis was to develop a methodology most
applicable to the construction project environment. It was observed that most of
the generic methodologies also apply to the construction project environment.
Therefore, the main phases and activities do not change in CMSDM but their
orientation and application change based on the project and process variables.
The project variables are whether or not a system is developed for a new
construction project or a modification of the existing system. The process
variables are selections of particular applications, reporting application, and user
access to the system.

0 Most construction organizations are involved in the construction of small
size projects. These organizations need to develop an organizational information
technology architecture which can guide them in selecting appropriate IT tool

according to the project requirements.

7.2.2. Cost Control System Related Conclusions

0 Cost control from the owner's point of view is of two parts:

A. To monitor actual expenditures compared to the actual progress.

206

B. To monitor changes in the scope of the project compared to the budget and
contingencies of the project.

o It is essential to identify the level at which project costs are monitored and
controlled. This level is normally at the bid pack level or cost account level. In
the case of large contracts with a larger size of individual bid packs, cost codes
are used by further dividing bid packs for better monitoring of different project
components. Project progress should also be monitored at the same level as the
cost control system for a common level for monitoring cost and time.

a One of the factors which affects the design of a cost control system is the
contract delivery system used in a construction project. In the case of a CM
project with cost plus fee contracts with the contractors, the cost control system
designed for CM firms also needs to analyze resource consumption by the
contractors. In the case of CM projects with lump sum contracts with the
contractors, the cost control system need not consider consumption of resources
by contractors. In the case of design-build projects, cost control systems can be
designed during the design phase of construction project to allow a fast track
approach.

0 Design of a cost control system depends on the user requirements, which
again depend on the various factors such as project size, unique project
requirements and complexity. The SOphistication of a cost control system varies
from a customized online application designed for a client-server environment
with an ability to prepare customized reports to a spreadsheet developed

according to the project requirements. With all this sophistication of the system,

207

it has a price tag attached to it and the system developer needs to consider the
tradeoff between the features provided by the system and the costs associated
with it. The cost control system should not be evaluated based on its
sophistication but it should be evaluated on the basis of fitting the project
requirements. Management of a developed system should be considered before

making decisions about the cost control system.

7.2.3 Case Study Related Conclusion

0 Users of information systems in construction projects change during the
life of the construction project. These users are project managers and project
engineers who use the system for decision making. The users have a wide
range of computer skills from low to moderate. Therefore the system should be
designed to be user friendly, for the lowest level of computer skills incorporating
a graphical user interface. The system should be supported with proper
documentation and the users should be trained for using the system. Due to the
popularity of the Internet, people are more comfortable with web interfaces.
Therefore, a web based user interface may be appropriate for the project level.
Web based interfaces can also be used to develop more user-friendly
applications and interfaces within applications.

0 Normally a project director or senior project manager or the highest
decision-maker in the construction project acts as a system owner. Project
managers, project engineers, schedulers, contract expediters act as system

users. This again depends on the size of the project. In the case of a medium to

208

large size project, the project owner also acts as a project user and gives system
requirements at all the levels. In small projects, the project manager acts as a
system owner, principal user and also system developer. Normally, in the
construction project environment, a single person acts as a system analyst,
system designer and system developer. Many times in small to medium size
projects, the system is developed by the system users and therefore all activities
of system owner, user, designer and builder are done by a single person.
Systems developed in an "ad hoc" manner are generally not technologically
advanced and use old tools such as spreadsheets to develop systems. Table 7.1
shows the different types of construction projects and their use of IT
applications. It also shows the futuristic adaptation of IT applications by types of
construction projects.

0 The system developer's knowledge about the construction industry helps
in communication and also affects the quality of the product. The selection of the
system developer depends on the computer literacy of the system users Table
7.2 explains the combination of minimum skill sets of system developers, and
system user. Table 7.2 represents two combination of skill-sets represented by
two rows. The first row represents the fact that system users with high computer
skills can work with system developer with moderate system development
experience but high construction experience. The second row represents the
fact that system users with low computer skills need to have system developer

with high system development experience and low construction experience.

209

 

 

 

 

 

 

 

Table 7.1 Range of Construction Project and System Solutions
Size of Small Medium Medium - Large
Project Large
Project Single project Single project Senior Project Senior
Organization manager manager with Manager and project
some project manager,
assistants engineers project
managers &
project
engineers
People Project Project Senior project Senior
involved in manager acts manager acts manager acts project
system as a system as a system as a system manager
development owner, user, owner, user, owner and acts as a
designer and designer and user and project
builder builder system owner;
analyst acts project
as a system managers
designer and act as a
builder system
users and
system
analyst acts
as a system
designer
and builder
System Classical Structured Iterative Iterative
development Project Life Project Life Structured Structured
process Cycle Cycle Project Life Project Life
Cycle Cycle with
prototyping_
System Standard Standard Some Unique
Requirements customization
System Spreadsheet Nonintegrated Nonintegrated Nonintegrat
Architecture: based system spreadsheet networked —ed
Current designed & and market ready networked
build by project application application custom
manager developed by and custom programs
project programs and ready
manager. developed by applications
system developed
analyst by system

 

 

 

 

 

analyst.

 

210

 

 

 

 

 

 

 

 

 

 

Table 7.1 Range of Construction Project and System Solutions.
(Continuied)
Size of Small Medium Medium - Large
Project Large
System More standard More standard More market Combination
Architecture: organizational organizational available of custom
Future application application networked and market
architecture architecture applications solution in
including including according to an
Ready software Ready project integrated
packages and software requirements. networked
training. Ready packages and environment
software training. sharing data
packages with other
project
participants
Table 7.2 System Developer Selection

Dew

. Develo

per“ SYSté

 

o The system support phase is very important for the successful

 

implementation of information system in project environment. All initial phases
need to be done in a structured manner to avoid a lengthy system support
phase. One of the system users should be trained to solve most of the

unexpected system performance problems and prepare "ad hoc" reports.

211

7.3

Future Areas of Research

The following areas are suggested for future research

Based on the CMSDM, a detailed methodology can be developed which
identifies the documentation produced and standardizes the techniques that
should be used for applying CMSDM. This methodology should include
different variations for different project variables such as project types,
contract delivery systems, and system owners. Such methodology could also
be sold in the market and commercially exploited. This will make this
methodology more applicable to the different industries and different types of
projects.

Demonstrating applications of CMSDM by developing a high-end
comprehensive project control systems consisting of cost control, time
control, and a document management system. This project control system
would include all the data, processes, interfaces and geography related
issues of its component subsystems.

Benchmarking industry practices in developing information systems in a
project environment. This may include identifying factors that affect people in
selecting a particular approach of system development rather than the
defined structure approach. This would include a survey that can capture the
use of IT tools by different types of construction projects and construction
organizations. Such data can be used to identify the reason behind the use

of particular IT tools and their applications. This would also help in identifying

212

the best practices in the industry. This research can be used to identify the

variable factors involved in decision making related to selection of IT tools.

The role of computers and information technology in the construction industry
is going to increase considerably in the years to come. For the future challenges
of constructing better, cheaper, and faster, the construction industry needs to
take an approach of information technology to improve the whole process of
construction.

This thesis is an attempt to attract attention of the construction industry to
the role of information systems and to propose a methodology for developing
information system in the construction project environment taking full advantage

of the technological discoveries to achieve project objectives.

213

APPENDIX A

Data-Flow Diagram
Process modeling is a technique for organizing and documenting the structure
and flow of data through a system's processes and! or logic, policies, and
procedures to be implemented by a system's processes. A data flow diagram
(DFD) is a tool that depicts the flow of data through a system and the work or
processing performed by that system. A DFD consists of the following basic
concepts.
Process: A process is work performed on, or in response to, incoming data
flow or conditions. eg. Creating change orders or approving change orders.
Data Flow: A data flow represents input of data to a process or output of data
from a process. eg. Requisitions send by a contractor or checks send to a
contractor.
External Agent: An external agent defines a person, organization unit, other
system, or other organization that lies outside the scope of the project but that
interacts with the system being studied. e.g. Contractor, or an owner for a
system developed for a construction management firm.
Data Store: A data store is an inventory of data. It is an object where data is

stored. 6.9. A paper file or a database table.

214

 

There are several competing symbol sets for DFDs. Most of them are
names after their inventors (e.g., DeMarco, Yourdon, Gane, Sarson). The

example below explains use of DFDs.

 

    

 

 

  

 

    

 

Example: Figure A.1 DFD: Prepare Invoice
Invoice File
Contractor _ Invoice _> Prepare Processed l
IIVOICC .
Invonce

" Contract Info.

 

 

Contract File

 

Table A.1 DFD Legends: Prepare Invoice

 

Legend Explanation

 

 

Represents external agent sending
Contractor information into the system

 

 

 

 

Represent data flow. Invoice sent from

_ Invoice _> contractor to the system.

 

Represents process. This represents
Prepare converting invoice from paper format
Invoice into an electronic format.

 

 

Represent data store. This is where
information is stored about particular
entity. In this data store represents
processed invoice.

 

 

Invoice File Contract File

 

 

 

 

The example explained above represents the process of accepting invoices from

the contractor and processing then for storage in an electronic format.

215

 

APPENDIX B

Entity Relationship Diagram
Data modeling is a technique for organizing and documenting a system's data.
The entity relationship diagram (ERD) is the most commonly used modeling
technique for representing data models. ERD depicts data in terms of the entities
and relationships described by the data. Entity is something about which an
organization or people want to store data. A relationship is a natural association
that exists between two or more entities. The relationship may represent an
event that links the entities or merely a logical affinity that exist between the
entities. More information can be obtained about ERD by referring to information
systems literature. The following example explains the use of ERD to represent

data model [Whitten & Bentley, 1998; Davis & Olson, 1986; Topper, et. al, 1994].

216

 

Example

Figure 8.1 ERD: Contract and Invoice

 

 

 

 

 

 

 

 

 

 

 

 

Contract 1 <>_L Invoice
Table 8.1 ERD Legends: Contract and Invoice
Legend Explanation
Represents the two entities between
Contract Invoice which the relationship is intended.

 

 

 

 

 

 

Represents the relationship between
two entities

 

 

"N" represents possibility of more than
one invoice related to each contract; 1
represents the fact that each invoice
can have only one related contract.

 

 

Therefore, this model represents the relationship between two data entities. The

model shows that each contract can have more than one invoice related to it

where as each invoice can have only one contract related to it. Three possible

relationships can exist between two entities. These are 1 to N, 1 to 1, and

Nto N.

217

 

 

BIBLIOGRAPHY

ASCE Task Committee (1984) "Application of Small Computers in
Construction," Journal 'of Construction Engineering and Management, 111(3),
173-189

Adrian, J. (1981) "CM: The Construction Management Process," Reston
Publishing Company, Inc.

Ahmed, I., Russel, J., Abou-zeid, A. (1995) "Information Technology (IT) and
integration in the construction industry," Construction Management and
Economic, 13, 163-171.

Brown, C. (1980) "Recommended Procedure for Computer Selection," Journal
of Technical Councils of ASCE, 105, 319-325.

Barnes, W. (1993) "Microcomputers in Management of Construction
Operations," Journal of Construction engineering and Management, ASCE,
119(2), 403-412.

Breuer, J., Fischer, M. (1994) "Managerial Aspects of Information Technologies
for AIEIC Firms," Journal for Management in Engineering, ASCE, 10(4), 52-59.
Barrie, D., Paulson, B. (1992) "Professional Construction Management,"

McGraw Hill, Inc.

218

Bossen'nan, 8., Ford, M. (1985) "Development of Computerized Specification,"
Journal of Construction engineering and Management, ASCE, 110(3).

Burger, A., Halpin, D. (1973) "Data Base Methods for Complex Project Control,"
Journal of Construction Engineering and Management, ASCE, 103(3), 453-463.
CRSS Constructors (1992) "Constructors Procedure Manual: Cost Control,"
CRSS Constructors, Inc.

Chris I-I., Tung A. (1989) "Project management for Construction," Prentice-Hall,
Inc.

Curtis, G. (1995) "Business Information Systems," Addison-Wesley Inc.

Davis, 6., Olson, M. (1985) "Management Information Systems: Conceptual
Foundations, Structure, and Development," McGraw Hill, Inc.

EXPEDITION (1996) "Reference Manual," Primavera Systems Inc.

Fenves, S., Schiffman, R. (1979) "Quality Assurance of Engineering Software,"
Journal of Technical Councils of ASCE, 105, 57-73.

Fisk, E. (1997) "Construction Project Administration," Prentice Hall, Inc.

Gibson, 6., Bell, L. (1991) "Electronic Data Interchange in Construction,"
Journal of Engineering and Management, ASCE, 116(4), 727-737.

Kostem, C. (1993) " Migration to a Networked Workstation Environment," Fifth

International Conference on Computing in Civil and Building Engineering, ASCE,

1183-1189.

219

Krone, S. (1993) "Containing Construction Change with Computers," Fifth
International Conference on Computing in Civil and Building Engineering, ASCE,
1762-1769

Lackowitz, G. (1992) "Computer Vendor-User Relationships," Eighth National
Conference on Computing in Civil Engineering and Geographic Information
Symposium, ASCE, 1031 -1034.

Mead, S. (1997) "Project Specific Intranets for Construction Teams," Project
management Journal, September 97, 44-51.

Najafi, F. (1991) "Legal Aspects of Computer Use and Measures of Software

Quality and Legal Concern," Civil Engineering and Symposium on Databases

held in conjunction with NBC, ASCE, 178-191.

Paulson, B. (1976) "Concepts of Project Planning and Control," Journal of
Construction Engineering and Management, 102(1), 67-80.

Paulson, B. (1992) "Trends in Computer Application for Building Construction"
1992 Kudroff Memorial Lecture at Penn State.

Paulson, B. (1996) "Computer Applications in Construction," McGraw Hill, Inc.
Pixley, A. (1992) "Computer Vendor-User Relationships" Eighth National
Conference on Computing in Civil Engineering and Geographic Information
Symposium, ASCE, 1015-1020.

Primavera Project Planner (1997) "Reference Manual," Primavera Systems Inc.
Russel, A. (1993) "Computerized Daily Site Reporting" Journal of Construction

engineering and Management, ASCE, 119(2), 385-401.

220

 

Sadri, S.,Roozbeh, K. (1993) "Construction Information Management," Fifth
International Conference on Computing in Civil and Building Engineering, ASCE,
1754-1761

Schultz, R. (1997) "Information Systems and Architecture Practices," [Online]
Available http://www.co.calstate.edu

Stanton W., Willenbrock, J. (1990) "Conceptual Framework for Computer-
based Construction Safety Control," Journal of Construction engineering and
Management, ASCE, 1 16(3), 383-398.

Stukhart, G. (1989) " Bar-Code Standardization in Industrial Construction,"
Journal of Construction engineering and Management, ASCE, 116(3), 416-431.
Syal, M. (1992) "Construction Process Knowledge Model to Assist Method
Selection in Project Planning," Ph.D. Dissertation presented to the Pennsylvania
State University, University Park, PA.

Syam, M., Willenbrock, J. (1991) "Computer-Integrated Design Drawing, Cost
Estimating, and Construction Scheduling," HRC Series No. 11, Housing
Research Center, The Pennsylvania State University, University Park, PA
Tenah, K. (1986) "Construction Personnel Role and Information Needs," Journal
of Construction Engineering and Management, 112(1), 33-48.

Tenah, K. (1984) "Management Information Organization and Routing," Journal
of Construction Engineering and Management, 110(1), 103-118.

Terry, P. (1993) "Using Computers to Competitive Advantage: Philosophy and
Example," Fifth International Conference on Computing in Civil and Building

Engineering, ASCE, 1105-11 13.

221

Thomas, J., (1991) "Managing Computer Resources in Engineering Firms," Civil
Engineering and Symposium on Databases held in conjunction with AIEIC,

ASCE, 167-177.

Tonias, C. (1992) "Computer Vendor-User Relationships," Eighth National
Conference on Computing in Civil Engineering and Geographic Information
Symposium, ASCE, 1007-1014.

Whitten, J., Bentley, L. (1998) "Systems Analysis and Design Methods,"
McGraw Hill, Inc.

Williams, T. (1994) "Applying Portable Computing and Hypermedia to
Construction," Journal of Management in Engineering, ASCE, 10 (3), 41-45.
Yourdon, E. (1989) "Modern Structured Analysis," Prentice-Hall, Inc.

Zapalac, R., Kuemmler, K. (1994) "Establishing Management Information

System for Multiproject Programs," Journal of Management in Engineering,

ASCE, 10(1), 37-42.
Zaremba, C. (1993) "PC Networking - A Case Study," Fifth International

Conference on Computing in Civil and Building Engineering, ASCE, 1867-1873.

222