• IdpRequirementsPortal

IDP - Requirements for DrawMGT Features

Introduction and Immediate Goals

The IDP Project is entering a phase where vendors will start to produce and deliver documentation. Until this point the collection and internal distribution of vendor delivered documents has been managed informally by individual project engineers, rather then centrally via the DrawMGT system. This has led to problems controlling and finding vendor documents. The project management now wants to correct this to centralize the management of vendor documents. We are the primary candidate being considered for the solution.

In the short-term we must prepare a description and offer for implementing the items described in the next section:

1. A rough description what we will implement
2. Delivery date
3. Price

HRV indicates willingness to pay for these updates, but given the financial situation in Iceland, we may not be able to charge the full price for all of our work. These changes have been motivated by Giovanni Cianni, a document control expert based in Montreal, Canada, who works for Hatch (hatch.ca). Hatch is apparently providing project management serves for the IDP project. He has previous experience working on Rio Tinto (the IDP project sponsor/owner) project and this is a chance for us to gain exposure.

Requirements Overview

The basic requirements for managing vendor documents is to:

1. Portal Features - to allow vendors (external users) limited access to selected sets of DrawMGT documents

   • . Provide a convenient way for vendors to deliver documentation, which will be entered into the system by the IDP DrawMGT administrators. The current proposal is to use a special email address which forwards all email to an HRV mailbox. This has already been implemented (the address is ipu-vendor@softxs.ch). We may lated consider setting up vendor specific WebDAV drives where, which the vendors could use for uploading larger sets of documents.

   • Provide a convenient way for vendors to access restricted sets of project documents, which they will need in order to complete their work. The current proposal is to create new contracts/groups to which the individual vendors will be granted access. Security exception tasks and/or transmittals could be used to grant access document in other contracts.

2. Document Tracking Report - a document/revision workflow status report

   • as specified by Giavanni Cianni of Hatch

3. Improved Transmissions - to make it easier for DrawMGT administrators to prepare and send transmissions

   • The goal is to make it easier and more efficient to send new version of documents to the people who should receive them. Solutions might include creating mailing lists, a document distribution matrix, document subscribers, user groups or some other mechanism.

Vendor Document Workflow

Vendors are external companies that supply components and services to the project.

The vendor's primary task (with respect to document control) is to prepare and deliver documentation for the components and services they deliver. In order to prepare their documents, vendors require access to reference documentation provided by the project.

Access to the project's reference documents is granted on a need to know basis and only the documents actually required by the vendor will be shared with them. As the reference documents can be located practically anywhere in the DrawMGT system, granting access via contracts/groups permissions will not work. The method of granting access could be via security exceptions, transmittals or some other mechanism.

The project management has the task of tracking and controlling the production and delivery of vendor documents. This includes:

1. Tracking planned/actual workflow step dates (mainly production and delivery) for new and updated vendor documents
2. Checking/approving/rejecting delivered vendor documents, usually within well-defined constraints. E.g. all received documents will be checked/approved within X days. Vendors have Y days to rework rejected documents.
3. Informing vendors about changes in workflow steps:
   • changed planned dates
   • changes in document status. E.g. approvals/rejects
4. Informing vendors about new and updated reference documents

Vendors are external to the IDP project and are unlikely to want to invest much effort learning DrawMGT. This means that the solutions we propose must be easy for the vendors to use, with little or no training or documentation.

HRV estimates that there will be between 20 and 50 vendors.

Requested Features

Portal Features

The basic requirements for portal features are:

1. Providing vendors with access to limited sets of documents to vendors.
2. Notifying vendors that new documents and new revisions of documents are available.
3. Providing a method for vendors easily to upload sets of documents. Note that this is currently solved via the vendor email address.

Possible solutions:

1. Provide WebDAV directories, where vendors have a log-in, which contains (read-only) copies of all documents that they have been granted access to.
2. Submittals/Transmittals
3. Security exceptions tasks

Document Tracking Report

The requested report is basically a list of documents with columns workflow steps for the next (and possibly also the following) revision. Most of the columns in the example report can be directly mapped to workflow fields.

Provided we can ignore the vendor copies, transmittal code and related columns then we should be able to create a report based on our current Document-Revision templates.

Improved Transmissions

The goal is to make it easier and more efficient to send new versions of documents to the people who should receive them. Ideally there would be an mechanism that automatically sends transmissions or update notifications to the right set of users when documents are updated or re-issued.

Possible Solutions:

1. Mailing Lists / User Groups - Create user groups that can be used for selecting sets of users for sedning transmittals to.

2. Document Distribution Matrix - Implement a matrix with documents (or groups of documents) on one axis and users (or user groups) on the other access, with each intersection represening a flag indicating whether the given user (group) should reveive an update if the given document (group) is updated.

3. Document Subscribers - Implemenent a document subscriber mechanism similar to that used for tasks.

It is likely that a combination of these solutions will be implemented.