It’s been over a year since I promised a post about RFPs: From December 2011:
“First of all, one of these days I’m going to put together a piece about web design/development Requests for Proposals (RFPs). It’s a big subject and I have mixed feelings about the entire process. But one general piece of advice I have for organizations when they put out on RFP is, in all cases where software or hardware is specifically mandated, there should be an explanation as to why the mandate, and the answer “because that’s what we have” should not be considered automatically acceptable. Your investment into that software or hardware, if substantial and forward-looking, can be a great reason to require it, and that detail should be provided. But there are so many options out there now, for so many components of a web site, that a good developer is going to wonder why you’re requiring the one you’ve selected over something that may be a better fit. Detail matters.”
Before we go any further, I’ll just admit it, I’m not a big fan of RFPs. We see a good amount of website design or redesign RFPs, and in my opinion, most of them miss their target. There is a great tendency to focus the RFPs into two areas:
1 – the appearance of the website, particularly into how it should integrate design elements from other materials; and
2 – the technology the website will use, based on current server environment.
This is not to say that those are not valid concerns, but they should not be primary. Primary should be the requirements that relate to the main question for the organization:
What do we want the web site to do for us?
Now it’s true that the resulting proposals may provide a variety of solutions to the various requirements of the site when an organization doesn’t lock into a look or a technology as the primary gauge of a proposal. It can provide a wide range of costs. So as much as an organization can tie that down in the RFP WITHIN THE CONTEXT OF THE CENTRAL QUESTION can help both the respondents and the RFP issuing organization.
For example – an organization may want their site to be able to accept credit card transactions. Perhaps there’s an entire back-end system where the transaction data is going to be maintained for the organization that may be online or offline – but it’s not necessarily the website’s database(s). Provide some detail as to how you will need the data – format, process, data fields, frequency, etc. Because the real goal isn’t just that the organization wants to be able to accept online transactions, but that it wants this to be as seamless as possible with their offline processes as well so that workflow is manageable and predictable.
Here’s a requirement from an RFP I see pretty regularly:
We want social media to be integrated into the website.
And that’s it. This is boilerplate, pure and simple, and it means about as much. Details matter, particularly when you are coordinating your site with other web sites for an appearance either on your site or their site.
What do we want the web site to do for us? Answer that question in regards to social media and you’ll hone the RFP responses in a way you can use.
Another RFP requirement I see quite often is of design/layout nature. For example, we want scrolling photos near the top of the front page. Okay, fine, simple enough. But real estate on the front page is so critical, shouldn’t design follow goals and functions rather than the other way around? Appearance, layout, flexibility… these are goals, but once you really focus on what you want the site to do, these goals become more general (a crisp professional look, the ability to translate easily for mobile access, etc.) and are almost a parameter for the other goals rather than a specific goal itself.
At the very least, an RFP ought to include something akin to a Goals list for the website and a Priorities list for the website. The goals list should be what the organization wants the website to do for them. It should be as specific to the functioning of the organization as the organization can be comfortable with. It should be open to technology used when appropriate. The priorities should be a focus on how IMPORTANT to the organization these goals are, because it may turn out that the best solution to the top priority may not really resolve the 13th priority adequately, and it’s important to the web developer to know what’s the most critical elements.
Finally, provide a cost range your organization is allocating to this project. An RFP should be viewed as a chance to review the best ideas for your organization’s web site going forward, not as a way to find the lowest price. That may be the result of an RFP process but should not be the goal. Provide an expected cost range allows the web developer to think about the project within a reasonable economic framework, and will keep your proposals more focused within the realm of what can be done.