Answered Question on Linkedin.com: What successful techniques have you used to improve learner's retention?

I recently answered a question on the Instructional Design & E-Learning Professionals' Group of LinkedIn, and wanted to share that answer here on my blog. The question posed was:

What successful techniques have you used to improve learner's retention? Based on my experience, there's only so much information you can stuff into people's heads.
What's the best single tip you would give to help improve the quality and quantity of information that people retain after experiencing the training you've developed?

My single most important tip is this: Instead of training your students to perform the task from memory, teach them why and when to perform the task, and how to use support materials to succeed at the task.

If you are training your students to perform a life-and-death skill under strict time constraints, then of course they need to be able to perform the task from memory, on demand. An emergency room medical procedure would be one example. In that kind of situation, you want them to leave class knowing exactly how to perform the task without any kind of support materials. But that is a rare situation.

In most situations, your students will have time to perform the task. That is, they will have time to find and use reference materials to help them with the task.

Instead of overloading your students with the detailed steps of how to perform a task, perhaps you should consider teaching them how to use the reference and support materials to perform the task. Then, you can focus your training on:

1. Why they need to learn to perform the task (motivation).
   
2. Who needs to be involved in the task (roles and responsibilities).
   
3. When they need to perform the task; where it fits into their workflow (context).
   
4. Which steps are critical or especially difficult (roadblocks and "gotchas").
   
5. Where to get supporting materials for the task (reference materials and job aids).
   

Of course you will still take your students through the detailed steps of performing the task. But instead of focusing on memorizing the how-to information, you'll focus on the information above. While demonstrating, you can reassure them that the "clicks, keystrokes, and actions" are all included in the support materials. After the student performs the task on-the-job a few times, with the help of the support materials, then it becomes committed to memory.

In my experience, this approach avoids information overload during class while enabling students to learn complex, long tasks. Does this agree or disagree with your experience? We want to hear from you in the comments!

How to develop training when the subject is a moving target?

Recently, I received this question from someone who had read my book on Writing Successful Software Classes. My answer appears after his question:

Problem: They keep changing the software spec's, as I'm developing training!

> The company is
> currently in the process of creating and implementing a new core business operating system.
> Our legacy system is antiquated to say the least (it is DOS based).
> The new system is being built from scratch, so this is no out of the
> box ERP that we are talking about.
>
> My team and I are competent instructional designers and trainers but
> our experience is limited to training on processes or systems that are
> already complete. What I am struggling with is building training for a
> system that is being built as we are expected to develop training. If
> the system were complete and then we had 6 months to develop the
> training before it was implemented, we would be okay, but that is not
> the case...we are expected to develop training from
> Functional Design Documents which by the way are not necessarily
> well-written. The system is being given to us in milestones, but they keep changing things and changing the milestones.
>
> I have found resources on major software rollouts, and systems
> implementations, but they are very technical in nature and gloss over
> end user training. Other resources that do concentrate on technical
> training make the assumption that a system or concept is complete when
> you develop the training.
>
> Do you have any advice or ideas of how we can tackle this? Let me know
> if you want any more details. I really appreciate your thoughts and your time.

Solution: Focus on documenting business processes first, then write keystrokes-and-clicks second

Training and user documentation almost always comes at the end of a software rollout. By the time the trainers and technical writers have the information we need, almost everyone else has finished their part of the project. And when people at the beginning of the project take more time than planned, and the deadline stays the same, that extra time they get must be taken from someone else. Usually, that's the trainers and technical writers. "We allocated three weeks for you to develop training, but testing and bug fixing took an extra week, so we had to shorten your time to two weeks."

At most companies, this is just the nature of the job. There are ways we can adapt.

First, focus on writing good instructions for your users. Unless your users must perform their work without referring to a manual, the instructions will be the user's safety net when they need to begin using the software.

Research I've done among the users that I serve showed that they prefer printed instructions. They don't like switching between two windows on their computer screen: one with instructions and one with the software. Among my users who have dual monitors, that is not a problem. But most of my users have a single, 17- or 19-inch monitor. I suspect that is why they prefer printed instructions.

Notice that I've been using the term "instructions" and not "user manual." A user manual is more than a collection of instructions. It gives background and context to the instructions. That is, a user manual doesn't just tell how to perform tasks, but also when and why. Think of instructions as a series of cheat sheets, or quick reference guides.

As you're writing those instructions, you will be simultaneously developing the demonstration that you use for training. More on that later. (At this point, you were probably wondering when I'd get around to answering your question about developing training. Hang in there).

Our biggest challenge is that as we are writing user instructions and developing training, the software is changing. We need to document and develop training for a moving target. How to do this? Here's something that has been key for me: start first with the information that will not change.

Forget about beginning your writing and course development with the introduction, or the clicks and keystrokes. Instead, begin with the information this is most unlikely to change.

In my experience, the specific list of business tasks that users need to perform with the software is unlikely to change. So I start with that. For example, suppose the business tasks I must teach are:

1. Create a new customer.


2. Enter customer demographics.


3. Attach a mortgage record to the customer.

Each of those tasks will have a quick reference guide, and a demonstration in your training class.

Now, I understand that you do not yet have the keystrokes for performing those tasks. The software is changing, so you can't write the keystrokes and clicks yet. But there are some things you can write about each of these tasks, such as:

• When to perform this task (where does if fit into your workflow?)


• Why to perform this task (what deliverable is produced; what result?)


• Next steps (what do you usually do next?)

So on each of your quick reference guides, you can add that information. For example, for the task "Create a new customer" your quick reference document might look like this:

Section: Creating a new customer

Subsection: When must you create a new customer? [This is business process information. You should be able to write this even if they don't have the software finished]
Subsection: When How to create a new customer [This subsection isblank, you don't have the keystrokes and clicks yet because they keep changing them on you]
Subsection: Results [This is business process information. You should be able to write this even if they don't have the software finished]
Subsection: Next steps [This is business process information. You should be able to write this even if they don't have the software finished]

Notice in that example above, you can write three out of four subsections even while the software is still being changed.

Remember I said that you can simultaneously develop the training demo? So at the same time that you start writing these instructions, you can start writing the slideshow for class. Your slides might read something like this:

Slide 1: Creating a new customer
When must you create a new customer?
Create new customer only when...
Slide 2: Demo
...blank slide, here you begin your demonstration...
Slide 3: Results
A new customer record in....
Slide 4: Next steps
At this point, you can now do this....

You can also start writing the in-class exercise, if there is one. For example, "Create a new customer using the following information..." During the exercise, you would have the students try to perform the task, using the quick reference guide that you wrote.

At this point, you send the instructions back to the subject matter experts for their sign-off. Since you don't have the keystrokes and clicks yet, you probably won't be sending the material to the software guys for sign-off.
But what you do have is the business process information, that is, what the user will do and where that fits into their workflow. So you will send this to the business owner of the software.

As the software team finalizes the screens, you'll be able to fill in your instructions with the keystrokes and clicks. You'll also be able to plan your training demos. When all those instructions and demos are filled in, you have most of a user manual and a nearly complete training course.

When you train, you'll make it clear that you don't expect the people in class to come out with the keystrokes and clicks memorized. That is what user documentation is for. Instead, your purpose in class is to:

• Show the students where each task fits into their workflow.


• Emphasize the critical steps in each task: things you must do.


• Stear them around the mistakes that you cannot recover from.


• Show them where to get further help with the software (if your company offers this kind of support).

In your email, you mentioned Functional Specification documents. You might be able to pull much of this information from those documents. But don't get bogged down in trying to write detailed instructions from those functional specs. It just isn't realistic to document clicks and keystrokes until you have a working product in front of you, and an authority figure who says, "freeze this interface here." Until then, you are writing the framework, or outline, into which you will drop these keystrokes and clicks.

This is the process that has worked for me. I hope that you will find it useful. If you have any questions, I'd be happy to help.

Developing an Online Course in Moodle as Quickly as Possible

I had a reader send me a question about how to estimate the time it will take to develop a course in Moodle. I'd like to share her question and my answer with you. As always, your comments and experiences are welcome.

Her Question:

I am just about to embark on my masters dissertation project, and am looking a web-based tutorials for teaching. At the moment I’m considering putting together a tutorial as part of the project using moodle (I have copies of your books in front of me now).

One question I cannot seem to find an answer to, is realistically how long would it take for me to construct something like this? I have seen reports stating that construction of online courses can take up to 18 months, but I think these were from scratch as opposed to using a software programme such as moodle. I am fairly Internet literate, and have created basic webpages before, but have never done anything like construct my own online course.

I am studying via distance learning and also have a full-time job. I have between now and June/July to work on my project (including analysis and user-testing, etc) – do you think this is something which I can realistically achieve in this kind of time frame?

My Answer:

In my experience, the old methods of determining how long it takes to develop courseware were never very accurate. With the variety of tools available to us today, the many different situations, and the many different expectations from learners and stakeholders, those old recommendations are even more inaccurate.

I no longer ask, "How long will this take me to develop?" Instead I ask, "How long before the client needs it?" And then I determine what I can do between now and then. It sounds to me like you have a few hours a week to spend on developing an online course, between now and June. That's not much time. So instead of dwelling upon how long it will take, let's talk about how to maximize your output in the time that you do have.

First, try to get out of installing Moodle yourself. If you can use an outside hosting service, find one that has a one-click install for Moodle. If you must use your organization's web server, try to get the web admin to install it for you. When Moodle installs without trouble, the installation goes quickly. When it gives trouble, you can spend hours tracking down the problem. If you pay a few dollars a month for a hosting service that will install Moodle for you, I advise it.

Second, resolve to stay within Moodle's built-in capabilities. Some of the add-on modules add great functionality. But for a project working against time constaints, I advise you stick with Moodle's built-in functionality and not get bogged down in trying to get add-ons to work.

Third, make as much use of existing material as possible. As a librarian, I'm sure you can locate web pages that you can use as course material. I think there's nothing wrong with a course whose learning material consists entirely of links to external web pages, video, and audio. For example, if I was teaching a course on public speaking, I might link to a funny Youtube video of public speaking bloopers, tips from Toastmasters, and famous speeches. Creating your own multimedia takes especially long, so I would search Creative Commons for media I could use in my course.

Fourth, I would try to use Moodle's built-in Web page editor (Web page Resource) to write a short description of each resource that I link to, and what I want the students to pay attention to while viewing it, and what I'd like them to get out of it. To ensure that they read this before going to the resource, I would put the link to the resource on this web page instead of on the course's home page. Then, the students would need to go through the web page that I write before clicking through to the external web page/video/audio.

Fifth, I would follow up each reading/viewing/listening resource with an activity created in Moodle. For example, I might ask the students to:

1. contribute to an online discussion, and to rate other students' postings in that forum. (Forum activity)


2. take a short quiz on the material (Quiz module)


3. write a summary of the material and upload it (Assignment activity)


4. record a snippet of speech and upload it (Assignment or Workshop activities).

Sixth, I would use outside services for things that Moodle doesn't handle, or that it handles only with plug-ins. For example, after the students have completed viewing the resources and doing the follow-up activities, just before an exam, I might schedule a summary lecture with WebEx or GoToMeeting. The lecture could include a slide show of the material that will be on the final exam, whiteboarding, and chat. If possible, I would record the session and offer it to the students as a download.

Seventh, I would offer an online exam open only at a given time, to ensure that students don't take the exam and pass along the answers.

That would be my model for rapid development of an online course. And if I could, I would choose a topic for that course based upon the amount of good material freely available online.

Estimating the time to create a training course

The Question

I received this email asking how to estimate the time it takes to create a software training course:

Hello,

I have a strong background in software development and training development and delivery. My training has always been around soft skills, business processes, and employee orientations.

I recently joined a software company as the Training Manager and I’ve been tasked with “figure out how we should do user training for our product”. I’ve purchased and read your book, User Training for Busy Programmers and it’s been very helpful already in translating my current knowledge of software development and non-software training into what I need to do for software user training.

I was wondering if you have any thoughts or resources around estimating the time it takes to develop user training following the process you outline in the book?

Thank you,

Jennifer

The (somewhat disappointing) Answer

Here's my reply:

Jennifer,

Years ago I asked this question on several of the most popular training and technical writing mailing lists. I also tried equating the time it took to develop training and documentation to things like function point counting, number of screens, number of keystrokes and clicks. None of it worked.

Seriously. The conclusion I arrived at is that there is way to predict the time to develop training and documentation, that is more accurate than your own experience.

Since you have experience developing training in business processes, you're not far off from being able to accurately estimate time to develop training for software. Because at the end of the day, a software class is (or should be) nothing more than a business process class that features a new tool. So when you're trying to estimate development and delivery time for a software class, ask yourself how long it would take to develop and deliver the class if you approached it as teaching a new business process, which just happens to use a new tool.

Sorry I couldn't give a more concrete answer. This is a question the continually challenges me, and I'd be happy to hear of any resources you find that help with it.

Regards,

William Rice

A Plea for Help

I want to hear what you have to say about estimating the time it takes to develop a software training class. Do you have any objective, quantitative methods that work for you? Or like me, must you rely on intuition and experience? How accurate are your estimates?

This topic is ripe for conversation. Leave a comment, and keep the dialog moving!

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.

Creating an Instructor Kit

After you've tested the in-class exercises, polished the presentation
materials, printed the handouts and workbooks, and created the data files
for class, are you ready to hand over the course to an instructor? Not
yet. You have one more thing to do before calling your course finished:
Create the instructor kit.

An instructor kit often differentiates a good course from an exceptional
course. It is more than a pretty package or a finishing touch. It is an
integral part of any training course that you must hand off to an instructor.
The instructor kit's ultimate goal is to increase the quality of the students'
experience, by helping the instructor to assimilate, set up, and deliver
your course.

This article addresses creating an instructor kit for a software course.
However, 90% of this article is directly applicable to creating an instructor
kit for any technical course, and the other 10% is easily adaptable to
non-software courses.

What is in an Instructor Kit?

An instructor kit consists of information and tools.
Most of the information helps the instructor teach. Most of the tools
help the instructor set up, reset, and delete the course. The information
that you should include in an instructor kit is listed below. The software tools that you should include are described after that.

Types of Information in an Instructor Kit

Most instructor kits require the following types of information:

Prerequisites

Prerequisites include:

• Proficiencies the instructor must have to teach the course.
  


• Information the instructor must know about the subject.
  


• Minimum equipment and software needed to teach the course.
  

Setup Directions

Setup directions include:

• Required settings and configurations for the equipment and software before installing the course.
  
• Directions for installing the course files.
  
• Required settings and configurations for the equipment and software after installing the course.
  
• Directions for testing the installation.
  

Delivery Information

Delivery information includes:

• The location of any data or documents that the instructor or student will use in class.
  
• The location of any data or documents, and a list of functions or menu items, that the instructor should steer students away from.
  
• Key points that the instructor must address in class.
  
• Directions for demonstrations.
  
• Information to help the instructor coach students through workshops.
  
• Directions for using the tools listed in the next section.
  

Reset Information

Reset information includes:

• A description of the state of the data and documents used in class, after class.
  
• Directions for returning data and documents to their pre-class state.
  
• Directions for testing the reset procedure.
  

De-installation Directions

De-installation directions tell the instructor how to de-install all
software placed on the training computers, and how to reset the computers
to their original state.

Types of Tools in an Instructor Kit

For a software course, most tools consist of software designed to help
the instructor present the course, such as:

• Installation Software.
  
• Electronic Slide Shows.
  
• Reset Software.
  

Tools may also include a printed instructor guide, and hardware needed
for the course. Most instructor kits require the following types of tools:

Instructor Guide

The Instructor Guide contains all of the information given above. It
is usually a printed document, but most instructor kits also include an
electronic version of the document.

Installation Software

The installation software may be simply files that the instructor copies
to the classroom PCs, or an application that performs the installation
when launched. The installation software can:

• Install the data used during the course.
  
• Install the documents and files used during the course.
  
• Install the Electronic Slide Show.
  
• Configure the settings on the computer(s) used during the course.
  

A course may require separate installation routines and files for the
instructor and students. A non-software course may instead have equipment
that is used during setup. This equipment may differ for the instructor
and student.

Electronic Slide Shows

Electronic slide shows are usually created with an application like PowerPoint
or Astound!. The slide shows may be installed by the same software as
the data and documents used during the course. Or, it may require its
own installation software.A tutorial on creating electronic slide shows
for technical training is beyond the scope of this article.

Training Applications

Training applicatioins consist of the applications that students and
the instructor need for the course. This may include the actual application
being taught, and also:

• The application used to run the slide show.
  
• Applications used to examine documents.
  
• Applications used to examine, create, or modify data that is used in class.
  

Training Files

Training files consist of the data and documents used during class. The
instructor may receive more complete versions of the data, for demonstrating
the results of in-class exercises. If this is so, the instructor and students
will need separate installation routines.

Reset Software

Reset software returns the data and documents used during class to their
pre-class state. It also resets and software settings that the students
changed during class.

De-installation Software

De-installation software removes all training software from the computers
used during training. It also returns the computers to their original
settings.

Outline for the Instructor Kit Guide

Use the following outline as a starting point for writing your instructor guide. I've numbered the sections so that you can see the hierarchy.

1. Introduction to the Course

Explain why the course is taught, what the course covers, and to whom it is taught.

1.1Purpose

List the proficiencies the students will develop during the course.

1.2 Software Covered

States the software that the students will learn to use. Include the version numbers and platforms for the software.

1.3 Audience

Describe the audience and the audience’s situation. For example, "This course is designed for line managers at Company X who must create budgets for the groups they manage."

1.4 Agenda

State the high-level topics and estimates for the time to teach each topic.

2. Contents of this Instructor Kit

An instructor kit is often packaged into a binder that includes a written instructor guide and CD containing all software and files. Usually, the majority of this section lists and describes the files on the CD.

2.1 Documents

Describe the purpose and format of any documents used during this course. If a document must be printed for the course, state so in its description. State when each document is used in the course.

2.2 Data Files

List and describe the data files used in the course. Stating when each file is used helps the instructor trace any problems during the course to a faulty installation. For example, suppose an exercise in loading data does not produce the intended results. If the instructor knows that FileX is used in this exercise, the instructor can check the installation of that file while troubleshooting the workshop.

2.3 Applications

If the course requires the installation of any applications, include the installation files and instructions.

2.4 Hardware

If the course requires special hardware that is not available at the training site, include the hardware in the instructor kit.

3. Prerequisites

This section describes all prerequisites for the course. Prerequisites can include physical items, software, and knowledge.

3.1 Room Equipment

List and describe the non-computer equipment the instructor needs to teach the course. Some items that might appear on this list are:

• A whiteboard.
• A flip chart.
• An overhead projector.
• Give-aways for students.
• Name cards for students and instructor.
• Items used during training games or demonstrations.

3.2 PC Hardware

List the minimum requirements for the student computers, and the instructor computer. Some of the requirements:

• The amount of memory. Does the instructor computer need more memory to run the training application and slide show concurrently?.
• The amount of free hard disk space. Do the instructor files take up extra disk space?
• Processor speed.
• Display resolution.
• Floppy, CD, and/or DVD drives.
• A printer.

3.3 Software

The software on which you are training is an obvious choice for this list. Also consider any applications needed for opening files used during training. For example, if you load a graphics file into the training application during class, will you need a graphics application to examine or edit the file before loading it? If you supply documents in .pdf format, will the students need Adobe Acrobat to view them? If the training application exports data to a spreadsheet, will you need a spreadsheet application to examine the data?

3.4 Instructor Proficiencies

This can consist of a list of tasks the instructor is proficient in. Or, it can state that the instructor must have a certain amount of experience with the application.

Most in-class exercises begin with a list of the proficiencies developed during the exercise. One easy way to complete this section is copying those lists into this subsection.

3.5 Instructor Knowledge

An often-overlooked prerequisite for many technical training courses is instructor knowledge of the business processes that happen before and after training. The instructor should also know who supports the users after training.

Students often ask questions that go just beyond the scope of the application being taught, such as:

• What is the source of the data that the training application accepts?
• What happens to the data or files that the application outputs?
• Who is responsible for supporting the users after training, as they begin to use the application?

3.6 Student Proficiencies

Many software courses list "Basic PC skills" as a student prerequisite. Be more specific. For example, many users who claim they have "Basic PC skills" do not know how to:

• Navigate around a hard disk and find a file from within the Open File dialog box.
• Turn on the display of file name extensions. With the file name extensions turned off, "file.txt" and "file.dat" are both listed as "file."
• Right-click and use shortcut menus.

If you do not state exactly which "Basic PC skills" the student needs, the instructor may need to spend valuable class time teaching teaching remedial PC skills.

3.7 Access Rights

Many training courses are taught off-site, at a client’s offices or a rented training center. While developing the course, you have access to the application and your computer. Do not take for granted that the instructor and students will have this same access when off-site.

When writing this subsection consider whether:

• The students can access the training application from the computers in the training room.
• The instructor has administrative rights to install the training software on the training computers.
• The students can access any network files they may need from the training room.

4. Setup Directions

This section includes setup directions for both the student and instructor computers. Refer to the section on software prerequisites and determine if the instructor needs to install the training application, and supporting applications used during class.

These directions do not always need to be detailed, step-by-step instructions. However, if you assume the instructor knows how to perform some parts of the installation without detailed directions, list this assumption in the Prerequisites section under Instructor Proficiencies.

4.1 Starting Point

Give a starting point for the installation. For example, before installation:

• What software must be on the student and instructor computers?
• What settings must be configured?
• What hardware must be connected?

4.2 Installing and Testing the Student Files

This subsection gives directions for installing the applications and files used by the student.

4.3 Installing and Testing the Instructor Files

This subsection gives directions for installing the applications and files used by the instructor. Sometimes the instructor setup is a completely different process from the student setup. Other times it is an additional process.

4.4 Installing the Slide Show

This subsection gives directions for installing the slide show. The installation may be as simple as copying files to the instructor’s computer, or it may use an installation application.

5. About the Training Application

This section tells the instructor what is unique about the training application. It supplies the kind of information that an instructor will discover after hours of exploring the training application. Save your instructor some preparation time and include a section about the training application.

5.1 Limitations, Instabilities, and Non-functionality

The development of a training course often starts while the product is still in development. For software courses, this means that the training course is often developed using an application that is not completely functional. The instructor must know what parts of the training application are unstable or unusable. Discovering these while presenting the class will undermine the students’ confidence in the instructor and the application.

5.2 Login Information

The instructor and students may use different login information. If all students access the same networked application during class, each will need a separate login.

5.3 Where the Data Is

A training application rarely contains as much data as a fully-functional production application. The instructor must know which settings will show data during demonstrations. Few things are more embarrassing for an instructor than desperately trying random settings during a demonstration, in an attempt to show how the application processes data.

5.4 Differences Between Student and Instructor Applications

The instructor’s application might contain more data than the students’ application, to make demonstrations possible. Or, the instructor’s application may have the finished versions of in-class exercises. The instructor must know about these kinds of differences before class.

5.5 Installing Fail-safe Data

Most software courses require a student to complete a series of in-class exercises. The result of one exercise often provides the starting point for the next exercise. Therefore, if a student fails to produce the desired result from an exercise, the rest of the class exercises can become impossible to complete.

Fail-safe data is data that can be copied into the training application to simulate the successful completion of an exercise. This gives the student the correct starting point for the next exercise.

If you supply the instructor with fail-safe data, include instructions for copying that data into the student application.

6. Module Notes

Each module, or chapter, in a training course usually covers a specific task or group of related tasks. Most modules follow a lecture-demo-exercise sequence. The subsections described below are based on these assumptions. Repeat each of these subsections for each module, or unit, in the course.

6.1 Points to Emphasize

Is there any information that the client asked you to emphasize during the presentation? Are there any procedures or steps that, if omitted, will cause a loss of data or failure in later procedures? Hopefully, all of the information that you have included in the course is important. But this subsection is for information that is essential to the success of the students, in class or when they return to their work.

6.2 Demonstration Script

You don’t need to script the instructor demo click-by-click. Just tell the instructor enough to re-create the demo you have prepared. Of special importance is stating exactly which data to use during the demo, and where the data is located.

6.3 Pre-exercise Checklist

This is a checklist of the menu options and features that the instructor taught during this unit. Just before the instructor tells the students to start the in-class exercise, the instructor can scan this list and determine if (s)he covered all of the topics necessary for the students to succeed at the exercise.

6.4 Starting Point for Exercise

Most students follow along with the instructor during demonstrations. This means that their screens will usually not be as they left them after the last exercise.

Describe the starting point for the in-class exercise. State where in the software the students should be, and what data they should be viewing. A screen shot may be a good idea.

6.5 Fail-safe Files for Exercise

The exercises in most software courses build upon each other. For example, Exercise 2 usually uses the results of Exercise 1 as its starting point. If a student does not produce the correct result from an exercise, this can jeopardize the success of subsequent exercises.

If this is the case in your course, provide fail-safe data for each exercise. State where the data is located and how to activate, or populate, that data if the student does not succeed at the exercise.

6.6 Slide Show Printout and Instructor Notes

You may know exactly why you’ve included each bullet point on each slide, but the instructor to whom you turn over your course may be left guessing. Instructor notes give the instructor more detail about the slides.

The slides do not need to be printed out at full-page size. Two to three slides per page gives the instructor enough detail.

Interview on Packt Publishing

Packt Publishing is the publisher of my book User Training for Busy Programmers. Based on that book, they published an interview with me on their site. We discuss some of the hard, real-world lessons I've learned as a technical trainer. It's a quick read, so if you're interested in training, check it out.

"User Training for Busy Programmers" is not just for programmers

I wrote User Training for Busy Programmers because I felt sorry for the programmers I worked with. Several of the software companies I have worked for had their programmers develop and deliver user training for their product. This was usually because the company started small, and did not have the budget to hire a full-time trainer. So the programmers were given the task of end user training. As the company grew, the programmers became too busy with programming to continue training and they became profitable enough to bring in a full-time trainer. In those cases, the programmers were very relieved to have me join the company!

I realized how common it was for small and medium sized software companies to have programmers, customer service representatives, and even salespeople conduct end user training. While many of these people have a natural talent for teaching, they are not professional trainers. They usually learn how to develop and deliver a software class "the hard way," by trial-and-error. And their employers have no intention of bringing in a professional trainer to take over the end user training. I wrote this book for them.

So don't be fooled by the title. Even if you're not a programmer, if you've been told to develop a software training class and you don't know where to start, this book is for you.

Why did I write Moodle Teaching Techniques?

I collect techniques. Techniques for writing clearly, techniques for constructing e-learning courses, techniques for making the best tiramisù (there is more to life than work, no?). When I began writing my collection of teaching techniques for Moodle, my intent was to add them to my first book, Moodle E-Learning Course Development. By the time I collected a handful of Moodle teaching techniques, I realized that they didn't belong in the same book as the general how-to instructions for using Moodle. Is this because the techniques in Moodle Teaching Techniques are more advanced than those in Moodle E-Learning Course Development? Partly, but if that were the only reason, I would have folded them into the first book anyway. It's because these techniques are developed and written from a different point of view.

When I wrote Moodle E-Learning Course Development, I started with Moodle and worked towards creating an online course that adheres to good teaching practices. The book is organized according to the workflow that works best in Moodle: create your course, add static course material, then add interactive material, then add social material, then customize the roles for your course...and so on. The approach in this book is to start with what Moodle can do and work towards creating an effective e-learning experience. The keystrokes and clicks in this book apply only to Moodle.

When I wrote Moodle Teaching Techniques, I started with a list of proven learning principles. I then developed Moodle techniques that used these principles. Some of these techniques work around Moodle's limitations, which makes them inappropriate for a book on using Moodle as it was intended. Others combine features, or use features in unexpected ways. In each case, the approach in this book is to start with a research-based learning principle and work towards creating an effective e-learning experience. Moodle Teaching Techniques is less about keystrokes, and and more about teaching techniques. You could probably apply all of the techniques in this book to another LMS, like ATutor or ILIAS. The keystrokes and clicks would change, but the most important parts of the book would not.

So here are two approaches that hopefully take you to the same place: creating an effective, engaging e-learning experience for your students. And that's the result all e-learning developers are striving for, no matter what tool we use.

Writing User Manuals from the Middle Out

You need to write the user guide for a complex product. There must be a dozens of functions and hundreds of tasks that can be performed with the product. Where do you begin? How to start writing? Conventional wisdom says: start at the beginning with an introduction to the product, and work your way through each function or task in the order the customer will use them. Don't! Here's a tip I learned the hard way after my ninth or tenth year tech writing: start in the middle, and work your way outward.

This article presents a method of writing user documentation that you may find easier and more effective than starting at "Chapter 1:"

1. Start by writing procedures for each task or menu option. This is the "middle" of the document, and results in a collection of subsections.

2. Then, add material just before and after each procedure. This is working "from the middle out." The result is a collection of sections.

3. Organize the sections into chapters, and add more material to the beginning and end of each chapter.

4. Finally, organize the chapters into a manual.

I have found that this method of writing user manuals from the middle out saves time, and yields more accurate and useable documentation.

Why Not Start at the Beginning?

When you begin your manual with an introduction to the product, you also begin your research with an introduction to the product. Typically, you ask the Marketing or Sales department to describe how the product will help the user: "What will users do with it?" You ask Development or Engineering to describe the product's structure: "What is it?" You experiment with the product long enough to determine how it's used: "How does the user use it?" Then, you write your introduction. Which will probably contain inaccuracies and be less useful than it could be, for three reasons:

First, you are attempting to describe the purpose of the product ("What will users do with it?") before you have completely experienced using the product. By asking others what the product does, you are only discovering what they believe the product should do. You must first use almost every function of the product to determine what it really does. Remember, the manual is for users and should be written from a user's point of view. You can better convey the purpose and advantages of a product to a user when you have completely experienced the product from the user's point of view. This is why, in the middle-out method, you write the introduction last.

Second, you are describing the structure of the product ("What is it?") before you have experienced how the pieces of the product work together. Describing what the modules of a software application are is not nearly as useful to the user as describing what those modules do, and how they work together. You can best determine what they do and how they work together by experience.

Third, you usually develop the outline for your manual at this stage. Remember that the outline will determine the order in which you present the product's functions and tasks. And, you have not yet performed all of the product's functions and tasks. After you have experienced a complete cycle of using the product, you will be qualified to determine the order in which to present the procedures for using the product. At this point, determining the order for these procedures is guesswork.

In sum, when you begin writing a manual at Chapter 1, the manual becomes a diary of your learning curve. The first sectioins tend to be either ambiguous or self-obvious. They become ambiguous when you are conscientious enough to attempt to state something meaningful about the product, when have yet to gain real experience with the product. They become self-obvious when you attempt to state only those facts of which you are sure. Because you have little more experience than the reader, those facts will tend to be self-obvious. Starting in the middle and working outward avoids these problems.

How to Do It

To create user documentation from the inside out, follow the suggested steps below.

Write the Sections

Following the steps below will result in a collection of sections. Later, you will organize these sections into chapters, and then a manual.

1. Write the directions for each task or function.

Let's assume one of the tasks the user performs with the product is, "Create a new record." Write directions for this task. Don't worry about:

• The purpose of the task (Why create a new record).

• Where it fits into the big picture (When to create a new record).

• What the user must do or know before performing the task (Prerequisites for creating a new record).

The only thing you are writing is how to perform the task at hand.

Repeat this for each task or function the user can perform with the product. When you finish, you will have a collection of directions for performing all possible tasks or functions with the product. Label this paragraph "Directions."

2. Add prerequsites in front of each task.

Add a paragraph of prerequisites in front of each task. In our example, the prerequisite might be that the product must be in a particular mode before creating a new record. This paragraph should tell the user only and exactly what conditions must exist before the procedure can be carried out. Label this paragraph "Prerequisites."

3. Add results after each task.

A results paragraph states what the user should see to confirm that the task was successful. It also states what has changed as a result of the task. Label this paragraph "Results."

4. Add background knowledge before the prerequisites.

Examine each task and determine exactly what the user must know to successfully perform that task. Put exactly and only the background knowledge the user must know for a task immediately before the prerequisites for that task.

If several tasks require the same background knowledge, you should probably organize them into a chapter or section and place the background knowledge only once at the beginning of that chapter or section.

5. Add next steps after the results.

State what user must, should, or can do next.

After following the five steps above, you have a collection of procedures. Each procedure comprises a section, consisting of:

• Background information

• Prerequisites

• Directions

• Results

• Next steps

Organize the Sections into Chapters

Only now that you have performed every task possible with the product, and determined the prerequisites and results of each task, can you see how they fit together into the overall process of using the product. Now you are ready to determine the proper sequence for performing the tasks, the purpose of each task.

Organize the sections (procedures) into logical groups. You may organize the procedures in the order in which the user is most likely to perform them. Or, you may group procedures with similar functions together. Whatever scheme you choose, each group of sections becomes a chapter.

Now examine the procedures in each chapter and ask, is there any information that the user must know to perform these procedures? At the beginning of each chapter, add exactly and only the information the user must know to perform the procedures in that chapter. Label this section "Introduction."

Determine the Purpose of Each Procedure

Good user documentation doesn't tell the user only how to perform a procedure. It also tells the user when. Now that you have experienced and organized all of the tasks for the product, you are qualified to determine when it is appropriate to perform each procedure. A "When this... Do this..." table is one effective way of presenting this information. You can place this "When..." information in:

The introduction to the manual. You would probably include "When..." information for all of the procedures here. This is usually the easiest place for the user to find the information.

The introduction to each chapter. You would probably include "When..." information for only the procedures in the chapter here.

Each section. You would probably include "When..." information for only the procedure in the section here. This is usually the most difficult place for the user to find the information.

Finally: Write Chapter 1

Now, look at the whole manual. Is there any background info that a user must know before using any of the procedures in the whole manual? Write it down. Call it "Chapter 1: Introduction."

Assemble the chapters, generate a table of contents, and you've got yourself a manual!

Course Evaluations that Matter

Do your course evaluations matter? Do they measure what's really important to your company and your students?

The training courses that you develop and deliver should advance your company's business objectives. This sounds like common sense. Now think back to the training classes that you have attended. After each class, you were probably asked to fill out a course evaluation. How many of those evaluations measured how well the course met the company's or your business objectives?

Too many course evaluations measure how well the course was written or delivered, and not how well the course supported the company's or student's objectives. For example, you have probably filled out course evaluations with a question similar to this one:

Rate the pace of the course:

• Too Slow

• Just Right

• Too Fast

This question helps you determine if the course is good. It does not help you determine if the course met the needs of your company or students. Here is an example of a question that measures how well a course met one of the company's business objectives:
As a result of this class, are you able to spend less time performing the task covered? For example, are you able to spend less time creating a purchase order or travel request, or less time looking for ledgers to view?

• No. It takes me just as long to perform the same tasks as before taking this class.

• Yes. I can perform the tasks covered in class in less time than before.

• This question doesn't apply to me.

One of the biggest challenges in the training profession is measuring return on investment for training. Entire books are devoted to this topic. While a complete treatment is beyond the scope of this article, you can still take steps right now to measure how well your course has met your company's or customer's business objectives.

Interview the course sponsors and/or students, and discover what business objectives they want to fulfill with the course. A business objective is a specific task whose success can be measured.

When you ask course sponsors or participants what they hope to accomplish in a course, their first answer is usually not specific enough. For example, if you are developing a course for a new engine analyzer, they might answer that the course objective is "To be able to use the analyzer." In this case, you would need more specifics. Use the asnalyzer to perform exactly which tests? On what kinds of engines? With what degree of accuracy?

Once you know the objectives being measured, the evaluation questions suggest themselves. When writing the questions, focus on asking the students whether they can now perform the given task better, faster, more accurately, etc. than before.

In addition to surveying the students, you might also consider objectively measuring the students' productivity before and after the class. For example, you might measure how long it takes students to perform a task before and after training, or how well they score on customer satisfaction surveys. These kinds of objective measurements are more difficult than having students fill out post-training evaluations. However, the payoff is a clearer idea of how well your classes support your company's and your students' business objectives.

This article is necessarily brief about how to measure the return on investment for a training course. However, using course evaluation questions that directly address your company's or student's business objectives is a good start. From there, you can move on to more formalized, complex techniques of course evaluation such as those discussed in the books recommended on this site. Your credibility as a trainer, and your company's bottom line, will both profit.