Step 1: Build the Change
The requested change has been approved. Now the actual hands-on work of making it happen can start.
Info-Tech Tip: Apply best-practice application development and project management approaches to maintenance execution, no matter how insignificant the change may seem. While you don’t want to overburden the process, keep in mind that every change, no matter how small, can have unforeseen ramifications on the overall performance of an application or system.
|
 |
1.1 Design, Develop, and Code the Change
Application maintenance has basic software development principles at its core. However, a full-blown development approach is often inappropriate for changes and enhancements requiring limited effort. Focus on the important steps – functional requirements and impact analysis before making the code change. Regardless of the size and scope of the change requested, some planning must take place to ensure the final result meets business expectations.
Use Info-Tech’s OptimizeIT core Functional Specifications Template to describe the business requirements and functional elements the change must deliver. Use OptimizeIT’s advanced Work Breakdown Structure Template to help identify specific activities and plan resources to ensure successful change completion.
|
|
|
 |
1.2 Build the Release and Gain Final Approval
For some organizations, once a change has been made, it is ready to be tested and released into the production environment. Other organizations will bundle a change with other changes into a scheduled release – release management. This process creates a package of changes that can be tested and released together.
The first two tools used in formal release management are the advanced Release Inclusion Request and the Release Configuration Record. The first is used by developers to define what changes have been made and need to be released into production. The latter is used by the release manager to confirm what will actually appear in a given release and to track the release’s status.
|
|
|
Step 2: Test the New Version
Testing is often the most overlooked aspect of application development and maintenance. Its proper execution is critical regardless of the size and scope of the change being made. Thorough testing of all changes should take place prior to rollout into a production environment.
Info-Tech Tip: The testing phase of any project is often given short shrift – it is often rushed or, in many cases, not carried out at all. The cost of failing to catch and rectify errors prior to introduction into the production environment grows exponentially the longer it is delayed. If you make one change to your development practices this year, introduce a rigorous testing program.
Info-Tech Tip: Don’t underestimate the value of a separate test environment complete with “golden” test scripts and data. The idea is that the “golden” scripts have proven results with the test data set. Use these test scripts to confirm that changes have no unintended results.
|
 |
2.1 Test the Changes to Be Implemented
Testing is all about confirming that intended results have been, and will continue to be achieved going forward. Developing a clear test plan that identifies the types of testing to be carried out and the goals of each type is essential.
First, use Info-Tech’s OptimizeIT advanced Testing Method Selection Tool to determine which testing types are of highest priority based on the quality of existing application development processes and overall impact of the change on the business. Next, use the advanced Test Strategy Template and Use Case and Test Case Matrix, as well as the core Functional Test Plan Template, to plan specific test scenarios and document your overall testing approach.
|
|
|
 |
2.2 Analyze and Review Test Results
Closing out testing activities is one of the final steps before rolling out a change. The effectiveness of this stage of a change activity or project can have a significant impact on the team’s ability to bring changes in on time, with quality.
Use OptimizeIT’s core Test Tracking and Resolution Report tool to document problems found and how they were resolved. The information tracked here will be important during last-mile progress communication with change stakeholders.
|
|
|
Step 3: Release the New Version
Releasing the new version of the application into production is considered by many to be the “grand finale.” Full user acceptance of the changed system hinges on thorough and timely communication with all change team members and business stakeholders.
Info-Tech Tip: While considered onerous, building out clear documentation is worth the investment. Create a centralized repository for all systems and application-related documentation. While read-only access should be broadly granted, it’s a good idea to restrict who can alter these important baseline documents. Currency is paramount, so make sure a documentation stage is built into every change process.
Info-Tech Tip: As the saying goes, “Communicate early and often.” Leave nothing up to speculation. A lot of corporate communication happens through informal lines, so it’s imperative to make sure that all team members are on the same page and conveying the same ideas. A centralized communication plan can go a long way towards standardizing key messages and setting expectations among stakeholders.
|
 |
3.1 Document Version, Configuration and Release Control
All changes that have been made must be clearly documented across a range of information repositories. This is the final opportunity to ensure that no detail that can affect the ongoing health of the release has been overlooked.
Take advantage of OptimizeIT’s core Version Control Worksheet in order to document all changes that have gone into the current version of the affected application. At this point, also be sure to update your existing Forward Schedule of Changes Template with new information about the status of the release.
|
|
|
 |
3.2 Plan and Communicate Version Release to Users
Making a change without proper communication can result in end-user confusion and ultimate failure of the change that was supposed to make things better. End users and all stakeholders of the requested changes must be kept in the loop to minimize risk and maximize success.
Start the communication process by drafting a Release Rollout Communication Plan. This advanced planning tool will help you organize the key messages and communication channels required to get the word out about the change. Also plan a Release Rollout Stakeholders Meeting to address final concerns and achieve final buy-in for the change rollout – Info-Tech has provided an advanced-level meeting agenda for this purpose. At this meeting you can use OptimizeIT’s Release Approval Checklist to make sure all release prerequisites have been effectively addressed.
|
|
|
Step 4: Monitor Maintenance Changes
Once the change has been rolled out, it’s not over yet. Was the change a success? Did it meet business users’ expectations? Were the practices applied effective and efficient in bringing about the desired results? Get answers to these questions in order to aid in continual improvement.
Info-Tech Tip: Lessons learned should be identified and carried forward to prevent problems and inefficiencies in the application maintenance process in the future. View every completed activity as an opportunity for continuous improvement.
|
 |
4.1 Review Maintenance Change Costs and Performance
Measuring the success of the change is the final step in the maintenance lifecycle. OptimizeIT offers an advanced Release Post-Implementation Review tool to help you assess the success of project-scale application changes and recommend changes to existing processes. .
|
|
|