Fragnets: What They Are and How to Write One

A fragnet, short for fragmentary network, is a small set of activities and logic that represents a single change or delay event. You write it, insert it into the current schedule, and recalculate to see what the event does to the finish date. It's the core of a time impact analysis and the usual way a change order gets into the schedule. This post covers what goes in one, how to tie it in, and the habits that make reviewers accept it instead of sending it back. There's a worked example at the end.

What a fragnet is for

The schedule represents the plan. When the plan changes because of an owner directive, an RFI that turned into a redesign, or a differing site condition, the schedule needs new work in it. A fragnet is that new work, written so it can be reviewed on its own before it goes into the live update.

Done well, a fragnet makes three things obvious:

• What new or changed work the event adds.
• What existing work it waits on, and what existing work waits on it.
• How long each piece takes, and why.

If a reviewer can see those three things in one table, the fragnet will usually go through. If they have to dig through the whole schedule to figure out what changed, it won't.

What goes in

Include every step the event actually requires, including the paperwork steps that eat calendar time:

• The triggering event, as a start milestone with the real date (directive received, condition discovered).
• Design or redesign by the architect or engineer, if any.
• Pricing and approval, if work can't proceed until the change is approved.
• Submittals and review cycles for new materials or equipment.
• Procurement and fabrication lead time.
• The installation work itself, broken to the same level of detail as the surrounding schedule.
• Inspections, testing, or commissioning the change adds.
• Removal or demolition of work already in place, if the change undoes something.

Don't include work that would have happened anyway. If the slab was always going to be poured, the slab isn't part of the fragnet. The fragnet adds the new conduit that has to go under it, and the slab gets a new predecessor.

How to tie it in

The ties are where most fragnets fail. A fragnet with weak ties either shows no impact when there is one, or shows an impact that's too large.

Start ties. The first fragnet activity should be driven by something real: the date of the directive, or a predecessor activity that physically has to be done first. Don't leave it hanging off the data date with no explanation.

Finish ties. The last fragnet activities have to drive the existing work they actually affect. Be specific. If a change only affects the east wing, tie it to the east wing activities, not the whole building. If the schedule's activities are too coarse to tie to the right place, split the existing activity and explain why.

No open ends. Every fragnet activity needs at least one predecessor and one successor. An activity with no successor can slip forever without moving anything, which is exactly the problem described in Open Ends and Dangling Logic.

No constraints. A start-no-earlier-than date inside a fragnet hides the logic. If something can't start until a date, say why with an activity (a delivery, a permit) rather than a constraint.

Go easy on lags. A lag of 10 days between two fragnet activities is an activity you didn't name. Name it. See Lags and Leads: The Hidden Logic in Your Schedule.

Durations need a basis

Every duration in the fragnet should have a source someone can check:

• A supplier quote or lead time letter for fabrication and delivery.
• The contract's stated review period for submittals and RFIs.
• Crew size and production rate for installation work.
• The design professional's written commitment for a redesign.

Write the basis down next to each duration. "10 days" is a number. "10 working days, the A/E review period in the spec" is a duration a reviewer can accept.

Don't pad. Padding a fragnet is the fastest way to lose credibility on every future fragnet you submit on the job.

Housekeeping that saves arguments

• Give fragnet activities their own ID prefix (for example, the change order number) and an activity code so they can be filtered in and out.
• Use the same calendars as the surrounding work, unless there's a reason not to.
• Code each activity by responsible party, so owner-caused and contractor-caused work aren't mixed.
• Keep a copy of the update without the fragnet. The comparison is the whole point.
• Submit the native file, not just a PDF.

A worked example

The owner directs the contractor to add a standby generator. The directive arrives on what we'll call day 0, at the data date of the current update. The convention below is 0-based: ES of the first activity is 0, EF = ES + duration, and a successor's ES is the latest EF of its predecessors (finish-to-start, no lag). Durations are working days.

The successor in the existing schedule is "Life safety acceptance test," which is on the critical path in the current update with an early start of day 62. CO12-08 becomes its predecessor.

Forward pass through the fragnet:

ID       Dur  ES  EF
CO12-01    0   0   0
CO12-02   10   0  10
CO12-03   10  10  20
CO12-04   30  20  50
CO12-05    3  20  23
CO12-06    2  50  52   (ES = max(50, 23))
CO12-07    4  52  56
CO12-08    2  56  58

The fragnet finishes on day 58. The life safety test can still start on day 62. No impact to the critical path; the fragnet has 4 days of float against that tie. The pad, which only needs 3 days and has until day 50, has plenty.

Now the supplier's letter comes back with 36 working days instead of 30:

ID       Dur  ES  EF
CO12-04   36  20  56
CO12-06    2  56  58
CO12-07    4  58  62
CO12-08    2  62  64

The fragnet now finishes on day 64, so the life safety test moves from day 62 to day 64. Since that test was critical with zero float, the project finish moves 2 days. The 6 extra days of lead time cost 2 days of project time, because the first 4 were absorbed by the fragnet's float.

That's the kind of result that holds up: the numbers trace back to a letter, the ties are specific, and the arithmetic can be redone on a napkin.

Where people go wrong

• Tying the fragnet's finish to the project completion milestone instead of to the work it actually affects.
• Starting the fragnet at the data date when the event actually happened weeks earlier, or later.
• Leaving out the submittal and approval steps, which are often longer than the installation.
• Including the contractor's own recovery or resequencing inside the fragnet without labeling it.
• Writing a fragnet at a much finer level of detail than the rest of the schedule, which makes the change look bigger than it is.

The fragnet supports the request for time, but it doesn't replace the notice. Send the notice when the event happens, and follow with the fragnet. See Delay Notices: What to Include and When to Send Them.

Key takeaways

• A fragnet is a small, self-contained network that models one event, reviewed before it goes into the live schedule.
• Include the paperwork steps (design, pricing, submittals, procurement), not just the field work.
• Tie both ends to specific existing activities. No open ends, no constraints, minimal lags.
• Give every duration a written basis, and don't pad.
• Recalculate and compare against the unmodified update; the difference is the impact.