Blog Content

Will a ticking time bomb wreak havoc and scuttle your project success?

Capital projects procure equipment and materials from suppliers that must provide data to support engineering, procurement, installation, operation, maintenance, and more. These requirements are listed in a Purchase Order (PO) form such as the Supplier Drawing and Document Requirements (SDDR), also called the Vendor Drawing and Document Requirements (VDDR). Table 1 shows a typical SDDR form.

Many supplier documents – calculations, drawings, and similar deliverables – are routinely produced and readily available. The challenge is specifying exactly what is needed and when it must be submitted. The SDDR is typically prepared by the Responsible Engineer (RE).

What could go wrong? Lots.

When prepared poorly or without sufficient rigour, the SDDR becomes:

• Incomplete, driving additional cost; or
• Incorrect, creating rework and waste.

The knock-on effects are worse:

• Late data delays other suppliers or construction activities; or,
• Problems often surface at the end of procurement when the project is closing out and de-staffing, especially for Manufacturing Record Books (MRBs).

Why is this so hard?

Engineered equipment and materials require technical documents to convey design intent and critical information to end users. Whatever the project needs must be clearly specified in the SDDR.

Suppliers serve many customers with different requirements, so the burden falls on the project to define a clear, tailored SDDR for their needs.

In Table 1, only select SDDR codes are shown for clarity, and submittal timing selections are omitted. A typical project SDDR template allows users to select required documents and define anything additional. This is where the RE starts: with a blank slate.

The challenge is how requirements are identified – and by whom. A project may:

1. Depend on the RE to define requirements or start from scratch;
2. Rely on a squad checker or peer reviewer to confirm what is needed;
3. Re-use prior project requirements with some adjustments;
4. Assume “we’ll figure it out later”; or,
5. Use predefined requirements or pre-populated SDDR templates.

Without the structure described in #5, projects often struggle to define and obtain the correct data. Guesswork becomes rework.

Requesting too much data can be just as problematic as requesting too little. For example, duplicate submission of Welding Procedure Specifications (WPSs) before fabrication and in the MRB. Or, do WPSs need review at all? It depends – but without clarity, inconsistency is guaranteed.

Project personnel bring different experience and expectations. What is correct? What is preferred? Relying on past practice or personal preference introduces avoidable risk.

Related: Cake, Craps, and Quality: How to avoid gambling with project success

A small project may absorb a few extra hours chasing incomplete or incorrect data. A major or megaproject with thousands of submittals cannot. Small inefficiencies compound quickly into significant cost and schedule impacts.

With larger teams and longer timelines, rework escalates – driving labour inefficiency and schedule pressure that can ultimately scuttle project success. Why take that risk?

Baseline data requirements should be clearly defined to drive consistency and efficiency, ideally using a project instruction.

Pro Tip: Do you notice anything missing from the SDDR in Table 1? The MRB title page and index – two of the most important supplier documents. Reviewing these early confirms required content and formatting. Without that step, rework during close-out is almost guaranteed, along with delayed turnover or substandard deliverables.

Related: When Lessons Are Unlearned, Rework Returns