How typical is your project? The need for a no-model approach for information management in AEC

Abstract

This paper discusses the merit of using a no-model approach (no common product models or ontologies, etc.) for managing information in the AEC. It proposes an option for such an approach through the generation and analysis of semantic and social networks of communication between project stakeholders. The proposed approach advocates for a bottom-up discovery of knowledge constructs from stakeholder communication. Knowledge constructs are mini two-mode networks containing, on the one hand, clusters of concepts that appear frequently in the semantic networks of stakeholder communication; and, on the other hand, the social networks of stakeholders discussing these concepts. Using common models (such as IFC) has several limitations, including inflexibility to recognize and accommodate project contexts (which vary constantly), inability to timely capture the emergence of knowledge, and the scope creep problem (the ever-existing need to add more concepts to the common model from within and outside ACE domain). The no-model approach presented here is meant to complement and not replace the established model-based approach. This approach is built on the belief in the ontological agency of project stakeholders: knowledge is a social phenomenon that emerges through interactions between people. It advocates a shift from a top-down format where experts or standards clearinghouses tell (force) practitioners what should be true about their project. In every project, stakeholders customize (the structure of) established knowledge and adopt elements from emerging knowledge to address project-specific needs. They use the more superior intelligence (the human one) to innovate a ‘model of what they know’ to guide the management of the project in a manner specific to its context. By studying projects’ communication, we tell (inform) project stakeholders what knowledge constructs can be found in their communication. Unlike generic/static models, the resulting knowledge constructs are by default sensitive to project conditions. We should re-design our information management systems to be able to recognize and adaptively use the constructs established by project teams to facilitate their sharing of data (along with the established scheme, such as IFC). Relatedly used constructs can be nominated as AEC-wide prototype constructs, representing what we know about a typical project. At the initiation of a new project, these can be the starting scheme used by information and communication systems. As the project evolves and the project's own constructs are generated, the project-specific constructs should guide the flow of information. Contrasting project constructs against prototypes should inform the stakeholders of not only what is factual about their view/model of knowledge, but also how unique are they (from generic/base knowledge). This approach to no-model thinking is advantageous for several reasons. First, addressing the model rigidity problem. Because of the increasing complexity of projects, no single/standardized model can capture all contexts. Second, the increasing need for handling project unstructured data. The proposed approach helps formalize knowledge constructs from such data using network science. Third, recognizing and tracking the evolutionary nature of knowledge. Fourth, supporting innovation: instead of forcing knowers (people) to comply with a static model of reality, the new approach encourages them to imagine new possible futures/ worlds—after all, the true essence of digital twinning is to virtualize futures not just to digitize the present.

A Literature Review of BIM Definitions: Narrow and Broad Views

“…Value in lean processes always comes from the end user, and defining value is one of the first, necessary steps of action in this methodology. Furthermore, because digital twinning is about virtualizing whole futures, our knowledge capture and information management systems must be scaled from the product level to the project level and even the asset life cycle level [54].…”