This is a recorded conversation (hosted by Christopher Parsons) about measuring the impact of knowledge management in an architecture/engineering/construction (AEC) firm, focusing on the recurring challenge of "overhead" work versus billable project work. Speakers debate whether KM tasks should be treated as overhead or billed as part of projects, highlight the need to embed KM into project workflows to reduce overhead, and raise cultural barriers in project-first firms. The chunk also addresses the difficulty of measuring prevented problems ("things that don't happen") and gives concrete measurement examples: a client reduced proposal drafting time from ~16–18 hours to 2–3 hours using synthesis AI, and a firm measured whether recurring drawing issues decreased after a targeted learning & development program.
Questions this video answers
October 21, 2025.
Before: about 16–18 hours; After: about 2–3 hours (≈80% improvement).
Chapters
And a term that keeps coming up, which I know nobody likes to talk about here, is just like this overhead of doing what you're talking about, right? You've got to have people do the thing to get the data into a structured form. And I imagine there's a bit of a, oh, wow, what if we don't need to do that? Because the AI can do some of that. Even though, like Chris just said, sometimes it's a slot machine, you still need to kind of chase it down. So you're still spending time either through overhead to accomplish that task or through following up and making sure with your staff who's not overhead doing those kinds of things. I'm curious how your firm sees that. Obviously, there's been some intention around putting you in this position of doing this thing, which is an overhead position, but for the benefit of the firm. And so there's some kind of value attached to that. But I'm just curious, how are those conversations that you have all the time about overhead? Because again, there's value, but it takes time.
I wake up every morning thinking about the impact of overhead on all of this, and I go to bed every night thinking about it. Absolutely, yes. I mean, we've had a lot of debates internally about whether or not this actually qualifies as overhead or whether it should be qualified as part and parcel of the project process and therefore part of the billable work. And, you know, I see it both ways. On the one hand, making it overhead, calling it out, and that way it gives it a certain amount of attention and autonomy of a sort, you know, in the, in how it's viewed. And it also gives you a little bit more flexibility. Like you're not limited by what we've promised the project value is going to be. You can do it as overhead and it doesn't have to be hemmed in by the. The project valuation. On the other hand, if you can call it billable work because, you know, it's in the course of work that you're developing this knowledge and that you need to document this knowledge for the success of this project that you're working on, and also the next project that you're working on, you know, then, then it's less of a financial liability. So there's, you know, there's a attention, and I think it's a little bit of both. And so to me, it's about minimizing the overhead and making sure that most of the processes support the work in the, in the course of the project work, but without creating too much of a liability for each individual project. I don't want to. I don't want to unfairly inflate the cost of doing the work, but to the extent that a lot of this could be optimized so that it does just flow as part of our natural project processes, then it could reduce the overhead for the company and for each individual project. And that's ultimately my goal. But I do think that it's important for the company to invest a bit into this as part of the company values. And there's. There is a chunk of this that truly can't be encapsulated in individual projects and that we need to make sure that we are putting the attention there.
You touched on this earlier. It's a conversation that you and I have had many times. It's like working within the culture that you have. And I'm paraphrasing here, so I apologize if I'm not quite right, but I remember you saying something like snowhead is, I don't know if you said suspicious or highly biased towards projects, you know, versus things that aren't projects, you know, like. Meaning project work always comes first and second and third. And then there's like, stuff that's outside of projects, and then that's the spectrum. Like, some firms are just like you described, and then there's others that like, they are kind of like businesses who happen to do architecture versus being design firms who happen to have to do business in order to keep doing design. You know, there's like a whole spectrum there.
Yeah. And yeah, I hate to say that they're suspicious of anything that isn't project work, but the art, that was maybe.
Too sharp a point to put on.
I don't think that's true. But there is. I mean, we're very focused on our project. We are project forward, for sure. And so to the extent that anything that we're doing as a business really supports the project work and is clearly tied to the quality of the project delivery, then that's embraced. To the extent that we lose the connection between those two ideas of like, we've got operations working over here on one thing, and we've got project teams working over here on another thing, and they are. They've lost the connection. That's when it becomes problematic.
So from like a change management perspective, I think what you're saying is you need to show the benefit to project teams of all these different things that you're doing on the business side.
Yeah. To project teams and ultimately the project delivery, the quality of design is number one. And the quality of delivery is, you know, side by side with that. That's our number one priority. And so everything that I do with knowledge management ultimately needs to be in service of that. Otherwise, you're right. Then there is suspicion about it, like, what are we doing?
But this. This overhead thing keeps coming up in my mind, which I. And I want to say this thing like that, I think just has to be said, which is, like, we can't measure things that don't happen. Right. And all this proactive stuff. All this proactive stuff is so that bad things don't happen. Right. Or so that we can minimize the amount of time it takes to do this thing that we've done 50 times, but nobody ever documented, like, it's stuff like that. And so I don't know if you guys have any ideas of how to measure things that don't happen. I would love to hear them.
But.
But to me, like, there's a huge value here that is. This seems like a conversation that shouldn't need to happen, but it does. It needs to happen all the time.
Yes, it does. Yeah. And I'm big on that. I'm big on overhead.
You have a thesis on this?
Yeah, I could write a thesis on it at this point, I think. But yes, being able to categorize what we're doing as overhead and track it as we do projects is very important. And I know a lot of firms do that already. It is not what Snohetter was doing when I came in, and it hasn't been what Snoheta was doing for a very long time, like, really carving out chunks of overhead effort and tracking them as projects in themselves. It was kind of just like a big bucket of overhead and then project work. And that was revealing of that value that we talked about earlier or in this conversation about the focus on project work quality and delivery. But what I ultimately needed to carve out space for overhead projects to be defined and have a similar amount of care taken with what they encompass, what the delivery looks like, who's working on it, how much they're working on it, and all of that sort of stuff. So tracking overhead in that way is very important. And even if, like, we are doing some part of it as part of the project delivery, I've been trying to work out with our teams how to call it out as what it is as part of the project delivery that it isn't necessarily putting in that big bucket. Yeah, yeah, exactly.
Makes sense.
I've got some stuff about measuring things that don't happen.
I was going to say that AI can do that.
I've got three examples. Well, I mean, it will tell you that it can. So a few things. So we've got a client. The first one's a synthesis thing. We have a client who's using synthesis AI search to help with proposal development and specifically answering RFP questions. And so she took a proposal and measured how long it took pre AI, and it was something like 18 hours, 16 hours. And then with AI it was two or three hours. So that's like an 80% improvement. So of course it requires you to do measurement upfront in order to compare it against the other thing. A lot of our clients use things like engagement surveys to understand do people feel like they know what's going on in the company? Do they have the resources they need to do their job? And again, it's kind of before and after. So when everything's smoothing, you have to have a. In order to a post occupancy survey, you have to do a pre occupancy survey survey.
Right?
Like, so you have to have like, both sides of the data. We have a client who implemented a whole learning and development program driven from the CA team that is like, look, it's the same 10 issues on drawings all the time. And so we should be teaching these things. And then they go back and they can measure whether or not those things are still showing up on drawings. So, like, it can be done. It takes, ironically, it takes effort and overhead to measure what, whether or not the overhead is being effective, which is the whole thing. But that is, you know, working in it is one of the worst examples of what we're talking about where if you do your job right in it, nobody even knows that it's happening. You know, like, it's only when things go wrong is it visible that there's an IT department, you know, like it's right.
