Benefits of Using Change Inspector

Additional work and change orders can result in delays to the project.  It is important to create a schedule comparison report with every change and schedule update to identify the impacts. A schedule comparison report can be created as a 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. Claim Digger used to be the “go-to” third-party software for comparing Primavera P3 files. Claim digger was acquired by Primavera and subsequently became part of Oracle Primavera P6. A brief timeline of Claim Digger is as follows:

  • 2004 – P3 e/c is renamed to P3 Engineering & Construction (Version 4.0 and 4.1) and Claim Digger was first added to the software as a java application.
  • 2008 – Claim Digger for P3 is no longer available for sale.
  • April, 2013 – P6 Pro and EPPM Version 8.3 added Visualizer tool.
  • October, 2014 – P6 Release 8.4 Patch Set 1 (8.4.1) P6 Pro stand-alone now installs SQLite database manager instead of the server options. SQLite version does not support Claim Digger.
  • April, 2016 – P6 Version 16.1.0 Schedule Comparison (Claim Digger) is available in P6 Visualizer. The Scheduler Comparison in the same location (Tools) as Claim Digger but clicking on it will launch the Visualizer program.

Claim Digger has its shortcomings. Change Inspector is a schedule comparison tool that addresses these short-comings.

Claim digger produces a lengthy HTML report that could be hundreds of pages long.  Navigating the Claim Digger reports can be cumbersome and time consuming. The scheduler has to scroll up and down through hundreds of pages. On the other hand, Change Inspector creates reports in Excel format organized by worksheets.  Not only that it is easier to review and navigate, it is also easier to create and format custom reports.

Claim Digger reports are difficult to use without clean up and reformatting. The schedule review and documentation of the changes require a streamlined approach. Change Inspector creates streamlined reports. 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.

Change Inspector

 

 

On the other hand, Claim Digger shows this information in 2 separate sections. Furthermore, the scheduler cannot see the float values on the same report. As a result, in the Claim Digger report, it is not possible to tell whether the duration changes result in negative float.

Claim Digger

 

It is important to see the added activities with their duration and float values on one report so that the scheduler can easily check if the activities were added to the critical path.

Change Inspector

 

Claim Digger only shows the added activities.  It is not possible to see the effects of the added activities in one streamlined report.

Claim Digger

Change Inspector produces additional reports such project dashboard.

Change Inspector

Change Inspector works with XER files or can directly connect to the Primavera  database. Change Inspector does not need to have P6 installed. To run Claim Digger, users need to have a P6 license. Claim Digger does not compare XER files.  Change Inspector can compare XER files.  As an added bonus, Change Inspector can also compare MS Project files.

These are only a few examples of Change Inspector’s benefits.   You  can download a 30 day trial version of Change Inspector  ( http://www.changeinspector.com/download.html ) and experience the benefits firsthand.  Change Inspector saves you time and money.

 

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.