Change Management Real-World Examples

Change Management Real-World Examples Change Management Real-World Examples - Start

2018-01-06 36K 36 0 0

Description

An overview of the Change Management Process and What Companies are Doing in the Real World. StrataCom, Inc. Overview. Founded in 1997 as an ITSM Consulting Company. Head-quartered in Midwest, offices around the country: MN, ND, WI, SD, NM, FL, VA, NV. ID: 620210 Download Presentation

Embed code:
Download Presentation

Change Management Real-World Examples




Download Presentation - The PPT/PDF document "Change Management Real-World Examples" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.



Presentations text content in Change Management Real-World Examples

Slide1

Change Management Real-World Examples

An overview of the Change Management Process and What Companies are Doing in the Real World

Slide2

StrataCom, Inc. Overview

Founded in 1997 as an ITSM Consulting Company

Head-quartered in Midwest, offices around the country: MN, ND, WI, SD, NM, FL, VA, NV

Niche and focused on

ITSM

Staff entirely comprised of W2 resources

Consultants versed in both process and technical consulting

Resources are primarily very senior, with newest consultants having 7 years of

ITSM

experience

Slide3

Services Offered

ITSM Tool Implementations

ITIL Process Evaluations

ITIL Process Consulting

ITSM Tool Tailoring and Integration Work

Staff Augmentation

Managed Services Offerings around the ITSM Toolsets

Primary Administration

Tool Development and Maintenance

Primary Support and Off-Hours Support

Slide4

What is ITIL?

The Information Technology Infrastructure Library (ITIL) is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business.

In

its current form (known as ITIL 2011 edition), ITIL is published in a series of five core publications, each of which covers an ITSM lifecycle stage.

ITIL

underpins ISO/IEC 20000 (previously BS15000), the International Service Management Standard for IT service management, although differences between the two frameworks do exist

.

Slide5

Is ITIL Useful?

ITIL describes processes, procedures, tasks and checklists that are not organization-specific, used by an organization for establishing integration with the organization's strategy, delivering value and maintaining a minimum level of competency.

It

allows the organization to establish a baseline from which it can plan, implement, and measure. It is used to demonstrate compliance and to measure improvement

.

It is only a ‘Framework’—Guidelines on how to manage IT.

Slide6

What is Change Management?

Change Management is a part of ITIL

ITIL Change Management aims to control the lifecycle of all Changes.

The

primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT

services

Slide7

Function of Change Management?

Ensure that all changes are properly recorded

Ensure that changes are properly categorized within the organization

Ensuring that changes are recorded, risk assessed, categorized, prioritized, planned, tested, evaluated, released, documented and reviewed in a controlled and standard manner

The primary goal of Change Management is to minimize unexpected downtime for the users.

Change Management is NOT a way to speed up change in the organization

Slide8

ITIL Change Management Benefits

Reduced business impact of Incidents by timely resolution

Proactive identification of beneficial enhancements

Availability of business focused information related to SLA’s

Improved monitoring of performance against SLA’s

Better staff utilization leading to greater efficiency

More accurate CMDB information enabling an ongoing audit while registering Incidents

Improved user satisfaction

Less disruption to both IT support staff and

users

Slide9

ITIL Goal of Change Management

Ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of Change-related incidents upon service quality, and consequently to improve the day to day operations of the organization

Slide10

When Should I Implement a Change Management Process

We typically see companies introduce ITIL processes in their organizations in this order:

Service/Incident

Service Desk

Event Management

Problem Management

Knowledge Management

Configuration Management

Change Management

Service Level Management

Request Management

Service Request Catalog

Deployment Management

Slide11

When to Implement Change

We typically recommend that the Service Desk functions are in place first

Problem Management is essential, it will actually help you determine which Changes to initially focus on

Some type of Asset Management is pretty much mandatory.

Changes are recorded against Assets (CIs)

CIs should be mapped to Services if possible, even if the number of services is low

Slide12

Important Change Roles

Change Manager

Change Advisory Board (CAB)

Emergency Change Advisory Board (ECAB)

Slide13

Change Manager

Controls the Lifecycle of the Change

Primary objective is to enable beneficial changes with minimal disruption to IT services

Key to Success: You must have a Change Manager Role in your organization!

This person may also handle the Release Management duties

In smaller organizations, could also be the Problem Manager

Every organization we’ve worked with that has implemented Change Process has a Change Manager

Slide14

Change Advisory Board (CAB)

A group of people that advises the Change Manager in the assessment, prioritization and scheduling of Changes

.

This board is usually made up of representatives from all areas within the IT organization, the business, and third parties such as suppliers

.

We see the CAB arranged in very different ways in different organizations

Slide15

CAB Procedures

Typical organization

CAB board is made up of various individuals from Infrastructure teams, process teams, security teams, etc.

Change requests are ‘Brought before the CAB’ which is typically a meeting that occurs once per week for a duration of a few hours

The floor is open for anyone to discuss the Change requests

Business users are invited to be informed of any changes that may affect their business units, but may not realize that a specific change affects their Business Unit

Typically this type of CAB turns into a Bureaucracy of the worst kind.

Changes with the correct forms filled out are rubber-stamped as good-to-go

Emphasis is not on the quality of the Change’s plan, but the ‘thoroughness’ of the documentation (i.e. is every boxed filled out with something?)

Slide16

A Better Plan…

Electronic CABs may work much better for you

Change approvals are automatically routed to Business owners for approval based on impact to their Business Units by which Services or Vital Business Functions are affected

Important Change procedures like the Implementation Plan and Back Out Plan are evaluated by Subject Matter Experts and approved or rejected

Change Managers have more flexibility managing the Change’s lifecycle when it’s not tied into a single meeting per week

Slide17

Emergency Change Advisory Board (ECAB)

A sub-set of the Change Advisory Board who makes decisions about high impact Emergency

Changes

Membership of the ECAB may be decided at the time a meeting is called, and depends on the nature of the Emergency

Change

ECABs are typically called during ‘War Rooms’ by the Command Center

Normally a ‘quick fix’ for a high-priority Incident

Slide18

How are Companies Utilizing ECABs?

A Change Manager or Incident Manager normally handles this process

Subject Matter experts have already come up with a fix for the Incident. Emphasis is on quick resolution

Approval typically done by the Business Owner of the Service affected

Documentation of Process and Approvals done on the fly and officially recorded after-the-fact

Very common to have an Emergency Change to fix something that went wrong because of a different Change Request

To improve Change Process, post mortems must be done

Slide19

ITIL Change Categories

Change Categories

Normal

Represents ordinary Changes to services, hardware and applications that happen over the lifetime of a service

Standard

Represents usual changes that are repeatedly performed

May be pre-approved

Reduced or no lead times (i.e.: Patch)

Slide20

ITIL Change Categories

Emergency

Changes which are necessary due to an incident or unplanned outage

Approvals may be received after the fact

Emergency changes are usually linked to a high priority incident

Unplanned

Change that occurs outside of the Change Management system or changes implemented without appropriate lead time

Scheduled Implementation before lead time date

Recorded after the fact

Captured from unmatched changes to the CMDB

Slide21

Are Companies following these ITIL Change Standards?

For the most part, yes

Many organizations really struggle to come up with Change Scenarios for their organization

The ITIL Change Processes are a very good place to start

Don’t be afraid to expand on these Categories

Allows you to work on Change Workflows without adding complex logic to existing workflows

Categorization makes reporting and SLAs very easy

Slide22

Other Change Categories We’ve Seen

Minor Change

Well-understood

Changes which do not require the involvement of Release

Management

Incident Change

Change specifically opened because of an Incident

Desktop Change

Changes specifically for Desktops

Many companies have different Change scenarios for:

Easy reporting against those types of changes

Ease of Administration of specific change workflows

Slide23

ITIL Change Lead Times

Change Lead Times

Lead Times apply to Normal Changes

Lead Times are based on the calculated risk score of the change

~ More risk = longer lead times

Lead Times allow enough time for the change to be reviewed and approved prior to approval

Lead Time Examples

High Risk – 10 day lead time

Medium Risk – 5 day lead time

Low Risk – 3 day lead time

No Risk – 1 or 2 day lead time

Slide24

Planning Changes in Downtime windows

Most organizations tie Scheduled Downtime windows to their Business Services

Typically, changes are scheduled during the downtime window

How are most companies scheduling downtime windows?

Standardized downtime window for all Business Services. Normally a number of hours overnight on a weekend

Each Business Service Gets it own unique Downtime Window

Slide25

Standardized Downtimes

A

dvantages

Everyone knows when the changes will occur

Typically scheduled where it will cause the least amount of disruption for the business

Disadvantages

Multiple Changes at the same time may cause issues

What if your change tracking tool has an outage at the same time as the other changes occur?

Slide26

Things to Think About Regarding Downtime Windows

Downtime windows should fit the way you do business

Think about resource availability

It may sound good to have downtimes every Saturday night, but can you get the resources you need if there are issues?

Scenarios like patching 500 windows servers that affect 100+ Services may alter your thinking on downtime windows

Slide27

Other Common Change Management Tools

Forward Schedule of Change (FSC)

A Document that lists all approved Change Proposals and Changes and their planned implementation

dates

Many companies are using software to create the FSC effectively by avoiding Change Conflicts

Not scheduling 2 high-risk changes at the same time

Avoiding scheduling changes that affect the same CI at the same time

Slide28

Change Compliance Report

Reporting that the Change Manager uses to evaluate how the organization is doing regarding changes

Are Changes staying in their allocated downtime and outage windows

Are Changes causing Incidents?

Was the Change successful?

More testing needed?

Was back out plan successful?

Was implementation

documentation correct?

Slide29

Change Review/Approvals

Review by Manager or other entity to ensure readiness for Production

Review by Change Management for completeness and planning

Review by groups affected by Change

Approval by implementing groups on Change

Approval by Change Authority (CAB)

Approvals required are based on evaluated risk

Higher risk applications = more risk/approvals

Industry/Gov’t regulations = more risk/approvals

Minor changes may bypass the CAB approvals

Slide30

Change Implementation

Change Implementations

Most organizations use one master change for planning and approvals

Organize separate parts of change into tasks, which can utilize different groups as implementers

Change should show encompass the full planned time for the change, including time for all tasks

Tasks allow for better reporting and accountability of what parts are successful and what failed

Slide31

Post Implementation Review

Post Implementation Reviews allow for organization to review changes

PIR’s promote better planning for future changes

Can be performed informally or recorded as part of change

Slide32

StrataCom Contact Info

Eric Krueger, Principal Consultant

ekrueger@stratacominc.com

Laura Walker, Director of Business Development

lwalker@stratacominc.com

701-232-5697 x27


About DocSlides
DocSlides allows users to easily upload and share presentations, PDF documents, and images.Share your documents with the world , watch,share and upload any time you want. How can you benefit from using DocSlides? DocSlides consists documents from individuals and organizations on topics ranging from technology and business to travel, health, and education. Find and search for what interests you, and learn from people and more. You can also download DocSlides to read or reference later.