Change Management Process Executive Summary

Change Management ProcessUniversity IT Service Management Steering CommitteeFebruary 2016

Change Management Process Design Participants Larry Dillard - Admin Systems Chris Lundin - Shared ServicesMatthew Ricks - ITS Facilities Thuylynh Nguyen - Shared ServicesMarvin Kirkendoll - ITS ITOC Vacilis Kollias - Shared ServicesDavid Macia - Networking Vesna Siracevska - Shared ServicesToai Vo - Admin Systems John Crook (Navvia)Randall Chong - ITS Finance: SoM rep.Raj Lalchandani - Admin SystemsSourabha Mohapatra - Admin SystemsSameer Marella - Admin SystemsCaroline Alemany - Consulting ServicesBhavana Tirukovalluri - Admin SystemsDean Zanardelli - Client Support Operations

Goals Align Change Management Process within University IT to commonITSM practicePrepare for Service Now Technical DesignDefine goals, roles, objectives, approvals and the ChangeManagement business processDefine Scope (and out-of-scope)Define Change types and Risk/Impact matrixDefine PoliciesIdentify areas where Stanford deviates from best practice, limit wherepossible

Output University IT Change Management Process DocumentChange Management Executive SummaryProcess DiagramRisk/Impact QuestionsApproval WorkflowsCommon understanding of Change Management Process

Change Management DefinitionChange Management is the process responsible for managing all Changes tothe Production Operations environment from inception to completion.To be successful in managing change the Change Management process mustensure that all changes are recorded and authorized at the appropriate levelwithin IT and the Business without being overly bureaucratic.Simple (routine, standard) changes would need minimal authorization butshould still go through the process to ensure they are correctly recorded andappropriately tested.Complicated, high impact changes may need to be authorized at the BusinessExecutive level as well as the University IT Executive level before theimplementation is initiated.

Goal of Change ManagementThe goal of the Change Management process is to conduct a formal,standardized methodology in the handling of all Changes in order to betransparent in our work, prevent change-related incidents, minimizenegative impact on delivery of services to our users and clients.Scope of Change ManagementA Change Request is required when there is an addition, modification, orremoval of any IT Service, system or component(s) that are part of aProduction environment as well as all services with agreements thatspecifically state service levels and environment up-time, are subject to theChange Management process and policies.*

Key Policy Changes SLA Alignment : Service Owners must align individual SLA(s) with the ChangeManagement Process.CAB Attendance : All Change Requests must have the Requested By or theirinformed designated representative in attendance to have the Change Requestconsidered for authorization. Core CAB members are required to attend orhave their designee attend the regular CAB meetings.Post Implementation Review : Every emergency, unsuccessful andsuccessful selected random changes must be reviewed for success and anyidentified post-implementation actions will be documented.Unauthorized Changes : Our culture is a zero tolerance for unauthorizedchanges.Integration with Processes : Ensure that the change process is integratedwith other service management processes to provide traceability of changes,detect unauthorized changes and identify change related incidents.

Change Management Roles Requested ForRequested ByAssessorChange ManagerChange ApproverChange Advisory Board (CAB)Emergency Change Advisory BoardInformational Change Requestor ImplementerChange Process OwnerBusiness Owner(ECAB)

Change TypesChange Type UserApprovalLead TimeStandardAvailablePre-Approved **n/aNormalAvailableBased on CI & Impact/RiskBased on Impact/RiskBased on CI & Impact/RiskDoes Not Meet MinimumExpeditedEmergencyP1 Incident Post ImplementationNoneInformational LimitedNo Approvaln/aUnauthorized LimitedNo Approvaln/a** In most cases, design still in process

Risk/Impact MatrixWeighted Dimensions Ability to back-out change Experience of implementing Locations or # Users Impacted Outage Scope / Complexity Business Impact of ChangeLevel Very High 10 Business days CAB High5 Business days CAB Moderate 1 Business days Low0 Days None0 Days

Change Record :Process StatesApproval States DraftAssessmentOpenWork In ProgressCompletedClosed SuccessfulClosed UnsuccessfulClosed CanceledPost Implementation ReviewNot Yet RequestedRequestedApprovedRejected

Change Management : High Level malExpeditedEmergencyRaise and RecordAssess and EvaluateIncidentProcessAuthorize & ScheduleImplementationReview & CloseCreate Change Request record with all necessary informationabout and tasks needed to implement the change includingimpact, back-out plans, scheduled time and downtime required.Review and assess the Normal/Expedited Change record.Ensure that all tasks, assignments, dates and details areappropriate and complete.CAB Review, Approve and Schedule the request, which mayinclude the creation of additional tasks. All necessary approvalsmust be obtained in order for the change to proceed. Onceapproved, the change is scheduled for implementation.The approved implementation tasks are now performed andverified. Remediation (fallback/backout) is implemented ifnecessary.Review and Close the Change record.

Change Management Other Processes Periodic Process Review & ImprovementsHandle Informational ChangeHandle Unauthorized ChangePost Implementation Review

Change Management Process Metrics Backlog of Change RequestsAccuracy of Predictions for ChangeImplementationStakeholder SatisfactionDisruptions caused by ChangesPercentage of Emergency ChangesSuccessful Changes# of Change RemediationIncidents Attributed to ChangesIncomplete Change SpecsIncomplete Impact Assessments Failed ChangesUnauthorized ChangesChanges by TypeChanges by ServiceChanges by Support Group

Benefits Standardization of Change management process within University ITCentralized repository of all changes with linkage to other modulesMinimized impact to users and businessMinimized conflicts between changesCalendar of Forward ChangesAlignment with ITSM best practicesRole and procedural definitionsClarifying process interaction and interdependence

Work Left to be Done : Out-of-Scope for Change RequestThe process design group noted that there are changes which : are not currently managed through the Change Management processdo not have CRQ created when work is donethey have had no issues with making the change(s) in the pastThe group thought that there should be a list of these changes which will remain“Out-of-Scope” of being tracked in the Change Management system until suchtime that an issue arises at which time, they will be evaluated to be moved offthis list and back into scope. During our discussion, examples included: adding a rack or racking a server in a production facility running a new fiber circuit UPS Battery replacement for break/fix (annual refresh remain in scope)What do you want the approval process to be for those items to be included onthe list of changes which do not need to go through Change Management.

Work Left to be Done: The rest Validation of processDesign procedures to fit Stanford’s organizationCommunicate policy & process changesAssigning named individuals to Change Management rolesTechnical design Including Business Approval model based on Risk Map existing processes to new processGo-live workExtending Change Management to others?

Questions:?

ITSM practice Prepare for Service Now Technical Design Define goals, roles, objectives, approvals and the Change Management business process Define Scope (and out-of-scope) Define Change types and Risk/Impact matrix Define Policies Identify areas where S