Level: Introductory Patrick McKenna, Senior Technical Advisor, IBM
15 Aug 2005 from The Rational Edge: Project portfolio management (PPM) for software development has been getting more attention over the past several years as organizations seek to improve net present value or expected commercial value regarding software projects. This article presents the history and theoretical underpinnings of PPM while avoiding the complex math usually associated with these concepts.  Many of us are familiar with the everyday concept of a portfolio -- a useful way to organize and manage a collection of items that are somehow connected. A portfolio is what holds an artist's sketches, a student's projects, and collections of cash, bonds, and stocks. Similarly, a project portfolio may be seen as a simple inventory or list of all the projects in the company, or, at a higher level of conceptual maturity, as a balanced collection of projects aligned with strategy, for optimum value. These project portfolio concepts are valid and useful, but they are all to a greater or less extent qualitative. They don't really get to the heart of how managers can use a modern portfolio approach to select and manage the optimum set of project investments. In the fast-paced twenty-first century, managers in software project organizations are faced with complex, often intractable, project investment decisions. Managers require quantitative portfolio concepts that can be applied to transform complex problems into efficient solutions.
The transition to modern portfolio thinking began in earnest in 1952, when Harry Markowitz published a paper entitled "Modern Portfolio Theory" (MPT) in the Journal of Finance. Very simply, Markowitz proposed that managers focus on selecting portfolios -- collections of assets -- based on their overall risk-reward characteristics. MPT offers guidance to managers who want to step up from the "local" level of projects thinking to the "global" level of portfolio thinking.
This article does not advocate MPT as a "magic bullet" for complex problems of software economics, nor does it treat the more detailed mathematics and algorithms that are required to fully apply it. Rather, my purpose is to discuss MPT in general, including its history, some of its basic concepts, such as return, risk, imperfect correlation, and Monte Carlo Simulation, as well as provide a practical example that demonstrates the portfolio approach.
A brief definition
To begin this discussion, let's accept Investopedia's definition of portfolio as "a group of assets held by an investor."1
If we apply this definition to project management, we can consider "assets" to be financial, physical, or information that alone unto itself and/or combined with other assets in a project will increase value. The "group" of assets is designed to achieve the growth of value at acceptable levels of risk over the longer term. The "investor" is a business manager whose job it is to put assets to work efficiently as a portfolio. Later in this article, I will revisit this definition after presenting more sophisticated concepts around managing projects, particularly the idea of software projects as investments.
Applying portfolio theory to IT investments
The idea of applying MPT and other contemporary risk-based approaches, such as Multi-Attribute Utility Analysis and Real Options Theory to IT investments, is far from new. It was first suggested in 1981, by F. Warren McFarlan, whose ideas were published in the Harvard Business Review in the article "Portfolio Approach to Information Systems."2 McFarlan suggested that managers employ a risk-based approach to the selection and management of IT projects. By explicitly understanding the nature and extent of risk, managers can allocate their resources appropriately to IT projects.
Thirteen years after McFarlan's paper, the General Accounting Office (GAO), in
1994, wrote a report entitled "Improving Mission Performance Through Strategic Information Management: Learning from Leading Organizations."3 The report describes how organizations may use a portfolio investment approach to select, control, and evaluate IT projects. Organizations can define and apply a set of decision criteria that will address the benefits, costs, and risks associated with a number of competing investment opportunities.
In fact, increasing concerns about high-profile IT failures, especially with regard to mission-critical or mission-essential IT systems, led to US government action on IT investment in the form of the Clinger-Cohen Act of 1996. This Act requires agencies of the US federal government to adopt an investment approach to IT projects. In 1998, the GAO followed with "An Executive Guide: Measuring Performance and Demonstrating Results of Information Technology Investments" that describes portfolio management as one of four strategic enterprise objectives.
Later that same year, John Thorp published The Information Paradox: Realizing the Business Benefits of Information Technology, which names portfolio management as one of three fundamental components of benefits realization. Thorp demonstrates that portfolio management can be applied to minimize risk, maximize return, and evaluate projects in light of other projects. He also describes the basic steps to establishing a project portfolio.
An MPT overview
Three key precepts underpin MPT:
- A rational investor chooses more value over less, and prefers less risk to more risk.
- There are many optimal portfolios that investors can select to support their goals.
- The portfolio, by diversification, increases the probability of success over time.
Portfolios are formed by putting together groups of assets in different proportions, then measuring the resulting aggregate risk and return of each group. In this text, "return" refers to the increase in asset value provided by an investment process. Since it is practically impossible to generate all possible asset combinations manually, automated methods must be applied. The most frequently used method is the Monte Carlo Simulation (which I will discuss later).
A simulation forms a "cloud" of many portfolios, including some that are efficient, from low risk/low return to high risk/high return, and others between these two extremes. Many portfolios will be inefficient, which means they may have high risk associated with a low return. These are to be avoided!
Figure 14 shows a cloud of all possible portfolios bounded and contained by a curved line. This line is called the "Efficient Frontier" and is Markowitz's key contribution to portfolio theory.
Figure 1: Portfolio optimization for oil and gas investments. Source: Don Merritt, Merak Projects
The closer a portfolio is to the Efficient Frontier the closer it is to being efficient, which means:
- For its level of return, there is no other portfolio with less risk, or
- For its level of risk, there is no other portfolio with more value.
It is worth mentioning that investment theories such as MPT, which are based on the movement of share prices, should not be imagined as being directly transferable to software or other projects. Shares represent the value of publicly traded companies and their price is determined by the markets. Projects, on the other hand, are generally short-term endeavors that are not priced by a market.
Some economists also express doubts as to the applicability of Modern Portfolio Theories. Consider this comment by a thought leader in MPT, William Sharpe:
If portfolios with radically different prospects are considered by an investor, too much reality may be omitted if his decision is assumed only to depend on risk and return. [my italics for emphasis]
The Allan Greenspan-like comment, "too much reality may be omitted," is particularly relevant to software project management and the difficult tasks surrounding estimating, capacity planning, staffing, scheduling, dependencies, communications, and so forth.
These caveats should caution, but not prevent, managers from examining modern portfolio concepts. After all, bonds and equities are issued to finance major projects that often are as large as some SMBs (Small and Medium Businesses), and the share prices of many "project-driven" companies in industries such as software, pharmaceuticals, and oil and gas are priced to a large extent by the health of their new product portfolios.
Portfolios in practice
As explained above, portfolios are generated by combining assets based on the metrics of risk and return that must be known in quantitative (statistical or mathematical) terms. In addition, well-designed portfolios contain projects that are "imperfectly correlated." Let's take a look at these concepts.
Risk and return
Software financial metrics are often, by necessity, quantitative. For example, a great deal of effort is put into producing valid and reliable data for software project cost estimates. The expected value and return on investment of a software project is based on these cost estimates, along with estimates of time to market, market studies, and pricing projections, with the final result often being expressed as one of the metrics mentioned below:
- NPV (Net Present Value). NPV is the present value of cash inflows minus the present value of cash outflows over a period. NPV analysis is sensitive to the reliability of future cash inflows that an investment or project will yield.
- ECV (Expected Commercial Value). Based on a decision tree analysis, ECV considers the future stream of earnings from the projects, the probabilities of both commercial and technical success, along with commercialization costs and development costs.
Risk in software project management is also well-known, although it is usually expressed qualitatively in a documented risk list. A quantitative approach to risk involves calculating NPV or ECV based on a range of values (high, low, and target) for inputs such as development and marketing costs, market size, time to market, pricing, and so forth.
This is usually performed through simulation and the NPV or ECV emerges as a histogram or distribution curve from which we can calculate the risk as a standard deviation. (A one half ("semi") standard deviation is a popular measure of downside risk.)
Correlation
Much of our knowledge, decision-making, and problem-solving capacity is based on our ability to spot behavioral patterns among co-varying things. The relationships among things in terms of whether they change together, or separately, is referred to as "correlation." For investment diversification to be effective, assets in a portfolio must not be too closely related (correlated) in terms of how they will behave in any given business context.
This notion can be illustrated pretty simply, at least to begin with, by the example of how the value of investments, such as airline stocks and oil stocks, move (co-vary) in opposite directions as energy prices vary; or in the way that property prices and the US dollar move in opposite directions as interest rates vary. In portfolio theory, assets that are not too closely correlated are said to be "imperfectly correlated."
In software projects this notion of imperfect correlation can be extended to, for example, quality and product innovation, two project categories that may be seen as imperfectly correlated. An organization may rush a product to market to secure a market position for its solution, and in doing so, it also may create quality problems for customers. In a fast-moving market context, where capturing market share and mind share is critical, a high-risk product innovation strategy is justified; in fact, it may be essential. The company can do something about the quality later. But as the business context changes to one of consolidation with more wary customers, we may have to invest more heavily in quality.
Skilled software managers are forever mitigating imperfect correlation to ensure that product innovation proceeds at full speed while quality remains strong. Software project managers do not have to calculate the correlations between projects or sub groups of projects. In practice, it is enough to know that the various components of the portfolio are not too closely related.
Monte Carlo Simulation
Monte Carlo Simulation is a technique that involves using random numbers and probability to find solutions to complex problems. The term was first coined by S. Ulam and Nicholas Metropolis in reference to games of chance, a popular attraction in Monte Carlo, in the Kingdom of Monaco.
The method is based on iterative evaluations using sets of random numbers as inputs. The method is used when the model is complex and nonlinear (that is, parameters do not co-vary in a linear manner), or when the model involves more than just two or three uncertain parameters. A simulation can typically involve over 10,000 evaluations of the model, a task that was once only possible with the help of super computers.
The simulation is categorized as a sampling method because the inputs are randomly generated from a probability distribution that stands in for a real data population. It typically uses random number5 generators to generate multiple scenarios of a model by repeatedly sampling values from the probability distributions for the uncertain variables.
The Monte Carlo method can be applied to estimate project value (NPV or ECV, as mentioned above) and risks, then to generate a range of different portfolios from these data.
An assessment of the portfolio approach
Earlier we accepted a simple definition of portfolio: A group of assets held by an investor.
A more complete and perhaps more concrete explanation of an IT portfolio is provided in an excellent report called "A Summary of First Practices and Lessons Learned in Information Technology Portfolio Management" by the CIO Council in March 2002:
An IT Portfolio is comprised of a set or collection of initiatives or projects. Portfolio management focuses attention at an aggregate level. Its primary objective is to identify, select, finance, monitor, and maintain the appropriate mix of projects necessary to achieve organizational goals.
Portfolio management involves the consideration of the aggregate costs, risks, and returns of all projects within the portfolio as well as the tradeoffs between them.6
It is important to realize that portfolio management is more than "scaled up" project and program management. An old, but good, IBM saying can be adapted to illustrate this point: "Projects are local; portfolios are global." In my view, "portfolios are forever;" as long as the organization exists and has a strategy to implement, it will have to have a project portfolio.
Let's look at a real-world example of this approach applied to software projects.
The Federal Chief Information Officers (CIO) Council's (Best Practices Committee -- Community of Practice for IT Performance Management) in 2001 assessed two portfolio methodologies as they were applied to two major federal IT initiatives: the Balanced Scorecard (BSC) and Applied Information Economics (AIE) approach. These methodologies were applied by Veterans Affairs (VA) to make decisions on investments in an Information Security Program (ISP).
The goals of the ISP project are to reduce the frequency and severity of three types of security incidents -- viruses, unauthorized intrusions, and environmental events -- that cause four types of losses: fraud, productivity, interference with mission, and legal liability.
There were seven types of ISP investments (projects) as follows:
- Public Key Infrastructure
- Intrusion Detection
- IT Systems Certification and Accreditation Program
- Simplified Sign On
- Antivirus
- Computer Incident Response Capability Training
- Education, Awareness, and Message Building
All seven of these ISP investments have various risk and potential investment returns. The VA team used an AIE method to analyze which combination of optional components would be the most effective in reducing security-related losses. To do so, they ran Monte Carlo Simulations to generate 50,000 random scenarios for cost and benefits -- each a potential ISP outcome. The simulator kept track of the scenarios and plotted a histogram of the investment returns along with the risk or uncertainty associated for all outcomes generated.
The Monte Carlo Simulation estimated that the optimum combination of ISP investments would reduce the losses that would likely occur without the ISP by between 75 and 95 percent. The same analysis showed that an investment in Intrusion Detection did not reduce enough losses to justify its cost. This discovery represented a $30 million project cost avoidance for the VA.7
Products for project portfolio management
I have endeavored to show that Modern Portfolio Theory and a risk-based approach to IT investment are far from new. There is even US Federal legislation (Clinger-Cohen Act, 1996) that requires federal agencies to adopt an investment approach to IT. The notions of the Efficient Frontier, Imperfect Correlation, and Monte Carlo Simulation are not alien or new to many businesses and are increasingly applied to optimize project investments.
Given the relative popularity of the portfolio approach to project management, it will come as no surprise that tools based on these concepts are commercially available. Let's consider some of these portfolio tools, including IBM Rational Portfolio Manager, and how they are being used.
Schlumberger
Schlumberger, a leading oil and gas exploration company, applies software that generates and analyzes optimal portfolios of exploration projects (oil wells) using a genetic algorithm iteration method. The software supports models of complex geological scenarios and key performance indicators (KPIs), such as production, investments, cash flows, and geological chance of success. The company markets this proprietary software through its wholly owned software subsidiary, Merak.
Portfolio Decisions, Inc.
Portfolio Decisions states that it uses a combination of Monte Carlo Simulation and linear programming to gain insight into portfolio problems, such as optimizing risk-to-return ratio, minimizing volatility, achieving balance, and so on. Economic outputs for all the considered projects are loaded into the model, along with probabilities of their occurrence. The firm's goals are entered as constraints. Monte Carlo Simulation is used to generate a database of possible outcomes, and this database is optimized to arrive at a maximum value portfolio, a minimum risk portfolio, and a set of value/risk trade-off portfolios in between. The program builds portfolios by varying ownership interest percentages (including zero) and project timing within constraints set by the analyst.
Palisade Corporation
Palisade Corporation offers its @RISK product that models any risky situation in business, science, and engineering. In order to combine all the uncertainties in a modeling situation, @RISK uses a simulation technique that includes everything known about variables, including the full range of possible values and some measure of likelihood of occurrence for each of these. @RISK uses all this information, along with an Excel model, to analyze every possible outcome. This is the equivalent of running hundreds or thousands of "what-if" scenarios all at once.
IBM
IBM Rational Portfolio Manager is a highly scalable tool for project and portfolio management. While it does not incorporate algorithms to randomly generate portfolios, it does offer many advantages that financial investment tools do not. Apart from its project management features, its repository stores project data, such as costs, EV (Earned Value) performance data, financial metrics (such as NPV), and ROI, that a project organization can apply to make portfolio decisions. The Portfolio Dashboard -- with its Scorecard and Investment Maps, OLAP Pivots, and what-if feature -- supports the processes required to select and manage the right mix of assets for a portfolio.
Conclusion
Many software project organizations most likely have some form of informal portfolio management processes that have been woven over time into their strategic planning, budgeting, and IT governance processes. These portfolio processes help align projects with strategy and balance risk and return of different project investments. Some portfolio analysis may also be performed at the level of the Project Management Office.
It is equally likely that much of this work is carried out based on qualitative, even intuitive approaches that will not serve an organization that faces very complex problems. To manage situations of complexity, organizations may find that they can benefit from a quantitative, risk-based approach to managing their project investments.
There is ample literature and knowledge on modern portfolio concepts and risk-based approaches that software project managers can draw upon to enhance their management methods. I hope that this paper will point managers and others to the portfolio knowledge that may then help them calculate the best use of the assets that shareholders have placed in their care.
Notes
1 http://www.investopedia.com/terms/p/portfolio.asp
2 Available for purchase from Harvard Business Online at http://doi.contentdirections.com/mr/hbsp.jsp?doi=10.1225/81510
3 Freely available at http://www.gao.gov/special.pubs/ai94115.pdf
4 For the full whitepaper from which I have borrowed this graph, see http://www.oilfield.slb.com/media/services/software/valuerisk/portfolio-optimization.pdf
5 See http://random.mat.sbg.ac.at/others/
6 This paper can be found in full at http://www.cio.gov/archive/BPC_portfolio_final.pdf
7 The full report is titled "Lessons Learned on Information Technology Performance Management: Applying the Balanced Scorecard and Applied Information Economic to Federal Information Technology Initiatives" is available at http://www.cio.gov/documents/PM_Lessons_Learned_Final_Report.pdf.
This report was prepared by the Federal Chief Information Officers Council Best Practices Committee (Community of Practice for IT Performance Management).
About the author  | 
| | Patrick McKenna is a senior technical advisor with the IBM Rational Portfolio Manager team in Montreal, Canada. He designs user training, writes about project portfolio management, and stays up to date on portfolio theory and deployment approaches. Prior to IBM, he worked in consulting, training, and human resource development with inbound and outbound sales teams. For seven years as a member of various ISO technical committees, he contributed to the development of ISO 9000 and ISO 13485 international standards. He holds an M.S. in chemistry and an M.Ed. in education. |
Rate this page
| 
