24 February 2011. The larger the project, the more rigor and structure is needed to manage documents. You can end up with a big mess trying to save and find documents if you do not think through a good document management plan ahead of time. The following areas should be considered part of an overall document management plan. These items do not reflect a process, per se, since many of the items can be considered and implemented in any order.
Determine where to store documents. The project team should have a common area, or repository, for storing documents. This could be in a file directory, document management software package, paper file cabinet, etc. The project manager should be sure that documents are not stored in multiple locations based on the preference of each team member. If that happens, the team will have difficulty finding important documents when they are needed – especially if there is turnover among members of the team.
Determine the types of documents to include. The team also needs to determine the types of documents that will be added to the document repository. It is possible that the repository can hold every document in every stage of completion, including drafts and documents in each team member’s work area. However, it is also common for each team member to have a work area for his own documents and for the document repository to only hold final, approved deliverables.
Define a logical and physical document organizational structure. Once you know where you will store documents, you should also determine the directory or folder structure. This will provide guidance to team members on the specific locations to store documents and will likewise help the team find documents when they are needed. The first step is to define a logical view of how the documents should be organized. The logical view just means that you place a draft on paper for feedback. Once you have agreement on this view, you need to implement it in the specific directory structure or tool. The structure should be one that is easy to understand and easy to use to find relevant information. After you have created this logical view on a couple projects, you will start to see similarities and you may find it beneficial to create a standard logical organization structure for all projects.
Define naming standards.It can be hard to find documents even if you have a good organizational structure. A common document naming standard will make it easier. An example was described previously for Status Reporting naming conventions. One convention could be '20061201 Joe Smith Status Report'. In this scheme, all the status reports for a given timeframe would sort together. On the other hand 'Joe Smith 20061201 Status Report' groups the reports by person. The project manager needs to make sure that everyone is using the same naming scheme. Although this exercise might seem tedious, having a common naming standard for related documents will be very valuable as your project team generates hundreds of documents over time.
Determine if some documents need versioning. The project manager should determine whether multiple versions of documents will be saved or if just the latest version will be saved. Many documents, such as the Project Charter, should have all approved versions saved. For these documents, the naming convention will need some type of version number. For instance, the original document might be named 'ABC Project Charter ’ 1'. The document name would be changed to ‘ABC Project Charter v 2’ if it is revised at a later time. People can then still refer back to the prior versions if necessary. On the other hand, documents such as the Issue Log only have a current version, and historical information is saved within the document. The current Issues Log always replaces the prior Issues Log, and there is no reason to keep separate versions. If you have a document management system it probably provides a versioning feature for you.
Determine if (and how) you will track document approval status. When documents need to be approved, and especially if the approval process can be lengthy, it is important to signify the document approval status. For instance, it is important to know whether a deliverable you are reading is a final approved version or a draft. Having separate libraries for documents as they go through the approval process can do this. Typical document indicators are “draft”, “work in-progress” and “final”. When a document is created, it is in “draft” mode. When the document is being circulated for approval, it is moved to the “work in-progress” folder. When the document is approved, it is moved to the “final” folder.
Define standard document formats. It is easier in the long run to read and create documents if they all follow a standard format such as font style and font size. In addition, the team can create standard headers and footers, cover pages and table of contents. This will give all the documentation a standard look and feel.
Identify standard document tools (optional). The team needs to have a standard set of document-processing tools. Normally this is not a problem if the team is all from the same area. However, the lack of common tools can be a problem if your project team includes people from different organizations, different countries or different companies. For instance, something as simple as a standard word processing tool is normally not a problem. However, if you have suppliers and vendors on your team, you may have some team members using MS Word as their word processing tool and some using WordPerfect. Similarly, all team members need to have the same spreadsheet software. Once the standard software is identified, you also need to ensure the entire team is on the same release. In other words, if you want to use MS Word on your project, make sure all team members have the same version of MS Word. Sometimes your documents will not be able to be easily shared if the creator and the reader are not on the same software release.
Think about document management ahead of time on large projects. It will save you a lot of extra work and aggravation one the project starts. |
