More Powerful, Not Necessarily Faster
If the promise of faster e-learning has never quite matched your lived experience, this is for you…
A few days ago, while tidying up some folders on my computer, I came across a PDF document called E-learning Development Time Stats. From memory, I couldn’t place it, so curiosity drove me to open it and take a look.
Dated 2010, it was something I hadn’t looked at in a very long time.
The document was produced by an organisation called Chapman Alliance. Honestly, I’m not sure if they are still going; but after a bit of Googling and asking questions of ChatGPT, I realised that at the time, this had been quite a widely shared and referenced document in relation to development times for different types of learning content.
If you’ve been in L&D a while, you might have seen this very document or heard someone quoting from it at some point.
The 184 hours headline
The development time numbers vary by type of output and complexity, but the figure that grabbed headlines in 2010 is this. Based on research surveying a large number of organisations, the document concluded that it takes roughly 184 hours of development time for every one hour of finished e-learning, at the higher end of complexity.
Also, it is important to point out that figure assumed full team effort (ID, SME, media, QA, PM etc.), not just authoring time — something we shouldn’t forget when comparing with today.
Re-reading this made me think: “Are these e-learning numbers anywhere near valid, 16 years later?” After all, in 2010 we were really still on the cusp of some big tech changes in terms of authoring tool capability and media production. And, if you add in the relatively recent arrival of AI, what must those numbers look like today?
Now, seemingly, there is no single modern equivalent study with the same scale and methodological clarity. More up-to-date data comes from things like:
ATD industry surveys
eLearning Guild research
vendor benchmarking
consultancy datasets
practitioner aggregation studies
The comparative updated headline figure that all of this data points to is somewhere between 80 to 150 hours to create one hour of finished e-learning, at the higher end of complexity. And it’s interesting to note that at the high end of that range, 150 hours, the total number of hours is not that far from the 184 hours in 2010.
On the face of it, both the 2010 and present-day numbers feel high. However, when you start expressing the amount of time in days rather than hours, they suddenly don’t seem that outlandish.
Which prompted me to look back at some projects I have worked on over the last couple of years. To my surprise, they came close to the top end of that 80 – 150 hours range.
The computing power principle
Why was that a surprise? Well, I think like most people, I’d just assumed that all the new tech we’ve been bombarded with over the last 16 years must have speeded things up dramatically. Yet the numbers tell a different story.
Of course, all that new tech arrived gradually over a quite a few years. It was never a ‘big bang’ moment. That could partly account for us not noticing there had only been a minor reduction in overall development time.
The other explanation could be that the equivalent of the ‘computing power principle’ (my made-up name for the phenomenon I’m about to describe) has also happened with e-learning development time.
The ‘computing power principle’ is about the overall price of computing hardware not changing that much over quite a long period of time; which means that each new iteration of said computer hardware buys significant increases in raw computing power and overall OS and application capability and functionality for roughly the same amount of money. In other words, the cost never really drops; but what that cost buys you is always increasing and improving.
I suspect the same thing has happened with e-learning. The number of hours required to create an hour of e-learning hasn’t changed that much; but the potential for what can be produced, in terms of sophistication and functionality within that timeframe has.
And that, I think, highlights a couple of other interesting (and possibly surprising) points.
The first point is how e-learning development hours are allocated. In bigger organisations with:
more stakeholders
larger numbers of learners, and
a lower tolerance for risk
there will undoubtedly be a lot of time allocated to analysis, design and review. But regardless of project size, I think it’s most likely that production time will still account for the largest single chunk of time within the project.
More sophistication, same labour
Which brings me to the second point.
All that new tech that’s arrived over the last 16 years has dramatically increased the potential sophistication of what you can achieve as a lone user of a tool. But what it hasn’t really done is reduce the manual point and click labour required to bring that sophistication to life.
What do I mean by this?
Well, let’s take Storyline as an example. The basic steps that you need to take within Storyline to produce a piece of e-learning have not changed dramatically since it’s release. There have, undoubtedly, been some very targeted improvements to certain aspects of the interface and the flow of the point and click within that interface.
The triggers panel is a good example of this. The small incremental improvements that have happened over a quite a long period of time have made the experience of creating and managing triggers much more elegant and easier to understand; but I’m doubtful it’s made a significant difference to the time it takes to create the triggers within a given project.
What the improved flow might have done is encouraged people who previously avoided using anything other than basic triggers (because they seemed too hard) to start using more sophisticated triggers. Guess what? More sophistication but slightly increased or very similar point and click time. Almost certainly not a reduction.
“But what about AI?” I hear you cry. Well, that is certainly speeding up some aspects of the design phase of the process. Content production or editing; defining objectives; outlining courses or modules; ideas for practice activities.
All vital stuff. But shaving time of all of these aspects of the design phase still doesn’t impact the time required for the production/development phase; or the human-intensive review and governance aspects of a project that exist in bigger organisations.
Now, do I think it’s almost inevitable that the day will come when AI can speed up the actual point and click of production? Absolutely; but we are certainly not there yet.
Two thoughts to conclude…
So, stepping back a little bit from all this, a couple of things strike me.
First, we have all felt the impatience of the non-L&D person over the time it takes to produce a piece of e-learning. If you are looking in from the outside, I think it is hard to understand how time-consuming the process can be. And, of course, this is not helped by the ‘we make it quick and easy’ narrative pushed by so many tool vendors.
Second, this external impatience can lead us to beat ourselves up unnecessarily. To feel that we are somehow not very efficient and that we are lagging behind the rest of the world in our use of technology. And this is understandable. ‘Surely the tech must be speeding things up’ thinking is all around us. And, of course, in some cases, it does. But as an e-learning context highlights, not across the board.
My hope is that this mini-exploration of development times past and present will be re-assuring. For me, it underlines the fact that creating a piece of e-learning to a high standard of interactivity is a relatively time-consuming process.
Even with all the amazing tech we have at our fingertips, producing genuinely interactive, well-crafted e-learning still requires a significant amount of manual skill and labour.
And if you look outside the world of L&D to other creative industries there is, I think, a much better understanding of this fact.
Anyway, that’s it for this week. To wrap it up, I’d love to hear your thoughts and experiences with any of this.
Until next time,
Andrew