Change Management Policies and Procedures Guide

Transcription

1 Change Management Plicies and Prcedures Guide Cntents Executive Summary IT Change Management Plicy... 2 Objective... 2 Fundamentals... 3 IT Change Management Defined... 3 The IT Change Management Prcess... 3 Scpe... 5 In Scpe... 5 Out f Scpe... 5 Wrkflw Tasks... 6 Initiating the Change (New Request fr a Change)... 6 Analysis and Initial Apprval Phase... 7 Creating a Request fr Change (RFC)... 8 Assigning the Change Categry... 9 Assigning the Change Pririty... 9 Develpment Phase Develping the Business Case Justificatin Technical Impact Analysis Business Risk and Impact Analysis Risk Level Based Lead Times Lead Time Guidelines Develping the Backut Plan IT Business Unit Manager Review and Apprval Testing Cnducting the Peer Apprval Change Apprval Phase Implementatin and Dcumentatin Phase Final Planning Scheduling and Ntificatins Change Implementatin Testing, Validatin, and Acceptance Change Review and Acceptance Mnitr Change in Prduct in Envirnment... 21

2 Hld Pst -Implementatin Review Accept Issues and Cntinue Measuring Quality in the Change Change Reprts Change Cmpliance Rles and Respnsibilities Change Manager Change Administratr Change Initiatr Change Crdinatr Change Task Assignee r Change Implementer Change Management System Administratr Change Advisry Bard CAB Membership CAB Meetings Vting Rules Key Definitins Executive Summary IT Change Management Plicy Ensuring effective change management is imprtant in ensuring quality delivery f IT services. The intent f this Plicy and Prcedures Guide is t ensure the effective management f change while reducing risk. Key cmpnents t the cmpany s Change Management prgram include: Accurate Dcumentatin Identify the infrmatin relevant t a specific change that needs t be cllected thrughut the change management prcess. Cntinuus Oversight Change Advisry Bard (CAB) The CAB is tasked with balancing the need fr change with the need t minimize risks. Frmal, Defined Apprval Prcess All changes will fllw the established multiple level apprval prcess t ensure rutine changes are cmpleted with minimum restrictins while cmplex, high impact changes receive the versight necessary t guarantee success. Scpe Establish the specific areas that this plicy will cver. Objective The primary bjective f this dcument is t prvide standardized methds and prcedures t meet the change management requirements supprting the cmpany s peratins. The business prcesses detailed in this dcument meet the fundatin requirements fr industry best practices as detailed within the Infrmatin Technlgy Infrastructure Library (ITIL) directly relating t IT change management.

3 It is imprtant t nte that nt all the ITIL best practices fr IT change management are included in this dcument. Fllwing these guidelines will ensure all infrmatin technlgy changes satisfy the Cntrl Objectives fr Infrmatin and Related Technlgies (COBIT) elements related t IT change management. This will ensure the day-t-day IT functins perfrmed t prvide effective change management t satisfy including Sarbanes- Oxley crprate gvernance audit requirements. In additin t meeting all f the audit requirements, these guidelines will prvide a prcess fr efficient and prmpt handling f all IT changes cmpleted by the IT rganizatin. Key Gals: Establish clearly defined best practice prcesses t ensure cmpliance with the SOX requirements as measured using standard COBIT measurement elements Imprve efficiency using autmated tls and a centralized data depsitry Imprve cmmunicatin thrugh autmated escalatins and ntificatins Ensure prper level f apprvals Reduce risk assciated with cmpleting changes Reduce the impact f changes n the IT and business rganizatins Fundamentals This sectin describes the definitin, basic prcesses, and scpe f Change Management fr the IT Change Management rganizatin. IT Change Management Defined IT Change Management is the prcess f requesting, analyzing, apprving, develping, implementing, and reviewing a planned r unplanned change within the IT infrastructure. The Change Management Prcess begins with the creatin f a Change Request within the cmpany s selected technlgy platfrm. It ends with the satisfactry implementatin f the change and the cmmunicatin f the result f that change t all interested parties. The IT Change Management Prcess The primary gal f the IT change management rganizatin is t accmplish IT changes in the mst efficient manner while minimizing the business impact, csts, and risks. All IT changes within the cmpany will be dcumented in the cmpany s selected technlgy platfrm. T achieve this, the change management prcess includes the fllwing primary steps (nte that all infrmatin cllected in the steps belw is dcumented in a Change Recrd created in the cmpany s selected technlgy platfrm): Frmally Request a Change. All requests fr change will be dcumented within the cmpany s selected technlgy platfrm by creating a new change recrd. The cmpletin f a new request fr change will be cmpleted by the Change Crdinatr with input frm the Change Requester. Categrize and Priritize the Change. The Change Crdinatr will assess the

4 urgency and the impact f the change n the infrastructure, end user prductivity, and budget. Analyze and Justify the Change. The Change Crdinatr wrks with the change requester and the change initiatr t develp specific justificatin fr the change and t identify hw the change may impact the infrastructure, business peratins, and budget. The Change Crdinatrs use this infrmatin t further research and develp an extensive risk and impact analysis. When cmpleting the analysis f the change, the Change Crdinatr must ensure they cnsider the business as well as the technical impacts and risks. Apprve and Schedule the Change. The Change Crdinatr uses the cmpany s selected technlgy platfrm t recrd an efficient prcess fr ruting the Request fr Change (RFC) t the Change Crdinatr, technical apprvers, business apprvers and, in the event f a majr r significant change, t the Change Advisry Bard (CAB) fr apprval r rejectin f the change. Plan and Cmplete the Implementatin f the Change. This prcess includes develping the technical requirements, reviewing the specific implementatin steps and then cmpleting the change in a manner that will minimize impact n the infrastructure and end users. Pst -Implementatin Review. A pst-implementatin review is cnducted t ensure whether the change has achieved the desired gals. Pstimplementatin actins include deciding t accept, mdify r back-ut the change; cntacting the end user t validate success; and finalizing the change dcumentatin within the cmpany s selected technlgy platfrm. The figure belw shws the change management phases.

5 Scpe Because the Change Management Prcess deals with the management f changes in the prductin envirnment, it is imperative that bth custmers and the cmpany s change rganizatin understand the events that are cnsidered within the scpe f the prcess. In this sectin, the scpe is described and includes areas which are bth within and utside f the change management prcess scpe. In Scpe The intended scpe f the Change Management Prcess is t cver all f the cmpany s r clients cmputing systems and platfrms. The primary functinal cmpnents cvered in the Change Management prcess include (Nte: Fllwing are examples nly yur specific areas may differ): SDLC Changes handled thrugh the frmal sftware develpment life cycle will be included within the cmpany s change management prgram. Hardware Installatin, mdificatin, remval r relcatin f cmputing equipment. Sftware Installatin, patching, upgrade r remval f sftware prducts including perating systems, access methds, cmmercial ff-the-shelf (COTS) packages, internally develped packages and utilities. Database Changes t databases r files such as additins, rerganizatins and majr maintenance. Applicatin Applicatin changes being prmted t prductin as well as the integratin f new applicatin systems and the remval f bslete elements. Mves, Adds, Changes and Deletes Changes t system cnfiguratin. Schedule Changes - Request s fr creatin, deletin, r revisin t jb schedules, back-up schedules r ther regularly scheduled jbs managed by the cmpany s IT rganizatin. Telephny Installatin, mdificatin, de-installatin, r relcatin f PBX equipment and services. Desktp Any mdificatin r relcatin f desktp equipment and services. Generic and Miscellaneus Changes Any changes that are required t cmplete tasks assciated with nrmal jb requirements. Out f Scpe There are many IT tasks perfrmed at the cmpany, either by the IT department r by the end users that d nt fall under the plicies and prcedures f Change Management. Tasks that require an peratinal prcess, but are utside the initial scpe f the cmpany s Change Management prcess includes: Cntingency/ Disaster Recvery Changes t nn-prductin elements r resurces Changes made within the daily administrative prcess. Examples f daily administrative tasks are:

6 Passwrd resets User adds/ deletes User mdificatins Adding, deleting r revising security grups Rebting machines when there is n change t the cnfiguratin f the system File permissin changes The Change Advisry Bard (CAB) may mdify the scpe peridically t include items in the scpe f the cmpany s verall Change Management prcess. Wrkflw Tasks This sectin describes the basic tasks assciated with the Change Management prcesses fr the cmpany. The fllwing diagram prvides a high level verview f the wrkflw fr the change management tasks. Initiating the Change (New Request fr a Change) Within the cmpany, changes are identified by the business unit r help desk within an IT business unit. Anyne identifying a requirement fr a change functins as the Change Initiatr and is respnsible fr prviding the necessary infrmatin t identify the basic requirements assciated with the change.

7 It is critical that the Change Management Prcess is cnsistent in quality and cmpleteness and discards irrelevant requests. Althugh a change request can be submitted by anyne within a business r IT unit, it will receive an initial review by the Change Crdinatr within the apprpriate IT business unit. Change Initiatr s can identify the need fr a change thrugh the Custmer Help Desk r directly t a Change Crdinatr in the IT Business Unit by phne r . The Change Crdinatr will determine if there is sufficient infrmatin t create the change request and will create a new change request within the Service Center Change mdule. They will cntact the Change Initiatr if additinal infrmatin is required. Nte 1: In the current Custmer change prcess, the IT Business Unit nrmally initiates changes based n their findings r a cnversatin with the relevant business unit. In these cases, the persn in the IT Business Unit will functin in the rle f Change Initiatr and may als functin in the rle f the Change Cr d inatr. Nte 2: Future enhancements will prvide the ability fr Change Initiatrs t submit an initial request fr change using a web based tl. Analysis and Initial Apprval Phase During the creatin f the new change request, the Change Crdinatr will cllect additinal infrmatin t help them further define the change parameters. This additinal infrmatin includes identifying specific cding r ther technical

8 requirements as well as establishing the initial pririty and categry. The diagram belw shws a mre detailed wrkflw f the analysis phase which includes the actual creatin f the change request, establishment f the initial pririty level, and the apprval at the IT business unit level. Creating a Request fr Change (RFC) The Request fr Change (RFC) is the standard dcument created by the Change Crdinatr within the cmpany s selected technlgy platfrm that captures all the relevant infrmatin abut the prpsed change. This infrmatin may range frm basic facts abut the change t mre cmplex technical specificatins necessary t cmplete the change. The Change Crdinatrs will wrk with the Change Initiatrs t identify as much f the fllwing infrmatin as pssible: The Change Initiatr s name and cntact infrmatin The Change Crdinatr s name and cntact infrmatin An accurate descriptin f the change required including the specific request, reasn the change is required and the required timeframe The pririty and categry f the change based n the infrmatin available Incident tracking number f any issue that relates t the change Descriptin and clarificatin f any items t be changed, including identificatin f the Cnfiguratin Item if knwn A cst-benefit analysis f the change and budgetary apprval, if required Business impact and resurce assessment Lcatin f the release and a suggested implementatin plan with timescale Impact n business cntinuity and cntingency plans Risk invlved in making the change

9 Assigning the Change Categry The Change Crdinatr will initially categrize the Change. The fllwing change categries and subcategries will initially be available: Categry Sub-Categry Systems - Hardware Accessries Systems - Hardware AS400 Systems - Hardware Database Systems - Hardware Mainframe Systems - Hardware Netwrk Systems - Hardware Servers Systems - Hardware Telc Prductin Migratin AS400 Prductin Migratin Client/ Server Prductin Migratin Database Prductin Migratin Mainframe Prductin Migratin Netwrk Prductin Migratin NT Ntes Prductin Migratin Unix/ Linux Categry RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced RFC - Advanced Sub-Cat egry business applicatins facilities imac netwrk ther prcurement security service management shared infrastructure telecms training user admin Categry Sftware Sftware Sftware Sftware Sftware Sftware Sftware Sftware Sftware Sftware Sftware Sftware Sub-Categry Accunting Apps Business Planning Apps E-Cmmerce Apps Human Resurces Apps Lgistics Apps Other Database Apps Other Mainframe Apps Other Netwrk Apps Payrll Apps Purchase Apps Stre Apps Supply Chain Apps Categry SDLC SDLC SDLC SDLC SDLC SDLC SDLC SDLC SDLC SDLC SDLC SDLC Sub-Categry Accunting Apps Business Planning Apps E-Cmmerce Apps Human Resurces Apps Lgistics Apps Other Database Apps Other Mainframe Apps Other Netwrk Apps Payrll Apps Purchase Apps Stre Apps Supply Chain Apps Categry Systems - Cnfiguratin Systems - Cnfiguratin Systems - Cnfiguratin Systems - Cnfiguratin Systems - Cnfiguratin Systems - Cnfiguratin Systems - Cnfiguratin Sub-Categry Accessries AS400 Database Mainframe Netwrk Servers Telc Categry Scheduling Scheduling Scheduling Scheduling Scheduling Scheduling Sub-Categry Client/ Server Database Mainframe Netwrk NT Ntes Unix/ Linux Additinal change categries will be added as the new change frms are created t meet specific business needs. Assigning the Change Pririty The Change Management system has been designed t default t a rutine pririty fr the end user cmmunity. The Change Crdinatr will have authrity t adjust the pririty level as required t meet the business needs. There are fur levels f Change pririties which include:

10 Emergency A change that, if nt implemented immediately, will leave the rganizatin pen t significant risk (fr example, applying a security patch). High A change that is imprtant fr the rganizatin and must be implemented sn t prevent a significant negative impact t the ability t cnduct business. Rutine A change that will be implemented t gain benefit frm the changed service. Lw A change that is nt pressing but wuld be advantageus. Nte: Emergency changes must be kept t an abslute minimum due t the increased risk invlved in implementing them. Develpment Phase The diagram belw shws the detailed steps fr develping the business case justificatin, including: Cmpleting a risk and impact analysis Develping specific change requirements Identifying a back-ut plan and receiving peer apprval Nte that all the infrmatin cllected during these stages shuld be dcumented in the cmpany s selected technlgy platfrm.

11 Develping the Business Case Justificatin Fr all change categries, the Change Crdinatr must develp a Business Case Justificatin, including the requirements f the change that will be attached t the RFC fr cnsideratin in the analysis prtin f the prcess. The business case infrmatin is dcumented in the Change Descriptin field within the cmpany s selected technlgy platfrm. The fllwing questins are relevant infrmatin that shuld be addressed during develpment f the business justificatin: The requirements and detailed descriptin f the change Describe the impact the change will make n the business unit s peratin Describe the effect the change may have upn the end user, business peratin, and infrastructure if knwn Describe the impact n ther services that run n the same infrastructure (r n sftware develpment prjects) Describe the effect f nt implementing the Change Estimate the IT, business and ther resurces required t implement the Change, cvering the likely csts, the number and availability f peple required, the elapsed time, and any new infrastructure elements required Estimate any additinal nging resurces required if the Change is implemented Technical Impact Analysis This sectin describes the criteria a technical reviewer must cnsider when evaluating the technical impact f a change. The technical impact and risk analysis is dcumented within the cmpany s selected technlgy platfrm mdule s Impact fields. After the Change Crdinatr reviews, categrizes, and priritizes the RFC, they will assign a resurce depending n the type f change and cmplexity, t perfrm a technical analysis f the change. This prcess is intended t evaluate and validate the technical feasibility, risk and effect a change will have n the prductin envirnment and end user prductivity. The Technical Apprver shuld cnsider the fllwing criteria while reviewing any change: Evaluate the change plans t gauge the impact and effect f the change during and immediately fllwing the change implementatin. Review the technical cmpleteness f the change plan, including anticipated assets changed, impact n start-up r shut dwn f systems, impact n disaster recvery plans, back-up requirements, strage requirements, and perating system requirements. Evaluate the technical feasibility f the change and the whle impact f the change in terms f: Perfrmance Capacity Security

12 Operability Validate technical aspects, feasibility, and plan. After the technical impact assessment is cmplete, the reviewer must assign a technical impact level t the change. The technical impact levels are described in the sectins belw. Lw Fr rutine categries, the technical impact default is lw. If the evaluatin f the technical impact crrespnds with the criteria belw, the technical impact will be designated as lw. The technical impact criteria include: Invlves IT resurces frm ne wrkgrup within same IT divisin Lw cmplexity n technical crdinatin required Lw risk t system availability (system/ service utage affecting clients during Nn-Prime Time) Easy implementatin and back-ut N impacts t service level agreements Medium The cmpnents f a medium technical impact include: Invlves IT resurces frm mre than ne wrkgrup within same IT divisin Significant cmplexity technical crdinatin required frm ne r mre functinal grups Mderate risk t system availability (system/ service utage expsure during Prime/ Peak Times, utage primarily expected during Nn- Prime Time) Sme cmplexity t implementatin and back-ut plans, back-ut nt expected t extend the windw timeframe Affects applicatin, data r server security Impacts service level agreements (e.g. Business Nn-Prime Time) and internal supprt required High A technical impact is classified as high if the fllwing criteria apply t the change: Invlves IT resurces frm mre than tw wrkgrups, crsses IT divisins High cmplexity cmplex technical crdinatin required with ne r mre functinal grups High risk t system availability (system/ service utage expected during Prime/Peak Times) Cmplex implementatin and back-ut plans, back-ut likely t extend the windw timeframe Affects security f data n infrastructure Impacts service level agreements (e.g. Business Prime/Peak Time) Outside vendr supprt is typically required

13 Business Risk and Impact Analysis This sectin details the ptential infrastructure and business risks and impacts assciated with a change, and the criteria necessary t assign a risk level t a change. The Change Crdinatr wrks with the business units clsely assciated r impacted by the prpsed change t cnduct a business risk and impact analysis. The business risk and impact analysis is cmpleted when a new change recrd is created. The business risk and impact prcess evaluates the impact f the change as it relates t the ability f the cmpany t cnduct business. The key bjective is t cnfirm that the change is cnsistent with current business bjectives. The fllwing pints shuld be cnsidered while perfrming the business risk and impact assessment: Evaluate business risk/ impact f bth ding and nt ding the change Analyze timing f the change t reslve any cnflicts and minimize impact Ensure all affected parties are aware f the change and understand its impact Determine if the implementatin f the change cnflicts with the business cycle Ensure current business requirements and bjectives are met. When the Change Crdinatr analyzes the change, they have the respnsibility f initially assigning a risk level fr all categries. Risk levels have been established based n the answers t the fllwing questins: Custmer and/r Client Impact High (4) Impacts several internal and/ r external custmers, majr disruptin t critical systems r impact t missin critical services. Mderate (3) Impacts several internal custmers, significant disruptin t critical systems r missin critical services. Lw (2) Impacts a minimal number f internal custmers, minimal impact t a prtin f a business unit r nn- critical service. N Risk (1) N impact t internal custmers, as well as n impact t critical systems r services. IT Resurce Impact High (4) Invlves IT resurces frm mre than tw wrkgrups and crsses IT divisins r invlves expertise nt currently staffed. Mderate (3) Invlves IT resurces frm mre than tw wrkgrups within the same IT divisin r invlves expertise that has limited s t a f f i n g. Lw (2) Invlves IT resurces frm ne wrkgrup within same IT divisin. N Risk (1) Invlves a single IT resurce frm a wrkgrup. Implementatin Cmplexity High (4) High cmplexity requiring technical and business crdinatin. Mderate (3) Significant cmplexity requiring technical crdinatin nly. Lw (2) Lw cmplexity requiring n technical crdinatin. N Risk (1) Maintenance type f change

14 Duratin f Change High (4) Change utage greater than 1 hur and affecting clients during Prime/ Peak times. Lengthy install and back-ut. Mderate (3) Change utage less than 1 hur during Prime/ Peak times r greater then 1 hur during Nn-Prime times. Lw (2) Change utage less than 1 hur during Nn-Prime times and affecting clients during Nn-Prime times. N Risk (1) N utage expected. Security High (4) Affects critical data r server security and the back-ut wuld likely extend the windw timeframe. Mderate (3) Affects nn-critical data r server security and has a mderate back-ut plan which wuld nt extend windw timeframe. Lw (2) N security issues and easy back-ut plan. N Risk (1) N back-ut plan needed. Service Level Agreement Impact High (4) Impacts SLA during business Prime/ Peak times. Mderate (3) Impacts SLA during business Nn-Prime times. Lw (2) Little measurable effect n SLA times. N Risk (1) N effect n SLA times. RANGE RISK High Mderate 12 7 Lw 6 1 N Risk Apprvals Required fr Change Based n Risk Level Required apprvals are based n the Change Categry, Risk Level and the Pririty. The required apprvals are shwn in the table belw. The Peer Review apprvals are cnditinal depending n the respnse t the questin, Peer Reviewer Requested? Change Categry Prductin Migratin Pririty Risk Level Emergency Urgent Rutine Lw N Risk N Risk Assignment grup Assignment grup Assignment grup Assignment grup Mgr f Mgr f Mgr f Mgr f Assignment grup Assignment grup Assignment grup Assignment grup

15 Pririty Change Categry Risk Level Emergency Urgent Rutine Lw Hardware High Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review, Peer Review, Peer Review, Peer Review, CAB CAB CAB CAB Mderate Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review Peer Review Peer Review Peer Review Lw Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review Peer Review Peer Review Peer Review N Risk Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review Peer Review Peer Review Peer Review Change Categry Pririty Risk Level Emergency Urgent Rutine Lw Sftware High Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review, Peer Review, Peer Review, Peer Review, CAB CAB CAB CAB Mderate Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review Peer Review Peer Review Peer Review Lw Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review Peer Review Peer Review Peer Review N Risk Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry subcategry, Peer Review Peer Review Peer Review Change Categry Pririty Risk Level Emergency Urgent Rutine Lw Retail Systems High Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review, Peer Review, Peer Review, Peer Review, CAB CAB CAB CAB Mderate Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry,

16 Peer Review Peer Review Peer Review Peer Review Lw Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review Peer Review Peer Review Peer Review N Risk Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry subcategry, Peer Review Peer Review Peer Review Scheduling High Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review, Peer Review, Peer Review, Peer Review, CAB CAB CAB CAB Mderate Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review Peer Review Peer Review Peer Review Lw Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry, subcategry, Peer Review Peer Review Peer Review Peer Review N Risk Assignment Assignment Assignment Assignment subcategry, subcategry, subcategry subcategry, Peer Review Peer Review Peer Review Risk Level Based Lead Times It is essential that requests fr change are submitted and apprved in a timely manner. This will allw cmpletin f accurate dcumentatin, change prcessing and btaining the apprvals in sufficient time prir t the requested implementatin date. Lead times are the number f days an actin (Initiatin r Apprval) must be cmpleted prir t the requested implementatin date. The number f days will vary, depending n the pririty and the risk level. Lead Time by Change Phase Pririty Risk Level Initiatin Apprval Emergency High 3 3 Mderate 2 2 Lw 1 1 N Risk 1 1 Urgent High 6 3 Mderate 4 2 Lw 2 1 N Risk 1 1 Rutine High Mderate 15 7 Lw 10 5 N Risk 5 3 Lw High 25 15

17 Mderate Lw 15 7 N Risk 10 5 Lead Time Guidelines It is essential that requests fr change are submitted and apprved in a timely manner. This will allw cmpletin f accurate dcumentatin, change prcessing and btaining the apprvals in sufficient time prir t the requested implementatin date, and prvide fr cnflict reslutin fr scheduling f changes. Lead times are the number f days an actin (Initiatin r Apprval) must be cmpleted prir t the requested implementatin date. The number f days may vary depending n the pririty and the risk level. The Risk Wrksheet which is required t be cmpleted fr each change will assist Change Initiatrs t determine risk ptential. Preferably, high risk and/ r large change requests shuld have several weeks (r even mnths) ntice prir t the requested implementatin date. Lead Times fr each change will vary depending n the type f change. Change Initiatrs shuld plan lead times t allw sufficient time fr planning, review, and apprval. In sme cases, lead times wuld als need t be planned t allw fr standard implementatin times that have been set fr certain prcesses like the SDLC Apprval prcess. Develping the Backut Plan Develpment f the back-ut plan is essential t ensuring effective recvery in the event f a failed change. The back-ut plan is primarily based n the technical impact analysis and the implementatin plan. IT Business Unit Manager Review and Apprval Fllwing the submissin f the new RFC, it will be screened by the IT business unit manager wh determines whether t authrize r deny the change based n the infrmatin in the new change recrd. This screening prcess includes a reality check t ensure that the RFC is apprpriate, and t ensure the request is cmplete. The manager can elect t apprve, deny r request additinal infrmatin frm the change initiatr. The Change Initiatr is ntified f the prgress f their request at all stages. Testing All change categries will underg sme level f testing depending n the cmplexity f the change. Once the change is built, cnfigured and integrated in the develpment envirnment, the change is mved t the Test/ QA envirnment. This phase fcuses n cnducting testing and quality assurance t ensure reliability and perfrmance f all cmpnents f the rganizatin s technlgy infrastructure. The Change Crdinatr will versee the testing functin, develp the test plan and reprt its findings back t the CAB fr vting n whether t advance the change t the next step. Cnducting the Peer Apprval Peer apprvals are the last step f the Change Develpment Phase. Peer apprvals are ptinal fr all changes cmpleted by a custmer IT business unit. This step ensures that all the technical cmpnents and ntificatins have been cmpleted as

18 required by the Change Advisry Bard. This apprval can be cmpleted by anyne apprved by the IT business unit manager and identified as a Peer Apprver in the cmpany s selected technlgy platfrm. Peer apprvals are cmpleted using a checklist which is attached t the change recrd. Change Apprval Phase After a minr, majr r significant change has been crrectly priritized, categrized, and analyzed by the Change Crdinatr and been thrugh the Peer Review prcess, the change must be authrized fr implementatin. The diagram belw identifies the wrkflw assciated with change management apprval at the cmpany: The prcess f authrizing a change request depends upn the categry and pririty f the change and will be handled in the fllwing manr: Emergency pririty changes are escalated t the apprpriate IT business unit manager fr fast- track apprval. All emergency changes will be entered the cmpany s selected technlgy platfrm (after the fact) and tracked by the CAB. Rutine changes are apprved by the apprpriate IT Business Unit Manager and prgress directly t the change implementatin phase. Minr changes can be apprved by the Change Crdinatr r the apprpriate IT Business Unit Manager r apprpriate peer apprval. All ther majr and significant changes must be apprved by the established apprval authrity as identified in the change recrd. Apprval authrity level is dependent n the change categry. Changes that are maintenance types f changes, usually within the peratins and systems supprt areas, can be apprved at the manager level, but will usually invlve a peer review nly. In each case, the apprpriate persn r bdy decides n whether the change shuld be implemented based n the infrmatin supplied in the RFC. If the RFC is rejected, the RFC is clsed and the Change Initiatr is infrmed f the

19 decisin. The reasns fr the rejectin are added t the change r e c r d. Implementatin and Dcumentatin Phase Once an RFC is apprved, it mves int the Implementatin and Dcumentatin Phase. This phase is cncerned with the steps necessary t successfully implement the change: Cmplete final planning Establish the schedule and cmplete required ntificatins Cmplete the change implementatin Test, validate and accept the change Cmplete final change dcumentatin The diagram belw shws the steps and wrkflw assciated with cmpleting the change: Final Planning During this step the Change Crdinatr reviews all cmments and recmmendatins t ensure all required tasks have been cmpleted. They cnduct this review with the IT business unit manager, the change implementer and the change initiatr. This phase is als used by the change implementer t cmplete any final change develpment necessary t cmplete the implementatin Scheduling and Ntificatins The Change Crdinatr establishes the apprpriate schedule fr the

20 implementatin f the change. The schedule is based n several factrs including the change pririty, ther changes being implemented, and system availability. Once the schedule has been established the Change Crdinatr ensures the change is nted n the cnslidated change schedule and ntifies all interested parties f the pending change. Change Implementatin The Change Implementer implements the change in accrdance with the implementatin plan and during the scheduled time. This is generally a technical implementatin. Failure f an implementatin at this level will nrmally require the Change Implementer t fllw the back-ut plan t ensure nrmal system peratins. Significant changes within the envirnment that require a majr prgram develpment effrt will fllw the guidelines established in the SDLC dcument and established Custmer Prject Management prcedures. In general, these include the fllwing requirements which all change implementatins must fllw: Develping an implementatin prject plan Verify testing was successful Applying the change t prductin Validating the change in prductin Reslving prblems caused by the change Writing a summary f the results Updating the Change Management applicatin with results f the implementatin Testing, Validatin, and Acceptance Once a change has been implemented, the IT Business unit respnsible fr the change and end users wh will be using the change will cnduct testing fllwing the test plan develped during the change develpment phase. Accurate dcumentatin and analysis f any abnrmalities is dcumented in the change recrd. The Change Crdinatr r the CAB designee will rate the change with ne f the fllwing ratings. Acceptance with n cmments Acceptance with minr exceptins (nte that these exceptins will either be fixed under the current change r may require the creatin f anther new change) Rejectin nrmally used nly if the implemented change desn t meet the required business needs. This results in a failed change determinatin and must be thrughly reviewed t identify the rt cause f the failure. This will nrmally result in the creatin f a new change request. Change Review and Acceptance Fllwing a successful change implementatin, a change review must be cnducted t determine if the change resulted in the desired utcme. In mst cases, this review prcess might be very brief. Fr a rutine change, where the

21 effect has been small and the results relatively predictable, the review prcess will be limited t checking that the change has prvided the user with the desired functinality. Mnitr Change in Prduct in Envirnment T determine whether the deplyed change has been effective, it is necessary t mnitr the changes in the prductin envirnment. Fr a small change, this may cnsist f checking n the desired functinality. Fr larger changes, it might require the mnitring f netwrk and server infrmatin, perfrmance data, event lgs, r respnse times. Several different tls and technlgies are available fr mnitring a change in the prductin envirnment. The actual tls used will depend n the nature f the change, the cmpnents f the IT infrastructure that are affected, and the skills and experience f persnnel perfrming the mnitring activity. The Change Crdinatr will typically determine the best tl needed based n the specific change. Hld Pst -Implementatin Review The Change Crdinatr is respnsible fr ensuring that a pst-implementatin review is cmpleted and presented t the CAB. The findings f the pst implementatin review are dcumented within the cmpany s selected technlgy platfrm recrd. After sufficient infrmatin, has been gathered frm mnitring t determine the effectiveness f the change, a pst-implementatin review is held. The CAB Chairpersn r Change Crdinatr will schedule and mderate the review meeting fr large changes. During the review, reference must be made t the riginal RFC, which states the bjectives f the change and ffers sme measurable indicatrs fr gauging the effectiveness f the change. The measured effects f the change can be cmpared with the desired effects t decide whether the change has met its bjectives. In additin t making a success r failure decisin n the change implementatin, the review will als cnsider hw the change was deplyed, and whether it was implemented n time and n budget. This exercise will result in the dcumentatin f lessns learned frm the change. Review feedback is then distributed t all parties invlved in the change t encurage and enable future prcess imprvements. Accept Issues and Cntinue Even if a change has nt fully met the desired bjectives fr the change, the review may still determine that the change shuld nt be backed ut and that it is nt desirable r cst-effective t make mre changes. Instead, there may be ptins available t wrk arund the shrtcmings f the system. Such wrkarunds shuld be dcumented. If they are user wrkarunds, the service desk shuld be infrmed s that the infrmatin can be easily made available t the users. If the wrkarund is an additinal manual prcess that sme IT staff needs t take, then they shuld be s infrmed. In this case, the change lg is updated with the reasns t accept the change and any wrkarunds that are implemented. The Change Initiatr and ther interested parties are infrmed and the RFC is clsed.

22 Measuring Quality in the Change Reprts frm the cmpany s selected technlgy platfrm will prvide meaningful and cncise infrmatin abut past and current changes. This infrmatin will permit the evaluatin f the impact f changes, dependencies, and trends. Change Reprts NOTE: These are currently recmmended reprts that shuld be develped. This sectin will need revisin at semi-annual intervals. The Change Management Reprts include: Reasns fr Change (user requests, emergency, enhancements, business requirements, service call/ incident/ prblem fixes, prcedures/ training imprvement, etc.) Number f successful changes Number f failed changes Number f changes backed-ut, tgether with the reasns (e.g. incrrect assessment, bad build) Number f Incidents traced t the change and the reasns Number f RFCs (and any trends in riginatin) Number f implemented changes reviewed, and the size f review backlgs Data frm previus perids (last perid, last year) fr cmparisn Number f RFCs rejected Number f changes per categry The abve reprts can be used as a basis fr assessing the efficiency and effectiveness f the Change Management prcess. Change Cmpliance This sectin describes the activities necessary fr the Change Organizatin t audit their effectiveness f change. The Change Manager will cnduct an annual audit that will include an examinatin f the fllwing items: CAB minutes and Frward Scheduling Calendar (FSC) Review recrds fr randm RFCs and implemented changes When review and analyze Change Management reprts based n the fllwing criteria: All RFCs have been crrectly lgged, assessed and executed FSC has been adhered t, r there is a gd reasn why nt All items raised at CAB meetings have been fllwed up and reslved All Change reviews have been carried ut n time All dcumentatin is accurate, up-t-date and cmplete Rles and Respnsibilities Rles assciated with the Change Management prcess are defined in the cntext f the management functin and are nt intended t crrespnd with rganizatinal jb

23 titles. Specific rles have been defined per industry best practices. In sme cases, many persns might share a single rle; and in ther cases, a single persn may assume many rles. The significant rles defined fr the change management prcess are: Change Manager Change Initiatr Change Crdinatr Change Task Assignee r Change Implementer Change Management System Administratr Cmmittees are als defined in terms f the rles they play and the respnsibilities they have in the cntext f the change management functin. At a minimum, there are nrmally at least tw cmmittees established: The Change Advisry Bard (CAB) and the Change Advisry Bard Emergency Cmmittee, which typically have management respnsibilities fr the change management prcess. Change Manager The Change Manager is respnsible fr managing the activities f the change management prcess fr the IT rganizatin. This individual fcuses n the prcess mre than n any individual change. Hwever, the Change Manager is invlved in every step f the prcess frm receipt f an RFC t the implementatin f the change in the IT envirnment. The Change Manager is ultimately respnsible fr the successful implementatin f any change t the IT envirnment. The Change Manager s respnsibilities include: Receiving RFCs and ensuring that they are prperly recrded in the change management system technlgy platfrm. Selecting CAB members and facilitating CAB meetings jintly with the CAB Chairpersn. Nte that the Change Manager may initially serve as the CAB Chairpersn. Preparing CAB meeting agendas and prviding all necessary review infrmatin t the CAB members prir t the meetings. If necessary, assigning teams t cnduct RFC impact analyses and risk assessments. Analyzing and priritizing RFCs. Categrizing, assigning change Crdinatrs, and scheduling RFCs, subject t apprval by the CAB. Apprving requests fr minr changes r assigning apprval authrity t thers. Prviding change ntificatin t the Change Initiatr and ther affected parties. Mnitring the successful cmpletin f all RFCs, including the change develpment prject phases and ensuring that these prcesses fllw the change schedule. Reviewing and evaluating the change prcess.

24 Change Administratr The Change Administratr directly supprts the change manager and is respnsible fr all the administrative functins assciated with the Change Management prgram. These duties include maintaining the CAB meeting schedule as well as preparing the agenda; publishing any reprts required fr the meeting, and publishing the CAB meeting minutes; updating the plicies and prcedures guide as required by the Change Manager; and assisting with the publishing f any change management reprts required t supprt business management and the CAB. Change Initiatr The Change Initiatr (nrmally smene within the IT Business Unit) riginates changes by submitting a Request fr Change (RFC) t the Help Desk r the Change Crdinatr in the apprpriate IT Business unit. Everyne is authrized t initiate an RFC. The Change Initiatr is respnsible fr prviding sufficient infrmatin n the change that the Change Crdinatr can cmplete the new change frm within the cmpany s selected technlgy platfrm. This persn is ntified whether the change was apprved and is kept up-t-date n the status f the RFC thrughut the change prcess. The Change Initiatr assists the Change Manager and CAB in determining the RFC pririty and, after the change, participates in the pstimplementatin review. Change Crdinatr The Change Manager assigns (with the CAB s apprval) an individual t be the Change Crdinatr fr a change - Change Crdinatrs will be assigned t each IT business unit. The Change Crdinatr is respnsible fr planning and crdinating all the phases f the change frm initiatin thrugh acceptance and dcumentatin. The Change Crdinatr will dcument all relevant infrmatin in the cmpany s selected technlgy platfrm. The Change Crdinatr will rutinely prvide prject status feedback t the Change Manager and identify any prblems as they arise. The Change Crdinatr presents all frmal updates and prpsals t the CAB after the CAB apprves the RFC fr passage thrugh the varius change implementatin, review and clsure phases. The Change Crdinatr must wrk with the Change Initiatr t ensure that the change meets the Change Initiatr s requirements and that it successfully crrects any prblems r prvides the crrect system enhancements intended by the RFC. After implementing the change, the Change Crdinatr assists the Change Manager in evaluating the change prcess as it applies t the change. The Change Crdinatr als crdinates and presents the pst-implementatin review analysis t the CAB. Change Task Assignee r Change Implementer Change Task Assignees are respnsible fr executing individual tasks within a change and ensuring they are cmpleted per the implementatin plan. Fr example, the technician wh perfrms the actual upgrade f the perating system wuld cmplete the tasks assciated with cmpleting the upgrade.

25 The Change Crdinatr when develping the planning and implementatin tasks will assign the apprpriate Change Task Assignee t perfrm the tasks required t plan and implement the change. (Nte: When using a standard change categry established technlgy platfrm, the tasks and Task Assignees are already identified. The Change Crdinatr can make mdificatins as required t meet specific requirements.) Change Management System Administratr The Change Management System Administratr is respnsible fr mdifying and maintaining the cmpany s selected technlgy platfrm, including the develpment and administratin f the Change Management reprts. Change Advisry Bard The Change Advisry Bard (CAB) is the change management decisin-making authrity fr the IT rganizatin. The primary respnsibilities f the CAB are t: Establish and manage verall change management plicies and prvide guidance Oversee the Scheduling Calendar (this is a reprt generated frm within the cmpany s selected technlgy platfrm) Review and apprve all pending requests fr high-risk and high-impact changes (The CAB may grant apprval authrity at levels lwer than the CAB) Review cmpleted changes and make recmmendatins fr apprval Appint peple t key rles within the Change Management prgram CAB Membership The CAB is made up f individuals with stakehlder interest in the IT prductin envirnment. Since RFCs can impact any part f IT and any rganizatinal grup, the makeup f the CAB reflects the fcus f the RFC being reviewed. In general, the CAB is cmpsed f individuals wh have a wide range f expertise and are familiar with business requirements, the user cmmunity, and IT system technlgy. The rganizatin chart belw shws the general structure f the Custmer Change Advisry Bard:

26 It s imprtant t nte that additinal CAB members may be required per the RFCs being cnsidered and if necessary may include input frm security, services, vendrs and custmer user grups. The CAB Chairpersn, will make these decisins and ntify resurces if they need t attend the regularly scheduled CAB r an emergency sessin. CAB Meetings The CAB is scheduled t hld an extensive meeting mnthly with update meetings held n a weekly basis r as required. The mnthly and weekly meetings will prvide an verall review f the technical and business impact, priritizatin, apprval, and scheduling f pending RFCs. The mnthly meetings will als include review f the key change management reprts, discussin n the change management prgram, and a review f any failed changes r changes requiring mdificatins during the implementatin phase t ensure a successful change. A few days befre each CAB meeting, the CAB Chairpersn will send ut a meeting ntificatin and agenda t all CAB members. The cntents f this include: Date, time, and lcatin (if relevant) f the meeting. Frmat f the meeting. As an alternative t hlding face-t-face meetings, CAB meetings may be held using a cnferencing sftware r by telephne cnference calls. Net Meeting is preferred because it enables CAB members t share dcumentatin and use electrnic whitebards. The reviewing rder fr RFCs (agenda). CAB members may be interested in nly a small number f the prpsed changes and might jin the meeting nly when necessary. A link t all the RFCs being reviewed at the meeting and a frward schedule f the change calendar fr discussin. Vting Rules This sectin establishes the vting rules fr RFCs requiring apprval f the CAB. The standard change categries develped and included in the cmpany s selected technlgy platfrm include a recmmended apprval prcess. If the specific

27 change being cmpleted des nt have established apprval requirements, the CAB Chairpersn will assign a minimum f tw CAB members as the apprval authrities fr that change. These apprval authrities are then added t the RFC dcumentatin in the change recrd. Key Definitins Key definitins fr change management used in this dcument include: Change Advisry Bard (CAB) The CAB is a crss-functinal grup set up t evaluate change requests fr business need, pririty, cst/ benefit, and ptential impacts t ther systems r prcesses. Typically, the CAB will make recmmendatins fr implementatin, further analysis, deferment, r cancellatin. CAB Emergency Cmmittee (CAB/ EC) This is a subset f the CAB that deals nly with emergency changes. It is established t be able t meet n shrt ntice t authrize r reject changes with emergency pririty. Change Any new IT cmpnent deliberately intrduced t the IT envirnment that may affect an IT service level r therwise affect the functining f the envirnment r ne f its cmpnents. Change Categry The measurement f the ptential impact a change may have n IT and the business. The change cmplexity and resurces required, including peple, mney, and time, are measured t determine the categry. The risk f the deplyment, including ptential service dwntime, is als a factr. Change Crdinatr The rle that is respnsible fr planning and implementing a change in the IT envirnment. The Change Crdinatr rle is assigned t an individual fr a change by the Change Crdinatr and assumes respnsibilities upn receiving an apprved RFC. The Change Crdinatr is required t fllw the apprved change schedule. Change Requester A persn wh initiates a Request fr Change; this persn can be a business representative r a member f the IT rganizatin. Change Initiatr A persn wh receives a request fr change frm the Change Requester and enters the request fr change in the Change Management prcess; this persn is typically a member f the IT rganizatin. Change Manager The rle that has the verall management respnsibility fr the Change Management prcess in the IT rganizatin. Change Pririty A change classificatin that determines the speed with which a requested change is t be apprved and deplyed. The urgency f the need fr the slutin and the business risk f nt implementing the change are the main criteria used t determine the pririty. Change Recrd The recrd within the cmpany s selected technlgy platfrm that cntains all the infrmatin relative t a change. This infrmatin includes