Re: Request for change (long response)

[Bonni Graham <bonnig -at- IX -dot- NETCOM -dot- COM>]

Eric wrote:

>I'd like to see discussions and questions on bigger issues
>than ones that we can look up in a dictionary or reliable
>reference material. I'm sitting here, looking at TECHWR-L subject
>lines of "state names," "online vs. on-line," "commas and
>lawnmowers," and "restrictive vs. non-restrictive banter
>continues." <snip>

Good point, although I think that the state names does point to a
larger issue, just one that has been staying implicit, rather than
explicit, and it ties in with one of Eric's issues below: how to
deliver what our users need.  That's a minor caveat, though, so on to
Eric's larger point.

><snip>used "which" or "that" in a specific section. No, I woke
>up worrying about how to deliver what our users need,
>not what the SMEs think the users want, without inciting
>complaints about unresponsiveness. I woke up wondering
>if I'd completely missed the point, or if it really was
>simpler than it had looked. I woke up wondering if technical
>feasibility would line up with business requirements before
>the pilot class.

These are the issues, but they're the tough ones.  What we're seeing in
this list is what we're seeing in American politics, at least, and I
suspect the rest of the world's as well: it's much easier to address
"sound byte" questions and answers than come up with substantive
information about what I call "think questions".  I can toss off an
answer to which vs that (although I haven't 'cause it just isn't that
big an issue for me).  I have to work a little, and take some risks to
answer larger questions that I haven't even thought all the way through
yet.  You're asking us to do the HARD stuff, to provide answers to
questions we have not fully settled for oursleves, let alone want to
let out of our heads into the world (at least, that's why I haven't
asnwered some of the meatier questions here, lately).

I'll take a crack at it, though.

I spend a lot of my time wondering if I'm missing the point -- that's
part of my job definition, isn't it? <g>  But SMEs are people, after
all, and you can usually reason with them.  The times I've found myself
in the situation you describe, I've taken the SME out to lunch and
asked WHY he or she was so insistent about that piece or set of
information. Once I knew where they were coming from, I was able to
evaluate whether and how to present it.  It's not something I can give
a firm answer on, because the correct response varies by situation.
I've had SMEs who won't share the reason, or who won't share
information at all (some of you may remember the Project From Hell post
a few months back).

The best you can do is keep trying to communicate.  For example, I had
a post mortem meeting with the client who spawned the PFH, in which I
described how hamstrung I was without information.  They didn't realize
that I was asking because *I* needed to know, not because I was going
to put the answer in the doc.  The meeting resulted in them initiating
a formal spec procedure, getting me those specs, and not releasing SW
they hadn't even checked yet to me.  It ended up positively, although I
would not have thought it was going to before the p-m meeting.  Had it
not been for the encouraging words of the others on this list
(responding to my despondent description of the problem and pleas for
guidance), I probably would have written this client off and never held
the p-m.

>I worry about completing the training and having the
>whole system change. I worry about completing the training
>and discovering that we've overlooked something fundamental.

Training is not easy.  If this the first time you're training on
something, the odds are that you're going to miss something obvious.
Sometimes it's caught easily, sometimes it's not.  Your best bet is to
have a fresh pair of eyes, as similar to the target audience as you can
find, look at the materials beforehand.  LISTEN to the questions this
person asks -- those are your holes.

>I argued for 15 minutes this morning
>about the difference between using "correct" terminology,
>using what our users expect, or using what they'll need to
>learn.

Intro material with what your users are expecting, but immediately
provide them with the correct/to be learned term and use THAT the rest
of the time.  I've done this with users from the woman who pressed the
front end of her mouse against the screen to click buttons in a Windows
class to system administrators to developers switching design
paradigms.  It works.  You have to present all the terms, or they'll
never understand it -- move from the familiar to the unfamiliar, and
link as much of the latter to the former as possible.

Whirlers, pick these ideas apart (gently, please, they're not all the
way done growing yet).  Anyone who received my Documenting to the
Question paper, feel free to pick it apart, too (privately, please,
since not everyone has read it and I don't want to take up the list's
time unnecessarily) -- I can't improve it or any of my other thoughts
without comments, and I REALLY doubt it's perfect as it stands.

I worry about all of these things, too. I'm not saying the answers I've
written above are the most perfect or only answers, they're just the
ones that I've come up with during white nights and refined during long
days.  They're things I'm still struggling with, and I'm *not at all
comfortable* at exposing my tentative solutions to the harsh world.
It's what's kept me from responding to "think questions" in the past,
but you're right, we need to think "out loud" a little more here.


--
Bonni Graham
Manual Labour
bonnig -at- ix -dot- netcom -dot- com