it change management process guide & standards v4.0

Prepared by:

Project Sponsor(s):

ITIL Consultant:

Wedgewood, Inc. Contributors:

Date Created:Date Last Modified:

Edward Pagsanhan

Paul VolkmanStephen ReynoldsDouglas Fernandez

Edward Pagsanhan

Stephen ReynoldsDouglas Fernandez

07.24.201609.__.2016

1

IT Change Management v4.0Process Guide & Standards

Current State – High Level Work-Flow (06/2016)

i

DOCUMENT PURPOSE

This document defines the Wedgewood, Inc.’s IT Change Management (CM) process, activities, and accountable roles for the IT organization.

Planning and adoption of an agreed upon Change Management process (with supporting procedures and tool enhancement) will assist in the classification of changes to infrastructure & applications and defines the process & procedures of the change lifecycle. This document is a guide to be updated as necessary in order to represent the current operational practices of the organization.

VERSION HISTORY

HISTORY LOG

Version Revision Date Revised by Description

1.0 7/24/2016 Edward Pagsanhan Initial Document Creation

1.2 8/3 EP Identify and Defining base process requirements

1.3 8/7 EP Key Controls – Gates and Doc Deliverables

8/8 EP Key Controls – Gates and Doc Deliverables/workflows

1.4 8/9 EP Key Controls/SDLC stages definitions

8/11 EP Key Controls/SDLC stages entry/exit criteria

8/15 EP Key Controls/SDLC stages entry/exit criteria

1.7 8/17 EP Key Controls – Roles & Responsibilities

2.0 8/18 EP Key Controls – Roles & Responsibilities

2.1 8/21 EP Edit Definitions – Key Deliverables (Documents)

8/24 EP Re-Defined Deliverables and R&Rs

8/26 EP Re-Defined Deliverables and R&Rs

2.6 9/02 EP Entry/Exit Criteria defined - Roles & Responsibilities (To Be Approved)

3.0 9/08 EP Draft v3.0

3.1 9/16 EP Draft edits

4.0 EP

2

TABLE OF CONTENTS

I INTRODUCTION..............................................................................................................51.1 OVERVIEW.................................................................................................................................... 61.2 SCOPE AND APPLICABILITY................................................................................................................. 71.3 DOCUMENT CONTROL AND COMMUNICATION.......................................................................................81.4 PERIODIC REVIEW AND APPROVAL...................................................................................................... 81.5 GOVERNANCE & OVERSIGHT.............................................................................................................. 8

II GLOSSARY OF TERMS, DEFINITIONS AND ACRONYMS....................................................92.1 TABLE 1: GLOSSARY......................................................................................................................... 9

III PROCESS FLOW OVERVIEW..........................................................................................113.1 PROCESS NARRATIVE (HIGH LEVEL OVERVIEW)....................................................................................113.2 CHANGE LIFECYCLE: DEFINITIONS...................................................................................................... 11

3.2.1 Initiate, Assess & Approve – Phase I...............................................................................113.2.2 DESIGN & BUILD – PHASE II.................................................................................................123.2.3 TESTING & QUALITY ASSURANCE – PHASE III...........................................................................123.2.4 DEPLOY, VALIDATE & CLOSE – PHASE IV.................................................................................12

3.3 ENTRANCE AND EXIT CRITERIA.......................................................................................................... 13

IV ROLES & RESPONSIBILITIES OVERVIEW.........................................................................144.1 TABLE 2: SUMMARY OF ROLES......................................................................................................... 14

V THE CHANGE ADVISORY BOARD (CAB).........................................................................155.1 CAB – PROCESS OVERVIEW............................................................................................................. 155.2 THE EMERGENCY CHANGE ADVISORY BOARD (ECAB)...........................................................................155.3 PROCESS EXCEPTIONS..................................................................................................................... 15

VI CHANGE TYPES - THE ITIL NORMAL & EMERGENCY CHANGE MODEL............................166.1 NORMAL CHANGE TYPE …………………………………………………………………………………………………………........17

6.1.1 Process Flow Diagram – Normal Change ……………………………………………………………………....176.2 EMERGENCY CHANGE TYPE ……......................................................................................................... 18

6.2.1 Process Flow Diagram – Emergency Change…………………………………………………………………..186.4 APPROVAL MATRIX………………………………………………………………………………………………………………………. 19

3

VII ADDENDUM 1: PHASES 1 – 4 PROCESS FLOW NARRATIVES.…………………………………………207.1 NITIATE, ASSESS & APPROVE – PHASE I.……………………………………………………………………………………………..20

7.1.1 Process Narrative…………………………………………………………………………………………………………..207.1.2 Entrance Criteria ……………………………………………………………………………………………………………207.1.3 Exit Criteria ……………………………………………………………………………………………………………….....207.1.4 Phase 1: Detailed Roles & Responsibilities...…………………………………………………………………..21

7.2 DESIGN & BUILD- PHASE II.………………………………………………………………………………………………….…..……..227.2.1 PROCESS NARRATIVE…………………………………………………………………………………………………….……..227.2.2 ENTRANCE CRITERIA . …………………………………………………………………………………………………………. 22 7.2.3 EXIT CRITERIA..…………………………………………………………………………………………………………..………227.2.4 BASELINE CONFIGURATION..…………………………………………………………………………………….………..... 227.2.5 DETAILED ROLES AND RESPONSIBILITIES ………………………………………………………………………………….. 23

7.3 TESTING & QUALITY ASSURANCE – PHASE III ……………………………………………………………………………………….247.3.1 PROCESS NARRATIVE ……………………………………………………………………………………………………….....247.3.2 Implementation Considerations …………………………………………………………………….………………257.3.3 Entrance Criteria…………………………………………………………………………………………………………….257.3.4 Rolling or Phased Implementations………………………………………………………………………………..257.3.5 EXIT CRITERIA (SUCCESSFUL IMPLEMENTATION)………………………………………………………………………….257.3.6 EXIT CRITERIA (UNSUCCESSFUL IMPLEMENTATION)……………………………………………………………………..257.3.7 DETAILED ROLES AND RESPONSIBILITIES……………………………………………………………………………………26

7.4 Deploy, Validate & Close – Phase IV..………………………………………………………………………………..………27Table 10: Change Request Process PHASE IV Overview……………………………………………………………277.4.1 Process Narrative ………………………………………………………………………………………………………….277.4.2 ENTRANCE CRITERIA............................................................................................................ 277.4.3 EXIT CRITERIA.................................................................................................................... 277.4.4 DETAILED ROLES AND RESPONSIBILITIES...................................................................................28

VIII ADDENDUM 2: EMERGENCY CHANGE PROCESS.............................................................298.1 DEFINITION & PROCESS NARRATIVE ..................................................................................................29

8.2 Detailed Roles & Responsibilities ...………………………………………………………………………………….31

4

I Introduction

1.1 Overview

This document, the Change Management Process Guide and standards, is to primarily serve as and focus on establishing the overall foundation for managing technology changes which predominantly support changes made to Infrastructure. The change management standards encompass all modifications to backup, production servers, applications, networks and infrastructure services; and changes made by any group that is visible to all other groups – collectively known as Wedgewood, Inc.’s IT Infrastructure & Operations.

Wedgewood, Inc. acknowledges the risks associated with changes to technology as well as the benefits of controlled deployment and change processes. Wedgewood, Inc.’s CM Process Guide and standards document defines the company’s overall approach to managing infrastructure changes and associated risks. The policies, processes, protocols, and Standards document contained in the CM Process Guide and standards document help protect the company from business and technology risks by defining a framework that helps ensure that technology changes are properly authorized, planned, approved and validated by business and IT Leadership where needed.

The purpose of the Change Management process is to ensure that:

Standardized methods and procedures are used for efficient and prompt handling of all changes All changes to service assets and configuration items are recorded in the Configuration Management

System (CMS), or the Knowledge Base component of the system of record tool.

The objectives for Wedgewood, Inc.’s technology Change Management processes are to:

Improve service and support to clients and customers by developing and maintaining systems that are aligned with strategy, needs, and expectations;

Improve quality by establishing baseline controls throughout the Change Lifecycle (DEV – QA – Prod) process;

Improve quality through the application of software quality assurance processes and procedures; Ensure all infrastructure changes, described below, are approved and that the implications of such

changes are properly considered and planned; Reduce downstream maintenance costs that result from poorly defined requirements or quality

assurance processes; Minimize risks to the confidentiality, integrity, and availability of systems and data that may result

from inadequately managed changes; and Achieve control objectives relevant to the Program Development and Program Change IT general

control domains, thereby facilitating compliance with Sarbanes-Oxley Section 404 requirements.

5

1.2 Scope and Applicability

This document addresses changes to databases, operating systems, and network connected devices that fall into one of the following categories:

1. Any core/production network devices2. DB servers,3. Application systems (typically includes configuration changes for code launch),4. Security Changes,5. Has a potential impact on revenue,6. Requires downtime, 7. Could result in downtime to internal users, customers and partners,8. Will change system architecture and/or monitoring practices,9. Will impact other departments or systems.

Exclusions

The policies and processes described in the Change Management Process Guide and Standards document are applicable to all Wedgewood, Inc.’s employees, Wedgewood, Inc.’s Consultants/Contractors and all aspects of the Wedgewood, Inc.’s technology environment except for the following areas:

1. Office Machines – common office equipment such as facsimiles, printers, photocopiers, scanners, and audio/visual devices are not subject to the processes defined in the ICM Standards document.

2. Computer Hardware – Desktop and laptops.3. Development Infrastructure4. Staging Infrastructure,5. Application / Systems production running on end user dedicated desktops (Section 3.4)6. Building Facilities7. Building Access Control – The systems and equipment providing control over ingress and egress to

Wedgewood, Inc.’s facilities, such as automatic door locks and closed circuit television, are not subject to the processes defined in the CMPG standards document.

8. Non-Production Systems – Changes to non-production systems and data are not subject to the processes defined in the ICM Standards document.

9. End User Computing Desktop Resources – Changes to end user computing (EUC) desktop tools such as spreadsheets are not subject to the process defined in the CMPG standards document.

Exclusions Note:

While these areas are currently not subject to Wedgewood, Inc.’s change management protocols, it is expected that the business and/or technology owner(s) of excluded entities and technologies conduct all changes with an appropriate level of due care. IT Leadership is permitted to add any of the exclusions above to the Change Management process as they see fit. Any questions concerning changes to excluded entities and technologies should be directed to the IT Infrastructure & Operations Change Manager (aka IT DevOps Program Manager and the DevOps Application Architect).

6

1.3 Document Control and Communication

The CMPG and standards document is subject to version control and all substantive changes to the standards document must be logged in the Revision History Log. All changes to the CMPG standards document must be approved by the Change Manager and pre-determined IT Leadership (i.e., CIO, Application Development Program Manager, Application Architect Manager) based on the type of change. All changes must be summarized and communicated to IT staff after approval.

1.4 Periodic Review and Approval

The CMPG & standards document is evergreen and is updated on an as-needed basis as the people, processes, and technologies supporting the change. As needed, but at a minimum of once per fiscal year, IT Leadership must inspect the CMPG & standards document to ensure that it remains current and correctly reflects the processes in use by the company. Evidence of this review is to be notated in the Revision History Log with any requisite updates.

At the conclusion of the annual inspection of the CMPG & Standards document, the IT Leadership Team must re-assess and re-approve said document. Evidence of this approval will be documented in the Revision History Log, and if needed, with any relevant supporting emails or other communications attached.

1.5 Governance & Oversight

All members of the IT Leadership team are responsible for adhering to, and enforcing, the standards and processes defined by the Change Management Process Guide & Standards document within their teams. The acting Change Managers and IT Senior Management shall provide governance oversight and responsibility for enforcing policies and processes. Policies and processes may be enforced through one or more of the following methods:

1) Implementation and use of security and change management software,2) Periodic compliance audits performed by the IT Operations & Infrastructure Managers, the Change Manager or

his/her designee, and3) Self-assessment surveys.

Notation 1: Manage Change - Control Objectives and Activities

Control activities must be implemented to satisfy the relevant Sarbanes-Oxley control objectives. In most cases, management must be doing something to satisfy the control objective and have tangible evidence to substantiate what actions were taken to verify that controls operate effectively.

7

II Glossary of Terms, Definitions and Acronyms

The purpose of this glossary is to provide an accessible list of commonly terms in this CM Process Guide & Standards document and the definitions behind them.

2.1 Table 1: Glossary

Name Acronym Definition

Baseline Configuration Standards

BCS Baseline configuration standards document is the configuration standard that is referred to as an organization’s “best practices” applied across infrastructure components such as routers, firewall, switches, servers, database services etc. These form a guide to meet an organization’s risk matrix.

Change Advisory Board

CAB A group of people that advices the Change Manager in the Assessment, prioritization and scheduling of Changes. This board is usually made up of representatives from all areas defined in Section 3.3.

Change Management

CM Change Management is an IT Service Management discipline. The objective of change management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service. Changes in the IT infrastructure may arise reactively in response to problems or externally imposed requirements, e.g. legislative changes, or proactively from seeking improved efficiency and effectiveness or to enable or reflect business initiatives, or from programs, projects or service improvement initiatives. Change Management can ensure standardized methods, processes and procedures which are used for all changes, facilitate efficient and prompt handling of all changes, and maintain the proper balance between the need for change and the potential detrimental impact of changes.

Request For ChangeORChange Request

RFC or CR The addition, modification or removal of anything that could effect on IT Services.

Configuration Item

CI The term configuration item or CI refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents, software, models, and plans. The Configuration management system oversees the life of the CIs through a combination of process and tools by implementing and enabling the fundamental elements of identification, change management, status accounting, and audits. The objective of this system is to avoid the introduction of errors related to lack of testing as well as incompatibilities with other CIs.

8

http://en.wikipedia.org/wiki/Configuration_management

http://en.wikipedia.org/wiki/Information_technology

http://en.wikipedia.org/wiki/IT_service_management


Configuration Management Database

CMDB A configuration management database (CMDB) is a repository of information related to all the components of an information system. It contains the details of the configuration items (CI) in the IT infrastructure. Although repositories similar to CMDBs have been used by IT departments for many years, the term CMDB stems from ITIL (Information Technology Infrastructure Library). In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment. A CMDB helps an organization understand the relationships between these components and track their configuration. The CMDB is a fundamental component of the ITIL framework's Configuration Management process. CMDB implementations often involve federation, the inclusion of data into the CMDB from other sources, such as Asset Management, in such a way that the source of the data retains control of the data. Federation is usually distinguished from extract, transform, load (ETL) solutions in which data is copied into the CMDB.

Critical Success Factor

CSF Critical success factor (CSF) is the term for an element that is necessary for an organization or project to achieve its mission. It is a critical factor or activity required for ensuring the success of a company or an organization. The term was initially used in the world of data analysis, and business analysis. For example, a CSF for a successful Information Technology (IT) project is user involvement.

Incident Management

IM Incident Management (IM) is an IT service management (ITSM) process area. The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within service-level agreement (SLA). It is one process area within the broader ITIL Best Practices & Standards environment.

Key Performance Indicator

KPI A performance indicator or key performance indicator (KPI) is a type of performance measurement. An organization may use KPIs to evaluate its success, or to evaluate the success of a particular activity in which it is engaged. Sometimes success is defined in terms of making progress toward strategic goals, but often success is simply the repeated, periodic achievement of some level of operational goal (e.g. zero defects, 10/10 customer satisfaction, etc.). Accordingly, choosing the right KPIs relies upon a good understanding of what is important to the organization. 'What is important' often depends on the department measuring the performance - e.g. the KPIs useful to finance will be quite different than the KPIs assigned to sales. Since there is a need to well understand what is important (to an organization), various techniques to assess the present state of the business, and its key activities, are associated with the selection of performance indicators. These assessments often lead to the identification of potential improvements, so performance indicators are routinely associated with 'performance improvement' initiatives. A very common way to choose KPIs is to apply a management framework such as the balanced scorecard.

9

http://en.wikipedia.org/wiki/Balanced_scorecard

http://en.wikipedia.org/wiki/Performance_measurement

http://en.wikipedia.org/wiki/Performance_measurement

http://en.wikipedia.org/wiki/ITIL

http://en.wikipedia.org/wiki/Service-level_agreement

http://en.wikipedia.org/wiki/IT_service_management

http://en.wikipedia.org/wiki/Information_Technology

http://en.wikipedia.org/wiki/Business_analysis

http://en.wikipedia.org/wiki/Data_analysis

http://en.wikipedia.org/wiki/Mission_statement

http://en.wikipedia.org/wiki/Extract,_transform,_load

http://en.wikipedia.org/wiki/Configuration_Management_(ITSM)

http://en.wikipedia.org/wiki/ITIL

http://en.wikipedia.org/wiki/Configuration_item

http://en.wikipedia.org/wiki/Information_system

http://en.wikipedia.org/wiki/Configuration_management


Known-Error KE In IT Operations known errors may be logged in a system's Known Error Database (KEDB) which is then used to prioritize changes and to develop customer support reference information where a work around exists.

Operational Level Agreement

OLA An operational-level agreement (OLA) defines the interdependent relationships among the internal support groups of an organization working to support a service-level agreement (SLA). The agreement describes the responsibilities of each internal support group toward other support groups, including the process and timeframe for delivery of their services. The objective of the OLA is to present a clear, concise and measurable description of the service provider's internal support relationships.

Request For Change

RFC The Request for Change (RFC) is formal request for the implementation of a Change. A Request for Change is to be submitted to Change Management for any non-standard Change (a set of standard/ routine Changes is usually defined by Change Management; these are minor Changes which do not require submission to the Change Management process). A Change is backed by a Change Owner, holding a budget for its implementation. In many cases the Change Owner is identical with the RFC initiator. Typically Changes are owned by Service Management roles (e.g. the Problem Manager or Capacity Manager) or by IT Leadership. The RFC is a precursor to the Change Record and contains all information required to approve a Change. Further information is added as the Change progresses through its lifecycle. The level of detail depends on the size and likely impact of the Change. Often there will be references to further documents containing more detailed information, e.g. a detailed Change proposal.

Root Cause Analysis

RCA Root Cause Analysis (RCA) is a method of problem solving that tries to identify the root causes of faults or problems that cause operating events.

Service Level Agreement

SLA A service-level agreement (SLA) is a part of a service contract where a service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service or performance). As an example, internet service providers will commonly include service level agreements within the terms of their contracts with customers to define the level(s) of service being sold in plain language terms.

Software as a Service

SaaS Software as a Service is an "on-demand software" supplied by ISVs or "Application-Service-Providers" (ASPs); is a software delivery model; in which software and associated data are centrally hosted on the cloud.

10

http://en.wikipedia.org/wiki/Internet_service_provider

http://en.wikipedia.org/wiki/Service_contract

http://en.wikipedia.org/wiki/Root_cause

http://en.wikipedia.org/wiki/Root_cause

http://en.wikipedia.org/wiki/Problem_solving



http://en.wikipedia.org/wiki/IT_Operations

III Process Flow Overview

3.1 Process Narrative Overview

The process for managing changes to infrastructure has been designed to ensure that changes to the IT Operations production, corporate network and applications are of minimal impact to productivity and revenue streams. The four phase process for managing technology is depicted below.

Table 2: Change Request Process Phase Overview

3.2 Change Lifecycle: Definitions (Phases 1 – 4)

3.2.1 Initiate, Assess & Approve – Phase I:

Change Requests (CRs) for IT projects are generally initiated through but are not limited to via email. These are logged/documented into the system of record (KACE), and proceed to the SPRINT PLANNING MEETING where they are:

1) Assessed and designated a change Type,2) Assigned a Change Type grade based on the level of urgency using a pre-defined set of

criteria/parameters,3) Assigned to IT development support staff to vet the scope of effort, and4) Approved a tentative release date on an upcoming Sprint Schedule within the Change Management

module.5) Technical requirements for the change are defined, documented, and approved, helping to ensure

Infrastructure changes are defined to minimize risk to the production environment.

11

Asessment Phase:Functional Design Specification review & RFC Classification

Build Phase:Solution design & implementation plan

Test/QA Phase:Test Plan execution

Deployment Phase:Implementation, validation & closure


Build Phase: Test/QA Phase: Deployment Phase:

3.2.2 Design & Build – Phase II: (Weeks 1 thru 2 of Sprint Cycle)*

1) Technical owners scope the effort and proceed with the design solution/dev plan for the change(s),2) Develop implementation and rollback strategies, and3) Perform all activities attesting to a successful build has been completed and documented

* (Key Control gate & deliverable due)

3.2.3 Testing & Quality Assurance – Phase III: (Weeks 2-4 of Sprint Cycle) *

Execution of technical tests in test environments. Testing/Validation activities are performed following the defined Test Plan and Scope approved during the prior 2 phases. * (Key Control gate & deliverable due)

3.2.4 Deploy, Validate & Close – Phase IV: (Week 4 - Production) *

1) Infrastructure changes are implemented into production. 2) Validation procedures are performed to ensure the change is working properly.3) The change is validated and the change request is closed.

* (Key Control gate & deliverable due)

12

Asessment Phase: Build Phase:Solution design & implementation plan

Test/QA Phase: Deployment Phase:

Asessment Phase: Build Phase: Test/QA Phase:Test Plan execution

Deployment Phase:

Asessment Phase: Build Phase: Test/QA Phase: Deployment Phase:Implementation, validation & closure

2.3 Entrance and Exit Criteria – High Level Overview

Entry and exit criteria are defined for each stage. These criteria allow the project manager, as applicable, to communicate the status of a project by phase. A project must generally meet all entrance criteria prior to entering a phase and generally meet all exit criteria prior to transitioning to the next phase. The specific entry and exit criteria for each phase are defined in detail in later sections of this document.

13

IV Roles and Responsibilities Overview

4.1 Table 3: Summary of Roles

14

Role Descriptions

Business Subject Matter Experts (SME)(Project Managers, Business System Analysts, Application Developers, QA/Test resources, etc.)

Individuals with extensive knowledge of Wedgewood, Inc.’s business processes and how computer systems support those processes.

Business SMEs help define business requirements as well as defining and executing user acceptance test scenarios. The Project Manager may represent the Change Request during the design assessment (Sprint Planning) and release approval (Sprint Go/No Go or CAB) as the SME as well.

IT Program Manager, Application Architect(acting Change Manager)

The individual assigned overall responsibility for defining, communicating, implementing, and monitoring the company’s IT Change Management policies and processes.

Requestor An individual or group requesting a change to systems or data. The Requestor may also act on behalf of a tester as applicable. Additional duties may include testing sign-off for a vendor or business unit. The Project Manager may represent as the Requestor as times as well.

ImplementerThe individual(s) responsible for implementing changes to production systems and data.

IT Leadership and Team Managers

The individual with overall day-to-day responsibility for managing the development of program and or infrastructure changes.

IT Staff/IT Resource The individual assigned day-to-day responsibility for managing the development of a system or data change. The IT Staff or Technical Owner may also act on behalf of a tester and or as applicable sign-off for a vendor.

V SPRINT Go/No Go (Change Advisory Board)

5.1 SPRINT Go/No Go (aka Change Advisory Board or CAB) – Process Overview

RFCs or CRs sent to the Change Advisory Board (CAB), or otherwise referred to as the Sprint Go/No Go meeting, must be approved after:

1) The appropriate assessment and approval in the Sprint Planning Review, followed by 2) Scheduling in a Sprint release calendar, 3) Has successfully completed the appropriate testing within the defined test scope, and,4) Has met all deliverable due dates throughout the Sprint Cycle accordingly.

5.1.1 CAB Members & Stakeholders

The CAB or SPRINT Go/No Go sessions meets once per Sprint Cycle (4 weeks) basis to review all approved and scheduled change requests, change dependencies and status of future, current or past changes. The CAB is comprised of the following members and is responsible for the communication back to the appropriate teams and or business areas, as needed:

Change Manager, DevOps Manager/Lead, Application Architect/Dev Ops Technical Lead, Testing Leads (DevOps BSAs, the CIO, etc.)

5.1.2 Process Owner & Facilitator

Facilitated by the DevOps Program Director (can be referred to as the IT Change Manager) on a regularly scheduled basis. The CAB or Go/No Go approval is provided by the following:

The CIO, DevOps Program Manager Enterprise Application Architect, DevOps BSAs, other IT Leadership or their delegates.

5.2 The Emergency Change Advisory Board (ECAB)

Leveraged as an escalation path or expedited process for Changes to Production that require to be deployed outside of the normal pre-defined lead time requirements.

The Emergency Change Advisory Board is a group called together by the Change Manager to act as decision makers on ALL changes that are categorized as emergency. This group usually meet virtually as the nature of emergency change means that it has been be agreed and authorized immediately.** See Section 8, Addendum 2: Emergency Change Process (page 29)

5.3 Process Exceptions

The protocols for managing exceptions will be included in subsequent versions of the CMPG & Standards document and will include the following areas, at a minimum:

Separation of duties conflicts, Required deliverables are not prepared, Required sign-offs or approvals are not received, Overrides of implementation go/no-go decisions, Non-emergency changes that must occur outside of release cycles, and An adequate QA environment is not available for testing.

15

VI CHANGE REQUEST Types – The ITIL Normal & Emergency Change Model

Different types of IT projects and infrastructure changes are categorized based on factors such as project size, number of impacted systems, and overall risk to the organization. The type categories help to further clarify the scope of the policies and processes defined by the CMPG & Standards document.

In terms of process scope, most Changes fall squarely in the middle of the Change Management process. Once the process is in place, the tools have been deployed, these types of changes rarely present significant issues.

However, the key to a successful and effective Change Management program lies in the ability of the process to handle the changes which occur around the edges of the process scope – not just the middle.

A few examples: How can we handle instances when a System Administrator needs to make a change to a setting on a

server? Does that fall within the scope of the Change Management process, or do we view this as routine operational “tuning”?

How do we treat desktop moves (i.e. moving an employee to a new office or cube)?

What procedures to leverage when there is a need to increase the allocated space on a shared drive (i.e. enterprise storage)?

ALL of these changes are likely to be included in the scope of the process.

The problem with such a zero tolerance approach to unauthorized/uncontrolled change is that it has the potential to be unwieldy and rigid. The IT Changes listed above occur on a (more or less) constant basis in most organizations, and the suggestion that each instance would require a formal approval process is likely to bring the IT staff a constant and ever increasing influx of unneeded effort.

Implementing ITIL ’s base Standard Change Management Model (Normal, Standard, and Emergency) provides a solution in eliminating bureaucracy, while streamlining the process.

16

http://www.beyond20.com/

6.1 TYPE CHANGE

Change Requests that is not an EMERGENCY type and follows all the Phases and activities defined in the Wedgewood, Inc.’s IT Change Management lifecycle process.

6.1.1 Process Flow Diagram – Normal Change

17

6.2 EMERGENCY TYPE CHANGE

Classified as typically a Normal change deemed to be urgent and required to be implemented as soon as possible. Essentially, it will follow the same process as the normal changes, but will be adapted to the emergency situation. If the CAB cannot meet quickly, the ECAB, having the authority level needed to make decisions, will be invoked. Testing must be carried out as much as possible, and documentation of change and configuration data may be completed later (example of urgent changes: solving a major incident, deploy an urgent security patch, etc.).

6.2.1 Process Flow Diagram – Emergency Change

18

6.3 Approval Matrix

Table 4: Approval Matrix

19

Responsibilities Busin

ess S

ubje

ct M

atter

Exp

ert

(SM

E)

Prog

ram

Dire

ctor

or C

hang

e M

anag

er

Requ

esto

r

Impl

emen

ter

IT L

eade

rshi

p or

Man

ager

IT S

taff

Tech

nica

l Ow

ner

Tech

nica

l Pee

r

Normal Change

Change Requests that is not an EMERGENCY type and follows all the Phases and activities defined in the Change Management lifecycle process. This CR type normally includes application new functionalities, enhancements, calculation changes and production fixes. This change type requires IT Manager approval and release scheduling prior to coming to the SPRINT Go/No Go (or CAB).

X P X X P X X X

Emergency Change

Immediate action is required to counter an emergency, to avert great damage to the business. System modifications necessary to comply with legal and regulatory requirements may also be considered emergencies. An Emergency Change may also be based on the critical functions of the business and can be deemed an emergency once appropriately reviewed. This change type requires IT Manager approval prior a CAB member signature.

X P X X P X X X

P = Primary ResponsibilityS = Secondary ResponsibilityX = Incompatible; separation of duties conflict

VII Addendum: Phases 1 – 4 Process Flow Narratives

7.1 Initiate, Assess & Approve – Phase I

Table 5: Change Request Process Phase I Overview

7.1.1 Process Narrative

Initiate and Assess is the first phase of the Infrastructure Change Management process. During this requests for IT projects are generally initiated through the use of a technical work request, but are not limited to other means i.e. email or other. Requests are assessed and if considered priorities, assigned to IT staff and assigned tentative dates on an implementation calendar within the Change Management module. Technical requirements for the change are defined, documented, and approved, helping to ensure Infrastructure changes are defined to minimize risk to the production environment.

Initiation – Changes, Technical Work Requests are resolutions or enhancements to application and or infrastructure and are received in one of two ways:

7.1.2 Entrance Criteria

Change Request (CR) TFS Record /Change Requests formally Change Request is listed in agenda of the SPRINT PLANNING MEETING for assessment and approval considerations.

TFS (Document of Record) is updated.

7.1.3 Exit Criteria

Change Request formally submitted and documented in TFS. Change Request has been reviewed and approved via SPRINT PLANNING MEETING

Tentative Release Schedule is assigned. TFS (Document of Record) is updated.

20


Design & Build Phase:Solution design & implementation plan

Test/QA Phase: Deployment Phase:Implementation, validation & closure

7.1.4 Phase 1: Detailed Roles and Responsibilities

Any listed table steps below are not mandatory and may be used or not used based on the discretion of IT Leadership and type of change;

Table 6: Phase I – Initiate and Assess


ess S

ubje

ct M

atter

Ex

pert

(SM

E)

Prog

ram

Di

rect

or/C

hang

e

Man

ager

Requ

esto

r

Impl

emen

ter

IT Le

ader

ship

or

Man

ager

IT S

taff

Tech

nica

l Pee

r

Phase I – Initiate and AssessIdentify production problems and or changes wanted to production and document production change needs an Incident, Request, Projects and or Problems

S S P S

Manages and organizes all requests S P SAssesses requests for costs, benefits, and other factors S P

Authorizes and prioritizes requests for development S P

Cancels/Defers change requests P STentatively assigns Requests to the release calendar S S P

Documents a project plan S PParticipates in the gathering of business requirements P S S

Documents business requirements S S SP = Primary ResponsibilityS = Secondary ResponsibilityX = Incompatible; separation of duties conflict

21

7.2 Design & Build – Phase II

The second phase of the Change Management process in which, business and technical requirements for changes are defined, documented, helping to ensure that design efforts are properly focused and changes to scope in later phases are minimized. The detailed steps of this process are described below.

Table 7: Change Request Process Phase II Overview


Phase II of the lifecycle where the Technical owners scope the effort and proceed with the design solution, development plan, map out the implementation plan and roll back strategies for the change(s). This includes review of all activities that attests to a successful build has been completed and documented.


Change Request record APPROVED Scheduled on RELEASE CALENDAR (Sprint Cycle) TFS (Document of Record) is updated

7.2.3 Exit Criteria

Completed Design/Dev Plan Defined impact, Test Plan, Rollback Plan (if applicable) TFS (Document of record) is updated

7.2.4 Baseline Configuration Standards

To meet the demand for high security and performance, baseline configuration standards may exist for all Infrastructure components but is change dependent. Depending on the nature of the Infrastructure change, updates to these baseline configuration standards may be required. Infrastructure groups should discuss pending changes with IT Leadership and other relevant groups, ensuring that baseline standards are updated, if appropriate.

22




7.2.5 Detailed Roles and Responsibilities

Table 8: PHASE II Roles & Responsibilities


ess S

ubje

ct M

atter

Ex

pert

(SM

E)

DevO

ps P

rogr

am M

anag

er

or C

hang

e M

anag

er

Requ

esto

r

Impl

emen

ter

IT Le

ader

ship

or M

anag

er

Tech

nica

l Ow

ner

Tech

nica

l Pee

r

Phase II – Design

Designs/configures change in test labP S

Documents Implementation and Rollback Plan P S


23

7.3 Testing & Quality Assurance – Phase III

Table 9: Change Request Process Phase III Overview


Implement is the fourth phase of the Infrastructure Change Management process. During this phase, changes are implemented into production according to an established set of implementation procedures. Technical validation occurs to help ensure the change is implemented properly. The detailed steps of this process are described below.

Successful Implementation (Testing and/or Staging environment) Steps:

Notify Impacted Groups of Pending Implementation – The Implementer works with the appropriate teams who then notify the impacted business and IT groups of the pending implementation as defined in the Implementation and Rollback Plan.

Implements Change into Production – The Implementer installs the change into production as defined in the Implementation and Rollback Plan.

Technical Validation – The Implementer executes the technical validation procedures defined in the Implementation and Rollback Plan. If change is not a success Implementer goes to the steps for an unsuccessful implementation.

Unsuccessful Implementation (Testing and/or Staging environment) Steps:

Resolve/Rollback – Depending on the severity of any issues experienced, the Implementer first attempts to correct any related problems that can be corrected during the defined implementation window. If the change cannot be resolved, the Implementer removes the change from production using the procedures defined in the Implementation and Rollback Plan. If the change cannot be removed from

production, the emergency change process is initiated.

Notify Impacted Groups of Failed Implementation – Implementer works with the appropriate teams who then notify the impacted business and IT groups of the implementation failure as defined in the Implementation and Rollback Plan.

24




Perform Root Cause Analysis – The Implementer logs any defects that are attributable to program code. The Technical Owner manages a root cause analysis process to identify the source(s) of problems

encountered with the implementation.

25

7.3.2 Testing Considerations

If non-code related issues are encountered during the implementation, the Implementer should work to resolve any issues and test the change’s implementation plan, provided the issue(s) can be resolved within the defined implementation staging window. Significant troubleshooting efforts should be recorded.


Defined Test Plan Resource has been identified and assigned to execute Test effort.

7.3.4 Rolling or Phased Implementations (Staging environment)

The Implementation and Rollback Plan for some Infrastructure changes, such as deploying service packs to company’s desktops, may define a rolling or phased implementation process whereby the change(s) are first deployed to a subset of Infrastructure components, evaluated, and then deployed to a broader group. Such deployments may not always occur during the same implementation window/timeframe.

After deployment authorization is received, Infrastructure groups should execute against the approved Implementation and Rollback Plan. Additional approval is reviewed on a case by case basis and may be required for subsequent phases of the implementation, although the notification requirements documented in the Strategy must be met throughout the process.

7.3.5 Exit Criteria (Successful Implementation)

Results are logged (included with Change Record – TFS)

7.3.6 Exit Criteria (Testing environment - Unsuccessful Implementation)

Results are logged (included with Change Record – TFS) Notification of test results to Program Manager, DevOps Lead, CIO, Change

Requestor, etc. Assessment for re-testing, OR re-scheduling.

26


Table 10: PHASE III Roles & Responsibilities

27

Responsibilities B

usin

ess S

ubje

ct M

atter

Exp

ert

(S

ME)

DevO

ps P

rogr

am M

anag

er o

r Ch

ange

Man

ager

Req

uest

or

Impl

emen

ter/

T S

taff/

IT

Lead

ersh

ip o

r Man

ager

Tech

nica

l Pee

r

Phase III - Implementation

Notifies impacted groups of pending implementation S S P

Implements change into production X X X P

Performs Technical Validation P SResolves implementation issues or executes rollback procedures

X X X P S

Notifies impacted groups of successful/failed implementation, if applicable

P

Performs root cause analysis, if applicable S S


7.4 Deploy, Validate & Close – Phase IV

Table 10: Change Request Process PHASE IV Overview


Validate and Close is the fourth and final phase of the Infrastructure Change Management process. During this phase, a Business representative and or IT Staff validates changes to help ensure the required functionality operates correctly in production and that primary controls continue operate effectively. The detailed steps of this process are described below.

Execute and Document User Validation – If RCA is considered necessary, the IT Manager may consider the potential risks to application functionality and controls. If necessary, the IT Manager or delegate coordinates user validation efforts with Business SMEs that help verify that the change does not introduce application errors. Any issues noted during this process are logged as problems in problem tickets and managed through the problem management process unless otherwise deemed unnecessary from IT Leadership. Otherwise, the request is closed by the IT Staff or Technical Owner.

Document Functional Acceptance – The IT Manager or designated IT Staff or Peer, where necessary, evaluates the user validation test results and formally documents final acceptance of the change.

Close Change – The Technical Owner closes the Change.


Testing has been fully executed and validated successfully. Implementation (Production Environment) Plan defined.

7.4.3 Exit Criteria

Document of record (TFS) updated and state is updated to “CLOSED”. Lessons Learned meeting summary, as applicable.

28





Table 12: Phase VI: Validate and Close


ess S

ubje

ct M

atter

Exp

ert (

SME)

DevO

ps P

rogr

am M

anag

er o

r Ch

ange

M

anag

er

Requ

esto

r

Impl

emen

ter

IT Le

ader

ship

or M

anag

er

IT S

taff

Tech

nica

l Ow

ner

Tech

nica

l Pee

r

Phase IV - Validate and Close

Determines if User Validation is necessary S S

Executes User Validation P P SAccepts change, approving User Validation P

Closes Change S P S SConducts Lessons Learned meeting, as needed S P S


29

VIII Emergency Change ProcessEmergency changes result from production problems or other events and require immediate resolution. Emergency changes are considered so important that the company’s risk tolerance is increased and a willingness to implement changes that may not be fully defined and approved by the business or adequately tested exists. Emergency changes may occur in one of the following scenarios:

1) A production problem that needs immediate action to counter or avert great damage to the business.2) An unsatisfied legal or regulatory requirement exists and non-compliance presents immediate issues to the

company.

8.1 Definition & Process Narrative

The Emergency Change process describes how the company manages changes that must be immediately implemented to address a production problem or other issue. Requirements definition processes are generally less rigorous for these changes due to the compressed timeframe. The detailed steps of this process are described below.

Identify – Production problems are identified and logged as Change Request (TFS) through the change management process. *

Investigate – IT staff / Technical Owner investigates the cause of the problem(s) and define a solution to address the incident / problem or its symptom(s).

Review Proposed Solution – A Technical Peer reviews the proposed solution, contributing ideas and challenging the approach presented by the Technical Owner.

Approve Change – The Emergency Change is approved by the appropriate IT Management/resource (DevOps BSA, Service Desk Leads, Applications Architect or Lead) along with the Program Manager (Change Manager) or IT Leadership.

Implement – If the change is considered ready for production, the change is implemented into production by the Technical Owner immediately.

Validate – A Subject Matter Expert and or IT Staff validates the change for the emergency and verifies that issue have been corrected. If the emergency condition persists, the solution is re-visited and the process returns to the Investigate stage.

Update and Close Change Request record (TFS) – The IT Staff / Technical Owner updates and closes the change request. **

Root Cause Analysis – Whenever needed, the IT Staff performs a root cause analysis of the issues that resulted in the emergency. If the solution implemented to address an emergency only corrects problem symptoms, and not the root cause of the problem, a Technical Work Request must be opened to correct the root cause followed by another Change Request to put into Production.

Post-Emergency Assessment – Whenever needed, the IT Leadership and Change Manager conducts a post-emergency assessment to gain an understanding of the issues encountered and the root causes of the issue as well as to determine if additional design is required to correct other issues or further stabilize the system.

* During “urgent” Emergency circumstances where time is of the essence, changes will go through the normal expedited process and documentation efforts can be executed afterwards.

** Can be performed “after” emergency change has been deployed/implemented into the Prod system.

30

8.2 Detailed Roles and Responsibilities

Table 13: Emergency Changes – Detailed Roles and Responsibilities


ess S

ubje

ct M

atter

Ex

pert

(SM

E)

DevO

ps P

rogr

am M

anag

er

or C

hang

e M

anag

er

Impl

emen

ter

IT Le

ader

ship

or M

anag

er

IT S

taff

Phase IV - Validate and Close

Identifies production emergencies P PInvestigates production emergencies S PReviews proposed solution(s) S SApproves emergency changes P P

Implements change in production X X

Validates change in production P PUpdate and Close Change Request S

Post-Emergency Assessment P P S


31