FWD: Re: SERIOUS: Formal vs. informal organizations

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

Name withheld upon request. Please reply on list.

*************************************************
Matt Ion wrote:

>I think that's ESPECIALLY true for a technical communicator.  Other people
>have information and knowledge you need, and often have no good reason to
>simply give it to you.  Extracting the necessary information in a timely matter
>can be a direct result of the relationships you build with those people.

I agree completely. However, there are some people who no matter how hard
you try you can't possibly build up a personal bond with them. Yet you still need
to get information from them, and if they don't give a rat's bottom about whether
or not the product ships with good or any documentation, you're not likely to get
what you need. That's where formalized procedures can come in handy.

I am strongly in favor of formalized procedures, but I don't think they should
get too detailed. They should do things like outline who is responsible for
producing what by what date and specifying a minimum level of quality. Review
and approvals should also be a part of the process. I think formalized
procedures, if handled the right way, can help people who need a little bit of a
push to organize themselves better. Style guides, though, are way over the top
and stifle creativity IMHO.

In my limited experience as a technical writer (two years), I've noticed that if a
product spec is lacking, I'm the first to notice (and suffer) because of it. Then
sales and marketing notice when they go to write their sales stuff, then more
and more people notice when the product that's going out the door isn't exactly
what people thought it would be. A good spec early on saves a lot of
headaches.

We're undergoing a lot of changes here, trying to focus on planning well and so
reduce the time it takes us to develop stuff. When I started my job, I was
documenting two products. Product spec #1 was written by SME #1, it was
very detailed and the SME was willing to provide additional info. Of course,
because the product spec was good, I didn't have to ask very often. Product
spec #2, however, was written by SME #2. SME #2 is not interested in
communicating anything to anyone in any medium. It's been a nightmare for
me trying to guess at what should be in the documentation because I have no
real product spec and an SME who only answers questions you already know
the answer to.

The manager of these SMEs knew product spec #2 wasn't good enough, but in
the interests of work going ahead, let it go. He knew there were going to be
problems, but there was nothing formalized in the company that said the spec
had to contain certain information, just that it had to exist. I was the first to have
real problems as the result of not having a good spec. Then another SME had
problems, since his work was related to product #2, but because the product
couldn't ship without his stuff (but can, of course, without docs) he got the
co-operation he needed, but only after much angst. Then sales couldn't figure
out what features they should be pushing. Now, product #2 is having to
undergo considerable rework whereas product #1 is having very little rework.

I feel like I've been burnt by the company's lack of organization -- my job was
made a whole lot harder than it should've been because of poor planning, and I
could've produced better documentation with that time pursuing information
that in some cases I never got. Fortunately, though, other people feel the same
way and new processes are being introduced and test driven on our next
project. So we'll see what happens.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Message forwarded on request. Please reply on list.


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