Change Management - Living with Change
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Change Management - Living with Change
Introduction
• Neil Thomas – Industry experience in IT & IT support – ITIL Vendor Product Management – ITIL Consulting – Specialised in Service Catalog & CMDB
• Fully Accredited ITIL Training • Fully Accredited SDI Training • ITIL Consultancy • eLearning • Social Media Training & Consultancy • Industry Webinars (ITSM & SM) • Industry/Organizational Podcasts • SDI Partner for Social Media Courses
Introduction
The Webinar Series
• Service Catalog • Developing a CMDB • Incident Management • Problem Management • Change Management • Measuring Service Desk Performance Metrics
Topics today
• Why Change Management – The Benefits • Why Change Management – The Risks • Change and Configuration Management • Change Advisory Board • Change and Release • Change KPIs and Critical Success factors • Types of Change • Change & the Service Catalogue
If Something Goes Wrong
(Incident Management)
Service If Something Keeps Goes
Wrong (Problem Management)
What Delivers it (Configuration Management)
Need to Improve or Resolve Problems
(Change Management)
Managing it (Service Portfolio
Management & Financial Management)
Ensuring it’s there in the Future
(Availability Management & Capacity Management &
Service Continuity Management)
Delivering Agreed Changes to Business
(Release Management)
User Needs Something (Service Requests & Service Catalogue)
How Quickly do we Support
(Service Level Management)
What is a Change?
A change in IT service accomplished by some change request
The ITIL defines it as any…
‘addition, modification or removal of authorized, planned or supported service or service component and its
associated documentation’
Where do Changes Originate From
• Incidents • Problems (Known Error’s, Workarounds) • Process analysis • Configuration Management • Capacity & Availability Planning • The BUSINESS !
Elements of Change – The Aim
• ITIL-aligned Change Management Policies, Processes and Procedures
• Standardized methods and techniques for efficient handling of changes
• Dedicated Change Manager • Change Advisory Board • Forward Schedule of Changes (FSC) • Published Service Availability (PSA) reports • Proper levels of pre and post Change communications with
customers and users
Who can raise a change?
• Anybody? • Only IT Staff • The Change Manager? • The person responsible for the Service? • Change Advisory Board
Types of Change
• Major Change - Defined as a high risk, involving complex changes altering production systems and difficulty with backup/recovery in the event of an issue. Major changes require review and approval at the Change Advisory Board (CAB) meeting prior to implementation
• Minor Change - Defined as a low risk change, categorized by limited impact to production services, and the ability to adequately test prior to implementation and easily back-out/recover in the event of an issue. Minor changes require review and approval by the technology manager of the group performing the change
• Emergency Change - Requires immediate implementation to correct a disruption or outage of service. Since these changes must be implemented immediately, documentation and approval requirements must be met following implementation
Seven ‘R’s of Change
• WHO is the REQUESTER ? • WHO is RESPONSIBLE for the build, QA and final change
implementation ? • WHAT is the REASON - what necessitates the change ? • WHAT is the expected RETURN from the change ? • WHAT RISK factors are associated with the change ? • WHAT RESOURCES are required to execute the change ? • WHAT is the inter- RELATIONSHIP between this change
and other changes ?
Critical Success Factors
• Controlling Changes • Making Quick And Accurate Changes Based On Business
Priorities • Protecting Services When Making Changes • Managing Risk
Everything’s a Change?
• Anything that changes state must be a change? • Service Requests
– User Hardware Request – Software Request – Business Service Request
• Repeatable, known procedures & outcomes
Forward Schedule of Change
• Diary of agreed & scheduled changes • Highlights multiple changes to the same CI • Highlights changes that contend with each other • Highlights changes that can be grouped together • Maximizes efficiency, minimizes disruption • It must be REVIEWED
Forward Schedule of Change
What is a CAB? & Why have one?
• Change Advisory Board • Mustn’t be too bureaucratic • Clear reasons for decisions taken • Consider ‘virtual’ CAB with electronic voting • Delegated authority to Change Manager • Easy access to changes and applying decisions • Current ITIL Change Management process is perfectly
suited for small to medium size organizations i.e., not too many changes, one Change Advisory Board (CAB)
Who sits on a CAB?
• IT Operations • Development • Security • IT Management • Vendor Manager • Project Manager • Vendor representatives • Customer • Customer Advocate • User • User Advocate • Vendors?
Change Reviews
• Newly submitted requests for change (RFCs) – The CAB reviews change requests and makes a determination to change, reject, or
request more information.
• Review of the minutes from the last meeting – Ensure that people are aware of the decisions made last time and review the status
of any open actions.
• Review change status – Update the status of approved change requests in regard to schedule,
implementation phase, priorities, etc.
• Post Implementation Review – For completed changes, successful or not, review what went good, bad and lessons
learned.
• Review health of the change process – Detect all changes. These changes should then be reviewed by the CAB to ensure
that they tie back to approved changes. If there are unapproved changes, then the CAB should launch an inquiry to determine the source and reason for the change.
– Second, the CAB must ensure that service-level agreements are being met. If not, then corrective actions must be taken.
CAB Structure – Larger Organisations
• Large organizations and/or large number of changes • Change Process may be circumvented if it is considered to be too slow • Solution governance structure • Governance, various ‘levels’ of authority for the approval of changes. • For example use a government model
– 3 levels of authority: Federal, Provincial and Municipal, with the higher governance levels taking precedence over lower levels.
– Allows a degree of autonomy, for example at the local Municipal Level, while still providing the required consistency of process at higher levels
– When too many changes are controlled at the Federal Level, an unacceptable amount of bureaucracy can develop
– If too many changes are allocated to the Municipal Level, then there is a loss of focus on accomplishing Federal Level Change Management objectives. Therefore, it is important to maintain a balance amongst all levels of governance.
CAB Structure – Larger Organisations 2
• Municipal Level Change Managers will have change approval authority for self-contained changes within their municipal area. If a Request for Change impacts some other municipal areas, outside of their own area, then the Request for Change (RFC) is passed onto the appropriate Provincial Level Change Manager for approval.
• Provincial Level Change Manager determines whether the change impacts only their provincial area, in which case the Provincial Level Change Manager may approve the change; or whether indeed the Request for Change impacts another provincial area outside of theirs, in which case the Request for Change is passed onto the appropriate Federal Level Change Manager.
• It is recommended to have only one federal Change Manager. • Federal, Provincial and Municipal, Enterprise, Customer and Service
Change KPIs
Basic Management Information • Number of RFCs processed • Number of RFCs rejected • Number of unauthorized changes detected • Number of RFCs implemented on schedule • Number of RFCs requiring reschedules
Making Quick and Accurate Changes Based On Business Priorities • Number of RFCs marked as URGENT • Number of RFCs not tested prior to implementation
Number of RFCs that failed • Number of RFCs without business case • Number of RFCs bypassing CAB or CAB/EC
Protecting Services When making Changes • Number of SEVERITY 1 incidents caused by RFC implementation • Number of SEVERITY 2 incidents caused by RFC implementation • Number of other incidents caused by RFC implementation • Number of RFCs without a backup strategy
Configuration Management
• Defines WHAT delivers a SERVICE • Defines the RELATIONSHIPS & dependencies • Know WHAT is important and HOW it connects
• Change Process uses IMPACT ANALYSIS – If we did this then WHAT would be the affected – WHO would be impacted
• Step in the Change Process
Change & Configuration Mgt
Current Version
Current Version
Previous Version
Future Version
Server Patched
Windows 2003 SP2 Windows 2003 SP3
Unauthorised Changes DISCOVERED MANAGED
CMDB IT Staff
Desktop Management
Change raised for Server to be upgraded from
SP2 to SP3
Change Process commenced
Owner notified
CI updated with a future version
Benefits of Change Management
• Improved alignment of IT services to business requirements • Increased visibility and communication of Changes to both business
and service-support staff • Improved risk assessment • Reduced adverse impact of Changes on the quality of services and
Service Level Agreements (SLAs) • Improved assessment of the cost of proposed Changes before they
are incurred • Fewer backed-out Changes, also back-outs performed more
efficiently and effectively • Improvements in Problem and Availability Management as they are
able to use valuable management information relating to changes accumulated via the ITIL Change Management process
Benefits of Change Management
• Increased productivity of Users as less disruption and higher-quality services
• Increased productivity of key personnel, reduced number of urgent Changes and the back-out of erroneous Changes
• Greater ability to absorb large volume of Changes increased speed of IT change
• Enhanced business perception of IT, improved quality of service and professional
• Enabling greater business agility • Reduced cost and risk of change with fewer failed changes • Manage release processes for greater efficiency and consistency • Improved infrastructure and quality of service
Horror Stories
Potential Problems • Over-bureaucratic process diminishes the effectiveness and is difficult to administer • Change Management is perceived as a bottleneck • Scope of Change too wide, over-stretching staff and causing delays • Cultural difficulties convincing staff, Customers and Users to accept a single Change
Management system • Compliance to the Change Management procedures by external suppliers • Ownership of impacted systems unclear, resulting in delays and incomplete assessments • Change Management implemented without ITIL Configuration Management results in
solution being less effective • Inaccurate configuration data, poor impact assessments, incorrect individuals consulted
about Change • Poor synchronization of upgrades between platforms and locations, makes it difficult or
impossible to schedule • Back-out procedures are missing or are untested • Progressing Change requests manually is time and resource intensive • Lack of Management support increases implementation times and staff resist controls
unless they see commitment from manager
How to be successful
• AVOID being bureaucratic • PROCEDURES for Minor, Major & Emergency Changes • Well COMMUNICATED & UNDERSTOOD process • AUTOMATED process for ‘standard’ changes • DELEGATED authority to Change Manager • EASY to raise and track a change • Clear REASONS for decisions taken • Clear COMMUNICATION to requestors and to affected
users • AUTHORITY must seen to reside with CAB & Change
Manger to avoid ‘independent’ action
Q & A Time…….
Confidential, All Rights Reserved, ServiceSphere™ 2008 http://www.servicesphere.com
Related Documents
