Document Hack (A Technical Writer’s Journal): Document Mismanagement System
March 29, 2005 by J.C. Hewitt
I have mentioned Documentum in this space before. Documentum is a useful, though certainly not perfect, document management system. Documentum stores files of all sorts, from graphics and desktop publishing files to applications under development. Once a file is stored in Documentum, individual users can “check out” that file (like checking a book out of a library). When they check out a file, it is then locked within Documentum. That means others cannot check the file out although they can download a copy of the file.
Locking prevents more than one person from working on the same file at the same time. This is important because if two people make different changes to the same file, then they essentially create two different files. Merging those two files back together can be a nightmare. Requiring people to check in and check out files prevents duplication of effort and lost changes.
One of the other handy aspects of Documentum is that it stores each version of a file that has been checked in. Because of this, if a major problem occurs, people can always go back to a previous version of the file. This helps prevent disasters.
Documentum allows people to copy files. This means that an individual can download a copy of the file without checking out the file. This is also handy because people often need to view or use files, but they do not need to change them. For example, a manager could download the latest version of a project tracking spreadsheet and bring it to a meeting without checking it out. Because of this, a programmer working on the project can still make updates when they finish parts of the project. If the manager checked out the file, no one on the project team would be able to update it and project tracking would come to a halt.
Documentum works fairly well. There are occasional bugs, but none as bad as a typical Microsoft product. The problem with Documentum is that human beings are allowed to use it. Human beings will screw up a system every time.
That was the case last week on my project. The new lead writer, without telling the rest of us, copied all of the project files to her hard drive to work on them. She did not check them out; she just copied them, not expecting any of the rest of us to work on the files but not telling us not to. I then came along, and in my ignorance, began copyediting the files. I did this the correct way. I checked out the files, worked on them, then checked them back in. After three days of this, our lead writer realized that I had altered about half of the files she had been working on.
On the plus side, the writer understood it was her mistake and took the blame. On the minus side, three days worth of my work had to be dumped. All of this could have been prevented if the system had been followed. It is not my intention to blame the other writer unfairly. If I had taken the time to tell her what I was planning on copyediting the files, she would have had the chance to tell me what she had done, but I trusted the system, and the work was lost because it relies on humans to follow its system.
This is not the only time that I have run into problems with the human element of Documentum. One of the typical problems is what I call file hoarding. This happens when someone checks out a file and keeps it for days or even weeks. This obviously causes a problem because it keeps others from working on a file, but it also causes a bigger problem. The key to using Documentum properly is to check files in every time there is a significant update to the file. That provides an easy path backwards for people when things go wrong. The greater the gap between backups of a file, they greater the amount of work a single error or crash can destroy.
The company policy here is that Documentum files should be checked in at least once a day, even if they are immediately checked out again. Daily use of Documentum lessens the problems associated with computer crashes and file corruption. When people hoard files, they tend not to check them in at all. They just keep the file on their hard drive. If they at least checked the file in once a day and then immediately checked it out again, disasters could be averted. The company I am currently contracting for has a series of policies regarding the use of Documentum. Unfortunately, there is no path for enforcing these policies. Violations are not merely tolerated, they are completely unacknowledged.
Because of this, problems like last week’s lost work are not just possible, they are inevitable. The keys to any system or process working are as follows:
- The actual system must be well planned and workable.
- The people within that system must be properly trained.
- The policies needed for that system to function properly must be enforced.
In this case, the system itself is workable, but there is a limited amount of training and almost no policy enforcement. Because of this, accidents like last week happen on a fairly frequent basis.
Thank you for your notes. I feel your pain. Very often the software (in this case Documentum) takes a hit for the users not following (or lack of) procedure. With 10 years of Documentum experience, I’d like to add a few technical notes to your blog.
1) Documentum does not write word processors or other products, just the tools that support the business process. Sometimes a 3rd party product (like Workshare) can address shortcomings in other vendor products. Workshare allows you to compare and resolve multiple edits of a Word document. This would address the uissue of multiple users changing the same document at the same time. You do still have to think it through and edit the result. (Full disclosure: I do not work for Workshare.)
2) Regarding the Document Dwarfs (that hoard the gold in their secret C: drive) – Documentum allows you to check in the document and not release the lock. This saves the hassle of having to checkin/out in two operations. Yes it is only 1-2 extra mouseclicks but I’ve learned never to underestimate people’s laziness.
Your development team may be able to create a utility that runs on system startup (or shutdown or both) that scans the drive for checked out files and checks them in automagically if changed.
If your co-workers have to think about the process they are not thinking about their writing. Making it a no brainer makes everyone happier and more productive.