Support Readiness Training

["Francis Anthony" <ItsFrancis -at- hotmail -dot- com>]

Hi,

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:

Course Requirements
--------------------------------

The course will be used for an instructor-led training in a classroom
The course will be conducted over a period of 3 to 5 days, each day
accommodating about 7 hours of instruction, which will also include hands-on
sessions in the laboratory. This ensures that the participants do not have
to endure, to borrow a trainer's turn of phrase, death-by-PowerPoint :)
The course will have a pronounced slant towards troubleshooting and
associated activities.
Ideally, the Support Readiness Training material will be the first thing
that the support personnel reach out for when faced with any kind of support
call
The courseware will comprise the following materials:
Participant Guide. The subject matter of the courseware is contained in this
guide, including labs and other miscellaneous information.
Instructor Guide. In addition to the content available in the Participant
Guide, the Instructor Guide contains other information designed to give the
instructor background information on the course material as well as
additional examples, and so on.
PowerPoint slides. Each lesson in the courseware is accompanied by
corresponding slides. These slides are meant to be a cue for the instructor;
she will use them to orchestrate the classroom experience. These slides are
also included in the Participant and Student Guides for reference.
As stated earlier, the intent of this mail is to get a second opinion on the
strategies developed by us.

Strategy 1
---------------

Since the courseware addresses a highly technology-literate audience, and
the intention of this audience is not so much to use the product as it is to
troubleshoot issues, the course will not cover mundane topics such as
installation, uninstallation, general administration, and so on. As these
topics are, in any case, covered extensively in the user's guides, it doesn'
t make much sense to repeat the procedures all over again in the courseware.
The assumption, of course, is that the participants will have read the user'
s guide and consequently have a fair understanding of the working of the
product.
Considering the limited time span of the course, there is only so much that
can be effectively instructed. Therefore, instead of burdening the
participants with superfluous information, this approach will give the
participants exactly the information they need to perform their jobs
effectively.
Therefore the course will exclusively concentrate on the troubleshooting
perspective of each topic. What this means is that, for example, the lesson
on installation, instead of covering the actual installation/uninstallation
procedures,  will cover issues that may arise while installing/uninstalling
the product, and possible solutions for the same.

Strategy 2
---------------
The strategy spelt out above, however, ignores situations where participants
are new hires, or there may be a new version of the product with new
features. In this case, even though the participants are highly
technology-aware, they would still require training on the usage and general
administration of the software. The solution to this situation is to make
the courseware all-inclusive, one that will contain the usual suspects such
as installation, general administration, and so on. It will also have a
focused approach to troubleshooting, either on a topic-wise basis or a
separate, consolidated troubleshooting chapter.

The troubleshooting chapter would be a detailed section that would include
the following details:


A detailed listing of error messages, with unique message identifiers
(UMIs), and a detailed explanation of the same. The explanation would
include possible causes that led to the error message being displayed, and
possible troubleshooting avenues.
A detailed unraveling of system and application logs that reflect system and
application activity
Randomly chosen problem scenarios and associated troubleshooting tips.

This approach is really a one-size-fits-all approach that caters to the
needs of experienced users and well as new users. While this approach might
win votes for being PC, one needs to keep in mind that it actually subjects
the participant to information overload, including information the
participant may already be aware of. It could also lead to the course merely
reinforcing information that participant already knows while not adequately
focussing on critical [no, I wasn't going to say "mission-critical";)]
troubleshooting information.

I guess I have harangued you guys long enough with details. Thanks for
taking time out to read this rather lengthy mail. I would appreciate it if
you could respond with your ideas and opinions. Your views would definitely
help us to come out with a concrete instructional strategy.

I look forward to hearing from you.

Kind regards,

Francis