44. Information Management Cycle


Information Management Cycle v0.3 (Full-size Image)

This high-level conceptual model describes the Information Management Cycles that Structured Project Information pass through [1]. Each Cycle includes three Information Management States, separated by varied Information Management Activities conducted by specialised Information Management Actors:

Information Management States

The three states describe how Structured Project Information can be experienced as either:

[A] Information Requirements: project specifications, protocols or similar that identify what needs to be generated by project stakeholders. Information Requirements can be represented as a set of Document Uses, Model Uses and Data Uses.

[B] Digital Deliverables: digital simulations of physical objects and how/when they’ll be constructed or fabricated. Digital Deliverables can either be documents (in digital format -e.g. CAD drawings or a PDF furniture lists), models and/or data sets.

[C] Physical Assets: information embodied within real world objects similar to whole facilities, a building, mechanical system, heating unit, or a single pump.

Information Management Activities

The transitions between these Information Management States are represented as either forward or reverse activities. Forward Cycle Activities refer to the actions executed to cross from one state to the next; while Reverse Cycle Activities refer to the measurements made to examine one state against its preceding one. Sample activities [2] are provided below:

  • Forward Execution Activities from [A] to [B]: the activities typically conducted during a project’s Design Phase which includes the planning and specifications sub-phases (e.g. drafting, drawing, detailing, and modelling); and
  • Reverse Measurement Activities from [B] to [A]: the activities necessary to verify or validate digital deliverables against information requirements (e.g. checking floor areas in a BIModel against a client’s spatial requirements).
  • Forward Execution Activities from [B] to [C]: all the activities typically conducted during the Construction Phase which includes construction planning and commissioning (e.g. laying floors, mounting ceilings, and painting walls); and
  • Reverse Measurement Activities from [C] to [B]: the activities necessary to test and confirm physical outputs against digital deliverables (e.g. checking the placement of duct hangers on site against relevant models or mechanical shop drawings).
  • Forward Execution Activities from [C] to [A]: all the activities typically conducted during the Operation Phase which includes management, maintenance and decommissioning (e.g. cleaning rooms, repairing down-pipes, replacing roof tiles); and
  • Reverse Measurement Activities from [A] to [C]: the activities necessary to capture data pertaining to a physical asset or to monitor the performance of a physical system (e.g. data capture through laser scanning and data monitoring through sensors).

Information Management Actors

The Information Management Activities separating Information Management States are conducted by actors which are either humans and/or computers. There are three main actors who operate throughout the Information Management Cycle:

  • Design Information Management Actors: executing the transition from Information Requirements to Digital Deliverables and measuring (e.g. verifying or validating) how well Digital Deliverables match with Information Requirements;
  • Construction Information Management Actors: executing the transition from Digital Deliverables to Physical Assets and measuring (e.g. testing or confirming) how well Physical Assets match with Digital Deliverables; and
  • Operation Information Management Actors: executing actions applied to Physical Assets (e.g. operating, maintaining and decommissioning). Also these actors can either (a) measure - e.g. capture or monitor - how well a Physical Asset matches with the Information Requirements covering the asset (within the same Information Management Cycle), or (b) measure one or more Physical Assets in order to generate new Information Requirements within a new Information Management Cycle.

Actors may overlap and replace each other. Depending on the current state of technologies, processes and policies within a market, two or even one Information Management Actor may be able to complete all execution and measurement activities across an Information Management Cycle [3].



The following colleagues have provided improvement suggestions to an earlier version of this model: AProf. Sheryl Staub-French, AProf. Julie Jupp, Ms. Marzia Bolpagni, and Mr. Victor Roig Segura. Thank you to all.



[1] Each Information Management Cycle has a nominal start (e.g. information covering the design of a new physical asset) and a nominal end (e.g. information decimated through the demolition of an asset). However, it is possible and even probable that the same information would persist over a number of Cycles (e.g. through iterative renovation of the same physical asset).

[2] Activities are a subset of ‘Relations’ within the Conceptual BIM Ontology.

[3] This model is part of the BIMe Initiative Integrated Information Platform project

43. Product Development Diagram

BIMe-Initiative-Product-Development-DiagramBIMe Initiative Product Development Diagram (full size image)

This diagram illustrates the process of delivering a BIMe Initiative Product (a Published Guide or a Software Application): a Top-Level Project must be first launched. Each Top-Level Project typically includes both existing components (e.g. a taxonomy or a classification) and new components. Existing components are (a) selected from the Knowledge Object Library, a public resource available through BIMexcellence.org. New components (e.g. a framework or a software module) are (b) generated by BIMe Members through Micro Projects. Once completed and validated, all components are (c) packaged into a new BIMe Product. Once tested and verified, the new product is (d) released through the Product Library (a webpage on BIMexcellence.org) and all newly generated components are (e) added to the Knowledge Object Library for future reuse. As opposed to the Knowledge Object Library and the Product Library, which are both publicly available resources, the generation of new components and end products are conducted within the Project Space (wiki pages, chat rooms and physical meetings) which are accessible to BIMe Members and invited international collaborators.

To understand Conceptual Components (also referred to as Conceptual Constructs), please review the Conceptual Hierarchy and - as an example - how components populate the Research Continuum. Also, for more information about BIMe Initiative products, projects, and how they are managed, please refer to 103in BIMe Initiative Projects.

42. BIMe Initiative Knowledge Structure

image from www.bimframework.infoBIMe Initiative Knowledge Structure (full size image)

This model represents the Knowledge Structure which the BIMe Initiative (BIMexcellence.org) is reliant upon to deliver interconnected software applications, guides, conceptual structures and learning materials. The Knowledge Structure is composed of five complementary Knowledge Sets:

  • KS1 Knowledge Foundations represents all the research supporting the BIMe Initiative;
  • KS2 Knowledge Blocks represents the modular language developed/used by the BIMe Initiative to define inputs, processes and outputs;
  • KS3 Knowledge Tools represents all the digital and analogue tools/templates used to conduct knowledge acquisition, engineering and sharing;
  • KS4 Knowledge Workflows represents all repeatable procedures for knowledge acquisition and service delivery; and
  • KS5 Knowledge Views identifies the varied ways the BIMe Initiative activities and deliverables can be represented and communicated.

The Knowledge Sets and their subsets form the bases for all BIMe Initiative Projects (refer to 103in); organise the activities of the BIMe Initiative Network (refer to 104in); and allow the development of an expansive Knowledge Object Library.

41. Macro Diffusion Responsibilities

This conceptual model (Figure 1) identifies nine BIM player groups (industry stakeholders) distributed across three BIM Fields (technology, process and policy) as defined within the BIM Framework. The nine player groups are: policy makers, educational institutions, construction organisations, individual practitioners, technology developers, technology service providers, industry associations, communities of practice, and technology advocates.

image from www.bimframework.infoFigure 1. Macro Diffusion Responsibilities v1.0 (full size, current version)


The nine player groups belong to either BIM Field or their overlaps. Pending further research, the tenth player group at the intersection of the three fields is intentionally excluded from this model. Table 1 below provides a succinct description of each player group followed by how this subdivision can be used in evaluating BIM diffusion within and across different markets.


Macro-Diffusion-Responsibilities-TableTable 1. Macro Diffusion Responsibilities matrix (player groups with sample players – market scale)


Each of the nine player groups identified in Figure 1 includes a number of player types. For example, player group 3 (construction organisations) is composed of varied player types including: asset owners, architects, engineers and project managers. Also, player group 4 (individual practitioners) is composed of professionals, associated professionals and tradespeople. These distinctions between player groups, player types and unique players (e.g. a specific person, group, association, company or university) allow the targeted assessment and comparison of stakeholders’ involvement.


Below is a short video explaining the above, as available on the Framework's YouTube channel:



Please note that the above model and table are part of five macro adoption models collated within "Succar, B., & Kassem, M. (2015). Macro-BIM adoption: Conceptual structures. Automation in Construction57, 64-79". Download full paper from here: http://bit.ly/BIMPaperA8

40. Project Information Taxonomy

The Project Information Taxonomy extends the Modular Requirements Clarification Language first introduced in Paper A10 . The taxonomy currently includes 21 concepts/terms (14 are new) to be used in defining project information requirements within mission-critical documentation (e.g. within an Employer’s Information Requirements (EIR), a BIM Management Plan (BMP) or similar).

Project Information includes both Unstructured Project Information and Structured Project Information:

  • Unstructured Project Information refers to non-computable data, undocumented, and temporary project information (e.g. hand sketches and casual phone chats); and
  • Structured Project Information refers to information organised and formatted for particular purposes or use cases.

Project information can be represented, stored or exchanged as either Documents, Models or Data. These three Information Representation Types can be mapped against a number of new Information Management concepts – including: Information Delivery Format, Information Uses, Information Views, Information View Definitions, Information Viewers and Common Information Environments.

This is clarified in the below table, a ‘flat’ representation of the Project Information Taxonomy (slightly updated Nov 29, 2016):

Project Information Taxonomy - Table

INFORMATION REPRESENTATION TYPE How information is represented


A physical or digital medium (e.g. a paper or an email) carrying a variety of Information including text, Data (e.g. hexadecimal code) and embedded Models (e.g. a 3D PDF document) [Partially adapted from ISO 14050:2009 and ISO 9000:2005][1]


A digital three-dimensional representation of Information. A 3D Model may embed or reference both Data and Documents. The term ‘Model’ refers to both digital and physical models (e.g. a 3D printed shape) but does not refer to financial, mathematical or conceptual models…Also refer to BIModel[2]


A reinterpretable representation of Information which can be collected/parsed with or without the human actor. Data is either statically embedded within Documents and Models or drive their dynamic generation/modification [Adapted from ISO/IEC 2382-1:1993][3]

INFORMATION DELIVERY FORMAT How information is - or need to be - delivered on a project

Documented Project Information[4]

Project information collated within Documents for functional purposes. Documented Project Information are captured and exchanged either manually or through digital means, and are intended for use by the human actor (e.g. drawings, maps and reports)

Modelled Project Information

Project information collated within Models for functional purposes. Modelled Project Information are generated by the human actor or driven by machine-captured data (e.g. structural analysis and asset tracking)

Structured Project Data

Granular project information collated within Documents and Models, or driving the generation of Documents and Models; Structured Project Data are captured through sensors and scanners; derived from connected data sources; or generated through machine learning

INFORMATION USE The intended uses/applications of project information

Document Use

The intended or expected project deliverables from developing and exchanging information through Documents.

Examples: Master Plan Drawing or Minutes of Meeting.

Model Use

The intended or expected project deliverables from generating, collaborating-on and linking Models to external databases.

Example: model-based Urban Planning or Lighting Analysis.

Data Use

The intended or expected project deliverables from generating, exchanging and manipulating Data.

Example: Fabrication Scripting, using code to drive cutting, milling or sintering equipment.

INFORMATION VIEW How project information is represented to enable its use

Document View

A view representing one or more Document Uses. A Document View can be a drawing, schedule, report, an instruction memo or a set of specifications. A Document View may be analogue or digital, developed manually or derived automatically from a Model or Data source.

Example: A Room Data Sheet

Model View

A view representing one or more Model Uses. A Model View can be a static 3D view, an animation, a holograph or a 3D print. A Model View follows the specifications within its corresponding Model View Definition or reflects unique project requirements

Example: A Model View showing only Mechanical and Structural elements

Data View

A view representing one or more Data Uses. A Data View can be a code snippet, a Computer Numerical Control (CNC) file, an XML file or similar information not primarily intended for the human actor.

Example: An If This Then That (IFTTT) recipe or a visual script in Autodesk Dynamo

INFORMATION VIEW DEFINITION How Information Views are defined to enable the consistent use of Structured Project Information

Document View Definition

A specification which identifies the contents, attributes and formats of Document Views. Document View Definitions are typically generated by authorities and large clients.

Model View Definition (MVD)

A specification which identifies the properties and specifies the exchange requirements of Model Views. A 'standardised' Model view Definition (MVD) can be a subset of an established schema (e.g. the Industry Foundation Classes) and is typically intended for software developers (not end users) to implement into their BIM Software Tools.

Example: the IFC4 Design Transfer View by buildingSMART International

Data View Definition

A specification which identifies the properties and specifies the exchange requirements of Data Views. Data View Definitions are generated by Project Participants to formalise their data exchange scenarios

INFORMATION VIEWER The software allowing access to Structured Project Information by a solitary user

Document Viewer

A software application allowing users to inspect and manipulate of Structured Project Information according to pre-set Document Views.

Example: A PDF reader or a 2D CAD viewer

Model Viewer

A software application allowing users to inspect and navigate Modelled Information according to ad-hoc or standard Model View Definitions. As opposed to Model Servers, Models accessed by a Model Viewer are read-only and cannot be modified.

Example: Autodesk Navisworks or Solibri Model Checker

Data Viewer

A software application allowing users to inspect and manipulate data according to pre-set Data View Definitions. An example of a Data Viewer is an online project dashboard merging data from several sources

Example: Google Flux or Autodesk Forge Viewer

COMMON INFORMATION ENVIRONMENT The digital environment  allowing access to Structured Project Information by multiple concurrent users

Shared Document Environment

A central source for Documented Project Information. A Shared Document Environment is not necessarily a single software tool but a combination of several software solutions – including: a Document Management System, a Document Viewer, a Model Viewer, and a Project Management software. A Shared Document Environment may connect several software tools and desperate data sources through middleware and plugins

Federated Modelling Environment

A central source for Modelled Project Information used to collect, store and allow controlled access to model-based information by project/asset stakeholders. A Federated Modelling Environment differs from a Shared Document Environment by allowing the isolation of Structured Project Information by Model View

Integrated Data Environment

A central or distributed repository of Integrated Data feeding from multiple data sources and information systems across disciplines and domains. An Integrated Data Environment allows manipulation of data by multiple stakeholders according to access rights and agreed Data View Definitions


More info

This post is part of the of an ongoing effort to clarify the language used (or to be used) in defining project requirements within Noteworthy BIM Publications. Some of the concepts introduced above are still being refined, connected and reconnected to multiple models, taxonomies and classifications. For an update-to-date description of these concepts and their relations, please refer to respective terms within the BIM Dictionary.



[1] A document refers to “information and its supporting medium” [i.e. when the information is placed on a medium, it becomes a document] … “The medium can be paper, magnetic, electronic or optical computer disc, photograph or master sample, or a combination thereof” – [SOURCE: ISO 14050:2009, 4.5 - adapted from ISO 9000:2005, 3.7.2]

[2] Another definition is a “representation of a system that allows for investigation of the properties of the system” [SOURCE: ISO 29481-1:2016(en) Building information models — Information delivery manual — Part 1: Methodology and format]

[3] “a reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or communication, or processing” [SOURCE: ISO/IEC 2382-1:1993, Information technology — Vocabulary — Part 1: Fundamental terms.01.01.02]

[4] Note: Documented Project Information should not be confused with Documented Information which is defined in ISO 9001:2015 as meaningful data that is required to be controlled and maintained by the organization and the medium on which it is contained (Source: ABP Consultant)

39. Model Uses Taxonomy

Model-Uses-TaxonomyFigure 1. Model Uses Taxonomy (Full Size)

The Model Uses Taxonomy organises Model Uses into a tiered structure that allows: (a) collation of Model Uses from across different industries; (b) close alignment with the Competency Taxonomy (Succar et al., 2013 - http://bit.ly/BIMpaperA6); (c) custom use-cases for unique projects; and (d) future expansion towards whole of life cycle classifications.

The Model Uses Taxonomy includes 3 Categories and 9 Series:

Category I: General Model Uses represent all Modelling Information as applicable across various knowledge domains, industries, and information systems. General Model Uses are organised a single Series, General Modelling (1000-1990) and include the word ‘modelling’ in their name to differentiate them from other categories (e.g. Audio-visual Systems Modelling or Urban Modelling);

Category II: Domain Model Uses represent industry-specific Modelling Information. The Construction Domain Model Uses are organised in seven Series:

CATEGORY III: Custom Model Uses are a combination of General and Domain Model Uses to respond the non-typical requirements of a specific project. Custom Model Uses are organized under a single Series, Custom Modelling (9000-9990) - e.g. Modelling security systems for a correctional facility.

 Please Note:

  1. The Model Uses Taxonomy was published as part of  BIM ThinkSpace Episode 24 (Sep 9, 2015).
  2. Please also refer to earlier post: Model Uses Conceptual Structures (Sep 9, 2015)
  3. There are currently 125 Model Uses across all categories and series (as of March 24, 2016). For a full list, please refer to BIMexcellence.org/model-uses.

38. Conceptual Reactor


The BIM Framework Conceptual Reactor v1.0 (full size, current version)

The BIM Framework Conceptual Reactor explains how existing conceptual constructs – terms, classifications, taxonomies, models and frameworks – are used to identify, explain and test new constructs.

The conceptual reactor thus allows the BIM framework to be continuously extended according to evolved research aims and objectives - represented as input 1 (or 'in1'). By integrating existing conceptual structures (in2) with new knowledge gained through literature reviews, and data collection (in3), the reactor can then generate new conceptual structures (output or ‘out’) after passing through an iterative, three-stage theory-building process. This process has been identified by J. Meredith (1993) (J. R. Meredith, Raturi, Amoako-Gyampah, & Kaplan, 1989) and includes three repetitive stages - description, explanation and testing:

  • First, the Description Stage develops a description of reality; identifies phenomena; explores events; and documents findings and behaviours;
  • Second, the Explanation Stage builds upon descriptions to infer a concept, a conceptual relationship or a construct; and then, develops a framework or a theory to explain and/or predict behaviours or events. In essence, the explaining stage develops a testable theoretical proposition which clarifies what has previously been described; and
  • Third, the Testing Stage inspects explanations and propositions for validity; tests concepts or their relationships for accuracy; and tests predictions against new observables.

37. Model Uses - Conceptual Structures

Model Uses are the “expected or intended project deliverables expected from generating, collaborating-on and linking 3D models to external databases” (BIM Dictionary, 2015). Each Model Use represents a set of defined requirements, specialised activities and specific project outcomes, grouped together under a single heading. 

Model Uses [1] rely on the conceptual structures of the BIM Framework, namely: the Tri-Axial Framework, Competency Framework, and BIM Ontology - Figure 1:

   Model-Uses-Conceptual-StructuresFigure 1. Conceptual Structure underlying Model Uses (Full Size v0.3 or Older Version )

As highlighted in Figure 1, Model Uses are supported by three conceptual structures [2] - Updated May 2, 2016:

  • Within the Tri-Axial Framework, Model Uses are deliverables [Tri-axial Framework>Fields>Field Components>Deliverables (Model-based Deliverables, identified through the Information Management Lens)] (refer to Papers A2 and A5);
  • According to the BIM Ontology, a Model Use is a knowledge block [BIM Ontology>Knowledge Objects>Knowledge Sets>Knowledge Blocks> Information Uses > Model Uses] (refer to Thesis, Appendix A); and
  • Within the Competency Framework, Model Uses are competency topics [Competency Framework> Competency Hierarchy>Competency Tiers (Domain)>Competency Set (Operation)>Competency Topics (9 Topics)] (Refer to Paper A6).

[1] Model Uses are discussed in detail  within Episode 24 on BIM ThinkSpace.

[2] The number of structures supporting a BIM Framework part is proportional to its conceptual strength.


36. BIM Ontology

  BIM-OntologyFigure 1.  The BIM ontology v3.1 (Neuron Model v0.4, Updated July 28, 2016)

The BIM ontology is an informal, semi-structured, conceptual domain ontology used for knowledge acquisition and communication between people. It is intended to represent knowledge interactions (push/pull) between BIM players, their deliverables and requirements (Figure 2) as described within Papers A1 and A2 (Succar, Sher, & Aranda-Mena, 2007) (Succar, 2009) and facilitate the validation of conceptual models (Shanks, Tansley, & Weber, 2003).

The BIM ontology includes BIM-specific concepts, their relations and attributes which facilitate analysis of domain knowledge (Noy & McGuinness, 2001), enable the construction of a domain framework (Studer, Benjamins, & Fensel, 1998), and support knowledge acquisition and communication (Milton, 2007a, 2007b) (Cottam, 1999) (Studer et al., 1998). Figure 2 below illustrates how ontological objects underlie the BIM Framework. The concept map (Figure 2 - right) is a visual representation of the ontological relationship between the three concepts (BIM Fields, BIM Stages and BIM Lenses); while the visual knowledge model (Figure 2 - left) abstracts these relations into the Tri-axial Model, a simplified graphical representation to facilitate communication. As discussed in Papers A1 and A2, this combination of visual modelling, driven by explicit ontological relations, renders the BIM Framework and its many conceptual constructs more accessible for analysis, modification and extension.

Also, as depicted in the Conceptual Hierarchy post, ontological relations enable a ‘conceptual mesh’ linking different types of conceptual constructs: frameworks, models, taxonomies, classifications and specialized dictionary terms. 

Figure 2. Visual Knowledge Model (left) + Concept Map (right)


Generating the BIM ontology

The BIM ontology has been generated by amending and reusing existing ontologies; a process recommended by Noy and McGuiness (2001). The reuse of an existing ontology followed Gruber’s criteria for shared ontologies: clarity, coherence, extensibility, minimal encoding bias and minimum ontological commitment (Gruber, 1995). Based on these criteria, the BIM ontology was first derived from the General Technological Ontology (Milton, 2007a) (Milton, 2007b) and the General Process Ontology (Cottam, 1999). While earlier iterations of the BIM ontology followed source definitions, newer iterations are more closely matched with the conceptual and practical requirements of the BIM domain.

Knowledge Objects

The BIM ontology comprises of four high-level knowledge objects: concepts, attributes, relations and knowledge Sets (Table 1):


Knowledge Objects




Concepts (Table 2)

A mental construct

Component; Document; Role


Attributes (Table 3)

Values and qualifiers associated with Concepts

Cost; Count; Description


Relations (Table 4)

Connections between Concepts; the effect of one Concept on another

Approves; Detects; Supplies


Knowledge Sets (Table 5)

A purposeful compilation of Concepts, their Attributes and Relations

Knowledge Foundations; Knowledge Blocks; Knowledge Views

Table 1. BIM Ontology Knowledge Objects (v3.0, last updated August 16, 2015)

 I. Concepts






Conceptual Construct


Data Source

Data Use




Document Use










Information Use

Knowledge Domain









Model Use













Software Application




System Unit

Target  Test Tool  Trigger    

Table 2. Concepts (51 Concepts in v3.10, last updated July 28, 2016)

II. Attributes






An integer or string indicating the basic existence or availability of a concept


The coordinates of an object within a physical space


A monetary value expressed in whole numbers, fractions or decimals


A defined economical boundary


An expression of elemental numbers using integers


An arrangement whether chronological or spatial – not preferential or developmental (refer to Grade)


An explanation expressed using words, phrases and sentences


A mutually exclusive distinction between clear choices


A variables denoting preference or developmental achievement expressed in integers, percentages or text


A description of condition whether temporary or permanent


A hypertext connection


An expression of chronology expressed in minutes, second, days, etc…


The language used to define a concept or a relation


A differentiation of genus

Table 3. Attributes (14 Attributes in v3.0, last updated August 16, 2015)

III. Relations

Below is a list of all standard relationship labels (158 as of Aug, 2015) connecting different Concepts:







Allow for



















Collaborate with




Communicate with
























Discuss with







Engage with












Function as




Has part

Has resource


















Link to



Make aware














Participate in











Provide for







































Table 4. Relations (158 Relations in v3.0, last updated August 16, 2015)

IV. Knowledge Sets

Knowledge Sets are higher order Knowledge Objects composed of the other three lower order concepts, relations and attributes.






Knowledge Foundations

A structured view of concepts and their relations. Knowledge Foundations include dictionaries, classifications, taxonomies, models, frameworks and theories

The BIM Ontology, The BIM Framework, Granularity Levels, Organizational Scales…


Knowledge Blocks

A self-contained knowledge item used to build larger knowledge structures  

A competency item, dictionary item, model use…


Knowledge Tools

An interactive view of concepts and their relations intended to assess, assist and educate its users. A tool has modifiable variables leading to varied outputs based on inputs

A calculator, an online tool, a cad software…


Knowledge Workflows

A repeatable set of activities conducted as part of a larger process to deliver a measurable outcome

An assessment methodology, a knowledge capture technique, a construction method, a verification routine….


Knowledge Views

A delimited self-contained view of multiple concepts and their relations - irrespective of knowledge content format (text, images or graphs) or knowledge content medium (hardcopy or softcopy)

A training manual, journal article, CAD drawing, poster, web page, video, concept map, repertory grid, process map, concept map, flowchart, Gantt chart…

Table 5. Knowledge Sets (4 sets in v3.1, last updated July 28, 2016)



Publication Log - Summary 





18 Oct ‘07

Initial version submitted as part as a research proposal at the University of Newcastle, NSW


6 Dec ‘08

Published as Table 6 within Paper A2


13 Dec ‘13

Published as Appendix A of the PhD Thesis


16 Aug  ’15

First published on BIMframework.com


29 Apr  '16

2 new Concepts added, 1 Concept modified


28 Jun '16

5 new Concepts added


2 Jul '16

1 Concept modified


28 Jul' 16

1 Concept added, 1 Knowledge Set renamed


21 Aug' 16

2 Concepts added


23 Jan' 2017

Removed the ‘active’ tone from all Relations. Added 1 Concept + 2 Relations. Modified 1 Concept



Cottam, H. (1999). Ontologies to Assist Process Oriented Knowledge Acquisition (Draft). Retrieved from http://www.inovexadvancedsolutions.ltd.uk/spede/default.htm

Gruber, T. R. (1995). Toward principles for the design of ontologies used for knowledge sharing? International journal of human-computer studies, 43(5-6), 907-928.  Retrieved from http://www.sciencedirect.com/science/article/B6WGR-45NJJDF-K/2/b47f5cb67315c76b60ac39f44e0a2cec

Milton, N. R. (2007a). Knowledge Acquisition in Practice: A Step-by-step Guide: Springer, London.

Milton, N. R. (2007b). Specification for the General Technological Ontology (GTO). http://www.pcpack.co.uk/gto/notes/files/GTO%20Spec%20v4.doc Retrieved from http://www.pcpack.co.uk/gto/notes/files/GTO%20Spec%20v4.doc

Noy, N. F., & McGuinness, D. L. (2001). Ontology Development 101: A Guide to Creating Your First Ontology. http://www.lsi.upc.edu/~bejar/aia/aia-web/ontology101.pdf Retrieved from http://www.lsi.upc.edu/~bejar/aia/aia-web/ontology101.pdf

Shanks, G., Tansley, E., & Weber, R. (2003). Using ontology to validate conceptual models. Communications of the ACM, 46(10), 85-89. doi:10.1145/944217.944244

Studer, R., Benjamins, V. R., & Fensel, D. (1998). Knowledge engineering: Principles and methods. Data & Knowledge Engineering, 25(1-2), 161-197.  Retrieved from http://www.sciencedirect.com/science/article/B6TYX-3SYXJ6S-G/2/67ea511f5600d90a74999a9fef47ac98

Succar, B. (2009). Building information modelling framework: A research and delivery foundation for industry stakeholders. Automation in Construction, 18(3), 357-375.  Retrieved from http://dx.doi.org/10.1016/j.autcon.2008.10.003

Succar, B., Sher, W., & Aranda-Mena, G. (2007). A Proposed Framework to Investigate Building Information Modelling Through Knowledge Elicitation and Visual Models. Paper presented at the Australasian Universities Building Education (AUBEA2007), Melbourne, Australia. http://aubea.org.au/ocs/viewpaper.php?id=15&cf=1


35. Point of Adoption

The Point of Adoption (PoA) model is a distillation of three implementation phases: readiness, capability, and maturity. As a term, PoA identifies the juncture(s) where organizational readiness transforms into organizational capability/maturity. It also identifies the juncture(s) where technological invention and a procedural innovation transforms into organizational - as well as market wide - diffusion:


Point of Adoption model v1.1 (full size, current version)

As explored in Figure 1 above, transformative BIM adoption starts at the Point of Adoption (PoA) when an organization, after a period of planning and preparation (readiness), successfully adopts object-based modelling tools and workflows. The PoA[1] thus marks the initial capability jump from no BIM abilities (pre-BIM status) to minimum BIM capability (Stage 1). As the adopter interacts with other adopters, a second capability jump (Stage 2) marks the organization’s ability to successfully engage in model-based collaboration. Also, as the organisation starts to engage with multiple stakeholders across the supply chain, a third capability jump (Stage 3) is necessary to benefit from integrated, network-based tools, processes and protocols (refer back to BIM Stages).

Each of these capability jumps is preceded with considerable investment in human and physical resources, and each stage signals new organizational abilities and deliverables not available before the jump. However, the deliverables of different organizations at the same stage may vary in quality, repeatability and predictability (refer to BIM Maturity Index). This variance in performance excellence occurs as organizations climb their respective BIM maturity curve, experience their internal BIM diffusion, and gradually improve their performance over time[2].

The multiple maturity curves depicted in Figure 1 reflect the heterogeneous nature of BIM adoption even within the same organization (e.g. sample Organization X) has a compiled rating of 1c, 2b and 3a). This is due to the phased nature of BIM with each revolutionary stage requiring its own readiness ramp, capability jump, maturity climb, and point of adoption. This is also due to varied abilities across organizational sub-units and project teams: while organizational unit A1 (within Organization A) may have elevated model-based collaboration capabilities, unit A2 may have basic modelling capabilities, and unit A3 may still be preparing to implement BIM software tools. This variance in ability necessitates a compiled rating for organization A as it simultaneously prepares for an innovative solution, implements a system/process, and continually improves its performance.

Note: the Point of Adoption model is also discussed  (along with the UK BIM Maturity model) in Episode 22 on BIM ThinkSpace.

Update (May, 2016): below is a short video explaining the above on the Framework's YouTube channel:


[1] The Point of Adoption (PoA) is not to be confused with the critical mass ‘inflection point’ on the S-curve (E. M. Rogers, 1995) (Everett M Rogers, Medina, Rivera, & Wiley, 2005); or with the ‘tipping pint’, the critical threshold introduced by Gladwell (2001).

[2] The X-axis in Figure 1 represents time relative to each PoA, not as an absolute scale. That is, this version of the chart does not represent a snapshot view of compiled capability/maturity at a specific point in (absolute) time.