At this point, it’s fair to say that most organizations will be engaging in application portfolio management. The basics of application portfolio management are fairly well known: define a standard catalog of applications that are managed by IT, and establish key parameters such as their annual spend, coupled with scoring applications on some basic criteria.
A common set might be business fit, technical fit, and risk, each on a scale of 1-5, or high/medium/low. The precise scale is less important, but it must be easy to identify which values are more desirable than others.
All well and good, but asking application owners to rate each of their applications from, say, 0 to 5 for business fit, technical fit and risk is a little unfair, as it demands subjective judgements. So in this and the next three articles, I’m going to define an approach to help with estimating such values.
The essence of our approach is to define specific factors that feed into the scores we estimate, and then provide a scale to estimate each one. We then average the scores to provide a more guided value for each metric.
So what are the components of our business fit score?
1. Support for business operations
Being brutally honest, this is the most fundamental component of business fit – if the application does not support the business, then what use is it? So let's see how we can measure this. Applications are about automation – so to what extent does the application automate business processes?
We can use the percentage of the business processes covered by the application that are automated by it as a measure of how well the application supports those processes.
2. Criticality
A second measure of how well the application supports the business is: how badly does the business depend on the application? Is downtime greeted with a shrug or an irate call from a vice president somewhere?
Here it’s a somewhat arbitrary measure – going from “Who cares?” to “GET THAT WORKING AND FIRE THE CIO!” Best to ask beforehand as to what reaction downtime will cause.
3. Flexibility
One of the classic complaints by the business about IT is the ability to accommodate changes.
So: how easily can this application accommodate changes to its operation? Are we talking two weeks or two years?
4. Integration capabilities
We just talked about how important accommodating changes within an application is for supporting the business. But just as important is the ability to integrate the application with other applications.
Does a change require a day of in-house time or an army of Accenture consultants.
5. Ease of use
It seems like stating the obvious, but just how confusing (or, hopefully, not) is this application? In 'Code Complete', Steve McConnell makes a convincing case that poor UI design caused a US warship to shoot down an Iranian passenger jet in 1986. That's an extreme example to make a point, but confusing user interfaces make it slower for staff to learn new tasks and lead to errors.
How guilty is this application?
6. Response times
Last of all, how much time do business users spend simply waiting for the application to respond to them? 5 minutes a day multiplied by 240 days a year multiplied by 100 users works out to 250 days of lost time per year across the enterprise.
The math can be surprising – how much time does the application cause to leak from the organization?
Last Word
In order for the scores to be treated consistently, they should all be rated on the same scale, e.g. 0 to 5. Of course, there will always be arguments on these ratings but breaking down the components of business fit makes the discussion detailed enough to enable a much more sensible discussion.