Rapid E-learning Book Review

We review a great book by Michael Allen on how to make Rapid Elearning happen. We didn't know we had a brother...

Michael Allen's E-Learning Library:Creating Successful E-Learning: A Rapid System For Getting It Right First Time, Every Time

Michael Allen is the CEO of Allen Interactions, a US elearning company. Allen was the chief architect, founder, and chairman of Authorware, which ultimately became part of Macromedia, then Adobe.

Michael promoted the ADDIE development approach (sing along with us: analyse, design, develop, implement, evaluate). ADDIE was adopted wholesale by much of the elearning industry. If you have ever received a proposal from a custom elearning developer it probably had a project path which went along the lines of:

Analysis > sign off > design document > sign off > storyboard > sign off > script > sign off and so on.

It’s a very linear model that has its roots in traditional software development. Nice, safe, reassuring – and totally unsuitable for elearning at today’s pace.

ADDIE, you're a baddie...

It’s been around for a long time now, and we’ve spoken in the past about the need for an overhaul. We’re not alone. Jay Cross has been vocal in his criticism of this approach and “the fiction that design takes place in discrete steps.”

In this book “Creating Successful E-learning” Michael, give him his dues, recognizes the limitations of the linear ADDIE model. He points out that its rote application has led to lots of problems in elearning:

“Boring e-learning results from using outdated processes that focus on content presentation, accuracy and comprehensiveness, processes that rely too much on up-front analysis, not providing stakeholders with an effective way of being involved.”

The key criticism comes back to the focus on a linear sign off process which limits design and creativity, and it just not reflective of real life. He doesn’t spare the horses:

· “Specification documents and storyboards are ineffective ways of creating, communicating and evaluating design alternatives”

· "Poor designs get pushed through the process and are not recognised until too late”

· “The need to redesign as better ideas are discovered is considered a fault (and one the client should pay for), rather than part of the process.”

We couldn’t agree more. We’ve described it as ‘The Rolf Harris school of design”. There’s too much of a focus on one part of the issue, another part of the issue, all in micro-steps, and it’s not until very late in the design process that you can pull back to see if you’ve guessed what it is yet. By then it’s often too late to make changes, or at least not without costs. The first sense of how the design actually works and will feel to users and stakeholders should be much, much earlier in the process.

Get to a first version already!

In our view, and in Michael’s, Rapid E-learning gives you a chance to accelerate the first version. He recommends an approach which involves rapid prototyping from the beginning of the process, to get to a first working version quickly, that you then iterate until it’s ready for release. He calls it successive approximation, neatly aligned to the wikipedia model in that there’s no ‘final version’; things just get incrementally better with each update.

Unlike design specifications that are rooted in documentation, rapid prototypes:

• Are fun!
• Shorten the process
• Improve information sharing
• Help people talk more constructively - everyone has a view on a prototype
• Lead to more creative designs

We think Michael has got it spot on, and kudos to him for turning his own model upside-down. We highly recommend this book.

The vendor squirm checklist:

So, the next time you get a proposal with a project plan or methodology which says something like:

Analysis > sign off > design document > sign off > storyboard > sign off > script > sign off > in blood > now you can see what it actually feels like in the alpha > too late for changes, remember you signed off > etc.

Ask the vendor some questions:

1) With the rapid development tools available, why endlessly describe something, when it’s quicker to build it and then iterate to the best solution?

2) Why lock it down in change control, when it’s simple to make changes on the fly?

3) Why fret when good ideas emerge late in the process? That’s a good thing.

Even better, tell them up front that you want to take a rapid approach that involves an early prototype, so you don’t have to pay change control costs when better ideas emerge through the process. Good ideas always emerge late in the day – isn’t that what collaboration is all about?

Get the book in our bookstore.

We build on these points and include our own tips on accelerating the design process in our insight report on rapid e-learning design here.

You may also be interested in...