Ongoing quests
Never regard a job as finished Some work has to be right first time. Let's take a feature film for example. With hundreds of people that need to be tightly co-ordinated over a relatively short period, spending millions of dollars in the process, a film shoot has to be prepared with extraordinary precision. It is unbelievably expensive and sometimes completely impractical to go back and re-shoot a scene that didn't turn out right. It hardly ever happens. And once a launch date has been set and the films and DVDs manufactured, there is little or no way of making changes. This is a right first time business.
The development of desktop computer software used to be the same. Once you'd pressed the CDs and mailed them out to paying customers, you did not want to be finding serious bugs. You certainly wouldn't expect to make any modifications until the next version, perhaps a year away. Now the situation with desktop applications has changed somewhat. Automatic online updates make it practical to fix mistakes, handle usability problems and add new features on a regular basis. You still don't want your software to be buggy, but you have a way out if the worst comes to the worst.
With websites and cloud-based applications, there are no practical barriers to changing your software as and when you want. If you find a problem, it can be remedied quite painlessly just as soon as you have a fix. If there is a clamour for a new feature you can add it in not much more than the time it takes to write the code. Now you'll have your own plans as well that you work towards systematically over time, but when you need to be responsive you can be. By and large this process is working and no software vendor or customer would want to return to the old system.
E-learning development processes have their origins in the days when courses were delivered on videodiscs and CDs, when updates and fixes were to be avoided at all costs. Because videodiscs and CDs are offline media and hard to maintain, it's not surprising that a model similar to that used for film production and desktop software development was applied. The e-learning development model is typically applied in waterfall fashion – water can flow down but it can never flow back up. Analysis, design, development, implementation and evaluation occur once and once only. Any iteration is an admission of error and failure.
How unlike classroom courses. Yes, a great deal of care can be put into designing a new classroom event, but no-one will be surprised when, the first time the course is run, what actually happens bears only the faintest resemblance to the plan. Learning is not an exact science and learners are not perfectly predictable. Major changes will need to be applied for the second running of any course and yet more substantial amendments before the third. Chances are, many years later, minor changes are still being made to fine-tune the methodology and adapt the content. The design, development and delivery of classroom events is an ongoing and highly iterative process allowing for continuous fine-tuning. A course is for life, not just for Christmas.
So we find ourselves in a situation in which traditional classroom training follows a model not a million miles from online software, while e-learning is developed according to the rapidly out-dated offline media model. Excuse me, but I sense a disconnect.
Why is a more agile model desirable? Because try as you might to do all your analysis before you start your design, you never stop discovering valuable new information about the requirements you are aiming to satisfy and the audience you are targeting.
Also because, try as you might to gather together all the creative ideas you will need in the design phase, great ideas can and do surface unpredictably at any point thereafter. Some of the best ideas occur long after the course has launched. Sometimes they come from learners.
Not only that, requirements change and audiences change for perfectly valid business reasons. And new technologies make opportunities available that were not there when the course was originally conceived.
Perhaps the most important change that’s needed is to stop looking at an e-learning course as a project and to start seeing it as an ongoing commitment. Once you have this mind-set, course maintenance ceases to be an annoying waste of resources and manifests itself instead as an exciting process of continuous improvement. The development of the Google search engine, Facebook or iTunes are not projects; they are never-ending quests for perfection. Why should e-learning be any different?
Clive Shepherd is an independent e-learning consultant