Enterprise Change and Configuration Management Plan

This document is Intellectual Property of for Internal Use only.

It may not be sold or distributed in hard copy or electronic format to any other company and/or association without permission.

Document Control

This is a controlled document produced by Agency Name. The control and release of this document, including any required amendments, is the responsibility of .

|Issue Control |
|Document Reference | |Project Number | |
|Issue | |Date | |
|Classification |FOUO |Author(s) | |
|Document Title | Enterprise Change and Configuration Management Plan |
|Approved By | |
| | |

|Owner Details |
|Name | |
|Office/Region | |
|Contact Number | |
|Email Address | |

|Version History |
|Version # |Date |Author |Description of Change |
|1.0 | | | |
|2.0 |3 | | |

Contents

Document Control iii

EXECUTIVE SUMMARY vii

1.0 Overview 1

1.1 Introduction 1 1.2 Purpose 1 1.3 Scope 1 1.4 Reference Documents 2 1.5 Change and Configuration Management Plan Maintenance 2 1.6 Change and Configuration Management Program 3 1.7 Enterprise Change and Configuration Tools 4

2.0 Enterprise Change and Configuration Policies 5

3.0 Enterprise Change and Configuration Roles and Responsibilities 6

3.1 Enterprise Change Control Board (ECCB) 6 3.2 Architectural Review Board (ARB) 6 3.3 Engineering Review Board (ERB) 6 3.4 Enterprise Change and Configuration Process Owner 6 3.5 Enterprise Change and Configuration Manager 7 3.6 Enterprise Change and Configuration Coordinator 7 3.7 Enterprise Change and Configuration Tools Administrator 7

4.0 Configuration Management 9

4.1 Configuration Management Process 9 4.1.1 Configuration Identification 10 4.1.2 Configuration Control 12 4.1.3 Configuration Verification and Audit 13 4.1.4 Configuration Status and Reporting 14 4.2 Enterprise Directorate and Service Directorate Configuration Roles and Responsibilities 15 4.2.1 Configuration Process Manager 15 4.2.2 Configuration Coordinator 15 4.2.3 Configuration Item Custodian 16

5.0 Change Management 17

5.1 Change Management Process 18 5.1.1 Draft 19 5.1.2 Request for Authorization 20 5.1.3 Request for Change 22 5.1.4 Planning in Progress 23 5.1.5 Scheduled for Review 24 5.1.6 Scheduled for Approval 25 5.1.7 Scheduled 26 5.1.8 Implementation in Progress 27 5.1.9 Completed 28 5.1.11 Emergency Change 30 5.1.12 Rollback 31 5.2 RFC Impact and Risk 32 5.3 RFC Urgency 33 5.4 Request for Change Types 34 5.4.1 No Impact Change 34 5.4.2 Normal Change 34 5.4.3 Latent Change 34 5.4.4 Expedited Change 34 5.4.4 Emergency Change 35 5.5 Change Dispositions 36 5.5.1 Approved 36 5.5.2 Rejected 36 5.5.3 Pending 36 5.5.4 Cancelled 36 5.6 Change Exceptions 36 5.6.1 Request for Deviation (RFD) 36 5.6.2 Request for Waiver (RFW) 36 5.6.3 Request for Deferral 36 5.7 Outages 37 5.7.1 Planned/Scheduled 37 5.7.2 Unplanned/Unscheduled 37 5.7.3 Emergency Outages 37 5.8 Enterprise Directorate and Service Directorate Change Roles and Responsibilities 37 5.8.1 Change Requestor 37 5.8.2 Change Manager 38 5.8.3 Change Coordinator 38 5.8.4 Change Assignee 39 5.8.5 Change Implemeter 39 5.8.6 Task Implementer 39 5.8.7 Change Control Board (CCB) 40 5.9 Interface Management 40 5.10 Traceability of Changes to Documentation 40

6.0 Request for Change Forms 41

7.0 Change and Configuration Metrics 42

7.1 Enterprise Metrics 42 7.2 Enterprise Directorate Metrics 42 8.0 Change and Configuration Audit 43 8.2 Audit Types 43

9.0 Archiving Storage and Disposal 44

10.0 Process Interfaces 45

10.1 Incident Management 45 10.2 Problem Management 45 10.3 Asset Management 46

11.0 Continuous Improvement 47

11.1 Continuous Improvement Process 47 11.1.1 Process Activities 47

Appendix E 49

Acronyms 49

Appendix F 50

Glossary of Terms 50

Table of Figures

Figure 1 Hierarchy of the Change Control Boards 4
Figure 2 Configuration Management Process 9
Figure 3 Configuration Identification 11
Figure 4 Configuration Control 12
Figure 5 Configuration Verification and Audit 13
Figure 6 Configuration Status and Reporting 14
Figure 7 Enterprise Change Management Process 18
Figure 8 Draft 19
Figure 9 Request for Authorization 20
Figure 10 Request for Change 22
Figure 11 Planning in Progress 23
Figure 12 Schedule for Review 24
Figure 13 Scheduled for Approval 25
Figure 14 Scheduled 26
Figure 15 Implementation in Progress 27
Figure 16 Completed 28
Figure 17 Closed 29
Figure 18 Emergency Change 30
Figure 19 Rollback 31
Figure 20 Impact and Risk Matrix 32
Figure 21 Urgency Matrix 33
Figure 22 Impact, Risk and Urgency Relationships 35
Figure 23 Continuous Improvement Process 48

EXECUTIVE SUMMARY

This document is the Enterprise Change and Configuration Management Plan (ECCMP) for the Agency Name. This ECCMP describes the elements of Change and Configuration Management and how these processes will be performed at the Enterprise level. This ECCMP also describes the processes of Change and Configuration Management that are required within Enterprise Directorates and Service Directorates. Enterprise Directorate process maps and narratives along with the Service Directorate specific Change and Configuration Management Plan and related procedures are included as separate appendixes to this ECCMP.

The organization of this ECCMP is as follows:

• Section 1, Overview – Contains the introduction, purpose, scope, list of reference documents, tools and describes the plan for maintaining this document.

• Section 2, Enterprise Change and Configuration Policies – Describes the policies that support the objectives for the change and configuration processes.

• Section 3, Enterprise Change and Configuration Roles and Responsibilities – Identifies the roles within Enterprise Change and Configuration Management and defines the responsibilities.

• Section 4, Configuration Management – Describes the processes for selecting and identifying configuration items (CIs), item naming conventions, labeling work products, managing configuration baselines, and use of libraries for configuration control.

• Section 5, Change Management – Describes the standardized method of proposing, coordinating, adjudicating, and implementing changes to approved baselines. It includes the change process, control boards, and interface management.

• Section 6, Request for Change Forms – Describes the forms within a change record and the required fields.

• Section 7, Change and Configuration Metrics– Describes the record keeping and reporting necessary to support the identification and control processes.

• Section 8, Change and Configuration Management Audit – Describes when, how, and by whom audits will be performed.

• Section 9, Archiving Storage and Disposal – Describes the archiving storage and disposal requirements.

• Section 10, Process Interfaces – Describes interfaces between the Change and Configuration Management process and other Agency Nameprocesses.

• Section 11, Continuous Improvement – Describes the processes behind performing process improvement efforts.

1.0 Overview

1.1 Introduction

This document is the Agency Name Enterprise Change and Configuration Management Plan (ECCMP). This ECCMP is intended to integrate the management of all enterprise configurations, and address all aspects of Agency Name change management and configuration management.

1.2 Purpose

The overall purpose of the ECCMP is to implement and sustain change and configuration processes and mitigate risk by effectively tracking and assessing changes to the Agency Name production environment according to best practices through an accurate baseline and relationship model of all services within the products and Service Catalog.

The ECCMP has been developed to provide guidance and a framework for defining standard and repeatable change and configuration processes at the Enterprise Operations and Service Operations levels that include governance and accountability. These processes are to be used to identify impact of and control the risk associated with changes to the production IT environment, and provide visibility and traceability throughout .

1.3 Scope

This ECCMP covers all processes and activities related to the stand-up and sustainment of an Enterprise Change and Configuration Management (ECCM) program within the Agency Name. It identifies the Enterprise Change and Control Board’s (ECCB) level of authority according to the charter and provides the roles and responsibilities for all participants within the Enterprise Change and Configuration processes. The ECCMP defines Enterprise Change and Configuration, metrics, policies, impact, risk and urgency levels. Furthermore, the ECCMP defines the Enterprise Directorate Change and Configuration process along with the minimum Service Directorate Change and Configuration process requirements in order to support the goals of the Agency Name.

Under this ECCMP, Change and Configuration Management (CCM) will be performed on all services offered by the Agency Name as documented in the Agency Name Service Catalog along with services not included in the Service Catalog. This includes all hardware, software, virtual environments, heating, ventilating and air conditioning (HVAC) items and documents that are owned, serviced, or published by the Agency Name.

The ECCMP does not define how or when each Service Directorate will conduct their CCBs or training, but rather requires the Individual Service Directorates to develop or augment their current processes and training to manage change and control their configuration items in accordance with the ECCMP minimum process requirements.

The ECCMP will be the governing change and configuration management process for all Enterprise Directorates, with the exception of , who is required to operate under a separate CCM plan due to its scope and mission of the Directorate. Directorate name will follow ECCMP minimum guidelines enumerated for the Service Directorates that includes provision of a CCM Plan to perform change and configuration management. The following list of Enterprise Directorates will use this plan to implement and sustain CCM processes and activities.

• Customer Relationship Management • Engineering and Service Design • Enterprise Security Service-Pentagon

1.4 Reference Documents

The following documents were used as reference when creating this ECCMP:

• MIL-HDBK-61A, Configuration Management Guidance, 7 February 2001, Office of the Under Secretary of Defense (Acquisition, Technology and Logistics) • ANSI/EIA 649, National Consensus Standard for Configuration Management, 10 July 1998 • The Information Technology Infrastructure Library; IT Service Management Forum (ITSMF) • Hewlett Packard (HP) Information Technology Service Model (ITSM) • Enterprise Change Control Board Charter ( AGENCY NAME EO0001) • Document Release and Maintenance Procedures (0007-PPT-0001) • Request for Deviation/Waiver Procedures (0007-PPT-0002) • AGENCY NAME Enterprise Project Charter (18 March 2002; revised 31 January 2003#)

1.5 Change and Configuration Management Plan Maintenance

This ECCMP will be updated as required to incorporate significant changes in the Enterprise Change or Configuration Management processes, procedures or policies under the Continuous Improvement Plan. At a minimum, review of the ECCMP will occur annually. All updates will be reviewed for efficiencies and alignment with business objectives and will be adopted by the Enterprise Change Control Board (ECCB) after the Architecture Review Board (ARB) approval.

The Service Directorate Change and Configuration Management Plans (CCMP) will be updated as required to incorporate significant changes in their Change or Configuration Management policy or practice. At a minimum, review of the Service Directorate’s CCMP will occur annually. All updates will be reviewed for efficiencies and alignment with Service Directorate and Enterprise business objectives, approved by the Service Directorates CCM Process Owner, and acknowledged by the Enterprise CCM Process Owner.

1.6 Change and Configuration Management Program

The ECCM Program will be comprised of a Change and Configuration Process Owner, Manager, Coordinator(s) and Tool Administrator that function as an industry best-practice governing body to provide guidance, support, change approval and continuous process improvement to each of the participating Enterprise Directorates and Service Directorates. The ECCM Program will report directly to the Deputy Executive Director. Overseeing the ECCM is the ECCB, comprised of the Enterprise Change and Configuration Process Owner, Manager, Coordinator, ECCB Chairperson, Engineering Review Board Chairperson, Change and Configuration Manager from each Enterprise Directorate and Service Directorate. Other optional participating members may include a Security Manager, Service Directorate Subject Matter Experts (SMEs) and the Deputy Executive Directors.

Each Enterprise Directorate and Service Dictorate will also encompass a CCM Program and reporting structure that will identify, according to the respective CCB Charters, the Change and Configuration roles and function as an industry best-practice governing body to provide guidance, and change approval within each Enterprise Directorate and Service Directorat. These CCM organizations serve as the point of contact responsible for managing changes to all configuration items, establishing configuration baselines and controlling changes to those baselines. The respective Enterprise Directorate and Service Directorate CCM organizations will be responsible for creating and maintaining an accurate organizational CCM Point of Contact (POC) list. Each Enterprise Directorate and Service Directorate will deliver the respective organizational CCM POC to the designated ECCM representative. Any changes to the POC will be forwarded to the ECCM representative within 5 working days of a change, and at a minimum should contain the following:

• - org name • - CCM rep name(s) • - phone # • - email address • - role of each individual

The roles and responsibilities for the ECCM are discussed in section 3.0. The hierarchies of these Configuration Control Boards are depicted in Figure 1.

[pic] Figure 1 Hierarchy of the Change Control Boards

1.7 Enterprise Change and Configuration Tools

This ECCMP is written to be Information Technology Service Management (ITSM) tool agnostic so that the process, activities, roles and responsibilities will not be restricted by technology. Agency Name’s current selection of Remedy as the default Enterprise ITSM tool will be implemented to support the Enterprise and Service Directorates Information Technology Infrastructure Library (ITIL) processes. The following section provides a brief description of the Change and Configuration Management tools utilized by Service Directorates and Enterprise Directorates.

• Remedy v7.5 – This ITSM tool will support the following Information Technology Infrastructure ITIL processes

o Change Management

o Configuration Management

o Asset Management

o Incident Management

o Problem Management

• BMC Atrium – This ITSM tool will support the following process

o Configuration Management

• Microsoft SharePoint – This tool will support the following process

o Configuration Management – CI document repository

2.0 Enterprise Change and Configuration Policies

Successful Change and Configuration Management is dependent upon effective governance through policies that provide controls for ensuring compliance in order to meet business objectives. It is essential that ’s Change and Configuration policies align with the overall organizational strategic framework and demonstrate a commitment to deliver the outcomes from changes to the service offerings. Effective governance is achieved by developing policies that support the business objectives. Below are the ECCM objectives and the supporting policies.

• Objective: Deploy configuration management enterprise-wide

• Policies:

Configuration Management will align configuration processes with current Service Directorate processes to improve efficiencies and effectiveness; new processes will be developed as required with re-use in mind

Agency Name will provide a clear framework of repeatable processes that reduce variations and improve integration among Service Directorates

• Objective: Support efforts to provide enterprise-wide standards for architecture, engineering, and change management

• Policies:

Agency Name will establish sustainable change management controls and disciplines throughout the configuration lifecycle to enable the smooth transition of service changes and releases

Agency Name will implement change management to ensure all changes to the Agency Name’s service offerings are managed by the configuration lifecycle processes

• Objective: Integrate configuration data at the service level and the enterprise level

• Policy:

CCM function will develop systems, processes and controls to assimilate and transfer knowledge for competent decision makers to effective decision making at the right time

• Objective: Improve systems interoperability consistency across the enterprise

• Policies:

CCM function will establish processes and procedures to ensure that all Requests for Change (RFC) will be planned, tested, and deployed into production in a manner that provides the agreed levels of traceability, in a cost-effective and efficient way

CCM function will provide and manage shared and specialist resources across change and configuration activities to eliminate delays

Change Management will provide processes that verify and validate that the proposed changes to the operational services defined in the RFC can and do deliver the required service requirements and benefits

• Objective: Eliminate hardware and software duplication among the Service Directorates where feasible

• Policy:

Change Management Program will establish sustainable controls and disciplines to check at the earliest possible stage in the change lifecycle that a new or changed service offering is capable of delivering the expected value and are not duplicated

3.0 Enterprise Change and Configuration Roles and Responsibilities

This section defines the Enterprise Change and Configuration Management (ECCM) roles and responsibilities. These roles and responsibilities delineate reporting hierarchy and activities that fall within the ECCM authority as defined by the ECCB Charter and are required to establish accountability and enforce controls throughout a configuration item’s life cycle from an enterprise level.

3.1 Enterprise Change Control Board (ECCB)

The ECCB is the equivalent of the ITIL Change Advisory Board (CAB). The ECCB ensures all proposed changes that have a potential to impact two or more Enterprise Directorates or Service Directorates within the Agency Nameenvironment are adequately assessed for risk, impact, and funding, and receive proper approval. The ECCB also takes corrective action towards any person or operation found in noncompliance by circumventing the Change Management process. The ECCB responsibilities include:

• Manages release functions while not compromising the integrity of the Agency Nameproduction environment • Handles all change requests that require ECCB approval • Resolve conflicts in change schedule across Service Directorates • Ensures the Change Schedule is updated • Ensures completeness of the Test Plans to confirm that all production environment components and configurations are tested • Approves Request for Waivers • Elevates change requests to higher governance

The Enterprise Change and Configuration Process Owner will chair the ECCB that is comprised of one (1) voting government appointee from each of the Enterprise Directorates and Service Directorates. Other personnel, such as technical and functional experts, may be invited to attend the ECCB meetings depending on the type of change proposed.

The ECCB will meet once (1) every quarter and at their discretion, and potentially hold virtual reviews of changes, the Chairperson may call meetings at other times when necessary. ECCB meetings will be guided by the priority of the agenda items requiring action. The Enterprise Change Coordinator distributes the approved ECCB meeting agenda to all members at least one (1) workday prior to the scheduled meeting. Members discuss non-agenda items only with the Chairperson’s discretion with time permitting.

3.2 Architectural Review Board (ARB)

The ARB provides direction to project, programs, and initiatives to facilitate alignment with the Agency Name Enterprise Architecture. The ARB will have final approval over any improvements to the Enterprise Change and Configuration Management processes, procedures and tools that impact any of the areas governed by the ARB.

3.3 Engineering Review Board (ERB)

The Engineering Review Board (ERB) will meet to consider functional and technical concept descriptions, software and hardware change requests. The ERB will consider any request it receives and, if approved, will forward it to the ECCB as a matter of record and formal request processing.

3.4 Enterprise Change and Configuration Process Owner

The Enterprise Change and Configuration Process Owner will report directly to the Deputy Executive Director. The Enterprise Change and Configuration Process Owner is responsible for organizing, directing, and coordinating the planning and execution of all Change and Configuration activities at the enterprise level. The Enterprise Change and Configuration Process Owner’s responsibilities include:

• Establishing and maintaining Enterprise Change and Configuration Management policies • Implementing Enterprise Change and Configuration Management as defined by this plan • Establishing and maintaining the integrity of the CMDB • Funding of Enterprise Change and Configuration Management activities • Chairing the Enterprise CCB • Providing approval authority for Change and Configuration Management Processes and tools • Supporting the performance of configuration audits described within this plan • Ensuring elevation of RFCs to higher governance as applicable

3.5 Enterprise Change and Configuration Manager

The Enterprise Change and Configuration Manager will report directly to the Enterprise Change and Configuration Process Owner. The Enterprise Change and Configuration Manager’s is responsible for the execution of Enterprise Change and Configuration Management processes. In addition, the Enterprise Change and Configuration Manager responsibilities include:

• Assisting with the establishment and maintenance of Enterprise CCM standards and procedures needed to implement this plan • Assisting with the establishment and maintenance of the CMDB • Assisting in the preparation and updates of the Enterprise CCM Plan and Service Directorate CCM Plans • Implementing Change and Configuration Management policies and procedures • Providing Enterprise level configuration control and status accounting • Establishing and documenting current and evolving enterprise level baselines • Providing guidance and direction in the organization and administration of the Enterprise CCB • Providing guidance and direction in the maintenance of version control of enterprise level baseline hardware and software • Providing guidance and direction in conducting configuration audits • Providing guidance and direction in implementing existing and new procedures • Establishing formal change management processes

3.6 Enterprise Change and Configuration Coordinator

Multiple members of the Enterprise Change and Configuration Management Program may fulfill the role of the Enterprise Change and Configuration Coordination. The Enterprise Change and Configuration Coordinator is responsible for the providing enterprise level CCM support and administration. The Enterprise Change and Configuration Coordinator responsibilities include:

• Assisting with the development of unique procedures that may be required to implement the ECCMP • Operating, maintaining, and establishing the CMDB • Assisting in the preparation of the Enterprise and Service Directorate Change and Configuration Management Plans • Implementing Change and Configuration policies and procedures • Providing Enterprise level configuration control and status accounting • Establishing and documenting current and evolving enterprise level baselines • Organizing and administering the Enterprise CCB • Maintaining version control of enterprise level baseline hardware and software • Compiling Enterprise configuration audits • Assisting with establishing formal change management processes • Producing process metrics and status reports

3.7 Enterprise Change and Configuration Tools Administrator

The Enterprise Change and Configuration Management Tools Administrator is responsible for the overall administration and maintenance of the Change and Configuration Management tools for Enterprise and Service Directorate staff. The Enterprise Change and Configuration Tools Administrator responsibilities include:

• Assist in the identification of standard CCM tools, fields and setups • Baseline Change and Configuration Management tool software and standard configurations • Setup and administration of CCM tools for the Enterprise and the Service Directorates • Document installation procedures and training guidelines • Ensure database security • Ensure appropriate backup and recovery of CCM databases • Provide technical guidance to Service Directorate users • Research and evaluate new ITSM software • Maintain accountability of CCM tools licenses

4.0 Configuration Management

There are two primary goals of the Enterprise Configuration Management process: (1) to provide timely and accurate information to support the Agency Name’s production environments and (2) understand configuration relationships and impacts in order to properly, assess, schedule and mitigate risk associated with changes to Agency Nameproduction environment, its services and service documentation.

A Configuration Item (CI) is any item that is managed, controlled and tracked under the Change Management processes in order to ensure successful delivery of Agency Name’s service offerings and supporting infrastructure. Some CIs are subsets of other CIs and are typically defined down to the lowest level at which a service’s component can be independently installed, replaced, or modified.

Configuration items (CIs) that have interconnectivity with other Service Directorates or Enterprise Directorates will be under configuration management control of the Service Directorate that holds the property book and/or is responsible for performing service/maintenance on the CI.

Each Enterprise Directorate and Service Directorate will establish a Configuration Management process under the guidance of Enterprise Change and Configuration Management using the following best practice processes.

4.1 Configuration Management Process

Configuration Management is comprised of four (4) primary processes that are discussed in further detail in the following sub-sections: Configuration Identification, Configuration Control, Configuration Verification and Audit, and Configuration Status and Reporting.

[pic] Figure 2 Configuration Management Process

4.1.1 Configuration Identification

The purpose of Configuration Identification is to identify and document what configurations are being added, in use, or require change according to type, attribute, version, federated systems and baselines within the Agency Name’s environment requiring control under the Change Management process. Configuration identification classifies CIs by type to assist in identifying location, relationships and dependencies. The identification of a configuration baseline demarcates a specific point in time and is used as a departure point for the formal control of a CI. Configuration baselines plus approved changes to those baselines together constitutes the currently approved configuration.

Software, hardware and documentation shall be identified to the level necessary to effectively mitigate risk, assess impact, and provide traceability and visibility across the Agency Name’s production environments through an accurate baseline and relationship model of all services within the Service Catalog. Federated Data shall provide asset or attribute information about a CI that is maintained in a decentralized data repository. The Media Repository shall provide documentation about a CI that is essential to providing and supporting the related service. The Configuration Management Data Base (CMDB) shall provide all CI’s and their attributes according to the ECCMP.

The CI types for configuration management within the Agency Nameare listed below and were selected and approved by the Service Directorate CCM representatives. Enterprise CCM maintains a listing of all CI types, categories, and attributes information. Additions to the CI types, categories, and attribute information are made through the ECCB via the Change Management process. (See section 5.0 Change Management)

CI Types

• Hardware – CI hardware types include any hardware that should be controlled because it enables services offered to internal and external customers by the Agency Name o Servers (e.g. application, database, virtual, web, etc) o Network devices (e.g. hubs, encryptors, load balancers, routers, switches, VPN concentrators, etc) o Printers (networked and stand alone) o Storage devices (e.g. arrays, edge routers, SAN switchers, tapes, tape libraries and drives, etc) o Desktops/laptops o Circuits o Mainframes o Telecom equipment (e.g. blackberries, cable TV, cell phones, pagers, wired phones, etc) o HVAC (e.g. power, piping/plumbing, etc.) • Software – CI software types include any software that should be controlled because it enables, monitors, and provides security to services offered to internal and external customers by the Agency Name o software o databases o COTS applications o GOTS applications o Firewalls o Operating systems o Management tools o Open sources • Documents – CI document types include any document that should be controlled because it relates to customer facing or is important to the operations of the Enterprise Directorates and Service Directorates o SOPs/CONOPS (e.g. work instructions, manuals, etc) o Contracts o SLAs/OLAs o Operating plans o Policy documents/Charters (directorate level)

The following CI attributes were selected and approved by the Service Directorate CCB representatives. Enterprise CCM maintains a listing of all CI types, categories, and attributes information. Upon initial selection of a CI, at a minimum, the following attributes will be identified:

• CI name • CI number • CI type • Manufacturer • Serial number • Model number • Version number • Contract number • Owner • Service provided • Customer • CAP/ATO • Warranty • Location

Designated members within the respective Enterprise Directorates and Service Directorates will examine the system architecture and documentation to identify all CIs within an organization. At a minimum, the Enterprise Directorates and Service Directorates Configuration Manager will be involved in the proposal of items to be selected as CIs. The CI selection will be forwarded to the respective Configuration Control Board for approval.

[pic] Figure 3 Configuration Identification

4.1.2 Configuration Control

The purpose of Configuration Control is to ensure that there are adequate control methods over CIs while maintaining a record of changes to CIs, versions, location and custodianship throughout the CI lifecycle. Configuration control is intended to prevent mismatches within the Agency Name’s physical environments and the CMDB. No CI should be added, modified, replaced or removed without following the Change Management processes.

[pic] Figure 4 Configuration Control

4.1.3 Configuration Verification and Audit

The purpose of Verification and Audit is to ensure conformity between the documented baselines and the actual Agency Nameenvironments. The associated activities are intended to verify the physical existence of CIs in the CMDB and validate the completeness and accuracy of all attributes and federated data related to CIs. Verification and audit is a quality gate to check that release and configuration documentation is present before making a release.

Before a major release or change, an audit of a specific configuration is required to ensure that the Agency Nameenvironment matches the CMDB. Before release into the Agency Name production environment, enhancements, new releases, builds, equipment and standards should be verified against the contracted or specified requirements. The RFC will be the record of change that proves that the functional requirements of a new or updated CI has been verified.

[pic] Figure 5 Configuration Verification and Audit

4.1.4 Configuration Status and Reporting

The purpose of Status and Reporting is to capture a record of the configuration status during the configuration identification and control activities. These records allow for visibility across the Agency Name’s operation and traceability for the efficient management of the evolving configuration. Varying types of reports will be needed to ensure visability and traceablity based upon individual configuration items, a complete service or all the services within an Enterprise or Service Directorate according to the Service Catalog.

Status Record

• Service configuration information (e.g. status, title, change history and its inclusion in any baseline) • The service or product configuration (such as design or build status) • The status of release of new configuration information • Changes implemented and in progress • Results captured from tests to update the configuration records.

Reports

• A list of configuration items and their configuration baselines • Details of the current revision status and change history • Status reports on changes, waivers and deviations • Details of the status of delivered and maintained products (e.g. part and traceability numbers) • Revision status • Report on unauthorized usage of hardware and software • Unauthorized CIs detected • Variations from CMS to physical audit reports [pic] Figure 6 Configuration Status and Reporting

4.2 Enterprise Directorate and Service Directorate Configuration Roles and Responsibilities

Within the Configuration Management process, several roles and responsibilities are required to establish accountability and enforce controls throughout a configuration item’s life cycle. The following roles have been identified as a minimum CCM process requirement and are to be performed at the Enterprise Directorate and Service Directorate levels. Multiple roles may be fulfilled by a single individual (i.e. the Configuration Management Process Manager and Configuration Coordinator may be the same individual). In addition, these listings include not only the responsibilities but also the accountability for each of the roles.

4.2.1 Configuration Process Manager

The Configuration Process Manager refers to the person who manages the configuration process and procedures within the Agency Name. The Process Manager manages the process to meet business and process goals, sets participant expectations and leads improvement efforts.

4.2.1.1 Accountability

• Manages and coordinates all activities necessary to identify, control, track and audit all CIs • Manages the Configuration Management process • Creates Configuration Management process improvement plan • Maintains process alignment with business goals and other ITIL processes

4.2.1.2 Responsibilities

• Ensures a good working relationship is established with all necessary support organizations • Maintains an accurate status of the CMDB • Identifies unauthorized CI change initiators and escalates as necessary • Participates in Change Management Process evaluation • Educates other support services to be able to work effectively and efficiently with the CMDB • Ensures all CIs are kept current with the actual system changes • Ensures all components relative to IT Service Levels are registered in the CMDB • Ensures only authorized and registered components are active • Generates and distributes standard and custom reports • Defines the CMDB • Ensures coordination in the Certification and Accreditation of the configuration change

4.2.2 Configuration Coordinator

The Configuration Coordinator refers to the person who coordinates all activities related to managing and controlling configuration items at the data level. The Configuration Coordinator actively participates in the Configuration Process and provides expert technical knowledge about the CMDB, CI attributes and resolving variations.

4.2.2.1 Accountability

• Records and maintains all Enterprise Directorate or Service Directorate Level CIs in the CMDB • Maintains the CI dependency matrix database

4.2.2.2 Responsibilities

• Ensures all enterprise components are accurately registered • Interfaces with other support organizations to ensure they are able to effectively use the CMDB • Creates reports and performs analysis of the CMDB when requested by the Configuration Process Manager • Ensures that Service Providers maintain adequate Configuration Management process disciplines and systems they own • Ensures authorized procedures and work practices are followed • Ensures the effective use of the Configuration Management System • Evaluates the Configuration Management process for continuous improvement • Reviews all test results

4.2.3 Configuration Item Custodian

The Configuration Item Custodian refers to the agency/team that controls the configuration item(s) for a service offering within the Agency Name. The CI Custodian manages the configuration item(s) through the CI lifecycle.

4.2.3.1 Accountability

• Subject Matter Expert on the CI’s under their control

4.2.3.2 Responsibilities

• Ensures all changes to CI’s are under the control of change management • Participates in Change Management Process • Participates in Configuration and Change Audits • Addresses unauthorized CI changes • Remediates unauthorized CI changes • Ensures CIs are recorded on a timely basis • Ensures CIs are up to date with Service Directorate defined standards • Ensures coordination in the Certification and Accreditation of the configuration item change

5.0 Change Management

The purpose of the Enterprise Change Management process is to ensure that standard methods and procedures are used for efficient and prompt handling of all proposed changes to Agency Name service offerings and that related configuration items are recorded in the Change Management System. Agency Name’s Enterprise Change Management process is intended to respond to the customer’s changing business requirements and IT requests for change in order to align the services with the business needs while maximizing value, reducing incidents, and minimizing disruptions and re-work.

Agency Name’s Enterprise Change Management objectives are to ensure that changes are recorded, communicated, assessed, prioritized, authorized, planned, tested, implemented, documented and reviewed in a controlled manner within the Organization and environment. This includes changes to hardware, software, and all documentation and procedures that are critical to the operation, support, maintenance, and implementation of Agency Name services according to the Service Catalog.

Change Management will be performed within the Organization at the Enterprise Directorate and Service Directorate level. Enterprise Change and Configuration Management is responsible for establishing Change control processes, procedures and policy standards for Enterprise Directorates and Service Directorates. These processes, procedures and policies are defined within the guidelines of this ECCMP.

Each Enterprise Directorate will use the Change process defined by this ECCMP[1]. It will be the responsibility of the Enterprise Directorates to follow the activities related to each of Change processes identified in this section. The Enterprise Directorates will be required to have an approved CCB Charter that will define the authority required to make a decision on a change.

Each Service Directorate within Agency Name will establish a Change Management process that will be defined within their respective CCMP. Enterprise Change Management has defined twelve primary processes that are required to some degree with each Service Directorate Change Management process, depending on business function. The Service Directorates will be required to have an approved CCB Charter that will define the authority required to make a decision on a change.

5.1 Change Management Process

A request for change (RFC) is a formal communication seeking an alteration to one or more configuration items. Changes are requested for various reasons:

• Reducing costs • Improving existing or adding new services • Increasing the ease and effectiveness of support • Means of resolving incidents and adapting to changing circumstances

Changes should be managed to identify and optimize risk associated with development lifecycles, minimize the severity and disruption of any incident and be successful at the first attempt. Making appropriate decisions with respect to requests for change, entails a considered approach in assessment of risk and business continuity, change impact, resource requirements, and change authorization and especially to the realizable business benefit. This considered approach is essential to maintain the required balance between the need for change and the impact of the change.[2]

Change Management within the Agency Name is comprised of twelve (12) primary processes, Draft, Request for Authorization,Request for Change, Planning in Progress, Scheduled for Review, Scheduled for Approval, Scheduled, Implementation in Progress, Completed, Closed, Rollback, and Emergency.

[pic] Figure 7 Enterprise Change Management Process

5.1.1 Draft

The purpose of the Draft process is to capture and submit all information required by Change Management within the Agency Name related to adding or altering an Agency Name service offering configuration item(s). The Draft process provides a method for categorizing the change, associating the configuration item(s) and assigning risk, impact and urgency. Information collected in the Draft process is essential to the service and configuration item lifecycle along with decision-making process. The Agency Name Change Management process defines four (4) change types: No Impact, Normal, Latent, Expidted, and and Emergency, which determine the workflow for a submitted change. (For more information about RFC types see section 5.4.)

[pic] Figure 8 Draft

5.1.2 Request for Authorization

The Request for Authorization process is the first of four (4) change approvals that a normal or emergency change must pass before being considered by a CCB. This approval is intended to ensure that all data captured in the change record is accurate, understandable and complete to make certain that informed and educated decisions can be made throughout the process and the proposed solution can be implemented in compliance with applicable policy and technical standards. It also provides a method for the Agency Name Service Provider and all stakeholders who have knowledge about the configuration item(s) dependencies, relationships and attributes related to the change of a service to validate the level of effort, cost, categorization, configuration item(s) and impact, risk and urgency before submitting for CCB approval. Level of effort activities should identify and ensure that resources will be available for the development, testing and implementation of a change. Cost assessments validate through business justification if the change makes sense for the business and that funding is available. Risk and impact activities identify the amount of risk and potential impact involved with a change and is used to assign proper change urgency from a business and customer perspective according to Change Management standards. (See sections 5.2 Risk and Impact of RFCs, 5.3 Urgency of RFCs)

[pic] Figure 9 Request for Authorization

Impact and risk consideration list:

• The effect on the infrastructure from a capacity and performance, contingency, security perspective • The impact on other services that run on the same infrastructure • The impact on the service desk, other support organizations, customer’s service and business operation • The effect of not implementing the change • The IT business and other resources required to implement the change • The current change and projected service outage schedules

Urgency consideration list:

• The impact and risk level • The maximum time limit the customer can function without the service • The stability and ease of the workaround provided by Incident Management • The cost associated with implementing the change and Service Level Agreements for the service • The number of customers impacted and the cruciality of their mission

5.1.3 Request for Change

The Approve Request for Change process is the second of four (4) change approvals and provides a method for all stakeholders to present the finalized proposed change to the Enterprise Directorate or Service Directorate respective Change Control Board and receive approval, denial, deferral or escalation to the ECCB. The Request for Change provides a method for the proper governing boards to make a determination, based upon the information captured in the change record, on whether to approve or reject the change. (see Appendix B for the meeting schedule and POCs for each higher and subordinate governance board). Change Management allows for four (4) types of dispositions. (See section 5.5 Change Disposition for more information.)

[pic]

Figure 10 Request for Change

5.1.4 Planning in Progress

The Planning in Progress process provides a method for capturing the development information essential for the transfer of knowledge to support organizations in order to sustain the environment through incident, problem and maintenance management. Planning in Progress ensures deployment activities are tasked in chronological order to the proper resources and deployment information such as build and test plans, implementation plans and configuration data are tracable in case of root cause analysis (RCA), incident resolution and lessons learned that are applied to standard operating procedures.

[pic] Figure 11 Planning in Progress

5.1.5 Scheduled for Review

The purpose of the Schedule for Review process is to provide a method to validate development related deliverables such as acceptance criteria, and test and evaluation reports, which include regression, CI baselines, and release information. Testing should ensure that the testing process works with all stages of the CI or service lifecycle so that designs are inherently testable, failure information results in improvement ideas, maintenances provides continued efficacies and testing has adequate funding, resource, profile etc. This information will be used within the Schedlued for Approval process to make a go, no-go decision.

[pic] Figure 12 Schedule for Review

5.1.6 Scheduled for Approval

The Scheduled for Approval process is the third of (4) change approvals and provides a method for reviewing all build and test material related to a proposed change. Even though the CCB has approved a change, Schedlued for Approval approvers should have the final go, no-go decision based upon a review of user acceptance test (UAT), regression testing, the design and deployment plans. It is critical for Scheduled for Approval approvers to consider what remediation options are available before implementing a change and establish that the remediation is successful when tested. Scheduled for Approval ensures that the proposed changes will accomplish what is intended, fits the need of the customer, and aligns with the Agency Name’s strategic direction.

[pic] Figure 13 Scheduled for Approval

5.1.7 Scheduled

The purpose of the Sceduled process is to provide a method for capturing all changes that have been approved for implementation in a forward schedule of change. Schedlued is intended to ensure that all stakeholds and key Agency Name persons are aware of the upcoming changes.

[pic] Figure 14 Scheduled

5.1.8 Implementation in Progress

The Implementation in Progress process is intended to provide a method for traking and auditing implementation activities to determin the success of an implemented change. Implementation in Progress ensure that all implementation activites have been completed, including any roll-backs and that configurations, federated data are udated accurately through a physical and functional audit.

[pic] Figure 15 Implementation in Progress

5.1.9 Completed

The Completed process is the last of the four (4) change approvals and provides a method to capture the Technical Post Implementation Review (TPIR) activites. Completed ensures that leasons learned are documented and that all activities related to implementing a change have been executed and any variations were/are addressed through change, incident or problem managemen.

[pic] Figure 16 Completed

5.1.10 Closed

The Closed process provides a method for closing out all deployed and failed changes. The Closed ensures traceability to Incident, Problem and Release Management throughout a service offering’s and CI lifecycle. All change that are mark completed will be automatically closed by the change system after ten (10) days.

[pic] Figure 17 Closed

5.1.11 Emergency Change

The Emergency Change process provides a method for assessing and approving a proposed change to a CI or group of CIs related to a Agency Name service offering within a short time period. An emergency change is a reserved change that is intended to repair a service disruption that is negatively affecting the Agency Name business to a high degree. These changes should be designed and tested before implementation or the impact may exceed that of the originating incident. Change Management may classify a RFC as an emergency, if and only if, its implementation resolves or averts immediate adverse system impacts and there is no time to hold a CCB meeting.

[pic] Figure 18 Emergency Change

5.1.12 Rollback

The purpose of the Rollback Process is to engage a back-out plan to a failed change and restore the service offering or CI to its previous configuration through the reloading of a CI or set of CIs baselines, especially software and data. Rollback ensures that failed changes are managed in accordance with other Agency Name ITIL processes and are properly communicated to stakeholders.

[pic]

Figure 19 Rollback

5.2 RFC Impact and Risk

The relevant urgency (section 5.3) is a measure of the impact and risk to Agency Name’s business services of submitted change requests. Impact and risk are assigned first in order to establish the most appropriate urgency classification level. The goal is to assess impact and risk from the business perspective to produce the correct course of action with the applicable degree of urgency. It is the responsibility of the RFC originator to provide the impact and risk level upon submission of the RFC. RFC impact and risk definitions are as follows:

Impact

1 - Extensive impact – 21 or more users, mission essential user-base, multiple mission-essential services, significant potential loss of revenue

2 - Significant impact – 21 or more users, mission essential user-base, single mission-essential service, significant potential loss of revenue

3 - Moderate impact – 0 – 20 users on a single service, non-mission essential user-base, single non-mission essential service, moderate potential loss of revenue

4 - Low impact – 0 – 20 users on a single service, non-essential user-base, non-essential services, negligible loss of revenue

Risk 1 - High risk – vast potential loss of customers, excellent chance for a failed change, definite disruption to other services, indefinite variations, multifaceted complexity of solution

2 - Medium risk – good potential loss of customers, good chance for a failed change, possible disruption to other services, indeterminate variations, slight complexity of solution

3 - Moderate risk – low potential loss of customers, low chance for a change, possibility low disruption to other services, minimal variations, slight complexity of solution

4 - Low risk – no potential loss of customers, no chance for a change, no disruption to other services, no variations, uncomplicated solution

5.3 RFC Urgency

Urgency is used within the Agency Name’s Change Management process for RFCs to establish the order sequence in which changes should be scheduled for release in order to maximize resource allocation efficiencies. The urgency of a change is based upon clearly defined definitions that determine how long the implementation can afford to be delayed. Each urgency definition includes a time constraint so that urgency is understood and authorization occurs within the agreed timeframe. It is the responsibility of the RFC initiator to provide a suggested urgency upon submission of the RFC. RFC urgencies are as follows:

1 - Emergency • Causing significant loss of the ability to deliver critical services • Security compromised • No practical workarounds • Impacting 21 or more users • Immediate action required to avert/mitigate adverse system impacts • Must be approved and implemented within an agreed time frame 2 - High • Severely affecting 21 or more users • The workaround is awkward or inefficient • Must be approved and implemented within an agreed time frame 3 - Medium • Impacting 0 to 20 users with unacceptable workaround • Reoccurring disruption that is customer facing • No severe impact, but the change cannot be deferred until the next scheduled release or upgrade (ECCB or CCB approval at next meeting) 4 - Low • Impacting 0 – 20 users that have an acceptable workaround • A change is justified and necessary, can wait until the next scheduled release or upgrade (ECCB or CCB approval at next meeting)

[pic] Figure 21 Urgency Matrix

5.4 Request for Change Types

Within Change Management process, change types intend to differentiate the RFC approach according to impact, risk and urgency categorization and relationships. The following sections provide a definition for each change type identified and approved by the Service Directorate CCB representatives.

5.4.1 No Impact Change

A no impact change is a change to a service offering or configuration item where the impact is minor and the risk is low and understood. No impact change tasks are to be well known, documented and the approach routine. The purpose for the no impact change type is to allow for changes related to standard maintenance, standard installs of approved software or fixes to know errors to be performed without having to wait for change approval. This type change should be used only for changes that appear on the CCB no impact change list. The Enterprise Directorates and Service Directorates will establish and maintain a list of no impact changes that are to be approved by their corresponding CCB and communicated to the support organization. No impact changes are pre-authorized by Change Management and do not require change approvals.

5.4.2 Normal Change

A normal change is a change to a service offering or configuration item that is not a standard, directed or emergency change. Normal changes can range from minor to high in impact, low to high in risk and low to high in urgency. The purpose for the normal change type is to provide a method for capturing all changes that are not standard, directed or emergency changes. This type changes is typically related to the request of a new service, service improvements, hardware, software and firmware upgrades along with problem records and incidents with a medium to low priority. A normal change requires chagne approvals.

5.4.3 Latent Change

A latent change is a change to a service offering or configuration item that has already been performed and requires tracablity. Latent changes can range from minor to high in impact, low to high in risk and low to high in urgency. The purpose for the latent change type to provide a method for capturing all changes that are the result of incident resolution or service request that falls under the scope of change management. This type changes is typically related to incidents with a medium to low priority and service requests for standard and approved hardware, software and firmware that change a configuration item(s). A latent change requires no change approvals but requires a Technical Post Implementation Review (TPIR).

5.4.4 Expedited Change

An expedited change is a change that is associated with proactive operational support activities. Expedited changes are high in impact and urgency and low to high in risk. The purpose for the expedited change type is to provide a method for quick approvals through the change process. This type change is typically related to event management and used to mitigate a potentially high impact to any service offering. An expedited change requires change approvals with a defined time constraint.

5.4.4 Emergency Change

An emergency change is a change to a service offering or configuration item where the impact is extensive and has a negative effect on AGENCY NAME’s ability to do business because of a hardware or software failure. Emergency changes need to be implemented immediately and are intended to repair the error in the service or configuration item. The purpose for the emergency change type is to provide a change method for rapid approval to changes that need to implemented to restore services or correct a workaround that has a negative effect. Emergency changes should only be used for changes that are associated priority one (1) or (2) incident records. An emergency Enterprise, Directorate or Service Directorate CCB approves these changes.

5.5 Change Dispositions

5.5.1 Approved

All information was accurate and understandable

5.5.2 Rejected

The change has been rejected by an approver because the risk and impact out-weighed business benefits, does not align with business or IT goals, and / or the return on investment (ROI) is too low or intangible

o A rejected change can be restarted but it returns to Request for Approval

5.5.3 Pending

The work on the change has been temporarily suspended o A pending change can only be moved back to its previous state

5.5.4 Cancelled

The change is no longer needed because it was overcome by events o A cancelled change can be restarted from the Draft state

5.6 Change Exceptions

Change exceptions allow for the handling of changes or change situations that fall outside the standard documented processes and procedures and are used for the acceptance or hold of a nonconforming configuration item. Each Service Directorate is to develop a process for the handling of deviations and deferrals.

5.6.1 Request for Deviation (RFD)

When it is determined that a product cannot be developed as specified in baseline documents, a RFD is prepared, in accordance with the Service Directorates Request for Deviation process, to gain approval for temporary departure from the documented configuration identification. An RFD applies to a specific number of units that do not conform to baseline documents. Approval of an RFD permits the installation of hardware that does not conform to design documents as an interim measure when ordered items cannot be delivered on time. The RFD must contain a plan for revising the deviating items for conformance with the approved requirements.

5.6.2 Request for Waiver (RFW)

An RFW is processed to record the departure from baseline documents and does not request a permanent change to the baseline documentation. An RFW may be processed when a CI incorporates a known departure from the baseline and it is determined that the CI is considered sustainable for use “as is” or after repair/rework. When an RFW is approved, the ECCB will review the requirement that has not been met to determine whether the design should be changed. If a design change is desired, a follow-up RFC is prepared to process the change. An approved RFW permits acceptance of the system/application or hardware product as is. Only the ECCB will have the authority to approve RFWs per the charter.

5.6.3 Request for Deferral

A Request for RFC Deferral is processed when the CCB or ECCB is unable to make a determination on a proposed change. Deferred RFCs will be updated with the missing information, returned for impact assessment, or escalated to the ARB according to the CCB or ECCB meeting minutes-action items. RCFs that have been deferred can be rescheduled to a CCB or ECCB for approval or they can be closed.

5.7 Outages

There are three types of outages: planned/scheduled, unplanned/unscheduled, and emergency. Only outages that meet the following requirements for each outage type will require a RFC.

5.7.1 Planned/Scheduled

Planned/Scheduled outages are occurrences in which a service may be brought down to perform maintenance and may or may not include the changing of a CI’s attribute. Planned/Scheduled outage where there is no change to a CI is typically related to maintenance and falls under the control of Event Management. These types of outages do not require a RFC unless changes to the CI are made proactively as well. Planned/scheduled outages performed that include the changing of a CI’s attributes require a RFC.

5.7.2 Unplanned/Unscheduled

Unplanned/Unscheduled outages occur when a service is made unavailable without notification to the appropriate parties. Upon discovery, immediate action is taken to restore service and any changes that occurred during recovery will require a change record that will be submitted through the CCB. Should a root cause analysis determine that further changes to the CI are required to eliminate the error; another change record will be submitted for CCB or ECCB approval.

5.7.3 Emergency Outages

Emergency outages are occurrences in which a critical system event occurs and warrants an immediate proactive response. Only the Enterprise Change and Configuration Process Owner, Enterprise Directorate or Service Directorate Director or their designee has authority to approve an emergency outage change outside of the normal Change Management process. Once the emergency outage is completed, the change initiator will submit the required information to the appropriate CCB or ECCB.

5.8 Enterprise Directorate and Service Directorate Change Roles and Responsibilities

Within the Change Management process, several roles and responsibilities are required to establish accountability and enforce controls throughout a service life cycle. The following are the roles that have been identified to be performed at the Enterprise Directorate and Service Directorate levels. Multiple roles may be fulfilled by a single individual (i.e. the Configuration Management Process Manager and Configuration Coordinator may be the same individual). In addition, these roles include not only the responsibilities but also the accountability for each of the roles.

5.8.1 Change Requestor

The role of Change Initiator applies to all people who need to request a change to existing service offerings or add new service offering.

5.8.1.1 Accountability

• Initiates the RFC process • Develops the business case • Submits a RFC form to Change Management

5.8.1.2 Responsibilities

• Identifies Requirements • Provides cost-benefit data and impact assessment • Assigns the User Severity Level for an RFC

5.8.2 Change Manager

The Change Manager refers to the person who manages the change activities within the Agency NameChange Management Process. The Change Manager manages the process to meet business and process goals, sets participant expectations and leads improvement efforts.

5.8.2.1 Accountability

• Coordinates all changes within the Production IT Environment • Owns the Operation level Change Management Processes • Chairs the CCB • Calls Emergency CCB meetings when required • Ensures only authorized changes are implemented

5.8.2.2 Responsibilities

• Approves changes • Establishes a good working relationship with all necessary support organizations • Minimizes the number of incidents resulting from change • Ensures changes include a roll-back plan • May approve changes that are deemed Urgent or Emergency • Ensures that changes are implemented in accordance with the needs of the business, and conform to process standards • Ensures that implemented changes mitigate risk • Ensures clear and effective change procedures are in place • Ensures that the CCB is authoritative and effective • Publishes and communicates Change Management standards • Ensures changes conform to process standards • Participates in Change Management process review and evaluation • Communicates the Change Schedule across the organization • Raises change related issues to the appropriate level of management • Participates in the ECCB as a voting member

5.8.3 Change Coordinator

The Change Coordinator refers to the person who manages the scheduling, recording and reporting of change activities within the Agency NameChange Management Process. The Coordinator manages the activities to meet business and process goals, sets participant expectations and provides input into improvement efforts.

5.8.3.1 Accountability

• Coordinates change control meetings including tracking action items • Produces Status Accounting Reports • Coordinates the processing of all change requests • Ensures the request is recorded and classified in the Change Management tracking tool • Approves changes, when applicable • Schedules all changes to the Production IT Environment and publishes the Change Schedule • Notifies all affected parties of the disposition of change requests

5.8.3.2 Responsibilities

• Advises and supports the Change Management Process Manager • Ensures the effective use of the Change Management Tracking Tool • Evaluates all change requests for completeness and enforces standards and procedures • Escalates Emergency change requests • Calls Emergency CCB meetings when required • Assesses risk, confers with relevant experts and provides the CCB with advice concerning approval of the change • Participates in setting initial priority • Participates in change assessment and review activities • Ensures approval has been obtained for the Release-to-Production Schedule • Ensures the closure of change requests with status information • Generates and distributes standard and custom reports • Evaluates the effectiveness of the overall Change Management process

5.8.4 Change Assignee

The Change Assigneer refers to the person responsible for the planning, implementing and scheduling RFC, and recording and reporting of change activities within the Agency NameChange Management Process.

5.8.4.1 Accountability

• Develops the business case • Coordinates all activities related to the implementation of a change • Communication to the internal and external stakeholders on the status of a change • Minimize change risk by coordinating the change release date • Secures the sign-off of the Release-to-Production Instructions for deployment into the Production IT Environment

5.8.4.2 Responsibilities

• Identifies Requirements • Provides cost-benefit data and impact assessment • Participates in change assessment and review activities • Reporting the status of a change • Evaluates all change requests for completeness • Participates in ECCB • Works with Service Providers to arrive at a solution

5.8.5 Change Implemeter

The Change Implementor refers to the person responsible for assigning implementation tasks in either chronologicaly or parallely and ensures that any variations in the implelemtation are documented and that any activity realted to a failed is executed as specified in the change record.

5.8.5.1 Accountability

• Esures change tasks are assigned to the correct level of skill • Validates change was implementaed according to plan • Participates in change assessment and review activities

5.8.5.2 Responsibilities

• Assigns tasks according to implelmentation plan • Participates in change assessment and review activities • Oversees the implementation of a change • Ensures the closure of change requests with status information • Participates in ECCB

5.8.6 Task Implementer

The Task Implementor refers to the operson that is responsible to the executing the implementation tasks assigned by the Task Implementor. The Task Implementor follows the implementation tasks accordingly, closes the task and documenting any variances.

5.8.6.1 Accountability

• Successful implementation of a RFC • Accuracey of task status information

5.8.6.2 Responsibilities

• Resolves any issues during implelentaiton • Backs out any failed changes • Closes completed tasks with status information • Participates in change assessment and review activities

5.8.7 Change Control Board (CCB)

The Change Control Board refers to a group of people responsible for reviewing and providing recommendations to the Change Management Process Manager for the acceptance, deferral, denial or escalation of a change. The Change Management Process Manager has the ultimate authority on whether or not to approve a change at the Enterprise Directorate or Service Directorate level. Each Enterprise Directorate and Service Directorate will be responsible for chartering a CCB.

5.8.7.1 Accountability

• Manages and controls the production baseline and configuration information • Ensures all changes to the Production IT Environment are adequately assessed for risk avoidance, impact, and funding • Takes corrective action towards any person/department who circumvents the Change Management Process • Rejects/Approves all changes to the Production IT Environment • Elevates changes that impact multiple Enterprise Directorates and or Service Directorate services to the ECCB

5.8.7.2 Responsibilities

• Manages release functions while not compromising the integrity of the Production IT Environment • Handles all change requests that require CCB approval • Resolves conflicts in change request schedules • Ensures the Change Schedule is updated • Ensures completeness of the Test Plans to confirm that all Production IT Environment components and configurations are tested

Enterprise Directorate and Service Directorate CCB representatives shall have accountability for all CCB decisions made in their respective CCBs. The Enterprise Directorate CCB and Service Directorate CCB will escalate all proposed changes not approved or deferred at the Enterprise Directorate and Service Directorate levels to the ECCB.

5.9 Interface Management

Interfaces are common boundaries between two or more items. Interfaces are defined in Interface Control Documents (ICDs). When an interface with other items exists, technical and administrative representatives, as necessary, from all sides of an interface will meet to communicate technical, and schedule information to interested parties. When a change to an interface is proposed, the impacted organizations are convened to ensure that all interests are represented in decisions, and interface changes are documented in the appropriate ICD. RFCs will be written to document the changes to each interface affected by the change. The initiating Service Directorate CCB and interfacing item Service Directorate representatives will review and determine the disposition of the RFC(s) as appropriate. If the initiating Service Directorate and impacted Service Directorate cannot agree upon implementation, the RFC is escalated to the ECCB for review and approval. The Service Directorate that owns the CI will be responsible for coordinating with the ECCB for addition of the impacting item to the ECCB agenda. Decisions made by the ECCB are final.

5.10 Traceability of Changes to Documentation

All released documentation will contain a Record of Change (ROC) page, identifying the change(s) incorporated in each update of the documents. The list of changes is cumulative. The ROC page is retained with other files pertaining to the document in the Enterprise Change & Configuration Central Repository. In addition, the applicability of RFCs to documents will be added to the RFC database, and the status of incorporation of changes will be output from the RFC database.

6.0 Request for Change Forms

The following sections identify forms used within the Change Management Process. Additional forms may be used by the Service Directorates in their change process. Any additional forms used must be described within the respective Service Directorate CCMP.

7.0 Change and Configuration Metrics

The Enterprise CCM, Enterprise Directorate and all Service Directorate CCMs are required to measure process performance, goals and compliancy, and generate a standard set of metrics. These reports will be generated on a monthly basis and disseminated to process participants, owners, managers and others as requested to determine if targets are being met, the level of compliance and to identify improvement efforts.

7.1 Enterprise Metrics

The following Enterprise metrics were selected and approved by the Service Directorate CCB representatives. The Enterprise Directorates and Service Directorates may also use these metrics. At a minimum, the following reports will be generated on a monthly basis:

Change

• Average change lifecycle (amount of time from open to close) by severity • Average change lifecycle (amount of time from open to close) by priority • Average lifecycle per change stage (amount of time in each change stage)

Configuration

• Total number of existing CIs o New o Changed • Number of CIs in the CMDB • Number of CIs audited in the period • Number of audited CIs with data errors in the CMDB o Number of deviations identified between the CI repository and actual environment o Number of CI discrepancies related to incomplete or missing CI information o Amount of time between identifying discrepancies and correcting o Number of same application instances on servers • Amount of time to update CI information after change

7.2 Enterprise Directorate Metrics

The Enterprise Directorates will use the following metrics and at a minimum generate reports using these metrics on a monthly basis. Each Service Directorate will continue to use current metrics but may also use the following metrics to measure the respective change processes.

Change

• Open RFC Report by submit date: o Old – greater than 90 days o New – 30 days or less • Critical RFC Report—Lists all open RFCs with a “critical” priority • Interface Report—Lists all open RFCs with interface impact • Number of RFCs per quarter • Number of RFCs successfully implemented • Number of RFCs closed without implementing by reason • Number of RFCs deferred by reason and Service Directorate • Number of RFCs escalated to enterprise level • Number of change process deviations by Service Directorate • Number of emergency changes by Service Directorate • Number of failed RFCs by Service Directorate • Number of Directed Changes by Service Directorate

8.0 Change and Configuration Audit

The primary goal of Change and Configuration Audits is to ensure that there is conformity and consistency, in the form of standards, between the documented baselines and the actual Agency Nameenvironments. A Configuration audit aims to verify that the correct and authorized version(s) of a CI exists in the production environment and are tagged with the correct status. Discovered unregistered and unauthorized CIs should be investigated and corrective action taken to address possible issues with procedures and behaviors.

Configuration audits are to be conducted annually by the Enterprise Directorates and Service Directorates Change and Configuration Management organizations. Enterprise Directorates and Service Directorates will use their respective audit plans to conduct configuration audits and at the conclusion of each audit an audit report will be prepared. All deviations, variations and exceptions are to have corrective actions and target dates for completion. Audit reports will be forwarded to the Enterprise Change and Configuration Process Owner and designated Enterprise Change and Configuration representative along with Enterprise Directorate and Service Directorate management as appropriate and published as a permanent management record. The Enterprise Directorate and Service Directorate Configuration Manager will be responsible for ensuring that configuration audits are conducted according to the respective guidelines.

8.2 Audit Types

The three types of audits that Enterprise CCM, Enterprise Directorates and Service Directorates can conduct to ensure functional and physical completeness of the CMDB and services are:

Physical Configuration Audit (PCA) -- The PCA compares the ‘as-designed’ records to the ‘as-built’ records for all hardware and software components. This includes the CI attributes, asset data and change record.

• Purpose: o To validate that what was designed is in production, meets standards (version, build, security, etc.) and is properly recorded in the CMDB • Actions: o Discrepancies and variations will be recorded and result in a RFC to update the production CI, the design records or the CMDB • Occurrence: o Annually and each time a baseline is changed or a new baseline is created.

Functional Configuration Audit (FCA) -- The FCA compares the CIs related to the delivery of a service to the functions specified in the statement of work, specification, requirement, SLA, MOU, 5E, etc.

• Purpose: o To validate that CIs related to the delivery of a services meet all requirements and are properly recorded in the CMDB to ensure services perform as designed and agreed. • Actions: o Discrepancies and variations will be recorded and result in a RFC to update the production CI builds, design records or the CMDB • Occurrence: o This audit should be conducted each time a baseline is changed or a new baseline is created.

Unauthorized Change Audit (UCA) -- The UCA compares CI data, asset data and change records

• Purpose: o To detect CI changes not captured in a change record and to identify non-compliance, repeat offenders and potential security vulnerabilities • Actions: o Discrepancies and variations will be recorded and result in a RFC • Occurrence: o This audit should be conducted quarterly

9.0 Archiving Storage and Disposal

All obsolete CIs will be archived and separated from active CIs within the Configuration physical and electronic libraries at both the Enterprise Directorate and Service Directorate levels. A CI becomes obsolete when it is no longer part of the active baseline. Access to archived CIs will be restricted. Configuration Managers will track the retention requirement for all Change and Configuration controlled documents. If not otherwise stated, all Change and Configuration controlled documents will be kept for five years beyond the end of their life.

10.0 Process Interfaces

The success of Change and Configuration Management is also dependent on the interfaces between other IT and business processes. Properly identifying and managing these interfaces provides the Agency Namewith a holistic view of the IT environment from a people, hardware, and software and facilities perspective. This section will identify other processes that interface with the change and configuration processes.

10.1 Incident Management

The primary objective of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations. Incident Management is the process that handles all incidents; this can include failures, questions or queries reported by the users, technical staff, or automatically detected and reported by event monitoring tools. An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service. It is also defined as a failure of a configuration item that has not yet impacted a service.[3]

Change Management input to Incident Management:

• Incidents as the result of failed changes • Impacts as the result of failed changes

Incident Management input to Change Management:

• RFC for an implemented change or to implement a workaround or solution

Configuration Management input to Incident Management:

• Data to identify and escalate incidents • Data to identify faulty equipment and assess the impact of an incident • Data to identify the number and type of users affected by potential problems • Data to assign incidents to correct support group according to CI

Incident Management input to Configuration Management:

• Tracks the number outages experienced by a CI • Maintains the status of faulty CIs • Audits the infrastructure when working to resolve an incident

10.2 Problem Management

The primary objectives of Problem Management are to prevent problems and resulting incidents from happening, to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented. A problem is defined as the cause of one or more incidents.[4]

Change Management input to Problem Management:

• Monitors the progress/success of problem resolution • Keeps Problem Management informed of changes

Problem Management input to Change Management:

• RFC for changes to a CI to eliminate recurring incidents • Rectifies incidents caused by failed changes

Configuration Management input to Problem Management:

• Used to identify faulty CIs and also to determine the impact of problems and resolutions • Used to form the basis for a known error Database

Problem Management input to Configuration Management:

• Tracks the number of CIs undergoing root cause analysis • Provides historical root cause data on CIs

10.3 Asset Management

The primary objective of Asset Management is to reduce the total cost of ownership, maximize asset value and manage IT asset lifecycle from cradle to grave. An asset is any resources or capability related to the procurement, development, delivery and support of an IT service.

Incident Management input into Asset Management

• Tracks historical data about total cost of ownership

Asset Management input to Incident Management

• Provides physical location of assets • Provides ownership data

Asset Management input into Change Management

• Provides contractual data in the form of SLAs / OLAs • Provides financial data of an asset

Change Management input into Asset Management

• Tracks historical data about total cost of ownership • Provides historical move data

Asset Management input into Configuration Management

• Provides asset lifecycle information • Provides physical asset information

Configuration Management input into Asset Management

• Used to determine strategic direction according to instances

11.0 Continuous Improvement

The primary goal of Continuous Improvement is to frequently align and re-align Agency Name services to the changing business needs by identifying and implementing improvements to Agency Name services and ITIL based processes to support business goals. Improvement activities look for ways to improve process and cost effectiveness as well as efficiency by identifying areas of automation, consolidation and integration.

Each Enterprise Directorate and Service Directorate will have the responsibility of planning and implementing improvement processes at the Enterprise and Service Operations level along with providing input to Agency Name Enterprise CCM improvements by assisting and making decisions on what improvement initiatives add the greatest value back to the business from a functional support and technical perspective. Agency Name process improvements will focus on a strategic approach addressing competencies, metrics, policies and governance.

1 Continuous Improvement Process

Enterprise CCM, Enterprise Directorates and Service Directorates should consider best practices processes when planning and implementing improvements. The Continuous Improvement Process consists of four (4) primary processes: Assessment, Planning, Implementation and Monitoring.

11.1.1 Process Activities

Each of the following activities should be performed in order to successfully identify, implement and measure process improvements for the Enterprise, Enterprise Directorates and Service Directorates Change and Configuration Processes.

11.1.1.1 Assessment

• Collect participants recommended improvement opportunities • Collect data and analyze trends compared to baselines, targets, SLAs and benchmarks • Include output from services and service management processes

11.1.1.2 Planning

• Set targets for improvement in efficiency and cost effectiveness throughout the entire service lifecycle • Set targets for improvements in service quality and resource utilization • Consider new business and security requirements • Consider new external drivers such as regulatory requirements • Create a plan

11.1.1.3 Implementation

• Revise policies, processes, procedures and plans where necessary • Implement improvements

11.1.1.4 Monitoring

• Measure, report and communicate on service improvement initiative status • Ensure that all approved actions are completed and that they achieve the desired results

[pic] Figure 23 Continuous Improvement Process

Appendix E

Acronyms

CAB Change Assessment Board CCB Change Control Board CCM Change and Configuration Management CMDB Configuration Management Data Base

ECCB Enterprise Change Control Board ECCM Enterprise Change and Configuration Management ERB Engineering Review Board

ITIL Information Technology Infrastructure Library ITSM Information Technology Service Management

KGI Key Goal Indicators KPI Key Performance Indicators

RCA Root Cause Analysis

SC Service Directorate SC CCB Service Directorate Configuration Control Board

TPIR Technical Post Implementation Review

Appendix F

Glossary of Terms[5]

A

Acceptance – A formal agreement that an IT service, process, plan, or other deliverable is complete, accurate, reliable and meets its specified requirements. Acceptance is usually preceded by evaluation or testing and is often required before proceeding to the next stage of a Project or Process.

Application - Software that provides functions that are required by an IT service. Each application may be part of more than one IT service. An application runs on one or more servers or clients.

Architecture - The structure of a system or IT service, including the relationships of components to each other and to the environment they are in. Architecture also includes the standards and guidelines that guide the design and evolution of the system.

Assessment - Inspection and analysis to check whether a standard or set of guidelines are being followed, that records are accurate, or that efficiency and effectiveness targets are being met.

Asset - Any resource or capability. Assets of a service provider including anything that could contribute to the delivery of a service. Assets can be one of the following types: management, organization, process, knowledge, people, information, applications, infrastructure, and financial capital.

Asset Management - Asset Management is the process responsible for tracking and reporting the value and ownership of financial assets throughout their lifecycle. Asset Management is part of an overall service asset and configuration management process.

Attribute - A piece of information about a configuration item. Examples are: name, location, version number, and cost. Attributes of CIs are recorded in the Configuration Management Database (CMDB).

Audit - Formal inspection and verification to check whether a standard or set of guidelines are being followed, that records are accurate, or that efficiency and effectiveness targets are being met. An audit may be carried out by internal or external groups.

B

Backup - Copying data to protect against loss of Integrity or availability of the original.

Baseline - Benchmark used as a reference point. A performance baseline can be used to measure changes in performance over the lifetime of an IT Service. A configuration management baseline can be used to enable the IT Infrastructure to be restored to a known configuration if a change or release fails.

Benchmark - The recorded state of something at a specific point in time. A Benchmark can be created for a configuration, a process, or any other set of data.

Best Practice - Proven activities or processes that have been successfully used by multiple organizations.

Build - The activity of assembling a number of configuration items to create part of an IT service. The term build is also used to refer to a release that is authorized for distribution.

Build Environment - A controlled environment where applications, IT services and other builds are assembled prior to being moved into a test or live environment.

Business Case - Justification for a significant item of expenditure. Includes information about costs, benefits, options, issues, risks, and possible problems.

Business Objective - The objective of a business process, or of the business as a whole. Business Objectives support the business vision, provide guidance for the IT strategy, and are often supported by IT services.

Business Perspective - An understanding of the service provider and IT services from the point of view of the business, and an understanding of the business from the point of view of the service provider.

Business Service - An IT service that directly supports a business process, as opposed to an infrastructure service, which is used internally by the IT service provider and is not usually visible to the business. The term business service is also used to mean a service that is delivered to business customers by business units.

C

Capability - The ability of an organization, person, process, application, configuration item or IT service to carry out an activity. Capabilities are intangible.

Category - A named group of things that have something in common. Categories are used to group similar things together. For example, incident categories are used to group similar types of incidents, CI types are used to group similar types of configuration items.

Change - The addition, modification or removal of anything that could have an effect on IT services. The scope should include all IT services, configuration items, processes, documentation, etc.

Change History - Information about all changes made to a configuration item during its life. Change History consists of all those change records that apply to the CI.

Change Management - The Process responsible for controlling the lifecycle of all changes. The primary objective of Change Management is to enable beneficial changes to be made, with minimum disruption to IT services.

Change Record - A Record containing the details of a change. Each change record documents the lifecycle of a single change. A change record is created for every request for change that is received, even those that are subsequently rejected. Change records should reference the configuration items that are affected by the change. Change records are stored in the Configuration Management System.

Change request - The controlled process for the addition, modification, or removal of approved, supported, or base-lined hardware, networks, software, applications, environments, or systems. A change request can involve multiple change activities

Change Schedule - A Document that lists all approved changes and their planned implementation dates. A change schedule is sometimes called a forward schedule of change, even though it also contains information about changes that have already been implemented.

Change Window - A regular, agreed time when changes or releases may be implemented with minimal impact on services. Change windows are usually documented in SLAs.

CI Type - A Category that is used to Classify CIs. The CI Type identifies the required Attributes and relationships for a configuration record. Common CI Types include hardware, document, user, etc.

Classification - The act of assigning a category to something. Classification is used to ensure consistent management and reporting. CIs, incidents, problems, changes, etc. are usually classified.

Client - A generic term that means a Customer, the Business or a Business Customer. The term client is also used to mean: A computer that is used directly by a User, for example a PC, Handheld Computer, or Workstation The part of a Client-Server Application that the user directly interfaces with.

Closed - The final status in the lifecycle of an incident, problem, change, etc. When the status is Closed, no further action is taken.

Commercial Off-The-Shelf (COTS) - Application software or middleware that can be purchased from a Third Party.

Compliance - Ensuring that a standard or set of guidelines is followed, or that proper, consistent accounting or other practices are being employed.

Component - A general term that is used to mean one part of something more complex. For example, a computer system may be a component of an IT service; an Application may be a component of a release Unit. Components that need to be managed should be configuration items.

Configuration - A generic term, used to describe a group of configuration items that work together to deliver an IT service, or a recognizable part of an IT service. Configuration is also used to describe the parameter settings for one or more CIs.

Configuration Item - Any Component that needs to be managed in order to deliver an IT service. Information about each CI is recorded in a configuration record within the CMDB and is maintained throughout its lifecycle by configuration management. CIs are under the control of Change Management. CIs typically include IT services, hardware, software, buildings, people, and formal documentation such as process documentation and SLAs.

Configuration Management - The Process responsible for maintaining information about configuration items required delivering an IT service, including their Relationships. This information is managed throughout the lifecycle of the CI. Configuration Management is part of an overall service asset and configuration management process.

Configuration Management Database (CMDB) - A database used to store configuration records throughout their lifecycle. A Configuration Management System maintains one or more CMDBs, and each CMDB stores attributes of CIs, and relationships with other CIs.

Configuration Management System - A set of tools and databases that are used to manage an IT service provider’s configuration data. The CMS also includes information about incidents, problems, known errors, changes and releases; and may contain data about employees, suppliers, locations, business units, customers and users.

Configuration Record - A Record containing the details of a configuration item. Each Configuration Record documents the lifecycle of a single CI. Configuration Records are stored in a Configuration Management Database.

Configuration Structure - The hierarchy and other relationships between all the configuration items that comprise a configuration.

Continual Service Improvement - A stage in the lifecycle of an IT service and the title of one of the core ITIL publications. Continual Service Improvement is responsible for managing improvements to IT Service Management Processes and IT services.

Contract - A legally binding agreement between two or more parties.

Control - A means of managing a risk, ensuring that a business objective is achieved, or ensuring that a process is followed. Example Controls include policies, procedures,roles, etc. A Control is sometimes called a countermeasure or safeguard.

Core Service - An IT service that delivers basic outcomes desired by one or more customers.

Cost Effectiveness - A measure of the balance between the effectiveness and cost of a service, process or activity. A Cost Effective process is one that achieves its objectives at minimum cost.

Customer - Someone who buys goods or services. The Customer of an IT service provider is the person or group that defines and agrees the service level targets. The term Customers is also sometimes informally used to mean users.

D

Dashboard - A graphical representation of overall IT service performance and availability. Dashboard images may be updated in real-time, and can be included in management reports and web pages. Dashboards can be used to support Service Level Management, Event Management or incident diagnosis.

Definitive Media Library - One or more locations in which the definitive and approved versions of all software configuration items are securely stored. The DML may also contain associated CIs such as licenses and documentation. The DML is a single logical storage area even if there are multiple locations. All software in the DML is under the control of change and release management and is recorded in the Configuration Management Database. Only software from the DML is acceptable for use in a release.

Deliverable - Something that must be provided to meet a commitment in a service level agreement or a contract. Deliverable is also used in a more informal way to mean a planned output of any process.

Deployment - The Activity responsible for movement of new or changed hardware, software, documentation, Process, etc. to the production environment. Deployment is part of the release and deployment management process.

Development - The Process responsible for creating or modifying an IT service or application. Also used to mean the Role or group that carries out development work.

Directed Change – A change mandated to be implemented by any government regulating authority.

Directorate – An Enterprise Operation organization within Agency Name.

Document - Information in readable form. A Document may be paper or electronic. For example, a policy statement, service level agreement, incident record, diagram of computer room layout.

Downtime - The time when a configuration item or IT service is not available during its agreed service time. The Availability of an IT service is often calculated from agreed service time and downtime.

E

Effectiveness - A measure of whether the objectives of a process, service or activity have been achieved. An effective process or activity is one that achieves its agreed objectives.

Emergency Change - An emergency change is a reserved change that is intended to repair a service disruption that is negatively affecting the Agency Namebusiness to a high degree. A Change that must be introduced as soon as possible.

Environment - A subset of the IT infrastructure that is used for a particular purpose. For example: Live Environment, Test Environment, and Build Environment. It is possible for multiple Environments to share a configuration item, for example Test and Live Environments may use different partitions on a single mainframe computer. Also used in the term Physical Environment to mean the accommodation, air conditioning, power system, etc. Environment is also used as a generic term to mean the external conditions that influence or affect something.

Escalation - An activity that obtains additional resources when these are needed to meet service level targets or customer expectations. Escalation may be needed within any IT Service Management Process, but is most commonly associated with incident management, problem management.

F

Failure - Loss of ability to operate to specifications, or to deliver the required output. The term Failure may be used when referring to IT services, processes, activities, configuration items, etc.

Fit for Purpose - An informal term used to describe a process, configuration item, IT service, etc. that is capable of meeting its objectives or service levels. Being Fit for Purpose requires suitable design, implementation, control and maintenance.

Function - A team or group of people and the tools they use to carry out one or more processes or activities.

G

Governance - Ensuring that policies and strategy are actually implemented, and that required processes are correctly followed. Governance includes defining roles and responsibilities, measuring and reporting, and taking actions to resolve any issues identified.

Guideline - A Document describing best practice, which recommends what, should be done.

I

Impact - A measure of the effect of an incident, problem or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.

Incident - An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a Configuration Item that has not yet affected Service is also an Incident.

Incident Management - The Process responsible for managing the Lifecycle of all Incidents. The primary objective of incident management is to return the IT service to customers as quickly as possible.

Incident Record - A Record containing the details of an Incident. Each Incident record documents the lifecycle of a single incident.

Information Technology - The use of technology for the storage, communication or processing of information. The technology typically includes computers, telecommunications, Applications and other software. The information may include business data, voice, images, video, etc. Information Technology is often used to support business processes through IT services.

Information Technology Service Management (ITSM) - Is a discipline for managing information technology (IT) systems, philosophically centered on the customer's perspective of IT's contribution to the business.

Infrastructure Service - An IT Service that is not directly used by the business, but is required by the IT service provider so they can provide other IT services. For example directory services, naming services, or communication services.

ISO/IEC 20000 - ISO Specification and Code of Practice for IT Service Management. ISO/IEC 20000 is aligned with ITIL best practice.

IT Infrastructure - All of the hardware, software, networks, facilities, etc. that are required to develop, Test, deliver, Monitor, Control or support IT Services. The term IT Infrastructure includes all of the Information Technology but not the associated people, Processes and documentation.

IT Operations - Activities carried out by IT Operations Control, including Console Management, Job Scheduling, Backup and Restore, and Print and Output Management. IT Operations is also used as a synonym for Service Operation.

AGENCY NAME Service - A service enumerated in the AGENCY NAME Service Catalog that is provided to one or more customers by AGENCY NAME’s service Directorates. An AGENCY NAME service is based on the use of IT and supports customer businesses processes. An AGENCY NAME service is made up from a combination of people, processes, and technology and should be defined in a service level agreement (SLA)

ITIL - A set of best practice guidance for IT Service Management. ITIL is owned by the OGC and consists of a series of publications giving guidance on the provision of quality IT services, and on the processes and facilities needed to support them

K

Key Performance Indicator (KPI) - A Metric that is used to help manage a process, IT service or activity. Many Metrics may be measured, but only the most important of these are defined as KPIs and used to actively manage and report on the process, IT service or activity.

L

Lifecycle - The various stages in the life of an IT service, configuration item, incident, problem, change, etc. The Lifecycle defines the categories for status and the status transitions that are permitted.

M

Metric - A Metric that is used within the IT service provider to monitor the efficiency, effectiveness or cost effectiveness of the IT service provider’s internal processes. Internal Metrics are not normally reported to the customer of the IT service.

Middleware - Software that connects two or more software components or applications. Middleware is usually purchased from a supplier, rather than developed within the IT Service provider.

Monitoring - Repeated observation of a configuration item, IT service or process to detect events and to ensure that the status is known.

O

Objective - The defined purpose or aim of a process, an activity or an organization as a whole. Objectives are usually expressed as measurable targets. The term Objective is also informally used to mean a requirement.

Operation - Day-to-day management of an IT service, system, or other configuration item. Operation is also used to mean any pre-defined activity or transaction.

Operational Level Agreement (OLA) – An agreement between an IT service provider and another part of the same organization. An OLA supports the IT service provider’s delivery of IT services to customers. The OLA defines the goods or services to be provided and the responsibilities of both parties.

P

Performance - A measure of what is achieved or delivered by a system, person, team, process, or IT service.

Planned Downtime - Agreed time when an IT service will not be available. Planned downtime is often used for maintenance, upgrades and testing.

Policy - Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent and appropriate development and implementation of processes, standards, roles, activities, IT infrastructure, etc.

Problem - A cause of one or more Incidents. The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation.

Problem Management - The Process responsible for managing the lifecycle of all problems. The primary objectives of Problem Management are to prevent Incidents from happening, and to minimize the Impact of Incidents that cannot be prevented.

Problem Record - A Record containing the details of a Problem. Each Problem Record documents the Lifecycle of a single Problem.

Procedure - A Document containing steps that specify how to achieve an activity. Procedures are defined as part of processes.

Process - A structured set of activities designed to accomplish a specific objective. A Process takes one or more defined inputs and turns them into defined outputs. A Process may include any of the roles, responsibilities, tools and management controls required to reliably deliver the outputs. A Process may define policies, standards, guidelines, activities, and work Instructions if they are needed.

Process Control - The activity of planning and regulating a process, with the objective of performing the process in an effective, efficient, and consistent manner.

Process Manager - A role responsible for operational management of a process. The Process Manager’s responsibilities include planning and coordination of all activities required to carry out, monitor and report on the process.

Process Owner - A Role responsible for ensuring that a process is fit for purpose. The Process Owner’s responsibilities include sponsorship, design, change management and continual improvement of the process and its metrics.

Production Environment - A controlled environment containing live configuration Items used to deliver IT services to customers.

Program - A number of projects and activities that are planned and managed together to achieve an overall set of related objectives and other outcomes.

Project - A temporary organization, with people and other assets required to achieve an objective or other outcome. Each Project has a lifecycle that typically includes initiation, planning, execution, closure, etc.

Projected Service Outage - A Document that identifies the effect of planned changes, maintenance activities and test plans on agreed service levels.

Q

Quality - The ability of a product, Service, or Process to provide the intended value. For example, a hardware Component can be considered to be of high Quality if it performs as expected and delivers the required Reliability. Process Quality also requires an ability to monitor Effectiveness and Efficiency, and to improve them if necessary.

R

Relationship - A connection or interaction between two people or things. In configuration management, it is a link between two configuration items that identifies a dependency or connection between them. In business relationship management, it is the interaction between the IT service provider and the business.

Release - A collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT services. The contents of each release are managed, tested, and deployed as a single entity.

Release and Deployment Management - The process responsible for both release management and deployment.

Request for Change (RFC) - A formal proposal for a change to be made. An RFC includes details of the proposed change, and may be recorded on paper or electronically.

Requirement - A formal statement of what is needed.

Resource - A generic term that includes IT Infrastructure, people, money or anything else that might help to deliver an IT service. Resources are considered to be assets of an organization.

Return on Investment (ROI) - A measurement of the expected benefit of an investment. In the simplest sense, it is the net profit of an investment divided by the net worth of the assets invested.

Retire - Permanent removal of an IT service, or other configuration item, from the production environment. Retired is a stage in the lifecycle of many configuration items.

Review - An evaluation of a change, problem, process, project, etc. Reviews are typically carried out at predefined points in the lifecycle, and especially after closure.

Risk - A possible event that could cause harm or loss, or affect the ability to achieve objectives. A risk is measured by the probability of a threat, the vulnerability of the asset to that threat, and the impact it would have if it occurred.

Risk Assessment - The initial steps of risk management. Analyzing the value of assets to the business, identifying threats to those assets, and evaluating how vulnerable each asset is to those Threats.

Role - A set of responsibilities, activities and authorities granted to a person or team. A Role is defined in a process. One person or team may have multiple roles.

Rollback - Returning a configuration item or an IT service to a working state. Recovery of an IT service often includes recovering data to a known consistent state.

Root Cause Analysis (RCA) - A class of problem solving methods aimed at identifying the root causes of problems or events.

S

Scope - The boundary, or extent, to which a process, procedure, certification, contract, etc. applies.

Server - A computer that is connected to a network and provides software functions that are used by other computers.

Service - A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.

Service Catalog - Electronic or physical document with information about all live IT services, including those available for deployment. The service catalog is the only part of the service portfolio published to customers, and is used to support the sale and delivery of IT services. The service catalog includes information about deliverables, SLAs, points of contact (POCs), and ordering.

Service Directorate – Any of AGENCY NAME’s IT service provider functional areas contracting with DoD agencies within the Pentagon via SLAs to provide IT products and services. The service provider groups are: Business Support Services (BSS), Data Center (DC), Consolidated Customer Service Center (CCSC), Customer Relationship Management (CRM), Defense Telecommunication Services – Washington (DTS-W), Enterprise Security Services Pentagon (ESSP), Engineering and Service Design (ESD), Information Management Support Center (IMCEN), Network Infrastructure Services and Operation – Pentagon (NISO), Pentagon Telecommunication Center (PTC).

Service Desk - The single point of contact between the service provider and the users. A typical Service Desk manages incidents and service requests, and also handles communication with the users.

Service Level - Measured and reported achievement against one or more service level targets. The term Service Level is sometimes used informally to mean service level target.

Service Level Agreement (SLA) - An agreement between a service provider and its customers or lines of business that formally documents the needs of the customer and makes sure the correct level of service is received from the service provider. An agreement between AGENCY NAME and a customer. The SLA describes the IT service, documents service level targets, and specifies the responsibilities of AGENCY NAME and the customer. A single SLA may cover multiple IT services or multiple customers.

Service Level Management - The process responsible for negotiating service level agreements, and ensuring that these are met.

Service Provider - An organization supplying services to one or more internal customers or external customers. Service Provider is often used as an abbreviation for IT service provider.

Single Point of Contact - Providing a single consistent way to communicate with an organization or business unit.

Stakeholder - All people who have an interest in an organization, project, IT service, etc.

Standard - A mandatory requirement. Examples include ISO/IEC 20000 (an international Standard), an internal security standard for UNIX configuration, or a government standard for how financial Records should be maintained. The term Standard is also used to refer to a code of practice or specification published by a standards organization such as ISO.

Standard Change - Also referred to as pre-approved change, is a pre-approved change that is low Risk, relatively common and follows a procedure or work instruction.

Status - The name of a required field in many types of record. It shows the current stage in the lifecycle of the associated configuration item, incident, problem, etc.

System - A number of related things that work together to achieve an overall objective. For example; A computer System including hardware, software and Applications

T

Technical Post-Implementation Review (TPIR) - A Review that takes place after a change or a project has been implemented. A TPIR determines if the change or project was successful, and identifies opportunities for improvement.

Test - An activity that verifies that a configuration item, IT service, process, etc. meets its specification or agreed requirements.

U

Urgency - A measure of how long it will be until an Incident, problem or change has a significant impact on the business. For example, a high Impact Incident may have low Urgency, if the Impact will not affect the business until the end of the financial year.

V

Validation - An activity that ensures a new or changed IT service, process, plan, or other deliverable meets the needs of the business.

Variance - The difference between a planned value and the actual measured value. Commonly used in financial management, capacity management and service level management, but could apply in any area where plans are in place.

Verification - An Activity that ensures a new or changed IT service, process, plan, or other deliverable is complete, accurate, and reliable and matches its design specification.

Version - A Version is used to identify a specific baseline of a configuration item. Versions typically use a naming convention that enables the sequence or date of each Baseline to be identified.

W

Warranty - A promise or guarantee that a product or service will meet its agreed requirements.

----------------------- [1] …. will operate like a Service Directorate and maintain a separate CCM Plan See Section 1.3 of this plan for more information [2] OGC Best Practice Management – ITIL [3] OGC Best Practice Management – ITIL [4] OGC Best Practice Management – ITIL [5] Definitions from: OGC Best Practice Management – ITIL Wikipedia

----------------------- Figure 20 Impact and Risk Matrix

Figure 22 Impact, Risk and Urgency Relationships