Re: FWD: Help! New Job, No Docs, Big Company

Subject: Re: FWD: Help! New Job, No Docs, Big Company
From: Michael Collier <mcollier -at- CSC -dot- COM>
Date: Fri, 2 Oct 1998 11:48:15 -0500

I think you need to be careful here because while there's plenty you can
contribute, you don't want to get stuck with documenting everything. Roles and
responsibilities need to be clearly defined and you need to make sure that
management does that, otherwise anything that requires documentation will get
thrown in your direction.

In situations like this that I've been in, business analysts have been responsible
for documenting the business processes that the system will be automating. Tech
writers can certainly help edit these and pull them together, but it's the BAs who
do the thinking about what needs to be modeled. These documents that they create
are called (at least in the worlds I've been in) business process descriptions.
Basically every business process that the system will be automating needs to be
documented, and this is way over the head of two tech writers, unless you have
accounting backgrounds.

These busines proces descriptions are usually created in accord with the software
development methodology. You should be able to find some discussion of documenting
business processes in software methodolgy and analysis and design books. If your
organization does not follow a methodology, ad-hoc methodologies can (and often
are) used but I think it's way beyond the tech writer's role to define that
methodology and make sure it is adopted and adhered to. That's a job for the
project manager or director of software development.

When the business process descriptions are done, then software project
descriptions can be created. These purport to show how the system under
development will implement the business processes. Again, as with the business
process descriptions, the tech writers can contribute to these but the main
thinking has to be done by the software developers.

From the software project descriptions the tech writers can get a good idea of how
the software is expected to function and they can plan the user docs, help,
training materials, etc. from there.You may be involved with the developers in
producing a functional specification out of the project descriptions, which
provides more detail and can serve as a prototype user guide.

Basically there's a lot of documentation that needs to be produced and the tech
writer can't produce all of it. A good deal of it, in my view, is the
responsibility of BAs and developers. Since there are a lot more of them than you,
you or you project management needs to mobilize them to define how it gets done
and by whom.

Michael Collier
mcollier -at- csc -dot- com


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



Previous by Author: PNG Graphics format
Next by Author: Re: Mid-level TW Blues Resolution
Previous by Thread: Re: Help! New Job, No Docs, Big Company
Next by Thread: Re: FWD: Help! New Job, No Docs, Big Company


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


Sponsored Ads