Power to the Edge: A Work Tracking
System for Construction
Nelly P. Garcia-Lopez, Dr. Martin Fischer, Dr. Raymond E. Levitt
Abstract
The rapid development of Virtual Design and Construction (VDC) methods during the last few years has
enabled progressive construction firms to improve their productivity. However, we are still far from
realizing the full benefits that VDC has to offer. This research paper analyzes the development of a Work
Tracking System (WTS) for construction. This system manages the information flows between workers
and management, allowing them to publish and get information from the system as needed. The
Building Information Model (BIM) is used to visualize work being performed by linking tasks to specific
BIM elements and exporting an updated task list. Mobile devices and cloud computing are leveraged to
bring the information and technology to the field, where the information is needed.
Introduction
Building Information Modeling (BIM) is revolutionizing the construction industry and forcing it to change
its traditional work processes. Progressive companies have seen this revolution as a strategic
opportunity to leverage technology to develop a competitive edge. Furthermore, according to McGrawHill Construction, as of 2012 more than 71% of the construction industry in North America is using BIM
and seeing unprecedented improvements in productivity and positive returns on investment (Jones and
Bernstein 2012). Recently, mobile apps supporting BIM-based information and processes have begun to
be used on construction sites to support field operations. This research presents the development of an
onsite Work Tracking System (WTS) for construction which leverages BIM, advances in cloud computing
and pervasiveness of handheld devices to track task completion, and improve on site productivity.
Observed problem
Construction control state of the art tools and methods do not provide an easy interface that allows
project stakeholders to understand what the current state of the project is with respect to the plan.
Schedules are management tools that are supposed to answer the question: WHO is doing WHAT,
WHEN? However, currently it is impossible for project managers, superintendents and field engineers to
answer this question once the project has started. What is the status of X task? Unless a problem has
been detected or a milestone has not been met, managers are generally unable to report a clear task
status, or they assume that everything is going well.
One of the reasons for this is that updating schedules takes an excessive amount of time using current
tools and methods. Not only do superintendents or field engineers have to walk the site and take note
of task progress to update this in the schedule, but they also need to deal with an inflexible schedule
structure to modify the task order, add levels of detail or change the construction method. As a result,
project schedules are always outdated, which makes it impossible for supervisors to use project
management tools, such as earned value and resource planning, to optimize work sequencing,
subcontractor coordination and subcontractor pay. Because of the lack of tools, supervisors rely on
their intuition to make decisions. In complex projects this might lead to suboptimal allocation of
resources and increased rework.
However, lack of clarity in the task status as well as the prioritization of tasks is not a problem that is
faced by supervisors only. Timely communication about the task scope, materials, methods and
resources is critical to avoid construction rework, which leads to wasted time, materials and energy
(Mourgues et al. 2008, 2012). With the emergence of mobile devices such as smartphones and tablets,
we should be able to quickly and effectively establish a two-way communication between workers and
supervisors (Saidi et al. 2002).
Research on the use of information technology in field construction has primarily focused on finding
ways of leveraging advances in hardware and data exchange protocols in the field. Chen and Kamara
formulated a framework for choosing the appropriate hardware and wireless communication protocols
to support on site management and different user roles (Chen and Kamara 2011). Deibert et al.
developed a theoretical model based on Task-Technology-Fit to analyze the theoretical impact of
applying technology to certain operations (Deibert et al. 2009). Similarly, Wang et al. developed a
framework for mapping the construction task profile with the appropriate technology to support those
tasks (Wang et al. 2006). Other approaches have focused on how to use a specific technology in
construction. The use of barcodes, RFIDs and PDAs have been linked with material tracking and
inventory control, (McCullouch and Lueprasert 1994; R.Navon and O.Berkovich 2012; Skibniewski and
Wooldridge 1992; Tserng et al. 2005; Wang et al. 2007) as well as progress tracking and inspections
(Ghanem and AbdelRazig 2006; Wang 2008). Improvements in both hardware and software have made
it possible to visualize 3D models in mobile devices (Lipman 2004; Mulloni et al. 2007), share
information among different team members effectively (Ochoa et al. 2010), and develop augmented
reality hardware-software packages such as the iHelmet (Yeh et al. 2012). Our approach differs from
previous research in that we focus on the information flows that workers currently require in their daily
operations, and suggest possible solutions that help make those information flows more effective.
Whereas previous approaches have focused on fitting a technological solution to solve a specific
problem, our approach is to understand the problem and suggest a suitable technological solution to it.
Emerging commercial mobile solutions have centered their attention in visualization, tracking punch lists
and timesheets. Software packages such as Autodesk BIM 360, allow workers to create punch lists
directly in the field using iPads and support BIM (Autodesk Inc 2013). Similarly, other applications allow
the user to store the floor plans in the cloud and synchronize the floor plans between devices (Plan Grid
2013) or create day to day reports through mobile devices (Construction Centrics LLC 2013; UDA
Construction Online TM 2013). However, these applications do not tie into a centralized system which
propagates these changes across the different project dimensions, including schedule.
In a rapidly evolving environment where projects are getting more complex every day, we need
information systems that can help managers and workers deal with this complexity more effectively and
efficiently. One of the ways of responding to these challenges is to empower construction workers by
leveraging Virtual Design and Construction (VDC) methods (Fischer and Kunz 2004; Garcia et al. 2004;
Kam and Fischer 2004; Kunz and Fischer 2009) to effectively bring “power to the edge” (Alberts and
Hayes 2005; Levitt 2011; Ramsey and Levitt 2005). However, important theoretical gaps must be closed
to truly bring power to the edge—i.e., to enable the construction workforce to work hand-in-hand with
project management, in more decentralized ways. Key gaps we propose to address in this research are:
the lack of a clear communication of design information and schedules – i.e., a clear definition of the
information required by laborers for safe and productive construction; and the lack of a clear definition
of work completion—i.e., what “done” looks like. Without such definitions, management techniques
such as Kanban (Ohno 1988) that have helped the manufacturing industry reduce variability, reduce
waste, increase output, and improve quality cannot be applied effectively in construction and support
the principles of Lean Construction (Ballard and Howell 2003) such as just in time delivery, last planner
and workflow reliability.
Method
The objective of this research was to understand how advances in cloud computing, mobile devices and
VDC could be leveraged to improve work related information flows among workers in the field. We were
particularly interested in analyzing information flows that were related to work tracking such as: task
communication and assignment, task progress and task reporting.
To achieve this objective, we carried out two main research tasks. The first task was to understand the
work related information flows between the different stakeholders in a construction site. The second
task was to develop a simplified working prototype of the idealized system to test the core
functionalities.
In the first part of the research, we leveraged the researcher’s previous construction experience to
formulate hypothesis about each stakeholder’s information requirements, i.e., what information they
require to perform their daily tasks; and information outputs, i.e., what information they produce or
have access to. After formulating our main hypothesis, we conducted informal interviews with the
different stakeholders (project manager, superintendent, project engineers, subcontractor foreman, and
workers) at two construction sites. These informal interviews allowed us to complement our initial
hypothesis and correct any misinterpretations.
Once we had a clear idea of the information flows and the requirements from each stakeholder, we
leveraged scenario planning (Godet 2000) to develop an idealized Work Tracking System (WTS), which
consolidated all the information flows and how they should be presented to the users.
The second part of the research consisted on developing a prototype of the WTS developed in the first
part of the research. Because of time limitations as well as some technology gaps that we identified, we
had to narrow down the scope of the WTS and focus on some core functionalities that would allow us to
communicate tasks to workers, track task progress and report completion. To understand what these
requirements were, the research assistant for this project became involved in building and managing the
Solar Decathlon Project, which was a student led project to design and build a 1,000 SF net-zero house.
During her involvement in the project, she collected information regarding what factors influenced
communication breakdowns and rework in the project, and how these could be overcome using the
idealized prototype system that we had developed earlier in the project. After the project was
completed, we carried out a retrospective case study (Ho et al. 2009) compiling and classifying the
observations to prioritize the features. After compiling the list, we interviewed four people involved in
the project and inquired whether they agreed with our prioritized list of features. These interviews
helped us prioritize the features as well as determine which ones are more useful to a certain
stakeholder.
After identifying the core features that would be included in the prototype, we developed a web-based
prototype of the system using the Google App Engine development framework, which provides a simple,
scalable model for building web applications (“Goggle App Engine” 2013). The backend was
programmed using Python and the data was stored using the App Engine Datastore. During prototype
development, we worked closely with the project manager, superintendent, foreman and two workers
in a mid-rise residential building who provided valuable input regarding user interface design and
usability of the web-based prototype.
Development of the Work Tracking System (WTS)
Scenario planning is used by organizations as a tool to aid in strategic planning (Godet 2000). By focusing
on the future, people can loosen the constraints they have about current practice and its limitations,
and focus on what is possible. Hence, scenario planning shifts the focus from finding specific solutions to
a problem, to designing a system where those problems do not exist.
Using this technique, we designed an idealized system by asking ourselves: What information is each
stakeholder interested in accessing with minimum latency? What information would help them make
better decisions, be more autonomous and be more productive? Who produces the information
required from each stakeholder? How easy is it to gather that information?
To answer those questions, we leveraged the author’s construction and field experience as well as
interviews with project managers, superintendents, foremen, subcontractors and workers. Table 1
shows a summary of the information flows that each stakeholder is interested in accessing and the
information that they produce. We can see that the information required by a stakeholder is produced
by a different stakeholder. For example, the superintendent is interested in knowing the status of the
tasks that are currently being carried out in the project. This information is produced by the workers
who are currently carrying out the work. Therefore, the challenge to overcome is to design a system that
makes it easy for all the stakeholders to share the information that they produce so that it can be used
by others with minimum latency.
T ABLE 1: I NFORMATION FLOWS TO AND FROM THE DIFFERENT PROJECT STAKEHOLDERS
Stakeholder
Information required
Information produced
Superintendent








Progress reports
Task status
Punch lists
Quality reports
Subcontractor PPC
Subcontractor progress
Quality reports
Issue reports
 Planned schedule
 Updates to schedule
 Task coordination




Drawings, BIM, Specifications
RFIs
Change orders
Progress payments
Subcontractors




Updated schedule
Prioritized task list
Updated Drawings/BIM/Specs
RFI responses





Task assignment
Task completion/signoff
Punch list
Issues
RFIs
Workers






Updated schedule
Prioritized task list
Updated Drawings/BIM/Specs
Parts list
Tool list
Instructions/Checklist
 Task completion
 Issue reporting
Project
Manager/Project
Engineers
The proposed Work Tracking System (WTS) will serve as an information broker that processes the data
produced by the stakeholders and consolidates it in a way that can be easily retrieved and repurposed
for use by a different stakeholder. Following the previous example, it will gather the task completion
data reported by all the workers and consolidate it in a report that is useful for the superintendent.
To achieve this, the WTS will need to communicate with the existing IT solutions in the jobsite where the
information is stored. The WTS will update the information available in these systems according to the
inputs from the stakeholders so that the information across the different platforms is updated and
synchronized. Similarly, it will pull the information from these systems and reformat it in reports that
are useful to the different stakeholders. Figure 1 summarizes the information that each stakeholder
wants to get from the system as well as what information can be supplied (published) by each. Similarly,
it shows how the WTS integrates and synchronizes the information with existing IT platforms being used
in projects today; Enterprise Resource Management systems, scheduling systems, BIM and estimating
systems.
Leveraging current state of the arts technology and the trend towards mobile devices, the WTS should
be cloud based to allow real time communication leveraging distributed processing, decreasing storage
costs and variable costs through the life cycle of the project, i.e., leveraging Hardware as a Service –
HaaS.
F IGURE 1: T HE WORK T RACKING SYSTEM KEEPS THE DIFFERENT SYSTEMS UPDATED SO THAT THE INFORMATION IT
RETRIEVES IS THE MOST CURRENT AVAILABLE
After understanding the information flows that each stakeholder wants to have access to as well as
what information is required from them by others, we developed low resolution wireframes to display
the user interface for the different stakeholders.
Superintendent:
Superintendents are interested in having an overall vision of how the project is doing with respect to
schedule so that they can focus their attention on what issues are arising and solve them before they
impact production. We designed four views that are useful for superintendents: a dashboard,
subcontractor statistics, a task view and a BIM view.
Superintendent Dashboard:
Figure 2 shows the dashboard designed for the superintendent. This view is divided into two main
sections showing the sprints that are in progress and the task backlog. The sprints consist of work that
has already been assigned to a specific worker and is reported as started. The backlog shows all the
upcoming tasks which are pulled from the schedule. Each task has the following information:









Status
Subcontractor
Task name
Planned Start (P.S.)
Planned Finish (P.F)
Actual Start (A.S.)
Actual Finish (A.F.)
Difference (Start and Finish)
Alert.
The task status is symbolized by the icon in the first column of the dashboard. Tasks that are part of
the current sprint are represented with a triangle, whereas tasks that are in the backlog are
represented with a square. The color of each of these shapes indicates the status of the task:



Green: task started on time.
Yellow: task started late but is not delayed yet.
Red: task is delayed.
Additionally, flags are used to express task priority according to the schedule impact of each task.



High priority: denoted by a red flag. These are tasks that are in the critical path according to the
schedule. A delay in these tasks will impact downstream activities. An alert will tell the
subcontractor what task will be impacted directly.
Medium priority: denoted by a yellow flag. These tasks have a free float but are predecessors to
critical path activities. Hence, if they are delayed by more than the free float they will delay the
whole project. An alert will inform the superintendent about the amount of the free float.
Low priority: These are tasks that are neither in the critical path nor are predecessors to critical
path activities.
By leveraging the task status and the task priority, superintendents will be able to focus their
attention on the tasks that are most critical for the project, and make better decisions with respect
to resource allocation.
http://worktrackingsystem.com/stanfordProject
Adam
Work Tracking System Dashboard
Dashboard
Subcontractor Stats
Superintendent
Task View
BIM View
Sprints in Progress
Sub.
Task
P.S.
P.F.
A.S.
A.F.
Framer
Framer
Mechanical
Framer
Electrical
Framer
L1-ZoneC-Frame Wall 2C
L1-ZoneC-Frame Wall 1C
L1-ZoneA-Install HVAC ducts ZA
L1-ZoneB-Frame Wall 2B
L1-ZoneA-Install conduit ZA
L1-ZoneB-Frame Wall 1B
01/15
01/16
01/16
01/16
01/16
01/16
01/16
Today
Today
Today
Today
Today
01/16
01/17
01/16
01/16
01/16
01/16
01/16
Framer
Framer
L1-ZoneB-Frame Wall 3B
L1-ZoneB-Frame Wall 4B
01/17
01/17
01/18
01/19
Framer
Electrical
L1-ZoneC-Frame Wall 3C
L1-ZoneB-Install conduit ZB
01/18
01/18
01/20
01/22
Mechanical
L1-ZoneB-Install HVAC ducts ZB
01/18
01/22
Dry wall
Dry wall
L1-ZoneC-Rock Wall 1C
L1-ZoneC-Rock Wall 2C
01/18
01/16
01/19
01/17
Dry wall
Window
L1-ZoneB-Rock Wall 2B
01/18
L1-ZoneA-Install windows ZA East 01/18
01/19
01/21
Difference
S.
F.
1
1
-
1
-
Backlog
1
1
-
-
-
-
1
-
-
-
Alert
Affects
Install
Elevator
Delays
install
server
Free float: 1D
Potential
delay
Predecessor
delay
F IGURE 2: D ASHBOARD VIEW DESIGNED FOR THE SUPERINTENDENT P ROVIDES A VISUAL REPRESENTATION OF THE
WORK IN PROGRESS (SPRINTS), AND THE STATUS OF EACH OF THE TASKS .
Subcontractor view:
Figure 3 shows the Subcontractor Statistics View, which can be used by the superintendent as well as
the project manager to evaluate subcontractor performance. The report contains useful information
including:






Work In Progress:
o Tasks started on time
o Tasks started late
o Delayed tasks
Task backlog (Upcoming tasks)
Finished Tasks:
o Tasks finished late
o Tasks finished on time
Tasks with issues reported
Percent Plan Complete (PPC)
Trends
This report allows superintendents to track subcontractor progress and take corrective measures in a
timely basis.
http://worktrackingsystem.com/stanfordProject
Adam
Work Tracking System Dashboard
Dashboard
Subcontractor Stats
Superintendent
Task View
Subcontractor Stats View
Backlog
Finished Tasks
– Not
Late
Started On time
Work in Progress – Active Sprints
Sub.
Started on Time Late Start
BIM View
Delayed
Tasks
with
issues
PPC
8 (3%)
62%
PPC
Trends
Electrical
10 (55%)
5 (28%)
3 (17%)
100
20 (66%) 10 (34%)
Framing
20 (36%)
15 (27%)
20 (36%)
300
50 (71%) 20 (29%) 20 (16%)
56%
PPC
Mechanical
30 (83%)
5 (14%)
1 (3%)
50
20 (90%)
86%
Issues
Dry wall
10 (55%)
5 (28%)
3 (17%)
400
30 (75%) 10 (25%) 10 (17%)
69%
PPC
Window
5 (71%)
2 (29%)
0 (0%)
50
5 (71%)
71%
Late
2 (1%)
2 (29%)
2 (3%)
1 (7%)
F IGURE 3: SUBCONTRACTOR STATISTICS VIEW
Task view:
The report shown in Figure 4 uses the information about activity start and finish to compute the real
productivity rate from the subcontractors, given a set of quantities from the model. This information can
be leveraged by the project to estimate schedule impacts as well as to reevaluate the historical
productivity rate logs for the company. Similarly, the company will have a better record of the crew’s
learning curve during the project, which can help them make better duration estimates for future
projects.
http://worktrackingsystem.com/stanfordProject
Adam
Work Tracking System Dashboard
Dashboard
Subcontractor Stats
Superintendent
Task View
BIM View
Task – Activity View
Work in Progress – Active Sprints
Sub.
Task
UoM
Est. Unit/hr
Avg. Unit/hr
Avg. vs Est.
Max Unit/hr Min Unit/hr
Ft
30
22
+10%
25
18
Electrical
Install conduit
Framing
Frame 2x4 stud wall
SqFt
100
90
-10%
100
80
Mechanical
Install HVAC ducts
Ft
15
20
+33%
25
10
Dry wall
Rock walls 3/8" dry
SqFt
200
160
-20%
210
130
Window
Install Type 1 window
Ea
0.2
0.3
+50%
.35
.15
F IGURE 4: T ASK VIEW TRACKING PRODUCTIVITY RATE BY TASK.
Trend
BIM View:
The BIM view will show the scheduler a color coded BIM, denoting the status of the work performed
using the same color coding as the task status.
Subcontractor Foreman:
The subcontractor foreman is interested in looking at the status of the tasks associated with him. This is
because in a pull production system, the superintendent will not assign a sprint to the subcontractor
until the predecessor task is completed, avoiding interdependencies.
Similar to the Superintendent Dashboard described above, the Subcontractor Dashboard (Figure 5) will
show tasks divided into current sprints and backlog. In this case, however, the subcontractor foreman
has the ability to assign tasks to individual workers. Once a task is released by the superintendent,
added to the foreman’s sprint list, they can assign it to an individual worker. Following the logic of the
pull system, each worker will only have one sprint assigned at a time.
The BIM view will show the status of all the tasks assigned to the subcontractor foreman. Finally, the
Progress by worker tab will show a dashboard representing individual worker’s productivity, allowing
the foreman to incentivize their crew and notice any gaps where a worker might be missing a skill or
lagging with respect to his colleagues.
Framing Foreman
Stanford Project
Task Dashboard
BIM View
Progress by worker
Sprints in progress:
P.F.
A.S
A.F
Difference
S F
Assigned
P.S.
L1-ZoneB-Frame Wall 1B
Joe
01/16
Today 01/16
-
-
L1-ZoneB-Frame Wall 2B
Matt
01/16
Today 01/16
-
-
L1-ZoneC-Frame Wall 1C
Alice
01/16
01/18
01/17
1
-
L1-ZoneC-Frame Wall 2C
Rob
01/15
01/16
01/16
1
1
L1-ZoneB-Frame Wall 3B
Jen
01/17
01/18
1
L1-ZoneB-Frame Wall 4B
Chris
01/17
01/19
1
L1-ZoneC-Frame Wall 3C
Mike
01/18
01/20
-
L1-ZoneC-Frame Wall 4C
Alice
01/18
01/20
-
L1-ZoneC-Frame Wall 5C
Matt
01/18
01/20
-
Backlog:
F IGURE 5: SUBCONTRACTOR FOREMAN DASHBOARD
Individual worker:
Interviews with workers revealed that they spend a large portion of their time asking about what tasks
they should be performing, obtaining the information required to perform those tasks in form of plans,
specifications, instructions, as well as the tools and materials needed to perform them.
Following production best practices, such as providing workers with visual aids that facilitate their job
(Greif 1991), we designed a user interface that helps workers understand the tasks that they are
expected to be performing (currently assigned sprints) as well as upcoming tasks. Similarly, it gives them
a summary of their previous performance, allowing them to see which tasks they completed late or on
time. This dashboard can be seen in Figure 6.
Stanford
Project
Joe
Framing Co.
Sprints:
L1-ZoneB-Frame Wall 1B
Due
Today
Backlog:
L1-ZoneA-Frame Wall 5A
Due
Tue
L1-ZoneA-Frame Wall 4A
Tue
Completed:
þ
þ
þ
L1-ZoneA-Frame Wall 3A
Finished
01/18
L1-ZoneA-Frame Wall 2A
01/17
L1-ZoneA-Frame Wall 1A
01/16
F IGURE 6: I NDIVIDUAL WORKER DASHBOARD
By clicking on one of the tasks, the worker can get access to information relevant to the task (Figure 7).
This view allows the worker to report task completion as well as report any issues. For example, they
can report conflicts with respect to missing information, lack of material availability, lack of tools, safety
concerns, etc. Similarly, the WTS will provide access to all the relevant drawings, specifications and a
BIM View. It will also provide a parts list, which includes the entire quantity take offs for the task, a tool
list and checklists for performing the work. Following Kaizen methodology of continuous improvement
(Imai 1986), by providing the workers with all the information they require for performing the task and
breaking it down into manageable pieces of information, workers can be more productive and efficient.
Stanford
Project
Task:
Joe
Framing Co.
L1-ZoneB-Frame
Wall 1B
Complete
Issue
Drawings BIM View
Floor plan
Specs
Shop drawing
Other views
Parts List Tool List Checklist
F IGURE 7: I NDIVIDUAL WORKER TASK INSTRUCTIONS
The worker dashboard (Figure 6) and the task information (Figure 7) mockups were the ones that
received most positive feedback from the managers and workers we interviewed. One of the foremen
we interviewed was excited about having all the information available on his mobile phone, since he
confessed that it took him a considerable amount of time to go back to the trailer and check the
specifications, RFI responses and plans. Similarly, one of the workers mentioned that having the parts
list would allow him to easily check material availability and raise concerns about this quickly to the
foreman. Also, he mentioned that the tool list prevented him from forgetting a tool and having to walk
back to get it.
Supplying just in time information to workers remains one of the most difficult problems to solve from a
technical perspective, since it requires that reasoning be applied to the BIM to obtain the views
associated to a particular task. However, as cloud computing becomes more ubiquitous and software
that was traditionally manipulated in local computers moves into the cloud, e.g. Autodesk BIM 360 Field
and Autodesk® BIM 360™ Glue®, this limitation will likely be overcome.
Work Tracking System prototype
Determining the WTS Core features
Due to time limitations, as well as other technological and theoretical gaps highlighted in the previous
section, we needed to narrow down the WTS to a set of core features that would allow us to provide all
the core functionality of the WTS, but be achievable given the time frame we had. To determine these
core features, we carried out a retrospective case study (Ho et al. 2009) of the lessons learned while
building the Solar Decathlon House. The observations were classified into different categories, and we
generated a list of prioritized features. With this list in mind, we interviewed four members of the Solar
Decathlon Team, and asked them to suggest improvements or make modifications. In addition to
helping us complete our prioritized list of features, these interviews allowed us to notice which features
were more important to a certain type of stakeholder. For example, we determined that the most
important feature for the superintendents was the dashboard tracking task progress, while the most
important feature for the foreman was the ability to create tasks and assign it to specific crews during
the weekly planning sessions. The final list of core features can be found bellow.
Core Features:



Task status dashboard showing:
o Task status (Future Activity, Started on Time, Has not started, …)
o Task assignment (crews/specific people)
o BIM element/Location
o Planned Start
o Planned Finish
o Actual Start
o Actual Finish
Create/Update tasks:
Visualization of the work being performed
System Architecture
Taking into account the core features as well as the feedback from the stakeholders, we developed the
architecture for the Work Tracking System (WTS) prototype. The big idea was to connect the
visualization information that is available in the BIM with the tasks in our WTS prototype. This way,
managers could export the current task information and have a real time 4D visualization of the work
progress.
WTS Architecture
Table 2 shows a summary of the stakeholder’s use cases, including the permissions to perform certain
actions and the IT platforms that each stakeholder uses in the project. There are four types of users:
Project Manager, Superintendent, Foreman and Subcontractor/Worker. We noticed that the foreman
and the subcontractor had the same requirements, so we were able to group them in a single user type
for this research. Depending on their type, each user is authorized to perform certain operations in the
Work Tracking System. We also optimized the UI/UX depending on the type of IT platform that they
used the most.
T ABLE 2: STAKEHOLDER HOLDER USE CASES AND PLATFORMS
Update tasks
Stakeholder
IT
Platform(s)
Task
dashboard
Create View
tasks tasks
Project manager
Desktop /
Tablet
x
Superintendent
Desktop /
Tablet
X
X
X
Foreman/
Tablet/
Phone
X
X
X
Subcontractor
Worker
Phone
Task
info
Actual
Assign
Start/
Task Complete
X
X
X
X
X
X
Figure 8 shows the information flows to and from the Work Tracking System based on the use cases
described in Table 2.
Project Manager
Superintendent
Task status summary,
Task dashboard
Task status summary,
Task dashboard
Create/Update Tasks: Task
Name, Planned Start,
Planned Finish, Element,
Assignee
Assign task: Task Name, Planned
Start, Planned Finish, Element.
Cloud based WTS
Create/Update Tasks:
Element, Assignee
Update Task Status: Report
Actual Start and
Task Complete
Task status
summary,
Task dashboard
Worker
Foreman/
Subcontractor
F IGURE 8: T YPES OF USERS , INFORMATION FLOWS AND IT P LATFORMS
Based on the types of users, information flows and IT Platforms preferred by each user, we developed a
class diagram (Figure 9) to represent the system we needed to build.
In this diagram, we can see three main classes: User, Task and BimNamespace. In the next section we
will discuss each of these classes in detail.
Task Class
The Task Class has the following attributes: Name, Planned Start, Planned Finish, Actual Start and Actual
Finish. The Task Class is connected to the User Class via the assignedTask attribute, which assigns one
user from the User Class to the task instance. Similarly, the Task Class is connected to the
BIMNamespace Class via the assignedElement attribute, which assigns a particular element of the BIM,
or elements, depending on how you define the BIM namespace (see Section Importing the BIM
Namespace), to a particular task instance. The Task Class also has the following Operations: getStatus(),
updateTask(), and completeTask(). The getStatus() operation reports about the status of the task: Future
Activity, Not Started, Started On Time, Delayed, Critical Delay, Finished On Time, Finished Late (See
Table 3 for more details about how the status is calculated). The updateTask() operation edits the task
instance attributes. Finally, the completeTask() operation assigns the current time to the ActualFinish
attribute of the task and reports it as completed.
User Class
The User Class has four attributes that are shared by the User Subclasses: Name, Email, Organization
and Asana_ID. The Name and Email allow us to identify individual users. The Organization attribute links
the user with a particular crew or company. Finally, the Asana_ID allows our Work Tracking System
prototype to communicate with the Asana API and assign specific tasks to specific users. See Section
Prototype Implementation for an explanation of why we link to Asana.
The User Class contains four subclasses: Project Manager, Superintendent, Foreman and Subcontractor.
Each of these types of users can perform certain operations; this allows us to control permissions in the
application. The following are the operations that can be performed: taskDashboard(), createTask(),
updateTask() and assignTask(). By calling the operation taskDashboard() the program is prompted to
update the status of all the tasks and to present the Dashboard Interface (See Section WTS Dasboard for
details). The operations createTask(), assignTask() and updateTask() allow the user to manipulate the
attributes of an instance of the Task Class.
BIMNamespace
The BIMNamespace Class has one attribute and two operations. The attribute elementID refers to a list
containing all the BIM elements that were exported from Revit by the user (See section Importing the
BIM Namespace). This list can be updated by calling the operation updateTask().
Task
-assignedTask
0..*
0..1
-Name
-PlannedStart
-PlannedFinish
-ActualStart
-ActualFinish
+getStatus()
+updateTask()
+completeTask()
-assignedTask
BIMNamespace
0..*
-elementID
-assignedElement
+updateNamespace()
+importNamespace()
User
0..1
-assignedUser
-Name
-Email
-Organization
-Asana_ID
ProjectManager
Superintendent
Foreman
+taskDashboard()
+createTask()
+assignTask()
+taskDashboard()
+updateTask()
+createTask()
+assignTask()
+taskDashboard()
+updateTask()
Worker
+updateTask()
F IGURE 9: C LASS D IAGRAM OF WORK T RACKING SYSTEM
Prototype Implementation
Figure 10 shows a high level system implementation. We used Revit to manipulate the BIM and
Navisworks for the 4D visualization. Finally, we used Asana to manage work assignments to individual
workers using a mobile app.
Work Tracking System Work Flow
Revit
Phase
Add ElementID
Shared Parameter to
elements
Export
ElementID
schedule in
CSV format
BIMNamespace
Navisworks
Asana
WTS
Import
BIMNamespace
from Revit
Add
organizational/
permission
attributes to
Users
Import Users
from Asana
Create Tasks
Assign Tasks
User List
Export CVS
task report
for
Navisworks
Update user
tasks in
Asana
Create Users
Import Revit
File
Update Tasks
Import CSV
task report
Report as
complete
Run 4D
Animation
F IGURE 10: WORK TRACKING SYSTEM WORKFLOW I NTEGRATION WITH REVIT, N AVISWORKS AND A SANA
In the following section, we will justify the use of each of these external tools and how we linked them
to the WTS.
Revit and Navisworks: Autodesk Revit and Autodesk Navisworks are some of the most widely used BIM
software at the moment. We were looking for BIM software that allowed the user to easily generate a
namespace to assign elements and groups to tasks. Revit allows the user to do this by creating a shared
parameter that can be assigned to elements. Once the Revit model is exported to Navisworks, it
preserves this parameter, which allows us to generate a data file containing the tasks, including the
shared parameter. In this way, Navisworks can identify the elements that are associated to tasks and
visualize it via the 4D model.
Asana: Asana is a web application that allows teams to share a common task list. Team members can
create tasks, assign them to users and set due dates. Users can also comment on tasks, giving them the
opportunity to ask questions to other users, add notes and attach files. Looking at the different types of
users that are going to use our WTS, we noticed that the worker needs a system where they can be
notified: of task assignment, the task's content and due date. Furthermore, workers need an application
that is optimized for mobile, both tablets and phones. As Asana provides all the required functionalities
in a user friendly interface that is mobile ready, we decided to connect our WTS to Asana, via the Asana
API. Once a task is created in the WTS and assigned to a specific user, it is automatically added to that
person’s Asana. Similarly, once the person marks the task as done in Asana, the change is reflected in
the WTS's dashboard. Figure 11 shows a screenshot of the Asana desktop user interface with a list of all
tasks in the project, which user they are assigned to and the due date. The panel to the right shows
additional information about the task, and allows users to add comments, ask questions to other users
and add attachments.
F IGURE 11: SCREENSHOT OF THE A SANA DESKTOP USER INTERFACE
Using Revit to export BIM Namespace
One of the most important steps is preparing the BIM so that it can be used to track tasks. To achieve
this, project teams must first decide on a namespace which they will use through the project. This
namespace determines how the BIM elements are logically grouped together to perform the tasks. This
is directly correlated to the level of detail used to control the tasks. For example, if a team is interested
in controlling the project at a low level of detail, they might want to track tasks such as "Pour Columns
Level 3". In this case, they would group all their level 3 columns and assign a unique ElementID to them.
However, if they want to control the project by tracking tasks at a higher level of detail, they might want
to track tasks such as "Pour Column A-1 Level 3". In this case, they will select the individual column A-1
and assign it a unique ElementID.
Selecting the correct level of detail depends on several factors; project complexity, type of company,
type of project delivery system and type of contract. Ideally, managers should be able to choose a
control of projects at varying levels of detail through their lifetime. Nowadays, projects are planned at a
very low level of detail, generally at the activity level of detail. Once the project begins, weekly planning
meetings are held, where teams decide what tasks they will perform. This is done at a higher level of
detail relative to the initial plan. The tools available today don’t allow superintendents to quickly, and
easily update the schedule to reflect these weekly planning meetings. Hence, it is very difficult for them
to know if a project is running as planned, or if changes need to be made to keep the project on course.
The current version of the WTS has this same limitation. Project teams cannot easily change the
namespace without updating the connection to all the tasks. This is a limitation that project teams need
to consider upfront and factor it into their namespace selection.
For this project, we created a Shared Parameter called ElementID, which is used to assign unique IDs to
specific elements or groups of elements. These elements are related to tasks in the WTS. Each
ElementID has to follow a naming convention to make it easy to search for the element in the WTS:
Where: Level refers to the vertical location of the element, Element Type refers to the BIM family (C:
Column, B: Beam, J: Joist, Slab: Slab, SW: Shear wall), and the UniqueID identifies the specific element
Naming Convention : Level – Element Type – UniqueID
Example:
L0
-
C
-
F3
being targeted. Figure 12 shows an example of the naming convention being used in a project. The
selected column the label L1-C-A1 set as its Element_ID property. This denotes that the element is
located in the Level 1 (L1), its type is a Column (C), and its unique ID is "A1", which is the intersection of
the gridlines.
F IGURE 12: EXAMPLE ASSIGNING AN ELEMENT_ID TO A SPECIFIC ELEMENT IN A BIM. THIS ELEMENT IS
TARGETING A LEVEL ONE (L1) COLUMN (C) IDENTIFIED AS A1.
Once we have created the namespace, we can create a Revit Schedule that contains all the unduplicated
elements that have an Element_ID assigned to them. This report can be exported as a text file that can
be read by our WTS. Figure 13 shows a snapshot of the Revit Namespace schedule.
F IGURE 13: SNAPSHOT OF THE NAMESPACE FOR THE BIM SHOWN IN F IGURE 12.
Overview of the WTS Web application
The WTS was built as a web application to allow teams to access real time information in a decentralized
manner. The web application was built using the Google App Engine Framework. This framework allows
the developers to easily deploy their projects using Google’s servers, provides powerful computing
power as well as automatic scaling for their applications. The back end of the application was written in
Python and Jinja was used as the template engine.
A beta version of the WTS can be accessed in: http://worktrackingsystem.appspot.com
Importing the BIM Namespace
The BIM Namespace created in Revit can be easily imported into the WTS by clicking on the Namespace
button in the top menu and choosing the file to upload. Internally, the WTS imports all the elements in
the Namespace into the Namespace Table. Figure 14 shows a screenshot of the webpage where this
task can be accomplished.
F IGURE 14: SCREENSHOT OF THE N AMESPACE PAGE IN THE WTS WEB APPLICATION
Adding Users to the WTS
Users can be added to the WTS through the Asana API. This means that Users are first created in Asana
by the project administrator, and then they can be imported into the WTS. This decision was made so
that all the users that are available in the WTS have an AsanaID that allows us to assign tasks to them.
Users are easily added by providing a name and an email.
F IGURE 15: SCREENSHOT OF THE A SANA MODULE FOR ADDING USERS TO THE WTS
In the WTS page, the user list can be updated by clicking on the menu item Users. This automatically
imports the data from Asana and updates the User Table.
WTS Dasboard
The WTS dashboard is the main view for project control. We divided the dashboard into two parts: the
Task Status Summary and the Task Dashboard. Figure 16 shows a snapshot of this webpage.
F IGURE 16: SNAPSHOT OF THE WORK T RACKING SYSTEM D ASHBOARD
The Task Status summary shows a quick snapshot of the work in progress (WIP), tasks not started, and
finished tasks. The WIP is broken down into the number of tasks that either started on time, late or are
delayed. The Finished tasks are broken down into tasks that were finished on time and finished late. This
information helps managers understand whether their project is under control or not, by comparing the
number of tasks that are delayed, have not started or were finished late.
The Task Dashboard shows a list of all the tasks associated with the project. Each task includes the
following information: Status, Task Name, Element, Assignee, Planned Start, Due Date, Actual Start and
Finish Date. There is also an option to add notes and edit the task. The task status is recalculated every
time the page is loaded. The rows are formatted according to the task status, which allows managers to
quickly realize which tasks require special attention. Table 3 summarizes all the task status considered,
how they are calculated and the row format used to denote them. Similarly, when the user hovers over
the status icon, the Task Status will appear as a tooltip to help them remember what the icon means.
T ABLE 3: T ASK STATUS SUMMARY , CALCULATION AND L AYOUT
Status
Description
Calculation
Status Icon/row format
Future Activity
Activity shouldn’t have
started yet.
Current time < Planned
Start
None
Started On Time
Activity started on time,
and the due date has
not passed yet.
Actual Start ≤ Planned
Start AND Current time
< Due Date
Late Start
Activity started late but
the due date has not
passed yet.
Actual Start > Planned
Start AND Current time
< Due Date
Activity has not started,
but the due date has
not passed yet.
Current time > Actual
Start AND Actual Start =
NULL AND Current time
< Due Date
Delayed
Activity has started but
is running late
Current time > Due Date
AND Actual Start ≠ NULL
Critical Delay
Activity has not started
and the due date has
passed.
Current time > Due Date
AND Actual Start = NULL
Finished On Time
Activity was finished on
time
Actual Finish ≤ Due Date
Finished Late
Activity was finished
passed its due date
Actual Finish > Due Date
Has not Started
Although workers can report a task as completed using the Asana API, project managers,
superintendents and foremen can also report tasks as completed from the project dashboard. By
clicking on the Mark as Complete checkbox, the task status is updated and the current time is set as the
Actual Finish (Figure 17).
F IGURE 17: T ASKS CAN BE REPORTED AS COMPLETED DIRECTLY FROM THE T ASK DASHBOARD
Creating, editing and completing a task in the WTS
New tasks can be created by clicking on the New Task button. This action opens a form which can be
filled with all the information for the task (Figure 18). The required inputs are: Task Name, Element ID,
that is prepopulated with the BIMNamespace imported from Revit, Task Notes, Task Assignee, that is
prepopulated with all the users registered in the project, Planned Start, Task Due and Task followers,
that is an optional field which can be used to alert specific users about the status of the task. The input
field "Actual Start" should be filled in once the task is started.
F IGURE 18: SNAPSHOT SHOWING THE INPUT FORM FOR CREATING A NEW TASK
Specific tasks can also be edited. To do so, click on the Edit/View link in the Task Dashboard. This action
opens a similar window to the one used to create a new task (Figure 19). In this case, most of the inputs
are prepopulated but can be edited. This is the preferred view for adding the Actual Start date.
F IGURE 19: SNAPSHOT SHOWING THE INPUT FORM FOR EDITING A TASK
Generating 4D visualization of the work performed
One of the cornerstones of this research was to develop a platform where teams could visualize the
work performed and “replay” it to understand what had happened and what could be improved. The
WTS provides a simple interface to allow this to happen. When the user clicks on the “Export to
Navisworks” button in the top menu, a csv file is downloaded to their local computer containing all the
information needed by the Navisworks timeliner to create a 4D simulation.
The following are the steps needed to configure the Naviswork's nwf file for visualization.
1.
2.
3.
4.
“Append” the Revit file. This will import the BIM into Navisworks.
Select “Timeliner”, it is located in Tools section of the Home Ribbon.
Select the Data Sources tab located in the Timeliner Window.
Click on Add, and select CSV import. Search for the file that was downloaded by the WTS and
click Open.
5. In the Selector, make sure to match the following Columns to these External Field Names:
a. Task Name: Column A
b. Display ID: Column A
c. Synchronization ID: Column A
d. Planned Start Date: Column B
e. Planned End Date: Column C
f. Actual Start Date: Column D
g. Actual Finish Date: Column E
h. User 1: Column F
6. Click on Refresh and select All Data Sources.
7. Select Rebuild Task Hierarchy and click Ok.
8. Select the Tasks tab in the Timeliner Window. You should see the list of tasks you imported.
9. Click on the “Auto-Attach Using Rules button.
10. Select the first option: Map TimeLiner Tasks from Column Name to Items with the same name,
Matching Case. Then click Edit.
11. Select “Attach Items to Tasks by Category/Property” in the rule description, set the Column to
be User 1, the Category to be Name ‘Element’ and the Property to be Name ‘Element_ID’. Click
Ok.
12. Click on Apply Rules.
13. Assign a Task Type to each task.
14. Click on the “Simulate Tab” and click play. You can also configure different settings in the
Timeliner, for example, to view the difference between the planned and the actual start and end
dates.
Preliminary Results
The current version of the prototype was designed and built while receiving constant feedback from the
project manager, superintendent, foreman and workers in a mid-rise residential building. This allowed
us to engage them on a daily basis to understand their current work processes and inquire how a system
like the one we were building would help them to be more productive.
Table 4 summarizes the advantages and limitations that were observed by different stakeholders that
were interviewed:
T ABLE 4: SUMMARY OF ADVANTAGES AND LIMITATIONS DESCRIBED BY THE DIFFERENT STAKEHOLDERS
Stakeholder
Project Manager
Advantages



The Task Status Summary helps
me to understand the overall
status of the project.
Choosing the namespace for the
project was an interesting
exercise. It would help as a
planning exercise at the
beginning of the project.
Visualizing the work in the BIM
was very interesting, since you
could see where the time
slippage had happened.
Limitations






ASuperintendent



The WTS provides an intuitive
interface to log in weekly
commitments and track them.
Color coding is useful to
understand which tasks are
falling behind and require
attention.
The 4D visualization showing the
difference between planned and
actuals allows me to “replay”
the work being carried out and
understand what could be done
better.



Would like to filter by
subcontractor and see their
individual performance.
Integration with progress
payments would be beneficial.
Summary report for task status
using the WBS or PBS to
calculate earned value.
The integration between the
BIM, WTS and Navisworks could
be smoother.
Linking the production schedule
with the procurement schedule
would improve communication.
Not all of our
subcontractors/workers have
data plans on their phones.
Would need to consider a costbenefit analysis.
Automatic synchronization with
Microsoft Project would be very
useful to notice changes in
downstream tasks.
Aggregation of tasks by WBS
hierarchy would help
understand what percentage of
the project is complete and
whether we will hit a milestone
or not.
Choosing the namespace was
not intuitive. Element grouping
depends on the task, and is
Foreman

If the 4D visualization could be
done real time I would not have
to be running up and down the
building all day.

Linking the task to the element
helped me understand where
the work was being performed
and loose less time searching for
the worker to give him
instructions.
Icons allow me to prioritize my
attention in the tasks that need
help or clarification, and not
waste time checking up tasks
that are doing well.

Good to have clarity on what
tasks are assigned to me.
The comment section is useful
to inform of problems.


Worker


constantly evolving as the
project progresses (different
grouping for pouring columns
than placing their rebar).


Filtering by “area” would be
good so I can check all the tasks
in my proximity and not walk
around the project.
Showing the status by
subcontractor or worker would
be useful to know who to
motivate.
Would need to motivate
workers to want to report task
completion.
Would like to be able to access
the drawings from my phone.
Overall, the feedback we received was extremely positive. Most of the comments highlighted how task
visualization was a tool that helped them identify where to focus their effort. It was interesting to see
how the project manager’s comments focused on the usefulness of summary reports that helped him to
see the project at a strategic level, whereas the foreman and worker focused on the tactical advantages
of checking progress on individual tasks.
On the other hand, although all the stakeholders saw value in integrating task with BIM elements for
visualization, they commented that this process was cumbersome and faulty. For example, the
superintendent’s observation that choosing a unique namespace for the whole project is a major
limitation in the current software solutions, and is an area that could be improved if BIM is going to
support production.
Another issue that was mentioned by the project manager and the superintendent was the ability to
create a live link between the WTS and the scheduling system, which in this case was Microsoft Project.
Currently, the WTS can only manage work at one level of detail, which does not support disaggregation
and aggregation of data into levels that are suitable for computing work progress and earned value.
Generating this link automatically would require a shift in current scheduling practice. Nowadays,
project teams generate the master schedule at a low level of detail. Production schedules are decided
during a planning meeting held either weekly or biweekly. However, these two schedules are generally
disconnected because the master schedule is outdated and the production plan is generally not done in
the same system as the master schedule. This is an interesting area of opportunity to understand how to
bridge the gap between how project teams create schedules and how they want to use them.
Finally, although mobile phones and tablets are becoming more ubiquitous in construction sites, it is still
uncommon for every worker in the construction site to have access to a mobile solution with data
available. Taking into account trends in mobile adoption, this technological burden will become less
important over time.
Conclusions and Future Work
In this research, we developed a novel system for managing onsite production by leveraging VDC, the
pervasiveness of mobile technology and advances in cloud computing. This Work Tracking System (WTS)
allows stakeholders to publish and obtain the needed information with minimum latency, by managing
the available information in the project platforms and maintaining it updated and synchronized. A
prototype of the WTS system was developed and feedback was gathered about the advantages and
limitations of implementing this prototype on a construction site. Most of the positive comments were
about the ability of visualizing the work being performed, enhanced communication for setting work
priorities and make decisions faster. Some of the major limitations highlighted the need to set better
filters and manage information at various levels of detail.
This research uncovered some major gaps that need to be addressed for the ideal envisioned system to
work. Current scheduling practices do not support data collection in a way that is meaningful for
management. Master schedules and production schedules are disconnected, sometimes even using
different systems. Since task progress is being measured using the production schedule,
superintendents need to reconcile the production schedule with the master schedule to get a
meaningful idea of the overall work progress. Most of the time, this process is cumbersome and
superintendents rely on their intuition to judge work progress, which means that although the progress
data is being collected, it is not converted into useful actionable information that can help managers
make better decisions. Therefore, it is necessary to develop tools and methods that support better
scheduling practices to facilitate data acquisition and processing. This will lead to better reports, which
will support management in their daily operations.
Finally, we would like to reach out to a broader construction community to test our Work Tracking
System and send us feedback about it. The web application is available in:
worktrackingsystem.appspot.com.
References:
Alberts, D. S., and Hayes, R. E. (2005). Power to the Edge. CCRP Publication Series.
Autodesk Inc. (2013). “BIM 360 Field.” <http://bim360field.com/> (Nov. 11, 2013).
Ballard, G., and Howell, G. (2003). “Lean project management.” Building Research & Information, 31(2),
119–133.
Chen, Y., and Kamara, J. M. (2011). “A framework for using mobile computing for information
management on construction sites.” Automation in Construction, 20(7), 776–788.
Construction Centrics LLC. (2013). “Construction Centrics.” <http://www.constructioncentrics.com/>
(Nov. 11, 2013).
Deibert, S., Hemmer, E., and Heinzl, A. (2009). “Mobile Technology in the Construction Industry-the
Impact on Business Processes in Job Production.” Proceedings of the Fifteenth Americas Conference
on Information Systems, San Francisco, California August 6-9.
Fischer, M., and Kunz, J. (2004). “The scope and role of information technology in construction.”
Proceedings-Japan Society of Civil Engineers.
Garcia, A., Kunz, J., Ekstrom, M., and Kiviniemi, A. (2004). “Building a project ontology with extreme
collaboration and virtual design and construction.” Advanced Engineering Informatics, Stanford
University, 18(2), 71–83.
Ghanem, A., and AbdelRazig, Y. (2006). “A Framework for Real-Time Construction Project Progress
Tracking.” Earth & Space.
Godet, M. (2000). “The art of scenarios and strategic planning: tools and pitfalls.” Technological
forecasting and social change, 65(1), 3–22.
“Goggle App Engine.” (2013). <https://developers.google.com/appengine/> (Nov. 19, 2013).
Greif, M. (1991). The visual factory: building participation through shared information. Productivity
Press, Portland.
Ho, P., Fischer, M., and Kam, C. (2009). “Prospective Validation of Virtual Design and Construction
Methods: Framework, Application, and Implementation Guidelines.” CIFE Technical Report, (WP
123).
Imai, M. (1986). Kaizen: The Key To Japan’s Competitive Success. McGraw-Hill/Irwin, 260.
Jones, S. A., and Bernstein, H. M. (2012). SmartMarket Report The Business Value of BIM in North
America SmartMarket Report.
Kam, C., and Fischer, M. (2004). “Capitalizing on early project decision-making opportunities to improve
facility design, construction, and life-cycle performance—POP, PM4D, and decision dashboard
approaches.” Automation in Construction, 13(1), 53–65.
Kunz, J., and Fischer, M. (2009). “Virtual design and construction: themes, case studies and
implementation suggestions.” CIFE, Stanford University, Stanford, CA, CIFE Working Paper.
Levitt, R. E. (2011). “Towards project management 2.0.” Engineering Project Organization Journal, 1(3),
197–210.
Lipman, R. R. (2004). “Mobile 3D visualization for steel structures.” Automation in Construction, 13(1),
119–125.
McCullouch, B. G., and Lueprasert, K. (1994). “2D Bar‐Code Applications in Construction.” Journal of
Construction Engineering and Management, American Society of Civil Engineers, 120(4), 739–752.
Mourgues, C., Fischer, M., and Kunz, J. (2012). “Method to produce field instructions from product and
process models for cast-in-place concrete operations.” Automation in Construction, Elsevier B.V.,
22, 233–246.
Mourgues, C., Kunz, J., and Fischer, M. (2008). “Implementing A Method To Produce Field Instructions
From Product And Process Models (FIPAPM) - Case Study And Guideline.” CIFE Technical Report,
(WP111).
Mulloni, A., Nadalutti, D., and Chittaro, L. (2007). “Interactive walkthrough of large 3D models of
buildings on mobile devices.” Proceedings of the twelfth international conference on 3D web
technology - Web3D ’07, ACM Press, New York, New York, USA, 17.
Ochoa, S. F., Bravo, G., Pino, J. A., and Rodríguez-Covili, J. (2010). “Coordinating Loosely-Coupled Work in
Construction Inspection Activities.” Group Decision and Negotiation, 20(1), 39–56.
Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press, Portland.
Plan Grid. (2013). “PlanGrid.” <http://plangrid.com/> (Nov. 11, 2013).
R.Navon, and O.Berkovich. (2012). “Development and On-Site Evaluation of an Automated Materials
Management and Control Model.” American Society of Civil Engineers.
Ramsey, M. S., and Levitt, R. E. (2005). “A Computational Framework for Experimentation with Edge
Organizations.” 10th International Command and Control Research Technology Symposium.
Saidi, K. S., Haas, C. T., and Balli, N. A. (2002). “The Value of Handheld Computers in Construction.”
Proceedings of the 19th International Symposium on Automation and Robotics in Construction,
IAARC, Washington, DC, USA, 1–6.
Skibniewski, M. shtslsa. J., and Wooldridge, S. C. (1992). “Robotic materials handling for automated
building construction technology.” Automation in Construction, 1(3), 251–266.
Tserng, H. P., Dzeng, R.-J., Lin, Y.-C., and Lin, S.-T. (2005). “Mobile Construction Supply Chain
Management Using PDA and Bar Codes.” Computer-Aided Civil and Infrastructure Engineering,
20(4), 242–264.
UDA Construction Online TM. (2013). “ConstructionSuite.”
<http://www.constructiononline.com/co_overview.html> (Nov. 11, 2013).
Wang, L.-C. (2008). “Enhancing construction quality inspection and management using RFID
technology.” Automation in Construction, 17(4), 467–479.
Wang, L.-C., Lin, Y.-C., and Lin, P. H. (2007). “Dynamic mobile RFID-based supply chain control and
management system in construction.” Advanced Engineering Informatics, 21(4), 377–390.
Wang, X., Dunston, P., and Jaselskis, E. (2006). “Framework for Implementing Mobile Computing
Infrastructure for Construction Operations.” Joint International Conference on Computing and
Decision Making in Civil and Building Engineering., Montréal, Canada.
Yeh, K., Tsai, M., and Kang, S. (2012). “On-site building information retrieval by using projection-based
Augmented Reality.” Journal of Computing in Civil ….