434
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

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
436
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

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.

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

ITEM NO. EQ. NO. QTY DESCRIPTION UNIT PRICE
0609.02
0609.03
0188.21
0996.01
0607.03
0172.00
0181.53 4517
200
200
1
3
4
1
1
Hilti Pins NK27
Hilti Pins NK27

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.
440
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

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
441
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
442
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

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
443
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
ITEM_CODE
DESCRIPTION
WORK_UNIT

CREW_CODE
OUTPUT
TIME_UNIT
MATL_UNIT_COST
DATEMCOS
INSTCOST
DATEICOS
Item Code Number

No
No

Using Table 14-2, a typical unit cost entry for an activity in construction might be:
ITEM_CODE: 04.2-66-025
DESCRIPTION: common brick masonry, 12" thick wall, 19.0 bricks per S.F.
WORK_UNIT: 1000 bricks
CREW_CODE: 04.2-3
OUTPUT: 1.9
TIME_UNIT: Shift
MATL_UNIT_COST: 124
DATEMCOS: June-09-79
INSTCOST: 257
DATEICOS: August-23-79
This entry summarizes the unit costs associated with construction of 12" thick brick masonry walls, as
indicated by the item DESCRIPTION. The ITEM_CODE is a numerical code identifying a particular
activity. This code might identify general categories as well; in this case, 04.2 refers to general
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
444
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

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
445
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

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

-27,500
35,000

447
As an example, suppose that a bridge is to be built with a span of 250 feet, located in Pittsburgh PA,
and crossing a river with limestone sub-strata. In initial or preliminary planning, a designer might
query the database four separate times as follows:
• SELECT from BRIDGEWORK where SPAN > 200 and SPAN < 300 and where CROSSING
= "river"
• SELECT from BRIDGEWORK where SPAN > 200 and SPAN < 300 and where SITE
CONDITIONS = "Limestone"
• SELECT from BRIDGEWORK where TYPE OF BRIDGE = "Steel Plate Girder" and
LOCATION = "PA"
• SELECT from BRIDGEWORK where SPAN < 300 and SPAN > 200 and ESTIMATED LESS
ACTUAL COST < 100,000.
Each SELECT operation would yield the bridge examples in the database which corresponds to the
desired selection criteria. In practice, an input/output interpreter program should be available to
translate these inquiries to and from the DBM and an appropriate problem oriented language.
The four queries may represent subsequent thoughts of a designer faced with these problem conditions.
He or she may first ask, "What experience have we had with bridges of this span over rivers?" "What
experience have we had with bridges of this span with these site conditions? What is our experience
with steel girder bridges in Pennsylvania? For bridges of this span, how many and which were erected
without a sizable cost overrun? We could pose many more questions of this general type using only
the small data table shown in Table 14-4.
Back to top
14.6 Other Conceptual Models of Databases
While the relational model offers a considerable amount of flexibility and preserves considerable
efficiency, there are several alternative models for organizing databases, including network and
hierarchical models. The hierarchical model is a tree structure in which information is organized as
branches and nodes from a particular base. [8]

While the early, large databases were based on the hierarchical or network organizations, the relational
model is now preferred in many applications due to its flexibility and conceptual simplicity. Relational
databases form the kernel for large systems such as ORACLE or SAP. However, databases distributed
among numerous servers may have a network structure (as in Figure 14-3), with full relational
databases contained at one or more nodes. Similarly, "data warehouse" organizations may contain
several different types of databases and information files. For these data warehouses, more
complicated search approaches are essential, such as automatic indexing of multi-media files such as
photographs.
More recently, some new forms of organized databases have appeared, spurred in part by work in
artificial intelligence. For example, Figure 14-4 illustrates a frame data structure used to represent a
building design element. This frame describes the location, type, cost, material, scheduled work time,
etc. for a particular concrete footing. A frame is a general purpose data representation scheme in which
information is arranged in slots within a named frame. Slots may contain lists, values, text, procedural
statements (such as calculation rules), pointers or other entities. Frames can be inter-connected so that
information may be inherited between slots. Figure 14-5 illustrates a set of inter-connected frames
used to describe a building design and construction plan. [10] Object oriented data representation is
similar in that very flexible local arrangements of data are permitted. While these types of data storage
organizations are active areas of research, commercial database systems based on these organizations
are not yet available.
450
Figure 14-4 Illustration of Data Stored in a Frame

451
Figure 14-5 Illustration of a Frame Based Data Storage Hierarchy

• Some suppliers might not exist in the historical record.
• Finding the lowest cost supplier for particular pieces of equipment would be exceedingly
tedious since every record would have to be read to find the desired piece of equipment and the
cost.
• No direct way of abstracting the equipment codes and prices might exist.
An alternative arrangement might be to separately record equipment rental costs in (1) the Purchasing
Department Records, (2) the Cost Estimating Division, and (3) the Company warehouse. While these
multiple databases might each be designed for the individual use, they represent considerable
redundancy and could easily result in inconsistencies as prices change over time. With a central DBM,
desired views for each of these three users could be developed from a single database of equipment
costs.
A manager need not conclude from this discussion that initiating a formal database will be a panacea.
Life is never so simple. Installing and maintaining databases is a costly and time consuming endeavor.
A single database is particularly vulnerable to equipment failure. Moreover, a central database system
may be so expensive and cumbersome that it becomes ineffective; we will discuss some possibilities
for transferring information between databases in a later section. But lack of good information and
manual information management can also be expensive.
One might also contrast the operation of a formal, computerized database with that of a manual filing
system. For the equipment supplier example cited above, an experienced purchasing clerk might be
453
able to immediately find the lowest cost supplier of a particular piece of equipment. Making this
identification might well occur in spite of the formal organization of the records by supplier
organization. The experienced clerk will have his (or her) own subjective, conceptual model of the
available information. This subjective model can be remarkably powerful. Unfortunately, the mass of
information required, the continuing introduction of new employees, and the need for consistency on
large projects make such manual systems less effective and reliable.
Back to top

14.8 Databases and Applications Programs
The usefulness of a database organization is particularly evident in integrated design or management

• component specifications,
• construction detail specifications,
• electrical layout,
• system isometric drawings,
• bills of quantities and materials.
The advantage of an integrated system of this sort is that each program need only be designed to
communicate with a single database. Accomplishing appropriate transformations of data between each
pair of programs would be much more difficult. Moreover, as new applications are required, they can
be added into an integrated system without extensive modifications to existing programs. For example,
a library of specifications language or a program for joint design might be included in the design
system described above. Similarly, a construction planning and cost estimating system might also be
added.
The use of integrated systems with open access to a database is not common for construction activities
at the current time. Typically, commercial systems have a closed architecture with simple datafiles or a
"captive," inaccessible database management system. However, the benefits of an open architecture
with an accessible database are considerable as new programs and requirements become available over
time.
Example 14-5: An Integrated System Design
As an example, Figure 14-7 illustrates the computer aided engineering (CAE) system envisioned for
the knowledge and information-intensive construction industry of the future. [13] In this system,
comprehensive engineering and "business" databases support different functions throughout the life
time of a project. The construction phase itself includes overlapping design and construction functions.
During this construction phase, computer aided design (CAD) and computer aided manufacturing
(CAM) aids are available to the project manager. Databases recording the "as-built" geometry and
specifications of a facility as well as the subsequent history can be particularly useful during the use
455
and maintenance life cycle phase of the facility. As changes or repairs are needed, plans for the facility
can be accessed from the database.
While a single database may be undesirable, it is also apparent that it is desirable to structure
independent application systems or databases so that measurement information need only be manually
recorded once and communication between the database might exist. Consider the following examples
illustrating the desirability of communication between independent application systems or databases.
While some progress has occurred, the level of integration and existing mechanisms for information
flow in project management is fairly primitive. By and large, information flow relies primarily on
talking, written texts of reports and specifications and drawings.
Example 14-6: Time Cards
Time card information of labor is used to determine the amount which employees are to be paid and to
provide records of work performed by activity. In many firms, the system of payroll accounts and the
database of project management accounts (i.e., expenditure by activity) are maintained independently.
As a result, the information available from time cards is often recorded twice in mutually incompatible
formats. This repetition increases costs and the possibility of transcription errors. The use of a
preprocessor system to check for errors and inconsistencies and to format the information from each
card for the various systems involved is likely to be a significant improvement (Figure 14-8).
Alternatively, a communications facility between two databases of payroll and project management
accounts might be developed.
457
Figure 14-8 Application of an Input Pre-processor

Example 14-7: Final Cost Estimation, Scheduling and Monitoring
Many firms maintain essentially independent systems for final cost estimation and project activity
scheduling and monitoring. As a result, the detailed breakdown of the project into specific job related
activities must be completely re-done for scheduling and monitoring. By providing a means of rolling-
over or transferring the final cost estimate, some of this expensive and time-consuming planning effort
could be avoided.
Example 14-8: Design Representation

7. Wilkinson, R.W., "Computerized Specifications on a Small Project," ASCE Journal of
Construction Engineering and Management, Vol. 110, No. CO3, 1984, PP. 337-345.
8. Latimer, Dewitt and Chris Hendrickson, “Digital Archival of Construction Project
Information,” Proceedings of the International Symposium on Automation and Robotics for
Construction, 2002."
Back to top
14.11 Problems
1. Suppose we wish to develop a database consisting of contractor names, addresses and
particular specialties as in Table 14-3.
o Suggest two hierarchical organizations of this data.
o Suggest an alternative relational organization for this data.
o Which organization would you recommend for implementation of a database?
2. Suggest four reports which could be obtained from the warehouse inventory system described
in Section 14.3 and describe what each report might be used for and by whom.
3. Suppose that a general contractor wished to keep a historical database of the results of bid
competitions. Suggest (a) the information that might be stored, and (b) a possible organization
of this information.
4. For your suggested database from Problem 3, implement a prototype system on a spreadsheet
software program.
5. Describe a relational database that would be useful in storing the beginning, ending and all
intermediate stages for blockworld robot movements as described in Problem 6 in Chapter 9.