Reducing Application Maintenance Costs

Maintenance requirements can vary significantly. Peaks can occur because of spikes in transaction volumes or spikes in business enhancement/support requests caused by a lack of system flexibility. These spikes increase incidents and user support requirements.

You are correct in your observation that Maintenance organizations “Hedge their bets” when it comes to maintenance. They deploy a fixed team of people who are pre-trained in the application so they can respond to high priority work quickly during these spikes. The size of the team is set to handle the spikes. As a result, they have excess capacity (and excess costs) when maintenance is not spiking.

Why does this happen?

1. Responding quickly to problems and high priority maintenance requires prior knowledge of the application. Development teams create specification documentation and user guides but they do not document the type of knowledge required to support and maintain applications. This knowledge is usually communicated by “word of mouth” over a long period of time so maintenance teams cannot rapidly adjust the available resources to respond to spikes.

2. Most incidents are the result of recurring problems. The support staff responds to the initial incident but they rarely fix the underlying cause to permanently eliminate the problem so the recurring problems contribute to these spikes in support. This type of continuous improvement should occur when maintenance is not spiking.

3. Systems are designed and built to require maintenance because adding user controlled parameters and robust data validation increases the development costs. These decisions increase future maintenance costs and impact reliability.

How do we reduce spikes in maintenance and reduce the total cost?

1. Fix recurring problems to reduce maintenance spikes and total maintenance costs.

2. Add functionality to increase flexibility with user-controlled parameters to reduce the need for enhancements and user support.

3. Document support knowledge and cross-train others so that people can multi-task across applications to balance spikes in maintenance. This improves utilization of staff and allows staff to be shared across applications so that Application Maintenance staff costs are reduced.

Does this work? I have managed Application Maintenance outsourcing engagements for more than 20 years and we routinely delivered the same or better levels of support while reducing staffing levels/costs by 30-50% using these recommendations.

In addition to these recommendations, development teams must avoid adding long-term maintenance requirements when they build applications by including user-controlled parameters to enhance flexibility, ensure adequate data validation, and mandate planning/testing for processing spikes.

IT Risk Management is more than Disaster Recovery Planning

Many IT executives create a Disaster Recovery Plan but is this all there is to risk management?    A risk is simply ”the Possibility of a problem or issue” in meeting IT’s responsibilities and commitments.  As a result, the first step in risk management is to clearly identify responsibilities and commitments.   IT operates and supports infrastructure but they are also responsible for operating and maintaining applications and consulting with the business to assist with planning and training.  Issues affecting application availability, reliability, and accuracy must be managed.  Finally, the failure to implement management processes for tracking commitments, measuring progress, and ensuring they are met also represent risks.  Successful risk management addresses issues with infrastructure, help desks, application support, project management, and service management.

Does the cost of your Applications represent an investment or waste?

Most people simply assume that applications are beneficial or we wouldn’t have them. As a result, they conclude that applications are investments.

An investment is an expenditure of capital in order to gain value. Value is a difficult concept because it can involve subjective criteria as well as objective criteria (cost). What is the “value” of operating an old application after the replacement application has been implemented? Does it provide access to historical data or was the retirement of the application delayed or forgotten? Is there an alternative to operating both applications?

Application Portfolio Management should answer these questions.  In order for this to occur, APM must span the entire life-cycle of an application from the decision to build or buy, operations and support, enhancement, and the eventual retirement of the application.   Application Rationalization is one of the APM activities where capabilities and benefits of the applications are assessed against the costs and risks in order to recommend long-term strategies (continue to operate, re-platform, replace, retire, etc.).  Without this type of periodic review, an organization cannot determine the benefits of their application portfolio and make appropriate strategic decisions.