“Time is on my side…,” or so the song goes? Actually, time is never on your side when you’re responsible for the quality control of an eLearning project. Chances are you’re working on a rapid eLearning development project, in which case there is little time to waste. When “push the training out” is the corporate mantra, it can mean quality control takes the hit. It can mean additional, after-the-fact development time or a project that doesn’t meet the stated goals.
As a project manager, planning time throughout your project cycle for quality control and making corrections earlier rather than later can save you time, money, resources and aggravation while enabling you to meet your training goals. Sure, it would help to have an eLearning company running the show, but for those in-house project managers running the eLearning development cycle, it is important to keep a few things in mind. We’ll examine three tips for managing the quality-control process through applying systems.
System 1: Build in Time
The eLearning development cycle is similar to the software development cycle. Would software companies release untested software full of bugs, AKA features? They shouldn’t, and that’s why you receive frequent updates. Wouldn’t it make better sense to plan for contingencies and to build in time for quality control throughout the project cycle instead of leaving it until the end? Do whatever it takes to convince the project manager to build in time for quality assurance.
System 2: Templates to the Rescue
Templates serve as the foundation or the bones of most eLearning projects. “Create once, use many” has the added feature of working out the bugs once and building on a bug-free foundation. Just as the template saves the developers and writers hours of work, the quality assurance (QA) is conducted once, not every time the company creates a new eLearning project based on the template.
System 3: Keeping Records
How boring, right? But, can you spell productive? Some people spell it “Excel.” Others have proprietary methods. Whatever your method, keeping records of problems and fixes (notes, dates, whatever else you want to note) can actually save you time. Document your QA efforts for a few programs, and you’ll begin to detect a pattern. Certain writers and developers tend to make the same mistakes repeatedly. Through your record-keeping, you’ll determine who falls short when validating data, who requires grammatical cleanup and who consistently sends you broken interactions and gamification.
Even on a short timeline, quality assurance doesn’t have to suffer. The trick to turning good QA into great QA is more than building in time at the beginning of the production cycle—it’s trading time for systems—whatever systems work best for you.
