Using SpiraPlan for Application Portfolio Management

Application Portfolio Management

IT Application Portfolio Management (APM) is a practice that has emerged in mid to large-size information technology (IT) organizations since the mid-1990s.Application Portfolio Management attempts to use the lessons of financial portfolio management to justify and measure the financial benefits of each application in comparison to the costs of the application's maintenance and operations.

Why is Application Portfolio Management Important?

As mentioned above, the original concept of application portfolio management (APM) first emerged in the early 1990s, but its benefits really became apparent during the Y2K buildup. When organizations began preparing for Y2K remediation, they often discovered they had accumulated a large number of applications that were redundant, costly to maintain, and of little real business value. Moreover, the majority of applications were not cataloged in any logical, searchable fashion. As companies began to review their application portfolios, the benefits of having an ongoing process of doing so became apparent. The applications in most of these organizations were not cataloged in an easy and search-friendly manner. This meant that there was a need for reviewing the application portfolios. Also, by following APM, businesses can obtain a clearer idea of the value they could derive from their applications in a quantifiable way.

Configuring SpiraPlan for Application Portfolio Management

SpiraPlan provides a great platform for managing your portfolio of systems, software applications and other IT systems. This section discusses how you can setup a special product template for managing application portfolios:

We will be using the requirement artifact to store the various applications in our portfolio that we're managing. So the first step is to create custom properties to track the different attributes and characteristics of our applications, for example:

• Version information
• Release date
• End of life date
• Cost
• Supplier(s)
• Deployment architecture
• etc.

Some of these will be simple free text or numeric fields, but others like Supplier and/or Deployment type will be list based. You can use the custom lists feature to populate these lists:

The lists can be used for both single and multi-select values.

In the example above, we've created a master list of application suppliers (Microsoft, Adobe, etc.) and a master list of deployment architecture types (SaaS, On-Premise, etc.).

In addition to these basic customizations, you will probably want to customize the workflows of the following artifacts:

• Requirements workflow - similar to what was described for supplier management
• Incidents workflow - change requests to an application in the portfolio will need their own change management workflow

Using SpiraPlan for Application Portfolio Management

Requirements

Now that we've setup the templates appropriately, you can use the standard requirements list views to display and organize the list of applications in your portfolio. In this example, we have used the hierarchical requirements' view to categorize the products by type (design vs. office), with the different application grouped under their containing type. We have also displayed the custom properties: version, end of life, cost, supplier and deployment type in the grid:

If we wanted to more easily sort and filter the applications by a field such as priority or supplier, we could instead switch to the sortable grid view, which is more flexible for "slicing and dicing" the data:

Releases

In order to track the applications in terms of when they are deployed, upgraded and eventually retired, we recommend creating high level releases and phases in the Release Gantt chart view:

In this example, we've created top-level releases for each broad platform baseline, and then created phases for each infrastructure segment that the application will be part of. Another way to organize things would be to do it by year and quarter:

Tasks and Change Requests

Tracking changes and action items is really important when managing an application portfolio. For example, a task might be to simply upgrade an application to the latest version, or it might be to conduct an application assessment before making configuration changes or changing license tiers. The Tasks module in SpiraPlan lets you create tasks, associate them with the application (requirement) and then plan them against the defined release/phase milestones.

In addition, when there are change requests coming in from the business users, you can use the incident artifact to have a special change request workflow that tracks the inbound requests from the users.

The change requests will follow the defined change request workflow, with the ability for users to approve or reject the change request, add comments, and associate it with the various applications (requirements) using the Associations tab to determine the change impact:

You can then run reports to see the application impact of each change request, determine costs, and plan for the outcomes.

Risks

In addition to the requested changes from users, another key area that SpiraPlan can assist with, is identifying, tracking and mitigating any risks associated with the applications. In this fictitious example, we have logged a risk that some of our Excel macros will not work with the version of Excel in our portfolio.

Using the standard risk management process within SpiraPlan, you can identify the various application risks and then associate them with the applications (requirements) as well as develop mitigations and action plans (tasks) to address the risks.

Reporting and Documents

Once you have the data in SpiraPlan, the reporting system lets you analyze the application portfolio based on a variety of criteria, including: number of suppliers, application cost, license type, deployment type, total cost of ownership (TCO). You can run an Excel summary report to get the data in various data grids:

The generated Excel report can be displayed directly in SpiraPlan, or for added benefit, you can publish the report directly into the SpiraPlan documents center:

In this example, you would have a simple application portfolio report that lets you slice and dice the data as needed:

Summary

In this article, we have seen how we can manage a portfolio of applications as requirements, track them against timelines using the releases module, respond to change requests via. the incidents module, assign tasks and risks to the applications, and generate reports to make it easier to analyze the applications in the portfolio.