Skip to content

Analyzing your application portfolio from a cost perspective

October 10, 2008

Ongoing Cost-Benefit Analysis for Applications

Once a project is delivered, the resulting applications are essentially financial assets, whose performance in terms of costs and benefits will be monitored by the application manager

It is important at this stage to differentiate between the financial assets just described, and the underlying technology assets like hardware and software, which might sit in a configuration management database (CMDB) or an IT asset management (ITAM) system. The former is the visible end product that the business client sees and uses and from which she will derive business benefit. The latter is a means to that end, and is often invisible to the client. Which makes sense — after all, as important as these physical assets are in terms of what they do, as far as the client is concerned they are ultimately ‘part of the plumbing’. There is still an unfortunate tendency in many IT departments to view assets mainly from their traditional, ‘physical things’ perspective. Yes, you have to be able to manage and track these physical assets in order to manage your cost base and your service levels, but beyond that they have no intrinsic business value. However, order entry application XYZ which is supposed to handle a throughput of so many orders at a given unit cost — now that is an asset with intrinsic business value. An analogy is your car, which can be considered as having ‘business value’ to you. However, even though the wheels and engine components might be considered physical assets (not that you’d want to track them anyway), they wouldn’t figure on your radar screen when considering the ‘business value’ your car provides you.

Let’s now show via two examples how an application manager would track costs and benefits over time from the perspective of a financial asset.

Application 1

The first example shows how the cost components of Application 1 change over time:

  • During the first year product development costs were naturally high, but operations and infrastructure costs were relatively low because the first year was a pilot which focused on a limited number of users.

  • In year 2, both infrastructure and support costs increased significantly as the product was rolled out across multiple BUs.

  • In years 3 and 4, both product development and support (part of operations) costs decreased as processes stabilized and gradually became institutionalized.

  • In year 5, the acquisition of another company significantly increased the number of users of the application, which in addition needed to be enhanced to take into account the functional requirements of the new company. This resulted in a spike in total costs, which almost doubled compared to the previous year.

  • In year 6, the acquisition was fully absorbed and the application was once again stable, leading to a decision in year 7 to outsource it, resulting in lower costs over the final years.

On the benefits side, assuming that this application is supposed to deliver two key benefits, e.g. decreased unit costs per order and a shorter order cycle time, we can see constant improvement in each metric over the years. Eight years after this application has been introduced, unit costs have been halved (benefit 1) and order cycle time has decreased by a factor of three (benefit 2).

In many ways this represents the ideal application, in which total costs decrease over time, while application benefits increase. Note that this analysis assumes that the benefits are directly related to the performance of the application — in reality of course, you can’t always be sure to what extent benefit performance is directly linked to the IT application or to external factors. In addition, benefits are not always easy to fully quantify and translate into financial terms — e.g. how would you objectively translate decreased order cycle time into increased sales? This is one more argument in favour of operational metrics as opposed to purely financial metrics, simply because they stand a much better chance of objectively measuring application benefits.

Finally, depending on the accuracy of the costs and benefits, you could combine the two charts to show a financial ROI, but as we’ll see in the next post, there are reasons why you probably wouldn’t want to do this.

Application 2

In our second example, Application 2 we see an entirely different picture:

  • The project was delivered in December of year 1.

  • In year 2, instead of decreasing, or at least remaining stable, total costs actually increased, for a number of reasons. Firstly, poor infrastructure capacity planning and load testing during the project phase resulted in poor response times from day one, requiring a significant hardware upgrade (infrastructure cost component). Secondly, inadequate testing and training, due to budget restrictions during the last phase of the project, resulted in much higher support costs (operations component). Finally, a combination of bugs and missing functionality required a significant new release after only one year of operation (product development component).

  • Year 3 was in many ways a replay of the previous year, with costs once again increasing and another round of rework and corrections (product development component) to cope with yet more bugs, and the dawning realization that the original specifications did not really correspond to reality, and needed to be revisited.

  • By year 4, little had changed, and it became clear that the company had a problem application on its hands, with annual running costs (operations + infrastructure) having more than doubled since the start of the project, instead of decreasing or at least staying stable.

On the benefits side, assuming similar benefits as for application 1 above, but for a different product line, we can see that apart from a timid drop in year 2 for benefit 2, the performance has actually been negative, with unit costs and order cycle time either stagnating or even increasing.

In year 5, the decision was taken to phase out the application, with product development funding limited to urgent bug fixes for the last year of its existence.

We are therefore looking at a problem application whose costs steadily increase over time, with no corresponding benefits to show for the money spent — the exact opposite of the previous example. Which prompts the logical question ‘Why would any company spend such money over a period of five years for no obvious business benefits?’. The unfortunate answer is that since very few IT departments are capable of understanding their application cost base in this manner, and hardly any companies have people in their BUs who track applications benefits from an asset perspective, this type of analysis is simply not possible. So it’s not that companies wilfully throw good money after bad, it’s just that in the absence of objective cost and benefit monitoring at the application level, they simply don’t have the visibility for proper decision-making. So most of them simply carry on funding non-performing applications and keep their fingers crossed that the original business case still holds.

Note that effective benefits monitoring is essential when IT costs are transferred to the business via allocations or cross-charging: people have to know what they’re getting in return for their payments.

Finally, application-based asset management as described here might make a lot of sense, but the average company runs thousands of applications and you can’t have an asset manager for each and every one of them. In practice you would manage a group or a set of applications, rolled up at either a functional level (e.g. marketing, sales, customer service) or at a business process level (e.g. acquire new customers, manage existing customers, fulfil orders). This means that the average company should have between five and ten asset managers to manage applications across either the key functional areas or the key business processes.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: