Answer: 2 1/2 months (Read on)
I recently participated in a panel where the question was asked “how long does it take to work through the LMS selection process?” The first consultant, who I greatly admire, and with a vast amount of experience in helping companies work through the LMS selection process quickly replied that in his experience, the process usually takes about one year to “do it right.” He went on to explain that LMS systems and process can be very complex and that there are some tough decisions to be made. TRUE!
However, I started feeling a bit uneasy, because for the last 9 years of specializing in LMS selection and touting services that walk through the entire process from beginning to end in about 2 1/2 months; I began to wonder what is the big difference between his process and mine. The general model looked somewhat similar, but there was one major difference. In my model, I have learned the value of moving the demo upfront, rather than waiting until after the RFP. It makes all the difference in the world.
Here is the 5-step model I strongly recommend (whether someone uses our services or not). I have tweaked and refined this model for many years now and it works.
Step 1: Short Listing. With over 140 LMS’s on the market, you will spend way too much time chasing down possible leads for the project unless you narrow the field right up front. The biggest mistake made during this phase is creating massive feature and functions list and then starting to weigh them against every system available. I have seen such documents with feature numbering in the thousands. In fact, I just saw a recent document with statements such as “The system shall allow a learner to log on to the learning environment.” Yikes. Have you ever heard of an LMS that doesn’t already do this? The process for short listing is so much more straightforward than all that. Just come up with some highly differentiating characteristics of your learning infrastructure or project. Make a small list of such critical needs. Our team works to keep the number to 10-20 items maximum. For example, one recent client wanted to build a customer-facing learning environment where their customers could self register and set up a learning account and their information would also set up a customer profile in SalesForce CRM. So, the critical needs list included (1) Looking for LMS vendors with experience working with SalesForce, (2) LMS must have e-commerce capability, and (3) potential users must be able to browse the LMS catalog before they create a profile/account. With these few items, the list was narrowed very quickly. Overall, I like to try to narrow the list to somewhere between 3 to 5 systems max during this phase.
Short listing is also where the Brandon Hall Research, LMS Knowledgebase comes in extremely handy. It has all the tools you need to quickly narrow your list. Click here for more information.
Step 2: Use Cases. Use cases are very different than features/functions. In fact, when I’m meeting with a stakeholder group for the first time; whenever someone throws out a feature, I make them tell me a story about how they plan to use that feature from beginning to end. Writing down the story is the use case. When the use case document is complete, it is a bigger story telling exactly how the LMS will be used. The document is written as a script for the 3 to 5 vendors selected during the short list phase. The purpose is that you want the vendor to come in and show how they might fit into this storyline. Consider how this is so fundamentally different than a typical LMS solution demo you might get if such a document did not exist. I generally try to keep use case documents down to around 10 pages in length. The idea is that the vendor should be able to tell the story in apx. 4 hours (length of the demo). I also refer to this part of the process as the “speed dating” phase. Spending 4 hours with each of the vendors quickly lets you know if they are a match or not.
Step 3: Scripted Vendor Demos. I put the demo much sooner in the process than traditional models of due dilligence. There are many reasons to do this: (1) it helps members of the stakeholder team solidfy in their common vision by seeing 3 to 5 different approaches to their common needs, (2) the vendor is much more focused on client needs from the very beginning (no dance of formality), (3) vendors walk away from the experience much better equiped to write a proposal/bid for the project, (4) the stakeholder team is much better prepared to read proposals (visualizing systems that they’ve already seen in action, and (5) it exposes issues such as “ease of use,” “visual appeal” and other subjective measures right up front. Something that is hard to capture through the RFP/Proposal process.
Step 4: RFP Development. By moving the demo ahead of the RFP, writing the RFP just became about 10 times easier. You write the RFP to the use cases and storyline. Certainly you can add detail to the story, but this is so much better than pasting in an Excel spreadsheet with 500 features all ranked from “must have,” to “nice to have” to “future need.” The vendors, instead of pencil whipping your included features list (“yes, we do that”) will tell you how they fit in your story and also what it will cost to reach that goal. So much better!
Step 5: Evaluate Proposals. When the proposals come in, you can go through the traditional process of grading their responses, but with the demo occuring prior to RFP, you have a very good idea about what they mean when they saw “yes, we have e-commerce,” because you’ve actually seen their model of e-commerce and you have an opinion about how well it will work into your processes.
The idea is to use the five steps to narrow the list to one (or perhaps two systems) before spending valuable time going extremely deep into the system, through sandbox testing, extensive discussions with the vendor, negotiations, etc.
Back to the orginal question. How does this all boil down into 2 1/2 months. Here’s how:
Week 1:
Week 2:
Week 3:
Week 4:
Week 5:
Week 6:
Week 7:
Week 8:
Week 9:
Week 10:
How long does it take to select an LMS?
Answer = 2 1/2 months
Workplace Learning Today
Subscribe by Email
Follow Bryan on Twitter
Connect on Facebook
Connect on LinkedIn
{ 3 trackbacks }
{ 2 comments… read them below or add one }
I would add to this somewhere, if you can get your hands on the product (even for just a week) to play with it, see if you can load in information the way you expect it to be relevant to your company’s learning culture. I’ve been in this implementation process for way to long and am still working on it. I was able to try 3 systems and each had their challenges in presenting material, reports, etc. based on the way learning is currently presented at my organization. A big thing to remember is that the demos are commericals. They are showing you what they want you to see, not necessarily what you need to see. If you can trial the product do so. I had many challenges trying to enter in courses (classroom based) that made me totally rethink and reinvent ways to list the courses so that my learners would understand just the registration process.
Just a thought.
I think Bryan’s onto something here, though I think that it really depends also on the size of your enterprise and the size of the audience you intend to serve. For instance, really small companies with less than 200 employees have remarkably different needs than large multi-nationals (ad that the most critical is often that smaller companies do not have the resources or bandwidth in IT to take on a resource-intensive LMS). In my own travels, I’ve found that an RFI as part of step 1, taking the information in various databases and then asking the vendors to send collateral is an important start to this process.
I think the RFP, though, needs to follow step 2 — once you have the use-cases defined, you would do best to come up with a short RFP that sets a limit to the length of the repsonse and a time to the response, so as to gather all of the facts into a decision chart for committee work is critical. The challenge to RFPs is coming up with ways to get the right questions so that you will have true apples-to-apples comparisons on things such as financial health of the company, frequency of source code refreshes, and the critical elements of your company’s need for an LMS is really important here.
I couldn’t agree any more with Tracy on getting your hands on the product for a test drive. In fact, I would add that whittling the list down to 3-4 vendors using the techniques listed in steps 1 and 2 is critical to the success of the project. Like Tracy, I’ve found that scripted vendor demos cannot show you how you’d need to use the LMS, and cannot show your particular day-to-day usage needs well enough. A test drive for a month with your 3-4 finalists ought to be part of step 3.
For instance, all LMSs provide reporting capability, and most provide a method to write reports. You may need, however, in your particular situation to have reports that detail unusual types of user information that may not be part of the ERP feed, and your current homegrown system currently provides this capability. In order to see how easy or hard it would be to replicate that behavior ought to be part of the demo / test drive.
I’ve found that setting aside a small portion of money and several key stakeholders for usability testing on the proofs-of-concept serves a really good validation for the most part (you’ll never trully discover all of your needs unless you do spend a year to gather those details, and the cost/benefit analysis as Bryan points out, is not worth it, as you lose time).
I’ve found that letting vendors know the phases of the analysis, and that the first cut after short listing is seeing how well the marketing collateral and the sales responses address the defined use cases, and that the second cut is a run off between three or four finalists is actually helpful. Letting them know that they have reached the finalist stage will engage them further as they are now only competing against less than a handful rather than the several hundred systems that could meet your needs (and I would quibble that Bryan’s number of 140 is way too low) is helpful. Especially when you tell them that the decision-makers and the stake-holders will all be engages in this test-drive using real courses and a portion of real user data with well-defined objectives (e.g., showing how easy or hard it is for instance to do bulk user management without using SQL in the database, or how efficiently the LMS imports well-formed SCORM IMS manifests with LOM definitions thus not requiring massive manual intervention for each course imported, or how the LMS performs with the variety of desktops that your enterprise has actively in use, or how well the LMS is designed to integrate with social-networking efforts that your company is undertaking, or how effective the LMS search capability really is).