Change Management Living with Change

Transcription

1 Change Management Living with Change

2 Introduction Neil Thomas Industry experience in IT & IT support ITIL Vendor Product Management ITIL Consulting Specialised in Service Catalog & CMDB

3 Introduction 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

4 The Webinar Series Service Catalog Developing a CMDB Incident Management Problem Management Change Management Measuring Service Desk Performance Metrics

5 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

6 If Something Goes Wrong (Incident Management) How Quickly do we Support (Service Level Management) If Something Keeps Goes Wrong (Problem Management) User Needs Something (Service Requests & Service Catalogue) Managing it (Service Portfolio Management & Financial Management) Service Ensuring it s there in the Future (Availability Management & Capacity Management & Service Continuity Management) What Delivers it (Configuration Management) Need to Improve or Resolve Problems (Change Management) Delivering Agreed Changes to Business (Release Management)

7

8 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

9 Where do Changes Originate From Incidents Problems (Known Error s, Workarounds) Process analysis Configuration Management Capacity & Availability Planning The BUSINESS!

10 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

11 Who can raise a change? Anybody? Only IT Staff The Change Manager? The person responsible for the Service? Change Advisory Board

12 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

13 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?

14 Critical Success Factors Controlling Changes Making Quick And Accurate Changes Based On Business Priorities Protecting Services When Making Changes Managing Risk

15 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

16 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

17 Forward Schedule of Change

18 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)

19 Who sits on a CAB? IT Operations Development Security IT Management Vendor Manager Project Manager Vendor representatives Customer Customer Advocate User User Advocate Vendors?

20 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.

21 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.

22 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

23 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

24 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

25 Change & Configuration Mgt Change raised for Server to be upgraded from SP2 to SP3 Server Patched Windows 2003 SP2 Windows 2003 SP3 Previous Current Version Version Change Process commenced Desktop Management IT Staff CMDB Owner notified Current Future Version Version CI updated with a future version MANAGED Unauthorised Changes DISCOVERED

26 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

27 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

28 Horror Stories

29 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

30 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

31 Q & A Time. Confidential, All Rights Reserved, ServiceSphere