Every VA App must have a Sustainment Plan that outlines how the App will be maintained and how users will be supported. Some items might not be applicable in a particular case, but all of them should at least be considered. VHA Web and Mobile Solutions (WMS) requires that a Sustainment Plan be provided for each App before it is deployed. Sustainment Plan is a required PMAS document. Ideally, the Requestor attaches the Sustainment Plan to the Request during the Planning stage.
Sustainment plans must be organized as shown in the following sections.
1.0 Overview
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 and software components should be described in a separate paragraph.
1.2. Status
This section gives the initial status of the system: New development or Completed Product.
1.3. Support
This section describes what support is needed: Hardware, Software, Help Desk, other.
1.4. Maintainer
This section identifies the maintainer and who will be responsible for the Support described above.
1.5. Contracts
This section describes any contractual protocols between the product owner and maintainer, including any Service Level Agreements (SLAs) requirements.
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.
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 (for example, 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.
2.2. Level of Support
This section describes the level of support for the system. The length of the support agreement and the number of new releases should be identified.
2.3 Support Period
This section describes the support period from pre-delivery to post-delivery.
3 Organization and Maintenance Activities
Once the maintenance organization is identified, the specific maintenance activities are specified. This section defines the role of the user and specifies activities that must be coordinated with other organizations.
Printer-friendly version
