The document dump is not administrative. It is risk transfer.

Twelve hundred documents is not disorganisation. It is a decision somebody made about who carries the consequence.

From the field · Associate, bid support · 6 September 2026

Sitting with a bid manager at a specialist contractor last winter, working through a pack that ran to well over a thousand files, he said something that has stayed with me since.

“the reason why they dump 1200 documents on you is to put all the onus on your responsibility, on you.”

Most people in bidding treat document volume as an administrative problem. Annoying, time-consuming, the price of doing business. He was describing something different and more accurate: the volume is the mechanism. Everything in that pack is deemed read. Every requirement in it is deemed accepted. The party who sent it has discharged its obligation to tell you, and the party who received it now carries anything it failed to spot.

That is risk transfer, executed through a file share.

Why it matters more than it sounds

Once you see it that way, several things that look like inefficiency turn out to be rational behaviour by people responding to an incentive.

His colleague put the human limit plainly:

“it’s only human nature that we cannot read absolutely every single item, every single word in every single document.”

That is not an admission of sloppiness. It is arithmetic. Give a team of four a fortnight and twelve hundred documents, and complete reading is not available at any level of diligence. What is available is a judgement about where to look, made under pressure, by someone who will be blamed if the judgement is wrong.

So teams do two things, and both cost money.

They over-cover. Faced with a requirement that might apply, the safe answer is to include for it. A pre-construction manager at the same firm described where that ends up:

“we have an awful habit of… filling in the gaps, you know, scope gaps, we include for the whole lot and then whenever we submit the feedback comes back. Jesus, crazy money.”

Priced out of the job by prudence.

Or they miss something, and carry it:

“something in the scope of works that say we’ve missed that in broad daylight… we haven’t quoted for it and it’s required. We’d have to do it off of our own back. So we’re potentially losing money.”

Between those two failure modes sits every ambiguous clause in the pack, and a decision nobody has time to make properly.

What actually helps

Not reading faster. Nobody reads twelve hundred documents faster.

What helps is changing what the reading is for. The useful question is not “what does this pack say?” — it is “what does our response fail to cover?” Those sound similar and they are not. The first is unbounded. The second is answerable, because it is checked against a fixed thing: what you have actually written.

That is the shift worth making, whether or not any software is involved. Stop trying to consume the pack and start interrogating your own answer against it.

The part that is not a technology problem

None of this makes the transfer of risk go away. The clause is still there, the liability is still yours, and the client still constructed the pack the way they did on purpose.

What changes is whether you find out in week one or after the feedback. That is the whole of the difference, and it is worth more than it sounds — because in week one it is a decision, and after the feedback it is a loss.