Project Portfolio Management for Your Software

By Jeff Monteforte

(Back to article)

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

Define the Software Modernization Strategy - After the applications portfolio has been completely evaluated each replace, redesign, and re-engineer project needs to be prioritized and sequenced, such that the envisioned business and technical environments are constructed. These initiatives are then placed on a high-level timeline to illustrate sequencing, interdependence and estimated delivery time frames.

Estimates Resources - Once the systems evolution plan and migration path is determined the resources required to execute the plan must be estimated. These estimates, like all estimates in this high-level plan, are high-level, order-of-magnitude approximations.

Resource estimates should be made in four primary categories:

  • Internal IT human resources;
  • External IT human resources;
  • Business unit human resources; and
  • Capital expenditures (i.e., hardware & software).
  • An important item to emphasize is that all estimates (e.g., human resource and capital) need to be presented as simple financial approximations for budgetary planning purposes.

    An enormous mistake I consistently witness is the desire for IT personnel to provide estimates that imply a certain degree of exactness, which is impossible to approximate at this early stage.

    For example, I see human resource estimates in the form of 7.125 FTEs and capital expenses represented as $25,927.63. The presence of decimals and fractions send the message of “thorough analysis” and “well-though-out estimates” to business executives. This form of estimating provides no added value at this phase of planning, but makes revising the estimates after true analysis a difficult and painful task.

    Construct “Evolution Program” and Strategy Document - A final step in the systems evolution planning process is to bring all the pieces of information together into a structured strategy document that describes a comprehensive execution approach that manages all the individually identified projects as a coordinated program.

    Keep in mind that beginning a software portfolio management practice is similar to establishing any kind of portfolio management discipline. It’s a 20% effort working out the nuts and bolts methodology and 80% managing the perception and organization change.

    Jeff Monteforte is president of Exential, a Cleveland, Ohio-based information strategy consulting firm, which specializes in IT governance, information security and business intelligence solutions. He can be reached at jmonteforte@exentialonline.com.