Specs + Data = ?

Contributed by Jeffrey Potter

The AEC industry is finally recognizing their treasure chest of data. It’s like the explosion of analytics with baseball (aka sabermetrics), it took over 100 years for baseball to realize what data chest they had and how to implement it. The same event is happening within the AEC industry and you better hop on the train now because it’s moving fast. Everything from the design of the building to the construction of the building is using data now in some capacity, but what about the specs, how can data assist or improve the role of specifications? The answer is probably not what you think…

When I realized the treasure chest of spec data I was sitting on, I work with a software where everything is stored on a server, my mind literally had one of those light bulb moments. Initially, from our project history in the server, I was able to figure the most commonly used sections and do two things. First, I cut down our 100-page specifications checklist to 40-pages, and finally to what is now 10-pages, of all the common sections for selections. Second, I created a historical archive where we keep those sections that have only been used once or twice in the past 4 years to be stored. My mind was blown, the possibilities where endless. I got amazing reviews for the two items above, and had so many other ideas on how to extract specification data and analyze it, but was going in the wrong direction until…

A few months later, I had another light bulb moment. There is such a thing as good data and bad/useless data. I was moving into the bad/useless data realm. For one example I wanted to figure or set up a template project with the top X amount of sections. Because every good size project has the same basic sections, it would be easy to set up and save time, but this conflicted with the Revit Model and how we bring specifications into our software. Which essentially does the same thing as a template project, although much quicker and smarter. Then, what would I do on small projects or much larger projects? This wasn’t the solution I was looking for on my data set.

My next train of thought took me down some exciting new avenues on how we can leverage data with specifications: product use and production. Product use is extremely important and I simply define it as “a product specified on a project that was installed”, pretty simple. Why is this important? Because if I am specifying Product A on 85% of my projects, yet on 75% of those projects, the Contractor is substituting for Product B… Why am I specifying this product? Why is the Contractor substituting? Is it because Product A cost more, harder on labor? Is it a regional item where Contractors in a specific region want Product B? Is my firm specifying old technology? Is one office favoring Product A over Product B? As you can see many questions arise, but the big ones are …

If I am specifying Product A and it’s being substituted X amount of time, that COSTS the team time and money every single time. What about RFI’s? The same goes for RFI’s. If we get X percentage of RFI’s on a certain product is it because we are specifying it wrong, detailing it wrong, what is the case? I have heard that it costs my firm over $700 to review an RFI. That was a few years back, so it could have changed, but it just shows the impact RFI’s have. I’m not saying that this data is the answer for all substitutions or RFI’s, but it probably will eliminate a solid portion.
 
The second data set that is available is production on the specifier side. I’m not talking about the Amazon ankle bracelet monitoring of how much time someone is billing or how much work they are getting done, but in theory one could find the “true” time spent in every section on a server-based spec software. What I’m talking about here is this… How long is someone spending in each section, editing it down to the project requirements? If a section is consistently taking a long time to edit, why is that the case? Are we specifying older products? Are certain regional offices changing products? All these questions, plus many, many more can be answered by looking deeply at the software server. From this, a specifications writer can appropriately manage work time for a given project, correctly specify the right product, and update masters accordingly.
 
Unfortunately, the software doesn’t exist for the first data set of product use. The data is there in firm archives, but it would take a huge effort for someone to manually get this data. For the production data set, the software companies would have to enable this feature on their program. The data is there but would need some configuration by the software company. A simple program, if one doesn’t know SQL, would be Power BI to extract and analyze the data set.
 
Specs, in this data revolution, seem to be an afterthought because these are just word documents. How can you get data from word documents? Well, the two examples above show you how to get specifications into the 21st century and make them a part of this revolution. Right now, I am using some of this data to help reorganize and refocus my firms master specification library. By taking the most common sections used, I shortened our project checklist, which enabled us to actually meet with the project teams to discuss the initial spec edits. This has added better coordination and added more overall “value” to the spec writer and Design Development Project Manual.
 
I was also able to set up the specifications software to conduct or automate basic edits based on soft data. I didn’t have hard data, but I have worked on over 300 projects in the past 4 years, so I know what is specified and what is not. I used that soft data and set the sections up in our software program, so now the software does a majority of the initial edits when the sections are brought in from the Revit model. This has cut down my editing time from about 10-15 minutes per section to under 5 minutes per section on the initial pass through. Where I was spending over 9 hours on 90+ sections, I can now say I spend about half the time on the same amount of sections.
 
To answer my equation above in the title “specs + data = better overall management”. The data in specs can cut down cost, time, energy, and assist in better management of the projects and master libraries. Once the big software companies come around to product use and production data, the benefits will be even greater, and specifications will truly be in this conversation of data and earn a right to stay in it. It will take some work, but it will revolution not just the project manual, but also how products are selected. Data is everything, we just need to leverage it. We should be working proactively towards a better, more predictable future, not reacting to the past.

(Editor's Note: You can view this blog and more on Jeffrey Potter's blog, In My Element.)