Beyond BIM: Data Driven Construction_Part 3_Data Definition

Third installment of Data Driven Construction, in which I talk about the origin and definition of the Data in a construction project. Where does this data originate? Does it all originate in the BIM Models as they say? Are there other sources? What standard is used? What treatment is given to this Data? How to measure the uncertainty of the data?

What Data is stored in a CDE

In a construction project, a CDE (Common Data Environment) is a centralized repository of project-related data. The data that can be found in a CDE on a construction project can come from a variety of sources, such as:

• Project Documentation: The CDE may contain contents of drawings, specifications, bills of materials, estimates, schedules, reports, etc.
• Design Data: Building information models can be extracted from 3D models, blueprints and others.
• Sensor Data: In some cases, sensors and other devices can be used to collect real-time information about the project, such as temperature, humidity, air pressure, and other environmental and construction factors.
• Equipment information: Information about equipment used on the project, such as heavy machinery, tools, and other equipment, can be stored in the CDE for tracking and maintenance.
• Configuration Management Data: Information stored in the project management platform. From WBS, requirements, risks, deviations, deviations, issues, decisions, change orders, etc.

In short, the data in a CDE on a construction project can come from almost any source, and the key is to ensure that all data is centralized and readable by all members of the project team to facilitate management and decision making.

Structuring the Data

As I just discussed the sources can be many, and as discussed in Article 2: Structures and Tools, the backbone of the entire project is the WBSs | WBSs, to be able to trace the data between different systems, and perform verification when it arrives at the EDC.

BIM is not the Center

I am very much against defining all BIM documents (BEP, MIDP, Quality Plan, etc) as if they will only affect BIM models. I think it is necessary to break with the wrong thinking of "BIMCENTRISM", as was the case with those who proposed the Universe revolving around the Earth.

Therefore, the structuring of the data of a project must be at a higher level, at the project level, and of course not forgetting the BIM part, but not as the origin of everything, because in this way we will generate many free and unnecessary restrictions.

Much of the information generated in a project comes from the design, at least at the beginning, but as the project progresses in its different design phases, even in construction, this information is increasingly "dispersed" in different repositories, platforms or departments. That is to say, no matter how much we want to make measurements and budgets or planning with BIM models, these will be done in other software, where part of the origin of the data comes from the models. The important part is to maintain the information linkage at all times.

Therefore the vision I have of the generation of project data is decentralized, as illustrated in the image, and not BIM-Centric. Each of the centers (where BIM is one of them) are containers of information, which may have been generated by different software. These centers are connected to the CDE.

Level of Data Uncertainty

The higher the level of definition of a project in any of its aspects, the lower the level of uncertainty. For this I consider important the definition of the data strategy, and the definition of its granularity/detail for each of the phases, classified by disciplines or even by categories.

An example is the existing relationship in the data of design, budget, planning and technical specifications. It is important to define all these areas, the level of detail that each of this information must have in each of the areas.

When we review the data in the dashboards extracted from the CDE, it allows us, depending on the time of the project, to take into consideration what level of uncertainty exists and how to interpret that data.

Design Definition Level

Even though the models are not the only source of information, they are a fundamental part of the origin of the data, which is why a good classification of them in early stages is fundamental.

First of all it is essential to create a breakdown structure of Models based on the OBS. The conditions of the project, contracts, planning can condition how we structure the MBS (Model Breakdown Structure) but as far as possible it should be 1 to 1, to the OBS (Object Brakedown Structure).

It is essential to define the classification system on which to work "across the project", so that it is easy for us to classify the elements through a codification. In the case of the Netherlands we are using the NL-SfB.

Once the categories are clear, it is advisable to develop a file for each of the categories, where the content of the design documents should be described in writing, both at the 3D and 2D levels.

But more important is the definition of which parameters should be included in the design documents.

For simplicity, usually in contracts or annexes, and documentation that is shared to other project teams is a simplified summary table.

Design Data Quality Control

We usually start from the client's requirements (in the EIR image). These requirements usually define the design principles of the project, and the basis on which the documentation should be developed.

As explained in previous paragraphs, a table of categories is defined, based on the classification system defined in the requirements.

Once all the categories are described, the MDS (Model Development Specification) is generated, which although it includes the word model applies to all the design elements whether they are modeled or not.

It is a good practice to apply the Pareto 80/20 law in these cases, what does this mean, being aware of the phase in which we are, identify the 20% of budget items that account for 80% of the budget, and focus on them.

What it means to put the focus, it means, to have a higher level of detail definition in the requirements to the designer, but also a higher level of control in the audits for these items.

It is even a very good practice to make specific modeling sheets for these items, where the modeling criteria are defined, so that at the time of extracting the measurements they are as accurate as possible. In the event that some of the main items (within the 20%) are not required to be modeled, it is highly recommended to do so, since the level of control will be much higher.

Finally, an audit plan is defined for the models, technical documentation, measurements and planning, with a level of detail corresponding to the phase of the project and the level of information handled.

Summary

Compilation of some key concepts to date which are listed below:

1. CDE is not an EDMS (BIM 360, Aconex) it is the centralization of the DATA of a project.
2. BIM (understanding it as a 3D model) is not the center nor the origin of everything. BIM is just another input.
3. It is important to define a Disaggregated Structure for the project information from the WBS. In the case of BIM models, the MBS.
4. All XBS structures must have at least one element in common.
5. A data correlation matrix is required, which serves to define the degree of joint and linear variation of two random variables.?
6. Data validation process required after data extraction, through a Prevalence Matrix.
7. Not only reporting, but also Data Analysis.
8. Fundamental to work with a classification system.
9. Define levels of definition/detail according to the stages/phases of the project, to have a good control of the uncertainty of the data.
10. Use of Pareto's law, to define the items to be modeled in greater detail to have a better control over the budget.

I leave you a video of the progress of the A9 project, works carried out during the weekend 7 of 2023, the first phase of the Bypass.

To be continued...Part 4 Reading Dashboards and utilities.