Tender deliverables (SDRL) checklist
A tender deliverables checklist is the list of engineering and project documents a bid commits to producing and submitting, drawn from the tender's supplier data requirements list (SDRL). Each deliverable carries a category, an owner, a submission stage (for approval, for review, for construction, or as-built) and a due date tied to a milestone. Work through the groups below to confirm every deliverable the tender demands is captured, scheduled, resourced and owned before you commit to it in your bid.
A tender's deliverables are a priced obligation, not an afterthought. The supplier data requirements list (SDRL) tells you exactly what documents you must produce, in what format and by when, and every one of them costs engineering hours you have to carry in the bid. Miss a deliverable at bid time and you absorb it later; underestimate the review cycles and your program slips. Use this checklist to capture every required deliverable, assign it a stage and an owner, and confirm it is resourced before you commit. Adapt the groups to the specific tender; not every deliverable applies to every package.
Design and engineering deliverables
Quality and test deliverables
Project and commercial deliverables
Operations and handover deliverables
For each deliverable, capture
Before you commit in the bid
- 01Extract the SDRL from the tender. Find the supplier data requirements list (or document deliverables list) in the tender and pull every required document into one register, reading the spec for deliverables the SDRL itself omits.
- 02Categorise each deliverable. Group each into design, quality and test, project and commercial, or operations and handover, so ownership and effort are clear at a glance.
- 03Assign an owner and a submission stage. Give each deliverable a responsible party and a stage (for approval, for review, for construction, or as-built); the stage determines how many review cycles it carries.
- 04Tie due dates to milestones. Express each due date against a contract milestone rather than a calendar date, so the register still holds when the program shifts.
- 05Price and resource the deliverables. Estimate the engineering hours each deliverable and its review cycles will take, and carry them in the bid. Deliverables are scope, and unpriced scope is absorbed cost.
- 06Flag gaps as clarifications or departures. Where a required deliverable, format or turnaround cannot be met, raise it as a clarification or state it as a departure rather than leaving the register to imply full compliance.
Common questions
What is an SDRL in a tender?
An SDRL (supplier data requirements list, sometimes supplier document requirements list) is the tender's list of documents a bidder must produce and submit across the project: drawings, datasheets, calculations, test records, manuals and as-builts. Each line specifies the deliverable, its submission stage and its timing. It defines a priced obligation, because every listed document costs engineering hours you must carry in the bid.
What is the difference between an SDRL and a document register?
An SDRL is the client's requirement: the list of documents the tender demands you deliver. A document register (or master deliverables register) is your live tracking of those documents through their revisions, submissions and approvals. In practice the SDRL seeds the register: you import every SDRL line, then add revision, transmittal and status columns to manage it from bid through handover.
What do IFA, IFR and IFC mean on a deliverable?
They are submission stages a deliverable passes through. IFR (issued for review) and IFA (issued for approval) are early submissions where the client comments before work proceeds; IFC (issued for construction) is the approved version released to build from; as-built is the final record of what was actually installed. The stage matters because each review cycle adds time and engineering hours to the deliverable.
Why price deliverables at bid time?
Because deliverables are scope. Each document on the SDRL consumes engineering hours to produce, and each review stage adds rework when the client returns comments. A bid that prices only the physical works and treats documentation as free absorbs that cost after award. Estimating the deliverables and their review cycles up front keeps the obligation visible and in the price.
Can building the deliverables list be automated?
The extraction can be assisted. A tool can read the tender's SDRL, specification and returnable schedules together and pull every required deliverable into one register, citing the source document and page for each, so nothing is missed. Deciding the effort, owner and program for each deliverable stays a judgment for your engineering and project team; the tool finds the requirements, people cost and plan them.
Send a real tender. Get the output back.
Hand Elora Grid one real task and judge the result yourself.