Practice Strategies - RFP - Preliminary Design Response

So, as we said earlier, the difference between RFP and an RFQ, RFQ is do you have a team of people who are qualified to do the project? But the RFP, the P is for proposal, so that means the RFP response has to have a proposal in it. So, what does that mean? What is a proposal in this sense? And things have changed over the years. Proposals used to be very schematic and these days have become a little bit more detailed and a little more three-dimensional modeling and that kind of thing. But the basic thought here is that we have an idea, so it's not just a process or an approach, but there's an actual idea on the table that you're putting out.

And that idea probably has something to do with a plan, so it's not just an image, but something that is a little bit organizational. You've started to organize something and you've started to put a sort of process to it and you've started to put a kind of aesthetic to those ideas. But the issue here is you're trying to do that in order to provide clarity about kinda where you're going and how the project is gonna work, but you don't wanna set anything in stone.

You don't wanna have so much detail in there that by the time you actually start getting into the project and you realize, wait, this doesn't really work as well as we thought it would. The procession isn't right or the parking lot doesn't fit or whatever it happens to be. You don't wanna have promised something to people that you can't fulfill. It's about having not just a process, not just an idea, but sort of a game plan that is literally probably a plan and making sure that you're getting enough information across without sort of handcuffing your later process.

So, obviously you're trying to figure out, what is it that they need? And different question but similar, what is it that they want? Right, so is this process something that they are looking for something that's beautiful, that they really wanna have something that sort of sets them apart? Or is it that they just wanna know that you have the capacity and you're thinking about it organizationally and you understand the complexity of something?

Or do they really not know what they want and you have to kind of think about, well, what should they want and what do we think they should want, and make a proposal that way? Essentially, you're looking to be aspirational. You're looking to sort of put something out that is optimistic, that is gonna go somewhere, that it's gonna take a design in a direction, but you're not suggesting something that's completely unrealistic so it's aspirational but balanced. That's the kind of assumption that you would expect that they would be looking for.

They want to have you answer directly the thing that they need answered, but they will also like it if you're going a bit beyond that, that you're taking it a little farther, right, so it's aspirational in some sense. But if you're taking it so far that it's not the same project anymore, well, that's probably not really appropriate for a response to an RFP. Now, there are plenty of interesting examples where people have done that and it's actually worked out fine for them, but most of the time you have to really answer the RFP to be able to answer the RFP.

So, you have to know exactly what they're looking for when they don't know what they want. So you're reading between the lines of the RFP. You're trying to figure out what issues are the main driving forces. Is it design issues? Is it economic issues? Is it schedule issues? Is it who the team is issues? Trying to figure that out from what they have sent you, making your best guess, putting together a proposal that includes the sort of idea of the process, an idea of the plan, an idea of the aesthetic. And you're kind of making that in such a way that nobody could really pin you down on the exact details because you don't want them to focus on that.

You want them to focus on the organization of the idea and the aesthetic and the sort of process. And then you're packaging that all together in some manner that's sort of clear and people could understand, just on sort of a quick look. When it comes down to it, you never know. The machinations on a board of reviewers or on a team of people who are going through these, you never know what things are gonna be.

The best idea may win or may not win. It's up to them to decide that. What's more important is that you have a pretty good sense of what it is they're looking for and then a very good sense of what it is that you bring to the table, what your strengths are gonna be, what this team project is gonna sort of get us, and then you sort of hope for the best, that your view, your proposal is the thing that they're actually gonna be looking for.

It's always a mistake when you get into a situation where you're just making a response to an RFP that you know is the response that they want but it's not necessarily something you would be good at or want to do, that if you have a team of people who really just can't do the thing for whatever reason that you've just responded to and you get the project, then you're living with that for a year or two years or three years as you go through a project. So, it's important that you're not only responding to that checklist idea of what it is they need, but you're also being true to your team and the way that you do a process, the way you think about the aesthetics of design and how you organize things.

So, aspirational but still at least somewhat realistic.

Log in to access files