Got a problem incorporating quantity take-off (QTO) into digital construction processes? Can you combine COBie principles to make QTO information exchange easy? Join Steven Adams in his journey to do just that.
He has worked for consultants and contractors since the late 1900s, primarily in building services and critical infrastructure, with exposure to architecture and structural design. Since moving from AutoCAD to Revit in the 2000s, Adams has been pushing for more joined up design and improving efficiency of delivery.
In this first instalment of a three-part series, he sets out the problem he faced with QTO and his initial thoughts of a solution.
There’s one ping that always sends dread through my body. It’s when someone who doesn’t create models drops me a line to say: “Hey Steve, can you send me the model for this project?”
This one arrived before 10am, which made life a little more difficult as I am acutely aware of how terse I can be in the morning. Rather than replying with chapter and verse about everything I feel is wrong with that statement, I tried to be proactive and find out what they wanted to do.
“Sure, what do you want to view it in?”
“I was hoping you would tell me that.”
“Okay. What are you trying to do?”
“I need to measure how much cladding there is so I can price it.”
“Right, you can get Navisworks Freedom installed and you can measure from there, but can you not use Bluebeam to do this and measure off the pdf files?”
“Can you show me how to use Navisworks?”
Well, no. That’s not something I want to do. Isn’t there a better way?
“My thoughts turned to the principles of the COBie spreadsheet view: a database of information that anyone can open and use to extract information whenever and however they want.”
COBie principles
This got me thinking about another of my ‘favourite’ phrases to hear: “We’re going to do lifecycle analysis from the model.” It’s particularly worrying when they say they will use the Revit file rather than the shared IFC, which we have better controls and checks over.
Design-stage models can be modelled differently by different appointed parties and, unlike drawings and schedules that are signed off by the engineers, models don’t always get checked properly. I’m sure I’m not the only person who has heard someone say: “As long as the drawing looks right, that’s the main thing.”
On top of that, what is the software going to look at to find its information? I’ve had someone come to me two weeks before a Stage 4 design was due to be delivered saying: “We’ve decided to use this software and these are the requirements of the models.” Okay, good luck with getting that.
So, my thoughts turned to the principles of the COBie spreadsheet view: a database of information that anyone can open and use to extract information whenever and however they want. We know we can schedule our models: that is one of the biggest benefits of the software we use. I definitely don’t want certain elements in COBie, but why can’t I get the Appointed Parties to schedule their design and make them check and validate it before sending?
QTO information exchange
I did some searching for standard QTO, but nothing really explicitly laid out what I wanted – it still revolved around someone else using the models to extract information, or using pdf drawings and counting symbols.
“So I made my first scribblings for a QTO information exchange, or QTOie to its friends.”
COBie, as an asset list, itemises every instance, and from that I could calculate totals of those elements. I was pretty sure I didn’t need to itemise individual walls, structures, etc, (and I wasn’t sure how we would even achieve it) and that is specifically excluded from COBie. So I made my first scribblings for a QTO information exchange, or QTOie to its friends. I heard someone pronounce it as “Cutie” in a meeting, so we’ll go with that. It’s better than “Q-toy”, which is probably more accurate, but less fun.
Ideally, we wanted to break this down into individual buildings, so I borrowed the Facility Sheet from COBie. We wanted to know who is providing the information, so that’s the Contacts Sheet, and also after speaking with the carbon engineers, designers should provide Environmental Product Declarations. They could go on the Documents Sheets, and we could use the same rules as per COBie. Thinking of handover, the documents sheet could also be used for product information.
Type requirement
When it comes down to it, what anyone really needs to know – whether for pricing, procurement, lifecycle analysis or any other sort of analysis – is what is in the design and how much of it is there. So a ‘Type’ sheet was needed.
I like to mull things over walking my dog, and I started thinking about what information I could deliver if I was still modelling in Revit. A unique identifier would be needed for a database to work. I would need to communicate what something is, what it is made up of, and, of course, I would need to show how much is in the design.
In part two, I will detail my final structure and give guidance of what is expected. Like with COBie, I needed to be able to audit what I receive, so using my favoured SMART criteria, I could specify what I would need.
Don’t miss out on BIM and digital construction news: sign up to receive the BIMplus newsletter.
