WIXLIB

Yale University Change Management ProcessGuideYale UniversityChange Management Process1 of 29

Table of ContentsIntroduction . 3Purpose . 3Scope . 3Change Management Overview . 3Change Management Key Concepts . 4Change Management Policies . 5Change Management Process Flow . 6Roles and Responsibilities . 6Process Procedures . 81.0 Request Change . 82.0 Review and Accept Change . 93.0 Assess Technical and Business Impact & Risk . 104.0 Approve Change for Build . 115.0 Build and Test Change. 136.0 Confirm Implementation Schedule and Impact/Risk Review . 147.0 Approve Change for Implementation . 168.0 Implement and Validate Change. 179.0 Close Change . 20Change Process Components. 22Change Types . 22Risk and Impact . 23Change Source . 24Change Submission Priorities . 24Assessment Condition Codes . 25Task Completion Codes . 25Approval Condition Codes . 26Completion / Implementation Codes . 26Closure Condition Codes . 27Process Metrics . 28Document History . 29Yale UniversityChange Management Process2 of 29

IntroductionPurposeThis document will serve as the official process of Change Management for Yale University. Thisdocument will introduce a Process Framework and will document the workflow, roles, procedures, andpolicies needed to implement a high quality process and ensure that the processes are effective insupporting the business. This document is a living document and should be analyzed and assessed on aregular basis.ScopeThe scope of this document is to define the Change Management Process, and process inputs from, andoutputs to, other process areas. Other service management areas are detailed in separatedocumentation. This document includes the necessary components of the Process that have beenconfirmed for the organization.Change Management OverviewWhat is Change Management? Process to coordinate the change needed by businessAuthorizes changes and coordinates change timelines to avoid conflictResponsible for governance, not execution activitiesUltimately to support the change owner and the implementation of a successful changeWhy is Change Management Important? Yale UniversityManages risk and priorityo On average, 80% of incidents caused by changeo Compliance (SOX, ISO9000, etc)o Prioritizes to implement most important changes firsto Rapid change capability for businessMaintains a complete view of change in the organizationChange Management Process3 of 29

Change Management Key ConceptsChange RequestService RequestConfiguration Item Release (andDeployment)Management Request for Change(RFC) Forward Schedule ofChange (FSC) Submission Priority Change Type Yale UniversityOptimize risk exposure.Minimize the severity of any impact and disruption.Proactive: Improve services, reduce costs,maintenance/prevention.Reactive: Resolve known errors and adapt to business changes.Something that can usually be planned for Standard, low/known risk, highly repetitive changes.Well-defined activities that result in the fulfillment.Access to an existing service, requests for information, orsomething that has been pre-approved by the Change AdvisoryBoard.Any Component that needs to be managed in order to deliver an ITService.An IT asset that is deemed valuable to track and manage throughchange control.Either a physical (e.g. server) or logical (e.g. policy) recordrepresenting the actual asset.CI’s are controlled through the change process (or through requestmanagement when changes are deemed to be standard).Release and Deployment Management aims to build, test anddeliver the capability to provide the services specified by ServiceDesign and that will accomplish the stakeholders’ requirements anddeliver the intended objectives.Packaging/bundling of Changes.Provides additional QA and oversight to ensure successful releases.A Request for ChangeRepresents what is being changed, optimally expressed as a CI, whoowns the change, when/where the change is occurring and how it isbeing implementedForward Schedule of ChangeA Document that lists all approved Changes and their plannedimplementation dates.Typically shows upcoming (i.e. non-implemented) changesThe relative priority that a change needs to be implementeddefined by its proposed implementation date/time and the time thechange was submittedChanges logged without optimal time to assess are typically definedas urgent changesThe scope and criticality of a given change, derived from thetechnical impact and riskOften requires some form of assessment to be conducted, coveringa number of key areas to derive a consolidated valueChange Management Process4 of 29

Change Advisory Board(CAB) Jurisdiction Change Advisory BoardAssists the change manager in prioritization, approval /authorization activitiesAssess business consequences of an unsuccessful changeAssist in scheduling the change, taking into account FSC andexternal factors (e.g. resource availability)An organizational entity that may have accountability over specificIT scopeOrganizations with multiple jurisdictions typically have multipleCIOsIT supported directly by the business is not a condition for multiplejurisdictionsChange Management PoliciesThe Change Owner is ultimately accountable for the success of their respective change.The approving Change Manager is accountable for the successful execution of the process, as a meansto mitigate impact and risk for stakeholders/customers.Change Management will manage all changes made to the production environment, including theoperational test environment. This includes changes implemented by vendors and externalorganizations.Effective Risk and Impact Assessment is enforced and is considered the foundation of ChangeManagement.All customers are informed of changes that affect the Service(s) they receive prior to changeimplementation.There is a mechanism to implement URGENT changes to the managed environment with minimumdestabilization of that environment.The number of changes deemed URGENT is reduced to a pre-specified and progressive metric throughproper planning.A CAB exists and the Change Manager is the ultimate decision making authority within the CAB.A Change implementation plan is required prior to change deployment.All Service Providers will fulfill their roles in compliance with the Change Management process.An RFC should not be approved for implementation unless relevant back-out plans are in place.Yale UniversityChange Management Process5 of 29

Change Management Process FlowChange ManagementAssess & EvaluateAuthorize & Plan UpdatesCoordinate Change ImplementationReview & CloseNo1.0 RequestChange2.0 Review& AcceptChangeBuild & TestRequired?StandardChange?NoYes3.0 Change forBuild7.0 ApproveChange forImplementation5.0 Buildand TestChange8.0ImplementAndValidateChange9.0 CloseChange6.0 ConfirmImplementationSchedule er/ d & Review RFCRoles and ResponsibilitiesThe following roles have been identified within the Incident Management Process.RoleChange RequestorDescription Change Owner Approving Change Manager Change Advisory Board (CAB)Yale University The individual asking for a change to be made. May or may not be the changeowner.The requestor should be the person sponsoring or advocating the change, usuallybusiness.Individual stakeholder ultimately accountable for the end result of change, seeingit through its lifecycle. Ex: A Network Engineer may be the change owner for arouter upgradeApproves changes for build-test and implementation for changed owned by theirjurisdictionAccountable for the execution of the change process in support of the changeownerConducts CAB meetingsOversees change processA body that exists to support the authorization and approval of changesAssists Change Management with assessment / prioritization feedbackProvides guidance to the Change ManagerChange Management Process6 of 29

RoleDescriptionChange Assessor Change Builder / ImplementerAuthorizing ChangeManager(s) Change CoordinatorFacilitates changes processAssists the Change Manager and Change Owner throughout the change processResponsible for contributing to the business and technical risk and impactassessment of a change for their domainIndividual responsible for performing the build/test and/or implementationAuthorizes changes where their jurisdiction is impactedParticipates in CAB meetings as requiredThe following illustrates the Responsibility, Accountability, Consulted and Informed (RACI) matrix relatedto the key Change Management Activities:ChangeRequester1.0 RequestChangeAR2.0 Review &Accept ChangeC3.0 AssessTechnical andBusinessImpact/ Risk4.0 ApproveChange forBuild5.0 Build andTest Change6.0 ConfirmImplementationSchedule andImpact / RiskReview7.0 ApproveChange forImplementation8.0 Implementand ValidateChange9.0 CloseChangeProcessMaturity andEvolutionYale angeBuilder AssessorChangeProcessOwnerRRRRRRCARRRRRCCCRChange Management ProcessCCCA7 of 29

Process Procedures1.0 Request Change1.0 Request ChangeRequesterChangeRequesterChange2.01.1 Create /Update RFC1.2 IdentifyImpactedStakeholders1.3 ClassifyChange1.4 IdentifySuccess Criteria1.5 Reference /AttachSupportingDocumentation1.6 Submit RFCFor Acceptance2.0StepActivities1.1 Create /Update RFCIdentify required information, such as contact information, requested schedule business rationale (eg.Functional enhancement to an application or service, increased performance/capacity/availability,resolution/fix to a known error ). It is possible some of these values may be updated by the changecoordinator/manager and/ or owner.1.2 IdentifyImpactedStakeholdersIdentify impacted stakeholders by identifying impacted CI's & services and indicate if they are located inother jurisdictions (change authorization required). Identify if resources will be required from otherjurisdiction(s) to assist in the change.1.3 ClassifyChangeChange requestor will provide the initial classification elements. This includes completing an initialimpact/risk assessment to determine the change type.1.4 IdentifySuccess CriteriaIdentify the Business objectives that will be used by to Validate Change Success after the change hasbeen implemented and prior to closure.1.5 Reference /AttachedSupportingDocumentationInclude all documentation appropriate to the nature of the change Project Charter, Business Case,detailed Change Description , etc) Note: If build-test is in-scope an Implementation plan, back-out plan,communication plan etc. may be included at this time, but are not mandatory.1.6 Submit RFC forAcceptanceOnce the request is complete, submit for acceptance.Yale UniversityChange Management Process8 of 29