Re: Integrating documentation and training

Subject: Re: Integrating documentation and training
From: "Doc" <doc -at- edwordsmith -dot- com>
To: <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 3 Mar 2004 17:54:09 -0800

> right now I'm brainstorming with myself
>on ways we can make this work. So far, it all
>seems to be coming down to information sharing --
>reviewing each other's material where possible (we
>do peer reviews in our group), keeping everyone in
>the loop when source documents are passed around,
>sharing software when we can to make repurposing
>easier, having writers attend the early training sessions
>to make sure feedback is cycled into the docs.

I have a few pointers and comments about training development. I also have a
few thoughts I'd like to share about trainings and delivery, based on things
that I've seen go wrong during in-house trainings.

You haven't told much about the purpose or audience for your training, but
the "information sharing" you've identified is, IMHO, a closed loop that
will leave you developing training in a vacuum, without real requirements.
You won't have accountability, and you won't have any criteria for training
success. These same issues are present during development of the manual,
but I've found that the audience for manuals is much more forgiving than
training audiences. Unlike the manual, a training either connects or
doesn't. Your training audience won't be back for a second training after
you've made feedback-driven changes. Your audience isn't the beacon at the
end of the flight, they're the navigator while you pilot the training
materials from take-off, throughout the flight, to completion. SMEs or other
writers/editors may like playing navigator, but unless it is playtime, best
to bump them and get audience nav.

I know of two fundamental requirements for success with training. Do these
two things together, and you will have the best chance for understanding and
addressing the real requirements for training, which also are your criteria
for success:

First, you must share the training development process with your target
audience and your information sources (SMEs).
Second, you must use standard Instructional Design techniques.

A few guidelines:

1. Know the target audience, and share the training development process
with them. You need to know how they work, day by day, in order to target
their training needs. Quite often, they share few or none of the
preconceptions a technical writer has about training. So you must seek out
audience representatives, review with them the source material, get their
input. If they've been around the block a few times and know their jobs
well, they'll spot the specific material they need to know. You can draw a
line around anything they identify as relevant to them, and then any other
topics or informational bits will have to be negotiated to get into the
training. Also ask for examples of trainings they found useful or not
useful. You're likely to learn a lot about their preferences and what sort
of training works for them (PowerPoint slides, hands-on lab, Q&A with
developers, telegraphic-style instructions or full-blown grammatical
paragraphs, ...). Note that this sharing activity with the audience happens
w-a-y upstream of any training review!

2. Know the SME(s) of your material, and share the training development
process with them, too. If, for example, the SME is product developers, and
the training is supposed to hand-off User Ed know-how, or something else
like product support know-how, to the target audience, then identify the
SME(s) who have experience handing off to your target audience, and get
their input on what is important for the target audience to know. Note that
this sharing activity also happens w-a-y upstream of a training review!

3. Know the difference between your SME and your target audience. They are
likely to have very different views of what specific material needs to be
delivered in training. Your job is to filter them both, and reconcile any
differences. It can be a contentious process, not all agreement and

4. Observe essentials of good instructional design: structure the training
by topic, group the training topics into logical training sections, if
possible. Always tell the audience what you're going to do, then do it, and
then summarize it. Do this serially, as a training overview, as a prelude
to each section, as a section summary, and as a final summary. The full
manual is not likely to be designed this way, so evaluate the manual, and
create separate training material if necessary.

5. As a follow-on to #4, don't risk losing anyone's attention where your
training material design is concerned. There is nothing as confusing as a
putative outline (or bright, colorful Powerpoint slide) that doesn't contain
the topic(s) you're talking about. Don't make the trainees thumb back and
forth through the manual or slide pack looking for the topic you're
delivering--be explicit in the training material. Hand out a comprehensive
outline, use narrowly-defined slides, and give page numbers/document name
where topic is found in referenced material. Refer to the outline often
during training so that everyone keeps up with, and stick to it.

Information sharing with the target audience might reveal specific
preferences and needs:

You'll probably find that the target audience is edgy because training takes
time away from their work. Patronize them. They don't want to spend 15
minutes on backgrounders if their job is simply to perform stepwise
procedures. On the other hand, you know that one goal of corporate training
is to develop their awareness and understanding of what they do and why, so
give them a view of their roles and responsibilities in the larger context
of how their work fits into the bigger picture. For example, if you're
training Help Desk, show them a high-level view of the system they're
supporting, so that they can see and understand the flow of things,
including where the problems come from and who else is involved. The manual
might cover this in excruciating detail, but for training you need to hold
back anything deeper than the target audience needs to know. You can train
them on where to look for it in the manual, but save the deeper item-by-item
classroom training for the audiences who are prepared to learn the details
as a part of their daily work.

You'll probably find that your SME resources know a great deal about the
system and want to dump a lot of it into the training. Don't do it. Filter
heavily on behalf of your audience. Check the material with an experienced
member of your target audience (their manager might be a good choice) and
let them tell you whether their trainees are prepared for more or less
information. As tech writer, you're all about giving your audience what
they need, and less about gagging them on a shoehorn full of extra

Be very careful about identifying your target audience. A two-hour training
will be perceived as a waste of time if it has only 5 minutes of content for
some of the trainees. Know who is going to be scheduled into your training
sessions, and check it with them in advance. If some trainees are only
peripherally involved, then design the training so that they can be there
only while it is relevant to them. Time the content for them, so as to let
them arrive late or leave early.

Try to have a 'source' person present at the training to answer any deeper
questions that arise. You might work with the source to develop a segment
of the training that the source where their expertise is helpful. let the
'source' present a segment of the training. DO NOT let the source dump too
much information on the trainees.

Hope this helps.

Ned Bedinger
Ed Wordsmith Technical Communications
doc -at- edwordsmith -dot- com
tel: 360-434-7197

Integrating documentation and training: From: Stevenson, Rebecca

Previous by Author: Re: IT documentation
Next by Author: Re: IT documentation
Previous by Thread: Integrating documentation and training?
Next by Thread: Promotion (was RE: IT documentation

What this post helpful? Share it with friends and colleagues:

Sponsored Ads