Book Review: Training for Software Rollouts

When a book on software training begins with the political issues of selling the training program to management and users, it's a sign that the author has real-world experience. As a training professional who's read too many books that take an academic approach to training, I appreciated the practical approach in Training for Software Rollouts: The Definitive Guide to Developing and Implementing Software Training Programs.

Charles H. Trepper's 480-page book is a comprehensive and accessible guide for IT managers and training professionals. Following the methodology in this book probably won't save you time compare to the seat-of-the-pants, ad-hoc method I've seen at many companies. However, the discipline and thoroughness of Trepper's method ensures better results for the time you invest.

Trepper takes a conservative approach, and bases his method on Instructional Systems Design (IDS), which consists of five phases:

1. Analyze
2. Design
3. Develop
4. Implement
5. Evaluate.

Trepper adds his own experience in company-wide software rollouts to the IDS method. For example, he covers Political and Organizational Issues in Chapter 1, which is probably worth the price of the book alone. He then moves on to the Analyze phase of IDS, with Chapter 2, How to Conduct a Training Needs Analysis.

Chapters 3 and 4 cover the Design phase of IDS. Some topics that only an experienced trainer could add are 3.4 Getting funding--where does all the money come from? and 3.7 Avoiding training budget cuts.

Chapters 5 through 8 cover the Develop phase, when the actual training materials are constructed. These are some of my favorite chapters.

Chapter 5, Self-Directed Training versus Classroom Training, helps you decide between classroom, self-study, and live distance learning. It ends with a brief discussion on combining these methods, 5.5 Combining methods for maximum effectiveness and efficiency. In the training profession we call this blended learning. If you decide to go this route, you'll probably want to learn more strategies for mixing learning modes than this section provides.

Chapter 6, Make or Buy--Purchasing Training versus Developing and Delivering Training In House, helps you make this important decision. Trepper points out that

It is reasonable to assume that some training professionals, in an effort to perpetuate their usefulness, may present a barrier to the outsourcing option.

This resistance is not only futile, but also counterproductive. As Trepper briefly states, "the role of training professionals within corporate environments is changing." The profession is seeing a shift from training to performance consulting, and trainers who don't get with this program are going to be left behind.

Chapters 7 and 8, Purchasing Training and Customizing Packaged Training to Meet the Needs of Your Organization, finish the Develop phase. Chapter 8 is notable because I have not seen any other training books offer guidance on how to customize purchased material. Don't expect detailed step-by-step directions on how to deconstruct a Flash-based training module. The situations are too varied. The advice is useful, but necessarily broad.

Chapters 9 through 11 cover the Implement phase of IDS. Chapter 9, Implementing the Training Program, makes you aware of administrative needs such as Tracking attendance, Maintaining Courseware, and Monitoring and Logging Training. However, it doesn't offer detailed solutions. For a more thorough treatment, you might want to check out The Trainer's Support Handbook by Jean Barbazette (disclosure: I get credit from Amazon when you buy through that link).

Chapter 10, Communicating the Training Rollout to the Organization, discusses employee resistance to training and how to deal with the resistance. This is the only training book I've seen that deals with this crucial topic. I think this topic is worth more than 12 pages, and if I could ask Mr. Trepper to expand any one chapter this would be it. He talks briefly about determining the "real resistance reasons" to training, but doesn't tell us how to do that. Even a few examples of these reasons would be very helpful. For example, I've found that employees often resist training because:

• They're afraid that efficiencies created by the new system will result in their jobs being eliminated.

• They are the only ones who can do their jobs well, and the new system might make their jobs easy enough (or appear easy enough) for almost anyone to do.

• They believe that the new system will take just as long as the present system, but management will still require more productivity to justify the new system.

• Their managers will require them to do the same volume of work even while they're taking time out to attend training.

• Previous, unsuccessful software rollouts make them cynical about this rollout's chance of success.

Chapter 11, Tips for the Trainer, gives some valuable advice for first-time trainers. The tips are general enough that they apply to almost every training situation. For more information about software training techniques, a good beginner's book is The Accidental Trainer : You Know Computers, So They Want You to Teach Everyone Else (yep, another Amazon Affiliate link).

Trepper devotes a few paragraphs to dealing with difficult students. If you want a more tips on dealing with hostile audiences, take a look at my article Surviving a Difficult Presentation: Techniques for Handling a Hostile Audience.

The Evaluate phase is covered in Chapter 12, Measuring Training Success by Measuring On-the-Job Trainee Performance. Trepper explains Kirkpatrick's Four Levels of Evaluation, which is the most popular and widely-accepted model. The four levels of measurement are:

1. The students' reaction to the training. Did they like it? Did they think it was clear?
2. The learning that took place. Did the students learn the material?
3. The transfer of the learning to the job. Can the students apply the learning on the job?
4. The result of the training on the organization. We also call this the Return on Investment, or ROI.

The ultimate goal here is to determine if, and how much, training has supported organizational goals. It's a big topic, but this chapter is densely packed and gives you enough information to evaluate your training program's effectiveness and return on investment.

One of my favorite pieces of advice in this chapter could come only from someone who has learned the hard way. Trepper writes about the difficulty of measuring the effect that training has on an employee's performance. He defines "results" as things the employee produces and that can be quantified: a completed widget, a completed support call, a discharged patient, a resolved customer complaint. He then defines "behavior" as something the employee does, without producing something that can be quantified: clean a room, give a massage, serve a diner. Results are easy to measure. But what about behaviors?

...begin by measuring results and only measure behavior when you have to. Most people try to identify the results of a position by listing its responsibilities and asking what product each activity generates. This process can take several hours and usually ends up with a very long list of results. A faster and better method involves identifying your customers and what you provide to them. This produces a list of key performance indicators.

In other words, to evaluate the bottom-line effectiveness of your training program, determine what effect it had on your customers' experience.

Chapter 13 covers Training the I/T Staff. I know many techies will appreciate this chapter, because I/T staff are often left out of training plans. The assumption is that training is for users, and techies can get what they need to know from the manuals and hacking around with the software. This is far from the truth, as Trepper adequately demonstrates in this chapter.

I've been called in several times to develop and deliver training for software that has already been rolled out. In Chapter 14, Trepper acknowledges that

..."training is not always at the top of the corporate priority list. Often training is developed casually as the software is rolled out."

The title of this chapter, Training Issues After a Software Rollout, talks about training issues when no training has been done, and when training was done with the rollout and now needs to be updated. Like Chapters 8 and 10, I've not seen any other training books deal specifically with this topic. And once again, I'd like even more of Mr. Trepper's valuable advice on this topic.

Chapters 1 through 14 comprise part one of the book, Designing, Developing, and Implementing a Software Training Program for Your Organization. Chapters 15 through 19 comprise part two, Application-Specific Training Issues. The applications covered are:

• MS Office
• Windows
• Lotus Notes
• SAP
• Oracle.

Each chapter covers some key training points for the application, potential problems, how to customize training for that application, and buying advice for training services and materials. These chapters are short but the advice is very targeted. For example, Trepper advises

Organizations often think they "know" Oracle because they possess the database. However, they fail to realize that the applications will probably be customized as much as the database.

Appendix A is the shortest of the seven appendices at only four pages. Trepper covers Rapid Development for Small Projects. I've spent at least half of my fifteen-year career rapidly developing small training programs, and I found Trepper's advice to be solid. For example, he states that

Designing the [training] program and custom-developing training can be done almost simultaneously...

This is often the case; an experience training developer will design and prototype the training program at the same time. Trepper includes a table of small-project steps and deliverables. This chapter, plus the guidance given in part one of the book, will serve you well if you need to rapidly develop a small training project. For a more focused treatment of rapid training development, you might want to look at my book User Training for Busy Programmers. It doesn't deal with the broader issues of a rollout like Trepper's book, but does offer a plan for non-trainers called upon to quickly develop end-user training.

Appendix B consists of Training Team Job Descriptions. Even if your team has been selected and everyone has their assignments, I recommend reading this chapter. Looking at the Principal Accountabilities given for each position may result in an "Aha!" moment when you realize that you left a task or area of responsibility unassigned.

Appendices C through G are hardcopy of sample materials that can be downloaded from the McGraw-Hill website:

• Appendix C: Sample Training Sales Presentation
• Appendix D: Sample Training Program Plan Outline
• Appendix E: RFP Outline and Completed Sample
• Appendix F: Training Program Process Checklists
• Appendix G: Sample Forms

These forms are in Microsoft Word format. Original purchasers of the book are permitted to download and customize the forms for their use.

At first glance, it would seem to be this book's focus that makes it uniquely useful. There are few books about training for software rollouts. However, after reading it, I realized that it's not the topic but the author's insight that makes this book unique. About three-fourths of the information in this book is standard Instructional Systems Design, customized for a software rollout. The other one-fourth consists of advice and insight that only someone with experience can offer. This is where the book most differentiates itself. If you're an experienced trainer, Trepper's insight can save you hours of work. If you're a non-trainer tasked with managing a company-wide software training effort, consider supplementing this book with some of the others I recommended, or with books from the American Society for Training and Development. Either way, this book is an investment that will pay off in a smoother software rollout.