In Part 1 of my current blog series, I discussed the way budgets get assigned to web projects through RFP’s. That info was intended for both the RFP creator and the RFP respondent. Hopefully, a major takeaway was that risk and reward need to be balanced. That balance can be achieved through creative project pricing and I gave some examples of how and why some pricing methods might be deployed.
This part of my blog is for the writer/creator of an RFP for a Web development project.
The goal of any organization writing an RFP is to provide a document to prospective vendors that can be easily understood, so they can confidently respond. The hope is that they will respond in like kind to the other responders, allowing good comparisons between the best vendors fit for the project. But, you need a few things first...certainly not be taken for granted:
- First, the RFP Creator (person or group) doing the creating has to actually know what they want.
- Second, the RFP Creator has to be able to define, in detail, what they want!
If the RFP creator is not capable of providing detail enough to define the website requirements, it may be necessary to hire an objective consultant to take on that task. For this blog, lets assume the creator knows what they want, and is able to communicate those needs in way that will be clear to respondents.
Here are some of the most important and relevant items to address in any Web RFP. The potential respondents will likely ask about these items, so it is ideal for RFP writers to provide this information up front:
- # employees
- # locations (and where)
- Company revenues (if able to share)
- Basic products or services and how they are sold
- Competitors (provide links and brief explanation of their strengths, weaknesses, leadership and history (especially about website success).
- Who is the key web project champion, and who will be the RFP process main contact person for the organization.
- Who is the highest C-level executive endorsing changes to the website?
- Define the IT infrastructure (how many IT staff, proficiency, technology platforms preferred, and anything else that can shed light on why the project may not be taken on by internal staff.)
- At the minimum, dictate the way respondents should frame up their quote (Fixed bid, T&M, or hybrid). This seems more of a stumbling block than it should be, but one thing is sure - the better the information available to a respondent, the more sincere will be the responses.
Platform and/or technology
- The RFP creator should know as much as possible about intended technical direction(s), and therefore should define the tools to be used for project implementation. Sharing that information will attract respondents that can genuinely provide the best responses.
User Interface, site architecture, and creative design
- Highlight good work examples and set expectations. The more info that can be provided, the less risk for everyone.
- Tell whether off-shoring or outsourcing is permissible on the project.
Custom Application Development
- With custom coding, all expectations much be defined or separated from the RFP. Ambiguity on this will beget huge risk.
Other Items to Consider
- SEO requirements
- Marketing or lead generation tools
- Analytics requirements
- Internal site search expectations
- The RFP Creator should logically present a timeline. The RFP respondent should be responsible for accommodating that timeline (or share why they can not).
Project Management and Project Oversight
- The RFP Creator should set an expectation, and allow the responder to respond and accept the terms.
As before...a number of the above items revolve around setting realistic expectations. If an RFP Creator is not comfortable setting those expectations themselves, they should seek a consultant for that assistance.
Important: The best way to be sure to yield readable, congruent RFP responses is for those who create the RFP to explicitly define the requested FORMAT of those responses, even if that means providing the answer blocks and exact instructions on how to answer to each question and/or requirement.
Oh, and one more thing. As with most things, the cost isn’t everything! We think the best, most genuine quotes logically come from the respondents who exert the most effort. Seek those who truly work to learn your website project requirements and who appear sincere to help solve problems.
Part 3 of my series on RFPs will be targeted to the RFP Respondent, and is specifically intended to give guidelines for project scoping and responding to RFPs.