Modeling a Multi-Activity Fragnet in a Time Impact Analysis

One Lump of Time vs. a Real Fragnet

A fragnet is a small network of activities representing a delay event, inserted into the schedule update that existed just before the event and recalculated — the core of a Time Impact Analysis. The simplest fragnet is a single activity. But an owner-directed design change is rarely that simple: the design has to be revised, the owner has to review it, and only then can the rework start. Three activities with real durations and real logic between them are easier to defend than one activity whose length someone had to estimate.

The Three Things a Fragnet Needs

1. Activities — each with a name, a duration, and a work calendar. Duration is entered in days and converted to working hours using the chosen calendar, so a three-day activity on an eight-hour calendar is 24 working hours.
2. Links between the fragnet’s own activities — Finish-to-Start, Start-to-Start, Finish-to-Finish or Start-to-Finish, each with an optional lag.
3. Connections to the real schedule — which real activities (identified by their Activity ID) the fragnet follows, and which it holds up. Without at least one, the fragnet cannot move anything.

Worked Example: Series vs. Parallel

A two-activity schedule: activity A (40 working hours, Monday January 5 to Friday January 9) followed by a finish milestone B (8 hours). B finishes Monday January 12 at 4:00 PM. Now a delay event is modeled two ways, using the same two fragnet activities — a two-day activity and a three-day activity:

Two lessons sit in that table. First, only the longest chain into a successor matters: in parallel, the two-day branch is absorbed by the three-day one and contributes nothing. Second, calendar days are not working days: the series fragnet spans a weekend, so five working days push the finish date seven calendar days. An analysis that reports only one of those numbers, without saying which, invites an argument.

A Caveat About the Critical-Path Flag

The finish-date delay rests on the forward pass, which reproduces Primavera P6’s own early dates closely. Whether a fragnet activity is flagged as being on the driving path depends on float, and P6 has several ways to define float that a from-scratch calculation may not reproduce exactly. Treat the finish-date delay as the headline result and the driving-path flag as supporting context.

Frequently Asked Questions

When is one delay activity not enough?

When the delay event really is a sequence of separate pieces of work with their own durations and logic -- for example a design revision, then an owner review, then rework. Modeling that as one lump-sum activity hides which piece drives the delay and makes the durations harder to defend. A fragnet with the same level of detail as the rest of the schedule shows exactly where the time comes from.

Why can a five-working-day delay move the finish date by seven calendar days?

Because the finish date is a date, not a count of working days. If the added work spans a weekend on a five-day work calendar, the finish moves by the working days plus the non-working days in between. Delay claims are usually stated in calendar days, so an analysis should report both figures and say which is which.

Do the fragnet activities have to be connected to the real schedule?

Yes -- a fragnet that isn't tied into the network can't affect the finish date. It needs at least one relationship into the existing schedule, typically at least one real predecessor (where the event starts) and one real successor (what the event holds up).

Does inserting a fragnet change work that is already complete?

No. A Time Impact Analysis is run against a schedule update from before the delay event, so the activities the fragnet affects are still in the future. Completed activities keep their real actual dates and are not recalculated, which is why the technique is meaningless against a fully as-built schedule -- that is what a collapsed as-built analysis is for.