2.3.1T Document Management - Basics

(2.3.1T.P1)

The larger a project is, the more difficult it becomes to share information between all the team members and stakeholders. This is especially true when more than one person works on large deliverables. If the project manager does not think about these document management processes ahead of time, the project team will end up with problems finding relevant information. This generally results in confusion and extra effort re-doing work that was already completed.

A couple examples will help explain this concept. Let’s say your project is going to create many documents that need to be stored and shared - for instance, the Project Charter, Issues Log, Business Requirements, Testing Plan, etc. After a document is created, the team members need to know where it should be stored. Depending on your sophistication, the document might go into a network file folder, a file folder on your hard drive, a document management software package, etc. After the document is created, you must know who can have access to it. Most documents might be accessible to the entire team, but you only want them to be able to view the documents – not change them. You should come up with a common naming convention for the original document and any revisions. For example, if you update the Project Charter, should the changed document replace the older version? Perhaps you should save the original document and then designate the new document version 2. These are all part of your document management procedures.

Let’s also look at Status Reports. You should determine the naming conventions of the Status Reports ahead of time. If every team member sends a Status Report to the project manager, it will not be long before the project manager will have dozens or hundreds of Status Reports. If the format of the document name is in the format of 'Date Name Status Report' the reports will sort in chronological order. If the document name is 'Name Status Report Date' they will all sort by person. Perhaps the project manager should just delete the Status Reports after reviewing them. All of these questions are components of document management. 

Document management considerations are trivial for small projects. For large ones, these processes need to be planned ahead of time or else confusion, uncertainty and extra work will occur when the project is in progress.

Structured and Unstructured Data (2.3.1T.P2)

Data can be stored in one of two states – structured or unstructured. Structured data refers to information that is stored in repetitive and structured format. Structured data refers to files, tables, databases, data warehouses, etc. This type of data is easily stored and accessed by computer programs.

On the other hand, unstructured data is typically in a format that is easier for a human being to understand but harder to manipulate automatically. Unstructured data includes documents, images, graphics, video, audio, etc. Unstructured data can be increasingly manipulated by a computer, but the basic understanding of the content is still best performed by people.

Although documents are the primary concern for most project teams, the concept of document management can be broadened on your project to include any type of unstructured data as described above. In other words, if your project generates audio and video files, you can use these same techniques regarding naming conventions, indexing, storage in the repository, etc. 

Examples of structured and unstructured data are shown in the table below.

Structured Data

Unstructured Data

Fields, records, files, tables

Code, models, scripts

Rely on tools, databases

Source code management tools

Hard to organize without tools or structures

Documents, pictures, graphics, text, video, chat

Difficult to find tools, although more exist today

Document management tools

Can organize without tools

Basics of Document Management (2.3.1T.P3)

The components of the document management process are described in this section. These processes can be modified as necessary for your project, and then inserted into the Project Management Plan that is created during the 2.1P Define the Work step. Many of these components are needed to support the process that a document goes through from creation to approval. This is explained in 2.3.3.1P The Document Life Cycle. The process for managing draft copies is described at 2.3.3.2P Draft Copies.

In fact, document management is not so much a sequential process as it is an approach and set of techniques for managing documents.

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. A sample logical repository structure is available at 2.3.2T Sample Directory Structure.

  • 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 v 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.