Time Impact Analysis (TIA) is a prospective schedule delay analysis method. In this method the analyst develops and adds a model of the change to an approved schedule to quantify the delay to project completion. AACE International Recommended Practice No. 52R-06 Change Management and Forecasting – Time Impact Analysis, describes implementation of this method in detail.
The first step in preparing a TIA is to inventory all new tasks occasioned by the change. These tasks are then logically related to each other and the base contract tasks to model the change with a schedule fragnet.
The scheduler should not work in a vacuum to develop and implement a TIA fragnet. The project team should be actively engaged to provide detailed input as how best to incorporate the changed work into existing means and methods. Otherwise the TIA becomes a highly subjective and often disputed change model that may not be fully implemented in the field.
The schedule fragnet is a subset of the activities in the project schedule that will be involved directly with the change. For ease of comprehension and review, the change should be described completely but as simply as possible. Use the fewest number of activities and relationships to substantially reflect the impact of the change to the schedule.
Notwithstanding simplicity, sufficient detail must be shown that is consistent with the nature and complexity of the change or delay being modeled. As the activities are added they should be identified in a logical manner to make it easy to differentiate the TIA from Base Work. Fragnet development must include representation by the affected disciplines of design and construction. It should receive a final sign off by design lead and construction lead. The fragnet will then be added to the appropriate schedule. Usually this is the latest approved schedule, statused and updated prior to the change or delay. This may not always be the case.
Primary steps for developing TIAs include:
1. Review of all project design documents added or impacted by the change
2. Review of physical construction quantities that result from the change
3. Inventory all tasks required to be performed as a result of the change.
4. Development of fragnet logic with input from design and construction subject matter experts. When developing a fragnet schedule:
- Activity descriptions should be self-explanatory while identifying themselves as fragnet-added or changed activities.
- Holidays and non-working periods must be taken into consideration
- Fragnet should not have “open ends” besides the first and last activities. Exceptions must be well justified and kept to a minimum
- The use of constraints should never serve as a substitute for detailed logic
- Even if the contract does not require a resource loaded schedule, resource limitations and flow must be considered. Analyst must ensure the resource assignment and activity durations represents a feasible execution plan.
- A fragnet coding structure must be established to filter, sort and summarize.
5. Determine the appropriate master schedule update that is to accept the TIA.
6. Obtain sign off from design, construction, and management before inserting the fragnet.
7. Sequentially insert fragnets if there are multiple changes and/or change may be implemented in distinct phases or areas.
8. Document results and changes with schedule comparison report
9. Document changes to float distribution as described below.
10. Prepare a summary table that lists the master schedule name, data date, fragnet number, impacted completion date in the order that the fragnets were inserted.
11. Update schedule basis documentation.
There are numerous opportunities to incorporate mitigation measures to offset impacts driven by owner caused delays. The analyst should first fully impact the schedule, measure and record the impacted facts using the tools previously described, record the full impact then mitigate and record the mitigated impact.
3) From Properties, select the Compatibility tab and check “Run this program as an Administrator”