RE. Are my docs un-useful?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

"Anonymous", who surely gets into more trouble than the rest of us
techwhirlers <g>, has a dilemma: <<My audience often does not think they
need my docs, but my project manager thinks they do.>>

What is the manager's basis for his decision about what the customers want?
From what you say later in your message, it seems like the manager is
relying solely on anecdotal evidence (e.g., "Well, we know they'll never
read it," "They
wondered why they received/paid for X document") rather than hard facts. If
three of your 10 000 customers call up to complain about getting docs they
don't need, and the rest remain silent, then what other opinion could he
possibly get than that your docs are "un-useful"?

<<I don't like the feeling that we're spending time perfecting documents
that no one uses, which lack information the clients want, or which are
really just part of project development (project approach aids).>>

The trick in these cases is always to figure out how you can go right to the
source to obtain this information: talk to your clients, to the tech.
support staff that solves their problems, and to the trainers (if any) who
teach them how to create those problems. <g> How to do this? You'll have to
persuade your manager that there are an awful lot of opinions, but no really
good facts. Try the following approach:
- get facts (statistics) from the tech. support and training staff about the
kinds of questions they're asked
- ask Marketing and Sales what kind of problems or issues the customers
raise (treat this with healthy skepticism, but don't discard it out of hand)
- bring these facts to your manager and point out the following: we're
wasting money producing docs that nobody wants or uses, and contacting the
customers to find out how you can better serve them will create enormous
good will (thus, future sales and good word of mouth advertising).

<<In addition, it seems like some of our documents are substitutes for a
good, clear understanding with the client>>

Customer service is dead (or in a persistent vegetative state) in most
organizations, so this doesn't surprise me. Someone (any volunteers?) needs
to act as the voice of the customer in making sure that these clear
understandings are reached. Include a documentation plan in that
understanding and you're well on your way to a productive, long-term
relationship with those customers.

<<after reviewing some of thse docs with clients they respond with "I paid
for this?/Why did I want this?">>

Either explain to the client why they paid for and want what you're
providing (and blush gracefully when they fall on their knees in gratitude),
or find out why they're questioning what you provide. I suspect that the
latter approach will be more productive.

<<if the client doesn't see a need for/ understand why we do what we do,
then where does that leave us?>>

Seriously vulnerable for being replaced by the first "two guys in a garage"
dotcom company that offers the same service at a greatly reduced price, even
if they do a lousy job of it. Apart from having produced great products
(plus a few clinkers), successful companies like IBM became and stayed
successful by forging long-term relationships with their clients (the
archetypical "schmoozing"). IBM in particular has reinvented itself as a
service company that emphasizes this relationship. I can't say how well it
actually works in practice, but all I've read says that IBM is doing very
well indeed from this strategy.

<<Where does that leave me, as the writer of the unread though meticulously
put-together documents?>>

As the logical sacrificial victim when things go sour?

<<What can I do to help make sure clients want what they need to have a
successful project?>>

Sometimes it's all a matter of how you present things. I've occasionally had
one of those "D'oh!" moments with an author when I explained (in terms he or
she understood) why I'd edited something in a certain way. But doing so
relies on a dialogue, and so far, it sounds like you've got strictly one-way
communication going on.
  
<<I'm wondering if we need to spend more time soliciting clients'
expectations/ requirements pre-kickoff, so that we understand what they
expect during the project.>>

Unquestionably. In particular, you need to both set and manage those
expectations: try to understand what they need (audience analysis!),
convince them (gently) of why they need it, and provide what they need. And
work with them (usability testing!!!) to make sure that you've succeeded in
understanding, convincing, and providing. In the long term, you'll develop
an approach that works for 95% of the clients, and you can do less
monitoring. But in the short term, it's going to take a lot of trial and
error to develop that approach.

<<I don't see the "pre-contract" client; our sales managers do...>>

Then the sales managers are the ones you need to be working with and
persuading. Good luck!

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer