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.

How Can You Vote for a VP Who Uses Yahoo Mail?!

Today, it was discovered that Sarah Palin's Yahoo account was hacked. Various emails were discovered including government business.

There has been speculation in the media that she was using Yahoo to conduct business so that she could avoid being under government freedom of information requests.

http://news.yahoo.com/s/nf/20080918/tc_nf/61961
http://wikileaks.org/wiki/Sarah_Palin_Yahoo_inbox_2008

So my basic question is this: regardless of whether you want to vote for this woman because of her stance on abortion, moose hunting habits, etc. why would you EVER vote for some so security illiterate that she would use a yahoo mail account with a weak password for government business? This is privacy 101 here - do we really want to trust this woman with the keys to nuclear codes, mission briefings, etc.?

Someone should tell her it's probably not a good idea to store CIA documents on USB keys or leave unshredded documents in her garbage can while they're educating her on basic privacy management.

Hug A Developer

I just love this video...



Enjoy!

Good Example of How Tricky Security Is - Even for Banks

I signed up for online visa account access today at CIBC, and found a basic security flaw in their registration process.

Here is their form:


The flaw is the last question - the previous balance. The flaw is a simple one - if you call up VISA on the phone and give them the information above, the phone system provides your previous month's balance!

It just goes to show that even a security conscious bank can make easy mistakes when it comes to security and the moral of the story is a simple lesson: make sure you analyze all your access channels for possible leakage of authenticating information before you demand it online.

Live Earth vs. Google Earth - Which One Is Better?

I decided to run a comparison between Google Earth and Live Earth. Here are some of my findings.

Google Earth runs only as a separate executable. Live Earth runs as an ActiveX control within the live maps interface. Microsoft's approach is more integrated but it also means that you cannot run the application full-screen.

Google Earth seems to find locations better especially when they are vague. For example, I typed in "yonge and dundas toronto ontario" and Google Earth found the intersection. Live Earth couldnt find it and simply suggested businesses which weren't even at that location.

Google Earth's ability to handle misspelled words is much better as well. For example, I typed in "young street toronto ontario" and it was still able to find Yonge Street as an exact match. Microsoft Live Earth could not find it.

Microsoft Live Earth splits the search box between businesses and locations. The search assumes that you will split the business name and location into the two boxes. For example, I typed in "eaton centre toronto ontario" into the business box and it asked me for a location. In Google Earth, typing in the same search query finds me the exact match.

The search box in Google Earth is on the left hand side. In Microsoft Live Earth the search box is at the top of the screen. This makes a big difference if you are using a wide screen monitor. Microsoft's map ends up being very wide. Google Earth's map ends up being nice and square.

Microsoft's satellite pictures seem to be more up to date and detailed. Looking at downtown Toronto, the Google Earth satellite picture shows certain buildings under construction which I know are now complete while the Microsoft picture shows them finished. See also the picture of Monarch Park below and you'll notice a significant difference in picture quality and resolution.

Microsoft Live Earth

Google Earth

Both Microsoft Live Earth and Google Earth have 3D modeled buildings. However, Microsoft Live Earth's are vastly superior both in number and in quality. Google Earth shows about 5-10 buildings in Toronto where Microsoft shows hundreds.

Google Earth: Not Much of a City Scape

Live Earth: Now That's a Downtown!

Both applications take up a large amount of RAM to run. Looking at Task Manager, Google Earth was taking up to 800 megabytes of RAM and Internet Explorer was taking up to 600 megabytes. I assume this must be for caching of data.

For smaller towns, both applications seem to be equally poor. For example, searching for Port Hope, Ontario yields a poor grainy image in both cases likely because the high resolution satellite imagery is simply not available.

Google Earth

Google Earth is much richer in terms of content overlays and more flexible in being able to turn them on and off. My personal favourite is the Panaromio overlay which geo-maps personal photographs to locations from hundreds of thousands of users around the world.

Microsoft Live Earth has a feature called "Birds Eye" which does a map of photographs to the map taken from different angles. This feature is not available at all in Google Earth.

Microsoft Live Earth has very nice traffic reporting features. I was able to check the 401 highway in Toronto, see the busiest spots to avoid and also it provides construction updates as well. Google Earth does not have this feature at all.

Both applications provide directions. However, Google Earth has a feature that allows you to "play" the route. The camera will follow the route through the directions showing you in 3D how to drive to your destination.

Breaking the Law of Triple Constraints

In classical project management methodology, there is a concept called the Law of Triple Constraints:




The law states that as two of the constraints are changed, there must be an equal change on the third constraint while still maintaining the same level of quality.

For example, if scope is increased and schedule decreased, this MUST have an impact on the number of resources required. If resources are decreased, this MUST have an impact on either scope decreasing or schedule increasing.

However, in practice, this law is not really a law at all, or rather it is based on idealistic assumptions.

These assumptions are as follows:

1. The process for running the project has been 100% optimized.

2. The process for running the project is 100% known and not subject to any possible innovation to improve the picture.

3. Talent on the project is not changeable or all talent is the same.

4. The amount of management is precisely what is required to manage the project.


The reality is that in most projects these assumptions are simply not true. In addition, this model promotes a mechanistic, deterministic approach to managing projects that lacks an hope for innovation, efficiency or reduction in management.

Here are ways you as a stakeholder or project manager can "break" the Law of Triple Constraints without sacrificing quality:

1. Re-examine your estimates and make sure they are not overly padded. Some contingency is always required in order to handle unexpected events. However, on a $1 million project, the difference between 10% contingency and 30% contingency is $200K - is it really necessary?

2. Challenge the team to be innovative about process, documentation, testing, builds, etc. There are better ways to doing any project - no team is 100% optimized. I've seen simple changes such as using automated unit testing that makes massive differences in effort and actually improves quality. Depending on the type of project, there is innovation to be had.

3. Do you really need to build something or can it be bought?

4. Be ruthless about gold-plating on all sides. Developers, stakeholders, creative directors, etc. all like to add changes, rounds of revisions, additional documents, new features, etc. and that extra 10-20% makes a difference over the course of a large project.

5. Improve communication and lower documentation overhead. For every 300 page use case document you have to write, edit, review and then update make sure they are necessary artifacts and they have value. I was on a project once where the wire frame document cost $100K to produce!

6. Make sure you have the right talent for the job. For hard problems, you may think that having your junior flash developer be your technical architect will save you some money but in my experience the opposite is true - get the best talent you can possibly afford because they pay for themselves in much higher value than the additional cost in salary. For easy jobs, don't take your technical architect and make him your excel macro monkey - it will frustrate him/her and is a waste of their talent.

7. Get Creative! On every project, there are ways to innovate. It may be in the implementation of a particular module. It may be that you re-examine the problem you're solving and come up with something more elegant than when you originally built your plan.

8. Make your team entrepreneurial. Encourage open communication, risk taking, fast decision making, and low document overhead. Have the right level of process and no more than necessary. Give everyone ownership in the project and let them understand the big picture.

9. A simple tip: make sure your team members know deadlines! It sounds really dumb, but I have noticed a big difference in teams where they can see the entire plan and understand the context of deadlines than if a person is just handed a task piecemeal and told to complete it blind.

I've seen project plans that are bloated and I have seen some that are way too lean. Starting with bloat and cutting down I find is easier to manage than starting lean and trying to increase to handle the bare minimum requirements. Start with a robust, conservative and full process plan and then take a good look at it and see if there are some trimmings to be had.

One final note - this is not a panacea and in my experience, you can achieve a savings of somewhere between 0-20%. Don't expect that you can cut your project timeline in half. However, on a $1 million dollar project that's still $100-200K and on a 6 month timeline that's still a month of time saved.

As a project manager, you can choose what you do in terms of managing stakeholders' expectations. Typically, I use a conservative estimate to start and then I try to get innovative once I'm executing. If the risks of being creative and entrepreneurial pay off, then I look like a rock star with a project ahead of schedule, a happy team and satisfied customers.

But if you are a project manager who simply adheres to a conservative approach and obeys the Law of Triple Constraints like dogma, then you will be missing opportunities to innovate!