Construction Productivity must be Owner driven – BIM, IPD, JOC

One thing is clear, the construction sector (architecture, engineering, contractors, owners, operators, users, suppliers) has been lagging virtually all other business sectors for decades with respect to productivity improvement.

I believe that the cause is largely cultural, however, any major improvement must be driven by Owners,and/or mandated by governmental regulation.

My reasoning is simple, Owners pay the bills.  Thus as long as Owners remain satisfied with the status quo and/or remain “uneducated” with respect to proven business “best practices” and lean management processes, as well as supporting technologies, economic and environmental waste will continue to be rampant.

Currently, my outlook is somewhat pessimistic.  If one looks at  capability and knowledge specific to life-cycle  facility management from an industry perspective, most has originated with the government sector, followed by higher education, state government, healthcare, process-based industries, etc. etc.    Basically, Owners whose mission is dependent upon their built environment tend to create and follow life-cycle management practices. These are Owners that can’t adopt a “churn and burn”, or “run to failure” approach to facility management.  These sectors can’t easily pack up and move if their facilities and physical infrastructure fail.

That said, even government owners, for the most part, have failed in any sort of department or agency-wide adoption of standardized best practices.  This is true even for  “simple” areas such as facility repair, maintenance, and renovation.  Only the Air Force appears to come close to having any true adoption of robust, proven, best-practices in this regard, as well as associated training, etc., most notably with their SABER construction delivery structure.

In order to effect measurable productivity improvement in the “construction” sector, , I have put together a core requirements “checklist”.

1. Robust Ontology – Cost effective information management and information reuse can only be accomplished with a detailed set of terms, definitions, metrics, etc.  This aspect is also critical to improved strategic and tactical decision support mechanisms.

2. An understanding of life-cycle management of the built environment from a collaborative, best-practices, process perspective as well as associated supporting technologies.  Forget the traditional strategy-design-construction-demolish approach.

3. Commitment to a total cost of ownership perspective including both economic and environmental costs vs. our classic “first-cost” mentality.

4. “Trust but measure” – Owners MUST conduct their own internal cost estimating and associated capital planning and compare these to contractor estimates, with each party using the same  data architecture (examples: RSMeans, masterformat, uniformat, omniclass).

5. Adoption of collaborative construction delivery methods such as Integrated Project Delivery, IPD, and Job Order Contracting, JOC, in lieu of antagonistic and inefficient design-bid-built, or even design-build.

6. STOP reinventing the wheel.  Nothing noted here is “rocket science”.  Many, if not most, processes, procedures, and technologies are readily available for anyone who does a bit of basic research!!!   Also, stop with the focus upon BIM from a 3D visualization perspective!  3D tools are great, and add value, however, INFORMATION and PROCESS drive success.



Legals Aspects of BIM – UK – 2013

Here’s a quick overview of a recent meeting discussing the legal aspects of BIM held July 2013.

‘Experts’ we gathered by RIBA Enterprises to discuss the topic.  Key items a noted below:

1. CIC Protocol requires employers/onwers to put the protocol in place for all team members and upate the model production delivery table is updated and that an information manager is appointed.Project team members are required to provide specified levels of information, with a reasonable level of care.

2. Key to manage expectations early on in the project.

3. Protocol doesn’t really change liability in itself.  That said, the concept of Level of Detail (LOD) become important in determining what information is considered ‘sufficient’ when team members are delivering information to “employers/owners”.   Greaeter definition is required for both “data”, i.e. COBie and geometries.

4. Common data is a central requirement and robust management/business rules must be followed to assure development and use.

5. An information manager should not be confused with a design manager.  The information manager role spans multiple disciplines / competencies.

6.  Copyrights and other intellectual property issues are not any more complicated and appropriate licenses/rights should be established/obtained for owners/team use at the onset of the project.

The key principles of the application of the CIC BIM Protocol are as follows:

  • All parties that are responsible for the production of Building Information Models on behalf of the Employer should have the Protocol incorporated into their contract/appointment.

  • The same version of the Protocol and Appendices should be incorporated into each contract.

  • The wording of the CIC BIM Protocol should not be amended

  • The Protocol should detail all Building Information Models that are going to be produced by all parties contracted to the employer on the project

  • The Appendices have to be completed with project specific information for all projects.  This should be available from pre-appointment documentation such as the Employer’s Information Requirements.

  • Changes to the Protocol and its Appendices should be treated as variations to the Contract

BIM-Protocol-appendix-2 (1) BIM-Protocol-Appendix-1 The-BIM-Protocol

BIMF - Building Information Management Framework

via – Premier cost estimating and efficient project delivery software – JOC, SABER, IDIQ, MATOC, SATOC, MACC, POCA, BOA… featuring integrated contract, project, and document management, visual estimating/QTO, and an exclusively enhanced 400,000+ RSMeans line item cost database with line item modifiers and full descriptions.

Note:  The above is not intended as legal advice of any type, but rather a simple report on the session.


OmniClass™ Work Results: a critique (source:

It has been suggested by some that, rather than developing or implementing Uniclass2, we in the UK should switch to OmniClass, used in North America. John Gelder, Head of content development and sustainability, takes a critical look at the OmniClass Work Results Table, comparing it throughout with the Uniclass2 Work Results Table.

OmniClass is the North American equivalent of Uniclass2 and is promulgated by CSI (Construction Specifications Institute) and CSC (Construction Specifications Canada).

Broadly speaking OmniClass is in a similar position to Uniclass 1997, with much the same general limitations, though it is rather more unified. Uniclass articles corresponding to this one include Reclassification and The new Uniclass Work sections table. For a review of OmniClass in general, refer to the separate article OmniClass: a critique.


Like Uniclass Table J (aka CAWS), the OmniClass Work Results Table (aka MasterFormat) is geared mostly to the specification of systems and products, and so is focused on the construction phase. It doesn’t serve the whole project timeline, as it doesn’t have homes for high-level (early-stage) objects such as Complexes, Activities and Elements. This means that the Table can’t properly serve design-build and design-build-operate procurement (which, in the latter case, typically requires the contractor to be involved from the very beginning of the project, as part of a consortium). Other Tables within OmniClass must be used to structure specifications for Entities, Spaces and Elements. Tables outside OmniClass must be used for other object classes. These would then need to map to each other and to the Work Results Table, in order to properly integrate the specification component of the building information model (BIM) along the project timeline. Given the lack of congruence, this won’t be easy.

The Uniclass2 Work Results Table has homes for objects of all classes from Regions down to Products, so can fully serve the project timeline, and all procurement routes. See Table 5.*

Even mapping between systems and products is problematic because, read with the non-OmniClass SectionFormat, there are no homes for System outline (or compositional) specifications. Indeed, Systems and Products are conflated. This means that the Work Results Table, plus SectionFormat, can’t properly serve BIM, which requires mapping between objects of different classes in the object hierarchy (e.g. this product is part of that system, this system comprises those products). Making this explicit in the specification requires outline specifications. We can’t rely on this mapping being delivered through the geometrical part of BIM (CAD) since many systems and products are not modelled geometrically at all.

The Uniclass2 Work Results Structure Table provides for outline (compositional) specifications all down the object hierarchy, including Systems-to-Products, so fully supports BIM. Table 5 illustrates this (left-hand column).

Table 5: OmniClass and Unclass2 Work Results Tables – scope

Item OmniClass Table 22 Work Results 2011 & SectionFormat 2008 Uniclass2 Work Results Table & Work Results Structure Table
Project management Division 00 Procurement and contracting requirements + Division 01 General requirements Group 00 Project management + Management Table
Region outline Not included Group 02 Regions + Regions Table
Region performance
District outline Group 04 Districts + Districts Table
District performance
Complex outline Group 06 Complexes + Complexes Table
Complex performance
Entity outline Group 08 Entities + Entities Table
Entity performance
Activity outline Group 10 Activities + Activities Table
Activity performance
Space outline Group 12 Spaces + Spaces Table
Space performance
Element outline Group 14 Elements + Elements Table
Element performance
System outline System sections: System outline subsection + Systems Table
System performance Work sections: SF Products subsection System sections: System performance subsection
Products System sections: Products subsection + Products Table
Custom-made products System sections: Custom-made products subsection
Execution Work sections: SF Execution subsection System sections: Execution subsection
System completion Sub-group XX 08 00 Commissioning System sections: System completion subsection
System FM Sub-group XX 01 00 Maintenance System sections: System FM subsection

SectionFormat has a home for the specification of performance and design criteria of products, which in turn are defined as including systems, assemblies, manufactured units, equipment, components, product types and materials. That is, SectionFormat doesn’t really distinguish between products, systems and materials, though OmniClass at large does (in the Products, Work Results and Materials Tables). ‘Performance’ at a higher level was in sub-group 01 80 00 Performance requirements in the 2004 edition of this Table, but this has been dropped in the 2011 edition. As it was actually mostly about elements rather than systems (e.g. 01 83 16 Exterior enclosure performance requirements), the idea is probably that this is specified using a specification aligned to the Elements Table.

The Uniclass2 Work Results Structure Table provides for performance specification of objects all down the object hierarchy, so fully supports contractor (and other) design. It also makes a clear distinction between Elements, Systems and Products (and so on) – this is essential for a rational approach to hierarchical object modelling. Table 5 illustrates this (left-hand column).

In the OmniClass Work Results Table, the commissioning and maintenance of systems (elements, actually) are not described in the system sections, but in separate sections in sub-groups 08 and 01 of each group, respectively, e.g. sub-group 09-08-00 Commissioning of finishes and section 09-01-70 Maintenance of wall finishes (see Table 6). This is rather inconvenient for those wanting to have everything about a given system collected together (though of course this could be managed through reporting in a digital specification tool such as NBS Create).

All aspects of each system, from design to operation, are collected in each of the System sections in the Uniclass2 Work Results Structure Table. Table 5 illustrates this (right-hand column).


The general sequence of sections within each Group doesn’t fully reflect construction sequence. For example, operation and maintenance should be last, and commissioning should be second-last, but this isn’t the structure at all. All of this is held in sections that precede those describing the thing yet to be designed and built. See Table 6.

The System section structure in the Uniclass2 Work Results Structure Table fully reflects construction sequence. See Table 5 (right-hand column).

Table 6: OmniClass Work Results Table – section sequence

Fabric example Services example
08-00-00 Openings 23-00-00 Heating, ventilating and air conditioning (HVAC)
• 08-01-00 Operation and maintenance of openings • 23-01-00 Operation and maintenance of HVAC systems
• 08-05-00 Common work results for openings • 23-05-00 Common work results for HVAC
• 08-06-00 Schedules for openings • 23-06-00 Schedules for HVAC
Not used • 23-07-00 HVAC insulation
• 08-08-00 Commissioning of openings • 23-08-00 Commissioning of HVAC
Not used • 23-09-00 Instrumentation and control for HVAC
08-10-00 Doors and frames 23-10-00 Facility fuel systems
Not used 23-20-00 HVAC piping and pumps
08-30-00 Specialty doors and frames 23-30-00 HVAC air distribution
08-40-00 Entrances, storefronts and curtain walls 23-40-00 HVAC air cleaning devices
08-50-00 Windows 23-50-00 Central heating equipment
08-60-00 Roof windows and skylights 23-60-00 Central cooling equipment
08-70-00 Hardware 23-70-00 Central HVAC equipment
08-80-00 Glazing 23-80-00 Decentralized HVAC equipment
08-90-00 Louvers and vents Not used

The OmniClass Work Results Table has deficiencies, specifically with respect to serving the entire project timeline and all procurement routes, and supporting BIM. It has a construction phase focus, and so has no homes for the specification of high-level objects such as Complexes, so it can’t deal with early project stages. System operation and maintenance specifications are isolated from descriptions of the systems themselves, so it doesn’t serve the occupancy phase as well as it might. Together this means that the Table is not well-suited to non-traditional modes of procurement, such as design-build and design-build-operate.

The Work Results Table conflates systems and products, and has no homes for outline or compositional specifications. Together these mean that the Table doesn’t support hierarchical object mapping, a key requirement for a BIM specification. This is exacerbated by the Table – and OmniClass as a whole – not supporting classification of high-level object classes and systems. Without these object classes we cannot produce a complete ‘building’ information model.

Finally, the basic design-build-operate sequence is not implemented fully in the Work Results Table, nor in SectionFormat (e.g. a proposed FM subsection has not eventuated; system-wide performance requirements are not distinguished from those for ‘mere’ products). This makes the default structure rather messy.

BIM requires a unified approach to classification if it is to work well, e.g. with simple mapping between classification Tables. OmniClass cannot deliver this, as it stands. Uniclass2 can.

* Note: Tables 1 to 4 are available in OmniClass™: a critique

via – Leading cost estimating and efficient project delivery software software solutions for JOC, SABER, IDIQ, MATOC, SATOC, MACC, POCA, BOA, BOS … featuring and exclusively enhanced 400,000 line item RSMeans Cost Database, visual estimating / automatic quantity take off ( QTO), contract, project, and document mangement, all in one application.

Open BIM – What’s it going to take to get there?

1.  Robust, collaborative construction delivery methods – IPD, Integrated Project Delivery, JOC – Job Order Contracting, et al .  Collaboration in the building industry requires the integration of complex inter-related workflows whereby multitude of stakeholders are incorporated into a common pool of information, decision-support, and activities over an extensive period of time.

2. Standardized “Glossary”.. terms, acronyms, definitions.

3. Benchmarks, metrics.

4. Life-cycle perspective and management techniques/processes… vs. a “first cost mentality”.

5.  Technology focused upon enabling robust processes…vs. current focus upon 3D modeling.  Embedding vetted processes with technology enables consistent, scalable deployment.

6.  Current examples of “open’ and standardized knowledge domains, processes, terms, and  technologies.

Capital planning and management systems (CPMS) – physical and functional condition monitoring and associated capital reinvestment planning.  traditionally dealing with expenditures in excess of $10,000.

Computerized Maintenance Management systems (CMMS) – inventory, repair, maintenance of ‘movable equipment’.  Typically involving expenditures of $10,000 or less.

Computer-Aid Facility Managements Systems (CAFM) – space planning, move management, space utilization.

Building Automation Systems (BAS) – security, life/safety, access control, environment systems management.

Geographic Information Systems (GIS) – computerized location management / positioning.

Create, read, update, delete) operations (CRUD)

Industry Foundation Classes (IFC) – structure enabling native storage of instance models

Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks.

Representational State Transfer (REST)  is an architectural style for large-scale software design

Construction Operations Building Information Exchange (COBie) a specification used in the handover of Facility Management information.

OMNICLASS  in simple terms, a standard for organizing all construction information. The concept for OmniClass is derived from internationally-accepted standards that have been developed by the International Organization for Standardization (ISO) and the International Construction Information Society (ICIS) subcommittees and workgroups from the early-1990s to the present.
ISO Technical Committee 59, Subcommittee 13, Working Group 2 (TC59/SC13/WG2) drafted a standard for a classification framework (ISO 12006-2, more information below) based on traditional classification but also recognized an alternative “object oriented” approach, which had to be explored further.

UniFormat is a standard for classifying building specifications, cost estimating, and cost analysis in the U.S. and Canada.

MasterFormat is a standard for organizing specifications and other written information for commercial and institutional building projects in the U.S. and Canada.

BIM and Big Data
BIM and Big Data

BIM for FM – What is COBie – A Section of Roadmap for Life-cycle Management of the Built Environment

(Source:A report for the Government Construction Client Group Building Information Modelling (BIM) Working Party Strategy Paper March 2011)

via – Premier technology solutions for cost estimating and efficient project delivery method implementation – JOC, SABER, IPD, IDIQ, SATOC, MATOC, MACC, POCA, BOA …

What is COBie?

COBie is a vehicle for sharing predominantly non-graphic data about a facility. The primary motivation for the use of COBie is to ensure that the Client as Owner, Operator and Occupier receives the information about the facility in as complete and as useful form as possible. Wherever possible, data should be recorded within COBie. The COBie dataset can additionally act as a guided index to the supplementary documentation, including 2D and 3D information.

 COBie2  was created to provide a means for the faculties industry to communicate information about facilities so that the client can immediately take full and responsible ownership.  It arose from the collaboration of the US Department of State, US Army Corps of Engineers, NASA, and the Veterans Association. In 2008 it was revised as COBie to ensure that it was relevant to facilities  worldwide  and  was  fully  compatible  with  international  standards  for  data  and classification. Adopters of the COBie approach also include public and private owners, University of Indiana, University Southern California, in the UK Vinci Construction Ltd, and in Germany, The State of Bavaria.

 COBie is a non-proprietary format based on a multiple page spread sheet. It is designed to be easily managed by organisations of any size and at any level of IT capability, allowing each of them to contribute efficiently to a single representation of the asset. It requires only information that is (or should be) available anyway, so it does not represent a change in the expected content, only in its usefulness and accessibility. The intent is to not create information that is not already available or produced as part of the existing processes. The aim is to structure and rationalise the information for re-purposing and use downstream.   COBie also acts as an index to other documents. Overall COBie provides traceability and visibility of design, construction and handover decisions to all supply and client side stakeholders.


COBie is used for communication, as a means of information exchange between parties, particularly to the customer.  Where automation is not in use, such as in the lower tiers of the supply chain, COBie information can be captured using direct entry into the spread sheet, often using cut-and-paste from existing schedules and documents. Parties including the client can use the COBie format as a primary document for managing the asset. Design development, construction management and asset management applications have had no difficulty in interfacing with the format.


COBie comprises sheets that document the facility, the levels (or sectors), spaces and zones that make up the function of the facility. These are then filled with the actual manageable systems and assets and details of their product types.  During construction and installation these are amplified with information about the spares, warranties, and maintenance requirements. Throughout the process additional attributes, issues and documents can be associated to all these items.


2 COBie (Construction Operations Building information exchange) was developed by a number of US public agencies to improve the handover process to building owner-operators.

cobie lifecycle




COBie data is accumulated throughout the life cycle

COBie transfers the information needed by the owner/operator to manage their asset efficiently. The principal use-case is therefore the handover of a facility after commissioning of the owner/operator. Typical questions answered by COBie include:

  • What is the design performance of my asset? Energy, rental, quality measures,
  • What is the amount of floor space of estate? Classified by building type.
  • What is the occupancy level of my estate/per building?
  • What is the required plant and equipment maintenance scheduling – preventative and reactive?
  • What is my operational cost expected to be?
  • What is my as-designed energy use cost expected to be? What is my actual energy use? The  use of
COBie in practice has shown that it is not limited and has a more general role of communicating the key information in a structured format. COBie has been found to be useful and efficient in many scenarios, including documenting existing facilities.

1.  The handover of a facility to the owner/operator.

2.  The capture of commissioning and survey information.

3.  The reporting of the designed project ready for tendering.

4.  The coordination of maintenance records of existing infrastructure.

5.  The documentation of issues discovered throughout the life cycle.

6.  The delivery of product data.

7.  The reporting of design intent at the early design stage.

8.  The comparison of briefing requirements against the designed and as built

Cobie sheets

COBie documents the asset in 16 consistent and linked sheets

We anticipate that our application of COBie will develop as the various technologies in the market mature, broadly in line with our “maturity levels model” described in appendix 3. For the majority of the five years of the life of this strategy we anticipate that most of the market will be engaged in or around level 2.  For all deliveries at this level, COBie will be adequate as a transport mechanism but may well require additional development to cope with additional attached data, which some clients may start to wish for collection. There will also be a need to have a more robust system for processing the information as our understanding and needs grow.    For this reason we have identified a stage where we would hold all delivered data in a database to enable these processes. This will need additional guidance as there would be a need to synchronise data, COBie, calculations and proprietary information at the same point in time.

 Our final vision for the delivery of this information will be a fully web enabled transparent (to the user) scenario, based on the Building Smart IFC/IDM and IFD standards.

The model below illustrates this progression, with respect to maturity level.

maturity model

Open BIM Standards – COBIE, OMNICLASS – IFC / COBIE Report 2012

BIM adoption remains a challenge due to the fact that its many supporters don’t focus upon it’s true relevance, the efficient life-cycle management of the built environment.

While any new technology has  barriers to adoption, changing the “status quo”, the fundamental nature of how a business sector does business requires a major event.   The cultural and process changes associated with BIM, namely the need for all stakeholders to collaborate, share information in a transparent manner, and share in risk/reward, remain chasms to be crossed by many/most.    Fortunately, those currently or previously involved with Integrated Project Delivery and Job Order Contracting (the latter a form of IPD specifically targeting renovation, repair, sustainability, and minor new construction) have experience with these “novel” business concepts.  Both IPD and JOC have proven track records and have clearly demonstrated the ability to get more work done on-time and on-budget to the benefit of all involved parties.

A key aspect of BIM, collaboration, can only be efficiently accomplished with a commonly understood and shared taxonomy including terms, definitions, and associated metrics.

So called “open BIM”, such as buildingSMART International’s Industry Foundation Classes (IFCs), are important to enabling collaboration as well as interoperability between BIM software applications.     COBie, a naming convention for facility spaces/components, etc., and its counterparts OMINCLASS, including MASTERFORMAT and UNIFORMAT,  etc. … can be leveraged and generated by IFC appears a goal worth additional focus on a local and global level.   That said, support for COBie, OMNICLASS, IFC, etc. varies and,  far from mainstream.

As noted in the IFC / COBIE Report 2012, BIM’s success depends upon the ability to:

  1. Create model data in a consistent format
  2. Exchange that data in a common language
  3. Interrogate the data intelligently.

There are multiple knowledge domains, technologies, and process involve in the life-cycle management of the built environment, all of which need a common data architecture, taxonomy, set of metrics, etc.

The IFC / COBIE Report 2012 correctly points out that pressing needs remain:

  1. The need for standards

  2. The need for guidance

  3. The need for enhanced IFC import export routines from BIM applications

  4. The need for agreed descriptions of who requires what data and when

  5. The need for an improved audit trail to allow greater confidence in collaboration.

Also, and I paraphrase / embellish…

  1. “Enforcement” of IFC by buildSmartalliance and all BIM “proponents”  is required.
  2. Domain experts must leveraged and queried to deliver structured data templates accordingly.  The industry needs well defined model view definition for each COBie data drop. From this can come clear guidance on the “level of detail” required at each COBie data drop. This will give a shared understanding of what information is required from and by whom and at what stage.  For example needs of Facilities Managers are required to inform the content of the COBie data drops. Facility management must be considered as early as the briefing process.
  3. Weaknesses in the IFC import /export processes exist in current software product implementation. These weaknesses make manual checking necessary and reduce confidence.  Improvement  is vital here.
  4. While IFC can be used when generating COBie data, people will use whatever works and is available. The market requires.  complete flexibility to choose what systems they use. Innovation should not be stifled by mandating a process to achieve the required data.
  5. COBIE is far from complete, but a good starting point.
  6.  Microsoft Excel  provides a view of the structured info of COBie data and one way 0f reporting data, however, in NOT a good authoring tool, nor does it support hierarchal relational data schema.