Insert a delay event into a real update and see what it does to the finish date.
What it does
Takes a schedule update from before a delay event, inserts a 'fragnet' (one activity, or a small linked network of up to twelve, representing the delay), ties it to the real activities it follows and holds up, recalculates the whole schedule from its logic and calendars, and reports the baseline finish, the impacted finish and the delay.
A fragnet inserted between real activities pushes the downstream work and the finish date.
What it helps you achieve
Quantify what a specific delay event did (or would do) to the completion date.
Model a delay properly, as a sequence such as redesign → review → rework, instead of one lump of time.
Show a delay's effect on the real schedule, on the Gantt, with the fragnet in place.
How to run it
Where to find it: Project page → Time Impact Analysis
Open the project and choose Time Impact Analysis, then + New Time Impact Analysis.
1. Choose the base schedule: an update from before the delay event.
2. Describe the fragnet: give the main activity a name, a duration in days and a calendar. Choose + Add a fragnet activity to add more (each can have its own calendar), and + Link two fragnet activities to sequence them (Finish-to-Start, Start-to-Start, Finish-to-Finish or Start-to-Finish, with an optional lag).
3. Connect it to the real schedule (at least one connection): pick the real activity and say whether the fragnet is a successor of it or a predecessor of it. Use + Add another connection as needed.
Choose Run Analysis.
Read the Baseline Finish, Impacted Finish and Delay (in calendar days and in working hours), then the table of fragnet activity dates and the Gantt with the fragnet in place.
What you get
Baseline finish, impacted finish, and the delay in both calendar days and working hours.
Start and finish dates for every fragnet activity, and whether each is on the driving path.
The impacted schedule on a Gantt, with link lines to the real activities.
An Excel export, and a saved result you can reopen.
Saved fragnet templates, so a common delay pattern can be reused.
Good to know
Only the real activities it connects to and the logic downstream of them matter; a fragnet tied to work that has float may cause no delay at all. That is a valid answer, not an error.
A chain in series adds its durations; branches in parallel only add the longest branch.
Calendar days can exceed working days because a weekend falls in between; the result shows both.
Limits, stated plainly
Run it against an update from before the event. Work already complete keeps its real dates and is not recalculated, so a fragnet placed upstream of completed work shows no effect.
The 'on the driving path' flag depends on float; treat the finish-date delay as the headline result.
Try Time Impact Analysis and fragnets on your own schedules. Claims Digger is invite-only while we’re in early access.
A small network of activities that represents a delay event. Instead of one activity standing in for the whole delay, you model its real steps and how they connect to the schedule.
Why did my delay come out as zero?
The activities you connected the fragnet to have enough float to absorb it, or the fragnet is tied to work that is already complete. Both are legitimate results.