The NBS BIM Toolkit public BETA – feedback


The new Digital Plan of Work (dPoW) and Classification system were introduced in public beta at BIM Show Live a few weeks ago. Both are incorporated into a single tool with development led by NBS to form the NBS BIM Toolkit BETA. The dPoW and Classification components form part of the wider components of “Level 2 BIM” with only PAS 1192-5:2015 now left to be published. The final live version of the toolkit will officially be available sometime around June 2015. 

01 NBS BIM Toolkit

Image: The NBS BIM Toolkit BETA site

The NBS BIM Toolkit can be accessed at Access is FREE to the whole toolkit (no excuses from anyone not to use it) following a simple registration process (although you can access some parts of the site without registering).

Before tackling the feedback I just want to say that the toolkit is a massive positive for the industry. As a believer in standard approaches this can only be positive for the industry. The team who have put this together have only had 6 months (including a Christmas period) and what has been achieved in the time is impressive. Its a great start and really pushes the Level 2 agenda forward.

The toolkit includes the following excellent features:

  • Its FREE to everyone!
  • Easy to use for non-technical users
  • Works on all platforms including mobile devices
  • Has a simple clean interface
  • Covers both Level of Detail (LOD) and Level of Information (LOI) which provides greater clarity about what different things need to look like in models as well as what information will be required
  • Over 5,500 templates for Level of Information (LOI)
  • Includes a Classification system built for BIM and aligned with latest international standards (ISO12006-2)
  • Includes Classification mapping to RICS NRM1 and NBS Create
  • Has a powerful search function for Definitions
  • Out-of-the-box templates for Tasks
  • Ability to reuse customised templates so that setup is quick and easy for new projects
  • Covers buildings and infrastructure (linear and environment)
  • Has the ability to change participants centrally once and they change in the Roles tables and in all linked Tasks and Deliverables
  • Will provide a consistent approach across the industry meaning less bespoke solutions from project to project
  • Includes export of open formats such as IFC and COBie
  • Will include Verification of models to ensure clients requirements are met (not yet available)


Like all things though they can be made better so this post really focusses on my own detailed review. My job is to work out how to apply this on our projects and I essentially sit between the developers of the toolkit and our project staff. I have to make sure it works for us as after all I’ll be the one taking grief from staff if it doesn’t work!

I do a lot of BETA testing of all kinds of software and the fundamental aim of this process is to try to break tools and find fault! The aim in finding the faults is to feed them back to developers so they can be fixed for the next or subsequent versions. The nearest equivalent in architecture is snagging and it is designed to ensure the final product is the best it can be for the client at the point of handover. BETA testing is the same and ultimately when issues have been addressed we can all sit back and say we contributed to the success. I have spent time looking at the detail as it is so important to get this right. In fact i’ve spent longer on this than I do on some other tools this year! After all this tool to specify client requirements will drive the tools that deliver them.

Others have already published general comments, observations and queries but given this BETA is an open public BETA, I thought I would post my own detailed feedback in a single public place. Feel free to add comments about the issues I raise and add further comments at the bottom on the blog piece.

This toolkit will be at the centre of the industry moving forward so its important it is right for industry. Getting it right from the start will allow it to be further developed over time. Because the BETA is public everyone has the opportunity to feedback. There are too many out there who will criticise but not put their comments in writing. This is of little help to developers who need the detailed feedback to improve their product.

These comments are designed to help push the development forward and whilst they may appear negative in places it is crucial the industry makes this fit for purpose. It may not be the easiest read if you are not familiar with the toolkit but hopefully I have picked up a lot of relevant issues.

So here are my personal observations:

Sharing and accessing the toolkit

The toolkit is currently created by an individual rather than by a company. What happens if the individual leaves a company after setting up the toolkit? How do other people access the project specific toolkit? (note: the toolkit does allow it to be exported by person A and then imported by person B to their own account but this seems a little primitive when it comes to ideal collaboration). Most systems would allow multiple users access. I think it is highly likely that different consultants would set up different parts. Or are we expecting there to be experts to complete it who are experts in all disciplines?

The only way to share the plan appears to be to download it but would it not be better to simply share the live version (with read only access perhaps as well)? The site could even add a way to comment on the emerging plan.

I understand from talking to the development team that this is on the to do list as its a highly sought after feature but wasn’t able to be achieved in the short delivery timescale. The  plans include allowing read-only access to other project team members by adding email addresses. This will be a very useful feature when added.

Details (stage)

06 Details

Image: The NBS BIM Toolkit Details

‘Construction start’, ‘Construction end’, ‘Construction cost’ and ‘Environmental assessment’ rating would be better at a project level rather than fields for every project stage.

It would then seem logical to remove “Copy from Stage X” if the above is at a project level. Why copy data? Not really a single source of truth?? I might have misunderstood the purpose of this and perhaps it needs some further explanation to explain why this functionality exists.


It is currently extremely difficult to comment on the classification tables individually as there is no method for viewing or extracting the individual tables. I understand this will be available soon.

Its not clear what format tables will be provided and how updates will be dealt with. Whilst the classification system needs to evolve it would be best if this happened at regular intervals in my opinion (i.e first day of the month).

09 Classification

Image: The NBS BIM Toolkit Classifications – example of Gypsum Board Partition Systems

The toolkit currently has Uniclass2015, NBS Create codes and RICS NRM1 included within the toolkit. Here are some comments though on additional classification systems that should be considered for addition:

1. IFC – There is no mapping provided to Industry Foundation Classes (IFC). IFC is described in both the Bew-Richards wedge diagram (see Figure 1 in PAS 1192-2:2013) and subsequent Digital Built Britain (Level 3 BIM) strategy and so is critical for future development. However it is also required for those currently using multiple tools on projects (according to the recent NBS survey this is around 50% of those using BIM approaches). By embedding this information in the toolkit it will allow everyone to become more familiar with this international standard classification system. Ideally the toolkit should describe how elements and products are classified at both IfcProduct and IfcTypeProduct level in both IFC2x3, and in order to future proof it, IFC4 as well. It would also need to include PREDEFINED type information.

2. Bespoke – There is also no way to add bespoke classification systems. Legacy classification systems may be required to be adhered to. Whilst I do believe clients should slowly move away from legacy classification systems to a unified industry standard there needs to be flexibility in the short term. Adding the ability to include bespoke classification in much the same way the toolkit adds Participants would be useful i’m sure to many.

Also what if a user wants to use another specification companies classification system? The toolkit may have been won by NBS but given it was developed with public money it should be able to handle any client classification requirements. I guess the market will dictate whether these other classifications systems are required.

3. Global – As a longer term feature it would be great to see other world wide classification systems added. Alternatively it could link to the buildingSMART Data Dictionary (bsDD) site. The Digital Built Britain strategy hopes to export the UK’s expertise to global markets. Adding other classification systems has 2 advantages. The first would be that other countries would be able to use the free UK toolkit *. This would mean the tool becomes the market leader in many markets (note there are other similar digital plans of work and tools already emerging). Secondly it would allow UK companies to apply their knowledge to wider markets without us needing to change our process completely for different markets.

* There is an interesting question about whether non-UK countries should be allowed to use our toolkit for free given it was developed with government funding (through Innovate UK). You only have to look at the BBC model where the BBC earns an income from BBC worldwide and only allows certain access from outside the UK. I can see pros and cons both ways but the tool needs to decide which way it intends to go. I could also see that having paid for advertising from manufacturers may mean this isn’t an issue (although i’m not a massive fan of the advertising as it takes away from the clean interface although I appreciate this will assist in paying for further development).


The term deliverables implies these are all the required deliverables for the project. Whilst this is true for models we should not forget that models are only one deliverable. Deliverables are required in many forms and BIM is wider than models including Specifications, Reports, Drawings, Spreadsheets etc. Some of these deliverables are covered in Tasks. For me BIM is about ‘Better Information Management’ so Deliverables should be about all project information not just models.

At the moment the toolkit will not replace Task Information Delivery Plans (TIDPs) or Master Information Delivery Plans (MIDPs) for example but I believe that it could easily be adapted to be a far more powerful central project management tool over time. So for me this should for now simply be retitled Model Deliverables or maybe Level of Definition (which is what LOD and LOI are combined) to avoid confusion.

I’ve not tested the ‘Generate Spec’ section so offer no comments here.

Level of Detail (LOD)

I’ve not gone through LOD in any great detail. My concern is really around the current lack of detail for elements at a high level. It is not possible for example to see what the LOD (or LOI) for an Internal Wall might look like. It is unclear whether this will be added as it states ‘Undefined’. Does this mean it will never be defined or has not been defined yet?

LOD 0 should be added to the toolkit to signify that no geometry is required. LOD 1 should signify that only a model representation, either 2D or 3D is required (for example a topographical survey could be a 2D DWG as this is all that is available and this would be received or sourced at Stage 1).

02 Level of Detail

Image: The NBS BIM Toolkit Level of detail

Level of Information (LOI)

The Level of Information or LOI for short describes a list of data deliverables required. The numbering of these means the data can align with the RIBA Plan of Work stages although the tool allows flexibility to apply less or more information at each stage depending on client requirements. The proposed information includes information described in COBie-UK-2012 and subsequently identified in BS 1192-4:2014.

03 Level of Information

Image: The NBS BIM Toolkit Level of information

There are a number of detailed points here to cover:

1. Purpose of each LOI? – Each Level of Information is distinguished by a number (currently 2-6) with each level delivering different information. However it is not immediately clear what each LOI is attempting to satisfy. The LOD component of the toolkit includes a purpose but not LOI. There are descriptions of what should be provided but not its purpose. For example, what will LOI 4 deliver if all the information is provided? The toolkit needs to add some simple descriptions about the purpose of each (they are in accompanying articles but not at the point where LOI is selected). The danger is people start selecting the incorrect LOI because they don’t understand the purpose. This potentially introduces confusion and waste to our industry.

2. Property sets – There is no information about which Property Set (basically in plain language – a folder for properties to fall into) that this information should be placed in within the authoring tool. This could easily be solved by adding this information in a drop-down menu (in a similar way that there is more information under the Tasks menu). Without this it is unclear where this information should be placed in a model and will lead to inconsistent application across tools and authors.

Its important we know which property sets to put our data for consistency and reduce mapping between applications. Are we for example going to put our data in the COBie property sets identified by the Responsibility Matrix spreadsheet scheme OR in the NBS BIM Object Standard property sets which simply put all data in a property set called ‘COBie’? For me in this instance (I think on the whole the object standard is a positive thing) the COBie Responsibility Matrix must take precedence as it fully aligns with BS 1192-4:2014 but I suspect NBS will want to align with their own standard.

3. Property naming – It is not evidently clear how the naming of properties have been arrived at. ISO 16739:2013 provides standard properties for all aspects of a project (it isn’t 100% but it should form the basis for determining properties). To me the data should fully align with this standard if the UK truly has a desire to be a global leader. There are already other tools that align more rigidly with the standard so I can see other countries going down that route rather than using a semantic choice of language.

Properties should also be consistent in the toolkit interface. For example Space Height also appears as Space height. Also properties should stick to fully aligning with COBie-UK-2012. Some of the properties do such as ModelNumber and ModelReference but others such as Bar code (should be BarCode) and Tag number (should be TagNumber) don’t. This might seem very petty but we should be consistent with standards to help adoption and reduce confusion.

4. Type/Component – There is no information in the interface to explain whether this information is placed at Type or Component (instance) level. This information for LOI 6 for example is described in both COBie-UK-2012 and BS 1192-4:2014 but it requires the user to go and research where this information needs to be placed. Adding this information would make the toolkit more complete for those who have to technically apply this data. As point 1 it would allow users to know where to place this data in a model and provide greater consistency.

5. Value type – The information in the toolkit does not describe what type of data is required in each tool. For example some may be text values, others numbers or dates etc. This should also align with IFC data types for robust model setup.

6. Expected or requirable – There is an assumption that all these data fields should be provided. On the face of it this might not seem an issue however under the requirements of COBie-UK-2012 and BS 1192-4 not all of this data is automatically expected. For example AssetType and Manufacturer are expected data fields as part of the standard schema but other data such as Features and ModelReference are requirable (i.e optional for the client to determine whether they need them or not). This means that all projects will need to provide this data whether the client requires it or not. Essentially the industry could be wasting time creating unwanted data. For me the tool needs another level of detail to show which are expected and which are requirable if defined by the client. The tool then needs to allow the client (or client representative) to determine which requirable fields are needed.

7. More/less data? – There is no way to remove data fields or add additional ones. It assumes a one size fits all for every element, product and system. This means if a client wants to deviate from the data determined by NBS (and its partners) then they either need to supplement with something else (end up describing the data not required and required in an Employers Information Requirement (EIR) document for example or not use the toolkit at all.

8. COBie – Not all COBie fields are included in the toolkit. For example the Name field is not described. The Name field is a critical field to create uniqueness for models at both the Type and Component level. Now it may not be required from a supplier/manufacturer but it will be required from the model author. The LOI should also identify the Category field (which is the Uniclass 2015 classification assuming Uniclass 2015 is used by a client of course).

9. BS 1192-4:2014 – The publication of BS 1192-4 identified additional properties to COBie-UK-2012 that may be required for both infrastructure and buildings. These fields are not currently identified in the toolkit. So how do these values get specified (and subsequently verified) by a client?

10. Data for non-modelled elements, products and systems – The toolkit provides information requirements for things that will never be modelled. The toolkit assumes everything can be modelled and information applied to them. Are designers or more realistically manufacturers really going to model door handles? (e.g. Pr_30_36_59_25 Door lever handle sets) Or paint?? (e.g. Pr_35_31_85_48 Luminous paints). Or glazing beads??? (e.g. Pr_35_90_07_33 Glazing beads). We have already seen the NBS National BIM Library develop paint content as an example but it simply won’t be used by model authors. This is just leads to confusion about what is truly required in models. This information can of course be provided but not in the model in my opinion. If the NBS don’t intend some of these to be in a model then it should state clearly where this information will be provided. I guess we could use the Comments box but we could end up writing war and peace about where information is required.

11. Existing – There is an assumption that all elements, products and systems are new but information would be different if information needs to be provided for existing elements, products and systems. For example BS 1192-4:2014 Table 14 specifically identifies required attribute data for existing Components (includes AssessmentDate, AssessmentDescription & AssessmentCondition). How can the toolkit handle existing buildings?

12. Description – The Description field for every element, system and product is not clear whether this is the Type Name, Type Description, Component Description or all? More clarity is needed for model authors. At the Type level I would expect the Description to populate the Name field so we need more explanation so we all work in a consistent manner.

13. Data author – The way the toolkit is setup is that information for each element, product and system is assumed to be created by a single author at each stage. There is no flexibility for allowing multiple data authors. For example as an architect I can currently fully automate 98% of AssetType data but if this is our responsibility I would then have to create all the other data? Should I scrap my automation and let someone else create it? Personally I believe it needs to allow data to be determined at an individual parameter level as well as a global level.

14. Predetermined data – Some elements require fields that can be predetermined without modelling. For example a toilet will always have a value of ‘Fixed’ for AssetType. So the toolkit should state this value as mandatory rather than explaining the standard available options. The downloadable product data template should also already have the value ‘Fixed’ in the AssetType cell.

15. Model data or connected data? – There is an assumption that all of the data will be in the model. The verification process will require an IFC to test the model. However there is currently no published methodology to get this data using open workflows from a product manufacturer into a model without a model being produced by a manufacturer or a design author inserting this content into their model. As a designer I don’t believe it is our job to use detailed content and data from manufacturers. This means we would need to rely on manufacturers. Are manufacturers really geared up to provide models for each project? I’m not convinced.

16. COBie fields for all elements, products and systems? – This is one that is a hot topic of debate. The license to use COBie is very clear that if you deviate from the standard you can no longer call it COBie. So detailed COBie data fields are not required for example for Beams, Columns, Slabs or Walls. Yet the toolkit assumes these values should be provided for everything (or at least everything I have searched for!). There needs to be more clarity about this topic. In the UK are we providing FM data for handover for all elements, products or systems or only those that are maintainable assets under COBie? If its the former we have to stop calling it COBie and just call it something else.

17. Space data – Space information provides huge value at the early stages of a project. The vast majority of Spaces have ‘Undefined’ next to them. As well as producing clients with confirmation of the spaces they require the data in a space can be used to derive quantity data even without components being modelled. For example, finishes information or the number of doors can be derived. COBie-UK-2012 and BS 1192-4:2014 both identify Space data so to me it seems logical this should be in the toolkit. As mentioned before it is unclear whether this will be added later?

Also we have projects for the Education Funding Agency (EFA) which already have determined the data they require for projects. How can these data requirements be incorporated into the toolkit given they use very specific data requirements. I can see how the toolkit could vastly improve the process for validation as at present much of the process has to be done manually. The toolkit has to be able to deal with these requirements.

18. Space Net Area – The default LOI value if not selected states that areas should be provided in mm². However net areas are normally measured in m². It would make more sense if m2 was the default value rather than mm². It should also have a note to point out where this can be changed as its not immediately clear that this is done at the project level if you go straight to the detail.

19. Facility, Floors, Zones etc – The toolkit very much focusses on data for spaces, elements, products and systems. However data required for projects is much wider than this. For example both COBie-UK-2012 and BS 1192-4:2014 identify specific values (both expected and requirable) for Facility (Project, Site and Building). How does a client specify their zoning requirements that want to be met? How does this get handled in the verification process? I can only assume this has be done outside the toolkit. This is a missed opportunity in my opinion as it could have been incorporated with little effort.

20. Data purpose – Much of the data seems to focus on data that would be provided by a manufacturer that could be used for FM. There seems to be little consideration for data to be used for other purposes. For example what about data for performance (fire, acoustic, surface spread of flame etc that are required values – not actual product values which may be greater than the required performance)? Or values that would allow IFC files to achieve BREEAM or other environmental compliance? Does it need 2 values – one for performance and one for the achieved value. There is an important distinction here.

21. Importing and updating external data – There appears to be currently no method to allow a user to import data into the toolkit. Some of the data in the toolkit is already created in other databases. For example, project participants already exist in Common Data Environments (CDEs). Without an import function there is likely to be duplication of work between systems and technology. It could be that standard requirement databases for certain clients could be linked to the toolkit. This would mean consistent approaches for clients with large estates, including different government departments.

22. LOI 0 and/or 1? – At the moment the lowest LOI that can be selected is LOI 2. It would seem logical to have an LOI for where no data exists. What if someone is only appointed to create a model for visualisation and there is absolutely no need for data? There needs to be a way to ‘classify’ this. Or another example would be if someone wants to create some geometry for massing that does not need to be passed to anyone else? Now i’m not saying this is right but I think the toolkit needs to have that flexibility. It might also help provide more distinction between what is a 3D project and what is actually BIM.

23. LOI 7? – Now i’m no expert on FM and this point has been raised on Twitter and LinkedIn by Kath Fontana from BAM FM who is far more knowledgable about this subject than me. But there needs to be consideration of data that may be required to be added during RIBA Plan of Work 2013 Stage 7 ‘In Use’. For me this would really push the adoption of BIM by FM professionals who on the whole have been slow to see the benefits of BIM.

24. Quantity data – There is very little to cover data required for costing. I would expect the LOI to identify somewhere typical Base Quantities that would be available with each type of element.


The toolkit currently allows companies to be added and has a section for individuals but the individuals part is currently not functioning. It would be better to turn this off until it is functional or simply add the functionality if it is required. I’m not convinced we need this as this an overall project plan rather than a company individual plan.

If we are going to be able to list individuals then we should also be able to define their individual roles on the project aligned with PAS 1192-2:2013. i.e Task Team Manager, Task Information Manager, Interface Manager, BIM Author etc.

As a minor change I would prefer to see this section renamed Actors as this aligns with how buildingSMART refer to project participants. Again this would align with the aspirations to export UK BIM services to wider parts of the world and move away from a semantic choice of language.


Are we forgetting process? Process to me is key to determining how we should tackle our move to a digital construction industry. Without considering process then we will fail in my opinion.

At an early stage of a project we will know that we will have walls and we can determine that we will need external and internal walls but i’m not convinced you will know what you need beyond this. How do we add detailed requirements early on? Do we add everything? So how do we determine what LOD and LOI for a detailed product or system will be at the beginning of a project?

More fundamentally I still think the toolkit thinks the wrong way round. BIM presentations always say we should start with the end in mind. And it could be argued that the toolkit focusses on this approach. However it nails into detail without any real questions about why you need the data in the first place. You could of course answer these questions elsewhere (i.e in an EIR) but how do you connect those two things?

I would have developed the toolkit based on a set of plain language questions that a client has the capability to answer (I don’t believe the toolkit will be used directly by our clients as most have never built a building before so would have no idea where to start). So you could ask “Do you wish to carry out room booking in the final building?” and this would automatically determine the data required to meet this need.

Or questions may start with a general question and then have further sub-questions. For example “Do you require the building to achieve a specific environmental standard?” and then sub-questions could be “Do you require the project to achieve BREEAM?” or “Do you require the project to achieve LEED?”. There could be client defined answers not on a standard list which would then require configuring but on the whole I believe standard questions could drive the required data need.

Further development of the above could be completed by the project team, like “Which BREEAM standards are compliance required for?”, with a picklist to choose from.

Some of the questions may be determined by other factors. For example there will be a planning requirement to meet a BREEAM standard or provide a set number of parking spaces to meet a travel plan. Again these could drive the required data fields to be provided.

Product Data Templates

The toolkit provides downloadable excel documents for manufacturers in the form or manufacturer product data templates or PDTs for short. Whilst PDTs are designed to provide a way of improving product selection workflows (which is a good thing) it is unclear how this information will be used in a modelling workflow. Does this data get pulled into the model or live outside the model? What is the workflow between a completed data sheet and the model? How does this workflow relate to open standards?

04 Product Data Template

Image: The NBS BIM Toolkit downloaded Product Data Template (PDT) and opened in Excel

The real big question about PDTs is we seem to have ended up with the NBS (RIBA Enterprises) developing a series of PDTs and also CIBSE who began this work originally having their own (currently services and landscape PDTs). Its not clear if they have a different purpose? This makes it highly confusing for manufacturers about what they need to do. Do they do one or do both and we end up creating waste in the industry? It is a shame that both institutions (NBS through the RIBA) have not developed this in conjunction with CIBSE. I appreciate the toolkit was developed in an extremely constrained timescale but there appears to be no longer term plans to merge the approaches as far as I can tell?

Project Details

Would seem logical to add here standard fields required for COBie. Title should be renamed ProjectName. ProjectDescription, SiteName, SiteDescription, BuildingName, BuildingDescription. Also at this level add Current Project Stage and use the values required for COBie (i.e. CIC Stages).

There should also be a field to add the BS1192:2007/PAS1192-2:2013 Project Code for the project. (The Reference field is more likely to be as an internal project code in my view).


Screen Shot 2015-04-19 at 19.06.37

Image: The NBS BIM Toolkit sample list of Roles

1. Role pull-down menu

The toolkit offers a standard set of roles out of the box. This is a pull down list with no option to customise. There are a number of ‘standard’ roles missing and in particular those identified in the new CDM 2015 regulations, which came into force on April 6th 2015, including Principal Designer and Main Contractor. Should therefore Health and Safety consultant even exist on the list?

Other missing roles that we have identified include: Aerial surveyor, Building surveyor, Commercial agent, Coordination managementCost consultant, Education consultant, Fabricator, Facade engineer (rather than cladding consultant?), FF&E consultant, Funder, Funders agent, Funders surveyor, ICT consultant, Illustrator, Installer, Lead consultant, Manufacturer, Model maker, Photographer, Reinforcement detailer, Rights of light surveyor, Strategic consultant, Sub-contractorSupplier, Swimming pool consultant, Tenant and Transport consultant. There may be some infrastructure roles missing here but this is outside my area of expertise.

Its not entirely clear why there is ‘Consultant’, ‘Consultants’, ‘Other Consultant’ and ‘Other Consultants’ in the list. This could just be simplified to ‘Other Consultant’ or General (non-disciplinary) as it is in BS 1192:2007?

I also think there should be an option to split further Building services design into Electrical designer, Mechanical designer, Heating and ventilation designer etc (as BS 1192:2007).

Finally I would remove BIM Manager as this is not a recognised project role. This is a role within a company to deliver BIM and not a project role. PAS 1192-2:2013 and the CIC BIM Protocol specifically calls this an ‘Information management’ role and there is identification of ‘Coordination management’ (see Figure 10).

2. Multiple roles

There is no way to have two participants performing the same role on a project? You could easily have 2 surveyors or 2 architects for example, on any one project. I think this flexibility needs to be considered to enable the tool to be used on all projects. If a Role was added twice it could easily be Surveyor 2 and so on. My understanding from the developers that this is on the to do list.

3. Role codes

The way the toolkit is currently setup there is no way to assign a role code to the role descriptions. There are a number of standard codes identified in BS 1192:2007 and further codes were developed by the AEC (UK) Committee to address industry need. There is a need for further standardisation since new roles have been identified including Information Manager, Coordination Manager etc. Without this we will be forced to write out the entire list again in a Post-contract BIM Execution Plan (BEP). To me this is just waste that could easily be removed. The agreed roles with codes could be simply referenced in a BEP.


Some tasks may be performed by multiple participants. The toolkit partially addresses this but only by putting the same task in multiple times. I can see how this could be a benefit for export but would it not be better if it was a single task that could have multiple responsibilities. This would keep the list more manageable.

05 Tasks

Image: The NBS BIM Toolkit Tasks

It would be helpful as well as identifying tasks that dates for tasks to start and end could be added. Aligning them with a stage is fine but sometimes stages can be extremely long. The toolkit should be able to act as a project programme.

Going forward it would be nice to see the toolkit developed to make tasks connected so that a specific task can not be done until another task has been completed. These interdependencies are important to prevent the task list just be a mammoth list with no real connection to project processes.

Verification of LOD (geometry)

At the time of writing the verification section is unavailable in the public beta so comments are limited here. I am looking forward to testing this particular part of the toolkit. This part could be a real game changer in terms of quality of data.

One interesting question here is how will Level of Detail be checked? Can it be done? How far away are we from being able to do this? If not it begs the question how many people will truly follow the guidance provided for LOD. Should it and will it be checked manually by Information Managers in the meantime?

08 Verification

Image: The NBS BIM Toolkit Verification section – not yet available

Verification of LOI (information)

As noted above at the time of writing the verification section is unavailable in the public beta so comments are limited here.

If the toolkit does not define which requirable fields for COBie are needed for Contact, Facility, Floor, Zone etc then how will the toolkit carry out verification? Obviously this can be defined in an Employers Information Requirement (EIR) document but how would the verification process know what to check?


As I said earlier in the post the overall message is one of a good start to this project. It is essential for industry if we want to create consistent high quality outputs and improve project outcomes.

At the moment though the toolkit would be unworkable for most of our projects. It doesn’t tick enough of the technical requirements for us to consistently apply it in our models and projects. More importantly i’m not convinced it currently fits with our architectural process. The toolkit focusses far too much on the detail and not enough on the steps that are arrived at that detail. We will have to test on a real project and I hope that this will happen around September this year.

I’m also concerned about the amount of duplication of information between the standard Level 2 documentation. The toolkit has the opportunity to become far more than a tool to define Tasks, Roles, Level of Detail and Level of Information. It could easily become the Employers Information Requirements (EIR), Task & Master Information Delivery Plans, BIM Execution Plans (both pre and post-contract). However what is the incentive to develop the toolkit further? NBS do have a commitment to develop it for 5 years but what does that mean in reality? Are there defined requirements or is it simply up to NBS to define. How much influence can industry have? Longer term does it need more investment as part of the Digital Built Britain (Level 3 BIM) Strategy? Does it mean only NBS can now do this development work given it is branded the ‘NBS BIM Toolkit’?

At the moment the toolkit has more work to do but hopefully the final (or rather next) release around June 2015 will deal with many of the points raised in this blog piece and it will become a go-to central tool for the industry that we can use on all our projects.

Rob Jackson, Associate Director, Bond Bryan Architects


3 thoughts on “The NBS BIM Toolkit public BETA – feedback

  1. Hi
    The tool is still in beta and I am sure we will see more stability and more polished functionalities during the next months.
    I have seen data disappearing after relogging and this is quite worrying, a proper backup must be in place.
    What we shouldn’t forget is that NBS` focus is product related and the website will be focussing on attracting business from the product selection etc.
    While the process part comes from the RIBA knowledge itself, NBS strength is in the product/model element data.
    More integration with PAS1192 worfklows would be welcomed and I do agree that there is a need for something which enforces the process in a more comprehensive way.

    • I don’t want to hijack the Blog but I’d like to hear more about the issues mentioned in your response.

      Please drop me a direct message or via the Beta bar in the NBS BIM Toolkit & I’ll pick this up with you.

      Many thanks,

      Seth – NBS Beta

  2. Great article. I’ve been getting to grips with the tool myself recently with a mind to use it within our BIM course at Coventry university.

    Many of the ‘issues’ or missing options you pointed out aligned with my thinking exactly such as multiple roles, integration of adding time deadlines to tasks and a continuing link between tasks from stage to stage.

    I also think it would be really good to have the option to add further bespoke deliverables outside of the set classifications to ensure that if additional bespoke deliverables were required they wouldn’t get missed simply down to not being stated in the tool kit.

    As you say with further development this could really be a one stop shop for projects if it was to include BxP and EIR’s etc. as well as great IFC functionality.

    An absolute must for me is the cloud based registration and interaction to the projects/tool kits. Having to download a fixed state of a project totally goes against the very iterative nature projects and project planning. It has to be live collaboration! A similar systems such as in CDE platforms and A360 etc. will work great.

    Thanks for the post, lots of food for thought.

    Danny- Architect-BIM.

Leave a Reply

Your email address will not be published. Required fields are marked *

2 × 1 =