June 2004 — eLearning

Print this article

Click here to receive your FREE subscription to T.H.E. Journal

Features and Functions Are Merely Trifles in the Selection of a Course Management System

The memo just landed on your desk - it's a mandate to put your school's courses online. But despite the breathtaking speed with which an impulse can turn into a Web site these days, there's a lot more to putting courses online than just creating a few Web pages. You need a course management system (CMS) to properly organize content, courses, sections, faculty, students and grades. The CMS also supplies tools for interaction, including assignments, quizzes, discussion groups, chat sessions and whiteboards.

However, all course management systems aren't created equal; features and functions differ. Yet, by the same token, there's a lot more to e-learning success than scrutinizing vendors' lists of features and functions and picking a winner. What lies beyond features and functions are considerations such as a vendor's underlying architecture, customer support, pricing strategies, partnerships, and the ever-important vendor-customer chemistry.

When tasked with selecting a CMS, the first step many responsible colleges, universities and consortia take is to name a selection committee of faculty, administration, students and possibly IT staff. They do some Web searching and talk to colleagues, friends and counterparts at other institutions. This same committee also defines goals, objectives and selection criteria. They then assemble a long list of vendors and send out requests for proposals (RFPs) - inevitably a long list of features and functions that the institution requires in a CMS. This plan of attack is better than flying blind. However, the biggest mistake a college, university or consortia can make is treating the RFP as the Magna Carta and selecting a software product on features and functions alone.

The Smoking Gun

Features and functions are important, but they generally dictate who should be on the initial vendor list rather than who comes off the list. Since no vendor will go for long without a feature that a competitor offers, comparing features and functions is virtually meaningless. If a company is missing a key feature, they'll likely have it soon. If a company has a unique feature, that d'esn't automatically mean it's useful, important or well-functioning. In fact, most vendors have the same basic lists of features and functions.

Some selection committee members will correctly argue that how vendors implement their features is critical. That may be true, but selection committees in general put far too much emphasis on minutiae - differences between implementations that are ultimately meaningless. For example, I served on one selection committee in which the interface expert performed a detailed analysis on the "usability" of two different course management systems. One offered slightly more customizability in the whiteboard function. The distinction struck some committee members as a smoking gun. Yet surprisingly, nobody in the room knew of a single online course, on campus or anywhere else, which employed the whiteboard function. Remember the 80/20 rule: 20% of the application is used 80% of the time. In real life, the smoking gun fired a blank.