Call and Response: Handling RFP Tension
In: Columns > The Business End
Published on August 29, 2005
In my office, we have a love-hate relationship with the request for proposal, or RFP. On one hand, RFPs are a handy substitute for open-ended conversations with client prospects who want a proposal, but can provide few details about what the proposal should cover (drafting an RFP requires that clients put at least some thought into project requirements). On the other hand, a poorly written RFP is much worse than even the most tentative and exploratory telephone conversation or meeting.
Having taken the time to produce an RFP, clients will lean heavily on the document as the guiding instrument of their discussions with you. If this document falls short in any way, you may find yourself in the uneasy position of writing a proposal without a clear understanding of how to insure that your capabilities and experience effectively align with the client’s needs.
So, in the interest of helping designers understand how they can make the most out of every RFP opportunity, this article highlights four areas of client/designer “engagement tension”—that is, places in the RFP where client interests and vendor interests are most often misaligned and cause the most friction. I have also provided some suggestions—mostly drawn from the actual experiences of my firm—to overcome or deal with these tensions.
Of the areas where clients and vendors are potentially opposed, this is perhaps the stickiest. Every vendor wants to know the client’s budget. And almost every client wants to get the best deal they can on a project, regardless of budget. Some clients feel that the way to achieve this is to conceal the budget from responding vendors. Sometimes a concrete budget doesn’t even exist at the time the RFP is issued. In other words, the RFP process is intended to define a market rate for the services required by virtue of the range of responses received. In either of these situations, it is crucial for both parties that the project parameters be clearly explained both in the RFP and in the response.
The intimidating formality of the RFP process can sometimes imply that no communication outside of the described process will be tolerated. Wise clients will build a question-and-answer process into the RFP. But even if they don’t, designers should always seek the answers they need to develop a fair and accurate estimate. Questions should be always submitted in writing. This makes it easier for clients to respond completely and to share the answers with other bidding vendors. “What is the project’s target budget?” should be your first question. If the client refuses to answer this, go ahead and propose a range and gauge the reaction. I have found that even clients who are not willing to provide a budget will usually react to a proposed budget range that is too high. At a minimum, this will help you determine how much work you are willing to put into your response (given the potential size of the project), or whether you want to respond at all.
If a budget target is given, stick to it. This may seem obvious, but just as clients sometimes hesitate to provide a budget, some designers assume that a stated budget is understated so that the client leaves room for savings, scope increase, etc. This may very well be the case, but the negative impact created by a proposal that ignores a stated budget is not worth the few extra dollars. Instead, designers should be crystal clear about how they arrived at their estimate—including any tradeoffs or compromises that were made to meet the budget. Feel free to propose alternate approaches or optional extras. As long as your base bid includes pretty much everything requested in the RFP, these additions can be a great way to advocate valuable services that will add to the project cost but also increase the quality of the end product.
If a client absolutely refuses to disclose a budget—or even to discuss a range—you are left with no choice but to propose a design process that you deem appropriate based on the circumstances as you understand them. Just make sure that your response not only clearly indicates whatever assumptions you make about this, but that it also prominently signals the consequences for the client of changing those assumptions (i.e., the proposed process and estimated costs go out the window). Clients have a legitimate right to point back to your RFP response both during contract negotiations and even the project itself. If you have not been up front about how you arrived at your projections, the client can rightly hand you your head.
Another area of tension concerns overlap (or lack of overlap) in each party’s sphere of expertise. So let’s just state the obvious: The client knows his business better than the designer, even if the designer has specific experience in the client’s domain. And the design firm, for its part, knows what information it needs to actually undertake a project. Unfortunately, each often assumes the other knows more about its situation than is actually the case. This can usually hurt the designer more than the client. So, designers should always insure that their RFP response contains a discussion and/or a rudimentary analysis of the client’s business situation and the project objectives.
In other words, designers need to communicate to prospective clients that they understand how this project fits into the client’s overall business, and, more importantly, that they can point to specific connections between their proposed design process (or their background and qualifications) and the factors that will make the project successful.
Another major disconnect occurs when designers assume that clients know how design “happens.” Designers spend so much time immersed in their own process that they take the lingo and concepts for granted. Design terminology has its uses. If there’s any question, make sure that you focus on business, marketing and technical goals.
Clearly communicate the parallels between your process and the client’s operation. This doesn’t mean you can’t talk about design. Make the rationale for certain design procedures (persona development, requirements definition, etc.) easy to grasp for the non-designers footing the bill.
Finally, make sure that you map your proprietary process to the client’s project plan or list of requested services. When writing your RFP response, stay aware that the client will compare your proposal with other vendors’. If your structure or terminology doesn’t make this easy, clients will not give you the benefit of the doubt. They will just gloss over the parts of your response that they don’t understand or that don’t fit into the grid they are using to compare their options. There are few things as frustrating as being eliminated from a selection process because a client simply couldn’t match up your proposal with the others in the pile.
This is another sore spot for both clients and vendors. Many clients expect that vendors who want a project badly enough will do whatever it takes to get it—including spending time and money creating speculative (“spec”) designs that give the client an idea of what they’ll get once they start paying. Designers, on the other hand, can be irritated by having to produce work under less-than-informed circumstances, especially when they have loads of references, case studies and other collateral that illustrates their capabilities. Generally, no vendor should be asked in an RFP to start the design job. But there is a set of goals for both sides that, if adhered to, streamline the process.
Name-brand clients usually have long-term projects and/or large budgets. They may treat an initial project as the beginning of a successful ongoing relationship with a design vendor. These clients may feel that it’s not unreasonable to request spec work—if only as kind of assurance from the bidding design firm that they appreciate the magnitude of the opportunity and the significance of the potential relationship. Even so, a busy design firm with solid case studies and client references that speak very well of the firm’s typical product may very well elect to pass on an RFP that requires spec creative. It’s a question of each designer’s personality and preferences. Some argue that spec creative, by its very nature, devalues the design process from the outset because it reduces the serious work required to identify design requirements to a few bullet points in an RFP. There is also the nagging issue of providing for free, up front, what you are trying to sell. These are valid arguments. And, in certain business environments, designers who are in high demand may be justified in adopting this kind of approach.
But designers should be aware that if they refuse to provide spec creative, they might automatically lose the opportunity—and the next one. I know, because I’ve been there. We received an RFP from a client for whom we had already done highly praised work. We were in a good position but we didn’t have feel for the creative direction of the new project (because it wasn’t provided in the RFP!), and questioned why we needed to prove ourselves yet again. We refused to do spec work and we were disqualified. And though the client assured us that it wouldn’t, we suspect that this refusal counted against us when prospective vendors were assembled for the next project and we were not included. It was regrettable, but we had decided that the cost to us of producing the spec designs could not be justified.
Process Timeline and Transparency
A final area of misalignment is the expectations surrounding the actual progression of the RFP process from start to finish. Of all these tension areas, this is the one where both sides probably work the hardest to stay on track—but can fail anyway. Most clients try to lay out a logical and reasonable timeline for each stage of the RFP process and then make an effort to stick to it. But I don’t want to count the number of times we’ve pursued an RFP with an incredibly aggressive timeframe only to have weeks go by without hearing anything about our status. Just try to tell a client in this situation that the resources you had planned to deploy on their project are now working on something else that came up in the interim. You will not receive sympathy.
The best you can do is to be open about your resources as they pertain to the RFP and if something changes before a decision is made, communicate. I am constantly calling prospective clients who are still mulling their decision to update them on our schedule and resource availability. I sometimes get the sense that these calls are interpreted as veiled attempts to force a decision, but I will take this risk in order to avoid the discomforts that can result when a client says “go” without being fully informed of our capacity to go at that precise moment.
Sure, there is always a little leeway in terms of committing resources until you actually get a project. But you shouldn’t try to win one if there’s no way you can deliver on the client’s timeline. By the same token, if the client screws their own timeline up and shatters your window of availability, you have to either let the client know or have a way to meet the new parameters.
I hope I have laid out a thorough primer for responding to the big issues in design RFPs. Obviously, all the advice above is intended to be a framework that can be adjusted to more specific circumstances. At least, I hope that some of the examples or admonitions might resonate. If these four areas of tension are out of whack, clients won’t be able to solicit the best firms and vendors will waste time and money.
I still prefer a detailed and unrestricted phone call prior to putting together a proposal. But I also know that such a conversation is not always feasible when it comes to allocating budgets. So, consider the above before undertaking the tough work of an RFP response.
I have provided just a few of our many RFP “Horror Stories” (and the lessons we have learned from them) in this article. There are more to share, to be sure. But I would love to hear from others, as well. What are some of the more outrageous requests or scenarios that you have encountered?
Nick Gould has witnessed the dotcom boom/bust/boomlet, and, to this day, finds it amazing that a small (but high-powered) design firm has provided more stability, security, and job satisfaction than any of his previous employers (including corporate law firms and Fortune 500 companies). Nick lives in his ancestral home of Brooklyn, New York with his wife and daughter.