Appendix S Sample Maintenance Plan

SAMPLE MAINTENANCE PLAN

Change Control Page

The following information is being used to control and track modifications made to this document.

1. Revision Date:

   CI:

   Author:

   Section(s):

   Page Number(s):

   Summary of Change(s):

TITLE PAGE

Document Name :	Project Name
Maintenance Plan
Publication Date:	Month Year
Contract Number:	XX-XXXX-XXXXXXXXX
Project Number:	Task: XXXXXXXXXXXXXX
Prepared by:	XXXX XXXXXX
Approval:	_____________________________________
	Name and Organization
Concurrence:	_____________________________________
	Name and Organization

COMPANY

Organizational Title 1

Organizational Title 2

PREFACE

Document Version Control: It is the readers' responsibility to ensure they have the latest version of this document. Questions should be directed to the owner of this document, or the project manager.

Life-cycle Stage: Project Name is in the maintenance stage of the project life cycle.

Approval: An approval signature constitutes approval of this document when accepting a developed project(s) into the maintenance stage or for an existing project(s) that has been in the maintenance stage but did not have a documented plan.

Document Owner: The primary contact for questions regarding this document is:

Author ' s Name, Author ' s Function, e.g., Project Planner

Project Name Team

Phone: (XXX) XXX-XXXX

E-mail:

Privacy Information

This document may contain information of a sensitive nature. This information should not be given to persons other than those who are involved in the Project Name project or who will become involved during the life cycle.

OVERVIEW

Background

Provide a high-level description of the project and its background. Clearly indicate if processes are already in place from the development of the system or whether the system has been in maintenance for some time and did not have documented processes. If the processes carried over from development, reference the documents that describe the process. If the processes were not documented before, describe each process in this maintenance plan.

Scope of Maintenance

Describe the software, hardware, documentation, and services that are included in the maintenance task assignment/contract.

State the parameters that are being set for the project(s). This may include areas such as work assignments; type and frequency of customer/client meetings; requirements analysis; project(s) characteristics, etc. Also, list any areas specifically excluded from the project(s) (i.e., acquisition of hardware/software, etc.).

Describe the nature of the maintenance to be performed. Is it ongoing (e.g., several resources are assigned and funded for a given period of time and they maintain the system) or is it for a specific project (e.g., a specific enhancement to be performed, or additional functionality to be added)?

References

Identify sources of information used to develop this document, such as IEEE or project documentation.

PRODUCT STATUS

Identify the status of the products included in the scope at the time the maintenance task assignment/contract is initiated. This would include version numbers, release numbers , and any known defects.

PROJECT TEAM

Identify all team members by functional job description (e.g., all maintenance team members, functional area members , and approvers). State approximate percentage of each team member's time that will be required to be devoted to the project(s).

Roles and Responsibilities

The person(s) responsible for ensuring that the maintenance activities are performed are identified in the in the chart below or the project(s) work breakdown structure that these persons are normally identified is referenced.

Role	Name	Org	Responsibility
System Owner/User Point of Contact (POC)			Has overall responsibility and accountability for systems and data. Assigns and approves all project activities.
Project Leader			Responsible for daily planning and control of project. Manages and coordinates technical effort. Evaluates all requests and assignments from system owner and assigns to the appropriate staff member. Provides consistent and timely communications with system owner. Responsible for final sign-off of all project assignments prior to forwarding to system owner for approval. Responsible for producing the Maintenance Plan and for obtaining the customer's agreement to the plan.
Project Leader's Manager			Provides support and guidance to the project leader and team. Ensures project staffing. Resolves and facilitates communications between client and support group .
Systems Programmer/ Analyst Support Staff			Analyzes assignments and performs the technical requirements of the task including coding, testing, documenting, and implementing.
Quality Analyst			Reviews deliverables from a QA perspective. Provides guidance and assistance on process matters.

MANAGEMENT APPROACH

Describe the priorities for managing the project; tracking and controlling the project; assumptions, constraints, or dependencies associated with the project; risk management issues; project estimates (sizing and time); staffing requirements (skills and resource load); and information on overall schedule and project deliverables. Provide an overview of how activities will be tracked to completion and how the project schedule/cost will be kept under control.

Management Priorities

Describe in general the approach for determining priorities.

Task Estimates

Describe the process for determining estimates for tasks received.

Estimate the task's size and the time required for completion. Estimates may be based on information such as the project's objectives, and information gathered during interviews, known requirements, and skill/experience levels. Estimating approaches may include a defined timeframe for each type of task based on tracking of actual times versus planned, over a period of time. Target response time and clearance time for problems/change requests .

Assumptions, Constraints, and Dependencies

List all known assumptions, constraints, and dependencies that could potentially affect maintenance of the project. An example of an assumption would be that the tasks for the project do not change significantly after they have been approved. A constraint is normally a situation that limits the resources that can be used to accomplish project maintenance. For example, the budget is restricted, requiring extra coordination to insure agreement on what tasks can be accomplished with the resources available. A dependency is an event or chain of events, outside the manager's control, that must happen for the project to be successful. For example, testing of project(s) will depend on installation, by 10-1-02, of a LAN backbone and connections by the Telecommunications area.

TECHNICAL APPROACH

Types of Maintenance Activities

The activities for maintenance changes are a shortened version of the development stages. The types of changes that are included in the main- tenance task assignment/contract are: problem resolution (corrective), enhancements, interface modifications (adaptive).

Configuration Management

Describe the configuration management process. Describe the change control activities. This includes how the change is initiated by the customer or the maintenance team and the process for analysis, risk assessment, design, coding, testing, and installation of a new release of the software, including changes to project documents.

Include the process for corrective changes that are made on an emergency basis to keep the project operational. A sample change request form is in Attachment 1.

Risk Assessment

State all potential risks associated with the change being implemented. Describe the elements of the risk, and state how the risk will be handled during task implementation.

Testing

Describe the process for testing the changes.

System Protection

Describe the process for protecting unauthorized access to the project(s).

Special Processes

Identify special-purpose programs that are planned/regularly scheduled maintenance activities such as mass changes, database modifications, backup and recovery, etc.

Maintenance Records and Reports

Describe the format of records of maintenance activities performed and frequency of issue to customer.

List reports that will be produced and frequency of issue. These should include:

• List of requests for assistance or customer problems and the status of each
• List of corrective actions, including their priorities and results, if available
• Failure rates and maintenance activity metrics

Reference Attachment 2 for a sample Maintenance Log, instructions, and Maintenance Log ” Detail Status Information.

Training

Describe the periodic or established training required for customers and maintenance team.

Documentation

Describe the documents that are maintained as part of the maintenance effort.

Quality Assurance Activities

Describe the activities and the process for reviewing the maintenance process to determine that activities are occurring as planned.

Software Change Request Form

INSTRUCTIONS FOR COMPLETING THE MAINTENANCE LOG

This change control log form is included as a suggested format for recording and maintaining software change request data, including changes to documentation. A Detailed Status Information form is available to record supplementary details. The log and software change requests should be maintained in the Systems Project Notebook.

Field	Definition
Page #:	Enter the appropriate page number of the log sheet.
Log Date:	Enter the date control log was started.
System Name :	Enter the name and acronym of the system to be managed.
Request #:	Enter the unique sequential number assigned to each request on the request form (i.e., software change request form, etc.)
Reqmnt #:	Enter the unique number of the requirement to be changed (if known) on the request form.
Date Submitted:	Enter the date the request was submitted to the maintenance team.
Priority:	Enter the priority from the request form using the first character of the priority; e.g., E = E mergency, U = U rgent, and R = R outine.
Approval:	This area is for recording request approval information obtained from the request form. Change Approved: Enter the date the request was approved. Change Not Approved: Enter the date the request was disapproved. Hold (Future Enhancement): Enter the date the request was placed on "Hold."
Status:	This area is for recording basic information about the status of a request. Technical Evaluation Phase: Enter the date the technical evaluation of the request commenced. Change In-Progress: Enter the date work began on the request. Usually, the areas "Technical Evaluation Phase" (if applicable ) and "Change Approved" should be entered prior to posting the "Change In-Progress" date. Work on most requests should not be initiated without a technical evaluation and formal approval in the request form. Canceled : Enter the date the request was canceled. Target Date: Enter the estimated date that the request will be completed and ready for release/implementation. Date Complete: Enter the actual date the request was implemented.

MAINTENANCE LOG ” DETAIL.S STATUS INFORMATION

Page #:	Log Date: ___ / ___ / ____
Request #:	System Name:
SCC-DS Log V1.0 (8/8/99)
Note: Use this form in conjunction with the Maintenance Log form to record supplementary details about a given software change request. Include the appropriate Page # and task # from the Maintenance Log form to maintain a cross-reference between logs. Keep all logs with the task request in t he System Project Notebook.

REFERENCE

This document is an adaptation of a Maintenance Plan document template from the U.S. Department of Energy.