This white paper sets forth the basic concepts behind one proven available methodology. It highlights the use of document control data for other management purposes, in particular the one known in the oil and process industries as SDRS [by Brown & Root] or VDRL [by Foster Wheeler].
- About the Task
- About SDRS
- How the SDRS works with Groups
- SDRS Reports
- Advantages of the SDRS Mechanism
The definition of what documents are going to be required for a project [including the specifications of what is going to be done] is a pre-requisite. This white paper is about the process of monitoring the provision of the required documents until they reach a usable state, that is to be given an appropriate status.
At its simplest, the task can be defined as ensuring that all the documents necessary for a particular part of the works to be carried out are usable and available at the appropriate time. This introduces the concept of a "due date", as opposed to "return within three days" for example.
The following diagram illustrates the link with planning:
The task of expediting the "document management" process breaks down into making sure that:
- the initial revision of every document is submitted into the review process by a defined date,
- the various actions forming the review process are carried out in a timely manner,
- that the process is repeated as necessary enabling each document to reach a defined status.
The information that arises from exercising "document control" is very considerable. However the following two things are missing:
- The definition of the review and approval process through which each document must pass in order for it to achieve the desired status
- The date by which this is process is required to be completed to allow, for example, tendering to commence.
These items are what forms the SDRS [or VDRL] information. SDRS stands for Supplier Document Requirement Specification [or Vendor Document Requirement List].
There are a number of other complications:
- A document often serves more than one purpose for, example, tendering and then construction.
- A document may be required for different areas, levels, zones, or work packages at different times.
The development of TDOC's SDRS mechanism has taken many years from the first [bespoke] version written for Amerada Hess in 1991, later substantially extended and modified for the LMK [Laing Morrison Knudsen] joint venture for British Airways' World Cargo Centre project in 1995. A number of other firms, notably Heery International, assisted in the next phase of development. In 2002 it was completely rewritten for the Windows NT platform. The module was last overhauled in 2009.
The diagram below indicates how the SDRS information uses the data available from normal document control operations, process's it within the framework of the SDRS which includes:
- the due date and the number of documents expected, and
- the review process leading to the generation of reports for managment purposes.
The following two diagrams show the movements of Other People's and One's Own Technical Documents which are recorded in the various TDOC Document Registers. The two Registers are similar except that a revision of an Other People's Document must be received for a reason, whereas a revision of One's Own documents must be created. These movements are analysed to determine whether or not the specified events have taken place, and for those that have, to obtain the result.
On a project with several thousand technical documents, the amount of data to be entered to define a due date and and a review process for every document would be huge, whereas specifying the same information for the group of documents forming for example a work package is much reduced.
TDOC has an entity called a "Group". Originally it was referred to as an "Asset", which typically was an item of plant aboard an Oil Rig. Groups can be created to refer to Work Packages, Areas, Levels, Zones or whatever: the latter classification being set up within the Group Type category.
Against a group the following information may be attached:
- A Requirement for the Provision of Documents, consisting of the following information
- The provider (viz sender) of the documents,
- The maker of the documents as a vendor may provide sub-vendors documents,
- The number of documents anticipated,
- The date by which the documents are required to be usable,
- The number of days for resubmission after return in an unacceptable state,
- The "value" of the required documents - in a consistent currency be it manhours or money. Each document is considered to be of equal value. The value of a document depends on the number of documents.
- The list of events forming the review process. An event is any item of information recorded in the TDOC Technical Document Registers, which may include:
- Other People's Documents
- Receipt of a revision of a document for a reason,
- Issue of a document for a reason,
- Return of a document to you,
- The allocation of a Status to the document,
- Return of a document by you to the person from whom it was received.
- One's Own Documents
- Creation of a revision, optionally at a Stage
- Issue of a document for a reason,
- Return of a document to you.
- The definition of each event includes the following information:
- The worth of the event once it has passed
- Whether it relates to the latest revision or any revision
- Whether it "Must Pass", viz whether failing triggers the need for resubmission
- If it Must Pass, whether it will override earlier failed events when it passes, and suppress later passed events when it fails.
- Other People's Documents
- The documents forming the group, whether they be your own or other people. Note that a document can belong to more than one group.
The Document Event Analysis is the engine which analyses each document through each event, and creates a set of information which can then be used for reporting. The forecasting of the expected date for an event depends on whether other events have taken place or not, and must take account of the need for resubmission. The rules applied for forecasting dates are therefore quite complex.
Each document is assigned one of the following status:
- Passed - meaning that it has passed all the criteria specified in the event list.
- Pending (Wait) - meaning that there are some events which have not taken place, but it has not yet failed those which have taken place.
- Pending (Fail) - as above, but it has failed one or more of those which have taken place
- Failed - meaning that it has failed one of the criteria specified in the event list.
The status of the requirement takes on the worst of the status from the documents, and the latest of the forecast dates.
There are two basic reports:
- Document Event Analysis,
- Earned Value Report.
The first report is used to determine the status and the earliest possible availability date of the documents forming the requirement. A similar report [a Requirement Status Note] may be generated for sending to the person providing the documents.
The second report analyses the overall progress in terms of numbers of documents required and provided, and an assessment of the earned value against the value of the requirements using the due date.
Additionally a report listing the requirements, and oiptionally:
- the history of change in the requirements,
- the attached documents, and
- the event list.
Options on the Document Event Analysis report are:
- Summary or Detail
- For each document the summary lists only the document, its status, expected availability date, and the status for each event.
- The detail option lists a further six items of information for each document for each event:
- The revision which was analysed
- The date of the movement through the event
- The actual Reason or Status etc as appropriate
- The latest revision of the document
- The forecast date for the next pass of the event
- Information such as whether Resubmission has been triggered, or whether it has been Suppressed or Overridden.
- Include Passed and or Pending(Fail) documents. This enables the Report to be provide only exceptions.
- Filters, which include:
- A specific Group (which may have more than one requirement when more than one Vendor or Sub-vendor is involved,
- A specific Provider,
- A specific Maker,
- Requirements due after and or before specific dates.
Although the task of Design Management viz expediting documents through the review process can be accomplished by reference to the Document Registers using the register reports, a very considerable amount of work is entailed scanning through reports - usually with highlighter in hand. The poker player with an excellent memory will manage the task a bit faster.
The prime advantage of the SDRS mechanism is that the analysis is done rapidly and accurately, and highlights exactly where a review is hung up. Where this results in one or more documents being unfit for purpose, this information can be communicated forthwith to the provider. The act of returning the documents to the provider with comments, status, and markups is done by Document Control.
A second advantage - or "by product" - is the information from the Earned Value Report which can also be used for:
- Monthly Progress Reporting. This can be done in conjunction with the Document Metrics reports.
- Assessing payments to Design Team members and others who are paid when documents reach various stages.