Cost of Delay Modeler Guide for Oregon

What this calculator does

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

DocketMath’s Cost of Delay Modeler helps you estimate the financial impact of time on a project or dispute timeline in Oregon (US-OR). In practical terms, it turns schedule and business assumptions into an output that looks like:

• Total cost of delay over a defined period
• Cost per day (or month) based on your inputs
• Breakdown by major cost drivers (e.g., lost revenue, additional staffing, extended overhead)

This is not a damages opinion and it doesn’t replace legal analysis. It’s a modeling aid: you can use it to test assumptions, compare scenarios, and create a timeline-driven cost narrative for internal planning, negotiations, or case preparation.

Core idea (plain language)

You choose:

• When the “delay” starts and ends (or the duration)
• How much “economic harm” occurs per unit of time
• Optional: multiple harm categories, each with its own timing and rate

The calculator converts those choices into a numeric estimate—useful for prioritizing mitigation, negotiating scope, or stress-testing a schedule.

When to use it

Use the Cost of Delay Modeler in Oregon when you want a time-based financial estimate that you can revise quickly. Common triggers include:

1) Contract and project schedule changes

If milestones slip, deliveries move, or performance is extended, a cost-of-delay model can help quantify the business impact of that extension. It’s especially useful when costs are naturally expressed as ongoing burdens:

• extended overhead
• continued labor/carry costs
• financing costs for work-in-progress
• delayed revenue recognition tied to commissioning or acceptance

2) Multiple competing schedule narratives

If you’re comparing versions of events (e.g., “earlier baseline” vs. “later revised schedule”), the model can produce side-by-side numbers. This makes it easier to focus discussions on:

• which period actually counts as “delay”
• which costs really accrue during that time

3) Settlement posture and internal decision-making

Even when settlement discussions are outside formal legal proceedings, decision-makers often need a defensible range rather than a single guess. Modeling helps you build:

• a conservative case (lower rate, shorter impact period)
• an aggressive case (higher rate, longer impact period)
• a sensitivity view (how much the result changes if your rate changes by ±10% or ±25%)

4) Dispute support work that benefits from structured assumptions

A well-structured timeline model can help you organize:

• key dates
• durations
• cost categories
• the logic connecting them

Step-by-step example

Below is a concrete example using DocketMath’s cost-of-delay flow. Adjust the numbers to fit your situation.

Scenario: Construction project with delayed revenue and extended overhead

Assume an Oregon project where:

• The owner expected substantial completion by June 1
• Actual substantial completion occurred on July 16
• You’re estimating business impact during that delay window

Step 1: Define the delay window

• Delay start: June 1
• Delay end: July 16
• Duration: 45 days (June 1 → July 16, counting the days used by your model’s convention)

In DocketMath, you’ll typically enter either:

• Start date + end date, or
• Total days directly (depending on the calculator’s input design)

Step 2: Choose cost categories

Let’s model two categories:

1. Lost net revenue

   • Expected daily net revenue: $2,500/day
   • Accrues during the delay window: full 45 days

2. Extended overhead

   • Additional overhead: $1,200/day
   • Accrues during delay: full 45 days
   • (If some overhead begins later, you’d model a different accrual period.)

Step 3: Enter rates and accrual timing

Enter in DocketMath:

• Category A: Lost net revenue

  • Rate: $2,500/day
  • Duration: 45 days

• Category B: Extended overhead

  • Rate: $1,200/day
  • Duration: 45 days

Step 4: Review the outputs

The calculator computes:

Step 5: Run a sensitivity check (recommended)

Now test how sensitive the estimate is to the revenue assumption:

• If daily net revenue is 10% lower: $2,250/day

  • Lost revenue becomes $2,250 × 45 = $101,250
  • Total becomes $101,250 + $54,000 = $155,250

• If daily net revenue is 10% higher: $2,750/day

  • Lost revenue becomes $2,750 × 45 = $123,750
  • Total becomes $123,750 + $54,000 = $177,750

A sensitivity range like this helps you avoid presenting a single number without context.

Common scenarios

The Cost of Delay Modeler is especially useful when delay-related harm shows up as recurring costs or delayed cash flows. Here are scenarios you can map into the calculator.

A) Lost revenue tied to opening/acceptance

If your revenue depends on a milestone (e.g., opening, acceptance, commissioning), model:

• daily or monthly net revenue
• accrual tied to the time you lacked the ability to generate revenue

Modeling tip: Net revenue is often clearer than gross revenue for delay models because it reflects margin rather than turning a business failure into a revenue claim.

B) Extended field supervision and staffing

When schedule slip keeps crews and supervision on-site longer:

• staffing costs can be entered as a daily or weekly overhead rate
• if staffing doesn’t start immediately, model staggered start dates

Example logic:

• Days 1–10: minimal incremental staffing
• Days 11–45: additional labor and supervision

C) Extended equipment or facility standby

Equipment rentals, site security, or utilities sometimes correlate strongly with time:

• daily equipment standby cost
• daily site overhead
• adjust for when the standby actually begins

D) Carrying costs and financing impacts

If you track additional interest or financing costs for the delay period:

• use a time-based financing rate (e.g., monthly carrying cost)
• apply it to the period the financing impact actually accrues

Caution: Financing models can become complicated quickly. Keep the inputs tight and explain the logic in your documentation.

E) Partial mitigation that reduces harm

If part of the delay was mitigated (e.g., you redeployed a crew or staged work):

• reduce the affected daily cost during the mitigated period
• represent mitigation as a second accrual window with a lower rate

Checklist idea:

Tips for accuracy

Small input choices can materially change the result. Use these techniques to keep your DocketMath model grounded.

1) Be explicit about the time unit

Pick one consistent unit for rates and durations:

• daily rates with day counts
• monthly rates with month counts

Then keep the same approach across categories. Mixing units can create avoidable arithmetic errors.

2) Split categories by accrual behavior

If one cost starts immediately while another starts later, model them separately. For example:

• Lost revenue starts at substantial completion
• Overhead may begin the moment the delay becomes apparent

3) Use “incremental” costs when possible

A good cost-of-delay model focuses on incremental costs caused by the delay rather than total project cost. Practical ways to operationalize this:

4) Document your rate sources (even internally)

DocketMath helps you build a transparent model; your credibility improves if you can point to how each rate was derived:

• timesheets
• invoices
• historical operational data
• budget documents
• forecasting models

No need to attach everything in the tool output—just keep the linkage so you can explain it.

5) Run at least two scenarios: conservative and optimistic

Create two versions:

• Conservative: lower daily impact rate or shorter affected period
• Optimistic: higher daily impact rate or longer affected period (only if justified)

Then present a range rather than a single figure.

6) Validate against a “sanity check”

After you compute the total, ask:

• Does the total roughly match what you’d expect for 30–60 days of delay?
• Are daily rates too high compared to your real operational economics?
• Did you accidentally double-count a cost (e.g., overhead included in both categories)?

A quick sanity check can prevent confident errors.

7) Capture Oregon-specific context through your inputs (not assumptions)

DocketMath doesn’t require special “Oregon rules”

Sources and references

Start with the primary authority for Oregon 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 California