Re: Devr. wants to take over doc.--long response

[Sella Rush <SellaR -at- APPTECHSYS -dot- COM>]

There seems to be two issues here:  delivering the product and getting
updates done.

Issue 1:  electronic deliverables is certainly an option, and I would
(in fact I am) do a serious analysis of how the print vs. online issue
applies to your situation(s).  This, of course, will depend on the
capabilities and inclinations of AD's clients.  If you send them an
electronic file, are they comfortable using it or, if not, can they
print it out?  If they do print, how will a lack of decent binding
impact them?  How will a lack of professional appearance (no binding or
cover) affect their opinion of the product?  If everyone's ready to jump
online and eliminate paper (an interesting phenomenon at Weyco, I bet),
then you've got some interesting times ahead of you figuring out what
format(s) to use and creating them.  In any case, in your presentation,
you can show that the benefit in Mickey's point #1 is a little more
complex then he presented; that it's a valid suggestion but needs a
little more thought and investigation.

Issue 2:  Why does the formal documentation need to have such a quick
turnaround?  I'd find out in what circumstances they are making changes
to the product.   I'd definitely take up "Minnie's" cue and find out
what this unique work environment involves that makes immediate
turnaround so unquestionable.  Interesting that Minnie says she creates
version updates every 2 months--this would seem to provide plenty of
time to communicate with you and work in parallel--is there something
about this work environment that prevents this?  In my experience, these
continual updates for customized products are very common--it sounds to
me like she just needs to incorporate you into this two-month cycle.  I
would definitely work with her on looking at specific projects and
figure out a way to work together to relieve her burden and still get
the documentation done within a day or so of the final product changes
(which would be part of the cycle).  I find Mickey's comment about a
bottleneck interesting also--he's talking about documentation updates
here rather than delivery, I think--it seems to suggest that the
documentation is either done or he is perceiving that it is done at the
end of the product upgrade, rather than as a parallel process.  In your
presentation, you might want to discuss this idea--either as the
unperceived reality or as an improvement to the divisions process.  With
parallel upgrading, it is unlikely you would be unavailable for the
whole project.  Also--I just noticed--he said "unnecessary bottleneck."
You might want to comment on this--documentation effort is not
unnecessary--and someone still has to do this--him or you.  So that
eliminates his benefit #2.

Note:  If they're making changes to the product "on the fly" (within a
day, as a result of tech support issues) then why are corresponding
changes to the formal documentation absolutely crucial? Can't they issue
a readme file with the changes and follow with formal documentation
updates within a couple of days (or even better on a regular schedule)?

Another note:  what's this "remote site" business?  You're working in a
different office than the programmers?  Maybe this is the problem--they
don't see you working and you don't see them.  This may be one reason
why they're anxious about having to rely on you at crucial times and are
unsure about securing your time for their project.  Better communication
is the key here.

As I've written this opus and checked back with your post, it's become
pretty clear that either (1) they don't have enough access to your time,
or (2) they don't grasp this team process.  I would definitely stress
the QA concern and, of course, the benefits of professional techcomm
documentation, but I would also make an obvious effort to understand
their concerns and meet them.  As is always the case, when someone has a
concern, they also have a solution to go with it.  The solution may be
shortsighted and even disastrous, but that doesn't negate the concern.
(I certainly wouldn't respond by quitting or digging a defensive
perimeter, just because their solution isn't very good.)
>

 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