The Bits and Pieces X: Training in Practice


There are many ways to train people to use complicated new software. You could sit down with each new user individually and show them what to do. Because you have 300 people on staff full-time to do that. The training might be a live demo of some of the processes, or one of those movies. It could be a series of online modules that take the user through various steps of various workflows. There might be a quiz at the end. Everybody likes quizzes.

We chose a variety of training approaches. This is a nice way of saying we didn’t really have a coordinated training approach. Our training started out with the best of intentions, of course. Unfortunately, our system was pressed into service before it was really finished, so the training program was REALLY not really finished.

Our first attempts at training involved the time-honored “live demo in front of a group of people” technique. I wonder if there’s anything more useless. Imagine a group of 20 people who don’t really know what’s going on, in a darkened room, staring at a projection of a completely foreign UI, listening to some dork (me) droning on about “tagging” and “attributes” and whatnot. For an hour. And at the end, being told to go back to their desks, and the software would be installed within the next couple weeks, and there are no handouts or manuals, but when you get the software, start using it all day as this is now your new way of working. We didn’t even offer snacks.

So that having predictably failed to impart all the vital skills they needed, the next step was to sit down with them individually or in very small groups and, with one of the users driving, talk them through the tasks they needed to do. “Click on the File menu . . . no, the Documentum file menu, not the Netscape file menu . . . good!” This actually worked pretty well. The only downside is the “trainer” has to spend all day doing it. And the trainer is never really “the trainer”, they’re more like the project manager who’s dropping everything to train people as they have questions.

To try to organize the random training and ensure that everybody in the group was getting the same information, we decided to hold weekly meetings to go over any questions that came up. Emergencies would still be handled as they occured (an emergency being an “I can’t do any work until you explain to me how to do this” situation). Unfortunately, or maybe inevitably, no questions ever came up in these meetings. I’m not kidding. “So how’s everything going?” “Fine.” Then an hour later 15 phone calls come in asking for individual help.

Then there’s the problem of “rogue training.” There’s always somebody who kind of gets it, assumes they totally get it, then trains their colleagues on their own. It is, after all, easier to ask the person sitting next to you than calling the person who caused all this pain and inconvenience in the first place. This caused no end of issues for everyone involved. Someone determined a simple 35-step procedure for creating a page and printing it out for further editing. The problem: the same thing could be accomplished in 3 steps, which had of course been covered in the original dark-room demo, but everybody forgot about that. And even better, the page didn’t really need to be printed out every time as it was after all a PDF file which could be viewed onscreen. But that rogue trainer had shown everyone their technique, everybody started doing it, and hours upon hours were wasted waiting for pages to process and print. And even after we discovered this and showed everyone the “right” way, many people still did it the “old” way because that’s what they were comfortable with.

(We also had someone come up with “rogue documentation” which was presented to me at a project postmortem. “Look at how complicated it is to use this!” “Where did you get this documentation?” “I wrote it up myself because this is so hard I needed a cheat sheet.” “I understand your frustration. I wish you would have talked to me during the project because most of this could have been done differently which would have made it easier.” ” . . . “)

When it finally became obvious that our ad hoc training program wasn’t going to cut it, we assigned someone to be a trainier and come up with a hands-on training program. And it wasn’t me. That was one of the happiest days of my career. It was one of the users, who knew what the users were going through, and spoke their language, and had credibility within their ranks. O joy! I just peeked in on the first couple sessions to make sure they weren’t talking crazy talk. And they weren’t. And everything went pretty smoothly from then on. Imagine that.

Advertisements

5 Responses

  1. Every software trainer should read this. If only to understand that you must offer snacks! šŸ˜‰ Seriously, this is great. Your suffering was not in vain. I’m reTweeting this so people don’t only think it only applies XML.

  2. As a software trainer myself, we always have a full plate of snacks and drinks ready for our students. There is even beer in the fridge if that helps.

  3. Deputizing someone who knows exactly how this software is used on a project is a stroke of genius. You used the “rogue training” element that is endemic to the process of learning any new software to your advantage. And if the “user trainer” can’t manage to get handouts done, then maybe a savvy “assistant’ to the user trainer could do that part of it, so no one is overburdened.

    GREAT article.

  4. One thing that bothers me the most is the “no manuals” part of the way software is distributed these days. A manual for anyone who wants one is absolutely essential in my opinion. It ends up paying for itself because there will usually be one brilliant user who figures out a “trick” that doesn’t occur to anyone else to get rid of about twenty steps in the process of doing something, and then everyone benefits. So argue for the money to buy those manuals!–at least for a select few.

  5. reTweeting? Is that even legal?

    I think beer should be in every fridge in every office in the land. Why isn’t it? I’m all growed up and know I can’t drink 6 beers and still expect to get work done. Most of the time.

    In our new configuration, we actually have a whole training department. I’m not sure how this will work though, since the trainers’ job is training and not doing anything that they’re training the staff to do. So they probably won’t know any brilliant shortcuts since they’re working on training materials and their presentations and not actually using any of the software in a real work situation. So even my ideal training utopia might not be that great. Maybe the user/trainer is the way to go. I’ll post more as we find out what’s working and what’s not.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: