A tale of two rapids

Virginia Barder delves into the world of rapid e-learning and shows us the reality of 'getting behind the hype'.

Krista recently wrote an article about Rapid e-learning 'getting behind the hype'. Here is one view of the reality behind that hype... A few weeks ago we were asked to do two different projects:

• Organisation A needed some e-learning ready to be delivered in four weeks. It was business critical that it met that date, and it was important enough to be worthy of reasonable budget and production values
• Organisation B recognised that in today's climate it has to change the way it approaches e-learning, and wanted to start doing rapid projects to be able to get e-learning produced more quickly, more efficiently, and cheaper.The old ways were too slow and too expensive.

How have they gone?

The first project was never called rapid. It just had a fixed, tight deadline. Though budget was important, it wasn't the main driver. It was better to spend a bit more to de-risk the project and ensure good quality learning, on time. And a few weeks on, we're almost ready to deliver to a satisfied client, on time.

The rapid project is not so rapid after all. Unavoidable problems with stakeholder and SME availability have meant a number of stops,starts and delays. The project is kicking off properly this week. And these stops and starts have chipped away at the much tighter budget, putting extra pressure on the remainder of the project.

Lessons learned

The lessons to be learned from this are, I hope, obvious:

• We're working together - we can probably move as fast as you can, and it's better to be realistic about how fast your stakeholders can move and how available your SMEs really are. It's perfectly legitimate to want to reduce your costs without having to have unworkable schedules.
• If you start with a low budget and there are project delays, there's little or no room for flexibility or manoeuvre, and something will have to give.

Don't pigeonhole your project

Meanwhile, we've got a lot of other projects, few of which anybody has ever labelled rapid, but some of which have turned around very fast indeed, and some have been very cheap. (See our article about a very rapid project we did for Bupa, for instance.) But like a parent who doesn't want to label or pigeonhole their child, so it's not always helpful to label a project, and impose a set of assumptions about the best way of doing it. The second, 'rapid', project, was disadvantaged by being labelled 'rapid' - it set up expectations that were bound to be disappointed. You're better not picking up a pre-defined 'process' and just applying it to a project because the labels match. You need to find the right process and the right way of working, to make each individual project work the way it ought to, in order to meet its own particular needs.

And the same applies to tools - there seems to be an assumption that some tools are more suitable for 'rapid' - and that a rapid project can be rapid as long you have the right tool. (To be fair, Krista's article points out where tools can be useful in rapid development.) Call me cynical but I only wish life were that simple. Better to find the right tool for your particular project - you'll get a much better outcome.

Comments

Add New

Very useful post gas 2011-06-16 14:10:42 Thank you for such information, I will keep this in my mind. Reply

Write comment
Name:
Email:
Title:
Please input the anti-spam code that you can read in the image.

Powered by !JoomlaComment 4.0 beta2