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:
Revision History:
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
Feature X
Description
Benefits
Feature Y
Description
Benefits
(etc.)

Good luck with your project and I hope this has been helpful.

Regards,
Megan Golding
SecureWorks, Inc.
(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.


Previous by Author: RE: Outputting to HTML and PDF formats?
Next by Author: Designing a Knowledgebase
Previous by Thread: Summary: Experience/No experience
Next by Thread: .WMF or .EMF graphics


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


Sponsored Ads