Benefits of EPPM Systems as applied to Forensic Schedule Analysis

In the same way that an enterprise-level scheduling system facilitates the identification and application of best practices for planning and scheduling across an organization’s projects, such a system can be used to prepare an organization for potential disputes and assist in avoiding or mitigating disputes that arise.

Maintaining an enterprise project portfolio management (EPPM) system provides a basic structure for the collection and organization of the schedule information necessary to manage change and avoid, mitigate, assert, or defend against claims.

While CPM schedules can be maintained in a stand-alone scheduling application, maintaining the organization’s baseline schedules and updates in a centralized system facilitates the application of a consistent set of best practices and peer review of schedules. Because schedulers working for the same organization become familiar with the standard formats and practices of the company, they are well equipped to identify elements of a schedule that are outside of the company’s standard practices, and question whether those elements were incorporated into the plan intentionally or by error. Peer review and management review of the baseline schedule outside of the project team can identify logic errors, missing scope, and high-risk areas of the plan. In general, anything that is done to improve the project plan at the outset can serve to reduce the risk of claims, reduce disagreements regarding the plan, and facilitate resolution of disagreements when they arise.

Some practitioners have argued that they need to remain focused on planning their projects, unimpeded by enterprise-level requirements or systems. However, having a standard set of best practices at the enterprise level should never reduce the quality of schedules at the project level. While each project has its own unique requirements and execution strategy, the success of the organization is determined by its ability to successfully execute a set of practices across all of its projects. One major project failure can result in losses that offset profits from all other projects, or even lead to organizational insolvency. Executing a standard set of scheduling practices across the enterprise can ensure that the projects that carry the most risk—or those on which risks increase during execution—receive the appropriate level of attention by company management.

While project personnel may bristle at corporate oversight, it is necessary to manage risk at the organizational level. For the project team, achieving buy-in by company management and an understanding of the project team’s execution plan will be valuable when changes and potential claims arise. Review and acceptance of the project team’s schedule by its own company’s management personnel should be used as a dry-run for review and acceptance by the owner or other project stakeholders. Changes to the schedule that are driven by another party often add risk to the company executing the plan. Company management should understand the original execution plan and be involved in significant changes that add risk.

In addition to allowing the company to identify and focus on projects that carry more risk, an enterprise-level system allows the company to quickly ensure that all of its projects have complete baseline schedules and have been appropriately updated over the course of their execution. These schedules are stored in a central database that can be backed up routinely to prevent loss of the data by hardware damage, viruses, or database corruption. A quick review of the schedule database can identify projects that have not been updated recently, and appropriate inquiries can be made as to the status of the project’s controls systems. Having a complete set of up-to-date project schedules across the enterprise prepares a company for claims that arise, even if they arise on projects that were not thought to carry significant risk.

Having managed the enterprise to ensure that project schedule records are as complete as possible and follow the company’s scheduling standards, the organization is in the best possible position for performing a forensic analysis when required. All methods of forensic schedule analysis are limited by the quality and completeness of available project information. Of the nine method implementation protocols outlined in AACE International’s RP29R-03, seven require the baseline schedule, schedule updates, or both as minimum inputs for the analysis. The remaining two methods require only an as-built record as a minimum input; however, a significant part of that as-built record could be contained within a properly updated CPM schedule.

Regardless of the analysis method chosen, there is a benefit in getting the appropriate information to the analysis team as efficiently as possible. Large organizations may have a specific group tasked with analyzing claims and supporting dispute resolution. For a group such as that, immediate access to all of the company’s schedules would be of certain benefit when they are notified of a dispute on a project. There would be no need to locate, export, transmit, and restore schedules from a separate database. Concerns regarding potential loss of information or changes to information when moving schedules from one database to another would also be eliminated. Even small organizations typically have a few specific individuals with experience in forensic scheduling. Maintaining schedules in a centralized system allows for a limited number of forensic analysis personnel to have immediate access to the company’s schedules.

Once the analysis begins, forensics personnel can prepare numerous analysis schedules. For example, an analyst executing one of the observational techniques may prepare additional schedules while inserting progress into one schedule from a subsequent update and analyzing the critical path on a day-by-day basis. An analyst executing one of the modeled methods may prepare numerous fragnet schedules or schedules with fragnets inserted into them. In either case, an enterprise-level system can be used to make these analysis schedules immediately available to other analysts or to the project team for review, discussion, and validation of the analysis results. Security controls in the enterprise system can be used to ensure that only the appropriate personnel have access to analysis schedules.

Analysts can work together more easily in an enterprise-level environment to prepare analysis schedules jointly. Moreover, as the enterprise-level system can facilitate consistency of practice and peer review in project execution, the same benefits apply to analysis. Senior-level personnel can review analysis schedules prepared across the organization to ensure that the company’s preferred analysis techniques are applied. In cases where a specific analysis technique is required by contract or by the legal jurisdiction in which the dispute is to be adjudicated, personnel with more specific experience in that analysis technique can be called upon for review and support. Even personnel outside of the organization can be given access to prepare or review analysis schedules through a secure channel.

Planning and scheduling tools and practices that were originally developed in the interest of better management of individual projects now are evolving to become incorporated into enterprise-wide management systems. This evolution can place additional burdens on project personnel as there is increased oversight and an increased desire to integrate project-level systems into systems for accounting and management reporting that are more focused on managing the company than on executing one specific project. However, the benefits to the overall company may justify any additional burden if they include an increase in the consistency and quality of its execution plans and better availability of information. A focused and disciplined approach to planning and scheduling can support successful project execution and claims resolution whether the tools used are stand-alone applications or enterprise-level systems. As software tools evolve, organizations will need to continue to evaluate the available tools, the benefits and costs of implementation, and the fit for their individual company.