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.