Knee-jerk to elearning

When a (now-not-so) new technology enters the smorgasbord of training options, industry training organisations may be tempted to jump in with both feet on the accelerator. This has been especially so with the advent of elearning. Everybody’s doing it so why not us? Anyone from within the organisation who suggests a cautious approach may be seen to be dragging on the vehicle bumper for reasons of their own discomfort at the speed of change.

Elearning is not a good idea unless it fits with the organisation’s technical capability and workforce readiness. While most of my work has some component of elearning, and I do believe the method adds amazing capacity to move learners forward, I, too, would like organisations I work with to be a bit more cautious before writing their Expression of Interest documents.

Elearning developers love to create, but they also want what they create to meet the needs of the learners in the organisation. Unless the project succeeds, the risk for the developer is that the tools they create will be seen as having failed, and that in turn will damage the developer’s reputation. Often it is not the tools but the process that is flawed.

My observation is that organizations follow a pattern of:

idea > resistance > wearing down > agreement > write the EoI > start the project asap

The promoters of the project are so intent on getting on with it, (seeing that so much time has been ‘lost’ in convincing the organisation to move) they fail to do enough research to develop an effective, measurable EoI, which is the only document a developer can respond to when designing a proposal.

The EoI can be based on assumptions about the needs of the learner, as well as unrealistic budgets and time lines for development. Developers have these options:

• To warn that the project is unrealistic and can’t be done in the timeline – good-bye contract
• To build in a number of ‘provided that’ clauses to cover potential timeline blowouts
• To answer the EoI as it stands and limit the potential of what they can provide within the timeline or budget

And guess which developer will get the contract?

Before any elearning project starts the organisation should:

1. Get some reliable research done on the needs and capability of the learners they serve, and not just rely on gut-instinct. Managers see the world through the technological eyes of their own use of computers – ‘everybody knows how to use a computer’. Well they don’t! They may be more adept at using a mobile phone or the DVD remote.
2. Really understand learners’ access issues to technology. The parents may have a computer installed at home, but what happens to accessibility when the young person moves out to their first flat? Can they afford to link up to Broadband or will they install Sky Sports? If they are into social networking online, do they really want their tutor/trainer muscling in for all their friends to see? And can they afford the cost of mobile communication when for days on end they don’t reply to txts because their credit’s run out before payday?
3. Decide whether it would be wiser to contract an independent researcher to investigate these issues before engaging a developer; or make the developer responsible for developing a learner profile and recommending a best practice solution.

It is in the best interests of the organisation, the learners and the developer to design the most effective learning solution, and that solution may NOT be elearning.