Re: contract editing (re...

[BurkBrick -at- AOL -dot- COM]

>(1) Consider this scenario: Engineering begins development
>of a new product. About two months into the project, tech pubs
>gets involved.

I used to get involved at the beginning of a project. The only real problem
is that sometimes you get
information that just doesn't apply in the final project. The worst case of
this was a contract job I had last
year in which we were rewriting all of the online help weekly. If I had
responsibility and could do it over
again, I would:

1) Still get involved in the early stages. You can plan much of the structure
and put together basic text. If
you're lucky (and persuasive), you can influence decisions on word choices
for keys, messages and such
before they are difficult to correct.

2) Do one draft with details, then sit on it until the product is relatively
finalized.

It's hard to sit on a document when you have a looming deadline, but in this
particular project, we were
changing details back and forth as the whims of management influenced the
projects. We could have been
much more productive if we had concentrated on other tasks, or just taken a
week of vacation (actually, I
did at one point - I got back and missed a whole series of changes that I
would have had to change twice.)
Of course, if they listened to my advice, they probably wouldn't have needed
me. :^(

>The training developers use the same source
>information as did the publications people.

I think the trainers should be working off the publications people's
material. It seems silly to go to original
source material and ask the same darn questions all over again. If the tech
pubs were done properly, they
should contain all the information that training needs, plus lots of extra
stuff. I would give training copies of
the documents and let them cobble it up as needed to meeting training needs.
The training documenters can
be used as a Beta test this way, too. The more input, the better, as long as
someone has final authority.

>(2) These five people get on an airplane, attend
>training class in a distant city, and return to their jobs,
>but they use the product they were trained on infrequently.
>Any problems here?

I'll say! Wasted money. It'll be interesting to see what other people think,
but I think you should only send
one or two people to a single-topic class or seminar. They should summarize
the results (that is, do a trip
report when they get back, or hold a meeting to discuss the class, or both)
and bring back training materials
for the rest. I would only send one person the first time - make sure it's
worthwhile before sending everyone
else. Also make future trips dependent on the trip report and meeting results
(although, contrary to popular
belief, I think many people would rather not travel because of family or
other concerns, so fights over who
gets to go are limited. I think more controversy is over who gets _asked_ to
go; but if some people were
asked, they'd refuse.)

>(3) Marketing consults with a major customer to identify a new
>function the customer needs in a software product. Marketing writes a
>requirements document, engineering interprets it as a specification,
>engineers develop the new function, and it is delivered to the
>customers. When the major customers' employees get it, they say,
>"What is this? I can't use it? It doesn't do anything I need!"

*Sigh.* This happens much too often. I think it happens because marketing
talks to upper managers, who
don't know the nitty-gritty of the day-to-day tasks of their employees.
"Sounds good," they say. The
employees know little or nothing about this until they receive the product,
but then it's too late to change.

Anecdote time:
My husband worked in the service department of his company before he got his
electrical engineering
degree. While he was out in the field, he would talk to the end-user of the
product, and watch what they did
on the job. From this information, when he did become an engineer, he
designed the first million dollar
product the company has ever had (you bet I'm proud of him; just wish he'd
gotten more than a pat on the
back).

Upshot: I believe this is the best way to do marketing. *Watch* people use
your product in their
environments; *talk* to them about what they like and don't like; and send
someone who knows enough
about the technology to see where things could be improved. People often
won't make suggestions (or just
say "I want it cheaper and faster") because they don't know how it could be.

Technical writers could probably fill this role, although they might not know
quite as much of the
technology (I'm coming from a hardware background, and I do try to know my
limitations). As technical
communicators, we are much more concerned about audience and usability than
many engineers. I also
think we're a little higher up the food chain than your average marketer - of
course, this opinion _could_ be
biased. :^)

(Coming out of fantasy-land now.)

I'm interested to see what other people have to say -

Barb Philbrick
Caslon Services
Cleveland, Ohio