Again - I would really welcome:
Continuing on from my earlier posts:
From several comments and from looking at my list of issues, I realize that writing a good LMS RFP is challenging and it's easy to make lots of mistakes.
LMS RFP Resources
John Theis wrote a
dissertation on the contents of 25 RFPs submitted to an LMS vendor. His dissertation contains some interesting information. The best stuff is found on pages 36-42, 54, and 56-75, but don’t miss John’s Dedication. I normally skim by that sort of thing, but his caught my eye and it brought a tear.
Included in John's dissertation are sample outline elements from different RFPs. Definitely worth seeing those.
Karl Kapp was nice enough to point me to a series of articles he's done on the subject and a set of templates for the selection process including a template for the RFP:
Selecting an E-learning Solution, Part 1: Who Should be on Your E-Learning Selection Committee?Selecting an E-learning Solution, Part 2: Avoiding Common RFP MistakesSelecting an E-learning Solution, Part 3: Ten Rules for a Smooth, Efficient E-Learning RFP ProcessSelecting an E-learning Solution, Part 4: Inviting the Vendor To PresentAnd finally
LMS Selection Templates.Another good resource is:
Learning Management Systems (LMS) A Review. This paper present ssome important criteria to evaluate and consider when purchasing a LMS. It also points out some of the purchasing mistakes that are common in that process.
Probably the best thing to do is simply to search on Google using a few tricks. For example:
(LMS OR "Learning Management System") AND
("Request for Proposal" OR RFP OR "Request for Quotation" OR RFQ) AND
(filetype:PDF OR filetype:DOC OR filetype:RTF)
will get you an
interesting list.
In fact, I'm pretty sure that some of these are not supposed to be found!
You can also add "template" to the search to find a few more good results.
Good and Bad LMS RFP Requirements
When you search around for LMS RFP examples, you'll find quite a variation and it's worth reviewing a few different RFPs to determine what elements you want in your RFP. But, what I see as the most common problem in LMS RFP documents are the requirements.
Generic Requirements
Rule #1 - Don't write generic requirements!
Many of the examples show requirements that are written that are hopelessly generic. For example, I found an RFP example that had a long list of requirements such as:
- Ability to create a training plan for individuals
- Ability to create a training plan for a group
What do you mean by a training plan? It means something different to most organizations and LMS vendors. Most vendors will simply tell you "yes" to these kinds of generic requirements. And if they can do it for an individual, they can do it for a group – of course, you might have a hard time in a particular LMS getting your kind of groups to have a common training plan. The list in this LMS RFP went on and on at this level. It looked like the RFP requirements were copied straight from some generic list.
Another example has a requirement:
- Supports a variety of learning formats
with a Yes/No response. The answer is "yes" unless the vendor is completely off their game. All LMS products support a variety of learning formats. At least clarify what you mean by a learning format. Are you talking different file formats or do you mean classroom vs. virtual classroom vs. asynchronous. And if that's what you mean, then list out the formats and what you mean by supporting the format.
The bottom line here is that there is only one case where a general / generic requirement is acceptable. That case is when it's a well known, well defined function and you DON'T CARE HOW IT'S DONE. In other words, any solution is acceptable. Otherwise, it's a waste of everyone's time to have a generic requirement when you really want something more specific than that.
RFP Death March Requirements
Another common mistake in RFP requirements are writing requirements that are well intended but make the vendor want to shoot themselves. Often they start with the word "describe" or "how do you" ... It's not always wrong to use these, but make sure that you really want the vendor to go to that much trouble. Or is it that you are trying to avoid having to write a more specific requirement?
For example in Learning Management Systems (LMS) A Review, one of the example requirements is:
- Describe capabilities for managing course capacity and waitlists issues.
Most of the LMS vendors have the ability to define a course capacity and then put people on waitlists. The specific handling after that is often configurable, possibly at different levels of granularity. There’s notifications. A whole bunch flows off of this. As a vendor, do I guess at what’s important to the prospect? Hopefully, I can find a bunch of marketing text to copy in, but it’s going to be hard to write a response that will help the prospect.
Now, it could be that you mean this as a general requirement. In other words, you generally need capacity and waitlists, and you don't care how that is handled by the LMS. If that's the case, then change the wording to eliminate the need to "describe."
However, I would put money on the fact that you DO care and thus you should be writing requirements that are more specific. Do you require notifications when someone a spot frees up? Do you need that notification to go to the employee, the manager, an adminstrator? Do you need specific rules about timing? How does this affect compliance requirements in your organization? Chances are you have a few specific requirements that you really would want to discover by spending the time to write a better RFP requirement.
Another example from a different source:
- Please describe how the application displays course information to the users.
Duh, it lists them and then it shows the course information. Is there something that your company needs that’s not standard?
Another example I ran into: - Describe administrative interface and usability.
Pretend you are the vendor. You have 30-50 administrative screens. You either will want to kill yourself or the customer.
Vague Requirements
Putting in a requirement that is vague is asking for problems later in the selection process. For example, one requirement I found:
- Can customized course catalogs be defined and displayed to different sets of users?
Most systems will allow a user to see a different catalog based on job role, organization, etc. If those are the criteria, then say so. Otherwise, what is meant by “customized catalog.” Without additional detail, you are enticing the vendor to say "yes" to something that may or may not have.
Opinion Requirements
Another common mistake is to put in requirements that ask for an opinion. By far the most common is "easy to use" but you see these quite often. John Theis' dissertation (which looked at 25 RFPs) had a couple examples of requirements that help illustrate:
- We require a solution that is personalized to the user, possesses a clean and easy-to-use interface, is easy to navigate, provides the ability to search for and find information, is menu driven and is intuitive.
- Have feature rich and flexible administration “back-end control panel”
Cmon - "easy to navigate," "intuitive," "feature rich," "flexible." As a vendor, you had better believe that you are all of these things.
You will need to formulate your own opinions about "easy to use" and "intuitive." This is going to come from demos and testing, not from an RFP response. "Feature rich" and "flexible" are probably a cop-out from writing more explicit requirements.
Good Requirements
My preferred approach is to write requirements that are based on differentiating use cases. These are the things that make this organization's needs somewhat special. You can ask a bunch of generic requirements around functionality that falls outside of this, but you really focus the RFP on the items that you believe will differentiate the products.
The requirements will be very specific items that you are looking for:
- Does your LMS work with WebEx as a virtual classroom tool to?
- allow administrators to create virtual classroom sessions at a particular day/time that map onto a class in the LMS?
- allow entry of the date and time is done on one screen by the administrator?
- provide a link to the learner in an email notification that allows them to launch into the virtual classroom session?
- track attendance at the virtual classroom session into the LMS?
- Does your LMS allow us to associate pre-work with both instructor-led training and virtual classroom training?
- allow pre-work to include SCORM courses?
These are very specific requirements. A few of these requirements were not "critical" requirements, but were nice to have. Generally we don't expose what are critical vs. important vs. nice-to-have within the RFP. There is still a lot left open in terms of how the LMS will allow you to accomplish each of these. During demonstrations and hands-on we would determine how well these things work in practice.
Also, I like to use an RFP where the columns are:
- Requirement
- Meets (Yes, No, Partial)
- Explanation (Optional)
The expectation is that the vendor will write in Yes to those they meet. No to those they clearly don't meet. And they will explain what they do or don't do for those that are partially met.
Additional Thoughts
Karl Kapp's articles point to some good thoughts on writing RFPs that I've not touched on above:
- Poorly Written - RFPs are notorious for being poorly written. Remember a Request for Proposal is a representation of your company. Take the time to do some proofreading before sending it to e-learning vendors.
- Providing Too Little Detail - Vendors cannot help you to solve your e-learning problem if they know nothing about your organization, nothing about your technological infrastructure, etc. Give them some background.
- Poorly Scoped - Karl talks about writing an RFP in which your needs are larger or smaller than what you are suggesting in the RFP. Most often this is because you actually don't know your needs. See my common mistakes.
- Make sure the vendor knows the business needs / rationale / context
areas with Web 2.0 is being able to share and post our ideas on the web. There are lots of options and I wanted to highlight some of them. One of the sites which I have used is Slideshare. Slideshare lets you upload PowerPoint (.ppt) and PDF (.pdf) and OpenOffice (.opd) files which you then share with others. Slideshare makes it easy to post or embed your slideshow to a blog. Slideshare is very easy to use and registration is free. Another option is using Google Presentation, you can register for a free account and be up an running in no time. With Google Presentation you can choose to upload your PowerPoint presentation or you can start from scratch and create one right from within Google Presentation. You do not have all the bells and whistles of PowerPoint like
transitions or animation but you do have the benefit of being able to share it with anyone connected to the web. I have begun to upload some of my PowerPoint presentations on Google and use it when I ma presenting. One of the advantages of Google Presentations is the ability to invite others to be collaborators. It is a great tool for group work in an out of the classroom. If you want you can also share your PowerPoint so that the recipient is just invited to be a viewer and can't make any edits or changes in your slide presentation.
buttons, charts, hyperlinks, and sound to your sPresentations. Once you have created your presentation it is easy to embed your presentation or email it to whomever you would like. Give each of them a try and let me know what you think.
