An alternative method for developing system training e-learning modules
Simon Humby is an eLearning designer and an expert in his field. Simon shared with Enterprise Study an alternative method, with greater success than the norm, for developing elearning for IT and system projects.
Working on so many eLearning projects over the years has led me to develop a workflow for developing System Training e-Learning that ensures better project management and swifter production.
It’s probably not original but I personally have not been on any project where they had decided on this method before I joined and suggested it to them. With all due humility I’m going to call it the Humby/Pen System-training Development Method B. (HPSDMB!). I’m Simon Humby and Pen Roberts was the co-discoverer.
It struck us that there are certain issues that arise during the development of system training eLearning that delay production. Some seem inevitable in an imperfect world but there is one big roadblock that we can do something about: Developers do not need to and should not become subject matter experts.
A typical story. I arrive on a contract. After meeting and greeting I then frantically make notes while a SME or trainer does their stuff. I’m given access to the Lesson Plans and Standard Operating Procedures. I’m told that if I have any questions to just ask so and so.
Great! Lots of information and information is a good thing isn’t it? Perhaps not.
After a few days of working with the software and asking questions I might be ready to start recording but my knowledge is still limited. Misunderstandings, re-recordings and delays are almost inevitable.
Next time you are developing eLearning suggest this process instead:
The Humby/Penn System Training Development Method B
- The SME/trainer and the developer sitting down side-by-side – they work together.
- The developer explains the simple but important ground rules as to how recording works.
- The SME/trainer – runs through the script on the computer while the developer uses the e-learning software (perhaps Captivate) to record the actions of the SME/trainer on the target software.
The developer doesn’t need to spend any time learning about the target system software. In fact, under certain circumstances, they could start the recording on day one of the contract.
They don’t risk making bad recordings based on incomplete or misunderstanding of the system.
This method cuts out the ‘middle-man’ as regards information flow.
Which really sums it up – but be warned that there are other considerations and detailed techniques required to make this a practical workflow in the real world. One of which is that the SME/Trainer must be the top person in the role. The lead trainer or lead SME and preferably the one who wrote the scripts for the training.
Accept no substitutes. It should NOT be just ‘whoever is available at the time’. The quality of the e-learning created by this method is directly related to the quality of SME. Having to fix it later is exactly what this method is trying to avoid.
I will go into more details about this and the other important issues that need to be considered in the next article.
I might even tell you why I’ve called it Method B and not Method A.
Connect with Simon on Linkedin