A contractor once walked me through a project that still bothered him.
The job wasn’t a disaster.
The field crew did good work.
The schedule mostly held.
But the margin was gone.
When he described what happened, none of it sounded dramatic.
A concrete subcontractor had excluded part of a pour that everyone assumed was included.
Two trades discovered halfway through the job that each thought the other owned a piece of work.
A small change order early on turned into a pricing argument weeks later.
Nothing catastrophic.
Just enough friction to slowly drain the profit out of the job.
When we walked the project backward, something became obvious.
None of those problems started in the field.
They were already baked into the job months earlier.
That’s the part that tends to surprise people.
Most operators assume projects succeed or fail during execution.
Productivity.
Weather.
Subcontractor performance.
But if you spend enough time around project-driven businesses, you start noticing something else.
The outcome of a job is often decided long before the work begins.
Not through one big decision.
Through a handful of small ones.
Over time I started noticing that many of those decisions cluster around the same moments.
Places where the work should pause until something is clarified.
Instead, the project moves forward.
Usually because someone says some version of the same sentence:
“Let’s move ahead and sort the details out later.”
Those moments act like small gates in the system.
Not formal ones.
Just the points where risk either gets contained — or quietly enters the project.
In theory the scope package is finished before subcontractors see it.
In practice it’s often half-formed.
Drawings are still evolving.
Responsibilities between trades are implied rather than written.
A few details still need to be figured out.
But the schedule is tight.
So the RFQ goes out anyway.
Subcontractors react in predictable ways.
Some add contingency.
Some exclude the uncertain pieces.
Some interpret the scope differently than the team intended.
Now three bids come back that look roughly comparable.
But they’re built on different assumptions.
Six weeks later those assumptions collide.
One subcontractor says a piece of work wasn’t included.
Another trade insists they never owned that coordination task.
Someone pulls out the drawings.
And by that point the work is already underway.
Which means the leverage to resolve the disagreement is gone.
That moment alone typically introduces 10–25% cost exposure before a shovel ever hits the ground.
This is where something subtle happens.
Most teams compare numbers.
But the numbers are only meaningful if the bids are normalized to the same scope.
One vendor includes mobilization.
Another excludes cleanup.
Another interpreted a specification differently.
The numbers still look close.
So the lowest bid wins.
Months later the gap surfaces.
A project manager asks the subcontractor to complete a task that seems obvious from the drawings.
The subcontractor replies:
“That wasn’t included.”
And the part that matters is that both sides are usually telling the truth.
Because the subcontractor didn’t underbid the job.
They bid a different job.
Which is why “lowest bid” only works when the bids are normalized to the same scope.
Otherwise you’re not selecting the lowest price.
You’re selecting the most optimistic interpretation of the drawings.
When that happens, the correction usually shows up as change orders, schedule friction, or coordination problems.
The cost exposure from that single moment can easily land in the 10–20% range by the time the job closes.
You can almost predict the conversation.
The schedule is tight.
The subcontractor says they can mobilize immediately.
Someone in the room says:
“We’ll finalize the paperwork while they get started.”
Everyone nods.
It seems practical.
Work begins before the contract language is finalized.
Insurance certificates are still coming.
Payment terms may not be locked down.
Change order language hasn’t been reviewed carefully.
Once the job starts, nobody wants to stop it.
So whatever risk was sitting in that contract simply becomes part of the project.
It happens when invoices come through.
The project manager is dealing with field issues.
Invoices stack up.
Finance wants to keep vendors paid and projects moving.
So approvals become administrative rather than operational.
Small discrepancies slip through.
Work billed ahead of completion.
Unapproved change work folded into invoices.
Quantities that don’t quite match field records.
Individually those errors look trivial.
Across dozens of invoices they accumulate.
Usually somewhere in the 1–3% range of subcontract value.
Which doesn’t sound like much until you multiply it across multiple projects.
That’s the moment that rarely gets fixed, because it never looks like a crisis.
I sent an early draft of this to a contractor.
His response was immediate:
this isn’t theoretical — it’s happening inside active projects.
But from his side, it doesn’t look like scope creep or indecision.
It looks like this:
– requirements that were never fully defined
– changes introduced midstream
– decisions that keep moving
And the work doesn’t stop.
So they adapt.
They start documenting everything.
They track every change.
They build a record of delays.
They push for decisions the customer hasn’t made.
He called it “reverse managing the customer.”
Not because they want to —
but because the system on the other side can’t carry the work.
That effort doesn’t create value.
It contains damage.
And it shows up as friction, change orders, and a slow bleed of margin that neither side planned for.
The leak isn’t in the work.
It’s in the structure that defines the work.
What makes these moments dangerous is that they compound.
A little scope ambiguity.
A bid that wasn’t normalized.
Work that started before the paperwork caught up.
A few invoices approved because everyone was busy.
None of those decisions looks fatal on its own.
Stack them together and the project’s economics can drift quickly.
It’s not unusual for a job to be 30–40% off its intended cost structure before it’s halfway complete.
If you spend enough time around projects, the same phrases tend to show up right before problems do.
The contractor I mentioned at the beginning knew all of this.
He’d been running projects for years.
The gates didn’t fail because he didn’t understand them.
They failed because the schedule was tight and he trusted his judgment.
That’s usually how it happens.
Not through one big mistake.
Just a few small ones that seemed reasonable at the time.
No posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.