Avoid an LMesS: Take Control of Your LMS Selection Process

Transcription

1 Avoid an LMesS: Take Control of Your LMS Selection Process February 2009 Prepared for:

2 Introduction To achieve your business, budget, and timeline goals when implementing an LMS, an honest assessment and prioritization of detailed requirements is critical. The best vendors offer many of the same features and functionality, claim system architectures that can support more users than you have in your organization, and tout their robust integration capabilities. How do you tell them apart? Bringing them in to conduct one size fits all demonstrations will leave you trying to relate your business needs to what you saw. Instead, the key is to offer a firm foundation of detailed requirements for vendors to demonstrate against. This allows you to set the agenda and requires the vendor to prove their software will meet your needs. This course of action consists of four main phases: Requirements Gathering comprehensive identification of requirements that are representative of all system stakeholders at various levels of the organization Requirements Prioritization examination of the identified requirements against overall business objectives, organizational learning needs, compliance requirements, and other factors to produce a ranking of items that are musthaves versus nice to haves Vendor Demonstration Request Development development of detailed scenarios representing the most common and most critical processes that the new LMS will be expected to support RFP Evaluation development of an evaluation tool and review process that ensures that each LMS will be measured against the requirements that have been identified and prioritized Requirements Gathering It can be challenging to gather requirements for an LMS. How do you know that the right people are providing input? What do you do when different departments have conflicting requirements? How do you reconcile the needs of directors accountable for learning strategy with those of training administrators responsible for day to day operations? The following guidelines will help ensure that your requirements gathering process provides the input you need to make solid decisions later. Identify stakeholders at all levels of the organization. During this phase, it is critical to identify stakeholders across all business units within the organization as well as within each business unit. Whereas a director may bring a strategic view to the conversation, a training administrator may have deeper operational knowledge, such as what data must be tracked to meet reporting requirements. Document requirements without bias. Treat requirements gathering like a brainstorming session; all ideas should be recorded without judgment. There will Page 2

3 be plenty of time during the prioritization period to whittle down the list if needed. Build stakeholder buy in and support for the project. This is the easiest time to build support for the project, because no hard decisions are being made yet. Implement and communicate a clear process for how the selection process is going to work, and institute a solid follow up plan with your stakeholders. Resolve conflicting requirements. Once requirements are gathered, review them to identify conflicts and bring the appropriate parties together to address any issues. The earlier this is accomplished the better; it avoids heated discussion during vendor demonstrations or worse yet, during system implementation. Requirements Prioritization Like any project, the scope of an LMS implementation is bound by constraints on time, money, and resources. As such, requirements must be prioritized to determine which are critical to the initial implementation, and which can be deferred until a later date. How do you maintain the support you ve been building for the project when inevitably, someone s pet initiative is being deferred and one business unit s top requirement is being prioritized above another s? Align requirements with business goals. High priority requirements should show a direct alignment with your organization s business strategy to demonstrate how the initiative not only furthers learning objectives but contributes to the achievement of the organization s business strategy as a whole. Provide a system roadmap. Show stakeholders that requirements that have not been slated for the initial release have not been forgotten. What are your goals for the system for the year? Two years? Five years? Maintain communication. As the project progresses, participation in the process will begin to narrow as justifications for funding, contracts with vendors, and eventually the system implementation take place. Even though many of the participants in the requirements gathering process will not have an ongoing role in the system implementation, keep them informed of the project s progress and the decisions being made. Vendor Demonstration Request Development Once specific requirements and priorities have been identified, they should be translated into discrete process based, use case scenarios for each potential vendor to demonstrate against. This is a departure from the traditional check the box RFP. While having that type of Yes or No information can give you a quick tally to compare each vendor, it does not ensure that your business processes can be translated into each LMS in the Page 3

4 sequence in which you may need events to occur, or with the appropriate business rules enforced. In addition, it may result in false analysis because vendors can make different assumptions about the terminology used in the RFP, or their Yes/No answer may reflect functionality at the surface level but does not delve deeper into what is really required to make the process work. The following example addresses one aspect of the registration process to show an organization s specific needs. By providing exact steps, data, and expected results, a vendor can demonstrate how closely their LMS can emulate a given process and where potential gaps may be. Your organization can then evaluate the product with a better understanding of the steps it may take for an administrator to perform set up tasks, how an employee will complete the process, and the available messaging within the system that provides direction for completion of these tasks. Example: Prerequisite Check In this example, the following six requirements were translated into a vendor demonstration request: Set up prerequisites for a course Set up equivalents for a course Allow completion of an equivalent to satisfy a prerequisite Allow an employee to register even if a prerequisite has not been met Allow administrator to monitor prerequisite status Allow administrator to send s to class participants The request takes each requirement and provides specific data to be demonstrated as well as a desired sequence for the demonstration to follow: Employees must often complete prerequisites before attending a training event. Administrators need to monitor their progress against completion of these prerequisites and follow up with employees that still have unmet prerequisites. 1. Set up a class (Course A) that has one prerequisite (Course B) that must be completed prior to attending the class. The prerequisite has an equivalent (Course C). The employee may complete either the prerequisite or the equivalent to meet the requirement. 2. Login as an employee that has already completed Course C. Register for Course A and demonstrate the product s ability to recognize that the class prerequisite has already been met. 3. Login as a different employee that has not met the prerequisite. Register for Course A and demonstrate how the system notifies the employee that there is a prerequisite that has not been met. 4. Login as an administrator. Show how the administrator can either view online or through a report the employees that have registered for Course A and whether or not they have met the prerequisite. Page 4

5 5. Show how the administrator can identify whether the employees that show up as not having met the prerequisite have registered for either Course B or C. 6. Demonstrate how the administrator can send an reminding registered employees to complete the prerequisite prior to the class start date. RFP Evaluation As information from each vendor is collected, it is important to have a consistent method of gathering and evaluating each product s strengths and weaknesses against your stated requirements. An LMS evaluation tool should be created prior to any vendor demonstrations or RFP submissions, and use of the tool must be communicated to all reviewers, along with an explanation of evaluation criteria and how the LMS evaluation tool fits into the overall selection process. Conclusion By spending the time up front to gather detailed requirements and understand your organization s business priorities, the process for selecting an LMS vendor can be made more efficient, as can the implementation of the chosen product. Not only will organizational buy in be greater because of wider involvement in setting the agenda, but the vendor demonstrations will provide a more accurate picture of what your future LMS may look like and lead to a more confident decision making process. Page 5

6 About The Educe Group The Educe Group is a boutique firm dedicated to providing uncompromising service in an increasingly critical niche: the implementation and adoption of Talent Management software. With a diverse team of professional consultants, Educe helps companies develop and execute learning strategy, conduct vendor selection, implement and adopt talent technologies, and deploy customized training solutions. Educe has also been commissioned to conduct research and produce white papers on industry best practices in learning and development. More information is available at For information on how The Educe Group can assist your organization with LMS vendor selection, or to schedule a service offering and capability presentation, please contact us at or info@educegroup.com The Educe Group. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. Page 6