TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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
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
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
Tech Writer - IS
Siecor Operations, LLC
Hickory NC 28603
debbie -dot- stewart -at- siecor -dot- com