E-learning developers: abandon your industrial methods
I’m increasingly convinced that the roles involved in producing e-learning are changing. This change is being driven by rapid tools, by cost pressure, but also by a widespread sense that e-learning still isn’t really delivering on its now (decade-long) over-promising.
Most e-learning production companies appear to have settled into organizing themselves in ways that resemble 19th or 20th century industrial production. Learning (instructional) designers write words, graphic artists do the visuals, technical developers build final products, project managers…er…well in theory they’re supposed to tie it all together, (although I do often wonder what value they would be adding if most of the time if the rest of the team would just take responsibility…but enough of that). Roles are clearly separate and do not overlap, (somewhat like a Subway outlet during busy periods).
The evidence from other design and software industries suggests that this isn’t necessarily the best arrangement. In many cases such an industrial, Taylorian approach leads to miscommunication, disassociation from client and user needs and, somewhat ironically, higher cost. People in such teams are swapped in and out, like cogs in a machine, each seeing only a small part of the process and often never really understanding what they’re contributing to. It’s the kind of teamwork that management writers in the 90s mocked mercilessly (look at anything by Rosabeth Kanter on this).
An alternative approach, and one that’s increasingly being shown to offer clients better value, is to establish smaller, stable teams in which more highly trained people overlap their roles. Overlapping is the critical characteristic. So the learning designer is also an IA (information architecture) expert, who understands graphical interfaces; the graphics person produces a technical working prototype that can evolve into the final product without needing a technical builder; the technical person, if they’re required at all, edits the copy…and so on. Each transgresses substantially onto the territory of the other. Such teams are more responsive, more capable of delivering what the client needs, and more able to manage themselves.
At the heart of the team is what I’d call an “e-learning producer”, a role that should evolve from our current learning (instructional) designer role. This person designs the learning experience, manages the project and plays a key part in actually building the final product; they have technical build skills. Learning designers are doing this increasingly anyway, using rapid authoring tools. This is going to become more and more productive as such tools increase in sophistication.
There is an increasing number of small e-learning companies, and in-house facilities building themselves around this kind of person, and I’m going to be monitoring their progress carefully. What our e-learning producer now needs is a flexible, sophisticated design and build tool, which I'll write about elsewhere. Neither the current generation of rapid tools, nor higher-end tools such as Flash, are quite right for this role.



Reader Comments