Best practices in software maintenance projects

(Prof. Sanjay Mohapatra, Xavier Institute of Management)

Abstract
Maintenance of software projects is an important phase in software engineering. However,
there are many challenges associated during this maintenance phase, including technical and
managerial. In order to reduce the cost of maintaining software project, many such projects are
being outsourced to low cost development countries like India, Philippines, Russia or China. This
paper talks about decision parameters for outsourcing maintenance projects. However,
outsourced maintenance projects have their own issues and challenges such as poor domain
knowledge, lack of understanding of application & technological knowledge and managerial
issues such as lack of motivation, attrition. To find solution to these issues, the research
conducted study in CMM level 5 organizations and based on case studies, developed an
approach for addressing these issues and challenges successfully. The best practices so
identified (such as training the trainer, process oriented systematic approach, developing a test
strategy and involving end users during execution) can be adopted in other organizations as
well. It was observed that the best practices improved productivity while reducing defects in the
deliverables.

Key Words: Software Engineering, Software Maintenance, Outsourcing, Software testing,

Software development

Introduction
An organisation’s functional strategy and outsourcing strategy need to be fully aligned to the
overall business strategy. Both the functional strategy and corporate sourcing strategy will be
used to drive an aligned and effective functional outsourcing outcome. The functional sourcing
strategy will be implemented through lifecycle planning and detailed phase-by-phase activity
planning - this will be carried out on a cross functional basis if appropriate. Traditionally, the
motivation for outsourcing was to cut costs. However, today the decision is influenced by more
strategic factors. To be competitive, organisations need to drive innovation, enable growth and
increase flexibility. Outsourcing activities can help organisations become more flexible and
adaptive and react faster to changing markets. Before considering outsourcing options, an
organization needs to ensure such a strategy aligns with the overarching business strategy. For
example, organisations with an aggressive growth strategy may need a flexible sourcing option
that can scale as the business grows. Those companies that do not carefully test alignment may
find themselves incurring new costs, frustrating customers and losing market share. Sourcing
decisions are often made tactically and in isolation from long-term business strategy.
Organisations should establish a sourcing strategy as an element of wider business strategy. This
provides a frame against which tactical sourcing decisions can be made.

Outsourced software maintenance is the last phase in the software life cycle process. Software
maintenance in software engineering is defined as the modification of a software product after
delivery to correct faults, to improve performance or other attributes, or to adapt the product
to a modified environment (ISO14764). The IEEE/EIA 12207 standard for software life cycle
processes describes the software maintenance as the process of a software product undergoing
modification to code and associated documentation due to a problem or the need for
improvement. The objective is to modify the existing software product while preserving its
integrity.

Software maintenance or sustenance, maintains or sustains the software product throughout its
operational cycle. Modification requests are logged and tracked throughout. The impact of
proposed modification requests is determined, accordingly code and other artefacts are
modified, testing is performed, and finally a new point version (sometimes also called as patch)
of the software product is released.

A common perception of maintenance release is that it is merely about fixing bugs. However,
studies and surveys have shown that the majority of the maintenance effort is used for non-
corrective actions (Pigosky, 1997) which are merely about explaining how a particular
functionality or a feature works in the software. Further, to add to this perception, most of the
times users submit a bug or a problem which are in reality, functionality enhancements to the
system. Boehm (1976) states that software maintenance ensures that the present version of
the software works as intended while the defects and bgs found in the applications are attended
to. Mohapatra (2009), in his book titled “Software Project Management”, defines maintenance
as a phase in software life cycle that corrects any fault that has been found while executing the
present software. Lientz et. al (1980) states that maintenance is the activity that keeps
operational computer systems aligned with end user requirements. As per him during
maintenance activities data processing activities are not affected at all. Also needs of all other
stakeholders are taken care of while maintenance of software is being carried out. Swanson
(1976) moves toward a wider view of maintenance in his definition: "Systems maintenance is
the activity associated with keeping operational computer systems continuously in tune with
the requirements of users, data processing operations, associated clerical functions, and
external demands from government and other agencies".

The market for outsourcing services has changed dramatically in recent years. What was an
emerging phenomenon with great potential is now a natural element of corporate services. The
value proposition and measures of success for outsourcing operations is evolving. Leading
organisations look to harness value beyond cost reduction through consolidation, automation,
and labour arbitrage to more commercial benefits including accessing and building capability,
scalability and flexibility to support business strategy. Today, technological advances, together
with trends in privatisation, globalisation and deregulation, are encouraging the emergence of
alternatives to traditional business models. Organisations employ a broad range of service
delivery models and techniques, including outsourcing, selective and hybrid models for core and
support functions. The scope of activities within an organisation’s value chain that can be
performed by a vendor (outsourced vendor) has grown as we continue to see new types of
services being handled remotely and across borders. In this context, it is important to identify
the issues and challenges that have emerged in the recent past. This research, has attempted to
identify these emerging challenges and find the practices that have helped in overcoming these
issues.

Key Issues with off-shored software maintenance projects

IEEE/EIA 12207 identifies the primary activities of software maintenance as: problem and
modification analysis; process implementation; modification implementation; maintenance
review/acceptance; migration; and retirement.Practically, Software Maintenance project
process consists of following phases as shown in the figure 1:
a. Modification request (Entry)
b. Classification of Requests (Tasks)
c. Impact Analysis (Tasks)
d. Implementation (Tasks)
e. Regression Testing and (Verification)
f. Release (Exit)

Figure 1: Software Maintenance Life Cycle

However, there are number of issues related to software maintenance project management.
Edwards (1980) through his research reports that there are there are number of factors that
affect maintenance project management. To be successful in project management in
maintenance projects, not only technical but also behavioural aspects need to be addressed. He
reports that the maintenance projects should take care of user needs well so as to consist of
amending the information provided to satisfy changing needs of end-users, removing
redundant information processing, and encouraging usage of information perceived as
underutilized by the users Edwards notes that the organizations in which the maintenance
was successful, end-user needs were satisfied, and the project team worked in a cohesive
manner. The project resources clearly devoted to maintenance of user needs thus satisfying
project goals The team also had a defined communication channels, and had allocation of
responsibility to improve accountability.

Arthur (1983) and Gopal et. al. (2003) classified issues related to project management in
maintenance projects into technology related, people related, and organization (management)
related. Martin(1983), Mathew (2006) and Hazel (2006), in separate studies, classified the
features into management, organizational structure, methodology, software, and hardware.
Features such as performance evaluation system and training program are listed under
"management." End-user programming, programming assistant, independent test group, etc.,
are categorized under "organizational structure." Features including prototyping, structured
design and analysis, and structured programming are under "methodology." Such features
as database management system, data dictionary, and report generator are listed under
"software." Finally, online developmental environment, and similar features are classified
under "hardware."

The National Bureau of Standards (1984), has provided guidelines for improving project
management aspects in software maintenance. The guidelines are under three general
categories: controlling quality in software maintenance, and improving productivity in
software maintenance. Under “improving productivity in software maintenance projects factors
such as job rotation, and keeping the staff well trained, etc., are listed. Under “quality
control”, factors such as following coding conventions or standards, usage of structured and
modular programming, effective documentation, etc., are mentioned.

Donahue (1980) and Ewers et. al (1981) feel that training, effective resource allocation and
usage of tools and coding standards will improve effectiveness of management of software
maintenance projects. As per these researchers key issues related to outsourced maintenance
projects are because of these projects are intellectually very difficult (because the team
member has to be knowledgeable both in technology and domain), lack of clarity as necessary
information related to complexity of bugs reported are not available, lack of proper
documentation during development phase which makes it difficult to asses the impact of
system failures. After outsourcing, there is a lack of understanding of post-contract processes
between vendor and organization that has outsourced its processes. The results are that
services aren’t performed to the expectation levels, implementation activities get delayed and
there is frustration among stakeholders. Sometimes, the entire schedule for achieving expected
business benefits are delayed. There are situations when communication protocol is not well
designed or understood. This makes it difficult to identify the person who should be contacted
in case of escalation of an issue. In addition, lack of well defined service level agreement (SLA)
leads to mismatch of expectations among customers and vendors. This becomes complicated if
it leads to litigation later on.

After signing the initial contract, both the client and service provider have multiple team
members who are trying to manage the initial implementation activities and ongoing
operations. In the initial stage, when employees from both customers and vendors are in the
learning process, there could be communication gaps. These gaps can lead to serious issues
such as job security, attrition and legal issues.

With many outsourcing implementations, there is an outright lack of a defined governance

team that would monitor and control the progress of outsourced activities. This causes issues in
implementation because there is no one with effective monitoring parameters for checking
periodic progress of outsourced team. Customers expect that since they are outsourcing the
work, the vendor will take care of everything and the client can “wash its hands” of ongoing
management responsibilities, resulting in a lack of governance staff. In addition, the governance
team may not have the right skills required for the governance roles.

Outsourcing creates uncertainty for existing employees and contractors who provide services to
the customer. The uncertainty can cause delay in delivery of the deliverables. Both customers
and vendors face this problem and strategies and policies need to be defined as a proactive
measure. There could also be issues with culture clashes between a customer and vendor work
culture. The mismatch can be at two levels, the customer and vendor may have different norms
in terms of speed, style, decision making and organizational structure. Another aspect of
potential corporate culture clash is that outsourcing represents a commercial relationship
between two separate entities. Sometimes both organizations can take extreme, inflexible
positions that serve to create tension or distrust. In addition, national/regional culture,
language and lack of understanding of verbal, non-verbal and written communications can be
problematic. Also, expectations regarding the level of open debate, acknowledgement of
potential problems, and willingness to veer from the defined process in order to complete work
may vary between regions and nationalities.

Therefore, as is evident from literature survey, issues and challenges faced during project
execution at offshore have well been studied. But the issues and challenges faced by a vendor is
limited and has not been discussed in details. Even though it can be argued that there could be
some overlap between issues and challenges at project and vendor organization levels, still a
detailed study only from vendor perspective have not been reported. We also found that
vendor organizations face different problems for outsourced maintenance projects and the
magnitude as well a nature of these challenge vary from that of project level issues and
challenges. These problems are related to clear definition of service level agreements for solving
the reported problems and mismatch of expectations from customer and service provider.

In summary, outsourced software maintenance projects provide unique technical and

management challenges. One of the challenges is to identify resources who can work on
software containing 500K lines of code that the software engineer did not develop. Planning for
a future release, while coding the next maintenance release and also sending out emergency
patches for the current release to the customers makes the entire process challenging. The main
challenges in software maintenance projects are:
Limited Knowledge
How quickly a software engineer can understand the software application and make a change
or a correction in software which he or she did not develop. Research indicates that nearly 40%
to 60% of the effort is spent on understanding the software to be modified
Testing
How much to test? The cost of full testing on a major piece of software can be expensive in
terms of time and money. Regression testing and selective retesting of a software component to
verify that the modifications have not caused unintended effects is very important in
maintenance projects. Many times, it is challenging to coordinate tests on testbeds when
different members of the maintenance team are working on different problems at the same
time. Hence automation testing plays an important role for maintenance release projects as it
can reduce the time of the entire lifecycle by running tests 24/7 basis.

Organization Structure
The maintenance team (once software is operational in the field) and the team that developed
the software are not necessarily same. The decision of having separate software maintenance
function team or not depends on priorities and process within the software engineering
organizations. What is important is the delegation or assignment of the maintenance
responsibility to a single group or person, regardless of the organization's structure. One of the
challenges in maintenance projects is to attract and keep software engineers. Maintenance is
often not viewed as glamorous work. As a result, software maintenance personnel are
frequently viewed as second-class citizens and morale therefore suffers. Hence, frequent
movement of these engineers to different projects within the organization keeps the attrition
low

Off-shoring
Outsourcing is a major industry. Many large enterprises are outsourcing entire portfolio of
software systems, including software maintenance. To reduce the risk, often the outsourcing
option is selected for less mission-critical software product. The challenge for the outsourcers is
to determine the scope of the maintenance services required, coming up with Service Level
Agreement(SLA), outsourcer adhering to the process and objective of the organization and
smooth transitioning of the work to the outsourcer.

The contribution of this study is in identifying key issues and challenges faced by a vendor
organization while executing software projects. Different issues and challenges have been
studied and based on case studies, an approach has been discussed to tackle these issues and
challenges at organization level.
Research Objective
Available literature pointed to different issues and challenges that outsourced maintenance
projects have to face. The issues have been discussed in the previous section. However, the
existing literature does not discuss these issues and challenges at vendor organization level and
no solutions to these issues have been elaborated. For example, literature explains the issue
lack of motivation of team members. But how to increase motivation level has not been
proposed. Job rotation can be one way of dealing with this issue; but in practice how do
organizations handle this issue has not been dealt with. Same are the cases with knowledge,
lack of testing time provided in the testing cycle, organization structure. The researchers used
this gap in the literature to study the solutions as practiced by different organizations and come
up with a framework that can be practiced and repeated across companies. Hence, the research
objective was to propose a solution framework for carrying out successful outsourced
maintenance projects in the changing business dynamics.

Research Methodology
The methodology adopted for research was primary survey in which project managers, team
members, delivery managers, HR managers and customers were interviewed. Thus, all the
stakeholders in a typical maintenance project were involved. Data collection was done through
face to face interview using check list questionnaire method. This was done so as not to restrict
the respondents to limited answers rather provide a holistic framework for solutions.

The selection of organizations was based on different criteria such as – availability of

stakeholders for interview, similar sized organizations (where employee strength were between
700 to 1000), minimum of one-third of the annual revenue was from outsourced maintenance
projects and they had high process maturity. These projects had team strength between 15 to
20 employees and were being executed for at least fifteen months. The time period was defined
so that different defined processes would have been implemented and stabilized over a period
of time. This gave similar level playing fields for all the teams. All the organizations should have
been assessed at CMMi level five meaning these organizations are following similar guidelines
from SEI (www.sei.cmu.edu) for defining and implementing processes. This ensures similar
processes being followed for activities such as recruitment, training, performance appraisal,
production etc. and will have similar level playing field for all the organizations. As a result, our
research can find exact nature of solutions deployed by these organizations in solving issues
related to maintenance projects as mentioned above.

Selection of project managers, delivery managers and team members were done based on
number of years of experience in executing maintenance projects. It was decided that all
interviewed persons should have at least worked for three years in maintenance projects and
would have experience in more than two domains at the least (such as banking, insurance,
healthcare etc.). This was done to understand the nature of solution deployed for issues related
to motivation, limited knowledge, and organization structure. Also since all these organizations
were carrying out maintenance projects in offshore mode, this criterion will help us understand
the nature of solution deployed by these organizations.

Qualitative analysis was used to prepare the solution framework.

Data Collection
Total 120 persons were interviewed in three different organizations over a period of seven
months. These persons (table 1 shows category role wise number of persons interviewed in
three different organizations) were from different roles as explained above and were actively
involved in project management processes as necessitated by their roles. Details about the
organizations are explained in the next section. At the request of management, names of the
organizations have been withdrawn; however, details about their business models have been
provided for better understandings. Table 2 shows the questionnaire that was used for
collecting data.

Table 1 : Role wise persons interviewed

Organization Delivery Managers Project Managers Team Members
ABC Software 3 11 21 35
ASSPL 3 12 25 40
ASM 5 14 26 45
Technologies
Total 120

Table 2: QUESTIONNAIRE
The questionnaires were submitted to the project manager who was the contact person for gathering data.
Sensitive data related to customer’s name was masked to guard the confidentiality of information. The
questionnaire format has been given below:

Respondent Information
Contact information for the questionnaire submitter
Name:      
Project:      
Address:      
State/Province:       Postcode:      
Country:       Fax:      
Telephone       E-mail:      

Effort
 Effort is measured in man months (Work carried out from requirement specification phase to
customer delivery).
Total Effort in months:      
Total Duration in months:      
Activity Review Rework
Stages (months) (months) (months)

Requirements gathering and Analysis                  

Design                  

Test Plan preparation                  

Coding                  

Testing                  

Process Infrastructure

What is the domain in which your application is being developed?

Banking Insurance Utilities
Other:      

How would you rate your project against levels available in CMM or CMMi?
Rating

Project Management

What are the issues faced by you in estimating maintenance requests?

How do you train all the team members? Do you use train the trainer concept?
Client support

How would you rate availability of reusable modules for your project? Please rate as 1 if there
was no availability and 7 if all the modules required for programming were available.
Rating:

How would you rate the support provided by client. If there was no support from client, please
rate it as 1 and if the best support was provided, rate it as 7.
Rating:

Application complexity

How would you rate your project for complexity of application being developed? If the
application had complex functionalities, please rate it as 10 and if it was a simple application,
please rate it as 1.
Rating:

Defects

How many Defects were identified (Test Defect & Review Defect) during various phases
(Requirement to Implementation) in your application Development?
Total Number of Defects      

Composition of team

What was the experience of team members in the area of domain at the time they joined the
project?
Total number of man months of experience:
 What was the experience of team members in software technology?
Total number of man months of experience:      

Training Effort
How many hours of training was attended by each member including that attended before
joining this project
Technology Training       months
Domain training       months
As er your view, which training is ore important – domain specific training or technology based
training?

Findings (Case studies)

This section deals with findings from each organization and analysis section will dal with our
proposed solution framework.

ABC Software Pvt. Ltd.

ABC Software Pvt. Ltd. (ABCsoft) is a young and entrepreneurial organization committed to
create a sustainable competitive edge for education institutes through innovative and need-
centric management and technology solutions. The company is promoted by "edu-preneurs"
and professionals with successful senior level experience in diverse industries.

ABCsoft is committed to participate in the education space as a provider of end-to-end services

in the realm of strategy, academic excellence and pervasive technology enablement. Their
flagship product is Greycells - a highly powerful, technology agnostic, and scalable ERP,
specifically designed for education institutes. Greycells integrated with Learning Management
System (LMS) proves to be a significant tool which assures an institution to improve its
academic processes and take pedagogy to newer levels. Over the past couple of years ABCsoft
has made an important contribution to in creating holistic centers of excellence out of
education sector by successfully implementing innovations that seamlessly mesh a string of
excellence oriented learning solutions with efficiency focused process orientation.

They also help their education sector clients to improve the sustainability of their business
models by advising in course selection, financial planning and strategic planning for imminent
global competition. They work along with their client during ideation stage of an institution,
assist them in establishment and keep their continuing support for process improvements once
the academics start. Their e-Learning practice & value enhancers for institutes, in association
with a few national and international partners, aim at bridging the gap between academic yield
and industry requirement. In addition to education sector, ABCsoft has also created a space for
itself in the realm of e-government over the past few years, especially in the health and defense
sectors. They see this as an engine of growth and are keenly interested to be part of the fast
growing Private-Public-Partnership initiatives that are expected to dot the national and global
landscape. They have more than a dozen successful case studies to cite and many satisfied
partners to boast of.

Total revenue earned from maintenance projects during financial year 2007-08 was more than
40% of their annual revenue. The organization had entered into contact with its customers for
maintaining applications that have been installed at their sites. All these applications were
developed and installed by ABCsoft, but the team maintaining the applications was different
than that of development team. The maintenance team was located at a different place than
that of development team, which made the communication between the two teams formal and
had to follow a particular protocol (communication protocol).

The researchers held number of face to face interviews with project managers and team
members who were part of maintenance team. It was found that the management first decided
on the profitability

ASSPL Pvt. Ltd.

ASSPL was founded in 1998, by industry experts with wide international exposure. Currently, it
has over 1000 person-years of experience and is continuing to grow rapidly. ASSPL's capabilities
and offerings are enhanced by its local presence in Europe and North America to provide
business, technical and strategic support to our clients located there. It has offices in Wixom,
MI, which provides the local interface in North America. It also has offices in UK, which caters to
the local client needs of Europe. With their international exposure and understanding of the
business environment in North America and Europe, there is a smooth integration in terms of
work culture and expectations, which is the backbone of Global Delivery Model. The success of
their delivery model is seen from the fact that over 60% of their customers have been referred
by existing customers.

In ASSPL, offshoring of IT Services continues to be the focus of attention in business and

technology management circles. The reasons for this can be due to lower cost of operations,
higher scalability, fast-changing industries, core-process focus, and economic downturn, fewer
errors per thousand lines of code, higher quality and academic attainment of workers in the
foreign locations like India. The organization has a mix of services offered to their clients. During
the period of research data collection (Financial Year 2006-2007 and Financial year 2007-08),
more than 45% projects were executed which followed maintenance life cycle. The organization
has developed different parameters such as profitability, onsite-offshore ratio of team members,
complexity involved in the applications to be serviced, the time required to turn around the
defects that have been reported, which are used for deciding whether to offshore a
maintenance project. ASSPL also offers a collaborative approach to software solutions, which
helps its customers in building the solution that really fits their need. One of the key aspects of
building right solution has been in selecting the right technical platform. The "Technology
Selection" is driven by their business needs, which makes it sustainable.

At ASSPL, the Project Managers have diverse roles. Their most significant activities are project
planning, estimating and scheduling. Planning and estimation are iterative processes. They
continue throughout the project. The project managers revise the plans and schedules, as more
information is available. The project managers when planning a project establish a series of
milestones such that a milestone is a recognizable end-point of a software process activity. It is a
predictable outcome of an activity where the formal report of progress is presented to the
management. The milestones represent the end of a distinct, logical stage in the project. Project
scheduling involves the creation of various graphical plan representations of part of project
plan. Also, the project managers identify the major project risks .They establish their probability
and consequences for the project. The Project managers in ASSPL make plans to avoid, manage
or deal with the likely risks if or when they arise. The risks are explicitly discussed at each
project progress meeting.

One of the major contributors to the success in all the projects (including maintenance projects)
undertaken by ASSPL is for everyone involved to accept the discipline of common set of project
goals, processes and procedures. This makes the sharing of information easier, particularly
when working across different sites and countries. This makes performance predictable and
sustainable. The fundamental processes for all the maintenance projects are: Project
conception: Project definition: Project planning: Project launch and Execution: Project closure:
Post Project Evaluation. The entire project cycle is sub-divided into vertical segments, called
"slices" wherein each slice is a deliverable. Each slice is integrated with each other with clearly
defined conditions for entry, exit conditions. These slices are done up-front, meaning done at
the beginning of the project. These slices are vertical, and the most granular level. These slices
are modular so that each slice can be developed independent of other. These slices contain
codes that represent features. This helps in the case of schedule slippage, in which case delivery
of certain functionality can be differed. These slices would take few days to complete.

Complete testing of the slices is carried out during each iteration of maintenance life cycle. This
methodology facilitates better risk management, better control on the project schedule through
better monitoring and early corrective actions and better requirements management in an
incremental mode. This methodology facilitates requirement evolution during maintenance life
cycle as well as helps in managing larger projects.

The project review approach at ASSPL is decided depending on the criticality of the product
components and the risk associated with it. The project manager in consultation with the
quality assurance manager plans this at the time of the project kick off. This review plan is
continuously monitored and updated. In case of less critical and low risk items, they normally
adopt review approaches like code walkthrough, where the reviewer inspects the code against
the specifications or design documents. In case of more critical and high risk applications, they
adopt more formal group review approach like group review (as per CMMI process guideline). In
order to align the information needs of the management with the organization-wide
measurement objectives, quantitative management techniques are used by defining metrics to
be measured. A few of the prime metrics along with the goals are mentioned in table 3. This
helps in lowering total cost of ownership and increases total benefits of ownership. It brings in
more predictability into the software development process thus ensuring improvement on
future deliverables. This review or validation process tests every angle of the software
applications that are the backbone of the customer’s business thus making them reliable.

Table 3: Quantitative Management

Metrics Goals
Minimize cost (in terms of effort) over-run Effort Variance
Timeliness in delivery Schedule Variance
Improve product quality Defect Density
Improve the level of process compliance Process Compliance index

The approach ensures total customer satisfaction, thus building up of lasting relationship with
our customers and more referrals (60% of the customers are referral based).

ASM Technologies Pvt. Ltd.

ASM Technologies was established in the year 1998 with two people and one vision. Since then
they have grown to an empire of 1000 people who are part of business model which provides
support business requirement like Data management starting from to its analysis and
derivation, Energy management applications, Application integration with customer, Process re-
engineering, Relationship management, Energy delivery and trading systems, Information
management portals, Project monitoring and Process automation to name a few.

The delivery process encompasses a flexible system of activities which range from Competency
Assessment and Training Roadmap, Implementation Strategy and Assessment, System
Architecture Design Review, Application Architecture Design Review, System Installation and
Configuration, Deployment Readiness. Each of these activities is individually analysed and
addressed minutely with the clients. A mutually aggressive business relationship is the resultant
of this customized approach. During the time of research, most of these applications were
already developed and have entered into the maintenance phase. Almost 650+ employees were
engaged in maintaining different applications. These applications were either developed by
ASM or they were developed by other vendors and were handed over to ASM for maintaining
them.

ASM, in order to meet the challenge, trained personnel for acquiring and enriching themselves
with new technologies. The review process helps them to monitor the training effectiveness
During interview, the project managers felt that their innovative Process Monitoring System
(PMS) gives a thorough insight to each of the undergoing jobs and helps in quality checks. The
delivery system is concurrent with the quality measures thus ensuring the final product having
scope for growth and flexibility.

ASM’s process in achieving quality is to set standards from customer’s perspective and then
work forward to achieve it. The approach was to doing things right the first time, conforming to
specifications for products or services, correcting the root cause of the problems by using
statistical tools such as Pareto Analysis, strengthening priorities like simulation and training,
applying quantitative project management to deliver solutions on time and on budget. The
consciousness for quality in projects and products has been refined in the process of ISO and
CMMI certification. The software development and maintenance processes are formalized
through a set of quality procedures. ASM's Software quality assurance (CSQA) consists of a
means of monitoring these software engineering processes and reviewing their progress against
set project goals. It is distinct from software quality control which includes reviewing
requirements documents, and software testing. CSQA encompasses the entire software
development and maintenance process, which includes processes such as software design,
coding, source code control, code reviews, change management, configuration management,
bug fixing and release management. Regular and effective training ensures that global delivery
model can use skilled resources and highly qualified and trained resources are available in
different domains. The process is also well defined in terms of roles and responsibilities of
different resources at offshore and onsite. Table 4 shows different activities that are done at
offshore and onsite.

Table 4: Roles and responsibilities for Maintenance and Production

Support
Services Client Site Locations Offshore Locations
Maintenance Client interaction Background research &
Interviews Reviews information support.
Goal-Setting
Gathering Detailed Requirements analysis,
Requirements, A high Architecture Design, High-level
level Requirements Design, & Prototype building,
analysis Code Development,
Testing& UAT Testing & Integration Extended
Integration UAT support, UAT Defect fixing
Implementation Implementation Change Mgmt& Implementation
support
Production Implementation & UAT support
Support

Analysis
Based on the findings from interviews conducted with team members from three organizations,
a framework could be developed for maintenance projects. Figure 2 shows the pictorial
representation of the framework. A maintenance project is first decided on its off-shorability
based on following factors – criticality of the application, complexity of the application and
profitability. A critical application is to be made available to the customers round the clock. Such
business critical applications are required to be serviced by the vendor immediately so that
business users will get uninterrupted availability of the functionalities from the application. The
degree of criticality will determine whether the maintenance activities need to be carried at the
client site or at offshore location. Highly critical applications need to be serviced at the onsite.
Similarly, a complex application needs constant interaction with the business users for
maintenance. This is because, the maintenance team needs to interact with the business users
to for resolutions to their queries related to bug fixing. Since the application is complex, the
required involvement of the customers will be higher also. Such situations warrant that complex
applications are serviced at client site. Figure 2 represents a decision matrix for offshoring
maintenance projects. This matrix has been modelled based on parameters and processes used
in all the three organizations in study.

At first organization deploys its maintenance team at onsite for maintaining applications that
are critical from business point of view and hence requires constant interaction with customers.
For product enhancement, feature enhancements, offshoring have been found to be profitable
in all the three organizations. For complex applications, the respondents preferred the team to
be near the customer location to facilitate early and correct resolution their queries. Small
applications, product feature enhancement, web enabling of old systems and applications,
testing of custom applications and maintenance of steady state support projects have been
found to be effective (here effective has been described by project managers as good
monitoring and control, resource utilization, meeting service level agreements). Also to be
profitable, while maintaining less critical and less complex applications, offshoring is
recommended. End user training needs to be carried out at client site rather than using web-
seminar or video conferencing. This helps to solve many unforseen design and coding related
problems as the end users can provide details about specific business scenario which were not
captured during requirement analysis. Similarly, maintenance of infrastructure applications
would be well supported by team stationed near the customer site; this fact has been proven by
both second and third organizations as many of their infrastructure related maintenance
activities have been well rewarded by the customers.
Offshoring also brings its own issues and challenges. These challenges are related to project
management and have been dealt in details in Introduction section. The other issues were
motivation issues among employees, work-life balance, effective domain and technology related
training, mapping of the skill set to the requirement, foreseeing competency level required
(technology and domain related) for new projects, estimating for new maintenance requests,
lack of process orientation, rework on bug fixes. During research, it was found that the best way
to address these issues and challenges is to make a holistic approach as shown in table 5. The
elements of the approach have already been tried in these three organizations where study was
conducted and hence can be tried in other organizations as well with fair amount of confidence.
By using this approach, the three organizations in question have been successful with high
customer satisfaction and repeat business from the same customer.

Table 5: Solution Framework for meeting challenges in software maintenance projects

Systematic process oriented approach: It is mandated to review the requirements and figure
out the best place at a high level for the bug fixing or functionality change that has been
requested to make. Many requirements are pretty specific about this, such as capturing postal
code for each consumer or the need to capture the phone number on the registration form etc.
For all such requests, having a map of the site or application, will improve compliance to defined
process, improve documentation, and reduce chances of future rework, setting the correct
expectation from the customer.

Train the trainer: The approach of train the trainer helps to create a trainer pool who then turn
the next level of team members. This reduces time, makes most of on the job training and more
often creates induction training materials for new employees. The training materials, since have
been prepared by team members, are easily understood easily; in two organizations, these
training have been converted to e-learning module with online assessment, making it highly
productive, self spaced learning practice. This reduces the learning curve and makes the new
employees productive faster than the traditional class room training approach.

Involving business users: Once the impact assessment is done and the team has found a place
for the change (if it is an existing page or screen), then the code related to that page must be
examined closely, by clicking on links and push buttons. Even though this may seem basic, but
pieces of functionality and content don’t often work the way it is required to and this approach
saves a lot of time in terms of productivity. Often, there are secret conditions and corporate
political issues that have not been tested before. These, of course, won’t be written down
anywhere and could be one off conditions in business scenario. The best way for the
maintenance team is to cultivate a friendship and amicable relationship with the business users
who know this information.

Test Strategy: Both quality and productivity are at stake in maintenance project in addition to
adherence to Service Level Agreement. It will be good if the teams carry out Unit testing of the
code that has been repaired followed by regression testing to understand impact on other code
as well. This reduces time compared to traditional testing cycle, where the code has to be tested
for Integration Testing and System testing before being moved to Acceptance testing.

Project Monitoring: In maintenance project, estimation and resource allocation has been found
to be accurate and effective, when simple excel or Microsoft Access based tools have been used
for estimation and resource allocation. This has been the practice in all the three organizations
researched, because over a period of time, the maintenance teams have standardized error
codes, and based on the request, the tool would allocate one of the error code and the
competent resource to close the request. Not only this approach has reduced project
management effort, but has brought in consistency and predictability in servicing the
customers.

Knowledge Database: As the error codes are standardized, so also solutions to these errors are
also standardized. This helps in reducing turn around time and increases productivity as well as
team members can be freed up to address new requests. All the three organizations have
created knowledge database with proper indexing and meta-data that help in searching for
solutions for a particular service request and error code. Also, this knowledge database is ever
increasing with new contributions from team members as they encounter new requests.

Benefits
If we look at the benefits of the proposed framework, we find different stakeholders are
benefited differently (in a positive direction). Different stakeholders are customers, employees,

Customer Benefits

As per the customer is concerned, this approach reduces the clients time spent researching
upgrade information, allowing them to focus on their projects. It increases the client's technical
knowledge by providing them with access to "advance-releases" of features that are slated for
inclusion in future upgrades. Clients without a Maintenance Contract would not have access to
new features until a new version is released (or until a Maintenance Contract is purchased).

Employee Benefits

Increase in productivity, with better work life balance as the team resources have free time to
handle all other issues. Increased motivation and involvement in project processes, help reduce
employee attrition. Low attrition reduces cost related to training new employees and making
them project worthy. Customer satisfaction increases repeat business for the organization.
All these benefits have already been found to be prevalent in the three organizations, where
research was carried out. Hence, the framework based approach is sustainable and can be
emulated by other organizations carrying out maintenance activities.

Figure 2: Decision Making Matrix to offshore projects

Conclusion
The research attempted to find issues and challenges faced by a vendor organization while
executing software maintenance projects. These issues were categorized as project
management issues (resource allocation, estimation), work-life balance, low motivation level,
inadequate and ineffective training sessions and lack of process orientation. The study shows
tried and tested approach (used in three different organizations) for addressing issues and
challenges related to maintenance projects. The approach is scalable and can be used in other
organizations carrying out maintenance projects at offshore.

References
Arthur, L.J. 1983. Programmer Productivity, John Wiley & Sons, New York.
Boehm, B.W. "Software Engineering," IEEE Transactions on Computers, C-25, December
1976, pp. 1226-1241.

Aundhe Madhuchhanda D., Mathew saji K.2009. Risks in offshore IT outsourcing: A service
provider perspective, European Management Journal,27, Pp 418-428.

Beulen, E., Fenema, P. V. and Currie, W. 2005. From Application outsourcing to infrastructure
management: extending the outsource service portfolio, European management Journal,23.

Donahue, J.D., and Swearinger, D. 1980. A. Review of Software Maintenance Technology,

ITT Research Institute, Rome Air Defence Centre, RADC-TR-80-13, New York, New York.

Edwards, C. 1980. "Determinants of Successful Information Systems Maintenance." Ph.D

Dissertation, University of Strathclyde, Glasgow, Scotland.

Ewers, J. and Vassey, I. 1981. "The Systems Development Dilemma - A Programming

Perspective," MIS Quarterly, Volume 5, Number 2, June 1981, pp. 33-45.

Glass, R.L., and Noiseux, R.A. 1981. Software Maintenance Guidebook, Prentice-Hall, Inc.,
Englewood Cliffs, New Jersey.

Gopal, A., Sivaramakrishnan, K., Krishnan, M.S. and Mukopadhyaya, T.2003. Cntracts in offshore
software development: an empirical study, Management Science, vol. 49.

Hazel, T.2006. Critical Risks in outsourced IT projects – the intractable and the unforseen,
Communication of the ACM, vol 49.

Lientz, B.P., Swanson, E.B., and Tompkins, G.E. 1978. "Characteristics of Application Software
Maintenance," Communications of the ACM, Volume 21, Number 6, pp.266-471.

Lientz, B.P.and Swanson, E.B.1980. Software Maintenance Management, Addison-Wesley

Publishing, Reading, Massachusetts.

Martin, J. and McClure, C.1983. Software Maintenance: The Problem and Its Solutions,
Prentice-Hall, Englewood Cliffs, NJ.

Mathew, S.K., 2006. Understanding risk in outsourcing, a fuzzy framework, Journal of

Information Technology Cases and Application research,8,3.

Mohapatra Sanjay.2009. “Software Project Management”. Cengage Learning Pvt. Ltd., New
Delhi.
Mohapatra S.2008.”Software product development model for achieving business goal - an
experience based report at j & b software”, Indore Management Institute Journal, Disha.

National Association of Software and Service Companies (NASSCOM). 2009a. “Directory of

Indian Software and Service Companies”, New Delhi.

National Bureau of Standards.1984. "Guideline on Software Maintenance," FIPS Pub 106, U.S.
Dept. of Commerce.

Swanson, E.B.1976."The Dimensions of Maintenance," Proceedings 2nd International

Conference on Software Engineering, San Francisco, California, 13-15, pp. 422-497.

www.jbsoftware.com, 2007
www.microsoft.com/products, 2008
www.nasscom.co.in, 2003, 2008
www.sei.cmu.edu, 2007
www.saasblogs.com, 2006