ChangeManagementProcess

VERSION1.0 VersionDate:1May 2006

TableofRevisions
REVISION NUMBER 0.1 0.2 1.0 DESCRIPTIONOFCHANGES(PARAGRAPHANDOR DATEOF REVIEWED/ SECTIONNUMBERSFORREVISIONTRACKING) CHANGE REVISEDBY FinalDraft 2206 BradLytle UpdatedprocedurestoreflectLotusNotesChange 42506 BradLytle Requestsystem FormalImplementation 5106 BradLytle

UNCGProprietary&Confidential

TableofContents

1.0
1.1 1.2

INTRODUCTION .................................................................................................. 4
SCOPEANDOBJECTIVES.................................................................................................................. 4 DEFINITIONS........................................................................................................................................ 4

2.0

CHANGEMANAGEMENTPROCESS................................................................ 5

2.1 PROCESSIMPLEMENTATION.......................................................................................................... 6 2.1.1 STANDARDCHANGES,EMERGENCYCHANGES,ANDOUTAGES............................................ 6 2.1.2 RISKASSESSMENT .......................................................................................................................... 6 2.1.3 IMPACTASSESSMENT..................................................................................................................... 7 2.1.4 CHANGENOTIFICATION................................................................................................................. 7 2.1.5 REQUESTFORCHANGEAPPROVAL ............................................................................................. 7 2.2 ROLESANDRESPONSIBILITIES ...................................................................................................... 8 2.2.1 CHANGEMANAGER ........................................................................................................................ 8 2.2.2 CHANGEADVISORYBOARD.......................................................................................................... 8 2.2.3 CHANGEREQUESTER ..................................................................................................................... 9 2.2.4 CHANGEASSIGNEE ......................................................................................................................... 9 2.2.5 CHANGEAPPROVER...................................................................................................................... 10

3.0

CHANGEMANAGEMENTPROCEDURES....................................................... 10

3.1 CREATINGREQUESTFORCHANGES........................................................................................... 10 3.1.1 STANDARDRFCs........................................................................................................................... 10 3.1.2 EMERGENCYRFCs........................................................................................................................ 11 3.1.3 APPROVALOFRFCs..................................................................................................................... 12 3.1.4 PEERREVIEW ................................................................................................................................. 12 3.2 CHANGEADVISORYBOARDPROCEDURES ............................................................................... 13 3.2.1 CHANGEADVISORYBOARDMEETINGS ................................................................................... 13 3.3 3.4 COMMUNICATINGPLANNEDCHANGES..................................................................................... 14 INFORMATIONSECURITY.............................................................................................................. 14

UNCGProprietary&Confidential

1.0 INTRODUCTION
TheInformation Technology Services(ITS) ChangeManagementprocessisdesignedtocontrol theimplementationofall changesmadetoanydeviceorapplication withintheUNCG productionenvironment. Theacademicandadministrativerequirementsoftheuniversity demandhighlyavailableandfunctionaltechnologyservices.TheITSChangeManagement processexiststoensureITScanprovideahighlevelof availabilityandintegrityinthedelivery of technologyservices.

1.1 SCOPEANDOBJECTIVES
ThescopeoftheITSChangeManagementProcessincludesallinfrastructure,applications,and servicesusedbytheUNCGclientcommunityforbusinessoracademicpurposes. TheobjectivesoftheITSChangeManagementProcessaretoensurethat: All Changesareproperly analyzed,documented,andcommunicatedtoITSstaffandto allfunctionalgroupsandclientspotentiallyaffectedby,orinvolvedin,theirexecution.* DetailsofallChangesaretrackedandstoredinacentralChangeManagementSystemfor thepurposeofhistoricaltrendingandreporting. Proceduresrequiredbefore,during,andafterChangeexecutionandtherespectiveareas ofresponsibilityareclearlydocumentedandpublished. Theproperanalysisandtestingisperformedtoassesstheneedforachangeversusthe potentialimpactofthechange. NoChangeisexecutedwithoutfirstbeingproperlyplanned,documented,peerreviewed, tested,andapproved. *Fordetails,seeSection3.3CommunicatingPlannedChanges

1.2 DEFINITIONS
Change Anymodificationtothesystems,infrastructure,orapplicationsthat comprisetheUNCGproductionenvironment,withtheexceptionof basic objectadministrationtasksthatdonotaffectservicefunctionality. ChangeAdvisoryBoardOrganizationalentityresponsibleforthe assessment,approval,andplanningofchanges. IndividualresponsiblefortheoverallChangeManagementprocessandits properexecution. Requestforchange ArequesttoimplementaChangewithin theUNCG productionenvironment.

CAB

ChangeManager

RFC

UNCGProprietary&Confidential

CMS

ChangeManagementSystemSoftwaretool orcombinationoftools utilizedfortherequest,approval,trackinganddetailsofchanges. TheUniversityofNorthCarolinaat Greensboro InformationTechnologyServices ServiceOperationsCenter

UNCG ITS SOC Production Environment

Allsystem,network,infrastructure,andsoftwarethatsupportsthe technologyservicesutilizedbytheUNCGclientcommunityforbusiness andacademicpurposes. Environmentsutilizedfortestingand developmentarenotconsideredtobeproduction.

2.0 CHANGEMANAGEMENTPROCESS
Toensuretheintegrity,consistencyandavailabilityoftheUNCGtechnologyservices,all changestotheUNCGproductionenvironmentwillbetrackedviaaRequestforchange(RFC). RFCswillbeenteredintoandmanagedviatheChangeManagementSystem(CMS)toensure Changesarecentrally tracked,approved,reportedupon,andenforcedinareliableandconsistent manner. RFCsmustbereviewedandapprovedbytheChangeAdvisoryBoard(CAB)priorto execution toensureaproposedChangedoesnotcompromisethestabilityoftheproduction environment. ChangestotheUNCGproductionenvironmentmustbe: ImplementedusingthestandardChangeManagementProcess. Documentedpriorto,during,andafterChangeexecution. Assessedforrisktotheproductionenvironment,assignedtheappropriateriskleveland handledaccordingtothelevelassigned. Submittedwithimplementationandrollbackplans,aswellasanassessmentof the probabilityoffailure. Peerreviewedbyatleastoneotherqualifiedstaffmember. Coordinatedwithallpeoplerequiredtoimplementandverifyfunctionally. ClassifiedandsubmittedthroughtheChangeManagementprocessastheproperChange typetoensureallaffectedpartiesareawareofandpreparedfortheimpendingChange* Communicatedtotheappropriateusercommunityifthechangehasany potential impact ontheuserbase,includingatemporaryserviceoutage.** Approvedbytheappropriatemanager(s). Monitoredandclosedinatimelymanner.
*ForChangetypedefinitions,seeSection2.1.1 StandardChanges,EmergencyChanges,andOutages **Fordetails,seeSection3.3CommunicatingPlannedChanges

UNCGProprietary&Confidential

2.1 PROCESSIMPLEMENTATION
WhiletheChangeManagementprocessbeginswiththeinitialuserrequestforchange,the informationpresentedinthissectionfocusesprimarilyonthosetasksnecessaryforthe implementationofaproductionchange.

2.1.1 STANDARDCHANGES,EMERGENCYCHANGES,ANDOUTAGES Astiming,impactandotherfactorsvaryduetotheurgencyandnature ofsomeChanges,thereis aneedtodefinestandardstodifferentiatebetweenStandardChanges,EmergencyChanges,and Outages. ForthepurposesofITSprocess, thesedefinitionsarethefollowing: StandardChangeAny Changethatisscheduledandreceivesapprovalforexecution fromtheCABpriortoitsexecution. EmergencyChangeAnychangethathasalevelofurgencythatrequiresitsexecutionto takeplacepriortotheCABhavinganopportunitytoreviewandapproveit.Emergency ChangesmusthaveavalidbusinessjustificationandmustreceiveapprovalfromanITS ManagerandanITSAssociateViceChancellorpriortoitsexecution. OutageAnoutageisalossofoneormoreservicesdeliveredbyITS.Workdoneon infrastructureorapplicationssupportingaservicethatisalreadyunavailableduetoan outage,arenotconsideredaChangeforthepurposesofthisprocessanddonotneedto followtheChangeManagementprocess.ThisworkwillbetrackedviatheIncident ManagementProcessrelatedtotheoutage. TheServiceOperationsandSupportgroup andClientServicesmustbenotifiedofaplanned changeofanykindpriortoitsexecution.

2.1.2 RISKASSESSMENT Anassessmentofriskmustbecompletedonany Changepriortoitsapproval.Thisassessment shouldbedoneataminimumofthreepointsthroughouttheChangeManagementProcess.They are: 1. BytheChangeAssigneeatthetimeof creatingtherequest. 2. BytheChangeApproverpriortoapprovingtherequesttogobefore theCAB. 3. BytheChangeAdvisoryBoardpriortogivingfinalapprovalfortheexecutionofthe change. Inassessingtherisklevelofachange,thefollowingfactorsmustbeconsidered: Probabilityofcustomerimpact Potentiallevelofcustomerimpact

UNCGProprietary&Confidential

Probabilityofsuccess/failure Potentialimpactoffailure Possibilityofrollback Potentialrollbackorrecoverytime

Oncetheappropriatelevelofriskisdetermined,itshouldbebalancedwiththelevelofneedfor thechangepriortomakingtheinitialrequestorateachstageofapproval.

2.1.3 IMPACTASSESSMENT Belowareguidelinesfordeterminingtheappropriatelevelofcustomerimpact: High Medium Low None Any serviceoutageofamissioncriticalsystemorapplication,and/or multipleusersarenotabletoperformtheirnormalbusinessfunctions Serviceoutageofanonmissioncriticalsystemorapplication. Serviceinterruptionwithnonoticeableimpactonendusersabilityto performtheirbusinessfunctions. Noanticipatedimpactontheendusercommunity.

2.1.4 CHANGENOTIFICATION ItistheresponsibilityoftheChangeAssigneetoensure: Anychangetotheproductionenvironmentthathaspotential impacttoservice availability,performanceorusageiscommunicatedtotheaffectedusercommunities.* AllchangesarecommunicatedtotheServiceDesk,ServiceOperationsCenter,and ClientServices. TheRequestforchangeisapprovedby theChangeApprover. AlloftheaboveiscompletedpriortoCABreviewoftheRequestforchange. AllmasscommunicationissentviatheITSCommunicationsOffice.
*Fordetails,seeSection3.3 CommunicatingPlannedChanges

2.1.5 REQUESTFORCHANGEAPPROVAL StandardRequestforchangeAStandardRFCmustreceivetwolevelsofapprovalpriorto execution.ThefirstapprovalmustcomefromtheChangeApprover.Thesecondapprovalmust comefromtheChangeAdvisoryBoard. Emergency RFCAnEmergency RFCmustreceivetwolevelsofapproval. Thefirstapproval mustcomefromtheChangeApprover.Thesecondapprovalmustcomefrom anITSAssociate ViceChancellor.

UNCGProprietary&Confidential

2.2 ROLESANDRESPONSIBILITIES
WithintheChangeManagementprocess,specificrolesandfunctionshavebeendefined.Each roleisultimatelyresponsibleforcompletingspecifictaskswithinthisprocess. 2.2.1 CHANGEMANAGER TheChangeManagerisresponsiblefortheoverallfacilitationoftheChangeManagement process.ResponsibilitiesoftheChangeManagerinclude: CoordinateandchairtheweeklymeetingsoftheChangeAdvisoryBoard. Facilitatetheresolutionofanyscheduleconflictsthatmayarise. MaintainthepoliciesandproceduresnecessarytocarrynecessaryCMfunctions. GrantaccesstotheChangeManagementDatabase. EnsureanynonstandardnotificationofusercommunitiesorPOCsisperformed.

2.2.2 CHANGEADVISORYBOARD TheChangeAdvisoryBoard(CAB)isagroupofindividualsthatrepresentvariousITS and Clientcommunities.Thisgroupisresponsibleforfinalreviewandapproval/rejection ofall standardRFCs.TheCABmeetsataregularlyscheduledintervaltoreviewallpendingRFCs butcanalsoperformtheirfunctionremotely(email,telephone)ifnecessary. Inadditiontothe normalCABmembers,theChangeAssignee(ora staff membersentintheirstead)whohasa pendingRFCsubmittedforreviewbytheCABshallattendboardmeetings. All ChangesarereviewedbytheCABduringitsperiodicmeeting.TheCABhastheauthorityto doanyofthefollowing: Cancelorrejectchanges ApproveRFCsaspresented ReassesstherisklevelofaChange ReassesstheimpactlevelofaChange Requestadditionalinformation priortoapproval

Note:Emergency RFCs,duetotheirurgentnature,maybeperformedwithoutpriorreviewby theCABonlyif writtenapprovalfromanITSAssociateViceChancellorhasbeenreceived.

UNCGProprietary&Confidential

2.2.3 CHANGEREQUESTER TheChangeRequesteristhepersonwhoinitiallyrequeststhataChangetakeplace.Often, thoughnotalways,thisiscarriedoutthroughinitiationofasupportrequesttotheITSService Desk,whichentersandtrackssupportactionsintheRemedyapplication.Insuchacase,the actionrequestisultimatelyassignedtotheperson/organizationwhosefunctionitistoimplement changesoftherequestedtype.TheChangeRequestermustprovidealltherequirementsand objectivesforthechange,includinganexplanationofthereasonandjustificationforthe proposedchange.IftheChangeRequesterdoesnotprovideadequatedetailedinformation,the ChangeAssigneeorChangeApproverhavetheauthoritytorequireitbeforecreatingtheRFC. IntheeventthattheChangeRequestorisalsotheChangeAssignee,thatpersonwillhavethe responsibilitiesofbothroles.TheresponsibilitiesoftheChangeRequesterinclude: Initialescalation/requestforchange(viaServiceDesk,CallTrackingSoftware,etc.). ProvisionofbusinessandtechnicalrequirementstotheChangeAssignee. Resolutionorescalationof Changeissues. Provideinputtotheassessmentofthechangeslevelofrisk. Provideinputtotheassessmentofthechangeslevelofimpact. Changeplanningandcoordination. ReviewoftheChangeplan/documentation. Ensuretheusercommunityaffectedbythechangeisnotifiedpriortothechange implementation. Facilitateanyrequiredclienttestingbefore,duringorafterChangeexecution.

2.2.4 CHANGEASSIGNEE TheChangeAssigneeistheowneroftheChange.ThispersonwillworkwiththeChange Requestor(ifitissomeoneelse)togathertheappropriateinformationrequiredtocreateand representtheRFC.ResponsibilitiesoftheChangeAssigneeinclude: CreationoftheRFCincludingPeerReviewofthechange. Communication andcoordination ofChangetestingandimplementation. MeetwiththeChangeRequester,asneeded,toresolveanyquestionsorproblemswitha proposedchange. Updateanyrelateddocumentationafterthechangehasbeenimplemented. UpdatethestatusoftheRFCandenterallnecessaryinformationintotheCMS,which maybehelpfulforhistoricalpurposes. FollowupwiththeChangeRequestertoprovidestatusontheimplementationsuccessor failure. ProvideclosurestatusintheCMS.

UNCGProprietary&Confidential

2.2.5 CHANGEAPPROVER TheChangeApproveristhemanagerwhoprovidesthefirstlevelofapprovaltoaRFC,allowing ittogobeforetheCABforreview.Inmostcases,thisisthemanageroftheChangeAssignee. Ifthatisnotpossible,theChangeApprovercanbeanyITSmanagerorabove. Responsibilities oftheChangeApproverinclude: Reviewall RFCssubmittedbystaffmembersoftheirgroup Ensureallnecessarycommunication,coordination,documentationandtestinghasbeen completedproperlyonall RFCspriortoapproval Approveall RFCspriortothembeingsubmittedforreviewbytheChangeAdvisory Board

3.0 CHANGEMANAGEMENTPROCEDURES
ChangeManagementprocedureshavebeendevelopedandimplementedthattakeintoaccount theimpactofchangestoUNCGsadministrativeandacademicactivitiesincludingsystem availability,userimpact,systemefficiencyandcurrency/usabilityofdocumentation.Amajor goaloftheprocessdevelopmenteffortwastoestablishasetprocessthatfacilitatedthe coordinationofchangeswithintheUNCGproductionenvironment.Thisprocesswillbe changedasneeded.

3.1 CREATING REQUESTFORCHANGES(RFCS)

3.1.1 STANDARDRFCS ThecreationandsubmissionproceduresforaStandardRFCarebelow,byareaofresponsibility: ChangeAssignee: 1. CompleteaRFCviatheChangeManagementDatabaseinLotusNotes.Completionofthis requestwillrequiretheChangeAssigneeto: a) CheckthecriticalEventsCalendartoensurethattheintendeddateforthechangewillnot conflictwithotheractivities. b) Assesstheriskvs.benefitofthechange(refertoRiskAssessment,section2.1.2),and assignarisklevelforthechange. c) Haveapeerreviewthechangesandannotatethattheyhavereviewedthechangeand concurwiththeplanningofthechange(seePeerReview,section4.1.4) d) CommunicateandcoordinatewithallnecessarysupportandclientpersonnelPRIORto submittingtheRFC.*

UNCGProprietary&Confidential

10

2. OncetheRFChasbeenfullycompleted,submitforapprovalbytheChangeApprover. (This willinitiateanemailnotificationtotheChangeApprover(s)alertingthemtothesubmitted RFC) ChangeApprover: 3. ReviewtheRFCandApproveorRejecttherequest.ApprovalwilladvancetheRFCtothe FirstLevelApprovedstatusandanotificationwillbesenttothenextlevelofapproversfor review.RejectionwillsendanotificationtotheChangeAssigneestatingthattheRFChas beenrejected. ChangeAdvisoryBoard: 4. ReviewthedetailsoftheRFCandapproveorrejecttherequest.Approvalwilladvancethe RFCtotheFinalApprovalstatus.RejectionwillsendanotificationtotheChange AssigneestatingthattheRFChasbeenrejected. ChangeAssignee: 5. ForapprovedRFCs,createaRemedyCaseforthescheduledChange.EntertheRemedy Case#intheRFC. 6. ExecutetheChangeatthescheduledtimeandupdatetheRemedyCaseappropriately. 7. AftertheChangeiscomplete,indicatetheappropriateDispositionoftheChangeintheRFC. UpdatetheRemedyCasewithanydetailsoftheChangeandResolveifappropriate. *Fordetails,seeSection3.3CommunicatingPlannedChanges

3.1.2 EMERGENCYRFCS Emergency Changesareusuallytheresultofactualorimminenthardwareorsoftwarefailures impactingorthreateningtoimpactaUNCGtechnologyservice.Theyareimplementedbefore theChangeAdvisoryBoardhashadanopportunity toreviewthem.TheseChangesmustbe associatedwithaRemedyCaseandmuststillbecommunicatedanddocumentedintheChange Managementprocesswithin24hoursfromthetimeofexecution. Intheeventan Emergency Changeiswarranted,theChangeAssigneewill: 1. Notify aDirector oraboveofthesituationandthatan Emergency Changeisneededand receivewritten approvaltoexecutetheChange. 2. NotifytheServiceDeskandServiceOperationsCenterandprovidesufficientdetailsto enablethemtorespondtocallsfromuserswhomaybeimpactedbythechange,aswellas identifymonitoringalarmsthatmaybeassociatedwiththeChange.Coordinate,as reasonable,anyemergencycommunicationsnecessarythroughtheapprovingDirectoror above.

UNCGProprietary&Confidential

11

3. ExecutetheChange. 4. OncetheChangeiscompleted,notifytheServiceDeskandServiceOperationsCenterand advisethemofthesuccessorfailureaswellasthecurrentstateoftheimpactedenvironment.

5. CompleteaRFCwithin24hoursofresolutionoftheChangeexecution andsubmititfor

approvalbytheDirectororaboveinvolved.

3.1.3 APPROVALOF RFCS WhentheChangeApproverisnotifiedofapendingRFC,they will: 1. ReviewtheRFCtoensuretheappropriateactionshavetakenplace,includingbutnotlimited topeerreviewoftheproposedsolution,planfornotificationoftheusercommunityif required,andcoordinationofchangewithappropriateteams. 2. ApproveorDenytheRFC. IftheRFCisnotapproved, theChangeRequestercan takeone ofthefollowingsteps: a) Cancel therequestcompletely, b) CompletethenecessarystepsasindicatedatthetimeofRejection,andresubmit therequest c) RequestthattherequestbeforwardedontotheChangeApproverssupervisor. TheChangeApproversRejection oftherequestwillremaindocumentedinthe ChangeManagementSystem.

3.1.4 PEERREVIEW OnceaRFChasbeencompletedandisreadytobesubmittedtotheChangeApproverforinitial approval,theChangeAssigneemustrequestareviewoftheRFCfromatechnicalpeerwith similarknowledgeoftheenvironmentwheretheChangewilltakeplace. Thetechnicalpeerwill reviewtheRFCandensurethatthespecifictechnicalstepsplannedappeartobecorrect.Once thisisverified,thetechnicalpeerwillupdatetheRFC,indicatingthattheyhavereviewedthe technicalstepsoftheChange. Note:ThetechnicalpeerchosenforPeerReviewisresponsibleonlyforreviewingandvalidating thetechnicalstepsindicatedintheRFCtocompletetheChangeitself.Thispersonisnot responsibleforensuringotherrequiredsteps(communication,coordination,scheduling,etc.)are taken.ThisresponsibilityisthatoftheChangeAssignee,ChangeApprover,andCAB.

UNCGProprietary&Confidential

12

3.2 CHANGEADVISORYBOARDPROCEDURES
TheChangeAdvisoryBoard (CAB)willmeetperiodicallyforthepurposeofreviewingall pendingRFCs.TheCABwilleitherapproveorrejecteach RFCduringthecourseofthe meeting.

3.2.1 CHANGEADVISORYBOARDMEETINGS TopreparefortheCABmeeting,theChangeManagerwill: Summarizeandcompileall RFCsreceivedprior tothemeetingstarttimeintoareport.This reportwillbecalledtheChangeSummarySheet. Thereportmustcontainsufficient informationforeachchangetoensuretheBoardmembersunderstandandcanevaluatethe changebeingproposed.Thereportcontentswillbefurthergroupedbythefollowing subcategories: NewRequests ExistingRequests Eachreportentrycontains: DescriptionoftheChange LocationofproposedChange LocationsandusercommunitiespotentiallyimpactedbytheChange Impactonendusercommunities NameoftheChangeRequester NameoftheChangeAssignee ScheduledDateandTimeforexecutingtheChange Approval StatusoftheRFC NameofChangeApprover

DistributetheChangeSummarySheettoallmembersoftheCABpriortothescheduled meeting. DuringtheCABmeeting,themembersoftheCABwillreviewanddiscusseach RFCasagroup toensurethatitmeetsallrequirementsoftheChangeManagementProcess.TheCABmaycall upontheChangeAssigneetoansweranyquestionsthatmayariseabouttheirRFCduringthe meeting. AllChangeAssigneeswhohaveaRFCpendingmustattendtheCABmeetingorsenda representativefromtheirdepartmentwhocan properlyrepresentanddiscusstheChange. Failure todosomayresultintheautomaticRejectionoftheRFC. RejectedRFCscanbeupdatedandresubmittedtotheCABforreviewatalaterdate.

UNCGProprietary&Confidential

13

3.3 COMMUNICATING PLANNEDCHANGES

AllplannedChangesthatwillimpact,orhavethepotentialtoimpact,aproductionservicemust becommunicatedtotheusersofthatservicepriortoexecution.Allcommunicationdetailsmust becoordinatedbytheChangeAssigneeandapprovedbytheCABPRIORtobeingsent.All masscommunicationmustbesentviatheITSCommunicationsOffice. TheChangeAssigneeisresponsiblefornotifyingtheServiceDeskandServiceOperations CenterimmediatelybeforeandimmediatelyaftertheexecutionofanapprovedChange.If physicalaccesstothemachineroomisrequiredforanapprovedChange,theChangeAssignee mustbeabletoproduceaprintedcopyoftheapprovedRFCtoServiceOperationsCenter personnelbeforeaccessingthemachineroomtoexecutetheChange.

3.4 INFORMATIONSECURITY
AstaffmemberofITSchargedwithInformationSecuritywillbearequiredmemberoftheCAB andmustattendallCABmeetings.ALL RFCSmustbereviewedforinformationsecurity implicationspriortoCABapproval.Considerationsinthisreviewinclude,butarenotlimited to,: Implicationstothesecurityofpersonalinformation (SocialSecurityNumber,Dateof Birth,etc.) Implicationstothesecurityofuniversitysensitiveorconfidentialdata. Implicationstothesecurityofuniversityequipment. Complianceimplications(HIPAA,FERPA,etc.)

UNCGProprietary&Confidential

14