Home > Resources > Project Management for Construction
Folder Project Management
Mini Site Design Masters
Project Management

01) The Owners' Perspective

Page 02 of 02 Chapter 01

02) Organizing For Project Management

Page 02 of 02 Chapter 02

03) The Design And Construction Process

Page 02 of 03 Chapter 03
Page 03 of 03 Chapter 03

04) Labor, Material, And Equipment Utilization

Page 02 of 03 Chapter 04
Page 03 of 03 Chapter 04

05) Cost Estimation

Page 02 of 03 Chapter 05
Page 03 of 03 Chapter 05

06) Economic Evaluation of Facility Investments

Page 02 of 03 Chapter 06
Page 03 of 03 Chapter 06

07) Financing of Constructed Facilities

Page 02 of 03 Chapter 07
Page 03 of 03 Chapter 07

08) Construction Pricing and Contracting

Page 02 of 03 Chapter 08
Page 03 of 03 Chapter 08

09) Construction Planning

Page 02 of 03 Chapter 09
Page 03 of 03 Chapter 09

10) Fundamental Scheduling Procedures

Page 02 of 03 Chapter 10
Page 03 of 03 Chapter 10

11) Advanced Scheduling Techniques

Page 02 of 03 Chapter 11
Page 03 of 03 Chapter 11

12) Cost Control, Monitoring, and Accounting

Page 02 of 03 Chapter 12
Page 03 of 03 Chapter 12

13) Quality Control and Safety During Construction

Page 02 of 03 Chapter 13
Page 03 of 03 Chapter 13

14) Organization and Use of Project Information

Page 02 of 03 Chapter 14
Page 03 of 03 Chapter 14

Folder 14. Organization and Use of Project Information-03

14.7 Centralized Database Management Systems

Whichever conceptual model or database management system is adopted, the use of a central database management system has a number of advantages and some costs compared to the commonly employed special purpose datafiles. A datafile consists of a set of records arranged and defined for a single application system. Relational information between items in a record or between records is not explicitly described or available to other application systems. For example, a file of project activity durations and scheduled times might be assembled and manipulated by a project scheduling system. This datafile would not necessarily be available to the accounting system or to corporate planners.

A centralized DBM has several advantages over such stand-alone systems:

  • Reduced redundancy good planning can allow duplicate or similar data stored in different files for different applications to be combined and stored only once.
  • Improved availability information may be made available to any application program through the use of the DBM
  • Reduced inconsistency if the same data is stored in more than one place, then updating in one place and not everywhere can lead to inconsistencies in the database.
  • Enforced data security authorization to use information can be centralized.
  • For the purpose of project management, the issue of improved availability is particularly important. Most application programs create and own particular datafiles in the sense that information is difficult to obtain directly for other applications. Common problems in attempting to transfer data between such special purpose files are missing data items, unusable formats, and unknown formats.

    As an example, suppose that the Purchasing Department keeps records of equipment rental costs on each project underway. This data is arranged so that payment of invoices can be handled expeditiously and project accounts are properly debited. The records are arranged by individual suppliers for this purpose. These records might not be particularly useful for the purpose of preparing cost estimates since:

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

    14.8 Databases and Applications Programs

    The usefulness of a database organization is particularly evident in integrated design or management environments. In these systems, numerous applications programs share a common store of information. Data is drawn from the central database as needed by individual programs. Information requests are typically performed by including pre-defined function calls to the database management system within an application program. Results from one program are stored in the database and can be used by subsequent programs without specialized translation routines. Additionally, a user interface usually exists by which a project manager can directly make queries to the database. Figure 14-6 illustrates the role of an integrated database in this regard as the central data store.

    Figure 14-6  Illustration of an Integrated Applications System

    Figure 14-6  Illustration of an Integrated Applications System

    An architectural system for design can provide an example of an integrated system. First, a database can serve the role of storing a library of information on standard architectural features and component properties. These standard components can be called from the database library and introduced into a new design. The database can also store the description of a new design, such as the number, type and location of individual building components. The design itself can be composed using an interactive graphics program. This program would have the capability to store a new or modified design in the database. A graphics program typically has the capability to compose numerous, two or three dimensional views of a design, to introduce shading (to represent shadows and provide greater realism to a perspective), and to allow editing (including moving, replicating, or sizing individual components). Once a design is completed and its description stored in a database, numerous analysis programs can be applied, such as:

  • structural analysis,
  • daylight contour programs to produce plots of available daylight in each room,
  • a heat loss computation program
  • area, volume and materials quantities calculations.
  • Production information can also be obtained from the integrated system, such as:

  • dimensioned plans, sections and elevations,
  • 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. 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 and maintenance life cycle phase of the facility. As changes or repairs are needed, plans for the facility can be accessed from the database.

    Figure 14-7 Computer Aided Engineering in the Construction Industry

    Figure 14-7  Computer Aided Engineering in the Construction Industry
    (Reprinted with permission from from Y. Ohaski and M. Mukimo, "Computer-Aided Engineering in the Construction Industry," Engineering with Computers, Vol. 1, no. 2, 1985.

    14.9 Information Transfer and Flow

    The previous sections outlined the characteristics of a computerized database. In an overabundance of optimism or enthusiasm, it might be tempting to conclude that all information pertaining to a project might be stored in a single database. This has never been achieved and is both unlikely to occur and undesirable in itself. Among the difficulties of such excessive centralization are:

  • Existence of multiple firms or agencies involved in any project. Each organization must retain its own records of activities, whether or not other information is centralized. Geographic dispersion of work even within the same firm can also be advantageous. With design offices around the globe, fast track projects can have work underway by different offices 24 hours a day.
  • Advantages of distributed processing. Current computer technology suggests that using a number of computers at the various points that work is performed is more cost effective than using a single, centralized mainframe computer. Personal computers not only have cost and access advantages, they also provide a degree of desired redundancy and increased reliability.
  • Dynamic changes in information needs. As a project evolves, the level of detail and the types of information required will vary greatly.
  • Database diseconomies of scale. As any database gets larger, it becomes less and less efficient to find desired information.
  • Incompatible user perspectives. Defining a single data organization involves trade-offs between different groups of users and application systems. A good organization for one group may be poor for another.
  • In addition to these problems, there will always be a set of untidy information which cannot be easily defined or formalized to the extent necessary for storage in a 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.

    Figure 14-8  Application of an Input Pre-processor

    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

    In many areas of engineering design, the use of computer analysis tools applied to facility models has become prevalent and remarkably effective. However, these computer-based facility models are often separately developed or encoded by each firm involved in the design process. Thus, the architect, structural engineer, mechanical engineer, steel fabricator, construction manager and others might all have separate computer-based representations of a facility. Communication by means of reproduced facility plans and prose specifications is traditional among these groups. While transfer of this information in a form suitable for direct computer processing is difficult, it offers obvious advantages in avoiding repetition of work, delays and transcription errors. A de facto standard for transfer of geometric information emerged with the dominance of the AUTOCAD design system in the A/E/C industry. Information transfer was accomplished by copying AUTOCAD files from user to user, including uses on construction sites to visualize the design. More flexible and extensive standards for design information transfer also exist, such as the Industry Foundation Classes (IFC) standard developed by the International Alliance for Interoperability (See http://www.iai-international.org/iai_international/) and the "Fully Integrated and Automated Project Processes" developed by FIATECH (see http://www.fiatech.org/)

    14.10 References

    1. Au, T., C. Hendrickson and A. Pasquale, "Introduction of a Relational Database Within a Cost Estimating System," Transportation Research Record 1050, pp. 57-62, 1986.
    2. Bosserman, B.E. and M.E. Ford, "Development of Computerized Specifications," ASCE Journal of Construction Engineering and Management, Vol. 110, No. CO3, 1984, pp. 375-384.
    3. Date, C.J., An Introduction to Database Systems, 3rd Ed., Addison-Wesley, 1981.
    4. Kim, W., "Relational Database Systems," ACM Computing Surveys, Vol. 11, No. 3, 1979, pp. 185-211.
    5. Mitchell, William J., Computer Aided Architectural Design, Van Nostrand Reinhold Co., New York, 1977.
    6. Vieceli, A.M., "Communication and Coding of Computerized Construction Project Information," Unpublished MS Thesis, Department of Civil Engineering, Carnegie Mellon University, Pittsburgh, PA, 1984.
    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."
    Plans 4 Boats
    Sketch-Plus Home  |  Contacts  |  Samples  |  Products  | Books  |  Sitemap Sketch-Plus.com © 2004 | Privacy Policy | Terms of Use
    Organization and Use of Project Information-03