The Six Proven Steps for Successful LMS Implementation (Part 2 of 2)

(Editor’s Note: This is the third of five articles by Steve Foreman on learning management systems.)

As I described in part one, theLMS implementation process involves six major steps: planning, LMS configuration,systems integration, course and data migration, user acceptance testing, and golive (Figure 1). I addressed the first three steps in part one, along with thekey communications and change-management activities that must be part of an LMSimplementation if you want the highest likelihood of success.

Figure 1: The LMSimplementation process

In part two, I cover the last threecritical steps.

Course and data migration

If you are changing LMS products ormoving from a custom LMS to an off-the-shelf product, you will probably need tomove the training data and courses from your legacy system to the new LMS. Thisis one of the more complex tasks in an LMS implementation. You must do it in aspecific sequence, and you must address any incompatibilities between the waythe data and courses were stored in the legacy system versus the new LMS. Thiscan sometimes require some creative problem solving.

For example, your new LMS mayenforce stricter data integrity rules than your legacy system does. Forinstance, some of the courses in your legacy system were entered in such a waythat their end date was earlier than their start date. The new LMS will rejectthese courses. So you may need to adjust the dates in the old system beforemoving them to the new LMS.

Data retention policy

The first step is to decide howmuch data to migrate. A good rule of thumb is to move as little data aspossible—the more data you migrate, the greater the potential for errors andproblems that may delay your implementation project. Check with your IT andlegal departments. They may have already established an information-retentionpolicy for your organization that you can use to guide your decisions.

For example, if your organization’spolicy is to retain employment records for three years, then you may not needto migrate the last 10 years of training data. You may instead decide tomigrate only three years of data and create a database archive of all olderdata. If the need arises to access the legacy data, you can ask IT to restorethe backup and run a report. Since the older data is not immediately accessiblein your LMS, retrieving archived data may take several days, but it keeps yourLMS clean and simplifies your implementation project.

There may be some exceptions to thepolicy. For example, you may need to consider courses that are prerequisites toother courses. If you do not move data related to prerequisites, some users maynot be able to register for a course for which they have already completed theprerequisites. Consider courses that result in compliance and certification aswell.

User data

Once you have decided how much datato move, the next step is to load your users into the new LMS. If you areestablishing a feed from an HR system, the feed must be developed, implemented,and tested before you migrate anything else. Otherwise, you will need to movethe user accounts from your legacy system to the new system.

Standards-based courseware migration

The courseware migration processvaries depending on the type of LMS. If you are moving from one academic LMS toanother you will need to export your courses to the appropriate format for yournew LMS and then import it. A nonprofit standards organization, IMS Global, hasdeveloped a number of standards for doing this, including the IMS CommonCartridge (CC), IMS Learning Tools Interoperability (LTI), and IMS Question andTest Interoperability (QTI) standards. Check to see whether your legacy and newLMS support these standards. It will make course migration a lot easier.

If you are moving from onecorporate LMS to another, the process is a bit more complex. First, if you haveimplemented SCORM-based courses, then you will need to reinstall the SCORMpackage for each of the courses on your new LMS. Some LMS products provide abatch method that enables you to queue up the installation of multiple courses.Other LMS products will require you to install each course, one at a time.

Even though the SCORM courses mayhave worked well on your legacy system, they may need some adjustment to workoptimally on the new LMS. A good approach is to start with an inventory of yourSCORM courses; here’s a method that works well:

• Categorize the SCORM courses by the authoring tool or vendor that produced them
• Then install and thoroughly test one course from each category
• Test course launch, player compatibility, bookmarking, navigation, audio, video, animations, graphics, and embedded links, as well as test score, and module and page tracking
• Make sure the course shows up properly in the transcript of the new LMS
• If you run into problems, make any needed adjustments to the course and the manifest, reinstall and retest
• Replicate your adjustments to all other courses in the category; install and test them all.
• Manage an exception list of any courses that don’t work properly
• If you no longer have the source code for the course, you may need to redevelop the course using a more compatible authoring tool

Course data migration

If you are implementing an academicLMS, your course data probably transferred via the IMS standards described inthe previous section. For a corporate LMS, your IT organization will need toextract your course titles, descriptions, schedules, locations, instructors,metadata, and other course-related data, format the data according to your LMSvendor’s specifications, and import the data into the new LMS. If your ITdepartment is not equipped to do this, you may need to hire your legacy LMSvendor to create the extracts.

Transcript migration

Once you have populated your newLMS with users and courses, the last step is to move your legacy transcriptdata to the new system. Transcripts represent the relationship between usersand courses, which is why the users and courses must be present in the systembefore you move the transcript data.

Test a sample of the user, course,and transcript data to ensure the migration process worked properly.

Migration stages

You should perform the user, course,and transcript migrations in three stages. Clearly, you’ll want to avoid anydata loss, so in the first stage you’ll migrate a relatively small sample ofthe data and test it to verify that the migration programming works properly. Thesecond stage is to migrate all data to date. Once you’ve done this, you will beable to enhance the course setups by configuring any features and functionalitythat you may not have had in your old LMS and you will be able to perform user-acceptancetesting. The third stage happens just prior to go live, where you will performa transfer of the data that was added or changed since the full migration youperformed in the second stage (this may sometimes be referred to as a “deltatransfer”).

User acceptance testing

The last major step before goinglive with your LMS is to conduct user acceptance testing. Your organization isthe “user,” and you are testing the LMS to make sure the vendor has delivered afully working, bug-free system. You are also testing to make sure yourconfiguration, courses, and data are available in the system as you expect themto be. Once you are satisfied with this testing, you are essentially “accepting”the system from the vendor.

The key to user acceptance testingis to be thorough in testing every part of the system. You want to find andcorrect all the bugs before you go live so that your end users don’t have a badexperience in the first few weeks or months after the LMS is introduced.

Start by convening the core team tobrainstorm a list of procedures to test. Include procedures performed byadministrators, learners, report users, instructors, and any other securityroles you have defined.

Once you have your list ofprocedures, divide the list between team members (you may want to engage someof the extended team) and ask each individual to run through the procedure andmake a note of every action performed: menu items selected, fields entered,checkboxes checked, buttons pushed, etc.

You may want to provide aspreadsheet format for the test designers to use. You can create a worksheetfor each test. Each worksheet may include a header with the test name, the roleof the tester (e.g., administrator, instructor, student, etc.), and anyrequisite data that is required to be configured in the system in order to runthe test. For example, if your test specifies that a student is to find acourse and register for it, the student’s account and the course must both bepresent in the system. The rows in the worksheet may represent the steps in theprocedure. You may want to include three columns to represent a description ofthe action to be taken, a description of the expected result, and a place forthe tester to enter the actual result.

After you have defined anddocumented all the test procedures, create a test schedule. Do your best atplacing the tests in a logical order to make test setup easier. For example,run the test in which an administrator creates a course before you run the testin which a student registers for the course. You may want to schedule no morethan one or two hours of testing per day for each tester so that they cancontinue to perform other work duties.

Assign a test lead to debrieftesters and record bugs. Convene the core team at the end of each testing dayto discuss the status of all open bugs. Prioritize each bug as critical (mustbe fixed immediately; prevents further testing), moderate (must be fixed priorto go live), or low (should be fixed in a future release). Route bugs relatedto the content and data to the appropriate people in your organization. Routebugs related to the system to your IT organization, the vendor, or both. Keeptrack of who owns each bug at any given time until the bug is corrected. Besure to retest corrected bugs to verify that they have been fixed.

Once all tests have been completed,end-to-end, and all critical and moderate bugs have been fixed, you are readyto go live with your new LMS.

Go live

The final step is to go live withyour new LMS. To prepare for go live, it is a good idea to meet with the coreteam to brainstorm a list of risks and a contingency plan to mitigate eachrisk. Notify your course owners and administrators well in advance of the golive date. Advise them to avoid scheduling critical training during the weekbefore and the week after the go live date, if possible.

Helpdesk preparation

Consider providing a helpdeskscript to your support staff, who will respond to questions and problemsreported by end users. Create a list of anticipated call topics and describehow to respond. Examples include how to get to the LMS, how to recover from alost password, what to do if something does not appear in your transcript, howto register for a course, etc. Provide an escalation process indicating who tocontact if your helpdesk staff cannot resolve the problem, and what informationto collect when escalating a problem.

Blackout period

There will be a period whereneither your old system, nor the new LMS will be available. During this “blackout”period, you will want to shut down your old LMS, perform the delta datamigration, spot check the data and functionality in the new LMS, and redirectthe legacy system’s web address to the new LMS.

If anything goes wrong, you willneed to reactivate the old system and postpone your go live date until theproblem is diagnosed and resolved.

To minimize disruption to your endusers, you may want to schedule the final go live tasks to occur over aweekend, provided the resources involved in your go live process are available.

Concluding thoughts

There are many moving parts in anLMS implementation. As the old saying goes, “The devil is in the details.” Implementingan LMS is a rigorous and resource-intensive process. It’s almost never the casethat an LMS, right out of the box, will suit all your needs, so it’s importantto be prepared for what is involved in LMS implementation when you decide toevaluate and select a product.

Many organizations remember their last LMSimplementation as a nightmare. Looking back, they could have avoided many ofthe problems they encountered. With the appropriate resources and planning, andlot of attention to detail, your new LMS can serve you well for many years tocome.