In addition to being the clearest, best structured session I attended, "Our Life with Canvas" provided me a good deal of insight into how to successfully change LMSs and to then take advantage of your new tools. Further, some of the key points for making a smooth LMS transfer apply to general training and use of LMS's by anyone.
Running down the list of good practices for a successful LMS transfer:
- Buy-in first, before an RFP. (Buy-in from faculty and Deans)
- Buy-in from leadership and a small selection committee that has procurement experience
- A dedicated transfer and implementation IT team
- Lightweight project management software to coordinate the transition
- Provide lots of training early on, and take advantage of official LMS provided support
- Have a decent budget for the initial transfer; share that money with profs, IT's, and the LMS
Do not make the transfer decision only in your IT department. Nobody likes having changes forced upon them; everyone likes a sense of agency, and there is a lot of talent around your university that should be involved in making (and then championing) a good decision.
Once you've made a university wide decision to start using a new LMS, launch it slowly, and in semester-long stages.
- Stage 1: Tests. Implementation should take advantage of your early-adopters and highly tech-proficient educators. In this first stage, you can begin to work out (or at least find) bugs that may hassle the course transfer process. These initial successes will help set the stage for future course-transfers while also working out the bugs with profs that can handle some hassle.
- Stage 2: Opt-in. Implementation provides all profs the opportunity to start using the new LMS; whether as a sandbox or as a complete course replacement. This is a full semester long stage that lets professors know it is their decision for now and gives them time to play with the new LMS before they have to start using it all the time.
- Stage 3: Opt-out: implementation allows those profs who still don't want in to hang on to their old ways. Say for instance that a prof is teaching his final course at your university... why would he want to learn new software on his way out? This stage gives profs a final opportunity to use their old content and to feel like they are not being forced into anything.
- Stage 4: Mandatory. Now nearly 2 years into an LMS transfer, finally require that all profs use the new LMS. At this point, your IT team and the community will be well versed in the new LMS and can provide the best support to those educators who were most reluctant to switch.
A few additional tidbits shared by the presenter (Dave Thomas, Director of Academic Technology, CU Denver) act to really help in those transition moments to keep people happy and successful throughout.
- If you provide self-service course transfer to professors, pay them a little bit for their time; as little as $250 can acknowledge and justify their efforts.
- Focus on small goals; don't try to push all of the cool new features all at once, and don't try to do to much with the LMS's API right off the bat. Small goals means lots of rewards; keeping people motivated and happy without overwhelming them.
- Make sure that any training you do is done within the LMS that professors will need to use. This provides professors unique insight into their students' experiences because those professors are playing with the same tools the students would use.
- Provide many different types of support, from professional development to documentation to paid help from the LMS provided.
In the end, after the final stage of transfer, 80% of the professors surveyed at CU Denver said that they were happy with the new LMS. This is quite a large percentage of people to have happy with any one piece of software and I am sure that the thoughtful transfer process weighed as heavily in their decisions as did the quality of the end product.
