Protect the Integrity of Your Document Repository

Large projects can generate a lot of documents. I have been on a couple of projects that generated hundreds of documents over a two-year period. In each case, I needed to share much of this documentation with many other stakeholders in the organization. For these kinds of projects, you need to create a document repository. This repository can be managed with software tools, or you can have a simple folder/file structure on a shared directory.

If you’re going to create a repository, you need to establish some rules and processes to protect the integrity of the stored documents. For example, all of your team members usually need full access to any of the documents that they create. However, you need to decide whether any team member can update documents created by other team members. In some projects this would be perfectly acceptable, while on other projects this would be considered a security breach.

You also should decide whether anyone on the team can add documents into your repository, or whether the update process will be handled by a person filling the role of a Librarian. Your first thought might be that having a central Librarian role to control updates to the document repository is an exercise in bureaucracy and overhead. However, the role might make sense.

In the large projects I mentioned earlier, it was important that the documents added to the repository reflected a consistent and high quality. We felt there would be a tendency for the overall quality of the repository to degrade if everyone had the ability to add, delete, and modify documents anywhere. Instead, a Librarian was established to control the process of adding documents. We used the following simple process.

1. Team members submitted documents to the Librarian at the end of every phase and the end of each individual project. (Remember that we had a large program made up of many individual projects.) The team member completed a form that described the deliverable, the keywords, approval date, recommended storage location, etc.

Read the rest at TechRepublic.