RE: Support Readiness Training (long)

Subject: RE: Support Readiness Training (long)
From: dthomps -at- foundationsoft -dot- com
To: ItsFrancis -at- hotmail -dot- com, techwr-l -at- lists -dot- raycomm -dot- com
Date: Tue, 19 Aug 2003 09:37:19 -0400

Hi Francis,
Your question was interesting to me because my job entails some of the same
tasks. I helped developed a new-support-representative training program some
time ago, and I am in charge of "continuing education" for our team of
existing support reps.

I have been doing this for about three years now, and have learned one
important lesson: NO ONE PREPARES.

I can assume that the reps will read, do pre-class assignments or even plan
to get up on time to get to class, but that seldom happens. Perhaps it has
to do with how busy they are, my company's culture, or my lack of real
authority over the reps. But whatever the reason, I have learned to assume
the worst case scenario instead. I have surveyed the classes, talked to the
reps one-on-one and had lengthy discussions with their manager. They all
claim to love the classes, appreciate my efforts, learn a lot, etc., but
none of that makes them willing to do work outside of the class.

It sounds like you have a lot more training time available than I do. If I
had that much time, I would break the class into segments of "underlying
concepts," "software skills" and "troubleshooting." At the beginning of each
section, I would spend some time evaluating the class's skills either
through a game, quiz or simple discussion and then be ready to change my
plans on the fly. If the majority of the class did not need any instruction
on "underlying concepts," I'd skip that and move onto the next section. The
disadvantage in this, obviously, is for those students who are not in the
majority. For them, I might plan an extra half hour or hour later in the day
to recap. Hopefully this would serve to encourage them to be more prepared
next time!

The more ideal strategy is probably to plan learning activities that teach
concepts, skills and troubleshooting in a not-so-obvious pattern. By
interspersing all areas into each activity, you may find fewer students
getting bored and/or left behind. Students who know the concepts/skills will
get additional reinforcement, and those totally unfamiliar will get at least
a cursory introduction. Of course, finding "fun" ways to cover all areas
without lecturing (i.e., boring students) is a HUGE challenge, one that I
simply don't have time for with all my other duties. However, since you have
a team of curriculum developers, you may find this feasible.

The bottom line is: Do not assume that anyone will read anything or prepare
at all before your class. Even if your company culture encourages it,
support reps are always VERY busy. At best, they may have to do the work on
their own time, and that only encourages resentment toward you and your
class before it even begins!

Thanks and good luck,

Dannette Thompson
Senior Technical Writer
dthompson -at- foundationsoft -dot- com <mailto:dthomps -at- foundationsoft -dot- com>

-----Original Message-----
From: Francis Anthony [mailto:ItsFrancis -at- hotmail -dot- com]
<snip>
My job profile involves developing courseware and instructional learning
material that is used to train both the global support personnel within my
firm (new hire and incumbent), as well as the support personnel of OEM's,
resellers, and partners; the objective being to arm them with information
critical for troubleshooting support calls.
The courseware design has peculiar requirements, and hence we (fellow
curriculum developers and I) have come up with two broad strategies to deal
with the same. The intent of this mail is not so much to seek for answers,
as it is to get a second opinion on the strategies that we have developed.
Of course, it goes without saying that if any of you have ideas that differ
from the ones we have put forth, that would be welcome as well.
The details are as follows:
</snip>




Previous by Author: RE: Upgrading Framemaker and Distiller
Next by Author: Fostering Teamwork and Communication
Previous by Thread: German tech writing contracts
Next by Thread: AT&T style guide


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


Sponsored Ads