Time Impact Analysis for Beginners

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.

CPM Schedule Comparison Reports

All efforts spent developing a baseline schedule can be wasted unless progress is monitored and changes to work are reflected in periodic schedule updates.  A periodic schedule update consists of two distinct processes, first updating for achieved progress and second incorporating changes to work and their impact to critical and near critical paths.  Changes must be evaluated separately and consistently to allow project stakeholders the opportunity to mitigate impacts of change.  Failure to implement change management as a separate process often reduces the effectiveness of the schedule as a real-time management tool.

Schedulers and delay analysts should create a schedule comparison report with every change and schedule update.  The comparison report is created as part of the routine monthly report and serves multiple purposes.  It serves to document the basis of the delay analysis as well as being a full auditable record of the project schedule.  This schedule comparison report also should be created for each impacted version of a schedule to serve as the full record and audit trail of multiple layers of time impact analysis (TIA).  This is important because it documents the incremental impact of each layered change or disruption to the project.

Traditional schedule comparison tools compare every field and produce a lengthy report.   Most often these comparison reports are difficult to use without clean up and reformatting.  The schedule review and documentation of the changes require a streamlined approach.  For example duration changes and description changes should be summarized in one report because both a description and original duration change may indicate an activity scope change.  It is important to see the added activities with their duration and float values on one report.  There should be composite reports to show every change to each activity.  Change Inspector software provides the schedule comparison results in a series of comprehensive and organized reports.  It works with Primavera (XER) files and Microsoft MPP files.

Enterprise Project Structure (EPS)

Enterprise Project Structure is a hierarchy that represents the breakdown of projects in the organization.  EPS nodes at the higher level might represent divisions within your company, project phases, site locations, or other major groupings based on your company’s needs and business practices.  It might be easier to visualize the EPS as the folder structure on your computer’s hard drive.  EPS nodes correspond to the folders and projects correspond to the individual files.  Every project in the organization must be included in an EPS node.  It is possible to combine separate P6 schedules under an EPS to represent a single project.  Before subdividing a project into multiple P6 schedules, the complications such as having multiple data dates, inability to calculate a longest path or the concept of default project must be clearly understood.

It is also possible to use EPS to combine contractor, P3 and MS Project (MSP) schedules from subcontractors or other project stakeholders.  The Microsoft Project Plug-in called ProjectLink allows users to use MSP as their daily tool to status projects and at the same time allows the data to appear in P6.  P6 users can see but not make changes to projects managed in MSP.  Projects must be saved locally in MPP format before sending to P6. The user must have rights to import global data and must have rights to the EPS Node the project is under. Only one user can check-in/check-out a project at a time. Most items will be “read only” in Project Manager. Work Products/Docs and Codes are the only items that can be changed in P6.

Although there are no tools to transfer the EPS from one database to another, it can be achieved by making a backup of the source database with the EPS structure and restore the database on the target environment.