Preparing faculty for change in learning management systems


Published on

Published in: Education, Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Preparing faculty for change in learning management systems

  1. 1. Preparing Faculty for Change inLearning Management SystemsBrett CreechMay 11, 2012
  2. 2. Assumptions• Full LMS migration is taking place within 1 year• Vendor has provided full documentation (including user guides)• Test server with new LMS installed is operating• LMS will be in pilot one semester before full release
  3. 3. Step One: Organization• Administrative Considerations: ▫ Project Budget ▫ Faculty requirements on using the LMS• Technical Considerations: ▫ Local customizations to LMS ▫ Third party integrations
  4. 4. Breaking Down the Material• Avoid creation of a full user manual• Treat the use of different objects (items, files, assignments, etc) inside the LMS as specific topics.• Consider breaking down certain topics into smaller chunks – separate the creation of a discussion board from grading that discussion board.• Prioritize – Critical objects should be documented first!
  5. 5. Timeframe Available• Need to determine how rapidly documentation must be put in the hands of users ▫ Example: University of Winnipeg moving to Desire2Learn this month; widespread faculty training started in February 20121. Pilot courses selected in October 2011 – pilot training began in December 2011.• Will there be time available to adjust any documentation if features are added/changed 1LMS Migration Project, with service pack releases? project
  6. 6. Step Two: Content Creation• Create documentation based on prioritization• Consider audiences: ▫ Faculty self-training in office or at home ▫ Workshop attendees ▫ Part-time Instructors ▫ Graduate Assistants• Make sure appropriate software for content creation is available
  7. 7. Types of Content Delivered?• Written Documentation – step by step instructions with screenshots• Video Documentation – screen recordings with audio and text cues to show how to navigate the LMS, add/edit objects, etc.• Workshop Exercises – Problems developed to give to workshop attendees that can be taken from workshop and referred to later
  8. 8. Content Considerations• Language: Material should be understandable by all faculty regardless of experience using an LMS.• Documentation Length – Keep written directions brief; videos should last a couple of minutes at most on basic topics.• Flexibility – Can the documentation be easily altered if service pack upgrades include new features?
  9. 9. Step Three: Distribution• How easy should it be for faculty to get access to documents? ▫ On campus ▫ Off campus ▫ Anywhere in the world?• Documentation Formats ▫ Written ▫ Video
  10. 10. Written Documention Distribution• Paper – some documentation distributed on paper for workshops and other in-person training sessions.• Electronic – PDF and HTML documents distributed via the Web ▫ Dedicated training documentation website ▫ Searchable ▫ Platform independent
  11. 11. Video Documentation• Screen recordings and other video documentation delivered via the Web ▫ Same website as written documentation ▫ Searchable ▫ Format compatible with standard desktop computers and mobile devices• Can be embedded in LMS for possible self- directed training courses.
  12. 12. Plan for Documentation Creation• Identify individual training topics• Create written and video documentation, including training workshop exercise sheets• Create web site for electronic distribution of training materials• Develop assessment for training materials to capture feedback and make changes if necessary to improve quality.
  13. 13. Final Recommendations• Complete all documentation (written and video) prior to any pilot release; release documentation only to pilot faculty and other Academic Technologies staff.• Use documentation to train pilot faculty.• Capture feedback from pilot faculty, alter documentation as necessary based on feedback.• Release upgraded documentation system-wide no less than 4 months prior to cut-over to new LMS.
  14. 14. Continued Development• Provide assessments of documentation and make upgrades as necessary based on faculty feedback.• Update existing documentation or create new documentation and provide to faculty no less than one month prior to upgrade to new Service Packs.
  15. 15. Questions?