Guide to Transitioning From Software Development to Maintenance

The transition from a software development team to the maintenance team is often taken for granted. Organizations focus so much on getting a project completed, they forget there are management and maintenance tasks required after implementation.

Software Development Life Cycle (SDLC) Overview

The SDLC is a methodology with clearly defined processes that support the creation and upgrading of software applications.

The modern SDLC contains seven stages:

1. Planning: This is where the ideas flow and the excitement begins. Teams define problems, brainstorm solutions, and start to think of their development objectives.
2. Requirements Gathering and Analysis: In the second stage, teams define requirements and determine the specific details for the new development. It’s important to consider the needs of end users, integration with existing and ancillary systems, and need-to-have versus nice-to-have features.
3. Design and prototyping: Using tools like process diagrams and prototypes, development teams work to create the kinds of plans that will kick off and fuel the development phase.
4. Development: In this phase, code is written, and the software application takes shape.
5. Testing: This phase involves activities such as looking for bugs, finding defects, and learning about shortfalls.
6. Implementation and integration: Often thought of as the final phase of the SDLC, implementation and integration involves a number of tasks that take place as a new or updated software application moves to a live production environment. In addition, user training plans are executed and hardware is installed.
7. Operations and maintenance: After a software application makes the move to production, ongoing operations and maintenance begins. This involves ensuring end users are well-supported as well as identifying the need for patches and updates, which can be a catalyst that starts the SDLC all over again.

Also read: Steps to Conducting a Software Usability Test

Four Types of Software Maintenance

Corrective

Corrective software maintenance is the process that keeps an application up and running. Corrections are most often identified by end users and relate to the design, logic, or code.

Adaptive

Changes to your environment can have an impact on the software applications that run within it. This may be related to hardware updates, operating system updates, or changes to infrastructure. Environmental changes can also include vendor changes, connections to new or existing ancillary systems, or even policy related to security or industry compliance.

Perfective

Perfective software maintenance changes are typically evolutionary. As end users get to work with a software application, they start to create wish lists with new features. In some cases, removing unnecessary or redundant features is also a function of perfective software maintenance.

Preventative

Preventive software maintenance is similar to a technical bandage. It involves smaller, incremental, changes necessary to adapt software applications, so they can work for a longer period of time.

Also read: Using Swim Lane Diagrams to Improve Software Development

Best Practices: Transferring a Project From Development to Maintenance Teams

Transferring a project from a development team to a maintenance team can be complex and challenging, no matter the size. Fortunately, there are a few best practices that should be followed for all transitions.

Identify team leaders

Leaders from the project team, which may include development leads, business analysts, and other stakeholders, should be identified and kept in touch with maintenance team leaders. Knowing who to look to for decisions and guidance can help mitigate risk and ensure a smooth transition.

Team leaders should discuss whether the new software application will impact or change the existing SLAs (service level agreements).

Budget for the transition

Don’t forget to include transitioning from development to maintenance in your project budget. This process shouldn’t be rushed or an afterthought. Be sure stakeholders understand the importance of a proper support plan.

This budget may also include the need to add additional support staff that will be needed post-implementation.

Start Early

Avoid the drop-and-run approach to transitioning projects from development to maintenance. Allow maintenance teams to shadow development teams long before things are complete, include maintenance teams in meetings and relevant correspondence, and update everyone on important decisions.

By including maintenance team members early on, development teams will also have the opportunity to better understand the current state of existing architecture and current software applications being used by an organization.

Communication

Don’t forget the maintenance team may not understand why decisions were made, priorities were defined, or how needs were identified. By communicating these types of details, maintenance teams can better support the software application as well as have empathy and ownership when they need to respond to future questions from end users.

Documentation

Documentation is a critical part of the support process. Skilled technology professionals learn to intuit the details that should be documented to help guide support tasks later on. Think about end users that may look for justifications for the way features or functionality were implemented, and consider the reasons why decisions were made.

A secondary benefit of thorough documentation will be felt with future development efforts. Don’t assume updates or bug fixes will always be done by the same developers.

Documentation elements to include:

• Overview
• References
• Assumptions
• Contacts
• Agreements and licensing
• Diagrams and prototypes with functional and feature lists and summaries
• Configuration details, such as directory structure and administrative functions
• Operational details like start up, shut down, backup, recovery, and archiving
• Security details

Knowledge transfer

Documentation alone isn’t enough, though it is a part of the knowledge transfer process. The trick is to understand and respect the roles of everybody on each team, knowing each has subject matter expertise that may not be known by the other.

Encourage questions and ongoing conversations. There may be things the others haven’t thought of or third-party systems that may unknowingly impact or be impacted by a proposed implementation.

Both teams are important

Neither team is lesser than. Having respect for the work done by each team will help to see the value in the service each provides.

Overlap

Whenever possible, be sure the transition process includes time in the schedule for a little overlap. As support requests start to filter in, it can be helpful to have a resource the maintenance team can call on to get advice and assistance.

That said, be sure the time period for this service is clearly defined and communicated. Having a clear line drawn assists with feelings of ownership and allows both teams to properly move forward.

Learn From Each Transition

Even though every software development project is different, with varying scope and complexity, the transition process can be standardized and learned from. Maintenance teams should conduct post-implementation and transition meetings to discuss lessons learned and solidify best practices.

Document the questions you wish you had asked and timeframes you wish you had designed differently, and bring this knowledge and experience forward to the next transition.

Read next: How to Choose a Software Development Methodology: 6 Approaches