Re: Resumes and SMEs

["Wing, Michael J" <mjwing -at- INGR -dot- COM>]

>Just out of curiosity, what do you guys do when you're
>faced with a difficult SME situation?
>
>Melissa Hunter-Kilmer
>mhunterk -at- bna -dot- com (standard disclaimer)
>
First, I'll mention two techniques that do not work (at least in my
experience and observation):

1)  The journalist/reporter approach.  This is the blank page, let's
start from the beginning approach.  The SME has to be thinking, "How
long is this person going to be in here?"  With the blank page, the SME
omits much pertinent information or often has to backtrack many of
his/her statements.  It also looks like the Technical Writer has done no
groundwork, and instead, wants the SME to spoon feed every morsel of
information.

2) The I'll-make-a-template-and-have-them-fill-it-out approach.  Trust
me, SMEs hate these.  It's like a homework assignment.  Most often,
these templates-to-be-filled-out become templates-to-throw-out.


Instead of these approaches, I research the information, test the
product (if possible), and approach them with specific and direct
questions.  I find that this focuses their
thoughts much better than "Tell me everything you know about ...".  I
feel that they provide much more information if they are correcting what
I have wrong (especially if they think the document is going out that
way) than if I say "let's start from the beginning".

Therefore, initially, I write a lot of fiction.  After writing the
fiction, I let them slam me about what I have wrong.  It's amazing how
much more information you can get if they think you have it wrong rather
than if they think you know nothing (blank page).  I've often had to
excuse myself because my head is going to explode with all the data
coming my way.

One technique I use is the Trojan horse.  Because I write programming
reference guides, I can get them where they live.  I approach them with
a code problem (the Trojan horse).  This always gets there attention
because I may have found a snag in their application.  I tell them what
I can't get to work, how I got around the problem (or how the program
crashed and burned), and then have them look at the code.   As we review
and test the code, I'm asking them all sorts of stuff about their part
of the application (this is the soldiers exiting the Trojan horse).
This technique works better than the others.  However, it works because
I have a good technical background.  It's very hard for them to snow me.
 It helps greatly in getting close to the point with the fiction part
and it helps with formulating follow-up questions.

Another technique is the lawyer approach (without the adversarial
overtones).  I take what I know about the product and ask them, "If this
and that are true, how can . . .".  This is like the shave-and-a-haircut
knuckle rap.  It's almost impossible for them not to add the two-bits
response.  To use this approach, you have to prepare and research the
material thoroughly beforehand.  Otherwise, it backfires.

I also try to keep the contact time to 15 minutes or less per
interaction.  This keeps focus on the next block of information in which
I have to process.  I can get into detail on a few items without turning
it into a prolonged affair.  Therefore, the next time I contact them I
am less likely to be met with "I'm too busy", "It's going to change,
talk to me later", or the tacit responses indicating that their main
objective is to send me away.  Often, after a leading question
(especially if I have a few premises incorrect, it is they who extend
the session).

>Mike Wing
> _____________________________________________
>|   Michael Wing
>|    Principal Technical Writer
>|    Infrastructure Technical Information Development
>|    http://www.ingr.com/iss/products/mapping/
>|    Intergraph Corporation
>|    Huntsville, Alabama
>|    (205) 730-7250
>|    mjwing -at- ingr -dot- com
>

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html