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 numbering system From:Todd Snarr <todd_snarr -at- AUTOSOFT -dot- COM> Date:Tue, 5 May 1998 08:31:51 -0600
I've been pounding my head for the last year on this topic, trying to come
up with some scheme that will meet the needs of the software company where
I work. I've decided that I can come up with a nifty numbering convention,
but then what? How am I going to get 200 employees to start using it for
their documents? (Our documentation effort here is "decentralized"--we only
have two writers.) Ideally, for this company at least, it would be best to
come up with a scheme that would require little training. And frankly, I'd
rather spend my time documenting software, not coming up with and managing
numbers for all software-related documents developed here.
Our solution for now is to base our document numbering convention on the
corporate project numbering convention already in place. These corporate
project numbers are generated with our accounting system. Every employee
uses these project numbers to account for their time each week on their
timecards. All engineers working on a product install for a particular
customer bill their time to the project number for that customer. Even
baseline products here that aren't yet customer-specific have a similar
project number.
The scheme for this corporate convention is as follows: 0150030-8001 where
01 = the office (we have 5 different offices at this time), 50 = the
department (we have about 15 in all), 030 = the product or activity center
(we have about 30 of these), 9 = the year of inception (we go by the fiscal
calendar, in this case 9 = 1999), 001 = the numerical order (001 = the
first project in the year).
To relate this accounting number with a document, we've just added a
two-character document type (for example, FS for functional specification,
TP for test plan (not toilet paper), DP for documentation plan, UG for
user's guide, AG for administrator's guide, OP for operator's guide, OH for
online Help, and so forth) and a revision code.
So, the number 0150030-8001-UG-A tells me that this is rev A of the user's
guide for a particular office, department, product, and year. Why do we
need the office and the department in a document number? Because in our
case, two different offices and departments can be working on the same
baseline product, but developing different versions for a particular (or
different) customer. And these different versions will need their own
fspecs, design docs, user guides, and so forth.
One of the disadvantages of this method is that it's TOO LONG. (I'm sure
other disadvantages will surface later.) But, without file naming
constraints in Windows anymore, we can archive documents using this same
number...and again, engineers and other employees are very familiar with
this orignal accounting number. We will just have to train them on how to
use the two-character document type and rev number. It would be great to
use something a little more intuitive like PPP-V.V.-DD-R, where PPP = a
product identifier, V.V = the version number, DD = the document type, and R
= the rev number, but here "versions" and particular customer needs make
things very gray.
Our Word templates are set up so when they are initially opened, prompts
ask you for the document title, number, revision, date, and so forth. The
document number is automatically placed on the cover and in the footers for
all documents.
Just some ideas to think about...
Todd Snarr
Senior Technical Writer
Auto-Soft Corporation
Salt Lake City, UT
todd_snarr -at- autosoft -dot- com