In our work at Duo, we see a lot of RFPs. For those who don't know, an RFP is a request for proposal, and it basically is a document potential clients share with us that tells us about the type of work they're looking for. We look over the information provided in the RFP, and from that, we try to put together as detailed of a proposal as possible.
Photo by rawpixel
As you can probably imagine, RFPs can come in many different formats and with an incredibly wide range of detail. Some get very specific into requirements the potential client is looking for and the problems they are looking to solve, while others, well, do not go very far beyond saying they need a website redesign. Not surprisingly, it's hard to give a thorough proposal to that second potential client without more information.
With that in mind, I wanted to share some tips for putting together a strong, effective RFP that will lead to a more thorough and accurate proposal. While these tips are based on our work in the web development industry, they really are applicable to any field that requires RFPs.
With that, let's get to the tips.
1. More communication: Offer an open forum for conversation
Now, I recognize the irony of beginning a list of tips to improve your RFPs with one that focuses on communication outside the initial document, but whenever possible, it's so valuable for us to be able to talk with the potential client. It can be over the phone or in person, but the opportunity to talk through a potential clients' needs is always more valuable than trying to respond to a bulleted list on paper.
This open forum allows us to ask questions and clarify points made in the RFP. Just as importantly, it often leads to additional conversations and more information about the organization and its needs. It’s fair and should meet the rules for any procurement processes that are in place, since all participating vendors have the opportunity to attend.
This back and forth allows us to increase our understanding and put together better solutions, and it also makes it possible for us to share more accurate estimates. The more communication the better.
2. Share the problem, not what you think the solution is
In RFPs, there are often lists of requirements such as “Slideshow for the homepage” that focus on a solution but do not tell us much about the reason it’s included. Why is a slideshow necessary?
In working with existing clients, they will often bring up the need for the creation of similar features. When I ask the client why they would like to add a new feature like a slideshow, I’ve often gotten responses like "Oh, well we need to be able to present our products in a meaningful way for the customers."
We’re able to discuss this request with the client and really delve into the reason behind it. What are we trying to accomplish with this meaningful presentation? What metrics can we use to gauge our success? This conversation allows us to leverage best practices and focus on the business need behind the request to come up with the best solution. Sometimes this might be a slideshow, but often there are other, better ways to fulfill the need.
Often, as I look over RFPs, they will contain a list of must-have features for the project, such as the slideshow mentioned above. With the opportunity for communication (see the previous tip), we could get into greater details, but what’s most helpful from an RFP perspective is to understand the problem, which in this case might be to create a meaningful presentation of products that will drive purchases.
If this sort of information isn’t in the RFP, I don’t know what the organization's needs are, and therefore we can only quote them on building a slideshow, rather than a different feature or set of functionalities that might be more effective.
Feel free to list the slideshow as an example of a way to showcase products, but don't make it sound like it is the only option. In other words, tell us the problem, and we'll come up with a recommended solution as part of our proposal.
3. Assign a primary point of contact
We know that business is complex and that there are a number of stakeholders who want or need to be involved in a website project. That being said, it makes everyone's life easier if there can be one person who is leading the initiative and is the point of contact for us to work with.
I was at a Drupal convention earlier this fall and spoke with a number of tech representatives from universities across the country, and on multiple occasions, I heard about website projects that ran into serious issues because there were too many people involved with communicating with the vendor.
I knew exactly what they were talking about.
We want to make sure that the stakeholders in your organization are not only satisfied but also delighted with the end product — it makes our life easier, though, if there can be one person who gathers feedback from the organization and then shares it with us, as opposed to us trying to aggregate it and then determine whose opinion outweighs others.
4. Speak plainly
I've seen some organizations try to be helpful in RFPs by using technical terminology. Unfortunately, this often leads to situations in which we could not tell what exactly it was that the organization wanted. Unfortunately, this can obscure the reason behind the request and is often too prescriptive in terms of the solution. Clearly listing your organization’s requirements is much more helpful.
There are times when your IT staff is involved in the project and will want to provide technical details, but no fancy language is necessary in the RFP. In most situations, if you can share what business requirements you have, we can take that and translate that into what it means for the project.
5. Provide a budget
Again, we understand how budgets work. We get the process. We know that your organization may have restrictions based on your organizational rules for procurement. Whenever possible, however, some sort of budgetary number helps. Any guidance — even a broad range — helps us determine the best way to provide an accurate and effective quote.
Particularly when you're talking about building with Drupal, there are a number of different options available that vary in price. We've worked with a number of clients who have had big needs but tight budgets, and we were able to work with them to deliver a product that solved their problems and fit their budget.
We try to cater each solution to the individual organization, so the more we know, the more we can do to help give the organization a product it wants at a price point it can manage.
There are other ways to create a strong RFP, but if you follow these five recommendations, you and your organization will receive a detailed proposal catered specifically to your organization and its needs.