Resource Management

Executives don’t lose sleep over Gantt charts.

They lose sleep over safety incidents, delayed in-service dates, claims exposure, workforce instability, and reputational risk

Yet most megaprojects still govern delivery using a model that ignores the most basic physical constraint on site:

How many people the site can actually support at one time.

We routinely approve schedules that look technically sound:

✔ Clean logic

✔ Stable milestones

✔ Acceptable cost curves

✔ “Balanced” craft loading

While the site itself tells a very different story:

✖ Congested access points

✖ Overloaded welfare facilities

✖ Diluted supervision coverage

✖ Rising interference and rework

✖ Declining productivity and safety margin

When those signals appear, we label them “execution issues.”

They’re not.

They’re governance failures.

If Capacity Isn’t Enforced, Commitments Are Fiction

A plan that cannot be executed safely, predictably, and repeatedly inside real physical limits is not a plan.

It is a hope statement with milestones attached.

Physics doesn’t negotiate.

Space doesn’t stretch.

Throughput doesn’t scale on demand.

Supervision doesn’t magically multiply.

Yet our schedules pretend they do.

The Leadership Shift Most Organizations Avoid

Modern project governance must treat physical capacity as a first-class control — not an operational afterthought.

That means:

• Total site headcount becomes a governed constraint

• Every population consumes capacity — not just craft labor

• Supervision and support density are visible and managed

• Unscheduled work reserves real capacity

• Shifts are governed independently

• Schedules move when limits are breached — not people

When this happens, the schedule stops negotiating with reality.

Why This Feels Uncomfortable

Because real capacity governance exposes:

Overcommitment baked into portfolios Optimism bias in business cases Political scheduling pressure False recovery narratives The hidden cost of congestion and interference The true limits of site throughput

Avoiding that discomfort doesn’t reduce risk.

It only delays when the truth surfaces — usually in the field.

The Question Leadership Should Be Asking

Not:

“Are we on schedule?”

But:

“Is this plan physically executable inside our real constraints — every shift, every day?”

If leadership can’t answer that with evidence, governance is incomplete.

Most megaproject disputes don’t start with bad contracts.

They start with good contracts operating inside broken delivery systems.

I’ve seen billion-dollar projects where:

The contract was technically sound Risk allocation was clearly written Change mechanisms were compliant Legal positions were defensible

…and yet the project still devolved into claims, friction, and commercial trench warfare.

Not because anyone breached the contract —

but because the contract was never designed to manage how work actually flows.

⚠️ The Hidden Assumption Inside Most Contracts

Most contracts quietly assume:

Stable access to work areas Predictable productivity Clean interfaces between contractors Unlimited buffering capacity Rational decision cycles Linear sequencing Infinite space, logistics, and shared services

That world does not exist on real megaprojects.

Reality looks more like:

Parking caps limit workforce ramp-up Lunchrooms, gates, laydown and cranes become bottlenecks Trades stack on top of each other chasing the same access Interfaces collide daily Productivity erodes silently before anyone can prove causality Decisions lag while the field improvises Schedules remain logically correct and physically impossible

Contracts don’t fail here.

The system fails — and the contract becomes the weapon of last resort.

🧨 Where Disputes Actually Come From

Disputes rarely originate from a single event.

They accumulate through invisible operational drift:

Congestion increases → productivity decays Resequencing becomes constant → logic credibility erodes Temporary fixes become permanent behaviors Access restrictions normalize Resource stacking becomes the default Change backlog grows Commercial trust degrades Everyone starts protecting their position instead of optimizing flow

By the time cost variance shows up, the damage is already baked in.

Claims don’t create conflict.

They simply reveal it.

🧠 Contract Administration Is Not Paperwork — It’s System Control

Strong contract administration is not:

Managing correspondence Policing clause compliance Arguing entitlement Chasing signatures Building defensive records

That’s late-stage behavior.

High-performing projects use contract administration to:

Detect operational drift early Surface constraint buildup Stabilize production flow Resolve friction before positions harden Align behavior with commercial intent Maintain trust while protecting accountability

The goal isn’t winning disputes.

The goal is preventing the system conditions that create them.

🔎 The Blind Spot: We Manage Outputs, Not Capacity

Most project controls still focus on:

Schedule logic Milestones Earned value Percent complete Cost variance

These measure outcomes — not constraints.

They tell you what already happened.

They don’t tell you what’s about to break.

Very few projects actively manage:

Physical capacity limits Space utilization Access throughput Shared service loading Shift congestion Interface density Resource stacking risk

Yet these are the real drivers of productivity, predictability, and claims.

When capacity is unmanaged, commercial stability becomes impossible — no matter how strong the contract is.

🎯 The Real Question Leaders Should Be Asking

Not:

“Is the contract enforceable?”

But:

“Is our delivery system capable of executing what the contract assumes?”

If the system cannot absorb variability, complexity, and constraint — disputes are inevitable.

You can’t lawyer your way out of physics.

🚀 The Opportunity

Megaproject performance will not improve by writing smarter clauses.

It will improve when organizations:

Treat capacity as a managed asset Design governance around flow, not just compliance Instrument constraints instead of hiding them Align incentives with system stability Surface risk before it becomes commercialized Run projects as integrated operating systems — not fragmented contracts

That’s where disputes disappear — not because anyone surrendered leverage, but because the system stopped creating friction in the first place.

Target Price contracts are often positioned as the “collaborative” alternative to lump sum or reimbursable delivery.

In theory, they align incentives.

In practice, they often expose a deeper problem: we still don’t understand cost drivers at a system level.

Before debating whether Target Price works, we need to be honest about what it assumes.

What a Target Price Model Is Supposed to Do

At its core, a Target Price contract sets:

A baseline cost (the target) A pain/gain sharing mechanism An expectation that owner and contractor will jointly manage risk

If the final cost comes in below target, both parties share the upside.

If it exceeds the target, both share the downside.

On paper, this encourages:

Early collaboration Transparent decision-making Cost discipline without adversarial behaviour

That’s the promise.

The Hidden Assumption No One Talks About

Target Price models quietly assume something critical:

That the target itself is grounded in a realistic, executable system.

Most are not.

Why?

Because many targets are still built on:

Unit-rate estimates Static productivity assumptions Sequential work logic Idealized schedules Unlimited site capacity

In other words, the target is often logically correct but physically impossible.

When the baseline is flawed, the contract doesn’t align incentives — it institutionalizes conflict.

Why Target Prices Fail in Execution

When projects miss target, the root cause is rarely effort or intent.

It’s usually one of three structural blind spots:

1. Resource Reality Is Ignored

Targets are commonly set without modeling:

Actual crew availability Trade stacking limits Access constraints Space, parking, or facility capacity Shared resource contention across contractors

Cost overruns then appear as “performance issues” rather than system constraints.

2. Risk Is Priced, Not Governed

Risk registers are converted into contingencies — and then forgotten.

But risk is not static.

It materializes through:

Throughput limits Schedule compression Deferred decisions Crowding effects

When risks convert into real constraints, the target price has no mechanism to adapt — only to argue.

3. Pain/Gain Is Applied After the Damage Is Done

Most Target Price models focus on outcomes, not leading indicators.

By the time cost variance shows up:

Capacity has already been exceeded Efficiency has already degraded Rework and congestion are already embedded

The contract reacts to failure instead of preventing it.

When a Target Price Does Make Sense

Target Price can work — but only under specific conditions:

✅ The target is built bottom-up from resource demand

Not just quantities, but:

Crew size and composition Shift patterns Access windows Utilization limits

✅ Constraints are treated as design inputs, not surprises

Space, logistics, throughput, and shared services are explicitly governed — not “managed in the field.”

✅ Cost control focuses on flow, not variance

The goal is not to hit the number.

The goal is to maintain balanced supply and demand across the system.

✅ Incentives reward constraint management, not heroics

Teams are rewarded for preventing overload, not absorbing it.

The Real Question Isn’t “Is Target Price Good or Bad?”

The real question is:

Is your target price modeling the system you are actually building — or the one you wish you had?

If the target ignores physical limits, human capacity, and shared resources, then no contract structure will save it.

You’ll still get:

Defensive behaviour Claims framed as “unforeseen” Post-hoc alignment instead of proactive control

Just with better intentions and worse disappointment.

Final Thought

Target Price doesn’t fail because people don’t collaborate.

It fails because the system they’re collaborating within is misunderstood.

Until cost targets are grounded in real capacity, real constraints, and real flow, Target Price is just optimism with a formula.

And optimism is not a control strategy.

Every time someone says

“That’s not industry standard,”

what they usually mean is:

“That’s not how I learned to be successful.”

Let’s be honest.

Most so-called industry standards were formed when:

• Projects were smaller

• Interfaces were fewer

• Constraints were looser

• Failure was cheaper

• Visibility was limited

They survived not because they were optimal —

but because they were good enough.

Good enough to avoid hard conversations.

Good enough to protect careers.

Good enough to keep reports green.

The Problem With “Normal”

Normal feels safe.

Normal feels proven.

Normal feels professional.

But normal also:

• Accepts recovered schedules that never recover on site

• Explains productivity loss as “execution issues”

• Treats physical constraints as afterthoughts

• Confuses activity logic with delivery capability

We don’t lack data.

We lack honesty about what the data is actually telling us.

Why New Ideas Get Attacked First

Here’s the uncomfortable truth:

New methods aren’t rejected because they’re unproven.

They’re rejected because they redefine competence.

When you change the model, you change:

• What gets measured

• Who looks good

• Where authority sits

• What “good planning” actually means

That feels threatening — especially to people who succeeded under the old rules.

So resistance shows up as:

“That’s theoretical.”

“That’s overcomplicating things.”

“We’ve delivered without that before.”

But notice something:

The same skepticism is rarely applied to methods that repeatedly fail quietly.

The Double Standard No One Admits

If a new approach underperforms once — it’s dismissed.

If a traditional approach underperforms consistently — it’s tolerated.

Why?

Because failure is acceptable

as long as it looks familiar.

Change Doesn’t Fail Because It’s Wrong

Change fails because it’s polite.

It tries to convince instead of confront.

It seeks consensus before clarity.

It avoids discomfort — and misses the system.

Real change introduces tension.

Between:

• Plans and physical reality

• Reports and lived experience

• Comfort and accountability

If your idea isn’t causing friction, it’s not touching the real constraint.

Being Early Is Lonely

Being early doesn’t feel like leadership.

It feels like repetition.

Resistance.

Misunderstanding.

You end up explaining problems

before others are ready to admit they exist.

But every practice that is now “industry standard”

was once dismissed as unnecessary.

The difference is simple:

Some people wait for permission.

Others wait for reality to catch up.

Reality always does.

💬 Question for the industry:

What “standard practice” do we still defend — even though it clearly no longer fits the projects we’re delivering?

If this made you uncomfortable, good.

That’s usually where the truth lives.

After stripping away the illusions of unit rates, logic-only schedules, earned value comfort, and recovered-schedule fiction, one question remains:

If those don’t create control — what does?

The answer is not a new tool.

It is a different operating model.

Control Starts With Accepting Limits

Capacity-managed control begins with a truth most projects avoid:

Not all work can happen at the same time — no matter how logical the plan looks.

Every site has hard limits:

Space Access Supervision Logistics Safety Cognitive load

These are not risks.

They are governing constraints.

Until they are explicitly acknowledged, planning remains aspirational instead of executable.

From Activity Management to System Management

Traditional controls focus on:

Activities completed Percent complete Milestones achieved

Capacity-managed control focuses on:

How many people the system can absorb Where work density becomes destructive Which constraints are currently binding How utilization changes under pressure

The shift is subtle — and profound.

Progress becomes secondary to throughput stability.

Governing Crew Density (Not Just Headcount)

Capacity-managed projects don’t ask:

“How many crews do we need?”

They ask:

“How many crews can this system safely and efficiently support?”

This leads to deliberate decisions:

Limiting parallel work even when scope exists Protecting critical workfaces from trade stacking Sequencing to preserve productivity, not just dates Reducing crews to increase output

Counterintuitive — and consistently effective.

Measuring What Actually Predicts Performance

Instead of waiting for CPI/SPI to turn red, capacity-managed control tracks leading indicators:

Utilization vs. availability Crew density by zone Time lost to interference Standby and waiting accumulation Constraint saturation trends

These signals surface weeks or months before traditional metrics move.

By the time cost variance appears, the decision window is already closed.

Capacity signals reopen it.

Planning Becomes a Constraint Conversation

In a capacity-managed environment, planning meetings change tone.

The question is no longer:

“Can we pull this work left?”

It becomes:

“What breaks if we do?”

Every acceleration has a visible trade-off:

Where efficiency will degrade Which constraints will bind What the cost of pressure will be

This doesn’t slow decisions.

It improves them.

Why Recovery Becomes Rare

When capacity is governed from the start:

Schedules stretch realistically Estimates stop assuming efficiency Crews stop fighting each other Progress becomes predictable

Recovery plans still exist — but they are measured, targeted, and honest.

Not heroic.

Not theatrical.

Not fictional.

The CRU View of Control

CRU defines control differently:

Control is not reacting faster.

Control is designing a system that doesn’t need recovery.

Capacity-managed control doesn’t eliminate risk.

It eliminates self-inflicted damage.

That alone changes outcomes.

Final Thought

If your controls rely on:

Perfect sequencing Infinite parallelism Late-stage variance detection Heroic recovery plans

You don’t have control.

You have hope — formalized in spreadsheets and schedules.

Real control starts earlier.

Runs quieter.

And looks boring on dashboards.

But it delivers.

Recovered schedules are one of the most dangerous artifacts in project delivery.

They look decisive.

They sound responsible.

They reassure leadership.

And more often than not, they are fiction.

What a “Recovered” Schedule Really Is

A recovered schedule is not proof of regained control.

It is proof that the planning system still believes control comes from logic, not capacity.

When a schedule slips, the recovery playbook is familiar:

Add parallel work Increase crew sizes Compress logic Authorize overtime Resequence activities

On paper, the finish date moves back into alignment.

On site, efficiency collapses.

Why Recovery Plans Feel So Convincing

Recovered schedules are persuasive because they operate in a world without physical limits.

They assume:

Space can absorb more people Supervision can scale instantly Logistics can stretch indefinitely Productivity remains constant under pressure

The schedule doesn’t see congestion.

It doesn’t feel interference.

It doesn’t register waiting.

So it declares victory.

The Control Paradox

This is the paradox at the heart of recovered schedules:

The more pressure the system is under,

the more the plan assumes efficiency.

As performance degrades, recovery logic demands more parallelism.

As congestion grows, the schedule responds by adding density.

What looks like control is actually accelerated loss of control.

Why “More Crews” Rarely Means More Progress

When capacity is constrained, adding crews:

Increases trade stacking Raises coordination overhead Expands idle and standby time Degrades individual productivity Amplifies rework and safety risk

Recovered schedules treat labor as infinitely scalable.

Real sites do not.

The result is a widening gap between planned progress and actual throughput.

How Recovered Schedules Mask Failure

Recovered schedules don’t fail loudly.

They fail by:

Hiding efficiency loss inside activity progress Shifting blame to execution teams Normalizing overtime and heroics Creating false confidence in reporting cycles

By the time recovery is proven impossible, cost and time are already sunk.

The schedule didn’t prevent failure.

It postponed recognition of it.

The Illusion of Control

Recovered schedules give leaders something dangerous:

The feeling that something is being done.

But control is not activity.

Control is constraint awareness.

If the recovery plan does not explicitly answer:

What capacity is binding? Where productivity will degrade? How many people the system can truly absorb? What efficiency loss is being traded for time?

Then it isn’t control.

It’s choreography.

The CRU Position

CRU challenges the idea that schedule recovery is primarily a logic exercise.

True recovery is a capacity decision, not a sequencing one.

Sometimes the most controlled decision is:

Slowing down Reducing parallelism Rebalancing crews Accepting short-term delay to prevent long-term collapse

Recovered schedules rarely allow those conversations.

What Real Control Looks Like

Real control is visible before recovery is needed.

It means:

Governing crew density Protecting critical workfaces Limiting parallel execution Measuring utilization, not just progress Making trade-offs explicit, not hidden

When control is real, recovery plans are rare.

Because the system never pretended it could do the impossible.

Final Thought

Recovered schedules don’t demonstrate control.

They demonstrate belief.

Belief that logic can overpower physics.

Belief that people can absorb unlimited pressure.

Belief that efficiency will return if we push hard enough.

Reality always wins.

And when it does, the schedule isn’t in control.

It never was.

Earned Value Management (EVM) is often treated as the ultimate truth-teller.

Numbers don’t lie.

Metrics don’t have opinions.

Dashboards don’t have egos.

And yet — on project after project — EVM turns red after the outcome is already unavoidable.

That’s not a tooling problem.

That’s a systems problem.

What Earned Value Is Actually Good At

EVM is excellent at measuring one thing:

Variance against an assumed plan.

It tells you:

How much work was planned How much work was performed How much money was spent doing it

If the plan is sound, EVM is powerful.

If the plan is built on false assumptions about efficiency and capacity, EVM becomes a lagging indicator of inevitability.

The Assumptions EVM Inherits (But Never Questions)

Earned Value does not challenge the plan.

It inherits it.

Which means it also inherits every flawed assumption embedded upstream:

That unit measures priced reality That schedules were physically executable That productivity was stable That parallel work increased progress

When those assumptions break down on site, EVM doesn’t expose the root cause.

It simply reports the damage.

Why EVM Turns Red Too Late to Matter

Here’s the pattern almost everyone recognizes:

Early EV looks healthy SPI and CPI hover near 1.0 Confidence increases Crews are stacked to “maintain momentum”

Meanwhile, on site:

Congestion grows Waiting increases Productivity erodes Efficiency quietly collapses

But EV still looks acceptable — because work is technically being completed.

By the time EV clearly turns red:

Duration has already slipped Costs are already committed Recovery options are limited Narratives harden into blame

EVM didn’t warn you.

It confirmed what had already happened.

The Core Problem: EVM Measures Output, Not Capability

Earned Value answers:

“Did we complete the work we said we would?”

It does not answer:

“Was the system capable of sustaining this work efficiently?”

It cannot see:

Overcrowding Trade interference Idle labor masked as progress Declining utilization Capacity saturation

As long as output continues — even inefficiently — EV reports progress.

This is how projects stay “green” while being structurally doomed.

Why “Recovery” Makes Things Worse

When EV starts slipping, the standard response is predictable:

Add crews Increase parallel work Compress logic Authorize overtime

On dashboards, this looks like action.

On site, it often accelerates failure.

More crews in a constrained system don’t restore efficiency — they destroy it.

EV may temporarily stabilize…

while real productivity collapses even faster.

The Illusion of Control

This is the most dangerous part.

Earned Value creates a powerful illusion:

“If we can measure it, we can manage it.”

But you cannot manage what your metrics are blind to.

If EVM is not paired with:

Resource utilization visibility Capacity thresholds Congestion signals Efficiency decay indicators

Then it becomes a post-mortem tool disguised as a control system.

The CRU Position

CRU does not reject Earned Value.

CRU rejects the idea that EVM alone is sufficient.

EVM must sit downstream of:

Resource-based estimating Capacity-aware scheduling Utilization governance

Otherwise, it doesn’t prevent failure.

It documents it beautifully.

What Real Control Looks Like

Real control happens before variance appears.

It requires asking harder questions earlier:

How many people can this system actually absorb? Where does efficiency begin to decay? What does congestion cost per week? Which constraints are binding right now?

When those questions are answered, EV becomes useful again — because it is measuring a plan grounded in reality.

Final Thought

Earned Value doesn’t tell you why projects fail.

It tells you when failure becomes undeniable.

If your controls only speak after the system has already broken, they aren’t controls.

They’re witnesses.

If unit-measure estimates assume efficiency,

most schedules institutionalize that assumption.

They do it quietly, convincingly, and with great confidence.

The problem isn’t that schedules are wrong.

It’s that they are logically correct and physically impossible at the same time.

The Shared Blind Spot Between Estimates and Schedules

Unit-measure estimates and traditional schedules fail for the same reason:

They model work, not capacity.

Estimates assume activities can be executed efficiently.

Schedules assume those activities can be sequenced cleanly.

Neither asks the most important question:

“Can the system physically absorb this much work, with this many people, at the same time?”

Logic Is Not Capacity

Modern schedules are excellent at representing logic:

Finish-to-start relationships Critical paths Milestones Float and recovery narratives

What they don’t represent is crowding.

A schedule can show ten trades working in parallel and still look healthy.

The schedule doesn’t know:

How many people can fit in the space How many crews can be supervised effectively How much access, staging, and logistics capacity exists How productivity degrades as density increases

So the schedule optimizes sequence…

while the site absorbs chaos.

Why Schedules Make Bad Assumptions Look “Managed”

When resource congestion appears, schedules don’t fail — they adapt.

They:

Resequenced work Add parallel activities Compress logic Pull recovery levers

On paper, the schedule recovers.

On site, efficiency collapses.

The schedule says:

“Work can happen in parallel.”

The site says:

“Not with this many people.”

The Cost Signal Comes Too Late

Here’s the dangerous loop:

The estimate assumes efficiency The schedule assumes clean sequencing Crews are loaded in parallel Congestion erodes productivity Duration extends Cost increases Leadership asks, “What went wrong?”

Nothing went wrong.

The system behaved exactly as designed.

Why Resource Loading Isn’t Enough

Many teams respond by “resource-loading the schedule.”

This helps — but it doesn’t solve the core issue.

Resource loading answers:

Who is assigned to activities

It does not answer:

How many people can work in the same space When capacity limits are exceeded Where productivity collapse begins What efficiency loss costs over time

Without capacity constraints, resource loading just gives false precision.

A Better Question for Project Controls

Instead of asking:

“Is the schedule logic sound?”

Project controls should be asking:

“Is this plan physically executable with the resources available?”

That requires shifting focus from:

Activities → systems Logic → capacity Outputs → utilization

Until that shift happens, schedules will continue to look credible — right up until they aren’t.

The CRU Position

CRU challenges a foundational belief in project delivery:

You cannot schedule your way out of a constrained system.

If efficiency is lost because too many crews are forced into parallel execution, the solution is not better logic.

It’s better capacity governance.

Estimates, schedules, and controls must align around one truth:

Cost, time, and performance are consequences of how resources interact inside real constraints.

Final Thought

A logic-correct schedule can still be physically impossible.

And when it is, the schedule doesn’t protect the project —

it accelerates failure by making bad assumptions look planned.

If your plan ignores capacity,

your controls will only tell you the truth after it’s too late.

Most construction estimates don’t fail because the estimator made a mistake.

They fail because the estimating method assumes a world that doesn’t exist.

Unit-measure estimating has been the industry default for decades. It is familiar, defensible, auditable, and easy to benchmark. It produces neat numbers that look precise and give decision-makers confidence.

And yet, time after time, projects blow past those numbers.

Not because quantities were wrong — but because efficiency was assumed, not priced.

The Core Flaw in Unit-Measure Estimating

At its core, unit-measure estimating prices work output:

Cost per metre Cost per unit Cost per installation

What it does not price is how that work is actually executed.

Unit measures implicitly assume:

Crews can work in clean sequence Trades can operate independently Productivity is stable and repeatable Resources appear exactly when needed No meaningful interference exists between activities

In other words, unit measures assume that work happens in series.

Real projects operate in parallel.

And that difference is where efficiency is lost — and cost is born.

Efficiency Is Not a Rate — It’s a System Outcome

Efficiency does not live inside a unit rate.

Efficiency emerges from:

Crew size and composition How many crews are present at the same time Shared access, space, supervision, and logistics Training, onboarding, rotation, and fatigue The physical limits of the site

None of these variables are priced by unit measures.

They are assumed away.

A unit rate might tell you what a task costs under ideal conditions.

It tells you nothing about what happens when ten crews are competing for the same access, the same space, the same supervisors, and the same support systems.

Why Crew Size and Makeup Change Everything

Two projects can have identical scope, quantities, and unit rates — and still diverge by millions.

Why?

Because cost is driven by who is on site, when, and in what combination.

Crew size and composition determine:

How much parallel work is attempted How much interference is created How much idle time accumulates How quickly productivity degrades under congestion

Unit-measure estimating has no mechanism to model this.

It assumes that adding crews adds progress.

In reality, adding crews often adds friction.

More people does not mean more output once capacity limits are reached.

It often means more waiting, more rework, more coordination overhead, and more inefficiency.

The Hidden Cost Unit Measures Never See

When efficiency collapses, unit-measure estimates don’t break loudly.

They bleed quietly.

Costs don’t appear as line-item errors — they surface as:

Extended durations Standby and idle time Overtime used to “recover” Layered supervision Productivity erosion masked as execution issues

By the time cost overruns are visible, the damage has already occurred.

The estimate didn’t predict failure — it assumed it away.

Estimating Based on Resources Changes the Game

A resource-driven estimate flips the logic.

Instead of asking:

“How much should this quantity cost?”

It asks:

“What does it cost to sustain this system of work over time?”

When estimating is anchored in resources:

Crew size becomes a primary cost driver Parallel work is treated as a risk, not a benefit Efficiency is measured, not assumed Constraints are surfaced early Cost becomes a consequence of behavior, not a guess

This is not about being pessimistic.

It is about being honest.

Why This Matters More on Megaprojects

The larger and more complex the project, the more dangerous unit-measure assumptions become.

Megaprojects amplify:

Trade stacking Shared constraints Logistics bottlenecks Workforce saturation Coordination overhead

Unit measures scale quantities easily.

They do not scale complexity.

That gap is where megaprojects lose control.

The CRU Perspective

CRU exists because the industry has spent too long managing outputs instead of systems.

If efficiency is critical to cost — and it is — then efficiency must be:

Modeled Measured Governed Actively managed

You cannot manage what your estimate refuses to see.

Unit-measure estimating isn’t obsolete.

But it is insufficient.

And until the industry accepts that efficiency is an outcome of resource behavior — not a property of a unit rate — cost overruns will continue to surprise teams who did everything “by the book.”

Final Thought

If your estimate assumes perfect sequencing, stable productivity, and unlimited capacity…

It isn’t predicting cost.

It’s assuming efficiency — and hoping reality cooperates.

Reality never does.

Deep-Dive Case Study of London 2012

Executive Summary

The London 2012 Olympic and Paralympic Games are widely cited as a rare example of a megaproject delivered 
successfully against a fixed, immovable deadline. Unlike many large infrastructure programs, London completed 
its venues early, transitioned smoothly into operations, and avoided the late-stage crises that frequently 
characterize projects of similar scale and complexity.

This paper argues that London 2012 succeeded because physical capacity constraints were explicitly identified, 
governed, and enforced across the delivery system. Rather than relying solely on logical schedules, milestones, 
and cost controls, the program treated transport capacity, access, interfaces, and operational readiness as 
hard limits that shaped planning and execution decisions.

The central conclusion is clear: a schedule can be logically correct and still be physically impossible. 
London avoided this trap by aligning demand to system capacity early, continuously, and decisively.

1. Introduction: The Persistent Megaproject Paradox

Despite decades of academic research, professionalization, and methodological advancement, megaprojects 
continue to exhibit chronic underperformance. Cost overruns, schedule slippage, productivity erosion, and 
late-stage operational failures remain common across transportation, energy, and public infrastructure programs.

A recurring paradox emerges. Detailed integrated schedules are developed and maintained. Earned value and 
milestone reporting often remain within acceptable tolerance bands. Workforce plans indicate sufficient labor 
availability. And yet, on-site performance deteriorates once execution intensifies.

The disconnect lies not in the absence of planning, but in what is planned and controlled. Most megaprojects 
manage logical sequence exceptionally well. They manage physical capacity poorly—or not at all.

Logical sequence and progress metrics fail to represent finite system 
capacity, allowing misalignment to remain invisible until congestion manifests on site.

2. Reframing the London 2012 Challenge

London 2012 was not merely a construction program. It was a city-scale transformation executed within one 
of the most constrained urban environments in Europe. The Games imposed a fixed and non-negotiable completion 
date, dense surroundings, limited transport throughput, heightened security requirements, and extraordinary 
levels of public scrutiny.

Under these conditions, traditional delivery questions—such as whether individual venues could be completed 
on time—were insufficient. The more consequential question was systemic: could the delivery system absorb 
unprecedented, time-peaked demand without destabilization? This reframing fundamentally altered planning 
priorities and governance behavior.

3. Capacity as a First-Class Constraint

Many megaprojects implicitly assume that supporting systems—transport networks, access points, staging 
areas, and shared infrastructure—will scale as required. These assumptions are rarely explicit, and therefore 
rarely tested.

London 2012 rejected this premise. Capacity was treated as a governing variable rather than a background 
condition. Transport throughput, site access, interface saturation, and readiness were assumed to be finite, 
measurable, prioritizable, and enforceable.

This forced difficult but necessary trade-offs early in the program lifecycle. Activities were sequenced not 
only by logical dependency, but by whether the physical system could safely and reliably absorb them. In doing 
so, London avoided the compounding congestion effects that plague many late-stage megaprojects.

4. Interfaces as the Primary Source of Failure

Megaprojects rarely fail because a single component underperforms in isolation. Failure most often occurs 
at interfaces—where systems, contractors, and phases converge.

These interfaces include points where transport meets site access, where multiple contractors occupy shared 
spaces, and where construction overlaps with commissioning and operational readiness. Each interface 
introduces dependency, timing sensitivity, and amplification of error.

London recognized interface management as a primary delivery function rather than a coordination afterthought. 
Clear integration ownership and decision authority were established to prevent interface conflicts from 
escalating into systemic disruption.

5. Deliberate Constraint of Construction Activity

One of the most counterintuitive decisions taken during the London program was the deliberate reduction of 
construction intensity as the Games approached. Rather than maximizing visible activity, leadership 
prioritized stability, predictability, and readiness.

In many megaprojects, late-stage pressure leads to increased crew density, trade stacking, and congested access, 
often justified as necessary for schedule recovery. London recognized that beyond a critical threshold, 
additional activity degrades safety, quality, and overall throughput.

Constraining activity in sensitive zones preserved flow, reduced variability, and protected the transition 
from construction to operations.

6. Governance Designed for Constraint Management

London’s governance structures were designed not merely to report progress, but to control the delivery 
system. Decision-making authority was aligned with system-level risk, escalation paths were clear, and 
independent assurance had real influence.

This governance model mattered because capacity constraints require timely and sometimes unpopular decisions. 
Without authority, constraints tend to be negotiated away until failure forces recognition under crisis 
conditions.

7. Activity Versus Deliverability

London explicitly distinguished between being busy and being capable of delivery. High utilization was 
not mistaken for high performance, and visible slack was accepted as a reliability mechanism.

This reframing allowed leadership to prioritize system stability over short-term output, reducing the risk 
of late-stage collapse.

8. Why London 2012 Remains the Exception

Despite widespread admiration, the lessons of London 2012 have not been consistently adopted. Many 
contemporary megaprojects continue to prioritize schedule logic over physical feasibility, treat capacity as 
a risk rather than a constraint, and rely heavily on lagging performance indicators.

The barrier is rarely technical knowledge. It is organizational willingness to enforce limits, say no to 
certain demands, and accept visible slack in politically sensitive environments.

9. Conclusion: Respecting Limits as a Leadership Choice

London 2012 did not succeed because it eliminated uncertainty. It succeeded because it acknowledged limits 
and built a delivery system around them.

Ignoring constraints does not make them flexible. Until megaprojects treat physical capacity with the same 
seriousness as cost and schedule, they will continue to produce plans that are logically correct—and 
operationally impossible.

London demonstrated that another approach is possible. The enduring challenge is not learning the lesson, 
but having the discipline to apply it.