I assumed that I would post this text on the blog repurposing old content into something fresh... and here it is a klops ( as we say in Polish meaning …meatball ) as it turns out that it doesn't get old, it just ages and acquires flavor - it's up to date. This is the full version of the article that was published in a slightly shortened form in Inżynier Mazowsza. I'm publishing it without the polished verbiage as it was originally written - maybe a little emotional…
BIM contract requirements
First of all, I would like to clarify that it is not my purpose to discuss the components of contract requirements documentation such as the LOD table, project roles or communication. A lot of materials have already been written about them in Polish. I want to focus on the most important values that such contract requirements should provide, namely the profitability and purposefulness of using BIM.
BIM Model in fashion
Fortunately, Polish BIM has already passed the introductory period, when contract requirements often included only one sentence about BIM - stating that BIM is to be! Fortunately, we did not go to the opposite extreme of writing multi-page reports describing how the ordered models were made. I do not deny that standardization is necessary, but it is not worth leading to a situation where entire teams have to change developed processes only for the needs of one project.
However, another trend has emerged - the As-Built BIM Model, preferably one for facility management
Suddenly, the client won't pay for the work without it.
The majority of documents or orders for their preparation that have passed through my hands in the last few months concerned the requirements to provide an as-built BIM model with the possibility of using it for Facility Management in the future.
I would like to emphasize right away that the As-Built Model, i.e. presenting the state of the investment at the time of its completion, and the model intended for facility management are extremely different in terms of LOD and LOI requirements.
In fact, the only thing they have in common is the fact that they are used after construction work is completed.
Every time I see such a document, I count on a productive conversation with the future property manager about his needs. It instinctively tries to follow the information exchange cycle suggested by ISO19650-1/2. This means that: lessons from the operational phase of previous projects provide the knowledge necessary to develop requirements for new projects. With a few exceptions, I don't learn much. This is the case even if the investor already has operational facilities and should know what data they use and in what form.
The requirement to provide an as-built model does not directly oblige the designer and/or contractor to use BIM during the development of the project. As a result, the model is often outsourced to the organization based on traditionally developed 2D documentation.
In such a situation, the impact of BIM on the construction process is non-existent, costs are generated and all process participants come to the conclusion that BIM costs money and is not worth it... Only the owner of a model farm, often in India or China, made money. This proves that pseudo BIM implemented for advertising purposes (Look! We have BIM!) is still doing great. The models created in this way will last many years on a dusty medium somewhere in the archive...
Needs analysis first and foremost.
No more whining about problems! How is it done so it pays off ?
Defining contract requirements for BIM is the first and key stage of implementing BIM in the project. The reason for such implementation may be the desire to improve the existing process or the continuation of the use of BIM based on experience from previous projects. Clients who are starting their first project are a separate case.
In each case, analyzing the needs of the organization and the project at the beginning of the implementation process is the most productive and cheapest element of starting the creation of BIM requirements. t is the basis for determining their type and scope.
Creating BIM requirements aims not only to describe models from the perspective of geometric and information requirements (LOD and LOI), the use of software functionalities and project management processes. It is also, or perhaps primarily, supposed to lead to the selection of partners with whom we will carry out the construction project. Partners on whom we will be dependent for the duration of the project. So often several years.
We take risks and we act.
The basis for developing BIM requirements should also be an in-depth and honest risk analysis of our organization and the project we are working on.
I emphasize that the analysis must be honest!
The risks we have and the approach that they are contractually transferred to our contractor, and we are tough and will be demanding (and threaten with lawyers), do not change much. If our designer/contractor/subcontractor messes up, we end up not getting the product and we waste time and money.
The most successful BIM implementations I have had the opportunity to lead started with analyzing lessons from previous projects and trying to avoid repeating the same mistakes.
To have such an analysis, we must first accept the fact that our projects are not necessarily relentless success story. If they were, construction would not lag behind in productivity as compared to other industries . And here we must return to the sincerity of our analysis, which I have already mentioned.
Change - a transitional state
Creating contract requirements for BIM in pilot BIM implementation projects is a part of broadly understood change management in an organization. If the project is a "pilot" for several organizations, the matter becomes more complicated.
BIM requirements for the project should be prepared for such an eventuality. Opening the door to companies wanting to implement BIM in their processes is necessary at this stage of market development - not only the Polish one. Otherwise, we will lose large amounts of professional knowledge. Experience shows that this requires conscious acceptance of some flexibility in the initial phase of the project. However, the adjustment period must be precisely defined in time. The matter may become more complicated in the case of projects subject to Public Procurement Law, where the subject of the contract must be precisely described.
For example Mock up
It is still difficult to say that the scope of BIM requirements can be assumed to be commonly known, as is the case with documentation created in 2 dimensions. Assuming that the other party intuitively knows what we expect is often wrong. To avoid any confusion resulting from this beyond the technical requirements and management, it is good practice to provide mock-ups of BIM models. This applies to both the appointing party and to be appointed parties responding bid . A BIM model mock-up is an example model with a very narrow scope, but enabling testing of the assumptions made in the BIM requirements.
The mock-up gives clarity on how the client expects the BIM model to be prepared, and on the other hand, in what form the designer or contractor will deliver our model and whether it will be usable by other members of the design team and the future user. It also allows you to test software processes, file conversions, and, to some extent, CDE functionality. During my practice, there were several situations where there was a dissonance between expectations based on the description of the model provided and the actual model provided by the contractor.
In summary, all provisions of contractual requirements related to BIM must have in mind the delivery of optimal value of the process and its results at the lowest price.
The implementation of BIM is expected to bring tangible benefits.
