P R O T O T Y P E I N T E G R A T E D C O S T AND S C H E D U L E

C O N T R O L S Y S T E M

By Osama Y. Abudayyeh I and William J. Rasdorf, 2 Members, ASCE

ABSTRACT: Effective management of construction projects depends on good ac- cess to and control of data, especially data pertaining to cost- and schedule-control functions. Long recognizing the need to integrate these interrelated functions and to improve the quality, integrity, and timeliness of data, researchers have proposed conceptual models to achieve this purpose. However, the proper design and de- velopment of an automated solution that would support the needs of integrated cost and schedule control and acquire and store quality data in a timely manner has been lacking. Aware of these deficiencies, we designed and developed a suc- cessful prototype of an automated cost- and schedule-control system that is based on the work-packaging model and that uses bar coding in its data-acquisition com- ponent. The purpose of this paper, then, is to discuss the prototype's capabilities and components and to illustrate how the system is used in controlling cost and schedule of a study case based on an actual construction project.

INTRODUCTION

Although a majority of construction projects employ some method of cost and schedule control, these projects often suffer from ineffective control due to inefficient flow of information. This inefficiency in control is a fun- damental problem in construction management . Specifically, the quality of information flowing in the control system is the essence of the problem. Problems are observed both in projects themselves at the time of their construction, as well as in the corporate historical data base. A solution to this problem imposes two challenges: integrationg cost- and schedule-control functions, and controlling data quality, integrity, and timeliness (Abudayyeh and Rasdorf 1990, 1991; Rasdorf and Abudayyeh 1991).

To address these challenges, it is important to acquire and maintain cost and time data using an established common-denominator control account de- fined at a sufficiently detailed level (Abudayyeh and Rasdorf 1990, 1992; Rasdoff and Abudayyeh 1991). However, it is not enough to simply establish and maintain a common denominator. What is also needed is an automated information-management system that can truly integrate cost- and schedule- control functions on the one hand, while acquiring, storing, and presenting quality data and information in a timely manner on the other. To satisfy those needs, we identified and selected the work-packaging model as the integrated model (Abudayyeh and Rasdoff 1990; Rasdorf and Abudayyeh 1991), and then used bar coding and data-base mechanisms to acquire and store data. The next section briefly describes the work-packaging model, which serves as the foundation of our cost- and schedule-control system. Then, the paper discusses the components of the prototype system and demonstrates its use.

1Bridge Engr., CA Dept. of Transportation, Office of Structures Construction, 21030 Redwood Road, Castro Valley, CA 94546; formerly, Res. Asst., Civ. Engrg., North Carolina State Univ., Box 7908, Raleigh, NC 27695.

2Assoc. Prof., Civ. Engrg., North Carolina State Univ., Box 7908, Raleigh, NC. Note. Discussion open until September 1, 1993. To extend the closing date one

month, a written request must be filed with the ASCE Manager of Journals. The manuscript for this paper was submitted for review and possible publication on September 11, 1991. This paper is part of the Journal of Computing in Civil Engi- neering, Vol. 7, No. 2, April, 1993. �9 ISSN 0887-3801/93/0002-0181/$1.00 + $.15 per page. Paper No. 2651.

181

WORK-PACKAGING MODEL

The development of the work-packaging model was meant to unify project data, specifically time and cost data, to make the analysis and decision- making processes easier to perform. This view imposes a change in the planning and budgeting philosophy, and a new approach to defining and using control accounts. Each of these needs and issues is addressed here.

Planning and Budgeting Planning and budgeting in the work-packaging model requires the use of

a work breakdown structure (WBS) early in the project life cycle. This means that work must be scheduled in accordance with the WBS, and budgets of resource (materials, labors, and equipment) consumption and costs must be prepared for each control account defined on the WBS. Then, the sequence of and the logical relationships between the control accounts are established, making each control account an activity on the activity network. Each control account then becomes a depository of control data that describes the work involved in it. Finally, organizational functional responsibilities are assigned to each control account established at the de- sired level of detail on the WBS. This involves using another breakdown structure: the contractor organization breakdown structure (OBS).

Measuring Work Progress Measuring work progress in the work-packaging context can be accom-

plished by a variety of methods, with the objective of estimating the progress (% complete) of every control account, and then aggregating these % com- plete values to arrive at an overall estimate for the project's progress. One method used for measuring work progress utilizes the units completed in a control account (Project 1987; Riggs 1987). In this method, the % complete for a control account is estimated by

actual units completed . . . . . . . . . . . . . . . . . . . . . . . . . . (1) % complete -- total units budgeted

Once the % complete for each control account is estimated, the overall project % complete can be computed. The project % complete is estimated using the earned-value method, in which an earned value is computed for each control account and combined with the other earned values. Individual earned values are computed by

earned value (BCWP) = % complete x budget for the account (BCWS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ( 2 )

where BCWS = total budgeted cost or work hours of work scheduled to be completed within a given time period in a specific control account; and BCWP = total budgeted cost or work hours of the work completed within a given time period in a specific control account. Thus, the progress in all control accounts can be reduced to earned dollars or work hours, which is achieved by

BCWP a c c o u n t s

overall project % complete - ~ BCWS . . . . . . . . . . . . . . . . . . . . . (3) a c c o u n t s

182

hence providing a mechanism for combining the progress in all accounts to compute the project's % complete.

Analyzing Performance The work packaging model analyzes performance by computing two in-

dices, a schedule performance index (SPI) and a cost performance index (CPI) (Project 1987). The SPt and CPI are computed for each control account as

SPI = - - BCWP BCWS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (4)

BCWP CPI -

ACWP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ( s )

where ACWP = total actual cost or work hours incurred in completing a particular work within a given time period in a specific control account. Note that SPI and CPI may be evaluated on a daily or cumulative basis.

Favorable schedule situations occur when SPI is greater than one, indi- cating that the accomplishments represented by BCWP exceed the budgeted amounts represented by BCWS (accomplishing more than what is sched- uled). Similarly, favorable cost situations are observed when CPI is greater than one, indicating that accomplishments represented by BCWP exceed actual expenditures represented by ACWP (earning more than what is spent). Thus, SPI and CPI provide assessment mechanisms for evaluating the per- formance in each control account, for which a favorable condition needs no further actions and an unfavorable condition requires further detailed analyses to remedy the situation.

Reporting A number of report sources can be found in the literature (Project 1987;

Barrie and Paulson 1984). In observing and analyzing these reports, it is concluded that an integrated cost and schedule reporting system must in- clude the following key elements:

�9 Actual cost and schedule data: The following data items are reported per control account on a daily or cumulative basis: actual material quantities, man-hours, equipment operation hours, % complete, and start and end dates.

�9 Budget cost and schedule data: This element includes the following data items per control account: budget, material quantities, man- hours, and equipment operation hours.

�9 Cost and schedule status: This element includes the following data items per control account and for the entire project: SPI, CPI, and an overall project % complete.

PROTOTYPE I(CS) 2 IMPLEMENTATION

A prototype integrated cost and schedule control system [I(CS) 2] has been implemented. Its three major modules (data acquisition, data storage, and data processing) along with its user-interface component are discussed in detail in the following subsections, along with a description of the user interface.

183

Data Acquisition Module The data-entry component of the I(CS) 2, called the data-acquisition mod-

ule, is composed of automated and integrated electronic forms combined with bar-coded data sheets to be used by an operator (assumed henceforth to be a foreman). The foreman uses a hand-held scanner to scan the data sheets, which in turn enter data directly onto the electronic forms. This automated data-acquisition system is superior to the manual systems we investigated, which has problems with data redundancy, inconsistency, and human errors in completing and processing the different forms used to collect cost and schedule data. These problems can arise when the information on these paper forms is filled out at a construction site, reviewed, and then summarized onto other paper form(s), and then keyed into a computer. The quality, integrity, and timeliness of the data are thus affected by human errors during this process.

The electronic forms combined with the bar-coded foreman data sheets used to acquire data in our system have the following advantages: (1) Only basic nonredundant data items are acquired, which is a result of integration; and (2) the integrity of data is improved because human errors are reduced through inputting the information through bar code scanning. Thus, the quality, integrity, and timeliness of data are substantially enhanced.

Electronic Forms Two types of electronic forms have been developed: remote and on-line.

The remote forms are developed using PCIRL for the transaction manager (TM). The TM and its remote forms are used for acquiring data on the site that describes the daily activities, and are assumed to be the only means for data acquisition. The program on the TM has a menuing system that assists the user in selecting the different forms. [The use of this program is discussed in the section headed "Running I(C5)2. ''] The TM can read in data by a bar-code reader in combination with bar-coded data, or by its own alphanumeric keyboard (Rasdorf and Herbert 1990).

Bar-coded data items are provided to the foreman on a sheet called the foreman data sheet (FDS), described in the next subsection. Bar codes are scanned using a portable device known as a wedge reader: given current bar-coding technology, we can assume that a foreman could easily operate the bar-code system. The electronic forms create four data files (workers, materials, equipment, and accounts status), shown in Figs. 1-4, on the TM. The foreman using the TM must then upload the data files to the workstation periodically. (The upload process is explained in a later section.) Once uploaded to the computer workstation, the files are changed into ASCII format.

The on-line forms are developed on the computer workstation using SQL*Forms. These forms are used for populating the data-storage module

1 t 131 t 11110 i 01/0~91 q 200321900 i 8 q 0

File Code (Hours Data File) Foreman ID (OBS Code) Control Account Number (Grading) Date Worker ID (Social Security Number) Regular Hours Overtime Hours

FIG. 1. Example Record from Contents of File A

184

2 131 11110 01/03/91 21210 350 2.6

q File Code (Materials Data File) 4 Foreman ID (OBS Code) q Control Account Number (Grading) t Date q Material Code t Quantity t Unit Cost

FIG. 2.

3 ii 131 11110 01/03/91 t 31210 q 6 t 19.5 q

FIG. 3.

Example Record from Contents of File B

File Code (Equipment Data File) I Foreman ID (OBS Code) I Control Account Number (Grading)I Date I Equipment Code I Operation Hours I Hourly Rental Rate |

I

Example Record from Contents of File C

4 4 File Code (Status Data File) 131 1 Foreman ID (OBS Code) 11110 q Control Account Number (Gradingl 01/03/91 t Date start t Start message

FIG. 4. Example Record from Contents of File D

with data that describes WBS, OBS, and budgets for resources. Each form is designed to populate one table in the static data base, and therefore the structure of each form closely resembles the structure of the corresponding table. These forms can accept data from a keyboard, as well as the wedge reader that is attached to the computer workstation.

Foreman Data Sheets (FDS) Foreman data sheets are designed to provide a foreman with all the

necessary data items needed to report cost and schedule data in a work- packaging control setup. An example FDS is shown in Fig. 5. The sheet includes six groups of bar-coded data items:

1. "CA Codes," which contains bar-coded control account codes under the responsbility of the foreman holding the sheet.

2. "Worker 's Names/ID's ," which contains the names and identification (ID) numbers of the crew members under the responsibility of the foreman.

3. "Material Codes," which contains the material codes for major ma- terial resources used in activities represented by the control accounts pro- vided in the CA Codes group.

4. "Equipment Codes," which contains the equipment codes of the pieces of equipment used in the activities represented by the control accounts provided in the CA Codes group.

5. "CA Status," which contains both "start" and "finish" bar-coded rues-

185

F o r e m a n D a t a S h e e t

Foreman Name:

I abex" foreman

Foreman ID: IIIIIIIIIlUlIIIH

I IIIlfllfillllliflllllll

i l l im Jlu IIH iii (liiiili~llllllililll

CA Codes

~i~i i i f i l lmi ~+~> : , , -

i i ~ l l l i l P +4> '~"

i1~ii]ilii111i~1~'1~ <''

Aloha-Numeric Pad

9 8 7 0 IIIII111111111 IIIIIIIIIIII IIIIIIIIIII1 IIIIIIIIIIIIII

6 5 4 . IIIIIIH IIIlIM IIIHIIm IIIIIIII!1 3 2 1

Illlllllllllill tliillillllill llllllllllllil IlIIIIIIIHIi~

E N T E R BS E~: It11111 IIIIIIIIIIIII i lUlllllllnl

Workers' Names/ID's

C ~ I ~ Lamb

l illilllllllllllllinMIIIIIlilllllllllllill IIl~liiiiil IIIII IIII Ill HII !1

kla I t er ~_Oouel I

i llllllllllllnlllllllllllHIIInlllllllllllll ~l~llll~li~ltllllllllllliltllill H~ry Norris

I IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIHI

Material Codes

~llt~i i,lili~lillillt e,_l,--adir~ s a i - ~ Cc~)

i tlill lili ill ill ill Uil Illl ~ i i U i [ l i l i l ~cl~ . . f i ! l i r ig s a n d

I IIIIIIIIIIlIIIIIIIIIIIlUlIIIII I IIIIIlllllliillilllllllllllll I I'lili'flil~'lillilllllll'~:ililllq " = ~ ' ~

CA Status

IIIIIIIIIIIII~IIIIHBIHIIIIIIIBIIIIII~I|

!!IIIIIIIIIIIIIIHIIIIIIH~IIIUHIIHIIIIIIIIIIIIIIIIIIII

Equipment Codes

Ib r o l let compactor

L illll111~lli~llllllllil]

~INilllNIIi~IlT'- truck-mounted crane

IMIIIIIIIIIlUlIIIIIIIIIII

FIG. 5. Bar-Coded Foreman Data Sheet

sages to be used by a foreman to mark the actual start and finish dates of each control account.

6. "Alpha-Numeric Pad," which contains bar-coded numbers ranging from "0" to "9," and bar-coded actions necessary for running the TM data- acquisition program. Actions such as the following are included: "Y" and "N" for yes and no, "BS" for backspace, "ENTER" for committing a data entry, and "ESC" for reentering a data value after it has been committed.

186

Additionally, two data fields are also shown in Fig. 5: foreman name and a bar-coded foreman ID, with a description of the craft type of the foreman printed on top of the bar code.

Data-Storage Module The data-storage module is represented as (and was developed as) a

relational data-base-management system (DBMS) that acts as a centralized repository of data (Abudayyeh and Rasdorf 1991). A centralized approach to the development of the data base is selected because it facilitates cost and schedule data integration and eliminates the problems related to main- taining integrity of a decentralized data-base approach. Moreover, creating a centralized data repository reduces the effort involved in data entry and can easily support a number of external, independent application programs for data processing.

The data-storage module has been developed using ORACLE's command language, called the structured query language (SQL). The prototype cen- tralized data-storage module in I(CS) 2 is composed of static, dynamic, and historical data bases (Abudayyeh and Rasdorf 1991). These data bases are called virtual data bases, meaning that their tables are conceptually ad- dressed as three separate groups, though physically they are one group (centralized). The three virtual data bases are shown in Fig. 6 and are briefly described as follows (Abudayyeh and Rasdorf 1991):

�9 The static data base includes 11 tables that deal with such data as budgets, definition of .the WBS and OBS, and activity network definition. The data maintained in this data base does not change with time, though sometimes updates may be necessary.

�9 The dynamic data base includes six tables that deal with the daily data acquired by field personnel on resource and time consumptions. The data included in this data base are acquired and stored on a daily basis, thus incrementally and dynamically increasing in size.

�9 The historical data base includes three tables that deal with storing historical records created from the daily accumulation of data and information about control accounts.

Data-Processing Module The data-processing module converts the data in the data base into useful

information that can be reported to management for their analysis and decision making. In this module, our focus is on demonstrating that the design and development of the previous two modules (data acquisition and data storage) successfully supply the necessary data for an effective data- processing and reporting outcome. This module essentially implements the data-processing methods and mechanisms of the work-packaging model. To implement these methods and mechanisms, two main approaches have been used. The first approach uses SQL's DDL and DML capabilities to create new tables that generate new information from existing tables, and the second approach uses external applications for processing data.

Data Processing Using Existing Tables Two types of tables exist in the data-base terminology: a base table, which

includes physically stored data values, and a view table, which is a virtual

187

FIG. 6. System Architecture

table that does not physically store values but, rather, retrieves existing data from base tables or derives new ones from existing data. A view is a necessary feature in a data-base language because it enables data to be processed by creating columns that are computed from others using formulas.

In our prototype, six views, each serving a specific data-processing pur-

188

pose, have been created to derive information from existing data. These views and their purposes are as follows:

�9 Daily-Man-Hours-Summary: Computes each control account's daily regular and overtime man-hours and costs.

�9 Daily-Man-Hours-Report: Computes BCWS, BCWP, ACWP, and % complete for every control account on a daily basis.

�9 Daily-Cost-Schedule-Status: Computes SPI and CPI for each control account on a daily basis.

�9 Percent-Complete-Summary: Computes a cumulative % complete value for each control account.

�9 Daily-Materials-Summary: Summarizes on a daily basis material use and costs for each control account.

�9 Daily-Equipment-Summary: Summarize on a daily basis equipment use and costs for each control account.

D a t a P r o c e s s i n g U s i n g E x t e r n a l A p p l i c a t i o n s The second approach utilizes external applications for processing data.

Two types of external applications exist in the current prototype imple- mentation: processing software, which includes commerical packages and in-house developed software; and interfaces, which includes programs that link the data base with other software packages. This second approach demonstrates that the information system described in this paper has been successfully integrated with existing commercial applications, adding more processing power to the system, and at the same time shows that other specific processing needs can be developed and integrated with the system using in-house development capabilities. In I(CS) 2, the C language and Pro*C were used to develop a number of external applications.

Currently, there are four software packages in the processing category and two interface programs in the interfaces category.

PLANTRAC is a commercial scheduling package that can handle activity networks using both the arrow and precedence notations. PLANTRAC in I(CS) 2 develops an initial planned schedule, and subsequently processes data acquired by the system to update the schedule to reflect current project status. The activity network for a project is assumed to be stored in PLAN- TRAC's format and not in the data base. The data base acts as a repository of the data items related to scheduling, in particular, man-hours and actual start and end dates of each control account. Then, an interface extracts this data and other derived values, converts them to PLANTRAC's format, and writes them to a file that can be used by PLANTRAC for schedule update, as shown in Fig. 6.

Historical Database Procedure is a program developed in-house used for searching the data base for completed control accounts to summarize them into permanent historical records stored in the historical data base. Sum- marization includes computing total resource quantities and costs for each completed control account. A constraint is added to the procedure that eliminates control accounts that have been processed before by this pro- cedure from consideration in a second invocation. This constraint is nec- essary for ensuring data-base integrity, meaning no duplicate records in the historical data base. The procedure is shown in Fig. 6.

UDIRL is a utility software provided with the bar-coding data-acquisition system. Its purpose is to upload the data files created by the data-acquisition

189

program on the TM to the computer workstation. UDIRL creates ASCII data files on the workstation.

PCLM is a commerical package used for developing bar-code labels. The package supports a range of bar coding symbologies to fit different users' needs. Bar codes are created and edited on a computer workstation and then printed on a printer.

The first of the aforementioned two interface programs is ORACLE/BC, an interface that reads the four ASCII data files uploaded by UDIRL. The structures of the ASCII data files are shown in Figs. 1-4. The interface opens a data file, identifies the type of data included in the file by analyzing the file's code, and populates the appropriate dynamic data-base tables. This process is shown in Fig. 6. The second interface program is ORACLE/ PLANTRAC, which extracts the data needed for updating a schedule. The interface has two components: The first component deals with partially completed control accounts and records a % complete for each account in this category. The second component deals with completed control accounts and records an actual finish data for each account in this category. The output of this interface is a file that contains PLANTRAC commands for updating the schedule. The update process is shown in Fig. 6.

Reporting Reports are the output of I(CS) 2 and can be generated by querying both

base tables and views. They are developed using SQL*ReportWriter and printed in tabular format. This component of I(CS) 2 demonstrates that the system is capable of producing the key elements of an integrated cost and schedule reporting system. A key contribution of this portion of the work is that we have developed a data-acquisition and storage model that is able to produce in a timely fashion all the elements needed by the standard reporting system of the work-packaging model.

The prototype I(CS) 2 implementation includes eight reports, but these reports are by no means the only ones that may be produced. They do, however, demonstrate the ability of the system to satisfy a variety of re- porting needs. The reports included by this system are as follows.

The "Daily Man-Hours Report" provides information on regular and overtime man-hours and their costs, and budgeted man-hours and their costs for each account.

The "Cumulative Man-Hours Report" provides cumulative information on regular and overtime man-hours and their costs, and budgeted man- hours and costs for each account.

The "Daily Materials Report" provides information on daily material quantities and their costs, and budgeted material quantities and costs for each account.

The "Cumulative Materials Report" provides information on cumulative material quantities and their costs, and budgeted material quantities and costs for each account.

The "Daily Equipment Report" provides information on equipment hours and their costs, and budged equipment hours and costs for each account.

The "Cumulative Equipment Report" provides cumulative information on equipment hours and their costs, and budgeted equipment hours and costs for each account.

The "Daily Cost/Schedule Status Report" provides information on the daily cost and schedule status (CPI and SPI) of each control account.

190

The "Cumulative Cost/Schedule Status Report" provides information on cumulative cost and schedule status (CPI and SPI) of each control account.

User-Interface Component The user-interface is an important component of the I(CS) 2 environment.

To establish a high degree of friendliness, it was designed in menu format. Menus are organized in hierarchical (tree) fashion to as many levels as needed. The tree organization allows some form of modularity in the system, so new actions and/or applications can be easily incorporated into the system by adding a new node on the tree at the appropriate location. Currently, the tree is four levels deep. The role of the user interface is shown sche- matically in Fig. 6, the user interface is shown to have direct access to the static, dynamic, and historical data bases. Fig. 6 also shows that the user interface has direct access to the report generator and external applications integrated into the system. In fact, the user interface acts as a supervisory system that creates an integrated environment, and it provides the flexibility of expanding the system to accommodate other future components.

CASE STUDY

To test and evaluate I(CS) 2, an actual project scenario involving a ware- house for storing grocery and nonfood items was used (Barrie and Paulson 1984). Three major components of the project are a heavy-duty concrete- paved yard area, a ramp slab used as a loading dock, and a base slab constituting the warehouse's storage area covered with a special hardened topping. Included in the structure itself are double-T precast and prestressed walls, structural steel framing with metal deck, and a built-up roof.

Planning and Establishing Control Accounts The WBS for the warehouse project is shown in Fig. 7. It has the whole

project at level one. The second level breaks the project down into seven systems: site work, foundations, superstructure, building finish, mechanical, electrical, and fire protection. Further breakdown of some of these systems yields a maximum of five levels of detail at some branches in the hierarchy. Next, control accounts were established at all leaf nodes on the WBS for this project--except for those nodes at level two that were not broken down into further details, namely, building finish, mechanical, electrical, and fire- protection systems. Those four systems are assumed to be subcontracted and thus are not considered in this case study, because our research did not address subcontract management. Therefore, a total of 23 control accounts were selected for the planning and estimating processes, and subsequently for control.

The OBS for the warehouse project has three levels of detail, as shown in Fig. 8. The top level has a general superintendent managing the warehouse project. Directly reporting to him are a mechanical subcontractor, an elec- trical subcontractor, a building-finish subcontractor, a fire-protection sub- contractor, and a civil superintendent. Under the direct supervision of the civil superintendent are five foremen: general labor, concrete, rebar, car- penter, and structural steel. Each foreman is responsbile for a crew that carries out the construction tasks related to his or her speciality, and reports daily accomplishments by allocating the data to the appropriate control account assigned to the tasks being carried out. The following lists the individual foremen and their assigned control accounts.

191

10000 Warehouse Project

11000 12000 I 13000 14000

I I I I Sitework Foundations Superstructure BL~lding Finish

111~. .~200 112100 112200 1~300

Earthwork Fencing Formwork Rebar Concrete

11130

I Excavate &

Backfill

13100 13200

I Struotaral Concrete Structural Metal

11110 I 11120

I I Grading Filing

150O0 16O0O 17OOO

I I I Mechanical Electrical Fire

Protection

13300 13400

I I Precast Walls Rooting

St al RoofJoists Metal Prestressed Prestressed Built-up ?-.5cmRigicl &Bridging Deck (56cm+lOcm) (41cm+13cm) Roof Insullation

Yard Paving Base&Ramp Mbcellaneous Slabs

li111 I Formwork Rebar Concrete I Formwork Concrete

I 3121 113122 13123 13124

I Forrework ~ Concrete Topping

FIG. 7. WBS for Warehouse Project

11o

I Mechanical

Subcontractor

lOO GeneralSuperintendent

120 130 I 140 150

I I I I Electrical Civil Building Finish FireProtection

Subcontractor Superintendent Subcontractor Subcontractor I

131 132 ll,33 134 135

I I I I I General Labor Concrete Rebar Carpenter StructuraISteel

Foreman Foreman Foreman Foreman Foreman

FIG. 8. OBS for Warehouse Project

�9 General labor foreman: Responsible for fencing, grading, filling, excavating and backfilling, 56 cm + 4 cm (22 in. + 4 in.) precast/ prestressed walls, and 41 cm + 1 3 cm (16 in. + 5 in.) precast/ prestressed walls control accounts.

�9 Concrete foreman: Responsible for concrete for foundations, con-

192

crete for yard paving, concrete for base and ramp slabs, topping for base and ramp slabs, and miscellaneous concrete control accounts.

�9 Rebar foreman: Responsible for rebar for foundations and rebar for base and ramp slabs control accounts.

�9 Carpenter foreman: Responsible for formwork for foundations, formwork for yard paving, formwork for base and ramp slabs, mis- cellaneous formwork, and 2.5 cm (1 in.) rigid-insulation control accounts.

�9 Structural steel foreman: Responsible for structural steel, roof joists and bridging, metal deck, and built-up roof control accounts.

Estimating and Scheduling Once the control accounts are established, the estimation and scheduling

processes are initiated. An integrated approach to estimating resources is ~ used by utilizing an estimation sheet, shown in Fig. 9 (The Work 1988). In each sheet, the resources (materials, man-hours, equipment) for one control account are estimated. Then, a productivity value for the resource used is estimated in the productivity box. Finally, the duration of the account is computed based on the productivity value and the material quantity. Thus, cost and schedule data are recorded for each control account, demonstrating the integration of the two functions as early as the planning phase of a project.

Next, to develop a schedule, each control account is assumed to be an activity. The sequencing and relationship between these activities are es-

Task Code: I I I o Responsibility Code (OBS): 13 (

Construction Estimation Sheet

Account Code: I I I I o

M=*ef~ Code

21210

Des~p~on

Direct Crew Labor

Description: G-~d,~ for S i'/r .~,-t ~ ~or

I i ooo

31110

Material Unit Quantity UnitCost Tot=Cost

Cn9 15,,ooo 2 , 4 o 3(~ooo

Labor Quantity Cost/Hr Ho~ TotaJCost

:5 /o ,o= 12d/O 12p

Equipment EqUpme~ Nuniber Hour= Cost/Hr To(alCost

d,,'= d e, f O s, o= k~

Productivity Base Units for Productivity

C.. ,,'P~

Total Quantity (Base U nit)

4 8 5 ~,,,/d=y Duration

4 g 5 r

Cost Summary

Matedal: 3 ~ o ~ Labor: 1 2 /# .a~ Equipment: '~-/4 ~ "

FIG. 9. Integrated Estimation Sheet

193

tablished, as shown in Fig. 10. The network shown in Fig. 10 is then con- verted to PLANTAC format to create the schedule. The initial processing of the aforementioned network produces early start and finish dates, late start and finish dates, and floats for each activity. These values represent the initial planned schedule for this project and will be updated periodically to reflect actual experience as the project proceeds.

Running I(CS) 2 This section describes how I(CS): is used and focuses on the data-acqui-

sition program (remote electronic forms) residing on the TM, and the in- formation-management system residing on the computer workstation. Using this system, the project manager is responsible for the static data base and the execution of the system programs, as well as for the activity network. The information-management system is initiated by first loading ORACLE into the workstation's memory at the operating-system level, and then in- voking the user-interface component. The user interface then handles all other system operations.

Acquiring and Storing Static Data Static data are the outcome of the planning, estimating, and scheduling

phase of the project's life cycle. These data must now be stored in the system to be used for cost- and schedule-control purposes. To store these data in the system (the static data base), the on-line electronic forms are used. Each form is invoked by selecting a menu option from the menu tree of the user- interface component. Then, the data are entered on the form using the keyboard and/or the wedge reader combined with the FDSs.

Acquiring and Storing Dynamic Data Dynamic data acquisition is an ongoing daily process that is conducted

by the foremen using the TM and the FDSs. In this section, each foreman is assumed to have his own TM. To report accomplishments of a given day, the foreman executes the program residing on the TM. Once invoked, the program prompts the user for a password. The foreman scans the password bar-code label, which could be attached to his driver's license. Next, the

35

3 28 31 32 37 20

31 31

FIG. 10. Activity Network for Warehouse Project

194

program prompts the user for his or her ID, which is entered by scanning the foreman bar code provided in the FDS. The program then displays the current data and awaits the user's acceptance or rejection of the date. If the data are rejected, the user is prompted to enter the desired date. If accepted, the program prompts the user for a control-account code, which is entered by scanning the appropriate control-account code from the CA Codes group on the FDS. Then, the program displays a main menu that has six options.

1. "Worker": This option is an electronic form that allows a foreman to report workers' hours spent on control accounts. It creates a worker's data file, called A, on the TM. An example of the contents of file A for January 3, 1991 is shown in Fig. 1. Comments are added to this file to explain each data item stored in the file.

2. "Material": This option is an electronic form that allows a foreman to report materials used by control accounts. It creates a material's data file, called B, on the TM. An example of the contents of file B for January 3, 1991 is shown in Fig. 2. Comments are added to this file to explain each data item stored in the file.

3. "Equipment": This option is an electronic form that allows a foreman to report equipment hours used by control accounts. It creates an equipment data file, called C, on the TM. An example of the contents of file C for January 3, 1991 is shown in Fig. 3. Comments are added to this file to explain each data item stored in the file.

4. "Status": This option is an electronic form that allows a foreman to report the status of a control account. It creates a status data file, called D, on the TM called. An example of the contents of file D for January 3, 1991 is shown in Fig. 4. Comments are added to this file to explain each data item stored in the file.

5. "End Account/Exit": This option allows a foreman to end the current control account data entry to initiate data entry for another control account, or allows the foreman to exit the data-acquisition program.

6. "N-Day": This option allows the user to continue using the program for an extended period of time. Selecting this option places the user at the date prompt, where data entry for a new day may resume. The entire data- entry process just described from the date data entry is repeated.

Note how all data items acquired by this program are allocated to a specific control account, demonstrating the integration of cost and schedule control function at the data-acquisition stage, which is an important factor in achiev- ing true integration.

Upon exit from the TM's program, the user, e.g. a project manager, is expected to upload the four data files to the computer workstation by using UDIRL, and subsequently to populate the dynamic data base by using the ORACLE/BC interface program, procedures that are selected from the menu of the user interface.

Processing Data To update a PLANTRAC schedule, one must include the activities that

have started in a PLANTRAC command file. Two types of activities in this file may exist. The first type includes those activities that have started but are not completed. This type will have a % complete value, which is used

195

by PLANTRAC to estimate its finish date and an actual start date. The second type of activities includes those that have been completed. This type must have actual start and finish dates. These activities do not need a % complete value. To construct this command file, the ORACLE/PLAN- TRAC interface program is invoked, which prompts the user, e.g. a project manager, for an output file, searches the data base for all active control accounts and recently completed ones, and constructs the output command file. Next, the user should invoke PLANTRAC, load the command file, and run it to update the schedule.

The second external application is the historical data-base generation procedure, which is invoked periodically to create the historical records for the completed control accounts.

Reporting Once processing is completed, reports can be produced. One report,

produced by PLANTRAC, is shown in Fig. 11, which is the updated sched- ule after 81 working days. Note in the Fig. 11 how the 11110, 11120, 13121, 11130, and 13111 control accounts are shown as completed. Three other sample reports are as follows.

The "Cumulative Man-Hours" and "Materials" reports option produces cumulative reports on man-hours and materials used by the active control accounts up to a user-specified date. The actual cumulative regular and overtime man-hours spent and material quantities used (and their costs) are displayed for each active control account in tabular format. Additionally, the budgeted man-hours and material quantities and their costs for each active control account, along with the craft type involved, are displayed in a separate table in the report.

The "Cumulative Cost/Schedule Status Report" option produces a cu- mulative report on cost and schedule status of each active control account up to a user-specified date. A sample report is shown in Fig. 12, in which BCWS, BCWP, ACWP, CPI, and SPI are combined and reported for each active control account on a cumulative basis. The report also displays the

NC STATE UNIVERSITY - EVALUATION ================================

PLANTRAC (c) TIME NOW = 25 APR 91 NETWORK = WRHS SELECTION 2 SEQUENCE 4 VERSION 1 PAGE NO. 1

T ACT. DESCRIPTION DURA- EARLIEST EARLIEST LATEST LATEST TOTAL Y NO. TION START FINISH START FINISH FLOAT

(D) (D)

S l0 Code iiii0 31.0 COMPLETED ON 2/14/91 20 Code 11120 31.0 COMPLETED ON 4/ 1/91 30 Code 13121 3.0 COMPLETED ON 4/ 4/91 40 Code 11130 9.0 COMPLETED ON 4/12/91 70 Code 13122 28.0 4/ 5/91 5/14/91 4/26/91 5/14/91 0.0

I00 Code 13111 2.0 COMPLETED ON 4/16/91 E 110 Code 11200 28.0 4/15/91 5/23/91 12/25/91 1/21/92 173.0

120 Code 12100 34.0 4/17/91 6/ 7/91 6/ 5/91 7/17/91 28.0 130 Code 13112 48.0 4/26/91 7/ 2/91 5/21/91 7/25/91 17.0 80 code 13123 31.0 5/15/91 6/26/91 5/15/91 6/26/91 0.0

140 Code 13131 5.0 6/10/91 6/14/91 1/13/92 1/17/92 155.0 150 Code 12200 6.0 6/10/91 6/17/91 7/18/91 7/25/91 28.0 90 Code 13124 32.0 6/27/91 8/ 9/91 6/27/91 8/ 9/91 0.0

170 Code 12300 ll.0 7/ 3/91 7/17/91 7/26/91 8/ 9/91 17.0 E 180 code 13132 2.0 7/18/91 7/19/91 1/20/92 1/21/92 132.0

190 Code 13210 37.0 8/12/91 i0/ 1/91 8/12/91 i0/ 1/91 0.0 210 Code 13310 45.0 10/ 2/91 12/ 3/91 10/16/91 12/17/91 10.0 200 Code 13220 20.0 10/ 2/91 10/29/91 I0/ 2/91 10/29/91 0.0 220 code 13410 35.0 10/30/91 12/17/91 10/30/91 12/17/91 0.0

E 230 Code 13230 22.0 10/30/91 11/28/91 12/23/91 1/21/92 38.0 E 240 Code 13320 25.0 12/ 4/91 i/ 7/92 12/18/91 1/21/92 I0.0 E 250 Code 13420 25.0 12/18/91 1/21/92 12/18/91 1/21/92 0.0

FIG. 11. PLANTRAC Schedule Update Report

196

Cumulative Cost/Schedule Status Report ======================================

Ending: 04/25/91

Control Actual Budget % Account Quant Quant ...........................

Iiii0 15000 15000 I00.00 11120 25000 25000 i00.00 11130 4400 5000 88.00 11200 1500 4680 32.05 12100 990 11300 8.76 13111 500 I000 50.00 13121 530 800 66.25 13122 74780 137800 54.27

BCWS BCWP ACWP CPI SPI Compl ..........................

1290.00 1240.00 1495.00 0.83 0.96 1240.00 1240.00 1335.00 0.93 1.00 320.00 316.80 320.00 0.99 0.99 360.00 358.97 360.00 1.00 1.00 120.00 119.15 24.00 4.96 0.99 40.00 40.00 40.00 1.00 1.00 80.00 79.50 80.00 0.99 0.99

600.00 607.79 600.00 1.01 1.01

Overall Project % Complete = 17.69

FIG. 12. Cumulative Cost/Schedule Status Report

cumulative actual and budgeted material quantities and % complete for each active or completed control account. Additionally, the report displays the overall project % complete, which is 17.69%.

SUMMARY, CONCLUSIONS, AND CONTRIBUTIONS

The integration of cost and schedule control functions and problems re- lating to the quality, integrity, and timeliness of data entering and flowing through cost- and schedule-control systems have long been of concern to construction researchers and professionals. This paper suggested that the work-packaging model is currently the well-integrated existing model that can solve these problems. However, to improve the performance of the work-packaging model, it was also suggested that automated mechanisms are needed. The paper focused on describing an automated, prototype in- formation-management system to support the work-packaging model and its bar-coding data-acquisition front end.

The practical applications of the research can be summarized as follows: (1) We have provided a paperless control system using automated data- acquisition (bar codes) and data-storage (data base) systems; and (2) we have integrated cost and schedule control into a single model.

This research provides several important contributions to the current body of knowledge. By introducing automation to the data-acquisition task, we have provided additional control over the quality and integrity of data by eliminating human errors in filling out paper forms and removing the chance of key-in errors by a computer data-entry operator. This is viewed as an important contribution because it provides a virtually error-free data-ac- quisition system.

Additionally, the system improves the timeliness of data access and use in many ways. First, we have eliminated the intermediary stages observed in a manual system by acquiring, uploading, and storing the data using a straightforward and error-free automated mechanism. Second, by integrat- ing cost- and schedule-control functions, each control account becomes a central depository for the data describing its tasks, thus improving the quality of the reports produced and eliminating the duplicate effort needed to acquire redundant data. Third, by providing an automated data-storage and processing mechanism, we have eliminated the need for summarizing and filling out new forms at the end of a day.

In summary, by combining the automation of the data acquisition and

197

data storage (BC and DBMS) with the integrated cost and schedule control concept represented by the work-packaging model, we have provided a good automated system that contributes to the solution of the problems described in the introduction section.

This work was sponsored by National Science Foundation. The support of this organization is gratefully acknowledged.

APPENDIX. REFERENCES

Abudayyeh, O. Y., and Rasdorf, W. J. (1990). "An assessment of cost and schedule control integration models." Tech. Rep. No. CE-90-10, North Carolina State Uni- versity, Raleigh, N.C.

Abudayyeh, O. Y., and Rasdorf, W. J. (1991). "Design of construction industry information management systems." J. Constr. Engrg. and Mgmt., ASCE, 117(4), 698-715.

Barrie, D. S., and Paulson, B. C. (1984). Professional construction management; McGraw-Hill series in construction engineering and project management. McGraw- Hill Book Co., Inc., New York, N.Y.

Hendrickson, C. T., and Au, T. (1989). Project management for construction: Fun- damental concepts for owners, engineers, architects, and builders. Prentice-Hall, Englewood Cliffs, N.J.

Ibbs, C. W., Ashley, D. B., Neil, J. M., and Feiler, F. W. (1987). "An implemen- tation strategy for improving project control systems." Project Controls: Needs and Solutions; Proc., of the Speciality Conf., ASCE, New York, N.Y., 101-112.

Project control for construction; publication 6-5. (1987). Construction Industry Insti- tute, University of Texas at Austin, Austin, Tex.

Rasdorf, W. J., and Abudayyeh, O. Y. (1991). "Cost- and schedule-control inte- gration: Issues and needs." J. Const. Engrg. and Mgmt., ASCE, 117(3), 486-502.

Rasdorf, W. J., and Abudayyeh, O. Y. (1992). "NIAM conceptual data-base design in construction management." J. Computing in Cir. Engrg., ASCE, 6(1), 41-62.

Rasdorf, W. J., and Herbert, M. J. (1990). "Bar coding in construction engineering." J. Constr. Engrg. and Mgmt., ASCE, 116(2), 261-280.

Riggs, L. S. (1987). "Project control techniques." Project controls: Needs and so- lutions; Proc., Speciality Conf., ASCE, New York, N.Y., 11-25.

Teicholz, P. M. (1987). "Current needs for cost control systems." Project controls: Needs and solutions; Proc., Speciality Conf., ASCE, New York, N.Y., 47-57.

The work packaging for project control; Publication 6-6 (1988). Construction Industry Institute, University of Texas at Austin, Austin, Tex.

198