A Formal Process to Create Resource-Loaded & Cost-Loaded ...

CIFE

CENTER FOR INTEGRATED FACILITY ENGINEERING

A Formal Process to Create Resource-Loaded & Cost-Loaded Activities Related to Feature-Based Product Models By

Sheryl Staub-French, Martin Fischer, John Kunz, Boyd Paulson, and Kos Ishii

CIFE Working Paper #71 July 2002

STANFORD UNIVERSITY

1

Copyright © 2002 by Center for Integrated Facility Engineering

If you would like to contact the authors, please write to:

c/o CIFE, Civil and Environmental Engineering Dept., Stanford University Terman Engineering Center Mail Code: 4020 Stanford, CA 94305-4020

2

WORKING PAPER #71 A FORMAL PROCESS TO CREATE RESOURCE-LOADED AND COST-LOADED ACTIVITIES RELATED TO FEATURE-BASED PRODUCT MODELS Sheryl Staub-French1, Martin Fischer2, John Kunz3, Boyd Paulson4, Kos Ishii5

Abstract Understanding how the building design influences construction costs is a challenging task for estimators. Estimators must recognize the design conditions that affect construction costs and customize the cost estimate accordingly. Estimators have different preferences for how and when to adjust a project’s activities, resources, and resource productivity rates that form the basis of a cost estimate. Current tools and methodologies lack ways to help estimators customize construction cost information according to their preferences and maintain cost estimates as the design changes based on those preferences. This paper describes the formal process we developed to customize a project’s activities, resources, and resource productivity rates based on a project-independent representation of estimators’ rationale and a project-specific feature-based product model. The formal process creates a set of project-specific activities that know why they are needed in the cost estimate, what feature requires their execution, what resources are executing the activity and why, and what their labor and material costs are. The formal process leverages the explicit relationships between features, activities, resources, resource productivity rates, and the estimator’s rationale to identify the cost information affected by design changes. Our tests show that the formal process enables a software prototype to generate and maintain cost estimates quickly and consistently for feature-based product models.

1

Assistant Professor, Department of Civil Engineering, University of British Columbia, Vancouver, BC, Canada, V6T 1Z4, [email protected] 2 Associate Professor, Department of Civil and Environmental Engineering and (by Courtesy) Computer Science, Director, Center for Integrated Facility Engineering, Stanford University, Stanford, CA 94305, [email protected] 3 Executive Director, Center for Integrated Facility Engineering, Stanford University, Stanford, CA 94305, [email protected] 4 Professor, Department of Civil and Environmental Engineering, Stanford University, Stanford, CA 94305, [email protected] 5 Associate Professor, Department of Mechanical Engineering, Stanford University, Stanford, CA 94305, [email protected]

1

1. Introduction and Overview Construction cost estimators are confronted with the challenging task of having to estimate the cost of constructing one-of-a-kind facilities. Estimators must recognize the design conditions of the facility design that are important (i.e., incur a cost) and how they affect construction costs.

Estimators have different preferences for what design

conditions they want to consider and how the cost estimate should be adjusted to account for them. Today, estimators account for the cost impact of many design conditions by manually adjusting the project’s activities, resources, and resource productivity rates that form the basis of a cost estimate for a specific design. Then, if the design changes, estimators have to manually identify the cost information affected and adjust the activities and resources accordingly so that the project’s design and cost estimate remain in balance. Estimators make these project-specific adjustments manually because current tools and methodologies are unable to customize the project’s activities and resources and create an integrated model that explicitly relates the design conditions, activities, and resources with the estimator’s preferences. Without automated support to customize construction cost information for a given design based on a specific estimator’s preferences, cost estimators often employ ad hoc methods that are prone to error and result in inconsistencies and inefficiencies in the cost estimating process. Prior research efforts demonstrate that cost estimates can be generated directly from 3D models (Laitinen 1998; Aouad et al. 1994; Froese et al. 1996; Aouad et al. 1997; Clayton et al. 1996).

They identify the typical activities, resources, and resource

productivity rates to calculate construction costs for a specific component in a product model and explicitly relate the components, activities, resources, and costs.

These

research efforts do not customize construction cost information for specific design conditions in a given product model and they do not account for different estimator preferences. Moreover, they do not represent why components, activities, resources, and costs are related and when the relationships are needed. Other research efforts recognize design conditions that affect construction costs and customize the activity’s resources and resource productivity rates accordingly (Fischer 1991; Hanna et al. 1992; Udaipurwala and Russell 2000; Froese and Rankin 1998; Thomas and Zavrski 2000; Thomas and Sackrakan 1994; de Sousa and Thomas 1996; Smith and Hanna 1993; Sanders and 2

Thomas 1991).

However, these research efforts do not represent and account for

different estimator preferences when customizing the project’s resources and resource productivity rates to the design conditions on a particular project.

Moreover, the

resources do not know why they were assigned to an activity, and the resource productivity rates do not know why they were assigned to a resource and how they were adjusted for specific design conditions. Hence, estimators need a formal process for customizing the activities and resources based on their preferences to create an integrated activity-based cost model that knows when it is needed and how it should be adjusted if the design changes based on a specific estimator’s preferences. This paper presents the process we formalized that helps estimators leverage their cost estimating knowledge to customize construction costs for a given design and create an integrated model consisting of features (), activities (), resources (), resource productivity rates (), and costs () ( model) that is related to the estimator’s rationale. We use the concept of features to describe the part of the design that estimators care about and design conditions to describe when features are important to estimators. We refer to the customization of construction costs as the adjustment of a project’s activities, resources, and resource productivity rates to reflect the cost impact of the specific features and design conditions in a given product model. Figure 1 shows the mechanisms implemented by the formal process and the resulting integrated model and compares it with the current cost estimating process and resulting cost estimate. The specific example will be explained in the next section. Estimators using state-of-the-art tools customize the cost items to construct a specific component according to their preferences for adding cost items based on the component’s properties (Timberline 2001). The cost items know what component they relate to in the product model but they do not know the estimator’s rationale for how the component properties affect specific cost information or how features of the component affect the component’s cost (Figure 1a). The formal process leverages the project-independent representation of estimators’ rationale to create project-specific resource-loaded and cost-loaded activities related to the project-specific feature-based product model (Figure 1b). The main contributions of the paper are the formalization of the feature-driven activity and resource customization process and the specification of the resulting integrated model.

3

Estimator’s Rationale

Cost Estimate Activity Description

Prod. Rate

QTY uom

Res. Costs

Total Cost

Crew C-1 and Rolling Scaffolding

Generic Cost Items & Assemblies Architect’s Feature-based Product Model

Install Metal Stud

1805

LF

6.6 lf/hr $4,273

$4,724

Hang Drywall

4800

SF

65 sf/hr $6,646

$7,654

Apply Tape

4800

SF

45 sf/hr $8,533

$9,013

Install Insulation

2400

SF

100 sf/hr $1,800

$2,880

Layout Wall

240

LF

20

$1,080

2

EA

75 sf/hr

Frame Wall-Beam Intersection 2

EA

1

Apply Fire Caulking

LF

40

Frame Openings

Generate Construction Costs

12

lf/hr $1,080 $150

$159

hr/ea

$90

$93

lf/hr

$14

$56

Architect’s Feature-based Product Model

Feature = Wall

Customize Cost Items! Calculate Costs!

Feature = Wall

Figure 1a: Estimators using state-of-the-art software tools automatically customize the cost items in a cost estimate by adding cost items for different component properties. Then, estimators manually customize the cost items by adding cost items to account for features of components and adjusting specific cost information in the cost item to account for different design conditions. The project-specific cost items know what component they relate to in the product model. However, they do not know the estimator’s rationale for how the component properties affect specific cost information, and they do not account for how features of the component affect costs. Estimator’s Rationale Generic Activities & Resources

Estimator’s Feature-based Product Model Feature = Similarity of Components Feature = WallBeam Intersection

Estimator’s Rationale

Generate and Maintain Construction Costs Feature = Turn

Feature = Wall

Resource-Loaded and Cost-loaded Activities and Related Feature-based Product Model Objects Actions Resources

Estimator’s Rationale

Activities

Features

Costs

Feature = Openings

Customize Activities! Customize Resources! Customize Resource Productivity Rates! Calculate Costs! Reconcile Costs (if design changes)!

Activity Description

QTY uom

Prod. Rate

Res. Costs

Total Cost

Crew C-1 and Rolling Scaffolding Install Metal Stud Hang Drywall

1805

LF

4800

SF

65 sf/hr $6,646

Apply Tape

4800 2400

SF SF

45 sf/hr $8,533 100 sf/hr $1,800

$9,013

240

LF

20

2 Frame Wall-Beam Intersection 2 Apply Fire Caulking 12

EA

75 sf/hr

$150

$1,080 $159

EA LF

1 hr/ea 40 lf/hr

$90 $14

Install Insulation Layout Wall Frame Openings

Estimator’s Featurebased Product Model

6.6 lf/hr $4,273

lf/hr $1,080

$4,724 $7,654 $2,880

$93 $56

Cost Estimate

Figure 1b: The process we formalized leverages the project-independent representation of estimator’s rationale to customize activities, resources, and resource productivity rates for a project-specific feature-based product model. The formal process creates resource-loaded and cost-loaded activities related to the feature-based product model and the estimator’s rationale. The process leverages these explicit relationships to identify the cost information affected by design changes. Control Legend: Input

Process

Output

Mechanisms

IDEF0 Nomenclature (IDEF0 1981)

Estimating Database

Template for Manually customized cost capturing estimator’s items, resources and rationale resource productivity rates

Cost Item related to component using current tools

Figure 1: Comparison of the current cost estimating process and resulting cost estimate with the formal feature-driven activity and resource customization process and resulting integrated model.

4

1.1 Motivating Case: Current Practice This section describes a use case to illustrate the requirements for automated support of the cost estimating process. The case study is based on a drywall estimator’s process for estimating the labor costs for one of the rooms in an office project shown in Figure 2. The building components in the room are annotated in Figure 2. Column (Existing)

Wall (“Wall1”)

Beam (Existing)

Door and Window

Figure 2: Building components in the office project case study. The drywall estimator is estimating the costs for constructing the four walls shown. Drywall estimators must identify the design conditions that affect the cost of constructing the walls and adjust the cost estimate accordingly. Estimators have different preferences for adjusting the activities, resources, and resource productivity rates to account for the cost impact of different design conditions. Figure 3 shows how the estimator customizes the activities, resources, and resource productivity rates to account for the specific design conditions in the motivating case and explains the estimator’s rationale for making the adjustments.

5

1

Typical Cost Assemblies

IFC-based Product Model

Estimator’s Rationale about Activities and Resources

2

Wall.HasOpenings

4

Cost Estimate

Customize Activities and Resources Wall

3

Cost Estimate

Customize Activities, Resources and Productivity Rates!

Estimator’s Rationale about Activities and Resources

Activity Description

QTY uom

Prod. Rate

Res. Costs

Total Cost

Crew C-1 and Rolling Scaffolding

Customize Activities and Resources

Install Metal Stud

1805

LF

6.6 lf/hr $4,273

$4,724

Hang Drywall

4800

SF

65 sf/hr $6,646

$7,654

Apply Tape

4800

SF

45 sf/hr $8,533

Install Insulation

2400

SF

100 sf/hr $1,800

$2,880

Layout Wall

240

LF

20

$1,080

Frame Openings 2 Frame Wall-Beam Intersection 2 Apply Fire Caulking 12

EA

75 sf/hr

lf/hr $1,080

$9,013

$150

$159

EA

1

hr/ea

$90

$93

LF

40

lf/hr

$14

$56

IFC-based Product Model Customize Activities, Resources and Productivity Rates!

Wall

1

2 Wall-Beam Intersection Estimator adds activities to install subcomponents of the wall, to frame the openings, and to lay out the wall.

Wall Decomposition

Openings

3

Estimator adds activity “Frame Wall-beam Intersection” to account for the unusual framing condition and adds activity “Apply Caulk" because the intersected wall is fire-rated.

4

Wall Height

Component Similarity

Estimator uses Rolling Scaffolding because the wall height is between 9' - 13', and use a Scissor-lift if the wall height is greater than 13'. Estimator prefers to use the same type of equipment.

Wall Turns Wall Curvature

Wall Turn Orientation 90o

Estimator selects base productivity rate based on the crew's composition of labor and equipment then increases it because 75-100% of the walls have the same height and reduces it to account for the additional framing for wall turns, the additional layout for non-90 o wall turns and wall curvature.

Legend: Estimator’s Rationale for the Activities, Design Resources, and Resource Productivity Conditions Rates for the Design Conditions

Estimator’s Rationale for the Activities, Design Resources, and Resource Productivity Conditions Rates for the Design Conditions

Automatic Customization of Cost Information

Manual Customization of Cost Information

Manual Data Entry or Manual Process

Automated Process

Estimating Database

Cost Item related to component using current tools

Figure 3: Current cost estimating process using state-of-the-art software that links with IFC-based product models. Estimators make automatic and manual adjustments to customize the activities, resources and resource productivity rates to account for various design conditions. The estimator automatically adds activities to construct the wall’s subcomponents, lay out the wall, and frame openings (1). Then, the estimator manually adds activities to account for the wall-beam intersection (2), changes the crew to include Rolling Scaffolding (3), and selects the base crew productivity rate and adjusts it to account for component similarity, wall turns, non-90° wall turns, and wall curvature (4).

6

(1) The estimator automatically customizes activities: The estimator add activities that are typically needed to construct walls to a cost assembly and specifies the component properties that limit the cost assembly’s applicability (Timberline 2001). For the use case, the estimator adds activities to install the wall’s subcomponents, lay out the wall, and frame the openings to the cost assembly. Then, the software automatically adds the activities for each instance of the component in the product model that satisfy the constraints on the component properties. (2) The estimator manually customizes activities: The estimator manually adds activities to account for unique design conditions, such as the “Wall-beam Intersection.” (3) The estimator manually customizes resources: The estimator manually adds resources to activities for specific design conditions. For example, the estimator changes the crew to include Rolling Scaffolding for executing the “Install Metal Studs” activity because the height of Wall1 is between 9’ and 13’. (4) The estimator manually customizes resource productivity rates: The estimator selects the base productivity rate for each activity based on the crew composition and then adjusts the crew productivity rate to reflect the production impact of different design conditions. For example, the estimator selects the base crew productivity rate for the Labor Crew C-1 using Rolling Scaffolding, and then adjusts the productivity rate to account for component similarity, wall turns, non-90° wall turns, and wall curvature. The motivating case shows how estimators customize a project’s activities, resources, and resource productivity rates to account for the cost impact of the different design conditions.

Estimators identify relevant design conditions and adjust the

activities, resources, and resource productivity rates regardless of the type of component they are estimating.

Consequently, it is possible to formalize and generalize the

estimator’s process and provide automated support of the cost estimating process for a variety of construction domains. To provide a formal and general process, we abstracted the design information estimators consider, the different ways estimators adjust the cost information to account for different design conditions, and the different steps estimators perform to customize activities and resources.

7

We use the concept of features to describe the design information estimators care about. We refer to components in a building product model, such as walls and columns, as “component features.” Throughout the remainder of this paper, the terms “component feature” and “component” will be used interchangeably. We refer to features that result from the intersection of two components, such as openings and turns, as “intersection features.” Design conditions describe when a particular feature affects construction costs. Design conditions can be based on properties of component features (e.g., the curvature and height of the wall), groupings of component features (e.g., the grouping of walls based on component similarity), the existence of intersection features (e.g., the existence of turns and openings), and properties of intersection features (e.g., the orientation of wall turns). The use case demonstrates that component and intersection features drive the requirement for activities for constructing a particular component. Activities are required to install the subcomponents of a component (e.g., “Install Metal Studs” activity for wall’s decomposition), to account for component properties (e.g., “Lay out Wall” activity for wall curvature), to perform supporting activities for constructing a component (e.g., the “Lay out Wall” activity supports the “Install Metal Studs” activity), and to construct intersection features resulting from a component’s intersection with other components (e.g., “Frame Wall-Beam Intersection” for Wall1’s intersection with the beam). Today, estimators manually adjust the cost estimate to account for the activities required to construct unique features, such as adding activities to construct the “Wall-Beam Intersection.” Estimators also use ad hoc methods to account for activities that are too time-consuming to consider explicitly, such as adjusting the crew productivity rate to account for wall turns and non-90° wall turns. The use case also illustrates the estimator’s process for customizing the resources required to execute the activities. For the “Install Metal Studs” activity, the estimator assigns equipment based on the height of the wall. Then, if multiple instances of the activity calls for different types of equipment (e.g., Rolling Scaffolding and Scissor-lifts), the estimator adjusts the equipment assignments so the activities are using the same type of equipment. For example, if a drywall design has 10’ and 14’ walls, the estimator adjusts the resource assignments for all “Install Metal Studs” activities to include a

8

Scissor-lift even though the estimator typically uses Rolling Scaffolding to construct 10’ walls. Finally, the estimator selects the base productivity rate for each activity based on the crew composition and adjusts the base crew productivity rate to reflect the production impact of specific design conditions. For example, for the “Install Metal Studs” activity, the estimator selects the base productivity rate for Labor Crew C-1 using Rolling Scaffolding, and then adjusts the productivity rate to account for component similarity and wall curvature. For a large project, it is typically too time-consuming to perform all the projectspecific adjustments of activities, resources, and resource productivity rates for the different design conditions in a given product model manually. Consequently, estimators often employ ad hoc methods (e.g., reduce the crew productivity to account for wall turns and non-90° wall turns) and overlook the cost impact of features and feature properties (e.g., overlook the wall-beam intersection and its cost impact). Moreover, if the design changes, estimators must manually identify the cost information affected because current cost estimates do not explicitly represent the estimator’s rationale for customizing activities and resources. Hence, the lack of automated support leads to inconsistencies and inefficiencies in the cost estimating process and the corresponding cost estimate. Estimators need a formal process for customizing the activities and resources to create an integrated model that explicitly relates the project-specific features, activities, resources, resource productivity rates, costs, and the project-independent estimator’s rationale. The formal process needs to: o Customize the activities for constructing a specific component based on the component’s decomposition, the component’s properties, the intersection features of the component, and the requirement for supporting activities based on an estimator’s preferences and the design conditions in a given product model. o Customize the crew composition of labor and equipment based on the specific design conditions in a given product model and an estimator’s preferences for when and how to make resource assignments. o Customize the crew productivity rate based on the crew composition, the specific design conditions in a given product model, and an estimator’s preferences.

9

o Identify the cost information affected by design changes and adjust the cost estimate according to the estimator’s preferences. Estimators need automated support to customize activities and resources according to their preferences when generating and maintaining cost estimates from 3D product models.

Our research addresses this need by formalizing a feature-driven

activity and resource customization process that can be implemented in the computer. 1.2 Research Goals The use case illustrates the needs of the formal process: (1) Formal: Estimators need a formal process for customizing activities, resources, and resource productivity rates to help them generate and maintain construction costs and prevent them from using implicit or ad hoc methods to account for the cost impact of different design conditions. By formalizing a process to provide this functionality, estimators should be able to account for the cost impact of features explicitly and consistently. (2) General: Estimators need a process that is general enough to account for different estimator preferences when generating and maintaining construction cost estimates from 3D product models. It must also be general enough to support cost estimating of different product models, product model changes, and construction domains. In summary, cost estimating tools must be able to recognize unique design conditions and adjust the project’s activities and corresponding resources and generate and maintain an integrated model based on the estimators’ rationale.

To

provide this type of functionality, we developed a formal process that combines and extends previous research in construction cost estimating and activity modeling.

2. Related Research Background Previous research efforts demonstrate that construction costs can be generated from 3D models.

Researchers also identify the design conditions that affect the

applicability of resources and impact a resource’s productivity rate when executing an activity. However, they do not provide a formal process that customizes a project’s activities, resources, and resource productivity rates based on an estimator’s preferences 10

and relevant features and design conditions in a given product model. Moreover, they do not create an integrated model that represents the many relationships between features, activities, resources, costs, and the estimator’s rationale. 2.1 Prior Research on Construction Cost Estimating Many research efforts focus on generating cost estimates from 3D models and creating integrated models and explicitly relate the components, activities, resources, and costs similar to our research (Laitinen 1998; Aouad et al. 1994; Froese et al. 1996; Aouad et al. 1997; Clayton et al. 1996). They customize construction costs by identifying the typical activities, resources, and resource productivity rates for a specific component in a product model. However, they do not formalize a process to customize a project’s activities, resources, and resource productivity rates for different design conditions or different estimator preferences.

Moreover, they do not represent why components,

activities, resources, and costs are related and when the relationships are needed. In contrast, previous research efforts on method modeling customize an activity’s resources based on the unique design conditions in a given product model similar to our research (Fischer 1991; Hanna et al. 1992; Udaipurwala and Russell 2000; Froese and Rankin 1998). For example, Fischer (1991) identifies the applicable formwork methods for reinforced concrete structures based on a given 3D product model. However, these research efforts do not provide a way to represent different estimators’ preferences and do not provide a formal process that customizes an activity’s resources based on those preferences. The resources assigned to the activities do not know what design conditions affect their assignment or when the assignment is no longer applicable. They are also unable to customize the crew executing an activity by assembling the appropriate labor and equipment resources based on the specific design conditions in a given product model. Similarly, researchers focusing on productivity modeling customize resource productivity rates for unique design conditions in a given product model (Thomas and Zavrski 2000; Thomas and Sackrakan 1994; de Sousa and Thomas 1996; Smith and Hanna 1993; Sanders and Thomas 1991; Akbas and Fischer 1999).

For example,

Thomas and Sackrakan (1994) formalize a process to forecast labor productivity based on the work environment, which includes different design conditions and construction 11

methods.

However, they do not formalize a process to customize the resource

productivity rates based on different estimator preferences. Moreover, they account for the production impact of some features in an ad hoc way. For example, they adjust the productivity rate for certain features, such as openings and turns, that actually require additional activities to be constructed. Prior research efforts in cost estimating do not provide a formal process to customize activities, resources, and resource productivity rates based on different estimator preferences and they do not create an integrated model that that explicitly represents the relationships between features, activities, resources, costs, and the estimators’ preferences. 2.2 Prior Research on Activity Modeling Prior research efforts in activity modeling generate resource-loaded activities for the component feature being installed and the method being used (Aalami 1998; Darwiche et al. 1989; Froese and Rankin 1998; Jagbeck 1994; Stumpf et al. 1996; Udaipurwala and Russell 2000).

They generate activities that know what object

they act on, what action is being performed, and what resources are being used. However, prior research efforts in activity modeling do not provide a formal process to customize the resources and the resource productivity rates to account for the production impact of different features and design conditions and different estimators’ rationale. Our research extends the activity definition by generating activities that also know what feature requires the activity’s execution and how much the activity costs to create an integrated model that is explicitly related to the estimator’s rationale.

3. Generating Resource-loaded and Cost-loaded Activities Related to Feature-based Product Models So far this paper has presented the need for a formal process to customize the activities and resources and create an integrated model that supports the maintenance of construction cost information. Figure 4 shows an overview of the feature-driven activity and resource customization process.

Based on the abstracted project-independent

estimating knowledge, the formal process transforms the project-specific feature-based product model and the generic activities and resources into project-specific resource-

12

loaded and cost-loaded activities. To represent estimators’ rationale about the influence of features on activities and resources, we created Activity Specifications (AS) and Resource Specifications (RS) respectively. The process creates an integrated model consisting of activities that know what feature requires their execution, what resources are assigned to the activities and why (RS), what the resources’ productivity rates are and how they were adjusted (RS), and how much the execution of the activities costs .

The explicit relationships between features,

activities, resources, resource productivity rates, and the estimator’s rationale provides the foundation for generating and maintaining construction costs for feature-based product models. Generation of Project-Specific Integrated Model Related to the Project-Independent Estimator’s Rationale (AS, RS) AS

Features

, AS

Has the estimator specified an activity for the feature? Estimate Feature-based Product Model

Yes

AS



Customize Activities

Project-Independent Activities, Resources and Resource Productivity Rates

Customize Resources

No

Project-Independent Estimator’s Rationale about Resources --Resource Specifications-(RS)

Activities

Yes

Resources

AS

AS RS

, RS RS RS Has the estimator specified a productivity rate for the resource?

Has the estimator specified a resource for the activity?

No

Project-Independent Estimator’s Rationale about Activities --Activity Specifications-(AS)

AS

, RS

Yes

RS

Customize Resource Productivity Rate

AS RS RS

Generate Construction Costs

No

Project-Independent Estimator’s Rationale about Resource Productivity --Resource Specifications-(RS)

Resource Productivity Rates

Figure 4: Overview of the formal feature-driven activity and resource customization process. The formal process assembles features , activities , resources , resource productivity rates, and costs based on the estimator’s rationale (AS, RS). We developed the feature-driven activity and resource customization process by abstracting estimating tasks and the associated knowledge.

We reviewed previous

research in this area, supported a design-build team with state-of-the-art tools to generate estimating quantities from a 3D model of the design (Staub-French and Fischer 2001), and interviewed 14 different cost estimators. We interviewed two general contractors and twelve subcontractors that self-perform construction work on drywall, structural concrete, ductwork, process piping, and electrical systems. We performed three case studies on two drywall construction projects and one concrete column construction project. We formalized the different vocabularies used by estimators to describe the design conditions that affect construction costs and formalized a process to customize a

13

project’s activities, resources, and resources’ productivity rates for specific design conditions in a given product model. We describe the process in greater detail in Section 3.3, but first we describe the feature-based product model that drives the process (Section 3.1) and the representation of estimators’ rationale in Activity and Resource Specifications that guides the process (Section 3.2). 3.1 Representing the Features that are Important to Cost Estimators The motivating case demonstrated that different design conditions influence construction costs. The “wall-beam intersection” created an unusual framing condition and the orientation of the “wall turn” affected the wall lay out. To help estimators generate and maintain cost estimates, cost estimating software must represent the design conditions that are important to cost estimators. To represent the design conditions that affect construction costs, we abstracted the different vocabularies used by estimators to describe different design conditions and formalized a feature-based product model to support construction cost estimating (Staub-French et al. 2002a). The motivating case showed that different types of design information affect construction costs. Estimators consider properties of component features, groupings of component features, intersections of component features, and properties of component intersections when creating cost estimates (Figure 3). We formalized a feature ontology that classifies features and represents the sets of features and properties that affect costs for a specific construction domain. Using the feature ontology, estimators can create features and specify the features and properties that affect a particular component’s construction costs.

We created a prototype application called Feature Generator

(FeaGen) that leverages the feature ontology to create a project-specific feature-based product model that represents the features and properties that are important to estimators. Figure 5 shows the symbolic representation of the features and properties instantiated for the drywall estimator estimating the wall component feature in the motivating case. Hence, each component feature instantiated knows what its decomposition is and what component properties, intersection features, and intersection feature properties influence its construction. The main contributions lie in the formalization of the feature ontology and the framework developed to capture this knowledge from estimators. 14

Project-Specific Features Component Features

Intersection Features

Turn1 Opening1 Wall-Beam Wall1 --Orientation = 85o Intersection1 --Height = 10' --Curvature = False --Fire-rated = True --Has Feature Set --Has Subcomponents Insulation Metal Stud Taping Drywall

Legend: Classes

--Properties

= Property Values

Contains Relationship

Objects Contained Specialization Relationship

Figure 5: Symbolic representation of the project-specific feature-based product model instantiated for Wall1 for the estimator in the motivating case. The project-specific feature-based product model represents the features and properties that are important to the estimator. The properties of Wall1 that affect construction costs are instantiated (e.g. height, curvature, and fire-rated), the intersection features of Wall1 are instantiated in the “Has Feature Set” attribute (e.g., Turn1, Opening1, and Wall-beam Intersection1), the properties of intersection features affecting Wall1 are instantiated (e.g., the orientation of Turn1), and the subcomponents of Wall1 are instantiated (e.g., Metal Stud and Drywall). The project-specific feature-based product model is the input to the activity and resource customization process. The next section describes how estimators represent their rationale for how features influence activities and resources in a project-independent way using Activity and Resource Specification templates. 3.2 Templates for Representing Estimators’ Rationale The motivating case demonstrated the need to represent estimators’ rationale in a computer-interpretable way to provide automated support for customizing construction costs based on different estimators’ preferences. To capture estimators’ rationale and represent it formally in the computer, we abstracted the common attributes of estimators’ rationale for how and when different design conditions affect construction costs and developed templates to capture this estimating knowledge from estimators (Staub-French et al. 2002b).

15

The motivating case illustrated the different ways estimators adjust construction costs to account for different types of design conditions. Estimators adjust the project’s activities, resources, and resource productivity rates to account for the cost impact of different design conditions. We created different templates that allow estimators to specify the design conditions that affect activities (Activity Specification templates) and the design conditions that affect resources (Resource Specification templates). Activity Specification templates capture estimators’ rationale about how and when activities are required for different design conditions.

Resource Specification templates capture

estimators’ rationale about when resources are required for a given activity and when and how to adjust resource productivity rates for different design conditions. The templates provide a structured way to describe the design conditions that affect construction cost information. Estimators can specify properties of component features (e.g., the curvature and height of the wall), subcomponents of component features (e.g., metal studs are a subcomponent of walls), groupings of component features (e.g., the grouping of walls based on component similarity), intersection features (e.g., the existence of turns and openings), and properties of intersection features (e.g., the orientation of wall turns). The templates represent the estimators’ rationale in a project-independent way so that they can be reused from project to project.

The main contributions of the generic

representation of estimators’ rationale lie in the different templates, the structure of the templates, and the attributes of the templates. 3.2.1

Activity Specification Templates The motivating case demonstrated that activities are required to install

subcomponents of a component, to account for component properties, to perform supporting activities for constructing a component, and to construct intersection features. For example, a subcomponent of the wall required the “Install Metal Studs” activity, the intersection of the wall and the beam required the “Apply Caulk” activity, and the curvature of the wall required the “Lay out Wall” activity (Figure 3). Activity Specification templates enable estimators to represent their preferences for the activities to add for a particular feature, feature property, or subcomponent of a component feature. Estimators input their rationale once in the Activity Specification templates and the formal process reuses this knowledge to create project-specific

16

activities when generating and maintaining cost estimates from feature-based product models. Estimators specify the feature that requires the activity, the design condition that dictates when the feature requires the activity, the activity (represented as an actionobject pair) to instantiate if the feature exists and the design condition is satisfied, and the cost implication of the activity. Figure 6 shows the attributes of Activity Specifications and instances from the motivating case. The estimator specifies the activity to add by identifying the object to install (e.g., “Metal Stud”) and the action to perform on the object (e.g., “Install”).

The action-object pair points to a generic activity that contains

additional information that is needed to calculate the activity’s cost and determine the resources needed to execute the activity.

Specifically, the generic activity contains

attributes for the formula for calculating the activity’s quantities, the estimator’s preferences for the possible labor and possible equipment resources to execute the activity, the estimator’s preference to use the same equipment for all instances of the activity, and the need for supporting activities. The formal process creates a projectspecific instance of the generic activity if the design condition specified in the Activity Specification is satisfied.

17

Relevant Design Conditions

Estimator's Rationale about Activities Required for Design Conditions

Estimators Rationale Input in Activity Specification Template Activity Specification

Install Metal Studs Metal Studs

W all

Action O bject Cost Implication Feature

Install Metal S tud Resourc e & Material N/A

Design Condition

Wall Decomposition

Feature

Insulation Drywall

Constraint N/A

Joint Tape

Figure 6a: Example Activity Specification template shows an estimator’s preference to add the activity “Install Metal Studs” to construct a subcomponent of the wall component feature. Relevant Design Conditions

Estimator's Rationale about Activities Required for Design Conditions

Estimators Rationale Input in Activity Specification Template Activity Specification

Wall-Beam Intersection

Feature

Design Condition

Apply Caulk

Action O bject Cost Implication Feature

W all-B eam Intersection A pply Caulk Resource & Material W all

Constraint W all is Fire-rated

Figure 6b: The example Activity Specification templates show an estimator’s preference to add the activity “Apply Caulk” for the feature “Wall-beam Intersection” if the intersected wall is fire-rated. Figure 6: Activity Specification templates represent an estimator’s rationale for when an activity is required for a specific feature and how it affects material and resource costs. The attributes of Activity Specifications represent our formalization of estimators’ rationale about the requirement for activities for particular design conditions. 3.2.2 Resource Specification Templates The motivating case demonstrated that resources are needed for different design conditions and that resource productivity rates are impacted by different design conditions. For example, the estimator added Rolling Scaffolding to the crew based on the wall’s height and adjusted the resource’s productivity to account for component similarity (Figure 3). Estimators represent their rationale for how different design conditions affect the allocation and execution of resources in an activity by filling out Resource Specification templates.

Estimators input their rationale once and the formal process reuses this

knowledge to assign resources and adjust resource productivity rates when generating

18

and maintaining cost estimates for a given feature-based product model. Figure 7 shows the attributes of Resource Specifications and instances from the motivating case. Estimators specify their preferences for when resources are appropriate in an activity (Figure 7a) and when to select and adjust a resource’s productivity rate for particular design conditions (Figure 7b).

To represent estimators’ rationale about resources,

estimators specify the activity (represented as an action-object pair), the resource, and the design condition that dictates when the feature requires the resource. The estimator specifies the activity by identifying the object to install (e.g., “Metal Stud”) and the action to perform on the object (e.g., “Install”).

The action-object pair points to a

generic activity that specifies the possible labor and possible equipment resources for executing the activity. The estimator selects the generic resource from the possible labor and equipment resources specified for the activity to represent their preference for when that resource should be assigned to the activity. To represent estimators’ rationale about resource productivity rates, estimators specify the activity, the resource whose productivity rate to adjust, the adjustment of the productivity rate, and the design condition that dictates when the feature requires the productivity rate adjustment (Figure 7b). The formal process assigns resources to activities and adjusts resource productivity rates according to the estimator’s preferences in Resource Specifications and based on the specific design conditions in the feature-based product model. The formal process leverages the estimators’ rationale captured in Activity and Resource Specification templates to customize activities and resources for a given product model, which we discuss next.

19

Relevant Design Conditions

Estimator's Rationale about Resources and Resource Productivity Rates for "Install Metal Studs" Activity

Estimator's Rationale Input in Resource Specification Template Resource Specification

Wall Height

Install

O bject Resource Feature

Metal S tud Rolling S c affolding W all

Design Condition

Use Rolling Scaffolding if the wall height is between 9' - 13'.

Action

Constraint

9'< = Height < =13'

Figure 7a: Resource Specifications representing an estimator’s preference to use Labor Crew C-1 if the wall height is less than 20’ and to use “Rolling Scaffolding” if the wall height is greater than 9’ and less than 13’ for the “Install Metal Studs” activity. Relevant Design Conditions

Estimator's Rationale about Resources and Resource Productivity Rates for "Install Metal Studs" Activity

Estimator's Rationale Input in Resource Specification Template Resource Specification

Component Similarity

Action

Design Condition

Increase the base crew productivity rate 10% if 75-100% of the walls have the same height.

Install

O bject Resource Adjustm ent Feature

Metal S tud Crew P .R. Increase 10% Grouping 75-100% W alls Constraint have S imilar Heights

Figure 7b: Resource Specification representing an estimator’s preference to increase the crew’s productivity by 10% if 75-100% of the walls have similar wall heights. Figure 7: Resource Specification template that allows estimators to represent their rationale for when a resource is appropriate in an activity and when and how a resource’s productivity should be adjusted for particular features. The attributes of Resource Specifications represent our formalization of estimators’ rationale about how and when different design conditions affect the execution of resources. 3.3 A Formal Process for Customizing Activities, Resources, and Resource Productivity Rates The motivating case demonstrated that estimators need automated support for customizing activities, resources, and resource productivity rates when generating and maintaining cost estimates based on feature-based product models.

The research

challenge is that different features and design conditions exist in any given product model, that different features and design conditions affect construction costs in different ways, and that estimators have different preferences for how to adjust construction costs to account for different features and design conditions. The process we formalized addresses these challenges because it is general enough to customize activities and resources for different estimators’ preferences and the particular features and design conditions in a given product model. The formal process assembles a project-specific integrated model consisting of features, activities, resources, resource productivity rates, and costs based on the project-independent representation of estimator’s rationale and the project-specific feature-based product model (Figure 4).

20

Figure 8 shows the mechanisms implemented and estimating knowledge used in the three primary steps in the activity and resource customization process and the inputs to each step: (1) Customize Activities: Customize the activities for each component feature being estimated based on the estimator’s rationale in Activity Specifications and the features in the product model. (2) Customize Resources: Customize each activity’s resources and resource productivity rates based on the estimator’s rationale in Resource Specifications and the particular features in the product model. (3) Generate and Maintain Construction Costs: Calculate each activity’s quantities and duration to determine the activity’s cost. If the estimate is based on a revised design, identify the cost information affected and reconcile the activities and resources so that the design and estimate remain in balance. Activity Specifications Generic Activities & Resources

Estimator’s Feature-based Product Model

Customize Activities 1

Activities & Related Feature-based Product Model

(1) Identify and Analyze Activity Specifications (Component Features)! (2) Instantiate Activities (Component Features)! (3) Identify and Analyze Activity Specifications (Intersection Features)! (4) Instantiate Activities (Intersection Features)! (5) Instantiate Supporting Activities!

Resource Specifications Generic Activities & Resources

Customize Resources 2

Resource-loaded Activities & Related Feature-based Product Model

(1) Identify and Analyze Resource Specifications (Labor & Equipment)! (2) Assign Resources to Activities! (3) Select Base Crew Productivity Rates! (4) Identify and Analyze Resource Specifications (Crew Productivity)! (5) Adjust Resource Productivity Rates!

Generic Activities & Resources

Project Cost Estimates

Generate and Maintain Construction Costs 3

Resource-loaded and Cost-loaded Activities & Related Feature-based Product Model

(1) Calculate Quantities and Resource Durations! (2) Calculate Costs! (3) Reconcile Costs (if design changes)

Figure 8: The three steps in the activity and resource customization process formalized in our research that customizes activities, resources, and resource productivity rates for a given feature-based product model. The resource-loaded and cost-loaded activities resulting from this process are explicitly related to the feature-based product model and the estimator’s rationale captured in Activity and Resource Specifications. We implemented the feature-driven activity and resource customization process and it’s mechanisms in the software prototype called Activity-based Cost Estimating 21

(ACE) as part of the validation of these specifications. We use ACE in the following sections to describe the specific mechanisms executed in the formal process. The next sections describe each step of the activity and resource customization process in detail. 3.3.1

Customize the Activities to the Features and Design Conditions in a Product Model The motivating case demonstrated that component and intersection features drive

the requirement for activities. The construction of the wall required the execution of activities based on the wall’s decomposition (e.g., “Install Metal Studs”), based on the wall’s properties (e.g., the curved wall requires the “Layout Wall” activity), based on the need for supporting activities (e.g., “Layout Wall” supports the “Install Metal Studs” activity), and based on the intersection features that result from the wall’s intersection with other components (e.g., “Frame Wall-Beam Intersection”). Hence, the activity customization process must formally consider the component’s decomposition, the properties of the component, the intersection features of the component, and the requirement for supporting activities when customizing the activities needed to construct a specific component. The project-specific feature-based product model and the project-independent Activity Specifications enable the activity customization process. The input product model explicitly represents the features and properties that are important to the cost estimator.

For example, the feature-based product model for the motivating case

instantiates the properties of Wall1 that affect construction costs (e.g. height, curvature, and fire-rated), the intersection features of Wall1 that affect construction costs (e.g., Turn1, Opening1, and Wall-beam Intersection1), the properties of features affecting Wall1 (e.g., the orientation of Turn1), and the subcomponents of Wall1 (e.g., Metal Stud and Drywall). Activity Specifications represent the estimator’s preferences for adding activities based on the component’s decomposition, the properties of the component, the intersection features of the component, and the requirement for supporting activities. Hence, at this stage in the reasoning process, ACE knows what the relevant features and properties are in the project-specific product model and the estimator’s preferences for adjusting the activities to account for them. With five reasoning mechanisms, the activity

22

customization process creates project-specific activities based on the estimator’s preferences for the project-specific features and properties instantiated in the input feature-based product model (Figure 9). Activity Specifications

Project-Specific Feature-based Product Model Features

Generic Activities & Resources Component Features

Customize Activities

Project-Specific Feature-based Product Model

1

Wall1

Features

Intersection Features

Turn1

Opening1

Wall-Beam Intersection1

Project-Specific Activities Component Features

Intersection Features

Turn1

Opening1

(1) Identify and Analyze Activity Specifications (Component Features)! (2) Instantiate Activities (Component Features)! (3) Identify and Analyze Activity Specifications (Intersection Features)! (4) Instantiate Activities (Intersection Features)! (5) Instantiate Supporting Activities!

Wall-Beam Intersection1

Activity Specification2

(3)

Metal Stud Drywall

Insulation Taping

Feature Action Object Cost Implication Feature

Design Condition

Wall1 --Has Feature Set --Decomposes Into

Constraint

Wall-Beam Intersection Apply Caulk Resource & Material Wall

Activities

(4) Apply Caulk

(5) Layout Wall

(2)

Install Metal Studs --Driving Feature --Object = Metal Stud --Action = Install --Cost Implication = “Resource & Material” --Formula: Length*Height/16" --Supporting Activities: Layout Wall --Use Same Equipment: “Yes” --Possible Labor = Crew C-1 --Possible Equipment = Rolling Scaffolding, Scissor-lift --Activity Specification

Wall is Fire-rated

Activity Specification1 Wall

Action Object Cost Implication Feature

Install Metal Stud Resource & Material N/A

Design Condition

(1)

Feature

Constraint N/A

Legend: Object

--Attribute

= Attribute Value

= Related Object

Project-specific Relationship

Step in Formal Activity and Resource Customization Proce

Figure 9: The first step customizes the activities for a specific component based on the component’s decomposition, the properties of the component, the intersection features of the component, and the requirement for supporting activities. To customize activities, the process executes five reasoning mechanisms that identify and analyze Activity Specifications for component features and intersection features, instantiate activities for component and intersection features and supporting activities. ACE creates project-specific activities based on the features and properties in the input product model and the estimator’s rationale in Activity Specifications. (1) Identify and Analyze Activity Specifications (Component Features): For each instance of a component feature, identify the Activity Specifications (Figure 6) that represent the estimator’s preferences to add activities for subcomponents of the component and properties of the component. For example, in the motivating case, ACE identifies the “wall” component features in the estimator’s feature-based product model. To identify the Activity Specification for the wall’s subcomponents and component properties, ACE identifies the Activity Specifications that have the

23

component feature in the “Feature” attribute. If the Activity Specification is for a subcomponent, ACE also matches the particular subcomponent in the “Object” attribute. For example, ACE identifies the Activity Specification for the “Install Metal Stud” activity because metal stud is a subcomponent of the wall and because metal stud and wall are specified in the “Feature” and “Object” attributes of the Activity Specification. If there are several matches, ACE asks the estimator to select the most appropriate Activity Specification. (2) Instantiate Activities (Component Features): Instantiate the activities specified in the Activity Specifications for subcomponents of the component and properties of the component. For example Activity Specifications shown in Figure 9, ACE creates the “Install Metal Studs” activity. Then, create relationships to the component feature that requires the activity and to the Activity Specification that represents the estimator’s rationale for adding the activity. Finally, find the corresponding generic activity in the database and copy the generic activity’s formula for calculating the activity’s quantities, the possible labor and possible equipment resources that the activity can use to execute the activity, the requirement for using the same equipment for all instances of the activity, and the need for supporting activities to the activity instance. (3) Identify and Analyze Activity Specifications (Intersection Features): Identify the Activity Specification for the intersection features of each component by matching the intersection feature in the “Feature” attribute.

Then, analyze the “Design

Condition” attribute of the Activity Specification because the applicability of the activity may be constrained to certain design conditions.

For example, in the

motivating case, the intersection feature “Wall-Beam Intersection” requires the activity “Apply Caulk” if the intersecting wall is fire-rated. Analyze the intersection feature and related intersecting components in the estimator’s feature-based product model to determine if the design condition is satisfied. (4) Instantiate Activities (Intersection Features): Instantiate the activities specified in the Activity Specifications for the intersection features of the component. For the example Activity Specifications shown in Figure 9, ACE creates “Apply Caulk” activity for the “Wall-beam Intersection” feature. Then, create relationships to the

24

intersection feature that requires the activity and to the Activity Specification that represents the estimator’s rationale for adding the activity and copy the corresponding generic activity’s attributes to the activity instance as described in step 2. (5) Instantiate Activities (Supporting Activities): For each newly instantiated activity, assess whether the activity requires supporting activities by checking the supporting activities attribute of the activity. If the activity requires supporting activities, instantiate those activities as described in step 2 and 4. For example, ACE creates the “Lay out Wall” activity because it is a supporting activity of the “Install Metal Studs” activity. The activity customization process creates project-specific activities for each component in a given product model based on the component’s decomposition, the intersection features of the component, and the requirement for supporting activities. The process creates activities formally and systematically and prevents estimators from using implicit or ad hoc methods to account for the cost impact of features. For example, estimators cannot account for the production impact of wall turns by fudging the crew’s productivity (Figure 3).

Rather, estimators must account for intersection features

explicitly by representing the activities that need to be executed. Moreover, if the design changes, the formal process re-assembles the activities for each component based on the new features in the revised design. At this stage in the reasoning process, each activity knows what feature requires its execution, the material and resource cost implications of the activity, the possible resources for executing the activity, and the estimator’s rationale for adding the activity. The resource customization process leverages this integrated model to identify the specific resources needed to execute each activity. 3.3.2 Customize the Resources in an Activity to the Features and Design Conditions in a Product Model Estimators often have preferences for when a specific resource should be used in an activity. That preference is often based on the particular conditions found in a design. For example, the estimator in the motivating case preferred to use Rolling Scaffolding in the "Install Metal Studs" activity when the wall height is greater than 9' and less than 13', and use a Scissor-lift when the wall height is greater than 13'.

The estimator also

preferred to use the same piece of equipment for constructing all instances of the “Install

25

Metal Studs” activities rather than switching equipment to execute the activities (Figure 3). Estimators also have different preferences for when a crew’s productivity rate is appropriate in a given activity and how it should be adjusted for different design conditions.

In the motivating case, the drywall estimator selected the crew’s base

productivity rate for the “Install Metal Stud” activity based on the resources required (Crew C-1 using Rolling Scaffolding) and then adjusted the productivity to account for wall curvature and component similarity. The project-specific feature-based product model, the project-specific activities, and the project-independent Resource Specifications enable the resource customization process. With the five reasoning mechanisms, the resource customization process assigns resources to activities and adjusts resource productivity rates based on the estimator’s preferences for the project-specific features and properties instantiated in the input product model (Figure 10). Project-Specific Feature-based Product Model

Project-Specific Feature-based Product Model

Features

Features

Component Features

Resource Specifications

Intersection Features

Component Features

Intersection Features

Activitybased Costs Turn1

Opening1

Wall1

Wall-Beam Intersection1

Project-Specific Activities

Customize Resources

Activities

Apply Caulk

Layout Wall

Install Metal Studs

--Driving Feature --Object = Metal Stud --Action = Install --Cost Implication = “Resource & Material” --Formula: Length*Height/16" --Supporting Activities: Layout Wall --Use Same Equipment: “Yes” --Possible Labor = Crew C-1 --Possible Equipment = Rolling Scaffolding, Scissor-lift --Activity Specification = Activity Specification1

2

Turn1

Install

Object Resource Feature

Metal Stud Rolling Scaffolding Wall

Design Condition

(1)

Resource Specification 2

Constraint 9'