U.S Department of Veterans Affair

Sustainment Plan Requirements


This content is no longer current.
Visit the new Developing VA Apps home page for updated processes and requirements for building your VA App


Every mobile application is required to have a Sustainment Plan that outlines how the App will be maintained and how users will be supported. This section provides an outline of items that should be considered when a sustainment plan is created. Some items mentioned here might not be applicable in a particular case, but all of them should at least be considered. The Web and Mobile Solutions (WMS) requires that a Sustainment Plan be provided for each App before it is deployed. Preferably, the Sustainment Plan is provided at the same time that a new product is initiated and is included with the product’s registration artifacts in the JIRA system. In the sections described below, examples are italicized.

General Requirements

This section describes the policies and responsibilities of the program/project team as it plans for software maintenance and user support.

1 Introduction

This section describes the system to be supported and identifies the initial status of the system (e.g., in planning, under development, already deployed). Complete identification of the system should include formal and common names, nomenclature, identification number, and system abbreviations. Subsystems and external systems with interfaces to the Mobile Application should be identified.

NOTE: Here is an example introduction that would apply if the developer will be performing maintenance:

This plan describes the processes and procedures necessary to provide software maintenance for the XYZ system. System XYZ, Version 1.0 is being developed by the ABC Mobile Applications Corporation. The Software Maintenance Department of ABC will perform all software maintenance functions.

NOTE: Here is an example introduction that would apply if maintenance will be outsourced to another company or will be performed by the OIA Web and Mobile Solutions (WMS) department:

System XYZ, Version 1.0 is being developed by the ABC Mobile Applications Corporation and will transition to OIA WMS for software maintenance support. System XYZ contains subsystems named COLLECTION, PROCESSING, and REPORTING. System XYZ interfaces with systems QRS and STU. This plan details the activities and specifies the various responsibilities needed in order to provide software maintenance for System XYZ.

1.1. System

This section describes the mission of the system: why it is needed, how it will be employed, and what interoperability requirements it has. It should describe system architecture, components, interfaces, hardware, and software. Each subsystem and major hardware/software component should be described in a separate paragraph.

System XYZ provides payroll processing for a small business. It provides input to a third party payroll company called FGH Payroll Processing Inc. The data provided must be in a format compatible with FGH’s requirements. System XYZ takes input from timecards, aggregates them, and formats the data to be forwarded to FGH.

1.2. Status

This section gives the initial status of the system:

System XYZ is under development and will replace System XY. System XY is a Mobile Application that is integrated into VistA. System XYZ will provide integration and the following functionality:

1.3. Support

This section describes why support is needed:

System XYZ has a projected life of three to five years. During that period, corrections and enhancements will be required. Corrective maintenance will accommodate latent defects as reported by users. Enhancements or improvements will be developed in order to improve performance and provide additional functionality for the users. As a result, maintenance support is required.

1.4. Maintainer

This section identifies the maintainer:

The maintainer for System XYZ is the OIA Web and Mobile Solutions department


The maintainer for System XYZ is the Software Maintenance Department of the DEF Company.


The maintainer for System XYZ is the OI&T Product Development Department.

Each maintainer must provide his or her software maintenance process manual, describing how items need to be delivered to the maintainer. That process manual should become an appendix to the sustainment plan.

1.5. Contracts

This section describes any contractual protocols between the product owner and supplier.

The Software Development Department of Company ABC has a signed Memorandum of Agreement with OIA Web and Mobile Solutions to provide software maintenance for system XYZ. Through a Configuration Control Board (CCB), agreement will be reached on what corrections and enhancements will be provided in the next release. Emergency support is provided on an hourly basis.


Company ABC has a signed Memorandum of Agreement with Company DEF to provide software maintenance for system XYZ. Through a Configuration Control Board, agreement will be reached on which corrections and enhancements will be provided in the next release. Emergency support is provided on an hourly basis. as appropriate.

2 Maintenance Concept

This section outlines the concept under which maintenance will be provided. It should address the following:

  • The scope of software maintenance (how responsive the maintainer will be to users);
  • The tailoring of the post-delivery process;
  • The designation of who will provide maintenance; and
  • An estimate of life-cycle costs.

The product owner should develop the maintenance concept early in the development effort with help from the maintainer. Defining the scope of maintenance helps the product owner determine exactly how much support the maintainer will give to the product owner and its end users.

Various organizations often perform different software-maintenance activities during the post-delivery process. An early attempt should be made to identify these organizations and to document them in the maintenance concept. In many cases, a separate maintenance organization performs the maintenance functions. Figuring out who or which maintenance organization should perform maintenance for a particular system involves many factors. If the system only has a lifespan of two years, it may be appropriate for the developer to maintain it.

2.1. Software Maintenance

Responsiveness to the user community is the primary consideration in determining the scope of software maintenance. The scope of software maintenance should be tailored to satisfy response times dictated by operational requirements. Scope relates to how responsive the maintainer will be to proposed changes. For example, a full-scope software maintenance concept implies that the Maintainer will provide full support for the entire deployment phase. This includes responding to all approved software-change categories (e.g., corrections and enhancements) within a reasonable period. Software maintenance concepts that limit the scope of software maintenance are referred to as “limited-scope concepts.” Limited-scope concepts limit the support period, the support level, or both.

The Software Maintenance objective for System XYZ is to release two operational versions during each year. The product owner will determine the target dates and the content of each release. Support for Version 1.0 will be limited to priority one (cannot operate the system) corrective actions. All other problems will be saved and included in the next release. All enhancements will be held until a scheduled release.

2.2. Level of Support

This section describes the level of support for the system.

Support will be provided for three years and will include support for two major releases each year. All corrective and enhancements approved by the product owner will be included in releases. Tracking of all change requests is required. A Help Desk will be maintained by the HRC, and technical support will be provided as needed. The Help Desk will refer defects to the maintainer and notify the product owner accordingly.

2.3 Support Period

This section describes the support period from pre-delivery to post-delivery.

The maintainer will provide support during the development phase. This support will be on an on-call basis to review requirements, plans, etc. The post-delivery support period will be three years.

2.4 Tailoring the Maintenance Process

Tailor the maintenance process by referring to the maintainer’s software maintenance process manual. Any activities or tasks in the process manual that will not be performed for System XYZ must be deleted. In this section, identify the specific sections of the process manual that will be deleted. Software Maintenance for System XYZ will be performed in accordance with Company ABC’s “Organization Software Maintenance Process Manual”, or, for outside support, in accordance with Company DEF’s “Software Maintenance Process Manual.” As an example, System XYZ may not require sections 3.3, 3.4 and 3.5 of the Process Manual. Thus, the following might be used. Specific activities tailored out for System XYZ are items: 3.3, 3.4, and 3.5 of the “Organization Software Maintenance Process Manual.”

3 Organization and Maintenance Activities

Once the maintenance organization (i.e., the maintainer) is identified, the specific maintenance activities are specified. General software engineering activities are performed during pre-delivery and post-delivery. This section defines the role of the user and specifies activities that must be coordinated with other organizations.