Contents


Preamble (Need)

The need for a standard Statement of Requirements (for the data and process's) is due to the general lack of recognition by the document management (software) industry of the specific business process needs of the building, construction, and engineering industry, and associated professionals.

A definition of "document management" was made in 1995 by the Computer Graphics Suppliers Association Ltd. in their report entitled The Document Management Strategy Report - A guide for Users available from Cimtech Ltd., a trading company of the University of Hertfordshire, sponsored by the Department of Trade & Industry. Although this report included a list "Document Management Application" categories, it failed to identify the main areas of need including transmittal notes, and links to planning for technical documents.

By 1997, the definition had changed considerably and been presented in terms of "System Functions", and areas of "Application Focus". However the specific needs for Construction Engineering Management Document Control (CEMDC) have still not been adequately identified.

This Statement of Requirements can be seen as fulfilling the need for an adequate industry definition. It has been based on documents produced by several plant owners, contractors, project managers, and designers.

Return to Contents  

Scope 

The scope of this Statement of Requirements covers all aspects of document management and control for procurement of the construction of capital projects ranging from buildings to power stations to airports. It is applicable in whole or in part to all the disciplines and parties involved from plant owners to subcontractors over the whole duration of the project.

Return to Contents 

Definition (Objective)

There are two sides to the objective - those which are passive, i.e. the need to comply with ISO9001:2000, Conditions of Contract, etc. and those which are active, i.e. the need to operate industry standard business process activities.

  • To establish a consistent approach to document control for all contracts and projects, and to meet the requirements of ISO9001 at the required level.
  • To provide registration of all technical, general and work package specific documents, identifying the whereabouts of not only the original, but also of every copy of every revision of every technical document, and every copy of every general document including those which are completed progressively by more than one party.
  • To enable the status of any copy of any revision of any technical document to be determined at any time.
  • To manage the repository in which documents are located in whatever form documents exist whether electronic [CAD or WP file, database generated, electronic image from Scaning or Facsimile], or hardcopy [paper, velograph, etc].
  • To manage the formal movement of technical documents by appropriate means to agreed standards, ensuring incoming and outgoing inspections are carried out by bothe issuing and receiving parties, generating the necessary transmittal documents in an appropriate format and media to manage the process.
  • To enable the management of technical documents (including their creation, review, and issue) to be carried out in a timely and efficient manner in accordance with a predefined plan.
  • To provide a reporting system to enable the full history of any technical document or group of documents, and of general documents on any subject or grouping to be listed.
  • To provide exception reports for expediting outstanding actions, to predict completion of actions on individual technical documents or on groups of documents, etc.

Return to Contents 


Functional Requirements

Document Types

The document management system must be able to handle all the common business process functions, for the main types of document which are defined as follows:

  Technical Documents Technical documents are created to define an entity such as a building, or part, and to pass information about the entity from the designer to others, e.g. clients, managers, other designers, constructors.
Technical documents may be revised, and re-issued prior to their use as comments may be made about them. They may require to have a status, and be issued for a reason
  Transmittal Documents Transmittal documents are those which are used to manage the movement of technical documents from one party to another. They are in fact only a report of an action which has been taken, and they form part of technical document management processes.
  Correspondence Correspondence (or general) documents are created by one party to send to another to convey certain information. They may be copied to third parties. The recipients may be required to respond.
  Other (Work Package) Documents This includes contemporaneous notes, daily record diary, minutes of meetings, inspection (snagging) records, planned and actual dates of events, and timesheets.

The list of processes given below cover the whole life of the document, and may be carried out by more than one party on a project. A firm or department may only require to manage some of these processes, for example a drawing office will be principally concerned with creation and revision of drawings using CAD, and may manage the electronic repository manually: Viz, for Own Technical Documents, only the second and fourth items are relevant.

Technical Document Processes

The processes which are associated with technical documents can be split into two groups. The two groups relate to whether the document is owned or not. The processes are defined for each group as follows:

Own Documents: Those documents for which you have the authority and responsibility to create and or amend.

  • Planning creation, and effort involved.
  • Creation and Revision.
  • Registration including reference, title, and other pertinent information such as its type, size, and for each revision, date of creation or revision, reason for change, and authority for revision, etc. Grouping information may also be required.
  • Storage and retrieval, i.e. the management of the document repository. This may be a file server for electronic documents, or filing cabinets for paper documents. Copies of documents may exist in both repositories for legal reasons.
  • Issue to other parties, usually under controlled conditions, i.e. for a reason.
  • Receipt from those or other third parties, again usually in a controlled manner, i.e. with a status and comment for each receipt of each copy of each revision of each document.

Other People's Documents: Those documents for which you do NOT have any authority or responsibility to create and or amend, i.e. the authority and responsibility reside elsewhere.

  • Planning the things which must successfuly happen to a document in order for it to become usable for construction etc. This is often referred to as an SDRS or Supplier Document Requirement Schedule. It will be different for the parties who generate documents to those who approve them.
  • Receipt from other parties, usually in a controlled manner, i.e. for a reason.
  • Registration including reference, title, and other pertinent information such as its type, size, and for each revision, date of creation or revision, reason for change, analysis of revision, etc. Grouping information may also be required.
  • Storage and retrieval, i.e. the management of the document repository. This may be a file server for electronic documents, or filing cabinets for paper documents. Copies of documents may exist in both repositories for legal reasons.
  • Issue to third parties, usually under controlled conditions, i.e. for a reason.
  • Receipt from those or other third parties, again usually in a controlled manner, i.e. with a status and comment for each receipt of each copy of each revision of each document.
  • Return to the parties who sent you documents, or who created or revised them again usually in a controlled manner, i.e. with your status and comment for each revision of each document.

Click to see the schema that is used for Technical Documents in The TDOC System

General Document Processes

The processes which are associated with general documents can be split into two groups. The two groups relate to whether the document is owned or not. The processes are defined as follows:

Own Documents: Those documents which you create and despatch.

  • Creation of document: this can be done without the need for a word propcessor.
  • Registration including reference, date, subject, addressees, and content, etc.
  • Storage and retrieval, i.e. the management of the document repository. This may be a file server for electronic documents, or filing cabinets for paper documents. Copies of documents may exist in both repositories for legal reasons.
  • Despatch to addressees.
  • Receipt of reply.

Other's Documents: Those documents which you receive, and if necessary re-act to.

  • Receipt of document.
  • Registration including reference, date, subject, issue, and content, etc.
  • Storage and retrieval, i.e. the management of the document repository. This may be a file server for electronic documents, or filing cabinets for paper documents. Copies of documents may exist in both repositories for legal reasons.
  • Despatch to other addressees if required.
  • Receipt of their responses if required.
  • Reply if required.

Click to see the schema that is used for General Documents in The TDOC System

Miscellaneous [Work Package Management] Documents: Those records, which may be specialised documents or metric information such as time allocation sheets.

  • Registration of the information, often attaching a document such as a photograph or sketch.
  • Registration or generation of any associated actions or downstream events.
  • Linking Documents to groups such as work packages, and to key words or phrases.

Click to see the schema that is used for Groups and Keywords in The TDOC System

Return to Contents


Configuration Requirements

Structure

Any software must have a structure to it which creates a framework within which the document processes can be managed. It is not part of this Statement of Requirements to identify specific types of database which might be suitable, nor which types of language are suitable for creating such an application set.

The structure must cover the following:

  • The ability to set up predefined lists of standard categories of document types, lists of the allowed reasons for issue, status which may be allocated etc.
  • Parameters to define numbering systems.
  • User settings to allow operators to work as required.

The structure may cover such things as:

  • Predefined distribution lists.
  • Defined schedules of deliverables.
  • Workflow or other means of ensuring that defined actions have been taken.
  • Standard types of user configurable forms.

It is preferable that the software structure can be setup by the skilled user and not require configuration by experts, external to the users organisation.

Background data to enable registration activities

  • Register of People
    Lists of Organisation Types, and Job Types for People
  • Register of Projects
  • Register of Job/Contracts
    List of Job/Contract Types
  • Register of People associated with each Job/Contract identifying their references
  • Register of Groups for such purposes as identifying Work Packages
    List of Group Types
  • Register of Subjects
    List of Subject Types
  • Register of Keywords for specialist indexing

Technical Document Registration

The following elements and associated sub-elements have been defined as necessary to operate the basic registration transactions defined within the processes for technical documents:

  • Registers of Technical Documents: both your own and other peoples
    Lists of Document Types & Sizes
  • Register of Revisions of Technical Documents
    List of Life Cycle Stages [for one's OWN revisions]
  • Register of receipts of documents from others
    Lists of Reasons for Issue (to you), and Media of Issued Document>
  • Standard Distribution lists at person document (revision) level
  • Register of issues of documents to other people, including returns by you of documents received from other people.
    List of Transmittal Note References
    Register of Acknowledgements
  • Register of Comments and Status made by other people on any document issued by you and returned to you, and by you on other peoples documents. List of Status

Technical Document Procurement

The following additional elements are required to manage the procurement of technical documents to a predefined plan, but exclude the elements required to create and run a planning package.

  • Register of Schedules of Deliverables - who, when, how many, value.
  • Work Flow or Event definition List.

General Document Registration

The following additional elements are required to manage the registration of general documents including specific document types such as Project Managers Instructions, Technical Queries, responses and the like.

  • Register of documents: incoming, and outgoing
    List of document types including
    document layout for Own Documents
  • Register of recipients of copies of documents
    List of types of responses required
    List of types of actions taken

Miscellaneous Document Registration

Miscellaneous Documents include the following

  • Contemporaneous Notes (telephone calls etc)
  • Record Diary (of happenings such as accidents)
  • Minutes of Meetings incluidng Agenda and Action Lists
  • Inspection (Snagging) reports incluing reinspections
  • Work Package Event Dates - Planned (with History of change), and Actual
  • Time Allocation Sheets against against Job and any relevant item.

Return to Contents  


Standard Features

Custom & Practice

Any software should comply with standards and custom and practice, which might include:

  • Both technical and general documents may have more than one reference, and for technical documents these may be different to the electronic (CAD) file name of the document.
  • To meet and use industry standards for the transfer of information from one system to another, whether the mode be electronic, email, or paper based.
  • To be in strict compliance with the requirements of ISO 9000 with reference to document control, and design control.
  • To allow the registration information to be accessible for management purposes.

Other Matters

It is also preferable that the following matters should be addressed:

  • Data entry should be minimised, and validation applied at all times where possible.
  • Document references should be generated automatically
  • The generation of reports and enquiries should be screen based not paper based.
  • Validation of general documents particularly those which transmit formal contract instructions by signature or other means.
  • Easing Communication with the other parties reducing effort required by them preferably using Electronic Data Interchange (EDI)
  • Further easing of communication by integrating HTML Forms with Server Side processing to generate EDI.

Return to Contents  


Standard Referencing

It is recommended that all references are reduced to a reasonable minimum to reduce the volume of data entry. For example, if the format of a document number consists of its JobNo / PlantItem / Sequential No, then only the Sequential No should be used for data entry. Entering a longer number simpoly increases the scope for a typing mistake which might then lead to a NEW document being recorded, when in fact it should only have been a revision of an existing document. The downstream effects of that could be catastrophic.

Technical Documents

When documents are transmitted from one place or person to another, it is necessary to ensure that the documents are uniquely identified so that there can be no confusion.

It is therefore recommended that technical documents are identified as follows:

Job/Contract Reference
+ Name Reference of the Person who created it (Maker)
+ The Maker's document reference
+ The Maker's revision reference

They may also be identified as follows:

Project Reference
+ Project document reference

For internal audit purposes, every copy of every revision of every document should be uniquely identified as follows:

Job/Contract
+ Sequential Identifier

General Documents

It is recommended that general documents are identified as follows:

Job/Contract Reference
+ Name Reference of the Person who created it (Maker)
+ The Maker's document reference

The may also be identified as follows:

Job/Contract Reference
+ Sequential Document Reference

For internal audit purposes, every document should be uniquely identified as follows:

Document Type
+ Sequential Identifier

Miscellaneous [Work Package Management] Documents

These are so diverse in nature that it is not feasible to standardise them.

Return to Contents   


Standard Data Types

Items of information are required in the management of documents, for example when generating a transmittal note. It is important that all systems have the ability to hold data of the same types to enable EDI (Electronic Data Interchange). The following table defines the entities which are required: all information may be included on a transmittal note:

Item Size Comment
Sender's name 50 For person & organisation
Communications 15,
80
Telephone, Fax,
E-mail address
Address 30 Up to 5 lines of address
Project Title 80,
40
Description
Reference
Job/Contract Title 80,
15
Description
Reference
Group Title 80,
8
Description
Reference
Transmittal Note Number 15 8 is recommended
Recipient's Name 50  
Maker's Name 50  
Maker's Document Number 15 5 is recommended
Document Title 80  
Revision Number 3 combined with document number can make file name
Document Type 15  
Document Size 15  
Document Material 15  
Senders Document Number 15 8 recommended
Project Document Number 40  
Senders Change Reference 5  
Number of Copies 3 or "ADV" for advice.
Reason for Issue 15  
Senders Status or Stage 15  
Senders Comment 80  
Date of revision 8

in DD/MM/YY format

Return to Contents   

Standard Methodologies 

It is recognised that the integration of planning and document control using the techniques accepted as common practice in the oil industry are not yet common practice within the construction industry. However similar methodologies are being developed, and are becoming more widespread.

There are two relevant methodologies which are:

Technical Documents SDRS

  • Generate a schedule of deliverables for each person for each group
  • Generate and issue a document register for each person for each group
  • Generate the documents.

General Documents

  • Requests for Information (Technical Queries) are documents which "grow" as answers are received from people to whom it is forwarded for answer before the final response is made. The final reposnses includes all the answers from those people to whom it was forwarded and who have responded.

Return to Contents