Re: Document management & workgroup tools

[Robert Plamondon <robert -at- PLAMONDON -dot- COM>]

>Hello, Twirlers. I have been nosing around here for a few weeks, and now
>find that I can use your input. I am working on an article about document
>management and collaborative document production.

>Some questions:
>What tools are you using for these needs?
>How effective are the tools you are using?
>What are the shortcomings of these tools?
>What are the benefits of the tools?

Here are my thoughts about the overall issues in turning a group of
individual Publications people into a cohesive workgroup, through the
proper use of computers.

Many of the critical issues are more network design and system administration
issues than anything.  My experience is that you need ALL of the following
things if your publications group is going to be an efficient, cross-trained,
collaborative workgroup:

* You need a network setup where there is plenty of space for all documents
  of all the projects that show the least sign of life.

* Documents need to be stored in a directory hierarchy that's organized by
  project and title, not by user.

* All the people in the Publications group need to be able to open, print,
  and modify each other's documents.

* No one outside the Publications group should be able to modify documents,
  but they should be able to open and print them.

* No data of any consequence should EVER be on an individual PC or
  workstation, unless that system is backed up daily, and is being used
  as a file server.  Everything should be on the file server, which had
  better be backed up daily itself.  If this is done:

   * Users whose systems fail can simply log onto a different machine
     and continue work.
   * No data is lost when a user's system has a hard disk failure.
   * Backups actually work, for once.
   * Users can open each other's documents, which helps them cover
     for each other during times of vacation, illness, or overload.
   * Users see each other's formatting tricks, and incorporate the
     good ones into their own work.

* All users should compose directly in the target DTP program.  It's
  very inefficient to do drafts in one program, layout in another, and
  then either have to edit the text in the layout program, or re-import
  and re-layout the entire text.

* The target DTP system should have a decent drawing package.  Microsoft
  Word, PageMaker, and Quark are particularly pathetic in this area.
  Importing diagrams sounds okay until you get a couple of hundred of
  them.

* The target DTP program should be able to handle multi-part documents
  seamlessly.  That is, a document divided into twelve files, one per
  chapter, should maintain pagination, autonumbering, and references
  across files, and generate full-document indexes and tables of contents
  across files.

* Use a DTP program that is designed for the types of documents produced.
  For a Technical Publishing group, the entire list is FrameMaker and
  Interleaf, with FrameMaker as the low-price leader, and Interleaf as
  the high-end product.

* Use templates and style sheets for everything.  Proper templates make
  it to compose documents in fully formatted form, avoiding formatting as
  a separate step.  They also impose uniformity of style and construction,
  simplify training, and speed up production.

* Have someone in the group who aggressively maintains and updates templates
  and style sheets.  If the tools don't fit the needs, the users will go
  off and individually reinvent the wheel.

* Network management is very important.  If the network becomes unreliable
  or slow, or if the network disks fill up and are not expanded, users
  will be forced to revert to the usual "all my files are on my PC, which
  was backed up two years ago" workplace style.

        -- Robert

Robert Plamondon * Writer * robert -at- plamondon -dot- com * (408) 321-8771
4271 North First Street, #106 * San Jose * California * 95134-1215

"Just cut a few notes and it will be perfect."