BIM ThinkSpace

BIM Episode 11: The difference between BIM Capability and BIM Maturity

The Story

Let’s start with a short story about two AEC organisations that – once upon a time – decided to adopt Building Information Modelling. Both organisations were mid-sized firms, operated within the same market and had the same mix of disciplines. Both were able to undertake large Design and Construct (Design and Build) projects of value exceeding $200m within the Health Sector. But this is where the similarities ended:

The Yellow Organisation decided to invest substantial energy and money to acquire object-based software (say Revit®, Tekla® or Vico®). This decision came after a group of enthusiastic and technology-savvy staff succeeded in convincing management to trial BIM. These ‘champions’ then organised and undertook the necessary training as recommended by their BIM software retailer and supplemented their learning by sieving through countless online forums. After a handful of months, a few setbacks and a couple of successful pilot projects, this group of individuals – now considered superheroes by some of their peers and computer-hugging fools by others – stood ready to implement what they’ve learned across the organisation. New BIM components where generated on-the-job and novel standards/processes started to slowly push out existing CAD practices. The management, now excited about the commercial possibilities of the new deliverables, instructed its marketing people to inject BIM images and labels  into Yellow’s corporate website and to start informing potential clients about their new abilities.

The Blue Organisation invested substantial time and energy in investigating, developing and then gradually implementing an overall BIM strategy, tailored training plans, modelling standards and workflow protocols. Internal and external help were sought to communicate, train as well as educate staff [1] about BIM technologies and processes. The management team, after leading this implementation effort from day zero, succeeded in getting all staff enthusiastic and engaged in developing BIM products and processes. They continuously conducted internal assessments to ensure that their BIM productivity is sufficiently stable and that they can predictably and uniformly deliver high-quality models and drawings. Convinced that BIM is the only efficient way to deliver services, they allowed their marketing people to inject BIM images and labels  into Blue’s corporate website and to start informing potential clients about their new abilities.

End of short story...

Now, from an onlooker’s point of view (a client for example) both organisations appear equally qualified, just as able to deliver the promise of BIM....But they’re not equally qualified – far from it. These two organisations demonstrate a significant problem in identifying the difference between BIM Capability - the ability to generate BIM deliverables and services, from BIM Maturity - the extent, depth, quality, predictability and repeatability of these BIM deliverables and services.

Let’s have another look at the above organisations using two different lenses:

#	Yellow Organisation	Blue Organisation
1	Uses Object-based software tools	Also uses Object-based software tools
2	Can collaborate internally using multi-disciplinary object-based models	Same as left...
3	Can deliver at least one large BIM project of construction value exceeding $200m	Same as left...
4	Has experience in the Health Sector	Same as left...
5	...	...
Quick Conclusion:  the Yellow and Blue organisation have very similar BIM Capability

Table 1. Comparing the two organisations using a BIM Capability lens

 

#	Yellow Organisation	Blue Organisation
1	Bottom-Up initial BIM approach	Top-Down initial BIM approach
2	Champion-lead implementation	Management-lead implementation
3	No evidence of overall BIM strategy	Overall Strategy preceded implementation
4	No evidence of internal communication about BIM implementation efforts	There is evidence of internal communication as part of the BIM implementation effort
5	Standards were learned, developed and extended on the go	Standards and workflows where readied prior to wide implementation
6	Evidence of change-resistance (cynicism)	Evidence of wide-spread enthusiasm
7	No evidence of skill/knowledge assessment	Evidence of skill/knowledge assessment
8	....	....
Quick Conclusion: the Blue organisation has higher BIM Maturity than the Yellow one (this conclusion will be explained in more detail in the next one or two blog posts)

Table 2. Comparing the two organisations using a BIM Maturity lens

Capability is thus a notion quite different to Maturity...I'll quickly expand on this a bit more by re-discussing BIM Capability before directly jumping into the more intricate topic of BIM Maturity:

BIM Capability, a reminder

As explored in Episode 8,  three ‘capability’ Stages are needed to pass from pre-BIM status to IPD. These Stages represent revolutionary changes (as opposed to evolutionary mutations) and are characterised by reaching a milestone or achieving minimum proficiency. For example, an organisation is considered to have reached BIM Capability Stage 1 by the relative easiness of deploying an object-based software. BIM Capability Stage 2 is reached when an organisation undertakes model-based multi-disciplinary collaboration. Finally, BIM Capability Stage 3 is reached when an organisation undertakes network-based, interdisciplinary model integration. In essence, the three BIM Stages are useful in identifying the minimum abilities of organisations and project teams but are not that useful in analysing or comparing how well they model, collaborate or integrate their deliverables.

Organisation which are not aware of the above capability progression usually refer to themselves as generically ‘BIM able’ as soon as they deploy a few copies of ArchiCAD, Tekla or Bentley Architecture. So how can individuals, organisational teams, organisations and project teams rate their own performance or that of their potential partners or competitors? How can clients filter out BIM wash from BIM reality? They need – we all need – some kind of ‘tool’ that can be applied to define, measure and hopefully improve these BIM abilities [2].

BIM Maturity

The concept of Maturity is not new and have existed for some time in many other industries but the most potent representation of this concept came from the software industry’s Capability Maturity Model. CMM is actually a ‘process improvement framework’ originally intended as a tool to evaluate the ability of government contractors to perform a software project. It was developed in the late 80s for the benefit of the US Department of Defence [3]. It’s successor, the more comprehensive Capability Maturity Model Integration (CMMI),  continues to be developed and extended by the Software Engineering Institute, Carnegie Mellon University.

Capability Maturity Models identify a set of standardised process improvement levels (or maturity levels) which allow implementers to achieve significant business benefits. Research into CMM has already identified the correlation between process maturity and business performance [4]. The use of maturity models is thought to lead to increased productivity and Return On Investment (ROI) as well as reduced costs and post-delivery defects [5]&[6].

The ‘original’ CMM is specific to the software industry and is not applicable to construction as it does not address supply chain issues and its maturity levels do not account for the different phases of a project lifecycle [7]. Although there are a few – some are extensive efforts - which focus on the construction industry, there is no comprehensive model that can be applied to BIM, its implementation stages, players, deliverables or its effect on project lifecycle phases.

 

I’ll leave it here now....In the next couple of Episodes, I’ll discuss currently available and applicable Maturity Models (including the one by NBIMS) followed by a new BIM Maturity Index which I think you’ll find interesting...

 

---

[1] “Education is about learning for oneself, and training is about learning for the sake of someone else” as beautifully summarised by Dr. Megan Squire after analysing this Monthly Review article.

[2] The full quality axiom dictates that "what cannot be defined, cannot be measured; what cannot be measured cannot be improved, and what cannot be improved will eventually deteriorate” (Dr. Daniel Meade, bettermanagement.com)

[3] Hutchinson, A., & Finnemore, M. (1999). Standardized process improvement for construction enterprises. Total Quality Management, 10, 576-583.

[4] Lockamy III, A., & McCormack, K. (2004). The development of a supply chain management process maturity model using the concepts of business process orientation. Supply Chain Management: An International Journal, 9(4), 272-278.

[5] Jaco, R. (2004). Developing an IS/ICT management capability maturity framework, Proceedings of the 2004 annual research conference of the South African institute of computer scientists and information technologists on IT research in developing countries. Stellenbosch, Western Cape, South Africa: South African Institute for Computer Scientists and Information Technologists.

[6] Paulk, M. C., Weber, C. V., Garcia, S. M., Chrissis, M. B., & Bush, M. (1993). Key Practices of the Capability Maturity Model - Version 1.1 (Technical Report): Software Engineering Institute, Carnegie Mellon University.

[7] Sarshar, M., Haigh, R., Finnemore, M., Aouad, G., Barrett, P., Baldry, D., et al. (2000). SPICE: a business process diagnostics tool for construction projects. Engineering Construction & Architectural Management, 7(3), 241-250.

The BIM Framework: an Academic Perspective

Many of ThinkSpace’s readers are academically-oriented and may be interested to know that the BIM Framework has now been published in the peer-reviewed Journal of Automation in Construction (Volume 18, Issue 3).  The Framework is the basis of most BIM episodes published so far and has allowed the generation of many BIM implementation and evaluation tools (more about that in future posts). Below is the paper’s abstract in both textual and visual forms:

Textual Abstract: “Building Information Modelling (BIM) is an expansive knowledge domain within the Architecture, Engineering, Construction and Operations (AECO) industry. To allow a systematic investigation of BIM's divergent fields, its knowledge components must be defined and expanding boundaries delineated. This paper explores some of the publicly available international guidelines and introduces the BIM Framework, a research and delivery foundation for industry stakeholders. This is a ‘scene-setting’ paper identifying many conceptual parts (fields, stages, steps and lenses), providing examples of their application and listing some of the Framework's deliverables. This paper also identifies and deploys visual knowledge models and a specialised ontology to represent domain concepts and their relations”.

Visual Abstract: visualisations reduce complexity; please click on the image below to open a higher-resolution image:

I regret that I cannot share the actual paper with the blog’s subscribers due to copyright restrictions. Please do not hesitate to contact me if you need further information or clarifications.

Technorati Tags: BIM,Research,Academic,Journal,Framework,Stages,Steps,Lenses,Project Lifecycle Phases,Data Flows,Modelling,Collaboration,Integration,IPD,Ontology,Visualisation,Visual Models

Effects of BIM On Project Lifecycle Phases

The BIM Episodes: Episode 10

A construction project passes through multiple phases from inception to demolition. These phases are typically referred to as Project Lifecycle Phases (PLPs) and include pre-construction activities like programming, cost planning as well as post-construction activities like occupancy and facility maintenance. Lifecycle phases can be delineated in a few ways but I have personally adopted a simplified subdivision as follows:

Construction projects pass through three major lifecycle phases: Design [D], Construction [C] and Operations [O]. These phases are also subdivided into sub-phases (Table 1) which are in turn further subdivided into activities, sub-activities and tasks.

Design Phase	Construction Phase	Operations Phase
D1: conceptualisation, programming and cost planning	C1: construction planning and construction detailing	O1: occupancy and operations
D2: architectural, structural and systems design	C2: construction, manufacturing and procurement	O2: asset management and facility maintenance
D3: analysis, detailing, coordination and specification	C3: commissioning, as-built and handover	O3: decommissioning and major re-programming

Table 1: Project Lifecycle Phases and sub-Phases

As an example of further subdivision, the Design phase [D] includes Architectural, Structural and Systems Design sub-phase [D1], which includes an Architectural Design activity [D1.1], which includes the Conceptualisation sub-activity [D1.1a] which lastly includes a 3D Modelling task [D1.1a.01]. The usefulness of these subdivisions will not be too evident in this blog post but just remember that BIM implementations can and will affect construction projects at Phase, Task and everything in between. For now we’ll just focus on the effects of BIM on Phases and I’ll discuss the effects of BIM on smaller lifecycle subdivisions in later posts.

 

BIM Stage 1: Object-Based Modelling

As a reminder, BIM implementation is initiated through the deployment of an ‘object-based 3D parametric software tool’ similar to ArchiCAD®, Revit®, Digital Project® and Tekla®. At Stage 1, users generate single-disciplinary models within either design [D], construction [C] or operation [O] – the three Project Lifecycle Phases. These models - like architectural design models [D] and duct fabrication models [C] - are primarily used to automate the generation and coordination of 2D documentation and 3D visualisations. Other deliverables of Stage 1 models include basic data exports (ex: door schedules, concrete quantities, FFE costs,...) and light-weight 3D models (ex: 3D DWF, 3D PDF, NWD, etc...) which have no modifiable parametric attributes. However, the ‘semantic’ nature of object-based models and their ‘hunger’ for early and detailed resolution of design and construction matters encourage ‘fast-tracking’ of Project Lifecycle Phases (Fig. 1).

 

Fig. 1. Project Lifecycle Phases at BIM Stage 1 – linear model

Figure 1 above depicts how object-based modelling encourages fast-tracking: when a project is still executed in a phased manner yet design and construction activities are overlapped to save time [2]. That is, after achieving maturity within Stage 1 implementations, BIM players will acknowledge the benefits of engaging other design and construction players with similar modelling capabilities. Such acknowledgement and subsequent action will lead them to BIM Stage 2, model-based collaboration.

 

BIM Stage 2: Model-Based Collaboration

Having developed single-disciplinary modelling expertise through Stage 1 implementations, Stage 2 players actively collaborate with other disciplinary players. This may occur in many technological ways according to each player’s selection of BIM software tools.

Model-based collaboration can occur within one or between two Project Lifecycle Phases. Examples of this include the Design-Design interchange of architectural and structural models [DD], the Design-Construction interchange of structural and steel models [DC] and the Design-Operations interchange of architectural and facility maintenance models [DO]. Stage 2 maturity also alters the granularity of modelling performed at each lifecycle phase as higher-detail construction models move forward and replace (partially or fully) lower-detail design models (Fig. 2).

 

Fig. 2. Project Lifecycle Phases at BIM Stage 2 – linear model

Figure 2 above depicts how model-based collaboration is a factor in instigating fast-tracking and changing relative modelling intensity within each lifecycle phase. The overlap depicted is driven by construction players increasingly providing design-related services as part of their Stage 2 offerings and design players increasingly adding construction and procurement information into their design models. Also, changes in semantic richness across lifecycle phases occur as detailed construction and fabrication models (ex: steel detailing and duct fabrication models) partially replace the more generic upstream structural and mechanical design models.

 

BIM Stage 3: Network-Based Integration

In this stage semantically-rich integrated models are created, shared and maintained collaboratively across Project Lifecycle Phases. This integration can be achieved through model server technologies (using proprietary, open or non-proprietary formats), single / integrated / distributed / federated databases [1,3] and/or SaaS (Software as a Service) solutions [4]. From a process perspective, synchronous interchange of model and document-based data cause project lifecycle phases to overlap extensively forming a phase-less process (Fig.3).

 

Fig. 3. Project Lifecycle Phases at BIM Stage 3 – linear model

Figure 3 above depicts how network-based integration causes ‘concurrent construction’: a term used when “all project activities are integrated and all aspects of design, construction, and operation are concurrently planned to maximize the value of objective functions while optimising constructability, operability and safety” [2].

In summary, object-based modelling will first blur the lines separating different project lifecycle phases. As model-based collaboration takes hold, lifecycle players start moving into each other’s territory. Finally, as network-based integration becomes the norm, design, construction and operations overlap extensively if not totally.

Note on terms used within Figures:

• A BIM data exchange is when a BIM player exports or imports data that is neither structured nor computable. A typical example of data exchange is the export of 2D CAD drawings out of 3D object-based models resulting in significant loss of geometric and semantic data.
• A BIM data interchange (or interoperable exchange) is when a BIM player exports and imports data that is structured and computable by another application. Interchanges assume ‘adequate interoperability’ between the sender and receiver systems.

References

[1] Bentley, Does the Building Industry Really Need to Start Over - A Response from Bentley to Autodesk's BIM-Revit Proposal for the Future, http://www.laiserin.com/features/bim/bentley_bim_whitepaper.pdf, last accessed July 12, 2008

[2] A. Jaafari, Concurrent Construction and Life Cycle Project Management, Journal of Construction Engineering and Management 123 (4) (1997) 427-436.

[3] J. Liaserin, Building Information Modeling - The Great Debate, http://www.laiserin.com/features/bim/index.php, last accessed July 12, 2008

[4] P. Wilkinson, SaaS-based BIM, http://www.extranetevolution.com/extranet_evolution/2008/04/saas-based-bim.html, last accessed July 12, 2008

The BIM Episodes: Episode 9

EPISODE 9: BIM STEPS

This post is about BIM Steps, those micro changes needed to implement Building Information Modelling within an organisation and then - by osmosis - throughout the whole industry. But before we introduce BIM Steps and in response to feedback received, I’ll partially revisit the BIM Stages topic (Episode 8) in an effort to invite more discussion.

BIM Adoption: Stages and Steps

The adoption of BIM by an organisation will not happen unintentionally and definitely not in a single giant leap. In fact, it will be deployed through intentional decisions passing through major milestones referred to as BIM Stages. These stages – if well defined - are very useful to understand BIM concepts and visions but are - on their own - not usable in implementation. Further subdivisions are needed: smaller incremental changes that each organisation can make to reach each major Stage, mature within it and then attempt to reach another. These ‘feetstones’ or micro objectives are called BIM Steps. The difference between BIM Stages and Steps is that stages are radical or transformational changes while steps are incremental/evolutionary changes or maturity levels.

But why do we need to define stages to start with?

BIM News Bits - Interesting Developments

I try not to to blog industry news but sometimes it feels 'irresponsible' not to do so. However, I'll follow the three BIM Nodes logic in my reporting:

On the Technology front: the emergent Microsoft Live Mesh technology deserves some attention... Would an enterprise version enable a different approach to BIM Integration (Stage 3) alongside Model Servers and what I term BIMaaS (BIM as a Service - read this and that)? It's too early to tell but its a space worth monitoring with wide-open BIM eyes.

On the Process side, I've been invited to have a look at the Build London Live effort. I'm personally not into grand gestures but I do think such efforts play a valuable role in promoting BIM Thinking within a decreasingly skeptical industry. In fact, I would love to include a couple of clients in a BIMStorm™ if it hits the Asia-Pacific!

On the BIM Policy front, an excellent effort by the AIA and I couldn't but reproduce the news:

"On May 15th 2008 the AIA released two new model agreements for integrated project delivery. The documents follow concepts in Integrated Project Delivery: A Guide, and provide two levels of design and construction integration. One is a transitional agreement for those less familiar with IPD; the second, a “single purpose entity”, offers a fully integrated way to deliver a project. Get more information about the IPD documents at http://aiacontractdocuments.org/ipd/."

In summary, the above three bits vary in importance but are all equally welcome BIM News. To achieve integrated project delivery, integrated design solutions or whatever you want to call the BIM climax, a great number of technology, process and policy steps are needed...Which reminds me, I need to upload Episode 9: understanding BIM Steps sometime soon...

BIM and the Process Improvement Movement

It gives me pleasure to introduce a guest author to BIM ThinkSpace – Sohail Razvi. Through the wonders of web-based professional networking, I met Sohail and we started a discussion that continues to date. This is Sohail's first web contribution into the topic and I'm delighted he's chosen BIM ThinkSpace for his well-thought piece. The below article explores a new angle into BIM Framework generation as Sohail argues how it could develop around a set of well established, measurable and institutionalised framework, the CMMI…You can download this 8-page article as a PDF file (317KB) from here.

BIM and the Process Improvement Movement

Building a case for a combined BIM-CMMI Framework

Introduction

The Architecture, Engineering, Construction and Facilities Management (AEC/FM) industry is almost certainly the only functionally-critical (and highly regulated) industry that builds its prototypes live on the production line. This is mostly still done without the benefits of digital modeling, prototyping and simulations as many peer industries have done (think of the car and aerospace industries for example). The consequences of working without such models are apparent, at times painfully, to anyone who has financed, built, owned, designed or operated a piece of built environment of any size or function.

Other major industries have quickly recognized the immense power of constructing and testing a virtual prototype of their product designs through digital techniques before ‘going live’. This ‘prototyping behavior’ has required an immense amount of effort by these industries to get their act together yet allowed their services and products to be repeatedly delivered to clients with dependable quality, timing and cost. In so many industries, the ability to manage and control an increasingly complex ‘product’ throughout its lifecycle is dependent on highly systemized processes and efficiencies acquired through digital technology.

The BIM Episodes: Episode 8

Episode 8: Understanding BIM Stages

Many industry discussions affectionately expand on BIM’s far-reaching deliverables: seamless collaboration, construction sequencing, shareable databases and fully integrated project delivery. While all these possibilities are foreseen today and are becoming more readily accessible as we speak (type), it is important to understand the deployment road ahead. Such an understanding will help us focus on the task at hand, better allocate available resources and prepare for the BIM-flavoured future.

The previous episode has described the 1^st dimension of the BIM Framework – ‘horizontal axis’ representing AEC players and their deliverables. It is now time to introduce the 2^nd dimension – ‘vertical axis’ of BIM adoption. This episode intends to identify deployment milestones or ‘stages’ that AEC players pass through on their way to fully integrated practices. There are three stages/milestones:

·         BIM Stage 1: Object-based modelling

·         BIM Stage 2: Model-based collaboration

·         BIM Stage 3: Network-based integration

Note that each of these stages is further subdivided into sequential steps. What separates ‘stages’ from ‘steps’ is that BIM Stages are transformational or radical¹ changes while BIM Steps are incremental² ones within them. In this post, we’ll focus our attention on identifying the transformational stages within BIM Nodes. We’ll do that after briefly describing the Pre-BIM status which insistently prevails within the AEC industry.

The BIM Episodes: Episode 7

Episode 7: Understanding BIM Nodes

The confusion in BIM discussions and implementations can be dramatically reduced by systematically analysing the larger-than-life concept. We’ll do that by subdividing Building Information Modelling into its basic components and then relate them back to each other in a – hopefully – meaningful and useful way.

As discussed in BIM Episode 6, there are three dimensions to every BIM discussion. The first dimension is what I term BIM Nodes – BIM circles if you wish – and it’s responsible for identifying industry’s stakeholders and their deliverables. The other two dimensions, BIM Stages and BIM Lenses, will be discussed in following posts.

So what do these BIM Nodes represent and why are they needed?

The BIM Episodes: Episode 6

Episode 6: A systematic understanding of BIM

Building information Modelling can be a very difficult topic to define. Just try to discuss it with a colleague and - more probably than not - you'll end up discussing endlessly overlapping topics. For example, you start to discuss BIM's effcts on industry and you end up comparing software solutions. Or, the topic starts with how to collaborate around the digital model and the discussion shifts to argueing risk-shedding vs. risk-sharing, insurance coverage and design fees. It doesn’t stop there, if you try to explain to how a small-sized company typically migrates from 2D to 3D or implements a basic BIM tool and the conversation shifts uncontrollably to model-servers and complex integrated practices.

SMARTcodes - the shape of things to come...

Building Information Modelling has promised a lot of added-value automation out of a well-constructed object model. After a few years of inflated expectations, it is good to start witnessing an increase in the availability of industrial-quality (as opposed to research-quality) tools targeting the rich data embedded within models. One of these 'tools' is SMARTcodes, an initiative by the International Code Council (a US-body). The ICC has produced a couple of demos intending to show how to "automate code compliance checking":

After registering here, you can participate in a couple of demos: one is labelled 'automatic' where the user theoretically uploads the BIM model (IFC format of course), inputs the location and decides on the code checking engine...The resultant deliverable can be a 'Solibri Model Checker Report' (a PDF document with images, summary table and element compliance list) or a Solibri Model (viewer required). The other demo is labelled 'manual' and relies on the user to input all relevant information into the tool...You can see the section reports being generated in real time and you end up with a printable collated one.

Of course, the automatic version is more BIM-like while the manual version caters for 'model-poor' consultants - an error prone double entry approach if you ask me. It is hard to understand why both approaches fall under the SMART banner - only the automatic approach fulfils the declared mission statement!

In a nutshell, SMARTcodes is a very promising tool indeed and I think it can be extended quite significantly...I look forward to uploading my own model and sifting through the results.

To read a tad more about SMARTcodes, you can start here (PDF Presentation - 967KB) or read the Frequently Asked Questions on ICC's website.