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.
RE: Procedures for Documentation for Release and Upgrades to Soft ware
Subject:RE: Procedures for Documentation for Release and Upgrades to Soft ware From:Megan Golding <mgolding -at- secureworks -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 27 Mar 2001 15:13:36 -0500
Shannon (mailto:shannon -dot- morris -at- gen21 -dot- com) asked
"Do any of you have procedures in place for the type of documentation that
you create to help facilitate information flow throughout an organization
when anticipating a new release or upgrade."
Shannon (and everyone else),
I often am called upon for exactly the sort of internal information you
describe. Recently, I was asked to provide a "feature summary" for a new
version of our software that is in development. The audience, as it turned
out, were our board members, marketing, and sales teams.
First of all, I maintain a section on our intranet for information designed
to flow from the technical team to marketing, sales, and customer care. I
publicize the URL internally so that the entire company knows they can go to
the intranet first for technical information. Every document is maintained
with a summarized revision history. For example, near the top of one
document is this text:
3/20/01 mgolding added text to "The Cool Feature" section
With revision history, any visitor to my little site knows if new info has
been posted since his/her last visit. With the intranet site, coworkers know
to check there before asking me for information. Often, their questions are
answered by info I've posted for other groups.
Another aspect of this information flow is timing. I find that talking about
new features too early in the process is very dangerous. So, I don't give
out Feature Overviews until features are committed to and in development.
Information needed before that date is generally very high-level. After our
feature set was chosen and development had been underway for about a month
(approx. 1/3 of the way into the planned development schedule), I wrote my
document which was a Feature Overview.
The Feature Overview was broken down as follows:
Overview of All Features
Good luck with your project and I hope this has been helpful.
(mgolding -at- secureworks -dot- net)
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.