The document defines Wedgewood Inc.'s IT change management process, activities, and roles. It establishes a framework for managing infrastructure changes through standardized methods and procedures. The objectives are to improve service/support quality, reduce risks and costs from changes, and achieve compliance. Key aspects include a change advisory board, four-phase change lifecycle of initiate/assess, design/build, test, and deploy/validate/close, and roles such as change manager and project sponsors.

1. 1
Preparedby:
Project Sponsor(s):
ITIL Consultant:
Wedgewood, Inc. Contributors:
Date Created:
Date Last Modified:
Edward Pagsanhan
Paul Volkman
StephenReynolds
Douglas Fernandez
Edward Pagsanhan
StephenReynolds
Douglas Fernandez
07.24.2016
09.__.2016
IT Change Management v4.0
Process Guide & Standards

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

3. 2
DOCUMENT PURPOSE
This document defines the Wedgewood, Inc.’s IT Change Management (CM) process, activities, and accountable roles for the IT
organization.
Planningand adoption of an agreed upon ChangeManagement process (with supportingprocedures 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 RevisionDate Revisedby Description
1.0 7/24/2016 Edward Pagsanhan Initial Document Creation
1.2 8/3 EP Identify and Definingbase 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

4. 3
TABLE OF CONTENTS
I INTRODUCTION .................................................................................................................... 5
1.1 OVERVIEW...............................................................................................................................................................6
1.2 SCOPEAND APPLICABILITY.......................................................................................................................................7
1.3 DOCUMENT CONTROL AND COMMUNICATION .........................................................................................................8
1.4 PERIODIC REVIEW AND APPROVAL...........................................................................................................................8
1.5 GOVERNANCE &OVERSIGHT....................................................................................................................................8
II GLOSSARY OF TERMS, DEFINITIONS AND ACRONYMS....................................................... 9
2.1 TABLE 1: GLOSSARY.................................................................................................................................................9
III PROCESS FLOW OVERVIEW................................................................................................ 11
3.1 PROCESS NARRATIVE (HIGH LEVEL OVERVIEW)......................................................................................................11
3.2 CHANGE LIFECYCLE: DEFINITIONS ...........................................................................................................................11
3.2.1 Initiate, Assess & Approve – Phase I...............................................................................................11
3.2.2 DESIGN & BUILD –PHASE II......................................................................................................................12
3.2.3 TESTING & QUALITY ASSURANCE –PHASE III............................................................................................12
3.2.4 DEPLOY,VALIDATE &CLOSE –PHASE IV ..................................................................................................12
3.3 ENTRANCEAND EXIT CRITERIA................................................................................................................................13
IV ROLES & RESPONSIBILITIES OVERVIEW............................................................................. 10
4.1 TABLE 2: SUMMARY OF ROLES ...............................................................................................................................14
V THE CHANGE ADVISORY BOARD (CAB)......................... ERROR! BOOKMARK NOT DEFINED.
5.1 CAB – PROCESS OVERVIEW...................................................................................................................................15
5.2 THE EMERGENCY CHANGE ADVISORY BOARD (ECAB)............................................................................................15
5.3 PROCESS EXCEPTIONS ............................................................................................................................................15
VI CHANGE TYPES - THE ITIL NORMAL & EMERGENCY CHANGE MODEL............................. 16
6.1 NORMAL CHANGE TYPE …………………………………………………………………………………………………………..........17
6.1.1 Process Flow Diagram – Normal Change ……………………………………………………………………....17
6.2 EMERGENCY CHANGE TYPE ……......................................................................................................... 18
6.2.1 Process Flow Diagram – Emergency Change…………………………………………………………………..18
6.4 APPROVAL MATRIX………………………………………………………………………………………………………………………. 19

5. 4
VII ADDENDUM 1: PHASES 1 – 4 PROCESS FLOW NARRATIVES.…………………………………………20
7.1 NITIATE, ASSESS & APPROVE – PHASE I.……………………………………………………………………………………………..ERROR! BOOKMARK
NOT DEFINED.
7.1.1 Process Narrative…………………………………………………………………………………………………………..20
7.1.2 Entrance Criteria ……………………………………………………………………………………………………………20
7.1.3 Exit Criteria ……………………………………………………………………………………………………………….....20
7.1.4 Phase 1: Detailed Roles & Responsibilities...…………………………………………………………………..21
7.2 DESIGN & BUILD- PHASE II.………………………………………………………………………………………………….…..……..22
7.2.1 PROCESS NARRATIVE…………………………………………………………………………………………………….……..22
7.2.2 ENTRANCE CRITERIA . …………………………………………………………………………………………………………. 22
7.2.3 EXIT CRITERIA..…………………………………………………………………………………………………………..………22
7.2.4 BASELINE CONFIGURATION..…………………………………………………………………………………….………..... 23
7.2.5 DETAILED ROLES AND RESPONSIBILITIES ………………………………………………………………………………….. 23
7.3 TESTING & QUALITY ASSURANCE –PHASE III ……………………………………………………………………………………….24
7.3.1 PROCESS NARRATIVE ……………………………………………………………………………………………………….....24
7.3.2 Implementation Considerations …………………………………………………………………….………………25
7.3.3 Entrance Criteria…………………………………………………………………………………………………………….25
7.3.4 Rolling or Phased Implementations………………………………………………………………………………..25
7.3.5 EXIT CRITERIA (SUCCESSFUL IMPLEMENTATION)………………………………………………………………………….25
7.3.6 EXIT CRITERIA (UNSUCCESSFUL IMPLEMENTATION)……………………………………………………………………..25
7.3.7 DETAILED ROLES AND RESPONSIBILITIES……………………………………………………………………………………26
7.4 Deploy, Validate & Close – Phase IV..………………………………………………………………………………..………27
Table 10: Change Request Process PHASE IV Overview……………………………………………………………27
7.4.1 Process Narrative ………………………………………………………………………………………………………….27
7.4.2 ENTRANCE CRITERIA..................................................................................................................................27
7.4.3 EXIT CRITERIA ...........................................................................................................................................27
7.4.4 DETAILED ROLES AND RESPONSIBILITIES ....................................................................................................28
VIII ADDENDUM 2: EMERGENCY CHANGE PROCESS................................................................ 29
8.1 DEFINITION &PROCESS NARRATIVE ......................................................................................................................29
8.2 Detailed Roles & Responsibilities ...………………………………………………………………………………….31

6. 5
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 managingtechnology 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 changeprocesses. Wedgewood, Inc.’s CMProcess Guideand standards documentdefines 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 risksby defininga framework thathelps ensurethat technology changes areproperly 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 changesto service assetsand configurationitemsare recordedinthe ConfigurationManagement
System (CMS), or the Knowledge Base component of the system of record tool.
The objectives for Wedgewood, Inc.’s technology Change Management processes areto:
 Improve service andsupporttoclientsandcustomersbydevelopingandmaintainingsystemsthatare
aligned with strategy, needs, and expectations;
 Improve qualityby establishingbaseline controls throughoutthe 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.

7. 6
1.2 Scope and Applicability
This document addresses changes to databases,operatingsystems, and network connected devices that fall into one of
the following categories:
1. Any core/production network devices
2. DB servers,
3. Application systems (typically includesconfiguration changes for codelaunch),
4. Security Changes,
5. Has a potential impact on revenue,
6. Requires downtime,
7. Could resultin downtime to internal users,customers and partners,
8. Will changesystemarchitecture and/or monitoringpractices,
9. Will impactother departments or systems.
Exclusions
The policies and processes described in the Change Management Process Guideand 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 Infrastructure
4. Staging Infrastructure,
5. Application / Systems production running on end user dedicated desktops (Section 3.4)
6. Building Facilities
7. BuildingAccess Control –The systems and equipment providingcontrol over ingress and egress to Wedgewood,
Inc.’s facilities,such as automatic door locks and closed circuittelevision,arenotsubjectto the processes defined
in the CMPG standards document.
8. Non-Production Systems – Changes to non-production systems and data arenot subjectto 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 theseareas are currently not subject to Wedgewood, Inc.’s changemanagementprotocols, it is expected that thebusiness and/or technology
owner(s) of excluded entities and technologies conductallchanges with an appropriate levelofdue care.ITLeadership is permittedto addanyofthe
exclusions above to theChangeManagementprocess as theyseefit. Any questions concerning changes to excluded entities andtechnologies should
be directed to the ITInfrastructure & Operations ChangeManager (aka ITDevOps Program Manager and theDevOps Application Architect).

8. 7
1.3 Document Control and Communication
The CMPG and standards document is subjectto version control and all substantivechanges 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 ITLeadership Team must re-assess
and re-approve said document. Evidence of this approval will bedocumented 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 providegovernance 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 complianceauditsperformed by the IT Operations & Infrastructure Managers,the Change Manager or
his/her designee, and
3) Self-assessmentsurveys.
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.

9. 8
II Glossary of Terms, Definitions andAcronyms
The purpose of this glossary is to providean accessiblelistof 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 Baselineconfiguration standardsdocumentis theconfiguration standard thatis referred
to as an organization’s “best practices” applied across infrastructure components such
as routers,firewall,switches,servers,databaseservices etc. These form a guide to meet
an organization’s risk matrix.
Change
Advisory
Board
CAB A group of people that advices theChangeManager 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 efficientand prompt handlingof all changes to control ITinfrastructure,in order
to minimize the number and impact of any related incidents upon service. Changes in
the IT infrastructuremay arisereactively in responseto 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 handlingof all changes,and maintain the proper balance between the need
for change and the potential detrimental impact of changes.
Request For
Change
OR
Change
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 lifeof 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 objectiveof this systemis to avoid the introduction of errors
related to lack of testing as well as incompatibilities with other CIs.

10. 9
Name Acronym Definition
Configuration
Management
Database
CMDB A configuration management database (CMDB) is a repository of information related to
all thecomponents of an information system. Itcontains the details of the configuration
items (CI) in the ITinfrastructure.Although repositories similar to CMDBs havebeen used
by IT departments for many years, the term CMDB stems from ITIL (Information
Technology InfrastructureLibrary).In theITILcontext,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 projectto achieveits mission.Itis a critical factor or activity required for
ensuringthe 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 understandingof what is importantto the organization.'Whatis important' often
depends on the department measuringthe 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,areassociated 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.

11. 10
Name Acronym Definition
Known-Error KE In ITOperations 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 supportgroups,includingtheprocess 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 approvea 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 thattries to identify the root
causes of faults or problems that causeoperatingevents.
Service Level
Agreement
SLA A service-level agreement (SLA) is a partof a servicecontract where a serviceis
formally defined. In practice,the term SLA is sometimes used to refer to the contracted
delivery time (of the serviceor performance). As an example, internet serviceproviders
will commonly includeservicelevel agreements within the terms of their contracts with
customers to define the level(s) of servicebeingsold in plain languageterms.
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 arecentrally hosted on the cloud.

12. 11
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 areof 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, and
4) 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.
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
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Build Phase: Test/QA Phase: Deployment Phase:

13. 12
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, and
3) 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 activitiesareperformed followingthe
defined Test Plan and Scope approved duringthe 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)
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

14. 13
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
phaseand generally meet all exitcriteria prior to transitioningto the next phase. The specific entry and exit criteria for
each phase are defined in detail in later sections of this document.

15. 14
IV Roles and Responsibilities Overview
4.1 Table 3: Summary of Roles
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 acton behalf of a tester as applicable. Additional duties may includetestingsign-
off for a vendor or business unit. TheProject Manager may represent as the Requestor
as times as well.
Implementer
The 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 managingthe development of a
system or data change. The IT Staff or Technical Owner may also acton behalf of a
tester and or as applicablesign-off for a vendor.

16. 15
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 followingmembers and is responsiblefor the communication back to the appropriateteams
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 ProgramManager Enterprise Application Architect,DevOps BSAs, other ITLeadership or their
delegates.
5.2 The Emergency Change Advisory Board (ECAB)
Leveraged as an escalation path or expedited process for Changes to Production that requireto be deployed outsideof
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 managingexceptions 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.

17. 16
VI CHANGEREQUEST 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 handlethe
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? Doesthatfall withinthe scope of the ChangeManagementprocess,ordowe viewthisas routine
operational “tuning”?
 How do we treat desktop moves (i.e. moving an employee to a new office or cube)?
 What procedurestoleverage whenthere isaneed to increase the allocatedspace ona shareddrive (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.

18. 17
6.1 TYPE CHANGE
Change Requests that is not an EMERGENCY type and follows all thePhases and activities defined in the Wedgewood, Inc.’s
IT Change Management lifecycle process.
6.1.1 Process Flow Diagram – Normal Change

19. 18
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, havingthe authority level needed to make decisions,will beinvoked. Testing must be
carried outas 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

20. 19
6.3 Approval Matrix
Table 4: Approval Matrix
Responsibilities
BusinessSubjectMatterExpert
(SME)
ProgramDirectororChange
Manager
Requestor
Implementer
ITLeadershiporManager
ITStaff
TechnicalOwner
TechnicalPeer
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
EmergencyChange
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 EmergencyChange mayalsobe basedonthe
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 Responsibility
S = Secondary Responsibility
X= Incompatible;separation of duties
conflict

21. 20
VII Addendum: Phases 1 – 4 Process FlowNarratives
7.1 Initiate, Assess & Approve – Phase I
Table 5: Change Request Process Phase I Overview
7.1.1 Process Narrative
Initiateand Assess is the firstphase of the InfrastructureChange 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 areassessed 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 changearedefined, documented, and approved,helpingto ensure Infrastructurechanges
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 assessmentand 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.
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Design & Build Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Implementation,
validation & closure

22. 21
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
Responsibilities
BusinessSubjectMatter
Expert(SME)
Program
Director/Change
Manager
Requestor
Implementer
ITLeadershipor
Manager
ITStaff
TechnicalPeer
Phase I – Initiate and Assess
Identifyproductionproblemsandor
changeswanted to productionand
documentproductionchange needsan
Incident,Request,Projectsandor
Problems
S S P S
Manages andorganizesall requests S P S
Assessesrequestsforcosts,benefits,and
otherfactors
S P
Authorizesandprioritizesrequestsfor
development
S P
Cancels/Deferschange requests P S
TentativelyassignsRequeststothe
release calendar
S S P
Documentsa projectplan S P
Participatesinthe gathering of business
requirements
P S S
Documentsbusinessrequirements S S S
P = PrimaryResponsibility
S = SecondaryResponsibility
X = Incompatible;separationof duties
conflict

23. 22
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
7.2.1 Process Narrative
PhaseII of the lifecyclewhere 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.
7.2.2 Entrance Criteria
 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, baselineconfiguration standardsmay existfor all
Infrastructure components but is change dependent. Depending on the nature of the Infrastructure
change, updates to these baselineconfiguration standardsmay be required. Infrastructuregroups should
discusspendingchanges with ITLeadership and other relevant groups,ensuringthatbaselinestandardsare
updated, if appropriate.
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Design & Build Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Implementation,
validation & closure

24. 23
7.2.5 Detailed Roles and Responsibilities
Table 8: PHASE II Roles & Responsibilities
Responsibilities
BusinessSubjectMatter
Expert(SME)
DevOpsProgramManager
orChangeManager
Requestor
Implementer
ITLeadershiporManager
TechnicalOwner
TechnicalPeer
Phase II – Design
Designs/configureschange intest lab
P S
DocumentsImplementationand
RollbackPlan P S
P = PrimaryResponsibility
S = SecondaryResponsibility
X = Incompatible;separationof duties
conflict

25. 24
7.3 Testing & Quality Assurance – Phase III
Table 9: Change Request Process Phase III Overview
7.3.1 Process Narrative
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 ITgroups of the pending implementation as defined
in the Implementation and Rollback Plan.
Implements Change into Production – The Implementer installs thechange 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 –Dependingon the severity of any issues experienced,the Implementer firstattempts
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.
Perform Root CauseAnalysis –The Implementer logs any defects that are attributableto program code.
The Technical Owner manages a root cause analysis process to identify the source(s) of problems
encountered with the implementation.
Asessment Phase:
Functional Design
Specification review & RFC
Classification
Design & Build Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Implementation, validation
& closure

26. 25
7.3.2 Testing Considerations
If non-code related issues are encountered during the implementation, the Implementer should work
to resolveany issues and testthe change’s implementation plan,provided the issue(s) can beresolved
within the defined implementation staging window. Significant troubleshooting efforts should be
recorded.
7.3.3 Entrance Criteria
 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 firstdeployed to a subset of Infrastructurecomponents, 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 caseby 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)
 Resultsare logged(includedwithChange Record –TFS)
7.3.6 Exit Criteria (Testing environment - Unsuccessful Implementation)
 Results are logged (included with Change Record – TFS)
 Notification of test results to ProgramManager, DevOps Lead, CIO, Change
Requestor, etc.
 Assessment for re-testing, OR re-scheduling.

27. 26
7.3.7 Detailed Roles and Responsibilities
Table 10: PHASE III Roles & Responsibilities
Responsibilities
BusinessSubjectMatterExpert
(SME)
DevOpsProgramManageror
ChangeManager
Requestor
Implementer/TStaff/IT
LeadershiporManager
TechnicalPeer
Phase III - Implementation
Notifiesimpactedgroupsof
pendingimplementation S S P
Implementschange into
production
X X X P
PerformsTechnical Validation P S
Resolvesimplementation
issuesorexecutesrollback
procedures
X X X P S
Notifiesimpactedgroupsof
successful/failed
implementation,if applicable
P
Performsrootcause analysis,if
applicable S S
P = PrimaryResponsibility
S = SecondaryResponsibility
X = Incompatible;separation of
dutiesconflict

28. 27
7.4 Deploy, Validate & Close – Phase IV
Table 10: Change Request Process PHASE IV Overview
7.4.1 Process Narrative
Validate and Close is the fourth and final phase of the Infrastructure Change Management process.
Duringthis phase,a Business representativeand or ITStaff validates changes to help ensuretherequired
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 otherwisedeemed 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.
7.4.2 Entrance Criteria
 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.
Asessment Phase:
Functional Design
Specification review &
RFC Classification
Design & Build
Phase:
Solution design &
implementation plan
Test/QA Phase: Deployment Phase:
Implementation, validation&
closure

29. 28
7.4.4 Detailed Roles and Responsibilities
Table 12: Phase VI: Validate and Close
Responsibilities
BusinessSubjectMatterExpert(SME)
DevOpsProgramManagerorChange
Manager
Requestor
Implementer
ITLeadershiporManager
ITStaff
TechnicalOwner
TechnicalPeer
Phase IV - Validate and Close
Determinesif UserValidationis
necessary
S S
ExecutesUserValidation P P S
Acceptschange,approvingUser
Validation
P
Closes Change S P S S
ConductsLessonsLearned
meeting,asneeded
S P S
P = Primary Responsibility
S = Secondary Responsibility
X = Incompatible;separationof
dutiesconflict

30. 29
VIII Emergency Change Process
Emergency changes result from production problems or other events and require immediate resolution.
Emergency changes areconsidered so importantthat the company’s risk toleranceis 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-compliancepresents 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 aregenerally
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 causeof 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,contributingideas 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) alongwith the ProgramManager (Change Manager) or
IT Leadership.
Implement – If the changeis considered ready for production,the changeis implemented into production by the
Technical Owner immediately.
Validate – A Subject Matter Expert and or IT Staff validates thechange 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 causeanalysisof the issues thatresulted
in the emergency. If the solution implemented to address an emergency only corrects problem symptoms,
and not the root causeof 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 assessmentto gain an understandingof the issues encountered and the root causes of the issueas
well as to determine if additional design is required to correct other issues or further stabilize the system.
* During “urgent” Emergency circumstanceswhere timeisof the essence, changeswill go through the normal expedited
processand documentation effortscan be executed afterwards.
** Can be performed “after” emergency change hasbeen deployed/implemented into the Prod system.

31. 30
8.2 Detailed Roles and Responsibilities
Table 13: Emergency Changes – Detailed Roles and Responsibilities
Responsibilities
BusinessSubjectMatter
Expert(SME)
DevOpsProgramManager
orChangeManager
Implementer
ITLeadershiporManager
ITStaff
Phase IV - Validate and Close
Identifiesproductionemergencies P P
Investigatesproductionemergencies S P
Reviewsproposedsolution(s) S S
Approvesemergencychanges P P
Implementschange inproduction X X
Validateschange in production P P
Update and Close Change Request S
Post-EmergencyAssessment P P S
P = Primary Responsibility
S = Secondary Responsibility
X = Incompatible;separationof duties
conflict