The drawings arrive just before the deadline. The contractor says the work is finished. You open the files and find a general layout, a few dimensions and a PDF.
Your operations team was expecting the project deliverables to include detailed drawings they could edit, equipment information they could load into their system, and records showing what was tested.
You ask where the rest is.
“We didn’t allow for that.”
Now you have a discussion you would much rather have had before the work started. The contractor thinks they have delivered what was requested. Your client thinks important parts are missing. Meanwhile, you are trying to finish the project.
How did everyone get this far with such different expectations?
Problem: Everyone Has a Different Idea of What Must Be Delivered
A deliverable name does not explain the requirement
Make sure you and your client agree on the deliverables expected for the project. That sounds obvious, but a contract can list project deliverables without explaining them well enough for everyone to understand the same thing.
“Provide drawings” could mean a general arrangement showing where equipment will be installed. It could also mean detailed drawings showing dimensions, connections, materials and everything required for construction and future maintenance.
Likewise, “provide a commissioning report” might produce a signed page saying the equipment works. The client might expect test procedures, actual readings, acceptance limits and evidence that each test passed.
Both descriptions sound reasonable until you compare the work involved. By then, the contractor may have priced one version while the client expects another.
Documentation requirements are easy to overlook
Some deliverables are obvious. A new building, installed pump or completed software system is difficult to miss. The supporting documentation is easier to forget, particularly when requirements are scattered through a large specification.
A drawing requirement might appear in one section, training records in another, and asset information somewhere near the back. Even when the contractor is required to provide these items, leaving people to find and interpret every reference makes omissions more likely.
The problem also affects small jobs. A short quotation might cover installation and testing but say little about what records will be supplied afterwards. Small projects still need clear deliverables.
Missing deliverables delay other work
Incomplete documents create work for someone else. Your maintenance team may need to chase equipment details, your designer may need to recreate drawings, and your project team may now spend weeks collecting files from people who have already moved to another job.
Depending on the agreed requirements, missing deliverables can also delay acceptance, handover or payment. If another activity depends on those documents, the effect extends beyond the original contractor’s work.
The contractor may have done good physical work, but the client still remembers the difficult closeout. That is a poor final impression to leave when you would like to work with them again.
Solution: Define the Deliverables and Agree on the Details Early
Start with what the client will actually use
Before preparing a deliverables list, ask what the client needs to do with the completed work. Who will operate it, maintain it, approve it or use the information later?
A PDF drawing might be sufficient for someone reading it. It may be unsuitable for a client who needs to update that drawing when the equipment changes. A generic supplier manual might explain a product range without identifying the model actually installed.
Include the people who will use the deliverables in this discussion. Operations, maintenance and document control staff can identify requirements that the project manager or purchasing team may miss.
This is why I recommend that you clarify who uses documents and why. Understanding the purpose helps you specify useful information instead of requesting paperwork that nobody needs.
Prepare a clear deliverables list
I believe tender and contract documents should include a clearly identified summary of the deliverables required. Do not rely only on requirements buried within paragraphs.
Give each deliverable a reference number and link it to the detailed specification. The summary makes the requirement easy to find; the specification explains exactly what is required. Check that the two agree, and resolve conflicting requirements before issuing the documents.
For a small job, a short table attached to the quotation request may be enough. A larger project may need a deliverables register that is updated throughout delivery.
For each item, record:
- What must be provided, including its scope and level of detail.
- Required formats, templates and applicable standards.
- Who will prepare it and who will receive it.
- Submission dates and any review stages.
- Acceptance criteria and the person authorised to accept it.
Keep the list accessible to your team and the contractor. It should be something they use, rather than another attachment forgotten after the contract is signed.
Specify detail and file formats
“Drawings” is rarely a sufficient description on its own. State whether you need concept drawings, general arrangements, detailed designs, construction drawings or final as-built drawings showing what was actually installed.
Specify the relevant drawing standards, numbering, title blocks and revision requirements. If you need editable AutoCAD files as well as PDFs, say so in the request for quotation or tender. Identify the required file version and supporting files where compatibility matters.
An editable drawing that cannot be opened properly because its references are missing is not particularly useful. Neither is a scanned PDF when the client expected a usable source file.
Apply the same thinking to other documents. Specify whether asset data must be supplied in a spreadsheet or an import template, and whether reports must include editable source documents. Clarify the client’s rights to use and update those files through the appropriate agreement.
Make acceptance criteria practical
Agree how you will decide whether each deliverable meets the requirement. “To the client’s satisfaction” gives people little guidance when they are preparing the work.
For example, an asset register might need a model number, serial number, location and maintenance reference for every installed item. A commissioning record might need the procedure used, equipment identification, measured results, acceptance limits, test date and the responsible person’s name and signature.
These are checks the supplier can perform before submission and the reviewer can perform afterwards. They also help prevent different reviewers from applying different expectations.
The Association for Project Management’s explanation of scope management (and the follow on links) provides useful background on defining project boundaries and recording assumptions. For your own project, turn that thinking into specific requirements that people can check.
Use examples to remove uncertainty
Sometimes an example explains the requirement better than another page of instructions. Provide a sample drawing, completed test sheet or manual index showing the expected content and level of detail.
Explain which parts of the example must be followed. Otherwise, the contractor may treat it as optional guidance, or copy information that does not apply to this project.
If you deliver similar projects regularly, prepare a standard set of example deliverables to include with your offers. These can show a potential client what your drawings, reports and handover documents will look like.
Of course, you should use approved or anonymised examples, and check that they match the current project requirements. Make sure the examples clarify the specification, not introduce another conflicting set of instructions.
Put the requirements into the tender and contract
The best time to agree on deliverables is before the price and program are committed. Give tenderers the deliverables list, relevant specifications, templates and examples so they can allow for the work.
Ask them to identify exclusions, assumptions and departures. If one tender excludes detailed drawings or allows only a basic manual, resolve that difference before comparing it with offers that include the full requirement.
This connects directly with the importance of good specifications. Unclear requirements make it harder to obtain comparable prices and easier to end up arguing about what was included.
Carry the agreed requirements into the final contract documents. Then make sure the delivery team receives them. A good tender clarification achieves little if it never reaches the people producing the work.
Confirm the understanding before production starts
Use the kickoff meeting to walk through the deliverables list with the contractor and the relevant client representatives. Ask questions about anything that could be interpreted differently.
Who will supply the equipment data? Which drawings need approval before fabrication? What information will the client provide, and when? Who combines the subcontractors’ documents into the final package?
For a large set of similar deliverables, review an early sample before the contractor produces the whole batch. Correcting one test sheet or drawing template is much easier than correcting fifty completed documents.
If you inherit a project already underway, do this review as early as possible. Record gaps and unresolved interpretations rather than assuming the previous project manager settled everything.
Allow time for review and corrections
A submission date is not necessarily an acceptance date. Your schedule needs time for preparation, internal checking, client review, corrections and re-submission where required.
For example, an operating manual needed for training must be usable before training starts. Receiving the first draft that morning does not achieve that, even if the contractor technically met the submission date.
Agree review periods and identify the reviewers. Check that those people know they are responsible and will be available. Where several departments must comment, nominate someone to coordinate their feedback.
As I discuss in Specify the Due Date, people need a clear deadline. For deliverables, they also need to understand which stage that deadline applies to: draft, review submission, revised issue or final accepted version.
Track delivery and record changes
Assign an owner to each deliverable and review progress throughout the project. Include subcontractor information early enough for the main contractor to check and combine it before submission.
Useful status descriptions include not started, in preparation, submitted, under review, returned for correction and accepted. Record the document reference and revision so people know which version has been reviewed.
Do not mark an item complete merely because an email attachment arrived. Check it against the agreed requirements and record what remains outstanding.
If expectations change, establish whether you are clarifying an existing requirement, correcting non-compliant work or requesting additional scope. Follow the agreed change process, including the effect on cost and time. Refer also to Document All Changes, Variations and Agreements.
Deliver a complete final package
Agree how the final collection will be organised and submitted. Even if documents have been issued during the project, provide a coordinated final set with an index identifying the current documents and revisions.
Depending on the work, this could include:
- Final drawings
- Operating and maintenance manuals
- Equipment data
- Completed inspection and test records
- Commissioning results
- Training records
- Warranties
Specify the applicable items rather than expecting every project to need everything.
Check quantities as well as document titles. If sixteen installed units each require two test sheets, the package should account for thirty-two sheets. One example sheet does not demonstrate that every unit was tested.
Confirm the intended recipient, submission method and storage requirements. Record receipt and acceptance separately so you can see whether the package is simply delivered or actually accepted.
Check the requirements before invoicing
Before submitting a claim, check which deliverables are required for that milestone and retain evidence that they were submitted. Where acceptance is required, allow for that process too.
My related lesson, Submit Deliverables Before Invoicing, addresses the avoidable delays caused by missing submissions. Agree these requirements early so the contractor can plan for them.
Use the actual contract requirements when assessing completion and payment. Keep additional client requests separate from agreed deliverables, and use the appropriate change process for extra work.
Lesson: Agree on What Finished Looks Like
Make sure you, your client and your contractors share the same understanding of the project deliverables before the work begins. A deliverable title alone may leave important questions unanswered.
Clearly identify what must be supplied, how much detail it needs, the required format, when it is due and how it will be accepted. Give documentation requirements their own visible place in the tender and contract, supported by detailed specifications and examples where useful.
Then use that agreement throughout the project. Check early samples, track submissions, record changes and provide a complete final package.
It is much easier to clarify what everyone expects before the contractor prices and produces the work than to negotiate it when everyone thinks the project should already be finished.
