You are on page 1of 9

0471-4098888 Documentation 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. 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 External Deliverable Permanent documentation as a deliverable from the project (eg "Help" information, User Manuals, Training Materials, Forms, etc) Temporary 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) Temporary documentation which is only for internal communication (eg ideas, issues, control, working papers 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) 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, online 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 bestpractice 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.
Answer Document Controller is a person which manages documents of an orginazation for a project or whole organazitation to a much higher degree of reliability for security, version, visibility, availability and, most importantly, with a controlled reliable audit trail. There are few rules which a document controller has to follow.

Answer Document Controller is a person which manages documents of an orginazation for a project or whole organazitation to a much higher degree of reliability for security, version, visibility, availability and, most importantly, with a controlled reliable audit trail. There are few rules which a document controller has to follow. 1. He / She should have very clear understanding of the company procedure and a clear understanding of company document moment System. 2. He / She should follow the documet or numbering policy of the company.

"A Document Controller job demands maintaining a master document register of the latest drawings on a project and ensure that all recipients are transmitted the drawings they require as soon as new revisions of drawings are received. A Document Controller can use Document control software applications like QDMS and TeamBinder to create an electronic register of documents and maintain a history of drawing revisions and transmittals sent to architects, builders, contractors and sub-contractors. This process also helps in maintaining controlled documents which is fundamental responsibility of document controller's position. Typical document controller jobs involve: Registering of internal and external documents. Maintain document control registers / documents for incoming and outgoing project documents. Ensure that the latest revision and approval status of drawings is kept updated continuously. Maintain stick files in an orderly manner. Production of status reports for weekly / monthly meetings Ensure all hard and electronic copy distribution of controlled documents to focal point. Maintain documents for transmittal process for project documents. Expedite and maintain acknowledgements to transmittals Expedite responses to transmittals sent for review/comment. Respond to queries regarding revision status of issued drawings / documents from engineering / drafting personnel. Follow procedures and update document control procedures when necessary Manage the electronic and hard copy filing of project related technical documentation. Scanning, creation of CDs and file manipulation. Assure document quality to include completeness, accuracy and compliance with established procedures and updates.

Filing and archiving of documentation to facilitate easy retrieval at a later date. Auditing Sending of Drawing Transmittals and Submittals. Ensuring that drawing transmittals are acknowledged in case there is a dispute on whether the drawings were transmitted. Manage the document/drawing review process, Internal and External. Archiving data for historical purposes. Maintaining efficient document control is essential to companies seeking ISO certification for Quality Assurance purposes." Source and further information: Document Controller is a person who has got responsibility to manages documents of an organization for a project or whole organizational to a much higher degree of reliability for security, version, visibility, availability and most importantly with a controlled reliable audit trail.

You might also like