I am looking for advice to impart to IT Trainers who are delivering short sessions on an unfinished system. They know the system is incomplete and is still being 'built' and have issues regarding their own confidence in delivery. Any ideas?
Martin Edwardes
5 Responses
Honesty and focus on learning objectives
I suppose the first question is why train someone on something that isn’t complete yet – aren’t you just going to have to re-train? But assuming you’ve already asked that question and you still have to do the training, I’d suggest (in no particular order):
Be honest and open to participants (but do NOT whinge or complain about it!) and have a discussion about the value/need to do the training now rather than later. Get someone more senior to do this if more appropriate.
Facilitate a brainstorming discussion with participants about their concerns. Acknowledge them and explain what the trainer or others are doing to overcome them where possible. (e.g. ‘the handbook we send you in 6 weeks time will cover this)
When an issue comes up in the training – link back to the ‘concerns’ list.
Focus on learning objectives, and don’t be distracted by things that don’t work which are not directly linked to them. Visually ‘Park’ or ‘ice-box’ issues and questions on a flipchart for follow up after the course.
I’ve had a similar experience – I had to train on a system that I had only just learnt – I was very honest that I could only train them on the course content and didn’t know anything outside that. It was either me training them or no training. It worked well and they were very supportive.
Another Suggestion
I’ve had to deliver quite a few training sessions whilst the system was in the latter stages of development. On a recent occasion the system was finished 1 hour before the training and I hadn’t seen it all working!
To overcome the embarrassment of pressing a button and nothing happen, I set the expectation level right at the beginning of the session. I am lucky in that I can say it’s both a training session and a development/snagging session.
I also agree that complaining about it in front of the delegates is not at all useful, but an explanation as to why it is necessary to have the training whilst the system is not 100% completed. However, I’ve found that our delegates are quite excited to find a button that they press and nothing happens, and I normally leave the day with a flip chart full of ideas and issues to pass back to our IT department. The delegates leave the day feeling that not only can they use the system but their ideas are valued – as we do get lots of great ideas that as a development team we may have over looked!
Honesty and users prvious expreience
I agrre with the previous contributors that honesty (without whingeing) is vital, as is taking users concerns seriously and feeding them back into the project. Another suggestion is to focus on how the new software will benefit the users once it has finished. Also you could ask the delegates for examples of previous “unfinished” system training and ask them how the system is now performing. In my experience their replies will be positive allowing you to make the point that things may not be prefect now, but the system will do it’s job when sent live.
Confidence in subject matter
I’ve been in this position too! Luckily I was involved with the configuration of the system – is it possible to let your IT trainers have some exposure to the ‘building’ of the system?
When they know what is happening and why, they’re more inclined to ‘buy in’ – this should help overcome their lack of confidence in training delivery.
Other points worth making: do they know the system that is being replaced and are they writing their own manuals? (I’ve found this to be a great help!)
Try to avoid getting into the position in future
Hi, I did a lot of this sort of work in the past, and frankly it’s an impossible position (great ground to cut your teeth on as a trainer though!). In my experience the key to this was to learn the lessons for the future and build in the training into the IT project itself. The training of the system (i.e. getting people to use it as intended) was too often the last thing that the IT project manager(s) were interested in (not sure why). This sounds simple in principle, but in practice it means getting in on the project as early as possible, influencing the decisions of key stakeholders, and ultimately being firm about the importance of training in the success of the project and realistic in how long it will take. It was tough to do, but the only way to improve this incredibly tough situation to find yourself in