Developing Cost Estimates with RDBMS

Many cost estimators rely on a spreadsheet database for their work. Calculating costs in an electronic spreadsheet is certainly better than using a calculator and a pad of paper, but spreadsheets also have a number of limitations. Unit costs have to be entered manually or copied and pasted in from another source. Material costs used in multiple assemblies must be changed in multiple places–or must be accessed by developing custom formulas. The formulas connecting the cells for costs, quantities, markups, etc., must be carefully constructed and maintained as items are added or deleted. Commercial unit costs delivered in a flat file format must be copied and pasted or carefully entered into the spreadsheet cells–and updating these costs midway through a project can be difficult. Remembering to include all necessary costs and all building products and processes in every assembly required can be tricky or even treacherous. The flat file structure also means that functions such as special data formatting and compressed or expanded reports are difficult or impossible to achieve. In short, traditional cost estimating using electronic spreadsheets can now be regarded as obsolete.

Cost estimates prepared in a relational database system overcome the limitations of spreadsheets and achieve significant advantages in the process. The RDBMS maintains one table for all product data, another table for all assembly data, and installation crew data in yet another table. Each record in the assembly table is linked to multiple product records in the products table and to an appropriate installation crew, with associated efficiency data. Together, the costs associated with the records in each table make up the total installed cost of the assembly. Each product and each crew are linked to multiple assemblies, but because the data for each is entered only once, the system is far more efficient and can be updated much more easily. In summary, the relational database approach offers the following significant benefits:

Cost estimating with a relational database includes a separate table for assemblies, with each assembly linked to multiple products in a separate table; final output can be compressed or expanded for an appropriate level of detail. Image courtesy of Building Systems Design, Inc.

 

• The relationships between the unit costs, crew costs and assembly costs can be easily established and maintained
• Updating numerous assembly costs is a simple matter of replacing individual records in the product and crew tables
• Adding a total installed cost to an estimate is a simple matter of dragging and dropping one record into the project file

In a fully functioning relational database cost estimating program, parametric models can be constructed that automatically update the cost estimate as the building size is changed. Data can be easily compressed or expanded in detail to suit the project phase and purpose of the estimate. Replacing estimate components is a simple matter of drag and drop – and, not to be overlooked – because all the data can readily be tagged hierarchically, it's possible to collapse or expand the output to suit the need. The cost estimate can therefore be printed with varying levels of detail, depending on the project's stage of development and its ultimate use. A relational database application is a different kind of cost estimating tool. It can be readily used by design professionals such as architects, engineers and others for whom cost estimating is important but not a primary job function. With the relational database system established and in use, it is possible to produce budgetary estimates readily in less than 15 minutes and produce detailed cost estimates at any point in project development. This RDBMS approach leads to time and cost savings within a firm for carrying out this critical service of providing reliable cost estimates to clients and building owners. Perhaps of even greater importance, such a cost estimating system can assist the design professional in determining the likely cost of owner-requested changes and can help assure that the project stays within budget.

Interoperability and BIM

Clearly, the design process can be enhanced in multiple ways by using relational databases and RDBMS within a variety of software applications. But how does this relate to BIM? According to the NIBS National BIM Standard (NBIMS) Project Committee, "Building Information Modeling (BIM) is a digital representation of physical and functional characteristics of a facility. A BIM is a shared knowledge resource for information about a facility, forming a reliable basis for decisions during its life-cycle; defined as existing from earliest conception to demolition." A common misperception about a BIM is that all the information about a project must be included in the 3-D model generated by CADD software. However, even a medium-sized building that has every object from 40-foot-long steel columns down to 1/8-in. setting screws identified with attributes and data chews up a lot of computer memory. The graphic data alone can bring such software to its knees for large projects, so adding detailed specification and cost estimating data is probably not a realistic option. The alternative approach is to distribute the data such that separate relational databases exist generated by the separate applications. Hence, CADD or BIM data resides with its software application while specification and cost estimating data reside with their respective applications. It makes much more sense to regard the BIM as a collection of data about a common project that is stored in separate programs but linked by virtue of an RDBMS. In total, this distributed data makes up the full Building Information Model with the RDBMS serving as the key to its effectiveness and usefulness.

With database information coming from multiple sources, the ability to openly and easily share that information in generic formats without the restrictions of proprietary software becomes critical. The term that describes this open sharing is "interoperability" and is commonly used among a number of computer-based activities with strong precedent elsewhere. In fact, the Institute of Electrical and Electronics Engineers (I-triple E) has spent a considerable amount of effort looking at this topic and offers this definition of interoperability: "The ability of two or more systems or components to exchange information and to use the information that has been exchanged." Some will go on to include the capability to transfer information from one software application for use in another without the need for human intervention or interpretation. The ability of different programs to do all of this depends on the nature of the software and the data being managed. If a software program is fundamentally proprietary and "closed" to other applications, then it will not meet the definition of interoperability. However, products that are based on common data standards and open software platforms can interact with and be understood by other open programs. In the CADD world, it is the difference between the proprietary .dwg format compared to the open .dxf format, which allows one CADD software product to use data produced in another CADD program. However, when we are dealing with fundamentally different software programs, such as CADD, specification writing and cost estimating software, the fundamental requirement is that the data being transferred be both relevant and in a standard format that can be understood and used by the receiving application.

A central data repository is not usually practical. A distributed repository uses a standard taxonomy to allow different software programs to share information and work together. Image courtesy of Building Systems Design, Inc.