Making Processes work in Maintenance & Support

Author: Rajesh Uttangi

Overview

This paper investigates some of the unique characteristics of the software application maintenance & support function. It attempts to capture the important aspects that need to be considered when planning to implement processes or process systems in an IS/IT organization.

The scenario assumed is of a typical in-house maintenance function or department, and not one of out-sourced nature. The scope of the activities addressed here-in pertains to a maintenance & support function that is entrusted with M&S items or requests that need the supported system or application to be fixed or modified in some way. It does not speak to activities pertaining to level 1 support organizations such as call centers.

Introduction

Most of the popular process frameworks and available process/technical literature focuses on new development activities. Some, at best, make a passing reference to maintenance activities. This contrasts with the fact that in most of the IT/IS organizations, maintenance activity exceeds the amount of cost and effort spent on brand new development. Hence this function requires more focused attention.

The challenges of making processes speak effectively to maintenance & support activities are of many dimensions, encompassing human, organizational, environmental and technical aspects. Also the development methodologies and tools used play a role. Processes, by taking into consideration all the peculiarities of this function, can help overcome many of the constraints associated with the function as discussed below.

Defining Maintenance & Support

Maintenance is defined as a process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment. 1 Maintenance accounts for more than 50 percent of the overall cost of developing/deploying a software application.

For the purpose of structuring processes, types of maintenance & support work can be classified as:

• Structured or Release based – where changes are pre-planned and batched into releases spanning weekly, months or quarterly cycles.
• Emergent – Attending to items that are ‘show-stoppers’ and hence need to be handled on priority.
• Customer driven – Customers drive the maintenance activity through business processes linked into IT processes.
• Ad hoc – Making changes as and when resources for doing the same become available

Characteristics of Maintenance & Support Function

To understand the implication of processes on maintenance & support activities we must first understand the characteristics of the maintenance & support function:

• Maintenance & support being an independent function of its own, comprises all aspects of development, i.e. project management, development, HR, QA, etc.
• It is a compressed life cycle, or SIP 2 (Software in Production), in terms of timelines and scope of the required change.
• Involves or affects multiple functional groups – development, operations, desktop support, security, business analysts, testing, etc.

Differences between New Development Projects and Maintenance & Support

Table Contrasting New Development and Maintenance Support

Maintenance & Support Challenges and Key Success Factors Challenges

Based on the source, issues and challenges in various categories can be identified:

External Factors – Factors that Originate Outside the Maintenance & Support Function

• Absent or inadequate documentation for systems
• Inadequate system turn-over information – information that defines the support requirements and SLA’s
• Impact on multiple departments – Operations, infrastructure, business, etc.

Factors that are due to Short Turn-around Times

• Difficulties in skilling and re-skilling of personnel
• Inadequate process documentation – documentation that captures what was changed and how within the maintenance & support function
• Knowledge sharing – how a particular problem was resolved previously
• Adequate customer involvement
• Quality considerations – absence of appropriate reviews and inspections

Factors Due to Difficulty in Prioritization of Tasks

• Tools chosen for the job – how to determine the cost vs. returns or criticality when investing in tools?
• Assignment of appropriate and adequate resources – how do we judge that this task requires higher skills?
• Defining and choosing the right process paths – ex. Small, expedited/critical, new development paths, etc.

Factors due to Variability in Nature of Work (For example, from Total Hardware Failure to a Minor Addition to a Database)

• Process paths and supporting process artifacts for each kind of work
• Matching skill sets to the job
• Identifying relevant stakeholders that need to be involved

Planning Process Support for Maintenance & Support

Given the above factors and the resulting issues, maintenance & support deserves or even warrants its own process track in the development life cycle. This model can be summed up with adjectives like compressed, tailored, and agile. Compressed from the standpoint of the larger development life-cycles intended for new development projects; tailored in the context of being able to handle variable intensity and type of work; agile to be able to be executed with limited resources in short time spans. Added to the core set of processes are the support processes like change and configuration management, which also require a modified perspective, when viewed through the lens of the maintenance & support

Apart from the work that is planned for a specific release, maintenance & support planning needs to take into account various other possibilities like those below:

• Work items may be carried over from previous release/time
• Need for emergent fixes
• Ad-hoc type of work that may be taken due to various factors to do with resource availability, business, management or external
• Some items may even get deferred due to various reasons like the above
• Some items may need to be ‘bumped-up’ to projects since the effort/cost/risk involved exceeds scope thresholds identified for maintenance & support

Process elements that need special attention while ‘tailoring’

Planning for maintenance & support is tricky because of the fluid nature of the work that flows through quickly, though arriving at a varying frequency and urgency. Also dealing with different aspects of the supported system will need interaction and collaboration between multiple departments and/or disciplines. Hence it is important that planning be done to communicate all the specific touch-points with the outside entities, release schedules, methods of assigning priority and resources to tasks based on criticality, etc. Also equally critical are well defined procedures for operational aspects like testing, build, change and configuration management, review and inspection, etc.

At a high level the planning aspects can be categorized as:

• Departmental/Management oriented, and
• Operational/Execution oriented

As the figure below shows, the plans that deal with the management aspects are best kept separate from the operational details, though ultimately contributing equally to how work is done. This ensures that, while the manager does not get called to answer or make decisions regarding each day-to-day operational issue, the implementation folks are not unnecessarily exposed to information that is not needed to perform their day-to-day work.

Departmental Management Planning

This category serves as a charter, budget, high level schedule and resource guide at the departmental level. Recommended aspects to include in this plan are as below:

Releases

Typical support organizations deploy fixes and enhancements to particular systems in periodic releases. Releases can be decided based on customer priorities, resource availability, or dependencies on other planning processes like new development or organization level/strategic.

Within the maintenance function planning needs to be done at several levels: annual, release based (quarterly, months, etc) and also at a day to day support schedule level. Also included are sections for handling emergency items that may even require emergency call outs to personnel, sometimes even in the middle of the night. Also there might be items from previous cycle of maintenance activities, be it previous release, previous year and so on which need to be taken up.

Systems Supported

While new development work tends to be driven by customer requirements, risks and architectural considerations, the maintenance & support function depends much on the nature of the systems being supported. Thus the major classification of work and processes need to take into account the criticality, composition, age and technology platform of the applications. Identifying the system, its criticality, point of contact within the customer and maintenance & support groups, etc., serves as a starting point for further planning.

Resources

While the support group might hope to have a dedicated team assigned to the organization, it is also true that whenever a ‘high visibility’ or ‘management’s pet’ new development project starts off, it is usually the support organizations that are likely to lose resources. This means that the support group has to be flexible enough to accommodate such events. It also means that from an overall organization perspective, the folks on the maintenance & support team must also have the know-how for working on larger, new development projects. Training is one of the major tools that can help accomplish this. Also must be considered the fact that frequent, out of the blue changes are not good for the human psyche and moral. To compensate for the anguish, support staff needs recognition and support systems that alleviate the burden of frequent transition.

Process for Assigning Work

This category of processes includes call-out procedures, system ownership and other support responsibilities. One of the factors that determine the specifics of the processes for assigning work is determined by the nature and frequency of emergencies, which in-turn is determined by the type of system being supported. Careful attention must be paid to this while adopting/tailoring the processes.

Operational Procedures and Processes Planning

Under this category several items can be included that are mostly determined by the environment and the policies governing the maintenance work.

Policies

Any overarching policies, that govern the day-to-day working of the department as a whole must be spelt out and made available to the concerned staff. It is also required to support these with training and monitoring as applicable.

Change and Configuration Management

Unlike new development projects, there are unlikely to be full-fledged and independent configuration & change mgmt plans for each task as such, but a set of procedures spelt out in generally accessible documents. Each set of procedures are segregated by system or application being maintained. The documents must specify:

• roles and responsibilities w.r.t. to configuration management
• change control procedures
• specific processes for source control in terms of repository
• tools usage, check-in/check-out procedures
• branching and merging procedures
• policies and back-up and recovery procedures

Build and Installation Procedures

The operational or functional documents should also cater to the processes involved in building and installing the specific system or system components. This is one more area that is likely to be very system specific.

QA Practices and Procedures

Given that work comes in small bits and pieces, the focus tends to be on getting the stuff-out-the door and working again. This is fertile ground for ad-hoc quality assurance procedures or work-arounds. Maintenance & support must come under the purview of the organization quality assurance practices and compliance assessments. QA procedures must be tailored or scaled down to suit the maintenance & support work and training provided to all concerned. If QA procedures are not formalized, there will be much heartache when regulatory compliance issues are identified and the required mechanisms like documentation and audit-trail are missing.

Test Planning

While most of the testing in maintenance & support is carried out by the developer, it is also important to plan for testing by the user or other relevant third parties. This ensures objectivity and prevention of propagation of defects into production. During the test planning phase, resources, time lines and important aspects (like interfaces) need to be explicitly mentioned.

Documentation

These procedures define the ways and means to obtain and produce relevant documentation when performing systems maintenance. It is absolutely critical that new development generated documentation is channelled into the maintenance function for on-going support and maintenance. Especially critical are the turn-over documents, design documents, test documents and documents that help establish traceability between components and systems, like the traceability matrix. While it is not feasible for all documentation to be manually maintained at all times, relevant critical information must be made available either through shared repositories or through on-line systems.

Maintenance & support processes, on the other hand must ensure that the documentation is updated whenever corresponding system changes are made. Again this applies all the way to the traceability documentation. If the maintenance work itself needs to produce additional documentation, it is essential to ensure that the templates and other artefacts are consistent with the level of effort and criticality for that particular system and the nature of the change required.

Other Key Criteria for Success

While diligent planning and the way the processes are defined ensure a degree of consistency and predictability, these must be supported by practical and innovative ways to implement. Some of the considerations that ensure success in the long run include the following:

Capture Lessons Learned

A database that records new or unique situations encountered and the steps to taken to resolve the problem is invaluable, particularly if the personnel being assigned the problem are new to the department.

Ensure the Level of Documentation Is Consistent With and Not an Impediment to the Work

Requiring elaborate and unnecessary documentation that is inconsistent with the nature of the effort and criticality of the task results in the documentation being produced for the sake of compliance and does not necessarily add value. By stipulating the appropriate amount of documentation requirements, processes have a better chance of being followed and the results will be beneficial to both the producer and the user (installation staff or developers who use it as reference at a later point in time) of the documentation.

Automate, Automate!

The right mix of automation and tried and tested, down to earth manual systems work the best.

Apart from the technical (CASE) tools, most beneficial are the tools that support the process. Tools that facilitate:

• Effort and cost estimation
• Tracking overall departmental effort and work status
• Customer and other stakeholder involvement through reviews and feedback, etc.

Incorporate Lean QA Practices as an Integral Part of the Workflow

QA processes like review, inspection and audits must be taken care of as a part of the process flow and not make it an additional burden on the implementing personnel. This can be achieved by context based review requirements and mechanisms and possibly, automation. For example, the customer being able to conduct an on-line and informal review of a process output like a requirements document or a screen lay-out has a better chance of being adopted than the need for all the stakeholders to do a joint review in a team setting.

Assign Specific Responsibilities for Supporting Functions like Change and Configuration Management

In many organizations the supporting functions like Change and Configuration management tend to be assumed to be part of the responsibility of the support personnel without explicitly specifying the procedures and supporting environment that enables carrying out the task. Also in the case of shared resources, unless the responsibilities and the processes are spelled out, nobody is likely to take ownership of the common elements and thereby create potential for confusion and failure. By planning and assigning responsibilities for these tasks, overall resource management becomes more structured, predictable and helps tracking.

Involve Customers through Process Based Interaction Points

Just as processes need to be sold to the practitioners, they also need to be sold to the customers. Undoubtedly, without adequate customer involvement, the final result from any maintenance or development activity is likely to be less than perfect, if not a complete failure. To ensure that customers do get involved at appropriate times, the processes need to spell out those touch points and the responsibilities of the customer representatives at that point. This can even be supported by adequate infrastructure like tools and meetings where appropriate.

Conclusion

With over 50 percent of the activity happening within a typical IT/IS organization being maintenance & support, it deserves special consideration when processes are being set-up. Special attention has to be paid to the fact that, while resembling a typical development life cycle, maintenance support has its unique characteristics like incorporating all disciplines in a compressed life cycle, reduced time and scope, various parts of the work being carried out by a single person, etc. Hence processes need to be tailored to suit maintenance & support function while also accounting for various scenarios like the routine, the small, the large or the emergent. Supporting procedures and documentation have to match the kind of work.

Since processes are the enablers of work being carried out with consistency and predictability and increase the chance of success it befalls the process planning effort to be innovative and considerate. Effective and efficient processes are the result of seamlessly integrating the practical and the best-practice based elements in the target function. With such a process framework, maintenance & support personnel have reduced overheads and a greater chance of meeting the demands of their seemingly disparate responsibilities.

References

• IEEE Standard – 610.12:1990, Glossary of Software Engineering terminology
• Software-In-Process, New/Old Project Metric, Kent Beck, Three Rivers Institute

The Author

Rajesh Uttangi is a consultant and CSQA (Certified Software Quality Analyst) working with the Quality Consulting Group of Wipro Technologies. He specializes in the area of software development process improvement using the Unified Process and CMMi frameworks and related tools. He has contributed significantly to SPI activities both internally to Wipro and also at several client locations in the USA. He can be contacted through e-mail: rajesh.uttangi@wipro.com.

Copyright Project Perfect