Wednesday, January 10, 2007

The big question for January: speed v quality

Tony Karrer has persuaded me that I have input to make on this month's Big Question, namely:

What are the trade offs between quality learning programs and rapid e-learning and how do you decide?
I thought I would duck it, since I have thus far not had any exposure to rapid e-learning per se, but Tony felt differently. He said:
"Karyn - the question is not as much about "Rapid eLearning" as it is about speed vs. quality. And I'm psychic, so I know you face that issue on almost every project you do. :)"
And, in a way, he is right, of course. I have been in this field in its various guises for 20 years now and although my involvement with e-learning only goes back two years or so, the challenge of quality v speed has been ever present. If I were to be flippant, I would probably say: quality every time.

Like anyone (I presume), I prefer to be given enough time and budget to produce a learning resource that will do the job, while looking good. Impress the learner while meeting his needs, why not? Of course, it's easy to say that when time is short we focus on functionality and forget form, and this is what the client usually suggests when proposing a gasp-inducing timeframe. The sad reality is that functionality takes wa-ay longer than form to produce. And I speak as one for whom form is important.

The bitter pill is that, when the schedule (or the budget for that matter) is tight, scoping has to be very tight and some things just ain't gonna happen! There is a serious risk of cutting corners in the analysis and scoping phase of the project, but I suggest that this is false economy. When I'm under time pressure I am even more in need of a tight scope in order to produce an effective resource within the limits placed upon me.

Even when the schedule is tight, the end product must WORK. It must deliver the goods, or it has been time (and therefore money) wasted.

One of the biggest frustrations when there are tight schedules is access to SMEs and stakeholders. Since they have different priorities (usually the day job), they can sometimes take their sweet time getting back to me! It is very important to have a good rapport with these folks.

So I would suggest that the following factors are required:
  • A diligent, somewhat ruthless analysis
  • A tight scope - signed off in blood, for preference ;-)
  • A resourceful, comprehensive design that will enable a quick build...
  • The tools to achieve a quick build (products like exe or Etomite are good for elearning materials)
  • Fast turnaround times on edits and amends
  • Easy access to and excellent rapport with SMEs (no "us and them)
  • QA that focuses first on functionality and then on form
  • A team that cares about the learner
  • A team that is prepared to send out for pizza and get the job done
  • A mutually accepted and respected process of change requests
In summary, I guess that while I grudgingly accept that some measure of quality will be lost when tight schedules are in place, some damage control is possible. At the end of the day it's about the user, though - intuitive access/navigation is non-negotiable, and the product must deliver the goods. If this is not possible within the constraints, I guess we need to qualify out of the running for the job. I recognise that internal providers don't have the luxury of this option, so perhaps some assertiveness training wouldn't go amiss - learning to say no without losing your job!

There's probably a lot more I should have mentioned and I'm quite likely to have omitted points that are so vital and integral as to be invisible...


Dave Lee said...

The comments on this post are being tracked and aggregated as part of Learning Circuits Blog's The Big Question for January. Thanks for participating, Karyn!

Wendy said...

I like your recommendations for attempting to maintain quality while working under deadlines.

The concept of "team" is most important. I have found during my disaster project that the 4 people who are making up the training "team" are able to come up with insights that can help mitigate some of the issues involved when trying to build any training fast.

The thing to watch out for....TOO MANY MEETINGS.

Sometimes it's easier to talk about things than to do them.....

Anonymous said...

Good point, Wendy. I think meeting-itis is a common procrastination tool! I think it's important to empower people to "get on with it". Within my (admittedly limited) experience, this is not something that features large in the British corporate ethos. As a consequence, people who come here from more autonomous cultures have a tendency to be labelled "aggressive" - yours truly among them!