But what does it DO?

December 20, 2007 12:29 PM

Corporate trainers, I need your help. I need to train some colleagues on the capabilities of an software package to prepare them for designing some upgraded features. However, they are not users of the software, so my standard new-user training is not going to cut it. Do you have any tips on how to do this kind of training/education? Any suggestions of training books or websites that can help?

In my job, I am a business analyst in support of an internally-developed software package. We use this software for a very specialized type of data entry and it has a steep learning curve as a result. My new project is to develop some new features to handle upcoming EU regulatory changes. Therefore, my European colleagues are heavily involved in the design of these new features, but progress is hampered by the fact that they don't really understand how the current software works. Management is asking me to put together some training so that the European members can gain a better understanding of the package, but I'm lost on how to accomplish it. They don't need the new user step-by-step training, but they need more than the 2-hour overview that I usually give to executives. I'm looking for some way to structure the training so that it's informative and explains what the software can do without getting into the nitty-gritty of "now click OK to close the window".

posted by cabingirl to work & money (4 comments total)

It sounds as if the software is challenging enough as it is, and these necessary new features may push some of your users over the brink. Even before you show your colleagues how the software works, I'd advise that you answer these questions.

1) Who are your users? How tech savvy are they? Would they be comfortable with any efficient innovations to the interface, or should you avoid confounding their expectations of how the software works?
2) How do your users work with the software? Do you have a library of scenarios you can demonstrate to your colleagues?
3) How do your users typically run into trouble with the current version of the software? If you have a support desk that they contact, what do their logs and internal reports suggest are current weak spots?

As for the training session itself, I think there will have to be at least some detailed hands-on work at some point. How hands-on is the executive training? How detailed is it? Could you expand it to include the background information on the users and how well they are managing the current implementation, then add the scenarios and a chance to work directly with the software?
posted by maudlin at 1:01 PM on December 20, 2007

I worked as a software trainer for ten years.

It sounds like a pyramid approach would work well, sort of like how journalists start with a lead sentence that sums up the article (the top of the pyramid) and then keep re-exploring it with more detail.

If you take this route, each person can get the training he needs and then leave when it starts getting overly detailed (more info than he needs). But a co-worker of his who wants/needs more data can stay for more.

Another solution: use cases. In other words, if you were teaching them MS Word, you'd say, "Imagine I'm a novelist, and I want to use Word to write a novel. I'd do this, then I'd do this, then I'd do this...

"Now, imagine I'm a secretary who needs to use Word as a tool for mail merges. First I'd do this, then I'd do this, then I might do this, but it would cause an error, because what I should really be doing is this..."

It sounds like these developers need to understand how people USE the software. And that's what use-cases are all about. Uses-cases also add a narrative layer to training, which gives it shape and structure.
posted by grumblebee at 1:39 PM on December 20, 2007

I'm a software trainer. But it's hard to recommend much from your description, as the problem itself isn't defined in very much detail. That said, I second grumblebee's idea of using use cases (do your developers know UML? Do you? Could be handy here).

On top of that, I find analogies to other software very handy. There's a lot of commonality in software. You can use that to help explain how to use it or, in your case, what you want to see in it.

It sounds like what you want here is more of a demonstration. In that case, lining out an overview of the features and demonstrating each one would help. And, if you can think up a decent training example that will allow you to demonstrate more than one feature/function, so much the better. If you can't demonstrate these features in real-time, do screencasts of them. Then, in the training session, set each clip up, play it, and then briefly discuss it.

I'll end with my most important bit of advice: define your desired outcomes first and let that define your training. What, in very specific terms, do you want your trainees to know or be able to do when they walk away from this? You don't have to measure it, but design the training as if you had to.
posted by wheat at 4:08 PM on December 20, 2007

Just to clarify, the people I need to train are regulatory experts, not the actual developers. They are all pretty comfortable with other software we use, just not this particular program. Still, I like the idea of use cases of some kind. We are still developing those but I think we know enough to go on for the purposes of this training. Thanks all!
posted by cabingirl at 5:49 PM on December 20, 2007