The contractor’s independent report: not yes, not no, but what would close the gap

A contractor puts forward an independent report to justify a change. Shorten a monitoring period. Accept a different material. Relax a criterion the specification set. The report has a consultant’s name on it and a conclusion that suits the contractor. The 2 easy answers are yes and no. Neither helps the client much. Both get argued about later.

Yes is not an answer. Neither is no

Yes means the Principal has accepted a position on someone else’s analysis without testing it. The Principal owns the consequence if it is wrong. No means the contractor has been refused on a report the Engineer didn’t engage with, which is exactly what the contractor wants to be able to say later. The useful answer says 3 things. What the report does establish. What it doesn’t. And what would close the gap.

Keep the designer’s assumption as the conservative case

The designer set the requirement for a reason. That reason is the conservative case and it stays on the table until something better replaces it. The report’s job is to show the design assumption was more cautious than the site needs. Your job is to check whether it has actually shown that, or just asserted it.

Use the project’s own data to build the likely case

Most contracts generate monitoring and test data the report’s author never looked at. Settlement plates, density tests, cores, instrumentation, survey. Put the report’s argument next to that data and work out a likely case from the project’s own numbers. If the data supports the report, say so. If it doesn’t, the gap between the conservative case and the likely case is where the conversation should be. It is a conversation about evidence rather than opinion.

Then set out what would make it acceptable

This is the part that gets missed. Instead of refusing, set out the monitoring, the trigger levels and the obligations that would make the contractor’s alternative acceptable. What gets measured, how often, what value stops the work, who pays for the response if the trigger is hit. Put it to the contractor in writing. Now they have a route to what they want that protects the Principal. If they don’t take it, the record shows a reasonable route was offered.

The questions I put to every technical submission

1. What specification requirement is this asking to change, quoted, not paraphrased.
2. Who wrote the report, what were they engaged to answer and did they see the project’s own data.
3. What does the report establish on its own evidence and what does it only assert.
4. What does the project data say when it is put next to the report.
5. What is the consequence if the report is wrong and who carries it under the contract.
6. What monitoring, trigger and obligation would make the change acceptable.

Route it properly

A technical submission that changes a design requirement is a design question, so it goes to the designer with the analysis above attached, not around them. What the Engineer’s Representative adds is the check against the contract and against what is on site. Having done structural design and verification myself, I can read a calculation package and test it rather than pass it on. Design questions still go to the designer. Why the structural background matters →

How I approach it

I write the response as what the report establishes, what it doesn’t, what the project data shows and what would close the gap, in that order, with every number tied to its source. Then it goes to the designer for the design call and to the Engineer for the contractual one. The contractor gets an answer they can act on either way. More on how I work →