Monday, January 22, 2007

Speed vs. Quality - Still Relevant?

January’s “Big Question” at the Learning Circuits Blog is:

What are the trade offs between quality learning programs and rapid e-learning and how do you decide?

My knee-jerk reaction is that the question makes an unspoken assumption that quality and speed are diametrically opposed – that “rapid” should be equated with “low quality”. Although that certainly may be the conventional wisdom position, I’m not sure it holds water under closer inspection.

It’s similar to asking about the trade-offs between ‘fast’ food and a ‘good’ food. Upon initial inspection, there’s a shared tacit agreement that a drive-through dinner from your local burger franchise won’t (can’t) hold a candle to the quality that would come from a multi-course meal from your favorite fancy sit-down restaurant.

But if you think more deeply about it for a moment, you may discover that (just as with most things) the “trade-offs” are intimately tied to objectives – or more simply put, “it depends”.

If you are in the midst of running a marathon, “good” and “fast” eating are defined quite differently than if you are having an anniversary dinner with your spouse. It’s only when you fully understand the needs and expectations of parties involved in a situation are you able to properly assess what (if any) trade-offs must be made to effectively/properly serve their objectives.

In the case of (e)Learning, the argument stands, as well. It’s generally accepted (in theory, at least) that one solution rarely addresses the needs of more than a few – that what is ‘fast’ and ‘good’ to one person/group isn’t the same as for another. The "value" of a solution is highly dependent upon the needs of target.

Consider, for example, the case of Google and how their primary service has been so deeply adopted into the fabric of society that their company name has morphed into a generic verb meaning “to search”. One of the more dramatic results of the service Google provides is that information on any topic at (nearly) anytime is available to anyone, all with a microsecond response time (rapid). Granted, there’s no guarantees to the quality of the information Google supplies in response to a query, but (and here’s the interesting part) that lack of guarantee also doesn’t preclude quality – it actually says nothing about it at all!

So, we are witnessing an interesting swing away from the monolithic course model, to a JIT search-browse-synthesize-apply model. In this world, ‘rapid’ and ‘quality’ can (and often do) comfortably co-exist. There’s no reason that a similar, albeit more constrained, replica of this model cannot be adopted and leveraged within individual organizations, as well. Instead of leaving the determination of ‘quality’ up to the seeker to discern (as is largely the current case when broadly searching with Google, despite the confidence their ranking algorithms is supposed to proffer), a company could create and offer a multitude of high-quality but quickly accessible & consumable ‘learning bites” on the most frequent/timely/damaging/profitable topics of interest. By aiming for succinct responses to the most leveragable “20” of the 80/20 Pareto Principle of business/sales/performance themes, it would be possible to serve the double-masters of Speed and Quality without any contradiction.

It’s important to note that one element will take precedence over the other in many cases – when the validity and comprehensiveness of information trumps the amount of time necessary to locate and understand it, or when something that half-right today is infinitely more valuable than something that is completely right tomorrow. Again, it all comes down to understanding the underlying objectives of your audience and adjusting your ‘S vs. Q’ knob accordingly.

(My response, obviously, is taking a consumption-oriented interpretation on the BQ. If one was to read the BQ to relate to production, I may have a slightly different stance in answering.

But then again, maybe not… :-) )

1 comment:

  1. Hi,

    I enjoyed reading your response to the big question, especially about understanding the underlying objectives and adjusting the "S" and "Q" knobs. Very often programs are of poor quality not because of the time spent on creation, but because the underlying objective was poorly defined.