RE: The Limits of Training

Subject: RE: The Limits of Training
From: "McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>
To: "Todd Walton" <tdwalton -at- gmail -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Tue, 17 Feb 2009 09:52:08 -0500

Todd Walton stated:
> I work in the support center of a mid-sized corporation. We battle
> constantly with how to reduce call volume. Many of the calls we take
> are about password resets for Windows/the network. It has been
> decided that it's really not a training or documentation issue. We've
> told these people time and time again how to change their network
> (Windows) password and they still do it a different way. Training is
> apparently not the answer. There's no document that has convinced
> these people to change their password in the right way.
> We have decided that we must change the way passwords work. We've met
> a limit of technical documentation.

Possibly, but consider that you and your system users have run up
against the limits imposed by a badly designed network access control

Nobody should deploy a system that allows users to perform a simple
action "a different way", when that different way is wrong.
You don't release an application whose user interface allows the user to
break the app.

If you do, then you fix it as soon as you discover the problem.

If you don't fix it, you face the situation that your gang is facing.

You must change the way that passwords work.

Documentation is not the fix for a badly designed

Consider that your user population probably changes their password once
every three months or so, and probably after some form of automatic
nagging. Chances are, with employee populations being as mobile as they
are, that many of them came from better-designed or differently-working
systems, and have years of habit behind their actions. Your system
should either accommodate their habit, or else just refuse to comply and
force them to do what's necessary. It should (stitch) recover
gracefully from any inappropriate input.

- Kevin
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.


ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals.

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:

The Limits of Training: From: Todd Walton

Previous by Author: RE: Wiki as a final output of the documentation?
Next by Author: RE: Studies relating to documentation density and getting the user to read the manuals
Previous by Thread: Re: The Limits of Training
Next by Thread: Wiki as a final output of the documentation?

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

Sponsored Ads