Re: My terrible client... Technical Writer Horror Story Number 3056

[John Kohl <sasjqk -at- UNX -dot- SAS -dot- COM>]

In article <9610101530 -dot- AA07701 -at- plamondon -dot- com>, Robert Plamondon
<robert -at- plamondon -dot- com> writes:
|> One way to deal with clueless clients is to set one's "consultant" hat
|> firmly on one's head (tossing away the one marked "temporary help").
|>
|> As a consultant, the most important task is to identify and suggest
|> corrections to problems.  Your second most important task is to actually
|> correct the problems.
|>
|> Periodically reporting on the project's status (and distributing the
|> report properly) helps quite a bit.  Concise status reports that can
|> be read and understood quickly often spur people into something resembling
|> action.
|>
|> One possible format goes like this:
|>
|> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|>
|> STATUS REPORT, BLAH-BLAH USER'S MANUAL
|>
|> PROGRESS
|>
|> (things that got done)
|>
|> DELAYS
|>
|> (I'd put this in a table)
|>
|> ITEM                SOURCE OF DELAY             MAGNITUDE OF DELAY
|> -------------------------------------------------------------------
|> Review of First Draft
|>                      1. Reviews not turned in    One week and growing
|>                         (list of missing copies)
|>                      2. Reviews performed by      Unknown, est. at 2 weeks
|>                         non-experts instead of
|>                         the requested experts
|>                         (list of switcheroos)
|>                      3. Reviews returned without   Unknown, est. at 2 weeks
|>                         markup
|>                         (list of names)
|> [etc.]
|> -------------------------------------------------------------------------
|>
|> COMMENTARY:  The failure of the design team to perform the comprehensive
|> review, as agreed, is an extremely ominous sign at this early stage of
|> the documentation process.  Unless the agreed-upon thorough review is
|> produced right away, it will be impossible to produce the kind of
|> accurate, thorough, timely documentation that I was engaged to create.
|> Perhaps you should consider abandoning this documentation project
|> entirely, as the necessary support seems to be lacking.
|>
|> If you like, I can create a new proposal that assumes that the engineering
|> staff will be no more helpful than they have been so far.  The necessary
|> reverse-engineering will make the project more expensive, less accurate,
|> and considerably later than it would have been under our original plan,
|> but it will put less of a burden on your technical staff.
|>
|> Yours Truly,
|>
|> John Q. Publications.
|>
|> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|>
|> Such a report takes your professional judgement and turns it into something
|> that management can use to make decisions.  That's what consultants are
|> for.  You've given them the bad news and shown them three of their four
|> basic choices (which are to drop the document, muster up some commitment,
|> switch to the working-in-a-vacuum mode, or -- not mentioned -- drop the
|> consultant and shop around for a second opinion).
|>
|> Most importantly, it puts management in charge of making the business
|> decisions.  They now have to explicitly face facts or dismiss them.
|> YOU are only shouldering the burden of holding up your end.  THEY are
|> responsible for holding up their end, and you're making it easy for
|> them by pointing out all the things that are and are not working.
|>
|>         -- Robert

I think it's more likely that the Neanderthals that the original poster
was dealing with would respond to the above by accusing her of not being
a "team player" or of having a "negative attitude" and telling her that
if she couldn't do the job, they'd find someone to replace her!


John Kohl
(speaking my own opinion, not representing my employer)