Fragnets
Last reviewed 9 September 20262,171 words10 min read
Building a change or delay as a mini-network
🟩 In one line: A fragnet is a small network of activities representing one change or one delay event, built in its own WBS node, linked into the accepted update at exactly one entry point and out at the real successors — so the impact it produces is measurable, auditable and defensible. One event, one fragnet, one WBS node, one before-and-after comparison.
👤 Who this is for: Mid-level planners doing their first time impact analysis; juniors inserting a variation; seniors reviewing whether a contractor's fragnet is honest. You should know time-impact-analysis and relationship-types-explained.
First, let's be honest about why this page exists
The fragnet is where most delay claims are won or lost, and it's usually built badly: three activities with round-number durations, linked to the completion milestone, producing exactly the number of days the contractor wanted. A reviewer spots it in ten minutes.
A good fragnet does the opposite — it models what actually happened or what the change actually requires, links to real successors, and produces whatever number it produces. If the number surprises you, that's a sign it's honest.
🟨 The standard — what "good" looks like
| Source | What it says (paraphrased) |
|---|---|
| AACE RP 52R-06, Time Impact Analysis — As Applied in Construction | Defines the fragnet method: insert a fragnet representing the delay into the schedule current at the time, recalculate, measure the difference in completion |
| AACE RP 29R-03, Method Implementation Protocol 3.7 (modelled/additive/single base) | The fragnet approach and its variants; requires the base schedule and the fragnet both to be validated |
| SCL Protocol 2nd ed., Core Principle 11 and Guidance Part B on time impact analysis | Prospective analysis inserts a sub-network of the delay event into the programme updated to just before the event |
| FIDIC 1999 Cl 20.1 / 2017 Cl 20.2 (check the edition in your contract) | Particulars supporting the claim — the fragnet plus the before/after schedules are the particulars |
| NEC3 / NEC4 Cl 62.2, 63.5 | Quotation for a compensation event includes revised programme showing the effect — effectively a fragnet impact |
🟢 Rule to remember: the base is the last accepted update before the event, never the baseline. Insert, recalculate, compare, archive. One event at a time.
How it actually works
Two kinds of fragnet.
| Type | What it models | Typical activities |
|---|---|---|
| Change fragnet (variation) | New work instructed | Design/submittal → approval → procurement → fabrication → delivery → installation → test |
| Delay fragnet (event) | Disruption to existing work | Suspension activity, waiting period, remobilisation, re-work, or an extended duration on an existing activity |
The build sequence.
| Step | Action | Detail |
|---|---|---|
| 1 | Fix the base | Last accepted update with data date immediately before the event. Copy it; never work in the live file |
| 2 | Create the WBS node | e.g. VO-014 Additional Chiller Capacity or DE-007 Late IFC Structural Zone B. All fragnet activities live here |
| 3 | Code the activities | Activity code "Event ID" = VO-014; ID prefix VO014-xxxx. Filterable forever |
| 4 | Build the activities | Real durations from real basis — approval periods from the contract, lead times from quotations, installation from crew/manhour calculation |
| 5 | Link IN | One entry point where possible — the instruction date, or the activity that was interrupted |
| 6 | Link OUT | To the real successors, not the completion milestone |
| 7 | Calendars | Assign the correct calendars — approvals on a 5-day office calendar, site work on the 6-day site calendar, shipping on 7-day |
| 8 | Constraints | None, except a Start On or After on the instruction date if that's a fact |
| 9 | F9 | Retained Logic. Compare completion before and after |
| 10 | Archive | Before XER, after XER, Schedule Comparison report, fragnet description note |
A typical variation fragnet — activities and duration sources:
| Activity | Duration source | Calendar |
|---|---|---|
| Receive instruction (milestone) | Fact — instruction date | — |
| Prepare technical submittal | Crew/manhour or standard 10–15 d | 5-day office |
| Consultant review & approval | Contract review period (e.g. 14 d) | 5-day office |
| Place order / PO | Standard 5–10 d | 5-day office |
| Fabrication / manufacture | Supplier quotation — quote it | 5 or 6-day supplier |
| Shipping & customs | Quotation + clearance allowance | 7-day |
| Delivery to site (milestone) | Calculated | — |
| Installation | Qty × rate ÷ crew | 6-day site |
| Testing & commissioning | Method statement | 6-day site |
A typical delay fragnet. For a suspension or waiting period, the cleanest model is often not new activities but a single activity representing the wait, inserted between the interrupted activity's predecessor and the interrupted activity:
| Activity | Duration | Note |
|---|---|---|
| Access to Zone B withheld (start milestone) | — | Date of the event |
| Await access to Zone B | Actual or forecast waiting period | Site calendar |
| Access granted (finish milestone) | — | — |
| Remobilise crew to Zone B | 2–5 d | Real, and often forgotten |
Then link Access granted → the interrupted activity, and let the network do the rest.
Where the fragnet must NOT link.
| Wrong link | Why |
|---|---|
| Fragnet → Completion milestone directly | Manufactures an impact regardless of the real path; the first thing a reviewer deletes |
| Fragnet → a summary or LOE activity | No real successor; impact is fictional |
| Fragnet with an FOoB constraint | Constrains the answer you're trying to calculate |
| Fragnet linked out at several points "to be safe" | Redundancy; makes the driver unreadable |
P6 mechanics. Use a Reflection (Project > Reflection, or right-click project > Create Reflection) for each event, so the base stays untouched. Build the fragnet in the reflection, F9, then Tools > Schedule Comparison (Claim Digger) against the base. Export both XERs. Name everything by event ID.
For multiple events in one window, build them cumulatively in event date order — insert event 1, record impact, then insert event 2 into the post-event-1 schedule, and so on. Never insert all events at once and divide the total.
📜 Entitlement points
| Point | Position |
|---|---|
| Whose fragnet counts? | The one built on the accepted update, with documented durations. A fragnet on the baseline is usually rejected |
| Must the fragnet be prospective? | SCL prefers prospective (TIA) where notice was timely; AACE 29R-03 recognises both modelled and observational approaches. Say which you're using |
| What if the work is already built? | Then a retrospective method may fit better — the fragnet should reflect what actually happened, with actual dates (windows-analysis) |
| Does the fragnet prove entitlement? | No. It proves impact. Entitlement comes from the clause, the notice and the cause |
🟥 Where people go wrong
- Building the fragnet on the baseline. Eighteen months of progress and re-sequencing are ignored, and the answer is meaningless. The base is the last accepted update before the event. This is the single most common rejection reason.
- Linking the fragnet straight to Completion. It produces a number equal to the fragnet's duration, every time, which is exactly why reviewers strip it. Link to the activities the new work actually feeds.
- Round numbers. Approval 15 d, fabrication 60 d, installation 20 d. No basis. Quote the contract review period, attach the supplier's lead-time letter, calculate installation from quantities. A fragnet with sources attached survives; one with round numbers doesn't.
- Inserting several events at once. Concurrency and shared paths make the total meaningless and you can't allocate responsibility. One event, one insertion, in date order.
- Forgetting remobilisation and re-work. A 30-day suspension is rarely a 30-day impact — there's demobilisation, storage, remobilisation, and often re-inspection. Model it; it's real and it's usually recoverable.
- Wrong calendars inside the fragnet. Consultant approval on a 6-day site calendar shortens a 14-day review to 12 working days on paper. Approvals are 5-day; shipping is 7-day.
- Not archiving the before file. Six months later the base schedule has been superseded, the comparison can't be reproduced, and the analysis is unverifiable. Export both XERs at the time and store them by event ID.
⚖️ When you're challenged
"Your fragnet shows 28 days but the variation only took 20 days to build." "The 20 days is installation. The 28 is the driving path through the fragnet — submittal, 14-day review under Clause 3.2, procurement and delivery, then installation partly in parallel with existing work. The installation itself isn't the whole delay."
"You've built this on the baseline." "No — the base is Update 14, data date 30 September, which is the last accepted update before the instruction on 12 October. Both XERs are attached and the Schedule Comparison shows only the fragnet as the difference."
"Why does this fragnet push completion when there was 18 days of float on that path?" "It doesn't push it by the full fragnet duration — it absorbs the 18 days of float first. The net impact to completion is 11 days, which is what the comparison shows. The float was consumed by the event, and under our contract float is the project's until it's gone."
"You've added remobilisation. That's padding." "It's 3 days for the blockwork crew to come back off the other zone and re-set. The daily allocation sheets show them redeployed on 14 March and back on 19 March. It's a fact, not an allowance."
📄 Related pages
- Time Impact Analysis — the method the fragnet serves
- Choosing a Delay Method — when a fragnet is the right tool
- P6 Reflections and What-If — building it without touching the live file
- P6 Schedule Comparison — proving the fragnet is the only difference
- Change Control in a Live Schedule — what happens after the fragnet is agreed
- Notice Requirements and Records — the clock that runs alongside
- Windows analysis — the retrospective alternative
- Concurrent Delay — what happens when two fragnets overlap
✏️ Worked example
A car park and podium in Riyadh. Instruction on 12-Oct-25 to add a fire-rated shutter system not in the original scope. Base: Update 14, data date 30-Sep-25, forecast completion 22-Jun-26.
Fragnet (WBS node VO-014):
| ID | Activity | Duration | Calendar | Basis |
|---|---|---|---|---|
| VO014-0010 | Instruction received (milestone) | 0 | — | 12-Oct-25 |
| VO014-0020 | Prepare shop drawings & submittal | 12 d | 5-day office | Designer's quotation |
| VO014-0030 | Consultant review | 14 d | 5-day office | Contract Cl 3.2 review period |
| VO014-0040 | Place order | 5 d | 5-day office | Standard |
| VO014-0050 | Fabrication | 55 d | 5-day supplier | Supplier letter dated 20-Oct-25 |
| VO014-0060 | Shipping & clearance | 21 d | 7-day | Freight quote + 7 d clearance |
| VO014-0070 | Delivery to site (milestone) | 0 | — | Calculated |
| VO014-0080 | Install shutters (4 no.) | 10 d | 6-day site | 4 × 2.5 d/unit, 1 crew |
| VO014-0090 | Test & certify with fire alarm | 4 d | 6-day site | Method statement |
Links: IN — VO014-0010 SOoA 12-Oct-25. OUT — VO014-0080 FS CIV-2210 Podium blockwork Zone C (shutter openings must be framed before blockwork closes), and VO014-0090 FS CM-0410 Fire system integrated test.
Result:
| Completion | Total float on podium path | |
|---|---|---|
| Base (Update 14) | 22-Jun-26 | +16 d |
| With fragnet, F9 Retained Logic | 09-Jul-26 | -1 d |
| Net impact | 17 calendar days / 15 working days | Float fully absorbed |
The fragnet's own driving path is 12 + 14 + 5 + 55 + 21 + 10 + 4 = 121 days end to end, but the impact to completion is 15 working days, because 16 days of float on the podium path absorbed the rest and the shutter install ran partly in parallel with other Zone C work. The claim was for 15 days, not 121 — and that's why it was accepted.
📖 References
- AACE RP 52R-06, Time Impact Analysis — As Applied in Construction
- AACE RP 29R-03, Forensic Schedule Analysis — MIP 3.7 and related protocols
- SCL Delay and Disruption Protocol, 2nd ed. (2017), Core Principle 11; Part B Guidance
- FIDIC 1999 Cl 20.1; FIDIC 2017 Cl 20.2 (check the edition in your contract)
- NEC3 / NEC4 ECC Cl 62.2, 63.5 (check the edition in your contract)
- Oracle, P6 Professional User Guide — Reflections; Schedule Comparison
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about fragnets. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience