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.