Cost of Delay Modeler Guide for South Carolina

What this calculator does

DocketMath’s Cost of Delay Modeler helps you quantify the economic impact of time—by turning dates and assumptions into an estimated cost per delay period and a total delay cost.

This guide is tailored for South Carolina using a 3-year limitation horizon grounded in the jurisdiction data provided (jurisdiction code: US-SC):

• Statute of limitations period (SOL): 3 years
• Primary statute reference (for the provided jurisdiction data): GS 15-1 (3 years, exception V1)
  Source: https://www.ncleg.gov/EnactedLegislation/Statutes/HTML/BySection/Chapter_15/GS_15-1.html
• Additional sub-rule reference provided: **South Carolina Code of Laws §16-1-20 — 3 years (exception V3)

In practice, the model typically supports a decision workflow like this:

• You choose a start date (when delay begins).
• You choose an end date (when delay ends) or accept the calculator’s SOL horizon.
• You enter daily/period cost assumptions (labor, overhead, lost revenue, carrying cost, etc.).
• The tool outputs:

  • Duration of delay
  • Cost for each segment
  • Total modeled cost of delay

When to use it

Use DocketMath’s Cost of Delay Modeler when timing is a cost driver and you need a repeatable way to quantify it. For South Carolina, the calculator’s 3-year horizon is especially useful for planning and evaluation scenarios that reference that duration.

Common use cases include:

• Project controls and scheduling

  • You want a quantified impact of slip (e.g., procurement delay, permitting lead time, change order cycle time).
• **Dispute support (business framing)

  • You want to translate “months of delay” into dollars tied to measurable drivers (resources, financing, opportunity cost).
• Settlement range modeling

  • You need to estimate a reasonable economic magnitude based on assumptions rather than intuition.
• Backlog and throughput decisions

  • You’re comparing process improvements by “cost per day saved.”

Why the 3-year SOL horizon matters in US-SC modeling

When you model potential exposure or time-based damages, a 3-year window often becomes a practical boundary for analysis. That aligns with the jurisdiction data you provided:

• **3 years — GS 15-1 (exception V1)
• **3 years — South Carolina Code of Laws §16-1-20 (exception V3)

Step-by-step example

Below is a concrete walkthrough you can mirror in the tool. The objective is to show how inputs change outputs, especially around the 3-year (1095-day) horizon implied by the jurisdiction data.

Example: Modeling a 14-month delay, then extending to the 3-year window

Scenario

• A project team identifies delay starting 2025-01-15
• Delay ends 2026-03-15
• Your modeled “cost of delay” driver is $2,500 per day
• You also want to see what the modeled cost looks like if you apply the 3-year horizon in the tool

Step 1) Open the calculator

Go to the primary CTA:

• **DocketMath — Cost of Delay Modeler

Step 2) Set the delay window inputs

Enter:

• Delay start date: 2025-01-15
• Delay end date: 2026-03-15
  (Optionally, if the calculator provides a “use SOL horizon” toggle, you can switch to that view for a 3-year analysis.)

Step 3) Enter the cost rate

Enter:

• Daily cost rate: $2,500 / day

Step 4) Choose the model mode

Common options in these tools typically include:

• Actual period: compute based on start → end dates
• Horizon period: compute based on start date → start + 3 years

If the calculator offers a horizon mode, select:

• Use 3-year window (SOL horizon) based on the provided US-SC 3-year limitation period data.

Step 5) Read the outputs and interpret them

A) Actual period

• From 2025-01-15 to 2026-03-15 is ~425 days (exact day count depends on inclusive/exclusive counting rules; use the calculator’s computed duration).
• Estimated cost:

  • 425 days × $2,500/day = $1,062,500

B) 3-year horizon

• 3 years ≈ 1095 days
• Estimated cost:

  • 1095 days × $2,500/day = $2,737,500

So the “mode” changes the output by essentially replacing the measured duration with the modeled horizon.

Step 6) Stress-test with different cost rates

To make your analysis more decision-useful, rerun:

• Daily cost rate = $1,500/day
• Daily cost rate = $3,500/day

You’ll see the total cost scale linearly with the daily rate. That relationship is usually one of the fastest ways to validate whether assumptions are realistic.

Tip: If your daily rate is derived from overhead or staffing, consider separating it into two inputs in your notes (e.g., “labor per day” + “overhead carry per day”). Then you can adjust each driver independently.

Common scenarios

Different delay contexts need different ways of thinking about inputs. Here are practical patterns that map cleanly into a cost-of-delay model.

1) “Partial delay” then recovery

Pattern

• Delay lasts for a window, then operations recover (or mitigations kick in).

Modeling approach

• Use actual start and end dates for the delay period.
• If mitigation reduces daily cost, model it in segments (if the tool supports multiple periods) such as:

  • Segment 1 (high cost): $3,000/day
  • Segment 2 (recovery): $1,200/day

Output behavior

• Total cost becomes the sum of segment costs rather than a single “flat” multiplication.

2) “Ongoing delay” with a planning horizon

Pattern

• Delay hasn’t ended, so you need a planning estimate.

Modeling approach

• Use SOL horizon (3-year) mode to cap the modeled duration, using the provided US-SC 3-year horizon data.
• Set end date as “not known” and let the tool apply the horizon logic.

Output behavior

• You’ll get a single total for the horizon, which is useful for budgeting and risk screening.

3) “Multiple cost drivers” (resources vs. lost opportunity)

Pattern

• Different economics accrue differently:

  • Labor time
  • Equipment standby
  • Revenue or production opportunity loss

Modeling approach

• If the tool allows only one cost rate, create a blended daily rate:

  • Blended cost/day = labor/day + standby/day + opportunity/day
• Keep notes that explain the components of the blended rate so you can revise them quickly.

Output behavior

• Total cost reflects your blended rate; changing any component changes the whole number.

4) Comparing settlement or business options

Pattern

• You have multiple proposals (e.g., expedited delivery vs. standard schedule).

Modeling approach

• Run the calculator for each option:

  • Option A: shorter delay window
  • Option B: longer delay window
• Hold the same cost rate assumptions across scenarios so differences reflect time, not assumption drift.

Output behavior

• Output differences become a direct read on the economic value of time saved.

Tips for accuracy

A cost-of-delay model is only as credible as its time inputs and cost-rate assumptions. These steps increase accuracy and defensibility in business discussions.

1) Confirm how the calculator counts days

Day-count conventions differ (inclusive vs. exclusive). Use the calculator’s computed duration as your “source of truth” and record it.

Checklist:

2) Use a daily cost rate tied to a defensible unit

Avoid vague rates like “cost of delay is high.” Instead, anchor to units:

Good inputs:

• Labor cost per day (salary + burden)
• Rental/standby cost per day
• Financing cost per day (if you model it)
• Known production revenue per day (if you can justify it)

Checklist:

3) Segment costs when the economics change

If costs drop after mitigation, or rise during a ramp-up, use separate segments if the tool supports them.

Example segmentation:

• Segment 1: $2,800/day (delay active)
• Segment 2: $900/day (mitigation ongoing)

Checklist:

4) Treat the 3-year horizon as a modeling boundary, not an automatic ceiling for all damages

Your provided US-SC horizon data includes a 3-year limitation period:

• GS 15-1 (3 years, exception V1) and **South Carolina Code of Laws §16-1-20 (3 years, exception V3)

Use this as a practical window for your analysis—not as an instruction to automatically cap

Related reading

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