Design Change Log

One of the things we've mentioned a couple of times is the idea of a design log. This seems sort of obvious but it's actually (laugh) really hard to do. You're in the middle of stuff, you're on the phone, you're typing emails, you're doing all this stuff; you're kinda keeping lots of things going, you're multi-tasking. And then somebody's little nagging thing in your head is saying "Wait, somebody told me to keep a design log". You have to remember to stop what you're doing, you just had a phone call with a client, they ask you to make a change, you got to go and keep track of that. You're not necessarily putting a lot of information in; what you're really focusing on is what was the change; so, a quick little description, might be bigger if it's important and more like a paragraph or something.

But, it could be just a couple of words like take the second stair out and replace it with this; you know, something like that. Who it was that made that request and in this case, you'll notice that it's actual names. Typically, if there's a lot of people involved it might be names and then the association that they have. So if it's somebody who works for the client, you'd see the client name there as well or if it's somebody that works for the bank, you'd have that information or funder or code official or somebody like that.

So you have some way of backtracking through this and remembering who was actually requesting what that change was. Potentially, it's even, you're keeping track of changes that are being requested by the architects in the office as well. Somebody may come in and review the set; the principal who hasn't been looking at it for a bit comes in and looks and says "I don't like this. I want you to focus more on that. You know, make these changes". You might actually keep track of that here as well just so that everybody can kind of remember how those changes came about down the road.

So, we've got the description, we've got who it is that's making that request and importantly, we have the date. So, this is a very key element for a design log. This is 90% of what this is about is saying "Alright the change that was requested was requested in April so this particular change was requested in April".

That means if we go back and look, if you start seeing stuff that didn't respond to that request in May or June that means something is not right; that somebody wasn't following the sort of order of operations; or if somebody starts claiming that "Well we told you back in February that we wanted this change"; you look at your design logs and nope, it was actually April 10th. It's a way of just keeping track and importantly, not just general idea of keeping track but a litigation sense of keeping track when decisions were being made.

Often you'll find that something that seems incredibly important in this moment while you're on the phone and somebody's making a change and it becomes this important thing and you keep the date; but then down the road other changes overtake it anyway and it doesn't really matter. We're really worried about one thing, we go along, go along, go along and then it turns out the client says "You know we don't have enough money for that entire wing anyways so we're just taking that whole thing off".

So a lot of these will end up being non-issues; it won't really matter. That's not what you're worried about. What you're worried about are the few that might become problems down the road. You're always hoping for the best that the project has no problems; there's no litigation; there's no arbitration; everything gonna be happy and everybody's gonna love the project. That's what you're hoping and that's good but you also have to prepare if anything does go wrong. This is what you're doing when you're preparing for So you're keeping track of the information so if somebody's asking you three years down the road in some court or in some arbitration setting that "Well why did this decision get made".

You can look back at this log and say "Well that decision was made by a Brown and they wanted to get rid of this and it was approved by such and such". Now, one of the things you'll find when you do these kinds of list is, first of all, the list will get pretty long because there's a lot of changes that are going on and also the date submitted will, that information will all get put into place.

These other ones about date approved and did the decision, is it pending, did get approved. That kind of thing often it will take a while for that to become sort of officially put in and so sometimes that gets put in and sometimes it doesn't. And then in the comment period you'll see on this example here the change will have a cost impact of $21,000. Well, it's pretty unusual for somebody to know that kind of number early on in the process.

That's something that comes down the road with change orders and conversations about "Well if we don't do this and we do that, like how much will that cost". So sometimes that kind of information will get put into this if you happen to have that information but often you don't have that information until much later and so it's not likely for it to get in here. So lots of different bits of information will get put in but the key thing is what the change was, who was asking for it, and what that date was.

That's going to be sort of a basis for how you keep track of all that information down the road.

Log in to access files