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:Re: Document Change Management System From:Robert & Betty Gravlin <rbg -at- TETRANET -dot- NET> Date:Thu, 12 Dec 1996 09:47:22 -0600
To Maureen Gordon,
Where I used to work, we had change request software that we developed
for our in-house software development. It had a user screen that
had a database for the info that was entered.
You entered the category of software, the transaction code or program
that needed change, priority, description of the change, the system
analyst, programmer, tech writer, configuration manager, and requestor.
As each person did their job, they signed off on it and entered the
date.
As the job progressed through the cycle, the status changed from New,
Work in Process, To Production, Moved, and Closed. You could sort
the jobs by status, user ID, programmer, transaction code, category,
etc. When it got to moved status, I knew it was time for the tech
writer to work on it. When I was finished, I changed the status to
closed.
You could also enter more detailed specifications and cross-reference
to the help desk software log numbers. There was also the function
that let you search for all the changes that had ever been made to the
program. All you did was enter the program number, programmer, or
transaction code.
It was a type of work group software. It was useful for letting
everyone on the team know what was being worked on. It prevented
programmers from starting to work on something someone else had
already started. It kept a history of what had been done.
The users had read-only access to the log so they knew the status of
their request.
When working in an environment where there are no scheduled release
dates (every day is a release day), it was very useful.
Our users still had to call the help desk to make a request because
not every call required a program change. We didn't let them fill
out change requests.
There was also a check box that indicated whether documentation (me)
needed to work on the change log.
We tried a paper change log system, but it didn't work. This company
always worked in crisis mode. They responded to problems instead of
planning the work. This change log software is the only way they
could manage the crisis of the moment.
I hope this helps.
Betty Gravlin
--
St. Louis, MO USA
