ACM Logo  An ACM Publication  |  CONTRIBUTE  |  FOLLOW    

Getting Out from Under the Contract: The risk of over relying on third parties for eLearning

By Chris Jennings / February 2014

TYPE: DESIGN FOR LEARNING
Print Email
Comments Instapaper

Once you've primed your management and stakeholders to green light the budget and resources needed, you can focus on assembling the right team and technologies to support your eLearning. As those of you who have built successful online programs know, course development is a rarefied skill. It involves a combination of instructional design, writing, graphic design, information organization, and in some cases, even programming experience that you may not already have on hand. It may also require new technologies that can support registration, hosting, communication, and assessment. Many organizations will rely on contract workers to fill skill gaps and third-party systems for platform support. While this might help launch a program quickly, it's important to think about the long-term future and not rely too heavily on third parties for development.

Ideally, you'll leverage talent from your existing organization to fill the various specialties required, but what if you don't already have the required personnel? Your first inclination may be to outsource needed positions to get your program up and running, but be careful. Think about how the program might change over time. Will you want to build out additional platform features or make database upgrades to capture new information? Will the subject matter have to be updated regularly? Are there complex graphics that will need reworking? While contractors can save organizations time and resources, you don't want to have to rely on them indefinitely; particularly, when they may not be immediately available to update content (or may charge exorbitant prices to do so). To retain the most control of your content going forward, you need to be able to rely on personnel you know will be available and that you trust to build out the program you envision.

You'll also need to consider what platform technologies can support your program based on your learning objectives and measurement goals. Many programs gravitate toward learning management systems (LMS) to provide content hosting, communication tools, registration, etc. in a single platform, but these can be as restrictive as they are convenient to use.

It's safe to say that most LMS's will only meet about 75 percent of your program's technology needs out of the box. The systems are either designed too generically for a broad user base, limiting customization, or designed too narrowly for a specific group of learners, limiting their applicability. LMS's can also be costly, locking you into long-term contracts and support levels that incur additional expenses. Their bug fixes and feature releases are generally governed by their highest paying and most influential clients and their APIs can be difficult to plug into if you want to pull course data from their platform.

Additionally, think about how you'll retrieve your content from an LMS if you ever need to migrate to a new platform. If the hosting company gets acquired, goes out of business, or decides to increase the price of your renewal contract, you may be forced into a painful manual migration. Having been there all too often, I can say with confidence that you don't want your content stuck in someone else's system.

For our training certification program, we eschewed traditional third-party learning management systems so we could control every aspect of our online delivery. For content hosting, we used a combination of Google App Engine and Google Cloud Storage—Web application hosting services that run on Google cloud server infrastructure and are reasonably priced, based on traffic volume. Instead of relying on an outside company to customize and maintain servers and databases, we simply contracted with a third-party Python developer (whom we'd worked with previously) to help us adapt the appEngine instance to our needs. Freeing us from the limitations of the LMS meant we could use any technologies we wished for the course content, from Javascript to Flash/HTML5 to third-party software like Adobe Captivate, anywhere we needed. It even gave us the ability to use dynamic Python variables in conjunction with logins so we could personalize the course for individual users.

While this particular certification didn't require tools such as a discussion board or real-time chat, our developer could have easily integrated outside systems such as Google Groups or Hangouts into our course interface. We did, however, need a more robust registration system that could collect more user data than the basic App Engine login. For this, our developer helped us fork a home-grown registration tool used for internal training to easily manage our registrants and build dashboards that showed specific registration and course engagement data. Now admittedly, we got lucky in that Google already had a sophisticated registration system we could leverage. If you don't have a spare registration system lying around, consider hiring a developer to modify an open-source registration tool. That way, you won't have to rebuild an existing technology from scratch and can still customize it around your programmatic needs.

We used a homegrown content management system (CMS), originally intended to manage global Web page development, to build out our course content in simple HTML, CSS, and Javascript files. This gave us the freedom to design the course without being locked into a pre-determined look and feel. The CMS also allowed us to easily manage edits across entire courses or sections of courses, grant granular edit rights to SME's, and translate the course into multiple languages. Using a CMS instead of directly entering content into an LMS meant if we needed to migrate off App Engine in a hurry, we could simply move all the HTML, CSS, and Javascript files into a new hosting system in a matter of minutes. No painful cutting and pasting, or automated export that requires manual cleanup.

It's hard to predict the future of an online learning program; there will invariably be a lot of unknowns. Will your students start using some new device you need to support? Will a technology you rely on become obsolete or have security issues? Will the success of your program merit translating it into different languages? You want to mitigate unexpected developments by retaining as much control over your content and platforms as possible. While relying on third-party talent or technology may get you launched quickly, you need to have a contingency plan in case those resources become unreliable. A little upfront investment in hiring the right people, and using home-grown personnel and technology like cloud-based services or open source, will make your program more adaptive to future needs and save you huge headaches and costs down the road.

(Next: Writing for the Web)

These opinions expressed herein are solely the author's and in no way represent the opinions of Google.

About the Author

Chris Jennings has more than 10 years experience in educational technology and instructional design, having previously worked at The University of Texas System and New York University. He is currently an instructional designer at Google where he has led the DoubleClick Training Team in building a cross-product, online certification program for advertisers that has increased attendance from live classroom training 200 percent year over year with comparable satisfaction rates.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Permissions@acm.org

Copyright © 2014 ACM 1535-394X/14/02-2579081 $15.00

DOI: http://dx.doi.org/10.1145/2579081



Comments

  • There are no comments at this time.