THESIS - Ryan Caetano Thesis Submission

Communicating progress in real-time from an
infrastructure construction site
A Thesis
Submitted in Partial Fulfilment of the Requirements
For the Degree of
Bachelor of Engineering
In
Civil Engineering
By
Ryan J. Caetano
312 078 609
Supervisor: Adjunct Professor Michel Chaaya
School of Civil Engineering
University of Sydney, NSW 2006
Australia
October 2015

ii
Student Disclaimer
The work comprising this thesis is substantially my own, and to the extent that any part of this
work is not my own I have indicated that it is not my own by acknowledging the source of
that part or those parts of the work. I have read and understood the University of Sydney
Student Plagiarism: Coursework Policy and Procedure. I understand that failure to comply
with the University of Sydney Student Plagiarism: Coursework Policy and Procedure can
lead to the University commencing proceedings against me for potential student misconduct
under chapter 8 of the University of Sydney By-Law 1999 (as amended).
Departmental Disclaimer
This thesis was prepared for the School of Civil Engineering at the University of Sydney,
Australia, and describes the development and implementation of a semi-automated solution to
activity progress monitoring. The opinions, conclusions and recommendations presented
herein are those of the author and do not necessarily reflect those of the University of Sydney
or any of the sponsoring parties to this project.
…………………………..
Ryan Caetano

iii
Summary
Large infrastructure projects require constant monitoring and adjustment to avoid delays and
budget overruns. The desire to work according to lean construction principles by optimising
workflows is driving research into the field of project monitoring. Having timely access to
project performance information can improve the decision-making processes that make the
adoption of lean principles possible.
This study investigates and develops a cloud-based solution to activity progress
tracking, and suggests a method of visualisation through Earned Value metrics within a
Building Information Model. A digital Daily Site Report was specifically developed to
capture progress data on a large infrastructure construction site. Specialised software was
used to harness this data into a useable format that could be interpreted to inform variation
control. Existing paper-based processes on-site were re-engineered to accommodate for the
implementation of the form, thus facilitating real-time control. Standardisation and cloud-
based data dictated the success of the study.
The implications of the development are discussed in the context of Automated Data
Collection technology. A readily implementable and flexible framework incorporating the
digital form is advocated.

iv
Acknowledgements
I am grateful to Dr Michel Chaaya for his continual support throughout this research.
I would like to thank my thesis partner Timothy Gollan for being a reliable wall to bounce off,
and a calming presence.
To several other university friends, namely Sam, Gabriel, Hashan, and Jonah, it’s been a
pleasure sticking it out with you through University.
To the team at EIC, thank you for the inspiration and the opportunity to make this research
happen. I will always be grateful.
To Rob, thanks for putting up with my persistence over the past few months. Without your
help, this thesis wouldn’t have been possible. Your contributions were instrumental to its
success.
To my family, thank you for your patience and understanding in my undertakings over the
past four years.
Finally, to my partner Jaimie, your support has been unwavering through the time’s I hadn’t
been so sure.

v
Contents
1 Introduction ......................................................................................................................1
1.1 Background.................................................................................................................1
1.2 Industry collaboration.................................................................................................1
1.3 Thesis aims and objectives .........................................................................................2
2 Literature review ..............................................................................................................3
2.1 Lean construction .......................................................................................................3
2.2 Building Information Modelling (BIM) .....................................................................3
2.3 Project monitoring and control...................................................................................4
2.4 Progress monitoring....................................................................................................6
2.4.1 Existing solutions ...................................................................................................6
2.4.2 Daily Site Report ....................................................................................................6
2.4.3 Progress measurement............................................................................................8
2.4.4 Automated Data Collection (ADC)........................................................................9
2.4.5 Progress monitoring in BIMs ...............................................................................11
2.5 Summary of analysis ................................................................................................12
3 Methodology....................................................................................................................13
3.1 Research approach....................................................................................................13
3.2 Analysis of existing monitoring processes ...............................................................14
3.3 Progress measurement tool.......................................................................................14
3.4 Focus group ..............................................................................................................15
3.5 Activity progress calculation....................................................................................16
3.6 5D model development.............................................................................................16
3.7 Process guide for implementation ............................................................................17
3.8 Methodology limitations ..........................................................................................17
4 Digital form development ..............................................................................................18
4.1 Analysis of existing monitoring processes ...............................................................18
4.2 Data requirements for progress measurement ..........................................................19
4.2.1 Methods of measurement......................................................................................19
4.2.2 Gates for type D activities ....................................................................................19

vi
4.2.3 Activity group methods of measurement..............................................................20
4.3 Digital DSR development.........................................................................................20
4.4 Focus group ..............................................................................................................22
4.4.1 Activity mapping..................................................................................................22
4.4.2 Progress calculations ............................................................................................23
4.4.3 Industry perspective..............................................................................................24
4.4.4 Recommendations ................................................................................................24
4.4.5 Focus group summary ..........................................................................................24
5 Progress visualisation.....................................................................................................25
5.1 Progress measurement calculation............................................................................25
5.1.1 Data sourced .........................................................................................................25
5.1.2 Activity progress ..................................................................................................26
5.1.3 Activity status.......................................................................................................27
5.1.4 Summary activity progress...................................................................................27
5.2 Dynamic connection in 5D BIM ..............................................................................28
5.2.1 System interface ...................................................................................................28
5.3 Activity progress processes ......................................................................................29
6 Discussion ........................................................................................................................31
6.1 Digital form development.........................................................................................31
6.1.1 Standardisation .....................................................................................................31
6.1.2 User experience ....................................................................................................32
6.2 Progress visualisation ...............................................................................................34
6.2.1 Cloud-based 5D BIM ...........................................................................................34
6.2.2 EVA method.........................................................................................................35
6.3 Feasibility of implementation...................................................................................36
6.4 Limitations................................................................................................................37
6.5 Practical implications ...............................................................................................37
7 Conclusion.......................................................................................................................39
7.1 Future work ..............................................................................................................39
References................................................................................................................................41
Appendices .............................................................................................................................A1

vii
Figures
Figure 2.1 - Typical S-curve (Del Pico, 2013) ...........................................................................5
Figure 3.1 - Three-phased research approach...........................................................................13
Figure 4.1 - Existing activity progress monitoring process......................................................18
Figure 4.2 - Digital DSR: desktop view ...................................................................................21
Figure 4.3 - Entering progress into digital DSR.......................................................................21
Figure 5.1 - Data sourced from databases ................................................................................25
Figure 5.2 - Relational database established in QlikView........................................................28
Figure 5.3 - 5D BIM cost and schedule data visualisation.......................................................29
Figure 5.4 - Semi-automated solution processes......................................................................30
Figure 6.1 - Digital DSR: tablet view.......................................................................................33
Figure 6.2 - Recommended ADC implementation approach ...................................................38

viii
Tables
Table 2.1 - Common data captured within DSRs.......................................................................8
Table 2.2 - Methods of progress measurement...........................................................................8
Table 2.3 - Automated Data Collection technologies.................................................................9
Table 2.4 - Barriers to implementation of ADC technology....................................................10
Table 4.1 - Existing progress data collection and reporting processes.....................................18
Table 4.2 - Defined methods of progress measurement...........................................................19
Table 4.3 - Example: gate breakdown and weightings for type D activity ..............................19
Table 4.4 - Example: matching methods of measurement to activity groups ..........................20
Table 4.5 - Re-engineered processes based on the digital DSR form ......................................22

ix
Abbreviations
AC
ADC
API
BIM
CBS
DSR
EV
EVA
FM/SE
ICT
IT
LPS
MS
PE
PM
PP
PPC
PV
RFID
ROI
WBS
Actual Cost
Automated Data collection
Application Programming Interface
Building Information Model or Building Information Modelling
Cost Breakdown Structure
Daily Site Report
Earned Value
Earned Value Analysis
Foremen and Site Engineers
Information and Communication Technology
Information Technology
Last Planner System
Microsoft
Project Engineer
Project Manager
Project Planner
Percent Plan Complete
Planned Value
Radio-Frequency Identification
Return On Investment
Work Breakdown Structure

1
Chapter 1
Introduction
1.1 Background
The conceptual pillars defining lean manufacturing focus on the elimination of waste and the
optimisation of workflows, the benefits of which have boosted productivity levels within the
manufacturing industry (Forbes and Ahmed, 2010). Large infrastructure construction is
innately complex, and relies on constant monitoring and control to mitigate the repercussions
of variation. Project complexity is increasing, perhaps causing the stagnation in productivity
that is characteristic of the current construction market. Firms are looking toward Lean
Construction principles in an attempt to increase productivity through variation control.
Progress monitoring and control is a key aspect to its implementation, however existing
systems do not enable a fast enough response to issues and changes on-site.
The essence of progress monitoring involves obtaining data directly from the
construction site. Traditionally, this is a labour intensive task requiring manual collection.
Development of technological tools such as Building Information Models (BIMs) and
Automated Data Collection (ADC) are presenting opportunities to automate these tasks, in-
turn improving productivity. Development goes astray by focusing on finding applications of
new technologies within the construction industry, where instead, the focus should be on
finding problems encountered in order to solve them with technological solutions (Navon and
Sacks, 2007). Key research in the field has been aimed at ADC (e.g. El-Omari and Moselhi,
2011; Golparvar-Fard et al., 2015; Turkan et al., 2012), however this is largely
underdeveloped for complex applications such as infrastructure construction. Recent research
is responding to this divide between research and industry (Isaac and Navon, 2014; Matthews
et al., 2015), however it lacks a holistic approach necessary for industry implementation,
particularly within complex infrastructure projects.
1.2 Industry collaboration
This research was industry driven by a large infrastructure project that is in the process of
transferring existing paper-based data collection to a digital format. The study was undertaken
in collaboration with several companies involved with the project, namely Hochtief ViCon,

2
EIC Activities, and Leighton Contractors. The North West Rail Link: Operations, Trains and
Systems project has been elected as a testing platform for future digital expansion within the
group. The project team requested the implementation of a cloud-based BIM solution to
synthesise construction and planning information in an attempt to track the project against
planned baselines. Pivotal to the success of the implementation was an update of existing
activity progress tracking processes. Particularly, replacing the existing Daily Site Report
with a digital form.
1.3 Thesis aims and objectives
This research is an amalgamation of past research efforts into one implementable system. It
proposes a semi-automated, holistic, and flexible solution to data capture such that activity
progress can be viewed and controlled in real-time. The project was used to establish lean
processes of progress data collection to inform Earned Value (EV) visualisation through a
cloud-based database. The study aimed to combine the efforts of semi-automated data
collection and cloud-based BIM-generated EV metrics, providing a means for future
implementation of automated solutions. Namely, the study aimed to:
i. Create a digital tool to capture activity progress data
ii. Use data captured to inform data flows in a semi-automated framework for activity
progress visualisation
iii. Document processes for implementation purposes

3
Chapter 2
Literature review
2.1 Lean construction
Technological advancements have enabled some industries to improve efficiency and reap the
benefits of time and cost savings, while others have failed to capitalise. Efficiency in the
construction industry seems to have plateaued in recent times. To contextualise this, time
wastage in manufacturing and construction are estimated at 12% and 57% of total time
expenditure respectively (Aziz and Hafez, 2013). A large contributor to efficiency gains in the
manufacturing industry is a shift in management ideals from mass production to lean
production principles.
Where mass production considers the sale of a product post-production to leverage
economies of scale through repetitive manufacturing, lean production focuses on long-term
gains, waste reduction, human development, and problem solving through learning and
understanding (Forbes and Ahmed, 2010). The relatively stable nature of manufacturing
makes lean principles readily implementable (Howell and Ballard, 1998); processes are well
established and not overly susceptible to external interference. Despite the obvious benefits,
application of these principles to a construction environment is somewhat problematic.
Processes are highly prone to external interference due to the vulnerability of work interfaces
encountering problems (De Souza and Koskela, 2014). The reason for this high vulnerability
is the nature of project work - projects are highly customised, unique, dynamic, and consume
mass resources (Hao, 2012). This gives rise to an adaptation of lean principles, through lean
construction; where lean manufacturing is implemented through iterative means, attempting
to improve an existing process, lean construction must be applied with the formation of every
project.
2.2 Building Information Modelling (BIM)
BIM is a technological tool to enhance project planning and management by serving as a
container for mass data input and a multi-user access point to this data (Becerik-Gerber et al.,
2012). It makes design information explicit through a multi-dimensional representation more
akin to people’s intuitions, making its intent and program more understandable and evaluable

4
(Penttilä, 2006). Benefits lie in enhanced collaboration amongst stakeholders, causing a
positive Return On Investment (ROI) by reducing errors and omissions (McGraw Hill
Construction, 2014). BIMs are applicable throughout all phases of a project (Computer
Integrated Construction Research Program, 2011). The BIM Use Classification System
categorises BIM use into five categories: gather, generate, analyse, communicate, and realise
(Kreider and Messner, 2013).
While lean principles and BIMs are conceptually independent, synergies between
them appear to suggest that the use of BIM inherently entails a large degree of lean uptake.
Indeed a study by Sacks et al. (2010, p. 973) found 56 interactions between BIM
functionalities and lean principles, the majority of which were linked to “online
communication of product and process information”. Communication links between
individual parties are not isolated channels between separate entities, as is the case in the
current construction environment, but instead all communication channels flow through the
BIM (Ding et al., 2014). This ensures that all communication data is consistent and
accessible, reducing the repetition of work involved in collecting and processing data. A
reduction of unnecessary waste ensures BIM is lean.
2.3 Project monitoring and control
The types of words associated with project monitoring and control are synonymous with the
BIM uses above - collect, extract, generate, analyse, report (Isaac and Navon, 2014). The two
are not necessarily linked, but at the core of each is a desire to use information to
communicate in an efficient manner. Although largely amorphous (Cook, 1997), the concept
behind project monitoring is collecting information about how a project is progressing and
communicating this to others who are in a position to control or modify the progression. The
two go hand in hand; project monitoring informs what should be changed, corrected or
prevented as dictated by project controls. Project monitoring and controlling are
“background” tasks (Project Management Institute, 2013), which should not detract from their
importance - they are necessarily ubiquitous throughout all project management process
groups. However, they remain some of the most neglected areas of project management
(Larson and Gray, 2011), preventing opportunities to reduce waste in the industry.
Construction sites are subject to change; project monitoring strengthens communication
channels (Dave et al., 2014) to facilitate controlling processes that stem the flow and knock-
on effect of changes, creating a more stable environment in line with Lean Construction.
Earned Value Analysis (EVA) is the traditional method of project monitoring and
control and is commonly used in construction. EVA informs project controls by comparing

5
planned schedules and budgets to actual performance. In short, management can assess
whether a project is not progressing as planned with respect to scope, cost and time, and as
such, whether corrective measures are needed. As defined by the Project Management
Institute (2013), there are three dimensions for monitoring purposes.
i. Planned Value (PV) or Budgeted Cost of Work Scheduled is the time-phased
budget, defining physical work that should have been completed.
ii. Earned Value (EV) or Budgeted Cost of Work Performed is the amount of actual
work completed as a measure of the budget. It incorporates percentage complete of
individual work packages in the Work Breakdown Structure (WBS).
iii. Actual Cost (AC) or Actual Cost of Work Performed is the actual, time-phased
monetary consumption of a project.
Tracking EV metrics allows progress visualisation through S-curves shown in Figure 2.1.
EVA necessarily relies on data - it is driven by schedule, cost, and progress data. Tracking
progress within these measures is one of the primary aims of project monitoring.
Figure 2.1 - Typical S-curve (Del Pico, 2013, p. 116)
The BIM uses mentioned identify a space for project controlling through a visual
representation of EVA metrics. Some of the primary benefits of BIM identified in literature
include scheduling, visualisation, project cost, and communication (Barlish and Sullivan,
2012), all of which culminate in a use of EVA with BIM. In relation to lean principles,
improving communication and reducing wastage through repeated data entry validate the
combination and pave the way for implementing lean construction principles.

6
2.4 Progress monitoring
2.4.1 Existing solutions
Progress data informs EVA calculations such that an evaluation of the project’s performance
can be made in line with project control procedures. However, the regularity of progress
measurement often dictates what can and cannot be controlled. Ideally, field personnel
measure the completion of planned tasks through frequent monitoring and data collection in
order to adjust activities in the short term. Being informed by real-time information systems
enhances control. Typical information delivery times, through intermittent progress reporting,
often exceed the time within which controlling processes can be executed to mitigate
deviations (Navon, 2005). The effectiveness of project control is hindered by a slow and
staggered information flow from the construction site to management. Regularly updated data
informs EVA such that schedule deviations and waste can be monitored and controlled to
avoid delays and cost overruns. Due to the infrequent and inconsistent nature of existing data
collection processes, the benefits of project controlling are often not fully utilised.
Data collection in BIMs has two fronts: planning and performance of construction
works (Babic et al., 2010). Planning inputs include schedule developments, activity planning,
resource planning, and cost budgeting (Koskela and Howell, 2008). Digital-based processes
are firmly grounded in ubiquitous software solutions within these domains, and as such
integrating planning information into a tool such as BIM is achievable (Koekemoer and
Smallwood, 2007). Performance of construction work inputs come from the construction site,
namely, monitoring the progress of the project within each of the planning domains.
Capturing data whilst the construction is in progress implores the need for data capture from
the field.
2.4.2 Daily Site Report
The most convenient and well-established way of collecting on-site data for activity
progress monitoring is through the use of Daily Site Reports (DSRs). Data acquisition has
traditionally been paper-based, and integrating captured data into BIMs is made difficult due
to this manual data input. These paper-based forms have become out-dated due to the advent
of their digital counterparts, reasons for which are explored in a study by Russell (1993). The
inherent problems associated with manual data collection are outlined by the study.
Individuals avoid comprehensive data collection due to time constraints, and a stigma that
interprets daily reporting information as incriminating. The cross-section of people filling out
daily reports varies, and as such so do their legibility, comprehensibility, and applicability.

7
Information can be biased, with individuals interested in representing the selective truth for
their own advantage. Field personnel are overburdened by filling out forms, with estimates of
the time spent recording and analysing site data reaching 30-50% (McCullouch, 1997; Navon
and Sacks, 2007). Chin et al. (2005) further developed this research, suggesting that daily
reporting is time consuming and data input is inconsistent. DSRs are standard forms with
blank fields requiring relatively uninformed and free data entry. This creates variability in
everything from activity names, codes, locations and personnel.
In short, insufficient or inadequate information from the construction site contributes
to poor productivity and rework, which can lead to schedule delays and cost overruns
(Matthews et al., 2015). These inherent issues lead to site information remaining relatively
unused as data is difficult to accumulate for current and future project use. For this reason,
progress data is often instead used for litigation purposes regarding claims and other disputes
(Navon and Haskaya, 2006). Both Russell (1993) and Chin et al. (2005), advocate
standardisation as a solution - by integrating planning and control systems, data integrity is
maintained, reducing inconsistency, biased information and overburdening. This enables the
development of the current project status, faster response times in dealing with problems,
enhanced communication, increased schedule updating, and assistance in dealing with claims
(Russell, 1993). The approach in standardising daily reporting information is enabled through
the use of digital forms. Going further, Navon and Sacks (2007) promote real-time data
collection, a currently manual process with potential for automation using ADC technologies.
Their research assessed the information needs for project control to identify the current
shortfalls of monitoring data collection and reporting. Industry responses emphasised the need
to improve communication at the daily resolution, particularly regarding activities.
Integrating data systems ensures that integrity is achieved - by entering data only once
into any one system, the reuse of that data thereafter remains consistent. Through identifying
data needs and sources, repetition of input can be identified and eliminated. Typical data
captured in DSRs incorporate information on activities, material, plant, and labour as
summarised in Table 2.1 (adapted from Abdelsayed and Navon, 1999; Chin et al., 2005;
Navon and Haskaya, 2006; Pogorilich, 1992; Russell, 1993).

8
Table 2.1 - Common data captured within DSRs
Data Group Data
Activity Information Weather and ground conditions
Activity identification
Activity status
Description of work accomplished
Major events
Problems encountered
Receipt of drawings and plans
Material and Plant
Information
Materials arriving to the site
Number and type of equipment
Equipment location
Labour Information General contractor workers by trade
Subcontractor workers
Name and identification of person inputting data
The groupings of data above form three separate avenues of data collection (Isaac and Navon,
2012). Material and plant information is typically captured within delivery dockets completed
on arrival of the product. Labour monitoring involves human resource usage and tracking
labour productivity and involvement through time-sheeting. Already, this duplication of data
defies intended lean construction principles. Activities consume both material and human
resources, however the activities themselves achieve progress through the completion of tasks
within a defined process. Activity information can be directly derived from the Work
Breakdown Structure (WBS) or scheduled activities established in almost all large-scale
projects. Chin et al. (2005) stress the importance of integrity and consistency of data by
integration with schedule information.
2.4.3 Progress measurement
The complexity and uniqueness of construction projects make it difficult to define a single
way of measuring progress. There are several methods considered (Forbes and Ahmed, 2010)
in Table 2.2.
Table 2.2 - Methods of progress measurement
Method of Measure Description
Units Completed Completion based on linear assumption of progression.
Incremental
Milestone
Milestones within an activity’s process have a predefined.
Percentage completion based on a reasonable estimate
informed by previous experience.
Start/Finish Similar to incremental milestone method, however tasks can
be started before others are completed.
Supervisor Opinion Reasonable estimates based on previous experience. Inherent
bias with subjective nature of measurement.
Cost Ratio Progress measured using the ratio of actual expenditure to
forecasted values.

9
Jung and Kang (2007) offer a standardised solution to progress measurement in which
measurement methods are pre-assigned to activities in the WBS. By combining this with the
WBS and schedule, integrity and accuracy of data improves, while time and waste in
repetition reduce. The variability in measurement methods for any particular activity type
triggers the necessity for defined methods of measurement for all activities.
2.4.4 Automated Data Collection (ADC)
An abundance of technologies are available for ADC; Table 2.3 below summarises the
technology currently available on-site (adapted from Navon and Sacks, 2007).
Table 2.3 - Automated Data Collection technologies
Technologies
GPS
RFID
Barcode
Video
Audio
Load
Gauges
Accelero-
meters
LADAR
Materials Bulk     
ETO       
Personnel Interior   
Exterior   
Equipment Building    
Earth-moving     
People-moving 
Activity Progress      
Hand Tools    
Refuse/Waste Materials 
In terms of measuring activity progress, most of these technologies bypass traditional
methods and minimise manual data entry. The inconsistencies, biases, and delays identified
by Russell (1993) as common problems associated with manual data entry, are abolished.
Several studies have developed systems in which progress is measured automatically (e.g.
Chin et al., 2008; Ghanem, 2007; Golparvar-Fard et al., 2015). However there is little uptake
of their methods in industry.
Automation in data collection is lean due to the benefits it provides. By offering
simple and continuous access to a rich, consistent source of information, many of the inherent
wastes in existing monitoring processes are eliminated. Effective progress monitoring helps to
inform project controlling such that variations can be identified and controlled. This makes
the value in implementing ADC technologies undeniable, however a study by Majrouhi
Sardroud (2015) explains why there is little uptake of the technology regardless of these
benefits. Barriers to implementation are outlined in Table 2.4.

10
Table 2.4 - Barriers to implementation of ADC technology
Barriers to Implementation
Cost-related Uncertain ROI
Financial constraints
Investment cost
Unclear benefits of technology use
Poor availability of tools for evaluating benefits of using ADC
Process-related Lack of understanding of the implementation process
Traditional business practice of the construction industry
Technology-related Lack of an Information Technology (IT) infrastructure
Lack of established IT system standards
Lack of perceived suitability of software
Technology immaturity levels
Other barriers Different working practices and resources
High degree of fragmentation due to uniqueness of projects
Culture
Behavioural barriers
Lack of staff
Advances in ADC technologies have accelerated in recent times, driving costs down and
making benefits of monitoring and controlling more apparent. In a survey study, Majrouhi
Sardroud (2015) identified that barriers to implementation of the technology have shifted
from technical problems to cost and process-related problems. Technology maturity levels are
improving, while implementation processes remain poorly understood. Majrouhi Sardroud
emphasises the development of a flow chart and strategic plan to combat this, and a general
focus on processes is stressed (Navon and Sacks, 2007).
In the context of complex infrastructure construction, application of ADC technology
to a wide range of activities is questionable. Their applicability is not universal; each ADC
technology is suited to certain construction tasks on-site. It is difficult to capture progress
completed for activities that do not only involve installing an object or tracking delivery. A
study by El-Omari and Moselhi (2011) presented a control model that integrated several ADC
technologies for the purpose of progress measurement. The narrow opportunity for
implementation was apparent through the inclusion of pen-based computers to collect data.
Although LADAR was used in the system, it was targeted towards quantity activities such as
earthworks. Progress-measureable activities that were not captured within ADC solutions
required manual data entry, which is to be expected. BIM, however, is flexible enough to
accept information input that stems from the needs of organisations. Where current methods
seek to fit technological solutions to business needs, BIM enables organisations to focus on
business processes in order to determine only the ADC technologies that are most suited to
those needs (Navon and Sacks, 2007; Sacks et al., 2010). While El-Omari and Moselhi (2011)
did develop technological solutions to suit project needs, attempting to implement their

11
approach in a complex infrastructure environment is problematic. The detail to which ADC
technology is currently able to measure is largely underdeveloped. Making progress is not
merely installing objects in their intended positions (Matthews et al., 2015); time and money
is expended on preparation, material delivery, formwork, cleaning, and the like. ADC
technologies can only compare actual completion to the planned model; they communicate
whether elements of a digital model exist in that state in real life. A more flexible solution and
focus on processes is necessary for this method to be applicable to a live environment - the
research solely identified the potential for this methods existence. As such, and remaining in
line with the process-related barriers to implementation identified above, ensuring progress
solutions are implementable and documented is essential for continued support of the BIM.
2.4.5 Progress monitoring in BIMs
Not only do the aims of both BIMs and progress monitoring align similarly with
communicating progress, BIMs can be used as the tool to achieve this. Many existing ADC
solutions use BIMs as a platform for their implementation (e.g. Golparvar-Fard et al., 2015;
Kim et al., 2010; Matthews et al., 2015; Toledo et al., 2014). The planning data contained
within the BIM is a useful data source that can be used to communicate progress. It is an
optimal environment to visualise planned and actual data in its context.
Projects are becoming increasingly complex and uncertain (Howell and Koskela,
2000). Implementing flexible solutions not only encompasses ADC technologies suitable for
all progress-measureable activities, but also the free flow of data. Cloud-based computing
provides instant access to an online shared pool of data that can be distributed with little
management (Mell and Grance, 2011). This enables real-time collaboration that extends BIM
use beyond design to construction. Cloud functionality makes progress measurement on-site
more feasible, as live data can be accessed and updated accordingly. However, cloud-based
BIM research lacks insight into how this technology can be implemented in practice (Wong et
al., 2014). A study by Matthews et al. (2015) uses a cloud-based BIM approach to progress
monitoring. Processes are recorded to establish the feasibility of implementation of the system
and documented to continually support the BIM. The research successfully develops an
approachable way of implementing a system for progress data capture using a flexible digital
solution. However no link is made to EVA nor any other data visualisation tool - the data is
not visualised in a BIM.
Several studies used BIM-based data to automatically generate EVA graphs. Kim et
al. (2010) created a system for EVA visualisation through a 5 Dimensional (5D) BIM,
however real-time cloud-based data was not a priority. Data was downloaded in “.xml” form

12
once a month from a web-hosted database, and uploaded to a program to view the 3D model
in conjunction with time and cost data in an EVA graph. Despite the success of the 5D BIM,
again the focus on development did not take into account practicality and opportunities for
implementation. Progress data capture was not mentioned.
Turkan et al. (2012) proposed a web-based real-time tracking system. EVA was
reported successfully, and progress data captured, however this was done through ADC
technology specific to volumetric and linear quantity tracking. There is some mention of
reporting, however a fully automated system was the focus; no distinct progress reporting
system was defined. As such, the unsuitability of automation for some tasks was not resolved.
The research identifies the limitations of the ADC technology used, suggesting that they do
not measure progress on a detailed enough level, being only able to discern installed objects.
The proposed solution was therefore not able to track progress of tasks that were ahead of
schedule - these activities were not included in the 4D BIM and hence not compared to the
baseline. By having flexibility in both progress monitoring tools and mapping of data to the
baseline, these issues can be resolved.
2.5 Summary of analysis
The analysis of literature indicates that an opportune point of similarity exists between lean
construction principles, BIMs, and project monitoring. Existing solutions attempt to unify
these concepts through automation. This technology is underdeveloped, at least in the context
of complex infrastructure projects. There appears to be a missing link between research
efforts and industry. A holistic approach to progress monitoring that considers both data
capture and visualisation is as yet unexplored. Digital forms seem to be the only realistic
approach to standardise progress data capture in the current market. Likewise, EVA is the
only workable and widely understood method to communicate and visualise this progress.
Synthesising these concepts into a single solution may provide the link from lean principles,
BIMs and project monitoring, to controlling, which existing solutions fail to provide to
industry.

13
Chapter 3
Methodology
3.1 Research approach
The methodology is outlined in three distinct phases as provided in Figure 3.1, namely an
investigation into research and industry, development and interpreting feedback, and
visualisation and process documentation.
Figure 3.1 - Three-phased research approach
Phase I: The first phase of the study focused on developing a course of action for the
subsequent phases through investigative means. This included determining existing solutions
to progress tracking by analysing literature, and reviewing existing business processes and
software. The Daily Site Report (DSR) was identified as the candidate for digitalisation, as
this was an existing platform for progress monitoring.
Phase II: A progress data collection tool was developed for the needs of the project. The
parameters for its development were established in the preceding phase, namely the data to be
captured and the processes to be supported. A pilot form was developed and distributed on-
site. The digital form needed to streamline processes utilising progress data, and as such, an
industry focus group was held. The results of this phase were analysed for refinement of the
form and determination of the methodology for phase III.
Phase III: Real-time communication between site personnel and management was achieved
by connecting progress data captured within the developed digital DSR with schedule

14
activities and cost data. These were linked to a 5D model using specialised software. From the
initial phase of research, Earned Value Analysis (EVA) was identified as the suitable
communication tool for progress information. A guide was subsequently developed to inform
users of the processes to follow in implementing the system.
3.2 Analysis of existing monitoring processes
Information regarding processes was sourced from the project. Existing progress monitoring
processes were determined in collaboration with managers and engineers through multiple
consultations. Typical time expenditure was recorded by on-site personnel, based on
opinionated feedback, to inform opportunities for implementation. The investigated processes
informed the research plan and determined how a semi-automated solution could be used by
the project. Ultimately, the information required, and the opportunities to automate processes,
were resolved. The existing paper-based DSR was identified as the candidate for digitalisation
(Isaac and Navon, 2014).
3.3 Progress measurement tool
Specific progress measureable items and measurement methods were defined (Forbes and
Ahmed, 2010). Of particular interest were milestone-based progress measurements, which
were assigned percentages for milestones reached within the activity. The percentages of each
milestone were determined in collaboration with the project and associated companies. The
methods of measure were assigned to activity groups created to cluster similar activities
provided in the WBS, a similar approach of standardisation to Jung and Kang (2007). This
was done to simplify mapping of progress measureable activities to their relevant measure
type. The existing paper form was analysed to determine what was to be included in its digital
counterpart, however as mentioned, the activity progress tracking component was the focus of
this study.
Several requirements were defined by the project in developing the digital form.
Primarily, the form was to fit in with existing software infrastructure - namely, using data
sourced from an online Microsoft (MS) SharePoint site hosted on a MS SQL Server with a
Standard licence, and similarly publishing captured data to this database. The MS SharePoint
site acted as a central repository for progress, cost, and schedule data. Access was to be
granted on a tablet device to allow use on-site, with Apple iPad Air 2 devices supplied by the
project, as well as online through the MS SharePoint site. The form had to be useable offline,

15
as areas of the construction site had limited to no internet access. The Formotus mobile
application was used to circumvent limited internet access.
The form was developed in MS InfoPath and was to be implemented and used by the
Foremen and Site Engineers (FM/SE) who typically complete the paper-based DSR. A pilot
form was developed and used on-site such that constructive criticism could improve the form
in a process of iteration. Such feedback was provided through consultations with FM/SE.
3.4 Focus group
Focus groups draw upon respondents’ views in a group setting, allowing respondents to take
initiative in their detailing of information and enabling the researcher to elicit large amounts
of information in a short period of time (Gibbs, 1997). They are particularly useful in
exploring consensus on a given topic, and balance rigour with pragmatism (Darke et al.,
1998). A focus group was a suitable qualitative interviewing approach in light of the below
research aims. A semi-structured focus group was conducted with the aim of informing
further development with respect to implementation and progress calculation. The focus
group was directed towards personnel responsible for progress calculation - those who used
progress data to calculate EVA metrics required for project control. The participants were
aware of project control processes and progress data capture. The interview participants
included a Project Engineer (PE), Project Manager (PM), Senior Project Manager, and BIM
Engineer.
The focus group was conducted with the following aims:
i. To understand the relationships between the WBS, Cost Breakdown Structure
(CBS), and payment items
ii. To determine the current methods of progress calculation
iii. To gain insight into recommended approaches in achieving process automation
iv. To recognise an industry perspective on the development
Four general areas of discussion were established in line with the above research aims. The
recording of the focus group was transcribed and coded for meaning, and then analysed in
light of the research questions and focus group aims. Methodological rigour was maintained
by cross-coding the transcript and through additional collaborative consultations with experts
in the field (Paulus et al., 2008).

16
3.5 Activity progress calculation
The digital form was created to track progress for progress measureable activities or tasks. As
such, actual progress accumulated per activity was necessarily calculated. Likewise, progress
of each activity at each successive level of both the WBS and CBS was required by the
project for a number of purposes, namely determining percentages complete for payment
claims and for general project controlling purposes. To enable this, a relation between the two
was determined. The sources of data established in the focus group defined how to map
schedule and cost activities so as to link time and cost data.
Existing activity progress on the project is communicated through EVA and as such,
on-site personnel and management are familiar with these metrics. MS Excel was used to pool
schedule, budget, progress, and actual expenditure data, as required for EVA metrics, from a
number of online databases by creating a dynamic link such that data could be refreshed in
real-time. The Power Query add-on enabled OData feed connections to the online databases
and was henceforth used to calculate progress at each level of the WBS and CBS as required.
This was then made viewable through graphs published on the MS SharePoint site to give on-
site personnel immediate feedback as to the progress of on-site activities. The MS Excel file
was stored on the online MS SharePoint site for multiple user access.
3.6 5D model development
Visualisation of the collected data through the lens of a 5D model was important in
understanding the impact of cost overruns and schedule delays on surrounding activities (Kim
et al., 2010). In order to make data visible and useable for project controlling, such that
management decisions could be made, incorporation of EVA calculations into the BIM was
necessary. ViCon 3DBIS, a specialised software package developed by Hochtief ViCon, was
used as the 5D BIM platform. A 3 Dimensional (3D) model was provided by the project.
Using a QlikView scripting interface, data was imported from the MS Excel file created and
stored on the MS SharePoint site, as well as the WBS, payment items, and schedule data
similarly accessed from the MS SharePoint site. As opposed to recalculating progress
calculations within ViCon 3DBIS, calculations were taken directly from the Excel file so as to
avoid excess loading times - the 5D BIM operated quickly. As such, the Excel file needed to
be downloaded, refreshed, and re-uploaded to ensure the 5D model had the most up-to-date
data. The structure of the model was vital to the interoperability of data. The object-based
model needed to again be mapped to the schedule so that incoming progress data could be
assigned to a location within the model.

17
3.7 Process guide for implementation
Informed by feedback captured in the focus group and subsequent development,
implementation of the semi-automated solution to progress monitoring was documented.
Defining and documenting processes allowed full implementation of the progress monitoring
solution (Majrouhi Sardroud, 2015; Matthews et al., 2015). Informing those involved in the
progress monitoring process of how to interact with the digital form and 5D BIM was critical
for the success of the proposed solution’s implementation.
3.8 Methodology limitations
Using MS Excel was necessary to provide immediate feedback to the FM/PE on-site -
installing ViCon 3DBIS for all on-site personnel was unrealistic. The real-time aspect of the
solution relied on frequent refreshing of the data file developed. However, an in-browser
refresh function for MS Excel files with Power Query-based OData feed connections is not
enabled in MS SharePoint. Initial trials of the MS Excel solution used the Power Pivot add-on
for MS Excel. Installing the Power Pivot add-on for MS SharePoint enables in-browser
refresh of MS Excel files with OData feed connections, however as the existing MS
SharePoint site was hosted on an MS SQL Server with a standard licence, this was not
possible. An enterprise licence is required to authorise this install. An added process step of
downloading, refreshing, and re-uploading the file was necessary before progress could be
viewed in real-time. Like Matthews et al. (2015), implementation of the innovative
technological solution was constrained by the delivery strategy already adopted by the
project. However the terminology itself is perhaps misleading - whether ‘real-time’ can ever
truly correspond to ‘continuous’ when applied to progress monitoring in construction settings
is questionable. In reality, the solution is only ‘real-time’ in so far as providing regularly
periodic updates of progress. Limitations inherent in a semi-automated, human-driven system
render real-time progress monitoring idealistic. In truth, real-time updates can only coincide
with automation.
Typical time expenditure for both existing and developed processes were not
rigorously tested through the proposed methodology. Times are recorded as estimates based
on the respondent’s experience, which are subjectively opinionated and prone to error.
Likewise, milestone-based weightings were solely reliant on the experience of the select few
consulted within the project. The rigorous testing of these weightings is beyond the scope of
this research.

18
Chapter 4
Digital form development
4.1 Analysis of existing monitoring processes
The project used a paper-based DSR to manually record progress (Appendix A). Existing
processes and their time expenditure were determined in collaboration with the project.
Table 4.1 - Existing progress data collection and reporting processes
Conventional DSR Process Time required (mins)
On-site processes 28
FM/SE makes handwritten notes of daily shift activities 5
Write Daily Site Report on PC 20
Send report to reporting manager 3
Off-site processes 40
Reporting manager checks and collects missing documents 30
Reporting manager produces daily client report (time per
single day report)
10
Figure 4.1 - Existing activity progress monitoring process
Significant time expenditure was observed both on-site and off-site as shown in Table 4.1.
Converting handwritten notes into a digital format created duplication. Opportunities to
digitalise the DSR were realised. Likewise, collection of DSR documents and report

19
production was time-consuming. The conventional DSR process above was placed in the
context of the entire activity progress monitoring process in order to inform future
implementation, shown in Figure 4.1.
4.2 Data requirements for progress measurement
In order to successfully digitalise the existing DSR form, several requirements were met such
that data provided by the project could be used within a digital form.
4.2.1 Methods of measurement
With the intention of standardising progress measurement, several methods of measure are
identified Table 4.2 in line with the review of literature.
Table 4.2 - Defined methods of progress measurement
Type Method Description
A 0-100%
Complete
Until the activity is complete, the associated progress will remain at
zero. Upon completion, progress is deemed to be 100%
B 50-50%
Complete
When the activity is started, the progress is evaluated as 50%, and
when complete, progress is deemed to be at 100%. Any progress in
between is not considered.
C Percent
Complete
A percentage value between zero and 100 is progressively assigned.
This progress measurement is at the discretion of the supervisor.
D Interim
Milestone
A set of milestones or gates are predefined for specific commonly
executed activities. Each milestone has an associated percentage.
Between each milestone, no progress is recorded.
E Yard
Stick
Depending on the activity at hand, a unit of measurement is defined
and used to quantify the work complete. Physical work complete is
measured to the highest degree of accuracy possible.
4.2.2 Gates for type D activities
Through extensive collaboration with industry partners, common gate structures and their
associated progress percentage for Type D activities were formulated. An example is
provided in Table 4.3; a comprehensive list is provided in Appendix B.
Table 4.3 - Example: gate breakdown and weightings for type D activity
Process & Process Gate Breakdown Gate Weighting
Concrete (FRP) 100%
1 Minor Excavation 10%
2 Blinding Concrete 10%
3 Rebar 25%
4 Formwork 25%
5 Pour Concrete 25%
6 Strip & Backfill 5%

20
4.2.3 Activity group methods of measurement
All activities defined within the WBS were matched to an activity group, dependent on the
type of activity. These activity groups were assigned methods and units of measure such that
progress could be monitored for activities within each activity group. An example is provided
in Table 4.4; a comprehensive list is provided in Appendix B.
Table 4.4 - Example: matching methods of measurement to activity groups
Activity Group Method of Measurement Unit
Backfills Type E m3
Cabling Type D lm
Demobilisation Type C %
Energisation Type A ea
4.3 Digital DSR development
The digital form was created for use on a desktop, tablet, and mobile device. The desktop
view is shown in Figure 4.2. The tablet and mobile views are in Appendix D. This form was
published for use through all mediums, and as such was installed on the MS SharePoint site,
and was made available for install through the Formotus application. Progress measurement
was the focus, however in updating the existing form, several data capture requirements were
maintained, such as the Foreman’s end of shift checklist.
Consultations with FM/SE indicated difficulties in using the pilot DSR form. Aptitude
with technology was a problem for some, which led to a general dissatisfaction with the
imposed development. Navigating for activities through the WBS was unfamiliar and
criticised. Adjustments to the pilot form were made in light of the feedback received.
Note: the digital form presented in Figure 4.2 is the final iteration of its development after
feedback provided by FM/SE. The pilot form is attached in Appendix C.

21
Figure 4.2 - Digital DSR: desktop view
Users entered progress dependant on the type of activity, selected through the activity groups
established and the detailed location of that activity within the site - this information comes
from the WBS. The process is established in Figure 4.3
Figure 4.3 - Entering progress into digital DSR

22
Time expenditure for re-engineered digital DSR processes in Table 4.5 was
determined in collaboration with the project, in particular, through the pilot implementation of
the form. Feedback from FM/SE completing the form on-site informed the effectiveness of its
implementation from a time-saving point of view.
Table 4.5 - Re-engineered processes based on the digital DSR form
Digital DSR Process Time expected (mins)
On-site processes 10
Fill out structured digital form on mobile device 5
Finalise digital form on mobile device 5
Automated sending 0
Off-site processes 5
Quality check and approval of received daily reports 5
Automated assembly of daily report 0
In comparison to the initial paper-based DSR processes, significant time-savings were
observed both on-site and off-site. Completing a structured digital form reduced duplicated
work - all previously handwritten notes were effectively converted into a digital format in the
one process step. The digital DSR forms were electronically stored on the MS SharePoint site
ready for review. The daily reports were automatically assembled for publishing. Time
savings were estimated through this process at 53 minutes per day. Assuming 6 sites
operating on any one day and 23 working days per month, the time savings accumulate to 148
working days per year.
4.4 Focus group
The success of the digital DSR not only depended on its initial development and ability to
query data from external sources in a singular interface, but also whether available activity
progress data was useful. The focus group addressed these issues as per the research aims, and
four recurrent themes were explored through a qualitative analysis by grouping the main ideas
discussed. The coded transcript is provided in Appendix E.
4.4.1 Activity mapping
As expected, it was identified that the schedule and cost breakdowns were separate entities.
Despite covering the same project, the two breakdowns did not match: “the WBS doesn’t talk
to the Cost Breakdown Structure, CBS”. This incompatibility made it difficult to map costs to
their schedule.
The level of detail within each breakdown structure differed. Costs were broken down
into items that could be budgeted, and actual costs measured against. Schedule activities were

23
broken down into progress measureable items, and as such were required in more detail: “the
problem is with cost codes, you want to keep that to a realistic amount of things to group
together to make it not too much detail. But with the program obviously we want to break it
up into more detail”. Ensuring a level of detail at which costs could be aggregated to map to
schedule activities was important in calculating EVA metrics for each of these activities.
Schedule activities needed budgeted and actual costs in order to make this possible.
Due to the identified lack of cohesion between the WBS and CBS, the approach in
doing so was to laboriously calculate costs on a case-by-case basis: “we’d look at the
progress claim and see how the activities are broken up, and then we’d work out which ones
of these cost centres relate to which of those progress items, and then we’d add them together
and do the percentages, manually at the moment”.
4.4.2 Progress calculations
Physical calculation required quantity data to establish EVA metric calculations. The source
of this data was necessary for both the original calculations carried out by the engineers, as
well as for EVA calculations under the proposed method identified in Phase I of the study. As
such, the delivery of this quantity information was established: “that comes from survey
information and an original strata model that was developed based on the borehole logs to
work out how much of each type of material there was”. Likewise, the source of cost data was
needed to feed the proposed methods of calculation. Forecast costs - “market research,
quotes” - were distinguished from actual costs: “forecast is just our budget…we are putting
actual cost into ROVER and tracking those”.
There was a consensus that existing calculation methods were complex and confusing.
Calculating budgeted and actual costs, and mapping these costs to schedule activities in order
to submit a progress claim, was a task that occupied a significant amount of time: “it’s a
pretty big effort”. The complexity of this process, and the back-and-forth calculations and
mapping involved, detracted from the actual engineering work to be performed on-site:
“we’re accountants, we’re not really engineers”. An example calculation was explained for a
Capping Beam (Appendix E). The existing approach was primarily beneficial in justifying
expenditure with the amount of progress completed to date: “it makes it easier to justify that
you’ve spent this money, and you’ve earned this value”. Justification was important when
deviations from the forecast were experienced.

24
4.4.3 Industry perspective
A proposed course of action for mapping the WBS and CBS sparked a positive response. By
defining a level of detail such that cost data and activity progress could collate and match,
EVA metrics could be calculated without restricting the engineers nor changing either
breakdown structure: “people can still have the freedom to define activities how they need
to…and you can make these talk to each other a lot better”. The group deemed the accuracy
of proposed progress calculations to be sufficient by being justifiable and explainable: “that is
close enough to this to make sense”.
4.4.4 Recommendations
The mismatch of activities between the WBS and CBS was attributed to problems during the
tender phase of the project: “this needs to be done at tender, which it wasn’t done”. Ensuring
the WBS and CBS are compatible from the outset would avoid problems with the mismatch
of breakdown structures.
Although the method of progress measurement proposed in Phase I of the study was
agreed upon as a feasible approach, type D activities did not have a sufficient enough gate
structure to encompass all progress measureable milestones: “[we’ve] got about 10 steps,
you’ve got about five”. A more rigorous approach to defining gates for each type D activity
was recommended.
Semi-automation was seen as a “good intermediary step”. Some data entry was
inevitably required, but the advantages of automated calculation was acknowledged: “if that
part of it could all be automated, that’ll save us heaps of time”.
4.4.5 Focus group summary
The focus group responded to the research questions it set out to answer. Several key points
were discussed.
i. The WBS did not correlate with the CBS due to their isolated development.
ii. Giving PEs the agency to define level 5 activities to map to the CBS would
circumnavigate most mapping issues.
iii. Existing progress calculations were complicated and time-consuming.
iv. The proposed solution was adequately justifiable and thus well received.
v. Type D activity gates were insufficiently defined.

25
Chapter 5
Progress visualisation
5.1 Progress measurement calculation
5.1.1 Data sourced
Informed by the focus group, the existing software infrastructure was realised. Data required
for cost and schedule progress tracking was sourced from a variety of databases, as outlined in
Figure 5.1.
Figure 5.1 - Data sourced from databases
Establishing a coding system was paramount to the interoperability of data. It was found that
costs and schedules were established separately - the WBS was defined as per the work to be
done, whereas the CBS was defined as per the likely expenses. In light of this, the level 5
schedule program of the WBS, which were progress-measureable activities or tasks defined as
required by project engineers to carry out the defined level 4 program, was matched to the
level 2 cost breakdown. The existing many-to-many relationship between the two was
problematic, Project Planners (PPs) reorganised the schedule to ensure a one-to-many
relationship. Cost codes and associated budgeted rates as defined in the tender phase of the
project were entered directly into MS SharePoint.
The CostX system was the source of cost code quantities, to be entered by PEs.
Material and plant costs were tracked digitally through the ROVER system. Subcontractor

26
costs were issued monthly via email and as such were kept track by PEs and entered into the
MS SharePoint site. Progress data was extracted from submitted DSRs using a SharePoint
Designer workflow (Appendix F) and listed in MS SharePoint as per the measurement type.
Primavera P6 provided scheduling data. All data was pooled into Excel using Power Query M
code (Appendix G).
5.1.2 Activity progress
In order to define the EVA metrics required, percentage complete of all activities in progress
needed to be defined. Types A, B, and C were inclusive of a percentage complete measure;
type D activities used a gates-based system to calculate percentage complete; type E activities
measured quantities complete, which was measured against a reference budgeted unit rate to
calculate EV metrics.
All type A, Type B, and Type C activities had percentage complete calculations
included in the initial data captured - within the DSR at the discretion of the FM/SE.
Percentage complete was accumulated to the report date for each entry.
Activity EV ($) = Accumulated Progress (%) × Budgeted Value ($)
Type D activities followed a rigid gates-based percentage complete accumulation,
however activities were further subdivided into objects. Engineers were able to assess
progress of all objects that fell under an activity, all of which followed the same gate
structure. Activity progress was an accumulation of each object’s percentage complete, as
calculated from the gate-structure. Percentage complete was calculated by determining the
previous report date’s accumulated gate weighting, and subtracting it from the current report
date’s accumulated gate weighting, specific to the object. This accommodated for the user
skipping gates for an object - the correct percentage complete was calculated.
Object Progress (%) = Accumulated Progress - MAX (Previous Accumulated Progress)
Object EV ($) = Object Progress (%) × Budgeted Value ($)
Activity EV ($) = ∑ Object EV ($)
All type E activities used a quantity-based measurement that related to the budgeted
quantity entered in the MS SharePoint site. However, budgeted unit rates were the prevailing
factor for calculations. They were used as opposed to budgeted final values to deal with
incorrect estimated quantities - the likelihood that actual progress exceeds or falls short of
estimated quantities was high. Using budgeted quantities to calculate percentage complete
was inappropriate here as once the budgeted quantity was reached, the EV would reach a
maximum. In reality, this is not the case.
Metric EV ($) = Metric Quantity (units) × Budgeted Unit Rate ($)

27
Activity EV ($) = ∑ Metric EV ($)
All entries were appended into one table in order to calculate PV and AC metrics. The
benefit of this approach is that for activities that extend across several measurement types, PV
and AC measurements are not duplicated. AC was aggregated for all entries between
successive entries of activity progress. This allowed final accumulation of AC to avoid
duplication. Budgeted costs for PV calculation were aggregated for each activity.
Activity AC ($) = Accumulated AC ($) - MAX (Previous Accumulated AC)
Duration to Date (days) = Report Date - Start Date
Accumulated PV ($) = Duration to Date (days) ×
𝐴𝑐𝑐𝑢𝑚𝑢𝑙𝑎𝑡𝑒𝑑 𝐵𝑢𝑑𝑔𝑒𝑡𝑒𝑑 𝑉𝑎𝑙𝑢𝑒 ($)
𝑇𝑜𝑡𝑎𝑙 𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛 (𝑑𝑎𝑦𝑠)
Activity PV ($) = Accumulated PV ($) - MAX (Previous Accumulated PV)
Time-phased graphs, filterable by activity or associated cost codes, were created in the Excel
file, which was stored on the MS SharePoint site for multi-user access. The graphs were
published and viewable directly through the MS SharePoint webpage to give PEs direct
feedback on activity progress. ViCon 3DBIS is a management tool and was thus only required
by those in a position to control the project. Both, however, used the same data to
communicate progress
5.1.3 Activity status
The status of metrics and objects within Type D and E activities largely determined the status
of an overall level 4 activity. Activity status parameters included “Not Started”, “In Progress”,
and “Completed”. If any object or metric within an activity was currently set to “In Progress”,
the whole activity reciprocated. If all objects or metrics were “Completed”, the activity was
set to “Completed”. Likewise, if all objects or metrics were “Not Started”, the activity was set
to “Not Started”.
5.1.4 Summary activity progress
Activity progress was accumulated to level 4 of the schedule - summary activities. This
informed EV for progress claims. All EVA metrics were calculated by accumulating their
associated level 5 activities.
Summary Activity EV ($) = ∑ Activity EV ($)
Summary Activity AC ($) = ∑ Activity AC ($)
Summary Activity PV ($) = ∑ Activity PV ($)

28
5.2 Dynamic connection in 5D BIM
The 5D model sourced data from the Excel file and WBS lists stored on the MS SharePoint
site. A dynamic link was created using QlikView coding (Appendix H) such that data was
refreshable. Level 4 schedule activities were linked to individual objects in the 3D model.
Progress calculations from the Excel file were mapped through activity codes to the WBS
such that selection of specific activities by the user was more easily facilitated. Likewise, the
most recent activity statuses calculated from the Excel file were linked directly to activities
under the WBS. All links are viewable in Figure 5.2.
Figure 5.2 - Relational database established in QlikView
5.2.1 System interface
Real-time data was viewable through the two-window interface provided in ViCon 3DBIS,
shown in Figure 5.3.

29
Figure 5.3 - 5D BIM cost and schedule data visualisation
EVA graphs were created from the available metrics and calculations. A colour scheme was
created for activities flagged as “Not Started”, “In progress”, and “Completed”. Interaction
with the 3D model allowed users to select single or groups of objects, and view the cost and
time progress specific to those objects through the EVA chart and schedule progress rendered
3D model. Conversely, users could use parameters within the WBS to reduce the list of
activities to only those required, and view them in isolation or in the context of the entire site,
while viewing their associated cost and time progress.
5.3 Activity progress processes
In accordance with implementation, processes were necessarily developed to determine how
the system fits in with existing software infrastructure and business processes.

30
Figure 5.4 - Semi-automated solution processes
All users interact with the solution system as described in Figure 5.4. Using this, a guide was
developed to inform users of the process. The process guide is provided in Appendix I.

31
Chapter 6
Discussion
Development of the digital form and the integration of data into the progress visualisation tool
were successful. The relevance of this to the existing construction market is analysed in the
context of current research.
6.1 Digital form development
Attempts to measure progress across construction sites have underestimated the complexities
inherent in large-scale infrastructure. The developed form adopts the aims of project
monitoring, to collect activity progress data in line with lean construction principles. This is
not a novel approach, with ADC technologies falling under the lean brand, however a focus
on a holistic, flexible, tablet-based digital DSR is undocumented in the literature. Of primary
importance for successful implementation was an assessment of standardisation, and user
experience.
6.1.1 Standardisation
The transformation to digital means of data capture stresses standardisation such that data can
be used for their intended purposes. Of course, existing processes define such structures from
the outset through the WBS and CBS, and the cost and schedule data flow to and from each.
However the two do not necessarily correlate. In this case each was developed in isolation,
which caused problems for being able to measure progress on WBS activities, and ascertain
cost data for these. In attempting to map the two breakdowns, a many-to-many relationship
was observed. Databases rely on a single direction of movement; that is, by definition, they
strictly understand one-to-many relationships. This hindered the development. As such, it was
necessary for PPs to restructure the WBS, and PEs to laboriously map it to the CBS. The
construction phase is not the desired environment to implement a digital solution as proposed
- the inherent constraints render this difficult (Matthews et al., 2015).
Standardisation of progress measureable activities was a less clear determination - the
flexibility required on-site due to the complexity of work required a less structured affiliation
with scheduled activities. Initial attempts to measure progress through the pilot digital DSR

32
indicated that activities were often not adequately refined to meaningfully measure progress.
This was also found in the study by Turkan et al. (2012), however the flexible nature of the
proposed solution lent itself to accommodating for the measurement of a wide range of
activities. PEs were given the space to define progress measurable tasks as they saw fit while
ensuring that they related back to the standardised WBS. This standardised the activity
progress measurements in the digital DSR.
Methods of measure replaced existing calculations to provide a standard, predictable,
and simple solution to progress measurement. Existing calculations were unnecessarily
complex - PEs noted the significant time and effort spent in engaging with complex EVA
calculations. The accuracy of the proposed methods of measure was not analysed, however of
primary importance to PEs in spite of accuracy was the ability to comprehend and justify
calculations. They appeared to be more concerned with being able to prove progress rather
than to accurately portray it. This fits in with their role as monitors of progress. Where control
seemingly relies on regular and accurate progress communication, progress monitoring in and
of itself seeks to communicate that progress whether accurate or not. It is not necessarily in
the best interests of the communicators to ensure the approach to measurement is rigorous as
they are not necessarily controllers themselves. Whether this is significant should be subject
to further research as it is necessary to postulate to what degree accuracy is useful in serving
project controlling purposes.
6.1.2 User experience
The design of the tool was pivotal to a positive reception. The pilot form was scrutinised for
being too complex and confusing for ease of use on-site. Primarily, the identification of
activities through the WBS was unfamiliar to FM/SE. Initial efforts to cater for this used a
four-week look ahead table within the form (Appendix C) for FM/SE to locate activities and
their associated WBS parameters such that these parameters could be entered in the progress
table to again find the activity. This was a meandering approach. The final digital DSR
development simplified this process by using the activity groups already established for each
activity. These categorised activities into understandable clusters. Consequently, activities
were chosen by selecting activity groups and detailed location. This was sufficient to narrow
down the activity list to a manageable select few.
On that note, simplicity was important in ensuring FM/SE were not overburdened, as
forewarned from existing literature (Chin et al., 2005; Russell, 1993). FM/SE were found to
regularly update repeated information on consecutive days. Using a template specific to users
meant simpler and less repetitive data capture on-site. Similarly, the tablet and mobile views

33
reduced data fields to only those required for activity progress monitoring, as shown in Figure
6.1. Again, users were not overburdened with excessive data entry.
Figure 6.1 - Digital DSR: tablet view
Allowing users offline access in remote areas of the construction site by preloading data into
the form was convenient, however the most updated data was not able to be queried from the
MS SharePoint site in this process. Convenience was a focus of the digital form’s
development. Having standardised data entry in a digital format reduced free text data capture
such that FM/SE did not have to describe progress in prose (Russell, 1993). Railroading users
in this way meant that the data captured was useful, however in a similar vein, it was not
necessarily practical. In particular, by the complexity of planned works requiring a more
refined level of the WBS to be tracked against, elements within level 4 activities needed to be
tracked separately. On a large infrastructure project, the number of activities worked on at a
site can be numerous, let alone tasks within those activities. The proposed design runs the risk
of obliging FM/SE to track a large amount of tasks through the digital form. Perhaps
completing this form on a computer device is more practical, however needing handwritten
notes to do so guarantees duplicated work. Regardless, the form spans both tablet and
computer-based mediums and as such can cater for such circumstances.
Emulating the existing DSR meant that FM/SE were familiar with the digital form
from the onset, smoothing the transition to the proposed system. In addition to tracking
activity progress, labour and material delivery information was included in the final digital
form development. Despite similar approaches as outlined by Navon and Haskaya (2006) and
Chin et al. (2005), labour and material delivery data capture are irrelevant here. Tracking
material delivery through daily dockets entered into the ROVER system, and having
personnel login to their workstations through the Onsite Track Easy solution already
implemented on-site, meant data was collected twice, disregarding lean construction

34
principles. In attempting to inform lean construction, modern progress monitoring processes
and solutions themselves need to avoid waste.
6.2 Progress visualisation
6.2.1 Cloud-based 5D BIM
Issues in data integration are frequently encountered in ICT systems. Existing solutions in
literature necessarily overcame interoperability issues in attempting to collate data (Matthews
et al., 2015). Different data formats and file types make it difficult to access data, particularly
in automating data transfer. Application Programming Interfaces (APIs) allow databases to
communicate, but they need to be developed for each software package interface. MS
SharePoint gets around data interoperability issues by acting as a central data repository.
Software vendors only need one API to MS SharePoint, a commonly used system, to integrate
their data systems. ViCon 3DBIS is able to mine this data once it is in MS SharePoint, acting
as a cloud-based BIM. This allows multi-user access to the data crucial to communicating
progress. In order to view this in a BIM, users needed specialised software installed on their
desktop computer. However, as was the nature of the arrangement with the software vendor,
providing the service to all involved in the progress monitoring process was cumbersome and
impractical. Viewing data outside the context of the BIM was made available through the
cloud for those attempting to communicate progress. Those reliant on the BIM to understand
progress on-site, were given access to the ViCon 3DBIS software package. In allowing a
wide-spread solution for industry, alternative BIM viewers are assessed through those utilised
in research. Several progress monitoring solutions use specialised software to communicate
progress (Kim et al., 2010), however software such as Autodesk® NavisWorks® is
ubiquitous in large-scale infrastructure. Matthews et al. (2015) advocate using the
iConstruct™ plug-in to align the breakdown of the model to the tasks within the schedule.
The software is not the focus of either study - it is unanimously understood that by
establishing correct data flows, any multi-dimensional BIM viewer is applicable so long as
data is matched as per conventional database structures.
Kim et al. (2010) suggest that viewing cost and schedule data in the conventional
sense, through text and tables, is difficult to understand and captured information is often
neglected. The results of this study indicate a drastic improvement in visualisation by
combining this data with a 3D model, however like Kim et al.’s study, it fails to quantify this
improvement. Regardless, the theoretical benefits are realised. Being able to visualise the

35
flow of work in progress allows the direct application of lean techniques that make modern
manufacturing processes successful (Sacks et al., 2009).
Real-time data is visualised through the 5D model. Matthews et al. (2015) promote
real-time project monitoring in developing strategies to improve workflows and mitigate
rework and delays. However the established processes in the construction-phase of the project
were a significant obstacle to interoperability. This reduced the effectiveness of real-time
information transfer. Interoperability issues in this research were circumnavigated as
previously discussed. In contrast to Matthews et al.’s study, the cloud-based database used
was compatible with existing software systems and as such enabled real-time data transfer.
Progress data visualisation times were reduced from the weekly progress report to almost
instantaneous viewing capabilities, facilitating the coordination process as found by
Golparvar-Fard et al. (2009).
6.2.2 EVA method
Solutions to communicating progress data vary in the modern context. Well established
methods such as EVA are perhaps being phased-out by those that give significance to
workflow. EVA is centred around the assumption that activities are not interdependent (Kim
and Ballard, 2010). In reality, the consequences of such a narrow-minded view results in
lower productivity achieved by the whole system. In spite of this, visualising progress through
EVA was needed in the development as industry professionals were already familiar with the
concept. In avoiding mass overhaul and overwhelming those involved, the research proposed
progress visualisation through strictly non-lean methods. Lean construction principles were
sacrificed in favour of simpler implementation, however the application of EVA in the
context of BIM argues the contrary.
The results of the development indicate that EVA metrics of singular or groups of
activities within their context, may provide an understanding of workflow. Zhang et al. (2014)
followed this notion to suggest that EVA can inform the adjustment of work to achieve steady
workflow. The 5D model allows users to interpret progress in relation to the activities around
it. Naturally, as one activity is delayed, it affects those that immediately follow it. By
understanding localised EVA parameters within a BIM, we can navigate to the root of the
problem. In fact literature fails to provide a solution to visualising progress with respect to
workflow. It is inherently difficult to analyse workflows and identify issues hidden within
them, particularly when those workflows are themselves variable.
The Last Planner System (LPS) gives credit to workflow by accounting for lack of
short-term knowledge and weekly planning (Koskela et al., 2010). Workflow measurement is

36
an underlying principle analysed by Koskela (2000) - the focus of monitoring workflow
through measurement involves reducing the risk of variability propagation downstream by
encouraging continual assessment. This is seemingly in line with the development, with both
being derived from lean principles. The measurement tool responsible for progress tracking in
the LPS is the Percent Plan Complete (PPC) index. Priven et al. (2014) define it as almost the
only measure of workflow stability in planning, but it does not communicate stability in
progress. The PPC method alone does not cater for workflow visualisation - perhaps in the
context of BIM, this method will yield similar results. Yet the method of visualisation is
almost irrelevant. Ensuring the data is captured from the construction site allows data flows to
communicate progress through any lens, be it EVA or otherwise. In this context, the proposed
solution merely investigates the feasibility of communicating progress in real-time; this was
achieved. In actual fact, the EVA visualisation requirements were set by the project. This is to
be expected; it is also changeable to workflow visualisation methods as they are improved
through future research.
6.3 Feasibility of implementation
The time-saving benefits of implementing the proposed lean solution are realised - it was
estimated to save 53 minutes per day, translating to 148 working days per year. However the
development’s feasibility is pivotal to its adoption. The acceptance of new processes during
the construction phase, particularly by those involved such as FM/SE and PEs, largely
determines its effectiveness and use. Significantly, the users are heavily relied on to be
adequate in using technology. Just as Russell (1993) found variability in skillsets of those
completing DSRs, the same variability was observed for their capacity to use technology. Be
it attributed to cultural issues or otherwise, there was an apprehension towards implementing
the system. The proposed solution inherently conveys transparency of happenings on-site, and
as Russell suggests, availability of such data can be incriminating. Such a stigma can be
harmful for the implementation of any similar system. Likewise, the solution revolves around
collaboration between parties. FM/SE need the PEs to enter quantities, objects, budget rates,
and cost codes for them to be able to complete a DSR. PEs need FM/SE to regularly complete
DSRs to have the most up-to-date data for reporting purposes. PMs and PPs rely on PEs to
provide them with progress data in real-time to enhance project control. A breakdown in the
process downstream hinders effective progress controlling upstream. In this way, the process
is circulated by a constant awareness of each party’s contribution - if FM/SE fail to complete
a DSR, it is in the best interest of those up the line to ensure this is rectified.

37
Those associated with the process need to have a clear understanding of their
involvement. The process guide was developed with this intention. Primarily, it is a blueprint
for the implementation of the entire solution. In response to issues identified by Majrouhi
Sardroud (2015) and a general focus on processes in a number of studies (Matthews et al.,
2015), the guide can be used to assist implementation by focusing on the processes critical to
its success. It is simple, specific to each type of user, while also communicating the intention
of the solution as a whole.
6.4 Limitations
Ensuring implementation of the solution is suitable to business needs requires a consideration
of existing infrastructure, and thus an understanding of alternative software. Further, a
consideration of the costs involved in implementing the solution allows industry professionals
to determine if it is feasible and useful to implement. These considerations were beyond the
scope of this study.
Complex infrastructure projects do not necessarily permit a rigid data structure as
proposed, specifically the WBS and CBS. It is unrealistic to assume plans will traverse the
construction phase unscathed. Variations are common, and the WBS and CBS need to be
flexible enough to accommodate. Mapping processes need to be dynamic and incorporated
when those variations take place, as opposed to when progress needs to be measured. The
repercussions of static data mapping mean changes render past progress data collection
incorrect.
6.5 Practical implications
The development can be applied to a broad classification of construction types by providing a
framework for semi-automated progress monitoring. Importantly, it is beneficial for such
purposes in the context of complex infrastructure, an area that research has failed to target. An
adoption of lean construction principles is possible by offering a workable BIM solution
through data collection and visualisation. An enhancement of existing progress visualisation
tools by including EVA within a BIM can allow project controlling to reach its full potential.
Looking to future research, the solution can be used as a platform for future
automation efforts. Difficulties in understanding processes to achieve this point towards a
readily implementable solution as a vehicle for future automation. A semi-automated solution
is not the end goal - although the activity progress calculations and visualisation have been
completely automated, progress data collection is a largely repetitive task that promises

38
reform through automation. Industry can use this tool as a means to an end. Where upcoming
ADC technology fails to provide a workable solution, the digital form is a safety net as
depicted in Figure 6.2, similar to the solution El-Omari and Moselhi (2011) propose.
Figure 6.2 - Recommended ADC implementation approach
As ADC technology improves overtime, this safety net will become obsolete. However in the
modern construction market, serving this purpose provides a clear way forward in connecting
the seemingly disparate worlds of innovative research and industry.

39
Chapter 7
Conclusion
This thesis outlines the development of a semi-automated digital progress monitoring tool and
its implementation in an ongoing infrastructure project. Collaboration with industry partners
interested in adopting lean and digital means of progress data capture enabled the study to
understand the current status quo of progress monitoring in industry by analysing existing
processes. It inevitably enabled the assessment of the proposed solution in a complex
construction setting. It should be noted that the focus of the research was not to determine
productivity gains from the implementation, but to determine its feasibility in the process of
doing so and provide a framework for this.
The digital form developed caters to the needs of the project in the data that it captures
and the progress information it makes visible. Standardisation was a major component in
achieving the results explained herein. Specifically, it enabled the form to confine
measurement to within strict data parameters such that progress could be communicated
effectively. Continuing development to the visualisation stage was key in distinguishing the
study as a holistic solution to progress monitoring, both in terms of its applicability to all
construction processes and in presenting a packaged solution. Choosing to communicate
progress through a 5D BIM was a lean approach to this visualisation. The embedment of EVA
metrics in this context provides an insight into how well understood and ubiquitous concepts
can be applied to recognise workflow, with the aid of modern tools. It encompasses past
research efforts to examine how BIM can be operationalised on-site during the construction
phase to communicate progress in real-time. The tool serves as a platform for future efforts in
automation.
7.1 Future work
Simplification of progress measurement methods facilitated real-time project monitoring.
Existing calculations were laborious, yet highly accurate efforts of estimating progress. On-
site personnel were satisfied with the level of detail and accuracy to which the simplifications
were able to estimate progress in comparison, however an ability to discover trends within the
visualisation tool in spite of these simplifications is not understood. The effectiveness of the

40
solution is perhaps limited by the simplifications it makes, though a judgement on this can
only be determined through further research. Specifically, milestone-based progress
weightings were determined solely through consultation with select industry partners. Under
the assumption that these simplistic means result in acceptable levels of accuracy, these
progress weightings need to be better informed and experimentally determined.
Beyond this, the research provides a plethora of opportunities for further development
along several fronts. Tailoring the 5D BIM at the behest of the business begs the need for a
number of variations and functionalities. Iterations of the tool can highlight delays, issues
with activities, or breaks in construction. Optimised progress visualisation was not the focus
of this study, however it was analysed as a feasible solution to communicating progress.
Literature lacks a comprehensive explanation of how workflow progress can be quantified,
and in turn visualised. The Last Planner System seems to address the issue but not the
communication. In light of this, perhaps quantifiable progress monitoring is not the way
forward and a focus on time wastage will signify productivity or a lack thereof. Visualising
progress through this lens may inform project controlling more effectively as workflows are
given significance.
This study focused on bridging the gap between research and industry domains by
providing a framework for semi-automated progress monitoring. Future work aimed towards
industry should increase the level of automation steadily as technologies become viable.
Identifying progress-measureable activities and fitting ADC technologies to suit is
encouraged.

41
References
ABDELSAYED, M. & NAVON, R. 1999. An Information Sharing, Internet-based, System
for Project Control. Civil Engineering and Environmental Systems, 16, 211-233.
AZIZ, R. F. & HAFEZ, S. M. 2013. Applying lean thinking in construction and performance
improvement. Alexandria Engineering Journal, 52, 679-695.
BABIC, N. C., PODBREZNIK, P. & REBOLJ, D. 2010. Integrating resource production and
construction using BIM. Automation in Construction, 19, 539-543.
BARLISH, K. & SULLIVAN, K. 2012. How to measure the benefits of BIM - A case study
approach. Automation in Construction, 24, 149-159.
BECERIK-GERBER, B., JAZIZADEH, F., LI, N. & CALIS, G. 2012. Application areas and
data requirements for BIM-enabled facilities management. Journal of Construction
Engineering and Management, 138, 431-442.
CHIN, S., KIM, K. & KIM, Y.-S. 2005. Generate-select-check based daily reporting system.
Journal of Computing in Civil Engineering, 19, 412-425.
CHIN, S., YOON, S., CHOI, C. & CHO, C. 2008. RFID+4D CAD for progress management
of structural steel works in high-rise buildings. Journal of Computing in Civil
Engineering, 22, 74-89.
COMPUTER INTEGRATED CONSTRUCTION RESEARCH PROGRAM 2011. BIM
Project Execution Planning Guide - Version 2.1. University Park, PA, USA: The
Pennsylvania State University.
COOK, J. 1997. Monitoring and Evaluation Capacity Building Study. ACN, 1, 883.
DARKE, P., SHANKS, G. & BROADBENT, M. 1998. Successfully completing case study
research: combining rigour, relevance and pragmatism. Information Systems Journal,
8, 273-289.
DAVE, B., KUBLER, S., FRAMLING, K. & KOSKELA, L. Addressing information flow in
lean production management and control in construction. 22nd Annual Conference of
the International Group for Lean Construction: Understanding and Improving Project
Based Production, IGLC 2014, June 25, 2014 - June 27, 2014, 2014 Oslo, Norway.
The International Group for Lean Construction, 581-592.
DE SOUZA, D. V. S. & KOSKELA, L. Interfaces, flows, and problems of construction
supply chains - A case study in Brazil. 22nd Annual Conference of the International
Group for Lean Construction: Understanding and Improving Project Based
Production, IGLC 2014, June 25, 2014 - June 27, 2014, 2014 Oslo, Norway. The
International Group for Lean Construction, 1095-1106.
DEL PICO, W. J. 2013. Project Control: Integrating Cost and Schedule in Construction,
Hoboken, New Jersey, John Wiley & Sons, Inc.
DING, L., ZHOU, Y. & AKINCI, B. 2014. Building Information Modeling (BIM) application
framework: The process of expanding from 3D to computable nD. Automation in
Construction, 46, 82-93.
EL-OMARI, S. & MOSELHI, O. Integrating automated data acquisition technologies for
progress reporting of construction projects. 2011 P.O. Box 211, Amsterdam, 1000 AE,
Netherlands. Elsevier, 699-705.
FORBES, L. H. & AHMED, S. M. 2010. Modern Construction: Lean Project Delivery and
Integrated Practices, CRC Press.

42
GHANEM, A. A. 2007. Real-Time Construction Project Progress Tacking: A Hybrid Model
for Wireless Technologies Selection, Assessment, and Implementation. Electronic
Theses, Treaties and Dissertations.
GIBBS, A. 1997. Focus groups. Social research update, 19, 1-8.
GOLPARVAR-FARD, M., PEA-MORA, F. & SAVARESE, S. 2015. Automated progress
monitoring using unordered daily construction photographs and IFC-based building
information models. Journal of Computing in Civil Engineering, 29.
GOLPARVAR-FARD, M., PENA-MORA, F., ARBOLEDA, C. A. & LEE, S. 2009.
Visualization of Construction Progress Monitoring with 4D Simulation Model
Overlaid on Time-Lapsed Photographs. Journal of Computing in Civil Engineering,
23, 391-404.
HAO, J. Application of lean construction to Chinese construction industry based on BIM
technology. 2012 2nd International Conference on Business Computing and Global
Informatization, BCGIN 2012, October 12, 2012 - October 14, 2012, 2012 Shanghai,
China. IEEE Computer Society, 47-50.
HOWELL, G. & BALLARD, G. Implementing lean construction: understanding and action.
Proc. 6 th Ann. Conf. Intl. Group for Lean Constr, 1998.
HOWELL, G. A. & KOSKELA, L. Reforming project management: the role of lean
construction. Proceedings of the 8th Annual Conference of the International Group
for Lean Construction, 2000.
ISAAC, S. & NAVON, R. Combining automatically and manually collected data for project
monitoring and control. 29th International Symposium of Automation and Robotics
in Construction, ISARC 2012, June 26, 2012 - June 29, 2012, 2012 Eindhoven,
Netherlands. IIT Madras.
ISAAC, S. & NAVON, R. 2014. Can project monitoring and control be fully automated?
Construction Management and Economics, 32, 495-505.
JUNG, Y. & KANG, S. 2007. Knowledge-based standard progress measurement for
integrated cost and schedule performance control. Journal of Construction
KIM, H., BENGHI, C., DAWOOD, N., JUNG, D., KIM, J. & BAEK, Y. Developing 5D
system connecting cost, schedule and 3D model. IABSE Symposium Report, 2010.
International Association for Bridge and Structural Engineering, 32-38.
KIM, Y.-W. & BALLARD, G. 2010. Management thinking in the earned value method
system and the last planner system. Journal of Management in Engineering, 26, 223-
228.
KOEKEMOER, V. & SMALLWOOD, J. Information Technology (IT) in the construction
process. 23rd Annual Conference on Association of Researchers in Construction
Management, ARCOM 2007, September 3, 2007 - September 5, 2007, 2007 Belfast,
United kingdom. Association of Researchers in Construction Management,ARCOM,
503-512.
KOSKELA, L. 2000. An exploration towards a production theory and its application to
construction. VTT Publications, X-296.
KOSKELA, L. & HOWELL, G. 2008. The underlying theory of project management is
obsolete. IEEE Engineering Management Review, 36, 22-34.
KOSKELA, L., STRATTON, R. & KOSKENVESA, A. Last planner and critical chain in
construction management: Comparative analysis. 18th Annual Conference of the
International Group for Lean Construction, IGLC 18, July 14, 2010 - July 16, 2010,
2010 Haifa, Israel. The International Group for Lean Construction, 538-547.
KREIDER, R. G. & MESSNER, J. I. 2013. The Uses of BIM: Classifying and Selecting BIM
Uses. The Pennsylvania State University, University Park, PA, USA.
LARSON, E. W. & GRAY, C. F. 2011. Project Management: The Managerial Process,
McGraw-Hill/Irwin.

43
MAJROUHI SARDROUD, J. 2015. Perceptions of automated data collection technology use
in the construction industry. Journal of Civil Engineering and Management, 21, 54-
66.
MATTHEWS, J., LOVE, P. E. D., HEINEMANN, S., CHANDLER, R., RUMSEY, C. &
OLATUNJ, O. 2015. Real time progress management: Re-engineering processes for
cloud-based BIM in construction. Automation in Construction, 58, 38-47.
MCCULLOUCH, B. Automating field data collection in construction organizations.
Proceedings of the 1997 5th ASCE Construction Congress, October 4, 1997 - October
8, 1997, 1997 Minneapolis, MN, USA. ASCE, 957-963.
MCGRAW HILL CONSTRUCTION 2014. SmartMarket Report: The business value of BIM
for construction in major global markets: How contractors around the world are
driving innovation with building information modelling. McGraw Hill Construction.
MELL, P. & GRANCE, T. 2011. The NIST definition of cloud computing.
NAVON, R. Automated project performance control of construction projects. 20th
International Symposium on Automation and Robotics in Construction: The Future
Site, 2005. Elsevier, 467-476.
NAVON, R. & HASKAYA, I. 2006. Is detailed progress monitoring possible without
designated manual data collection? Construction Management and Economics, 24,
1225-1229.
NAVON, R. & SACKS, R. 2007. Assessing research issues in Automated Project
Performance Control (APPC). Automation in Construction, 16, 474-484.
PAULUS, T., WOODSIDE, M. & ZIEGLER, M. 2008. Extending the conversation:
Qualitative research as dialogic collaborative process. The Qualitative Report, 13,
226-243.
PENTTILÄ, H. 2006. Describing the changes in architectural information technology to
understand design complexity and free-form architectural expression. ITcon.
POGORILICH, D. A. 1992. Daily report as a job management tool. Cost Engineering
(Morgantown, West Virginia), 34, 23-25.
PRIVEN, V., SACKS, R., SEPPNEN, O. & SAVOSNICK, J. A lean workflow index for
construction projects. 22nd Annual Conference of the International Group for Lean
Construction: Understanding and Improving Project Based Production, IGLC 2014,
June 25, 2014 - June 27, 2014, 2014 Oslo, Norway. The International Group for Lean
Construction, 715-726.
PROJECT MANAGEMENT INSTITUTE 2013. A Guide to the Project Management Body
of Knowledge (PMBOK Guide). 5th ed. Newtown Square, PA: Project Management
Institute, Inc.
RUSSELL, A. D. 1993. Computerized daily site reporting. Journal of Construction
SACKS, R., KOSKELA, L., DAVE, B. A. & OWEN, R. 2010. Interaction of lean and
building information modeling in construction. Journal of Construction Engineering
and Management, 136, 968-980.
SACKS, R., TRECKMANN, M. & ROZENFELD, O. 2009. Visualization of Work Flow to
Support Lean Construction. Journal of Construction Engineering and Management,
135, 1307-1315.
TOLEDO, M., GONZLEZ, V. A., VILLEGAS, A. & MOURGUES, C. Using 4D models for
tracking project progress and visualizing the owner's constraints in fast-track retail
renovation projects. 22nd Annual Conference of the International Group for Lean
Construction: Understanding and Improving Project Based Production, IGLC 2014,
June 25, 2014 - June 27, 2014, 2014 Oslo, Norway. The International Group for Lean
Construction, 969-980.

44
TURKAN, Y., BOSCHÉ, F., HAAS, C. T. & HAAS, R. 2012. Toward automated earned
value tracking using 3D imaging tools. Journal of construction engineering and
management, 139, 423-433.
WONG, J., WANG, X., LI, H., CHAN, G. & LI, H. 2014. A review of cloud-based BIM
technology in the construction sector. The Journal of Information Technology in
Construction, 19, 281-291.
ZHANG, L., LI, Y. & TANG, J. The application of the earned value management in the last
planner system for project performance control. 17th International Symposium on
Advancement of Construction Management and Real Estate, CRIOCM 2012,
November 17, 2012 - November 18, 2012, 2014 Shenzhen, China. Springer-Verlag
Berlin Heidelberg, 851-857.

A1
Appendices
Contents
Appendix A - Existing DSR form .......................................................................................A2
Appendix B - Data requirements.........................................................................................A3
Gate breakdown and percentage complete for type D activities .....................................A3
Matched method of measurement to activity groups ......................................................A4
Appendix C - Pilot digital DSR form ..................................................................................A5
Desktop view...................................................................................................................A5
Four-week look ahead function.......................................................................................A6
Appendix D - Progress measurement tool: final digital DSR .............................................A7
Tablet view ......................................................................................................................A7
Mobile view.....................................................................................................................A8
Appendix E - Focus group...................................................................................................A9
Coded transcript...............................................................................................................A9
Example calculations for capping beam........................................................................A31
Appendix F - Microsoft SharePoint Designer workflow...................................................A32
Appendix G - Power query M code...................................................................................A33
Appendix H - QlikView code in ViCon 3DBIS................................................................A43
Appendix I - Process guide for implementation................................................................A51

A2
Appendix A - Existing DSR form

A3
Appendix B - Data requirements
Gate breakdown and percentage complete for type D activities
Process & Process Gate
Breakdown
Gate
Weighting
Process & Process Gate
Breakdown
Gate
Weighting
Concrete (FRP) 100% Piling 100%
1 Minor Excavation 10% 1 Poured 80%
2 Blinding Concrete 10% 2 Breakback 20%
3 Rebar 25% Trench, Lay & Backfill 100%
4 Formwork 25% 1 Excavation 10%
5 Pour Concrete 25% 2 Sand Bedding 5%
6 Strip & Backfill 5% 3 Lay and Fitup 30%
Pipework (Above Ground) 100% 4 Welding & Jointing 30%
1 Lift & Fit 30% 5 Hydrotest, or Testing 10%
2 Field Weld, Bolt or Thread 30% 6 Coating and Wraping 10%
3 Supports 20% 7 Backfilling 5%
4 NDT, QC, Clearance 10% Install (Package Item) 100%
5 Hydro & Pneumatic Tests 10% 1 Preparation 5%
Cable Install 100% 2 Transport & Place 45%
1 Cable Tray 10% 3 Align, Level & Grout 30%
2 Pull & Dress 50% 4 Aux Equipment Install 10%
3 Terminate 30% 5 Final Alignment 10%
4 QA and Testing 10%

A4
Matched method of measurement to activity groups
Activity Group Method of
Measurement
Unit Activity Group Method of
Measurement
Unit
Backfills Type E m3
Masonry Type E m2
Cabling Type D lm Milestone
Cladding Type E m2
Mobilisation Type C %
Clear & Grub Type E m2
Notification Type A ea
Cutover ea Paving Type E m2
Demobilisation Type C % Piling Type D ea
Demolish Type C % Pipework Type D
Energisation Type A ea Place & Compact Type E m3
Excavation Type E m3
Potholing Type C %
F.R.P. Type D m3
Precast Footings Type E ea
Finishes Type E m2
Roofing Type E m2
Fit Out Type C % Screen & Process Type E m3
Flash Butt
Welding
Type E ea Seal Type E m2
Glazing Type E m2
Shotcrete Type E m2
Handover Type A ea Soil Nail Type E ea
Install Type D ea Steelworks Type E t
Installations
Rough-in
Type C % Survey & Setout Type C %
Kerb and Gutter Type E lm Testing &
Commissioning
Type C %
Landscaping Type E m2
Top Soil Type E m3
Linemarking,
Signage &
Guardrail
Type E lm Trench, Lay &
Backfill
Type D lm

A5
Appendix C - Pilot digital DSR form
Desktop view

A6
Four-week look ahead function

A7
Appendix D - Progress measurement tool: final digital DSR
Tablet view

A9
Appendix E - Focus group
Coded transcript

A31
Example calculations for capping beam
Sub Metric Budgeted Value = ∑ Task Budgeted Value
Sub Metric Budgeted Unit Rate =
𝑆𝑢𝑏 𝑀𝑒𝑡𝑟𝑖𝑐 𝐵𝑢𝑑𝑔𝑒𝑡𝑒𝑑 𝑉𝑎𝑙𝑢𝑒
𝑆𝑢𝑏 𝑀𝑒𝑡𝑟𝑖𝑐 𝐵𝑢𝑑𝑔𝑒𝑡𝑒𝑑 𝑄𝑢𝑎𝑛𝑡𝑖𝑡𝑦
Metric Budgeted Unit Rate =
∑ 𝑆𝑢𝑏 𝑀𝑒𝑡𝑟𝑖𝑐 𝐵𝑢𝑑𝑔𝑒𝑡𝑒𝑑 𝑉𝑎𝑙𝑢𝑒
𝑀𝑒𝑡𝑟𝑖𝑐 𝐵𝑢𝑑𝑔𝑒𝑡𝑒𝑑 𝑄𝑢𝑎𝑛𝑡𝑖𝑡𝑦
Sub Metric Weight Factor =
𝑆𝑢𝑏 𝑀𝑒𝑡𝑟𝑖𝑐 𝐵𝑢𝑑𝑔𝑒𝑡𝑒𝑑 𝑈𝑛𝑖𝑡 𝑅𝑎𝑡𝑒
𝑀𝑒𝑡𝑟𝑖𝑐 𝐵𝑢𝑑𝑔𝑒𝑡𝑒𝑑 𝑈𝑛𝑖𝑡 𝑅𝑎𝑡𝑒
Weighted Sub Metric Quantity = Sub Metric Quantity × Sub Metric Weight Factor
Metric Quantity = ∑ Weighted Sub Metric Quantity
Metric EV =Metric Quantity × Metric Budgeted Unit Rate
Activity EV = ∑ Metric EV

A32
Appendix F - Microsoft SharePoint Designer workflow

A33
Appendix G - Power query M code
Type D Gates
let
Source = OData.Feed("https://www.oris-
server.com/projects/nrt/Construction/RTRF/_vti_bin/Listdata.svc"),
TypeD_Gates_table = Source{[Name="TypeD_Gates",Signature="table"]}[Data],
#"Removed Columns" = Table.RemoveColumns(TypeD_Gates_table,{"ContentTypeID",
"Title", "Id", "ContentType", "Modified", "Created", "CreatedById", "ModifiedById",
"Owshiddenversion", "Version", "Path", "CreatedBy", "ModifiedBy", "Attachments",
"ActivityStatusValue"}),
#"Expanded ActivityStatus" = Table.ExpandRecordColumn(#"Removed Columns",
"ActivityStatus", {"Value"}, {"ActivityStatus.Value"}),
#"Changed Type" = Table.TransformColumnTypes(#"Expanded
ActivityStatus",{{"ReportDate", type date}}),
#"Added Custom" = Table.AddColumn(#"Changed Type", "Week Ending", each
Date.EndOfWeek([ReportDate])),
#"Merged Queries" = Table.NestedJoin(#"Added
Custom",{"Gate_cal"},TypeD_GatesWeighting,{"GateNumber"},"NewColumn",JoinKind.LeftOuter),
#"Expanded NewColumn" = Table.ExpandTableColumn(#"Merged Queries",
"NewColumn", {"AccumulatedWeighting"}, {"AccumulatedWeighting"}),
#"Changed Type1" = Table.TransformColumnTypes(#"Expanded NewColumn",{{"Week
Ending", type date}}),
MyMAXIFFunction = (InputTable as table, MyDate as date, MyAccount as text) as number
=>
let
FilteredTable = Table.SelectRows(InputTable, each([ReportDate] < MyDate and
[Object_cal] = MyAccount)),
MaxOfAmt = List.Max(Table.Column(FilteredTable, "AccumulatedWeighting"))
in
MaxOfAmt,
AddedMAXIFS = Table.AddColumn(#"Changed Type1", "MAXIFS", each
MyMAXIFFunction(#"Changed Type1", [ReportDate], [Object_cal])),
#"Replaced Errors" = Table.ReplaceErrorValues(AddedMAXIFS, {{"MAXIFS", 0}}),
#"Merged Queries1" = Table.NestedJoin(#"Replaced
Errors",{"Object_cal"},Objects,{"RTRFObjectCode"},"NewColumn",JoinKind.LeftOuter),
#"Expanded NewColumn1" = Table.ExpandTableColumn(#"Merged Queries1",
"NewColumn", {"Budgeted Value", "COUNTIFS"}, {"Budgeted Value", "COUNTIFS"}),
#"Added Custom1" = Table.AddColumn(#"Expanded NewColumn1", "EV", each
([AccumulatedWeighting]-[MAXIFS])*[Budgeted Value]/[COUNTIFS]),
#"Changed Type2" = Table.TransformColumnTypes(#"Added Custom1",{{"EV",
Currency.Type}}),
#"Grouped Rows" = Table.Group(#"Changed Type2", {"Object_cal", "Week Ending"},
{{"EV", each List.Sum([EV]), type number}, {"RTRF Activity", each List.Max([RTRFActivity_cal]),
type text}, {"Activity Status", each List.Max([ActivityStatus.Value]), type text}}),
#"Merged Queries2" = Table.NestedJoin(#"Grouped
Rows",{"Object_cal"},Objects,{"RTRFObjectCode"},"NewColumn",JoinKind.LeftOuter),
"NewColumn", {"RTRFActivity_cal", "Budgeted Value", "RTRFCostCodes.JDECostCode",
"RTRFCostCodes.CostCodes"}, {"RTRFActivity_cal", "Budgeted Value",
"RTRFCostCodes.JDECostCode", "RTRFCostCodes.CostCodes"}),
#"Removed Columns1" = Table.RemoveColumns(#"Expanded NewColumn2",{"RTRF
Activity"})
in
#"Removed Columns1"

A34
Type A B C RTRF
let
TypeA_B_C_RTRF_table =
Source{[Name="TypeA_B_C_RTRF",Signature="table"]}[Data],
#"Expanded ActivityStatus" = Table.ExpandRecordColumn(TypeA_B_C_RTRF_table,
#"Removed Columns" = Table.RemoveColumns(#"Expanded
ActivityStatus",{"ContentTypeID", "Title", "Id", "ContentType", "Modified", "Created",
"CreatedById", "ModifiedById", "Owshiddenversion", "Version", "Path", "CreatedBy",
"ModifiedBy", "Attachments", "ActivityStatusValue"}),
#"Changed Type" = Table.TransformColumnTypes(#"Removed Columns",{{"ReportDate",
type date}}),
#"Grouped Rows" = Table.Group(#"Changed Type", {"RTRFActivities_cal",
"ReportDate"}, {{"Percent Complete", each List.Sum([ActivityPercentComplete]), type number},
{"Activity Status", each List.Max([ActivityStatus.Value]), type text}}),
#"Merged Queries" = Table.NestedJoin(#"Grouped
Rows",{"RTRFActivities_cal"},ProgressReportList,{"ActivityID"},"NewColumn",JoinKind.LeftOute
r),
"NewColumn", {"BudgetCost", "RTRFCostCodes.JDECostCode", "RTRFCostCodes.CostCodes"},
{"BudgetCost", "RTRFCostCodes.JDECostCode", "RTRFCostCodes.CostCodes"}),
#"Added Custom" = Table.AddColumn(#"Expanded NewColumn", "EV", each [Percent
Complete]*[BudgetCost]),
#"Renamed Columns" = Table.RenameColumns(#"Added Custom",{{"BudgetCost",
"Budgeted Value"}}),
#"Added Custom1" = Table.AddColumn(#"Renamed Columns", "Week Ending", each
#"Renamed Columns1" = Table.RenameColumns(#"Added
Custom1",{{"RTRFActivities_cal", "RTRFActivity_cal"}})
in
#"Renamed Columns1"
Type E Quantities
let
TypeE_Quantities_table = Source{[Name="TypeE_Quantities",Signature="table"]}[Data],
#"Expanded ActivityStatus" = Table.ExpandRecordColumn(TypeE_Quantities_table,
#"Removed Columns" = Table.RemoveColumns(#"Expanded
ActivityStatus",{"ContentTypeID", "Title", "Id", "ContentType", "Modified", "Created",
"CreatedById", "ModifiedById", "Owshiddenversion", "Version", "Path", "CreatedBy",
"ModifiedBy", "Attachments", "RTRFActivity_cal", "ActivityStatusValue"}),
#"Changed Type" = Table.TransformColumnTypes(#"Removed Columns",{{"ReportDate",
type date}}),
#"Added Custom" = Table.AddColumn(#"Changed Type", "Custom", each
#"Renamed Columns1" = Table.RenameColumns(#"Added Custom",{{"Custom", "Week
Ending"}}),
#"Grouped Rows" = Table.Group(#"Renamed Columns1", {"RTRFMetricCode_cal",
"Week Ending"}, {{"Activity Quantity", each List.Sum([ActivityQuantity]), type number}, {"Activity
Status", each List.Max([ActivityStatus.Value]), type text}}),

A35
Rows",{"RTRFMetricCode_cal"},Quantities,{"RTRFMetricCode"},"NewColumn",JoinKind.LeftOut
er),
"NewColumn", {"BudgetedUnits", "RTRFActivity_cal", "BudgetedUnitRate",
"RTRFCostCodes.JDECostCode", "RTRFCostCodes.CostCodes", "Budgeted Value"},
{"BudgetedUnits", "RTRFActivity_cal", "BudgetedUnitRate", "RTRFCostCodes.JDECostCode",
"RTRFCostCodes.CostCodes", "Budgeted Value"}),
#"Changed Type1" = Table.TransformColumnTypes(#"Expanded
NewColumn",{{"BudgetedUnitRate", Currency.Type}}),
#"Added Custom1" = Table.AddColumn(#"Changed Type1", "EV", each [Activity
Quantity]*[BudgetedUnitRate]),
#"Changed Type2" = Table.TransformColumnTypes(#"Added Custom1",{{"EV",
Currency.Type}}),
#"Renamed Columns" = Table.RenameColumns(#"Changed
Type2",{{"RTRFMetricCode_cal", "SubActivity_cal"}})
in
#"Renamed Columns"
Cost Codes
let
CostCodes_table = Source{[Name="CostCodes",Signature="table"]}[Data],
#"Removed Columns" =
Table.RemoveColumns(CostCodes_table,{"ContentTypeID", "ContentType", "Modified",
"Created", "CreatedById", "ModifiedById", "Owshiddenversion", "Version", "Path",
"CreatedBy", "ModifiedBy", "Attachments"})
in
#"Removed Columns"
Progress Report List
let
ProgressReportList_table =
Source{[Name="ProgressReportList",Signature="table"]}[Data],
Table.RemoveColumns(ProgressReportList_table,{"ContentTypeID", "TaskType",
"DisplayedInDPR", "LocationText", "AreaText", "DisciplineText", "SubDisciplineText",
"DetailedLocationText", "Today", "DateDifference", "ActivityGroup", "ExportDate", "ContentType",
"Modified", "Created", "CreatedById", "ModifiedById", "Owshiddenversion", "Version", "Path",
"ActivityStatus", "MeasureType", "CreatedBy", "ModifiedBy", "Attachments"}),
#"Expanded RTRFCostCodes" = Table.ExpandRecordColumn(#"Removed Columns",
"RTRFCostCodes", {"JDECostCode", "CostCodes"}, {"RTRFCostCodes.JDECostCode",
"RTRFCostCodes.CostCodes"})
in
#"Expanded RTRFCostCodes"
Objects
let

A36
Objects_table = Source{[Name="Objects",Signature="table"]}[Data],
#"Removed Columns" = Table.RemoveColumns(Objects_table,{"ContentTypeID", "Title",
"Id", "ContentType", "Modified", "Created", "CreatedById", "ModifiedById", "Owshiddenversion",
"Version", "Path", "CreatedBy", "ModifiedBy", "Attachments"}),
#"Merged Queries" = Table.NestedJoin(#"Removed
Columns",{"RTRFActivity_cal"},ProgressReportList,{"ActivityID"},"NewColumn",JoinKind.LeftOu
ter),
"NewColumn", {"BudgetCost", "RTRFCostCodes.JDECostCode", "RTRFCostCodes.CostCodes"},
{"BudgetCost", "RTRFCostCodes.JDECostCode", "RTRFCostCodes.CostCodes"}),
#"Changed Type" = Table.TransformColumnTypes(#"Expanded
NewColumn",{{"BudgetCost", Currency.Type}}),
MyCOUNTIFFunction = (InputTable as table, MyAccount as text) as number =>
let
FilteredTable = Table.SelectRows(InputTable, each([RTRFActivity_cal] = MyAccount)),
CountOfAmt = List.Count(Table.Column(FilteredTable, "RTRFObjectCode"))
in
CountOfAmt,
AddedCOUNTIFS = Table.AddColumn(#"Changed Type", "COUNTIFS", each
MyCOUNTIFFunction(#"Changed Type", [RTRFActivity_cal])),
#"Renamed Columns" = Table.RenameColumns(AddedCOUNTIFS,{{"BudgetCost",
"Budgeted Value"}})
in
#"Renamed Columns"
Quantities
let
Quantities_table = Source{[Name="Quantities",Signature="table"]}[Data],
#"Removed Columns" = Table.RemoveColumns(Quantities_table,{"Title",
"ContentTypeID", "ContentType", "Modified", "Created", "CreatedById", "ModifiedById",
"Owshiddenversion", "Version", "Path", "CreatedBy", "ModifiedBy", "Attachments",
"UnitOfMeasure"}),
#"Expanded RTRFCostCodes" = Table.ExpandRecordColumn(#"Removed Columns",
"RTRFCostCodes", {"JDECostCode", "CostCodes"}, {"RTRFCostCodes.JDECostCode",
"RTRFCostCodes.CostCodes"}),
#"Added Custom" = Table.AddColumn(#"Expanded RTRFCostCodes", "Budgeted Value",
each [BudgetedUnits]*[BudgetedUnitRate])
in
#"Added Custom"
Quantities Reference
let
Source = Quantities,
#"Grouped Rows" = Table.Group(Source, {"RTRFActivity_cal"}, {{"Budgeted Value",
each List.Sum([Budgeted Value]), type number}})
in
#"Grouped Rows"
Type D Gates Weighting
let

A37
TypeD_GatesWeighting_table =
Source{[Name="TypeD_GatesWeighting",Signature="table"]}[Data],
Table.RemoveColumns(TypeD_GatesWeighting_table,{"ContentTypeID", "ContentType",
"Modified", "Created", "CreatedById", "ModifiedById", "Owshiddenversion", "Version", "Path",
in
#"Removed Columns"
Activities Info
let
Source = Excel.Workbook(Web.Contents("https://www.oris-
server.com/projects/nrt/Construction/RTRF/Excel Spreadsheets/NRT OTS L3 DP LV-
Activities.xlsx"), null, true),
TASK_Sheet = Source{[Item="TASK",Kind="Sheet"]}[Data],
#"Changed Type" = Table.TransformColumnTypes(TASK_Sheet,{{"Column1", type text},
{"Column2", type text}, {"Column3", type text}, {"Column4", type text}, {"Column5", type text},
{"Column6", type text}, {"Column7", type text}, {"Column8", type text}, {"Column9", type text},
{"Column10", type text}, {"Column11", type text}, {"Column12", type text}, {"Column13", type
text}, {"Column14", type any}, {"Column15", type any}, {"Column16", type any}, {"Column17",
type any}, {"Column18", type any}, {"Column19", type text}, {"Column20", type any},
{"Column21", type text}, {"Column22", type any}, {"Column23", type any}}),
#"Removed Columns" = Table.RemoveColumns(#"Changed Type",{"Column2",
"Column5", "Column9", "Column10", "Column11", "Column12", "Column20"}),
#"Renamed Columns" = Table.RenameColumns(#"Removed Columns",{{"Column1",
"Activity ID"}, {"Column3", "WBS Code"}, {"Column4", "WBS Name"}, {"Column6", "Activity
Name"}, {"Column7", "Start"}, {"Column8", "Finish"}, {"Column13", "L6 Area"}, {"Column14",
"Area"}, {"Column15", "Discipline"}, {"Column16", "Detailed Location"}, {"Column17",
"SubDiscipline"}, {"Column18", "Process"}, {"Column19", "Activity Type"}, {"Column21",
"Activity ID Pre"}, {"Column22", "Activity ID Post"}, {"Column23", "Activity Grouping"}}),
#"Removed Top Rows" = Table.Skip(#"Renamed Columns",1)
in
#"Removed Top Rows"
All Costs
let
server.com/projects/nrt/Construction/RTRF/Excel Spreadsheets/CURRENT 2015 CTD
REPORT.xlsx"), null, true),
#"All Costs _Sheet" = Source{[Item="All Costs ",Kind="Sheet"]}[Data],
#"Changed Type" = Table.TransformColumnTypes(#"All Costs _Sheet",{{"Column1",
type text}, {"Column2", type text}, {"Column3", type any}, {"Column4", type any}, {"Column5",
type text}, {"Column6", type any}, {"Column7", type text}, {"Column8", type text}, {"Column9",
type any}, {"Column10", type any}, {"Column11", type any}, {"Column12", type text},
{"Column13", type any}, {"Column14", type text}, {"Column15", type any}, {"Column16", type
any}, {"Column17", type any}, {"Column18", type any}, {"Column19", type any}}),
#"Removed Columns" = Table.RemoveColumns(#"Changed Type",{"Column1",
"Column7", "Column8", "Column12", "Column13", "Column14", "Column15", "Column16",
"Column17", "Column18", "Column19"}),
#"Renamed Columns" = Table.RenameColumns(#"Removed Columns",{{"Column2",
"Task"}, {"Column3", "JDE"}, {"Column4", "Rover"}, {"Column5", "Task Name"}, {"Column6",
"Date"}, {"Column9", "Quantity"}, {"Column10", "Rate"}, {"Column11", "Amount"}}),
#"Removed Top Rows" = Table.Skip(#"Renamed Columns",1),

A38
#"Added Custom" = Table.AddColumn(#"Removed Top Rows", "RTRF Cost Code", each
Text.Remove([Task],".")),
#"Changed Type1" = Table.TransformColumnTypes(#"Added Custom",{{"Date", type
date}}),
#"Removed Columns1" = Table.RemoveColumns(#"Changed Type1",{"JDE"}),
#"Appended Query" = Table.Combine({#"Removed Columns1",AdditionalCosts}),
#"Merged Queries" = Table.NestedJoin(#"Appended Query",{"RTRF Cost
Code"},CostCodes,{"CostCodes"},"NewColumn",JoinKind.LeftOuter),
"NewColumn", {"JDECostCode"}, {"JDECostCode"}),
#"Changed Type2" = Table.TransformColumnTypes(#"Expanded NewColumn",{{"RTRF
Cost Code", type text}}),
#"Added Custom1" = Table.AddColumn(#"Changed Type2", "Cost Code", each if
[JDECostCode] = null then Text.Range([RTRF Cost Code], 0, 5) else [JDECostCode]),
#"Added Custom2" = Table.AddColumn(#"Added Custom1", "Week Ending", each
Date.EndOfWeek([Date])),
#"Grouped Rows" = Table.Group(#"Added Custom2", {"RTRF Cost Code", "Week
Ending"}, {{"AC", each List.Sum([Amount]), type number}, {"Cost Code", each List.Max([Cost
Code]), type text}}),
#"Added Custom3" = Table.AddColumn(#"Grouped Rows", "Week Ending Text", each
[Week Ending]),
#"Changed Type3" = Table.TransformColumnTypes(#"Added Custom3",{{"Week Ending
Text", type text}}),
#"Added Custom4" = Table.AddColumn(#"Changed Type3", "Cost Code Lookup", each
[RTRF Cost Code]&"_"&[Week Ending Text]),
#"Filtered Rows" = Table.SelectRows(#"Added Custom4", each ([RTRF Cost Code] =
"32350" or [RTRF Cost Code] = "323501" or [RTRF Cost Code] = "323502" or [RTRF Cost Code] =
"323503" or [RTRF Cost Code] = "323504" or [RTRF Cost Code] = "323505" or [RTRF Cost Code]
= "323507")),
#"Changed Type4" = Table.TransformColumnTypes(#"Filtered Rows",{{"Week Ending",
type date}}),
#"Sorted Rows" = Table.Sort(#"Changed Type4",{{"Week Ending", Order.Ascending}})
in
#"Sorted Rows"
Additional Costs
let
AdditionalCosts_table = Source{[Name="AdditionalCosts",Signature="table"]}[Data],
#"Renamed Columns" = Table.RenameColumns(AdditionalCosts_table,{{"CostCode_cal",
"RTRF Cost Code"}}),
#"Removed Columns" = Table.RemoveColumns(#"Renamed Columns",{"ContentTypeID",
"Title", "Id", "ContentType", "Modified", "Created", "CreatedById", "ModifiedById",
"Owshiddenversion", "Version"}),
#"Renamed Columns1" = Table.RenameColumns(#"Removed
Columns",{{"SupplierName", "Task Name"}}),
#"Removed Columns1" = Table.RemoveColumns(#"Renamed Columns1",{"Path",
in
#"Removed Columns1"
NRT Activities
let

A39
server.com/projects/nrt/Construction/RTRF/Excel Spreadsheets/NRT OTS - Activity Schedule.xlsx"),
null, true),
Table2_Table = Source{[Item="Table2",Kind="Table"]}[Data],
#"Added Custom" = Table.AddColumn(Table2_Table, "Start Date", each
Text.Start([Start],10)),
#"Changed Type" = Table.TransformColumnTypes(#"Added Custom",{{"Start Date", type
date}}),
#"Added Custom1" = Table.AddColumn(#"Changed Type", "Finish Date", each
Text.Start([Finish],10)),
#"Changed Type1" = Table.TransformColumnTypes(#"Added Custom1",{{"Finish Date",
type date}}),
#"Added Custom2" = Table.AddColumn(#"Changed Type1", "Duration", each if
Duration.Days([Finish Date]-[Start Date]) = null then 0 else Duration.Days([Finish Date]-[Start
Date])+1),
#"Filtered Rows" = Table.SelectRows(#"Added Custom2", each Text.StartsWith([WBS
Code], "NRT OTS L3 DP UD27.9.RTRF")),
#"Sorted Rows" = Table.Sort(#"Filtered Rows",{{"Activity ID", Order.Ascending}})
in
#"Sorted Rows"
Budgeted Costs
let
Source = Objects,
#"Removed Columns" = Table.RemoveColumns(Source,{"ObjectCode",
"RTRFObjectCode", "ObjectDescription", "ActivityGroup_cal", "DetailedLocation_cal",
"RTRFCostCodes.JDECostCode", "RTRFCostCodes.CostCodes", "COUNTIFS"}),
#"Appended Query1" = Table.Combine({#"Removed Columns",TypeA_B_C_RTRF}),
#"Removed Columns2" = Table.RemoveColumns(#"Appended Query1",{"ReportDate",
"Percent Complete", "RTRFCostCodes.JDECostCode", "RTRFCostCodes.CostCodes", "EV", "Week
Ending"}),
#"Grouped Rows1" = Table.Group(#"Removed Columns2", {"RTRFActivity_cal"},
{{"Budgeted Value", each List.Max([Budgeted Value]), type number}}),
#"Appended Query" = Table.Combine({#"Grouped Rows1",Quantities_Reference})
in
#"Appended Query"
SubActivities EV
let
Source = TypeD_Gates,
#"Appended Query" = Table.Combine({Source,TypeE_Quantities}),
#"Removed Columns" = Table.RemoveColumns(#"Appended Query",{"Activity Quantity",
"BudgetedUnits", "BudgetedUnitRate"}),
#"Appended Query1" = Table.Combine({#"Removed Columns",TypeA_B_C_RTRF}),
#"Removed Columns1" = Table.RemoveColumns(#"Appended Query1",{"ReportDate",
"Percent Complete"}),
#"Changed Type" = Table.TransformColumnTypes(#"Removed Columns1",{{"Week
Ending", type date}}),
MyCOUNTIFFunction = (InputTable as table, MyDate as date, MyAccount as text) as
number =>
let
FilteredTable = Table.SelectRows(InputTable, each([Week Ending] = MyDate and
[RTRFCostCodes.CostCodes] = MyAccount)),
CountOfAmt = List.Count(Table.Column(FilteredTable, "RTRFCostCodes.CostCodes"))
in
CountOfAmt,

A40
AddedCOUNTIFS = Table.AddColumn(#"Changed Type", "COUNTIFS", each
MyCOUNTIFFunction(#"Changed Type", [Week Ending], [RTRFCostCodes.CostCodes])),
#"Added Custom" = Table.AddColumn(AddedCOUNTIFS, "Week Ending Text", each
[Week Ending]),
#"Changed Type1" = Table.TransformColumnTypes(#"Added Custom",{{"Week Ending
Text", type text}}),
#"Added Custom1" = Table.AddColumn(#"Changed Type1", "Cost Code Lookup", each
[RTRFCostCodes.CostCodes]&"_"&[Week Ending Text]),
#"Merged Queries" = Table.NestedJoin(#"Added Custom1",{"Cost Code Lookup"},#"All
Costs",{"Cost Code Lookup"},"NewColumn",JoinKind.LeftOuter),
"NewColumn", {"AC"}, {"Total.AC"}),
#"Replaced Errors" = Table.ReplaceErrorValues(#"Expanded NewColumn",
{{"COUNTIFS", 0}}),
#"Added Custom2" = Table.AddColumn(#"Replaced Errors", "AC", each if [COUNTIFS]
= 0 then 0 else [Total.AC]/[COUNTIFS]),
#"Added Custom3" = Table.AddColumn(#"Added Custom2", "Activity Lookup", each
[RTRFActivity_cal]&"_"&[Week Ending Text])
in
#"Added Custom3"
Activities EV
let
Source = SubActivities_EV,
#"Grouped Rows" = Table.Group(Source, {"RTRFActivity_cal", "Week Ending"},
{{"EV", each List.Sum([EV]), type number}, {"AC", each List.Sum([AC]), type number}}),
Rows",{"RTRFActivity_cal"},#"Budgeted
Costs",{"RTRFActivity_cal"},"NewColumn",JoinKind.LeftOuter),
"NewColumn", {"Budgeted Value"}, {"Budgeted Value"}),
#"Merged Queries1" = Table.NestedJoin(#"Expanded
NewColumn",{"RTRFActivity_cal"},#"NRT Activities",{"Activity
Mapping"},"NewColumn",JoinKind.LeftOuter),
"NewColumn", {"Summary Activity Mapping", "Start Date", "Finish Date", "Duration"}, {"Summary
Activity Mapping", "Start Date", "Finish Date", "Duration"}),
#"Added Custom" = Table.AddColumn(#"Expanded NewColumn1", "Accumulated PV",
each if [Duration] = 0 then if [Week Ending] >= [Finish Date] then [Budgeted Value] else 0 else if
Duration.Days([Week Ending]-[Start Date])+1 < 0 then 0 else if Duration.Days([Week Ending]-[Start
Date])+1 > [Duration] then [Budgeted Value] else (Duration.Days([Week Ending]-[Start
Date])+1)*[Budgeted Value]/[Duration]),
#"Changed Type" = Table.TransformColumnTypes(#"Added Custom",{{"Accumulated
PV", Currency.Type}}),
=>
let
FilteredTable = Table.SelectRows(InputTable, each([Week Ending] < MyDate and
[RTRFActivity_cal] = MyAccount)),
MaxOfAmt = List.Max(Table.Column(FilteredTable, "Accumulated PV"))
in
MaxOfAmt,
AddedMAXIFS = Table.AddColumn(#"Changed Type", "MAXIFS", each
MyMAXIFFunction(#"Changed Type", [Week Ending], [RTRFActivity_cal])),
#"Added Custom1" = Table.AddColumn(#"Replaced Errors", "PV", each [Accumulated

A41
PV]-[MAXIFS])
in
#"Added Custom1"
Sub Cost Codes EV
let
#"Grouped Rows" = Table.Group(Source, {"RTRFCostCodes.CostCodes", "Week
Ending"}, {{"Budgeted Value", each List.Max([Budgeted Value]), type number}, {"EV", each
List.Sum([EV]), type number}, {"AC", each List.Sum([AC]), type number}, {"RTRF Activity", each
List.Max([RTRFActivity_cal]), type text}, {"JDE Cost Code", each
List.Max([RTRFCostCodes.JDECostCode]), type text}}),
#"Merged Queries" = Table.NestedJoin(#"Grouped Rows",{"RTRF Activity"},#"NRT
Activities",{"Activity Mapping"},"NewColumn",JoinKind.LeftOuter),
"NewColumn", {"Start Date", "Finish Date", "Duration"}, {"Start Date", "Finish Date", "Duration"}),
#"Added Custom1" = Table.AddColumn(#"Expanded NewColumn", "Accumulated PV",
each if [Duration] = 0 then if [Week Ending] >= [Finish Date] then [Budgeted Value] else 0 else if
Duration.Days([Week Ending]-[Start Date])+1 < 0 then 0 else if Duration.Days([Week Ending]-[Start
Date])+1 > [Duration] then [Budgeted Value] else (Duration.Days([Week Ending]-[Start
Date])+1)*[Budgeted Value]/[Duration]),
#"Changed Type" = Table.TransformColumnTypes(#"Added Custom1",{{"Accumulated
PV", Currency.Type}, {"AC", Currency.Type}, {"EV", Currency.Type}, {"Budgeted Value",
Currency.Type}}),
=>
let
FilteredTable = Table.SelectRows(InputTable, each([Week Ending] < MyDate and
[RTRFCostCodes.CostCodes] = MyAccount)),
MaxOfAmt = List.Max(Table.Column(FilteredTable, "Accumulated PV"))
in
MaxOfAmt,
AddedMAXIFS = Table.AddColumn(#"Changed Type", "MAXIFS", each
MyMAXIFFunction(#"Changed Type", [Week Ending], [RTRFCostCodes.CostCodes])),
#"Added Custom2" = Table.AddColumn(#"Replaced Errors", "PV", each [Accumulated
PV]-[MAXIFS])
in
#"Added Custom2"
Cost Codes EV
let
Source = SubCostCodes_EV,
#"Grouped Rows" = Table.Group(Source, {"JDE Cost Code", "Week Ending"}, {{"EV",
each List.Sum([EV]), type number}, {"AC", each List.Sum([AC]), type number}, {"PV", each
List.Sum([PV]), type number}})
in
#"Grouped Rows"
Summary Activities EV
let
Source = Activities_EV,
#"Grouped Rows" = Table.Group(Source, {"Summary Activity Mapping", "Week

A42
Ending"}, {{"EV", each List.Sum([EV]), type number}, {"AC", each List.Sum([AC]), type number},
{"PV", each List.Sum([PV]), type number}})
in
#"Grouped Rows"
SubActivities Progress
let
#"Grouped Rows" = Table.Group(Source, {"SubActivity_cal"}, {{"Budgeted Value", each
List.Max([Budgeted Value]), type number}, {"Last Progress", each List.Max([Week Ending]), type
date}, {"Total EV", each List.Sum([EV]), type number}, {"RTRFActivity_cal", each
List.Max([RTRFActivity_cal]), type text}, {"Total AC", each List.Sum([AC]), type none}})
in
#"Grouped Rows"
Activities Progress
let
Source = Activities_EV,
#"Grouped Rows" = Table.Group(Source, {"RTRFActivity_cal"}, {{"Budgeted Value",
each List.Max([Budgeted Value]), type number}, {"Total EV", each List.Sum([EV]), type number},
{"Start Date", each List.Max([Start Date]), type date}, {"Finish Date", each List.Max([Finish Date]),
type date}, {"Last Progress", each List.Max([Week Ending]), type date}, {"Total AC", each
List.Sum([AC]), type number}}),
#"Added Custom" = Table.AddColumn(#"Grouped Rows", "Percentage Complete", each
[Total EV]/[Budgeted Value])
in
#"Added Custom"
Activities Schedule
let
Source = #"NRT Activities",
#"Merged Queries" = Table.NestedJoin(Source,{"Activity
Mapping"},Activities_Progress,{"RTRFActivity_cal"},"NewColumn",JoinKind.LeftOuter),
"NewColumn", {"Last Progress", "Percentage Complete"}, {"Last Progress", "Percentage
Complete"}),
#"Removed Columns" = Table.RemoveColumns(#"Expanded NewColumn",{"Summary
Activity", "Activity ID", "Activity Status", "WBS Code", "WBS Name", "Activity Name", "Original
Duration (d)", "Start", "Finish", "Activity Type", "Physical % Complete(%)", "LCPL Text Generic
UDF 01", "N1006 Payment", "Code Mapping", "N1006 Summary Codes", "Free Float (d)", "Total
Float (d)", "Area", "Area (ORIS)", "Activity Group"})
in
#"Removed Columns"

A43
Appendix H - QlikView code in ViCon 3DBIS
// WBS MAPPING
// MAPPING TABLES
//
// Mapping DEPARTMENT
Mapping_WBS_Department_CodeToName:
MAPPING LOAD
[Department Code],
Title
FROM
[Mapping_Department.xlsx]
(ooxml, embedded labels, table is SP_Connection);
//
// Mapping LOCATION
Mapping_WBS_Location_CodeToName: // Code to Name
MAPPING LOAD
[Location Code],
Title
FROM
[Mapping_Location.xlsx]
Mapping_WBS_Location_NameToCode: // Name to Code
MAPPING LOAD
Title,
[Location Code]
FROM
//
// Mapping AREA
Mapping_WBS_Area_CodeToName:
MAPPING LOAD
Code,
Title
FROM
[Mapping_Area.xlsx]
// Mapping DETAILEDLOCATION
Mapping_WBS_DetailedLocation_CodeToName: // Code to Name
MAPPING LOAD
Code,
Title
FROM
[Mapping_DetailedLocation.xlsx]
Mapping_WBS_DetailedLocation_NameToCode: // Name to Code
MAPPING LOAD
Title,
Code
FROM
//
// Mapping DISCPLINE
Mapping_WBS_Discipline_CodeToName: // Code to Name
MAPPING LOAD
Code,
Title
FROM
//

A44
// Mapping SUBDISCIPLINE
Mapping_WBS_SubDiscipline_CodeToName: // Code to Name
MAPPING LOAD
Code,
Title
FROM
[Mapping_SubDiscipline.xlsx]
Mapping_WBS_SubDiscipline_CodeToName: // Name to Code
MAPPING LOAD
Title,
Code
FROM
// Mapping OBJECTS
Mapping_WBS_Object_CodeToName: // Code to Name
MAPPING LOAD DISTINCT
Code,
Title
FROM
Mapping_Object.xlsx
//
// REGULAR TABLES
// Table Discipline Code <-> Name
// Department
WBS_Department:
LOAD DISTINCT
[Department Code] AS WBS_Department_Code,
Title AS WBS_Department_Name
FROM
[Mapping_Department.xlsx]
JOIN LOAD * INLINE [
WBS_Department_Code, WBS_Department_Name
-, -
];
// Location
WBS_Location:
LOAD DISTINCT
[Location Code] AS WBS_Location_Code,
Title AS WBS_Location_Name
FROM
WBS_Location_Code, WBS_Location_Name
-, -
];
// Area
WBS_Area:
LOAD DISTINCT
Code AS WBS_Area_Code,
Title AS WBS_Area_Name
FROM
Mapping_Area.xlsx
WBS_Area_Code, WBS_Area_Name
-, -
];
// Detailed Location
WBS_DetailedLocation: // Code to Name

A45
LOAD
Code AS WBS_DetailedLocation_Code,
Title AS WBS_DetailedLocation_Name
FROM
WBS_DetailedLocation_Code, WBS_DetailedLocation_Name
-, -
];
// Discipline
WBS_Discipline:
LOAD DISTINCT
Code AS WBS_Discipline_Code,
Title AS WBS_Discipline_Name
FROM
[Mapping_Discipline.xlsx]
WBS_Discipline_Code, WBS_Discipline_Name
-, -
];
// SubDiscipline
WBS_SubDiscipline:
LOAD DISTINCT
Code AS WBS_SubDiscipline_Code,
Title AS WBS_SubDiscipline_Name
FROM
WBS_SubDiscipline_Code, WBS_SubDiscipline_Name
-, -
];
// Objects
WBS_Object: // Code to Name
LOAD DISTINCT
Code AS WBS_Object_Code,
Title AS WBS_Object_Name
FROM
Mapping_Object.xlsx
WBS_Object_Code, WBS_Object_Name
-, -
];
//
// WBS
// Load WBS Codes and Assign Names
WBS:
LOAD
if(LEN(TRIM(DepartmentCode))>0, DepartmentCode, '-') AS WBS_Department_Code,
[Location Code] AS WBS_Location_Code,
[Area Code] AS WBS_Area_Code,
[Detailed Location Code] AS WBS_DetailedLocation_Code,
[Discipline Code] AS WBS_Discipline_Code,
[SubDiscipline Code] AS
WBS_SubDiscipline_Code,
ObjectCode AS WBS_Object_Code
FROM
[NRT WBS_2015-05-21.xlsx]
(ooxml, embedded labels, table is WBS);
//
// Model Data / Attributes
//
LOAD Guid,

A46
cpID,
Activity_Id,
WBS_Department_Code,
WBS_Location_Code,
WBS_Area_Code,
WBS_DetailedLocation_Code,
WBS_Object_Code,
WBS_Discipline_Code,
WBS_SubDiscipline_Code
FROM
Guid_cpID_ActivityId_WBS.qvd
(qvd);
//
// Model Attributes - Volume
cpId_To_Quantities:
LOAD
cpID AS cpID,
cpCountTriangles As cpCountTriangles,
cpTopArea AS cpTopArea,
cpSurfaceArea AS cpSurfaceArea,
num(Volume) AS Obj_Volume,
num(Diameter) AS Obj_Diameter,
num(Width) AS Obj_Width,
num(Height) AS Obj_Height
FROM
[Model_Quantities.xlsx]
(ooxml, embedded labels, table is Model_Quantities)
WHERE
cpCountTriangles > '0' ;
// create temporary table containing ActivityID and Volume
// to calculate volume based on ActivityID
// Join of two tables with cpID as common field
// [Chose cpID to map]
tmp_Joined_Quantity_Activity:
LOAD
cpID AS cpID_A,
Activity_Id AS Activity_Id_A
RESIDENT
Guid_cpID_ActivityId_WBS;
JOIN LOAD
cpID AS cpID_A,
num(Volume) AS cpVolume_A
FROM
[Model_Quantities.xlsx]
(ooxml, embedded labels, table is Model_Quantities)
WHERE
cpCountTriangles > '0' ;
//
// Calculate volume of activities
tmp_ActivityId_To_Volume:
MAPPING LOAD
Activity_Id_A,
if(sum(cpVolume_A)='','0',sum(cpVolume_A))
RESIDENT
tmp_Joined_Quantity_Activity
WHERE
(NOT ISNULL(cpVolume_A))
GROUP BY
Activity_Id_A;
// Drop temporary table
DROP TABLE
tmp_Joined_Quantity_Activity;
// Activities
//
// Load activity information from table

A47
// Add the previously calculated activity volume
// Later, the
tmp_Activity_Information:
LOAD
[Activity ID] AS Activity_Id,
[N1006 Payment] AS PaymentItem_Id,
[Activity Name] AS Activity_Name,
[Activity Type] AS Activity_Type,
NUM(SUBFIELD([Original Duration], 'd', 1)) AS Activity_Duration,
Start AS Activity_StartDate,
Finish AS Activity_EndDate,
[N1006 Summary Codes],
APPLYMAP('tmp_ActivityId_To_Volume', [Activity ID], NULL()) AS Activity_Volume
FROM
[Delivery Program as at 12 Jun 2015.xlsx]
(ooxml, embedded labels, table is Sheet1)
WHERE
([N1006 Summary Codes] <> 'IPS');
//
// Payment Items (Id, Description, Amount, Unit)
Payment_Items:
LOAD
Item AS PaymentItem_Id,
Description AS PaymentItem_Description,
Amount AS PaymentItem_Amount,
Unit AS PaymentItem_Unit,
Level1 AS PaymentItem_Level1,
Level1_Text AS PaymentItem_Level1_Text,
Level2_Text AS PaymentItem_Level2_Text,
Level3_Text AS PaymentItem_Level3_Text
FROM
[Payment_Items_Activity_Mapping.xlsx]
(ooxml, embedded labels, table is Tabelle1);
//
// Payment Items - Activity Duration
// I don't use a mapping table here because this table is later used in a join
PaymentItem_ActivityVolumeDuration:
LOAD
PaymentItem_Id AS PaymentItem_Id,
sum(Activity_Duration) AS PaymentItem_ActivitiesDuration, //
Duration of the activities that belong to the payment item
sum(Activity_Volume) AS PaymentItem_ActivitiesVolume
RESIDENT
tmp_Activity_Information
GROUP BY
PaymentItem_Id;
//
// Payment Items - Weighting
tmp_ActivityAndPaymentItem_VolumeAndDuration:
LOAD
Activity_Id AS Activity_Id_W,
Activity_Duration AS Activity_Duration_W,
Activity_Volume AS Activity_Volume_W,
PaymentItem_Id AS PaymentItem_Id_W
RESIDENT
tmp_Activity_Information;
JOIN
LOAD
PaymentItem_Id AS PaymentItem_Id_W,
PaymentItem_ActivitiesDuration AS PaymentItem_ActivitiesDuration_W,
PaymentItem_ActivitiesVolume AS PaymentItem_ActivitiesVolume_W
RESIDENT
PaymentItem_ActivityVolumeDuration;
// Activities weighted

A48
Activity_Weighting_VolumeBased:
MAPPING LOAD
Activity_Id_W,
Activity_Volume_W / PaymentItem_ActivitiesVolume_W
RESIDENT
tmp_ActivityAndPaymentItem_VolumeAndDuration;
// Activities weighted
Activity_Weighting_DurationBased:
MAPPING LOAD
Activity_Id_W,
Activity_Duration_W / PaymentItem_ActivitiesDuration_W
RESIDENT
DROP TABLE
// Activity Information
Activity_Information:
LOAD
Activity_Id,
PaymentItem_Id,
Activity_Name,
Activity_Type,
Activity_Duration,
Activity_StartDate,
Activity_EndDate,
Activity_Volume,
APPLYMAP('Activity_Weighting_VolumeBased', Activity_Id, 'Not found')
AS Activity_Weighting_VolumeBased,
APPLYMAP('Activity_Weighting_DurationBased', Activity_Id, NULL())
AS Activity_Weighting_DurationBased
RESIDENT
tmp_Activity_Information;
DROP TABLE tmp_Activity_Information;
// PRIMAVERA
// Level Texts
P6WBS_Level1_IdToName:
[WBS Code] as P6WBSLevel1_Id,
[WBS Name] as P6WBSLevel1_Name
FROM
[Delivery Program as at 31 May 2015.xlsx]
(ooxml, embedded labels, table is Sheet3);
FROM
FROM
FROM

A49
FROM
FROM
//
// Map Activity ID to P6 Level
// // Difference between MainActivities and SubActivites: [N1006 Summary Codes] ->
see WHERE
P6_SubActivities:
LOAD
subfield(WBS,'.',1)&'.'&subfield(WBS,'.',2) AS P6WBSLevel1_Id,
APPLYMAP('P6WBS_Level1_IdToName', WBS, '-') AS P6WBS_Level1_Name,
subfield(WBS,'.',1)&'.'&subfield(WBS,'.',2)&'.'&subfield(WBS,'.',3)
AS P6WBSLevel2_Id,
subfield(WBS,'.',1)&'.'&subfield(WBS,'.',2)&'.'&subfield(WBS,'.',3)&'.'&subfield(WB
S,'.',4) AS P6WBSLevel3_Id,
S,'.',4)&'.'&subfield(WBS,'.',5) AS P6WBSLevel4_Id,
S,'.',4)&'.'&subfield(WBS,'.',5)&'.'&subfield(WBS,'.',6)
AS P6WBSLevel5_Id,
S,'.',4)&'.'&subfield(WBS,'.',5)&'.'&subfield(WBS,'.',6)&'.'&subfield(WBS,'.',7)
AS P6WBSLevel6_Id,
num(subfield([Original Duration],'d',1)) AS SubActivity_Duration,
DATE(
ALT(
DATE#(Start, 'DD-MMM-YY A'),
DATE#(Start, 'DD-MMM-YY*'),
Start
),
'DD.MM.YYYY')
AS SubActivity_StartDate,
DATE(
ALT(
DATE#(Finish, 'DD-MMM-YY A'),
DATE#(Finish, 'DD-MMM-YY*'),
Finish
),
'DD.MM.YYYY')
AS SubActivity_FinishDate
FROM
(ooxml, embedded labels, table is Sheet1)
WHERE
([N1006 Summary Codes] <> 'IPS');
//
// Main Activites
// Difference between MainActivities and SubActivites: [N1006 Summary Codes] -> see
WHERE
P6_MainActivites:

A50
LOAD
[Activity Name] AS MainActivity_Name,
[Activity Type] AS MainActivity_Type,
// WBS as MainWBSCode,
// [WBS Name] as MainWBSName,
subfield([Original Duration],'d',1) AS MainActivity_Duration,
// [N1006 Payment] as PaymentItem,
DATE(
ALT(
DATE#(Start, 'DD-MMM-YY A'),
DATE#(Start, 'DD-MMM-YY*'),
Start
),
'DD.MM.YYYY') AS
MainActivity_StartDate,
DATE(
ALT(
DATE#(Finish, 'DD-MMM-YY A'),
DATE#(Finish, 'DD-MMM-YY*'),
Finish
),
'DD.MM.YYYY') AS
MainActivity_FinishDate
FROM
(ooxml, embedded labels, table is Sheet1) WHERE([N1006 Summary Codes] =
'IPS');
LOAD RTRFActivity_cal as Activity_Id,
[Week Ending],
EV,
AC,
PV
FROM
[Progress Calculations Workbook - Copy (V1).xlsx]
(ooxml, embedded labels, table is [Activities Data]);
LOAD [Activity Mapping] as Activity_Id,
[Start Date],
[Finish Date],
Duration,
[Last Progress],
[Percentage Complete]
FROM
[Progress Calculations Workbook - Copy (V1).xlsx]
(ooxml, embedded labels, table is [Activities Schedule Data]);

A51
Appendix I - Process guide for implementation

THESIS - Ryan Caetano Thesis Submission

More Related Content

Similar to THESIS - Ryan Caetano Thesis Submission (20)

THESIS - Ryan Caetano Thesis Submission