This post introduces Model Uses and how they can be applied in practice. This apparently simple - but actually quite complex – topic has not been given its due care over the past few years. The rush to standardise every process and deliverable has evidently taken precedence over the efforts to simplify the collaboration process and minimise project complexity. Model Uses – as defined in this article – offer a structured language for translating project goals into project outcomes, and thus brings clarity to services’ procurement and performance improvement.
This is a lengthy post and will thus try to avoid unnecessary distractions: lengthy introductions, side-track topics, and all discussions that can be delayed until a solid foundation for Model Uses is set. For example, this episode will not explore how overall project objectives are defined; the potential effects of Model Uses on project roles and supply chain responsibilities; or the legal implications of applying Model Uses in services’ procurement. Although these topics are important and will be discussed in future episodes, this post has a singular focus: introduce Model Uses in an unambiguous way, and explore how they can be used in practice.
Figure 1. Model Uses – term cloud
Section I: Introduction
Let’s start with a few simple questions:
What is the easiest way to specify the modelling requirements of a project? Is it by defining what needs to be modelled, what analyses to be performed, or what project outputs to be extracted?
The obvious answer is ‘all of the above’…But, how can we specify all these requirements, activities and outputs in a simple and consistent way? And, how can we link these to the abilities of individuals, organizations and teams?
This peer-reviewed [1] episode will address these question by introducing Model Uses (Figure 1), a total rethink, and a practical expansion of the ‘BIM Uses’ taxonomy (Messner and Kreider, 2013)(NBIMS v3, 2015) [2].
This episode is available in other languages. For a list of all translated episodes, pleaser refer to http://www.bimthinkspace.com/translations.html. The original English version continues below:
Definition
According to the BIM Dictionary, Model Uses are the “intended or expected project deliverables from generating, collaborating-on and linking 3D models to external databases”. Each Model Use represents a set of defined requirements, specialised activities and specific project outcomes, grouped together under a single heading so they can be more easily specified, measured and learned.
Benefits
The main drivers for generating - and publically sharing - a comprehensive Model Uses List (Section III) is to contribute towards the reduction of project complexity by (a) facilitating communication between individuals, organizations and teams; (b) clarifying project requirements and desired project outcomes; and (c) linking these requirements and outcomes to their respective competencies, tools and methods. By properly defining Model Uses, we can more easily:
- Identify project deliverables: After project goals has been identified, Model Uses provide a structured language for populating Requests For Proposals (RFP)s, Pre-Qualification Questionnaires (PQQ), Employer’s Information Requirements (EIR)s and similar documents;
- Define learning objectives: Model Uses allow the collation of specialised competencies to be acquired by individuals, organizations and teams;
- Assess capability/maturity: Model Uses act as performance targets to be used for measuring or pre-qualifying the abilities of project stakeholders;
- Allow assignment of responsibilities: Model Uses allow Project Team and Work Team capabilities to be matched to particular Model Uses and the assignment of responsibilities; and
- Bridge the semantic gaps between project-based industries: Model Uses represent the deliverables of multiple information systems – BIM, GIS, PLM and ERP [3] - and help bridge the semantic gap between interdependent industries (e.g. Geospatial, Construction, and Manufacturing).
Before introducing the Model Uses List, let’s explores how Model Uses have been conceptualised, identified and classified:
Section II: Foundations
This Section will clarify the knowledge sources reviewed to identify Model Uses. It will also shed some light on the method followed to generate a Model Uses List which is reasonably comprehensive, semantically precise, yet taxonomically flexible to allow future customisation, localisation and extension.
Conceptualising Model Uses
Model Uses rely on the conceptual structures of the BIM Framework, namely: the Tri-Axial Framework, Competency Framework, and BIM Ontology. For more information about these structures, please refer to this post – published concurrently - on the BIM Framework blog.
Identifying Model Uses
Model Uses are identified by reviewing and comparing several publically-available knowledge sources from a number of countries:
- Published academic research (or academic-quality research), including “The Uses of BIM” (Messner et al, 2010); the “BIM Handbook” Table 4-1 (Eastman et al, 2008, p.98);
- Noteworthy BIM Publications (NBP)s, including the LACCD BIM Guide (2010); Veteran Affairs BIM Guide (2010); GSA BIM Guide (2011); New York City BIM Guide (2012); Common BIM Requirements – Finland (2012); Statsbygg BIM Manual – Norway (2013); Massachusetts Port Authority BIM Guide – Appendix A (2014); NATSPEC BIM Project Inception Guide (2014); NBS Components of Level 2 BIM – 2 images (2015)
- Relevant Classification systems, including OmniClass Table 33; UniClass2015 Table Ss; and
- International Standards and candidate standards, including PAS1192-2:2013; ISO/TS 12911:2012 Framework for building information modelling (BIM) guidance; and ISO/DIS 29481-1:2014 Building information modelling - Information delivery manual.
The sources listed above provided a rich inventory of well-defined and undefined Model Uses. Applying the Model Use definition presented earlier, the author identified, classified and aggregated [4] a large number of candidate Model Uses. These were reviewed and duplicate terms removed. If two terms had very similar connotations, the one appearing more frequently in the above sources became the Model Use; and the other less used terms were added as synonyms.
The above resources also helped clarify a number of competing terms and prompted the development of new ones.
Model Uses or BIM Uses?
The two terms - Model Use and BIM Use - can be applied interchangeably. However, in my view, it is preferable to use Model Use for a number of reasons - including:
- The acronym ‘BIM’ in the US is often used to refer to the Building Information Model [5] while – in Australia, the UK and many other countries - it consistently refers to Building Information Modelling. Since we are describing the relation between the User (the human actor) and the product (the model), the term Model Use is less ambiguous;
- The term Model Use is not wedded to the construction industry and thus can be applied to GIS, PLM [6] and other information systems;
- The term Model Use is semantically connected to Model View and Model View Definition - as will be clarified further below.
Whether you prefer to adopt the term ‘BIM Use’ or ‘Model Use’ has little or no practical consequences. However, for consistency across this article and all other episodes, Model Uses will be treated as the umbrella term that covers BIM Uses, GIS Uses, PLM Uses and other model-based use cases.
Model Uses and Model-based Deliverables
It is important to differentiate between Model Uses (what we are able to deliver, plan to deliver, or request others to deliver) and Model-based Deliverables (what is delivered). In a sense, “deliverables and BIM uses [Model Uses] are two sides of the one coin – BIM uses represent the tool or process – deliverables represent the output.” (NATSPEC BIM Project Inception Guide, 2014, p. 6).
In other words, Model Uses translate quantifiable project requirements (input) into measureable project outputs [7]. How information defined within Model Uses are transformed into actual Model-based Deliverables will be elaborated upon - using Process, Interaction and Transaction Maps [8] - in future BIM ThinkSpace episodes.
To avoid confusing Model Uses (e.g. Clash Detection, Thermal Analysis, and Relocation Management) with Model-based deliverables, the later will always be suffixed with a Document Type (e.g. Clash Detection Report, Thermal Analysis Chart, and Relocation Management Animation).
Model Uses and Mode View Definitions
According to buildingSMART [9], an "IFC View Definition, or Model View Definition, MVD, defines a subset of the IFC schema, that is needed to satisfy one or many Exchange Requirements of the AEC industry." Also according to NBIMS, the “aim of the Information Delivery Manual (IDM) (buildingSMART Processes) and Model View Definition (MVD) is to specify exactly which information is to be exchanged in each exchange scenario and how to relate it to the IFC model." (US-NBIMS-v3, Section 2.5.4.4). To date, only a few Model Views are defined via official MVDs [10], and even less MVDs have been implemented by BIM Software Tools.
Irrespective of the number of MVDs currently available, will be defined in the future, or will be implemented by willing software developers, there is a prior and separate need for a comprehensive list of Model Uses. This is because:
- On the one hand, Model View Definitions are clearly intended to standardise computer-to-computer exchanges [11] based on common use cases;
- On the other hand, Model Uses are intended to simplify human-to-human interactions, and human-to-computer interactions (HCI). Model Uses’ main purpose and benefits - as discussed in Section 1 - are not to improve software tools, but to facilitate communication between project stakeholders and link Client/Employer’s [12] requirements to project outcomes and team competencies.
Defining Model Uses
We can approach Model Uses in many different ways: based on how, when and by whom they are applied within organizations and on projects; based on the competency contents of each Model Use; or based on the legal implications of applying Model Uses to distribute responsibilities among individuals, organizations, and teams. All these are valid approaches that must be discussed after we establish a solid foundation to build upon. To lay such a foundation, I will apply an Information Management Lens [13] to isolate Model Uses from amongst all information available throughout a project’s lifecycle (Figure 2):
Figure 2. Project Information, from Unstructured to Integrated (Full Size)
Figure 2 abstracts all the information available throughout a project’s lifecycle into colourful shapes [14]. These shapes (and their placement within concentric circles) represent five types of information organised according to their computability:
[..] General Background Information (GBI): information that has no direct influence on the project (e.g. the history of the land upon which the facility is built). GBI represent non-relevant project information and is thus not represented in the above image;
[❶] Unstructured Project Information (UPI): non-computable data, undocumented, and temporary project information (e.g. hand sketches and casual phone chats). UPI is represented as formless shapes of different colours;
[❷] Structured Project Information (SPI): computable data and organised information reflecting particular purposes and use cases (e.g. a marketing video or a Request for Proposal). SPI includes documents, drawings, maps, messages, photos, reports, schedules and visualisations. SPI is represented as unconnected 2D geometric shapes;
[❸] Modelled Information (MI): information represented within a 3D model to reflect particular Model Uses (e.g. Structural Analysis and Asset Tracking). Modelled Information include those used for planning, simulating, quantifying, constructing, fabricating, operating, maintaining, monitoring, and controlling. MI is represented as connected 3D geometric shapes; and
[❹] Integrated Data (ID): interconnected, highly-structured and granular information; covering multiple projects, portfolios and programmes; derived from varied information sources, including models and all types of Structured Project Information. ID is represented as a perfect sphere [15] of interconnected 3D shapes.
The above classification is our key to identifying the type of information residing within (or can reside within) 3d models, and can thus be represented by Model Uses (MU)s. It also helps us to identify the type of information that reside outside the Model (e.g. a satellite image, or a CNC script) and are represented by Information Uses (IU)s or Data Uses (DU)s linked into 3D models.
I will expand on the critical relationships between MUs, IUs and DUs in a future post. For the remainder of this episode, I will focus exclusively on Type 3, Modelled Information, and how it can be represented by Model Uses of different classes and categories.
Classifying Model Uses
It is possible to define tens or even hundreds of Model Uses (MU)s to represent modelled or model-able information. However, it is important to define the minimum workable number (no more, no less) that allows two seemingly contradictory objectives: accuracy of representation and flexibility of use.
With respect to accuracy of representation, if the number of Model Uses is too small, then their definitions would be wide, less precise and subdivisible into sub-uses. However, if the number of Model Uses is too large, then their definitions would be narrow, include overlapping activities/responsibilities and thus cause confusion. What we need is a Model Use breakdown which is ‘just right’ for effective communication and application.
With respect to flexibility of use, and to allow the application of Model Uses across varied contexts, Model Use definitions must exclude unnecessary qualifications that vary from user to user, and from one market to another. To this end, Model Uses are defined independently from their user, industry, market, phase, priority, and inherent activities:
- Model Uses are defined independently from Project Lifecycle Phases and thus can apply – depending on stakeholder’s BIM Capability [16] - at any/all phases of a project;
- Model Uses are defined independently from how they will be applied: this allows their consistent use in project procurement, capability development, organizational implementation, project assessment and personal learning;
- Model Uses are defined without a built-in priority: this allows each MU’s priority to be set by stakeholders on each project; and
- Model Uses are not pre-assigned to disciplinary roles: this allows the assignment of responsibility for Model Uses based on project participants’ experience and measured capability.
By combining the two objectives - accuracy and flexibility – and after identifying the point of balance between them [17], the below Model Uses List has been developed and is released for discussion below. This release (v0.73) is based on numerous iterations [18], consultations [19], and tests [20]:
The Model Uses List (v0.73 – Sep 8, 2015) represents the latest stable taxonomy with 125 Model Uses, organized under 3 Categories and 9 Series [21] - Figure 3:
Figure 3. Model Use categories and series (Full Size)
CATEGORY I: Model Uses > General Model Uses
General Model Uses are applicable across industries, information systems and knowledge domains. General MUs include the word ‘modelling’ in their name and are typically measured using granularity metrics (e.g. Level of Definition [22], Level of Development [23] and Granularity Level [24]) at component/item level. There are currently 52 General MUs - with 100s of potential synonyms [25] - organized as a single MU Series, General Modelling (1000-1990). The following are sample General Model Uses [with a few synonyms]:
- 1020 Audio-visual Systems Modelling [Sound Systems Modelling; Video-network Modelling]
- 1420 Temporary Structures Modelling [Scaffolding Systems Modelling; Fence Modelling]
- 1490 Urban Modelling [City Modelling; Precinct Modelling]
CATEGORY II: Model Uses > Domain Model Uses
Domain Model Uses are industry-specific. The ones identified below are Construction Domain Model Uses (or BIM Uses for short). The naming format for each Domain Model Use is either a Noun + Adjective (or just an Adjective). There are currently 73 Domain MUs, organized in seven MU Series:
Series 2: Capturing and Representing (2000-2990), synonyms not listed
Series 3: Planning and Designing (3000-3990), synonyms not listed
Series 4: Simulating and Quantifying (4000-4990), synonyms not listed
Series 5: Constructing and Fabricating (5000-5990), synonyms not listed
Series 6: Operating and Maintaining (6000-6990), synonyms not listed
Series 7: Monitoring and Controlling (7000-7990), synonyms not listed
Series 8: Linking and Extending (8000-8990), synonyms not listed
CATEGORY III: Model Uses > Custom Model Uses
Custom Model Uses are a combination of General and Domain model uses. Custom MUs are tailored – when needed – to each project, Client/Employer or market’s specific modelling requirements. There is no fixed number of Custom MUs and are all organized under a single MU Series, Custom Modelling (9000-9990). The following are hypothetical Custom Model Uses:
- 9XXX Modelling of a floating sculpture with a wave-powered signalling beacon
- 9YYY Modelling security systems for a correctional facility
- 9ZZZ Modelling ventilation systems for an astronaut staging station on the moon
Note: the full Model Uses List is hosted on BIMexcellence.org as a community page under a limited Creative Commons License. For the latest iteration, license information, and change log, please refer to BIMexcellence.org/model-uses.
Section IV: Applying Model Uses in practice
After introducing the Model Uses List, it’s beneficial to identify a couple of ways to apply MUs in practice: Model Uses as an Implementation Template, and Model Uses as a Performance Metric (for other applications, please refer back to Section I):
Model Uses as an Implementation Template
From an implementation perspective, each Model Use is a ‘container of activities’ that – if completed - would deliver a predefined project outcome or meet a specific Client/Employer’s requirement. Let’s take Clash Detection, a Domain Model Use, and identify some of the activities [26] it contains, organized against six Performance Improvement Phases [27]:
- SCOPING PHASE - activities include:
- Establish if [Clash Detection] is applicable for this type of project
- Establish if [Clash Detection] is required for this specific project
- Establish the relative priority of [Clash Detection] for this specific project
- Establish who is the [Responsible Party] to conduct [Clash Detection]
- ASSESSMENT PHASE - activities include:
- Assess if the [Responsible Party] has the ability to conduct [Clash Detection]
- Assess the quality of the [Clash Detection] delivered by [Responsible Party]
- ANALYSIS PHASE - activities include:
- Analyse whether [Clash Detection] abilities match [Clash Detection] requirements
- Generate a Proceed, Pause/Clarify, Stop/Modify, or Abort [Clash Detection] recommendation
- PLANNING PHASE – activities include (not in order):
- Select the software application suited for conducting [Clash Detection]
- Gain access to model(s) in the format necessary for conducting [Clash Detection]
- Prepare model(s) or part model(s) for [Clash Detection] – sample tasks:
- Delete/purge/turn-off non-mission critical parts
- Open/import/collate model(s) into [Clash Detection] software application
- Define target components/systems for [Clash Detection] (select set, load filter…)
- Identify target results for [Clash Detection] – examples:
- Spatial, geometrical, semantic or
- Drawings, Details, Quantities, Specifications or Analytical Data
- ACTING PHASE - activities include (in chronological order):
- Execute the [Clash Detection] program/script/extension
- Check for redundancy and errors
- Remove/isolate redundancy and errors
- Generate [Clash Detection] report
- Communicate [Clash Detection] results
- MEASURING PHASE - activities include (not in order order):
- Confirm workflow for next round of [Clash Detection] or
- Refine process for next round of [Clash Detection]
Note: [Clash Detection] can be replaced with any other [Domain Model Use]
Model Uses as a Performance Metric
Model Uses and their respective Model-based Deliverables are useful for establishing the performance and compatibility of multiple stakeholders across different Organizational Scales (OScales) - Table 1:
|
Assessee (OScale)
|
What is Assessed
|
Metric used
|
Possible Results
|
|
Individuals, Groups, Work Teams and Project Teams
|
Knowledge, skill and experience in generating, or benefiting from, Model-based Deliverables
|
Individual Competency Index
|
Competency: None; Basic, Intermediate; Advanced; or Expert
|
|
Organizations and Organizational Teams
|
Ability to deliver (Capability), and quality of what’s being delivered (Maturity)
|
Capability (a binary metric) and the BIM Maturity Index (BIMMI)
|
Capability: Yes or No
Maturity: Low; Medium-Low; Medium; Medium-High; or High
|
|
Projects and BIMmodels
|
The number of Model-based Deliverables derived from the project’s federated or integrated model
|
Model Richness Variable (MRV)
|
Richness: value ranging from 0 (poor/none) to 1 (rich/all applicable MUs)
|
|
Industries and Markets
|
The availability of well-defined Model Uses within a market
|
Availability of a Model Uses List. Assessed as part of Component VII: Standardised Parts and Deliverables, within the Macro Maturity Components model
|
Availability: Yes or No
Maturity: Low, Medium-Low; Medium; Medium-High; or High
|
Table 1. Model Uses as a performance metric across organizational scales (partial)
Let’s demonstrate how Model Uses can be used in performance measurement:
An informed Client/Employer wants to assess the team assigned to a large and complex BIM project. After establishing its goals and project requirements, the Client/Employer uses the Model Uses List as a simple checklist to identify the Model-based Workflows it needs during – or the Model-based Deliverables it expects at the completion of - the project. Based on the checklist items, it commissions an assessment with several sets of questions [28], each set focusing on a single Model Use, with the following sample questions:
- Do you have experience in conducting [Cost Estimation] on [Project Type]?
- If yes, on how many projects have you conducted [Cost Estimation] in the past [X] years?
- What BIM Software Tool(s) do you have experience in?
- What is the main tool you’ll use to conduct [Cost Estimation]?
- Do you have documented processes for conducting [Cost Estimation]?
- What are the standards, protocols and classifications you follow when conducting [Cost Estimation]?
- What are the [Cost Estimation] [Document Types] you will be delivering at [Project Phase]?
…etc.
Note: [Cost Estimation] can be replaced with any other [Domain Model Use]
Upon completion of the assessment – delivered through a dedicated assessment tool - the Client/Employer was able to compare the project team’s abilities to its predefined requirements (Figure 4):
Figure 4. Model Use Wheel – showing Capability (left) and Maturity (Right) – Full Size
As depicted in Figure 4, the highlighted cells in Model Use Wheel A (Left) identify all the Model Uses required by the Client/Employer on a large and complex BIM project. Each highlight (blue) represents a single checklist item. The highlighted cells in Model Use Wheel B (Right) provide a visual summary of the Project Team’s competence (assessed as a single unit) against each Model Use. The hypothetical results vary from Low (Light Grey, 0-20%); Medium-Low (Yellow, 21-40%); Medium (Light Orange, 41-60%); Medium-High (Dark Orange, 61-80%); or High (Red, 81-100%).
Based on this visual analysis, it is clear that a number of Client/Employer’s expectations cannot be met by the project team. For example, Model Uses 4060, 4110, 4230, 5080, 8010 and 9120 are practically not available. Based on this, the Client may address this shortfall by (a) requiring specific team members to acquire these abilities; (b) assigning a specialist service provider to assist the project team; or even (c)...
Of course, it is not necessary to use the dedicated assessment tool or the Model Use Wheel to establish basic team capability against Model Uses. One can do that using basic questions and a basic rating system (e.g. traffic light colours) to get a significant return on assessment effort.
Summary (and an invitation)
This post introduced the Model Uses concept as a foundation to build-upon, templates to use, and classifications to extend. Of course, there’s much much more to be said about MUs and especially how they affect supply chain roles and enable an intuitive, performance-based alternative to prescriptive protocols. I'm hoping to discuss these strategic aspects and additional practical applications of Model Uses in the near future.
Finally, for the Model Uses concept to deliver the many benefits described in Section I, it needs to be further extended through a collaborative and open community effort. You are therefore invited to adopt, test and modify the Model Uses List for your own requirements. That is, under a Creative Commons Attribution Non-commercial Share-alike 3.0 Unported licence, please feel free to use the concepts, structures and list to populate procurement documents, generate implementation checklists, and develop learning modules.
Acknowledgements
This is a peer-reviewed Blog Post. BIM ThinkSpace Episode 24 has been reviewed by international experts from four countries. The names and affiliations of all reviewers are listed below in alphabetical order:
- Antony McPhee, BIM Manager at John Wardle Architects, fellow blogger at practical BIM (AU)
- Brian Renehan, BIM Leader - Victoria at GHD Woodhead, fellow blogger at BIM Fix (AU)
- Chris Needham, BIM Lead, AECOM, Chairman (RTC Australasia) at RTC Events (AU)
- Eduardo Toledo Santos, Assistant professor at University of São Paulo (BR)
- Neil Greenstreet, Senior Architect at NATSPEC (AU)
- Olly Thomas, Information Manager at BIM Technologies (UK)
- Ralph Montague, Managing Director at ArcDox (IR)
- Victor Roig Segura, Managing Partner at BIMETRIC LAB (SP)
I am indebted to all reviewers for their excellent commentary on an earlier version of this post. Their insights and recommendations have greatly improved this article; thank you to each and all!
Endnotes
[1] This BIM ThinkSpace episode has been reviewed by 8 domain experts prior to initial publication. Additional information is provided under Acknowledgements.
[2] BIM Uses is defined as the “method of applying Building Information Modeling during a facility’s lifecycle to achieve one or more specific objectives” (NBIMS v3, 2015, Section 5.9.1). The term was popularised by the published works of John Messner, Ralph Kreider and others from Penn-State University (2010-13). It is worth noting that nearly all BIM Use definitions currently in circulation emanate from the original work conducted 5 years ago. Since then, very little if any systematic investigations have been conducted. For more information about BIM Uses, please refer to “The Uses of BIM | Classifying and Selecting BIM Uses” (v0.9, September 2013, Page 6) and this Prezi clarifying how the 25 BIM Uses were identified.
[4] The research method used for identifying, classifying, aggregating and using/re-using Model Uses is the same as the one used for Competency Items (both Model Uses and Competency Items are considered Knowledge Blocks by the BIM Ontology). For more information about the identification method, please refer to the Competency Flow model (Succar et al., 2013). http://bit.ly/BIMPaperA6
[5] Understanding BIM as a model in the US gave rise to another acronym – VDC (Virtual Design and Construction) - that addresses the semantic shortfall. We do not observe this BIM+VDC coupling in countries where the BIM acronym designates modelling.
[6] There are many Model Uses that apply to across BIM and PLM (e.g. Sheet Metal Cutting), and across BIM and GIS (e.g. Urban Modelling).
[7] Model Uses are an expansion and re-organization of BIM Outcomes, “the possible desired results to be obtained from the application of BIM” as defined in ISO/TS 12911:2012ISO/TS 12911:2012 Framework for building information modelling (BIM) guidance.
[8] Model Uses can help identify and quantify stakeholders’ business requirements according to their respective project roles. By identifying these business requirements, Model Uses would facilitate the development of detailed process maps clarifying the interactions and transactions between these roles. For more information about process, interaction and transaction maps, please refer to ISO/DIS 29481-1:2014 Building information modelling - Information delivery manual.
[9] Refer to buildingSMART International, MVD Summary - last accessed Sep 1, 2015.
[10] There are currently only a couple of ‘official’ buildingSMART International MVDs (for IFC4) supporting a small number of ‘workflows’: coordination planning; clash detection; quantity take-off; background/integrated reference; and construction sequencing.
[11] Refer to sample MVD specifications here – last accessed Sep1, 2015.
[12] The term ‘Client/Employer’ has two connotations: internal (e.g. the manager, head office, or employer of individuals); and external (e.g. the general contractor is the Client/Employer of the sub-contractor)
[13] Information Management is one of the many ‘Disciplinary Lenses’ within the Tri-axial Framework. To understand BIM Lenses, please watch the BIM Lenses video on the BIM Framework’s Channel.
[14] The limited colours used in this model reflect the same general connotations of the wider range of colours used in earlier models - see earliest example (2005).
[15] The sphere shape is consistently used by the author to represent the highest level in any illustrated metric. Please refer to the post-BIM sphere in the Capability Stages Index (video shot), and the Optimised sphere in the BIM Maturity Index.
[17] The author is guided by Noy and McGuiness (2011) whose research identified multiple criteria for selecting or developing an ontology. These are: clarity, coherence, extensibility, minimal encoding bias, and minimum ontological commitment. Refer to http://www.lsi.upc.edu/~bejar/aia/aia-web/ontology101.pdf (PDF 282KB - last accessed Aug 11, 2015).
[18] The first mature Model Uses List (v0.2) was presented at RTC Australasia 2012. It included 99 Model Uses distributed against Project Lifecycle Phases. The next version (v0.3, 2013) included 50 Model Uses and – each subsequent version – included a different number of MUs based on varying identification criteria. The current Model Uses List (v0.73, published in this post) is a mature taxonomy: its subdivisions won’t significantly change any more but the naming/number of Model Uses may still vary with additional testing and user feedback.
[19] Earlier versions of the Model Uses List benefited from continual discussions with business colleagues and research students over the years. More recently, the current version (v0.73) benefited from the many good suggestions provided by peer-reviewers acknowledged above. Additional suggestions for improvement are always welcome!
[20] Model Uses are tested by including their Titles/Definitions within live assessment modules and project protocols (e.g. Employer’s Information Requirements), collating feedback from assessees and informed protocol users, and then – after refining Model Uses to reflect feedback – repeating the testing cycle. The tests are ongoing and, thus, Model Use numbers, classifications and descriptions are neither final nor conclusive. Even when numerous consultations, workshops and tests have been completed, the Model Uses List will continue to evolve as current modelling/analysis tools improve and new information systems/tools emerge.
[22] Level of Definition (LoD) is the term used in the UK and includes two parts: Level of Model Detail (geometric detail) and Level of Model Information (semantic richness).
[23] Level of Development (LOD) is the term used in the US (and Australia) and typically refers to both geometric and semantic richness.
[24] Granularity refers to the “scale or level of detail present in a set of data or other phenomenon” (Oxford Dictionary, 2014). There are four Granularity Levels (GLevels) in the BIM Framework (Low, Medium-low, Medium, Medium-High, and High) that can be assigned to an implementation template, assessment module, or learning unit.
[25] The number of General MUs are kept as low as possible by combining quasi-synonyms together. For example, ‘Plumbing Systems Modelling’ is considered a synonym to ‘Hydraulic Systems Modelling’. Also market-specific differentiations are kept to minimum. For example, the classification does not differentiate between ‘above ground’ and ‘below ground’ hydraulic systems as considered the norm in some markets.
[26] A Model Use (e.g. Cost Estimation) is defined at medium granularity, near the mid-point separating granular activities (e.g. calculating concrete volume or counting door handles) and a specialty (e.g. Cost Planning).
[27] The author follows the BIM Excellence Performance Improvement Lifecycle which includes 6 activity groups: scope, assess, analyse, plan, act, and measure.
[28] The number and format of these questions can vary greatly depending on the priority given to each Model Use and the Level of Evidence sought by the Client/Employer.
