Engineering Transmittal Database Workflows

Services organizations have been using transmittal workflows for years. The process consists of collecting multiple documents — some contractual, some operational and some informational — and attaching a summary cover sheet to create a deliverable package. This package, which can be delivered either by courier, mail or fax, today is mostly sent by email.

The cover sheet frequently includes a description and listing of all the items contained in the package, the versions and dates of the documents, and often some instructions.  Confirmation or acknowledgment letters are often included so senders have documentation that the package was received and the documents were approved/rejected by the recipients.

This was a great way to organize drawings and specifications being sent to customers, contractors and vendors. It also memorialized and tracked which files and versions had been sent. This assisted in ensuring changes were being made to the latest documents while also serving as a historical record, should disagreements or litigation erupt.

Sending transmittal packages by email has made it easier to distribute not only the files, but to track the dates of transmission and have a record of who the files were sent to and when they were received.

Automating transmittals

System automation for creating, distributing and tracking transmittals are now available for organizations. This includes the creation of the transmittal (i.e., who is to receive the package, when it is to be sent, what files are to be included, and typically some confirmation or acknowledgment requirement). This automation has saved thousands of hours of manual transmittal package generation as well as improving the accuracy of such packages.

Some systems can control the creation and distribution of transmittals based on key criteria such as:

  • The status of each of the incorporated files
  • The status of the project
  • Internal approvals established by managers/supervisors.

By controlling the workflow with these types of criteria the organization can better govern when and how transmittals are executed. This means fewer packages are released before they are ready, packages are not released without adequate review and approval, and transmittals are sent only when key project milestones are hit.

Transmittals as a separate workflow

The current issue that provides further opportunity for many companies is that the transmittal workflow is independent of the other organizational workflows, instead of being integrated with drawing design and release, submittals, RFI tracking, markups (redlining) and others.

The creation and distribution of a “transmittal package” should be viewed as just another step in a larger project completion workflow and initiated, tracked and reported on within the context of the bigger process. For example, a project workflow to create a drawing for a facilities renovation should include the original RFI, the response and approval, changes to any drawings, and the acknowledgment that the RFI is closed.

These automated handoffs ensure nothing falls through the cracks and sufficient notification is sent to the various parties as milestones are approaching, or if actions are overdue. By including the transmittal workflow in the larger project workflow, actions, requests, notifications and collaborations can be initiated automatically instead of being tracked and reported on manually, which is typically how it is done today.

Project status as the governor

Integration of transmittal workflows is best done using a project or workflow status.  Each project should be governed by at least one status attribute, if not several. This can include status such as RFI received, RFI approved, drawing(s) assigned, drawings approved, etc. As the project transitions through each status, an automated transmittal package can be created or updated and distributed, if applicable. This way interim transmittals can also be developed, increasing the speed of the overall project workflow.

By automating the process through the transmittal package development and distribution phase, the organization also gains better insight into the reasons why projects fall behind, miss milestones, or are just not satisfying the customer (often the project owner). Reports correlating project status to the number of events and timing of events clearly indicate critical path items for companies to focus on improving.

The transmittal package then becomes a key event within the bigger engineering/construction project, not just an independent offshoot that is being accomplished at the pace of the document control or project management group.

Transmittals – integral to project workflow

Organizations benefit from the audit trail created by automating transmittals, but at the same time should not overlook the true purpose of the workflow — to expedite and progress the overall project workflow. As long as the company policies, procedures and systems disintegrate the transmittal workflow from the other project workflows, the real advantages won’t be realized.

In the future, workflow management systems will improve and better recognize the project management and transmittal correlation, and perhaps even get the related parties to collaborate more in real time. Until then, the development and distribution of transmittal packages should be a key step in the overall project — one that is integral, not independent.