<<Project Name>>

Operations 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

Operations Plan

Author

 

Creation Date

 

Last Updated

 

 


 


Table of Contents

Summary

Objectives

Operations Infrastructure

Reporting Model

System Level Reporting

Application Level Reporting

Skill Requirements

Change Management Process

Receipt of Request for Change

Change Analysis and Review

Change Notification and Release

Change Building, Testing, and Implementation Monitoring

Change Outcome Notification

Post-Implementation Evaluation

Urgent Change Process

Operational Activities <Product/Feature Solution 1>

Ongoing Operations

Systems Management

Backup and Recovery

Maintenance

Monitoring the System

Securing the System

Performance Planning

Capacity Planning

Problem Management

Configuration Management

Configuration Management Planning

Configuration Identification

Configuration Control

Configuration Status Accounting, Verification, and Auditing

Service Level Management

Appendix – Monitoring Guidance



 

[Introduction to the Template

 

Description: The Operations Plan describes how day-to-day operations will occur when the solution is in place. It provides guidance for the organization to maintain the solution successfully over an extended period of time. It contains details on both ongoing and contingency operations and how to proactively handle problems that may arise. Key components of this plan include backup recovery steps, managing configuration changes, and the skills necessary to support the operations.

 

Justification: By planning for operations early in the project, the organization can take the time necessary to put operational success factors into place. These factors may include changes or additions to people resources, processes, and infrastructure.

 

{Team Role Primary: Release Management is responsible for planning and implementing the operations necessary to support the solution. Release Management derives the Operations Plan from requirements documents and functional specifications.

 

Team Role Secondary: Program Management approves this plan and verifies that it satisfies the project’s requirements. Development reviews the plan to understand how their work will be deployed and modifies their development plan if necessary. Test reviews the plan to ensure their test environments are set up to reflect the operational environment in which the solution will be placed.}]

 


 

Summary

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

 

Justification: Some project participants may need to know only the highlights of the plan, and summarizing creates that user view. It 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 identifies the primary drivers that were used to define the operations approach and the key objectives of that approach. Input to this section could be from the existing operational environment and the functional specifications.

 

Justification: Identifying the drivers and operational objectives signals to the customer that Microsoft has carefully considered both the present operational situation and what the future environment must be to support the solution successfully and has created an appropriate operational approach.]

<<Begin text here>>

 

Operations Infrastructure

[Description: The Operations Infrastructure section provides a comprehensive description of the overall environment into which the solution will be deployed and supported once deployment is complete.

 

Justification: This information provides the context for all operations planning and establishes the necessary baseline infrastructure.]

<<Begin text here>>

 

Reporting Model

[Description: The Reporting Model section describes the solution’s overall reporting model and any supporting tools that will be used. It describes generally who will receive reports, what information they will get and on what schedule, and what source data will be used to generate the reports.

 

Justification: This information assures Operations that the information necessary to manage the solution successfully will be available.]

<<Begin text here>>

 

System Level Reporting

[Description: The System Level Reporting section should include a description of who will receive reports, what information they will get and on what schedule, and what source data will be used to generate the reports.]

<<Begin text here>>

 

Application Level Reporting

[Description: The Application Level Reporting section should include a description of who will receive reports, what information they will get and on what schedule, and what source data will be used to generate the reports.]

<<Begin text here>>

 

Skill Requirements

[Description: The Skill Requirements section identifies the job roles and associated skill requirements necessary to operate the solution. This information could be placed in a matrix that identifies 1) types of operational functions, 2) the job roles that work within each function, and 3) the skill requirements for each job role.

 

Justification: Defining skill requirements facilitates the assessment of the current operational staff and identifies skill gaps that must be filled before the solution becomes operational.]

<<Begin text here>>

 

Change Management Process

[Description: The Change Management Model describes the change management process that will be applied to the operational solution.

 

Justification: The presence of this model ensures that standardized methods and techniques are used for efficient and prompt handling of all changes so that change-related problems are prevented.]

 

Receipt of Request for Change

[Description: The Receipt of Request for Change section describes how the change request will be tracked and recorded.]

<<Begin text here>>

 

Change Analysis and Review

[Description: The Change Analysis and Review section describes who analyzes and reviews change requests and how they are approved.]

<<Begin text here>>

 

Change Notification and Release

[Description: The Change Notification and Release section describes who will be notified of changes and their release and how that notification occurs.]

<<Begin text here>>

 

Change Building, Testing, and Implementation Monitoring

[Description: The Change Building, Testing, and Implementation Monitoring section describes how changes are incorporated into the development, test and implementation processes.]

<<Begin text here>>

 

Change Outcome Notification

[Description: The Change Outcome Notification section describes how people are notified of the outcome of changes.]

<<Begin text here>>

 

Post-Implementation Evaluation

[Description: The Post-Implementation Evaluation section describes how change implementations are reviewed and assessed for success and challenges.]

<<Begin text here>>

 

Urgent Change Process

[Description: The Urgent Change Process section describes how urgent changes are processed.]

<<Begin text here>>

 

Operational Activities <Product/Feature Solution 1>

[Description: The Operational Activities section describes the operational activities (listed in the sub-sections below) for EACH subsystem within the solution. Include within each sub-section each independent solution or technology (i.e. server product) implemented within overall solution.

 

Justification: Describing the detailed operational activities enables operations to develop the tactical plans from which resources and procedures will be organized and implemented.]

 

Ongoing Operations

[Description: The Ongoing Operations section describes the various ongoing operational procedures performed. List all procedures and describe each.]

<<Begin text here>>

 

Systems Management

[Description: The Systems Management section describes the various systems management procedures performed. List all procedures and describe each.]

<<Begin text here>>

 

Backup and Recovery

[Description: The Backup and Recovery section describes the entities that need to be backed up. Refer to Backup and Recovery Plan for detailed procedures.]

<<Begin text here>>

 

Maintenance

[Description: The Maintenance section describes the regular and scheduled maintenance that will occur and the procedures for that maintenance.]

<<Begin text here>>

 

Monitoring the System

[Description: The Monitoring the System section describes what system components will be monitored and how that will occur. For more details, refer to the Monitoring Plan.]

<<Begin text here>>

 

Securing the System

[Description: The Securing the System section describes what aspects of the system will need security. Refer to the Security Plan for additional detail. There are a number of different aspects to the security of an installation. They can be categorized as follows:

 

 

<<Begin text here>>

 

Performance Planning

[Description: The Performance Planning section identifies which of the solution’s aspects require the highest performance and determines the allocation of resources within the solution to ensure performance goals can be met. Refer to the Performance Plan for additional detail.]

<<Begin text here>>

 

Capacity Planning

[Description: The Capacity Planning section identifies the solution’s capacity requirements and summarizes the allocation of systems/resources (e.g., storage space, processor speed, network bandwidth) that will meet those capacity requirements. Refer to the Capacity Plan for additional detail.]

<<Begin text here>>

 

Problem Management

[Description: The Problem Management section provides an overview of the resources that will be allocated to manage operational problems. Refer to the Support Plan for detailed information on the entire problem management cycle.]

<<Begin text here>>

 

Configuration Management

[Description: The Configuration Management section defines the processes of managing the solution’s configuration, from planning to audit.]

 

Configuration Management Planning

[Description:  The Configuration Management Planning section describes the overall strategy for configuration management, including who is involved, the planning process used, and the strategy to address ongoing configuration management issues.]

<<Begin text here>>

 

Configuration Identification

[Description: The Configuration Identification section defines how configuration will be researched and identified. Deep dependencies exist here upon the Requirements documents from the Functional Specification documents.]

<<Begin text here>>

 

Configuration Control

[Description:  The Configuration Control section describes the process for controlling configuration and the adoption path for configuration selections.]

<<Begin text here>>

 

Configuration Status Accounting, Verification, and Auditing

[Description: The Configuration Status Accounting, Verification, and Auditing section describes how the quality of the configuration process will be assured. This process includes ongoing maintenance reviews, auditing of successes and challenges, and validations of configuration deployments against the Operations Plan, Master Project Plan, and Functional Specification documents.]

<<Begin text here>>

 

Service Level Management

[Description: The Service Level Management section defines the service levels needed to support the solution, including uptime, redundancy, and disaster recovery. It should reference any existing Service Level Agreements and identify necessary extensions to those agreements or new agreements that must be put into place.]

<<Begin text here>>


 

Appendix – Monitoring Guidance

 

[Service monitoring allows the operations staff to observe the health of an IT service in real time. Accurate monitoring of a system is a complicated puzzle within a distributed process environment, complicated even more by the integration with systems operated by trading partners. With this in mind, the following list is an example of system components that are typically monitored to ensure the IT service remains available:

 

 

However, knowing the current health of a service or determining that a service outage may occur is of little benefit unless the operations staff has the ability to do something about it, or at the very least notify the appropriate group that a specific type of reactive or proactive action needs to occur. This is what is meant by the term "control." When combined and implemented properly, this service management function provides the critical capability to ensure that service levels are always in a state of compliance.]