Traditionally, project portfolio management (PPM) is targeted at directing the demand for requested projects that enable new business services and capabilities. While the management of this investment is critical, because it represents the most significant opportunity for business value, it typically only accounts for about 25% of the total IT budget.
The remaining 75% of the budget is consumed by operational activities, required to maintain existing IT assets that support operations. These operational activities come in a variety of flavors that include maintaining infrastructure, fielding help desk calls, performing bug fixes, etc.
While all of this operational demand should be organized, controlled, and managed within an overall portfolio management strategy, the operational demand I want to focus on in this article is effort required to maintain your business system software.
Software applications, like all IT assets, have their own unique life-cycle, from implementation, to upgrades, to retirement. (In one of my previous articles, De-Mystifying Portfolio Management, I list all the items that should be considered an IT asset and provide an overview on how portfolio management disciplines can be applied to manage each asset type.)
As I stated for all IT assets, a full life-cycle approach should be employed to manage software assets in an effort to deliver maximum business value from investments being made on the application.
Evaluating Your Portfolio
If you are familiar with the core concept of PPM then you’re well aware there are two fundamental components required to launch any PPM practice: (1) establishing a single repository encompassing all the assets that you want to manage (e.g., software) , and (2) having a non-biased and consistent approach to evaluating each asset and determining its disposition.
Once you determine that rationalizing your software portfolio is necessary and you have executive management’s support for such an effort, then I recommend the following six steps:
Understand Business Needs – Business needs are capabilities that must be provided by the system(s). These requirements are often expressed as business or operational activities that must be supported by the system. A good understanding of the business area’s work flow must be developed as part of the business needs definition activity.
Map to Your Technical Architectural Direction – Having a technical architectural blue print and direction is critical to successful software evaluation and understanding the technical architectural target is required to enable migration from one application to another.
As systems evolve, they must move towards the desired technical environment that best fits the organization and its skill set.
Legacy System and Application Portfolio Analysis – I like to define the borders of individual software portfolios by grouping the applications needed to satisfy the business needs of a specified business area.
Each of these applications can then be evaluated in a one-by-one fashion within the context of business value (support of the business needs) and technical quality (compliance to the target architecture). The evaluation approach should be consistent whether you’re using if for vendor purchased software or custom software.
Each application can be evaluated and charted using the following criteria:
| Ability to Support Business Capability |
Technical Quality |
Recommended Disposition |
| LOW | LOW | REPLACE |
| LOW | HIGH | REDESIGN |
| HIGH | HIGH | MAINTAIN |
| HIGH | LOW | RE-ENGINEER |