Is “Rapid” eLearning Design and Development Possible?

Traditional eLearning may be on its way out, but it is still with us today. In fact, some companies still rely on it heavily. It’s our job to look to the future, while also catering to present needs.

In today’s lean times, there is lots of buzz and interest around “rapid” elearning design and development. But what, exactly, is “rapid?”

In a 2008 post by Tom Kuhlman, author of the Rapid e-Learning Blog (one of my favorite blogs), it’s 40 hours. Here’s what he has to say (on another topic actually – professional narration):

Rapid elearning development has a 33:1 ratio in development time. For every finished hour, you’re probably spending about 33 hours of work in labor. I’m just going to keep it simple and say that it takes you a week to do a project. That’s 40 hours. At $100* per hour, the company is spending about $4000 per project. That’s just for your labor.

Hmmm…I am amazed by that number. I suppose it could be true if you already had your learning objectives, course design, and content defined and were at the point of programming it into your authoring tool. I wonder if it’s true when you have to convene a team of SMEs, discuss what the course is supposed to accomplish, define a look/feel for the course, write the content, and then program it. Here’s what makes or breaks rapid for us – and rapid is not 40:1:

The client project manager. If you have someone who understands work plans and scope, then you will move fast. If you have a PM who allows subject matter experts to add screens, content, animations, etc. to the course, things will not be rapid.
Content. If it exists and is stable, then we can move quickly. If it has to be gathered from people’s heads…and people have multiple opinions about the content, things will not be rapid.
Limiting screen templates. If we agree at the design stage how many unique screens will be created – and stick with it (i.e. 8 or 10 different screen layouts), then we can import content quickly. If the customer – or the instructional designer – keeps wanting changes and different screen layouts, things will not be rapid.
Realization of what a 30-minute course really means in terms of the amount of content to develop. If the client and instructional designer understands that 30 minutes is probably somewhere between 17-30 screens (depending on the # of pop-ups, animations, or video files embedded within a screen), then we’re good. If the designer creates a design that requires 40-50 screens, a bazillion popups, or tons of audio, sthen we will not be rapid.
SMEs. Quite frankly, the more you have the less rapid things will be. Wherever possible, one SME per course is optimal. Get 5 SMEs involved, and you will have 5 opinions to consider and 5 schedules to work around. This is one of the BIGGEST reasons rapid doesn’t happen more often.
Review cycles. If we can go from design to alpha with no script reviews, then we can be very rapid. If the client wants three review cycles on scripts/storyboards before we move into programming, we are in trouble in terms of rapid.

I might hit Tom’s # of 40 hours if I get to be the SME, the project manager, the instructonal designer, the writer, and the multimedia developer all in one and I have all the content at my fingertips with no creation of it required. The reality is that on a complex project, this is seldom the case. I contend it’s also a lot harder to be “rapid” when you are truly trying to teach someone to do something as opposed to merely sharing information with them. So…what strategies have others evolved to achieve “rapid” AND how do you define “rapid?”