Change Management
Change Management
ChangeManagementGuide(Version1.1)
1) Purpose
Thepurposeofthisdocumentistoprovideguidancetobridgethegapbetweenthechange managementprocessandproceduresdescriptiondocumentation,ChangeManagementProcessand Procedures,andthedetailedRemedytechnicalchangemanagementusersguides,OTOPChange ManagementQuickGuideSubmitters(andApprovers).
2) Background
AsaresultofthedevelopmentofamoreITILcompliantenvironmentinOTOP,withassociated commonprocessesacrosstheoperatingdivisions,thechangemanagementapprovaland implementationprocessesinNCCandEDSDhavebeenrealignedintoasingle,integratedprocess. Additionally,asingleChangeAdvisoryBoard(CAB)hasbeenestablishedwithmembersfromboth NCCandEDSD,chairedbytheOTOPDeputyDirector.Thisrealignmentnecessitatedthe developmentofnewprocessesandproceduresprescribinghowinformationtechnologysystem changesaresubmittedandapproved.
3) CustomerImpact
Customerimpactmustbeconsideredforallsubmittedchanges.Asdescribedinparagraph4.a.1 below,notificationtimeframeshavebeenestablishbytheOTOPDirectorwheneveranoutageor customerimpactcouldresultfromachangeimplementation.Inordertominimizecustomer impact,changesubmittersshouldmakeeveryefforttomeetthesetimeframesandalsoattemptto keepmostchangescategorizedasnormalchanges.
Page1of14ChangeManagementGuide(V.1.1August1,2011)
4) SubmittingaRequestForChange(RFC)
a. ChangeTypes
FourchangetypesareinuseintheOTOPenvironment:Normal,Standard,Expedited, andEmergency(definedasLatentintheRemedysystem).TheChangeManagement ProcessandProceduresdocumentprovidesdescriptions,processflowchartsforthese changetypesandconsiderabledetail.ChangesaresubmittedviatheRemedysystem andareaccompaniedbyasupportingRequestforChange(RFC)document. NormalChanges:Normalchangesarethemostcommontypeofchange.Theseare changeswhichdonotrequireanyspecialconsiderationsandcanbeappliedwithin thetimeframeestablishedbytheChangeManagementProcessandProcedures document.ChangesthatwillrequireanOEINotification,AgencyMassMailerorCTS Notificationduetoasystemoutageorsignificantsystemchangesaffecting customersrequireatenbusinessdayleadtimefornotificationtothecustomers. Keepthistimerequirementinmindwhendetermininghowsooninadvanceto submitthechange.NormalchangeswillbeprioritizedautomaticallybyRemedyas definedinparagraph4.bbelow.TheworkflowforaNormalChangeisshownin AppendixA. NormalChangesKeyHighlights: RequestsubmittedviaRemedy Approvalprocess(FunctionalApprovers)3businessdays High&mediumpriority(significance)requestsapprovedelectronically byfunctionalstaff,thenroutedforCABapproval. Lowpriority(significance)requestsareapprovedelectronicallyby FunctionalApproversonly. CABhasthefinalapprovalonhighandmediumchanges. Formalmeetingisheldchangesarenotapprovedelectronicallyvia RemedyuntilafterCABmeeting.
gothroughthenormalapprovalcycle/timeframe(e.g.,customerrequest,change directedbyEPAmanagement,vendorsavailability).Forinstance,achangemay requirethatanexternalvendoralsobeavailablewhenthechangeisimplemented. Theexternalvendormayonlybeavailableonthe3rdbusinessdayafterthechange issubmitted,whichcouldbebeforethenextscheduledChangeAdvisoryBoard meeting. AftertheFunctionalApproversapprovetheexpeditedchangerequest,aRemedy notificationwillbesenttothefiveprimaryOTOPCABmembersalongwiththeir fourdesignatedbackups.TheChangeCoordinatororChangeManagerwillsenda followupremindernotificationtotheOTOPCABandthefourdesignatedbackups. TheOTOPCAB(primaryBranchChief)memberwhoownsthechangerequest shouldrespondviaemailwithinonebusinessdaytoRebeccaForbes(Change Coordinator)andTomLagrassa(ChangeManager)withtheanswerofapprove, reject,orneedmoreinformation.TheOTOPCABmembershouldalsocctheother CABmembersandtheCommunicationSpecialistifausernotificationisneeded. NOTE:IftheOTOPCABmemberwhoownsthechangerequestisnotavailable, thentheirdesignatedbackupshouldrespond.IfneithertheprimaryOTOPCAB membernorhis/herbackupisavailablethentheotherprimaryand/ordesignated backupCABmemberwithinthesamedivisionshouldrespond.Ifnoneofthe primaryCABmembersortheirdesignatedbackupsareavailableinthesamedivision thenoneoftheotherCABmembersfromtheotherdivisionshouldrespond.The ChairwilladdressconflictsandrespondwhennoneofthedivisionalOTOPCAB membersareavailable. TheChangeCoordinatororManagerwillupdatetheRemedysystemonbehalfof theCABmemberandperformanynecessaryfollowupifneeded. NOTE:Dependingonwhentheexpeditedrequestwassubmitted,itmaybe discussedattheOTOPCABmeetinginsteadofbeingapprovedelectronicallybyone CABmember.Ifdiscussedatthemeeting,thentheentireOTOPCABwouldvoteon therequestthesamewaytheCABvotesonnormalchangerequest. ApprovedexpeditedchangerequestsarepresentedtothefullCABinaPostChange ImplementationReviewatthenextscheduledCABmeeting.TheExpeditious
Page3of14ChangeManagementGuide(V.1.1August1,2011)
Changeroutingshouldbeusedassparinglyaspossible.Theworkflowforan ExpeditedChangeisshowninAppendixB. ExpeditedChangesKeyHighlights: Follownormalprocessflowwithfasterreviewtime(1businessday)for FunctionalApprovers. ElectronicallyapprovedbyCAB(onlyoneCABapproverneeded)forhigh andmediumpriority.NoformalCABmeetingrequired.(1businessday) CommunicationSpecialistisnotifiedifausernotificationisrequired becauseofanoutageand/orifsystemoperationswillbeaffected. LowpriorityrequestsareapprovedelectronicallybyFunctionalApprovers only.
StandardChanges:AStandardChangeisanormalchangethatwillbeimplemented onaroutine,recurringbasis(e.g.certainDominosystemsmonthlypatches).These changesaresubmittedasNormalChangesthefirsttimetheyareconsidered,but aredesignatedtobecomeaStandardChange.TheChangeSubmittershould indicateintheSummaryfieldthattheyarerequestingthatthisnormalrequest becomeastandardandtheprioritymustbemediumorhighinorderforthechange requesttoberoutedtotheCAB.IfapprovedbytheCABasanewstandardchange, astandardtemplateiscreatedinRemedywithachangenumber.Whenitstimeto implementthestandard,theChangeSubmittershouldresubmittherequestin Remedyusingtheappropriatestandardtemplate.Thischangewillnotgothrough theCABreviewandapprovalprocessagain,however,itwillbeplacedonthe ForwardScheduleofChanges.TheworkflowforaStandardChangeisshownin AppendixC. StandardChangesKeyHighlights: Standardpreapproved,lowrisk,routinechange Followsnormalprocessflowforinitialrequestonly.
Page4of14ChangeManagementGuide(V.1.1August1,2011)
EmergencyChanges:AnEmergencyChangeisachangetocorrectaBreak/Fix condition(e.g.amajorsecurityissuehasbeenfoundinanoperatingsystemanda patchmustbeappliedimmediately).TheEPAFunctionalApprovermustgeta verbalorwrittenapprovalfromanOTOPCABmembertoproceedwiththe emergencyrequest.Oncetherequiredapprovalisreceived,theFunctional ApprovercangiveauthorizationtoaTechnicalPointofContacttoproceedwiththe change.TheemergencyrequestwouldthenbeenteredintoRemedywithinone businessdayfollowingthechangeimplementation.Anotificationwillgooutvia RemedytotheprimaryFunctionalApprovers,OTOPCAB,EDSDandNCC CommunicationSpecialists,ChangeCoordinator,andChangeManager.Emergency changeswillbereviewedbytheCABatthenextscheduledCABmeetingthrough thePostChangeImplementationReviewprocess.TheworkflowforanEmergency ChangeisshowninAppendixD. Emergency(break/fix)ChangesKeyHighlights: OnlyoneCABmemberrequiredtoapprove(<1businessday)approvals receivedfromFunctionalApproververballyorviaemail. CommunicationSpecialistnotifiedifausernotificationisrequiredbecause ofanoutageand/orsystemoperationsareaffected. RequestenteredinRemedywithin1businessdayafterchangeis implemented. Broadcastnotificationthatanemergencychangehasbeenimplemented willbesenttotheCAB,CommunicationSpecialist,primaryFunctional Approvers,ChangeCoordinatorandChangeManager.
Page5of14ChangeManagementGuide(V.1.1August1,2011)
b. Remedy
Anyonechargedwithsubmittingorapprovingachangerequestwillrequireaccessto theRemedysystem(Note:CABapprovalisfacilitatedbytheChange Coordinator/Managersupportpositions).ChangesubmitterslogintoRemedyandare promptedtoenterthechange.Detailedproceduresforenteringandapprovingthe changeinRemedyarecontainedintheRemedyusersguides,OTOPChange ManagementQuickGuideSubmitters(andApprovers).Userssubmittingachange musthaveanawarenessoftheusercommunityandsystemsbeingimpacted,asthe Remedysystemwillrequirethemtoevaluateuserimpactandoverallrisk.Remedy userswillanswerthefollowingfiveriskrelatedquestionsinanonlineforminthe system(byclickingthescaleicon)toassistthemindeterminingtheriskratingonthe DeterminationofUrgency/Prioritymatrix: 1) Isthechangeimplementationplandocumentedtothelevelsothatmorethanone individualcouldexecuteit? 2) Istherollbackplandocumentedtothelevelsothatmorethanoneindividualcould executearollback? 3) Isthereawrittenverificationtestplanthatwillbeexecutedimmediatelyatthe conclusionofthechangetoverifysuccess? 4) Hasthechangebeentestedinanonproductionenvironment? 5) Will thischangebeimplementedoutsideofcorebusinesshours? Userswillalsoassesstheimpact(affectonthepopulationofusers)ofimplementinga proposedchange.TheDeterminationofUrgency/Prioritymatrixhasrisklevelonone axisandimpact(Low,MediumandHigh)ontheother.Impactisdefinedasbelow. ImpactLevel Low Medium High RemedyValue 4Minor/Localized 3Moderate/Limited 2Significant/Large QuantityAffected <150Users 1501,500Users >1,500Users
subjecttoreviewatthenextregularlyscheduledCABmeeting.Thepreviously describedmatrixisillustratedbelow.
V. 2
Impact
<150 users 4-Minor/Localized 150-1,500 users 3-Moderate/Limited >1,500 users 2-Significant/Large
Risk Level 4 or 5
Risk Level
Risk Level 2 or 3
Risk Level 1
a. RFCDocument
Eachnormal,emergency,expeditedandstandardchangesubmittedintoRemedymust beaccompaniedbyanattachedRequestforChange(RFC)document,RFCForm2.1.The RFCcontainsdetailedinformationabouttheproposedchange,suchasdescriptionof thechange,affectedsystems,nameoftheimplementer,proposedchangedate, implementationplan,backoutplan,andotherrelevantinformation.Certain informationintheRFCduplicatesinformationthatiscontainedintheRemedychange record(e.g.,RiskLevel).ThisduplicateinformationshouldbeconsistentandtheRFC documentmustbeattachedbeforethechangerecordissubmittedintothereview process.ProceduresforfillingouttheRFCandhowtoattachitinRemedyaredescribed
Page7of14ChangeManagementGuide(V.1.1August1,2011)
intheRFCdocumentitself.Itcontainsdetailedinstructionsforcompletionalongwith embeddedhelptips.
6) TheChangeManagementProcessafterSubmission
a. FunctionalandTechnicalReview
1) AftersubmissioninRemedy,normalchangeswillbegiventhreedaystobe reviewedbyanestablishedlistofFunctionalApproversinbothNCCandEDSD. Functionalreviewersmaychoosetoconsultwiththeirtechnicalstaffduringthis period,butmustapproveordisapprovethechangewithinthethreedayreview period.TheRFCformissubmittedwithchangesrequestsandattachedtothe Remedychangerecord.TheRFCformcanbeseparatelydistributedtoappropriate partiestosupporttechnicalreviewforthosethatdonothavethenecessary Remedyprivilegestoviewthechangerecorddirectly.Thiscanbeaccomplishedby: a. TheFunctionalApproverdownloadingtheRFCfromRemedyandforwardingit tothetechnicalsupportstaff, b. Or,thetechnicalsupportstaffrequestingtheChangeManagerorCoordinator toforwardtheRFCtothem. 2) Expeditedchangesaregivenaonedayreviewperiod.Again,FunctionalApprovers maycoordinatewiththeirtechnicalsupportteam. 3) Standardchangesarepreapprovedandarenotsubjecttofunctionalreviewother thanduringtheirinitialsubmission. 4) Emergencychangesdonotgothroughthefunctionalreviewprocess. FunctionalApproversareexpectedtoparticipate,eitherinpersonorbyteleconference, intheCABmeetingsinordertoansweranyquestionsortoprovideadviceand assistanceasrequested. IfoneormoreFunctionalApproversdisapproveachangerequest,thechangerequest willbereturnedtotherequestorformoreinformationandresubmittal.Onceachange isrejected,itcannotberesubmittedbytheChangeSubmitter/Initiator.Anewchange requestmustbecompletedandthechangerequestshouldincludetheoriginalchange requestnumber,whytherequestwasrejected,andhowtheissuewasrectified.Care shouldbetakenbyFunctionalApproversnottorejectinadequatelydocumented requests,initially.Thefirstresponsetoinsufficientinformationshouldbetorequest moreinformationviatheRemedysystem.
Page8of14ChangeManagementGuide(V.1.1August1,2011)
b. ChangeAdvisoryBoardReview
TheCABwillnormallymeetonceaweek.Allhighandmediumpriority(significance) normalchangesareroutedtothechangeadvisoryboardforapproval.Inadditionto reviewingandapprovingnormalchanges,theCABperformsthefollowingfunctions: 1) Provideenterpriseriskmanagement,communicationsmanagement,andprocess compliancemanagementtothechangeprocessenvironment. 2) EnsurethatchangestotheEPAinfrastructureorcontractedEPAsystemsare reviewedandprocessedinaccordancewithestablishedChangeManagement processesandprocedures. 3) EnsureallchangesadheretoEPApolicy,aredocumented,tested,andapproved. 4) ProvideoversighttoensurethatEPAChangeManagementprocessdocumentsare maintainedasaConfigurationItem(CI)componentandplacedunderconfiguration managementcontrol. 5) ReportingontheeffectivenessofChangeManagementactivitiestoexecutive leadership. 6) OverruleanyapprovalsordisapprovalsoftheFunctionalApproversonindividual changerequests. ExpeditedchangerequestsnormallybypasstheCABmeetingprocessduetothequick turnaround,butarestillpresentedtooneoftheCABmembersforanelectronic approval.ThefullCABwillreviewexpeditedchanges(alongwithstandardand emergencychanges)atthenextregularlyscheduledCABmeeting. TheDeputyDirectorOTOPisthedesignatedCABChairperson.TherearealsotwoCAB memberseachfromNCCandEDSD.
c. ChangeManager/CoordinatorRole
SubmittedchangeswillbemonitoredbytheChangeManagerand/orChange Coordinator.Thesecontractorsupportpersonnelwillperiodicallyreviewtheprogress ofsubmittedchanges,ensureFunctionalApproversarereviewingandactingonchange requests,andwillcollateandsubmitchangestotheCAB.TheChangeCoordinatorwill alsofacilitatetheCABmeeting,presentingreportssuchastheNext14DayChange Schedule,thePastSevenDaysChangeSchedule,andtheForwardScheduleofChange. Theywillperiodicallyinteractwithfunctionaland/ortechnicalapproverstoshepherd changesthroughthechangeprocessandwillalsoassistandadvisefunctional/technical personnelandCABmembersonprocessandproceduresmatters.AdditionalChange
Page9of14ChangeManagementGuide(V.1.1August1,2011)
ManagerandChangeCoordinatorresponsibilitiesareoutlinedintheChange ManagementProcessandProceduresdocument.
d. ChangeImplementation
OnceanormalchangehasbeenapprovedbytheCAB,itcanbeimplementedin accordancewiththeschedulethatwasapprovedbytheCAB.Ifanychangefails, presentsissues,orcannotbeimplementedforanyreason,aChangePost ImplementationReview(CPIR)formwillbepreparedandtheChangeManagerand/or CoordinatorwillpresentthechangeforreviewatthenextscheduledCABmeeting.
7) CommentsandFeedback
a. Commentsand/orfeedbackonthisdocumentortheChange Managementprocessaresolicitedandshouldbesubmittedtothe following(currentasofAugust1,2011;thesearecontract positionssupportingOTOPChangeManagementoperationsand continuousprocessimprovement):
1) 2) 3) 4) [email protected] [email protected] [email protected] [email protected]
Page10of14ChangeManagementGuide(V.1.1August1,2011)
AppendixA
Page11of14ChangeManagementGuide(V.1.1August1,2011)
AppendixB
Page12of14ChangeManagementGuide(V.1.1August1,2011)
AppendixC
StandardChange ProcessFlow
Technical Peer Review Functional Review Approve?
YES
RFC Raised
NO
CAB Approval?
YES
Change Implemented
NO
RFC Raised
CAB Notified
Must be entered in Remedy in time to be in the Forward Schedule of Change Report for the next CAB meeting.
Page13of14ChangeManagementGuide(V.1.1August1,2011)
AppendixD
Page14of14ChangeManagementGuide(V.1.1August1,2011)