An accomplished construction specifier, Jeffrey Potter has worked at some of the premiere architecture firms, and now works at Deltek. Across his career, he has pioneered the use of data as a way of looking at processes and seeking to improve them, including knowledge work like specifying. In this fascinating episode, we dive into how specifications are data, and how data about the specification process can make for more efficient spec writing, and ultimately higher quality buildings.
Follow Jeffrey Here: https://www.linkedin.com/in/jeffrey-potter-80304086/
Read his blog here: https://inmyelementspecs.wordpress.com/
Hugh Seaton: Welcome to Data In Construction. I'm Hugh Seaton. Today I'm here with Jeff Potter specification solutions manager at Deltek. Jeff ,Welcome to the podcast.
Jeff Potter: Hey, thank you. Thank you for inviting me, looking forward to it.
Hugh Seaton: Yeah. And actually I invited you because you have a really good blog.
And I was looking at specifications and data because, obviously, working with CSI, that's something I think about a lot. And I thought your blog post about specs and data was really cool. You want to talk a little bit about what led you to write that and let's start with what that was about.
Jeff Potter: Yeah, that's a great question. And it, I mean, man, it was really an idea that kind of evolved over time, I guess. And in my background, I had a warehousing background, so I was all about efficiency and how can I make my processes, more efficient and quicker. How can I get something done quicker? That's the way my mind works.
Like taking my dogs out to go to the bathroom in the morning. My mind is like, how can I make this quicker? Like, I'm at six minutes, how can I knock it down to five? Right. Like that's the way my mind works. So in terms of specifications, There's no, there's no way to track efficiency within specifications, right?
Like it's pretty much all about, You know, kind of how you feel like, yeah, this, this certain task might take me 15 minutes or yeah, a project might take me like four hours, but you don't have any actual data to back that up. And so when I was kind of taking over the specifications department, it was, "you know, how can I make us more efficient? How can I make us better so that we have more time to do other things?" And so one of the initial questions that I had was how many times am I using our master specs, right? Because at the firm I worked at, we had over like a thousand master specs, and it's like, we don't use all thousand of these and it takes too much time to go through and figure out what ones we need to update.
So how can I understand, what ones to focus on, what ones to prioritize when updating. And so I figured out a way was able to figure out what sections are most commonly used and kind of developed a new checklist based off of that. And then from there, it kind of evolved in, "okay. So I know I use these sections most commonly, how about how much time do I spend in each section when editing, right. And that's really what propelled it forward. Was this thinking of as a specifier. Okay. How much time am I spending in a section? Why am I spending so much time in this section? Is it because the basis of design is not what my project teams are using or is the master spec out of date, and I just have to constantly update it on a project by project basis. And then it evolved more into kind of this overall kind of sense that wow, specifications have a lot of data in them. Like a lot of historical data.
When you look at all of the a firm's past construction projects, right? You have in their archives, you have all the submittals, you know what product was specified, you know, every time what product was substituted. And so it's, it's gathering this data and trying to understand, well, if I'm specifying product "a" on all my projects, but it's being substituted eight times out of 10. Why is that right? Is it because the cost is too expensive? Is it shipping? Is it schedule, maybe this product isn't favorable in the region, right? There's a million other questions that you can go with that. And so I've kind of been on this, I guess, personal mission, right?
To get this data from specifications and the way the industry has been working in the past, you know, 10, 20, 30 years is everything is word doc based. Everything is in PDFs and folders. So you can't mine that that data, it wouldn't be beneficial. And so it's trying to figure out some type of platform and some type of way where, I can get an industry push to realize that, Hey, all this data out here can be used, so that we can make better decisions, more efficient decisions in the future, on our projects. But that's, I mean, that's kind of the origin story of where this all started.
Hugh Seaton: That's so cool. So you're looking at processes, at like there's more than one level of what you just talked about. I mean, you started by saying as knowledge workers as people, you know, thinking and do and writing and producing content, for lack of a better word, let's look at what we're doing and start to apply data to it. Maybe productivity isn't the easiest thing, because it's not, but you can still do things like what are we using a lot? What are we not using a lot?
What are we changing a lot where we get stuck? What takes longer than we think it should. Even if it's qualitative, at least you're saying we all feel like we're getting stuck when we're writing about. I dunno, you know, dry wall. I doubt that's, I doubt that's the sticking point, but the fact that you're thinking about the process of knowledge work and I'm taking it at the general sense, because that's, that's I think a good way to start anyway.
As, as a process, that's still, even though it is inherently idiosyncratic, right? Every building's different or, patterns emerge, but nevertheless there's always factors that make them a little different, but at the same time, that doesn't mean you're, you're helpless. It does mean that some things, statistical things might be a little harder, but you can still say, yeah, but we're using the same tools over and over again.
So maybe we, instead of worrying about what we produce. We, we anchor it on tools that are used every time and start from there, which it sounds like you started to do.
Jeff Potter: Yeah, it is right. It's I heard the term many years ago from a friend and he, he basically said, and this kind of revolves around the concept of building information modeling, right. And it's called evidence-based design. Right? You, you, and he gave the example of when you're designing a hospital. And you are trying to place a nurse call station on a certain floor, right? As an architect, you, you, as an experienced architect, you know exactly where that nurse call station should go.
But owners now want justification. Right? And so it's, it's using these computer programs to justify the placement, the ideal placement of a nurse call station. And so I've kind of taken that and transferred it over to specifications, calling it evidence-based specifying. And just trying to make these decisions, these data-driven decisions to better projects.
I mean there's so much out there and there's so many ways that I think just the specification process can improve by using data and you know, it's all about how do we gather data right now. Right? Like what are the tools out there that we can mine this data and track it and, and use it.
And then the conversation, I think explodes because you can go in quite a bit of a direction with it.
Hugh Seaton: I'd like to ask about how the first thing you talked about though, the process side of it, how did that go? Were you able to, to make some headway in, in gathering that data on what we use?
Some of it, it sounds like was just you in your own personal practice. So you got as far as you want it to go, but at a kind of bigger level where you able to, to get the department to start thinking like that?
Jeff Potter: Yeah. I was to a degree, right. The first, I guess, tasks that I use with that data and just about every specifier knows what I'm going to talk about here is, The specification checklist, we called ours the purple sheets.
And it's basically a list of specifications. You hand it over to the project team, they identify the specs and maybe a couple other things within those specs, hand it over. And that's how you develop the project manual or the first iteration of the project manual. And so ours was a hundred pages. And if you think about going through a hundred pages with hundreds of spec sections, I mean, it takes hours for a project team member to do that.
And then I get it and people think, oh, this was developed by spec writers. Like he must love it. No, I hated it. It was such a pain in the butt to go through. And so when I had that first kind of, data on most common specs. I went to my boss at the time and said, Hey, why don't we, we'll do two things, right?
We'll take our master office library, we'll create a historical archive. So anything that's not on the list of, I think it was like 200, right. We're going to throw in this historical archive, it's still be there in case we need it for the future. Right. And then the second thing was, let's shorten this project checklist. Right? And so the first pass, we went from a hundred pages down to 40, and then from there we shortened it down. About a year later, we shorten it down to 10 pages. Because we found out that, you know, there was some information that, that we really didn't need, just based off my own experience and everything.
So that was kind of the first headway. And it, it was really well received across the firm, you know, going from a hundred pages down to 40, down to 10, and the communication factor of it was important too. I mean, you can't just communicate to people like, Hey, we, we shortened it down from a hundred to 40.
Here's the new one, right? It's more like, Hey, I, I just found out what sections are most common, here's the checklist based off of it. And not only is this going to save me time when I process it's going to save you time. Right. Instead of spending maybe two hours, it's going to take you 30 minutes or whatever, right.
And then it kind of evolved from there, but it was really well received at the beginning. And it was, I think with the limitations of technology at the moment, I could only take it so far. You know, like you mentioned, you know, I had my own kind of personal experience there, so when it came to specifications and the software out there, one example was, the firm I was working at was the identification signage section. And so in it, the way it was developed by the previous director of specs was we had three different sign materials. We had like plastic aluminum and like chemically etched zinc, something like that.
And 99 percent of the time we would always use plastic signs. And so in my head, I'm thinking, why am I going through every single project and eliminating this? Right? Like, that's just, it might be five minutes, but I'm doing that on multiple sections with just things that may have been added at one time, just because it might be useful for a future project.
Right. And so using specifications software, I was able to automate that. So when I added that section to a project, I only have plastic signs. Right. And so it, I was able to essentially just by my own numbers cut my time in half, when developing a first iteration of a project manual, which was usually at like a hundred percent DD.
So, I mean, I don't have the hard numbers to back up a lot of what I say, but I've got the experience to say, Hey, it actually cut down my time from eight hours to four hours, or, you know, I've got great feedback from team members, going from a hundred to 40 to 10.
So it's been a process, right? It's been, especially with the current technology. It, like I said, you can only take it so far, but, I'm hoping that the future will change that.
Hugh Seaton: Well, I think process improvements like you just described, thankfully don't need too much proving, right?
Because I think anyone who's seen, what master specs start with, will say, oh, right. So if, if you're just automating the fact that things that we never use or, using some numbers to say, we're going to balance between the things we almost never use. And we, you can draw the line, whether you want to have it there or not. Right.
Is like, if it's in 10% of projects, maybe we don't have it in there. And if it's in 30% of projects, maybe it's worth it. Half the time, it probably is worth it. You know what I mean? Like you don't have to be a specifier to get how that makes a ton of sense. It's just I can imagine that again, you don't need numbers in this case to, to show how the use of numbers is valuable.
Like you can describe it in English without having to show pretty charts.
Jeff Potter: Totally, I agree with that. And, and to take it even one step further, right? Like if I can use that data or personal experience to make those decisions like, Hey, I know a team's not going to use like I'm 99% sure our team's not going to use aluminum signs or stainless steel signs. They're going to use plastic. Right. And I'm going to send out that spec, that's less that they have to review. That's less time that they have to review. Right. It's just a snowball effect that it just cuts time down in the review process as the project goes on.
And it kind of take that, a big step forward is, what I learned from having this list of most common sections. If you're doing, if you work on education, right. And you're, you're doing new projects, new construction from the ground up, every project's going to have chipboard, right.
Every project is going to have paint every project's going to have joint sealants. Some of the finishes are different, but for the most part you've got doors, frames, you've got access panels, you've got insulation, you've got studs.
And so my next big thing was, I never really got around to it, but it was to develop kind of these project templates, right? Like, oh, okay. This is a gymnasium. All right. Like these 50 sections, I fairly confident you're going to need those. And they're going to be pre edited so that you don't really have to review them. Right. Or, oh, a new hospital. These are the hundred sections I know you're going to use or a new high school. Well, I know you're going to need these. Right. And so you can start to really predesign the specifications before you actually get to them, which is, I think extremely helpful for project teams. It's less that they have to review less, that they have to think about.
And then when you're in these early design meetings, you know that, Hey, I know that, you're going to have a weather resistant barrier. Let's have a conversation about that, right? Let's have a conversation about the different types that are out there. So instead of waiting till 50% CD to have that discussion, you're now having it at a hundred percent DD.
So you're moving all of these decisions from the later stages of the project to an earlier stage, which allows them to focus maybe more on some design features, maybe they're waiting on estimates, to see if they need to cut back or maybe something's in flux with the owner or making a decision or something.
But it, it really, I mean, if you can use data at the very beginning of a project and it snowballs and it can cut a lot of time out through the whole project.
Hugh Seaton: And you just, I love that you just put your finger on one of the reasons for doing process improvement and kind of pushing for efficiency, especially for the, the drudgery. Right?
I mean, a lot of what you're saying is we're taking away the stuff that's just repetitive. Yeah. We know, we know, we know, we know there's no, not a lot of thinking to say we're removing pieces that it doesn't take judgment to know we don't need. And as a result, you're compressing the amount of time that's spent on repetitive, less skilled parts of the job.
So people have more time to worry about the hard stuff and really debate. Is this the right solution or does it fit with other things, and apply the things that really people took their job for, right? Like you're the point of the job is the thinking and that feeling of having solved the problem, as opposed to having deleted things that you know you need to delete.
Jeff Potter: Yeah, totally. I mean, it's not to say that someone who's inexperienced can't make those decisions. I mean, it would be a little bit tougher for them to realize that, but if you have a good system in place, I mean, you could set those standards up with a committee and you can. I think you can easily implement right?. And then, how does that translate over to the drawing side? Right. And so this was kind of an exercise that I was involved with, but you can align your keynote verbiage, you can align your details. You can create standard details. And if you already have standard details, then they can be better because you know, Hey, this is a new gymnasium, this is potentially a detail that we're going to use. And it's been vetted with the specifications and that aligns with you know, the kind of standard 80 20 rule where 80% standard, 20% options. And if you follow that all the way through with just setting up your standards across the firm, I mean, you can get a lot done that way.
And you know, I understand architecture is different, right? Because the design fluctuates a lot, and materials... but at the end of the day, if you've got a design feature, out of wood, if you've got wood beams coming across the facade, I mean, that's the same spec, right?
And it might be a different wood material, maybe a different finish on the wood, but 80% of that spec is going to be relatively the same for the most part. Right. And so that mentality used across all the specs, you can go a long way with it. Which is really nice as a specifier. And I think as a project team member, when you review specs.
Hugh Seaton: What I'm really liking about this is part of the point of the entire podcast really is to find times and moments when data is helping to do the job people are already doing. And we talk about that in the field. We talk about that in different parts of the building life cycle and the fact that you have pretty unusually clearly found a way to use data to make the process better. And again, not thousands and thousands of data points so much as, as simple ones. Right? I mean, a lot, I would assume that some of this is saying, well, we use this 10 times and we use that 20 times as opposed to 10,000 versus 5,000.
But so what it's still helping you to over time, get more efficient. And I think that's important that data doesn't always have to be sophisticated statistics and really big base sizes, sometimes you're just saying that stack is higher than that stack. So let's focus on the higher stack.
Jeff Potter: Yeah, exactly. I mean, as the specifier at my previous firm, I worked on a couple of hundred projects a year, so I think I had a decent size set of data. But when you think about the life cycle of a project, right? It could be months. It could be years. So there's a lot of overlap there and it's not that I jumped to conclusions, but I saw the trends the way they were going, right?
Like, oh, okay. I'm seeing that I'm really editing this out on like every project, you know, why is that, um, you know, and answering those questions and then it's going back to, Hey, why are we specifying something this way when it's taking me more time to, you know, specify in a project? Oh, it's because the master is out of date and it's all messed up and I have to pretty much redo it, every project.
But yeah, I mean, it's not like I had thousands of data points saying, yep. This is exactly the data. It was small data points and it was being aware of the trends that were out there within my previous firm. And so how I got on that is, you know, like I said, it's how my mind works and I look back at it now thinking, wow, that was a great thought process for me to do. And it's kind of led me in the direction that I've, I've been in and it's been well received thankfully throughout the industry.
Hugh Seaton: Yeah, I'd love to see it more and it speaks to mindset more than specific process. Right?
It's more that look, we could probably learn some things to do this better, faster, more efficiently. And maybe we have a lot of data, maybe we don't, maybe we just have a little bit of data that gives us a hypothesis, but the cool thing is you're the one doing the work, or at least you're part of a team that's doing the work.
So you don't need a final answer. You just need some things to try out. Right. And that's why I was saying, you may find that, that what you decide to exclude or not exclude might be a moving target and you may decide, you know, we overdid it. We keep having to add things back in or go look them up.
So let's put more back in to the master spec. And by that, I mean the firm's master spec. But you know what I mean? Like, but that's all hypothesis that's saying, right. Well, we're never going to get it perfect. All we can do is keep rolling. And the other thing that does of course is mean because you're keeping an eye on things as stuff changes.
You're not stuck with solutions from five years ago.
Jeff Potter: Yeah. Yeah. I mean, that's a great point that you just mentioned, right? Like there, it's not like when I started having this thought process, it went smoothly, right. There was a lot of trial and error in terms of like developing new processes and, and some of the things that sound great in my mind when you put them into practice, it's like, oh no, this wasn't that great, this is way worse. Right? And so it's luckily I had the support from the firm leaders to kind of do these things and use my own time in a way to kind of develop them and try them out.
And I had teams that were willing to be Guinea pigs on certain things. If it went well, then we escalated it from there and if it didn't, then we just scratched it and you know, didn't revisit it. And so it it's, it is a lot of trial and error. I've thankfully I've been more successful than I, I haven't, you know, I can't, there's been a few times where, you know, I've had ideas and it's like, oh yeah, this is great. And then you realize like, nah, maybe not. It's too much time to develop it, or there's just not enough from doing it. So, yeah, it's been an interesting ride for sure.
Hugh Seaton: Yeah, it's funny, in an earlier time, six Sigma went from, which was a, you know, a quality management based on statistics that sort of came out of the Toyota production system.
That is also lean. I'm just kind of tying some buzzwords together so I can feel good about myself, but six Sigma was often in the nineties, especially towards the end of the nineties, was being deployed in knowledge work where you don't have lots of data, explicitly as a way of thinking, not because, okay, we're going to have statistics.
So some of what you're talking about has a really good history. Where I think that kind of went away, the six Sigma got overtaken by lean and some other things, and we're a little bit less, statistically process focused in some things than maybe we were in the past.
And construction for sure, or AEC for sure it's tougher to aggregate the stats you need to do that, but it's interesting that kind of thinking where it's more about the approach than it is the specific tools, really has a good heritage. And I wonder if what you just described, doesn't connect to design thinking as well. You know what I mean? Like it's a lot of the same stuff.
Jeff Potter: Yeah. And I've been on leadership forums at my firm and I've brought up the question and this kind of goes along with it is, you know, if you ask a young designer who who's a modeler, right. And, um, now how long does it take you to model a roof? Right?
Like in my eyes, you should have an answer. Yes, no roofs are alike, but generally, right? Like you shouldn't be spending, if you're doing a low slope roof, PVC, single ply, you know, it's not like doing that roof is, it's not going to vary between 10 hours to 50 hours.
Right. And so I pose this question of, should we start tracking tasks as, as modelers or designers of, Hey, it took me five hours to do this roof. I want to see what I see what I can do to kick it down to four or, Hey, it took me 10 hours to do this roof, let me go to my BIM department and say, Hey, these are the tools that I need to become more efficient.
And I don't think those are the questions that are necessarily being asked. As an architect, I think those, those questions are important because we're seeing this kind of business model that architecture has always been doing where fees are not necessarily... it's hard to compete in this industry, right? With the fees and consultant fees going up, but maybe not at the same rate, the architecture fees are going up. And then you've got owners with extremely tight schedules. And so it's, it's not like, Hey, we got to turn this out faster. We got to turn out faster, but we're doing the same processes over and over within that within a shortened timeframe.
In my mind, like, let's start asking these questions. How can we become more efficient? Well, let's start tracking how long it takes us to do tasks. Because then as a project manager, you can say, alright, designer one, it takes you five hours to do a roof. Perfect. I know how long it takes you and let's plan you to do work on the cladding for the other eight hours of the day or whatever. Right.
So we just got to start asking those questions.
Hugh Seaton: You know, it's funny, there's that saw, that shows up everywhere, which is you can have it fast, cheap, or good. You can pick two. Yeah. The problem with that is if it winds up being an excuse for not thinking about your process.
It assumes that your resources and your process are fixed. And again, back to the Toyota production system, way, way back in the fifties, I believe it was, there was this belief that you needed so much time and money to stamp something I'm being really generalizing about making cars, which you'll discover I don't know much about, but there, there were some assumptions based on Detroit that this is how, how much it takes to do things. And the Japanese changed the process because they didn't have the cash in the fifties, to do it any other way. And as a result, because the process changed that triangle was no longer valid.
And I think that's the point of design thinking, the point of lean thinking, the point of all these things that are, kind of in a family together, is how do we say we have the resources we have, but we can do a better process to make better use of them. So quality doesn't suffer, but we can do it in less time or because we doing it faster, quality goes up because we have more time to think as, as opposed to doing less knowledge intensive parts of the job.
Totally this idea of that triangle, I think is a bit of a trap and it's a place where you can retreat when you don't, when you think, well, I'm not going to work 90 hours a week. It's like, no, no, that's not the only variable.
Jeff Potter: Yeah. Yeah. Right. And you brought up a great term, "lean," right?
If you're a contractor, it's all about lean right now. Right. Trying to find the most efficient way to do something. And I bring up an example. I don't want to say the contractor's name, but, I was in a meeting doing a tour plant and, this contractor figured out a way based off of feedback from their own guys out in the field that they can save 34 minutes a day by having, basically gang boxes that were kind of mobile.
Right. And so if you think about, wow, 34 minutes a day that's times five that's over two hours a week. So that's over 10 hours a month. That's a whole extra day that these guys are working a month, you know, just, just by doing something so simple. And, and that's the whole idea of the construction industry, right?
And as the architecture industry, we haven't really developed the mindset of lean, right? Like we haven't developed a, you know, I'm sure there's individuals within the architecture world that practice some sort of lean and I would encourage them to share their process, but architecture just doesn't have that mindset right now. Right.
Being able to figure out the inefficiencies in the process, you know, what is important? What's not important. Where can we save time? Like I mentioned, oh, it takes me five hours to do a roof that gives me, you know, X amount of more hours to do a more complicated tasks down the road.
The story of Toyota in the fifties is, I mean, it's phenomenal, right? Like everybody copied it and it's kind of unfortunate. That's why we're having the big supply chain issues right now, but, their way of thinking changed everything from a manufacturing standpoint.
Hugh Seaton: Yep. Well, and I think the supply chain issues are, you can overdo a good thing, you know, you can, you can, I think people focused on one variable instead of more than one, which, which we're looking to rebalance.
Jeff, this has been amazing. I really loved hearing about your approach. And I, I, you know, again, purposely generalized it, cause I think across the AEC building life cycle, there's a lot of room for people to approach problems. And again, if it's not based on if output efficiency, maybe it's use of input efficiency, which is where I saw you, you taking this, which I thought was really exciting.
So thank you for being on the podcast.
Jeff Potter: Yeah. Thank you. Hugh, this was great. And thank you for the invitation.