Electrical contractor · Dallas–Fort Worth, TX
Halving change order approval time on fast-track data center work
A DFW electrical contractor carried $2.3M of unapproved change orders at any moment. The fix was what left the building, not what happened after.
Representative engagement. This describes work of a type we build, with figures modeled rather than measured at a named client. We would rather tell you that than invent a customer you cannot phone.
Outcome Measured after go-live
- 44 → 19 days
- Change order request to approval
- Median across 14 active projects, measured 120 days after go-live.
- 58%
- Reduction in aged unapproved value
- Submitted change order value outstanding more than 60 days.
- 2.5 FTE
- Administrative time returned
- Redeployed to project management rather than removed.
The situation
An electrical contractor running fast-track data center and commercial work across DFW. Fourteen active projects, roughly 190 change order requests a month, and a business growing faster than its back office.
Speed is the defining feature of data center construction. Scope changes constantly and it changes fast, which means change orders are not an exception in this business. They are a significant and permanent share of revenue.
The company was profitable and busy. The problem was that roughly $2.3M of submitted-but-unapproved change order value was outstanding at any given moment, and the number was growing with revenue.
What the audit week found
We expected to find a tracking problem. What we found was a submission quality problem wearing a tracking costume.
Change order requests were going out incomplete. Not wrong, incomplete. A missing daily report reference, no photograph of the condition that caused the change, a labor breakdown that did not tie to the schedule of values. Each omission generated a GC question, each question cost a week, and roughly 40% of requests went through at least two revision cycles before anyone discussed the money.
Nobody owned the request after it was sent. Project managers submitted and moved on. Follow-up happened when a controller noticed an ageing number, which was usually well past the point where the superintendent remembered the event.
Pay applications and change orders were tracked in different places. Approved change orders had to be manually reconciled into the schedule of values each month, which is where two of the three billing errors we found had originated.
The prototype we built in the audit week checked 60 recent requests for completeness against each GC’s own requirements. Forty-one were missing at least one required element at the moment they were submitted.
What we built
A completeness gate. Before a change order request can be submitted, the system checks it against that GC’s documented requirements: daily report reference, photographs, labor and material breakdown, schedule impact. Missing elements are listed. The project manager can override with a reason, and the overrides are logged, because sometimes speed genuinely matters more.
Packet assembly. The supporting documentation is pulled together automatically from the daily reports and photograph library rather than hunted for. This is the part project managers noticed.
An ownership and ageing board. Every outstanding request, whose desk it is on, how long it has been there, and what the next action is. Visible to leadership without asking anyone.
Schedule of values reconciliation. Approved change orders flow into the SOV so the monthly pay application reflects them without manual entry.
What happened
Median approval time fell from 44 days to 19. Almost all of the improvement came from eliminating revision cycles rather than from chasing GCs harder, which was not the intervention anyone expected to work.
Aged unapproved value fell 58%. The remaining balance is concentrated in two projects with genuinely contentious scope, which is a commercial problem rather than a paperwork one.
The administrative time saved was redeployed rather than cut. That was the client’s decision and, watching it play out, the right one.
What went wrong
Procore’s API gave us less than the sales conversation implied. Some of what we needed was available only through a higher tier the client was not on. Reworking around that cost about a week and a half and changed what the integration could do.
Project managers experienced the completeness gate as an accusation. The first version blocked submission outright, which produced a genuinely angry meeting in week four. Adding the logged override fixed both the workflow and the politics. If we built this again, the override would be there on day one.
One GC changed its documentation requirements mid-project and nobody told anyone. The system dutifully checked against the old rules for six weeks. There is now a quarterly review of the requirement sets, which is a process fix rather than a software one.
What it cost
| Workflow Audit | $7,500, one week |
| Build | $79,000, six weeks, fixed price |
| Care and feeding | $6,500 a month |
| Cloud and model usage | Paid directly by the client, roughly $420 a month |
What it was built with
- Web app, no field component required
- Postgres on the client’s AWS account
- Claude for document assembly and completeness checking
- Procore and Foundation integrations