The point of this post is simple -- software training cannot be successful until users have the live system in front of them with a goal in mind they want the software to help achieve.
TL;DR: Up front training is not successful for logical reasons. Use up front sessions to create user buy-in instead of training. Parallel testing is often the ideal time to train users.
I am not an expert when it comes to the fine details of software training. How best to conduct the sessions and how to present the content are things I respect but have little practical expertise in. I am, however, a witness to a great many people who learn how to use new software systems and I am (painfully) aware of the kinds of problems they have.
I am not naive about the difficulty of setting up the "software in front of your users with goal in mind" scenario but in most software deployments there is one convenient moment that puts your users in a position to succeed -- during parallel testing. A parallel test is no small task but it is the perfect opportunity for this scenario to exist for a wide range of users. Piggy backing on the parallel test for training is superior in efficiency of dollar spent per unit of user skill gained to traditional up-front user training because of the psychological engagement only real use cases can invoke. I strongly recommend parallel testing for any system roll-out for many other good reasons but utilizing the optimal training moment is one of the best side effects.
Psychologically, when users have "skin in the game" they can learn. And to be painfully realistic, very few are capable of learning before that point. We are busy, we have deadlines looming, we simply cannot pay attention to a system training for a system we will not touch for another 2 weeks and we've never seen before!
So I am recommending the abolishment of traditional up-front user training sessions? No. What I am recommending is a shifting of the goal of that up front meeting (and hopefully reducing its duration and expectations). It can provide enough of a primer that the users think the system will be easy to use. Show high level things it can do. Describe in glorious detail how it will make their life easier. Set up scenarios and make the software sing. Its almost a full sales demo, but with the system's future users instead of its purchasers. Get them excited about it. That first training session is more about "buy-in" and emotional connection to the new reality. Make them want it by selling the system. That is about as good as you can hope for. This is a huge difference from the usual top-down approach that has a tendency to demoralize future users and encourage animosity towards support staff (notice how support teams are seperated from the trainers? Why are these are different teams? Support is very often "just in time" training!) negative feedback that finds its way back to the stakeholders as complaints about the "complexity of the system". That rationally stubborn user behaviour can be curbed by acknowledging the very human need for buy in in a sales-like kick off meeting. Of course there are limits to the success of this initiative and after that buy in meeting there may still be resistors, but at least you've identified them (or perhaps the solution doesnt solve their problems and thats a whole 'nother issue :)).
No comments:
Post a Comment