I wish I had a nickel for every time I read a post on one of my networking groups where someone asks what features they should be sure to get on their LMS. Having been down that path multiple times, I can say the chances of finding one with the “best features” are really good, because most LMSs I’ve seen have all of them. My point being this – the LMS is the commodity – the world does not revolve around the LMS – the application in which the LMS is going to be implemented is where the variability that matters is manifested. Being at a state of readiness to utilize your new LMS is of far greater importance than the features that, for the most part, come as standard. I will share several areas where most of the blood we let was experienced; both were external to the LMS, and yet depended upon the LMS for successful implementation.

The first and second areas were linked, and at the core was the ability to write database queries. I’ve researched, evaluated, deployed and implemented four different LMS platforms and have consistently found that REPORTING is not a core competency. True, most have a host of canned reports, and some have ad hoc capabilities for reporting, but rarely will they suffice when your stakeholder population wants to slice and dice the data…and they will. Precious few will ask for the same report. And invariably there will be the add-on for pushing email notifications based upon what “intelligence” is gained by virtue of those custom reporting formats. Staffing of a database guru is essential.

Without a resident database query architect in your midst, you are going to experience a dissatisfied stakeholder population, and the LMS will be the technology they learn to hate no matter how many bells and whistles the sales rep convinced you that you would need. And yes, I have possession of that t-shirt.

Here is a perfect example…providing training on a new medical records system for 14,000 employees, and recognizing that all users must be “certified” before getting their tattoo and sign-on credentials. We had to stagger delivery of learning courses, some on-line, some live ILT. I guarantee there will be the ones who miss due to illness, or emergency patient care scenarios, or dis-interest, or a manager who does not “encourage” participation. There will be plenty for other reasons as well. I quickly learned that a GoLive of this magnitude does not get pushed back for any reason, least of all…incomplete training.

If someone is late or missing their assigned window for training, there will need to be a report that identifies them…and oh yes, that scope of reporting covers delivery to 600+ mangers who need a report that tells them who is late and who needs to be harassed with a nasty-gram from the LMS. Plus, that report must be exclusive to only their area of responsibility. Add to that a roll-up report to the Director so they can harass the managers who are non-compliant. And do not forget the roll-up to the VP who job is to harass…you get the idea. It’s just ugly, but it has to happen. Having a query-writing guru will be essential. Having a robust email notification capability will be no less essential. While these are not directly tied to the topic of this posting, they make the case for integrating the needs of the user population from individual to manager.

The third, and probably the most critical area, has nothing to do with the LMS, but without it, the LMS becomes a filing system with one drawer and no folders. Thou shalt have taxonomy. In one instance in my career, I inherited a LMS that had been deployed two years prior to my arrival…not yet implemented…because they did not consider implementation beyond a successful GoLive party…and the LMS had over 700-courses in the catalog. There was not only one taxonomy in place; there were 37-taxonomies in place. That was not a bonus situation. Every individual in unrelated areas of discipline had courses they were responsible for…and they had their own naming convention…their own taxonomy…and they had freedom to use…or not…keywords. And they did…or did not…as each was so moved. The result was redundancy in the catalog and some courses were buried so deeply there was little chance of successfully browsing and finding anything. Forget searching…half the course titles started with “The…”

Lesson learned #1 – Shut down access to loading courses to a few whose neck you can grab when something goes wrong…and it will. We went from 37-souls with access to only three and they reported to me. This was actually a lesson learned in an earlier LMS implementation where we built from the ground up, versus dealing with inherited chaos that had brewed [festered] for nearly two years.

Lesson learned #2 – Build the taxonomy prior to loading anything into the LMS. Build the taxonomy to match the stakeholder population’s work context. We used a top-level category structure that was limited to seven-to-nine entities max. I refused to accept the role of being the business unit to choose what those top-level categories would be. We went to the business unit executive teams for their guidance. Collaboration is key.

Lesson Learned #3 – Build a hierarchy underneath each top-level category the same way with sub-categories that match work disciplines…and get your guidance from those stakeholder leaders who will be expected to use them. Never volunteer your LMS team as the ones who will choose sub-categories, or sub-subs.

Lesson Learned #4 – Do not expect a hierarchy of any construct to make your implementation successful. Sounds like a contradiction doesn’t it? It’s not. Ultimately, you are building a multiple-browse-path capability. This means recognizing that there is a distinct difference between “search” and “browse”. Some users will window shop [browse] and some want to go right to the course they need [search] and clicking twenty times to get there only breeds hatred toward the LMS. Whining will begin almost immediately, “I can’t find anything in this #@*$ system. Why did we ever buy this thing?”  And your LMS help desk will get swamped with those who cannot find what they are after…and neither will your help desk…who will then join the chorus with, “I hate this #%&#@ thing!” and threaten to transfer to IS.

Lesson Learned #5 – Use a Mind-Mapping software to map your taxonomy. Ours, when printed out and pieced together, was in 10-point font and mounted on a poster board measuring five feet square. Impressive, pretty…and scary. In reality, you will wind up with clusters of mini-hierarchies within larger hierarchies. Each top-level entity had multiple sub-categories underneath and each of those, in some, but not all cases, had sub-sub-categories where courses were then actually clustered. To make that mix workable, see Lesson Learned #6.

Lesson Learned #6 – Equip those who have access to entering new courses, new sub-categories and sub-sub categories [if need to go that deep] with a NAMING CONVENTION that is locked down. Tight. And make it mandatory that KEYWORDS are not optional…and it would not hurt to gather relevant keywords from the stakeholders within their disciplines where keywords might be used in a search. Do not overlook the key word I just used…SEARCH. Without a naming convention that is strictly enforced, your search capabilities are at risk. Folks will be willing to click-happy browse all day, but when they are in search mode, clicking more than twice to get to the course they needed was considered unacceptable performance and whining resulted.

Lesson Learned #7 – You will have redundancy on the taxonomy map. That’s a good thing because that is the only place you will have redundancy. Each course is resident in a single instance no matter how many times it shows up in categories or sub and sub-sub categories in the course catalog. You may have one course that shows up thirty times in as many browse paths, but there is only ever one course on the LMS. Locking down who has the rights to add categories and subs [See Lesson Learned #1] is absolutely essential.

There were other lessons learned, but these were the most impactful to establishing a sense of integrity within the course structure in the LMS course catalog. Do not expect your LMS vendor to be of much help. Your LMS will not be of much help either because they come standard with one file drawer and no folders. They all have a search function, and they all welcome the casual browser to browse to their hearts content. The ability to do one or the other is a function of your taxonomy, and hands-down…functional SEARCH is the most critical to solid user performance on the LMS. If they cannot find it, your team will be the first to know…and it is always your fault.

Tons have been written about taxonomies and folksonomies and how hierarchical search is obsolete. I agree. What I have just described, while being based on hierarchies within hierarchies and folksonomies by work context-relevant keyword metadata, is in reality only a hierarchy to the naked eye. It has to be organized that way to visualize it. If you browse, it is indeed a hierarchy. BUT…if you search the hierarchies are irrelevant and avoided altogether by having integrity to naming conventions and rigor in the use of keywords, phrases and meta-tags. Do not under-estimate the importance of a multiple browse path construct.

My advice? Start building your taxonomy waaay in advance of loading your first course. Guard access to your course catalog like a big dog to ensure lasting integrity of the taxonomy. Do not freak out when you see over 3,000+ appearances of courses in a 700-course catalog. Engage your stakeholders in the development of the catalog taxonomy. If you build it, you get the blame. Call me a preservationist, but I am convinced that equipping the user population to find what they need will go a long way toward allowing your help desk to provide more meaningful help. You may break a few hearts if you need to reel in access rights from rogue LMS administrators who were trusted at the time of the GoLive party, but trust me, they will get over it.

G.

Gary G. Wise
Workforce Performance Advocate, Coach, Speaker
gdogwise@gmail.com 
(317) 437-2555
Web: Living In Learning
LinkedIn