Best Practices for Implementing a Learning Management System

I have just co-written a white paper that is now available through Brandon Hall.

Here is the description of the paper - click the link if you would like to purchase it or stay tuned to my blog for further ideas and writings.

Description

Imagine you've been given the job of researching and finding a suitable learning management system (LMS) for your company. Where do you start?

Everyone knows that selecting the wrong LMS can have terrible financial repercussions and hurt the quality of your learning initiatives. What is often forgotten, though, is that selecting the RIGHT learning management system but implementing it poorly can be equally painful.

This report, written by Gary Woodill, Ed.D., director of Research and Analysis at Brandon Hall Research; David Fell, vice president of Business Development at Operitel Corporation; and Christopher Woodill, Vice President, Solutions and Strategy at Navantis Corporation, is the first in a four-part series on the process of implementing an enterprise LMS.

A typical LMS can take months, if not a year or more, to implement and can cost hundreds of thousands of dollars. Getting it right is critical; getting it wrong can be a problem for both you and your business. Essentially, the process involves four stages:

Stage 1: Planning and Evaluating Business Needs for an Enterprise LMS
Stage 2: Purchasing an Enterprise LMS
Stage 3: Implementing the Selected LMS
Stage 4: Maintaining, Supporting, Operating, and Governing an LMS

This report focuses on Stage 1 and addresses the following:

• Developing a business case for investing in a learning management system
• Considering alternatives to an LMS
• Articulating a vision and scope for the entire project, resulting in developing a “project charter”
• Developing an implementation strategy and project management plan that includes presenting the business case, assessing the LMS's impact on the organization, and changing management strategy
• Developing the communications and marketing plan for the project
  Identifying all stakeholders for an enterprise LMS
• Conducting a requirements gathering exercise, including developing “use cases” for each business unit and group of stakeholders
  

If you have thoroughly carried out the above suggestions, then you are ready to prepare and send out an RFP, investigate products and vendors, and move toward purchasing a learning management system. It’s also important to note that getting this first stage right provides a firm foundation for success in all the later stages.

Some thoughts on the Zachman Framework

I have been doing some reading on the Zachman Framework in the context of some work we are doing with the government. The ZF is popular in government circles as an enterprise architecture framework and they routinely ask for experience using it within their RFPs, especially for roles such as technical architect or business analyst. Having had lots of work in the enterprise architecture space but none specifically using the Zachman Framework, I wanted to see for myself what it was about and understand how it could support my own needs in presenting strategic plans to a client.

Having now read a few books and posts on the subject, here is my own reaction to it:

• Written in 1987, it definately has that architectural ivory tower approach that assumes that if we could only document every explicit assumption in our enterprise we would have this perfectly functioning enterprises. Having worked in lots of different enterprises, I don't know any that actually lived up to this ideal and they functioned quite well despite not having every prescribed artifact nailed down.


• I love the simplicity of the model: 6 roles and 6 interogatives. It's the simplicity that makes it "universal" - it's like saying any problem can be solved by combining asking questions and a planning/building life cycle. While I would say this is true, its also quite vague and doesn't provide a lot of specific techniques or approaches to enterprise architecture other than a method of organization.


• I like the approach in that its business centric and quite non-technical. I could quite easily explain the framework to a project manager, a business analyst and an industry stakeholder. You do not need an engineering degree to get the ideas here and the expertise is delegated to filling in the particular models.


• I really like the integrated approach that forces architects to really think about more than just code, servers, and technology. The framework puts a heavy emphasis on logistics, business cases, scheduling, business rules, and people. The "HOW" part of the framework is only 1/6 of the picture which I think is about right.


• The concept of a normalized architecture, e.g. a unique spot for a piece of information is an interesting one but hard to accomplish in practical terms. In my experience, its definitely a good ideal - I have had too many cases where the requirements document, the data model and the network diagram are changed independently and they no longer match.


• One challenge with the organization of models in ZF is that they are very model focused instead of feature focused. In many cases, you want to organize your requirements, code, etc. by feature so that you can take it out - this seems inherently different to do in ZF because your feature is now spread out in 36 different buckets of artifacts. Trying to take a feature out or change it means finding it in your master universal schedule, your master universal network diagram, your master use cases, etc. (Ideally, you could automate the entire repository of requirements so you could slice and dice in multiple dimensions so that you could search your whole picture by "sliver")


• There is a certain religious zeal about this framework from some authors - the fundamentalist belief that if you can complete all the spots on the grid that you now have this nirvana requirements repository and we can all go home until the next change request. In real life of course, the nirvana never happens and you have to cut corners like crazy to get anything out the door. While this is a nice framework, in practice many medium to large organizations could not fill in every bucket down to every explicit assumption and maintain the repository with any execution speed. This is probably why this framework is popular amongst governments, large scale industries (aerospace for example) where you have years to gain value out of your architecture investment but not used by smaller or faster moving organizations.


• There are some ways you can approach the ZF with an agile approach. Scott Ambler has a good article on this here.

In general, for a framework that evolved in the mid 80's, I was pleasantly suprised at how relevant it is in today's context. I could conceivably apply the same principles in some of the enterprise planning work I do today in very different technology contexts than what were around in 1987, e.g. portals, internet, rich client applications, data warehouses, etc. I could also see using it as a basis to analyze and document a very specific domain model instead of an entire enterprise.