Tài liệu Project Management for Construction Chapter 14 doc

A listing of the most important information sets would include: • cash flow and procurement accounts for each organization, • intermediate analysis results during planning and design,

14 Organization and Use of Project

Information

14.1 Types of Project Information

Construction projects inevitably generate enormous and complex sets of information Effectively managing this bulk of information to insure its availability and accuracy is an important managerial task Poor or missing information can readily lead to project delays, uneconomical decisions, or even the complete failure of the desired facility Pity the owner and project manager who suddenly discover

on the expected delivery date that important facility components have not yet been fabricated and cannot be delivered for six months! With better information, the problem could have been identified earlier, so that alternative suppliers might have been located or schedules arranged Both project design and control are crucially dependent upon accurate and timely information, as well as the ability

to use this information effectively At the same time, too much unorganized information presented to managers can result in confusion and paralysis of decision making

As a project proceeds, the types and extent of the information used by the various organizations

involved will change A listing of the most important information sets would include:

• cash flow and procurement accounts for each organization,

• intermediate analysis results during planning and design,

• design documents, including drawings and specifications,

• construction schedules and cost estimates,

• quality control and assurance records,

• chronological files of project correspondence and memorandum,

• construction field activity and inspection logs,

• legal contracts and regulatory documents

Some of these sets of information evolve as the project proceeds The financial accounts of payments over the entire course of the project is an example of overall growth The passage of time results in steady additions in these accounts, whereas the addition of a new actor such as a contractor leads to a sudden jump in the number of accounts Some information sets are important at one stage of the

process but may then be ignored Common examples include planning or structural analysis databases which are not ordinarily used during construction or operation However, it may be necessary at later stages in the project to re-do analyses to consider desired changes In this case, archival information storage and retrieval become important Even after the completion of construction, an historical record may be important for use during operation, to assess responsibilities in case of facility failures or for planning similar projects elsewhere

The control and flow of information is also important for collaborative work environments, where many professionals are working on different aspects of a project and sharing information

Collaborative work environments provide facilities for sharing datafiles, tracing decisions, and

communication via electronic mail or video conferencing The datastores in these collaborative work environments may become very large

Based on several construction projects, Maged Abdelsayed of Tardif, Murray & Assoc (Quebec, Canada) estimated the following average figures for a typical project of US$10 million:

• Number of participants (companies): 420 (including all suppliers and sub-sub-contractors)

• Number of participants (individuals): 850

• Number of different types of documents generated: 50

• Number of pages of documents: 56,000

• Number of bankers boxes to hold project documents: 25

• Number of 4 drawers filing cabinets: 6

• Number of 20inch diameter, 20 year old, 50 feet high, trees used to generate this volume of paper: 6

• Equivalent number of Mega Bytes of electronic data to hold this volume of paper (scanned): 3,000 MB

• Equivalent number of compact discs (CDs): 6

While there may be substantial costs due to inaccurate or missing information, there are also

significant costs associated with the generation, storage, transfer, retrieval and other manipulation of information In addition to the costs of clerical work and providing aids such as computers, the

organization and review of information command an inordinate amount of the attention of project managers, which may be the scarcest resource on any construction project It is useful, therefore, to understand the scope and alternatives for organizing project information

Back to top

14.2 Accuracy and Use of Information

Numerous sources of error are expected for project information While numerical values are often reported to the nearest cent or values of equivalent precision, it is rare that the actual values are so accurately known Living with some uncertainty is an inescapable situation, and a prudent manager should have an understanding of the uncertainty in different types of information and the possibility of drawing misleading conclusions

We have already discussed the uncertainty inherent in making forecasts of project costs and durations sometime in the future Forecast uncertainty also exists in the short term For example, consider

estimates of work completed Every project manager is familiar with situations in which the final few bits of work for a task take an inordinate amount of time Unforeseen problems, inadequate quality on already completed work, lack of attention, accidents, or postponing the most difficult work problems

to the end can all contribute to making the final portion of an activity actually require far more time and effort than expected The net result is that estimates of the actual proportion of work completed are often inaccurate

Some inaccuracy in reports and estimates can arise from conscious choices made by workers, foremen

or managers If the value of insuring accuracy is thought to be low or nonexistent, then a rational worker will not expend effort or time to gather or to report information accurately Many project scheduling systems flounder on exactly this type of non-reporting or mis-reporting The original

schedule can quickly become extremely misleading without accurate updating! Only if all parties concerned have specific mandates or incentives to report accurately will the data be reliable

Another source of inaccuracy comes from transcription errors of various sorts Typographical errors, incorrect measurements from reading equipment, or other recording and calculation errors may creep into the sets of information which are used in project management Despite intensive efforts to check and eliminate such errors, their complete eradication is virtually impossible

One method of indicating the relative accuracy of numerical data is to report ranges or expected

deviations of an estimate or measurement For example, a measurement might be reported as 198 ft +

2 ft There are two common interpretations of these deviations First, a range (such as + 2) might be

chosen so that the actual value is certain to be within the indicated range In the case above, the actual

length would be somewhere between 196 and 200 feet with this convention Alternatively, this

deviation might indicate the typical range of the estimate or measurement In this case, the example

above might imply that there is, say, a two-thirds chance that the actual length is between 196 and 200 When the absolute range of a quantity is very large or unknown, the use of a statistical standard

deviation as a measure of uncertainty may be useful If a quantity is measured n times resulting is a set

of values xi (i = 1,2, ,n), then the average or mean value then the average or mean value is given by:

greater uncertainty about the exact value of the measurement For the commonly encountered normal

distribution of a random variable, the average value plus or minus one standard deviation, + , will include about two-thirds ofx the actual occurrences A related measure of random variability is the coefficient of variation, defined as the ratio of the standard deviation to the mean:

(14.3)

Thus, a coefficient of variation indicates the variability as a proportion of the expected value A

coefficient of variation equal to one (c = 1) represents substantial uncertainty, whereas a value such as

c = 0.1 or ten percent indicates much smaller variability

More generally, even information which is gathered and reported correctly may be interpreted

incorrectly While the actual information might be correct within the terms of the data gathering and recording system, it may be quite misleading for managerial purposes A few examples can illustrate the problems which may arise in naively interpreting recorded information without involving any conceptual understanding of how the information is actually gathered, stored and recorded or how work on the project actually proceeds

Example 14-1: Sources of Delay and Cost Accounts

It is common in construction activity information to make detailed records of costs incurred and work progress It is less common to keep detailed records of delays and their causes, even though these delays may be the actual cause of increased costs and lower productivity [1] Paying exclusive

attention to cost accounts in such situations may be misleading For example, suppose that the

accounts for equipment and material inventories show cost savings relative to original estimates, whereas the costs associated with particular construction activities show higher than estimated

expenditures In this situation, it is not necessarily the case that the inventory function is performing well, whereas the field workers are the cause of cost overrun problems It may be that construction activities are delayed by lack of equipment or materials, thus causing cost increases Keeping a larger inventory of materials and equipment might increase the inventory account totals, but lead to lower overall costs on the project Better yet, more closely matching demands and supplies might reduce delay costs without concurrent inventory cost increases Thus, simply examining cost account

information may not lead to a correct diagnosis of a problem or to the correct managerial responses

Example 14-2: Interest Charges

Financial or interest charges are usually accumulated in a separate account for projects, while the accounts associated with particular activities represent actual expenditures For example, planning activities might cost $10,000 for a small project during the first year of a two year project Since dollar

expenditures have a time value, this $10,000 cost in year 1 is not equivalent in value to a $10,000 cost

in year 2 In particular, financing the early $10,000 involves payment of interest or, similarly, the loss

of investment opportunities If the borrowing rate was 10%, then financing the first year $10,000 expenditure would require $10,000 x 0.10 = $1,000 and the value of the expenditure by the end of the second year of the project would be $11,000 Thus, some portion of the overall interest charges

represents a cost associated with planning activities Recognizing the true value of expenditures made

at different periods of time is an important element in devising rational planning and management strategies

Back to top

14.3 Computerized Organization and Use of Information

Numerous formal methods and possible organizations exist for the information required for project management Before discussing the details of computations and information representation, it will be

useful to describe a record keeping implementation, including some of the practical concerns in design and implementation In this section, we shall describe a computer based system to provide

construction yard and warehouse management information from the point of view of the system users [2] In the process, the usefulness of computerized databases can be illustrated

A yard or warehouse is used by most construction firms to store equipment and to provide an

inventory of materials and parts needed for projects Large firms may have several warehouses at different locations so as to reduce transit time between project sites and materials supplies In addition, local "yards" or "equipment sheds" are commonly provided on the job site Examples of equipment in

a yard would be drills, saws, office trailers, graders, back hoes, concrete pumps and cranes Material items might include nails, plywood, wire mesh, forming lumber, etc

In typical construction warehouses, written records are kept by warehouse clerks to record transfer or return of equipment to job sites, dispatch of material to jobs, and maintenance histories of particular pieces of equipment In turn, these records are used as the basis for billing projects for the use of equipment and materials For example, a daily charge would be made to a project for using a concrete pump During the course of a month, the concrete pump might spend several days at different job sites,

so each project would be charged for its use The record keeping system is also used to monitor

materials and equipment movements between sites so that equipment can be located

One common mechanism to organize record keeping is to fill out cards recording the transfer of items

to or from a job site Table 14-1 illustrates one possible transfer record In this case, seven items were requested for the Carnegie-Mellon job site (project number 83-1557) These seven items would be loaded on a delivery truck, along with a copy of the transfer record Shown in Table 14-1 is a code number identifying each item (0609.02, 0609.03, etc.), the quantity of each item requested, an item description and a unit price For equipment items, an equipment number identifying the individual piece of equipment used is also recorded, such as grinder No 4517 in Table 14-1; a unit price is not specified for equipment but a daily rental charge might be imposed

TABLE 14-1 Illustration of a Construction Warehouse Transfer Record

TRANSFER SHEET NUMBER 100311 Deliver To: Carnegie-Mellon

Received From: Pittsburgh Warehouse

Job No 83-1557 Job No 99-PITT

0609.02 0609.03 0188.21 0996.01 0607.03 0172.00 0181.53

4517

20020013411

Hilti Pins NK27 Hilti Pins NK27 Kiel, Box of 12 Paint, Spray Plywood, 4 x 8 x 1/4"

Grinder Grinding Wheel, 6" Cup

$0.360.366.535.5711.6214.97

Transfer sheets are numbered (such as No 100311 in Table 14-1), dated and the preparer identified to facilitate control of the record keeping process During the course of a month, numerous transfer

records of this type are accumulated At the end of a month, each of the transfer records is examined to compile the various items or equipment used at a project and the appropriate charges Constructing these bills would be a tedious manual task Equipment movements would have to be tracked

individually, days at each site counted, and the daily charge accumulated for each project For example, Table 14-1 records the transfer of grinder No 4517 to a job site This project would be charged a daily rental rate until the grinder was returned Hundreds or thousands of individual item transfers would have to be examined, and the process of preparing bills could easily require a week or two of effort

In addition to generating billing information, a variety of reports would be useful in the process of managing a company's equipment and individual projects Records of the history of use of particular pieces of equipment are useful for planning maintenance and deciding on the sale or scrapping of equipment Reports on the cumulative amount of materials and equipment delivered to a job site

would be of obvious benefit to project managers Composite reports on the amount, location, and use

of pieces of equipment of particular types are also useful in making decisions about the purchase of new equipment, inventory control, or for project planning Unfortunately, producing each of these reports requires manually sifting through a large number of transfer cards Alternatively, record

keeping for these specific projects could have to proceed by keeping multiple records of the same information For example, equipment transfers might be recorded on (1) a file for a particular piece of equipment and (2) a file for a particular project, in addition to the basic transfer form illustrated in Table 14-1 Even with these redundant records, producing the various desired reports would be time consuming

Organizing this inventory information in a computer program is a practical and desirable innovation

In addition to speeding up billing (and thereby reducing borrowing costs), application programs can

readily provide various reports or views of the basic inventory information described above

Information can be entered directly to the computer program as needed For example, the transfer record shown in Table 14-1 is based upon an input screen to a computer program which, in turn, had been designed to duplicate the manual form used prior to computerization Use of the computer also allows some interactive aids in preparing the transfer form This type of aid follows a simple rule:

"Don't make the user provide information that the system already knows." [3] In using the form shown

in Table 14-1, a clerk need only enter the code and quantity for an item; the verbal description and unit cost of the item then appear automatically A copy of the transfer form can be printed locally, while the data is stored in the computer for subsequent processing As a result, preparing transfer forms and record keeping are rapidly and effectively performed

More dramatically, the computerized information allows warehouse personnel both to ask questions about equipment management and to readily generate the requisite data for answering such questions The records of transfers can be readily processed by computer programs to develop bills and other reports For example, proposals to purchase new pieces of equipment can be rapidly and critically reviewed after summarizing the actual usage of existing equipment Ultimately, good organization of information will typically lead to the desire to store new types of data and to provide new views of this information as standard managerial tools

Of course, implementing an information system such as the warehouse inventory database requires considerable care to insure that the resulting program is capable of accomplishing the desired task In the warehouse inventory system, a variety of details are required to make the computerized system an acceptable alternative to a long standing manual record keeping procedure Coping with these details makes a big difference in the system's usefulness For example, changes to the status of equipment are generally made by recording transfers as illustrated in Table 14-1 However, a few status changes are not accomplished by physical movement One example is a charge for air conditioning in field trailers: even though the air conditioners may be left in the field, the construction project should not be charged for the air conditioner after it has been turned off during the cold weather months A special status change report may be required for such details Other details of record keeping require similar special controls

Even with a capable program, simplicity of design for users is a critical factor affecting the successful implementation of a system In the warehouse inventory system described above, input forms and initial reports were designed to duplicate the existing manual, paper-based records As a result,

warehouse clerks could readily understand what information was required and its ultimate use A good rule to follow is the Principle of Least Astonishment: make communications with users as consistent and predictable as possible in designing programs

Finally, flexibility of systems for changes is an important design and implementation concern New reports or views of the data is a common requirement as the system is used For example, the

introduction of a new accounting system would require changes in the communications procedure from the warehouse inventory system to record changes and other cost items

In sum, computerizing the warehouse inventory system could save considerable labor, speed up billing, and facilitate better management control Against these advantages must be placed the cost of

introducing computer hardware and software in the warehouse

Back to top

14.4 Organizing Information in Databases

Given the bulk of information associated with construction projects, formal organization of the

information is essential so as to avoid chaos Virtually all major firms in the arena of project

management have computer based organization of cost accounts and other data With the advent of micro-computer database managers, it is possible to develop formal, computerized databases for even small organizations and projects In this section, we will discuss the characteristics of such formal

databases Equivalent organization of information for manual manipulation is possible but tedious

Computer based information systems also have the significant advantage of rapid retrieval for

immediate use and, in most instances, lower overall costs For example, computerized specifications writing systems have resulted in well documented savings These systems have records of common specification phrases or paragraphs which can be tailored to specific project applications [4]

Formally, a database is a collection of stored operational information used by the management and application systems of some particular enterprise [5] This stored information has explicit associations

or relationships depending upon the content and definition of the stored data, and these associations

may themselves be considered to be part of the database Figure 14-1 illustrates some of the typical

elements of a database The internal model is the actual location and representation of the stored data

At some level of detail, it consists of the strings of "bits" which are stored in a computer's memory, on the tracks of a recording disk, on a tape, or on some other storage device

Figure 14-1 Illustration of a Database Management System Architecture

A manager need not be concerned with the details of data storage since this internal representation and

manipulation is regulated by the Database Manager Program (DBM) The DBM is the software

program that directs the storage, maintenance, manipulation and retrieval of data Users retrieve or store data by issuing specific requests to the DBM The objective of introducing a DBM is to free the user from the detail of exactly how data are stored and manipulated At the same time, many different users with a wide variety of needs can use the same database by calling on the DBM Usually the DBM will be available to a user by means of a special query language For example, a manager might ask a DBM to report on all project tasks which are scheduled to be underway on a particular date The desirable properties of a DBM include the ability to provide the user with ready access to the stored

data and to maintain the integrity and security of the data Numerous commercial DBM exist which provide these capabilities and can be readily adopted to project management applications

While the actual storage of the information in a database will depend upon the particular machine and

storage media employed, a Conceptual Data Model exists which provides the user with an idea or

abstract representation of the data organization (More formally, the overall configuration of the

information in the database is called the conceptual schema.) For example, a piece of data might be viewed as a particular value within a record of a datafile In this conceptual model, a datafile for an

application system consists of a series of records with pre-defined variables within each record A record is simply a sequence of variable values, which may be text characters or numerals This datafile model is one of the earliest and most important data organization structures But other views of data organization exist and can be exceedingly useful The next section describes one such general model, called the relational model

Continuing with the elements in Figure 14-1, the data dictionary contains the definitions of the

information in the database In some systems, data dictionaries are limited to descriptions of the items

in the database More general systems employ the data dictionary as the information source for

anything dealing with the database systems It documents the design of the database: what data are stored, how the data is related, what are the allowable values for data items, etc The data dictionary may also contain user authorizations specifying who may have access to particular pieces of

information Another important element of the data dictionary is a specification of allowable ranges for pieces of data; by prohibiting the input of erroneous data, the accuracy of the database improves

External models are the means by which the users view the database Of all the information in the

database, one particular user's view may be just a subset of the total A particular view may also

require specific translation or manipulation of the information in the database For example, the

external model for a paycheck writing program might consist solely of a list of employee names and

salary totals, even if the underlying database would include employee hours and hourly pay rates As far as that program is concerned, no other data exists in the database The DBM provides a means of

translating particular external models or views into the overall data model Different users can view the

data in quite distinct fashions, yet the data itself can be centrally stored and need not be copied

separately for each user External models provide the format by which any specific information needed

is retrieved Database "users" can be human operators or other application programs such as the

paycheck writing program mentioned above

Finally, the Database Administrator is an individual or group charged with the maintenance and

design of the database, including approving access to the stored information The assignment of the database administrator should not be taken lightly Especially in large organizations with many users, the database administrator is vital to the success of the database system For small projects, the

database administrator might be an assistant project manager or even the project manager

Back to top

14.5 Relational Model of Databases

As an example of how data can be organized conceptually, we shall describe the relational data model

In this conceptual model, the data in the database is viewed as being organized into a series of

relations or tables of data which are associated in ways defined in the data dictionary A relation

consists of rows of data with columns containing particular attributes The term "relational" derives from the mathematical theory of relations which provides a theoretical framework for this type of data model Here, the terms "relation" and data "table" will be used interchangeably Table 14-2 defines one possible relation to record unit cost data associated with particular activities Included in the

database would be one row (or tuple) for each of the various items involved in construction or other

project activities The unit cost information associated with each item is then stored in the form of the relation defined in Table 14-2

TABLE 14-2 Illustration of a Relation Description: Unit Price Information Attributes

Attribute Name Attribute Description Attribute Type Key

Date of MATL_UNIT_COST Installation Unit Cost

Date of INSTCOST

Pre-defined Code Text

Text (restricted to allowable units)Pre-defined Code

Numerical Text Numerical Date Text Numerical Date Text

YesNoNoNoNoNoNoNoNoNo

Using Table 14-2, a typical unit cost entry for an activity in construction might be:

masonry work ITEM_CODE might be based on the MASTERFORMAT or other coding scheme The CREW_CODE entry identifies the standard crew which would be involved in the activity The actual composition of the standard crew would be found in a CREW RELATION under the entry 04.2-3,

which is the third standard crew involved in masonry work (04.2) This ability to point to other

relations reduces the redundancy or duplication of information in the database In this case, standard

crew number 04.2-3 might be used for numerous masonry construction tasks, but the definition of this crew need only appear once

WORK_UNIT, OUTPUT and TIME_UNIT summarize the expected output for this task with a

standard crew and define the standard unit of measurement for the item In this case, costs are given per thousand bricks per shift Finally, material (MATL_UNIT_COST) and installation (INSTCOSTS) costs are recorded along with the date (DATEMCOS and DATEICOS) at which the prices were

available and entered in the database The date of entry is useful to insure that any inflation in costs can be considered during use of the data

The data recorded in each row could be obtained by survey during bid preparations, from past project experience or from commercial services For example, the data recorded in the Table 14-2 relation could be obtained as nationwide averages from commercial sources

An advantage of the relational database model is that the number of attributes and rows in each

relation can be expanded as desired For example, a manager might wish to divide material costs (MATL_UNIT_COST) into attributes for specific materials such as cement, aggregate and other ingredients of concrete in the unit cost relation defined in Table 14-2 As additional items are defined

or needed, their associated data can be entered in the database as another row (or tuple) in the unit cost relation Also, new relations can be defined as the need arises Hence, the relational model of database organization can be quite flexible in application In practice, this is a crucial advantage Application systems can be expected to change radically over time, and a flexible system is highly desirable With a relational database, it is straightforward to issue queries for particular data items or to combine data from different relations For example, a manager might wish to produce a report of the crew composition needed on a site to accomplish a given list of tasks Assembling this report would require accessing the unit price information to find the standard crew and then combining information about the construction activity or item (eg quantity desired) with crew information However, to effectively accomplish this type of manipulation requires the definition of a "key" in each relation

In Table 14-2, the ITEMCODE provides a unique identifier or key for each row No other row should have the same ITEMCODE in any one relation Having a unique key reduces the redundancy of data,

since only one row is included in the database for each activity It also avoids error For example, suppose one queried the database to find the material cost entered on a particular date This response might be misleading since more than one material cost could have been entered on the same date Similarly, if there are multiple rows with the same ITEMCODE value, then a query might give

erroneous responses if one of the rows was out of date Finally, each row has only a single entry for each attribute [6]

The ability to combine or separate relations into new arrangements permits the definition of alternative

views or external models of the information Since there are usually a number of different users of

databases, this can be very useful For example, the payroll division of an organization would

normally desire a quite different organization of information about employees than would a project manager By explicitly defining the type and organization of information a particular user group or application requires, a specific view or subset of the entire database can be constructed This

organization is illustrated in Fig 14-1 with the DATA DICTIONARY serving as a translator between the external data models and the database management system

Behind the operations associated with querying and manipulating relations is an explicit algebraic theory This algebra defines the various operations that can be performed on relations, such as union (consisting of all rows belonging to one or the other of two relations), intersection (consisting of all rows belonging to both of two relations), minus (consisting of all rows belonging to one relation and not another), or projection (consisting of a subset of the attributes from a relation) The algebraic underpinnings of relational databases permits rigorous definitions and confidence that operations will

be accomplished in the desired fashion [7]

Example 14-3: A Subcontractor Relation

As an illustration of the preceding discussion, consider the problem of developing a database of

possible subcontractors for construction projects This database might be desired by the cost

estimation department of a general contractor to identify subcontractors to ask to bid on parts of a project Appropriate subcontractors appearing in the database could be contacted to prepare bids for specific projects Table 14-3 lists the various attributes which might be required for such a list and an example entry, including the subcontractor's name, contact person, address, size (large, medium or small), and capabilities

TABLE 14-3 Subcontractor Relation Example

Attribute Example NAME

CONTACT PHONE STREET CITY STATE ZIPCODE SIZE CONCRETE ELECTRICAL MASONRY etc

XYZ Electrical Co

Betty XYZ (412) xxx-xxxx xxx Mulberry St

Pittsburgh

PA 152xx large

no yes

no

To use this relation, a cost estimator might be interested in identifying large, electrical subcontractors

in the database A query typed into the DBM such as:

SELECT from SUBCONTRACTORS

where SIZE = Large and ELECTRICAL = Yes

would result in the selection of all large subcontractors performing electrical work in the

subcontractor's relation More specifically, the estimator might want to find subcontractors in a

particular state:

SELECT from SUBCONTRACTORS

where SIZE = Large and ELECTRICAL = Yes and STATE = VI

In addition to providing a list of the desired subcontractors' names and addresses, a utility application program could also be written which would print mailing labels for the selected firms

Other portions of the general contracting firm might also wish to use this list For example, the

accounting department might use this relation to record the addresses of subcontractors for payment of invoices, thereby avoiding the necessity to maintain duplicate files In this case, the accounting code number associated with each subcontractor might be entered as an additional attribute in the relation, and the accounting department could find addresses directly

Example 14-4: Historical Bridge Work Relation

As another simple example of a data table, consider the relation shown in Table 14-0 which might record historical experience with different types of bridges accumulated by a particular agency The actual instances or rows of data in Table 14-4 are hypothetical The attributes of this relation are:

• PROJECT NUMBER - a 6-digit code identifying the particular project

• TYPE OF BRIDGE - a text field describing the bridge type (For retrieval purposes, a

numerical code might also be used to describe bridge type to avoid any differences in

terminology to describe similar bridges)

• LOCATION - The location of the project

• CROSSING - What the bridge crosses over, eg a river

• SITE CONDITIONS - A brief description of the site peculiarities

• ERECTION TIME - Time required to erect a bridge, in months

• SPAN - Span of the bridge in feet

• DATE - Year of bridge completion

• ACTUAL-ESTIMATED COSTS - Difference of actual from estimated costs

These attributes could be used to answer a variety of questions concerning construction experience useful during preliminary planning

TABLE 14-4 Example of Bridge Work Relation

Project

Number

Type of Bridge Location Crossing Site Conditions

Erection Time (Months)

Span (ft.)

Estimated less Actual Cost

RailroadRiver Highway

200' Valley Limestone 250' High Sandy Loam 135' Deep Pile Foundation