Your inbox is full. Slack is piling up. Client messages need a response yesterday. Typing thoughtful replies to all of it takes hours you don't have.

Wispr Flow turns your voice into clean, professional text you can send the moment you stop talking. Speak like you would to a colleague — tangents and all — and get polished output. Emails, Slack, LinkedIn, WhatsApp, whatever's open.

89% of messages sent with zero edits. Used by teams at OpenAI, Vercel, and Clay. Works on Mac, Windows, and iPhone.

Try Wispr Flow free

Welcome back to Beyond Deadlines newsletter—a free perk for people looking to improve in Planning and Scheduling. Each week, we provide tactics, prompts, jobs and food for thought. We want you to succeed today, tomorrow and throughout the rest of your career.

*Think of the above quote in terms of your project and how it will change overtime.

I recently posted on LinkedIn about how we account for uncertainty in cost but often treat schedule dates as precise predictions. The problem seemed to resonate, but when I asked how people actually create schedule contingency, nearly every solution pointed back to QSRA.

QSRA is a great tool.

But surely that can't be our only strategy for dealing with schedule uncertainty.

It isn't.

The more I thought about it, the more I realized we already have dozens of ways to create schedule contingency.

We just don't always call them contingency.

Some are analytical.

Some are operational.

Some are commercial.

Some are contractual.

And some aren't time at all.

So instead of asking:

"How much contingency should the schedule have?"

I think we should ask:

"Where should we create contingency, who owns it, and what uncertainty is it protecting us from?"

Here are some of the options available to us:

That's a much bigger toolbox than:

"Run a QSRA."

And different tools make sense at different points in the project.

An owner making a commitment three years before construction needs a different strategy than a GC developing its baseline.

And that GC needs a different strategy than an electrical contractor trying to protect energization three months from now.

Let's break the options down.

The simplest strategy is finishing earlier than required.

Contract completion: December 31.

Planned completion: November 30.

Contingency: 31 days.

Simple.

But there's a catch.

If management turns November 30 into the new external commitment, you didn't create contingency.

You created a more aggressive commitment.

Someone creates float. Management sees float. Management takes float.

Your contingency lasted seven minutes.

Owners can create more layers because they often control the dates before the contract exists.

For example:

Planning forecast: 30 months
Management target: 32 months
External commitment: 34 months

The project team manages toward 32 months while leadership protects the 34-month commitment.

You can also protect the business date rather than just construction completion.

Construction complete: June 1.
Operations need the facility: July 1.

That month can absorb punch list, retesting, training, documentation, move-in, late equipment, operational readiness, or commissioning issues.

Because the real objective usually isn't "finish activity A12345."

It's energize the data center.

Start production.

Open the hospital.

Turn over the building.

Generate revenue.

Protect the outcome that actually matters.

Early in development, you may not have enough detail for sophisticated risk analysis.

That's okay.

An owner could apply a top-down allowance based on project maturity, complexity, historical performance, or risk.

For example:

Conceptual schedule: +20%
Design development: +15%
Procurement/construction planning: +10%
Mature baseline: +5%

Those are examples, not universal recommendations.

The principle matters more:

Contingency should generally shrink as uncertainty is retired.

Historical performance can make this better.

Instead of asking what this schedule says, ask what happened on the last 20 similar projects.

If projects planned for 24 months routinely took 26, 28, or 30 months, that's useful information.

For owners repeatedly building data centers, semiconductor fabs, warehouses, hospitals, retail programs, or manufacturing facilities, the portfolio itself can become a risk model.

And, of course, this is where QSRA fits.

P50. P70. P80. P90.

You might establish:

Internal target: P50
Contract commitment: P70
Business commitment: P80

QSRA is powerful.

It's just one tool in the toolbox.

Not all contingency needs to sit at project completion.

You can protect intermediate milestones:

Steel complete.

Dry-in.

Permanent power.

Mechanical completion.

Ready for commissioning.

Substantial completion.

That creates local protection around the events that actually matter.

You can take the same approach with the things feeding those milestones.

If switchgear is needed August 1, don't plan delivery for August 1.

Maybe you establish:

Vendor promise: July 1
Required on site: July 15
Installation need: August 1

Now you have room for manufacturing delays, logistics, inspections, receiving problems, or damage without immediately affecting installation.

Do the same upstream with design.

If construction needs IFC drawings June 15, maybe the design target is May 15 and the formal required date is June 1.

Decisions can work the same way.

Target decision date.

Required decision date.

Last responsible moment.

Permits, utilities, OEM technicians, inspections, controls, commissioning documentation, and weather can all have explicit protection as well.

The point is to put the contingency close to the uncertainty it's protecting.

That creates local containment.

A problem in foundations doesn't automatically consume the contingency protecting commissioning.

Just don't confuse deliberate contingency with padding every activity.

One is risk management.

The other destroys schedule transparency.

Here's where contingency gets more interesting.

Contingency doesn't have to be time.

Maybe the base plan needs 40 electricians, but 50 are available.

Maybe the schedule assumes five 10-hour days, but a sixth day is available.

Maybe you can add another crane.

A second commissioning team.

Additional startup technicians.

Another installation crew.

More fabrication capacity.

A second shift.

Those are all forms of schedule contingency.

You may never exercise them.

But having them changes your exposure to delay.

Think about a trade contractor.

Base plan: 2 crews.
Recovery plan: 3 crews.
Emergency plan: second shift.

The contingency isn't sitting in P6 as 15 days of float.

It's sitting in executable capacity.

And that raises an interesting possibility:

A schedule with zero float but several realistic recovery options may actually be more resilient than a schedule showing 20 days of float with nowhere to go when something fails.

The best recovery plan is usually designed before you need recovery.

The shortest plan isn't always the strongest plan.

Imagine the baseline sequence is:

Area 1 → Area 2 → Area 3

If Area 2 isn't available, can the crew execute:

Area 1 → Area 3 → Area 2?

A crew with one available work front is fragile.

A crew with three constraint-free work fronts has options.

Buildings, floors, rooms, zones, systems, and equipment can all provide that flexibility if the work is packaged correctly.

Scope can create another release valve.

Ask:

"What absolutely must be complete to achieve this milestone?"

Maybe landscaping, finishes, documentation, training, or other noncritical work can follow operational readiness.

Everything that isn't required for the milestone becomes a potential sequencing option.

Means and methods can create similar flexibility.

Prefabrication.

Modularization.

Off-site assembly.

Parallel work fronts.

Early procurement.

Temporary systems.

Alternate installation methods.

At this point, we're no longer asking:

"Where can we add 20 days?"

We're asking:

"How do we build the execution strategy so one problem doesn't stop the project?"

That's a much better planning question.

Eventually somebody asks:

Who owns the float?

The owner?

GC?

Party that created it?

First party to use it?

The project?

Imagine a GC plans to finish 30 days before contractual completion.

Then an owner-caused event consumes 20 days.

Did the owner delay the contractor?

Or did the project simply consume available float?

That answer can have major financial consequences.

Don't wait for the delay to decide.

The schedule and contract need to tell the same story.

Contracts should also distinguish between dates like:

Contract Completion
Baseline Planned Completion
Current Forecast Completion
Internal Target Completion

Those aren't synonyms.

Keeping them separate allows teams to manage aggressively without automatically turning every internal target into a contractual commitment.

The contract should also establish how time extensions work.

What qualifies as excusable delay?

How is concurrency treated?

How is abnormal weather handled?

When is notice required?

How will Time Impact Analyses be performed?

Which schedule is used to evaluate the impact?

These aren't just claims questions.

They're part of your contingency strategy.

Contract language varies, so the exact provisions need to be developed with the appropriate commercial and legal teams.

Owners have another advantage.

They don't necessarily have to give all their contingency to the contractor.

Maybe the contractor is required to finish November 30.

But the business doesn't need the facility until December 31.

That month can remain an owner-held reserve against owner-retained risk.

Money around dates creates another lever.

Maybe there's an early-completion incentive before November 15.

Contract completion is November 30.

Liquidated damages begin after December 1.

Now you've created an economic structure around schedule performance.

Another option is shared contingency.

Instead of fighting over every day, create a project reserve with agreed rules for using it.

Maybe the project starts with 30 days:

30 days remaining: Green
20 days: Yellow
10 days: Red
0 days: Executive recovery plan

Now contingency becomes something the team actively manages instead of something everyone argues about after it disappears.

This may be the biggest opportunity.

If you start with $10 million of cost contingency and spend $2 million, everyone knows $8 million remains.

Why don't we routinely do the same thing with time?

Starting contingency: 45 days
Utility delay: -8 days
Design issue: -5 days
Procurement recovery: +3 days
Remaining contingency: 35 days

That tells leadership much more than watching the completion milestone stay green until it suddenly turns red.

Then track the burn rate.

Thirty days remaining sounds comfortable.

Except maybe you had 60 days three months ago.

You're burning 10 days per month.

Now you're forecasting when the buffer disappears, not just when the project finishes.

And contingency shouldn't only be consumed.

It should be released when uncertainty disappears.

Utility energized?

Release utility contingency.

Major equipment delivered?

Release procurement contingency.

Building dried-in?

Release weather contingency.

Commissioning Level 3 complete?

Release another portion.

That creates a risk-retirement curve:

Early project: high uncertainty → high contingency.

Late project: lower uncertainty → lower contingency.

That feels much closer to how we already think about cost contingency.

I don't think construction needs one universal formula for schedule contingency.

We need a toolbox.

Contingency can be time.

But it can also be capacity.

Alternate work fronts.

Sequence flexibility.

Scope flexibility.

Commercial terms.

Contractual protections.

Or statistical confidence.

Different risks deserve different protections.

And different parties should hold different contingency.

An owner three years before construction shouldn't manage uncertainty the same way an electrical contractor three months from energization does.

So when you're building or reviewing a schedule, ask five questions:

That last question matters.

Contingency nobody manages eventually becomes invisible float.

And invisible float has a habit of disappearing.

Don't just ask your scheduler for the completion date.

Ask what's protecting it.

Where is the contingency?

What risks does it cover?

Who owns it?

How much has been consumed?

What recovery options remain?

What happens when it reaches zero?

A finish date can be mathematically precise and still be unreliable.

Build the contingency architecture before you need it.

NY US Construction Scheduler

Infrastructure & Capital Projects, Data Center Scheduler (multiple levels), ANS

Construction Scheduler

^{We have no connection to these jobs or companies. Our goal is simply to help you land the job of your dreams.}

This week’s episode we dive into how to nail an interview. Watch or Listen on Spotify, Apple Podcasts or Youtube.

Thank you for reading.

Check out Micah, Greg and Beyond Deadlines on LinkedIn.

Sign up for our LinkedIn newsletter.

Subscribe to our YouTube Channel.

Listen to the podcast on Spotify or Apple Podcasts. Visit our website.

See you next week,