Marc My Words: Writing a Good RFP

We’ve all heard the phrase caveat emptor (buyer beware), but toooften we ignore it when selecting an eLearning vendor. One way to protectyourself is to write a solid request for proposal (RFP). An RFP is aninvitation to the vendor to propose work according to criteria you set. Most RFPs contain three sections:1) boilerplate (all the legal jargon, such as proprietary informationprotection, project termination, payment processes, and warrantees); 2) procedures(what potential vendors must do to submit an acceptable RFP); and 3) statementof work (the details of the work they are being asked to perform).

Since the boilerplate is usuallywritten by lawyers, purchasing, and procurement specialists, we’ll leave thatout for now and focus on procedures and statement of work.

Procedures

Here, you want to focus on whatthe vendor is to do in order to successfully submit an RFP to you. Eightimportant items you want to include, and look for in their responses, are:

1. Background information. Ask the vendorto tell you their story, something beyond the information on their website. Itis not as important to ask for references, since, hopefully, you did thatbefore you sent out the RFP.
2. Specific dates, milestones, and deadlines ofthe RFP process. You can tell the vendors when to submit their proposal andwhen you will get back to them with a decision.
3. Proposal judging criteria. Some peoplethink you should keep this a secret, but informing vendors how they will bejudged can help them write a better proposal, more to your specifications andrequirements.
4. What should be included, or not. Youmight require vendors to send along specific samples and demos, or you canleave it as an option. You can also tell vendors what you will not accept. Perhaps you don’t want to beinundated with ancillary materials; it’s OK to restrict what you want them tosend you.
5. Format. You can specify how theproposal is formatted, as well as the length of the proposal and even thesoftware it is written and delivered in. This will help your team review theproposals more efficiently. You can require print or electronic delivery, orboth, and you can specify how many copies you need.
6. Vendor behavior. You will want to tellvendors what they can and cannot do during the process, including how they willsubmit questions and seek clarification. You can set restrictions on any othercontact with your organization, and, if necessary, you can use a third party tomake the whole process anonymous.
7. Subcontractor information. If thevendor might use subcontractors, you can establish rules for their use in theproject, and require disclosure and approval of all subcontractors.
8. Pricing. Of course, pricing informationwill be key. Talk with your purchasing and procurement people about the bestways to ask for this information so that you can compare “apples to apples.” Keepin mind that the more specific you get here, the more insight you will haveinto the costs for the project. However, don’t get so deep that you drown inthe numbers.

In all of these cases, you cantell vendors what the consequences will be if they violate the procedures,which could include elimination from consideration.

Statement of work

When developing your statementof work (SOW), your goal should be a clear explanation of what you want done. Hereare eight items to include in your SOW:

1. Overall project goals. A clearstatement of what the project is about and what it hopes to accomplish.
2. Detailed description of the need orproblem. Help the vendor understand completely what you are trying toimprove, fix, change, or create. The more you tell them about what you want,the more likely they are to address your needs.
3. Profile of users. Explain who thedeliverables are targeted for, and provide their background, readiness,capabilities, etc.
4. Requirements. These are detaileddescriptions of what the actual deliverable(s) should look like and be able todo. For technology projects, the technical requirements are the most importantpart of the entire RFP. If you don’t tell the vendor exactly what you want, youshould not expect to get it (think of creating a building without architecturalblueprints).
5. Project duration and preliminary schedule.How long you expect the project to take (by phases, if appropriate), includingfeedback, revisions, testing, and implementation, if necessary.
6. Deliverable evaluation criteria. Youcan specify how you will judge the success of the project, except if thedevelopment of the evaluation plan is actually part of the project.
7. Expectations about long-term support. Specifyhow you expect the vendor to assist you after the project is completed.
8. Expected deliverables. Details aboutwhat you expect the finished product(s) to be, how they will look and function,etc. Although this may change while the project moves forward, you want to puta stake in the ground here, if for no other reason than to compare competingproposals.

In all these cases, your goalshould be to tell the vendors exactly what you want without telling them how you want it. That’s their job to tell you;don’t do it for them.

Quite a while back, I wrote acolumn titled “Qualifying eLearning Vendors.” In this column, as a follow-up, we’ve covered thebasics of developing a sound RFP. Next month, I’ll discuss evaluating thoseproposals. The smarter we are about the products we buy and the vendors we use,the better it will be for our work and our organizations.