We’ve all heard the phrase caveat emptor (buyer beware), but too often we ignore it when selecting an eLearning vendor. One way to protect yourself is to write a solid request for proposal (RFP). An RFP is an invitation 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 information protection, project termination, payment processes, and warrantees); 2) procedures (what potential vendors must do to submit an acceptable RFP); and 3) statement of work (the details of the work they are being asked to perform).

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

Procedures

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

  1. Background information. Ask the vendor to tell you their story, something beyond the information on their website. It is not as important to ask for references, since, hopefully, you did that before you sent out the RFP.
  2. Specific dates, milestones, and deadlines of the RFP process. You can tell the vendors when to submit their proposal and when you will get back to them with a decision.
  3. Proposal judging criteria. Some people think you should keep this a secret, but informing vendors how they will be judged can help them write a better proposal, more to your specifications and requirements.
  4. What should be included, or not. You might require vendors to send along specific samples and demos, or you can leave it as an option. You can also tell vendors what you will not accept. Perhaps you don’t want to be inundated with ancillary materials; it’s OK to restrict what you want them to send you.
  5. Format. You can specify how the proposal is formatted, as well as the length of the proposal and even the software it is written and delivered in. This will help your team review the proposals more efficiently. You can require print or electronic delivery, or both, and you can specify how many copies you need.
  6. Vendor behavior. You will want to tell vendors what they can and cannot do during the process, including how they will submit questions and seek clarification. You can set restrictions on any other contact with your organization, and, if necessary, you can use a third party to make the whole process anonymous.
  7. Subcontractor information. If the vendor might use subcontractors, you can establish rules for their use in the project, and require disclosure and approval of all subcontractors.
  8. Pricing. Of course, pricing information will be key. Talk with your purchasing and procurement people about the best ways to ask for this information so that you can compare “apples to apples.” Keep in mind that the more specific you get here, the more insight you will have into the costs for the project. However, don’t get so deep that you drown in the numbers.

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

Statement of work

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

  1. Overall project goals. A clear statement of what the project is about and what it hopes to accomplish.
  2. Detailed description of the need or problem. Help the vendor understand completely what you are trying to improve, 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 the deliverables are targeted for, and provide their background, readiness, capabilities, etc.
  4. Requirements. These are detailed descriptions of what the actual deliverable(s) should look like and be able to do. For technology projects, the technical requirements are the most important part of the entire RFP. If you don’t tell the vendor exactly what you want, you should not expect to get it (think of creating a building without architectural blueprints).
  5. Project duration and preliminary schedule. How long you expect the project to take (by phases, if appropriate), including feedback, revisions, testing, and implementation, if necessary.
  6. Deliverable evaluation criteria. You can specify how you will judge the success of the project, except if the development of the evaluation plan is actually part of the project.
  7. Expectations about long-term support. Specify how you expect the vendor to assist you after the project is completed.
  8. Expected deliverables. Details about what 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 put a stake in the ground here, if for no other reason than to compare competing proposals.

In all these cases, your goal should 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 a column titled “Qualifying eLearning Vendors.” In this column, as a follow-up, we’ve covered the basics of developing a sound RFP. Next month, I’ll discuss evaluating those proposals. 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.