RE: Doc version control - in-house

Subject: RE: Doc version control - in-house
From: "McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>
To: "salt -dot- morton -at- gmail -dot- com" <salt -dot- morton -at- gmail -dot- com>, "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Wed, 21 Apr 2010 15:40:35 -0400

Chris Morton suggested:

> Well, I certainly *cannot* recommend Quadrite's RitePro.
> Among other issues,
> they refuse to listen to any customer input regarding their
> clunky web-based
> UI, always stating, "It was specifically designed that way!"
> We're now looking ourselves (again)...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Can you give some hints as to what fails or what you
find annoying about using the product?

I have two areas of interest... only because I read and
depend upon the documents produced by the other folks,
to do my own work:

1) At some point - early in the project - the Marketing
Requirements Document (MRD) should "freeze" (stop that snickering)
and become generally available in a public place (inside
our company). Any further discussion and changes to the
content should result in a formal revision-bump. This
should be enforced by the system. Reviews of each version
and the approvals should be enforced by the system. You
can't "release" a new version without it being digitally
signed-off by key persons. You can make your proposed
new version available for review and comment, but it
carries a designation that makes clear it's not been

2) Documents like the SOW (Statement of Work - Engineering's
response to the requirements in the MRD) should also
become controlled in the same way. Even better would be
if changes to (say) the MRD were to trickle down to
the SOW - or at least, to a proposed new version of the
SOW. In turn, when the SOW update is approved, that would
trigger a review cycle for docs that depend on the content
of the SOW, like the Test Plan(s), Test Cases, Test Reports,
Manufacturability Report, Work Instructions (to the people
who eventually will _do_ the manufacturing), etc.


a) It should be obvious to all that a new rev of a document
is in the works

b) Viewing/finding docs, and seeing their status should be

c) If "floating" licenses/seats are involved, they should
age and close with inactivity (so the early bird each
morning can't just tie up a license all day when they
don't really use it much).

d) Reviews should be "pushed". It should not be required
that a person come looking for status of a document. If
they are on the Required Reviewer list, or just on the
Info-only list for a document or a set of documents,
they should receive an e-mail or a text message to alert
them that a document is changed.

e) Deadlines should be settable, and automated nagging
should be available, to prompt reviewers to get their
butts in gear when a revised document must get approved.

f) Currency and supersession should be obvious.

g) Relationships/dependencies between/among documents
should be obvious. A new rev of the SOW for a project
should raise a flag for each dependent/downstream
document, that must be mindfully cleared either by
those documents being updated/reviewed/re-approved,
or an authority taking an action to indicate that
the upstream change has been considered and is determined
to NOT require a change to some subset of downstream

h) All of this stuff - the actions by people and by
the system (any state changes) should go into an
audit trail or log that is timestamped (NTP?) and
carries the person's digital signature. No anonymous
changes to docs in the system.

i) Other stuff that's not coming to mind just now...

Oh yeah! Automated interconnections among docs should
work - at least - for MS Office docs, but it would be
nice if an open file format like .odt were supported, too.
(yes, yes, dream on)

- Kevin

The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.


Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial:

- Use this space to communicate with TECHWR-L readers -
- Contact admin -at- techwr-l -dot- com for more information -

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:


Doc version control - in-house: From: McLauchlan, Kevin
Re: Doc version control - in-house: From: Chris Morton

Previous by Author: Doc version control - in-house
Next by Author: RE: Doc version control--in house
Previous by Thread: Re: Doc version control - in-house
Next by Thread: Re: Doc version control - in-house

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

Sponsored Ads