Change order cycle time

What it is

When scope changes, the contractor prices the change and submits a change order request to the owner. The owner reviews, negotiates, and approves or rejects it. Cycle time is how long that takes.

Approved changes are measured by cycle time. Changes still pending are measured by open age: days since submission.

Why operators track it

• Cash. Work on an unapproved change often cannot be billed, so long cycle times show up as underbilling.
• Margin risk. Costs post to the job before the revenue is approved, which can make the job look like it is fading.
• Owner relationships. Cycle time by owner or architect shows who is slow to approve.
• Forecast quality. Pending changes are a common source of disagreement between the PM's view and the WIP.

How it is calculated

Cycle time = approved date − submitted date (in days)

• Report the median across approved change orders in a period. A few slow ones can pull an average far up.
• Report open age for pending changes separately: as-of date − submitted date.
• Pair both with the dollar value pending.

Worked example

Job 2417 has four change orders. Three were approved in 28, 50, and 14 days, a median of 28 days. The fourth, worth $42,000, has been pending 72 days.

How to read it

• Median and open age together. A low median can hide one large change order pending for months.
• Weight by dollars. A slow $200,000 change matters more than a slow $2,000 one.
• Split by owner and by stage. Time with the contractor (pricing) and time with the owner (review) have different fixes.
• Typical cycle times depend on contract type and owner, so we do not publish a benchmark.

Definitional choices and common pitfalls

• Start date. Submitted to owner, or when the change was first identified. Starting at identification also captures the contractor's own pricing time.
• End date. Approved by the owner, or fully executed and signed. Say which.
• Rejected and revised. Decide whether a revised resubmission restarts the clock.
• Potential change orders. Many systems track a potential change order before the formal request. Choose which stage starts the measure.
• Median or average. Median is less sensitive to outliers. If you show average, show the count too.

How different roles use it

Questions it answers

• How long do owners take to approve changes?
• How much approved work is waiting on paperwork?
• Which owners or architects are slowest?
• Which pending changes are oldest?

How to present it in a report

• KPIs for median cycle time, number and value pending, and oldest open age.
• A list of pending change orders sorted by age with dollar value.
• Median cycle time by owner or by PM.
• A monthly trend of median cycle time.

Data you need

Fields

What the raw data looks like

Example data A few rows as they might come out of the source system.

Where this data usually lives

• Project management often holds change orders, commitments, and project documents. For example: Procore.
• Construction ERP and accounting holds job cost, budgets, billing, AP, and AR. For example: Sage 300 Construction and Real Estate, Viewpoint Vista (Trimble), and Foundation. Some smaller contractors use general accounting software such as QuickBooks with jobs set up as projects.
• Spreadsheets often hold forecasts, logs, or the report itself.

The same field can live in more than one system. Agree with the customer which one is the source of truth.

Common data gaps and traps

• Dates not captured. Some systems store only the current status, not when it changed. Status history or audit logs may be needed.
• Changes outside the system. Field changes may live in email until the PM enters them.
• Two systems. The PM tool holds the request; the ERP holds the approved amount. Join on CO number.
• Approved date is the entry date. If the ERP date is when accounting keyed it in, cycle time is overstated.

Related metrics

• WIP over/under billing: pending changes often show as underbilling.
• Cash flow by job: where the delay lands.
• Profit fade and gain: cost posted before revenue is approved looks like fade.

FAQ

What is a good change order cycle time?

It depends on the owner and contract. Track your own trend and compare owners.

Should rejected change orders count?

Show them separately. Including them in the median mixes two different outcomes.

Why median instead of average?

A few very slow change orders can make the average misleading.

cycle_days    = approved_at - submitted_at              -- approved only
open_age      = :as_of - submitted_at                    -- pending only
median_cycle  = PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY cycle_days)
pending_value = SUM(revenue_amount) WHERE status = 'pending'

SELECT job_id,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY approved_at - submitted_at)
    FILTER (WHERE status = 'approved') AS median_cycle_days,
  COUNT(*) FILTER (WHERE status = 'pending') AS pending_count,
  SUM(revenue_amount) FILTER (WHERE status = 'pending') AS pending_value,
  MAX(:as_of - submitted_at) FILTER (WHERE status = 'pending') AS oldest_open_days
FROM change_orders GROUP BY job_id;

metric: construction.change_order_cycle_time
grain: one row per change order
inputs:
  - status
  - submitted_at
  - approved_at
  - revenue_amount
  - owner_id
logic:
  - cycle_days = approved_at - submitted_at for approved
  - open_age = as_of - submitted_at for pending
  - median by job, owner, PM, month approved
edge_cases:
  - approved_at before submitted_at: flag as data error
  - resubmitted CO: keep original submitted_at unless policy says restart
  - void or rejected: exclude from median, count separately

Version 1.0 · Last reviewed 2026-10-20 · Machine-readable definition