Write and They Will Come

Subject: Write and They Will Come
From: Debbie Stewart <Debbie_Stewart -at- SIECOR -dot- COM>
Date: Wed, 11 Mar 1998 11:14:45 -0500

HELP. If you were a new tech writer and went to work for 35 programmers in
a department that had *absolutely* no infrastructure existing for
documentation procedures and were the first tech writer hired there, where
would you start?

Obviously, the old sage that said "Write and they will come" did not work
with programmers.

Background: most of what I will be writing will be used by computer
operators, systems analysts, programmers, and networking personnel. My
primary customers are personnel within the department. The result of this
documentation will also evolve into user training/procedure materials for
customers in other departments. We have a large enterprise system and work
in a Lotus Notes environment. I have databases which will act as central
repositories, so the technology end is covered. We have applications that
cover manufacturing, order processing, financials, and taxes, etc. - all
the usual business flows.

What documentation there is is scant, and found in Lotus Notes, Word, loose
leaf paper, and in old manuals and on individuals' PCs, Notes databases, in
hardcopy forms, and in many brains.

Plan of Action: I am trying to get management to buy in and promote this
documentation process. Yes, I have been hired but not empowered. No one has
time because they are putting out fires. Management by crisis and adhoc
culture reigns.
1. I am putting together information to give to management to show
that documenation needs to be promoted by them and made part of the product
and a mandatory part of the applications process.
2. Develop a plan that covers what the documentation consists of for
existing and future applications.
3. Chart a process for developing documentation procedures and
4. Start developing documentation standards and departmental style
5. Give target areas (i.e. Operations - updating computer and
operations manuals; document architecture and standards; update disaster
recovery procedures; Applications - document architecture and standards and
critical business applications first, then be made part of the process from
the begining on new projects, document existing applications;
Networking/communicaitons - document disaster recovery procedures,
architecture) and time lines.

Can you give any suggestions whether or not these five items make sense or
what is missing. Where do I go to get proof for the pudding - how do I find
information to back up my reasons for documenting (besides the fact that we
have lost a lot of good programers and their knowledge) Has anyone out
there started a tech writing department from scratch and what are your
experiences and advise? How do you go from convincing personnel that
documentation is important to implementing the procedures? When programmers
are busy putting out fires and the new ones are looking for answers and
help, how do I get in the picture and produce something that is added
value? Do you have advise where I can learn more about the *hows* than just
the *whats*???? You folks out there have some incredible experiences and
knowledge. I hope to one day be able to help new tech writers and return
the knowledge!

Debbie Stewart
Tech Writer - IS
Siecor Operations, LLC
Hickory NC 28603
debbie -dot- stewart -at- siecor -dot- com

Previous by Author: Frame Training
Next by Author: SUMMARY - Write and They Will Come (long)
Previous by Thread: search engines
Next by Thread: Re: Write and They Will Come

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads