This is part of a series of articles looking at The Digital Plan of Work
To define the level of information (LOI) required in a specification, a short code can be helpful. This article explores the principles behind this. A table illustrating these codes is available further down this article.
Introduction
Project information develops over time to reflect how designs change through various work stages. At its simplest, this information management takes place in two arenas. Graphical work, typically in 3D models, evolves with design decisions (and it might be easy to visualize an asset developing in this way, from early massing and masterplanning to sketch design, technical coordination and the drawing outputs from model environments like plans, elevations, sections and details). However, in parallel, information in the specification and other non-graphical data is evolving too, describing aspects like performance characteristics, testing or installation to achieve desired results.
Non-graphical data is produced in many forms, from the client brief to schedules, reports and the focus of NBS platforms: Preliminaries, specifications and product content from manufacturers. Specification forms a critical part of the information exchanges expected to be delivered at key project stages. Clients procure the building asset and a wealth of digital information for future stages and long-term use. This can be a complex process, with data being exchanged between multiple organizations across the project.
To ensure delivery of the required data, but reduce wasted effort and repeated work, it is essential that the amount of information to be provided at each stage of design development is clearly understood and agreed by all parties, considering risk, responsibility, delegation and collaboration.
Level of information
There are several industry guides that break the project timeline into work stages. One common example of this is the RIBA Plan of Work, overhauled in 2013, and updated to its current form in 2020 to describe an industry-wide approach to design development. The framework breaks down projects into eight stages, including ‘Concept Design’, ‘Spatial Coordination’ and ‘Technical Design’.
But how much information is required from a design team, contractor or manufacturer at each of these stages? Along with defining design responsibility, the management of the outputs required in the process can be simplified into two basic questions:
- How much graphical information is required at this stage, and who is producing it?
- How much non-graphical, specification and text-based data is required at this stage, and who is producing it?
Defining these project deliverables in accurate terms is essential, but a decade ago, UK organizations that wanted to describe and agree the amount of data expected by the end of a work stage in contracts used a range of methods. Design responsibility matrices were sometimes explained using standards and specifications developed in the US, like the AIA E202 BIM Protocol or US BIMForum level of development bands, which didn’t reflect typical UK projects or procurement. In addition, it was felt that it would be useful to break the single LOD banding into two separate bandings – one for geometric detail and one for related information.
The result of an Innovate UK-funded project, NBS worked with industry to fill this gap with the BIM Toolkit, a collaborative platform allowing users to record the current work stage of the project and to indicate the amount of information required for each building system, with a clear structure for the data to be documented and shared with other project stakeholders. Along with capturing requirements at each stage and allowing users to record that those outputs had been delivered before proceeding, the platform also let the client and project team designate who was responsible for the information.
The Toolkit content followed the PAS 1192-2 approach of differentiating between graphical and non-graphical information development and used indicative ‘bandings’ to suggest how much data was required at each stage with the terms:
- LOD = ‘level of detail’ (graphical); and
- LOI = ‘level of information’ (non-graphical)
Whilst these terms are now superseded by BS EN ISO 19650 and the ‘Level of Information Need’ approach, it is a useful shorthand to think about these two aspects of data development happening in tandem. In particular, these terms enable us to focus on the idea that the model environment doesn’t contain all the data, and that many aspects of non-graphical information are in the specification, preliminaries or product test reports.
This article focuses on LOI and specification development. A sister article about level of detail and graphical development can be found here.
Specification development across the project stages
So, if level of information is how much non-graphical data is required at each stage, how do the bandings help project teams to reach agreement? How does this align to specification development in platforms like NBS, and to design responsibility?
A core belief at NBS is that non-graphical, written data like preliminaries, specifications, descriptions and certification is a critical part of the overall project information generated by the construction industry. The 3D model cannot replace robust specification, as some items will never be modelled, and performance, standards and execution requirements are not captured in object properties, and notes on drawing outputs are not a substitute for a well-written specification. Specification information describes in words things that cannot be explained in drawings and the model, and is often developed alongside Preliminaries for contractual and project management requirements. Importantly, the specification data will feed into records and operation manuals for the asset owners once the building is in use.
In very brief terms, there are broadly four ‘types’ of specification that can be used at appropriate stages of a project’s development, and it is likely the specification documentation will include a combined mix of these types within one project, depending on the procurement route, project team and levels of expertise required:
- Outline
- Descriptive
- Prescriptive
- Record
Equally, the specification should be considered from the earliest possible stage. While drawn information is developing, the non-graphical properties and requirements of the design should be captured as decisions are made and evolve organically (rather than being retrospectively pulled together once model development is already at an advanced stage).
The client brief and high-level design ideas can be captured as an Outline description, then requirements of the building, systems and products can be specified in performance terms in a Descriptive* specification, such as the acoustic, thermal or structural requirements. The specification details further into more Prescriptive clauses, selecting the standards, grades and materials of component products. In prescriptive specification or through contractor selection, the specification also needs to include product information like range names, reference product codes and key properties selected from manufacturer choices to allow for asset information to develop and for future replacement and repair. Finally, for certain assets, Record specifications and associated information will be required to record what has been built, how to verify the specification and how to maintain the asset.
In the simplified example below, outline descriptions help to capture client requirements and key properties the final asset must meet, but with collaboration, these requirements evolve and develop into specification data. By ‘green’, does the client mean a living, green roof with planting and irrigation, for the designer to prioritize sustainability criteria, or that the final finish must be green in colour? What does ‘fire-resistant’ mean in terms of standards, technical build-up, design constraints, and the activities within the asset? And does ‘20 years min.’ require the roof system to last 20 years because it will be inaccessible, or achieve that duration with a regular maintenance schedule? Specification is being specific, and in this way the specification information evolves and becomes increasingly detailed for each system and product selected for the project.
* For certain specifications there may be a requirement to specify the overall performance (Descriptive) but retain selection responsibility for certain products (Prescriptive). For example, a roof covering system where a certain performance is required, but a particular brand of roof tile has been agreed with the client or the planners.
The earlier that requirements are captured, the better, to ensure that they evolve through the specification and that key information from the client is not lost at any stage of the project, or between project stages. By using a specification platform like NBS Chorus, the specification can evolve from outline to descriptive specification and into prescriptive selections, instead of information being transferred or rekeyed between documents or spreadsheets.
Design responsibility
Defining design responsibilities is vital on any project, especially when there are contractor design portions. Illustrations of the interface between the design team and the contractor’s team are given below. This NBS article looks at developing a ‘Responsibility Matrix’ in further detail.
In this diagram from the RIBA Plan of Work Overview, descriptive explanation is replaced by prescriptive product information up to the point of manufacture/ assembly, product purchase or on-site construction.
However, not all systems will reach this checkpoint at the same time. Some systems may be prescribed early in the project to allow site works such as lifts and foundations to commence, whilst finishes and furniture are still being designed. As part of upcoming fire safety regulations, it is expected that prior to construction commencing clarity will be required with respect to specification decisions impacting on building safety. For aspects of design awaiting prescriptive solutions, it is expected that construction will not be able to commence on these areas until the prescriptive solutions are complete and approved by the regulator.
Prior to construction, each system will need to be fully prescribed to allow for its assembly, fabrication, manufacture or procurement. As in the diagram below, technical design will require a level of information to allow the contractor to proceed and make final selections, often with a submittals/approvals process in place. A later stage may require that all the final product selections to complete the system design are updated in the information, for transfer into a record specification.
The NBS LOI bandings
The LOI bandings for specification development are below. These include a simple code and a corresponding definition.
RIBA Plan of Work
Within this family of support articles, NBS are directing users to the RIBA Plan of Work, which includes a template responsibility matrix. The Toolbox spreadsheet provides a template based on the plan of work stages to set up a responsibility matrix, including columns to list each system in the project, and indicate level of detail (LOD) and level of information (LOI) for each work stage for that system. Stage 4 is separated to allow for the allocation of design team, and contractor responsibilities where appropriate.
Working in spreadsheet software also allows the user to generate their own bespoke ‘pick lists’ for the dropdowns in each column. For example, you can add simple terms to each banding, e.g., 2 – Outline, 3 – Descriptive, 4 – Prescriptive, etc.
NBS will continue to update our articles and guidance to reflect new workflows and international development of standards like ISO 19650 and BS EN 17412-1 but want to ensure that customers have access to existing information and LOI bandings.
Further reading
- Digital plan of work
- Uniclass
- RIBA Plan of Work Toolbox
- Level of detail (LOD) and digital plans of work
NBS platforms
- NBS Chorus – the leading construction specification platform.
- NBS Source – the construction product information you need when you need it.
