1
Chapter One: INTRODUCTION
1.1. General Background of the Study
The Construction industry is portrayed as a dynamic, versatile, and a risky industry.
Decisions are being taken every day in construction projects based on assumptions, individual’s
experience, and inadequate data (Anees et al., 2012). In fact, mega construction projects have
been executed with an average of 20% deferment as opposed to what was planned, and
completed with 80% over budget (Agarwal et al., 2016). The construction sector is distinctive
from the production sector in the sense that: 1) the construction supply chains are project-based,
2) it involves multiple stakeholders allocated in different areas, and 3) management systems
are customized with respect to the adopted project delivery method (Hao et al., 2008). Given
these factors, there are various events that take place during the course of a project that are not
anticipated before starting the project. Consequently, changes are inevitable in every
construction project regardless of its type or size. These changes constitute a principal factor
for works disruption, cost increase, time slippage, and scope creep. Project changes can result
in cumulative cost overruns as much as 200% of the original project budget (Ibbs, 2012). In
terms of time slippage, project changes are determined to be one of the main causes of projects
delays (Ibbs, 2001). In terms of work productivity, studies have shown that unidentified and
unanticipated changes cause a disruption to the flow of works which consequently decreases
the labor productivity on site (Ibbs, 1997 and 2001). A study conducted by Sun et al. in the UK
in 2004 revealed that “More than a third of major clients are dissatisfied with contractors’
performance in keeping to the quoted price and to time, resolving defects, and delivering a
final product of the required quality”. These overruns and defects are mainly inflicted due to
the various changes taking place in the projects that the contractors failed to cope with.
2
A project change is any event that has an impact on the project’s scope, time plan, quality
and/or cost budget with respect to the baseline project management plan formulated at the
beginning of the project which is based on the awarded contract (Hanna et al., 2002). These
changes could be initiated or identified by one of the stakeholders, be it the Contractor’s team,
the Engineer’s team, the Owner’s team, or anyone who is directly or indirectly involved in the
project. Changes could take place on various scales. These events occur in all construction
projects arising out of numerous causes, generated from different sources, at any time during
the course of a project. Furthermore, changes in the construction sector, if not properly
identified and dealt with in an effective manner, can be a major source of contractual disputes,
which is a contributing factor to a project’s failure (Hao et al, 2008). The inevitability of these
changes necessitates an implementation of an integrated, yet effective, change management
system in all construction projects, irrespective of their sizes, let alone the megaprojects.
The objective of a change management system “CMS” is to forecast potential changes, capture
changes that have occurred, formulate action plans for preventive and corrective measures, and
monitor the implementation of changes simultaneously (Sun et al, 2006). CMSs currently
adopted by construction entities in the market involve an immense amount of change
documents emerging from the different types of documents such as Internal Change Reports
(ICPs), Potential Change Notice (PCNs), Variation Proposals (VPs), Contract Change Orders
(CCOs), or Request for Information (RFIs). Each change requires proper identification,
analysis, documentation, and apportionment of responsibilities to effectively manage the
repercussions of this change. Construction changes take place concurrently and
simultaneously, which makes the formulation of an integrated CMS of paramount significance
(Karimidorabati et al., 2016). The incapability or ineffectiveness of the project change control
management may ultimately lead to an overall project failure (Hwang and Low, 2012).
A Variation Order (VO), or sometimes referred to as Contract Change Order (CCO), is a
contractual document in which the Contractor and the Owner agree to amend the project’s
3
baselines, be it the project’s time schedule, contract price, and/or the scope of works, without
having to draft a new contract (Keane, et al., 2010).
On the other hand, there are various project delivery methods “PDMs” currently adopted in the
construction sector that prescribe how a project is being delivered. Selecting an appropriate
delivery method is determined upon the given circumstances of a particular project. One of
these methods is the turnkey in which the Contractor provides a comprehensive set of services
containing basic and detailed Engineering, Procurement, and Construction “EPC” works, or
sometimes referred to as “design-build projects” with minimal involvement from the Owner.
In most of the times, EPC projects are delivered by contractors entering contract agreements
with owners on lump-sum turnkey basis “LSTK”, in which almost all project risks are
transferred to the contractor’s liability. Turnkey and design-build projects have more
uncertainties as opposed to a traditional design-bid-build project. A study has shown that
turnkey and design-build projects encounter an average of 7.4% of negative changes whereas
the design-bid-build projects had an average of 0.4% positive changes (Ibbs, et al, 2003). This
is mainly due to the fact that turnkey and design-build project embark on without a well-defined
scope of works and accurate data.
Therefore, it is imperative for turnkey contractors to incorporate their own project CMS that
would capture, analyze, and monitor all project changes effectively irrespective of whether
such change cases could be claimed against another project parties. Even if the contractor will
absorb the impacts of such changes on its own account, these changes must pass through the
project change management to sustain the project performance as per the baseline budget and
schedule and to ensure that all deviations are properly managed and controlled. An important
aspect of the project change management is continuous improvement where the analyses made
for each change case would be utilized by the contractor as a lesson learned to be considered
whether in upcoming projects or during the ongoing ones.
4
1.2. Problem Statement
The inevitability of changes in construction projects necessitates managing changes in
an effective and a systematic way in terms of time and cost savings, as well as smoothness of
data flow and analysis accuracy. The majority of Contractors currently engaging in the practical
field do not implement project CMS in its entirety whereas the Contractors who execute project
CMS do not have an efficient system for controlling all changes to the project’s baselines
(Karimidorabati, 2016; Nahod, 2012). Mismanaging changes, or lack of controlling thereto,
can result in adverse irreversible impacts to the projects (Mitropoulos and Tatum, 2000; Anees
et al, 2012; Hanna, 2004). Construction practitioners as well as academic researchers tend to
focus on CMSs that are only associated with Contract Change Orders or external changes.
These systems would not necessarily lead to positive results in all cases, particularly for
contractors undertaking Engineering, Procurement, and Construction works on a turnkey basis.
In such case, it is essential to handle all deviations and changes to the project baselines,
regardless of who is the party responsible to bear the impacts. In this context, construction
megaprojects encompass various stakeholders from different backgrounds who are not
necessarily located within the same area. Multiple changes take place concurrently during the
course of a project, which, if not properly identified and dealt with, will have negative
consequences on the project’s performance and the Contractor’s objectives.
Furthermore, the CMSs being adopted in the construction industry require significant amounts
of paperwork and documents that have to be circulated among the different stakeholders of a
project where it would consume unnecessary amounts of time, cost, and efforts (Charoenngam
et al., 2003; Chen et al., 2015). Current systems rely on hardcopy documentations, electronic
mails, and softcopy archiving in the format of Portable Document Format “PDF” in which they
are circulated by the Change Manager among the stakeholders. These systems depend on
human discipline and awareness, which is most likely exposed to errors, loss of data and
unreliability of its results. As a result, contractors tend to view the CMS as time and cost
5
consuming to the point that the viability and benefits of these systems are not perceived. This
ultimately leads to scope creep, cost overruns, and time slippages. Such repercussions would
result in profit erosion which would affect the Contractor’s business performance in general.
Another key barrier that is particular to EPC/Turnkey projects where the project team of the
Contractor is spread over several locations. For instance, the Engineering works, procurement
works, and management activities are carried out at the Contractor’s Area Office whereas the
Construction team is allocated on site; some of the Engineering and Procurement activities
could also be carried out overseas, at the Head Quarters Office for instance. Therefore, to
implement a paper-based change control management system in such organization would
require an extensive amount of communication activities and data circulation between the
different disciplines in more than one location. Furthermore, paper-based systems do not have
a single database platform that would compile the data gathered from all projects; this impedes
the Contractor from utilizing the CMS analysis for its continuous improvement.
Hence, there are market needs for having an effective change management tool for Turnkey
Contractors in which it could easily involve the corresponding stakeholders in the different
processes of construction changes to optimize the time and effort consumption as well as
reducing projects’ costs.
1.3. Research Objectives and Scope
The aim of this research is two-fold outcomes, the first outcome is to develop a Change
Management System “CMS” customized for Lump-sum Turnkey Contractors in accordance
with the change control guidelines outlined by the professional construction institutes, as
discussed in the Literature Review Chapter. This shall be produced by formulating, as well as
visualizing, process workflows and working steps that, collectively, shall address all scenarios
that could be encountered during the implementation of the CMS throughout the execution
phases. The second outcome is to develop an integrated web-based user-friendly toolkit,
namely a comprehensive CMS web-based portal, to automate the CMS workflow, data
6
circulation, and data analysis, on the project & portfolio levels, to act as a single-source hub
for the CMS of the Contractor. The toolkit aims to eliminate all required paperwork, manual
circulation, or analysis, pertaining to the CMS and, thus, optimizing the time consumption, cost
efficiency, and accuracy of circulated data. In principle, it shall also maximize the benefit of
the extensive data stored on the toolkit by providing all required Key Performance Indicators
“KPI”s and data analysis to enable the Contractor to determine the areas of concerns for the
purpose of continuously improving the projects’ performances.
Upon implementing the web-based tool and adopting the CMS, the following subsequent
outcomes shall be realized:
A structured set of working steps to assist the Contractor to set up the CMS procedures
for new projects
Eliminating the need for paperwork and redundancy of data entry. It also optimizes the
needed efforts among the team to communicate the particulars of change cases
Integrating CMS related-data seamlessly by continuously updating the Output
Component dashboard, reports, and lists
A unified platform for all project’s CMS data that could be accessed virtually from any
location using the Internet
Identifying the bottlenecks of the CMS process and the delayed task owners for the
purpose of optimizing the workflow.
Allocating the magnitude of impacts, resulting from change cases, to their respective
cost accounts which enables the PM to monitor the amount of deviations occurring to
each element within the project’s CBS
This application can be promoted as a useful tool to be adopted by Contractors currently
employed in mega construction projects, particularly in EPC/turnkey projects, for managing
the workflow of the change management processes.
7
1.4. Research Methodology
The following chart illustrates the research’s sequential methodology:
8) Provide research conclusions & recommendations
7) Conduct model validation by launching the model for actual implementation within a
running project of a LSTK EPC contractor
6) Model & Working Steps verification by designing & conducting face-to-face interviews
with the representative sample of EPC LSTK Contractors experts to assess the
functionalities & capabilities of both functions through a set of structured questions
5) Conduct initial testing and tuning for the web-based model
4) Design & Develop: a) detailed working steps and procedures for applying effective
project change management within lump-sum turnkey projects to be used by EPC
contractors, and b) a comprehensive web-based toolkit to facilitate the application of
project change management for LSTK EPC Contractors by automating the workflows,
alerting & notification systems, and generation of data analysis reports
3) Develop research methodology to reach the desired objectives based on Literature
Review and experts feedback
2) Identify and study the different factors affecting the internal and external change
management processes
1) Conduct a thorough literature review to explore the available research work made in
regards to a- best practices for implementing project change management within the
construction industry and b- enhancing & automating the workflow of the project change
management processes
8
1.5. Thesis Structure
4.2.2.1. Chapter 1: Introduction:
This chapter presents an overview on the construction changes in general and how they affect
the baselines set for the different types of construction projects. An emphasis is given for
defining construction changes particularly in turnkey and design-build projects. This overview
is meant to emphasize the significance of improving the current change management systems.
4.2.2.2. Chapter 2: Literature Review:
This chapter aims to discuss and study the previous academic researches done with regards to
changes in general, and change management systems in particular. The gap found in the
literature review shall also be explained and discussed.
4.2.2.3. Chapter 3: Working Steps of Change Management System for EPC LSTK
Contractors:
This chapter discusses in detail the development of the proposed procedures, working steps,
and work flows of the CMS for Lump-Sum Turnkey “LSTK” projects.
4.2.2.4. Chapter 4: Development of the Web-based Change Control Management Toolkit
Subsequently, the developed working steps are then used to develop an online portal that
facilitates the CMS workflow, automates the work facilitation, data circulations and
notifications to the given stakeholders, and generation of data analysis reports. The model
architectural concept, detailed design, formatting, and interfaces of the model are thoroughly
demonstrated.
4.2.2.5. Chapter 5: Results & Discussions
Upon development, this chapter discusses the testing, and verification phases of the model,
which were carried out using complete system checks, and the quantitative assessment of a
number of construction experienced practitioners currently working for EPC LSTK
contractors.
9
Also, the model is validated and piloted by an EPC LSTK contractor that used it one of its
running EPC projects. Further, an endorsement was made by a construction expert with over
30 years of practical experience in the industry upon analyzing the WCCMT in terms of its
capabilities, functionalities, and readiness for implementation within the construction market.
4.2.2.6. Conclusion and Recommendations
This chapter will also conclude the conducted research as well as providing a number of
recommendations for future researches.
10
Chapter Two: LITERATURE REVIEW
2.1 Changes in the Construction Industry
Project changes are discerned as one of the key factors leading to delays and disruptions
in construction projects (Motawa et. al, 2006). It is almost certain that changes take place in
any construction project, being one of the most common features existing in construction
projects (Motawa et. al, 2006; Ming et. al, 2004). Immense deviations to the baseline time
schedule, direct and indirect budgeted costs, and original scope of works can be the
implications of the incurred project changes (Ibbs et al., 1998). A report has shown that,
worldwide, the impacts incurred due to post-contract design changes account for 5.1% to 7.6%
of the total project cost (Ibbs, 2012). Hence, project changes are one of the key concerns of
project management in the construction industry (Zhao et al., 2010; Lee, 2006). It is therefore
important to adapt a proper change management system to ensure an adequate level of control
of project changes; otherwise, severe consequences will result (Hwang and Low, 2012).
2.1.1. Defining Project Changes
Arain in 2008 defined project change as any alterations or adjustments made to the
contractual agreement between the Contractors and Owners.
Ibbs et al. (2001) considered project changes to be any omissions, additions, or modifications
to the scope of works or project goals either resulting in an increase or decrease to the project’s
baseline budget or time plan.
In the context of Engineering and design philosophy, change is an alteration or variation to the
drawings, function or form of the end product during the project’s lifecycle and after starting
the works (Stasis et al., 2013). Whereas in the context of the construction industry, change has
been defined as any modification or variation taking place during the project’s course that has
resulted in an impact to the time schedule, budget, quality or scope of the works (Stasis et al.,
2013).
11
Changes and deviations identified by any individual shall be conveyed by means of a Change
Request. A Change Request articulates a request made either by one of the authorized project
team participants or by a project party to its counterpart, namely from the Contractor to the
Owner or Project Manager, for authorizing and approving a certain change case (Stasis et al.,
2013).
Lee (2006) states that identified changes most likely are approved changes based on the
viability of these changes to the project, from the Client’s perspective, via the claim and change
management process. However, a rejected change can either be permanently rejected or to be
reconsidered as a later stage; the latter one is referred to as “latent change”. Latent changes are
reconsidered and reevaluated if it has been determined that there are no other alternatives but
to implement these changes. Latency may result in substantial impacts on the project and
maybe a source for legal disputes; also, it would be much more difficult to determine the root
causes of these changes and who is to be responsible for it.
Lee also argues that all project changes and errors basically have a common feature, which is
increasing the initial scope of works. Therefore, it could be integrated into one comprehensive
system.
Provided that variations take place throughout the course of the project’s lifecycle, it involves
multiple project members and participants (Stasis et al., 2013). Therefore, this necessitates
having an effective documentation, information circulation, communication processes to make
timely informed decisions regarding the identified changes (Stasis et al., 2013; Charoenngam
et al., 2003; Ibbs et al., 2001). The CMS aims to reduce the magnitude of changes with negative
implications, avoid or mitigate unnecessary ones, and exploit changes with positive
implications whereby the earlier the identification of changes process is carried out, the better
it is for the project’s overall performance; hence, the identification or initiation of project
changes during the design phase is the most efficient (Arain, 2008; Sun et al., 2006).
12
CMS is the integrated process of identifying, analyzing, authorizing, and controlling all
changes and deviations, be it from a technical or commercial point of views, as opposed to the
project’s baselines and contractual terms in terms of scope, time, and budget. The CMS is also,
and most importantly, associated with internal changes which have to be reimbursed by the
Contractor and allocated internally. In this context, CMS is the process of identifying,
documenting, monitoring and controlling all changes to the baselines as well as providing
lessons learned for continuous improvement of the contractor’s performance.
Given that changes are almost inevitable in all construction projects, studies have
recommended practitioners to adapt, handle, and take advantage of changes for the overall
benefit and interest of the project as much as practicable and to use the previous projects as
benchmarks for learning lessons and enhancing the forthcoming decisions (Ibbs et al., 2001;
Ibbs, 1997; Stasis et al., 2013).
Differentiating between Project Changes and Change Orders
It is apparent that the literature has been using ‘project changes’ or ‘variations’ and ‘change
orders’ or ‘variation orders’ interchangeably, the majority of researches used them without a
clear distinction between both terms. This is one of the setbacks in the academic literature as it
is indispensable to distinguish the differences. A project change is an alteration taking place in
a project that led to a deviation to any of the project baselines or objectives, the baseline time
schedule, baseline cost budget, baseline specification of the works, or original scope of works
(Keane et al., 2010). Such deviations do not necessarily have to activate the variation orders
and/or claims procedures mechanisms under the contracts, meaning that not all change impacts
have to be reimbursed from one entity to another. Depending on the contract terms, some
project changes will have to be absorbed internally by the Contractor. On the other hand, a
“Variation Order”, “Change Order”, “Contract Change Order” are all terms referring to the
official contractual document issued by the Owner to the Contractor authorizing a specific
variation or alteration to a part of the Works, scope, budget, and/or time schedule that becomes
13
a part of the contractual agreement between both parties (Keane et al., 2010). One of the main
characteristics of a Variation Order is that it is construed as a change that has been incurred
due to reasons beyond the Contractor’s scope of work or for which the Contractor is not
responsible of (Charoenngam et al., 2003). Hence, it is interpreted that all change events
resulting from the Contractor’s fault, or for which the Contractor is responsible of, will not be
captured through managing and controlling the Change Orders alone. There are two types of
Variation Orders or “Contract Change Orders (CCOs)”, the first one is the directed CCO where
the initiator is the Owner or Owner’s representative whereas the second type, the constructive
CCO, is the one initiated or identified by the Contractor or one of its sub-contractors regarding
a change case that is caused by the Owner or his representative and the Contractor is entitled
for pursuant to the Contract terms (Charoenngam et al. (2003)
2.1.2. Types of Changes
Several researches have been conducted to explore the different types of variations.
Motawa et al. (2006) argued that construction project changes are comprised of beneficial,
neutral, or disruptive changes. Ibbs et al. (2001) categorized project changes into beneficial and
detrimental changes whereby it is essential to promote for an environment that encourages
beneficial changes and discourages detrimental changes. Since some researches have argued
that certain changes could be beneficial for the project, Sun and Meng (2009) argued that
projects could benefit from proactive changes by determining the cost-benefit analysis of the
proposed changes.
Some researchers have classified changes into 3 main categories: design errors and omissions,
design variations, and unforeseen conditions (Ibbs, 1997; Diekmann and Nelson, 1985).
Charles et al. (2015) argued that there are two basic types of changes: proactive changes, and
reactive changes. Proactive changes are the ones proposed with the main purpose of enhancing
the completed facility’s performance to be even higher than the expected levels whereas
reactive changes are mainly executed to react to ‘reactive change causes’ such as remedying
14
engineering and design errors. Two case studies were conducted to investigate these two types
of changes and it was found out that out of the total cost overruns caused by variations were,
70% are attributed to reactive changes while 30% are attributed to proactive changes.
Lee (2006) emphasized the importance of identifying changes, deviations, and errors as early
as practicable so as to confront these changes with the proper decisions to minimize the impacts
on the project. In case these changes were not promptly identified and the works went on, but
were to be identified at a later stage, these changes are referred to as “latency”.
2.1.3. Causes of Changes
To be able to effectively and properly analyze and evaluate the identified changes, and
in order to have an integrated change control management, it is important to have a common
understanding of the root causes of the changes and their resulting effects on the project
outcomes (Arain, 2008).
Various factors contribute to project changes of which could be either caused by internal
aspects or external ones (Love et al., 2002). Internal factors are categorized into project related
issues, organizational issues, and stakeholders’ issues (Hwang and Low, 2012). Stakeholders
issues are one of the main aspects causing negative project changes as stakeholders, being
humans, make a lot of errors in form of engineering errors, omissions, inaccurate identification
of the scope of works, reworks and lack of workmanship on site (Hwang et al., 2009). As for
organizational issues, these issues include lack of proper channels of communication between
the different departments and disciplines within the firm as well as changes in the management
team which would cause disruptions to the project’s decisions (Hwang and Low, 2012). Project
related issues are mainly related to inaccurate estimation of the project’s budget, either due to
incorrect costing, inaccurate quantification of the works, or missing portions of the works,
deficiency in resources, and lack of proper project planning (Hwang and Low, 2012).
15
On the other hand, the external factors are comprised of any unforeseen events or circumstances
that might result in project delays and additional costs (Hwang and Low, 2012).
Several studies had been conducted to identify the causes of project changes. These causes
were usually attributed to 4 main categories: owner-related, contractors-related, consultants-
related, and other variations (Sertyesilisik and Ross, 2010). This categorization is clearly
oriented towards the traditional design-bid-build project delivery method where the three
principle parties exist and influence the occurrence of project changes. The causes of variations
initiated by the Owner included: Scope changes where the Owner decides to add, vary, or omit
a portion of the Works. This is mainly due to vague identification of the project’s scope at the
pre-execution phase (Arain et al., 2005), cash-flow problems, changing the project’s
specifications, and uninformed decision-making process (Sertyesilisik and Ross, 2010).
Regarding the consultant-related variations, the main causes were identified as: design changes,
errors and omissions, discrepancies among project documents, changes in technology (Arain
et al.,2005), inadequate knowledge of available materials and equipment in the market, and
therefore specifying materials that are not applicable or available and would ultimately be
changed during the execution, and unclear design details (Sertyesilisik and Ross, 2010). As
for changes initiated by the Contractor, the main causes were determined as: shortage of
resources, in terms of materials, equipment, and skilled labor (Sertyesilisik and Ross, 2010),
incidents occurring on site, differing site conditions, acceleration and deceleration of the works,
delays of long-lead items due to poor procurement management and coordination (Ibbs, 1997),
design errors, reworks, fluctuations in productivity levels, unresolved claims and disputes
(Stasis et al., 2013), and ineffective communication (Arain et al., 2004). Other variations were
primarily attributed to “force majeure” events. Force Majeure events are commonly known as
events that are fully beyond the control of both contractual parties, the Contractor and the
Owner, and could not have been foreseen by an experienced entity from the same industry;
such events include: exceptionally adverse weather conditions, unforeseen economic and
16
political conditions, change in regulations, and other unforeseen events falling beyond the
liabilities of both parties (Sertyesilisik and Ross, 2010).
Schedule slippages and cost overruns resulting from variations have been reported to incur
further efficiency losses to the overall project’s performance during the construction phase
(Stasis et al., 2013).
During the design phase, projects’ designs are usually set to be completed in unrealistic
durations, with a time buffer to coordinate and harmonize between the different project
deliverables. This buffer is usually consumed to compensate for the time loss instead of
merging between the project’s deliverables. As a result, the project’s documents would
ultimately be consisting of unadjusted documents that do not constitute a unique logic to the
form of the project (Hanod, 2012).
Table 1: Main Causes of Changes (Hanod, 2012)
It can be deduced from Table 1 that owner-initiated changes and incomplete or discrepant
project documents are the two most common sources for project variations.
A study has shown that the cost aspect is the dominant factor of the Change Orders between
the Contractor and the Client in the Egyptian market; in fact, 83% of the Change Orders are
related to cost variations (Anees et al, 2012). This means that the majority of change orders
17
drawn in the Egyptian market have implications on the project’s budget where only 13%
entitled the Contractor to extension of the project’s schedule.
Figure 1: Primary Driving Factors of Change Orders (Anees et al., 2012)
2.1.4. Effects of Changes
A number of researches have also studied the potential effects of project changes on the
project’s performance and different aspects. Studies have shown that project changes are one
of the key triggers for projects cost overruns and time slippages. Sun and Meng (2009) stated
that site reworks alone caused by project changes could lead to a cost overrun of 10-15% as
well as other negative impacts such as productivity inefficiency, and time loss.
Patrick et al. (2010) grouped the effects of changes to be attributed to 5 main elements: cost
impacts, time impacts, quality impacts, organizational impacts, and other impacts. They are
summarized in Table 2: Main Effects of Project Change (Patrick et al., 2010)
Table 2: Main Effects of Project Change (Patrick et al., 2010)
18
Uncontrolled and unidentified changes will not only have severe repercussions on the project’s
time schedule, and cost budget but will also result in scope creep, vague priorities, and
unknown needs (Mitropoulos and Tatum. 2000). It could also lead to numerous disputes
between the Contractor and Client (Anees et al., 2012). One of the most disrupting impacts of
detrimental changes on the project is the “ripple effect”. A study has shown that despite changes
were identified, analyzed, and evaluated prior to issuing the relevant Variation Order, it has
been found that the changes incur additional costs and disruptions other than what was
accounted for (Hanna, 2004). This effects account for additional costs associated with
disruptions and inefficiencies that when were viewed retrospectively were large in number and
magnitude that have resulted in additional repercussions (Lewis, 1999). Therefore, it is
essential that the Change Management System consider the ripple effect of the identified
changes so as to avoid any non-quantified impacts that would lead to unaccounted for
ramifications.
Ibbs, along with a pre-established taskforce from the Construction Industry Institute “CII”
(1997), studied the effects of changes to the scope by quantifying the impacts of this type of
changes on the project’s performance. The researcher focused on only changes related to the
scope aspect during the detailed design development and construction stages. Ibbs (1997) was
only focusing on changes related to change orders and claims that have either been issued or
should have been issued but absorbed by the Contractor. The taskforce team had collected the
data, of 104 projects from 35 companies, at specific progress milestones of both phases, the
design and construction.
The study has shown that productivity is significantly affected when changes take place.
Furthermore, as the amount of changes increase, the productivity decreases proportionally as
shown in Figure 2. However, the rate of decrease in productivity differs between the design
stage and the construction stage. It has been calculated that every additional 10% worth of
changes account for a 2.48% decrease in productivity during the design stage. Nevertheless,
19
the slope of the equation of the construction’s productivity is higher than that of the design
stage implying that changes have a more disruptive impact on the labor productivity of the
construction phase.
Figure 2: Project Changes Vs. Productivity during Design (Ibbs, 1997)
Figure 3: Project Changes Vs. Productivity during Construction (Ibbs, 1997)
The study has also shown that there is direct proportion between the total cost of the change
and the labor cost incurred to implement the change as shown in Figure 4 which depicts that
the implementation efficiency of the identified changes decreases as the value of changes
increase. Consequently, this means that as the magnitude of changes increases in a given
project, the site work efficiency decreases accordingly and, hence, the actual cost increases.
20
Such implication shall be considered when assessing the order of magnitude of changes prior
to implementation.
Figure 4: Change Implementation Efficiency (Ibbs, 1997)
As for Electrical and Mechanical type of projects, Hanna et al. (2002) studied the factors that
contribute to the impacts from the Change Orders and the findings suggest that the timing of
implementing the Change Orders was one of the key factors contributing to the quantified
impacts of these variations. This finding was endorsed by another research made on another
type of projects, namely heavy-road construction projects (Serag et al, 2010).
In Egypt, it was reported that Change Orders had contributed to an average of 15% schedule
overruns to the baseline time plan and an average of 13% cost overruns (Anees et al, 2012).
2.2 Integration Management
Given the complexity and the extensive variety of needed specializations of the
construction industry, construction projects tend to be delivered with a significant degree of
fragmentation (Mitropoulos and Tatum, 2000). This fragmentation enables construction
entities to take advantage of the developed skills acquired by its individuals to deliver its
projects successfully. This results in a variation of knowledge and objectives between the
21
organization’s individuals. Therefore, these specialized individuals, namely technical
positions, would most likely not be aware of the repercussions of their decisions on other
aspects of the project, in terms of time, budget, and quality plans. This unawareness contributes
to changes and conflicts to the project’s baselines; therefore, there is a need for a vigorous
coordination between the different team members by providing a mutual platform or tool
between all team members to ensure an effective performance (Mitropoulos and Tatum, 2000).
In this context, several researches have concluded that projects experience a severe lack of
performance due to the fragmentation of the processes and works between different
stakeholders (Harper, 2014; Demirkesen and Ozorhon, 2017).
So therefore, the concept of Integration management has emerged and is seen as coordination
and merging between these fragmentations in order to enhance the overall project performance
so it is noted as one of the most vital components of project management (Demirkesen and
Ozorhon, 2017; Ospina-Alvardo et al., 2016).
Integration management is deemed as one of the most important components of construction
project management where it combines all features and areas of project management in order
to tackle the project’s dimensions, namely time, cost, quality, safety, and client satisfaction
(Demirkesen and Ozorhon, 2017).
It maintains the needed coordination between the different project activities. PMI has
emphasized the importance of Integration Management in the Project Management Body of
Knowledge Guide “PMBoK” making it the first in the list of the ten knowledge areas of project
management whereby it was stated that it includes the merging and coordination of the different
processes entailed in the remaining knowledge areas (PMI, 2013).
Also, as cited from other studies, successful management, control, and handling of project
claims is one of the essential elements to enhancing project’s performance (Demirkesen and
Ozorhon, 2017). Given the interdependencies between change management and claim
management, this means that effective change management within the organization itself is
22
indispensable to have a functional claim management to assert the Contractor’s or Owner’s
rights for any sort of relief, as the case may be.
Demirkesen and Ozorhon (2017) have investigated the effects of integration management on
the project’s overall performance according to specific indicators. The research has determined
that “integration of changes” is one of the key components of Integration management. It
defined the integration of changes as an element that the proper identification and evaluation
of all project changes as well as handling them in a timely manner so as to control the impacts
of these changes and incorporating them in the project’s scope and deliverables as well as
updating the project management plan. It shows that construction companies have reported that
the key to a solid project integration management is the proper implementation of change
integration management.
Figure 5 shows that it construed as essential to implement the change management system
throughout all construction phases starting from the conception phase up to the close-out of the
project.
Figure 5: Proposal for Change Management Implementation during Construction Phases (Demirkesen and Ozorhon,
2017)
2.3 Change Management Systems in the Construction Industry
Since changes are very common, it is of paramount importance to identify, handle, and
take advantage of these changes so as to ensure a sustainable and successful growth (Ibbs et
al., 2001). The importance of effectively managing and controlling project changes in a timely
manner has been emphasized by several researchers (Ibbs et al., 2001; Anees et al., 2012; Arain,
2008; Chen et al., 2015). A study in Croatia has shown that 70% of the cases where the projects
23
had exceeded the project’s budget and time plans was attributed to unauthorized changes being
executed without a proper assessment of the consequences in a project (Nahod, 2012). Change
Management, in its essence, aims to identify changes that have already taken place, predict
potential and inevitable changes, plan corrective and preventive measures, as well as
controlling changes throughout the project’s duration so as to minimize the impacts and the
number of changes that may will have negative repercussions on the project (Zhao et al., 2010).
Also, change management evaluates and assesses the effect of changes on the project in terms
of cost, time, and quality aspects. A number of institutes and researchers have developed best
practices for change management systems to be used in construction projects where they are
considered among one of the most important systems among other project management best
practices (Motawa et al., 2006). There are numerous factors affecting the overall effectiveness
of these systems such as the project size, contract type, project type, project complexity (Hwang
and Low, 2011). Accordingly, it is essential to have a certain level of change management
being full force and effect in all construction projects where the level of control shall be
increased as the complexity of the project increases as well as the project’s needs and
objectives.
To first understand the status of the change management implementation in the Construction
industry and its performance, Hwang and Low (2012) conducted a study on change
management systems in the Singaporean market. The findings have identified that only 10%
of heavy industrial projects implement a change management system as opposed to 38% of
building projects and 14% of infrastructure projects. This finding depicts the lack of having
any level of change management system in heavy industrial projects, despite its complexity,
which ultimately leads to scope creep, cost overruns, and project delays. Derived from this
analysis, Hwang and Low (2012) formulated the key barriers and benefits to implementing
change management systems. The main barriers were: resisting the status quo and comfort with
current systems, scale of projects, time consumption, and cost of implementation, whereas the
24
key benefits were: prompt response to identified changes, time saving, cost saving, overall
project risk reduction, and productivity improvements.
Ibbs et al. (2001) had recommended to formulate and initiate the project Change Management
System “CMS” prior to commencing the project so as to proactively manage changes from the
beginning.
Furthermore, regarding Change Orders, the enhancement of the change management system of
the Change Orders process between the Contractor and Client is believed to reduce the risk of
cost overruns, schedule delays, and will lead to a trustful relationship between the parties (Al-
Dubaisi, 2000).
Few construction institutes have published best practice guidelines for change management
systems in construction projects. The most common practice guidelines in use are the ones
published by the Construction Industry Institute “CII”, Project Management Institute “PMI”,
and Construction Industry Research and Information Association “CIRIA”.
2.3.1. Change Management Systems Best Practices
In 1994, the CII has prepared a comprehensive change management system. The CMS is
comprised of two hierarchal layers, or levels, where the first one is the basic principles of the
CMS whereas the second one is the more detailed processes of each principle to be incorporated
in the system, or the management processes, as shown in Figure 6. The CII has provided the
particulars of only these first two levels whereas the third and fourth layers, of which they entail
the detailed system procedures and the working steps respectively, are left for Contractors and
Owners to prepare them in order to adapt the CMS to properly fit in their projects’ unique
characteristics and needs. The first layer is founded on 5 basic principles:
1. Promoting a balanced change culture
2. Change identification
3. Change evaluation
4. Change implementation
25
5. Continuous improvements from lessons learned
Figure 6: Change Management System (Ibbs et al., 2001)
Ibbs et al. (2001) has discussed the CII CMS in detail with an emphasis on the first level and
demonstrating the second level of the system. It is important to note that these 5 principles must
be interacting with each other to ensure an effective usage and optimization of the system. In
case a new project is found to have similar characteristics and features of other projects that
have implemented the CMS, the lessons learned and conclusions are ought to be used for the
new project, to minimize the potential additional costs and delays in a systematic and effective
way.
26
Proper and thorough decision-making process is of paramount importance as it is not only
included in each of the basic 5 principles but also might affect or impact other inter-related
activities taking place in the project. In order to make this process effective, this necessitates
having a robust communication and documentation system.
2.3.1.1.Promoting a Balanced Change Culture
This is the first principle of the CMS where the Change Management team shall first make sure
that the team members could differentiate between the two types of changes, detrimental and
beneficial changes. Detrimental changes are the ones that have negative impacts on the
project’s baselines in a way or another whereas beneficial changes are the one that would either
have positive impacts on the project’s baselines or would optimize one of the project’s aspects.
The team should be encouraged to determine beneficial changes and to reduce the possibility
of detrimental changes as much as practicable. The project management and change
management team should enforce the mindset of determining beneficial changes to ensure a
positive environment and platform that would contribute to the project success. The beneficial
changes do not necessarily have to result in a significant saving to the project but might shield
the remaining activities of the project from unexpected losses. As shown in Figure 7, it is also
important to establish the project’s baselines by developing the following aspects:
Project goals and objectives
Baseline time schedule, cost plan, and scope of works.
Roles and responsibilities of the project management plan in general and the CMS
in particular.
Change management manager and team, if needed.
Review/approval process of the identified change cases.
Authorized reviewers and approvers board of the CMS
Contract strategy
These aspects, among others, should be well communicated to all project team members.
27
Figure 7: Promote Balanced Change Culture (Ibbs et al., 2001)
2.3.1.2.Change Identification/ Recognizing
Under this principle, all team members are jointly responsible to identify and recognize
potential and incurred changes at the earliest time possible. Communication channels are very
important to be effectively in force between the team participants. Upon identification, the
change should be categorized either as “elective” or as “required”. Required changes are
compulsory whereas elective changes are left the project management team to decide at their
28
discretion whether to proceed with their implementation or seek other alternatives.
Nevertheless, as shown in Figure 8 all identified changes must be properly assessed in terms
of their impacts on all aspects of the established project baselines. Also, all identified changes
are to be documented in the CMS log stating their current statuses as well as obtained data.
Figure 8: Change Identification/Recognizing (Ibbs et al., 2001)
2.3.1.3.Change Evaluation
The change evaluation principle is a continuation of the change identification stage whereby
the management team, namely the change management and project management team
29
respectively, gives its decision on whether the change case is approved and to be implemented.
The decision making process is of the essence and is a critical step in the CMS (Arain, 2008).
If in the change identification process the change was determined to be of a high criticality, the
management shall expedite the approval process and shall determine the appropriate funds to
finance the identified change since any delays could cause further repercussions. However, if
it was determined that time is not of the essence for the change case, the management should
thoroughly investigate the viability of the change and try to explore other alternatives to select
the most optimum strategy. The main objective is to minimize any losses and negative impacts
on the project and maximize the gains using the flowchart presented in Figure 10 where it
shows all activities and aspects to be covered at this stage. As for elective changes, the
management team shall only approve the implementation of such cases only if it was found
that the benefits exceed the costs. This analysis could be done via the benefit-to-cost (B/C)
ratio as an indication of the difference between both figures to assist in the approval process.
The later the elective change is proposed, the higher the B/C ratio as opposed to the elective
changes proposed at earlier stages due to the unanticipated cost impacts associated with late
changes. Figure 9 illustrates the required B/C ratio for elective changes of the different stages
of the project. In case a detrimental change was completely avoided or the negative impacts
were either avoided or converted into positive ones, the B/C would yield to a much higher ratio
since the cost and time impacts would not increase consecutively in the project. This stage also
highlights the criticality of having an adequate communication and documentation
management system.
30
Figure 9: B/C Ratio for Elective Changes (Ibbs et al., 2001)
However, in all cases, the project management team shall ensure that all necessary data are
obtained, analyzed, and all impacts are identified in order to take the appropriate decisions.
Figure 10: Change Evaluation (Ibbs et al., 2001)
31
2.3.1.4.Change Implementation
Ibbs et al. (2001) perceive this principle as a critical stage to the system, being the essence of
why there is a need for a change management system in the first place. In this principle, the
Project Manager should give his decision regarding the change case either by approving or
rejecting it after taking into account all analyses and evaluations conducted. This, of course,
comes after all team members have checked, verified, and inserted their inputs to the pending
change. Subsequently, after approving the change comes the implementation monitoring
activity where it requires monitoring the implementation process, as well as overcoming other
barriers and obstacles encountered thus far. It is critical that there is an adequate level of
documentation and recording of the actual impacts so as to be presented as an evidence when
resolving any disputes related to the change case or any of its impacts; also, it can serve for the
lessons learned stage of the system.
Figure 11: Change Implementation (Ibbs et al., 2001)Figure 11 shows the different processes
to be accomplished at this stage where the final approval, implementation monitoring,
documentation and recording of the implementation occur.
2.3.1.5.Lessons Learned
The last principle of the CMS is the lessons learned stage where the essence of it is about
learning from all errors and mistakes as well as circumstances that were the driving causes of
the identified changes. Under this principle, it requires the conduction of root cause analyses
in order to reach a systematic approach for pre-empting the occurrence of these changes in the
future as well as upcoming projects. Upon completing the analysis, a discussion workshop
should be made to present the prepared analysis amongst the team members so that they could
comprehend the mistakes and errors that were done that have caused these changes and the
consequences these changes have led to. It also serves to having a proactive environment within
the organization that would avoid the recurrence of these impacts, being one of the dominant
features of the CMS. These principles should be carried out throughout the project’s lifecycle.
32
Figure 12 demonstrates the importance of developing an action plan to tackle the identified
lessons such as adding measurements to the project’s measurement system, updating the CMS
processes, and updating the project’s risk register. This stage holds various benefits to the CMS
of upcoming similar projects whereby the lessons learned will act as a decision support system
to the management team through the knowledge base acquired from the past learned lessons.
This will mitigate the possibility of the recurrence of detrimental changes in the future as well
as guiding the project team to proactively identify potential changes and select the proper
control measures.
33
Figure 11: Change Implementation (Ibbs et al., 2001)
34
Figure 12: Lessons Learned (Ibbs et al., 2001)
The CII formed a benchmark assessment form for evaluating the implementation of the system,
as shown in Table 3: CII Benchmark Assessment Form (CII, 2011), for the purpose of obtaining
a performance score. This score is an indication for the level of implementation for future
improvements and detecting the weaknesses of the system.
35
Table 3: CII Benchmark Assessment Form (CII, 2011)
Arain (2008) developed a Knowledge-Based Decision Support System “KBDSS” through
adapting the five main principles of the CII CMS discussed hereinabove. The author
emphasized the importance of utilizing the lessons learned from the past projects for early
identification of the potential changes in the instigating projects. As shown in Figure 13, the
research has developed the system with an emphasis on the importance of communication,
tracking, and documentation of the CMS throughout the cycle of the system. The knowledge
base should also be updated with the variations of the current project along with their related
36
data, such as frequency of changes, time and cost impacts and the like, to strengthen the support
system. The Knowledge base consisted of 4 main layers:
Macro layer that contains the general data and information of the projects of which the
data were collected, such as: project name, project duration, date of completion,
contract value, number and frequency of variation orders, etc. The data could be filtered
using a set of rules so as to present only the data the user is seeking.
Micro layer that contains detailed information about the stored variations and variation
orders, such as: causes and effects of variations, type of variations, and cost and time
impacts. Using the query form, the user could select multiple filters in order to have a
summary of the most frequent causes of changes, most frequent types for a set of
specific parameters.
The effects and controls layer that included data of the incurred impacts and the selected
control measures with regards to the causes of variation orders. It will be updated once
new ones are identified and inserted into the knowledge base.
Lastly, the control shell is the last interface of the system that proposes a list of control
measures to be adapted for the identified variations by linking the shell with the effects
and controls layer of the knowledge base.
This decision support system lacks any detailed particulars of how the proposed control
measures are to be implemented. For the sake of clarity, one of the control measures stated
in the system for design discrepancies is the freezing design; it does not entail what, when,
and how exactly this measure could be implemented. Moreover, given that this system is
exclusively developed for a particular program that contains a set of repetitive and similar
projects, namely educational buildings in Singapore, the concept of this system shall only
be applicable in case of having a specific program containing similar projects; otherwise,
the control shell would not be useful.
37
Figure 13: KBDSS CMS (Arain, 2008)
2.3.2. Importance of Documentation and Communication Systems
Researchers have emphasized the importance of having sufficient records of the impacts
incurred due to changes, particularly the ones related to the site works since it was determined
38
that the majority of contractors cannot possibly evaluate the incurred additional costs until the
end of the project due to lack of sufficient records and supporting document (Moselhi et
al.,1991). Furthermore, the volume of change related documents such: Contract Change
Requests “CCRs”, RFIs, Change Reports “CRs”, and Contract Change Orders “CCOs” are
immense. Thus, Arain (2008), Zhao et al. (2010) and Karimidorabati et al. (2016) highlighted
the significance of developing effective communication and documentation systems
exclusively for the implementation of the CMS such that proper control and management of
such flow of information would result in a better performing change management.
2.4 Change Management Systems Using Information Technology
A number of researches were carried out to formulate toolkits for project change
management systems. These researches are varying in terms of complexity as they include
simple toolkits that identify the change steps to more thorough ones that are involved with the
workflows, documentation and databases, as well as subsystems. Some of these researches
have been concerned with developing different IT systems for change management. Most of
these systems rather focus on providing decision support tools for managing the project
changes, based on the database acquired either from previous projects or previous variations
within the same project, for a particular type of projects. In addition, some studies were made
to exploit the internet and web technology platforms for the purpose of developing change
orders management systems between the principle project parties.
2.4.1. Database Management System “DBMS”, Workflow, Workflow Engine, Process,
and Cloud Computing
A process is a series of sequential tasks and activities that must be executed to accomplish a
specified objective (Karimidorabati, 2014). A workflow comprises of a series of sequential
actions that has a starting point and an end point based on a set of rules and restrictions, which
is most commonly outlined using flowcharts and process flow diagrams as graphical
representations (Karimidorabati, 2014). These workflows involve interactions and circulation
39
of information among the task owners to complete these activities (Muir, 2013). In this context,
a workflow engine is a computer tool that enforces the workflow and facilitates the execution
of the workflow events. It has three main functions: 1) Verifying a change in the current
workflow state, 2) verifying the user’s authority to carry out the workflow task, and 3) assessing
the validation script (Karimidorabati, 2014). For instance, in the context of the change request,
the user cannot change the change status from being under review to being approved unless
authorized to do so through the workflow engine.
A DBMS is the management system that records and manages this volume of data being shared
amongst the different users or recorded on one of the CMS reports or forms (Karimidorabati,
2014).
Cloud computing is a notion for all applications serviced using the Internet (Kumar and Cheng,
2010). These applications are used to move towards having paperless systems which is
advantageous to the Construction industry and holds a significant potential to having timely
information sharing which would lead to informed decisions in projects. Change Management
is one of these areas that could benefit from the cloud computing in construction projects since
immense amounts of change documents are moving back and forth among the stakeholders.
2.4.2. Levels of Automation of Change Management Systems
The majority of the current CMS in the Construction industry heavily rely on human discipline
and actions; since these systems either are paper-based, depending on hardcopies and faxes for
data circulation, or e-mail based, relying on softcopies in PDF format and emails for data
circulation among team members (Karimidorabati et al., 2016).
The first generation of the CMS “GEN 1” is the conventional approach of the management
system that is entirely paper-based relying on faxes and physical circulation of the hardcopies
of the change-related documents.
The second generation “GEN 2” is a more advanced approach in which e-mails are used to
circulate the soft copies and scanned copies of the change documents as well as their supporting
40
documents. Further, the system’s log is formed using spreadsheets to record all relevant data
of these changes. The key advantage of this generation is the zero-time needed for documents
transfer as well as the ease of access to these documents from different computer devices.
However, the risks of redelivery of documents, intractability of circulated data, reworks,
miscommunication, repeated data entry, and misinformation will most likely take place in both
generations where the second generation could reduce such risk but without avoiding it.
Furthermore, in both generations, the change log is updated manually which could be subjected
to rework due to wrong data entry and delayed updates. Therefore, these two generations are
referred to as “loose processes” where the tasks to be carried out are not well defined
(Karimidorabati et al., 2016).
Hence, the third generation “GEN 3” aims to mitigate and eliminate the aforesaid deficiencies
by having an automated workflow process. It merges between the different IT technologies,
namely the internet, workflow engines, database management systems “DBMS”, and web-
based software applications. A common platform, namely the web browser, will act as a central
pool of workflows and processes pertaining to the CMS among all project participants, as
shown in Figure 14. The workflow engine is responsible for transferring the change reports
and files from one participant to the other. Upon completing each task, the DBMS will be
updated automatically and will update the change log accordingly.
Karimidorabati et al. (2016) compared between the performance of GEN 3 versus the first two
generations based on accuracy of circulated data and compliance. The study showed that GEN
3 substantially enhanced the accuracy of data, timely traceability of the status of identified
changes and approximately 21% reduction of the overall cycle as opposed to the other two
generations.
41
Figure 14: Stakeholders Interaction in CMS GEN 3 (Karimidorabati et al., 2016)
Over the past years, the Internet Technology, or the Internet of Things “IoT”, has been
discerned as a platform that with a vast potential for the construction industry (Charoenngam
et al., 2003). This technology can deliver a communication, documentation, and record-keeping
platform either between different project parties or between different project team participants
within a single organization for a specific project. This shall positively impact the performance
of construction projects since short-term benefits could be visible in terms of reduced repetition
of data entry, reducing errors and misinformation in project documents, a centralized database,
reducing paperwork, and therefore, reducing the overall efforts, time consumption, and cost of
the projects (Weippert et al., 2002).
Within the context of change management, there are numerous change orders management
systems that are commercially available in the market; however, these applications are
primarily focused only on controlling and managing the Change Orders, let alone the fact that
these applications are costly. Some of the web-based applications are eSUB’s change order
system, Procore Change Management System, and VPO Change Management system, and
Coreworx which are all based on the same concept whereby change orders and change requests
could be archived, requested, checked, reviewed, and issued among the principle project parties
using virtual interactions from anywhere. These applications are designed to be accessed via
42
different types of electronic devices, computer devices, mobile devices, or tablets. The end
users could also attach any type of document to the system. One of the interesting features these
applications have is the time-out concept where the creator could set a specific duration for the
issued document to be reviewed and returned back to the creator. Yet again, these applications
are focused on change orders and facilitating the data flow, communication and data
management systems for contractual changes between the Contractors and Owners, or
Contractors and their lower-tier subcontractors. Therefore, the development and research fields
have not yet given an emphasis to the internal project change management system for the
Contractor’s usage to control its own deviations during the execution of the projects.
As cited from Charoenngam et al. (2003), there are other change orders management systems
available in the market such as Primavera Expedition, and Citadon. Charoenngam et al. (2003)
stated the 2 key components for developing an efficient, change management system are proper
documentation and effective communication and circulation of data which could be
accomplished using the Internet technology that would provide timely information mechanism
in an accurate manner that could be accessed from various locations at any time. Coreworx is
viewed as the most comprehensive application tool available in the market exclusively
developed for the oil and gas types of construction projects. It has various interfaces to cover
all cycles of the CMS.
2.4.3. Toolkits and Applications for Improving CMS Performance
Charoenngam et al. (2003) developed a web-based toolkit for managing change orders among
the principle project parties. The research recognized the complexity of the Change Order
process and the immense amounts of information and data that need to be circulated among
various individuals to be checked, reviewed, requested, approved or rejected; these issues were
tackled by developing this toolkit using the Internet Technology. The toolkit has adapted the
variation order processes entailed in the 4th edition of the FIDIC forms of contracts, without
specifying which book of the FIDIC forms, and the 6th edition of the Institution of Civil
43
Engineers “ICE” forms of contracts. The toolkit was designed following the main steps: 1-
System analysis, 2- System design, and 3- System implementation. System analysis is focused
on recognizing the needs and the requirements to develop the toolkit. System design entails the
design philosophy, the system’s concept, and how the system can be established using the
computer format. The system implementation is the programming works and activities to turn
the system into an actual application software. The main objectives were facilitating the
Change Orders transactions between project parties, structuring a proper database management
system for managing change orders, establishing the change order procedures according to the
aforementioned form of contracts which would aid project members who are not acquainted
with these procedures, and application practicality. The toolkit targeted 4 main users, the
Owner, the Engineer, the Contractor, and the Sub-contractor. Derived from the analysis, the
role for each of the 4 users was outlined as shown in Figure 15. The toolkit also used the time-
out concept mentioned before using the durations stipulated in the Contracts to determine the
number of days given to submit and review the Change Orders. These roles were governed by
a set of rules incorporated in the system; for example, the Change Order request is only
presented to the Owner for final approval only if the Engineer has evaluated the merits of the
request and given his approval. The Owner will be also informed via email for any requests or
approvals made on the system, however, any formal actions could only be taken by the
Engineer. The same goes between the Contractor and its Subcontractor where only the
Contractor take actions on the system. If the Subcontractor believes he is entitled for a Variation
Order to its scope of works, it can be done through regular correspondence to the Contractor.
44
Figure 15: Change Order Management System Diagram (Charoenngam et al., 2003)
To model the toolkit, the “use cases” method was used where it lists the actions and interactions
between the system users and the system itself to ensure the system’s integration. Using this
method, the model comprised of 3 main subsystems: 1- Change order subsystem, 2- Request
for Information subsystem, and 3- Document management subsystem. The first subsystem is
concerned with the different forms associated with Change Orders, namely approved Change
Orders, Change Orders Cost Proposal, Change Orders Request, Notice to Proceed for approved
Change Orders, as well as the correspondences and clarifications made between the Contractor
and the Engineer regarding the Change Orders. This subsystem was built on two main
scenarios, one for the directed Change Orders, and the other for the constructive Change
Orders. The Request for Information “RFI” subsystem handles and facilitates the circulation
of information for the RFIs. The documentation management subsystem is associated with all
contemporary records needed for the quantification and evaluation of Change Orders such as,
interim schedule reports, photographic images, and Purchase Orders. From these subsystems,
a set of objects were identified and for each object, a set of requirements and data are
established. For instance, for the Change Order request document, Table 4: Data Requirements
for Change Order Requests “COR” (Charoenngam et al., 2003) entails data requirements for
45
the system. As shown, one of the needed inputs is the work breakdown structure number which
is essential for the database of the system in order to allocate the stated impacts to the
designated activity. This will help in the filtering process of the system’s log so that the project
participants could have all changes occurred for a specific activity or work package.
Table 4: Data Requirements for Change Order Requests “COR” (Charoenngam et al., 2003)
The system was developed using Microsoft Access as a database management system and
Structure Query Language “SQL” to handle the stored data in Microsoft Access whereas the
programming of the system was done by employing Active Server Pages (ASP) Visual
Interdev. A comparison was made between the developed web-based toolkit and the
conventional method (GEN 2) of the Change Order management system and the author has
estimated that the conventional method would consume 12 working days to complete the
Change Order cycle whereas the web-based toolkit would only consume 6 working days. Other
benefits of developing a web-based toolkit were having a centralized database system which
46
would avoid any loss or mismanagement of information, data, or documents, reducing the
project’s overall cost since the efforts and time consumed are minimized, and facilitating a
proper communication platform. However, there are some activities that must be done which
is not provided by the system such as actual negotiations and agreements between the parties.
Furthermore, one of the system’s limitations is that the participants must regularly check the
system for any new documents since it lacks any notifications to the users whenever any new
information or data is placed or inserted.
Chen et al. (2015) had developed a holistic web project-based change management “WPCM”
system for managing, controlling, and facilitating the changes in information to enable the
principle project parties (Contractor, Suppliers, and Subcontractors) to receive and share any
variations in the information and data of the construction projects. The system aimed to exploit
the advantages of the web technologies to enable project participants to enhance the decision-
making process regarding change management and control. The study divided change
management into 5 phases: identifying changes, confirming changes, notifying changes,
implementing changes, and change closure. This definition is similar to the one developed by
the CII but with an emphasis to the notification and verification of the identified change cases
which is seen as essential to having a proper CMS. The proposed system identified the change
roles as follows: change initiator, change stakeholder, change coordinator, change manager,
and change approver. The definition of each role is entailed in Table 5: WPCM Change Roles
(Chen et al., 2015).
Table 5: WPCM Change Roles (Chen et al., 2015)
As for the framework of the WPCM, it aims to collect the relevant data and information related
to the identified change case, determines the change stakeholders and their roles regarding the
47
change and allocates the impacts with respect to the relevant change breakdown structure as
shown in Figure 16. All data are then archived and documented in the system’s database. The
system is developed using a web portal so as to facilitate and share all inserted inputs and
information to all project participants. This portal will act as an online communication channel
by providing a record sheet where authorized users can log the succeeding pending action to
complete the change management's cycle. Once the data are updated on the server, automated
emails are sent by the system to the Contractor’s project manager as well as the change
stakeholders. One of the other advantages of using a web portal is the authentications and
access control mechanisms where it determines the authorized users that can only access
information on the system based on their privileges, so the Contractor can control which
information could be shown to other authorized users.
Figure 17 shows the WPCM system steps to control project changes. It can be noticed that the
change approval stage comes during the implementation phase. This is a setback of the system
as it is deemed as a reactive approach instead of a proactive one since these changes could have
been avoided or substituted with a less adverse one especially if the change is elective. The
approval step should involve the approval or rejection of the change case so as to determine
whether the change is to be implemented in the first place.
48
Figure 16: WPCM Framework (Chen et al., 2015)
Five modules have been developed to satisfy the system’s requirements and needs: a change
edit, change history, change tracking, an alerting setup, and online change report. Change edit
module enables users to submit new change cases or edit old ones. The module prevents
unauthorized users from inserting or retrieving information or data they are not allowed to. A
certain user, namely the Contractor Project Manager, is given the ultimate accessible authority
to act as the ultimate manager of the system. The change history module is a generation of the
complete history and data related to the change process. These data include uploaded files in
PDF formats as well as downloading these files. The tracking module aims to provide users a
platform to monitor identified change events by tracking the progress or delivery conditions of
critical events. The alert setup module creates an alert system to let users determine how the
changed events impact the project’s progress. It also aims to enable authorized users to get
alerted and notified whenever a change stakeholder or change manager inserts or updates the
49
status of the change case. The online change report encompasses all formulated analyses in a
single form to be circulated among the project participants.
Furthermore, a number of researches have been developed to explore the potential integration
between the Building Information Modeling “BIM” and change management. This integration
is seen as necessary since BIM is of mandatory use in some construction markets and projects
and its potential for automation is ideal for enhancing the project’s change management system.
Langroodi and Staub-French (2012) studied the change management process in the design and
construction phases using the available BIM tools for a fast-track project. It recognized the
change characteristics using BIM tools to manage project changes. Liu et al. (2014) formulated
an integrated framework for incorporating the change management system into BIM. The
framework has four main stages: analyzing the flow, change review and approval, foundation
update, and BIM server update. This framework aims to automate the capturing and
incorporating changes on the BIM models.
A decision support system for educational building projects in Singapore was developed for
managing project changes by founding it on two main components: a knowledge-base which
is acquired from the data of similar past projects, and a controls selection tool to assist the
Project Managers in taking the proper decisions and to minimize the impacts of changes on the
project (Arain, 2008).
50
Figure 17: WPCM Steps (Chen et al., 2015)
Pena- Mora and Li (2001) have developed the Dynamic planning and control methodology
“DPM” that incorporates existing tools and application in an integrated dynamic mechanism
to maintain flexible utilization of a project’s constraints and variables. The DPM is specifically
developed for fast-track design-build projects to provide a mechanism that could help absorb
project changes with minimal disruptions to the project schedule. It consists of four layers: 1)
strategic core, 2) tactical core, 3) operational layer, 4) interface layer. System Dynamics, and
51
GERT technique, were used as tools for the model development. However, in order for this
mechanism to be practically used, the change management process must be thoroughly
developed for each project; this was criticized by Hanod (2012) as it would require high levels
of efforts and costs to develop unique change management processes that are only applicable
for a specific project.
Motawa et al. (2006) aimed to provide an integration between the change identification systems
and the simulating systems of the unforeseen impacts caused by changes. This was done by
formulating a general change process model and developing a computer model that predicts
the impact of the identified changes as well as the probability of occurrence using the fuzzy
logic technique. The prediction system consists of two main functions where the first one is to
determine the level of stability of the scope of works while the second one is to establish the
potential iterations to take place while implementing the identified changes within the scope of
works. The term “stability” was derived from the solidness of the defined scope of works such
that a high stability depicts only a small number of changes is expected or anticipated at a given
project and vice versa. Prior to developing that system, a basic change process model was
formed which was divided into four main stages: Starting up, identification and evaluation,
approval, and post-change. These sub-processes are mainly tackling the change process
between the Contractor and the Client where the approval and post change processes are
specifically tackling the Client’s approval and dispute resolution methods in case the
apportionment of the identified changes were disputed. It also denotes that there might be
several iterative cycle with respect to a single change case; these iterations may increase the
uncertainties and complexities of the resulting effects. The prediction system was then
developed for the purpose of taking actions proactively to diminish the effects of changes. The
system has also followed the Dynamic Planning and Control Methodology “DPM”. This model
has been viewed as a useful mechanism to deploy proactive control strategies to the identified
changes and for later changes, the reactive control strategies could also be employed using the
52
same tool (Stasis et al., 2013). This system, despite being an integrated model, is only
addressing the identified changes that would only potentially result in requesting a Change
Order or, in other words, an approval from the Client. Also, as the paper has demonstrated at
the end, the system requires realistic implementation using actual data from different types of
projects, since the simulations of a number of variables between the change causes, effects, and
factors that needs to be validated and tested, implying that this remains as a conceptual system
that has not been tested to fit in the construction market.
Sun et al. (2006) stated that there is an apparent gap in the literature to provide practical and
industrial standards for project change management and control processes and procedures to
the Construction field. Sun et al. (2006) built on the previous work done to develop a toolkit
that is founded on two main components: the knowledge component, and the support
component. This toolkit was described as a holistic change management system to the
construction industry (Stasis et al., 2013).
53
Figure 18: Basic Change Process Model (Motawa et al., 2006)
Isaac and Navon (2009) developed a graph-based application that identifies the potential
impacts of potential changes prior to their implementation, during the design and planning
phase. The model identifies the links between client’s requirements that are defined into the
54
model at the beginning of the project and building design features by applying requirement
traceability.
Anees et al. (2012) had studied the efficiency of the change management systems, the causes
and effects of project changes in the Egyptian construction markets by distributing a
questionnaire among different Egyptian entities and analyzing the Change Orders process
between the Contractors and Clients. They identified changes as being referred to as “Change
Orders”. To test the efficiency of the change management system, the study selected 4 projects;
these projects were all greenfield projects (new construction projects not revamping, extending,
or adding to existing facilities) and had a re-measured contract type. However, it did not specify
the project delivery method adopted by these projects which means that the efficiency of the
systems was analyzed using the same parameters disregarding whether it is a turnkey project,
design-bid-build project, or otherwise.
Again, this study, among others, is alluding that the change management systems are only
targeting the changes emerging from the Change Orders between the Client and Contractors,
depicting that if the Change Orders are well handled and controlled, this would ultimately lead
to an effective change management system. Nonetheless, it does point out to a remarkable
conclusion, which is the fact the majority of Change Orders are only approved by agreeing on
a negotiated fixed price. This means that, while the efforts made to develop Change Order
Management Systems between the project parties are well-acknowledged and is a step forward
towards project integration management, these systems are not very effective in the practical
field since the majority of Change Orders are only issued after a cycle of negotiations,
meetings, exhaustive verbal communications, and going back and forth until both parties reach
satisfactory figures and values to the impacts outlined in the Change Orders, be it time and/or
cost impacts. However, this is not the case with the CMS implemented within the Contractor’s
organization itself since it does not need any negotiations because there is no counterpart to
negotiate with; instead, the CMS is focused on identifying, analyzing, implementing, and
55
controlling the project changes whether they are internal changes or external ones that need to
be claimed from another contractual party.
2.5 Turn-key Projects
Even though turnkey and design/build projects place considerable amount of risks and
responsibilities on the Contractor, they are viewed as one of the very effective mechanisms of
maintaining an integration between the design and construction phases (Mitropoulos and
Tatum, 2000). The involvement of the contractor in the early stages of the design process is
effective and would have positive impacts on the overall project’s success in terms of value
engineering, constructability of the developed design, and selecting the latest and state-of-the-
art construction materials and specifications. However, it requires significant coordination and
integration between the different disciplines and participants within the organization.
Furthermore, provided that turnkey projects are accompanied with a lot of uncertainties and
interdependencies between the tasks, turnkey projects require immense amounts of information
being circulated between the different decision makers in order to come up with the optimum
decisions and achieve the targeted levels of performance (Mitropoulos and Tatum, 2000). The
decision maker has to consider all the affected sub-activities and involve the task owners of
these activities in the decision-making process. So as cited by previous studies, Mitropoulos
and Tatum (2000) state that, as task uncertainties are increased, organizations have two possible
solutions to enhance the decision-making process and determining the optimum actions to be
taken: a- information systems, and b- lateral solutions. Regarding the information systems, past
researchers have focused on developing IT tools that assist decision makers in predicting the
optimum problem-solving strategy. However, for issues that are not measurable, group
decision-making platforms are deemed as more efficient. Therefore, there needs to be an
integrator that collates and assemble all different information and data into a single view to
take the appropriate decision and come up with the best course of action (Mitropoulos and
Tatum, 2000).
56
When Ibbs (1997) collected the data from different types of contracting strategy to study the
quantitative impacts of changes on projects, it was found that 52% of the Design-build projects
were carried out using the lump sum type of contracts.
57
Chapter Three: WORKING STEPS OF CHANGE
MANAGEMENT SYSTEM FOR EPC LSTK CONTRACTORS
This chapter entails the methodology followed to develop the framework of the CMS,
proposed procedures, and working steps to be followed by EPC LSTK Contractors, in
accordance with the CII best practices guidelines.
Hence, this stage was formulated upon conducting a thorough literature review and obtaining
practical feedback from construction experts with their recommendations particularly
regarding the data and parameters that should be incorporated in the CMS. Furthermore, a
practical observation and participation were conducted by the author for a total period of 24
months in one of the LSTK projects in Egypt for an EPC Contractor.
The CMS is following the Change Management System best practice proposed by the CII, as
discussed in Chapter 2. The CII have identified levels 1 and 2 of the system so this paper shall
identify and develop level 3, being the CMS procedures, as well as level 4, being the CMS
working steps. The proposed system also follows a number of recommendations provided by
the PMI for the implementation of an integrated change control system.
3.1 CMS Identification
3.1.1. CMS Mission
The aim of this system is to capture and identify all potential as well as incurred
changes, analyze the required or alternate actions, quantify the net resulting impacts, and
update the project’s deliverables and plans effectively and systematically. This system shall
enhance the Contractor’s management capability in taking early decisions of dealing with
project’s changes and deviations as well as allocating the adequate resources in minimizing
detrimental changes and exploiting beneficial ones.
58
3.1.2. Definitions
The following terms are used interchangeably in this Chapter; the definitions thereof
have been determined based on the literature review and aforementioned practical experience:
a- Change Request: A Change Request “CR” is an official application to modify any
deliverable, baseline, or document. The request initiator could be any member of the
Contractor’s team who has identified a deviation that is believed to have an impact on
one of the baseline pillars. This form acts as the first step towards implementing the
CMS process. Upon approval of a Change Request, a Change Report shall be prepared
to conduct further analysis and investigation of the case and to carry out the remaining
CMS process tasks. This form is an internal form that is only viewed within the
Contractor’s organization.
b- Change Report: The Change Report contains a detailed data about the identified change
depicting the required actions, quantified cost and time impacts, and all related
information pertaining to the change. It also incorporates the communication cycle of
approvals and rejections of that change case to determine whether the change is to be
implemented and incorporated in the project’s plan. This form is for internal use only
and is not necessarily to be related to external variations – change events caused by
external parties.
c- Contract Change Request “CCR”: It is the official written application submitted by the
Contractor to the Client requesting or proposing a variation to the Works, either as a
result of a request from the Client or identified by the Contractor itself, with a rough
estimation of the potential impacts on the project. This should be submitted in case the
Change Request stipulates that the contractual party to be charged is the Client. This
form can also be used to apply for contractual variations with other contractual parties
59
such as the Subcontractors, and Suppliers, whereby the Contractor, in these cases, takes
over the role of the Client.
d- Contract Change Order “CCO” or Variation Order “VO”: Upon obtaining the Client’s
approval of the CCR, the Contractor shall prepare and submit a draft of the CCO/VO
so that it could be issued by the Client to the Contractor certifying a variation to the
works. The CCO/VO shall contain all necessary information and data in a clear and
concise manner to specify the varied items and corresponding impacts on the project.
e- Project Claims: A project claim is the only legal means of asserting the Contractor’s
rights to a relief or compensation to the incurred damages, in terms of time delay and
additional costs, resulting from an event to attributable to the Contractor. These claims
may arise out of events as a result of the Client’s rejection of a constructive CCR or as
a result of events that are not specified under the variations events of the Contract but
is an excusable or compensable one for which the Contractor is not responsible
nonetheless.
f- Perform Integrated Change Control: This control process is developed by the PMI in
conjunction with the project’s integration management so as to review all change
requests, approve changes, as well as managing changes to the project documents,
deliverables, organizational process, and Project Management Plan.
3.1.3. Project Change Control Manager Role
Once the project has been awarded to the Contractor, the Project Change Control Manager
“PCCM” in conjunction with the Project Contracts Manager have the duty to thoroughly study
the contract agreement made with the Client to identify the following particulars:
60
1- Variation procedures between the Contractor and the Client.
2- Change events of which the Contractor is entitled for a compensation for all impacts
arising out of them and should be dealt with through a CCO.
3- Claims procedures between the Contractor and the Client
4- Ambiguities and discrepancies within the Contract that could potentially lead to
deviations and changes to the project baselines.
The PCCM shall establish the CMS procedures and change management plan to be included
in the Project Management Plan.
The PCCM is the overall accountable individual for controlling the implementation of the CMS
processes.
For all identified change cases, the PCCM shall conduct a thorough investigation of the case
so as to establish the causations and effects of the case. The PCCM shall also have the authority
to requesting the team members in justifying the deviations and changes detected in order to
minimize the impacts as practicable.
3.1.4. System Description
The CMS process includes all change control activities, starting from the setting up of the
system processes up to the lessons learned and data analyses of captured changes. Figure 19
illustrates the general process to be carried out by the Contractor for implementing the system.
Figure 19: CMS Processes
61
3.1.5. Establishing project’s baselines
According to the PMI (2013), the Contractor shall form the Project Management Plan
“PMP” which acts as the point of reference to all deviations detected throughout the course of
the project; it shall be formed according to the following aspects:
Contract agreement between the Contractor and the Client
Baseline time schedule
Baseline cost budget
Baseline scope of works
Baseline design philosophy and project specifications
Each of these aspects should be well identified at the initiation phase of the project so that the
Contractor has the capability of judging the identified changes. The time schedule and cost
budget should be broken down to the activity level. For each set of activities, an individual, of
the project team, shall be assigned as the accountable person for detecting any deviations that
might occur to any of its activities.
The management team shall ensure that each member is aware of the scope and responsibilities
in relation to the assigned activities. For instance, the civil engineering team is responsible for
reporting and justifying any variations in the civil works quantities and/or design with respect
to the baseline BOQ and design specifications while the superior site engineer is responsible
for reporting and justifying any reworks or idle times taking place on site.
3.1.6. Setup Project CMS
The first step is to formulate the project-specific CMS that is customized to the parameters
and characteristics of the project. Once the CMS working steps are established, the Project
Change Control Manager “PCCM” shall ensure that all project stakeholders are fully
acquainted with the CMS process. The setup phase should be carried out at the beginning of
the project’s execution. The activities associated with this stage are the following:
Assigning the roles and responsibilities of project stakeholders
Defining the interfaces between the different roles
62
Setting out the level of authorities for changes
Conducting seminars and workshops for CMS to the project team
Setting out the workflow and working steps between the project team with regards the
CMS
Each project participant is responsible for detecting any changes in the assigned particular
scope of work and shall ensure that these changes are promptly reported to the PCCM once
identified, either via informing the superior line manager or, to the PCCM directly. The project
participants should be informed of the potential changes that could possibly have an effect on
the project baseline/s. If one of the project’s management team (Project Manager, PCCM,
Construction Manager, Engineering Manager, and/or Procurement Manager) confirms that an
identified change case could have possible effects on one of the baselines, namely the time
schedule, cost budget, engineering design, or scope of works, a corresponding CR shall be
prepared.
3.1.7. Changes to baseline
Once a potential change is recognized in the change log, the change case should
undergo the Integrated Change Control activities as illustrated in the CMS Development
section of this report. Through the CMS workflow, all data and information related to this case
shall be gathered, the change case should then be evaluated, analyzed, quantified, to be in
readiness for the Project’s Manager decision.
During the evaluation process, the PCCM has to categorize the case as an internal change or
an external change from a contractual standpoint. If determined as an external change and
associated impacts shall be reimbursed by the Client or other contractual parties, upon
approving the Change Request, the PCCM shall inform the Project Claims Manager about the
identified case to follow the contractual procedures for variations or claims, depending on the
nature of the case. Upon approval, the Project Management Plan shall be updated with the new
change’s effects.
63
3.1.8. Change Control Processes and Lessons Learned
Upon formulating the PMP, the Contractor shall start carrying out the change control and
lessons learned processes forthwith, as discussed herein below.
The processes and workflows have been graphically represented using the Business Process
Model and Notation “BPMN”. Being a standardized common language, BPMN is a tool that
is easily comprehended by all different stakeholders (Shapiro, 2011 as cited by Karimidorabati
(2014)). Microsoft Visio has been used as a drawing tool to develop the PFDs and flowcharts
since it already embeds the BPMN.
3.2 CMS Development
For the purpose of clarity, Table 6 compiles all of the acronyms used in this section, whether
included in the figures or the content, along with their meanings:
Table 6: Used Acronyms & Their Meanings
A
M
CR
Change Request form
PCCM
Project Change Control Manager
PM
Project Manager
CPM
Commercial Project Manager
PCA
Project Contract Administration Manager
CCR
Contract Change Request
VO
Variation Order
MTO
Material Take-Off
BOQ
Bill of Quantities
Qty(s)
Quantity/Quantities
CM
Construction Manager
PPM
Project Procurement Manager
In order to develop the system, the following aspects have to be considered:
64
1- Understanding the characteristics of EPC projects and their impacts on controlling
project changes, as discussed in Chapter 2.
2- Identifying the change control processes
3- Defining the roles and responsibilities of the project stakeholders
4- Formulating the detailed working steps following the different change case scenarios
The CMS shall be developed in accordance with the CII guidelines, discussed in the Chapter
2, whereby the change management processes are divided into 5 main stages: CMS formulation
and promoting a balanced change culture within the project team, identifying/initiating a
change case, evaluating change, implementing change, and lessons learned and continuous
improvement. Some of the guidelines outlined by the PMI were also adopted.
3.2.1. Stage 1: CMS Formulation and Promoting a Balanced Change Culture
This stage shall be executed once the project is awarded to the Contractor and the team
is assigned. The results of this stage are monitored and maintained throughout the project’s
execution through a series of steps. Figure 20 depicts the process map and steps that shall be
carried out with respect to this stage. The PCCM is the accountable individual to monitor the
implementation of this process tasks.
The project controlling structure shall be composed of segregated categories: a) cost
controlling, b) time controlling, c) quality controlling, d) risk controlling as well as e) change
controlling. The PCCM shall conduct change management workshops with the Engineering,
Procurement, Site, and Project Management teams to convey the importance and values of
implementing beneficial changes and diminishing detrimental changes.
65
Figure 20: Process Map for CMS Stage 1
The primary objective of this stage is to have a well-defined project baseline from which all
deviations will be identified and measured. The first task is to develop the PMP where the
baseline time schedule, cost plan, and scope of works for the EPC phases are developed and
identified.
Despite the aim of capturing all deviations from these established baselines, it is onerous,
throughout the project’s execution, to set out a control eye for each work item of the project,
that would capture all types of changes from their set baselines, irrespective of the magnitude
of impact, and handle each one of them as a separate change case through the CMS particularly
as the complexity of the project increases.
Therefore, using these baselines, the controlling team shall obtain the level of criticality for all
work items. This would assist the controlling team as well as the accountable individuals to set
their priorities in terms of the urgency of identifying the deviations of the work items from their
time and cost baselines.
C T / A Sessions for the EPC T
Present Viability & Importance of CMS Encourage Beneficial, Discourage Detrimental Changes
T Unaddressed Lessons Learned
Determine C/B for Implementing Elective Changes Incorporate Applicable Lessons Learned
S U Project-Specific CMS
Procedures & Working Steps PCCM/CCB Identification Establish Roles & Responsibilities for
CMS Stakeholders Action Plan to Ensure CMS
Effectiveness
P Managemen P
Establish Project Baselines (BL Time Schedule,
Cost Plan, & Scope of Works)
Identify critical scope elements (Risk
Management, Pareto’s law, Longest/ Critical
Paths) Identify Budget & Activity Owners
66
Nevertheless, these criteria shall not be followed in case of any scope deviations. Any
deviations or changes from the original scope of works, shall be qualified as a change case
through the CMS. This aims to avoid any risks associated with scope deviations that could
potentially lead to scope creep.
Further, during the design development stage, any deviations detected by the Engineering team
must be captured as a change case and reported to the PCCM. This is to ensure a proactive
CMS implementation whereby such deviations are tackled at the early stages of the project.
The risk management system also serves as a source of information for the CMS. The Risk
Control Manager shall be responsible for reporting any identified risks that are most likely to
occur or have been already incurred so as to be captured via the CMS.
The subsequent step is to identify the accountable individuals. Table 7: Accountable
Individuals Identification demonstrates the proposed accountable individuals for each of the
cost packages. The accountable individual shall be responsible for informing the project
controlling team with any deviations in the Estimate at Completion “EAC” cost, or forecasted
time slippages, of any of the items. Considering the nature of EPC projects where the
Procurement and Construction activities are carried out concurrently with the design
development stage, the Engineering team formulates the Bill of Quantities “BOQs” and
Material Take-Offs “MTOs” for the Procurement and Construction items based on preliminary
estimation of quantities with a low accuracy level when the design work is still under
development. This level of accuracy increases as the design package develops and,
subsequently, the estimated quantities vary. Therefore, the Engineering team is also responsible
for updating the Controlling team with any deviations in quantities on a regular basis which
will, subsequently, update the EAC for the Procurement and Construction items.
67
Table 7: Accountable Individuals Identification
W Category
C Packag
A I
Engineering
Engineering’s Team Man-hours and all
associated services (such as: consultants fees,
outsourced activities, and the like)
Engineering Manager, and Lead
Engineers (for each corresponding
discipline)
Procurement
Engineering
Procurement’s Team Man-hours
Procurement Manager
Procurement
Expediting
Materials Works, including materials prices,
expediting, inspections, shipping, and
transporting to site
Procurement Manager/ Engineering
Manager
Construction
Engineering
Site Team Man-hours
Construction Manager/ Engineering
Manager
Construction Site
Management
Construction Works including manpower,
equipment, construction consumables, and
construction materials
Construction Manager / Engineering
Manager
Project
Management
Project Management and Project Controlling
Man-hours
Project Controlling Manager
The man-hours stated above shall be converted to cost unit when multiplied by their
corresponding fixed unit rates.
The PM should then assign the PCCM of the Project. Depending on the complexity of the
Project, and following the PMI guidelines, the PM may decide to form a Change Control Board
“CCB” to be responsible for the implementation of the CMS whereby the PCCM will act as
the head of the CCB. The PCCM shall formulate the project-specific CMS procedures and
working steps and shall distribute these particulars among all team members for
implementation. The PCCM shall also recognize the roles and responsibilities of each of the
CMS stakeholders. Table 8 represents the main roles and responsibilities of the project team.
68
Table 8: CMS Roles and Responsibilities Matrix
The PCCM shall conduct a workshop with the bidding team to study and investigate the lessons
learned obtained from the CMS of the previous projects and develop a list of the unconsidered
lessons and their relevancy to the current project. Using this list, the PCCM, with the assistance
of the technical teams, should categorize the unconsidered lessons learned to detrimental,
beneficial and whether they are elective or required. Based on this categorization, the project
team shall decide on the lessons that should be qualified as change cases for further analysis to
decide if these lessons will be considered and incorporated in the PMP.
Furthermore, the PCCM shall ensure that this balanced culture is sustained throughout the
course of the project. This could be done through the weekly change control meeting, which
shall be discussed later, where the PCCM should recognize the team members that have
J Category
P
R and Responsibilities
I /
I
R
V
Case
E /
Q
A /
R
T
I
All
Project Team
Member
X
Engineering
Lead Engineer
X
X
Engineering
Manager
X
X
X
X
Procurement
Lead Engineer
X
X
Procurement
Manager
X
X
X
X
Construction
Lead Site Engineer
X
Construction
Manager
X
X
X
X
Controlling
Scheduling Manager
X
X
X
Cost Manager
X
X
X
Reviewers/
Approvers
PCCM
X
X
X
X
X
Commercial
Manager
X
X
X
Project Manager
X
X
X
69
successfully identified and proposed beneficial changes that later were approved by the PM.
Another proposal is to set a financial incentive scheme for the team members who successfully
propose applicable beneficial changes.
3.2.2. Stage 2: Change Initiation/ Identification
As soon as the Contractor commences the project execution phase, the project team
members shall start carrying out the activities and tasks assigned to them. All team members
have a shared responsibility of identifying any potential deviations to the project’s baselines.
As soon as a team member identifies a particular case where it could potentially lead to a
change to the baselines, the team member shall be obliged to report such case to the responsible
superior in the project team. All potential changes shall be reported, regardless of its cause and
without taking into consideration the magnitude of effects these changes may result in. Upon
receiving a detected change case, the responsible superior shall study the case and determine
whether it is an actual deviation to the planned set of work, this should be done in conjunction
with the PCCM to decide on how to proceed with filling in the Change Request “CR”.
The CR is the official means of identifying and/or initiating all change cases of the project,
which shall then be evaluated by the PCCM to determine if this qualifies as a Change case.
The Scope Manager shall check the CR and sign it off to be submitted to the PCCM.
The CR provides the PCCM with an overview on the case and presents a set of data the case
that shall enable the PCCM to thoroughly study the contained data, and set for a meeting with
the reporting personnel in case more data or elaboration is needed. Subsequently, the PCCM
shall determine if this change qualifies as a change case, being an actual change to one or more
of the project’s baselines, and needs to be evaluated and controlled through the CMS.
For the purpose of understanding the sources of where the deviations could potentially come
from in EPC projects, Table 9 demonstrates a sample of events that could potentially take place
in an EPC project, which is not conclusive but they are outlined for guidance following the
conducted literature review:
70
Table 9: Sample of Possible Change Events in EPC Projects
C
C Ev
Engineering
1. Design and engineering errors
2. Incomplete or inaccurate formulation of the engineering estimates during the bidding
phase
3. Variations in scope
4. Changes in the estimated quantities of the BOQs and MTOs
5. Inefficiency of the manpower undertaking the engineering activities
6. Revisions of Engineering documents that were not taken into account during the
tendering phase
7. Client’s instructions
8. Delay in issuing the Engineering deliverables as scheduled
9. Change in design philosophy
10. Missing inputs from the preliminary engineering works during bidding
Procurement
1. Changes in materials costs, either price increase or decrease
2. Variations in scope
3. Material delays due to extensive unaccounted for custom clearances procedures and time
durations
4. Acceleration costs of delivering materials to recover project’s delay (i.e. air freight)
5. Changes in fuel price
6. Client’s instructions/variations
7. Changes in carrying and order costs of materials – procurement team additional man-
hours
8. Inaccurate basis of estimation of materials during tendering phase
Construction
1. Idle time of resources (manpower and/or equipment) on site
2. Execution of additional quantities on site other than what had been estimated in the
project’s baselines
3. Damages/Shortage of materials on site
4. Ripple effect of variations on construction direct costs
5. Client’s variations
6. Changes in sequence of works OR changing the relationships between activities in the
time schedule
7. Shifting of milestones
8. Prolongation costs
9. Recovery measures (i.e. overtime and night work shifts)
10. Productivity inefficiency
Scope Deviations
All scope deviations must be qualified as change cases even if, in the opinion of the initiator,
it would not affect the project’s time and/or cost baselines. The following flowcharts represent
the working steps and process flow designed for the possible scenarios of change initiations
(by Engineering, Procurement, Construction, or the Controlling or Project Management team).
71
A- Engineering Change Initiation
In the event that the Engineering team initiates a change case, the process flow outlined in
Figure 21 shall be followed. The Lead Engineer together with the Engineering Manager “EM”
shall first verify if this change affects any of the issued engineering documents, in such case, a
CR shall be prepared and issued to the PCCM. If not, the EM shall check if this case has
affected or could potentially affect any of the cost accounts or activities in terms of their set
baselines; if a potential impact is identified, a CR shall be prepared. If the PCCM approves the
CR, the case must be investigated, impacts must be quantified, and causations and effects must
be established via the Change Report. The Engineering team must prepare a Bill of Quantities
“BOQ” for all additional quantities of work items to be performed on site as well as a Material
Take-Off “MTO” for all additional quantities of materials to be procured to the site. All other
supporting documents such as design drawings, technical specifications, or any other
calculations must also be prepared and sent to the PCCM. Subsequently, the Construction
Manager “CM” and Project Procurement Manager “PPM” shall estimate the Order of
Magnitude of the additional activities derived from the BOQ and MTO. If these lists include
additional un-priced items, the tendering team shall be involved to provide estimated rates for
those items or the controlling team shall formulate the rates based on the actual costs in case
the change has already been implemented. The PCCM shall also investigate if the change case
would result in any disruptions to the progress of works on site that were not accounted for
such as affecting labor productivity or idle times to the assigned resources as discussed by Ibbs
(2001).
72
Team Member
Identifies/
initiates a change
case
Reports to his/her
Lead Engineer
Lead Engineer
Identifies/initiates
a change case
Start here Or here
Change to frozen engineering
documents?
Design
Development
No
Lead Engineer:
i) checks with
Engineering Manager
ii) fills in the Change
Request form
Yes
Additional Materials to be purchase, Add. Qtys to
be executed, and/or disruptions to works on site?
Engineering Team submits new
MTOs & BOQs & Procurement
Manager & Construction Manager
to estimate order of magnitude
Yes
Controlling team to
review, analyze &
verify time and/or cost
impacts considering all
aspects
Cost/time
Impact?
Yes
Implement
Change
No
PCCM approves
change?
Change Rejected No
Engineering
Manager to estimate
additional man-
hours needed
No
Change Report
Approved?
External
Change?
Yes Yes
No
Change Log is updated
& team is notified of
rejection No
Change Log is
updated & team is
notified of acceptance.
Implementation to be
tracked
Yes Internal/
External?
Contract Variation
procedures are followed
External
EndInternal
Contract Manager
is informed
Figure 21: Engineering Change Initiation PFD
B- Procurement Change Initiation
In case a change is initiated or identified by the Procurement team, the process flow dictated
in Figure 22 shall be followed. The PCCM shall not only investigate the impacts incurred with
regards to the Procurement activities but also the Engineering and Construction ones as
indicated in the foregoing figure. If the case has an impact on the project time schedule and the
delay analysis has shown that the additional materials would result in a deferment to the
73
project’s critical construction activities or would incur additional costs on site due to
unavailability of materials, idle time of resources, mobilization and demobilization costs, and
the like, the team shall seek alternative solutions to minimize the disruption to the works such
as transporting the imported materials by Airfreight.
C- Construction Change Initiation
If a change case, in connection with the construction works, constitutes additional
engineering and technical activities, the additional man-hours to be consumed by the
Engineering team must be calculated. Affected Procurement activities must also be analyzed.
Figure 23Figure 23: Construction Change Initiation PFD outlines the workflow to be followed
for construction change cases.
74
Team Member
Identifies/
initiates a change
case
Reports to his/her
Lead Engineer
Lead Engineer
Identifies/initiates
a change case
Start here Or here
Change to Ordered Qtys?
Identify Order
of Magnitude
No
Lead Engineer
prepares the CR
& PPM to check
Yes
Technical Change?
Engineering Team to estimate
additional man-hours needed
Yes
Control team to
review, analyze &
verify time and/or
cost impacts
Cost/time
Impact?
Yes
Implement
Change
No
PCCM approves
change?
Change Rejected No
PPM to estimate
Order of
Magnitude of
Add. Materials
No
Change Report
Approved?
To
Reimbursed by
Client?
Yes Approved by
PM?
Yes
No
Change is rejected
No
Yes
Change Log is updated
& users are notified of
rejection No
Change Log is
updated & users are
notified of acceptance.
Implementation to be
tracked
Yes Internal/
External?
CCR/Claim is prepared and
sent to Client for Approval
Client
End
Internal
Add. Qtys and/or
Disruption to works on
site?
Construction Team
to estimate Order of
Magnitude
Yes
No
PCA is involved
in the loop
Initiate a Change
Report
Prepare & Submit VO/
Claim to Counterpart
Subcontractor/ Supplier
Figure 22: Procurement Change Initiation PFD
75
Site Team
Member
Identifies/
initiates a change
case
Reports to his/her
Lead Engineer
Lead Engineer
Identifies/initiates
a change case
Start here Or here
Lead Engineer prepares
CR & CPM to check
Technical Change?
Engineering Team to estimate
additional man-hours needed
Yes
Control team to
review, analyze &
verify time and/or
cost impacts
PCCM approves
change?
Change Rejected No
CM to estimate
Order of
Magnitude of
Change
No
Change Report
Approved?
To
Reimbursed by
Client?
Yes Approved by
PM?
Yes
No
Change is rejected
No
Yes
Change Log is updated
& users are notified of
rejection No
Change Log is
updated & users are
notified of acceptance.
Implementation to be
tracked
Yes Internal/
External?
CCR/Claim is prepared and
sent to Client for Approval
Client
End
Internal
Add. Materials to be
purchased by PPM?
Procurement Team
to estimate Order of
Magnitude
Yes
No Prepare & Submit VO/ Claim
to Counterpart
Subcontractor/Supplier
Figure 23: Construction Change Initiation PFD
Time and Cost Deviations
For changes that are not necessarily captured as deviations from the baseline Scope of
Works but rather time and cost slippages/savings are determined/foreseen, such cases shall be
identified by the Controlling or Project Management teams. However, as it is largely
anticipated that numerous cost items as well as schedule activities will incur deviations from
76
their set baselines, a threshold must be established to determine the level of urgency for
analyzing such deviations.
In this context, from the cost perspective, the cost controlling team shall prioritize the cost
elements by adopting Pareto’s law, in which case it would depict that by controlling the top
20% of the WBS elements, it would yield to 80% of the desired CMS results (Hardy, 2010).
Using this concept, if at any time, the cost controlling team have identified a deviation in any
of the highest 20% cost items, by comparing the Estimate At Completion “EAC” value against
the baseline value, a change request shall be prepared and submitted to the PCCM. The highest
20% cost items shall be regarded as “critical cost items” whereas the remaining 80% are “non-
critical cost items”. The categorization of which could be changed by the PM during the
execution depending on the changes encountered to the budget values.
As for time slippages, the scheduling team must, at a regular basis, identify the schedule’s
critical path. The team should identify the activities lying on the updated schedule’s critical
path to determine any potential changes; the critical activities are the ones with not available
float and any deferment of the end dates shall defer the project’s completion date accordingly.
For incurred changes, in the event where the updated schedule has shown that the project’s
completion date is deferred, the scheduling team must prepare a CR capturing this deviation
for further analysis by the scheduling team along with the PCCM. Furthermore, for non-critical
time activities or cost elements, a threshold criterion must be established where any potential
or incurred deviations exceeding such threshold must be qualified as a change case for further
analysis. Figure 24 illustrates The PFD demonstrating the time and cost controlling criteria
with regards to the CMS identification process. Hence, Pareto’s law will be followed for the
cost baseline’s deviations whereas the longest path will be followed for the baseline schedule’s
deviations using the Critical Path Method “CPM”. Any deviations detected in these critical
items shall be qualified to the CMS implementation right away; the initiation should either be
carried out by the controlling team or by the corresponding technical discipline.
77
On the other hand, the scheduling team shall monitor the status of the other non-critical
activities and, if deemed required, the deviations of which shall be analyzed through the CM
process. The objective of analyzing non-critical deviations is to conduct a thorough analysis of
why such deviations have occurred in the first place to be formed as lessons learned so as to be
avoided in future projects.
However, in case the incurred/potential deviations on non-critical cost items, individually, were
estimated to be more than 2% of the total project’s budget, or in the event that deviations on
near-critical paths or non-critical paths are forecasted to decrease their overall time float to be
less than 3 Calendar Days, then a Change Request must be prepared and submitted to the
PCCM. These figures are unfixed and the PCCM could decide to establish different threshold
values for the project depending on the given factors. In all cases, it is important to establish
this threshold so as to ensure the CMS effectiveness.
78
Controlling Team
Monitoring
Project
Performance
Cost Controlling
Identifies EAC>BL
Budget
Critical Cost Item(s) ?
Prepare CR
Yes Critical Activities?
Scheduling Identifies
time slippage
Yes
Variance >2% of
Budget?
No
Total Float <3 CD?
No
YesYes
To be
studied Later
To be
studied Later
PCCM
Approves?
Prepare Change
Report
Change is Rejected.
Alternative to be
studied
Order of Magnitude
to be Calculated/
Estimated
PCCM Determines
Root Causes &
Consequential
Impacts
Change Report
Approved?
Change Log is updated
& users are notified of
rejection
Change Log is
updated & users are
notified of acceptance.
Implementation to be
tracked
Internal/
External? EndInternal
No
Yes
CCR is filled and sent to
Client for Approval
Client
Prepare & Submit VO/
Claim to Counterpart
Subcontractor/Supplier
Figure 24: Controlling Team Change Initiation PFD
An action plan shall also be developed to ensure that the CMS will be effectively implemented.
For non-critical items, it shall be monitored by the controlling team during the implementation
process to ensure that the accountable individual would submit a CR regarding such deviation
at a later pre-determined stage.
3.2.3. Stage 3: Change Evaluation
If the PCCM reviews the change case specified in the CR and determined that this
qualifies as a change case, the PCCM shall approve the CR and informs the change initiator.
79
Upon approval of the CR, the PCCM shall start preparing the Change Report. The Change
Report contains more detailed information and data regarding the case, namely a detailed
breakdown of all associated impacts. The Change Report shall be prepared in close co-
operation with the Lead Engineers and technical disciplines for the purpose of ensuring that
the associated consequences are incorporated in the evaluation process.
The PCCM may convene a meeting with the affected disciplines, including the Engineering,
Procurement, and Construction teams as may be viewed necessary, to discuss the change case
and collect the needed data for evaluating the impacts.
An action plan shall also be prepared to formulate all required actions for the evaluation of the
impacts. These actions include the cost estimate of new work items, conducting a delay analysis
for the affected schedule activities, communicating with the suppliers or subcontractors to
gather the necessary data including delivery times of materials and costs of additional works.
The PCCM shall also determine whether this case is required or elective. If elective, then a
discussion shall be conducted with the team so as to identify the viability of this case by
formulating the B/C ratio. If the PCCM in conjunction with the PM have determined that the
elected change is not viable, the change case shall be rejected and the Change Report shall be
closed; the project team has to be informed with such action.
In case of detrimental changes, the PCCM should also discuss with the project team the possible
means of avoiding this change, or diminishing the impacts. The PCCM shall make sure that
negative impacts are minimized as much as practicable and that the net impacts are the ones
that cannot be avoided, given the particulars of the case.
When all consequences are ascertained and verified, the technical departments along with the
controlling team (Planning and Cost controlling team) shall start estimating and calculating the
cost and time impacts.
However, internal works resulting from the change case shall not be commenced unless the CR
is approved. As for all external works, including but not limited to issuing purchase orders,
80
variation orders to subcontractors or suppliers, and services provided by external parties, shall
not be executed unless the Change Report has been approved.
For external changes, the Contract Manager must be involved in the evaluation process so as
to be proactively aware of the case and to request other needed information or substantiation
for the preparation of the relevant CCR, Claim, or VO.
In addition, for external changes, the CCR could be prepared concurrently with the preparation
of the Change Report depending on the urgency and criticality of the time limitations for
submitting the CCR to the Client. In case the claim or CCR is disputed by the counterpart, the
PM may decide to proceed with the implementation of the change; in that case, the PM shall
inform the PCCM with such decision and the Change Report to be approved accordingly. Once
the claim is settled, a new revision of the Change Report shall be prepared.
On the other hand, for internal changes, the PCCM along with the controlling team shall
determine the cost accounts that are going to be affected by the change. If the affected cost
accounts have an EAC value less than the estimated baseline value, in other words there are
cost savings, then these cost accounts shall absorb the additional impacts. If there are overruns
within these accounts, the contingency accounts or other cost accounts having potential savings
shall be checked to cover for these impacts so that a part of the budget is to be shifted to cover
for the overrun accounts. As for the time impact, the PCCM and the planning manager shall
analyze the time impact and formulate a recovery plan, if possible, to overcome any impacts
on the time schedule. The recovery plan could include changing the sequence of works,
increasing manpower, and working overtime. In any case, all costs associated with such
recovery measures should be incorporated in the cost breakdown of the Change Report. The
ripple effect of all changes collectively shall also be considered during the evaluation process
as secondary impacts incurred in connection with the change case. Figure 25 illustrates the
process flow of the change evaluation stage.
81
Start Preparing
Change Report
Required or
Elective
Calculate B/C Ratio Elected
Change is
Viable?
Change is rejected No Find all means
possible to minimize
impacts
Required
Approve Change &
inform team Quantify all net
impacts including
ripple effect & time
recovery costs
Determine cost
allocations & cost
accounts to cover
for deviations
Change is
Approved?
Change is rejected.
Team is informed No
Internal/
External?
Yes
Change is approved.
To be implemented Internal
CCR/Claim
Accepted?
External
Yes
PM decides to
proceed?
No
Yes
Change is rejected.
Team is informed
No
Figure 25: Change Evaluation PFD
82
3.2.4. Stage 4: Change Implementation
Once the PM decides on the case, the PCCM shall forward the Change Report to all
project team members affected by this change, specifying whether this change has been
approved or rejected.
If the case is approved by the PM, the PCCM shall forward the approved Change Report to the
Controlling team, the planning and cost controlling team, as well as all affected technical
disciplines.
Rejected changes are archived in the database as rejected and shall neither be implemented nor
executed and the initiator and involved disciplines shall be informed.
If the case is approved, the affected disciplines shall incorporate the change into their plan and
start the implementation process. The Scope Managers (Engineering, Procurement, and
Construction Managers) are responsible for ensuring that all project team members are
informed about the approved change and carry out the corresponding works effectively.
The PCCM shall monitor the implementation of the approved change cases and collect all
associated actual data with regards to the actual impacts on the project’s baselines resulting
from the approved cases. These data shall be collected in order to verify the estimated impacts
in the Change Report and, if it had been detected that there is deviation between the actual
impacts and the estimated ones, the PCCM shall record such information in an updated revision
of the Change Report. This updated revision shall go through the approval/ rejection cycle
mentioned above.
3.2.5. Stage 5: Lessons Learned and Continuous Improvement
3.2.5.1. Reporting
For proper alignment of the project team with the CMS progress and current status, it is
recommended that the PCCM presents the status of the identified change cases on both, a
weekly and a monthly basis throughout the project’s duration.
Weekly Reporting
83
The PCCM shall present to the project team the status and the performance of the CMS on a
weekly basis via the following meetings:
Weekly project coordination meeting, chaired by the PM or the Project Coordinator
Weekly change control meeting chaired by the PCCM
Monthly Reporting
The PCCM shall convene a monthly meeting discussing the highlights, lowlights, and critical
issues related to the CMS implementation within the progress. The meeting should also discuss
the key figures analyzing the change control’s performance such as Key Performance
Indicators “KPIs”, number of approved changes, durations taken to carry out the CMS process,
number of pending changes, and whatever figures the PCCM deems as necessary to be
demonstrated to the project team.
3.2.5.2. Lessons Learned
The Lessons Learned process shall be integrated within the CMS to ensure a comprehensive
and a valuable deviation management. Thus, it is recommended that the Change Reports,
regardless of its format, would include a designated section to register the lessons learned that
might be identified by the participants regarding the given change event. Identified lessons
learned shall be accompanied with suggestions for improvement, or best practices, as well as
the causing and affected phases of the project. Subsequently, a separate Lessons Learned log
shall be prepared to archive these items. This log shall be timely updated and accessible by the
Contractor’s tendering and management team to ensure that the lessons learned from all
running projects are properly and timely acknowledged. Such lessons shall be further analyzed
to determine its root causes within the organization and preventive measures shall be prepared
to avoid the recurrence of such errors.
At a regular interval, as defined by the PM at the beginning of the project, a lessons learned
review workshop shall be conducted with the project team to analyze the identified lessons and
brainstorm for other unidentified ones to be added to the register.
84
3.2.5.3. CMS Database
All change cases shall be recorded by the PCCM in the CMS database on a daily basis
according to the current status. The PCCM shall ensure that all documents related to the CMS
are properly documented and archived in a unique manner to ensure that all documents are
allocated to their corresponding change cases. This could be done by establishing a coding
system to the different documents in cooperation with the project’s document control manager.
In this context, the CMS database should be a pool of data that contains all information related
to all change cases. These data include the current status of the change case, the detailed
breakdown of the costs and time impacts, affected cost accounts and schedule activities,
affected disciplines, the type of the change, identification of the party responsible to reimburse
the impacts, the status of the CCOs, and all detailed information of all identified changes.
All identified changes should be captured in the change log regardless of the changes
disposition, whether an approved or a rejected case.
85
Chapter Four: DESIGN & DEVELOPMENT OF THE WEB-
BASED CHANGE CONTROL MANAGEMENT TOOLKIT
This study aims to transform the system into generation 3 “GEN3” as indicated in
Figure 26 such that it reduces the volume of human tasks and increases the machine’s ones to
diminish the likelihood of errors.
Figure 26: Human-based V. Machine-based Tasks Across Different Generations of CMS (Karimidorabati, 2014)
Web-based information platforms have proven their effectiveness and contribution to the
performance improvement of the various construction project management processes since
they facilitate extensive information sharing among numerous project participants (Chen et al,
2015). Information technology is essential to manage and control project changes by improving
the communication channels and coordination among the project participants, as well as
automating the process workflow to minimize human errors (Sun, 2010).
Moreover, web-based systems are cost-efficient, dynamic, and adaptable platforms that collect,
filter, manage, and disseminate extensive information to support management of construction
projects (Motawa et al, 2006; Chen et al, 2015).
Portals avoid the need for multiple re-entries of the same data which diminishes redundancy
of data entries yet provides all needed information records in a shared environment via a web
interface (Chen et al, 2015).
The CMS is a pre-dominantly paper-based system such that it still relies on human discipline
to circulate and archive the data manually leading to significant issues in terms of the system’s
86
effectiveness and performance. Thus, there is a need to formulate an automated CMS, in
conformity with the proposed working steps and procedures set out by this paper under Chapter
3, for LSTK projects. The capabilities of the web-based system shall be examined in
comparison with the current change management systems. It is therefore imperative to make
use of the computer clouding technology to enhance and automate the workflow, data storage,
and data analysis of the CMS.
To design the WCCMT, the scope of works shall be divided into 5 main phases: 1- System
analysis, 2- Toolkit architecture design, 3- Toolkit workflow design, 4- Toolkit
implementation, 5- Model validation. The system analysis, and toolkit implementations are
formed by adopting the steps used by Charoenngam et al. (2003).
4.1. System Analysis
As outlined in the CMS processes, the change control system is primarily a communication
intensive system in which it incorporates different channels of communications between the
project members during the course of the project. Even though the CMS aims to cover the
complete cycle of the integrated change management process, the Change Requests and
Change Reports have to be circulated to different stakeholders in order to complete, modify,
and verify the data.
The PCCM shall make sure that, for each case, the reports are conclusive, complete, and
reviewed by the engaged participants within the planned duration. If the data was later modified
data, the report shall be re-circulated and reviewed, which prolongs the process duration and
requires additional amounts of efforts. Moreover, the PCCM has to issue reminders and urge
the team members to finalize the identified changes, consuming substantial amount of time
which disrupts the overall cycle.
Throughout this process, data could be lost, basis of quantification might be duplicated, and
affected disciplines might get different interpretations of the merit of the case. As a result, false
87
data may mislead the team to make uninformed decisions. Further, the change log highly relies
on manual data entry by the PCCM which is also subject to human errors and, consequently,
an inefficient data archiving system.
Accordingly, there is a definite need to enhance, facilitate, and optimize the communication
channels of the system among the different team members, along with eliminating the human
factor from the data circulation and archiving processes. A unified platform is needed whereby
all data, information, and circulations are being carried out and in a limited time as set out by
the system. This shall be done for all registered projects on the platform. Therefore, by
analyzing the business requirements and deficiencies, the following objectives shall be
realized:
Enhanced communication among the project team members and facilitating the
coordination activities to be carried out by the PCCM.
Optimizing the overall time duration of executing the CMS processes and, thus,
reducing the cycle duration and required efforts.
Reducing additional costs of consumed man-hours needed to implement the system in
comparison with the paper-based CMS.
Diminishing the possibility of human errors regarding the data and information
circulation.
Providing a comprehensive and single data source to the change management system
of the projects.
Handling the data archiving, data circulation and notifications automatically in real-
time
Handling the allocation of the assessed impacts to the proper work packages in
accordance with the project-specific WBS and cost breakdown structures “CBS”.
A centralized data source to the company’s change management system lessons learned
88
Enhancing the performance of the CMS to maximize the capturing of the critical project
deviations and reducing the possible deviations for the future projects of the contractor
Providing a toolkit with user-friendly interfaces that obtains a generic capability to be
used for different types of projects.
Creating a mechanism that encourages the team members to propose beneficial changes
for the projects.
Providing automated data analysis to assist the Contractor to make informed decisions
and continuously improve.
4.2.Toolkit Architecture Design
i. Conceptual Design
The design is aimed towards having a simplified yet an efficient application. It also aims to
develop a cost efficient toolkit to maximize the benefit to cost ratio. Accordingly, this tool shall
be developed using a combination of available programming and database management
systems. The toolkit shall be an independent system since the CMS could be addressed as an
independent process despite being part of project management integrated system (Hao et al.,
2008).
The toolkit is composed of two main components, an input component and an output
component.
The input component comprises four modules whereas the output component comprises six
modules as demonstrated in Figure 27.
89
Figure 27: WCCMT Components
The Input Component is responsible for gathering all needed data and records; this shall be
acquired by filling four simple forms, two of which will be filled in only once for each project
- the Project Initiation, Project Creation forms- while the other two are developed for
facilitating the CMS data collection and storage – the Change Request, and Change Report
forms.
The Request and Report online forms shall be designed to accommodate all relevant data and
information needed for a particular change case. Each identified change case shall have its own
online form with a unique identification number. The Change Request form shall act as the
starting point of the CMS whereby, as soon as the Change Request is initiated by an authorized
user, the automated workflow, notifications, data circulation, storage, and analysis shall be
initiated accordingly. As for the Change Report, it acts as the platform for the authorized users,
including the PCCM, to place their inputs associated with the change identification/initiation,
change evaluation and quantification, and change verification processes. Once a new action is
made, the toolkit automatically sends out notification emails to the relevant users. For the
purpose of optimizing the Input Component’s agility, an alerting subsystem shall also be
embedded to act as regular reminders for authorized users in case of overdue tasks.
Input Component
•Project Creation
•Project Initiation
•Change Case Initiation
•Change Management Cycle
Output Component
•Data Display Lists
•Data Analysis & Reporting
•Multi-informative Dashboard
90
The Output Component is associated with the data displays, data analysis and reporting, and
toolkit dashboard. It also provides performance indicators for the CMS performance status.
The “use case” model was adopted to identify the key actors and their main roles towards
implementing the WCCMT as recommended by Charoenngam et al. (2003). Figure 28
demonstrates the key concepts of the model whereas Figure 29 illustrates the followed design
philosophy.
PCCM Reviews
Request
Change
Event
Database
Management
System
Initiator Submits a new Change Request
PM & CPM to
approve/ Reject
Data Analysis
PCCM/ PM Fills in Project
Creation Form
Request
Approved?
Automated
Notification Mail
to Initiator
No
A New
Change
Report is
Created
Yes
Users to quantify
& insert impacts &
needed inputs
Automated Notification Mail to
Initiator +Selected Users +
Controlling Team +PM
Controlling Team
Validate &
approve change
Automated
Notification Mail
to PCCM
Automated
Notification Mail
to PCCM & PM
Automated
Notification Mail
to Participants +
PCCM
Datalists
Data Analysis
& KPIs
Reports &
Logs
Dashboards
Senior User Fills in Project
Initiation Form
Automated
Notification Mail
to PCCM
Automated
Notification Mail
to Controlling
Team
PCCM Validates
& approves
change
Automated
Notification Mail
to PM & CPM
Input Component Output Component
Figure 28: WCCMT Conceptual Design
91
1- Initiation/Identification of Change Events
Any member of the
project team Identifies/
Initiates a Change Event
Reports to
his/her LE/
Supervisor
Authorized Application
User fills the change request
form (Mandatory fields +
Optional Fields if possible)
Authorized
Application User
identifies/initiates a
Change Event
A change to the
baselines?
PCCM updates & approves
change request. An
automated email is sent to
selected users
Yes
PCCM rejects
change case with
reasons
No
Automated
Notification to
Initiator
PCCM classifies
Change Case as
Internal
PCCM approves
Change after ensuring
all affected elements
are inserted/verified
An automated email
is sent to PM &
Commercial
Manager to approve/
reject change
PM & Commercial Manager
make their decision by
Approval or Rejection
Real-time Analysis to
Stored Data
Automated mail to
Contract Manager
End
Reports & Lists
Lessons Learned Project & Portfolio
Dashboards
2- Evaluate & Propose Change
4- Implement Change
5- Continuously Improve 3- Approve/
Reject
An automated notification mail is
sent to the PCCM for Approval
Should be
reimbursed by
External Party?
No Yes
Follow up on case
to initiate external
change process
Controlling
Team checks &
validates inputs
Users fill in the
quantified impacts
based on change data
& description in the
online form
WCCMT Creates new
Change Report Linked
to approved request
Timeout
Reminder
Timeout
Reminder
Automated
Notification to all
affected users +
PCCM for
implementation
PCCM Verifies
actual impacts
against estimated
ones
Figure 29: WCCMT Design Philosophy against CMS Stages
92
ii. Detailed Design: Input Component
1. Input Forms
Figure 30: WCCMT Interfaces throughout Project's Phases
The Project Initiation and Project Creation forms shall be filled in by the authorized users for
every new project only once to introduce the Project to the toolkit. As for the Change Request
and Report forms, these shall be utilized continuously throughout the project execution up till
the closure stage for each identified change case or event.
Project Initiation
Only one senior user shall be granted the authorization to create a new project, which is
recommended to be the Head of the Project Management Division of the Contractor. Upon
project signature, the senior user shall initiate a new project on the model by providing the
name and number of the project, and individuals’ names that shall be assigned as the Project
Manager and PCCM. The toolkit shall be directly connected to the organization’s user accounts
registry. Hence, once the senior user submits the form, an automated notification mail is sent
by the toolkit to the assigned PM and PCCM.
Project Creation
P
I
F
P
C
F
C
R
F
C
R
F
Project Initiation Phase
Project Execution Phase: Perform Integrated Change
Control Management
93
Upon receiving the notification, the assigned PCCM and PM shall be the authorized users to
fill in the Project Creation form for the newly created project. The form shall be divided into
three sub-tabs: 1- Project Key Information, 2- Project WBS, and 3- Project Users.
The first sub-tab shall contain the key data of the project as well as the baseline values and
information as deduced from the Contract. The required data, along with the explanation and
purpose of each entry is depicted in Table 10.
Table 10: Project Key Information Entries
S . No.
F Entry
T
R
P
1
Project Number
According to the Contractor’s
internal numbering system
Unique identification of the
project in the toolkit
2
Project Name
As stipulated by the Contract
3
PM
Assigned Project Manager’s
Name
For authorization, data
protection, and automated
notifications by the toolkit
4
PCCM
Assigned Change Controller’s
Name
5
Client Company
Name
As stipulated by the Contract
Data analysis and output
component of the model
6
Project Type
According to the categorization
of projects
7
Contract Value
According to the total price
stipulated by the prime contract
8
Project Start and
Finish Dates
As stipulated by the contract
9
Project Location
As stipulated by the contract
The second sub-tab, the WBS, shall incorporate the complete WBS enclosed with the Project
Management Plan down to the activity and task level of all E/P/C as well as project
management work packages. The WBS shall be developed and listed in MS Excel format,
depicting the WBS code, description, and baseline budget of all activities and work trades.
94
Subsequently, the WBS sheet shall be uploaded on the toolkit. The toolkit shall subsequently
link the enclosed data with the database management system and shall demonstrate the
uploaded data in a tabular form embedded in the form interface. The purposes of uploading the
WBS are the following aspects:
1- Allocation of change impacts to their respective accounts in terms of time and cost
implications
2- Tracking and monitoring the approved deviations of each given account and comparing
the deviations against the baseline budget value
3- Reporting the WBS deviations to the Contractor’s PM and Controlling teams, to initiate
the necessary action plans, whereby such reporting would be one of the Output
Component’s generated results
The third sub-tab, Project Users shall incorporate all participants which shall be the authorized
users in the toolkit, for the selected project, to access and edit the WCCMT different interfaces
in accordance with their roles and granted permissions. The project users list shall include the
user’s name and function within the project’s organization. Such data shall serve for the
automated notifications and authorizations provided by the WCCMT.
Change Request
Once the project is initiated, the Change Request form for this project shall be available for
usage by any of the identified Project Users. The Request form shall be embedded in the
model’s interface and shall be divided into 3 sub-tabs: 1- Change Request Information, 2-
Nominated Users for Case, 3- Case Supporting Documents.
The Change Case Information shall incorporate the key data pertaining to the captured case to
initiate the CMS process; these data shall be provided based on the available information at the
time the case is captured. Unavailability of some information related to the entries shall not
impede the initiator from submitting the request form and informing the remaining project’s
participants. Only the Project Name, Request Title, and Description entries are mandatory to
be filled by the initiator while the remaining fields shall be optionally filled according to the
95
available information and knowledge. The tab’s required data, along with the explanation and
purpose of each entry are depicted in Table 11.
Table 11: Request Form Key Information Entries
S . No.
F Entry
T
R
P
1
Project Name
and No.
Project of subject matter to be
selected via a drop-down list
Proper allocation of case to
its parent project
2
Request Title
User to give a unique title to case
based on relevancy
Unique identification of the
case in the toolkit
3
Creation and
Closure Dates
Date of creation represents the time
where the initiator submitted the
request. Closure date is when the
request was accepted or rejected by
the PCCM
Data analysis and output
component of the model
4
Description
Detailed illustration of the captured
change (describe trail of events, and
reasons of why this is seen as a
change to the baselines)
For recording the particulars
of the change case
5
Impacts On
To make single or multiple
selections via a drop-down list based
on the impacted aspect (Time, cost,
design, scope)
Data analysis and output
component of the model
6
Case Priority
To select (Low, Medium, High)
based on the criticality of
completing the full CMS processes
Determining the timeout
features of the workflow
steps
7
Caused By
To make single or multiple
selections via a drop-down list based
on initiator/PCCM’s judgement of
which Party caused the deviation
(Client, Supplier(s),
Subcontractor(s), Internal
(Contractor), Licensor, Service
Provider)
For recording the particulars
of the change case and Data
analysis and output
component of the model
96
8
Required
Action(s)
List actions to be taken to implement
the change if approved
For recording the particulars
of the change case
9
Change/ Defect
Initiator/PCCM to categorize the
case of whether it is deemed as
Change or a Defect. A defect shall
be selected in case the change is
caused due to materials and supplies
issues
Determining the
corresponding change
category list in Change
Report form and data
analysis of output
component of the model
The Nominated Users tab shall be filled by the initiator and the PCCM to add all authorized
users of whom contributions and attention are required in the Change Report form. The
Supporting Documents tab is designed to act as a platform where the initiator and the PCCM
could upload all supporting documents to be attached to the given Change Request form as
substantiation to the case. The attached documents shall be listed in a tabular format whereby
the user shall define the document type by selecting one of the following entries: Original
Scope, Deviated Scope, Cost Impact Documentation, Time Impact Documentation; this shall
serve as proper organization of the supporting documents to their corresponding aspects.
Furthermore, the initiator shall have the option to save the request information prior to
submitting it if the provided data is incomplete or inadequate.
Change Report Online Form
This form is the main submodule of the Input Component as it compiles and gathers all data
pertaining to any given change case. The form shall be designed to be an embedded interface
within the toolkit with the following 6 sub-tabs: Detailed Information, Detailed Costs
Breakdown, Affected Activities, Approvals/ Rejections, Supporting Documents, and Lessons
Learned.
The Detailed Information tab shall contain all information related to the change case in subject.
It aims to enable the reader to be informed about the different aspects pertaining to the case
such as the chronology of events, the accountable party, the CMS analysis findings, as well as
97
the actions needed to implement the varied works in an effective manner. All field entries of
the Change Case Information of the Change Request form will be automatically transferred to
the Detailed Information tab by the toolkit. Only the PCCM shall have the authority to edit and
update any of these entries in the Change Report based on the updated information and findings.
In addition, Table 12 illustrates the field entries that shall be added to this tab:
Table 12: Additional Field Entries of Change Report Detailed Information
S . No.
F Entry Title
R
P
10
Causation Phase
To indicate which phase of the
project that resulted in such
change via a drop-down list based
on the different project phases
(Bid Management, Process Design
Package, Conceptual Design,
Basic Design, Detailed Design and
Procurement, Construction,
Commissioning, Warranty period)
For recording the
particulars of the change
case and Data analysis and
output component of the
model
11
Impacted
Phase(s)
To indicate which phase(s) of the
project that shall be affected by
such change via the same drop-
down list mentioned above
12
Change Type
To determine whether the change
case is considered as Beneficial,
Neutral, or Detrimental
To follow the Literature
Review and for data
analysis and output
component of the model
determining the
corresponding change
category list in Change
Report form and data
analysis of output
component of the model
13
Required/Elective
To indicate whether the change
must be implemented or if the PM
has the discretion to reject it
14
Change Category
To select one of the categories
depicted and explained in Table 13
via a drop-down list
15
a- Causes
b- Effects
To state the root cause of the
particulars that led to this change
Urge the PCCM to
establish causation and
Effects linkage
98
and establish the proper linkage
with the corresponding effects
17
Total Amount
The total cost amount of the change
will be automatically linked to the
summation of the Detailed Costs
Breakdown tab
Data analysis and output
component of the model
18
a- Change
Case No.
b- Revision
No.
Unique ID number automatically
given by the WCCMT for both the
Request and Report forms.
Revision number is given for each
new revision made of a closed
Change Report
Database management for
proper allocation of data
19
a- External
Party
Accepts
Charge
b- Accepted
Amount
c- Basis of
Entitlement
In case the Change Case is not
caused by the Contractor (internal
change), this set of entries shall
appear for the PCCM to select
whether the external party accepted
to bear the impacts. In case of
acceptance, PCCM to insert the
accepted amount to be charged.
PCCM in cooperation with the
Contract Manager to determine the
basis and references giving rise for
entitlement of such reimbursement
To store the external
variation data. Also, to
indicate the recovered
amount from the external
party against the internal
cost incurred
Field entry numbered 14 which indicates the change category; one of two lists will appear
based on the selection in the Change Request form of whether it is a “Change” or a “Defect”.
The main aim of this categorization is to allocate the change impacts to the different cause
types; such that the amount of change impacts each category causes will be determined. Table
13 depicts the change categories to the project’s baselines. The change categories have been
determined in accordance with the Literature Review findings.
99
Table 13: Change Categories
T
C
W to be selected?
Change
Scope Shift
Scope is shifted between internal entities or outsourced
Budget Shift
Part of cost account budget is moved to another account(s)
Incorrect Estimation
Overestimated, underestimated, or missed estimate of a
certain item or if the estimated specification of the item is
inaccurate
Quantity Change
Inaccurate estimation of the quantities that were taken into
account in the project budget
Engineering Faults
Design errors, poor design estimate, or specifications errors
that resulted in additional costs and/or delays for the project.
Also, poor management of engineering activities resulting in
additional costs or other consequences.
Concept Change
New technologies or value engineering incorporate for
potential savings
Delays/Acceleration
Measures made that incur additional costs to recover time
delays or to create time buffer
Customer Influence
Client’s instruction to vary, Client’s delay/disruption events,
and Client’s errors
Hindrance/Inefficiency
Disruptions caused internally or by external factors or low
productivity rates against planned ones
Defect
Incomplete Delivery
Missing materials upon delivery to site
Deficient Packaging
Improper material packaging resulting in damages
Preservation
Improper preservation of materials
Transport
Materials damaged during transportation
Incorrect Design
Materials not fit for intended use due to design errors
Incorrect Material
Materials not complying with design specifications
Fabrication
Faulty fabrication of materials by supplier
Wrong Installation
Poor workmanship on site
Malfunction
Materials or equipment not functioning properly
Warranty
Repairs to be made during the warranty period
Out of Scope
Materials purchased for another party but not in Contractor’s
Scope of Work
Erection Damage
Materials damaged during installation on site
100
Commissioning
Damage
Materials damaged during the commissioning phase of the
project
The “Detailed Costs Breakdown” tab is for determining all the affected cost elements and the
magnitude of impact pertaining to the change case. It shall include a table with the following
headers: WBS No., Cost Element Description, Additional/Subtracted Man-hours (in case of
engineering impacts), Additional/ Subtracted Value, and Remarks. The toolkit shall link the
uploaded WBS sheet from the Project Creation form to this tab. The affected WBS element
could either be inserted by searching for it using the cost element description text or the WBS
number. To insert a new input, an “Add Cost Account” button shall be pressed to insert the
foregoing data. The PCCM and affected users could add, remove or edit any of these data.
Other users are only permitted to view the records. At the end of the tab page, the values of the
cost accounts shall be summed up into one cell, which is the total value of change.
The “Affected Activities” tab shall follow the exact concept of the Detailed Cost Breakdown
tab but with respect to the project’s time schedule. The table headers are as follows: WBS
Element, Planned Finish Date, Actual/Forecasted Finish Date, Total Float (in days), Critical
(Y/N), Remarks.
The “Approvals/ Rejections” tab contains the actions taken regarding this change either by
approving or rejecting the change. It acts as the digital signature of the authorized users such
that each of the nominated users, the PCCM, Controlling Team, the Commercial Manager, and
the PM would have their corresponding checkboxes. After inserting all relevant data,
evaluating the case, and inserting the quantified impacts, each of the nominated users shall
check the box denoting that the user verified the inserted data and that the change case is
assessed and quantified with respect to the user’s scope of activities. The PCCM can only
approve the Change Report upon approval of all affected users. The PM and Commercial
Manager would have two checkboxes, one for approval and the other for rejection depending
on the PM’s standpoint to the identified change.
101
The “Attachments” tab shall include all attached files supporting the change case such that any
of the authorized users could upload any file that would assist in substantiating the change case.
The toolkit shall automatically transfer all attachments uploaded on the Change Request form
to this tab. It shall follow the same structure and categorization of the Attachments tab in the
Change Request form. The PCCM could remove, or edit any of the attachments whereas other
users could upload additional attachments. These attachments may include calculation sheets
of the quantified cost impacts, time delay analysis of the project’s time schedule, Request for
Information “RFIs”, Request for Approval “RFAs”, Inspection Requests “IRs”, Non-
Conformance Reports “NCRs”, engineering drawings, transmittals, photographic images,
correspondences, mails, letters, Purchase Orders “POs”, or any other supporting document the
users may see as beneficial.
Finally, the “Lessons Learned” shall include all identified errors, defects, incomplete and
missing data, as well as mistakes that could have been avoided and shall be registered for future
references. It shall be in a tabular format with the following headers: Disciplines Concerned,
Main Focus, Problem/ Good Practice, Topic Description, Impacts Description, and Suggestions
for Improvement.
Automated Notifications and Reminders Subsystems
This submodule aims to enhance the performance of the CMS within the WCCMT and
optimize the workflow facilitation of the defined working steps. The main objective is to ensure
that the CMS stages are completed within a predefined timeframe and should not be exceeded
which would result in an improved efficiency to the change management performance of the
Contractor’s projects. This shall be done by developing two subsystems, an automated
notifications feature and an automated workflow alerting feature. The automated notifications
shall be activated and provided to the corresponding users once specific preceding tasks are
completed first. This will be provided via email sent by the toolkit to the user’s registered mail
102
with a notification providing a brief of the completed task and the pending action to be taken
by the user.
Table 14 clarifies the different notifications that shall be executed for the Automated
Notifications feature along with their associated specifics.
Table 14: Automated Notifications of WCCMT
T
N Description
A
T
W ?
Project Initiation
“A new Project has been initiated in
the WCCMT and you are assigned
as the PCCM (or PM)”
PCCM and
PM
Upon project initiation
by Senior User
Project Creation
“A new Project named (Project
Name) has been created by the
PCCM and you are assigned as one
of the authorized users to participate
in the Project Change Management
portal”
PM and all
Authorized
Users
Upon submission of
the Project Creation
form by PCCM
Change Request
Submission
“A new Change Request has been
submitted by “User name” and is
pending your review.
Request Details:
Project Name: (Given Name to be
stated)
Request Title: (Given Title to be
stated)
Request Number: (ID number given
by the tool to be stated)
Hyperlink: Link to the Request
form in subject to be stated”
PCCM
Upon submission of
Change Request by
initiator
Change Request
Review
Decision
In case of Approval:
“ The PCCM (PCCM Username)
reviewed and has approved your
change request
Initiator
Upon
Approval/Rejection by
PCCM of Change
Request
103
(Request Details to be provided as
stated above)
In case of Rejection:
The same text but also stating the
reason(s) for rejecting it
Change Report
Creation
“A new Change Report has been
created and pending your
contributions
Report Details:
Project Name: (Given Name to be
stated)
Report Title: (Given Title to be
stated)
Report Number: (ID number given
by the tool to be stated)
Change Priority: To state the given
priority level of the case
Hyperlink: Link to the Request
form in subject to be stated”
Affected
Users,
Controlling
Team,
Initiator,
Commercial
Manager and
PM
Upon Approval by
PCCM of Change
Request and WCCMT
opens a corresponding
Change Report
Change Report
Review
“A Change Report is verified by
affected users and pending your
verification
(Report Details to be provided as
stated above)”
Controlling
Team
Upon verification
made by affected
users for a given
Change Report
Change Report
Final
Verification
“A Change Report is verified by all
affected users and Controlling Team
and pending your final verification
(Report Details to be provided as
stated above)”
PCCM
Upon verification
made by all affected
users and Controlling
Team for a given
Change Report
Change Report
Approval
“A Change Report is approved by
the PCCM (state PCCM username)
and is pending PM approval
(Report Details to be provided as
stated above)”
Commercial
Manager and
PM
Upon approval made
by PCCM of a given
Change Report
104
PM &
Commercial
Manager “CM”
Review
Decision
In case of Approval:
“ A Change Report is approved by
the PM (state PM username) & CM
(State CM username)
(Report Details to be provided as
stated above)”
In case of Rejection:
The same text but also stating the
reason(s) for rejecting it
Affected
Users,
Controlling
Team ,
Initiator and
PCCM
Upon
Approval/Rejection
given by PM of a given
Change Report
New Revision
Creation
“A new revision has been created by
the PCCM/PM for a closed Change
Report
(Report Details to be provided as
stated above in addition to the
new revision number)”
Affected
Users, CM
and PM/
PCCM
In case a new revision
is created by PM or
PCCM after closing a
Change Report to
repeat the workflow of
the Change Report
form
Furthermore, an additional feature is the alerting system. This is an alert given by the toolkit to
notify the user that a specific task is overdue whereby the alerted user is the task owner. The
timing of the alert shall be determined based on a predefined timeframe for each step according
to the workflow working steps. However, these durations shall vary depending the on the
criticality of the change as specified in the Change Request, whether it is low, medium, or high.
This subsystem is discussed with more depth in section 4.3.
In addition to the above, the toolkit shall have a designated link for each user depicting the
action list for all due tasks, which is also one of the generated reports by the Output Component.
WCCMT Database
The core of the WCCMT is the data storage automated system such that it provides an
integrated data source of all information related to the change control management system. As
soon as the Change Request is accepted and a Change Report is initiated, all upcoming data,
105
files, and information are forthwith recorded and stored in the database along with the date and
time of the data entry as well as the user’s name.
iii. Detailed Design: Output Component
The Output component aims to utilize the stored records to generate key indicators and
quantitative analyses for the purpose of providing the Contractor a decision support system,
assisting the users into making informed decisions for the running and future projects, and to
formulate effective action plans accordingly. This shall be accomplished by generating, both,
data analyses and representation. The data depicted in this component shall be updated in real
time once a new record is added, and original ones are modified or removed.
Dashboard
The dashboard shall have a default view where all developed indicators are shown,
summarizing the compiled data of all aggregated projects. To accommodate the different needs
of the users, a filtering and sorting criteria shall be developed to determine the data to be
analyzed, the indicators to be shown, the layout and organization of the dashboard.
The Portfolio-level dashboard is the first and default interface that the toolkit will display
once the user logs on to the system. Table 15 depicts the dashboard design features and the
method of calculating the different indicators.
Table 15: WCCMT Portfolio Dashboard Design
S . No.
R
D
M of Calculation
1
Number of Registered
Projects
Count formula of Created Projects
2
a- Total Contracts
Value
b- Percentage of
Approved
Changes Vs. Total
Budget
Summation of the Contract Value of all registered
projects as derived from Project Creation Form
Summation of approved changes net Cost Impact
Values divided by summation of total value of
budgets in percentage
106
c- Approved Time
Impact
Approved schedule impacts to the completion
dates of the projects
3
Total Approved Changes
Value (Positive and
Negative)
Total net cost impact value of approved changes
in addition and in subtraction
4
Total Value of Changes
with regards to Project
Types
Total net cost impact value of approved changes
of each project type represented in a Pie Chart
5
Change Categories Pie
Charts
Total net cost impact value of approved changes of each
change category represented in a Pie Chart. Two pie
charts will be developed, one for the change categories
and the other for the defect categories
6
a- Beneficial Vs.
Neutral Vs.
Detrimental
Changes
b- Required/Elective
Total absolute value of net cost impact of all approved
changes regarded as “beneficial changes” against the
ones regarded as “Detrimental Changes” as well as
“Neutral Changes” represented in a graphical chart and
another one for required versus elective changes
7
Executive Summary of
Change Reports and
Requests Statuses
A list depicting the total count of request and report forms
attributed to their current status in the WCCMT workflow
8
Pie chart of Change
Values Caused by Each
Party
Total net cost impact value of approved changes
attributed to each causing party (Client, Suppliers,
Subcontractors, Contractor (Internal), Licensor, Service
Provider represented in a pie chart
9
Bar Chart of Causing
Phase Vs. Impacted
Phases
Total net cost impact value attributed to each causing
phase and to which phase its impacting to be represented
in a horizontal bar chart
10
Bar Chart of Approved
Changes Vs. Project
Timeline (Is displayed
only in case 1 project is
selected in the filtering
criteria)
It shall include a bar chart depicting the approved cost
impact values per each month, starting from the Project
Start Date up to the Project Finish Date, with a
segregation between the added amounts and subtracted
ones.
107
Lists and Reports
A list of all registered projects will be displayed by the toolkit as a second subtab beside the
above dashboard tab.
A filtering criteria shall be developed for each of the following lists and reports to select which
projects, and data to be displayed based on multiple parameters. In addition, for each of the
following reports, the filtered data can be exported to an independent MS Excel sheet generated
by the toolkit for the user’s usage if required.
An embedded list of the Project’s Change Reports as well as a list of the Change Requests will
be displayed with available selection from the toolkit toolbar. A hyperlink will be provided for
each request or report form to open the form details. Such lists will be adjacent sub-tabs to the
Project’s dashboard, and creation form details.
Table 16 depicts the reports to be generated by the toolkit and the different particulars of each
one.
Table 16: WCCMT Project Reports
S . No.
R Description
P
1
Projects List
A list with the following data:
1- Project Number,
2- Project Name,
3- Assigned PM,
4- Project Status,
5- Project Type,
6- Client Name,
7- Contract Value,
8- Approved Change Amount,
9- Percentage of Changes,
10- Project Location,
2
Change Requests Log
A list with the following data:
1- Project Number and Name,
108
2- Request Number,
3- Request Title,
4- Initiator Username,
5- Creation Date,
6- Closure Data,
7- Priority,
8- Caused By,
9- Request Status,
10- Change Request Hyperlink
11- Corresponding Report Hyperlink
3
Change Reports Log
A list the following data:
1- Report Number,
2- Report Title,
3- Priority,
4- Report Status,
5- Initiation Date,
6- Closure Date,
7- Cost Impact Value (Added Amount/ Subtracted
Amount)
8- Time Impact Value
9- To Be Reimbursed By
10- Change/Defect
11- Change Category,
12- Revision Number,
13- Estimated Impacts Verified (Y/N)
14- Attachments
15- Beneficial/Detrimental
16- Required/ Elective
17- Causation Phase,
18- Impacted Phase(s)
2
WBS Accounts Summary
A WBS accounts list showing the WBS elements along
with their approved deviations amounts, both added and
subtracted from/to its budgeted amount. If an account is
double-clicked, a breakdown of the deviations amount is
109
shown along with its corresponding Change Report
number
3
Lessons Learned Register
A compiled table of all registered lessons learned from
approved change reports in MS Excel sheet
6
Beneficial Changes &
User Performance
A list depicting the number of overdue tasks, and on
which projects for each registered user. Also, another list
shall display the number of initiated beneficial changes,
and the magnitude of the approved ones that were
initiated by the given user for all registered users.
4.3.Toolkit Workflow Engine Design
A workflow management is a process area whereby it automates the transition of information
and actions from one user to another to facilitate the progress of a given set of activities in
accordance with a predefined set of procedures (Parkes, 2004). The workflow system adopted
is activity-based since the main focus shall be made on the progression of activities and not on
entities, namely documentation, as suggested by Bergmann in 2007. Three questions should be
answered for each pre-defined steps of an activity-based workflow management system, “Who
must do what, when and how?” (Bergmann, 2007). The what represents the activity description
of what should be done, the when represents the sequence by which the activities are to be
completed and whether they should be done concurrently, the how represents the application
features that will enable the user to complete the given activity, and the who represents the
assigned user to complete the task.
Hence, following the design philosophy outlined in the previous section, the toolkit workflow
design has been formulated accordingly. Figure 31 is a graphical demonstration of the
WCCMT workflow and working steps; the task owner as well as the list of tasks with regards
to each step are outlined. The workflow design diagram is a demonstration that all workflows
are identified, activities are mapped out and the toolkit workflow would facilitate the
application from the initiation phase up till data processing. It consists of 10 main activities.
110
Some of these activities are to be performed by multiple users concurrently as depicted in the
aforementioned diagram.
The first step, being related to the Project Initiation Form, is carried out by the Head of Project
Management Division where the new Project’s name is identified and the PCCM and PM roles
are assigned to the designated users. This shall be the only user authorized to access the
Initiation Form. Subsequently, the PCCM and/or PM, after being notified by an automated mail
for the new project, shall fill in the Project Creation form to introduce the key data of the project
by carrying out the actions in the to-do list. The PCCM and PM are the only authorized users
to fill the Creation form. Upon submission, an automated mail shall be disseminated to all
authorized users identified through the form. The PCCM and PM can edit any of the Initiation
form field entries later on and at any time before closure of the Project.
Once any of the Project team members identifies a change case, it shall be reported right away.
In case initiator is not an authorized user, the initiator shall forthwith report the case to the
superior member that is an authorized user. The authorized user shall log onto the WCCMT
and click on the “Change Request Creation” tab. The initiator/creator of a new change case
will have to fill in a list of mandatory fields along with some optional fields, subject to the level
of information the creator has at that stage, as depicted in the to-do list’s actions of Step 3 and
submit the form. There is a “Save” button in case the initiator would like to submit the form
later on. Upon submission, the PCCM, after being informed through an automated mail, shall
review the change case, verify the field entries and decide on whether the request qualifies as
a change case and whether it would affect one of the Project’s baselines. The PCCM will have
the authority to edit any of the inserted data or the empty fields that the creator could not fill.
Subsequently, the PCCM shall either approve or reject the change request in the approval box
of the form, based on whether the identified case qualifies as a change event. It is important to
note that only the PCCM has an access to the approval/reject slot box. If the PCCM has rejected
the change request, the system will send a notification email of the rejection along with the
111
stated reason(s) to the initiator. If accepted, the PCCM, before approving the request shall carry
out the actions listed under Step 4. In such case, the PM, the CM, affected users along with
the Contract Manager, if it is an external case, shall be informed. The “Detailed Information”
tab shall be filled by the PCCM whereas the other users do not have the authorization to edit
any of the fields therein but could be viewed by any user. The PCCM should first ensure that
he understands the change case properly so that the inserted information would be accurate;
the PCCM may set a meeting with the change initiator as well as the other users to discuss the
change case in detail, based on the criticality and complexity of the change case. The PCCM
should also come with a list of required actions as a conclusion of the convened meeting to be
inserted in the online report. In addition, the PCCM should establish the linkage between the
causation and effects to appropriately comprehend the essence of the case.
It is important to note that if any external party should reimburse the impacts of this change,
the PCCM, along with the Contract Manager, should thoroughly review the contractual terms
to determine the contractual entitlement of the Contractor for the compensation. The Contract
Manager shall establish the particular sub-clauses of the Contract and/or any legal references
that give the Contractor such entitlement, if applicable. The PCCM shall provide any additional
support needed to the Contract Manager. As soon as an agreement is reached, the change report
shall be updated and finalized accordingly. In case of an external change, another field appears
asking whether the change has been accepted or rejected from the charged party. The affected
users shall list all the affected WBS elements in terms of time and cost impacts. All supporting
documents shall be attached, and the type shall be determined. The corresponding lessons
learned shall be identified along with the suggested actions for improvements. Upon
completion, the affected user shall approve the Change Report by checking the approval box
designated to the given username. The user cannot check any of the approval boxes except the
one authorized to.
112
The PCCM shall be notified by an automated mail once any of the affected users approves the
Change Report. When all affected users give their approvals, an automated mail is dispatched
to the Controlling team. Their role is to verify the costs breakdown, acquire an accurate
estimation of the new items from the Cost Estimation team where no references were found.
The Scheduling Manager shall verify the affected activities log and attach a delay analysis
report if needed. Upon approval of the foregoing participants, the PCCM shall be notified by
an automated mail. The PCCM shall verify all entries of the Change Report, edit if needed, and
subsequently approve the case. A subsequent mail will be provided to the PM and CM
requesting a review decision to be given to the subject Change Report. The PM, & CM shall
either approve the case or reject it along with giving proper justifications. In both cases, a
relevant automated notification shall be provided to the PCCM, affected users, controlling
team, as well as the initiator by the toolkit. In case either the PM or CM rejects the case, the
system will deem this report as rejected; thus, both members have to jointly approve the report
to be considered as approved.
If approved by the PM & CM, the Project Team shall start executing the varied works and
incorporate the Change Report within the Project’s plan. The PCCM shall monitor the
implementation of the changed activities. Upon implementation, the PCCM shall verify the
accuracy of the estimated impacts relevant to the case either by checking the designated
“Impacts Verified” checkbox found in the Change Reports Log embedded in the WCCM or
create a new revision of the Change Report to record the actual impacts or to correct any of the
original data; such new revisions, along with the original one, of all Change Reports shall be
archived by the toolkit and available to be viewed by any user.
Status of Change Requests and Reports
Depending on the current step upon which the Change Request form or the Change Report is
pending, the WCCMT shall automatically determine the status of the CMS and shall be
demonstrated in the respective logs.
Change Request Statuses:
113
1- Pending for Investigation: User saved but not submitted
2- Pending for PCCM Action: User submitted but PCCM did not take action
3- Approved/Rejected: PCCM decision taken
Change Report Statuses:
1- Pending for Investigation: Users and PCCM inputs are still pending
2- Pending for Controlling Team Action: Users approved the case but controlling team
have not yet reviewed the inputs
3- Pending for PCCM Action: Controlling Team and users completed and reviewed the
inputs but PCCM has not yet verified the final inputs
4- Pending for PM and Commercial Manager Action: PCCM verified the case but PM &
Commercial Manager have not given their decisions yet
5- Pending for PM Action: Commercial Manager approved the case, pending for PM’s
approval
6- Pending for Commercial Manager Action: PM approved the case, pending for CM’s
approval
7- Approved: Approved by PM & CM
8- Rejected by PM
9- Rejected by Commercial Manager
114
Step 1
Authorized User (Initiator)
To Do:
- Fill in the mandatory fields of the Change Request
Online Form (Project Name, Description, & Request
Title)
- Fill in the non-mandatory fields if possible
- Attach supporting documents
- Nominate authorized affected users to participate in
change case analysis
- Submit the form.
Step 2
PCCM
To Do:
-Check, edit & verify inserted data
- Complete the unfilled field entries
-Check and add to the nominated persons list
- Approve the Request
PCCM gets informed
Email
Initiator is informed
with reasons
Email
Reject
Workflow closed
Submit
Accept
- Change Request is archived with status
Approved
- A new Change Report is created with same
Request No.
- Data is stored in database & transferred to
Change Report
- Logged as Pending for Investigation
Change Report
Online Form
Step 3
Nominated Affected Users + PCCM (E/P/C)
To Do:
- Fill in and complete all additional field entries of the Detailed Information tab
- Edit, & verify the transferred data from the Request form
- Complete and check all related technical data
- Insert all WBS elements which timeframes are affected
- Attach all additional supporting documents and needed data for evaluation,
analysis, and quantification (BOQ, Drawings, Photographic images, MTOs, Original
Scope Vs. Varied scope, RFIs, RFAs, Inspection Requests, NCRs, etc)
- Register Lessons Learned
- State the affected WBS elements in terms of time & cost impacts with
corresponding Order of Magnitude
- When completed, check the corresponding approval checkbox.
External?
Controlling Team (Cost Control/ Scheduling Team)
To Do:
Cost Control & Commercial:
-Determine and analyze all affected cost accounts
-Communicate and acquire from the Estimation team any new item not
included in the BOQ
- Study impacts on the Project s Cost Performance
Scheduling:
- Determine and analyze all affected activities
- Conduct a delay analysis
- Develop a recovery plan, if possible
Step 4
Step 5
Controlling +
Commercial are
informed when all
affected users approve
Change Report
Email
PCCM
To-Do:
- Verify data
- Approve the Change Report
PM & Commercial
Manager are
informed
PM & Commercial
Manager
To Do:
-Accept/Reject Change
- If rejected, state
reason(s)
Change to be
implemented
PCCM
To Do:
Verify Actual values/ impacts against estimated
and modify.
- Submits the report
- Ticks the Verified checkbox in the Change
Reports List
Implemented
Step 7
Step 8
Approve All participants &
PCCM are informed
Email
Reject
- Data is stored in database
- Logged as Rejected by PM or
Rejected by Commercial
Manager
Step 9
Step 10
Change Request
Online Form
Project Initiation
Form
Head of PM Division
To Do:
- Identifies the new Project name
- Assigns the PM & PCCM roles for the Project
PCCM & PM are
informed
Email
Submit
PCCM
To Do:
- Fills in all field entries in the Project Key
Information sub-tab
- Upload Project-specific WBS sheet
- Identify all Project participants to be
deemed authorized users
- Submits the form.
PM & Authorized Users
are informed
Email
Submit
Project Creation
Form
PCCM
To Do:
-Study the case to determine if it qualifies as a
change case (change to the project baselines)
-Accept/ Reject the Change Request, if rejected,
then state the reason(s).
- If accepted, then before accepting, complete step
4
Initiator is informed
- A new change request no. is created
- Data is stored in database
- Logged with status of Pending for PCCM Action
Email Contract Manager is
informed
Affected users, &
PM are informed
Emails
Email
PCCM is informed that all
affected users + Controlling
team approve the Change
Report
All participants &
PCCM are informed
with reasons
- Data is stored in database
- Logged as Approved
- Data is stored in database
- Logged as Pending for PM
Action
A new revision of
Change Report?
Yes
Email
End
No
Step 6
PCCM is informed
when a user
approves & verifies
Change Report
Email
Email
Figure 31: WCCMT Workflow Design
Automated Alerts
The WCCMT shall have an alerting system for each step such that each step will have a set duration
that the responsible person shall submit the necessary data and inputs before the deadline. The
defined duration for each step had been determined based on the time analysis conducted for the
conventional CMS during the practical observation period.
In case the corresponding action was not completed within the time limit, an automated alert email
shall be sent to the task owner and the PCCM. Steps 1, 2, 3, 9, and10 shall not have pre-defined
durations, being initiation steps to the succeeding activities in the process while step 10 is carried
out once the case activities have been completed which varies for each case. Thus, the timeouts
for each step shall be as per Table 17 according to the change criticality.
Table 17: Timing of Automated Reminders
S Description
R Per
H
M
L
R
(W
D )
R
(W
D )
R
(W
D )
Change Request Review
PCCM
1
2
3
Change Report Preparation
Affected Users + PCCM
1
4
5
Change Report Verification
Controlling Team
1
2
3
Change Report Final
Verification
PCCM
1
1
2
Change Report Approval
PM
1
2
3
Total Maximum Allowable Durations (Days)
5
11
16
4.4.WCCMT Development
The WCCMT system has been developed using four different layers, Web Browser, User Interface
“UI”, Application, and Database. Each of these layers serves for different functions and
responsibilities. The WCCMT has been hosted by Windows Server 2016 whereby the Internet
Information Server “IIS” functioning as the web-base. The access privileges, whether viewing,
editing, approving, or initiating, were also provided using the authentication sublayer depending
116
on the user’s account on the Microsoft Windows operating system. The toolkit’s database has been
developed using SQL Server Database; SQL Management Studio was used to manipulate the
database’s archived records. A series of tables were created, a bundle for each form, and the
relationships between tables’ fields are established.
The UI has been developed using HyperText Markup Language “HTML”, Cascade Style Sheet
“CSS”, and Java Server Pages “JSP”, which are easily integrated together. CSSs are used for
formatting, and presentation purposes to ensure that the toolkit is user-friendly. In addition,
Angular Material was used to obtain some controls over the AngularJS codes which serves to
enhance the representation of the toolkit’s forms and tables. FontAwesome was used to develop
the different icons embedded within the WCCMT.
The Application layer serves to develop the different application features for, both, the Input and
Output Components. .Net and Crystal Report are the tools used to develop the application’s
features. Crystal Report was used to create the toolkit’s reports, using the acquired data from the
database, to extract the data to Microsoft Excel format. The Output Component’s dashboards were
developed using JavaScript, CSS, and Chart.JS for data visualization. Within .Net, ASP.Net MVC
was used as the WCCMT framework, C# was adopted as scripting language, Entity Framework
was used to link the data stored in the SQL database and the .Net protocol.
117
Chapter Five: MODEL TESTING, VERIFICATION, AND
VALIDATION
This chapter addresses the testing, verification, and validation works carried out pertaining to the
developed model. The testing was done using both fictitious and actual data related to the project
change management to test its sensitivity against different scenarios. The verification was made
by acquiring the quantitative assessment of a representative sample from the EPC market in terms
of the model’s functionalities and capabilities. The model validation was carried out using two
different exercises, first by acquiring the feedback from a construction expert based on a face-to-
face orientation while the second step is by incorporating the toolkit within the execution of a
running EPC project in Egypt by a LSTK contractor.
5.1. Model Testing
Both fictitious random data or data acquired from previous projects were used to be plugged in the
model field entries to ensure that all parameters of the engine are checked, and the possible
scenarios that could be encountered during the execution are simulated during this phase. These
scenarios were reflected in the testing action plan prior to starting the testing work.
This stage was planned over a time period of 20 working days. During testing, some errors were
identified and were subsequently rectified. These errors included miscalculations, open loops,
wrong relationships between database elements, and spelling mistakes. Notes were taken
throughout the phase, including insights, to improve the functionality and representation of the
toolkit.
118
5.1.1 Execution of Testing & Results
The data were inserted manually in the fields, both mandatory and optional ones. The diversity of
data and user actions were determined based on change management registers obtained from three
previous EPC projects.
A set of seven new projects were created on the portal using the Project Initiation and Project
Creation forms. The new projects were then displayed by the toolkit via the Projects List.
Figure 32 shows the process of testing the initiation of a new project in the portal. The assigned
persons as the PCCM & PM are identified using the database directory of the organization’s
personnel.
Figure 32: Project Initiation Testing
Figure 33 shows that, upon initiation, the toolkit sent an automated notification to the assigned
PCCM & PM informing the individuals of the initiation of the new project with provision of a
hyperlink to the next required step.
119
Figure 33: Testing Automated Notification for Initiated Project
Subsequently, the Project Creation form was tested, as shown in Figure 34, where different entries
for the fields were plugged in. The WBS was created for each project in an MS Excel format and
then uploaded to be interpreted and stored by the portal’s database. A number of project users were
identified for each project with assigning each individual the project-specific role which then is
reflected by the portal to determine the task owners.
120
Figure 34: Summary of Testing Project Creation Form
The data pertaining to the initiated and created projects were correctly shown in the Projects list,
as illustrated in Figure 35. The search and filtering sub-form was also tested for the list to ensure
its accuracy, as shown in the foregoing figure. The filtering can be applied using the following
parameters whether individually or collectively:
Project name
Project status
Project location (city and country)
Minimum and maximum percentages of approved changes, against the total budget
Client name
Business division
121
Figure 35: Summary of Project List & Data Filtering Testing
122
Further, upon project creation, the assigned user is authorized to create a new change request. If
not assigned, the user cannot access the given project to create a new request. The fields of the
designated form were all tested, as illustrated in Figure 36. Once submitted, the portal accurately
sends out a notification mail to the selected PCCM of the project for review. All trials were
successful. According to the permission rules, only the assigned PCCM is authorized to review
and edit the pending requests.
Request
Creation
Change
Request
Information
Projects
Change
Requests
Request
Log
Request
View
Request
Creation
Request
Edit
Request
Review
Change
Reports
w
Request
Creation
Change
request
information
Change
Request
Nominated
Users
Change
request
nominated
users
Change
Request
Attachments
Select
Project
Request
Title
EDC
Missing
Budget
of
Canned
Pumps
Package
Description
According
to
new
layout
requirements,
it
has been
found
out
that
new
internal
roads should be
constructed
between
the
two
tanks;
these
requirements
were
not
taken
into
consideration
during
the
bidding
phase.
Hence,
new
civil
&
electrical
Engineering
as
well
as
Construction
activities
shall
be
carried
out.
These
activities
include
the
following:
a.
New
Roads
to
be
constructed
between
the
new
two
tanks
/
near
the
new
pumps.
b.
Construct
of
new
rainstorm
trench
and
modified
of
the
existing
one
will
take
place
accordingly.
c.
New
lighting
poles
foundation
to
be
constructed
accordingly.
d.
New
street
lighting
fixtures
to
be
supplied
and
installed.
e.
New
feeding
cables
to
be
supplied
and
installed.
a“
Impacts
on
Priority
Time,
Cost
~
Medium
¥
Caused
by
Internal
(contractor),
Service
provider
+
Required
Actions
1-
Update
drawings
for
new
paving.
2-
Update
underground
coordination
plan
drawing.
5-
Update
Civil
BOQ.
“ae
©
Change
O
Defect
(Change
request
attachments
Project
Request
title
EDC
~
Pipe
Rack
Structural
Modifications
Decerition
Pursuant
to
EPC's
written
instruction
provided
on
December
15th,
2019,
enclosed
under Attachment
01,
to
formulate
a
variation
proposal
of
modifying
the
structural
elements
of
the
Project's
new
pipe
rack
located
at
CU
500
at
a
specific
area
of
the
Project
as
demonstrated
in
Attachment
03;
this
modification
shall
be
made
to
accommodate
a
new
set
of
pipelines
pertaining
to
another
project
that
is
out
of
thlS
scope
of
works.
The
technical
calculations
of
such
modifications
had
been
made
based
on
the
data
received
from
EPC
for
the
new
set
of
pipelines
which
shall
mean
that
tkIS
bears
no
liability
with
respect
to
the
correctness
and
verification
of
the
data
pertaining
to
the
new
set
of
pipelines
to
be
accommodated
by
the
Project's
pipe
rack.
In
addition,
and
as
substantiated
by
EPC's
instruction,
enclosed
in
Attachment
01,
tkiS
was
instructed
to
suspend
all
Engineering
&
Construction
works
pertaining
to
the
pipe
ack
at
CU
500
up
and
until
EPC
issues
this
CCO.
refore,
by
issuing
this
CCO
in
accordance
with
Article
20
of
the
Contract,
EPC
hereby
instructs
to
undertake
the
eee
Portion
indicated
herein
under
and
shall
eet
thIS
with
an
additional
amount
equivalent
to
the
CCO
TOTAL
VALUE.
4A
mpacts on
Priority
Time,
Cost
~
High
~
Caused
by
Client
v
Required
action
1-
Undertake
the
necessary
Engineering
&
Construction
additional
works
and
reworks
to
the
structural
elements
of
CU
500-
new
pipe
rack
to
accommodate
the
additional
loads,
prev
Ged
by
EPC,
which
are
imposed by
the
new
set of
pipelines
pertaining
to
another
project
out
of
thIS
Scope
2-
Undertake
the
necessary
Project
Management
activities
to
Sor
orate
the
CCO
within
the
Project
Management
Plan
3-
Undertake
the
necessary
Construction
Management
activities
to
execute the
additional
works
and
incorporate
the
(CCO
within
the
Project's
work
front
4a
(@)Deviation
()
Nonconformity
123
124
Figure 36: Testing Request Creation Form
Upon submission, the Change Requests list reflects the data pertaining to the registered request,
irrespective of the PCCM decision. Figure 37 shows the tested list; the filters and data extraction
buttons have been successfully tested as well. The data were extracted in readable formats in an
exported MS Excel file.
125
Figure 37: Testing Change Requests List
Afterwards, the Report form was tested for each approved request. The entries pertaining to the
external/contract change management process are only displayed in the Report Information tab if
a reimbursable party is selected other than the Contractor (Internal). A sample of the random
entries testing to the different tabs of the form are shown in Figure 38. For long texts that are ought
to describe the particulars of the case or findings of the conducted analysis, the portal allows for
expanding the field size to demonstrate the information.
Furthermore, the portal has been tested to identify discrepancies between interrelated field entries.
Particularly, the model ensures that the aggregate value of the following aspects are all identical
prior to submission or approval:
Change Category values
Apportionment of values among reimbursing parties
126
Total Cost Impact value
Upon completion of the reviewing and editing process by the PM, the “approve” button appears
to deem the case as approved.
127
Figure 38: Summary of Report Form Testing
As a final cross-check of the integration between the Input Component and Output Component
data, the reports list was tested in terms of sensitivity to the data changes via the report forms.
128
After each action taken, the status is instantly updated for the given report. The list was also tested
whether data amendments are reflected instantly, prior to approving or rejecting the case. The
demonstration of the tested list, along with the exported raw data in MS Excel format, is depicted
in Figure 39.
Figure 39: Summary of Change Reports Testing
129
5.1.2 Discussion of Results
The plugged random inputs in the different entries of the Input Component were reflected
accordingly in the data analysis and presentation of the Output Component. All developed reports
that are generated by the portal were tested in terms of data accuracy, functionality, and display.
Figure 40 shows the WBS account summary report, whereby the approved total float, the budgeted
cost, and the approved added and subtracted amounts by means of change reports are all analyzed
and demonstrated. For instance, regarding the WBS element numbered 49-0114-PM-607 for the
“EPPC” project, records an approved added amount of EGP 80,000.00, which was cross checked
with the approved change reports list. Further, and as also shown in the aforementioned figure, the
generated report enables the user to view the breakdown of the approved amount by selecting the
“Cost Details” button where the relevant Change Reports data are laid out in a new screen.
130
Figure 40: Sample of Output Component Reports
Moreover, the component’s dashboard was also tested with respect to the random data inserted in
the field entries. Figure 41 illustrates the sample of indicators that were checked against the Input
Component data. A feature has also been added where, for representation purposes, the portal
allows the user to show a specific indicator in full screen, print it out, or save it if required for other
customized reporting, as shown in the aforementioned figure.
Required/Elective
=
Total
Approved
Value
=
Pending
Reports
=
Required
=
Approved
Value
Elective
0
0
0.5
1
1.5
2
2.5
-5M
0
5M
10M 15M
20M
25M
Values
Velue
©@
Required/Elective
©
Subtrected
@
Added
©
Total
Highcharts
com
Change
Report
Types
Reimbursed by
Service
provider
Chant
0
1
—
Supplies)
=
og
(®)
Neutral
O
Change
Request
Status
Values
Internal (contractor)
©
>Change
Report
Types
Higheharts.com
Highcharts
.com
Pending
Requests
Change
Request
Priorities
=
Changes
To
Business
Divisions
High
6
20M
15M
0
Count
Peyding/Total
5M
Values
Process
technologies
Cement
Minig
©
>=Changes
To
Business
Divisions
Highcthars.com
131
132
Figure 41: Testing of WCCMT Output Component Dashboard
5.2. Model Verification
The model verification has been undertaken by acquiring a quantitative assessment for a number
of construction practitioners in the market. This was done by conducting face-to-face structured
interviews. The objective of this process was to verify whether the WCCMT would be widely
acceptable by practitioners, who are currently engaging in LSTK projects for EPC Contractors, in
case of actual implementation.
Subsequently, in order to deduce a quantitative assessment of the proposed CMS and developed
WCCMT, a structured questionnaire, containing 32 questions, was developed. This questionnaire
aims to enable the selected experts to provide a quantifiable assessment of the CMS functionality,
133
and the WCCMT functionality and capability. It also consolidates the recommendations of the
experts to enhance the WCCMT’s interface.
The verification process targets a population of professionals who have proven practical
experience and are currently working for EPC Contractors and engaging in LSTK projects. The
population also is planned to be diverse, working in different roles and positions ranging from
Engineering engineers and managers, Procurement and purchasing managers, construction and
project managers.
The survey sampling has been determined using a selection of methods that would directly
contribute to the survey results and its precision which in return would affect the verification
process. Based on research, and considering the objectives of this survey, two sampling methods
were adopted and used simultaneously to select the interviewees that would represent the
population sample: Purposive Sampling, and Convenience Sampling, both of which are non-
random sampling techniques (Hibberts et al. 2012). Convenience sampling is by selecting
individual who are available and ready to participate in the survey whereas Purposive Sampling is
by filtering the individuals, of which they are available and ready, who match a specific set of
criteria. The specified criteria of the interviewees are those who are: a) currently engaging in LSTK
projects and are on the EPC Contractor’s sides, b) are experienced practitioners with a minimum
experience level of 10 years, and c) are/have been assigned roles that require them to engage in
the CMS of the projects. These steps have been repeated until the required sample size has been
reached.
As for the sample size, a number of twenty interviewees were selected; such sizing was determined
in accordance with the conducted research. The literature review has suggested that a range of 20
to 30 individuals for sample sizing of structure interviewees is deemed as sufficient (Vasileiou et
134
al. 2018). It has been concluded that thematic saturation, whereby no new trends or concepts are
emerging from incrementing the number of interviews, has been reached upon completion of 20
interviews.
The questionnaire form is enclosed under Annex 01, which has been designed following the
guidelines provided by Hibberts et al. 2012 for designing and framing the questions.
A thorough explanation and illustration of the system’s workflows and working steps as well as
the toolkit’s design, features, and different interfaces shall be given prior to asking the below
questions. Dzeng et al.’s (2015) questionnaire was used a guideline for formulating the questions.
The following questions shall be answered with a score of 1 to 5, where the scores depict the
following:
5- Excellent
4- Very Good
3- Good but needs some modifications
2- Acceptable but needs substantial modifications
1- Failing and needs complete redesign
The level of experience and details pertaining to each interviewee are summarized in Table 18.
Table 18: Interviewees Details and Experience
N .
P
C T
Y of
E
Y
W
LSTK
C
T of
E
P
A
C
V of
P
(M USD)
INT001
Head of Project
Management
Department
Main Contractor
20-25
15-20
Buildings,
Heavy
Industrial
50-100
INT002
Lead Contracts
Manager
Main Contractor
10-20
10-15
Heavy
Industrial
50-100
INT003
Project Manager
Main Contractor
10-20
10-15
Buildings,
Heavy
Industrial
50-100
135
INT004
Project Manager
Main Contractor
30+
15-20
Heavy
Industrial
0-50
INT005
Head of
Commercial
Management
Department
Main Contractor
20-25
15-20
Buildings,
Heavy
Industrial
100-500
INT006
Head of
Engineering
Department
Main Contractor
30+
20+
Buildings,
Heavy
Industrial
50-100
INT007
Engineering
Manager
Main Contractor
10-20
15-20
Heavy
Industrial
50-100
INT008
Lead Piping
Engineer
Main Contractor
10-20
10-15
Heavy
Industrial
0-50
INT009
Company CEO
Main Contractor
30+
20+
Heavy
Industrial
500-1000
INT010
Head of Planning
Department
Main Contractor
10-20
10-15
Heavy
Industrial
0-50
INT011
Lead Commercial
Project Manager
Main Contractor
10-20
10-15
Heavy
Industrial
0-50
INT012
Project Manager
Main Contractor
10-20
10-15
Heavy
Industrial
100-500
INT013
Head of Cost
Estimation
Department
Main Contractor
10-20
10-15
Heavy
Industrial
50-100
INT014
Head of
Construction
Management
Department
Main Contractor
10-20
10-15
Heavy
Industrial
50-100
INT015
Construction
Manager
Main Contractor
10-20
10-15
Heavy
Industrial
100-500
INT016
Civil
Construction
Superintendent
Main Contractor
10-20
10-15
Heavy
Industrial
50-100
INT017
Site Manager
Main Contractor
30+
20+
Heavy
Industrial
50-100
INT018
Site Manager
Main Contractor
30+
20+
Heavy
Industrial
100-500
INT019
Cost Controlling
Manager
Main Contractor
10-20
10-15
Heavy
Industrial
0-50
136
INT020
Procurement
Manager
Main Contractor
10-20
10-15
Heavy
Industrial
100-500
The summary reveals that 5 of the 20 interviewees have more than 30 years of experience and the
minimum years of experience of any interviewee is 10 years. The interviewees have all spent a
minimum of 10 years working for LSTK EPC contractors.
All 20 interviewees have engaged in projects where a CMS were implemented and part of the
execution plans, but all CMSs were GEN II. However, 80% of the interviewees reported that the
most optimum level of CMS implementation they have experienced is assessed to be 30% (3 out
of 10) whereas only 20% reported that their assessment is 60%. This indicates that there is a
practical deficiency of proper CMS implementation in the market.
Figure 42: Years of Experience of Interviewees
The interviewees were then requested to give scores about the different aspects of the proposed
CMS, which is discussed in Section 3.2 of the paper. A list of the scores is shown in Table 19.
Numbers from 8 to 14 represent the numbering of questions.
10-20
65%
20-25
10%
25-30
0%
30+
25%
Years of Experience
5-
1
0
0
%
10-15
60%
15-20
20%
20+
20%
Years of Experience in LSTK EPC
Projects
137
Table 19: CMS Functionality Scores List
N .
P
CMS F
8
9
10
11
12
13
14
INT001
Head of Project Management
Department
4
4
5
3
4
4
4
INT002
Head of Contract
Management Department
4
4
4
4
4
4
4
INT003
Project Manager
5
4
4
5
5
4
4
INT004
Project Manager
5
5
5
5
4
4
4
INT005
Head of Commercial
Management Department
4
4
4
4
4
4
4
INT006
Head of Engineering
Department
4
4
4
5
5
5
4
INT007
Engineering Manager
4
4
4
4
4
3
4
INT008
Lead Piping Engineer
4
4
4
4
5
3
4
INT009
Company CEO
4
4
4
4
4
4
4
INT010
Head of Planning Department
4
5
4
4
5
4
4
INT011
Company CFO
4
4
4
5
3
4
4
INT012
Project Manager
4
5
4
4
5
4
4
INT013
Head of Cost Estimation
Department
4
4
5
5
4
4
5
INT014
Head of Construction
Management Department
4
4
4
5
4
4
4
INT015
Construction Manager
5
4
4
4
4
4
5
138
INT016
Head of Procurement
Department
4
4
5
4
5
4
5
INT017
Site Manager
4
4
4
4
3
4
4
INT018
Site Manager
5
4
4
4
4
4
4
INT019
Cost Controlling Manager
5
5
4
4
5
4
5
INT020
Procurement Manager
4
4
4
5
5
4
4
An analysis of the scores, as shown in Figure 43, determines that 3% of the scores were 3 out of
5, 73% were 4 out of 5, 24% were 5 out of 5. These figures could lead to an informed conclusion
that the proposed CMS workflows would enhance the Contractor’s performance in managing and
controlling the project deviations originating from different sources. Two recommendations
were given to improve the proposed CMS, modifying the process flow to successfully manage
all time schedule deviations, and integrating the CMS workflows with project risk management
to ensure that critical risks with high probability to be proactively monitored by the change
management.
Figure 43: CMS Functionality Statistical Analysis
1
0%
2
0% 3
3%
4
73%
5
24%
CMS Functionality
139
Subsequently, upon providing a detailed walkthrough inside the WCCMT to the interviewees, a
series of questions were asked to assess its functionality and capability.
A list of the scores, for questions from 16 to 31, is shown in Table 20.
Table 20: WCCMT Functionality and Capability Scores List
N .
P
WCCMT F
WCCMT C
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
INT001
Head of
Project
Management
Department
4
4
4
4
5
4
5
4
4
5
5
4
5
5
3
4
INT002
Head of
Contract
Management
Department
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
INT003
Project
Manager
5
5
4
4
4
4
5
5
4
5
5
4
4
5
5
4
INT004
Project
Manager
5
4
5
5
5
5
4
4
4
4
4
5
5
5
5
5
INT005
Head of
Commercial
Management
Department
4
5
5
5
5
5
4
4
5
5
5
4
4
5
5
5
INT006
Head of
Engineering
Department
5
5
4
4
4
4
5
5
5
5
5
5
5
4
4
4
INT007
Engineering
Manager
5
4
4
5
4
5
4
3
5
4
4
5
5
4
4
5
INT008
Lead Piping
Engineer
4
4
4
4
4
4
4
3
5
4
3
4
4
4
4
4
INT009
Company
CEO
4
4
4
4
3
4
4
5
3
4
4
4
4
4
4
4
INT010
Head of
Planning
Department
5
5
5
4
4
4
5
5
5
4
4
4
4
5
4
4
INT011
Company
CFO
4
4
4
5
5
3
4
4
5
5
4
4
3
4
5
4
INT012
Project
Manager
4
5
5
5
4
4
3
4
5
5
5
4
4
4
4
4
140
INT013
Head of
Cost
Estimation
Department
5
5
5
5
4
4
4
4
5
5
5
5
4
5
4
5
INT014
Head of
Construction
Management
Department
4
4
4
4
3
4
5
5
4
4
4
5
5
4
5
4
INT015
Construction
Manager
5
5
5
4
4
4
4
4
5
4
4
4
4
4
4
4
INT016
Head of
Procurement
Department
5
5
3
4
4
3
4
4
4
4
4
4
4
4
4
5
INT017
Site
Manager
5
5
4
4
4
4
4
4
4
4
4
4
5
4
4
4
INT018
Site
Manager
4
4
4
4
5
5
5
4
3
4
4
4
4
4
4
4
INT019
Cost
Controlling
Manager
5
5
4
4
4
5
4
5
4
4
4
4
5
4
4
5
INT020
Procurement
Manager
5
4
4
4
5
4
5
4
5
4
5
4
4
5
4
4
In terms of the toolkit’s functionality, 3% of the scores were marked as 3 out of 5, 58% were 4 out
of 5, and 39% were 5 out of 5, whereas in terms of its capability and ease of usage, 4% of scores
were 3 out of 5, 63% as 4 out of 5, and 33% as 5 out of 5 as shown in Figure 44. These results lead
to a conclusion that the WCCMT is viewed as a fully practical and reliable tool to be incorporated
in the upcoming LSTK EPC projects to facilitate and manage the project’s change management
system. In addition, the following recommendations were provided:
i. Adding a remarks text box for each digital signature to be used in case the user decides not
to approve the change report.
ii. Improving the font size and formatting of the headers of all tables and lists
141
iii. Give the authority to the PM to bypass the workflow and approve or reject the Change
Report irrespective of the progress of the workflow
All of these recommendations were subsequently considered and implemented in the succeeding
model version.
Figure 44: WCCMT Functionality and Capability Statistical Analysis
The mean scores of the addressed 16 questions are depicted in Figure 45. The mean values are
varying with a range of 4.2 to 4.6 out of 5, with a total average value of 4.3. It could be,
subsequently, concluded that the WCCMT has an overall “very good” rating in terms of its
functionality, capability, reliability, comprehensiveness, and ease of usage.
1
0%
2
0%
3
3%
4
58%
5
39%
WCCMT Functionality
1
0% 2
0%
3
4%
4
63%
5
33%
WCCMT Capability
142
Figure 45: WCCMT Assessment Mean Scores
5.3. Model Validation
The WCCMT is further validated on two stages:
1. Acquiring a detailed quantitative assessment and feedback by a construction
management expert from outside the LSTK contractor where the model was developed.
The expert shall provide his feedback regarding the capabilities and reliability of the
WCCMT to be used in diverse real projects.
2. Bringing the model into force and effect to be utilized for a real EPC project to facilitate
the CMS of a LSTK contractor for one month. The project data was created and
uploaded on the model using the two designated forms. The validation process involved
five different actual change cases that are initiated, verified, analyzed, implemented,
and recorded using the WCCMT. The project commenced a year before the model
validation period, where the contractor execution team adopted GEN II CMS, using
MS Word, MS Excel, and MS Outlook tools for implementation. Thus, a comparative
3.9
4
4.1
4.2
4.3
4.4
4.5
4.6
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Mean Score of Questions
WCCMT Functionality & Capability
143
analysis is formulated between the WCCMT performance and the conventional GEN
II CMS which were both implemented in the same project and by the same team
members; the results shall be discussed at the end.
5.2.1. Construction Management Expert Validation
The expert practitioner has an overall experience of 35 years in construction project
management, working currently for a renowned project management consultant.
He has over 30 years of experience working for a main contractor engaging in LSTK EPC projects,
the types of these projects include heavy industrial, infrastructural, and buildings. The average
value of the projects is ranging between 500 Million to 1 Billion USD. Firstly, a thirty-minute
presentation was provided to the expert to entail the understanding of the Project Change
Management system, its objectives, as well as presenting the developed workflows and steps for
EPC contractors, as shown in this chapter. Subsequently, a detailed walkthrough across the entire
interface of the WCCMT was provided to the expert such that the different workflows, model
features, actions, and mechanisms were all covered, the duration of the walkthrough was 90
minutes. During this walkthrough, the expert was requested to provide his comments and
recommendations, and upon completion, the expert filled in the quantitative assessment
questionnaire of the WCCMT and CMS.
In general, the expert concluded that the WCCMT is a comprehensive, reliable, and effective tool
to completely manage the CMS of any given project of an EPC contractor. The expert also
highlighted that, with the current development level of the toolkit, the WCCMT is ready to be
rolled out for immediate incorporation in the market for practical implementation, however, with
taking into account the given recommendations for improvement. Another positive feedback is
144
that the WCCMT is an agile tool in terms of continuously keeping all participants informed and
urged to take action forthwith and in a timely manner.
The expert has provided scores, regarding all different aspects, ranging between 4 “Very Good”
and 5 “Excellent, with a mean score of 4.7 for CMS functionality, 4.6 for WCCMT functionality,
and 4.5 for WCCMT capability.
5.2.2. Case Study Project
5.2.2.1. Project Information
The project that adopted the WCCMT is an EPC heavy industrial project to be executed on a LSTK
basis in Alexandria, Egypt. The contractor’s scope of works includes basic and detailed
engineering, procurement, construction, and commissioning of a new Ethylene Dichloride “EDC”
cracking unit to produce Vinyl Chloride Monomer “VCM” with an annual capacity of 125,000
mt/annum of VCM. This project is brownfield whereby this unit shall be connected, both
downstream and upstream, to the client’s existing and operating plant facilities. The project size
is medium scale with a planned duration of 33 months, 31 for mechanical completion, and
additional 2 months for start-up and commissioning of the new plant. The contractor has
subcontracted the construction works for a single subcontractor by means of a re-measured
contract. The project also includes a trust agreement drawn by the contractor with a licensor to
grant a license to the client for operating the new unit. The project team of the contractor are spread
over three main different cities, Cairo, Alexandria, and Frankfurt, a setup that is one of the core
principles tackled by the WCCMT for enhancing the workflow and data collection. For the
procurement works, the majority of the long lead items shall be designed and fabricated at
numerous workshops of several suppliers, the majority of which are located in Europe. The model
145
validation period lasted 1 month, during this period, six change requests and four change reports
were facilitated using the WCCMT.
5.2.2.2. Project Creation and Information
Prior to starting, a comprehensive induction of the toolkit’s interfaces and features was provided
to all members of the contractor’s project team. It included an open discussion including different
inquiries and suggestions for improvement, all of which were responded to and considered. The
team members then confirmed their readiness to use the WCCMT.
The workflow and sequence discussed in Chapters 3 and 4 are followed throughout the
implementation process. First, the Head of Project Management Division “Senior User”, filled in
the Project Initiation form by identifying the PM and PCCM of the project using the company’s
directory. Upon submission, the WCCMT sent automated emails to both individuals informing
them of their assignment. The project is also registered in the projects list and its state is initiated.
Subsequently, the PCCM, using the Project Creation form, provided the project-related data in the
Key Information sub-tab. The PCCM also uploaded the WBS of the project which was then
interpreted and embedded within the system’s database, and the project team authorized users were
identified. Upon submission, all authorized users were informed of their assignments by means of
automated emails issued by the WCCMT. During execution, there was a change of personnel
among the team, so the authorized users needed to be changed for this project. So it is possible to
amend the authorized users list of the project at any given time during execution, which was made
to incorporate the change in personnel. However, in case there are pending tasks due by the
changed user, such tasks have to be completed first before authorizing the new member. Such
constraint was put to avoid any possible workflow errors, or loss of data.
146
5.2.2.3. Change Cases Workflow & Data Analysis
Six change requests were filed using the WCCMT, each submitted by a different user. Two of
these requests were submitted by the site management team, one request submitted by the
engineering team in Frankfurt, while the remaining are initiated by the project team in Cairo
(Contract Manager, Engineering Manager, and Commercial Manager). For each request, the
PCCM receives a notification with the necessary information and link for the request.
Subsequently, depending on the initial priority level given by the initiator, the PCCM is given a
pre-defined timeframe, as indicated in Table 17, before the task becomes overdue. The issued
requests were in regards to the following topics:
Missing budgets for critical materials & supplies “CH001”
Savings in social insurance budget “CH002”
Incorrect estimation of the German’s team hourly rates “CH003”
Re-adjustment of construction work packages “CH004”
Contract amendment of equipment list supplies “CH005”
Contractual agreement for change in scope of works “CH006”
Only CH005 & CH006 are in connection with an external contract partner, namely the client,
whereas the remaining requests are internal deviations. For detailed illustration of the validation
process, the workflows of CH001 and CH005 will be further discussed.
For CH001, the Engineering Manager filled in the change request form with the available data,
upon detection of missing budgets related to a number of materials and supplies that are within the
contractor’s scope of works. The engineering team, being the account managers, detected this error
whilst working on developing the relevant material take-offs “MTOs” during the basic engineering
phase. The request was filed and a notification was provided to the PCCM. The PCCM, reviewed
147
the entry fields, understood the case, identified the authorized participants, and approved the
request at the same working day. Subsequently, all relevant users were informed via the automated
notification of the newly created report. The PCCM, upon some communication with the
Engineering Manager and account managers, conducted the needed change evaluation and
prepared the information sub-tab data. It was concluded that the root-cause of this change was a
miscommunication between the proposal management team and the technical team during the
tendering phase where an additional scope of works was reflected and incorporated in the technical
proposal, and agreed with the client through signed technical clarifications, but the proposal
management failed to coordinate such update with the cost estimation team, and thus the budgets
were not considered. The account managers filled in the cost breakdown tab in accordance with
the project WBS along with the designated budgeted amounts. There is no time impact resulting
from such deviation given that this scope was already considered in the time schedule. The PCCM
uploaded the documents, mainly internal correspondences, supporting the root-cause analysis, in
addition to the detailed calculation sheets and technical specifications of the missed items. PCCM
submitted his inputs first, followed by the account managers and the Engineering Manager. Upon
their approvals via the signature boxes, a notification was given to the controlling team. The team
verified the cost breakdown tab, in terms of correct allocations and designated amounts, as well as
the supporting documents before approving the report. Subsequently, the PCCM provided his final
approval followed by a notification to the PM and the CM for approval. Within the planned
timeframe, both individuals approved the report without any modifications, followed by an
automated notification to all relevant users as per the toolkit’s workflow. The report and the request
are both registered and displayed under the corresponding lists where the status and information
were updated in real-time.
148
For CH006, the Contract Manager had initiated discussions with the client to amend the defined
scope of works of a particular package under the contract. The scope of works for this package
was split between the client and the contractor in a way that was later analyzed to be impracticable
and is creating contractual risks particularly on the side of the contractor. Both parties have then
reached a mutual agreement by amending the scope of works to be more practical and avoiding
the contractual risks identified by the contractor. This amendment contained de-scoping of
engineering and construction works to the contractor and omitted it from the scope of the project
entirely, in return for a reasonable reduction in the contract value. The change, therefore, contains
both a reduction in the contract value and the forecasted cost of the project. Upon agreement, the
Contract Manager initiated the CMS cycle by submitting a change request using the WCCMT. The
case is categorized as external, regarding both the client and the construction subcontractor, and
has effects on the engineering and construction works. Given the criticality of the case, the
Contract Manager identified its criticality as “High”. The PCCM received the notification and,
based on the given timeframe, reviewed the request details, amended the authorized users list and
the supporting documents, and approved the request. Subsequently, the PCCM, in conjunction
with the Contract Manager, filled in the report details with all the external information and cause
& effects analysis. The agreed upon contract value reduction was clearly illustrated in the case
description. The report details contained additional information given it is categorized as an
external change. The authorized users studied and understood the deviation case, and extracted the
scope that has been omitted for separate quantification. A separate BOQ was developed for the
omitted items, and another calculation sheet for the engineering man-hours allocated for these
works. Subsequently, each account manager inserted the relevant WBS elements with the savings
value in the Cost Impact tab. After the PCCM and authorized users approved the report, the
149
controlling team reviewed the case to also identify the budgeted amounts that shall be removed
and their correct allocations. In addition, the scheduler conducted a time impact analysis by
omitting the corresponding activities from the time schedule to study its impact on the sequence
of activities, site resources allocation, and time buffers. The results were recorded in the Time
Impact tab. Upon review, the controlling team & PCCM verified and approved the report, followed
by the PM & CM approvals.
Upon approval, the PCCM amended the contract value of the project in the project creation form
by doing the following:
Reducing the total contract value,
Amending the budgeted amounts for the omitted WBS elements to be zero
This step is to ensure that the net savings value of the change report is excluding the reduction in
contract value as agreed with the client.
Upon completion of the given tasks regarding the Input Component, the Output Component’s data
analysis changes accordingly. The dashboard figures, and KPIs were reviewed by the project team
to verify its accuracy and reliability. It was concluded that the WCCMT dashboard calculations
are both accurate and beneficial for the project team to give them insights to develop action plans
that would continuously improve the project’s performance.
5.2.2.4. Comparative Analysis
Once the validation period was over, the project team was requested to provide its constructive
feedback on the WCCMT’s capabilities and benefits. For guidance, the interview questionnaire
and the list of the model’s objectives were distributed among all participants. The team collectively
expressed that the WCCM has successfully accomplished the pre-defined objectives and has
150
optimized the entire CMS, in terms of lead times, transfer of data and information, proactive
control of project changes, and overall value to the company’s performance on the project and
portfolio levels.
Furthermore, as a quantitative analysis, one of the model’s objectives is to optimize the CMS
overall time duration. Therefore, an analysis has been made to compare between the time taken to
complete the cases, starting from request submission up to report review decision, using the
WCCMT against the conventional GEN II CMS. The advantage of using this project as a case
study is that it was already running and the GEN II CMS is adopted by the team and in force since
the beginning of the project. Thus, a comparative analysis between both systems using this project
is accurate and indicative.
It is not possible to track the time taken for each step of the CMS using the conventional GEN II
system, so, while it is possible to be tracked in the WCCMT, a comparative analysis has been made
in regards to the average overall time duration. The duration of each completed change case using
GEN II was calculated, and the outliers, particularly the ones with prolonged durations, were
disregarded for better accuracy.
The analysis revealed that the average total duration taken to complete the workflow using the
conventional GEN II system is 17 days whereas the time is reduced to only 8 days using the
WCCMT. Table 21 & Figure 46 demonstrate the summary of results.
This analysis showcases the improvement and optimization the WCCMT has provided by reducing
the CMS workflow lead time by more than 50%. The time saving is likely to be caused by the
automated notifications and reminders submodule, along with the user performance report, which
are all urging the task owners to complete the pending tasks in a timely manner.
151
Table 21: Comparative Analysis Summary
Figure 46: Comparative Analysis Time Bar "GEN II V. WCCMT"
Change Request Cycle (Submission & Review) 6 2
Change Report Cycle (Preparation & Review) 11 6
Average Total Duration (Days) 17 8
GEN II
WCCMT
A Total D
S Descri
8
17
WCCMT
GEN II
COMPARATIVE ANALYSIS "GEN II VS.
WCCMT"
152
Chapter Six: CONCLUSION AND RECOMMENDATIONS
6.1. Conclusion
Changes are almost inevitable to take place in any construction project despite extensive
efforts being exerted at the planning stages. Change events are one of the key factors leading to
adverse consequences to all project stakeholders in the construction industry, particularly if not
dealt with the required endeavors. Among those stakeholders, Contractors engaging in projects on
a LSTK basis bear almost all consequences of change events alone without sharing it with other
project parties. Hence, LSTK Contractors ought to incorporate an effective CMS as part of its
execution strategy in the running projects whereby the results of which must be utilized for
continuous improvement of the Contractor’s performance. Despite its importance, not all
Contractors address this aspect by implement an effective CMS. As for the CMSs being
incorporated in the market, they rely heavily on paperwork and hardcopy documentations, which
in turn makes the CMS a time-consuming process that is prone to human errors and eventually
leads to scope creep, cost overruns and delays.
The majority of the academic research conducted regarding this matter focused only on contractual
variation management between the project parties which does not encompass all change events
that occur in the projects. Hence, it was deduced that this deficiency shall be eliminated by
developing an effective change management tool customized for Turnkey Contractors that shall
facilitate the execution of the entire change management process to optimize the time and effort
consumption besides reducing projects’ costs. Accordingly, this aim was accomplished by: a)
developing detailed working steps, and workflows, in accordance with the CII and PMI guidelines,
for LSTK Contractors and b) designing, as well as developing a user-friendly comprehensive web-
153
based toolkit tailored for these Contractors. This toolkit comprises an Input Component, which
facilitates the workflow from initiation up to implementation, and an Output Component, which
analyzes the data and provides needed indicators for continuous improvement. This eventually
enables the management to make better decisions at early stages while dealing with the projects’
changes besides allocating the sufficient resources in minimizing detrimental changes and
exploiting beneficial ones.
The primary objectives of this work was to develop a toolkit that:
1. Eliminates paper-work deficiencies and possible human errors by automating the data
transfers, notifications, and archiving for different types of projects
2. Consolidates the data collection, and analysis from participants that are remotely and
distantly located by transforming the system into a web application
3. Encourages the project team members to initiate beneficial changes to the project by
categorizing of change cases and generating an automated report that recognizes users who
initiated beneficial cases that were approved by the PM
4. Provides data analyses and displays that are needed by project participants at all times by
setting out interface flexibilities for the Output Components
5. Captures, identifies and monitors all anticipated as well as incurred changes by analyzing
the required actions and quantifying the net resulting impacts
6. Contributes to the continuous improvement of the Contractor’s performance by generating
the required indicators and analysis as well as providing a comprehensive database for all
the information relevant to the change management systems of the project
7. Enhances the communication between the projects’ teams, hence reduces the overall cycle
time of the change process, and ultimately saves amounts of time and effort.
154
8. Reduces the required number of individuals to handle the change management processes
compared to paper-based CMS, leading to less project’s costs.
9. Ensures a smooth flow of information throughout the process.
Accordingly, a set of detailed working steps and procedures were formulated based on four
different scenarios to address the change sources in EPC project: a) engineering and design
changes, b) procurement and materials-related changes, c) construction changes, d) project
management and controls changes. The workflows aimed to address all types of impacts identified
through the literature review, in terms of cost budget, time schedule, quality of the works, and
scope of works.
Subsequently, the web-based model was conceptually designed by means of workflows and
process flow diagrams. The architecture of the toolkit included the identification of model forms,
lists, reports, and interface layouts needed to encompass the model’s Input & Output Components.
It was determined that a set of four forms are needed to gather the different data: a) Project
Initiation, b) Project Creation, c) Change Request, and d) Change Report. The first two forms were
designed to collect the project-related information that should be known and registered at the
beginning of the project’s execution phase. Such information includes the embedment of the
project’s WBS within the model’s database to attribute the impacts assessed through each change
event. The Change Request and Report forms are designed to facilitate the workflow of the CMS
cycle for each identified change event. The Output Component includes three lists: a) Projects List,
b) Change Requests List, and c) Change Reports List, three reports: a) WBS Accounts Summary,
b) Lessons Learned, and c) Users Performance and Beneficial Changes, and a model dashboard.
Further, a detailed design was carried out to define the field entries pertaining to the four forms,
the data display and analysis of the three lists, three reports, and the dashboard. The design also
155
included the filtering criteria for each of the Output Component’s subsystems that shall be applied
to provide a desired set of data.
Upon completion of the design phase, the model has been developed using four different layers:
a) Web Browser, b) User Interface, c) Application, and d) Database. The WCCMT has been hosted
by Windows Server 2016 whereby the IIS was utilized as the web-base. A set of software tools
were used to develop the model’s access privileges, database, workflow engine, notifications, and
interface subsystems.
The model was tested by plugging a combination of fictitious and actual data to check the different
subsystems’ functionalities. The loopholes and errors were identified and a reiterative process was
undergone until all functionalities were performing according to the design.
The verification process was conducted by obtaining the quantitative assessment of twenty
construction practitioners for the purpose of evaluating: a) the adopted workflows and working
steps, b) the WCCMT’s capabilities and functionalities. The results have shown that the two
aspects were given a “very good” rating with an overall mean score of 4.3 out of 5.
Moreover, the WCCMT was validated by carrying out two further steps: a) Obtaining a
quantitative assessment by a construction expert with an overall practical experience of more than
30 years, and b) launching the WCCMT for implementation within a running EPC project, which
was engaged on a LSTK basis, by the Contractor. The process led to satisfactory results with a
positive feedback by the construction expert, who gave a “very good” rating to the model’s
functionalities and capabilities, and team members who utilized the WCCMT for implementation.
Furthermore, based on the verification and validation results, the following benefits for LSTK
Contractors were realized using the WCCMT:
156
A structured set of working steps to assist the Contractor to set up the CMS procedures for
new projects
Eliminates the need for paperwork and redundancy of data entry. It also optimizes the
needed efforts among the team to communicate the particulars of change cases
Integrating CMS related-data seamlessly by continuously updating the Output Component
dashboard, reports, and lists
A unified platform for all project’s CMS data that could be accessed virtually from any
location using the Internet
During investigation, the WCCMT can help to identify the bottlenecks of the CMS process
and the delayed task owners for the purpose of optimizing the workflow.
Allocating the magnitude of impacts, resulting from change cases, to their respective cost
accounts which enables the PM to monitor the amount of deviations occurring to each
element within the project’s CBS
6.2. Limitations and Recommendations
In spite of the above-mentioned advantages for the developed WCCMT, this toolkit has some
limitations that could be tackled in future research as follows:
The toolkit can only be accessed using the Internet. It cannot be accessed offline; therefore,
the need for an uninterrupted internet connection is a must among the different project
users. Further development should be made to enable the users to use the tool offline and
the data could be uploaded using the Internet when available.
157
The adopted working steps and organization structure might not be fit for all LSTK
Contractors structure. Thus, the toolkit could be enhanced to be more flexible and acquire
a more generic approach.
The toolkit testing phase needs further extensive validations before floatation in the
construction market to all contractors
The toolkit cannot be used using mobile devices and have to be connected to the
Contractor’s web server which could be a restriction for site engineers; thus, future research
should focus on developing a mobile application
Another recommendation is to develop underlying automating portals that can formulate
the quantitative assessments of the identified changes without in an automated manner and
without any human intervention. This would necessitate the development of web-based
platforms that integrates the data from various sources such as: Time scheduling
application(s) “MS Project or Oracle Primavera”, budgeting and cost monitoring
applications “MS Excel Sheets or SAP”, and engineering design applications “AutoCad,
Micro Station Bentley, Autodesk Revit, or Navisworks”. This platform shall be linked to
the WCCMT such that the entire quantitative assessment and analysis processes would be
formulated automatically once the deviation is identified.
