Re: Finding out if anyone reads your stuff

["Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>]

Folks:

Like the rest of you, I've run into the "is anybody reading this?"
feeling.  Fortunately, I've got very supportive management and a
relatively small userbase.  Here are a couple things I've tried:

1)  Don't theorize, don't ask, don't observe.  Go out for a few days or
weeks and BE A USER.  When I started with Pioneer two years ago and took
over responsibility for the detasseler payroll system, I spent two weeks
in a small, hot room in South Dakota transferring data from mud-spattered
time cards to a VAX terminal.  Because this also put me in close contact
with the plant's business manager and the other temps, I got a very, very
intimate, user's-eye view of the system and some of the related systems as
well.  (Not to mention some sobering insights as to how the field views
the data center.)

I realize this is much more difficult if the audience is customers rather
than employees, and management is loathe to give up the time (I advocated
this across four years and three jobs before I finally got the opportunity)
but it is worth it.  I came back from that trip and engineered a
documentation overhaul that is still going on under my successor.

2)  If you can get to your audience by e-mail, use it.  I've sent out
follow-up questionnaires to see how users received a new piece of
documentation, and gotten responses from over half of them.  I think the
keys are to keep the questionnaire only a couple screens long, and ask very
specific questions (Example: Was the lettering on the checklist: a) Too
small to read. b) Too large and awkward. c) Just right for my needs.)
Also, ask questions that will help you guide future development, like
whether the document is used primarily to train new hires or temps, as a
troubleshooting guide by more experienced users, or to keep track of steps
taken.

Always send a follow-up "Thank-you" and a summary of the responses to
people who participate, and copy their managers as well.

3)  Bring users in during development.  I've had Support identify users who
were likely to be cooperative, then had Security open the development
environment to the selected users for a limited time, faxed sample
documentation and some suggested tasks, then made a follow-up phone call.
Fortunately, I work for the kind of company where I can just tell a few
people I'm going to do that and then do it, instead of getting bogged down
in endless committee meetings.

Field users are usually thrilled that someone at corporate is paying
attention to them, and enjoy the opportunity to contribute to the system.
The only problem I've found is that you usually get more input on the
system than the documentation, but it does sometimes provide ammunition to
get the development team to do things you want them to do.

Again, a follow-up "Thank-you" with a copy to the relevant manager is
important.

4)  If you use Support feed back as an indicator of your performance, don't
overlook qualitative factors.  On one checklist that I did, the Support
folk said the main change was that the checklist forced a standard
terminology into the discussion.  Instead of spending five minutes at the
front of every call trying to figure out what the user had done and where
they were now, users could say "I'm on step 6 and the system won't accept
input on the PAY BY field." To which support people could reply, "OK, what
did you enter in the VENDOR field back on step 4?" This made calls shorter
and more productive, and that won't show up in a raw call count.

Also, you may get the same number of calls of the same length or longer,
BUT it will be because the users are plumbing the more advanced features of
the system.  For an internal shop, this is good, because it means the
company is finally getting some payback for the development time invested
in those features.   For certain types of vendors, this is also good,
although the reasons aren't as obvious.  If you're a high-price/high-value
vendor, your defense against lower-cost rivals is your advanced feature
set; if customers can't get to it because they're bogged down using the
"easy" stuff, you're in for *lots* of market share and margin pressure.

I hope this helps,

Doug
ENGSTROMDD -at- phibred -dot- com