[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:

• Simple is better - There are many great technologies and fancy architectural schemes that become a troubleshooting nightmare when something goes wrong. Software and network architects often create incredibly complex solutions to achieve a very minimal performance or security improvement. Simplified solutions can reduce support and maintenance costs dramatically. If troubleshooting a problem seems too complex, then perhaps it is.

• Be systematic - Troubleshooting is mainly a systematic process of elimination. Create a list of the most likely causes and then systematically eliminate each through a series of simple steps to confirm or eliminate each idea. It is important to be systematic and work from a list of ideas so that you do not accidentally overlook a possibility. It is also important to maintain a list of theories, isolation steps, and their results so that as specialists are engaged you can share what has already been done.

• Utilize action plans – A written action plan can be used to define the problem, detail problem status, and designate action items. When sent as a daily or weekly email announcement, an action plan can help all parties agree on what the problem is, what the current status is, and who is responsible for the next troubleshooting steps. 

• Get a clear perspective - It sometimes helps to bring in a third party who has not been involved with the previous troubleshooting steps and who can provide a fresh perspective. Rather than briefing this person on previous steps, let them offer fresh suggestions. It is quite common that a clear perspective brings with it a new idea that had been overlooked.

• Good process is key   - The best approach to minimizing troubleshooting and increase support efficiency is to develop good practices as part of your development and infrastructure cycles. Time and effort spent improving your testing process, architectural design, and monitoring and diagnostic systems all contribute to minimizing troubleshooting efforts. Troubleshooting will always be a part of the information technology industry, but good process can dramatically reduce the amount of time and resources consumed by the effort.]