Workshop 3: Calling Bullshit on BIM

Workshop 3 - 31 October 2023 : Calling Bullshit on BIM

Facilitated conversations

Mode: Unconference style

Objective: The 3rd CoDE•SA workshop will look at the hurdles / challenges / pain points we anticipate in the national BIM journey, through a “CALLING BULLSHIT ON BIM” approach

Pain points/challenges hurdles to be addressed, as identified by the People. These pain points are grouped and reported under three Digital/BIM implementation fields: People, Process/Policy as well as Technology. Each delegate identified a field of interest from the three and formed 3 groups.

The discussions around the table were centered around:

Further detailing the pain points
Possible interventions/solutions

The collection of the reports is planned to inform the policy development by the CIDB, happening in parallel to the BIMCommUnity Africa industry engagement events.

These conversations are recorded below.

Background: The current process with the adoption of ISO 19650 is as follows:

ISO 19650 parts 1 (principles) and 2 (Construction) have been published as a SANS standard. Part 3 (Operations) comment period has closed and should be published as a SANS soon. Cidb is interested in supporting the drafting of the National Annex and a protocol but this is a while off. This lack of clarity coloured much of the conversation. There was very little pushback on the value of BIM as a technology, just on the way it is likely to be implemented.

Concern was expressed about the need to clarify BIM’s role before tendering for a project. The lack of proper briefing from the client and the imposition of new requirements only once the project documentation was underway. These are covered in the Process outlined in ISO 19650 and needed to be supported in the development of the National Annex. This is a valid concern as the clients do not get very involved in the briefing of project teams. The role of developers and their project managers in making hard ‘bargains’ focused on reducing fees also played a role.

It was felt that there was little incentive to introduce BIM into projects as it did not tie in with existing frameworks (Contracts, particularly PROCSA, in use) The long-term benefits were also not properly understood or explained to project teams. There was some concern that enforcement would be very one-sided and put unreasonable pressure on project teams. (Lack of Client understanding of their role and responsibilities)

The discussion also addressed the ROI of moving to BIM, forced by the market or willingly adopting a new technology and maximising its potential. Here the actions of the BIM Champion were seen as critical. It was felt that having someone of the same discipline who had the responsibility of easing the introduction of BIM into the practice and providing support to colleagues working with it was critical.

On the point of creating a local need, the necessity of having a predictable and stable process and procedure in support of an accepted policy would lead to wider adoption and acceptance.

There is a lack of experience in BIM Projects where ISO 19650 plays a role and how this will impact the market for any understanding beyond genuine concern.

There was also little understanding of how workflows need to change with a BIM project. During the discussion, the role of having a BIM Champion within the company's structure is to support the rollout of the technology and processes as to simply learning about the software’s capabilities.

This was understood to cover families and libraries that are shared and introduce the benefits of the reuse of components in speeding projects and saving rework costs. A BIM Manager was seen as having a project-based responsibility across disciplines and not helpful in an upskilling role within the team.

Without understanding the organisational workflow, human resources, resources and strategy, it is easy to assume that technology may be expensive. During the discussion, it became evident that the focus is on the upfront cost of technology and less on the impact a tool such as software can have, supporting workflows and enabling companies to do things they haven’t done before. Be that faster processing, more accuracy (or less human error), meeting deadlines, or being more profitable on projects.

The discussion started to unpack the focus that could help companies generate greater internal and external value from adopting technology and position them as trusted advisors on projects rather than service delivery experts. It starts by creating a demand (Establishing a well-documented EIR that cuts the risk of over promise and under deliver) and ensuring that your information needs are documented and explained. From here, assign the correct resources to the correct levels and ensure they have the skills to meet your EIR requirements. There was a fantastic recommendation that a RACI matrix (Responsible, Accountable, Consulted, Informed) be created, giving a clear picture of the demand and the requirements and thus eliminating some of the surprises.

The conclusion was that if you don’t understand the impact technology will have on your existing company structure, workflows, workforce and hardware, then the assumption that technology is expensive will remain. Instead, change the perception that technology is an enabler (There is always an investment cost) for the company to deliver on promises and bottom line.

Technology does have significant advantages that can be of great benefit, but deploying it incorrectly can/will have a detrimental effect on the business or the execution of the project. For that reason, it is far more important to understand the impact it may have as different people find themselves at different stages of the Technology Adoption Curve.

Technology will always be expensive if there is no understanding of how to use it to make money. The application of technology can either drive additional profits (Open revenue streams that were previously not an option) or become more profitable (Being more efficient by reducing errors, streamlining processes or automating repetitive actions).

We looked at the various comments that were presented and decided to group them under a generic heading Change Management.

It was a perception by the younger generation that the older generation were stifling progress with BIM, mainly due to a resistance to change. This may be due to a lack of understanding of the new technologies, or just not wanting to change traditional workflows. The younger generation put forward the idea that possibly BIM workflows should be mandated and even legislated.

The lack of not wanting to change workflows may also be because there was a lack of clear understanding of benefits of working within a BIM workflow.

In some larger organisations, it was felt that people worked within “silos”, not wanting to collaborate and therefore protecting their own knowledge silo.

It was felt that there was also not an awareness of the need to change and work within a BIM workflow. It was suggested that perhaps the ADKAR model for Change Management might be appropriate.

A - Awareness: People needed to be made aware of the need for change
D - Desire: People needed to meaningfully and actively participate and support the change
K - Knowledge: Knowledge of how to change - acquire new skills and learn new workflows
A - Ability: Ability to implement new skills and changes in behavior
R - Reinforcement: Reinforcement to sustain the change - look back at progress critically and implement steps for a more successful future to ensure sustainability of the change

It was further felt that the traditional methodology of determining the feasibility of anything new in the industry was difficult to conduct when considering BIM before implementation.

Traditional methodology e.g. a cost-benefit analysis is difficult to conduct if the costs are certain but the (financial) benefit remains uncertain. For example: It is easy to conduct a cost-benefit analysis on installing a solar plant as the energy that it will provide can be measured/closely estimated upfront. Yet improvement in customer experience/satisfaction is not easy to measure upfront (before implementation). The same can be said for improved workflow processes that should save time and costs, predictive maintenance, etc.

Therefore it was suggested that the BIM community could provide Case Studies of the real-world (proven) benefits of BIM to assist with the ADKAR model of change management and to drive the adoption of BIM and the adaption required to implement BIM.

Case studies should focus on:

Cost saving
Time-saving
Environmental benefits
Client experience improvement

Case studies should include all the different phases of the project life cycle:

Conception
Planning
Design
Costing (and feasibility study)
Construction
Tenanting and Occupancy
Operational
Refurbishment
Re-design and re-development

With evidence of the advantages of BIM, the typical uncertainties in the industry that prolong resistance to change could be addressed.

In addition, tertiary institutions could be motivated to educate the younger generation in the Built Environment on the BIM workflow and provide the knowledge and skill sets required for BIM. When this generation then enters the workplace, they will be suitably qualified, skilled and employable globally.