Time impact analysis#

A time impact analysis (TIA) answers the question owners ask most: how many days did this specific event add to the finish? You describe the delay (an unforeseen condition, a change, a late approval) and Owl's Delay analysis specialist models it as a small set of activities inserted into your schedule, recalculates, and measures how far it pushes completion. It's the method most often expected for a time-extension request, and the first one to reach for when a single event has set you back.

Note: The industry term for the inserted activities is a fragnet, short for "fragmentary network": a small cluster of activities that represents the delay and ties into your existing schedule. The agent proposes the fragnet; you approve it.

Before you start#

Have the basics of the event ready: what happened, roughly when, who is responsible, and which existing activities it hit. If you have supporting paper (a change order, an RFI, a photo log, an updated schedule file), have it handy to attach. You don't need to have modeled anything; that's the agent's job.

Step 1: Set up the analysis#

In the chat panel, click + (New thread) and pick Time impact analysis under Delay analysis specialist. (In a thread that's already with that agent, use the Flows button under the message box.) See Analyze a delay for both routes.

The form opens at the bottom of the thread. The first step asks two things:

12341The bar shows where you are: this flow has three steps.2Analysis perspective: Prospective or Retrospective.3Un-impacted schedule: the schedule the delay is inserted into.4Next goes to the delay event.

• Analysis perspective: Prospective (a forecast run close to when the event happens, the most common) or Retrospective (looking back at an event after the fact).
• Un-impacted schedule: the "before" schedule the delay goes into. Usually your Current schedule; you can also use the Project baseline or Upload an update (the update that was in effect just before the delay, as P6 XER/XML, MPP or Excel).

Step 2: Describe the delay event#

Tell the agent what happened.

12341Responsible party: Owner, Contractor, Third party, Force majeure / weather, or Undetermined.2Event description: a plain account of cause and effect. The more specific, the better the fragnet.3Impacted (target) activities: the existing activities the event delays. The fragnet ties into these.4Supporting evidence: attach the change order, RFI or correspondence.

• Event name: a short label, for example CO-07 EV charging or Unforeseen rock at Zone B footings.
• Responsible party: this frames whether the delay is usually excusable (you're owed time) and compensable (you're owed money). The report notes it but doesn't decide entitlement for you.
• Event description and Impacted (target) activities: what happened, and which activities it delays. An activity that's already complete is fine; the agent ties the added work to its next unfinished successor.
• Model several events together: turn this on if more than one event in the same update period should be analyzed together, and describe each one.
• Supporting evidence, When it happened and Time claimed (working days) are optional. The date sets where the fragnet starts; the time claimed lets the report compare the result with what the change order asks for.

The last step, Check and start, lists every answer. Click Edit next to one to change it, then press Start. Your answers appear in the thread as your message, and the agent gets to work.

1231Every answer, in one place.2Edit jumps back to that question.3Start sends the answers to the agent.

Step 3: Review the proposed fragnet#

The agent reads your schedule and the evidence, then proposes the fragnet in the chat: the new activities, their durations, and how they tie into your schedule. It also says what it found at the data date, for example a delivery that was already complete before the change was issued.

121The proposed fragnet: each new activity, its duration in working days, and what it ties into.2A question card asks for the judgment calls and your go-ahead. Once answered, it folds down to your answers.

This is the judgment call, and it's yours. If a duration or a tie is wrong, pick the option to change it on the question card, or type what to change. Nothing touches the schedule until you approve.

Step 4: Read the result#

Once you approve, the agent inserts the fragnet into a scenario (your working schedule is untouched), recalculates, and measures the delay to the completion milestones. It writes the report and asks you to accept it or say what to change, for example to add a sensitivity run with a different assumption.

12341The report document: the summary of results by milestone, then method, fragnet, critical path before and after, and caveats.2The agent's summary: the delay to each milestone and what it means for the claim.3The scenarios it built, marked draft. Open one to see the fragnet in place.4The report under Documents.

You get two things:

• A report document under Documents (for example, Time Impact Analysis — CO 07 - EV Charging) that you can export and attach to your submittal.
• The scenarios it built, under Scenarios. Open one to see the fragnet on the Gantt. Keep them as the record of the analysis; don't merge them into your working schedule.

Note: The delay is measured along the longest path, the chain of activities that sets the finish date. A fragnet only pushes completion if it lands on that path. If the agent reports zero days, that's a real result: the event hit work with enough float to absorb it. In the example above, an EV charging change order delays completion by 0 working days if the added conduit goes in during the deck rebar work, and by 2 if it goes in after, because only the second case reaches the critical deck pours.

What to do next#

• Try a different lens: if the job is already complete, a collapsed as-built approaches the same question from the other direction, by removing delays instead of adding them.
• Send it: export the report document for your time-extension request or claim.