Cost of Delay Modeler Guide for Colorado

What this calculator does

Run this scenario in DocketMath using the Cost Of Delay calculator.

DocketMath’s Cost of Delay Modeler for Colorado (US-CO) helps you translate time delays into dollars using a consistent, reviewable structure. In practice, it turns “how long did (or will) this take?” into outputs your internal stakeholders can compare across options—like faster approval, earlier production, or an expedited schedule.

This guide is focused on defensibility and internal review. That means you’ll want:

• A clear set of assumptions (what changed, when, and by how much)
• Inputs that can be traced back to documents (emails, project plans, contracts, claims logs)
• Outputs expressed in a way that reviewers can audit (per-day cost rates, compounding vs. linear, and time windows)

What the model typically converts

Most cost-of-delay models follow the same conceptual pipeline:

• Delay duration → number of days (or weeks)
• Cost rate → dollars per day (or per period)
• Schedule timing → which days are “in-scope” for costs
• Discounting (optional) → present value for cash timing differences

Even if your organization uses different internal labels, you’ll usually be mapping them to those components.

When to use it

Use the Cost of Delay Modeler when you need a defensible way to quantify the impact of schedule slippage in Colorado. Good use cases include:

• Internal business cases
  Example: comparing two remedial plans—Plan A finishes 30 days sooner; Plan B finishes on the original date but requires higher upfront expense.

• Dispute-ready narratives (pre/post analysis)
  Example: you have contemporaneous records showing the delay start and end dates, and you need a consistent damages-style math narrative.

• Owner/contractor coordination
  Example: change events that shift milestones—your team wants a single spreadsheet model rather than multiple inconsistent calculations.

• Risk reporting and mitigation planning
  Example: you’re forecasting the cost exposure of continued schedule drift so leadership can decide whether to fund acceleration.

Colorado-specific practical focus

Colorado is a “real documents” environment: the strongest models connect cost outputs to time evidence and assumption documentation. You’ll be most effective when you align your model with:

• The schedule baseline (the “before” world)
• The time-impact evidence (what caused the change)
• The cost drivers (what costs were actually affected by time)

If your timeline evidence is fuzzy, the model can still help you structure assumptions—but expect reviewers to push back unless you can defend why the dates are credible.

Primary call to action

Start here: /tools/cost-of-delay

Step-by-step example

Below is a walkthrough you can mirror inside DocketMath. It’s written as an example; adjust numbers to match your project facts.

Scenario

A project has a planned completion milestone of June 30, 2025. Due to a delay event, the completion occurs July 30, 2025. Your team wants to model the cost of delay for 40 in-scope days (some costs begin after mobilization).

Step 1: Define the delay window precisely

Create a simple date mapping:

• Planned completion: 2025-06-30
• Actual completion: 2025-07-30
• Total elapsed impact: 30 days
• In-scope days for cost: 40 days (example assumption that some costs accrue in a broader window, like rework, standby, and downstream effects)

In DocketMath, use the calculator inputs so that the model is explicit:

• Delay duration (in days) that drives costs
• Start date / end date (or the equivalent “delay period” fields)

If your tool asks for a single delay duration, compute it from your in-scope rule and write that rule down for reviewers.

Step 2: Select your cost rate basis

Assume your project has a measurable daily cost driver. For example:

• Daily indirect cost rate (project overhead allocated to schedule): $1,250/day
• Additional time-sensitive costs (escorts/inspectors/yard costs): $450/day
• Total cost rate: $1,700/day

Your model should treat cost drivers consistently:

• Either sum them into a single per-day rate, or
• Enter separate line items if the calculator supports it

Step 3: Enter the number of cost-accruing days

If you use the in-scope window from above (40 days), then:

• Cost = 40 days × $1,700/day = $68,000

If your internal policy uses total elapsed days (30) instead, then:

• Cost = 30 days × $1,700/day = $51,000

This is where reviewers usually disagree—so pick a rule and document it.

Step 4: Add timing/discounting only if it meaningfully improves reviewability

If the calculator includes discount rate or present value timing, use it when your delay spans enough time that cash timing matters for your internal accounting.

For short delays, many teams skip discounting or keep it simple. The key defensibility move is: if you use discounting, state the reason and the rate source internally.

Step 5: Stress-test with “assumption sensitivity”

Before you export or share results, run two quick alternatives:

• Lower rate: $1,500/day for 40 days → $60,000
• Upper rate: $1,900/day for 40 days → $76,000

Then capture a short sensitivity statement in your internal notes:

• “Outputs shift by ±$8,000 depending on the overhead allocation rate.”

That single sentence can prevent late-stage model rejection.

Step 6: Make the output auditable

After running the calculator, ensure your model output includes (or you separately record):

• The delay period definition
• The daily cost rate components
• The in-scope day count
• Any discounting or compounding settings

If DocketMath gives you an export, keep the export linked to your scenario name (e.g., “2025 Q2 completion delay model”) and retain the date assumptions in the same file.

Common scenarios

The most frequent cost-of-delay modeling patterns generally fall into a few buckets. Below are examples of how to set inputs so your outputs match the underlying story.

1) Milestone slip with standby and supervision costs

Symptoms in the data

• Team was on site longer than planned
• Supervision, inspectors, and temporary services continued

Model approach

• Use a per-day standby/supervision cost rate
• Apply to the actual accrual period, not just total calendar delay

Checklist

• Standby costs begin on a documented date (mobilization/shift start)
• End date matches the time services actually stopped
• Rate comes from payroll distribution or a documented estimate

2) Downstream impacts (rework, integration, or extended commissioning)

Symptoms in the data

• Completion shift triggers delayed start for other workstreams
• Costs accrue beyond the “substantial completion” event

Model approach

• Include only those days when downstream activities were affected
• If downstream effect begins after a lag, reflect that lag

Warning: Pitfall: using total project elapsed days for every cost bucket. Reviewers will ask why downstream costs accrued during days when downstream work wasn’t actually restrained.

3) Acceleration vs. delay tradeoff

Symptoms in the data

• You can pay for acceleration to reduce completion delay

Model approach

• Compute:

  • Cost of delay for baseline schedule, and
  • Additional acceleration costs,
  • then compare net exposure

How outputs change

• As acceleration reduces delay days, cost-of-delay output declines linearly with days (unless you include discounting)

4) Multiple delay events with overlapping periods

Symptoms in the data

• Several events contribute to slippage
• Overlaps make it unclear what portion of delay belongs to each event

Model approach

• Decide an allocation rule up front:

  • “Exclusive day windows,” or
  • “Proportional allocation by impact factor,”
  • or “first-impact vs. incremental impact”

Checklist

• Overlap days are not double-counted
• Allocation rule is documented in the same file as the calculations
• Each event’s time window is mutually consistent

5) Rate uncertainty (overhead allocation, escalation, or resource cost assumptions)

Symptoms in the data

• Your daily cost rate is derived from budgets or estimates

Model approach

• Use a single base rate for the main output
• Provide sensitivity runs for “low/base/high”

Outcome

• Your main number becomes easier to defend, while the sensitivity supports transparency.

Tips for accuracy

Accuracy isn’t only about arithmetic—it’s also about assumption discipline and internal alignment. The tips below focus on practical habits that make your outputs easier to review.

Use a single, documented definition for “delay days”

Pick one of these approaches (and document which one you used):

• Total elapsed delay days (actual completion minus planned completion)
• In-scope cost accrual days (only days when the costs truly accrued)
• Milestone-to-milestone days (e.g., from notice date to completion)

Then keep that definition consistent across all cost components.

• The delay window rule is written in your model notes
• The same rule applies to every cost bucket unless you explicitly justify otherwise

Build the daily cost rate from visible components

Instead of dropping in a single number without provenance, break it down:

• Indirect overhead rate: $/day
• Specific time-sensitive services: $/day
• Equipment standby: $/day (if supported by usage logs)

If you must use a blended rate, state what it blends and where it came from.

Align start/end dates with evidence, not memory

Your hardest reviewer questions usually target dates. Improve defensibility by matching:

• start date to a written event (notice, directive, change order, documented impairment)
• end date to a measurable condition (restart date, completion date, acceptance,

Sources and references

Start with the primary authority for Colorado and confirm the effective date before relying on any output. If the rule has been amended, update the inputs and rerun the calculation.

• Primary authority reference

Related reading

• Cost of Delay Modeler Guide for Alabama
• Cost of Delay Modeler Guide for Arizona
• Cost of Delay Modeler Guide for Connecticut