BIM projects can go bad?

We received feedback after our last post on rescuing difficult BIM projects from a number of people asking us to expand on the tell-tale signs of bad BIM. Before diving into this topic, the first thing we need to address is the fact that, shock horror, BIM projects can go bad. Most people that have been working with BIM over the past number of years realise it isn’t a panacea. Unfortunately we still find BIM is being sold to project clients and AECO professionals as a cure all for project woes. We see people, process, and technology as the three components of BIM that need to be aligned in order to work. To break it down a bit further, we see 80% of the effort and risk associated with BIM implementation relating to people and process. With all of that risk locked up in the most challenging aspects of project and organisational management, it shouldn’t be a surprise that BIM is difficult to get right.

With that background in mind, on to the main topic. Once BIM goes bad on a project, it needs to be rescued and this incurs cost on projects. Like all rescue attempts, the longer bad BIM is let to run on a project, the harder it is to get back on track. So how do you know BIM is going bad? We have highlighted a number of metrics that can be used to test projects, or more importantly act as early indicators for potential BIM difficulties. These are qualitative metrics that should be seen as alarm bells to identify potential problems, which require a more quantitative assessment to determine real project impacts.

The Unlucky 13 Signs that BIM is Probably Going to Go Bad

1. There are no (or poor) Employers Information Requirements documented for the project – It’s tough to deliver on something when you don’t know what it is that you are meant to deliver. BIM projects without a clear scope of information deliverables are starting off on the wrong foot. If an EIR isn’t produced, expect a free for all that can be difficult to reign in.
2. Nobody is formally tasked with managing project information – While BIM presupposes a collaborative approach to project delivery, someone needs to formally take a leading role. Without someone in charge from a project team perspective, deliverables and engagement with BIM will be inconsistent.
3. A BIM Execution Plan is not in place – Similar to a missing EIR, it is difficult to work within a process if you don’t know the rules of engagement. Projects without a BIM Execution Plan, often result in uncoordinated model production, information sharing, and deliverables
4. There is no formal commitment to use a BIM process on the project – We have seen a number of projects where members of a project team informally commit to BIM when it isn’t a project requirement. As project resources and schedules are put under pressure, a systematic reneging on early stage promises follows. Without a formal commitment to BIM, the project is open to the excuse ‘well BIM isn’t a project requirement anyway’. When this card is played, information dependency risks have become a reality.
5. Rouge information transfers are taking place – Usually sharing information is a good thing. It means people are being given the information they need to perform. However, unexpected information transfers can be detrimental to project teams. When team members operate outside the plan of action, confusion and distrust is not far behind.
6. BIM coordination workshops become unproductive – We have seen this issue come in two forms, workshops that don’t accomplish anything and others that are hijacked. Useless BIM coordination workshops are typically down to decision makers not being present, meeting room technology failure, unprepared or unwilling participants. While BIM is integrated with design and construction processes, time does need to be dedicated for model coordination. BIM coordination workshops that become overridden by other project issues delay project problems from being solved.
7. New technologies are being introduced without project consideration – Interoperability challenges and technical capability deficiencies are BIM risks that can be managed, but require time and effort to overcome. If new technologies are being introduced without consideration to wider project impacts, time will be continually wasted trying to deal with unintended consequences. A common example is one project team member upgrading the version of their model authoring software, which is not backward compatible. Time and effort is then wasted in dealing with an interoperability issue that didn’t previously exist on the project.
8. Information transfers are infrequent or non-existent – Better decisions are made when more information is available to the project team. If weeks are flying by without information being transferred between project team members, then dependency related risk increase. The result is uncoordinated project information and deliverables.
9. Levels of Detail (LOD) and Information (LOI) are not aligned with the current work stage – A misalignment between the Level of Detail and Information in BIM outputs is usually detected at project milestone reviews. Similar to a lack of information sharing, the risk here is team members acting on information that is incomplete or invalid. In order to pick up this issue earlier than a milestone review, we encourage teams to include LOD and LOI parameters for all model elements. Model LOD and LOI can be measured for each information transfer.
10. Project team members are reverting to non-BIM processes – When non-BIM outputs start to show up at project meetings, deliverable packages, or information transfers, the yellow caution flag needs to be raised. The root cause for reverting to traditional production methods is usually a lack of capability or capacity. The longer this issue goes on the harder it becomes to get information back into the BIM process.
11. The “but it’s in the model” argument – The flip side of reverting to non-BIM processes is a fire and forget approach to modelling. If a disagreement includes a “but it’s in the model” type argument, it is a signal that communication is not as effective as it should be. Sharing updated models is important, but revisions need to be communicated to ensure knock on impacts are picked up by all team members.
12. There is a negative sentiment towards BIM within the project team – This is an obvious one, but it is often ignored. Negative attitudes toward BIM can spread like wildfire if left unchecked. There can be a variety of legitimate reasons for negative comments and complaints to arise on BIM projects. Rework is one example that often comes up in conversation before being implemented. When a particular issue, such as rework, is raised, it should be explored further and corrective action taken before a BIM technology blame game ensues. The issue may in fact be a technology related, but there is a risk that the root cause is people or process, which will be missed if the focus is purely on technology.
13. BIM related issues are not being highlighted by the project team – If everything is running completely smoothly, then something must be wrong. Modelling approaches and techniques vary depending on how information is to be used on projects. Project teams that are not having issues with the model object content, creation, or coordination are most likely not engaging with the process fully. BIM processes are not perfect and require refinement as project progress. Without feedback from project participants, the process cannot be improved and associated risks remain.

As noted above, these are red flag metrics rather than measures of performance. Once the signals are read, the next step is to investigate and do something about them.