<<Project Name>>

Support Plan

 

Customer Name

 

 

 

Directions for using template:

Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.

 

Some templates have four levels of headings.  They are not indented, but can be differentiated by font type and size:

You may elect to indent sections for readability.

 

 

 

Author

 

Author Position

 

Date

 

 

 

 

 

Version: 1.0

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ó 2002 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.

 


 

Revision & Sign-off Sheet

Change Record

Date

Author

Version

Change Reference

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Reviewers

Name

Version Approved

Position

Date

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Distribution

Name

Position

 

 

 

 

 

 

 

 

 

Document Properties

Item

Details

Document Title

Support Plan

Author

 

Creation Date

 

Last Updated

 

 


 


Table of Contents

Summary

Objectives

Support Resources

Service Level Agreements

Help Desk

Procedures

Logging

Training

Certification

Escalation Policies

Quality Assurance

Service Level Agreements

Bill Back Arrangements

Staffing

Vendor Support

Crisis Resolution Teams

Specialists

Support Processes

Incident and Problem Management

Problem Identification

Problem Classification

Problem Resolution

Improving Support

Documenting and Sharing Information

Apply Gained Knowledge

Appendix

Appendix 1: Incident and Problem Management Guidance

Appendix 2: Best Practices & Lessons Learned


 

 

 


 

[Introduction to the Template

 

Description: The Support Plan describes how the solution will be supported once operational. This includes a description of the support personnel and their roles as well as the processes to resolve problems arising within the solution boundaries.

 

Justification: Planning for a solution’s operational support ensures that the support personnel and processes are in place as the solution is deployed. This enables operational support personnel to be involved with the solution early and gain the knowledge and skills necessary to provide quality ongoing support.

 

Team Role Primary: Release is responsible for the content of the Support Plan.  Development contributes content to the plan to ensure the feasibility of plan’s the technical implementation.  Program Management is responsible for ensuring the plan is complete and for incorporating it into the Master Project Plan.

Team Role Secondary: All other teams review the plan to ensure its feasibility.}]

 


 

Summary

[Description: Provide an overall summary of the contents of this document.

 

Justification: Some project participants may need to know only the plan’s highlights, and summarizing creates that user view. Summarizing also enables the full reader to know the essence of the document before they examine the details.]

<<Begin text here>>

 

Objectives

[Description: The Objectives section describes the business and technical drivers of the support process and the key objectives targeted for the support process.

 

Justification: Identifying the drivers and support objectives shows the customer that the project teams have carefully considered the situation and solution and have created an appropriate support approach.]

<<Begin text here>>

 

Support Resources

[Description: The Support Resources section describes the types of and the nature of support required by the solution. 

 

Justification: All types of support should be known up front to provide the customer ample time to put that support into place. A description of the support resources facilitates analysis of the current operational environment to determine if there are gaps in support personnel’s knowledge and skills. These gaps can be closed during the solution development phase in anticipation of deployment.]

 

Service Level Agreements

[Description: The Service Level Agreements section defines the solution’s Service Level Agreements

 

Justification: The availability of a system is most typically defined as part of a Service Level Agreement (SLA). This agreement acts as a contract between the service provider and the service consumer. This document may contain performance metrics for the system, bonus clauses for exceeding targets, as well as penalty clauses for failing to meet goals.]

 

<<Begin text here>>

 

Help Desk

[Description: The Help Desk section describes the support provided to users and applications by the Help Desk organization. This support should include first-level support for direct user questions and application issues as well as in-depth support for new or difficult issues.]

<<Begin text here>>

 

Procedures

[Description: This section describes the procedures supported by the help desk, which may include incident reporting, hardware failure, software bugs, and usability issues.]

<<Begin text here>>

 

Logging

[Description: This section describes how help desk calls are logged for this solution.]

<<Begin text here>>

 

Training

[Description: This section describes any special training or skills that help desk personnel will need to acquire.]

<<Begin text here>>

 

Certification

[Description: This section describes any special certification that help desk personnel will need to acquire.]

<<Begin text here>>

 

Escalation Policies

[Description: This section describes the policies for escalating a help desk request.]

<<Begin text here>>

 

Quality Assurance

[Description: This section describes the processes for monitoring the help desk quality of service.]

<<Begin text here>>

 

Service Level Agreements

[Description: This section describes any existing Service Level Agreements that cover the help desk.]

<<Begin text here>>

 

Bill Back Arrangements

[Description: This section describes any existing arrangements for bill-back, per call or per incident support.]

<<Begin text here>>

Staffing

[Description: The Staffing section identifies the teams (i.e., crisis resolution team) and personnel (technicians, engineers, etc) that will comprise the support group and specifies the nature of their support. This may include on-site as well as remote personnel.]

<<Begin text here>>

 

Vendor Support

[Description: The Vendor Support section identifies the specific support that will be purchased from a vendor. This should include the support functions and a description of the quality expectations of those functions (response time, turnaround, access to resources, etc). The nature of the solution (business and technical environments) will determine the quality expectations – maintaining high availability requires high quality support.]

<<Begin text here>>

 

Crisis Resolution Teams

[Description: The Crisis Resolution Teams section describes how the support environment will implement the common best practice of crisis resolution teams. These teams are responsible for critical solutions in a high availability environment. The team will typically consist of an application architect or development lead, an operations supervisor, a representative from the user community, and a representative from the support staff. The team may also include a vendor's support personnel.]

<<Begin text here>>

 

Specialists

[Description: The Specialists section describes the circumstances in which in-depth knowledge of the solution demands engaging specialists. Events where a situation or request is especially complex require technical personnel (database administrators, networking staff, system security, etc.) that assist with isolation once front-line troubleshooting is performed. This section should identify the type of specialists that may be required and the source of that expertise.]

<<Begin text here>>

 

 

Support Processes

[Description: The Support Processes section identifies and describes the key support processes that will be put into place to ensure the solution’s availability.

 

Justification: Establishing quality support processes within the organization requires commitment, cooperation, and planning from all parties involved. Although establishing good processes can be time consuming and cumbersome in the beginning, this investment yields satisfied customers, continuous business transactions, employee productivity, and minimized support costs.]

<<Begin text here>>

 

Incident and Problem Management

[Description: The Incident and Problem Management section describes the incident and problem management processes. This description includes the support situations that fall within the process scope, the process steps, roles and responsibilities in executing those steps, and documentation required to report status. Additional guidance on these two support processes can be found in the Appendix.]

<<Begin text here>>

 

Problem Identification

[Description: The Problem Identification section provides additional detail on the problem identification process; it is the first step taken to detect an incident, a known error, or to acknowledge a problem that may consist of any combination of these difficulties. This should describe how the solution will be monitored and how historical data will be viewed. The Monitoring Plan can provide in-depth information on the monitoring process.]

<<Begin text here>>

 

Problem Classification

[Description: The Problem Classification section defines how problems will be classified. This typically includes ratings for Severity and Urgency. Severity represents the direct or potential impact to a solution; Urgency serves as a way to prioritize efforts.]

<<Begin text here>>

 

Problem Resolution

[Description: The Problem Resolution section provides additional detail on the problem resolution process. This description includes the process steps, roles and responsibilities in executing those steps, and the documentation required to report status.]

<<Begin text here>>

 

 

Improving Support

[Description: The Improving Support section identifies and describes two key processes that will facilitate the continuous improvement of the support functions.

 

Justification: Even a well-established troubleshooting process should evolve to meet the changes introduced by technical and business growth. This industry constantly changes, and the technologies within the production environment are constantly updated. By establishing continuous improvement processes, the organization sets the expectation that its support processes will be periodically re-assessed, and that the knowledge gained through previous efforts will be communicated and applied.]

 

Documenting and Sharing Information

[Description: The Documenting and Sharing Information section defines how information will be documented and made available to all parties who may be engaged in the support functions. An effective tracking system should facilitate assessing diagnostic information, build support knowledge bases, report resolution times, and identify support trends.

<<Begin text here>>

 

Apply Gained Knowledge

[Description: The Apply Gained Knowledge section defines how the support function will be periodically assessed from top to bottom. This includes the assessment of processes and their steps, roles, and responsibilities; problem classification; and information management. Additional information about the application of gained knowledge can be found in the Appendix.


 

Appendix

 

Appendix 1: Incident and Problem Management Guidance

 

[The Incident Management Team provides the first level of support and represents a help desk or initial response team in a production outage. The Incident Management Team’s goal is to restore service as quickly as possible with minimal customer impact. The Problem Management Team is engaged in the event that this team cannot restore service or identify the root cause of failures, or if it recognizes several failures that might represent a broader problem.

 

The Problem Management Team is responsible for root cause explanation and represents a persistent point of contact and ownership during an issue’s lifespan. A problem manager should maintain a strategic focus of the issue and be responsible for engaging other parties or specialists as needed until the issue is resolved. A problem manager should be responsible for driving an issue to resolution and escalating it when needed. He or she may not personally perform all of the troubleshooting steps, but should be responsible for ensuring front line isolation was performed and the right data is collected prior to engaging other troubleshooting resources. During the isolation process, specialists can be engaged to help focus on the technology area in question. A problem manager should work with specialists and enforce the completion of action items to avoid wasting time and resources.

 

An important aspect of the problem manager’s role is to maintain ownership. It is not uncommon to see a problem evolve from a networking issue to a server issue, then to a software issue, and so on. As a problem is isolated and different parties are engaged and disengaged to help find the cause, it is essential to keep someone involved in the process from start to finish communicating and organizing priorities, findings, and reporting.]

 


 

Appendix 2: Best Practices & Lessons Learned

 

[The following best practices may apply: