Scribd
Upload
319 views7 pages

Document Management and Control

This document discusses management and control of project documentation. It begins by describing different types of documentation including permanent vs temporary and external vs internal. It emphasizes making components self-documenting when possible. The document then discusses representing documentation as a multi-dimensional matrix and releasing elements independently. Finally, it provides guidance on setting up documentation management at the project and phase levels, including cataloging documents, tracking status, and using templates to guide format.

Uploaded by

basutk4851
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
319 views7 pages

Document Management and Control

This document discusses management and control of project documentation. It begins by describing different types of documentation including permanent vs temporary and external vs internal. It emphasizes making components self-documenting when possible. The document then discusses representing documentation as a multi-dimensional matrix and releasing elements independently. Finally, it provides guidance on setting up documentation management at the project and phase levels, including cataloging documents, tracking status, and using templates to guide format.

Uploaded by

basutk4851
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Document: Management and Control

Why, What, How?


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.

In terms of the lifespan and usage of project information, there are four main scenarios:

  Permanent Temporary
External Permanent documentation as Temporary documentation
Deliverable a deliverable from the project that is an external deliverable
(eg "Help" information, User from the project but has no
Manuals, Training Materials, value once the project has
Forms, etc) been completed (eg
discussion papers, draft
documents, interim progress
reports, etc)
Used by Permanent documentation to Temporary documentation
Project Team support the maintenance and which is only for internal
enhancement of the system communication (eg ideas,
(eg Design Specifications, issues, control, working
Database Definitions, source papers etc)
code, process diagrams, etc)

Consider how these factors affect the requirements for quality, review and update. For example:

 external deliverables need to be of high quality, whereas internal documents may be


informal and incomplete,
 permanent documentation will need to be updated as circumstances change, but
temporary documentation will usually be left unchanged.

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:
 analysis, design and development tools should be self-documenting,
 development standards for source code should generally ensure it can be easily
understood and followed by others,
 user procedures can be presented through a workflow system,
 user manuals and help information can be provided incorporated as context-sensitive, on-
line information,
 training materials can be designed for electronic self-study.

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,


 they receive it in manageably sized pieces,
 they do not have to wait for unrelated content to be ready,
 by restricting circulation of any given information to those people
with a relevant interest in the specific content, the complexity factor is
reduced,
 the various elements will arrive at differing times, reducing peaks and troughs in the
workload.

Document Management and Control at Project Start


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:

 description
 purpose / objective
 form and format
 responsibilities for production
 responsibilities and rights for review
 responsibilities for approval
 further circulation - for information only
 retention and usage (eg temporary or permanent, internal or project
deliverable)
 requirements for update (usually, permanent documentation needs to
be updated if something changes after it has been finalised, whereas
temporary documentation may be left as a historic record even
though something has subsequently been changed)
 required protocols for review and quality assurance

Tracking of progress and status information per document, eg:

 planned date of completion


 current status and effective date
 persons currently updating or reviewing the document
 current projected date of completion

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

Document Management and Control at Phase Start


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:

 incoming documentation and information should be coming from somewhere, and


 outgoing documentation and information should be used somewhere.

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.

Document Management and Control during the Project


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:

 documents that are not at their planned stage of completion,


 documents that are unnecessarily checked out,
 completed work where the documents have not been finalised,
 competing demands for a document,
 participants not working on the correct, controlled version of a document,
 adequacy of review, control, quality and audit information.

The Project Manager will monitor the overall status of the repository and deal with issues as they
arise.

At the End of a Phase


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.

 
At the End of the Project
Items in the project's documentation repository will be dealt with according to their nature:

 temporary items will be normally be archived (just in case),


 permanent items will be retained for future use - eg in maintenance and support, and
 external deliverables will have been distributed and must be maintained.

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.

You might also like