Engineering projects fail in two distinct ways. The first is a technical failure — something was designed incorrectly. The second is a documentation failure — something was designed correctly, then changed, and the change was never properly recorded, communicated, or incorporated. The fabricator built from the wrong revision. The as-built drawing does not reflect what was built. The calculations reference dimensions that were superseded two months before the design was completed. The second type of failure is, in the experience of most project engineers, more common than the first — and almost entirely preventable.

Engineering change control is the set of disciplines that prevents documentation failures. It is not bureaucracy for its own sake. It is the minimum structured process required to ensure that the design intent at any point in a project's life is accurately represented by the documents in circulation, and that everyone working from those documents is working from the same version of the truth.

Why Change Control Fails — The Common Pattern

Change control failures follow a remarkably consistent pattern across projects of all sizes. It almost always starts small: a client requests a minor modification by email late in detailed design. The engineer makes the change in the model or calculation and sends an updated drawing by email. Someone else on the project hasn't seen the email. They have the previous revision. The fabricator, who was sent drawings piecemeal throughout the project as they were completed, received the previous issue and has already cut the material. The new revision is not clearly marked as superseding anything. Nobody has a controlled register of what has been issued to whom. The as-built drawing is completed by adding red markup to a print of the last formally issued drawing, which was two revisions before the version that was actually built.

This is not a hypothetical scenario. It is what happens on the majority of small and medium engineering projects that do not impose a formal change control process. The consequences range from minor rework to significant safety implications where the dimension, pressure rating, or material that was changed was safety-critical.

The Document Register — The Foundation of Change Control

The starting point for any change control process is a document register — a controlled list of every drawing, calculation, specification, and report on the project, with the current revision status of each. Without this, there is no change control — only a collection of documents with no authoritative statement of which version of each is current.

A basic document register for a mechanical engineering project contains, as a minimum, for each document:

The register is updated every time a revision is issued. It is the single source of truth for the current status of every document on the project. If the register says Drawing FP-DWG-007 is at Revision 2, then Revision 1 is superseded — it should not be in circulation, and any fabrication being done from it is being done from the wrong document.

Revision Numbering — A Convention That Actually Works

The revision convention used on a project matters more than which specific convention is chosen, because consistency is what makes the convention useful. A document at "Rev C" is clearly later than "Rev A." A document marked "Issue 3 (for approval)" is clearly later than "Issue 2 (for review)." What fails is when different documents on the same project use different conventions, or when dates alone are used (which require the recipient to know the full revision history to determine currency).

A practical convention for engineering projects:

Title blocks on all drawings must show the revision history — at minimum the last three or four revisions with dates and brief descriptions. When a drawing is reissued, the person receiving it can immediately see what changed and confirm they are working from the correct revision.

The Change Note — Formalising the Request Before the Change

The most valuable single intervention in change control is requiring that changes to approved documents are formally requested and authorised before the change is made, not informally communicated and made on the fly. The vehicle for this is the Design Change Notice (DCN) or Engineering Change Request (ECR).

A DCN need not be complex. At minimum it captures:

The DCN is logged in a DCN register alongside the document register. The DCN number is then referenced in the revision description on the drawing or document that is reissued to implement the change. The trail from "client requested flange rating change" to "DCN-007 raised" to "Drawing FP-DWG-003 reissued at Rev 1 per DCN-007" is complete and traceable in both directions.

The key discipline: No change to an approved document without a DCN. Email is not a change control system. A verbal instruction on site is not a change control system. A Post-it note on a drawing is not a change control system. The DCN is. Enforcing this single rule eliminates the majority of documentation failures.

Transmittals — Controlling What Has Been Issued to Whom

Knowing the current revision of every document is necessary but not sufficient. You also need to know what has been issued to external parties — the client, the fabricator, the certifying authority — and at what revision. This is the function of the document transmittal.

Every issue of documents to an external party should be accompanied by a transmittal record that lists every document being issued, at what revision, and for what purpose (for review, for approval, for construction, for information). The transmittal is numbered and filed. The recipient acknowledges receipt.

When a document is revised and reissued, the transmittal record shows that the fabricator was sent Revision 0 on a specific date. If they subsequently build from an unmarked print, the transmittal record is the evidence of what they should have been working from. If they never acknowledged the transmittal of the revision that superseded the one they built from, that is a process failure in their QA system that the transmittal record makes visible.

The transmittal process also protects the designer. If a client claims that a dimension on the as-built is wrong and was not on any drawing they approved, the transmittal record and the client's acknowledgement of the approval-issue drawing shows exactly what was issued, when, and at what revision. Without transmittal records, this is a he-said-she-said dispute. With them, it is a factual record.

As-Built Documentation — Closing the Loop

The as-built drawing is the record of what was actually constructed. It is not the same as the last-issued construction drawing, because construction inevitably involves minor departures from the drawing — field welds relocated, supports moved to suit existing steelwork, pipe lengths adjusted on site. The as-built record captures these departures.

As-built documentation should be a defined deliverable on every engineering project, produced by marking up the construction-issue drawing set with all site-confirmed changes, then either reissuing the drawings at an "As-Built" revision or maintaining a controlled red-line set. The as-built document set is the handover document — it is what the maintenance team and future engineers use to understand the plant as it was constructed.

The common failure: as-built documentation is treated as an afterthought, produced under time pressure at project closeout from memory of what changed on site, rather than maintained progressively during construction. The result is a set of as-built drawings that are accurate for the things that were changed early (when people still remember them) and inaccurate for the things changed late. Progressive as-built marking — updating the red-line set every time a site deviation is agreed — is the only reliable method.

Change Control in Regulated Environments

For pressure systems, lifting equipment, structural steelwork, and other regulated plant, change control has a specific additional dimension: changes to approved designs may require re-approval by the competent person, the certifying authority, or the notified body before they can be implemented. The PED (Pressure Equipment Directive), the Machinery Directive, and CDM 2015 all have provisions that affect when a change is significant enough to require formal re-approval rather than just a designer's internal revision.

The test is broadly: does the change affect the safety-relevant design basis? A change to a pipe support that does not affect the pressure boundary, the pressure rating, or the stress analysis is likely to be a minor change manageable within the designer's authority. A change to the flange rating, the vessel operating pressure, or the material specification is a change to the safety-relevant basis that requires formal assessment and may require re-approval. The CDM 2015 Principal Designer has a specific duty to ensure that the Health and Safety file is maintained with accurate design documentation — which is only possible if change control has been maintained throughout the project.

The Practical Minimum for Small Projects

Not every project warrants a full ISO 9001-compliant document management system. A small mechanical design project with one engineer, one client, and one fabricator does not need a document management platform. But it does need:

  1. A document register — even a simple spreadsheet listing every drawing and calculation with its current revision
  2. A consistent revision convention — applied to every document, without exception
  3. A change log — a record of every change made to every document, with the reason and the date
  4. Transmittal records — a record of every document issued to every external party, at what revision
  5. Superseded document control — when a new revision is issued, the previous revision is clearly marked "SUPERSEDED" or archived. Never deleted — the history is the audit trail.

Five items. None of them require specialist software. All of them can be managed in a structured folder on a shared drive with a disciplined naming convention. The discipline is not in the tools — it is in the consistent application of the rules, on every document, every time.

Naming Conventions — The Invisible Infrastructure

A file naming convention is the lowest-level change control discipline and the one most commonly abandoned mid-project. A consistent convention makes the document register self-populating and makes the transmittal trivial to compile. An inconsistent convention — "Final_Drawing_v3_REVISED_use this one.pdf" — is a document management failure embedded in the file system.

A workable naming convention for a mechanical engineering project:

[Project Code]-[Type]-[Number]-[Revision].[Extension]
e.g. FP001-DWG-003-R2.pdf
e.g. FP001-CAL-001-P1.pdf
e.g. FP001-SPEC-002-R0.pdf

The revision is always the last element before the extension. When the document is reissued, only the revision element changes. Sorting by name gives a complete chronological list by type and number. Filtering for "R0" gives all construction-issue documents at their first approved revision.

Summary

Engineering change control is not a bureaucratic overhead — it is the minimum structured discipline required to prevent the wrong revision reaching the fabricator, to maintain a traceable record of why the design is the way it is, and to produce accurate as-built documentation that the next engineer to work on the plant can rely on. The foundation is a document register. The mechanism is the DCN. The evidence is the transmittal record. The closure is the as-built set. Applied consistently to every document on every project, these four disciplines eliminate the category of failure that has nothing to do with engineering skill and everything to do with whether anyone knows which drawing is current.

Forgepoint produces fully controlled design documentation packages with revision history, transmittal records and as-built handover sets as standard deliverables. Get in touch to discuss your project.

Discuss Your Project — 07549 032776