Project Portfolio Management for Your Software
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 youre 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 managements 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 areas 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 youre 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|
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:
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. Its 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 email@example.com.