All projects involve the production and control of documentation. There will be many types of document with varying purposes, natures, and lifecycles. Of course, most information and documentation these days will not be on paper and its format may not even look like a conventional document. There is every reason to use state-of-the-art ideas and technology to share and convey information as efficiently as possible.
The concept of document management sounds very authoritarian and bureaucratic. It should not be seen that way nor presented in such terms. It should provide an efficient way of sharing knowledge, information and thinking among the project's participants. All participants should find it easy to consult the project's documentation repository to find all content that is relevant to their interests. It should equally be easy for them to lodge in the repository any documented information that they feel is of value to the team.
Documentation Management and Control is closely related to Configuration Management. In some projects they will be treated as part of the same overall process and toolset. More typically, separate management procedures are applied to documentation and technical components.
In terms of the lifespan and usage of project information, there are four main scenarios:
| Permanent | Temporary | |
| External Deliverable | Permanent documentation as a deliverable from the project (eg "Help" information, User Manuals, Training Materials, Forms, etc) | Temporary documentation that is an external deliverable from the project but has no value once the project has been completed (eg discussion papers, draft documents, interim progress reports, etc) |
| Used by Project Team | Permanent documentation to support the maintenance and enhancement of the system (eg Design Specifications, Database Definitions, source code, process diagrams, etc) | Temporary documentation which is only for internal communication (eg ideas, issues, control, working papers etc) |
Consider how these factors affect the requirements for quality, review and update. For example:
As technical solutions improve, and particularly with eSolutions, it is increasingly sensible to make components self-documenting, ie there is not a separate document to be created, stored, accessed and read - the information is directly within the component itself. This is absolutely crucial with business-to-consumer eSolutions - when did you see a customer stopping to download the user manual when ordering from a web storefront? It is equally valuable in terms of other documentation and information, for example:
The traditional IT view of documentation was one-dimensional - there was a document to reflect each major stage in the evolution of the project. A better view of the project's knowledge, information and documentation is that it forms a matrix reflecting different types of information, at different stages, for different issues within the overall business solution. There are at least two dimensions in the matrix - the type of information or document and the aspect of the project to which it relates.
Many participants will take
an interest in specific aspects of the solution. They will want
to follow the story of a particular topic such as the web
storefront or the billing process. Conversely, they do not want
to receive and review the entire design documentation for the
whole project. At any given time, they are probably only
interested in a few cells in the matrix. If the documentation has
been constructed as a structured knowledge repository, with
adequate indexing and controls, this should be easy to achieve.
If you have followed a conventional route and produced a single,
enormous document to describe the entire design - the
participants will be swamped with unnecessary information.
A further advantage of compartmentalising the information and documentation is that items can be released for review, finalisation, approval or action without waiting for other non-dependant elements to be completed. The net result is:
participants only deal with the
content that is relevant to them,
At the start of the project, you will only have a high-level view of the required deliverables, so it will not be appropriate to catalogue them comprehensively in detail. What you do need to do is to consider and define how you will manage and control documentation during the project.
In most cases you will set up some form of system to control the documents. In a short simple project, it might be as simple as a spreadsheet in which you track the main documents. You might personally take control of the documents and transport them using EMail or a shared server.
| You can take a look at a simple template Excel spreadsheet by clicking here. There are two worksheets. The first is the basic descriptions of topics. It would be prepared and agreed during the project start. The second is intended to track the status of each controlled document. |
In larger projects it will be worth selecting a Document Management toolset. There are many Document Management systems available. As it is a constantly changing and improving marketplace, we will not attempt to analyse the merits of specific products. Instead, let's consider what functionality we are looking for.
Here are some of the functions to look for in a Documentation Management system:
Documentation Management Systems |
| Catalogue of all controlled documents and deliverables |
Registration
of key information per document, eg:
|
Tracking of progress
and status information per document, eg:
|
| Ability to incorporate further documents as required throughout the project |
| Ability to store and issue a template version of each document as a starting point where appropriate |
| Ability to access model examples and other illustrative examples to provide team members with a guide to the content that is required |
| Management of multiple versions |
| Secure storage of documents |
| "Checking out" a copy of a document for update to an authorised team member, ie applying appropriate controls and delivering the document to the team member for update |
| "Checking in" an updated version of a document, ie receiving and storing an updated document with appropriate controls and audit trail |
| Controlling and capturing document status changes - what, who, when, why |
| Providing management views and reports of the status of each document |
| Providing team members search access and viewing access to information (subject to authorisation controls) |
| Ability to consult previous historic versions where relevant |
| Ability to identify changes and the reasons for those changes |
| Ability to support a distributed team through Internet, Intranet or WAN networks |
| Analysis of document flow |
Following the detailed planning of a stage in the project, you will be in a position to set up the initial data for document management. You should now know the planned deliverables and documents. If you followed a deliverable-focused planning approach this should be simple, otherwise, you will need to identify the anticipated deliverables, documents and other output products from the plan. You should also define and agree the key details, eg formats, responsibilities, further circulation, level of quality review, etc.
It is worthwhile to validate the flow of documents. Within your planned approach:
Where possible, you should guide the team members with template, model or example versions of each document. This will encourage them to follow a preferred format and will help them to understand what is required. Ideally, the templates, models and examples will be chosen by you, the Project Manager, so that you have editorial control over the style the documentation should take.
| Template | A pre-formatted skeleton for the document. It may contain headings and explanatory text but it would not contain any content. It can be issued to a team member as "version 0" of a document. |
| Model | A completed example of the document which illustrates best-practice in terms of the style, depth and quality, but which does not necessarily have any content directly relating to the needs of the current project. |
| Example | A completed example of the document that is not regarded as a model in terms of its format or quality, but which contains some content that may be of value in producing the deliverables for this project. |
As individual team members join the project, they will need to be instructed and coached on the use of the Document Management System. This is one of the many aspects you would normally include in the project team briefing and training sessions at the start of each phase.
Operation of the Document Management System during the project should be made as easy and efficient as possible, but without losing the degree of control and audit that is required. Routine control will often be a responsibility of the Project Office. Individual participants should be able to access, "check out", update, and "check in" the contents, subject to the defined rules concerning responsibilities, authorities and controls.
The Project Manager and/or Project Office will keep track of document status, looking particularly at:
The Project Manager will monitor the overall status of the repository and deal with issues as they arise.
At the end of a phase or stage of the project, all planned deliverables should have been completed, finalised, approved and distributed. Internal documents should also have been completed, subjected to the defined reviews and finalised.
The Project Manager and/or Project Office would review the status of all items in the repository. The Quality Audit process would normally ensure that all planned items had been produced in accordance with the defined controls and procedures.
Bear in mind that the information and documentation should be flowing out - either into the project's future work or as final external deliverables. Make sure that all outputs have been directed to the right places and will be picked up and used in those contexts.
Items in the project's documentation repository will be dealt with according to their nature:
There needs to be a continuing process to manage the permanent documentation. Before the project is complete, the Project Manager will have established and agreed who will be responsible for which items. It may be that the project's repository will be tidied up, temporary items archived, and that it will then be retained as a permanent facility for the support of the solution.
Where valuable materials from the project might be re-used on other projects (subject to any ownership or confidentiality issues), the Project Manager should ensure that they have been captured and retained - ideally in a shared knowledge repository.
 |
| Copyright © Simon Wallace, 1999-2016 |