Internal communications?

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

Steve Shepard is <<... the technical communications manager for a software
company.  We have doubled the number of employees and quadrupled revenues in
the last four years... a lot of growth in a short period of time. One of the
biggest problems now is getting the information we need to write docs. A
couple of years ago the entire technical staff (programmers, QA, docs,
technical support, etc) were all on one floor. As changes were made to the
programs, or new programs where initiated, you just heard about it. Now we
are spread out between four buildings with the docs group in a Victorian
house down the street.>>

The trick would seem to be to formalize what used to be informal. Ideally,
this should be done from the top down (someone Really Important should make
it company policy, thereby clearing the way for you to begin formally
becoming part of the development process). Realistically, that might not
happen, so you'll have to come up with a different approach. The various
project managers who actually supervise production of the stuff you document
must periodically hold meetings with their own staff--either as a formal
project team or informally, as in "management by walking around"--to discuss
project status, identify problems, and do whatever it is that managers
really do. <g> You need to attend these meetings. Every damned one if they
meet in groups, but a representative sampling if they meet individually.
When you explain why ("so we can produce documentation in time for you to
meet your ship dates"--always express things in terms that they understand
viscerally), most of the managers will be happy to invite you to the
meetings. You don't have to actually do or say much at the meetings, but you
do need to be present so you can hear what's going on and plan accordingly.
In some companies, the managers don't meet in groups with the people they
supervise, but do meet together in management meetings; getting yourself
invited to these meetings is one good way to find out what's going on. (I've
done this at my current job, though now that we've got a new manager, it's
his job. Amen. <g>)

Some managers won't cooperate, usually for no good reason; for those with
good reasons, you can usually figure out a compromise that addresses their
objections. If you've got the brass, and enough support from your manager,
attend the meetings anyway--though be aware that you'll be stepping on toes,
and that this might not be the most politically intelligent move (you may
have to defend yourself to your manager or someone higher up the pecking
order). Other alternatives: identify members of the project teams and
befriend them, so they can provide the information you need. Since that's a
lot of work for you, it might make sense to get the more diplomatic of your
own staff to do this job for you: after all, since they'll have to talk to
the developers anyway, they might as well get started _now_ getting to know
their colleagues and developing good working relationships. (Heck, aren't
you being paid to delegate? <g>)

<<There are no project teams, there are no design specs... So getting
information is difficult.>>

Even if there are no formal project teams, there will still be formal
supervisory arrangements in place that you can take advantage of (see
above). You could add enormous value to your company if you can persuade
senior management of the value of project teams and design specs, but even
if you don't, understanding how information really flows (usually not what's
shown on the organization chart) will be a huge step towards understanding
what to do about it.

<<I have considered insisting on a formal request system for docs, but
because the cultural of this company I am sure it would meet a great deal of
resistance.>>

Plus, that just adds a layer of red tape. If your company's flagship product
arrives with no prior notice, ready to ship and with documents required in 2
weeks, are you really going to say no? (You may say a lot of unpublishable
things, but you're still going to have to produce docs of some sort.) If an
informal approach has worked in the past, you should be able to figure out
how to use the same approach in the future. You'll just have to add
"intelligence gathering" to your list of daily duties. A pain in the ASCII,
but there you have it, and frankly, that's why you're being paid to manage
the technical communications. (And one of about a dozen reasons why I
wouldn't have the job for double the salary.)

--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