Document history

Date

Summary

2020-07-16

IT Executive Leadership Council approval – Approved version number set to 4.0

2020-05-20

Architecture Review Board endorsement

2020-02-11

Change Management COP review and feedback implemented

2016-03-31

IT Executive Leadership Council approval

2016-03-16

Architecture Review Board endorsement

2016-01-22

Updated to current GO-ITS template (2014-11-27) and revised to ensure content consistency and structure across GO-ITS process standards.

2015-12-11

PIML review and feedback implemented

2015-11-19

Modernized engagement standards and terminologies, to align with business models.

2007-07-26

Approved by the Architecture Review Board (ARB)

2007-04-30

Changed the informative reference - internal incident management process and procedures guide v1.2.5 to v1.2.9

2007-04-30

Original - GO-ITS 35 version 1.0 created

Requirements levels

Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:

Must: this word, or the terms "required" or "shall", means that the statement is an absolute requirement.

Should: this word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, cost) must be understood and carefully weighed before choosing a different course.

1. Foreword

Government of Ontario Information Technology (GO IT) Standards are the official publications on the IT standards adopted through the Office of the Corporate Chief Information Officer (OCCIO) for use across the government’s I&IT Infrastructure.

These publications support the responsibilities of the Treasury Board Secretariat (TBS) for coordinating standardization of Information & Information Technology (I&IT) in the Government of Ontario.

In particular, GO IT Standards describe where the application of an IT standard is mandatory and specify any qualifications governing the implementation of the IT standards.

Applicability

All Ministries and I&IT clusters are subject to GO IT Standards.

All advisory and adjudicative agencies are subject to GO IT Standards. For the purposes of this document, any reference to Ministries or the Government includes applicable agencies.

All other agencies that are using Ontario Public Service (OPS) information and information technology products or services are required to comply with GO IT Standards if they are subject to either the management and use of I&IT directive or GO IT Standards by memorandum of understanding.

As new GO IT Standards are approved, they are deemed mandatory on a go-forward basis meaning at the next available project development or procurement opportunity as applicable.

When implementing or adopting any GO IT Standards, Ministries, I&IT clusters and applicable agencies must follow their organization’s pre-approved policies and practices for relevance of this standard and ensuring that adequate change control, change management and risk mitigation mechanisms are in place and employed.

2. Introduction

Background and rationale

This process standard was initially part of a portable set of Information Technology Service Management (ITSM) process documentation intended for use as a reference across the OPS. A key objective identified during an OPS ITSMplanning workshop held in December 2003 was to “define standard portable elements for all ITSMprocesses”. As a result, process guides were designed to be portable across all I&T clusters as well as any parties in the end-to-end supply chain. These guides would only include the necessary process components that should be common across the OPS.

The requirement for an all-encompassing OPS change management standard was predicated by the fundamental positioning of all infrastructure service and support within Infrastructure Technology Services (ITS); a new organization within the OPS mandated to deliver all infrastructure technology services to the OPS. This mandate was provided in late 2005 and the ITS organization was created in 2006.

The Establishment of ITS required a  review of the GO-IT standard for change management to ensure it applied to the consolidated perspective of service delivery implied by the creation of ITS. The result was the creation of an enterprise view of change management describing the elements required to implement this standard within the OPS. The Enterprise Change Management (eCM) Model reflected a need to specify    several additional process elements. Further procedural detail still may be required to be defined at the local level, but all parties in the supply chain are expected to follow the eCM process, roles and principles at a minimum.

This documentation builds on the portable guides and, prior to their creation, the OPS standard change and Configuration Management Process Guide version 2.3 (last updated in March, 2001) as reference points. Changes have been made to the portable guide for the following main reasons:

  1. Principles, roles, responsibilities and processes that are required OPS-wide have been added.
  2. The standard has been updated to reflect a maturing of the OPS in its implementation of the eCM process.
  3. The standard has been updated to reflect the evolution of ITIL best practices and the evolution of IT service management within the OPS.

This document establishes standard eCM principles, roles and associated process and process model for use across the OPS.  Use of this single process and supporting information will also enable OPS-wide monitoring and reporting through establishment of common data and associated metrics.

GO-ITS 44 ITSM Terminology Reference Model  provides a common information model for key process parameters that require standardization across the OPS to ensure consistency, reliable business intelligence and to support end-to-end cross-jurisdictional service management.

Target audience

The information in this document is primarily intended for members of the following areas within the OPS:

  • Infrastructure Technology Services (ITS)
  • Cyber Security Division (CSD)
  • I&IT clusters.
  • Agencies that use Ontario Public Service (OPS) information and information technology products

Scope

eCM is the addition, modification, maintenance or removal of an authorized, planned or supported  IT Service Assets and components and its associated documentation.

The eCM process includes activities that ensure the ability to measure the impact of  changes within the IT environment.

The eCM process must be able to maintain a standard environment; cope with heterogeneous dynamic I&IT Infrastructure requirements; and the integration and interaction with various related changes (e.g. Applications/Solutions/Services).

A key criterion in defining whether an action falls within the scope of the eCM process is whether that action has potential impact on service delivery and whether it will impact a Configuration Items(s) (CIs) and/or  relationship controlled by the Enterprise Service Asset and Configuration Management (eSACM)  process.

In Scope
  • Managing change of information solutions (e.g. applications, solutions, etc.) and I&IT Infrastructure services
  • Authorizing change to information solutions (e.g. applications, solutions, etc.) and I&IT Infrastructure services
  • Technical and business risk and impact assessment of change implementations.
Out of Scope
  • Control of application development and release of new changed components (release management)
  • Controlled release of new software, hardware, etc. if required to implement change (release management) and updates to CIs (eSACM)
  • Assess impact on business and IT performance (capacity management).

3. Technical specification

3.1. Process definition

The eCM process ensures that all changes to the IT production environment are properly planned, managed, assessed, approved and reviewed prior/following their implementation and release.

Note: The eCM Process Standard will be reviewed regularly and be updated as a result of continuous service improvement to ensure that there is appropriate governance and oversight for each component of this process model; as such, this process model may be subject to change in the future.

3.2. Process purpose

The purpose of the eCM process is to control changes to Information (e.g. solutions/applications) and Information Technology (e.g. Infrastructure) through standardized, repeatable methods and procedures. The eCM process supports efficient handling of changes, minimizes impact to the production environment and provides accurate timely management information on changes. It should be emphasized that the aspect of communicating changes and identifying communications to support staff across the OPS is in fact an essential responsibility of eCM.

The primary focus of the eCM process is on managing the initiation, review, approval and oversight of the implementation of all proposed changes to the I&IT Infrastructure and productions environments.

This process is triggered by other ITSMprocesses whenever there is a need to modify a Configuration item (CI), either by altering, adding or retiring a CI.

3.3. Value to the business

The proper planning, assessment and implementation of changes to the I&IT environment ensures that outages to applications that support business or technical services are minimized, and that I&IT Infrastructure remains operational, to support dependent services.

eCM provides value to the organization in the following ways:

  • Risk reduction - Control and management of change minimizes the risk of adversely affecting service delivery when introducing a change into the production environment.
  • Cost reduction - Proper change management improves change efficiency and reduces rework and back outs.
  • Service agility improvement - A streamlined process and structured procedures for change implementation allow organizations to align quickly and effectively to changing business requirements.
  • Service quality improvement - Proper risk and impact assessment of changes prevents unscheduled outages thereby increasing service quality. In addition, keeping records of changes facilitates continuous process improvement and expedites resolution of issues related to change.

3.4. Basic concepts

The eCM process enables CI changes to be planned and executed while minimizing the risk of service disruption. This process provides improved responsiveness to the business and enables streamlined approval decisions based on class and risk and impact assessment for different categories of change.  Change Advisory Boards (CABs) at the appropriate level of jurisdiction facilitates assessment, prioritization and advise the Change Manager whom has final approval of each change.

The eCM process requires managing the initiation, planning and approval, building and testing, release to production, ongoing maintenance, and review of all proposed changes to the I&IT environment. Changes include those to hardware and operating system software (including security patches), communications software and hardware, application software, documentation, process and procedures, environmental facilities and all other I&IT infrastructure CIs that are identified as requiring management and control.

A change is defined as any activity that adds to, deletes from, or modifies a CI.

eCM is also the “gate” through which requests for change to managed CIs must pass on their way from a non-production to the production environment.

The eCM process provides the ability to handle changes to the I&IT infrastructure and information-based solutions in a manner that minimizes the effect changes have on the provision of I&IT services to customers. In addition, through standardized processes and procedures, the eCM process allows an organization to accommodate a higher volume of change effectively and efficiently.

A single change request (CRQ) triggers the process.  Impacted components, service functions and end-to-end services are identified and the impact of the proposed change is assessed by reviewing the attributes and relationships of the CIs that will be affected by the change, as well as any other relevant information. Consequently, an effective linkage is required between the eCM process and the eSACM process and associated Configuration Management Database (CMDB) in order to improve accuracy of impact and risk assessments. This function of change assessment may include input from assessors across the OPS, and is not restricted to a single organization.

After the change has met the minimum submission criteria and the   change has  been accepted by an Enterprise Change Management Practitioner , the  change becomes an object that can be tracked through implementation. Status updates will be made to the  change, as progress is made, which allows change activity to be tracked and managed. Once a  change is created and tracked by eCM, it remains permanently accessible for auditing purposes, regardless of its lifecycle outcome. Throughout the change process, information around key events is provided to the OPS IT service desk (through the Forward Schedule of Change/Activity (FSC/FSA) so impacted stakeholders and end users can be informed. Additionally, costs for labour (time) and materials may be optionally recorded for future analysis and billing purposes. Upon completion the change is reviewed.

Two key change activities are change class and risk level:

  • Class is used to establish the order in which changes are considered for implementation . For example, a change may have a class of “Expedited” and hence should be prioritized over changes with a class of “Normal”
  • Risk level looks at both the Risk and Impact of implementing the change. Risk level will impact the level of approvals required for the change – i.e. review from jurisdictional CABs may be required, or approval from corporate change management

 To streamline the approval process, the concept of a standard change was introduced. Standard changes are types of changes that are frequent in nature, low in risk/impact and considered pre-approved. For a change to be established as a standard change, the requester must provide historical evidence to the Enterprise Change Management (eCM) team that proves the change meets the criteria of a successful precedent setting repeatable minor change  The eCM team can then designate that all future changes of this type can be treated as a standard change.

Also,  fast track path through the process exists to process   “ Emergency and Expedited” changes. This  may requires a meeting of the emergency CAB (ECAB) or the appropriate level of signing authority for Expedited changes.

3.4.1. Inputs to the process

Inputs to the eCM process include:

  • CRQ
  • CI data from eSACM
  • Change implementation procedures.

3.4.2. Outputs from the process

Outputs from the eCM process include:

  • Detailed CRQs
  • Implemented change
  • CAB minutes and actions
  • Change reports
  • Information provided to eSACM for updates to CI and relationship updates
  • Satisfied customer.

3.5. Process principles

 I&IT organizations define principles to guide the design and delivery of services to customers or users. Principles can be common – that is they apply to all functions and groups or local and apply to a specific function or group.

The absence of well-defined common principles may result in processes that are neither aligned with customer expectations nor with the standards set for delivery of service.

Common principles for the OPS include the following:

Principle 1:

eCM will manage all changes made to the production environment, including the operational test environment. This includes changes implemented by vendors and external organizations that has the potential impact to the OPS.

Rationale:

  • Standard, consistent, end-to-end process across  the enterprise. Primary focus on reducing impact on the production environment.

Implications:

  • All changes are recorded and tracked by the same repeatable process for consistency across the  enterprise.
  • The formal process might be perceived as taking longer, especially for urgent and minor/standard changes. Special expedited procedures are required for urgent and standard changes
  • Clear criteria are required to define changes by type. All service providers and vendors must comply with the process
  • Procedures and guidelines must be made available to all participants in the eCM process
  • Communication and process training will need to be developed for customers, vendors and I& IT personnel.

Principle 2:

Effective risk and impact assessment is enforced and is considered the foundation of eCM.

Rationale:

  • Primary focus on reducing impact on the production environment
  • Service-focused  I&IT management.

Implications:

  • Relationship information for I&IT components and services must be clearly defined and readily accessible
  • Integration with eSACM is required
  • Standard risk and impact assessment criteria are needed
  • Different types of changes may require different eCM procedures depending on factors such as risk and impact. The change class determines the procedures applied to it
  • Change process turnaround times  should be based on Risk and Impact in addition to change class
  • Awareness of concurrent changes and release schedules and understanding of dependencies is required.

Principle 3:

All customers are informed of changes that affect the Service(s) they receive prior to change implementation.

Rationale:

  • Manages expectations
  • Service-focused I&IT management.

Implications:

  • The communication procedures (internal and external), technology, and responsibilities will have to be defined and implemented
  • FSCs are required
  • Integration with Incident Management is needed.

Principle 4:

There is a mechanism to implement Expedited changes to the managed environment with minimum destabilization of that environment.

Rationale:

  • Support the business in responding to unanticipated external influences
  • High responsiveness to security incidents and breaches, safety and expedited change requirements.

Implications:

  • A separate path is required for expedited changes
  • Clear criteria are required to define timing reason (i.e. urgency of the change)
  • Change documentation might be delayed till after the expedited change is implemented
  • Depending on the nature of the change, it may be necessary to implement a change without a written/detailed change request (CRQ); procedures must exist to cover these exemptions
  • Some changes might be introduced into the production environment without full testing thus posing more risk to the production environment
  • Negative impact may occur
  • A clear change management escalation and approval path is required.

Principle 5:

The number of changes deemed expedited is reduced to a pre-specified and progressive metric through proper planning.

Rationale:

  • Expedited changes are the exception
  • Emphasize proactive planning
  • There is always a risk associated with the implementation of an expedited change.

Implications:

  • Metrics need to be defined and tracked for Expedited changes
  • Change Manager must have the authority to reject or delay unplanned changes.

Principle 6:

A CAB exists and the Change Manager is the ultimate decision making authority within the CAB.

  • Rationale . It is at the discretion of the Change Manager, in conjunction with the eCM Process Manager and the CAB membership to determine the frequency of the CAB meetings:
  • Expedited decision-making
  • Clear accountability.

Implications:

  • Change Manager has to be assigned at an appropriate job level
  • Clear and appropriate guidelines are required for CAB membership and engagement.
  • Enterprise Change Manager requires the support of the membership
  • Jurisdictions of approval are clearly defined.

Principle 7:

The Corporate Change Advisory Board (CCAB) reviews all changes to I&IT services that have the potential to affect OPS business operations across two (2) or more Clusters, an enterprise-wide or public facing impact.  The eCM portfolio representative for the organization coordinating the change, is responsible for the change approval and representing the change at the Corporate Change Advisory Board

Rationale:

  • Ensure that multi-cluster/public facing changes will receive necessary due diligence prior to approval and implementation
  • Address the increasing multi-cluster business dependence on  enterprise I&IT infrastructure and services.

Implications:

  • Change Managers need to clearly understand the criteria for involving the Corporate CAB (CCAB)
  • CCAB membership must ensure adequate representation, role clarity and appropriate levels of authority to effect compliance
  • An escalation procedure is required to allow Change Managers to contest or facilitate a CCAB decision, if necessary. Review and Prioritize multi-cluster changes, especially between the Business (application) and IT (Infrastructure) changes.

Principle 8:

A change implementation plan is required prior to change deployment.

Rationale:

  • Enables the Change Coordinator to ensure that the change conforms to standards and principles
  • Ensures consistency of approach.

Implications:

  • Change coordinator(s) will be responsible for planning assigned elements/stages of change implementation
  • Change coordinator will require a check list of required plan components (e.g. risk assessment, backout plan, verification plan).

Principle 9:

All service providers will fulfill their roles in compliance with the eCM process.

Rationale:

  • Ensures consistent execution of change process
  • Service providers can play key roles in the process
  • Service providers own configuration items that are impacted by change.

Implications:

  • Change coordinator(s) will be responsible for planning assigned elements/stages
  • Process provisions will apply to internal and external service providers
  • Contracts with service providers must reflect the eCM activities, tasks and linkages associated with their role
  • External service providers require an OPS representative for certain activities (e.g. submitting CRQ, viewing sensitive information)
  • Linkages to service provider eCM process must be defined.

3.6. Process roles and responsibilities

Each process has specific roles with defined responsibilities for process design, development, execution and management. In an organization, one person can take on multiple roles as per the requirements specific to the organization. This person may choose to delegate these responsibilities to those lower in the hierarchy. Additionally, responsibilities of one role could be mapped to multiple individuals.

Regardless of specific organizational mapping, specific roles are necessary for the proper operation and management of the process. These roles are required at the Enterprise level of eCM. This section lists these roles and their responsibilities.

In addition to process roles, service-specific roles may be defined as part of the management and governance structure for a specific service. Other roles will also be involved in the eCM process activities, including other ITSMprocess roles, operations, and service providers.

One role is accountable for each process activity. The role may assign one or more people who are responsible to carry out the task. However, it is ultimately the job of the person who is accountable to ensure that the “job gets done”.

Legend:

R=Responsible
A=Accountable
C=Consult Before
I=Inform After Implementation

Process activities

Change requester

Change mgr.

Change coordinator

CAB

Change assessor

Change implementer

1.0 Log and classify change

R

A

R

-

-

-

2.0 Approve change for assessment

I

A

I

I

-

-

3.0 Asses risk and impact and schedule change

I

A

R

R

R

-

4.0 Approve change for implementation

C

A

R

C

R

I

5.0 Implement change

C

I

R/A

I

-

R

6.0 Validate change

R

I

A

I

-

R

7.0 Conduct post implementation review

R

A

R

-

R

R

8.0 Close change

I

A

I

-

I

I

3.6.1. eCM Process Owner

The eCM process owner is accountable for setting policy and providing leadership and direction for the development, design and integration of the process as it applies to other applicable frameworks and related ITSMprocesses being used and or adopted in the OPS. The eCM process owner shall be accountable for the overall health and success of the process.

Responsibilities:

  • Ensures that the process is defined, documented, maintained and communicated at an Organizational level through appropriate channels
  • Undertakes periodic review of the process to ensure that a methodology of continuous service Improvement, (including applicable process-level supporting metrics) is in place to address shortcomings and evolving requirements
  • Ensures alignment between the eCM and other  IT Service Management processes
  • Ensures the process requirements are developed, documented and implemented with enabling technology
  • Defines and evolves enterprise process Key Performance Indicators (KPIs) and reporting for the process
  • Consults with the Process Stakeholders to ensure the process is meeting the needs of all affected stakeholders.

3.6.2. eCM Process Manager

The eCM Process Manager  oversees the process and manages the supporting documentation for the process within their  change portfolio. The eCM Process Manager provides process leadership by ensuring that the process is followed by the jurisdiction. When the process isn't being followed or isn't working well, the process Manager is responsible for identifying why and ensuring that required actions are taken to correct the situation. In addition, the eCM Process Manager is responsible for the development of continuous service improvement plans and to highlight and identify any process deficiencies or anomalies to the eCM process owner.

Responsibilities:

  • Ensures that the process is defined, documented, maintained and communicated at the local jurisdictional level
  • Reviews effectiveness and efficiency of the eCM process and identifies opportunities for process improvement
  • Is responsible for the success or failure of the eCM process (not the actual changes themselves)
  • Establishes local-level eCM process metrics based on jurisdictional reporting requirements
  • Ensures adherence to the eCM process
  • Ensures adequate level of process training is made available in the enterprise.
  • Facilitate  alignment between the eCM process, ITSM processes in the enterprise.
  • Analyzes change records to detect any trends or problems and proposes actions to rectify apparent weak areas in the eCM process.

3.6.3. Change Manager or eCM Practitioner

The primary focus of this role is at the process level within their  eCM portfolio(s) although some responsibilities do cross over and require attention at the individual change level as well.

Responsibilities:

  • Accountable for carrying out and executing the defined process within their eCM portfolio(s),Ensures that the eCM process is followed and that only approved changes are implemented
  • Ensures the eCM process is followed for planning, assessing, building, testing and implementing changes
  • Ensures changes are  reviewed by all impacted organizations, through the engagement of impacted stakeholders (i.e.: Change Managers and impacted clusters, etc.)
  • Chair the CAB and ECAB meetings
  • Makes decisions regarding the composition of the CAB and ensures that the CAB is authoritative and effective
  • Ensures changes conform to process standards, principles and  change procedures
  • Analyzes change records to detect any trends or problems and proposes actions to rectify apparent weak areas in the eCM process
  • Monitors resources within  change management portfolios to ensure the completion of all assigned change activities by scheduled dates, escalating to the eCM Process Manager as required
  • Coordinates/schedules changes considering all dependencies and relationships
  • Responsible for reviewing the change plan and for ensuring  that changes contain implementation, verification and back out plans
  • Approves the assessment of  changes initiated by  their  portfolio. Rejects changes that do not meet the defined requirements
  • Coordinates the production and distribution of the FSC
  • Ensures that all changes implemented  are  fully assessed and  approved
  • Reviews change exceptions
  • Ensures that Post Implementation Reviews (PIRs) are conducted
  • Produces regular and accurate management reports
  • Engages upper levels of management when needed to resolve conflicts
  • Identifies and implements process and procedural improvements
  • Provides input to management regarding staff skill levels for eCM
  • Participates in other ITSMprocess initiatives and process reviews
  • Provides input into important decisions regarding eCM supporting technology
  • Closes changes.

3.6.4. Change Coordinator

The primary focus of this role is to oversee changes ensuring they are executed as per the defined process while being accountable to the eCM Change Manager. . The focus of this role is at the individual change level rather than the process level.

Responsibilities:

  • Accountable to the eCM Change Manager  to carry out and execute a change as per the defined process
  • Responsible for all issues and inquires for coordinated changes, including  execution of change activities that impacts multiple portfolios.
  • Ultimately accountable for the acceptance and  successful implementation of the change
  • Develops implementation plan for assigned changes including coordination with other technical groups
  • Solicits active involvement of appropriate technical groups during planning
  • Locates and assigns resources used to build, test and implement changes working with the  stakeholders from other jurisdictions, when required
  • Ensures the eCM process is followed for planning, assessing, building, testing and implementing changes
  • Reviews the initial change class and priority based on predefined definitions and requests changing them if warranted due to new information
  • Following implementation, updates change record with an appropriate status and confirms that the completed change can be closed
  • Participates in the Post Implementation Review (PIR) process, if requested
  • Performs the initial risk and impact assessment from both a business and a technical perspective of the change to assist the applicable change jurisdiction in approving and classifying the change
  • Provides additional information regarding a particular change when requested by the Change Manager
  • Responsible for locating, confirming a and scheduling resources within their  portfolio to plan, assess, build, test and implement changes
  • Reports exceptions to Change Manager.

3.6.5. Change Assessor

Responsibilities:

  • Responsible for contributing to the business and technical risk and impact assessment of a change for their jurisdiction
  • Responsible for reviewing the change implementation, verification and backout  plan, to confirm impacts and resourcing availability. Participates in planning for changes
  • Identifies dependencies and potential cross-impact of changes
  • Provides an informed opinion on change risk and impact, as submitted, within their domain of responsibility
  • Consults other subject matter experts or Stakeholders, as required.

3.6.6. Change Implementer

Responsibilities:

  • Responsible for deploying the approved change into the I&IT environment as per the approved CRQ’s implementation, testing and backout plans
  • Participates in planning for changes
  • Participates in business and technical change risk and impact assessment
  • Participates in building and testing changes
  • Implements change request
  • Participates in post-implementation testing, change validation and back out activities
  • Closes their assigned(s) task in a timely manner
  • Communicates status to Change Coordinator.

3.6.7. Change Requester

The primary focus of this role is the population of the change request ensuring all mandatory criteria is met for the Change Manager to approve the change for assessment.

Responsibilities:

  • Provides a clear description of the reason for the change
  • Assigns an initial “class” based on predefined change class definitions
  • Provides initial business and technical risk and impact assessment which is captured by the risk level questionnaire on proposed changes and communicates this information back to the business
  • Follows the eCM process for submitting a CRQ
  • Provides additional information regarding the change when requested by the Change Manager/Coordinator
  • Confirms the completed change was successful and met original objectives
  • Relate impacted CIs to a CRQ if applicable.
  • Participates in the PIR process if requested.

3.6.8. Change Advisor Board (CAB)

The CAB is a body that exists to assist the Change Manager in the assessment, prioritization and approval of changes. There are multiple jurisdictions of CABs in the OPS, one for each change portfolio, Change Managers in each portfolio have the added responsibility of coordinating with other Change Managers (who may also engage their CABs) as required.

For example, an ITS  change affecting one cluster may precipitate that the subject portfolio’s Change Manager to review at their CAB, to ensure the risk and impact are well defined.   the portfolio Change Manager should communicate concerns to the ITS Change Manager as required.

The Change Manager chairs the CAB, which will include people who have adequate understanding of the needs of the customer as well as the technical development and support functions. The CAB must be constituted and run based on an  approved Terms of Reference (TOR), which will establish details such as who sits on the CAB, voting procedures, and quorums.

Responsibilities:

  • Review  CRQs to determine their impact, resource requirements and associated costs
  • Ensure all changes are adequately assessed and  have the appropriate  class and risk level
  • Utilizes the FSC for change scheduling decisions
  • Advises the Change Manager of scheduling conflicts
  • Shares in the responsibility for protecting the integrity of the I&IT environment.

CAB members are expected to attend CAB meetings as required by the eCM Change Manager  to support all CAB decisions.

For emergency changes, there may not be time to convene the full CAB, and it is therefore necessary to identify a smaller organization with authority to make emergency decisions. Such a body is known as the ECAB.

The ECAB usually consists of the eCM Process Manager, Change Manager and one to three subject matter experts whose  attendance  at ECAB depends on the nature of the change. The purpose of ECAB is to review and assess the Emergency change in an expedited manner. As such, this meeting may be a telephone conference.

3.6.10. Enterprise service provider

Due to the evolution and growth of the OPS, some service delivery entities (with the support of their I&IT cluster) provide services to other members of the OPS; as such, ITS is no longer the only entity that can offer services on an enterprise level.

A service delivery entity can be deemed an enterprise service provider in a CRQ under the following circumstances:

  1. A service delivery entity’s enterprise service is consumed by a cluster (different from themselves) to deliver service(s).
  2. The service being consumed is sanctioned by ITELC as enterprise-level, therefore, the service delivery entity is sanctioned as an enterprise service provider.

Coordination, assessment and appropriate governance are required to ensure that efficient service delivery is maintained, and that the end-to-end service satisfies the service delivery entity’s commitments to clients. Therefore, where an Enterprise Service Provider and one other client are provisioning a change, the change will not be presented at the CCAB.

The scope of changes presented at the CCAB includes those which impact public facing and enterprise-wide services. For example, the Land and Transportation Cluster (LTC) Cluster may be approving a change for their Road User Safety (RUS) business area, where one other Cluster is impacted by the change. In this scenario, LTC is not considered an enterprise service provider, as RUS is not an enterprise service provider. However, if LTC was approving a change for their .NET SDC business area, where one other Cluster is impacted by the change, LTC would be considered an enterprise service provider, as .NET SDC is an enterprise service provider. Hence, a portfolio may or may not wear the “service provider” that depending on the service area involved in the change.

A cluster acting as an enterprise service provider for a change is not identified as a cluster, therefore stating that “2 or more clusters are impacted on the change”, is not accurate – just 1 cluster is impacted.

Where an Enterprise Service Provider and one Client (i.e. another Cluster) are impacted by a change, review at the CCAB is not required.  Anytime two or more Clusters are impacted, the change will be tabled for review at the CCAB.

Corporate Change Advisory Board (CCAB)

The CCAB is an Advisory Committee consisting of eCM Change Manager representatives from all Clusters, Cyber Security and some Service Providers.  The purpose of the Committee is to review changes that impact the enterprise (2 or more clusters), enterprise-wide services, and the delivery of public facing mission and business critical services.  

Responsibilities:

Produce an FSC that captures changes for the upcoming week that impact 2 or more Clusters

  • Review changes presented on the FSC to address any potential questions or concerns.  Where concerns are raised, ensure investigation into the concerns, and resolution of any issues that are identified.
  • CCAB lead will initiate PIRs for changes that should have been classified as multi-jurisdictional will review results and action items with the CCAB membership
  • Utilizes the FSC to make informed assessments and decisions around scheduling
  • Advises the Change Manager of scheduling conflicts
  • Shares in the responsibility for protecting the integrity of the I&IT environment.

3.7. Concepts and definitions

3.7.1. Change prerequisites

Prior to logging and submitting a CRQ, the Change Requester must ensure the following:

  • Business approval has been secured
  • Funding approval (if applicable) has been secured.

These activities may be formalized in a service planning process or by an associated strategic (business-based) role.

3.7.2. Change jurisdiction/cluster

 It is important to understand when a change is applied to a cluster I&IT service and when a change is applied to an ITS I&IT service. The following table supports the determination of whether a change is being applied to a cluster or ITS service:

Criteria

Cluster I&IT service

ITS I&IT service

Service agreement

The I&IT service is delivered internally within a cluster and may be defined by a formal Operating Level Agreement (OLA).

The I&IT service is delivered by ITS and a Service Level Agreement (SLA) exists between one or more Clusters and ITS.

Configuration items/ownership

The  I&IT service  is defined  by solutions (I&IT component sets) and individual I&IT components that are owned and all technical elements (e.g. application code changes)  are managed by a cluster.

The I&IT service is  defined by systems (I&IT component sets) and individual I&IT components that are owned and all technical elements (e.g. firmware upgrades) are managed by ITS.

Accountability

A cluster is accountable for the day-to-day operational management and known state of the service, and all underlying components.

ITS is accountable for the day-to-day operational management and known state of the service, and all underlying components.

3.7.3 Risk levels

The risk level is used as a criterion to determine required approvals. The default risk level is level 1, which is the lowest level. The highest risk level is level 5. Risk assessment involves computing the overall risk based on risk related questions and the derived risk factors.

The Change Requester is responsible for answering the risk level questions and any concerns regarding the risk level should be directed to the Change Coordinator and the Change Manager as necessary.

The risk level questions incorporate both business and technical impact. The following are some general statements which expand on the setting of risk level:

Risk level 1 - minor change impacting less than 2 clusters and does not impact public facing or enterprise-wide services

Risk level 2 - significant change impacting less than 2 clusters and does not impact public facing or enterprise-wide services.

Risk level 3 - major change impacting less than 2 clusters and does not impact public facing or enterprise-wide services

Risk level 4 - minor change impacting 2 or more clusters and impacts public-facing or enterprise-wide services.

Risk level 5 - significant/major change impacting 2 or more clusters and impacts public-facing or enterprise-wide services.

  • Minor Change:  Minor changes are of low risk (i.e. risk of causing a service outage) and will have minimal impact.  These changes can be one or multiple jurisdictions can be approved by the eCM Change Manager rep.
  • NOTE: All public facing changes regardless of Risk level must be tabled at the CCAB.
  • Significant/Major changes are those that have the potential to impact either many users or a critical service, either as part of the change implementation or as a result of a high-risk change failure. These changes often encompass major projects or initiatives and are often cross-jurisdictional.

Changes are assessed at the discretion of the Change Manager following the initial Risk Level assessment. When the Risk Level is uncertain, the Change Requester may engage Change Management for assistance.  It is the responsibility of the Change Manager and/or Delegates to review/modify the initially submitted change assessment as part of the initial approval step of the eCM process to ensure that the Change Requester has correctly classified the change

3.7.4. Change class

The eCM process categorizes changes into the following classes:

  • Normal: a change that meets the required submission lead time and follows all the defined steps of the eCM process.
  • Standard: Low risk, relatively common change that follows a repeatable procedure or set of work instructions. Standard changes are “pre-approved” and therefore bypass the Approve Change for Implementation step in the change process. In order for a change to be established as a Standard Change, the Requester must provide historical evidence to CAB that proves the change meets the criteria of a successful precedent setting repeatable minor change.CAB can then designate that all future changes of this type can be treated as a Standard Change. In situations where a new or existing Standard Change needs to be approved or removed please refer to the eCM Process Procedures Guide (PPG).
  • Express Change: There are certain types of changes that like a normal change, require implementation approval from a Change Manager, however, resources required to implement the change have been engaged, and therefore the full “Normal change” lead time is not required.  In these scenarios, the resources involved have committed to assess and implement the change with less than the standard 5 business days lead time.  The Express change model addresses this scenario, in that, it allows for a change to follow the normal change lifecycle (including approvals from Change Management), but the lead time required is flexible, and the normal 5 business days lead time is not required.
  • Expedited: Utilized when a change does not meet submission lead times. Follows the full change request workflow under expedited timelines.  Expedited changes must be supported with a business justification to support the urgency/accelerated implementation time.
  • Emergency: Authorized by an ECAB, the change is driven by an Incident (e.g. break-fix).  Follows the full change request workflow under accelerated timelines.
  • Advisory: A change to non-OPS owned or managed infrastructure, a change on OPS owned or managed infrastructure that is consumed by a broader public sector agency, or a change used to communicate information to impacted Change Management stakeholders; it does not involve an implementation of any kind.  Advisory changes are “exempt” from OPS eCM Approve Change for Implementation step, but still require communication to Change Management stakeholders as well as identifying any risks, impacts and potential outages. In situations where an exception must be made, it should be discussed and approved through the eCM Change Advisory Boards (CAB).
  • Latent: A change that has already been implemented. Latent changes must have an Incident or through automation (to record a change after it has been implemented through an orchestration tool). 

3.7.5. Impact and urgency

A business and technical impact and urgency assessment  must be completed for all changes. While the accountability for change impact and urgency assessments rests with the Change Manager, it is a key responsibility of the Change Requester  who  completes the assessment  prior to  submitting their change.

Impact is the potential business vulnerability and measure of the effect the Change will have on the enterprise. Impact and urgency are used to assign a priority to the change.

The following are the values for Impact:

  • 1-Extensive/widespread:  There is significant business service impact because multiple customers are affected by the change. Considerable human and technical resources are needed. Management is involved in the decision process.
  • 2-Significant/large: There is clear service impact because at least one customer is affected by the change.
  • 3-Moderate/limited: There is little impact on current services because no customers are affected as a result of the change.
  • 4-Minor/localized: The change can be executed without prior approval from the Change Manager because no customers are affected by the change.

Urgency is an evaluation of the business impact of delaying the change. For example, an issue was discovered with the application that produces Statement of Remuneration Paid Tax Documents (T4’s) found during a mid-year audit. The impact is extensive/widespread; however the urgency in July is low.

The following are the values for urgency:

  • 1 - Critical: A full service outage of a critical system. System is non-operational. Urgent response.
  • 2 - High: A change that will resolve an issue(s) that disrupts a users' ability to do work or an issue that partially impacts a very important person or process. Quick response.
  • 3 - Medium: A change that will resolve an issue(s) that partially impacts the user’s ability to do work or one for which a workaround exists. Assistance is needed. Response as soon as possible.
  • 4 - Low: A change that will resolve an issue(s) that has no impact on users' ability to do work. Response is not critical.

3.7.6. Priority

Priority is a category that identifies the relative importance of a change. The following table details how Priority is determined based on the Impact and Urgency values.

Priority

Urgency: critical

Urgency: high

Urgency: medium

Urgency: low

Impact: extensive

Priority 1

Priority 1

Priority 2

Priority 4

Impact: significant

Priority 1

Priority 2

Priority 3

Priority 4

Impact: moderate

Priority 2

Priority 2

Priority 3

Priority 4

Impact: minor

Priority 2

Priority 3

Priority 3

Priority 4

3.8. Process workflow

The following diagram illustrates the end-to-end eCM process workflow:

Image of process flow. Full description available using link below.

Accessible description of infographic 1

3.9. Process workflow description

The following table provides content related to the inputs\triggers, description, output\completion criteria and common change record status for each process step in the eCM process workflow illustrated in the previous section.

When many roles are involved in a procedure task, the following abbreviations are used in order to fit the diagram on one page:

  • CR – Change Requestor
  • CC – Change Coordinator
  • CM – Change Manager  (includes Enterprise Change Management)
  • CA - Change Assessor(s)
  • CIMP – Change Implementer (person or persons involved in change implementation)
  • CAB – Change Advisory Board

No.

Task

Roles

Input, trigger

Description

Output, completion criteria

1.0

Log and classify change

CR

Trigger: business need for a change. change request

  • Change requester submits CRQ to eCM for consideration.
  • Expedited changes will follow the expedited process.
  • Business approval has been received prior to this point.

Change logged and classified

2.0

Approve change for assessment

CM

Input: logged change request

  • The CRQ is reviewed for accuracy and completeness, approved or rejected, processed, classified and prioritized.

Change approved Or rejected

3.0

Assess risk and impact and schedule change

CAB
CR
CC
CA
CIMP

Input: CRQ with planning in progress status

  • Identify and analyze business and technical risk and Impact of the requested change on the environment and impacted business(es).
  • Review of scheduled date for potential change conflicts.

Assessments completed

4.0

Approve change for implementation

CM

Input: build and test activities complete and satisfactory, signed off test plan

  • Change, including test results, implementation and backout plans, is reviewed by change.
  • Management and approval to           implement is provided.
  • Implementation date is finalized.

Change approved for implementation

5.0

Implement change

CR
CC
CA
CI

Input: approval to implement and implementation resources scheduled

  • Implementation of change in the production environment. back out performed if necessary.

Change implemented or backed out

6.0

Validate change success

CR
CC
CA
CIMP

Input: implemented change

  • The implemented change is monitored for a pre-determined period of time to ensure no undesired results or impacts.
  • Confirmation that change met requester objectives.

Change implemented or backed out

7.0

Conduct post
implementation
review

CM
CAB
CR
CC
CA
CIMP

Input:
implemented change

  • Review and document activities completed for the change.
  • Document opportunities for improvement and action items to facilitate improvements.
  • Communicate PIR results to impacted stakeholders.

Completed PIR

8.0

Close change

CM
CAB

Input: implemented and validated change

  • Update status reason for the change based on change validation results.
  • Close change.

Closed CRQ

3.10. Linkages to other processes

Process

Linkage

Enterprise service asset and configuration management

  • eCM uses the CMDB to access  changes  and  determine what services and/or stakeholders may be impacted by a proposed change.
  •  
  • Changes drive the creation, modification and/or retirement of CI and relationships in CMDB.
  • Enabling technology must define the relationship between changes and CIs.

Enterprise incident management

  • Incidents reported may drive the creation of change requests to resolve the issue reported.
  • Changes implemented, where issues are encountered, may drive the creation of an Incident.
  • Enabling technology must define the relationship between changes and incidents.

Enterprise Release management

  • Releases may involve the creation and management of various change requests to support the modification to, or launch of a new service.
  • Enabling technology must define the relationship between Changes and Release Records.

Enterprise Problem management

  • Changes – or specifically a pattern of issues identified through change implementation, may trigger the creation of a problem record.
  • Problem investigation may also trigger change requests to facilitate a fix for the problem.
  • Enabling technology must define the relationship between changes, problem records and known errors.

Enterprise Service level management

  • Changes may contribute to the measurement of SLAs.
  • SLAs may also drive the urgency of a CRQ.

Cyber Security Division

  • Security plays and overarching role for IT operations. Depending on the nature of the change; if it is as a result of vulnerability patching; or deferral reference to GO ITS 42 EVM is required.   For all other security related change reference to GO-ITS 25 is required.

3.11. Approvals

3.11.1. Approve change for assessment

  • The Approve Change for Assessment step of the process must be completed by an Enterprise Change Management Practitioner that represents the jurisdiction/portfolio that requested the change.   During this process step, the Change Management Practitioner reviews the change request for accuracy and completeness and may enhance the impacted areas section based on their knowledge of the environment. The Practitioner either approves (for assessment) or rejects the change and notifies the Change Requester

3.11.2. Approve change for implementation

Accountability for Change Approval resides with the member of the Enterprise Change management team for the Jurisdiction that is coordinating the change. Implementation of the change may require assistance of resources from another organization, in which case, authorization (via assessment task) will be required from that Jurisdiction’s Change Manager.

  • Authorization tasks are provided for all Change Managers with portfolios impacted by a Change. All Change Managers can action their authorization task in parallel.
  • For changes that impact two or more Clusters, the Corporate Change Advisory Board (CCAB) will offer an additional level of oversight.
  • Each Change Jurisdiction has a CAB that exists to provide input to the appropriate Change Manager in support of approving a change.

3.12. Due diligence for Change Coordinators

While a comprehensive set of criteria for due diligence on changes will be managed by the release management process, it is expected that the following criteria will be incorporated at the procedure level of each change management jurisdiction.

  • Build and test activities completed and signed off
  • Installation/production build procedures documented and tested
  • Post-installation test procedures documented and tested
  • Backout procedures documented and tested
  • Scheduled start and end dates and times confirmed
  • Implementation resources confirmed and contact information documented and communicated to the implementation team and the service desk
  • Communication of change, impact and service outage prepared and delivered to service desk, OPS and Clients
  • Training completed and delivered to service desk, OPS and clients
  • Supporting documentation created and/or updated
  • Component/service monitoring, alerting tested and complete.

3.13. Communication matrix

Effective communication of the status of the change to stakeholders at key points throughout the change lifecycle is essential to the success of eCM. The following table outlines when change communication should occur, to whom and how.

Process step

Communication target

Delivery mechanism

2.0 Approve change for assessment (communicate approval to assess the change)

  • Change Requester
  • Change Coordinator
  • Change Manager of impacted jurisdictions or appropriate eCM Practitioner
  • Change Assessors

Automated notifications

4.0 Approve change for implementation (communicate approval to implement the change)

  • Change Requester
  • Change Coordinator
  • Change Manager of impacted jurisdictions
  • Change Implementers

Automated notifications

4.0 Approve change for implementation (communicate approval to implement the change)

Business consumer of services

Email detailing service outage, timing, and impact to business consumer delivered via the service desk

5.0 Implement change (communicate change completion status – implemented, backed out)

  • Change Requester
  • Change Coordinator
  • Change Manager of impacted or appropriate eCM Practitioner.
  • Change Implementers
  • Change Assessors
  • Automated notifications
  • Email communications

3.14. Escalation protocol

3.14.1. Escalation process

Occasionally, situations will exist where a cluster (or clusters) and/or ITS do not agree with and cannot support a change approval decision or scheduled implementation date. In order to effectively deal with these situations, there must be a mechanism in place to ensure timely escalation and resolution. The following policy, process and procedures provide an outline of the activities contained within the eCM process for initiating and managing escalation situations.

The objective of the escalation is to ensure that the resources with the appropriate level of authority and accountability are assigned to move a dispute to an acceptable resolution.

3.14.2. Hierarchal escalation

In the event that a cluster, multiple clusters and/or the ITS organization are not satisfied with a decision rendered on a specific change, a request for escalation may be invoked to address their concerns. For each escalation, there will be a minimum of two recipients: one from the jurisdiction where the approval decision has been made, the other from the party disputing the decision. In the event that multiple jurisdictions oppose a decision rendered on a change request, there will still be one escalation notification, with additional primary recipients.

Escalations should be facilitated, at the first level, between Change Managers. Any Change Management stakeholder can initiate an escalation; however, they need to engage their jurisdiction’s Change Manager to validate/discuss an escalation request. The Change Manager is responsible for the formal initiation of the escalation process.

3.14.3 Escalation process

To invoke the escalation process, and for each subsequent escalation, the escalation initiator will provide all recipients with the following information:

  • Issue: a brief synopsis of the scope and impact of the change request, supported by additional documentation where applicable and available.
  • Escalation trigger: the trigger outlines the reason for invoking the escalation policy and/or subsequent escalations. it also provides a summary of previous escalation efforts.
  • Recommended actions: a list of recommended actions intended to promptly resolve the disputed change request.
  • Next escalation trigger: information about how, when and to whom the next escalation will be triggered.

3.14.4. Escalation guidelines

Hierarchal escalation

Trigger

Escalation Initiator

Escalation recipient

Informed

Method

Timing

Escalation 1

Unsatisfactory decision to approve or not approve a CRQ

Enterprise Change Practitioner

 Enterprise Change Practitioner for the Jurisdiction which holds the assessment/ approval

  •  Enterprise Change Practitioner (applicable jurisdiction, as well as the Enterprise Change Practitioners from each party disputing the decision)
  • Change Coordinator
  • Change Requestor

Written

 As soon as the non-approval decision is communicated

Escalation 2

No resolution within two (2) business days of escalation 1

 

 Enterprise Change Practitioner

  • Enterprise Change Practitioner
  • Change
    Coordinator
  • Change
    Requestor
  •  Process Owner

Writing - briefing note

At any time after two (2) business days with no resolution to escalation 1

Escalation 3

No resolution within five (2)  business days of escalation 2

Process Manager

 Process Owner

  • Change Manager
  • Change
    Coordinator
  • Change
    Requestor
  • Senior Management
  • Change Process Owner

Writing - briefing note

At any time after five (5) business days with no resolution to escalation 2

Note: a change will not progress while subject to an escalation.

3.14.5. Scenario: ITS initiated, single cluster impacted, ITS implemented

The following, “real-world” scenario is presented in order to help demonstrate the process.

The ITS organization has proposed a change to one of their services which will impact a single cluster (e.g. database hosting). After assessing the request for change, the impacted cluster Change Manager indicates that they do not authorize the change.

Despite the objection by the impacted cluster, ITS chooses to approve the CRQ. Finding this decision to be unacceptable for business reasons, the cluster Change Manager wishes to invoke the escalation process.

Following the escalation process:

  • The cluster Change Manager invokes the escalation process by issuing an escalation notice to service management senior management representatives of both ITS and the impacted cluster (escalation 1).
  • Either party may escalate the matter to the director level after two business days have elapsed without an acceptable resolution (escalation 2).
  • Either party may escalate the matter to the CIO level after five business days have elapsed without an acceptable resolution (escalation 3).

3.15. Post implementation review (PIR)

The conduct PIR step of the eCM process is intended to address the cycle of continuous service improvement by assessing the results of changes performed and investigating (at an appropriate level) the rationale/reasons why changes were unsuccessful. A PIR may investigate why a change is implemented without proper approval. It also is the mechanism whereby recommendations to prevent recurrence of unsatisfactory aspects of the change.

A detailed PIR shall be conducted for all changes causing a Critical or High Priority Incident. However, the extent and level of detail will be guided by the impact, significance, complexity and outcome of the change. Generally, Standard and Minor changes (Risk Level 1, 4) will be reviewed, reasons for failure or issues documented and closed; while more Significant changes (Risk Level 2, 3, 5) will require more scrutiny and rigout through a formal PIR.

The PIR process will be Managed by the Corporate Change Advisory Board (CCAB) Lead. The outcome of PIRs will be documented, reviewed at the CCAB and attached to the change record.

3.15.1. Objective

The objective of the PIR process is to ensure that changes deemed to have caused a negative impact to the process, end user or I&IT environment are analyzed and reviewed with the following goals:

  • Determine root cause
  • Investigate recommendations for improvement
  • Learn and capture that knowledge so that incidents of similar nature can be avoided or improve the assessment of future changes.

3.15.2. Conducting the PIR

The Enterprise Change Management team is accountable to ensure that an initial PIR for each Change Request causing an incident is conducted. For changes that cause a Critical or High Priority incident a detailed PIR must be conducted and for changes causing a medium or low priority incidents a “brief” PIR is required. The initial PIR will consist of a series of questions that would be used to influence a decision to proceed to a more formal, detailed PIR.

All participants involved in the specific change that is being reviewed must be prepared to contribute.

The outcome of a detailed PIR will be a standard, consistent report that includes:

  • Recommendations for process and/or procedure improvements
  • Recommendations for infrastructure and/or technology improvements
  • Lessons learned, translating into knowledge records.

3.16. eCM patterns

As part of building the eCM Contextual Model, several consistent patterns were identified that were reflective of the majority of changes typically processed across the OPS. For each of these patterns, the change jurisdiction and Change Coordinator jurisdiction have been identified. The following table provides a summary of the eCM patterns.

Pattern #

Initiated (Coordinator in most cases)

Who Impacted

Implemented By

Jurisdictional Assessment Approval

Jurisdictional Implementation Approval

1 Single Cluster

Cluster

Cluster

Cluster

eCM

eCM

2 Cluster and Enterprise Service Provider (ESP)

Cluster or ESP

Cluster, ESP

ESP, Cluster

eCM

eCM

3 Multi-Cluster/ Public facing

Cluster or ESP

Clusters, ESPs

Clusters or ESP

eCM

eCM

4 Single Enterprise Service Provider (ESP)

ESP

ESP

ESP

eCM

eCM

5 OPS change impacts BPS

OPS

OPS, BPS

OPS

BPS

eCM

6 BPS change impacts OPS

BPS

OPS and/or other vendors

BPS

OPS

BPS

  • NOTE: This model will be reviewed to ensure that there is appropriate governance and oversight for changes of this nature; as such, this model may be subject to change in the future.
  • The Enterprise Service Provider (ESP) provides an Enterprise service to another entity outside of their organization.  To be deemed an ESP, the service offering must be sanctioned as such by ITELC.  ITS and .NET are example of an Enterprise Service Provider.

Note: This model will be reviewed to ensure that there is appropriate governance and oversight for changes of this nature; as such, this model may be subject to change in the future.

3.16.1. Pattern # 1 (Single Cluster)

Initiated By

Who Impacted

Change Approval for Acceptance & Assessment

Change Jurisdiction(s) – Approval for Implementation

Implemented By

Cluster

Cluster

eCM

eCM

Cluster

Image of Pattern # 1 (cluster owned CIs – cluster IT services). Full description available using link below.

Accessible description of infographic 2

(cluster owned CIs – cluster IT services)

Initiated by

Who impacted

Change jurisdiction – approval for assessment

Change jurisdiction(s) – approval for implementation

Implemented by

Cluster

Single cluster

Cluster

Cluster

Cluster

3.16.2. Pattern # 2  (Cluster or Enterprise Service Provider (ESP))

Initiated By

Who Impacted

Change
Approval for Acceptance & Assessment

Change Jurisdiction(s) – Approval for Implementation

Implemented By

Cluster or ESP

Cluster, ESP

eCM

eCM

Cluster or ESP

Image of Pattern # 2 (cluster owned CIs – cluster IT services). Full description available using link below.

Accessible description of infographic 3

3.16.3. Pattern # 3  (Multi-Cluster/Public Facing)

Initiated By

Who Impacted

Change Approval for Acceptance & Assessment

Change Jurisdiction(s) – Approval for Implementation

Implemented By

Cluster or ESP

Cluster(s), ESP(s)

eCM

eCM

Cluster or ESP

Image of Pattern # 3 (ITS owned CIs – ITS IT services). Full description available using link below.

Accessible description of infographic 4

3.16.4. Pattern # 4 (Single Enterprise Service Provider)

Initiated By

Who Impacted

Change Approval for Acceptance & Assessment

Change Jurisdiction(s) – Approval for Implementation

Implemented By

ESP

ESP, Cluster

eCM

eCM

ESP

Image of Pattern # 4 (ITS owned CIs – ITS IT services). Full description available using link below.

Accessible description of infographic 5

3.16.5. Pattern # 5  (OPS - Impacts BPS)

Initiated By

Who Impacted

Change Jurisdiction – Approval for Assessment

Change Jurisdiction(s) – Approval for Implementation

Implemented By

OPS

BPS

eCM

eCM

OPS

Image of Pattern # 5 (ITS Owned CIs – Cluster IT Services). Full description available using link below.

Accessible description of infographic 6

3.16.6. Pattern # 6 (BPS - Impacts OPS)

Initiated By

Who Impacted

Change Jurisdiction – Approval for Assessment

Change Jurisdiction(s) – Approval for Implementation

Implemented By

BPS

OPS

BPS, OPS

BPS

BPS

Image of Pattern # 6 (ITS owned CIs – ITS IT services). Full description available using link below.

Accessible description of infographic 7

3.17. Process quality control

In parallel to the execution of the eCM process, there are activities related to the management of the process to control quality as well as to ensure that the process is both effective and efficient.

Monitoring of the effectiveness of the j Enterprise change management process is performed regularly by the eCM Process Manager. This allows the eCM Process Manager to answer any questions about service quality and customer satisfaction. The eCM Process Manager is responsible for taking corrective actions if bottlenecks are identified in the process.

Reporting involves measuring the process via metrics and recording how well it behaves with respect to its metrics. It provides eCM stakeholders with feedback on the process. It provides the eCM process owner with the necessary information to review the process performance and initiate required improvements.

This also includes operational reporting, such as the generation of the FSC.

Evaluating the process involves regular reviews of the performance of the process and identification of possible improvements or actions to address performance gaps. Every process is only as good as its last improvement; hence, the feedback loop of continuous improvement is essential to every process.

The eCM Process Manager is accountable for these quality control and continuous improvement supporting activities. .

3.18. Common process metrics

Metrics are intended to measure the effectiveness and efficiency of a process. Metrics are also required to support strategic decisions. The following received careful consideration:

  • Reporting metrics should be readily measurable (preferably automated collection and presentation of data)
  • Metrics need to be chosen to reflect process activity (how much work is done?), process quality (how well was it done?) and process operation (to review and plan job on hand).

The following common metrics are utilized in the eCM process:

  • Volume of Changes Approved for Assessment– Impacted vs. Coordinated
  • Number of  changes planned vs actual implemented during period
  • Average turnaround time of changes
  • Number and percentage of changes by reason
  • Number and percentage of changes backed out by reason
  • Number of incidents resulting from change
  • Number and percentage of change by priority
  • Number and percentage of change by risk and impact category
  • Number and percentage of change by product category
  • Number and percentage of cancelled changes
  • Number and percentage of changes back-logged
  • Total change management effort in person-hours
  • Total change implementation effort in person-hours
  • Number and percentage of successful/unsuccessful changes.
  • Volume of Changes Implemented – Impacted vs. Coordinated
  • Percentage of Planned, Expedited and Emergency Changes
  • Percentage of Changes Implemented Without Approval
  • Percentage of Latent Changes
  • Percentage of Successful Changes
  • Percentage of Changes that have Caused Incidents

3.19. Standard process parameters

Parameters used for the classification, categorization, prioritization and closure of changes require a certain level of standardization across the OPS. Special attention needs to be given to parameters related to the consistency of reporting. This is particularly important for the provision of reliable business intelligence.

Please refer to the Classification Model section of the GO-ITS 44 ITSMTerminology Reference Model  for standard process parameters and allowable values for eCM.

Please refer to the State Model section of the GO-ITS 44 ITSMTerminology Reference Model  for standard status/state parameters and their definitions for eCM.

4. Related standards

4.1. Impacts to existing standards

GOIT standards and how they are impacted by the GO ITS 35 standard. There is no impact to the GO ITS 37 - Enterprise incident management standard. The GO ITS 36 Enterprise service and configuration management standard is being updated in parallel and will reflect process linkages described above. The GO ITS 44 ITSMterminology reference model standard is being updated in parallel and will reflect process linkages described above.">

GO IT standard

Impact

Recommended action

GO-ITS 37 – enterprise incident management

No impact

N/A

GO-ITS 36 - enterprise service and configuration management

This standard is being updated in parallel and will reflect process linkages described above.

N/A

GO-ITS 44 - ITSMterminology reference model standard

This standard is being updated in parallel and will reflect process linkages described above.

N/A

4.2. Impacts to existing infrastructure

GOIT standards and how they are impacted by the GO ITS 35 standard. There is no impact to the GO ITS 37 - Enterprise incident management standard. The GO ITS 36 Enterprise service and configuration management standard is being updated in parallel and will reflect process linkages described above. The GO ITS 44 ITSMterminology reference model standard is being updated in parallel and will reflect process linkages described above.">

Impacted infrastructure

Impact

Recommended action

Not applicable

N/A

N/A

5. Compliance requirements

In order to manage the effectiveness of this standard, ministry, clusters and applicable agencies are expected to adopt and monitor compliance.

6. Roles and responsibilities

Accountable role (standard owner) definition

The individual or committee ultimately accountable for the process of developing and maintaining this standard. Where a committee owns the standard, the committee chair is accountable for developing the standard including future updates. There must be exactly one accountable role identified.

Accountable role:

Title: Chair, Service Management Executives Committee (SMX)

Responsible role definition

The organization(s) responsible for the development of this standard. There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization(s) provides the resource(s) to develop the standard).

Responsible organization(s):

Ministry:  Ministry of Government and Consumer Services (MGCS)
Division:  Infrastructure Technology Services (ITS)
Branch:  Service Management Process & Operations

Support role definition

The support role is the resource(s) to whom the responsibility for developing and maintaining this standard has been assigned.

Support role (editor):
Ministry: MGCS
Division: ITS
Branch: Service Management Process & Operations
Section: ITSMProcesses
Job Title: Senior Manager
Name: Arpad Martonosi
Phone: 519-830-6431
Email: Arpad.Martonosi@ontario.ca
Delegate:
Name: Robin Aklu (eSM Process Manager)
Phone: 416-319-5930
Email: robin.aklu@ontario.ca

7. Consultations

Areas consulted as part of the development of this standard. Include individuals and committees, councils and/or working groups:

Organization consulted (ministry/I&IT cluster)

Division

Branch

Date

Enterprise Change Management Community of Practice (COP)

ITS

Process and Operations

January 28, 2020

Stakeholders/ Subject Matter Experts (SME) Peer Review

 
  • CAC:  Patty Ma
  • Cyber Security:  Cornel Carbureanu + Michael Savo 
  • GSIC:  Stephen Martin, Amy Wang
  • JTS:  Anna Lisandro
  • LTC:  Mandip Singh
  • LRC:  Mike Spaans

 February 12, 2020

 Practice Standards Working Group (PSWG)

ITS

CAC- Enterprise Architecture and Standards Branch
ITS - Service Management reps.

March 6, 2020

 Senior Management Team (SMT)

ITS

Service Management

 March 18, 2020

 Service Management Executives (SMX)

Multi-ORG

 Service Management

 March 19, 2020

8. Appendices

8.1. Normative references

eCM Change Manager will determine if procedures are a normative or informative reference and how they will be managed/evolved.

Note:  a normative reference specifies a supporting document or GO IT Standard (in the case of the Government of Ontario’s I&IT infrastructure, often another OPS I&IT authorized publication) that must be read to fully understand or implement the subject matter of the main GO IT Standard. Such authoritative or de facto references may be external and may, or may not be, owned/controlled by the GO IT Standard owner.

8.2. Informative references

Not applicable.

Note: an informative reference is not normative; rather, it provides only additional background information.

8.3. Differentiation: process, procedure, work instruction

Image of differentiation: process, procedure, work instruction. Full description available using link below.

Accessible description of infographic 8

  • Level 1 tasks are defined in a process. They specify what action must be taken and who is involved.
  • Level 2 tasks are defined in procedures which decompose each level 1 task into more granular operational tasks, and additionally, prescribe how the activity should be performed.
  • Level 3 tasks represent work instructions. Work Instructions are a further decomposition of procedure-level tasks which typically are defined to address any unique local requirements when performing a procedural task, such as a using a specific distribution list for communications.

8.4. Procedural localization guidelines

The standard content applies to all organizations and groups within the OPS. Procedural localization involves adding group-specific information that applies to a particular organization or group. For every group, local content will focus on what’s important for the particular environment.

The process standard expresses the what and the who (role) in terms of enabling eCM. Procedures define the detailed how and who (role) in support of the process. For example, the process identifies that changes are assessed for impact and risk, and expresses accountabilities in the RACI matrix (what and who). Procedures for change assessment will define specific steps required, the how, and specific roles that will perform these activities, the Who, within the constraints of the standard. Procedures allow for organization-specific activities. HSC, for example, may need to perform certain activities in accordance with regulatory standards, when implementing changes (e.g. addressing sensitivity to citizen data). The process of implementation will remain consistent for all stakeholders, but the HSC procedures may require additional steps and, in some cases, include specific roles for implementation (e.g. privacy auditor).

Local procedures are anticipated to address business or organization-specific requirements not prescribed within the standard process. Localization is not a modification to the process; as such a modification would result in a fractured process model that only applies under certain circumstances. Localization is the creation of procedures that support the process and ensure the process outcomes are achieved through the definition of additional detail that supports and aligns to the process standard.

The standard content will always apply to all localizations; local procedure guides are expected to be more granular and organization specific.

8.4.1. Localization principles

  • ITIL- the OPS implementation of ITSM represent our reference framework for guidance on best practices
  • Inter-relationships with other ITSM processes and their procedural localizations should be considered.

8.4.2. Local procedure guide content

All process standard content plus:

  • Local operational principles, guidelines and activities
  • Business-specific standards (e.g. HIPPA)
  • Additional roles and responsibilities that augment but do not replace or deviate from the standard roles and responsibilities
  • Local procedures (such as escalation and line of business communications)

8.5. Contextual Model diagram

Image of Contextual Model diagram. Full description available using link below.

Accessible description of infographic 9

Vision – a consistent eCM process across the enterprise.

Mission – to work collaboratively across the enterprise to identify and address eCM and change control gaps (both process and technology) and define an integrated eCM common frame of reference across the enterprise by which all IT changes (including infrastructure and applications) are governed, assessed, controlled, approved, communicated and measured.

The eCM Contextual Model addresses the following:

  • Simplifies and streamlines eCM while ensuring the appropriate level of diligence is applied to assessments and approvals
  • Ensures the risk and impact of proposed changes is appropriately considered
  • Ensures the right people are involved and notified when changes are assessed, approved and completed
  • Ensures effective communication of change status to relevant parties throughout the change lifecycle
  • Provides checks and balances to ensure changes are implemented successfully and in a timely manner.

The goals of eCM are as follows:

  • Single source of change record information across the enterprise
  • Single approval provided by the appropriate enterprise Change Management Practitioner 
  • Risk and Impact Assessment activities and Implementation activities documented and linked as part of the Change Record
  • Change status awareness throughout the lifecycle
  • Standardized Process Performance Reports

9. Glossary

Term

Definition

Change

From an eCM scope perspective, a change is a modification to a CI in the Production I&IT environment including:

  • Hardware and Software (HW/SW) components,
  • Services and service components,
  • Production support documentation (e.g. service desk knowledge records, operations procedures)
  • eSACM data relating to any of the above.

A change is required to modify any of the following CI attributes:

  • Capacity
  • Functionality
  • Scope
  • Availability
  • Data

Change request

 (CRQ)

Change Manager (CM) role or Enterprise Change Practitioner (eCP)

The physical record of the change in the change management system. A CRQ will transition through various states throughout its lifecycle.

The individual(s) fulfilling this role, is responsible for ensuring compliance to the eCM process through the review and approval of Change Requests (CRQ)s. For the purpose of this document, reference to the Change Manager may equate to either the eCM Process Manager or the appropriate Enterprise Change Practitioner (eCP) rep fulfilling an ITIL role.  

Implementation date

Date when change will be implemented. There are several ‘views’ of this date during the lifecycle of a change:

  • Requested date refers to the implementation date identified on the original change submission.
  • Scheduled date refers to the date that the change is being assessed for implementation for – this date may change through the lifecycle of the change, however once the change is approved, the scheduled date represents the change window under which the change activities can take place.
  • Actual date refers to date on which the change was implemented. This may vary from the “scheduled” date, based on when the actual implementation work was completed, however, it should align with the scheduled date.

Incident

Any event, not part of the standard operation of a service or component, which causes, or may cause, an interruption or reduction in quality of service

Formal name = incident – service interruption, with three subtypes:

  • Service interruption – fault
  • Service interruption – degradation
  • Service interruption – security

IVB

Refers to the  Implementation, Verification and Backout instructions contained in the Method of Procedure (MOP) plan.

Work order

BPS

A request for some type of action to be undertaken, related to an existing production service, e.g. information request, user account: add, delete, modify.

Formal name =  incident - work order (with multiple subtypes)

A work order has the following characteristics:

  • No impact to existing service (capacity, scope, functionality, availability)
  • Repeatable
  • Procedure based
  • An SLA exists to defines entitlement and response target.

Note: a work order may have originally been a standard change, which, after being processed under the eCM process, was subsequently approved for processing as a work order.

Refers to the “Broader Public Sector” refers to the organizations that receive funding from the Government of Ontario. They are not, however, a part of the government itself. Examples of BPS organizations include hospitals, universities, colleges, and school boards, Elections Ontario, LCBO etc.

Infographic Descriptions

Infographic 1: End-to-end eCM process workflow

Step 1.0 - change requestor logs and classifies the change
Step 2.0 - Change Manager approves the change for assessment
Step 3.0 - change requestor, Change Coordinator, change assessor, change implementer, and CAB (if applicable) fulfill their responsibilities associated with assessing the risk and impact, and scheduling the change
Step 4.0 - The Change Manager will approve the change for implementation
Step 5.0 - change requestor, Change Coordinator, change assessor, and change implementer fulfill their responsibilities associated with implementing the change
Step 6.0 - change requestor, Change Coordinator, change assessor, and change implementer fulfill their responsibilities associated with validating the change
Step 7.0 - Change Manager, CAB (if applicable), change requestor, Change Coordinator, change assessor, and change implementer fulfill their responsibilities associated with conducting the post implementation review
Step 8.0 - Change Manager will close the change. Note: for changes classified as standard, step 4.0 is skipped. The change will go from 3.0 assess risk and impact and schedule change to 5.0 implement change

Infographic 2: Pattern # 1 (Single Cluster)

Step 1.0 - cluster logs and classifies the change
Step 2.0 - eCM approves the change for assessment
Step 3.0 - cluster assesses the risk and impact, and scheduling the change
Step 4.0 - eCM will approve the change for implementation
Step 5.0 - cluster will implement the change
Step 6.0 - cluster will validate the change
Step 7.0 - eCM will conduct the post implementation review
Step 8.0 - eCM will close the change

Infographic 3: Pattern # 2 (Cluster or Enterprise Service Provider (ESP))

Step 1.0 - cluster or ESP logs and classifies the change
Step 2.0 - eCM approves the change for assessment
Step 3.0 - eCM and cluster or ESP assesses the risk and impact, and scheduling the change
Step 4.0 - eCM approves the change for implementation
Step 5.0 - cluster or ESP implements the change
Step 6.0 - eCM and cluster or ESP validates the change
Step 7.0 - eCM conducts the post implementation review
Step 8.0 - eCM closes the change

Infographic 4: Pattern # 3 (Multi-Cluster/Public Facing)

Step 1.0 - cluster or ESP logs and classifies the change
Step 2.0 - eCM approves the change for assessment
Step 3.0 - eCM and cluster or ESP assesses the risk and impact, and scheduling the change
Step 4.0 - eCM approves the change for implementation
Step 5.0 - cluster or ESP implements the change
Step 6.0 - eCM and cluster or ESP validates the change
Step 7.0 - eCM conducts the post implementation review
Step 8.0 - eCM closes the change

Infographic 5: Pattern # 4 (Single Enterprise Service Provider)

Step 1.0 - ESP logs and classifies the change
Step 2.0 - eCM approves the change for assessment
Step 3.0 - eCM and cluster and ESP assesses the risk and impact, and scheduling the change
Step 4.0 - eCM approves the change for implementation
Step 5.0 - ESP implements the change
Step 6.0 - eCM and cluster and ESP validates the change
Step 7.0 - eCM and cluster and ESP conducts the post implementation review
Step 8.0 - eCM closes the change

Infographic 6: Pattern # 5 (OPS - Impacts BPS)

Step 1.0 - OPS logs and classifies the change
Step 2.0 - eCM approves the change for assessment
Step 3.0 - OPS and BPS assesses the risk and impact, and scheduling the change
Step 4.0 - eCM approves the change for implementation
Step 5.0 - OPS implements the change
Step 6.0 - OPS and BPS validates the change
Step 7.0 - eCM conducts the post implementation review
Step 8.0 - eCM closes the change

Infographic 7: Pattern # 6 (BPS - Impacts OPS)

Step 1.0 - BPS logs and classifies the change
Step 2.0 - BPS and OPS/eCM approves the change for assessment
Step 3.0 - BPS and OPS/eCM assesses the risk and impact, and scheduling the change
Step 4.0 - BPS and OPS/eCM approves the change for implementation
Step 5.0 - BPS and OPS/eCM implements the change
Step 6.0 - BPS and OPS/eCM validates the change
Step 7.0 - BPS and OPS/eCM conducts the post implementation review
Step 8.0 - eCM closes the change

Infographic 8: Differentiation: process, procedure, work instruction

Hierarchical chart differentiating between process, procedure and work instructions

Level 1 process defined in standards. This includes approve change for implementation.

Level 2 procedure. This includes: confirm final scheduled implementation date, approve change for implementation, approve implementation (risk level 4 or 5), etc.

Level 3 work instructions/localized procedures. This includes work instructions for clusters e.g. HSC, CAC, etc.

Infographic 9: Contextual Model diagram

The Contextual Model diagram shows the process at a high-level and then shows the relationship that the system has with stakeholders. Generic process flow:

  1. Log and classify change
  2. Approve for assessment
  3. Assess risk and impact and schedule change
  4. Approve for implementation
  5. Validate change
  6. Conduct PIR
  7. Close change

The business drivers are:

  • service planning
  • projects
  • legislation/standards
  • vendors
  • broader public sector
  • security
  • preventative maintenance/refresh activities
  • problem management.

Next, there is the change requestors who can be:

  • service owners
  • project managers
  • customer account representatives
  • third-party provider representatives
  • external resources (IO, BPS)
  • security analysts
  • operational/service management staff
  • client/business representatives

Next, there is the Change Coordinator who has overall accountability followed by the assessment phase where the change assessors will assess the risk and impact.

Next, there is the approving jurisdictions who can be the following:

  • corporate - an infrastructure or application/solution change that has the potential to impact more than one cluster, and Enterprise service or is public facing will be reviewed as a corporate change.
  • cluster - a solution/application change that will only impact one cluster, and does not require changes to infrastructure components will be managed as a single cluster change.
  • service provider (SP) - an infrastructure change that does not impact any clusters or one that may only impact a single cluster will be managed as an SP change.

Next, using due diligence, there is the Change Manager who provides approval followed by the supporting roles:

  • change builders/testers
  • and change implementers.

Finally, the diagram lists the following benefits:

  1. Clear accountability:
    • 1 change record
    • 1 change Coordinator
    • 1 change jurisdiction
    • approvals from impacted jurisdiction
    • 1 OPS schedule of I&IT changes
  1. Cross jurisdictional collaboration:
    • assessment across multiple organizations
    • corporate, cluster and ITS approvals implementers from ITS and the clusters
    • end-to-end post implementation review conducted