Observations About The Utility PPM Problem
 
 

Contents: Problem Setting | Solution - Requirements | Solution - Implementation | Analytics

This is a set of observations about the electric utility project portfolio management problem ( the PPM problem). These observations are based on my experiences (1) developing, for transmission and distribution companies, a method and software to solve the utility PPM problem and (2) implementing the method at over 10 electric utilities.

I started working on the utility PPM problem in the late 1990s while managing an EPRI research program on Utility Asset Management. Since mid 2003 I have continued to work on the problem as a private consultant and director of S.Chapel Associates.

Steve Chapel


 
   
 

 

 
 

Problem Setting

Asset Intensive Business: Electric Utilities are extremely asset intensive requiring about four dollars of capital in-place for every dollar of annual revenue. This high ratio translates into extra-long periods for capital recovery

  • The market will not allow quick capital recovery.
  • Long-period capital recovery requires necessarily long economic lives and significant maintenance requirements

Pressure to Reduce Costs: Industry restructuring has and will continue to create pressure to reduce costs. At the same time the delivery infrastructure is aging and as a result demanding increasing levels of maintenance and replacement. For many companies, the funds allocated to capital and especially maintenance projects has been and is being reduced. Engineers are starting to be ask to build sound business cases for all significant projects.

Hundreds of Project Decisions: For most power companies building and maintaining electric utility infrastructure requires funding and executing literally hundreds of capital and maintenance projects every year. Excellence in managing these assets requires that utility planners and engineers treat fairly and consistently projects with different attributes (including large and small projects, projects with different time horizons, and projects that respond to different needs—financial, environment, safety, reliability, and customer requirements).

Top

 
   
 

 
 

Solution - Requirements

Consequences of Deferring Projects: At the project level a system must measure the value contributed by a project and value that is given up if the project is delayed (I like to refer to this as measuring the "pain" of deferral). The fundamental decision is what to do in the current year and what to delay. Project value must be measured in terms of contribution to company objectives.

Consequences of Reduced Portfolio Budgets: At the portfolio level a system must measure the value of the portfolio and the value of the portfolio under different levels of funding. The value of the portfolio is an aggregation of project values.

Project Selection That Maximizes the Portfolio Value: A system must be based on a project selection method that maximizes the value of the portfolio.

Transparent Results: The results of the system must be transparent to all parties involved. This means that project scores must be easily understood and results easily communicated to (1) engineers who sponsor projects, (2) managers responsible for company functional organizations, (3) company senior management and (4) regulators.

Top

 
   
 

 
 

Solution - Implementation

Contents: Valuation Method | Implementation Check List | Software

Project Valuation Method

Fortunately a powerful methodology exists for solving the PPM problem. The methodology, based on multi-attribute decision theory, allows for the explicit quantification of (1) the consequences of doing or not doing a project and (2) the risks of deferring a project because of funding constraints.

At the highest level, the reason projects are done is that they have attributes that contribute to overall corporate objectives. The decision maker, when evaluating projects with different attributes, can define measures that allow him to trade-off competing values. This trade-off is often done implicitly. Decision frameworks based on multi-attribute decision theory, makes this trade-off explicit.

The explicit trade-off procedure is based on combining three kinds of measurements:

  1. First, each project is described with respect to a collection of attributes. These attributes are chosen by the utility company and may include such variables as cost, reliability, power quality, and overloads.
  2. Second, each attribute level is compared to the best possible level that can be achieved, thus creating an attribute scale. The scale of an attribute measures the degree to which an intermediate level of an attribute approaches the best possible level. The scale measures how much is lost by achieving less than the best.
  3. The third kind of measurement compares relative values of competing attributes. These relative values are represented by weights.

Each project is represented, scaled, and weighted based on the attributes provided. If the attributes are well defined the process of representation, scaling, and weighting becomes a natural way to consider alternative projects. It is a means for decision-makers to understand better what they are basing decisions upon.

Note: The remarks on the three kinds of measurments are from Project Prioritization System: Methodology Summary. Chapel, S.W., Feinstein, C.D., Morris, P.A., V. Longo, 2001. EPRI Report 1001877

Implementation Check List

A good implementation strategy benefits from a check list. My list is the following:

  • Get the necessary corporate commitment
  • Organize for PPM and create the internal expertise to effectively use the system
  • Create a credible valuation tool through rigorous design and testing
  • Implement the system in a multi-user software environment.

Corporate Commitment: Implementing a formal quantitative PPM requires a commitment of significant internal resources in a corporation. It also requires change management - that is both managers and engineers must embrace both the design of the system and its adoption as the analytic tool for project portfolio management. Resources and change management can only come from the most senior management in a company.

Organizational Change: Experience has demonstrated that to effectively implement a PPM system necessary organization elements include:

  • An Executive Sponsor, representing senior management commitment to implementing the Project Prioritization system
  • A system administrator with the authority to administer the PPM system including perform analysis and work with project sponsors and functional managers to get data and review project scores. The administrator must have accountability for the credibility of the analysis process.
  • Project sponsors, typically engineers, in the functional organizations that are committed to the system and to working with the Administrator.
  • Cross-functional support and participation from the various functional organizations – maintenance, engineering, construction, and operations – as well as management for the implementation of a comprehensive and sustainable asset management program.

Design and Testing of the System: The success of a PPM system depends upon a rigorous and credible analytic methodology for performing analysis of project and portfolio value. My guidance for the design phase is the following: (1) use multi-attribute decision theory as the underlying methodology, (2) hire an expert in this field to facilitate the design and testing of the system, (3) budget at least six months time for the design, and testing phase, (4) make it your objective to create a system that produces, for all stakeholders, credible project values and rankings, (5) finally consider brining in an outside expert to work with you essentially full-time in-house during this critical phase.

Software Selection

It is my experience that companies tend to view the software selection decision as the lynch pin to PPM success. I could not disagree more with this point of view. System design, testing, training and corporate commitment are critically important. Software is important but insufficient absent the other elements. That said there are important considerations and question when choosing software.

Good PPM software will have three components

  1. A data management component for collecting, storing, and retrieving the information that serves as the foundation for project portfolio decision making.
  2. A decision component for (a) converting project induced changes into measures of project value, and (b) using project value to identify value-maximizing portfolios.
  3. A reporting component that displays the results.

There are several questions that should be considered when choosing software. These include:

  • Is the supplier set up to handle both the IT and value modeling support that is required for success?
  • Is the system designed to support implementation of value models based on a credible method for quantifying value (i.e., multi-attribute decision theory)?
  • Can the implementation of the tool be easily modified without the help of the suppler and without writing code? In other words is the system flexible in its setup and modification or does it have a pre-specified set of project attributes that require software coding in order to modify or expand?
  • Does the modeling system (1) supports enterprise wide project portfolio management, (2) is it a general system that enables users to quickly implement and modify multi-attribute valuation models without any custom code development?
  • Does the system have a data management system that allows ease of collecting storing and retrieving information including remote data entry and analysis?
  • Does the software allow remote data entry via a client-server environment?
  • How are reports generated and can the user create customized reports?
  • Can the system export data to other corporate databases? Likewise can required data be imported into the system?
  • Finanly does the system account for deferral risk when valuing projects? The failure of PPM solutions to account for deferral risk is a major limitation for electric utility applications. As far as I know, none of the commercial products have proper algorithms for accounting for deferral risk when valuing projects. To illustrate the importance of this problem, a colleague, Lee Merkhofer, and I have developed an Interactive Risk Demo. Click here to start the demo.The demo makes it clear that, as a result of not properly accounting for deferral risk, available PPM tools incorrectly prioritize utility projects and vastly under-value the importance of investing in maintenance projects.

Top

 
   
 

 
 

Analytic Considerations

Contents: Project Value | Time Horizon | Optimization | Risk

Note: The remarks in this section are taken partially from Fundamental Principles of Project Prioritization. VMN Group LLC and S.Chapel Associates, Feinstein, C.D., Chapel, S.W., 2004

Project Value

The value provided by a project is based on the incremental benefit the project provides compared with not doing the project, the so-called Do-Nothing alternative. The attribute levels associated with doing nothing must be specified over time. The attribute levels associated with doing the project must be specified over time.

Time Horizon

The practical question is over how many years will a project provide value? There is a time associated with a project such that the project provides incremental benefits compared with the Do-Nothing alternative. Beyond that time, the attribute levels are the same and the project provides no net benefits. Another way to express this idea is that delaying the value provided by the project indefinitely cannot happen and that somehow doing nothing “catches up” to the project – after some point the project can no longer be deferred and a project must be done. The point here is report incremental value provided by a project only until the time it takes for doing nothing to catch up.

Optimization

Solving the utility project portfolio management problem requires solving an optimization problem. The optimization problem is one of selecting starting times for all projects so that the sum of the benefits is greatest without exceeding any of the constraints (budget and labor).

  • Decision Variable: The decision variable in this problem is actually when to begin a project.
  • Objective: The objective is to maximize the value of the portfolio subject to budget and perhaps labor constraints.
  • Outcome Uncertainty and Risk: The outcome of this decision problem is value provided by doing a project and value foregone by deferring a project. Values may be predicted with some certainty or in some (many) cases the values of doing and deferring a project may be uncertain and thus risky.


Project Risk & Deferral Risk

Most tools for project portfolio management have shortcomings that make them incapable of accurately prioritizing projects. One source of error is the lack of proper algorithms for correctly valuing risk.

Risk can come in many flavors. Two import sources are project risk and deferral risk. Project risk refers to the risk that a project may fail to deliver its promised benefits. Project risk decreases project value. Deferral risk refers to the potential for losses to the business if the project is delayed. Deferral risk increases project value.

The failure of PPM solutions to account for deferral risk is a major limitation for electric utility applications. As far as I know, none of the commercial products have proper algorithms for accounting for deferral risk when valuing projects. To illustrate the importance of this problem, a colleague, Lee Merkhofer, and I have developed an Interactive Risk Demo. Click here to start the demo.The demo makes it clear that, as a result of not properly accounting for deferral risk, available PPM tools incorrectly prioritize utility projects and vastly under-value the importance of investing in maintenance projects.

Top

 
   
 

 

 

 

 

 
Copyright © 2003 - 2008 S. Chapel Associates.
Initial Site Designed by Imagine India Software Services Pvt. Ltd.