Fragnet (Fragmentary Network)

Definition

A fragnet, short for fragmentary network, is a small, self-contained set of activities and logic links that plugs into a larger CPM schedule to represent a specific event — most often a delay, a change order, an acceleration, or a proposed recovery plan. The fragnet is developed separately, reviewed for internal correctness, and then integrated into the baseline (or into a copy of the current update) to measure its schedule impact. Fragnets are the working currency of forensic scheduling and Time Impact Analysis.

Origins

The term entered mainstream scheduling practice through the U.S. Army Corps of Engineers modification impact evaluation guidance in the 1970s and was later codified in AACE International Recommended Practice 52R-06 and the Society of Construction Law Delay and Disruption Protocol. Every serious delay-claim methodology in use today — Time Impact Analysis, Windows Analysis, and Collapsed As-Built — relies on properly built fragnets.

Anatomy of a Fragnet

• Inserted activities — new work required by the change or delay event.
• Logic ties into the host schedule — clear predecessor and successor links to existing activities.
• Duration justification — every duration has a source (crew and productivity, subcontractor confirmation, supplier lead time, or historical benchmark).
• Calendar assignment — the fragnet must respect the calendars in force on the affected activities (weather, shutdowns, holidays).
• Reference documents — RFIs, change directives, correspondence, and photographs that support the inserted logic.

Real-World Construction Example

On a 22-storey commercial tower, the owner issued a directive to change the curtain-wall system from unitised to stick-built on floors 8 through 22, four months into construction. The scheduler built a 47-activity fragnet covering re-engineering, sample fabrication, procurement of new extrusions (a 14-week lead item), mock-up, and installation crew re-training. The fragnet was inserted into a copy of the current update, and the critical path shifted by 63 working days. The contractor issued a change order supported by the fragnet; the owner and their independent scheduler negotiated the delay to 58 days after adjusting two of the durations. The claim closed in eight weeks — fast, by industry standards, because the fragnet made the argument transparent.

Real-World IT / Agile Example

Fragnets are less common in pure agile work but appear routinely on delivery programmes with hard dependencies — for example, migrations to a new payments processor. A telco delivery programme discovered mid-flight that a regulatory change added a new compliance certification, needing a specialist third-party lab. The programme scheduler modelled a 21-activity fragnet — vendor selection, contracting, sample submission, remediation cycles, certification, and rollout — and inserted it into the master delivery plan. The fragnet showed a 47-day slip to the mandatory go-live. Rather than argue in prose, the team walked stakeholders through the fragnet at the steering committee, secured the descoping decisions needed, and preserved the regulatory date.

Best Practices

• Build the fragnet in isolation first, then integrate. Building directly into the master is where errors originate.
• Every duration and every logic tie must be traceable to a document.
• Assign the correct calendar; a fragnet built on the wrong calendar produces the wrong answer.
• Preserve a clean baseline copy for the "before" comparison — you will need it in any dispute.
• Keep the fragnet contained to the affected work; global logic rewrites disguised as fragnets are a red flag in claims review.

Common Mistakes

• Inserting a fragnet without corresponding removal or suspension of superseded activities.
• Overreaching — including work that was already delayed for other reasons.
• Missing logic ties on both sides; a fragnet with predecessors but no successors floats freely and doesn't drive dates.
• Using the current update instead of a defensible reference schedule.
• Failing to document the sources; the fragnet is only as strong as its evidence.

Expert Tips

• Draw it on paper first. A fragnet with more than 20 activities is easier to sketch than to model. Sketch, review, then build.
• Keep two versions: the pure fragnet (unimpacted) and the integrated schedule (impacted). Reviewers will ask for both.
• Colour-code inserted activities in the integrated version. Reviewers appreciate visual clarity.
• Peer-review before submission. Have a scheduler with no stake in the outcome walk the logic. Nine times out of ten they find at least one flaw.
• Never insert a fragnet into a schedule that has been retroactively "cleaned up". The claim will be denied on integrity grounds alone.

Practical Lessons Learned

• Fragnets settle disputes faster than narrative arguments — a well-built fragnet turns a claim negotiation into an engineering conversation.
• The claims that fail are almost always the ones with sloppy logic or missing documentation, not the ones with weak underlying merit.
• Owners' schedulers respect a fragnet that shows its work. Hiding assumptions guarantees pushback.

Key Takeaways

• A fragnet is a small, focused subnetwork used to model a delay, change, or recovery.
• Every duration and link must be evidence-backed and calendar-correct.
• Build in isolation, then integrate into a defensible reference schedule.
• Fragnets are central to Time Impact Analysis, Windows Analysis, and modern delay claims.
• Transparent, well-documented fragnets close claims faster and cheaper than prose arguments.

Related Encyclopedia Entries

• Time Impact Analysis
• Critical Path Method
• Change Order Management
• Extension of Time
• As-Built Schedule

Related Research Articles, Case Studies & Tools

• Fragnet Template & TIA Toolkit
• Project Controls Academy: Forensic Scheduling
• Curtain-wall change fragnet case study
• Fragnet integrity in delay claims