Product Portfolio Management

Product Portfolio
If you want to manage a portfolio of software products, it is necessary to understand the organizational goals that are met by those software products. The product portfolio is a vehicle for understanding the ongoing investment in development or deployment of software assets. It requires an ability to measure the value of software assets separate from their cost (rarely done in industry today), and an ability to measure the cost of ongoing support and maintenance of software product.

Software Asset Valuation
We also have to deal with the valuation of software. Not from a capitalization perspective, but from a business value perspective. The project view is ROI – return on investment. The product view is cost to replace the same business value. But here is the deal, in a software product portfolio, once implemented, the notional value is 0. I cannot sell the software, separately from the lines of business using it. So Return on investment, pragmatically, is calculated by determining when (how long) will we realize enough value from the software to offset the expense of investment. Since I can capitalize the investment, and depreciate the asset, I can offset the investment over time, against depreciation expense.

Here is the catch:
Even though the capital expenditure is completely depreciated, so in effect the software investment is now sunk cost in infrastructure (like a machine) it is still producing business value. This Business value is usually day to day cost savings in some form or fashion, that will need to be replaced, to maintain the lines of business that are using it. Think about that value as follows:

Now, remember, that since returns are calculated as a “rate”, use the cost of replacement as a denominator. Why not use the total investment in the software, rather instead of the cost of replacement? Because you are managing a portfolio. You need the “current” price (cost of replacement) as the denominator of the return, not your actual cost or undepreciated cost. As you look to make decisions which change the return, you can see the impact on the value of the product.

Making Decisions
There is some point, when the cost of increasing the value of the software product (in a desired way) or the cost of maintaining the software product as is, becomes so expensive that it costs less to replace the product, then you make that decision. Sometimes this happens because of infrastructure (product is based on old infrastructure and cost to move to current infrastructure is high). Sometimes it happens because over time, business needs change faster than the funding for software change to accomodate those needs – this decreases the value of the current software (the return has been decreased). Other times it happens because software is built without sufficient thought for sustainability, and the cost of maintenance and enhancement is greater than the cost of replacement. The key to making these decisions is having a basis for valuing the current existing software. Without that information, you are merely deciding based on whim and whether funding is available. If you want to make a case for funding either enhancement or replacement, you have to understand how to value the assets in your portfolio.

The decision making is not dissimilar to the cost of investing in corporate real estate. If I own a 100000 square foot warehouse, and I have to pay five dollars per square foot per year in maintenance, and I need 300000 square feet of warehouse space – I have to decide whether to repace the existing facility or to build additional facilities. The cost of construction and the cost of maintenance as well as the market value of the property I already own are factors in that decision. The cost of upcoming maintenance on existing facility, or proposed tax increases in the community, may also influence my decision. If I need to replace a roof, or rebuild freight elevators – it may be better to raise the building and build a bigger one on the same location, etc.

Focused, Balanced, or Diversified
Investment portfolios can be said to be balanced, focused or diversified – meaning they have different strategies for aligning software assets to meet business goals. If we have a portfolio of business goals, then we could “structure” a portfolio of software assets to offset. These offsetting portfolios could be used to discern gaps in our ability to meet key business goals, and therfore could be used to direct investment. How these offsetting portfolios are organized would be focused (emphasizing a few strategic business goals), balanced (expressing how we are emphasizing strategic or tactical goals) or diversified (emphasizing a wholistic view of all business goals.

Conclusion
For the last 10 years, we have focused on the cost and risk of software construction – especially from a project orientation – in ways that mostly ignore the ongoing life of the software as an asset, that we forget that the software we already own has some value. We have project management organizations (PMO’s) and project portfolio management (PPM) as topics of conversation – but all they really do is manage the spend, and the transactional aspect of software construction. The is no discipline in the industry for software asset management or software product portfolio management. We have product managers, but that discipline appears to be concerned with ensuring that the projects deliver the right value, so even the product management discipline we have has become infected with our fetish around project management. If the software industry is to grow and mature, we need to get better at understanding what to do with our work product, and how that work product interacts with the real world entities that it equips. Product portfolio management is one way to think about this.