ANON: RE: Can a bad process make a poor writer?

[Anonymous <anonfwd -at- RAYCOMM -dot- COM>]

Message forwarded on request. Please
reply on list.

****************************

There have been a lot of postings for the past few days asking if a
good process can help build a good writer. Eric asked if the reverse
is true: Can a bad process make a poor writer?

I believe that it can.

I've been at my present company about three and a half years. For most
of that time, the process defining tech pubs and writing requirements
has been poor. And, as a result of that, I'm seeing good writers
slowly but surely turn into bad writers. And I'm seeing bad writers
turn into something awful.

At our company, there are four basic issues that contributed to this.

First, for quite a long time there was no clearly defined quality
process. We have editors, but there's no real requirement to send
material to them during documentation development. I know some writers
have -never- submitted material to the editors. Technical reviews have
been, up until fairly recently, conducted only by sending manuscripts
out for review by SMEs. If there were no comments returned, the
writers assumed the material was correct as written. And although
there was a theoretical requirement that writers exchange drafts so
that each could perform the other's written procedures, in reality
that was never done.

RESULT: For about ten years this company sent out untested and
unreviewed materials to the customers.

The next problems is that for about half the company's history, it was
a fairly small (under 500) operation, with only a handful of domestic
customers. One particular customer accounted for about 75% of our
business. When we delivered a new product, we'd send a "tiger team" of
folks out to help set up. This team would include developers, QA
people, tech support people, and the like. (Writers were rarely sent.)
The tiger team would ensure that the hardware and software were all
properly installed, and that the customer's employees were all
properly trained. I've jokingly suggested that some of the
documentation from six or seven years ago is still sitting on the
shelf in the shrink-wrap...

RESULT: The customers don't read and don't use the documentation, so
there's no feedback to the tech pubs department. The conclusion by
tech pubs is "No complaint? That must mean no mistakes."

Third (and somewhat related to the first two), the project leaders
outside of tech pubs really had little interest in the content or
accuracy of the documentation. The emphasis instead was upon simply
delivering "a doc set." The attitude of these managers was clearly
that they wanted a neat, printed, bound set of books to load into a
box for shipment on the delivery date, along with the software. Given
a choice between bad docs on the ship date or good docs a week late,
the managers wanted the version that would hit the ship date.

RESULT: The motivation to ensure accuracy takes second place to the
motivation to hit the schedule.

And finally, there was no regular method used to deliver documentation
updates to the customers. In theory, we have a mechanism to supply
change kits. In practice, these kits aren't done to correct errors,
only to supplement the baseline when new optional products are
installed.

RESULT: Once a customer gets a mistake, they are effectively stuck
with the mistake for life.

It doesn't take a writer too long to realize that working for my
company is a pretty good gig. The pay is good, the working environment
is good, you can start your stroll out to the parking lot at 5:00
every day, and as long as you've got that doc set ready for delivery
on the due date, nobody in management is going to breath down your
neck. What's that, the deadline is here and you don't have the data?
No matter, just leave it out. Nobody cares.

Unfortunately, things have changed here in the past few years. We've
tripled in size. We no longer cater to a handful of domestic
customers, we've got customers scattered around the world. We can't
send out tiger teams to ever customer, so as a result more and more of
them are starting to rely on the documentation.

What those customers have discovered is that the foundation of the doc
set is rotten, the procedures don't work, material is missing or out
of date, and their chances of getting updates are slim. In a recent
survey of customer satisfaction, the doc set was the number one issue
with the customer, and was consistently the area with which they were
least pleased.

You'd think that this would light a fire under the tech pubs folks,
and that they'd be working full time at correcting the errors. I wish
that were so. What has happened instead is that the folks who have
been here the longest (and grown most comfortable in the workplace)
have been fighting a rearguard action as they try to defend what has
been written in years past.
(A recent example of this, and to quote Dave Barry "I am not making
this up,": I showed a section of the tech manual to a manager and said
"Hey, your people need to make a change here. The first table in this
section is numbered as Table 2." The manager's response was "Yeah? So?
There's no requirement in our spec that we start the table numbering
at 1.")

There is some good news. About a year and a half ago, higher
management (i.e. "above tech pubs") recognized the problem, and made
major changes in the process. Now, nothing (and I mean NOTHING) gets
to the customer until the QA department has reviewed it with a fine
tooth comb. And there's a guy in the QA department who does nothing
except review and test the written procedures, 40 hours a week. That
guy can be a real jerk sometimes, 'cause if the procedure doesn't work
I..er..he won't hesitate to write up a defect (and a correction to the
procedure).

And the docs don't go out the door until the errors are corrected.

(And for all of those reading this who are working in defense
contracting and are saying "Geez, that sounds like validation and
verification"...yep. It is. I used USAF T.O. 00-5-3 and USN NAVAIR
00-25-600 as guides when I wrote the QA doc testing policy.)

Our last major software release was a bloodbath for the doc set. There
were 40 major defects filed against the software, vs. about 180 major
defects filed against the doc set.

But doggone it, for once in the history of this company, we released a
doc set full of procedures that stand a fair chance at working.

I've asked that Eric post this anonymously for one big reason. I'm not
afraid of backlash against myself. Some of you reading this figured
out who I am, and if some of you reading this are working at the same
company I am, you -definitely- know who I am. I have no heartburn with
that.

But we've got a number of good writers at our company. I know some of
them are looking for jobs right now. I'd hate for any of them to have
their chances poisoned by a hiring manager who associates their resume
with the comments I've posted. That would be too bad, as the good
folks are the ones leaving, and the bad ones are staying here where
it's comfortable.

But to answer Eric's question: Can a bad process lead to the creation
of a poor writer? You bet it can. I've been watching it happen right
here.






*****************************
Message forwarded anonymously on request.
Please reply on list if you want the original
poster to see the message.

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=