Attachment B - ECC SOP v2.doc

Solicitation - TIRNO-14-R-00025

Attachment B

MAINFRAME PERIPHERAL AND SOFTWARE MAINTENANCE

RECOMPETE

Enterprise Computing Center Change Management Standard Operating Procedures Version 2.0 April 19, 2010 Subject:

Enterprise Computing Center

Change Management

Standard Operating Procedures

Effective Date:

Originator:

Enterprise Computing Center (ECC) Operations Services, Scheduling & Validation Branch

Approval:

Director, Enterprise Computing Center

Approving Organization:

Enterprise Computing Center

Change Management

Standard Operating Procedures

Version 2.0

April 19, 2010

Enterprise Computing Center

Change Management Standard Operating Procedures Document No. ECC CM - SOP

Version 2.0

Concurrence

April 19, 2010

Director

ECC:

Date

Deputy Director

ECC

Date

Chief, Security

MgMt Office:

Date

Chief, Mainframe Operations Branch:

Date

Chief, Operations Services, Scheduling & Validation Branch:

Date

Chief, Service Operations Command Center

Branch:

Date

Change Management Standard Operating Procedures Document No. ECC CM - SOP

Version 2.0

Concurrence

April 19, 2010

Chief, Data Management

Branch:

Date

Chief, Tier II Wintel Systems Branch:

Date

Chief, Tier II Unix Systems Branch:

Date

Chief, Systems Integration & Coordination Branch:

Date

Chief, Configuration Change Management Branch: Enterprise Services

Date

Document History

Version 1.1

Change Record

Effective Date Change Entered By

Table of Contents

8List of Tables

Section 1 Office of Responsibility

1.1 Enterprise Computing Center Change Management Board (ECC ChMB)

1.1.1 Responsibility

1.1.2 Membership

1.2 Purpose 1.3 Mission 1.4 Impacted Organizations 1.5 References 1.5.1 IRM 2.27.1, Configuration Management, Effective January 1, 2010 This IRM supersedes Modernization and Information Technology Services (MITS) CM Standard Operating Procedures (SOP) and CM Directive.

1.5.2 MITS Technology Release and Control for Information Technology (TRaCIT)

1.5.3 TRaCIT Phase 0.2 Improve Change Management Process

1.5.4 MITS Configuration Management Plan

1.5.5 Enterprise Computing Center Change Control Board Charter

1.5.6 Release Readiness Review Board (RRRB) Charter

1.5.7 ITIL®v3 Glossary of Terms and Definitions v01, 30 May 2007 - The Official Glossaries/Acronyms of any Office of Government Commerce (OGC) Best Practice Publication as published by or on behalf of OGC

1.5.8 LEM 2.7.5 MITS Operations System Control Point (SCP) Configuration Management (CM)

1.5.9 Emergency Transmittal Criteria

Section 2 Change Requests (CR)

2.1 Change Request Types

2.2 Scheduling Change Requests

Section 3 Change Request Categories

3.1 Change Categories

3.2 Standard Change – Low Risk

3.2.1 Critical Elements of a Standard Change:

3.2.2 Intrusive and Non-Intrusive Change Requests

3.3 Normal Change

3.3.1 Normal Change - Moderate Risk

3.3.2 Normal Change-High Risk

3.4 Urgent Change

3.4.1 Urgent Change-Emergency

3.4.2 Urgent Change-Expedite

Section 4 Processing Change Requests

4.1 Processing Change Requests

4.2 ECC ChMB Roles and Responsibilities

4.2.1 The Chairperson

4.2.2 The ECC ChMB CM Representative/Secretariat

4.2.3 The ECC CM-Initiator/Change Sponsor

4.2.4 The Subject Matter Expert’s Role

4.2.5 The Manager or Supervisor’s Role

4.2.6 Change Management (CM) POC

4.2.7 Business Owners

4.3 How the ECC Interfaces With Other MITS Organizations

4.3.1 The Large Systems & Storage Interface (LSSI) ChMB Interface

4.3.2 The PCRB Interface

4.3.3 The RRRB Interface

Section 5 Submitting a Change Request

5.1 Submitting a Change Request

5.1.1 Cutoff Time

5.1.2 Urgent - Expedite Change Requests

5.1.3 Urgent - Emergency Change Requests

5.1.4 Management Reports

Section 6 ECC ChMB Meeting

6.1 ECC ChMB Meeting

6.2 ECC ChMB Agenda

6.3 Sponsor Participation

6.4 Disposition of CRs

Section 7 Project Implementation Plan

7.1 The Project Implementation Plan

7.1.1 Detailed Description of Each Activity

7.1.2 PIP Schedule

7.1.3 Back-out Procedures

Appendix A Change Category Criteria and Approval Authority A.1 Standard – Low Risk Change A.2 Normal Change – Moderate Risk A.3 Normal Change – High Risk A.4 Urgent Change - Emergency A.5 Urgent Change – Expedite Appendix B Abbreviations and Acronyms

List of Tables

Tables

13Table 3.1-1 Change Categories

Table 6.1-1 Board Deliberation Table A-1 Standard – Low Risk Change Criterion Table A-2 Normal - Moderate Risk Change Criterion Table A-3 Normal – High Risk Change Criterion Table A-4 Urgent Change - Emergency Criterion Table A-5 Urgent Change - Expedite Criterion Table B-1 Abbreviations and Acronyms

List of Figures

Figures

11ECC ChMB Change Request Types, Figure 2.1- 1

12Change Request Scheduling, Figure 2.2- 2

20ECC ChMB CR process, Figure 5.1- 3

23Change Board Dispositions, Figure 6.4- 4

Section 1 Office of Responsibility

1.1 Enterprise Computing Center Change Management Board (ECC ChMB)

The ECC ChMB is established to ensure all required or requested modifications to the ECC Information Technology (IT) configuration are appropriately controlled and documented. Board and participant roles are outlined in Section 4 - subsection 4.2 of this document.

1.1.1 Responsibility

The ECC ChMB is the approving authority and is responsible for the implementation of the processes and procedures that are described within this document. The originating organization, Enterprise Computing Center, is responsible for the development and maintenance of this document. Any person or organization requesting an ECC IT configuration change will abide by all decisions made by the ECC ChMB.

1.1.2 Membership

The Standing Board Members are the ECC Director, ECC Deputy Director, all ECC Branch Chiefs or Designated Representatives; Business Representatives, Principal Project or Infrastructure Stakeholders, and Subject Matter Experts as well as Deployment Team members.

1.2 Purpose

This document describes the ECC Change Management (ChM) Standard Operating Procedures (SOP) of the ECC CM Process and defines the mission, authority, responsibilities and thresholds along with the ECC ChMB membership, meeting schedule, and decision making processes.

1.3 Mission

The mission of the ECC ChMB CM Process is to review and rule on proposed changes to ECC controlled IT Systems, as defined and described in the ECC CM Plan.

The ECC ChMB will also be used to arbitrate conflicts concerning change packages that impact more than one planned implementation within ECC.

1.4 Impacted Organizations

The ECC technical support organizations are responsible for complying with applicable guidelines contained within this SOP as appropriate. The ECC CM representative is responsible for ensuring compliance with these procedures by all impacted organizations. Organizations outside of the ECC who have a business reason to request a modification to an ECC Information Technologies configuration must comply with the guidelines contained within this SOP document.

1.5 References

Current MITS Process Asset Library (PAL) approved versions of sources of authority and other official reference documents are to be applied to the implementation of the processes and procedures found in this document.

1.5.1 IRM 2.27.1, Configuration Management, Effective January 1, 2010 This IRM supersedes

Modernization and Information Technology Services (MITS) CM Standard Operating Procedures

(SOP) and CM Directive. http://irm.web.irs.gov/Part2/Chapter27/Section1/IRM2.27.1.asp

1.5.2 MITS Technology Release and Control for Information Technology (TRaCIT)

1.5.3 TRaCIT Phase 0.2 Improve Change Management Process

1.5.4 MITS Configuration Management Plan

1.5.5 Enterprise Computing Center Change Management Board Charter

1.5.6 Release Readiness Review Board (RRRB) Charter

1.5.7 ITIL®v3 Glossary of Terms and Definitions v01, 30 May 2007 - The Official

Glossaries/Acronyms of any Office of Government Commerce (OGC) Best

Practice Publication as published by or on behalf of OGC

1.5.8 LEM 2.7.5 MITS Operations System Control Point (SCP) Configuration Management (CM)

1.5.9 Emergency Transmittal Criteria

Section 2 Change Requests (CR)

A CR is defined as a formal proposal for a change to be made to the existing ECC Information Technology IT baseline environment or platform. The CR is created by an initiator and is to contain a detailed description of the planned change and must have pre-approved authorization by management before coming to the ECC ChMB for final approval into Development, Test, and Production environments. The CR must have all fields populated in the Configuration Change Web Application Database and contain a list of all systems that will be impacted or potentially impacted by the implementation of the CR. Change categories are described in Section 3 of this document.

2.1 Change Request Types

All Tier I, Tier II, Wintel Telecom, Network configurations, Middleware builds, Computer Security Incident Response Center (CSIRC) and Vendor Patches, Knowledge Incident/Problem Service Asset Management (KISAM) tickets and Modernized Application requested changes to the ECC IT Configuration are controlled by the ECC CM process (See ECC ChMB Change Request Types, Figure 2.1-1 below).

ECC ChMB Change Request Types, Figure 2.1- 1

2.2 Scheduling Change Requests

A CR must be created and scheduled prior to the ECC ChMB weekly meeting in the Configuration Change Web Application Database. A CR will be dispositioned at the ECC ChMB meeting for implementation to begin and end within a (24) hour period only. Multiple day requests require separate CRs. The CR cut-off day for Standard and Normal CRs is COB two days prior to the scheduled ECC ChMB weekly meeting.

Change Request Scheduling, Figure 2.2- 2 Desktop changes are not controlled by the ECC CM process; the following are changes to the ECC IT configuration which require a CR to be created:

· Hardware/Software Installations

· Hardware/Software Upgrades

· Application Patches Installed

· Security Patches Installed

· Hardware/Software de-installations

· Reconfiguration of disk space

· Any manual change that requires downtime or has potential impact on system processing

· Transmittals that are for initial application builds, middleware builds, operating system installations, database installations, all upgrades, security patches, and any transmittal that requires downtime or has a potential negative impact on system processing. Otherwise transmittals will be tracked by the Systems Control Point function within ECC

· KISAM Break-Fix tickets or incident reports

Section 3 Change Request Categories

3.1 Change Categories

A CR is defined as any request for change to the existing ECC IT Configuration. The impact of the problem, urgency for remedy, and risk to business of any change will determine the category into which the CR falls.

Recovery Test

(P1 KISAM Ticket) X

Emergency

(P2 KISAM Ticket)

Table 3.1-1 Change Categories

3.2 Standard Change – Low Risk

A change to a service or infrastructure for which the approach is delegated or preauthorized by Change Management and has an accepted and established procedure to provide a specific change.

3.2.1 Critical Elements of a Standard Change:

a. There is a defined trigger to initiate the CR

b. The tasks are well known, documented and proven

c. Authority is effectively given in advance, but change must be documented in the ECC Configuration Change Web Application Database

d. The risk is low, and always well understood

e. A change is relatively common and follows an established procedure or work instruction.

f. Criteria for Standard Changes are outlined in Appendix A, Table A-1, Change Category Criteria and Approval Authority

g. Standard changes are routine work processed under normal processing timeframes and approved by the ECC ChMB Representative

3.2.2 Intrusive and Non-Intrusive Change Requests

The terms non-intrusive and intrusive have multiple meanings and associated levels of risk. A non-intrusive change is a change that involves no disruption to normal operations and can be scheduled at any time with concurrence from all impacted applications. An intrusive change is a change that impacts one or more application or organization build. An intrusive change must be done in a predetermined Maintenance Window.

Intrusive to application only

· Intrusive only to the application during the build but non intrusive to any other applications, servers, or shared services.

· Intrusive only to application during the back-out and non intrusive to any other applications, servers, or shared services.

Intrusive to application and other applications, servers, or shared services

· Intrusive to application and/or one or more other applications, servers, or shared services during the build

· Intrusive to application and/or one or more other applications, servers, or shared services during the back-out

· Back-out plan cannot be tested in EITE. Sponsor/SME should be able to explain why the back-out cannot be tested.

Non-intrusive

· No server reboots

· No application restarts

· No Java Virtual Machine (JVM) restarts

· Back-out plan has been fully tested in EITE

· Back-out plan testing is verifiable as non-intrusive

3.3 Normal Change

A change to a service or infrastructure from the initiator (the individual or organizational group) for which approval is authorized by a designated Change Management (CM) authority. A normal change does not need to be implemented prior to the next regularly scheduled ECC ChMB meeting. There are two types of Normal Changes, Moderate Risk and High Risk.

3.3.1 Normal Change - Moderate Risk

Changes of moderate risk to business, services, or MITS operations do not require extensive oversight for rapid approval. Criterion for Normal – Moderate Risk changes are outlined in Appendix A, Table A-2, Change Category Criterion and Approval Authority

Moderate risk changes, with fully documented tickets in the ECC Configuration Change Database, may be marked for bulk-approval at the next regularly scheduled ECC ChMB meeting

Items marked for bulk approval will not normally be discussed during board deliberation unless pertinent changes have occurred or schedule conflicts arise with other scheduled changes or critical business processing dates

3.3.2 Normal Change-High Risk

Changes requiring expanded coordination, potential elevation, or deliberation by the change authority. Criterion for Normal – High Risk changes are outlined in Appendix A, Table A-3, Change Category Criterion and Approval Authority

3.4 Urgent Change

The number of Urgent Changes should be kept to a minimum, because they are generally more disruptive and prone to failure. There are two types of Urgent Changes, Emergency and Expedite

3.4.1 Urgent Change-Emergency

Changes intended to repair an error in an IT service or infrastructure component that is negatively impacting business to a large degree. To be considered an Emergency Change each of the following criteria must be met:

a. A work stoppage must exist

b. A corresponding KISAM P1 or P2 ticket must be open

c. The emergency change ticket and transmittal document must clearly annotate the P1 or P2 KISAM ticket number

d. Criterion for Urgent – Emergency changes are outlined in Appendix A, Table A-4, Change Category Criterion and Approval Authority

3.4.2 Urgent Change-Expedite

Neither an Expedite nor an Emergency CR is to be used to intentionally bypass the formal ECC CM policies and procedures for Standard and Normal Risk CRs. An Expedite CR is created when a change needs to be implemented prior to the next regularly scheduled ECC ChMB meeting and there is not an associated work stoppage.

In addition, an Expedited CR is created when a CR needs to be submitted after the established submission deadline for ECC CRs, but needs to be placed on the ECC ChMB agenda for that week. The presentation of the CR at that weeks’ ECC ChMB or the processing of the CR via email is at the discretion of the CM representative. The planned change must be advantageous to the requesting area or the stakeholders affected by the Change Request.

Criterion for Urgent – Expedite changes are outlined in Appendix A, Table A-5, Change Category Criterion and Approval Authority. Standard, Normal CRs and late requests received after the cutoff date will be reported in weekly ChMB status accounting reports and will be processed the following week unless approved by next level manager or the change is truly urgent, e.g., P1 or P2 ticket.

Section 4 Processing Change Requests

4.1 Processing Change Requests

These procedures apply to all proposed changes to ECC controlled systems. A CR for a change to the ECC IT Configuration will be created in the Configuration Change Web Application Database. Once the initiator enters the system all fields must be populated before being forwarded to the initiator’s Manager or Supervisor for approval. Upon receipt of approval from the Manager or Supervisor, the change request is put on the weekly agenda for ECC ChMB approval. Once the CR is approved it is ready to be deployed into Development, Test, and Production environments.

4.2 ECC ChMB Roles and Responsibilities

4.2.1 The Chairperson

The ECC ChMB Chairperson is the sole decision maker, using other board members as advisors.

As outlined in the ECC ChMB Charter, the Chairperson has the following responsibilities:

· To chair all ECC ChMB meetings. At the Chairperson’s discretion, he/she may temporarily delegate chairmanship responsibility to a Director, who is a standing member.

· To disposition all proposed changes submitted against ECC baselined products.

· For arbitrating conflicts between Functional Level ChMBs pertaining to change package proposed solutions.

· Review with the ChMB, then escalate change packages to the MITS-CCB when:

1. Proposed solutions affect other project or system’s approved business requirements.

2. The ECC ChMB threshold limits are exceeded.

4.2.2 The ECC ChMB CM Representative/Secretariat

The ECC ChMB CM Representative performs activities to support the ECC ChMB as directed by the Chairperson and:

· Attends and facilitates all ECC ChMB Meetings

· Prepares the ECC ChMB agenda,

· Schedules and announces the ECC ChMB meeting,

· Captures all ECC ChMB decisions and action items, and if additional information is needed the CM Representative will contact the CR initiator or the CR POC for the additional information. All impact or problem issues must be resolved prior to the CR being presented to the ECC ChMB.

· Prepares and distributes the ECC ChMB meeting minutes, including attendance

The CM Representative may also distribute the CR to designated Cyber Security representatives for review. Any potential Security ramifications or requirements concerning the CR will be provided to the CM Representative for notification to the CR initiator and/or POC. Any Security issues must be resolved by the CR initiator prior to the CR being presented to the ECC ChMB. The CM Representative will also prepare the “Technical Review Document” and distribute the CR via e-mail to designated subject matter experts (SMEs) for a technical review including any associated documentation with the CR.

4.2.3 The ECC CM-Initiator/Change Sponsor

The initiator determines the CR category (Standard, Normal, Emergency or Expedite) and inputs the CR into the Configuration Change Web Application Database. The initiator defines the change needed to an ECC configuration, provides all required information and submits the CR to the respective Manager for authorization and an email to the designated technical Subject Matter Experts (SMEs) for a technical review. Any additional associated documentation, (e.g. Project Implementation Plan) must also be distributed with the CR. An expedited CR must be distributed via email to the ECC ChMB CM Representative and the designated technical SMEs for an expedited technical review.

The initiator is the Internal Revenue Service (IRS) & MITS sponsor who has initiated the change request. Each change request must have an identified IRS initiator. The initiator will ensure:

· Pre-coordination is complete,

· Pre-deployment testing is complete,

· Coordination with all impacted projects / organizations has been completed,

· Origin of change is included,

· Post-deployment applications and infrastructure testing are planned,

· Security has been addressed,

· On-site lead is identified, and

· Release back-out plan is established.

4.2.4 The Subject Matter Expert’s Role

Subject Matter Experts (SME) will perform the technical review and impact analyses. The SME will usually be an IT Specialist and depending upon the complexity of the change and impacted systems, the SME may include someone with expertise for operating systems, databases, COTS, and various other LSS Infrastructure elements. After reviewing all documents, please use the voting buttons within the e-mail to “Approve” or “Reject” the proposed changes. If the “Reject” button is selected, state your rejection clearly and return the document for further coordination.

4.2.5 The Manager or Supervisor’s Role

When a CR is submitted by the initiator, the manager must authorize the change before the CR is sent to the ECC ChMB Representative to be compiled onto the ECC ChMB weekly agenda. Managers can delegate their own authority level only to their immediate employees only. The employee must first create a password. The employee's immediate manager can then delegate authority to, un-delegate manager authority from, or delete the password of, any their immediate employees who have passwords.

4.2.6 Change Management (CM) POC

The CM Point of Contact is the Database Administrator (DBA), System Administrator (SA), deployment lead or team implementing the change. The POC will be the primary contact for deployment updates and will report the results of the change implementation.

4.2.7 Business Owners

Appropriate business unit representatives will be included in ECC ChMB meetings and may participate to address concerns specific to the impact of a proposed change or release.

4.3 How the ECC Interfaces With Other MITS Organizations

There are instances when ECC Change Requests must interface with other MITS organizations for review or approval before being deployed into the Production environment. These are changes that are created for Modernized Projects, Network systems, KISAM tickets, routine maintenance, middleware builds, CSIRC & Vendor patches, Wintel Telecom, and Tier I & II systems.

4.3.1 The Large Systems & Storage Interface (LSSI) ChMB Interface

When a CR is created in the ECC Configuration Change Database which has an associated LSSI CR, the LSSI CR number will be entered into the appropriate field of the ECC CR. The LSSI CR should not be created in the ECC Configuration Database until LSSI ChMB has approved that CR. If, because of time restraints the ECC CR needs to be opened prior to the LSSI CR being approved, the CR will not be implemented until LSSI ChMB has approved the LSSI CR. The Initiator of the CR will ensure that the LSSI CR has been approved by LSSI ChMB prior to proceeding with the planned implementation. The LSSI ChMB meets on each Thursday before the ECC ChMB cutoff on Mondays.

4.3.2 The PCRB Interface

The Portal Program Management Office (PPMO) Configuration Review Board (PCRB) is responsible for managing all Registered User Portal (RUP) and the Employee User Portal (EUP) change requests that are deployed into the Modernized Production environment. The PCRB operates in tandem but independently from the ECC ChMB. A Portal change does not need approval from the ECC ChMB before implementation; however, an ECC ChMB change request may require resources to complete an installation that resides in the EUP since the portal is the “front-door” to the backend systems that are managed by the ECC ChMB and will need approval from both Boards. The PCRB meets every Tuesday before the ECC ChMB meeting.

4.3.3 The RRRB Interface

The RRRB will operate as the mitigating body to resolve elevated issues that cannot be decided on by either the PCRB or ECC ChMB. The RRRB will convene only by an exception request to intervene and hear issues. Standard and Routine Expedite CRs will not be heard by the RRRB and depending upon the urgency of the request, the RRRB resolution response can take up to 24 hours from the date/time received.

Section 5 Submitting a Change Request

5.1 Submitting a Change Request

When a change is required to a Production system, Development/Test system or Platform, a change request must be submitted into the Configuration Change Web Application Database. A change request can be initiated by almost anyone from inside or outside the ECC Division. The CR Initiator must complete the CR form, required fields have bold prompts and must be populated to complete a successful submission. After the new CR is submitted, an email will be sent to the Initiator's manager requesting that the new CR be Authorized and to the ECC ChMB Representative for review. The Initiator can edit the CR anytime before it is authorized. Any manager with Authorize authority can authorize any CR, but it is preferable for the CR to be authorized by the Initiator's manager. Managers can delegate their own authority level to their immediate employees only. The employee must first create a password. The employee's immediate manager can then delegate authority to, un-delegate manager authority from any their immediate employees who have CRs must be passwords or delete their password.

ECC ChMB CR process, Figure 5.1- 3

5.1.1 Cutoff Time

All changes must be submitted by COB on the Monday before the next upcoming Wednesday ECC ChMB meeting. Exceptions for urgent processing are outlined below.

5.1.2 Urgent - Expedite Change Requests

When a CR is required after the cutoff time, but needs to be on the next upcoming ECC ChMB agenda, an expedite change request can be submitted into the Configuration Change Web Application Database. An Expedite CR must be submitted to the Configuration Change Web Application Database as to allow (8)-eight business hours for the technical review and the voting process to be completed by 4:00pm Eastern Time. The CR will be processed through the normal email process.

5.1.3 Urgent - Emergency Change Requests

Emergency priority CRs are for priority 1 and 2 (P1 and P2) KISAM tickets only. An Emergency P1 priority CR can be implemented first, entered into the Configuration Change Web Application Database, without being approved by the ECC ChMB. An Emergency P2 CR for a Production system, must be submitted as to allow (4)-business hours for the technical review and the voting process to be completed by 4:00pm Eastern Time. The CR will be processed through the normal email process

5.1.4 Management Reports

Management reports will be automatically generated to compile various types of metrics to ensure operational efficiency of the deployment of change requests into the Production environment. Standard and Normal CRs received after the cutoff date will be reported in weekly ChMB status accounting reports.

Section 6 ECC ChMB Meeting

6.1 ECC ChMB Meeting

The ECC ChMB will meet each week via teleconference to deliberate pending Change Requests. The ECC ChMB will consider all changes proposed for implementation for the three week period that extends beyond the date of the teleconference.

If the ECC ChMB Chairperson is not available, one board member will be designated as ECC ChMB Meeting Chair. The Chair will vote on the disposition of CRs and is final unless concerns are raised by other board members or business representatives. The ECC ChMB Chair will limit discussion on low and moderate risk changes to essential updates or concerns specific to the impact of a proposed release. Board deliberation of high risk changes will focus on responses to board member or business questions. Coordination between impacted parties should be completed prior to the teleconference. The ECC ChMB will consider changes proposed for implementation for the three week period that extends beyond the date of the ECC ChMB teleconference.

The ECC ChMB will not formally vote on CRs for Development, Test or Disaster Recovery (DR), Current Production Environment (CPE) IT systems; these CRs will only be presented for documentation purposes.

Normal

Urgent

Emergency

(P1 KISAM Ticket) For information only – no deliberation

Emergency

(P2 KISAM Ticket) For information only - Previously approved via email

Table 6.1-1 Board Deliberation

6.2 ECC ChMB Agenda

The ECC ChMB Representative will use the categories in Appendix A to categorize types of change in preparation for building the ECC ChMB Agenda. Change Requests will be presented to the ECC ChMB via a formal agenda prepared by the ECC ChMB Representative and discussions will be facilitated by the ECC CM Representative and will focus on pending change requests. Modifications to previously approved, deferred and older CRs that need disposition status from initiators will be noted. Changes implemented by emergency or expedited CRs are considered information only and any discussion or information sharing should be held offline. The ECC ChMB Agenda will be published the day before scheduled ECC ChMB meetings. The minutes of the ECC ChMB meeting will be prepared by the ECC CM Representative and distributed via email to all stakeholders

6.3 Sponsor Participation

The ECC CM-Initiator/Change Sponsor, appropriate SMEs, CM Point of Contact (POC) or Business Owner representative for each pending CR affecting Production will be prepared to discuss the CR at the ECC ChMB meeting. If no one is available the CR will be deferred until the next regularly scheduled ECC ChMB meeting. SMEs for CRs relating to Development or Test systems are not required to attend the ECC ChMB meeting.

6.4 Disposition of CRs

Approval, disapproval or deferral of pending change requests will be made by the chairperson of the ECC ChMB. To speed deliberation, only the designated chairperson will approve changes during a board session. The concurrence of other board members is assumed, unless an objection is raised by another board member or stakeholder. In the event a disposition cannot be reached the change packages will be elevated to the appropriate senior board for resolution:

1) Proposed solutions affecting other boards, project timelines, business requirements – elevate to RRRB ad an ah hoc action; if unresolved elevate to MITS-ChMB

2) ECC ChMB threshold limits are exceeded – elevate to MITS-ChMB

Change Board Dispositions, Figure 6.4- 4 Section 7 Project Implementation Plan

7.1 The Project Implementation Plan

When a CR or groups of CRs are planned over a span of time, a Project Implementation Plan (PIP) is required. The PIP is a chronological schedule of all major activities that will occur at ECC for all installation/migration of planned change. The schedule will include the following:

7.1.1 Detailed Description of Each Activity

Procedures to be conducted by the ECC technical staff to accomplish the installation and migration activities defined above in Section 7.1 must be clearly defined in the PIP. The procedures will include, but are not limited to, transmittals, associated Version Description Document (VDD) for manual procedures or Packaged Description Documents (PDD) for automated push procedures.

7.1.2 PIP Schedule

The PIP must specify the date(s) and time(s) when known impacts will occur. This information will be used to notify ECC customers, internal and external, of planned system outages. The impact that the installation and migration activities will have on the targeted system at ECC and on the overall ECC production, test, Disaster Recovery, and/or telecommunications environment must be outlined.

Examples of impact include but are not limited to the following:

· Downtime for the targeted system

· List of all systems impacted or potentially impacted

· Disruption of service to applications in operational/test status

· Disruptive configuration changes to telecommunications equipment

7.1.3 Back-out Procedures

A detail of the back-out procedures to be followed in the event an installation/migration is unsuccessful. The back-out procedures should include the anticipated timeframe required to perform the back-out steps needed for recovery.

Appendix A Change Category Criteria and Approval Authority

A.1 Standard – Low Risk Change

A change to a service or infrastructure for which the approach is delegated or preauthorized by Change Management and has an accepted and established procedure to provide a specific change.

· have completed pre-deployment testing,

· are implemented in an approved maintenance window, or

· have the intrusive upgrade on infrastructure components outside the maintenance window approved by impacted business unit(s) ECC ChMB Representative Approval

Table A-1 Standard – Low Risk Change Criterion

A.2 Normal Change – Moderate Risk

Changes of low risk to business, services, or MITS operations, which fail to meet the criterion for Standard Change, do not require extensive oversight, for rapid approval.

Table A-2 Normal - Moderate Risk Change Criterion

A.3 Normal Change – High Risk

A change to a service or infrastructure for which the approach is delegated or preauthorized by Change Management and has an accepted and established procedure to provide a specific change.

Table A-3 Normal – High Risk Change Criterion

A.4 Urgent Change - Emergency

Changes intended to repair an error in an IT service or infrastructure component that is negatively impacting business to a large degree.

Table A-4 Urgent Change - Emergency Criterion

A.5 Urgent Change – Expedite

An Expedite CR is created when a change needs to be implemented prior to the next regularly scheduled ECC ChMB meeting and there is not an associated work stoppage. An Expedite CR is not to be used to intentionally bypass the formal ECC CM policies and procedures for Standard and Normal Risk changes.

Table A-5 Urgent Change - Expedite Criterion

Appendix B Abbreviations and Acronyms

Change Control Board

Table B-1 Abbreviations and Acronyms

PAGE

iv

_1395642182.vsd ECC Change Management Board

_1396702226.vsd Create CR in DB

Standard or Normal CR

Cutoff date

ECC ChMB Meeting

Disposition

Request Date

Select CR Type

Two Days Prior to ECC ChMB Meeting

Review CRs

Approve, Defer, Withdraw, Elevate

_1332070706.vsd Change Request (CR) Requirement

Initiator Logs into Configuration Change Database

Initiator Submits CR

START

Valid Data?

email Manager for Authorization

Manager Authorizes

YES

Conduct ECC CCB Meeting

Change Request added to Agenda

Approved

NO

email CCB Admin for Risk Analysis email SME for Technical Review

_1332070662.vsd RRRB Elevation

AGREED APPROVAL

ECC CCB Meeting

Deploy into PRODUCTION

WSCR Ticket

Initiator

Configuration Change DB Ticket

Coordination

Portal Chg

Back End Chg

RESOLUTION

MITS CCB

PCRB Meeting