A Checklist for your next Website RFP

I created my first website in April of 1993; a week after Mosaic was launched and the WWW as we know it was born. I’ve reviewed to over 1,500 Requests for Proposals since that time and I can probably count on one hand how many of those clearly and accurately described the project scope or defined what would spell success for those clients.

Most RFPs are nebulous and vague, speaking in generalities with a healthy sprinkling of current buzz words and trends so that the writer feels they are in tune with what is needed. Most miss crucial elements and lack any facilitiy to ensure that all vendors are quoting on the same project scope.

With that in mind I’ve created a checklist of things to consider as you write your next requirements document. Keep in mind that you can NEVER provide enough detail if you are asking people to bid on your vision. I will be following up with detailed articles on each point and the pitfalls that each has. As with all my posts please feel free to send me questions and comments.

As you review this short list keep in mind the maxim “Be Specific to be Terrific!”

1. Description: Provide details of the project; its purpose and why it is necessary. Share business objectives and any data that clarifies your vision. Without an initial 30,000 foot view of where you are and where you want to go it is hard to determine what direction needs to be charted for the developers to get you there.
2. Budget: In a perfect world provide an accurate budget for the project. If a fixed budget has not been identified then at least provide a range that would be probable. If this is fishing expedition then consider hiring a consultant so that you don’t waste anybody’s time, including your own.
3. Terms and Conditions: Include a complete list of terms and conditions. This may include proof of insurance, workers compensation status, pending lawsuits, conflicts of interest, who owns what at the end of the project etc. Knowing these can eliminate or limit potential risks and conflicts later.
4. History: Provide background on what got you to this point. Understanding your previous success and failure provides perspective on your experience and expectations. Your developer, hopefully E-Cubed Media Synthesis can then manage your expectations as you move forward with new objectives.
5. Audience: At the very least define your primary, secondary and tertiary audiences. Include as much demo-graphic, psycho-graphic and techno-graphic information as possible. Crafting a targeted user experience requires getting inside their brain and walking in their shoes as much as possible. Day-Glow Mohawks, tattoos and tongue piercings do not sell nursing home services like they used to.
6. Features and functions: List essentials as well as non-essential aspects of your feature and function lists, go crazy here but prioritize clearly. Provide links to existing sites that showcase the technology you are requesting. If you want a ‘photo gallery’ show examples of what you like and provide notes of why you like them.
7. Database connectivity and Reporting: – if dynamic data sources and reporting are required please state the level and complexity of your existing data environments and what needs to be connected to or reported from. If possible provide samples of the schema for review.
8. Site Specifications: design parameters, accessibility/usability requirements, Platform considerations and programming languages, hosting environment, eCommerce needs, CMS requirements.
9. Existing Content and Tools: Current content, database data and online systems may need to be transferred to the new site and infrastructure. Please list or provide an accurate page count including structure and dependencies with external systems. Data migration and reformatting can be a large part of  the site redesign budget. A rough rule of thumb that I use is that one person can migrate, reStyle, link and test an average of 4 pages per hour. Do not underestimate this area!
10. Staffing: Knowing the players on your team is extremely valuable. Who is the main point of contact? Is that person empowered to make decisions or do they report to someone or to a committee? Knowing the lay of the land can identify bottlenecks and possible challenges for a developer especially for approvals and revisions.
11. Timeline: Provide a clean time frame for your project starting from the RFP issuing date thru to the project launch. Knowing major milestones is critical. Identifying when developer goals need to be achieved can be contrasted against resources and scope of work. Many times the supplied corporate time line is unrealistic based on the scope of the project so provide some room for delays, especially for corporate approvals and proposal review and due diligence.
12. Formatting: Clearly separate your RFP into logical chunks. Number your proposal’s sections and subsections so that vendors can respond with reference points. If you use certain terminology to identify specific features, functions or industry jargon please ensure that this is clearly stated or better yet provide a glossary. If you want it delivered in a specific fashion or presented in a specific way provide details. If you want pricing broken out in specific ways please detail your expectations.