Easy RFP Template

Me again. There is nothing particularly *easy* about filling out this template, but the post title will probably get me some good organic search results.

There seems to be a pretty decent need for a generic RFP template, so I thought I would fire one off this afternoon as I attempt to rest my little brain here in Miami (where the people are way nicer than I was told they are).

• X. Some sort of Confidentiaity Agreement may come before the RFP delivery. I have seen these IN the RFP, but come on… the RFP is in their hands at that point.

• 1. Executive Summary - Formal declaration of the fact that this is, indeed, an RFP.

• 2. Organizational Summary - What is the organization’s history?

• 3. Organizational Contacts - Who is the internal PM, Product Owner, other key Stakeholders? At this point, there is no need to give contact information for anyone who you do not want to be contacted.

• 4. Project Summary - What is this project/effort? Short and sweet. A paragraph or two.

• 5. Timeline - When is the RFP issued? When are questions due? When will responses be sent? When will final proposals be due? When will a vendor be selected and when will be project/effort begin? If there is a due date or a time the project must be completed by, you might want to note it here and let the vendors tell you that you are crazy.

• 6. Terms and Conditions / Glossary – What verbiage is not immediately intuitive or contextual in a way that needs to be explicated? Also, you might want to mention that the RFP is not to be passed around or presented to 3rd parties.

• 7. Design Requirements - Reference to a Style Guide if there is one, and depending on if the project involves design work, as much as can possibly be communicated in regard to desired look and feel. You might want to mention sites that are particularly well-liked, competitor sites, etc. Also, do you expect to see 3 versions of a proposed homepage, followed by X rounds of review? State this.

• 8. Functional Requirements - A big list of dot notated “The System shall…” statements. Corresponding MoSCoW assignation may be useful, or some type of priority codification.

• 9. System Requirements - Are there any? Scalability, for instance?

• 10. Subsystem or Integration Requirements – Any special workflows involved? Any integration mandated? If you are migrating data, mention it here. You might want to provide a data model (high level) along with a general assessment of the data’s condition. What DB is is coming from and what DB is it going to? Alternatively, what other Systems will be integrated and what do those integration points look like (high-level UML might be useful here).

• 11. Project Milestones - For the Vendor to posit delivery dates against.

• 12. Request for Platform, SDLC, and/or PM Methodology Clarification – How are they going to build it? On what? What process do they use and can they describe what the experience will be like? Iterative? Hope so.

• 13. Restrictions and Limitations - Anything that might speak to this could be helpful.

• 14. Specific Questions - Good place to ask outright whatever it is that is not a requirement but needs to be asked, like “Have you ever done anything remotely similar to this before?” Or, “How much of this work will take place on US soil?” Or, “What will our points of contact be, what will our escalation protocol be, what will our change. This part can also function as an RFI (Request for Information) of sorts, if you have a general idea about something you need improvement on or help with but are not sure how to accomplish the goal.

• 15. Point of Contact for RFP Questions and Submission - Self explanatory, but it is important that this person does not answer any questions without taking the protocol into consideration. Also, the protocol should have a mandatory end date for questions to be submitted in writing. Anything after that will go unread. If a vendor submits questions a day late, chances are they are short on resources (or just sloppy). If a vendor cannot submit by the mandated date, they should make that clear. Generally, I like to give vendors a week or two’s notice that they will be getting the RFP and then, depending on the scope, 2-3 weeks to respond with questions and another 2-3 weeks to write up and deliver their proposal.

The quality of your RFP will usually speak to the quality of the proposals you receive. It is also advantageous to put some work into fleshing out initial requirements so the vendor can respond, specifically, to what you know you need. This up front work is subject to change, but it provides a rough idea of initial scope and vendors who simply cannot create a J2EE application that integrates Oracle with Informix and Google Gears will know to bail early. Also, if you are able to toss a nice UML diagram in your RFP here and there, the vendor will take care to understand their audience is not entirely unaware of BS.

If you need help writing your RFP, contact me. This is in no way intended to be a catch-all Table of Contents. Like every project, every RFP is at least a little different. It is all about delivering good, working software. This process starts with a firm engagement with the vendor.

Best,

Josh Milane