I once worked for a company where I inherited an LMS implementation that had not been planned. It was a disaster. Stakeholders had not been identified. Requirements were not defined. Implementation was not planned. After a year, the LMS had only a handful of users, and all of them were on the team trying to resurrect the thing. Instead of using the LMS to manage our learning, we spent our time documenting why it would not do what we needed to be done. The person who had installed it, and who had signed the 3 year contract, soon left the company. During my tenure at the company, we would manage our learning the same way we always had - using multiple spreadsheets distributed across the company and planning for our next LMS implementation.
This entry provides an outline for an LMS implementation that follows standard Project Management guidelines and procedures and hopefully allows you to avoid some of this heartache.
There is a very big assumption that if you are project managing the installation of an LMS, you are part of the training department or working on behalf of the training department. The needs that started the project and the objectives of the training department are “baked into” the fact that you have been commissioned to get this moving.
First, identify your other stakeholders. Who are they? What do they need? Start by finding out what 900 pound gorillas live in everyone’s closet. HR may need onboarding information to be communicated. Manufacturing may need to track ISO 9000 training. IT may have long term plans to move all of their infrastructure to the web. Start by talking to your stakeholders. There will be some suggestions as to how to identify them.
Your stakeholders will generally not be shy when it comes to stating their objectives. In order to get the buy-in you will need to get your project going, you will need to get their objectives and to ensure that those objectives are part of the project plan. Unfortunately, the LMS cannot be all things to all people. You will need to determine the differences between the “need to have” features and the “nice to have” features. You’ll need to establish tools and processes to organize these objectives.
The outcome of those meetings within your organization should be a clear and unambiguous project scope. This will help you in many ways, including communicating what the project hopes to achieve to all levels in your organization, and the not insignificant detail of knowing when you are finished (something that often gets overlooked).
While the details of your project may be very dependent on your organizational structure and your stakeholder requirements, there are some common points that most LMS implementations should pass through. In this section, we will touch on a number of them.
Selection: There are a number of processes that need to be addressed when selecting one vendor from the many. One of the most useful is to build sample classes before you start you actual selection. If it is an eLearning class, have your technologists build a class that will touch and explore all the various and typical technologies you will use. If you normally embed video in your classes, your test course should have some video. Likewise for audio, and any other components that are part of your normal eLearning suite. Be sure to include tests and assessments in your class. Make sure that you structure the course the same way that you do in your normal practice. If a course has multiple assessments that are tracked, then build your test course the same way.
Some additional examples of this are making sure your prospective LMS can handle the upload and download requirements of your courseware and do it without breaking the bank. To do this, you will need to have a current or projected total number and size of courses.
If it is an instructor-led class, have your instructional designers build a shell that incorporates all the various and standard pieces that are needed in your organization, including things like media and site selection, if those are applicable. By this, I mean things that mirror your organization. You might have a dedicated room for training, or you might need to schedule a shared room. How is that done? Your process should note that currently you need to send an email to someone to reserve the room. Do you print courses centrally, or can you distribute that function to the training location? This can be dependent on something as “minor” your internal charge system for printer usage. Does this fit within the LMS processes available in the system under review?
You won’t know if the LMS will work with your company processes unless you try to use it to care for the “trivial” things.
The final step here is that whatever team you have designated to make the selection needs to get together and make the selection. You need to leave this meeting with everyone on the same page and enthusiastic to move forward. Some of this is dependent on the LMS, and some will rest on your abilities as a project manager and leader.
Planning: There is more to implementing an LMS than turning it on and hoping for the best. You will need to load your standard course catalog. How is that organized? Is your company organized by lines of business? Are there multiple training teams with shared responsibilities, or is there a single team dedicated to a line of business? Are you organized by location? If you have a large training catalog, you should take a look at how it is organized and consider how that will be reflected in the new LMS. One thing that will help you is the simple act of naming your courses. Who assigns course numbers and how is that done? Are courses limited by geography, or can people in California try to finagle a free vacation to New York to take a course? (I have had people try this!)
As you start to build the working system you should look at the available roles within the LMS, and determine who will fill each role. Who will be the System Admin? Who will be the Training Admin? Will they be the same person? As you plan for the initial implementation, you should have specific people tasked for specific roles, and then you will need to plan for the training of all these key individuals. That should be done in some more organized way than “here is the link to the manual.” Before you start loading software, anyone who will be on your project team and responsible for implementation should have the training needed to use the system in their designated role.
Launch and Training: Once your system has been selected, and after you have planned everything, you will need to load all that data into the system. You have examined your training catalog and your users and your resources. Now you will actually put them into the system. You should have a test plan to ensure that everything you think is in the system is actually where you think it is. In much the same way that you had test courses in the selection system, you should have a robust test suite ready for after the system has been installed and loaded, and done before you “go live.” Who will write the scripts and who will run the tests?
Finally, after everything else has been done, and no matter what the vendor says, the system is not intuitive. You will need to train people how to use it, and hopefully this will occur at some point BEFORE they need to use it. How big is your company and how will you roll out the system? How will your end users learn what their ID is on the system? Who will provide support for the inevitable lost or forgotten passwords? This is the final step as you launch the system. Care for it well, and your users will not dislike you (c’mon, did you think they would LOVE you because you rolled out a Learning Management System?)