Research

Publication Date: 16 August 2010 ID Number: G00205509

How CIOs Can Maximize Value From Application

Maintenance Teams
Andy Kyte

Application maintenance teams are an increasingly important contributor to service

delivery and user satisfaction, but they are also a growing component of the IT budget.
CIOs will find that paying attention to application maintenance teams delivers good
rewards through lower costs and targeted results.

Key Findings
There are five key maintenance functions: corrective, adaptive, preventive, perfective
and minor enhancements.

Implementing regular structured reporting and reviews of application maintenance

activities will enable the CIO to set targets for performance improvements that will lower
costs while improving quality and user satisfaction.

Regular reviews of staff members on application maintenance teams will give early
indications of potential risks due to team demographics.

Once the CIO has instituted regular reporting and performance monitoring for
application maintenance, he or she is in a much better position to evaluate the options in
application maintenance outsourcing.

Recommendations
Institute regular structured reporting and review of application maintenance.
Set targets for application maintenance that will reduce costs, improve quality and raise
user satisfaction.
Ensure strict control of minor enhancements.

© 2010 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its
affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior written permission. The
information contained in this publication has been obtained from sources believed to be reliable. Gartner disclaims all
warranties as to the accuracy, completeness or adequacy of such information and shall have no liability for errors,
omissions or inadequacies in such information. This publication consists of the opinions of Gartner's research organization
and should not be construed as statements of fact. The opinions expressed herein are subject to change without notice.
Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or
services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may
include firms and funds that have financial interests in entities covered in Gartner research. Gartner's Board of Directors
may include senior managers of these firms or funds. Gartner research is produced independently by its research
organization without input or influence from these firms, funds or their managers. For further information on the
independence and integrity of Gartner research, see "Guiding Principles on Independence and Objectivity" on its website,
http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp
ANALYSIS
"Hey, boss. Is there any chance of a transfer to the application maintenance team? All these
development projects are just so boring." Not a very likely starting point for a conversation, is it?
Of all the various outposts of the IT organization, application maintenance has to be one of the
least regarded. However, for any organization that has undertaken application development in the
past, and for many that have implemented packaged systems with a large amount of
customization, the application maintenance budget is a sizeable and growing component of the IT
budget. As the CIO and the IT management team get to grips with the challenges of application
overhaul, the application maintenance team will play an increasingly important role in managing
the bloated application portfolio.
All too often, maintenance is seen as a necessary evil, with little in the way of management
objectives other than to keep a lid on costs and avoid problems that would affect business
operations. With the rise in cost of the application maintenance function, the CIO should review
the objectives and scope to maximize return. The starting point for such a review is getting a clear
understanding of the five key functions of applications maintenance:
1. Corrective maintenance. This is also known as "bug fixing." As errors are identified in
the application, they will pass through various support gatekeepers until they land with
the maintenance team. Some of this corrective maintenance work is the laborious and
seemingly never-ending task of working through a stack of medium- and low-priority
errors, often a truly Sisyphean task. By contrast, some corrective maintenance work is
real SWAT team stuff — trying to recover a live application to a viable state in the full
glare of spotlights shone by everyone from the CEO down.
2. Adaptive maintenance. The application runs in a complex environment. It sits on a
stack consisting of hardware, netware and infrastructure software, such as OSs,
databases, application servers, compilers, etc. This environment is subject to normal life
cycle changes, with components of the environment being upgraded or replaced from
time to time. Adaptive maintenance is the set of tasks associated with migrating the
application to run in this modified stack.
3. Preventive maintenance. All applications have errors. For each application, a decision
must be made as to whether to wait for the users to be impacted by the errors or to
undertake forensic investigation of the source code to spot errors before they have a
negative impact on the users. This activity is most useful in the early part of an
application's life cycle, when there will be more undetected errors. Because one of the
key factors in errors in applications is the widely varying capabilities of individual
programmers, one of the highest-value techniques in preventive maintenance is to use
root cause analysis in the corrective maintenance function, to identify those
programmers who seem to have produced a disproportionate number of errors and to
concentrate on the code produced by these individuals.
4. Perfective maintenance. An application delivers business functionality in the context of
an application architecture and design that is intended to achieve certain desired
characteristics. These characteristics are defined by the nonfunctional requirements,
and include attributes such as efficiency, performance, maintainability, etc. Now, in the
same way that there can be functional errors, where the application does not perform to
the functional requirements, there can also be nonfunctional errors, where the
application fails to achieve specified nonfunctional requirements. For example, there
could be a requirement for the application to achieve a specified average response time.
If the application fails to achieve the desired performance, and the problem is identified
as being in the way the application was written (rather than a simple lack of compute

Publication Date: 16 August 2010/ID Number: G00205509 Page 2 of 6

© 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
 resources in the infrastructure), then a perfective maintenance activity would be needed
to address this deficiency. Note, too, that nonfunctional requirements can change over
the life of an application, in which case the retrofitting of the new requirements would be
a task for perfective maintenance. For example, the application may have been built to
run in English only, but international expansion now means that it needs to be able to be
used in many languages.
5. Minor enhancements. Strictly speaking, minor enhancements are development project
tasks, not maintenance tasks. However, for certain types of minor enhancements, the
maintenance team is the most cost-effective delivery mechanism. There is a danger that
minor enhancements can become the primary work activity within a maintenance team,
because they often give a greater sense of satisfaction to the programmer than the more
mundane bug fixing.
Although these are the five key application maintenance functions, it is an entirely separate
question as to whether any specific maintenance team should be allocated all these functions for
any specific application. For example, under some circumstances, it makes sense to allocate
adaptive maintenance to a project team in the development organization.
So, how can the CIO ensure that the organization gets maximum value from the application
maintenance investment?
Put maintenance on the CIO agenda. The maintenance team often feel undervalued
and ignored, only ever coming to the attention of management when something goes
wrong. The CIO should look at the proportion of the IT budget that is being consumed by
maintenance, then look at the proportion of the CIO diary that is dedicated to the activity.
For many CIOs with more than 15% of the total IT budget spent in application
maintenance, asking for one hour a month to read reports and one hour a month to chair
a review meeting does not seem like an excessive time commitment.
Implement standard reporting for application maintenance activities. Most
application maintenance teams are responsible for a number of applications, meaning
that a lot of valuable detail is obscured if the team only reports headline activity. For
each significant application under maintenance, there should be a line in a monthly
report that shows the amount of time spent on each of the five maintenance tasks
identified above. Of course, it is necessary to strike a balance between the value of
transparent reporting and the overwhelming bureaucracy of a time sheet culture, but
even if the time allocations reported are only estimates, the standard report will allow the
CIO and the IT management team to get a feel for what is going on, and start to direct
activities in a way that supports the broad IT objectives.
Regularly set and review targets for maintenance activities. The challenge when
setting targets for a maintenance team is to get the granularity correct. Too high a level
of granularity (e.g., "all Priority 1 errors cleared within 24 hours") means that little
valuable information can be derived from monitoring performance against targets, but
too low a level of granularity leads to a lot of overhead in collecting the data. In
establishing a target-driven regime for maintenance, consideration should be given to
the desired outcomes, which are generally (a) reduced cost, (b) improved quality or (c)
improved user satisfaction. The CIO should use the knowledge gained through the
standard reporting mechanisms (discussed above) to identify specific targets for
maintenance focus where achievements of those targets will deliver improvements
against one or more of these domains. For more investigation of target setting for
maintenance, see "Are You Spending Too Much on AD Maintenance?"

Publication Date: 16 August 2010/ID Number: G00205509 Page 3 of 6

© 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
 Implement planning for maintenance activities. At first sight, the concept of
"planning" seems to be out of place in a maintenance team. After all, the team is not in
control of the rate at which errors are identified, so how can it plan? However, look at the
five key functions of application maintenance listed above. Only one of them —
corrective maintenance — is subject to random demand fluctuations. The other four
functions are not event-driven. They are selected as a result of decisions concerning the
life cycle management of the application. For example, two applications could have a
high error rate. One of them is a core application intended to support the business for at
least the next 10 years; here, there should be a plan to invest in preventive
maintenance. The other application is intended as a temporary solution with a short life
span; here, it would not normally be appropriate to invest in preventive maintenance.
Ensure integration between maintenance plans and development plans.
Applications under maintenance are also likely to have development projects, while new
development projects will transfer to maintenance at some point. All too often, there is a
lack of synchronization between the project team and the maintenance team, resulting in
contention for access to source code, and missed opportunities for synergy in testing
and release. However, by far the most common problem in the interface between
development projects and application maintenance is the lack of maintenance presence
in the development project's requirements planning and quality assurance processes,
especially the lack of maintenance acceptance testing. This leads to the well-worn cliche
of development "throwing the application over the wall" to the maintenance team — and
the development team being feted as heroes for completion of the project, while the
maintenance team gets the blame for errors in the application. This traditional model
serves nobody well, but time after time, we see development teams taking short cuts to
achieve timely delivery, followed by years of complaints about the maintenance team. If
the development team must cut corners, then so be it, but it should be in the context of a
holistic plan in which the maintenance team is given adequate budget to run perfective
and preventive maintenance to solve the problems caused in development. For further
details of the relationship between development and maintenance, see "How to
Determine When to Split Projects and Maintenance."

Exercise strict control over minor enhancements. There are some immutable laws.
Dogs have fleas, and applications have backlogs of enhancement requests. There is an
unfortunate tendency for some application maintenance teams to see the enhancement
backlog as a personal challenge — their own version of Mount Everest. This results in a
culture where there is an expectation from users and maintenance programmers that
everything on the list will surely eventually get done, so users keep on requesting
enhancements and maintenance programmers keep on working on them (see
"Managing the Unrelenting Demand for Application Work"). It is true that many
enhancements will deliver great business value, but it is equally true that some
enhancements will not deliver value commensurate with their costs. There is also the
question of the most effective mechanism for implementing enhancements. Some
should properly be delivered on the "when code open" principle, meaning that if a
program needs to be edited because of a bug, then the enhancement can be done at
the same time. Other enhancement requests could be best-served by being added to a
proposed development project, rather than being worked on piecemeal by a
maintenance team (see "Determining When a Project Is Really a Project"). In general,
the principles of investment management that are traditionally applied to the big
development proposals — the business case, design plan, estimating, review and
approval — should have a lightweight instantiation in the maintenance management
team.

Publication Date: 16 August 2010/ID Number: G00205509 Page 4 of 6

© 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
 Ensure regular structured staff reviews for maintenance teams. The single most
important factor driving productivity in application maintenance is the years of
experience with specific applications among those on the maintenance team.
Productivity is not greatly related to years of experience in a particular programming
language (although that helps); rather, it is driven by understanding what the application
does, how it does it, why it does it like that, where to find good test data and protocols
for adding error messages or changing the database structure, and a host of other
points of knowledge that can only be learned through experience. The demographics of
many maintenance teams is becoming a source of concern, as the best and most
productive programmers are approaching retirement. The CIO needs to have forward
information about this, to develop the options for dealing with the loss of key staff and
the subsequent drop in productivity and quality of work. Flexible HR policies can go a
long way toward mitigating this risk, through part-time work, flexible work or work from
home; however, to take advantage of these possibilities, the CIO would need to start
discussions early in the cycle with the corporate HR function and with the affected
individuals.

Market test the internal maintenance team against outsourced options. Application
maintenance outsourcing is a growing area of IT services, with practically all Tier 1 and
Tier 2 service providers actively engaged in this market and aggressively positioning
their capabilities as a less expensive option than the internal team. The challenge for a
CIO is often that there is insufficient clarity about exactly what the current maintenance
team does to appreciate the difference between an outsourcing proposal and the
internal service. By instituting regular reporting, target setting, planning and reviews, the
CIO gains a much more detailed awareness of this critical area, and is in a much better
position to judge which applications might benefit from application maintenance
outsourcing and what the parameters of such a service would need to be.

Publication Date: 16 August 2010/ID Number: G00205509 Page 5 of 6

© 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
REGIONAL HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
U.S.A.
+1 203 964 0096

European Headquarters
Tamesis
The Glanty
Egham
Surrey, TW20 9AW
UNITED KINGDOM
+44 1784 431611

Asia/Pacific Headquarters
Gartner Australasia Pty. Ltd.
Level 9, 141 Walker Street
North Sydney
New South Wales 2060
AUSTRALIA
+61 2 9459 4600

Japan Headquarters
Gartner Japan Ltd.
Aobadai Hills, 6F
7-7, Aobadai, 4-chome
Meguro-ku, Tokyo 153-0042
JAPAN
+81 3 3481 3670

Latin America Headquarters

Gartner do Brazil
Av. das Nações Unidas, 12551
9° andar—World Trade Center
04578-903—São Paulo SP
BRAZIL
+55 11 3443 1509

Publication Date: 16 August 2010/ID Number: G00205509 Page 6 of 6

© 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.