When an owner change, design delay or other excusable event hits, justify the time with a prospective TIA per AACE RP 52R-06: build a fragnet for the event, insert it into the update in effect when it occurred, and let the recalculated network show the effect on completion. If the critical path moves, you have a supported request in CDs, subject to the contract, responsibility, concurrency and notice. If it only consumes total float, you have a documented impact but, under most contracts, no extension yet. Expect the owner's scheduling consultant to review every piece.
Why this matters more for the GC than anyone
You hold the completion date, and it usually carries liquidated damages. Every unrecovered owner delay comes out of your float first and your pocket second. Skip contemporaneous TIAs and you're self-funding the owner's changes, then facing the LD conversation with no record. TIA discipline isn't claims posturing. It's how the time side of the contract gets administered, change by change.
What the analysis stands on
- A credible network. A TIA is only as good as the schedule it runs in. Open ends, constraint-driven dates and a critical path that ignores slips let the owner's reviewer dismiss your result unread. Run the DCMA 14-point check on your own schedule first and fix the network.
- The right base schedule. The update with a data date just before the event, statused honestly. Measuring from the baseline or an after-the-fact schedule misstates the impact and reads as manipulation.
- A real fragnet. The activities and logic of the change itself (revised drawings, resubmittals, procurement, added or resequenced work), tied in where it connects. One "owner delay" bar at your requested duration is an argument, not an analysis. Source every duration from submittal logs, vendor quotes or production rates.
- Honest concurrency. Address your own performance issues that ran alongside the owner's delay. Under many contracts, concurrent contractor delay on the controlling path turns a compensable extension into excusable time only, and an analysis that hides its own side loses credibility everywhere. Deal with it first, on the record, and you control that conversation.
Entitlement in plain terms
Contracts differ, so read yours, but there are usually three buckets:
- Excusable and compensable. Owner-caused: changes, late design, denied access, owner-furnished equipment slipping. Time plus extended cost, when the TIA shows critical path impact.
- Excusable, not compensable. Neither party's fault, unusually severe weather being the classic. Time, no money, and the weather has to beat what the contract assumes.
- Non-excusable. Yours. No time, and the reviewer will test every day you put elsewhere. The contemporaneous record keeps your events out of it.
Float sits under all of it. Most modern contracts say total float belongs to the project, so an event earns an extension only when it drives the path critical. Log float consumption in the update narratives every month, because the change that finally moves completion is proven by the record of float eaten before it. The compounding we covered for subs in the change order release article runs against you from the owner's side. Same cure: evaluate time on every change, not just the big ones.
Field notes from the review side of the table
- Split progress from impact. Completion moves for two reasons: your own production and the events you want time for. Status the update to just before the event and save it, then insert the fragnet and run again. The first run sets the pre-event forecast, the second measures the fragnet. Your progress and any concurrent delay still get their own review, done contemporaneously.
- Chart total float on the driving path, every update. Not the project average. One line with CO markers, kept in the narrative. When it crosses zero, the trajectory is the entitlement argument, and the owner is arguing against their own change log.
- Mirror your sub and prime paperwork. Time you grant a sub should line up with what you claim upstream for the same event. Give the sub 10 CDs for an owner change and ask the owner for 4, and be ready to explain the difference with milestones, logic and float.
- Treat a directed recovery schedule as a constructive acceleration flag. If the owner denies a supported extension and directs you to hold the date, that combination has a name and money attached. Log the denial and directive, price the acceleration, and involve your attorney now, not at closeout.
- Keep a delay log keyed to activity IDs. One line per event: date, activity IDs affected, notice reference, fragnet number, TF consumed, status. Minutes a week. It feeds every TIA package, and if the job goes forensic it becomes the spine of the expert's chronology instead of a reconstruction bill.
The process that makes it routine
- Notice inside the contract window. Your prime contract's notice clause has teeth too, same as your subs'. The notice letter discipline applies up the chain.
- Fragnet and TIA while the event is live. Prospective analysis, submitted with or shortly after the change proposal, so the time request travels with the cost proposal.
- The extension into the contract. Granted time goes into a revised schedule with the fragnet incorporated, keeping the record and the network in sync.
- Updates that keep the story. Monthly narratives on progress, float consumption and open impacts. If a dispute comes, forensic methods under AACE RP 29R-03 build from that record, and the GC with clean updates starts ahead.
This is the rhythm we run as an outside schedule department for small and mid GCs, from the baseline through the monthly cycle to the fragnets and TIAs when changes hit. The owner has a scheduling consultant reviewing your submissions. The GCs who fare best have one producing them.
Send the change and your current update. We'll run the fragnet, tell you what the network shows, and package the request for the reviewer with the assumptions, math and records.