The Cone of Uncertainty

I recently sat in a call for a project where two separate cost consultants where being given the opportunity to engage the BIM process and take advantage of any model-based data they could derive. The client was allowing them some time to engage the process and use the project as a pilot to identify their own gaps, whatever those may be.

After some talk, a leading voice emerged making the claim that the traditional method would be preferable as it would be the fastest. The comparison focused on expediency to produce the same product that was required by industry standard and their scopes. Based on these parameters, this person was probably correct. The chips were stacked against the new process as the lack of experience in the tools alone would doom the surveyors to a slower process than usual.

These parameters, however, failed to make a true comparison since the two products would be fundamentally different. The traditional method would lead them to a reasonably accurate pricing estimate, but with some considerable allowance due to uncertainty. The new process would require this allowance as well, but the introduction of the transparency afforded to us by a design model being made available should move the needle.

In software development project management, the Cone of Uncertainty represents the ‘…evolution of the amount of uncertainty during a project.‘ (source) The premise is that at the onset of a project, little is actually known about what the product will look like in the end and how it is going to be made. As we move through the process of design and development, decisions are made, paths are selected until eventually unknowns ‘…decrease, reaching 0% when all residual risk has been terminated or transferred. This happens by the end of the project i.e. by transferring the responsibilities to a separate maintenance group.’

Source: modernanalyst.com via Federico on Pinterest

The same article states that “Most environments change so slowly that they can be considered static for the duration of a typical project, and traditional project management methods therefore focus on achieving a full understanding of the environment through careful analysis and planning.” This strikes a clear parallel with the traditional design stages of the design delivery process. A lot of work is done through design development and construction documents to more clearly define a building’s scope of work. ‘Careful analysis and planning’ is done, sometimes for years, to come up with a set of specifications and drawings that will act as the basis for design in the bidding and construction phase. 

It continues “Well before any significant investments are made, the uncertainty is reduced to a level where the risk can be carried comfortably.” It stands to reason then that a rich source of insight into the designer’s intent – as is the model – would go a long way to move the dial farther to the right in the above graph. Even in a model of poor craft, having a clear understanding of the ‘gaps’ in the design is of value.

Model and data driven approaches to studying how a model was built and the intent behind it then should derive a richer context for the quantity surveyor, essentially ‘de-risking’ the estimating process by increasing transparency and democratizing access to information.

The person described above identified risk in the many unknowns that came with the new process and new information, and would act to mitigate that risk by recommending we don’t engage it. Instead, he should see the opportunity to provide a more complete estimate at an earlier time in the project schedule. Essentially, a more complete estimate, earlier in time and with less unknowns. This, regardless of whether a model existed, should be at the core of their research and development efforts internally. In this case, they are being given the opportunity to work with a client jointly on that R&D. I hope they take that chance.

Delivering BIM for FM isn’t without cost

Don Rudder, our CTO and I presented at RTC recently on our recent work implementing BIM for FM solutions. The presentation focused on what we’ve learned over the past year or so implementing custom workflows and tools within two hospital systems, the Porter Replacement Hospital in Porter, Indiana, and Children’s Hospital in Birmingham, Alabama. Both of these projects were done with the Contractor as a client, not the owner. In both cases, the contractor was acting as a proxy to the owner in helping them get the most out of what BIM they had developed to date, for downstream use during operations. I also want to point out that both projects are the brain child(ren?) of Aaron Wright, Hoar Construction’s BIM Director. It’s been his dedication to figure out the real application of a construction model during FM that brought us on board on both of those jobs.

Although very different, both projects faced similar issues: purpose built models not quite meeting necessary requirements for FM use; model craft required for coordination is different than that required for FM; information requirements for one is not the same as the other, etc. The list goes on… In any case, we knew there was value in there, we just needed to figure out how to squeeze it out, or better yet, how to repackage it to make it useful downstream.

Probably the more interesting development in all of this was that many of the more common issues weren’t issues at all, but instead general misconceptions about BIM and its utility over the lifecycle of a building project. One of these misconceptions was:

The only cost associated with BIM is its creation

This statement supposes that once you have a model, you’re done. This is a huge industry problem right now and is causing a lot of unnecessary friction. First, it falls into the usual trap of thinking BIM is a product and not a process. Off the bat, you’re thinking that the cost of BIM is finite and that once you’ve paid for a model, you can move on to the next item on your list. This is very much incorrect, and misses the point on a lot of the potential value to be derived. Yes, there is a cost associated with modeling, but the model is only a part of the process, not the end in itself.

The big misconception, then, is in thinking that there is no cost to maintain a model.  Again, if BIM is a process, then the process itself has a cost. If the product of a Construction BIM process is to be used during an FM BIM process, then one needs to budget for two things: first the translation of the construction BIM to something useful in FM, and second, the process of maintaining that BIM over the lifecycle of the facility.

BIM during FM should be dynamic and constantly learning about day to day facility operations.  If it is not, then you will quickly find its value degraded to no more than a ‘snapshot of the facility at the end of construction’. Over time, there will be enough difference between the physical facility and the virtual one that BIM will be set aside and lose its privileged position within day to day operations.  That moment marks the death of a model in most cases.

If you want to learn more about cost, effort and value of BIM, I recommend you read Mario Guttman‘s The Information Content of BIM