Web Based Application For Managing Change Orders in Construction Projects

Construction Innovation 2003; 3: 197–215
Web-based application for managing change

orders in construction projects
C. Charoenngam, S. T. Coquinco and B. H. W. Hadikusumo School of Civil Engineering,
Asian Institute of Technology, Pathumthani, Thailand
Abstract: A change order is an order from an employer authorizing a variation. Success in

managing change orders results in uninterrupted construction operations and an agreed
nal project cost as well as duration. One of the methods to manage change orders is to
establish good communication and cooperation among project team members. Success of
this method can be enhanced by developing and utilizing a web-based change order
management system that supports documentation practice, communication and integration
between different team members in the change order work ow. This paper discusses our
web-based project management system, change order management system (COMS), to
manage change orders using the Internet. In order to show COMS’ potential bene ts, a test
case was conducted for comparing the COMS with the conventional practice of change
order management.
Key words: change orders; contract; documentation; Internet; variation; web-based

project management
Introduction
The construction industry has a complex communication nature because a lot of parties are
involved in the business process. An example of this complex nature is that multiple reports
must be prepared to ensure that information is delivered to all organizations, departments or
staffs using it. This can be a problem if a channel and mechanism of communication is not
adequately designed. This problem can be overcome by establishing an Internet-based
communications channel, which supports information transfer for all remote project team
members is a timely and accurate means so that all teams can obtain the information suited to
their functions.
In the construction industry, a client often decides to issue a change order for authorizing
a variation of work from the original scope of work. A study by Cox et al. (1999) found that in
monetary terms alone, the direct cost of post contract design changes amounts to 5.1 to 7.6% of
the total project cost. In terms of project delays, change orders are considered to be one of the
major causes (Arditi et al., 1985; Ehrenreich-Hansen, 1994; Zafar, 1996; Al-Saggaf, 1998).
A change order is a complex information transfer that has to be managed carefully, otherwise
disputes between a client and a contractor related to cost and time of work might occur. A change
order is complex because it involves all the construction teams, together with a voluminous
amount of information that either has to be sent, checked, corrected, approved, requested,
clari ed, transmitted or submitted, among many other things. Owing to this complexity, a method
to manage change orders is proposed in this research by using Internet technology.
Address for correspondence: B.H.W. Hadikusumo, School of Civil Engineering, Asian Institute of Technology,
PO Box 4, Klong Luang, Pathumthani 12120, Thailand, E-mail: kusumo@ait.ac.th
# Arnold 2003 10.1191=1471417503ci058oa

198 C. Charoenngam, S.T. Coquinco and B.H.W. Hadikusumo
This paper rst discusses web-based construction project management. Secondly, we

discuss change orders in the construction industry including the existing practice of change
order process viewed from two different standard forms of contract: ICE 6th and FIDIC 4th.
This discussion is used to analyse the system of our proposed method, COMS. Finally, the
major works of research to develop COMS are discussed: analysing and developing the
COMS system and testing the proposed method in order to know its potential advantages.
Web-based project management
Bridges (1997) identi ed the potentials of Internet technology for managing construction
projects, stating that this technology will change business methods in managing construction
projects, for example, because data can be retrieved transparently from either a local disk or a
remote website that provides a communication point for client, designer and contractor. The
utilization of this technology has been applied in some actual projects (Scoones, 1999;
Wilkinson, 2000a,b) and academic researches (Deng et al., 2001).
Several commercial applications for managing change orders are available in the market.
The applications vary from a PC-based software, such as Primavera ExpeditionTM, to
business-to-business (B2B) servers, such as CitadonTM; however, we have not identi ed
any change order system that supports standard forms of contract, such as FIDIC and ICE,
which are commonly accepted and used in construction projects; this is the rst of our
research rationales.
The second rationale is to provide a framework for interested construction companies to
develop affordable web-based project management, particularly for the change order manage-
ment system.
The change order in construction projects
Change orders can be de ned as a change, alteration or addition with respect to the original
plans, speci cations or other contract documents, as well as a change in cost, which follow the
creation of legal relationship between client and contractor (Choy and Sidwell, 1991; Wallace,
1994; both cited in Chan and Yeong, 1995; and Hanna et al., 1998). Change order has several
characteristics: a) it is a written document containing authorization of the requested change,
b) the change is brought about through no fault of the contractor, and c) the changed work is
not included in the original contract and therefore it is not included in the contract price.
According to its types, Cox (1997) identi ed three kinds of change orders: 1) a formal
change order, which is an actual document called ‘change order’ issued by a client which
modi es the contract terms, plans or speci cations; 2) a constructive change order, which is
an extra contract work performed pursuant either to oral or implied owner directives, or as a
result for problems for which the owner is responsible; and 3) a cardinal change order, which
may occur whenever there is a substantial amount of work required outside the scope of the
original contract. The latter is out of this research scope.
Formal change orders are those that originate from either the owner or owner’s representa-
tive in the presence of the architect=engineer (A=E). It can be described as a directive issued
by the owner to conduct changes in the scope of work.
Web-based application for managing change orders 199
The constructive change orders originate from either the contractor or subcontractor. The
contractor les a constructive change when the authorized representative gives or fails to give
directions that interfere with the normal contract development and has such an effect as if a
formal change has been issued (Bu-Bshait and Manzanera, 1990).
Documentation and formal procedures for change orders

Chan and Yeong (1995) stated that quality contract documentation, and good communication
and cooperation between building team members are two of several elements that can be used
to manage change orders. The rst element, good documentation, can be facilitated through
the design of an effective change order system. Jacob (1978: 64–65) noted that ‘lax attitudes
and unfamiliarity with proper change order procedures have led to serious nancial loss and
insolvency’. A realization of the construction participants of the importance of documentation
practice is one of the rst components in the development of a change order system. The
effective change order system can be designed by understanding the change orders process or
work ow, which can be compiled from the standard forms of contract. The second element,
good communication, can be facilitated through providing information in a timely mechanism.
This can be achieved by using Internet technology as the communication media, because the
information can be accessed in a timely and accurate manner and may be accessed from
different locations. These two elements are used in this research to develop COMS.
The change order process: ICE 6th and FIDIC 4th

In this research, two standard forms of contract, ICE and FIDIC, are studied in order to
identify the practice of the change order process. The reason for choosing these two standard
forms is that they are well accepted.
ICE contract conditions

The conditions of this contract cover several aspects related to change orders: ordered
variations, valuation of ordered variations, engineer to x rates, and notice of claims.
Ordered variations. The ICE conditions of contract refer to change orders as ordered
variations. It is stated that it is the Engineer who can order variations, which should be in
writing, but can also be in oral form. For the case of oral instructions it was stated that such
instruction should be con rmed in writing as soon as possible. If such writing is not carried
out by the Engineer, the Contractor can make a written account of the said oral instruction
and, if not contradicted by the Engineer, shall be considered as an instruction in writing.
According to the ICE conditions of contract, the variations may include, ‘additions,
omissions, substitutions, alterations, changes in quality, form, character, kind, position,
dimension, level or line and changes in any speci ed sequence or method or timing of
construction required by the contract’. Figure 1 is a graphical representation of a possible
scenario for the conduction of a variation order.
Valuation of ordered variations. When the variation is of similar character and executed
under similar conditions, the works shall be valued according to the rates and values found in
the BOQ (bill of quantities). When the works to be varied is not similar, the BOQ shall be
used as a basis for valuation.
Figure 1. Ordered variation process
Engineer to x rates. On occasions of any work with related variations, in which the
Engineer or the Contractor nds the rate or price for such varied work on the contract as
unreasonable or inapplicable, the following are carried out:
° The Engineer gives to the Contractor or the Contractor to the Engineer a notice regarding
the inapplicability of the price. This is done before the commencement of the varied work
or soon thereafter as applicable.
° In circumstances in which the rate or price is to be varied, the Engineer shall x such rate
or price as in the circumstances the Engineer shall think reasonable and proper.
Notice of claims. A notice of claims procedure is conducted when the Contractor intends to
claim a higher rate or price than that stipulated by the Engineer. Its ow can be stated as
procedures for sending the notice of claims and procedures for the submission of interim
accounts and updates (Figure 2). Sending the notice of claims must be conducted following
several conditions: 1) the Contractor is to send a noti cation of intent to claim within 28 days
of the happening of such an event that provoked the intention to le the claim; 2) the intention
to le must be done in writing; and 3) the Contractor must keep contemporary records as may
be necessary to substantiate the Contractor’s claim. In addition, the procedures for submitting
the interim accounts and updates are as follows a) The Contractor must send the rst interim
account, after noti cation of claim. The rst account must give full details of the amount
claimed to date and the grounds of the claim. b) After this, the Engineer reserves the right to
Figure 2. Notice of claims and interim accounts and updates of ICE and FIDIC
ask the Contractor to send to the Engineer up-to-date accounts of the claim, giving the
accumulated amount for the claim and additional grounds for which the claim is based.
FIDIC 4th contract conditions

Some parts of the FIIDIC, Part I of the conditions of contract, have similar forms and contents
as the ICE conditions of contract. However, some details of the FDIC are different from ICE.
The process of change orders of FIDIC is similar to that of the ICE (Figure 1). The following
is a summary of some relevant aspects found in the FIDIC conditions of contract.
Variations. The FIDIC conditions of contract refer to change orders as variations. Similar to
ICE, the Engineer is given the right to order variations to the Contractor. The Engineer’s
authority consists of instructing the Contractor to do the following:
° increase or decrease the quantity of work included in the contract;
° omit such work except when the work is to be carried out by the Employer or another
contractor;
° change the character or quality or the kind of any such work;
° change the levels, lines, positions and dimensions of any part of the works;
° execute additional work of any kind necessary for the completion of the works;
° change any speci ed sequence or timing of the construction of any part of the works.
Valuation of variations. FIDIC’s clause for variation is similar to that of ICE.
Power of the Engineer to x rates. On instances where the varied works cannot be valued
appropriately by the existing rates and prices on the contract, the Engineer, in consultation
with the Employer and Contractor, shall determine a suitable rate or price, which should be
agreed upon by the Engineer and Contractor. In case of disagreements the Engineer shall x
such rates or prices as in his opinion is appropriate and shall notify the Contractor
accordingly, with a copy to the Employer.
FIDIC, in contrast to ICE, adds a provision in terms of time for noti cation for the
Engineer or the Contractor in cases where they may wish to change a rate or price. A notice
must be given within 14 days of the date of instruction (change order) by:
° the Contractor to the Engineer of the Contractor’s intention to claim extra payment or a
varied rate or price;
° the Engineer to the Contractor of the Engineer’s intention to vary a rate or price.
Procedure for claims. There are three important elements in the claims procedure:
° Notice of claims. The Contractor is to give notice of his intention to claim to the Engineer,
plus a copy to the Employer, within 28 days of the point when the event giving rise to the
claim has rst arisen.
° Contemporary records. The Contractor is to keep records in order to support the claim he
wishes to make.
° Substantiation of claims. After 28 days of giving the notice, the Contractor is to give the
Engineer an account giving detailed particulars of the amount claimed and the grounds for
which the claim is based. When the event is continuous, the Contractor is to give interim
accounts giving accumulated amounts and any further grounds upon which the claim is
based.
Figure 2 shows graphically the process for lling notice of claims and sending interim
accounts. It must be noted that the difference in FIDIC’s process is that it did not specify
that the notice should be in writing, unlike that of ICE. In FIDIC, the Contractor is to send
a nal account to the Engineer upon occurrence of the end of the effects resulting from
the event giving rise to the claim. The FIDIC states the process for submitting the nal
account.
Web-based change order management system (COMS)
There are three major steps in developing an application: system analysis, design and
implementation. System analysis studies the need to develop the application by identifying
its requirements. The system design stage studies how to represent the system analysed in the
computer format; and system implementation covers the programming part in order to
transfer the system analysis and design into a computer application software. The approaches
used to analyse the system are a) to understand the business objectives, and b) to model the
system. The system analysis part is discussed in detail in the third section, but the other two
stages are not presented in detail in this article. However, the results of the system design,
which are the business objects and its data requirements, are represented in Appendix A.
System implementation is presented brie y in Section 3 in order to provide a better idea of the
COMS developed.
Business objectives
The rst step to develop COMS is to analyse the system requirements. The results of this
analysis form the four main objectives of COMS:
1. Aid for change order transaction

° Facilitation of the timeliness of related change order documents submission. Reference
is given to the clause in ICE and FIDIC regarding the days given to submit change order
claims and interim reports.
° The system should act as a tool to facilitate better communication between the
construction participants.
° The system should act as a proactive tool for the prevention of costly disputes. This is
the core premise for the RFI (request for information) subsystem.
° Reduction of cost in business processing compared to the previous paper-based system.
Reduction in cost can be achieved in terms of avoidance of delays and potential disputes
to mismanaged change orders.
2. Offer data storage and structure
° The system should aid proper structured documentation providing an integrated data
source.
° The system should be able to le change order requests and change orders and all
related attachments to each change order systematically, such that access to such
documents can be facilitated.
3. Aid for change order form making
° The system should be able to set the process to follow in change orders, thereby giving
the process set procedures, and hence control and uniformity. This is done in the
assumption that the eld personnel are not equipped with ample knowledge in change
order management.
4. Practicality of application
° A generic ability of the system prototype to be reused for different projects.
Another result of this analysis is the context diagram presented in Figure 3. The context
diagram de nes the scope and boundaries of the system. This diagram is accompanied with
system rules which govern the roles of project teams as follows:
1. Owner
° Can correspond only through the architect=engineer. Uses correspondence to ask for
any intended change of works.
° The major function of the owner is to decide whether a change order request and its
attached work evaluation will be approved, returned for renegotiation or rejected. It
must be noted that a change order request, before it is brought up to the owner for nal
approval must be evaluated rst by the architect=engineer for its merits and cost
proposal made by the contractor.
Figure 3. Change order management system context diagram
° The owner will always receive copies of correspondence, request for information,
change order request, change order: cost proposal, change order for approval and
interim reports made by the contractor sent to the architect=engineer.
2. Architect=Engineer
° Corresponds directly to the contractor and on occasion to the owner.
° Between the owner and the architect=engineer, the latter reserves the right to issue
formal change order requests and approved change orders. The architect=engineer
functions as the direct representatives of the owner to the contractor.
° Receives correspondence from owner and contractor.
° Evaluates change order cost proposals (change order for approval).
° Can ask for cost and schedule interim reports.
3. Contractor
° Corresponds directly with the architect=engineer but sends copies to owner’s account.
° Acts as the representative for the subcontractor. Receives and sends correspondence
from subcontractors regarding clari cations on work items or for facilitation of
subcontractor initiated change of work request.
° Reserves the right to send change order request, change order cost proposals and
interim reports.
° Receives approved change order with notice to proceed and change order requests
subject to work valuation from the architect=engineer.
4. Subcontractor
° For items of work that require valuation, the subcontractor corresponds the values to the
contractor. In this system, only the contractor can send a formal work valuation
document in the form of the change order: the cost proposal.
° If the subcontractor in doing his works nds a need to bring about a change order
request, he shall do so through the contractor by sending a correspondence.
5. Supplier (not included in this study)
° Supplier information can be added to the system in order to cost the changed work in
terms of added materials and equipment.
Object-oriented modeling
In this study, object-oriented methodology is used to conduct a detailed study of system
analysis. A speci c method, ‘use cases’, is used. This method can be used to identify objects,
attributes, behaviour and relationships between objects in the systems.
Object-oriented modeling in this method involves three main stages: 1) nding ‘actors’ and
‘use cases’ based on the system’s context diagram, 2) constructing the ‘Use Cases’ model,
and 3) identifying business objects and its de nitions.
Finding ‘actors’ and ‘use cases’ based on the context diagram . The ‘actors’ and ‘use cases’
found are listed in Table 1.
Modeling the ‘use case’. By using the previous analysis, the ‘use case’ of COMS can
be modeled (Figure 4). The model consists of three subsystems: 1) the change order
facilitation management subsystem, 2) the request for information subsystem, and 3) the
documentation management subsystem.
Change order facilitation management subsystem. This subsystem enables the participants
to make change order requests, correspondence and clari cations, and change order couples
with notice to proceed. There are two scenarios applied in this subsystem: formal change
order and constructive change order. In the rst scenario, the owner makes a change order
request document. The contractor is then asked to produce a valuation in terms of cost and
schedule with regard to the change works. The contractor either makes a valuation or if the
changed work is subcontracted, asks the subcontractor to make the valuation. The contractor
may also opt to send a correspondence for clari cation if the valuation is vague. After
clari cation, the contractor then sends the valuation of the change works as a change order
cost proposal, which is subject to owner approval. The A=E checks the change order cost
proposal and performs one of two functions: 1) The A=E may send a correspondence to
clarify items on the cost proposal, or 2) if the A=E is satis ed, the A=E may recommend the
proposal to the owner for approval and eventual signing. The A=E then facilitates the sending
of the approved change order to the contractor coupled with a notice to proceed document.
Table 1 Listings of actors and use cases for the COMS
Actor Use case

Owner Initiates Sends correspondence (limit to A=E account only)
Initiates Sends approved change order to the contractor
Architect=engineer (A=E) Initiates Sends correspondence (to owner, contractor)
Initiates Submits change order request
Initiates Sends change order (assessed by A=E to the owner for approval)
Contractor Initiates Sends correspondence (to subcontractor, A=E)
Initiates Submits change order request
Initiates Submits change order: cost proposal
Initiates Submits change order: interim reports
Initiates Submits request for information
Subcontractor Initiates Sends correspondence (to contractor only, regarding RFI,
work valuation, request for change work, interim reports)
Supplier (optional) Initiates Submits material and equipment cost list
Figure 4. Change order management system (COMS) ‘use case’ model
In the second scenario, the contractor sends a change order with a valuation (change order
cost proposal) to the A=E for approval, or the contractor just sends a notice of an occurrence
of a change event rst, in the form of a change order request, and then sends the change order
cost proposal thereafter. Similar to scenario 1, the A=E checks the change order cost proposal
and so on.
Request for information subsystem. This subsystem enables the participants to send request
for information forms. The system scenarios are: 1) the contractor or subcontractor asks for
design clari cation from the A=E, or they may send shop drawings for approval, and 2) the
A=E is given a set time according to the contract to review the queries and respond.
Documentation management subsystem. The main function of this subsystem is to record

the interim cost and schedule changes arising from particular change orders, which can be in
the form of photos, receipts, schedule documents, purchase orders, and so on. The scenarios
of this subsystem are: 1) the contractor keeps records to document the change order in terms of
alterations in cost and schedule, which may include cost of material, labour equipment,
overheads, pro t and time delays, and 2) the system should be able to give a summary report of
the changes of the total cost and schedule regarding any particular change of work.
Business objects. The use case model is analysed to produce the business objects and
objects’ association. There are eight business objects found in this study, as can be seen in
Figure 5, which illustrates the association between business objects. The eight business
objects are:
Figure 5. Object association model
1. Correspondence – a document of communication sent by the owner, A=E, contractor or

subcontractor for the purpose of clarifying, asking for information, or informing the
receiving party of intent for a change of work.
2. Change order – a formal document that alters some conditions of the contract document.
The change order may alter the contract price, schedule of payments, completion date or
the plans and speci cations.
3. Change order: cost proposal – an unapproved change order made by the contractor, which
states the estimated added or deducted contract price and new time of completion (if any),
due to the change order request.
4. Change order: approved – a change order contract document that has been approved by
the owner. This documents enables the contractor to commence with the change order
work.
5. Change order: interim reports – a document that contains interim information regarding
the accumulated cost and schedule of approved change works.
6. Change order request – a document written by the owner, A=E, contractor or subcon-
tractor. This document states a change event or intent for a change in a project.
7. Request for information – a form of communication=correspondence, which poses
questions regarding drawings and speci cations. This form is sent by the contractor or
subcontractor to the A=E.
8. Construction participant – the owner, A=E, contractor, subcontractor or supplier.
The result of this object identi cation is used to design the COMS database. Among
the eight objects found, four objects are represented into database tables: change order
request (Table A1), change orders (Table A2), correspondence (Table A3), and request for
information (Table A4). These tables show the business objects and data requirements
needed in the COMS.
System development
The COMS is developed under MicrosoftTM environment by Microsoft AccessTM for data-
base development, Active Server Pages (ASP) Visual InterdevTM as a server programming,
and Structure Query Language (SQL) for manipulating the data in the Microsoft Access
database.
An example of the application interface for checking the status of the change order is
illustrated in Figure 6. The data in this gure shows that several change orders are sent to the
contractor. By clicking the ‘view’ button, detailed information of the change order can be
obtained (Figure 7).
Advantage of COMS compared to a conventional method of change order
This section discusses the advantages of COMS compared to the conventional method of
change order management by using a simulation of a typical change event. For this purpose, a
case study, modi ed from the Primavera ExpeditionTM, is used. The project consists of a
single-storey, masonry structure with brick siding, housing an automobile and light truck
servising centre construction. The service centre has below grade pits ranging from 0.5 to 0.8 m
below the furnished oor. This structure involves reinforced concrete, structural steel, masonry
walls and brick siding. The exterior work includes site drainage, paving and landscaping.
A variation issue occurred in this project. During the excavation activity of the trenches, an
estimated 10 cubic metres of extra rock was found that was not part of the agreed upon scope
of work. For this, the contractor initiated the process for a possible constructive change order.
Figure 8 shows the ow diagram to be followed in conduction of the change order.
Figure 6. An example of a COMS interface: change order view

Figure 7. An example of a COMS interface: change order information
Change order process in the conventional paper-based method

In the conventional method of change order management, a paper-based method is used,
where a form must be lled manually and sent to another party. Table 2 shows the estimated
time needed to process the change order. In this conventional method, a party needs two days
to ll in the form and send to the other party. The number of days to complete the change
order process until it is approved is 12 days.
Change order process in the COMS method

The change order facilitation conducted through COMS differs only slightly from the
traditional method. The typical change order work ow is still followed, meaning that
actual negotiations and agreements are not facilitated by the information system, and cost
and time issues must still be settled through meetings or other traditional means.
The COMS system aids in the following:
° usage of a standard set of forms for each activity in the facilitation process;
° prompt delivery of the documents to the addressed construction participant;
° means to know if the other party has read your sent document;
° record keeping is through a common centralized database, therefore all parties have the
same documents and no con icts arise regarding loss of particular forms;
° mismanagement of documents is avoided.
Figure 8. Flow diagram of the change order procedure
However, the following restrictions arise in the use of the COMS:

° To enable the use of the system a construction participant is required to be connected to the
Internet.
° A construction participant is also assumed to check his=her document manager regularly to
check for any new documents.
° Partnering must be strong between the different construction participants since there will
only be one central database. Each participant must trust the holder of the database and
program logic.
° The users of the system must have some know how of proper change order document
management concepts like placing the correct document code format.
Table 2 Total duration to complete the change order process: the conventional method
Activities Duration in days
1 2 3 4 5 6 7 8 9 10 11 12
Contractor sends a change 5 5
order request
Architect=engineer acknowledges 5 5
COR and requests for a COCP
Contractor prepares a change 5 5
order: cost proposal
Architect=engineer assesses 5 5
COCP, determines an
agreeable price and time
Owner assesses COAA, af xes 5 5
signature for approval
Contractor creates a COIR for 5 5
change order work assessment
Total time consumed 12 days
Table 3 Total duration to complete the change order process: the COMS method
Activities Duration in days
1 2 3 4 5 6
Contractor sends a change order request 5
Architect=engineer acknowledges COR and requests for a COCP 5
Contractor prepares a change order cost proposal 5
Architect=engineer assesses COCP: determines an agreeable 5
price and time
Owner assesses COAA, af xes signature for approval 5
Contractor creates a COIR for change order work assessment 5
Total time consumed 6 days
Assuming the use of the COMS system and taking into account the speed at which a docu-
ment can be sent through the Internet, it is assumed that the 12 days it took to facilitate the
change order using the traditional means can be cut to six days (Table 3). This is done by
eliminating the usual extra day required for each activity for delivery of the documents to the
addressed construction participant.
Conclusion
The potential advantage of Internet technology to deliver information in a timely, remote and
accurate manner for a complex organization can be utilized to manage the change order process
in construction projects. The advantages of adopting this technology in the change order
management process are; 1) usage of a standard set of forms for each activity in the facilitation
process, 2) prompt delivery of the documents to the addressed construction participant, 3) the
means to know if the other party has read the sent document, 4) record keeping is through a
common centralized database, therefore all parties have the same documents and no con icts
arise regarding loss of particular forms, and 5) mismanagement of documents is avoided.
Appendix
Table A1 Data requirements for change order request document
Required Data Remarks

Project information
Project name Refers to the speci c project name
Project Code Refers to the code assigned to determine each project from
another
Contract number The contract number re ected in the construction contract
Contract date The date when the contract was signed and agreed upon
Owner The owner’s name
Architect=engineer The architect=engineer’s name
Contractor The contractor’s name
Change order request information
Title The general topic related to the COR
Change order request code The unique code assigned to each COR document
Document sent date The date when the COR is sent by the initiator
Sent to Refers to the person in authority addressed by the COR
document
Sent by Refers to the person in authority sending the COR document
Work breakdown structure number Re ects the code assigned by the contractor to the work to
which the COR is referring
Work breakdown structure title Re ects the title assigned by the contractor to the work to
which the COR is referring
Contract references Refers to any related contract that is used as references to the
COR, e.g. drawings or specs
Initiator’s name The name of the speci c initiator of the COR
Initiator document Refers to any contract that is a basis for executing the COR
document
Job condition Describes the onsite job situation for the intended COR work
Change order request justication Reasons=justi cations of the change order work
Description of work to be done Procedures that are intended to be done to conduct the
change of work
Table A2 Data requirements for change order document
Required data Remarks

Project information
Project name Refers to the speci c project name
Project code Refers to the code assigned to determine each project from another
Change order information
Title The general topic related to the COR
Change order code The unique code assigned to each CO document
Status Determines the level of the change order document, i.e. CO, COCP, COAA,
COAO, or COIR
CO sent date The date when the CO was sent by the initiator
CO sent to Refers to the person in authority addressed by the CO document
(continued)
Table A2 Continued

CO sent by Refers to the person in authority sending the CO document
COCP sent date The date when the COCP was sent by the initiator
COCP sent to Refers to the person in authority addressed by the COCP document
COCP sent by Refers to the person in authority sending the COCP document
COAA sent date The date when the COAA was sent by the initiator
COAA sent to Refers to the person in authority addressed by the COAA document
COAA sent by Refers to the person in authority sending the COAA document
COAO sent date The date when the COAO was sent by the initiator
COAO sent to Refers to the person in authority addressed by the COAO document
COAO sent by Refers to the person in authority sending the COAO document
COIR sent date The date when the COIR was sent by the initiator
COIR sent to Refers to the person in authority addressed by the COIR document
COIR sent by Refers to the person in authority sending the COIR document
Work breakdown structure number Re ects the code assigned by the contractor to the work to which CO
is referring
Work breakdown structure title Re ects the title assigned by the contractor to the work to which CO
is referring
Contract references Refers to any related contract that is used as references to the CO.
e.g. drawings or specs
Initiator’s name The name of the speci c initiator of the CO
Initiator document Refers to any contract that is a basis for executing the CO document
Change order work The actual steps involved in conducting the change work
Cost proposal information
Original contract price The original agreed contract price
Net change in price Sum of all price changes due to change orders as of present date
Current contract price The present current price in consideration of past price changes
Present contract price Change in price due to the proposed change order
New contract price Probable new contract price due to present proposed change order
Original contract time The original agreed contract time for completion
Net change in time Sum of all time changes due to change orders as of present date
Current contract time The present current time in consideration of past time changes
Present contract time Change in time due to the proposed change order
New contract time Probable new contract time due to present proposed change order
Change order approval information
Owner approval Owner approval in the form of a signature
Date of owner’s approval Date at which the owner af xed his signature
Owner’s company name Name of owner’s company
A=E approval A=E approval in the form of a signature
Date of A=E’s approval Date at which the A=E af xed his signature
A=E’s company name Name of A=E’s company
Contractor approval Contractor approval in the form of a signature
Contractor’s company name Name of contractor’s company
Change order interim report information
Budget price for change work The agreed upon budget for the change order work
Accumulated cost so far The accumulated cost of the change work as of present date
Deviation in case The deviation in actual cost if any, from the budget of the change work
Estimated time for change work The agreed upon estimated time for the change order present date
Accumulated time so far The accumulated time used for the change work as of present date
Deviation in time The deviation in actual time consumed, if any, from the estimate time of
the change work
Change work comments Any remarks intended by the contractor for the attention of the A=E
regarding the change work
Contractor’s signature Authenticates the submission of the interim report
Table A3 Data requirements for correspondence document (CORR)

Project information
Project name Refers to the specic project name
Correspondence Information
Title The general topic related to the CORR
Change request code The unique code assigned to each CORR document
Document sent date The date the CORR was sent by the initiator
Sent to Refers to the person in authority addressed by the CORR document
Sent by Refers to the person in authority sending the CORR document
Work breakdown structure number Re ects the code assigned by the contractor to the work to which CORR
is referring
Work breakdown structure title Re ects the title assigned by the contractor to the work to which CORR
is referring
Contract references Refers to any related contract that is used as references to the CORR,
e.g. drawings or specs
Iinitiator’s name The name of the specic initiator of the CORR
Initiator document Refers to any contract that is a basis for executing the CORR document
Subject Contains the intent of the CORR. This section of the document is where
the construction participants may write down their queries and replies
Table A4 Data requirements for request for information document (RFI)

Project information
Project name Refers to the specic project name
Change order request information
Title The general topic related to the RFI
Request for information code The unique code assigned to each RFI document
Initial sent date The date when the RFI was sent by the initiator
Initial sent to Refers to the person in authority addressed by the RFI document
Initial sent by Refers to the person in authority sending the RFI document
Work breakdown structure number Re ects the code assigned by the contractor to the work to which RFI
is referring
Work breakdown structure title Re ects the title assigned by the contractor to the work to which RFI
is referring
Contract references Refers to any related contract that is used as references to the RFI, e.g.
drawings or specs
Initiator’s name The name of the specic initiator of the RFI
Initiator document Refers to any contract that is a basis for executing the RFI document
Request for information Section of the document where the contractor places his request for
information
Request for information reply The architect=engineer after a designated time replies to the contractor
through this format
References
Al-Saggaf, H.A. 1998: The ve commandments of Deng, Z.M., Li, H., Tam, C.M., Shen, Q.P. and
construction project delay analysis. Cost Love, P.E.D. 2001: An application of the Internet-
Engineering 40(4), 37–41. based project management system. Automation in
Arditi, D., Akan, G.T. and Gurdamar, S. l985: Construction 10, 239–46.
Reasons for delays in public projects in Turkey. Ehrenreich-Hansen, F. 1994: Change order
Construction Management and Economics 3(2), management for construction project. Cost
171–81. Engineering 36(3), 25–28.
Bridges, A.H. 1997: Implications of the Internet for the Hanna, A.S., Russell, J.S. and Thomack, D. 1998:
construction industry. Automation in Construction Quantifying the effect of change orders on electrical
6, 45–49. construction labor ef ciency. Cost Engineering
Bu-Bshait, K. and Manzanera, I. 1990: Claim 40(2), 36–40.
management. International Journal of Project Jacob, R.C. 1978: How to cope with claims and
Management 8(4), 222–28. change orders. McGraw Hill’s Construction
Chan, A.P.C. and Yeong, C.M. 1995: A comparison Contracting October, 64–65.
of strategies for reducing variations. Construction Scoones, A. 1999: Electronic exchange of project
Management and Economics 13(6), 467–73. information: 3COM Project, Phase 2, IT Case
Choy, W.K. and Sidwell, A.C. 1991: Sources of Study. London: CRC Ltd.
variations in Australian construction contracts. Wallace, D. 1994: Hudson’s building and engineering
Building Economist 30(3), 25–30. (Cited in contracts. London: Sweet and Maxwell. (Cited in
Chan, A.P.C. and Yeong, C.M. 1995: A Chan, A.P.C. and Yeong, C.M. 1995: A comparison
comparison of strategies for reducing variations. of strategies for reducing variations. Construction
Construction Management and Economics, l3(6), Management and Economics 13(6), 467–73).
467–73). Wilkinson, P. 2000a: Making the connection — a low
Cox, I.D., Morris, J.P., Rogerson, J.H. and cost ‘Extranet’ for construction project teams:
Jared, G.E. 1999: A quantitative study of post Damond Lock Grabowski, IT Case Study.
contract award design changes in construction. London: CRC Ltd.
Construction Management and Economics 17(4), Wilkinson, P. 2000b: Electronic issue management
427–39. system: GreenPark, Reading, IT Case Study.
Cox, R.K. 1997: Managing change orders and claims. London: CRC Ltd.
Journal of Management in Engineering 13(1), Zafar, Z.Q. 1996: Construction project delay analysis.
24–29. Cost Engineering 38(3), 23–40.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Web Based Application For Managing Change Orders in Construction Projects

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Based Application For Managing Change Orders in Construction Projects

Uploaded by

Copyright:

Available Formats

Construction Innovation 2003; 3: 197–215

Web-based application for managing change

Abstract: A change order is an order from an employer authorizing a variation. Success in

Key words: change orders; contract; documentation; Internet; variation; web-based

# Arnold 2003 10.1191=1471417503ci058oa

This paper  rst discusses web-based construction project management. Secondly, we

Web-based project management

The change order in construction projects

Documentation and formal procedures for change orders

The change order process: ICE 6th and FIDIC 4th

ICE contract conditions

Figure 1. Ordered variation process

FIDIC 4th contract conditions

Valuation of variations. FIDIC’s clause for variation is similar to that of ICE.

Web-based change order management system (COMS)

1. Aid for change order transaction

Figure 3. Change order management system context diagram

Table 1 Listings of actors and use cases for the COMS

Actor Use case

Figure 4. Change order management system (COMS) ‘use case’ model

Documentation management subsystem. The main function of this subsystem is to record

Figure 5. Object association model

1. Correspondence – a document of communication sent by the owner, A=E, contractor or

Advantage of COMS compared to a conventional method of change order

Figure 6. An example of a COMS interface: change order view

Figure 7. An example of a COMS interface: change order information

Change order process in the conventional paper-based method

Change order process in the COMS method

Figure 8. Flow diagram of the change order procedure

However, the following restrictions arise in the use of the COMS:

Activities Duration in days

Activities Duration in days

Table A1 Data requirements for change order request document

Required Data Remarks

Table A2 Data requirements for change order document

Required data Remarks

Required data Remarks

Required data Remarks

Table A4 Data requirements for request for information document (RFI)

Required data Remarks

You might also like

This paper rst discusses web-based construction project management. Secondly, we