Schematic Design Tools - Example

Let's consider an example situation. Alright, after the programming presentation, the client says it's not quite right, and they ask for a redesign. So okay, it's after programming, we're presenting the program, we're trying to get everything sort of finalized, and they ask for a redesign, which clearly if it's at the programming phase that's really talking about the program itself. You know what does that mean? Well that's a perfectly reasonable thing. The program needs to be right. It has to be the sort of right program that fits for them, and it has to work through because it's gonna be the starting point for the rest of the project.

The expectation is that programming may take a few back and forths in order to make sure that it's on the right track. So this seems completely reasonable. Let's look at the next one. After the schematic design presentation, the client says it's not quite right, and they ask for a redesign. Oh okay, so where are we in the process? Does that, doing a redesign at that point, make sense?

Yeah, essentially this is the sort of first opportunity for the client to say yeah we're meeting their at least their idea of what the program is. So you're at a spot early enough in the process, maybe you have a couple of options, maybe you don't, maybe you only did one option, but you're early enough that things are schematic enough and loose enough that if things aren't quite where they want to be going, there's not that much lost.

Like it's okay to sort of use what you've learned and then sort of move into the process and revisit the schematic design and kinda go back through. Again, schematic design there's sort of an expectation that there's gonna be a little bit of trying this and that in order to get to that point where everybody starts feeling like everything's sorta rolling forward. Alright, so how do we feel about if we have the exact same thing at the end of design development?

So here at DD, we've already gone through a moment where, at SD, at schematic design, there's been a moment where the client had to sign off and say, yes this is the direction, I'm happy with this direction, let's move forward. So that if we're then going in deep into the project through design development, and we now are have a lot of time invested in this, and we have a lot of information gathered, and now they're saying eh I don't like it, let's redesign.

Well, that's starting to become a little bit of an issue, and you're gonna wanna talk to them about possibly either getting additional service onto the contract or possibly just sort of finding some way to help streamline the process, to get some extra money for redesigning whatever it happens to be. But you're gonna wanna have a conversation about it because you're pretty deep in at that point, and they've had the opportunity to make sure that the project was going in the correct direction.

Okay, now we're at contract documents, at the end of contract documents. We're at the spot where we're now ready to send out for bid, and the client says, oh let's redesign. Well that's clearly problematic because if they've already signed off at the program, and they've signed off at the schematic design, and they've signed off a design development, they really shouldn't be challenging the issues of design at CDs.

That's a sort of completely unreasonable, that's actually effectively gonna kill that contract. And so you would probably be renegotiating the entire contract at that point. As opposed to at design development, we were just saying, well, maybe we can get some additional monies, we can do it as an additional service, couple of extra design options, something like that. Because you know you're still early enough that you can use a lot of what you've done, but by the time you've finished CDs, you're you know 85% of the way through the architectural contract.

So you've spent all the time and all the money already in order to get that work done. So that's essentially a new contract. So the point being here that at each point along the way, this is why you're reviewing the program, why you're reviewing the contract, are we meeting the state of the contract, why you're getting a signoff at programming, why you're getting a signoff at SD, at DD, and then at CDs.

That you're making sure that there's a very clear communication. If there isn't clear communication, then you know that means the contract isn't working, it has to be that everybody understands what's going on, both from your team but also from the client's team. And so we're really talking about if this sense of communication and tools for the communication and the signoff and all of that is part of that.

And in the context of NCARB, if you imagine this question, you really have to understand the context of the question in order to be able to answer it. If they're saying something, and you're sort of in that schematic design kind of thinking, well clearly it's schematic, you've only invested so much so far. It's meant to be tested and changed and ideas trying out and bouncing ideas off of each other.

That's the whole point of schematic design. So that's a very different experience than having that conversation way at the end as you start to get bidders ready and you're about to go into permit. And you know that's a totally different moment. So this is just another example of you know the questions are partly gonna be sort of simple and straightforward, but you also need to really make sure that you're thinking about what is the context that they're talking about that question.

How are they thinking about this, in what context? So this exam, we're talking about programming and analysis, so if we had a question like this, we would really be in this zone that we're talking about. So can the client say let's redesign, let's revisit? Sure they can, in the context of this exam, they absolutely can. By the time we get into some of those other exams, same question, the answer would be no. That's gotta be a new contract, right, so the context is everything.

Log in to access files