Rapid - getting behind the hype

Download the PDF [156 KB]

What is rapid? It ain't what you do, it's the way that you do it?

Everyone's got an opinion about rapid e-learning: is it a rain that's going to wash away our sins? Or will we all be swept away on a tidal wave of low quality e-learning?

First of all, what do we mean by rapid? Often we think of rapid as anything that's built using a rapid tool. But there are a lot of other tools that can be used in a rapid way – and there are a few self-appointed rapid tools that, by the time you’ve twiddled about trying to work them out, don’t feel very rapid at all. Perhaps a better way to think of rapid is in the process, rather than the tools. As always, it isn’t what you do, so much as how you do it.

Before we look at the common assumptions about rapid e-learning (tools and process), let’s see a couple of quick examples of rapid processes in action.

Rapid processes

Virginia Barder, Director of Projects at Brightwave, explains, “There are two approaches to rapid processes that we use at Brightwave: a bespoke rapid process that takes a little time and thought to set up and tailor to the client’s needs, but then keeps rolling out e-learning quickly and easily over the long-term. And there’s the one-off quickie project that needs to get up and running and out of the door in a short time, so we follow our own tried-and-tested rapid process that we know will work”.

Bupa is a long-standing Brightwave client and has used both of those processes. For the aptly named SWIFT project, Brightwave delivered 600 modules over two years. Each module had a twelve day schedule from starting the script to delivering the final signed-off build. Barder elaborates, “We spent a lot of time up front on the design, conducting workshops and training sessions, to make sure that once we were up and running the project would run smoothly”.

A related requirement for competency tests for Bupa followed the short run process. Barder explains, “In one day, we met Bupa to kick off the project in the morning, agreed the design in the afternoon, and signed it off with them over a cocktail in the evening. This is all helped by the mutual trust and understanding that we have.”

Of course, you can’t completely separate tools from process. For example, if, as many people do in rapid projects, you decide to leave out the step of creating a written script and to script straight into a build tool, it might be helpful to use a tool, like Atlantic Link, Mohive or the Brightwave BIT issue tracker, that has a facility for reviewers to record review comments. Otherwise it can be hard to capture accurate feedback, which can of course have a knock-on effect on later reviews.

So if you’re thinking about using rapid for the first time, or you're taking a nanosecond out to reflect and review, let’s explore the facts and fictions.

Rapid assumptions - Quick to judge?

So what are our common assumptions about rapid e-learning? We often understand rapid to mean:

• Fast
• Cheap
• Lower quality
• Anyone can do it

Of course, time, cost and quality are the golden triangle of project management – fiddling with one will usually unbalance the others. Let's look at these assumptions in a bit more detail.

Fast? More haste, less speed?

What do we mean by fast? These days, we're talking weeks, rather than months. It's not uncommon for projects to have a 30 day turnaround, from initial kick-off meeting to the course hitting the user's screen.

But does rapid have to be fast? Surely fast is the one thing that rapid has to be. It's a tautology, but otherwise, what's the point? But as always there’s scope for tripping yourself up if you try to run before you can walk.

We know that rapid tools can cut building time, but building time is just one part of the overall process - and fine-tuning that whole process is key to going rapid. Wildly hacking great chunks out of a schedule just to hit the desired end date is always going to end in tears - didn't our mothers always tell us 'more haste, less speed'?

Skipping early reviews or rushing sign-offs can often just be more time consuming in the long term, so you end up overrunning or adding extra iterations at the very last minute. But on the other hand, making canny decisions about what’s necessary and what’s indulgence can whittle down a schedule. As Virginia Barder points out, “Rapid is about common sense. Do you really need each stakeholder to review the script six times?”

But what if we don't need the project to be fast? We can still use rapid tools to speed up building the course, and spend that time concentrating on getting the script and graphics right first time. And, conversely, if the timeframe is very short, then even using rapid tools might not necessarily cut costs if the product still needs to be very high quality. Which leads us neatly to…

Cheap? You get what you pay for?

What's cheap? Cutting unnecessary process and development time can definitely cut costs. These days, the common assumption is that the hourly cost for rapid can be half of what a standard bespoke e-learning project usually costs.

And does rapid deliver on that promise? If your well-planned rapid project involves less work then it's obviously going to be cheaper! Steve Rayson of Kineo pointed out on clive-shepherd.blogspot.com a couple of years ago that there was a growing recognition that "much of the cost of e-learning historically was inefficient processes".

However, as with the issue of speed, we're only heading for a happy ending cost-wise if the preparation and groundwork has been done up front. If a rushed job hits the buffers near the delivery date the fix-up work can end up costing more for everyone involved.

If we stick with the definition of rapid as something that's simply fast, then that's not necessarily cheaper. A big scope project, or a course that needs to be a dazzling head turner, can still be produced in a short time, but is unlikely to be cheap as chips.

Low quality? Fit for purpose?

What do we mean by low quality? Usually in terms of e-learning, low quality means that the instructional design hasn't been thought through, the target audience has been missed or misunderstood, the script or graphics stink - or maybe it just doesn't run properly.

So does rapid have to be low quality? The critics might call it 'vapid' e-learning, but that doesn’t have to be the case. Anyone who's eaten hot fish and chips on a winter beach, or spent a summer's afternoon lazing in the park, knows that some of the best things in life are simple and cheap. And let's face it, we've all seen higher-cost e-learning that simply didn't hit the spot. So rapid doesn’t have to be low quality, but is it more likely to underwhelm?

The obvious point here is that speed and cost are more often drivers than quality, so quality is usually nearest the door, to be elbowed out at the first point of compromise. And if ‘fit for purpose’ is the working motto for your project, then that doesn’t have to be a problem, if managed right.

Some people point to the templated nature of rapid as a limitation, but if those templates are solid interactions used well that doesn’t have to be a bad thing. Articulate, for example, has a set of interactions that aren’t jaw-dropping in their innovation or flair, but they are solid and effective. And as Articulate works hand-in-hand with PowerPoint you also have access to all the possible freestyling customisations of a PowerPoint slide. So there’s no excuse….

There is often an assumption that rapid means one person creates the e-learning alone (which we’ll come to in more detail shortly) – which leads to this sense of ‘jack of all trades, master of none’. And this can add to concerns about low quality. Lars Hyland, Brightwave’s Director of Learning Services, says, “There is another consideration too - which is the writing quality itself, and the meaning and intent of images used. These in themselves can require huge skill to craft and sequence. So while something can be functionally simple and quick to build with a rapid tool, it may actually be a time-consuming/expensive process to assemble and design the content so that it is a genuinely powerful learning experience. There is a real danger that rapid projects generate content of little value. If this is case, then rapid ends up being hugely expensive."

Let’s look at this in more detail….

Anyone can do it? Power to the people?

First of all, what do we mean by anyone? The idea is that any e-learning professional and anyone in a business or organisation can create and build their own e-learning, without any specialist advice or help.

Can this be true? Rapid tools have been revolutionary in making accessible what was previously a fairly specialised technical arena, and this is a fantastically democratising move, freeing individuals, SMEs in particular, to have greater control over the final product – for better or worse.

Not everyone has the right skills set to use rapid tools. The expert knowledge of a great SME, or the creativity that makes a great graphic artist, designer or scriptwriter doesn’t always go hand-in-hand with the rigour and attention to detail needed for building with any kind of tool, or even the relatively low level technical skills needed to use rapid tools. Following from this, if a user has the skill set across that range, it is (let’s face it) unlikely to be at a very high level across the whole range: good enough writing, graphic and technical skills usually lead to a good enough product – so, as we saw before, quality is the first value to be shuffled towards the door.

Hyland goes into more detail, “There is an increased interest in self-authoring of e-learning content due to the perceived benefits of reduced costs and speed of production. However, the skills required to deliver an effective and engaging online learning experience are hard won and not easily acquired. There are further skills to acquire when using a self-authoring tool, such as when and where to apply interactivity, choice of supporting imagery, use of audio and video assets, technical environment and tracking requirements. All of which contribute to the quality of the end learner experience.”

Many people argue that this democratisation is to the detriment of product quality and of the progress of the e-learning field overall. At the Oxford Union E-learning debate 2009, which debated ‘This house believes that the e-learning of today is essential for the important skills of tomorrow’, Dr Marc Rosenberg argued that e-learning is rocket science, and that rapid tools and processes serve to de-professionalise the field (http://clive-shepherd.blogspot.com/2009/09/e-learning-debate-2009.html).

While rapid tools do open up the field to allcomers and there are obvious risks to this in terms of quality, if we see rapid as more about the process than the tools, then it can only be a good thing. A finely tuned rapid process that is merely one part of a successful and smooth-running relationship between creator and customer (or internal customer) is about as professional as it gets.

Conclusion

It’s impossible to separate completely the issue of tools from process in rapid e-learning. But an effective tool is no more and no less than that, and the methods and processes around using that tool are what makes the critical difference in the successful creation of rapid and effective e-learning. Streamlining processes can certainly cut costs and timeframes, with no detriment to the quality, if those processes are well planned or tried and tested.

Top tips:

Tailor your rapid process to your project, your team and your (internal) client

• Or use a tried and tested rapid process
• Look around for a tool that fits your needs best
• Make it fit for purpose – if you need high quality, use the best resources available
• Use common sense – cut out indulgences in your schedule

Read more articles in the news archive

Call us on 01273 827676 or email us at enquiries@brightwave.co.uk to find out more about our corporate learning solutions and how we can help your business.



Visit our brightideas page for some inspiration. Browse through articles, watch videos and play back webinars at the click of a button.