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 |
|
Ó 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
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 |
|
Change Notification and Release
Change Building, Testing, and Implementation Monitoring
Post-Implementation Evaluation
Operational Activities <Product/Feature Solution 1>
Configuration Management Planning
[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.}]
[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>>
[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>>
[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>>
[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>>
[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>>
[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>>
[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>>
[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.]
[Description:
The Receipt of Request for Change section describes how the change request will
be tracked and recorded.]
<<Begin text here>>
[Description:
The Change Analysis and Review section describes who analyzes and reviews change
requests and how they are approved.]
<<Begin text here>>
[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>>
[Description:
The
<<Begin text here>>
[Description:
The Change Outcome Notification section describes how people are notified of the
outcome of changes.]
<<Begin text here>>
[Description:
The Post-Implementation Evaluation section describes how change implementations
are reviewed and assessed for success and challenges.]
<<Begin text here>>
[Description:
The Urgent Change Process section describes how urgent changes are
processed.]
<<Begin text here>>
[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.]
[Description:
The Ongoing Operations section describes the various ongoing operational
procedures performed. List all procedures and describe
each.]
<<Begin text here>>
[Description:
The Systems Management section describes the various systems management
procedures performed. List all procedures and describe
each.]
<<Begin text here>>
[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>>
[Description:
The
Maintenance section describes the regular and scheduled maintenance that will
occur and the procedures for that maintenance.]
<<Begin text here>>
[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>>
[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>>
[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>>
[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>>
[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>>
[Description:
The Configuration Management section defines the processes of managing the
solution’s configuration, from planning to audit.]
[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>>
[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>>
[Description: The Configuration Control section
describes the process for controlling configuration and the adoption path for
configuration selections.]
<<Begin text here>>
[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>>
[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>>
[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.]