GO-ITS 240PRS Enterprise Release Management

1 Introduction

Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the IT standards adopted through the Office of the Corporate Chief Information Officer (OCCIO) and IT Executive Leadership Council (ITELC) for use across the government’s information and information technology (I&IT) infrastructure.

These publications support the responsibilities of the Treasury Board Secretariat for coordinating standardization of I&IT in the Government of Ontario. In particular, GO-ITS explain when an IT standard is mandatory and outline any conditions that apply to its implementation.

2 Summary

2.1 Standard name and description

This standard defines the technical requirements for the IT Service Management practice called Enterprise Release Management, based on the Information Technology Infrastructure Library (ITIL) framework.

2.2 Background and rationale

The GO-ITS 240PRS Enterprise Release Management (eRM) standard was primarily created to protect the production environment and its services. eRM helps ensure that IT solutions or service projects are successfully released to production and that post-implementation support is in place across the end-to-end I&IT supply chain. For each release, eRM acts as a guide, facilitator, coordinator and checkpoint gatekeeper.

In line with the Information Technology Infrastructure Library 4 (ITIL 4), GO-ITS 240PRS Enterprise Release Management includes more details about the Deployment Coordination Service (known as the Deployment Management Technical Management Practice in ITIL V4). It also clarifies the difference between the Service Management Readiness (known as the Release Management Service Management Practice in ITIL V4) and the Deployment Coordination Service.

Service Management Readiness (SMR) focuses on the planning, execution and overseeing the operational support activities needed to activate or decommission IT solutions or services in production. SMR confirms that the IT Service Owner is operationally ready.

Deployment Coordination Service (DCS) focuses on planning, executing and overseeing the deployment, migration or decommissioning of IT hardware or software into or from the production environment. DCS confirms that new or enhanced IT solutions or services are implemented with minimal disruption to production operations.

Distinguishing between SMR and DCS also aligns with ITIL’s integration with DevOps software development practice, which brings together software development and information technology operations to shorten the systems development lifecycle while delivering features, fixes and updates frequently in close alignment with business objectives.

2.3 Target audience

This standard is intended for staff in the following areas within the OPS:

• Infrastructure, Technology and Operations Division (ITOD).
• I&IT Clusters.

2.4 Scope

eRM aims to plan, schedule and control the testing and deployment of application and infrastructure releases into production. The goal of the Enterprise Release Management process is to support planning, communication, coordination and execution of release and deployment activities between stakeholders to ensure the integrity of the production environment and that post-implementation support is in place across the end-to-end I&IT supply chain.

eRM also ensures a formal handover to Operations and that training and documentation are available to support ongoing service delivery.

2.4.1 In scope

• Updates or changes that impact end users.
• Activities to build operational support structures.
• Changes or modifications to existing I&IT infrastructure, solutions or services.
• Implementation of new or decommissioning of existing I&IT infrastructure, solutions or services.

2.4.2 Out of scope

• Updates or changes that do not impact end users.
• Identifying operational support teams and defining operational processes.
• Project-related change management activities.
• Project Management activities such as technical build, test, certification and non-production deployment.

2.4.3 When to engage Enterprise Release Management

• SMR
  • Use SMR for any new or significant change to an application or service that requires support from the OPS Service Centre (OPSSC).
• DCS
  • Use DCS for any changes or modifications to existing or new I&IT infrastructure, solutions or services that need deployment coordination and client validation.

2.4.4 How to engage Enterprise Release Management

Service Planning and Intake Management SPIM reviews new projects and determines when SMR and DCS is required based on the criteria in 2.4.3, When to engage Enterprise Release Management..

For DCS, the Enterprise Change Management process assesses any new changes to confirm if DCS should be involved to assist with coordination.

2.5 Applicability statements

Compliance with this standard is mandatory.

The standard must be used along with any other relevant requirements related to governance, management, digital services, information and data assets that are outlined in Ontario Government directives, policies, standards, memorandums of understanding (MOUs) and service level agreements (SLAs).

This standard applies to Ontario ministries and provincial agencies that use IT services or products from the Ontario Public Service (OPS) or seek technology investment approval/procurement approval from Treasury Board or Management Board of Cabinet.

2.5.1 Organization

All Ministries and I&IT Clusters must follow Government of Ontario IT Standards.

All adjudicative and advisory agencies are subject to Government of Ontario IT Standards.

Other agencies that use OPS information and information technology products or services must comply with Government of Ontario IT standards if required by the Governance and Management of Information Technology Directive or Government of Ontario IT Standards by memorandum of understanding.

For the purposes of this standard, any reference to Ministries or the Government includes applicable agencies.

As new GO-ITS are approved, they are deemed mandatory on a go-forward basis (go-forward basis means at the next available project development or procurement opportunity).

When implementing or adopting any Government of Ontario IT standards or IT standards updates, Ministries, I&IT Clusters and applicable agencies must follow their organization’s pre-approved policies and practices to ensure proper change control, change management and risk mitigation mechanisms are in place and employed.

2.5.2 Requirement levels

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

Must, REQUIRED or SHALL — indicates that the statement is an absolute requirement.

Should or RECOMMENDED — means that there may be valid reasons in some circumstances to ignore the recommendation, but the impact (such as business functionality, security, cost) must be understood and carefully considered.

3 Technical specification

The following requirements apply to all I&IT assets and operations within the scope of the Governance and Management of Information Technology Directive.

3.1. Process definition

The eRM process works to ensure I&IT infrastructure, solutions and services are successfully released to production and that post-implementation support structures are in place across the end-to-end I&IT supply chain.

3.2. Process purpose

The purpose of eRM is to provide value to the customers by minimizing the risk of releasing to production new or changed I&IT infrastructure, solutions or services and ensure it meets or exceeds agreed upon service levels.

Key objectives of eRM include:

• defining and agreeing on release activities and plans with customers or stakeholders
• considering both technical and non-technical aspects when creating or changing an IT service
• deploying changes in a way that protects the environment’s integrity and establish effective use of service to delivery
• improving consistency in how IT services are delivered, leading to higher quality, lower risk and better use of resources
• managing, tracking and verifying changes during deployment, including the ability to reverse a release if needed
• recording and manage deviations, risks, issues related to the new or changed infrastructure, solution or service, and take necessary corrective action
• ensuring that skills and knowledge are transferred to operations and support staff to enable them to deliver, support and maintain the infrastructure, solution or service, according to required warranties and service effectively and efficiently levels
• improving the service management process across the I&IT organization

3.3. Value to the business

The implementation of the eRM process provides oversight of changes to IT solutions or services. It helps ensure the implementation is in accordance with other ITSM processes and aligned with business needs. eRM also supports successful activations by ensuring effective pre-operation communications between all groups involved in IT solution or service projects.

eRM provides value to the organization in the following ways:

Risk reduction

• Ability to manage a higher frequency of releases without sacrificing IT service quality.
• Opportunity to test or pilot changes before launch.
• Assurance that services are operationally ready — supportable, measurable and reportable.
• Enhanced agility and flexibility to respond positively to risk demands during a deployment due to multiple parties operating the release.
• Increased collaboration through information sharing and instant communication.
• Better awareness and advanced communications of upcoming releases.

Cost reduction

• Greater stability in production environment through testing.
• Fewer incidents caused by a poor release.
• More efficient and effective use of resources by following best practice process.

Service quality improvement

• Collaterals needed for releasing IT solution or service projects.
• Faster delivery time of services through shorter release cycles.
• Higher success rate of releases with minimal service disruptions while maintaining IT service quality through a unified and controlled release process.
• Improved input into IT service descriptions.
• Better information on how IT Services are measured.

3.4. Basic concepts

eRM plans, schedules and controls how releases move into the production environment. The goal is to protect the stability of the production environment and ensure that only the correct and approved components are deployed.

3.4.1. Inputs to the process

Inputs to the eRM process include:

• Service Planning and Intake Management (SPIM).
• Release Management Assessment Task within eSMT Change Management Module (Change Request or CRQ).
• Service Management Customer Awareness Forum Exchange (SM – CAFE).
• Release Planning Committees.
• Service Management Engagement & Integration (SMEI).

3.4.2. Outputs from the process

Outputs from the eRM include:

• Release plan or Service Activation Checklist.
• Method of Procedure (MoP).
• Release Announcement.
• Go / No-Go decision.
• deployment coordination and communications.
• satisfied experience for clients.

3.5. Process principles

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

All releases will promote and adhere to existing Information Technology Service Management (ITSM) Standards, Policy and Procedure Guides (PPG) for all services or solutions being released into the production environment.

Rationale

• Adopts common frameworks and standards.
• Ensures consistency and manageability of production services during a release.
• Effective execution of all ITSM processes requires consistent communication of procedures and requirements.
• Avoids rework.

Implications

• Requires adherence and integration to existing GO-IT standards

Principle 2

A single Release Repository will be used to track and manage information for each release and store all supporting documentation.

Rationale

• Protects accuracy of information by:
  • ensuring that only authorized roles can update information
  • enabling View or Read Only access
• Provides traceability and auditability of releases to the production environment
• Ensure accountability for approvals for production
• Reporting on release information needs to be accurate and consistent

Implications

• Users will be required to submit a service request with the appropriate approvals to obtain access to the Release Repository.
• The Release Repository must be capable of linking release information with other ITSM process records (for example, Incidents, Known Errors, Change Requests, Configuration Items, and more).

Principle 3

Each Release will be categorized using predefined values for its Impact, Urgency and Priority.

Rationale

• Allows release and release components to be accurately recorded and tracked.
• The release impact, urgency and priority categorization will define the level of work effort involved and estimated timelines for completion.
• For DCS, the release impact, urgency and priority will align with the related Change Request (CRQ).

Implications

The release impact, urgency and priority values may change during the project lifecycle if the scope of the project changes

Principle 4

Each release will progress through the following milestones during the Release Lifecycle: Initiate, Planning, Build, Test, Deployment and Close down.

Rationale

• Provides visibility and communication of progress to stakeholders.
• Allows for a repeatable process and consistency from release to release.

Implications

• Deliverables for each stage in the Release Lifecycle will need to be defined with relevant Stakeholders.
• Release management activities and deliverables will need to be formally documented, managed and available to relevant Stakeholders.

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 and may also be applied at local levels of eRM. 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 eRM process activities, including other ITSM process 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".

3.6.1. Service management readiness (SMR) activities

Legend:
R – Responsible                
A – Accountable                
C – Consult Before                
I – Informed After Implementation

3.6.2. Deployment coordination service (DCS) activities

Legend:
R – Responsible                
A – Accountable                
C – Consult Before                
I – Informed After Implementation

3.6.3. eRM process owner

The eRM 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 ITSM processes being used and or adopted in the OPS. The Process Owner shall be accountable for the overall health and success of the process and shall be responsible for the approval of all proposed changes to the process and development of process improvement plans.

Accountabilities

• Ensures that the process is defined, documented, maintained and communicated at an Organizational level through appropriate channels.
• Owns the Release Management lifecycle across the enterprise for multiple applications across various portfolios.
• 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 the process requirements are developed, documented and implemented with enabling technology.
• Defines and evolves enterprise process KPIs and reporting for the process.

3.6.4. eRM Release Manager

The Release Manager is accountable for planning, implementing and managing the ongoing execution of the process, managing the operation of the Release Repository, and directing the activities of all I&IT infrastructure, solution and service projects that participate in eRM.

Accountabilities

• Develops, implements and maintains Enterprise Release Management procedures.
• Interfaces and communicates with I&IT Clusters and ITOD OPS Management teams.
• Identifies functional requirements for the Release Repository in conjunction with other ITSM Process Managers; conducts acceptance testing for modifications to enabling technology.
• Provides leadership and direction to the enterprise release management team.
• Assigns release management work to Release Coordinators and ensure deliverables are completed in line with established Release Management policies and procedures.
• Obtains support for new or changes to existing eRM procedures; ensures that changes to the eRM procedures are properly approved and communicated to staff before being implemented; plans, publicizes and manages implementation of any new Release Repository.
• Ensures staff are trained.
• Proposes and/or agrees on procedural interfaces with other ITSM process managers and operational managers.
• Develops and produces reports, including process health metrics, operational management reports and deployment statistics and including an analysis of the results to identify issues and make corresponding recommendations to address them.
• Builds enterprise release calendars while working closely with management from different portfolios to centralize the view of current and future releases.
• Assesses and determines risk to applications through assessment tasks within Change Requests.
• Assists auditors to audit the operational activities of the eRM process for compliance with current procedures; ensures that recommended corrective action is carried out.
• Receives release requests, confirms scope and type and assigns a Release Coordinator if required.

3.6.5. Release Coordinator – Service Management Readiness (SMR)

The Release Coordinator role within SMR is defined to assist the Release Manager in undertaking the following responsibilities:

Accountabilities

• Initiate
  • Validate scope, priority, impact and urgency of a release based on the Opportunity Assessment completed by intake.
• Planning
  • Update Release Repository accordingly.
  • Create Release Plan.
  • Create Release Announcement.
• Build
  • Create, schedule and facilitate Release Kick off to review scope, timelines and tasks with core team.
  • Validate release plan and specific deliverables with Stakeholders.
  • Develop milestones, manage tasks and issues.
  • Facilitate status meetings.
  • Collect all Stakeholder collateral.
  • Validate release checklist readiness of all Stakeholders.
  • Update Release Repository accordingly.
• Test
  • Coordinate End-to-End Testing (as required).
  • Develop Release Go/No-Go presentation.
  • Facilitate Release Pre-Go/No-Go (as required).
  • Facilitate Go/No-Go Prepare and send Go/No-Go decision communication.
  • Update Release Repository accordingly.
• Deployment
  • Monitor or track Post Activation Items during Release stabilization period.
  • Facilitate any stabilization efforts.
  • Update Release Repository accordingly.
• Close down
  • Ask Project Manager and Service Owner to approve that all release activities are complete and provide feedback about release process.
  • Communicate any release process improvement to Release Process Owner.
  • Validate all data in Release Repository is correct.

3.6.6. Release coordinator – Deployment coordination service (DCS)

The Release Coordinator role within the DCS is defined to assist the Release Manager in undertaking the following responsibilities.

Accountabilities

• Initiate
  • Validate the scope of the Change Request and reach out to respective resources for additional information, if required.
  • Determine Release Type.
  • Update Release Repository accordingly.
• Planning
  • Accountable to own the planning and/or coordination of all phases of release deployment activities for systems, applications and the production environment.
  • Engage Project Manager, Lead or Stakeholders to gather additional information about the deployment (for example, scope, resources, and more).
• Build and test
  • Create, schedule and facilitate Release Kick off to review scope, timelines and tasks with core team for Complex Releases.
  • Develop detailed Method of Procedures (MoPs) for production environment deployments involving numerous stakeholders, clients and vendors.
  • Facilitate walkthrough of the MoPs to make refinements with deployment resources.
  • Ensure Client Communication is scheduled (if required).
• Deployment
  • Provides release coordination by monitoring each phase of the release and providing appropriate communication to respective stakeholders through task e-mails, status update e-mails and running issue triage calls where required during the deployment.
  • Confirms the MoP is followed and that the release deliverables have been completed.
  • Monitor for issues that arise during the deployment and ensure Incident Management protocols are followed for necessary escalations to stakeholders.
• Close down
  • Coordination of backout, backout verification and communication activities if backout permits.
  • Update Release Repository accordingly.

3.6.7. Release stakeholder

Release Stakeholders reside throughout the OPS wherever I&IT infrastructure, solutions and services are identified, managed and owned.

Accountabilities

• Participate in Enterprise Release Management process
• Attend release Kick off or MoP walkthrough meetings to review scope, timelines and tasks and provide feedback to Release Coordinator where appropriate
• Responsible for completing tasks
• Implement and report on status of deliverables or issues at status calls and MoP walkthrough meetings and during deployment activities
• Perform testing
• Provide feedback to Release Coordinator on release collaterals where required
• Provide any documentation created as part of the Release to the Release Coordinator
• Attend Pre-Go or No-Go and provide readiness recommendation response (when applicable)
• Help resolve outstanding tasks from Pre-Go or No-Go (when applicable)
• Attend final Go or No-Go and provide readiness recommendation response
• Provide post-activation feedback to Release Coordinator

3.6.8. Service owner

The Service Owner is accountable for a specific service within an organization regardless of where the underpinning technology components, processes or professional capabilities reside.

The Service Owner is accountable for:

• initiation, transition and support of a particular service
• continual improvement and the management of change to the service
• exchanging relevant service information with the Service Level Manager who is the prime customer contact for all service-related performance inquiries and issues

Note: Both Clusters and ITOD can be Enterprise Service Owners. Whoever initiates the enterprise service follows the Enterprise Release Management workflow and champions the release activates.

Accountabilities

• Provides input in service attributes such as performance, availability and more
• Represents the service across the organization
• Understands the service (components and more)
• Point of escalation (notification) for major Incidents
• Represents the service in Change Advisory Board meetings
• Provides input to the Continual Service Improvement (CSI) process
• Participates in internal service review meetings
• Identifies and prioritizes service improvements
• Assists the enterprise Problem Manager with identification, prioritization and resolution of Problems
• Responsible for obtaining the appropriate endorsement and approvals for introducing new or making changes to infrastructure, solutions and services
• Accountable for submitting any request for changes — if required for making changes to I&IT infrastructure, solutions or services
• Responsible for ensuring that the service entry in the organization’s Service Catalogue is accurate and is maintained
• Participates in negotiating Service Level Agreements (SLAs) and Operational Level Agreements (OLAs)

3.6.9. Project manager or Release requestor

As an active participant in the Release Management Process, the Project Manager or Release Requestor is responsible for the following activities. The role of a Project Manager or Release Requestor may differ slightly between the Service Management Readiness (SMR) and the Deployment Coordination Service (DCS)

SMR

• Provide an approved Project Charter with required signatures (when applicable).
• Attend release-related meetings (for example, Kick-off, Status Updates and Go/No-Go).
• Provide project updates on service technology and user development status or issues.
• Provide project-related content for the Kick-off and Go/No-Go meetings.
• Act as a single point of contact between Release Management Stakeholders and the project team and is accountable for ensuring that any requested information is provided in a timely fashion to assist in the completion of eRM activities.
• Work with the Customer Relationship Management (CRM) team and Service Management Engagement and Integration (SMEI) to liaise with the Cluster or customer.
• Include Release Management in Post Implementation Review and/or Lessons Learned activities (when applicable).

DCS

• Ensure Pre-Prod or UAT deployment was completed successfully and signed-off on
• Provide initial Method of Procedure (MoP) or deployment tasks to the Release Coordinator
• Provide the Release Coordinator with deployment-related resources from the application, technical team and business areas to participate in the MoP walkthrough meetings
• Attend release-related meetings (for example, Kick-off, MoP Walkthrough Meetings, Technical Deployment Bridge, and more)
• Confirm list of recipients for the deployment thread and Release Status e-mails (when applicable)
• Work with Change Coordinator to include required details in the CRQ and address inquiries as per Enterprise Change Management process
• Communicate change or outage details to clients (for example, via ITSM Communication Service)
• Include Release Coordinator in MoP related meetings, Post Implementation Review and/or Lessons Learned activities (when applicable)

3.7 Concepts and definitions

3.7.1. Key terms

Assessment criteria                                   
Assessment criteria are the standard set of questions posed by Service Management Engagement and Integration with the Service Owner and/or their delegate. For example, Project Manager when a new project (solution or service) is initiated. It is used to determine the scope and impact of each release.

Deployment                                   
The activity responsible for movement of new or changed hardware, software, documentation, process and more to the production environment.

Enhanced Service Activation (ESA)

Enhanced Service Activation acts as an assurance wrapper around existing activation processes, practice and standards by providing additional layers of security, reliability and quality assurance. It ensures that when new features or functionalities are activated, they are integrated seamlessly into existing systems without causing disruptions or vulnerabilities. This assurance wrapper involves thorough testing, validation and compliance checks to guarantee that the activation process adheres to industry standards and best practices. It also includes safeguards to protect against potential errors, conflicts or security breaches that could arise during the activation process. By encapsulating the activation process within an assurance wrapper, organizations can instill confidence in their customers that the enhanced services will be deployed smoothly and reliably.

Enhanced Service Activation requests can be logged through ONRequest and consultation requests will be routed to the Service Management and Integration (SMEI) team via eSMT.

Executive summary update                                   
Release Manager sends an e-mail summary to Executives including a list of upcoming and completed release deployments with an overall status for visibility and awareness. Executive Summary will include Service Outage (when applicable), accountable director, deployment date and time, Change Request and more.

Go/No Go recommendation                                   
A recommendation to halt or proceed with the implementation of a release based on Service Management readiness and any identified risks. Go / No Go meetings are scheduled and facilitated by Release Management and include Service Owners and Release Stakeholders impacted by the change.

Initiative complexity and effort (ICE) sizing                                    
A matrix used by the Service Planning Intake Management Team to identify the complexity and effort of a particular release (X-Small, Small, Medium or Large).

Impact                                   
Measure of scope and criticality to business.

Method of procedure                                   
The Method of Procedure (MoP) is a work-plan which typically includes project scope details, step-by-step tasks to execute the production implementation, stakeholder involvement activities as well as backout activities. There are many variations of MoPs pending on clients and release scope (for example, Simplified, Detailed, Vendor, and more).

Opportunity assessment                                   
The Opportunity Assessment is a meeting between Service Management Engagement and Integration (SMEI) and the Project Manager or Project Lead in which the details of the project are reviewed and scope, impact, urgency and priority of the release are determined.

Release                                   
A collection of hardware, software, documentation, Processes or other Components (CI's) required to implement an approved Change to IT Services. The contents of each Release are managed, tested and deployed as a single entity.

Release announcement                                   
The Release Announcement is an e-mail which outlines the background, scope and project or release objectives that is sent to a set distribution list of stakeholders. This Distribution List includes ITOD Management.

Release deployment status update                                   
Release Deployment Status Updates are sent at scheduled times during a release deployment to provide the overall status of the implementation activities to a predefined distribution list which typically includes executives, management and stakeholders involved in the deployment activities. The updates may include overall deployment status, outage information, deployment summary, major milestones, issues and more.

Release lifecycle                                   
The Release Lifecycle refers to the entire progression of a given release from when it is determined that Release Management activities are required. If Release involvement is required, a release will pass through the following stages in its lifecycle: Initiate, Planning, Build, Test, Deployment and Close Down.

Release plan                                   
A document used to outline and track the deliverables for each stakeholder participating in each release.

Release repository                                   
The tool used to keep track of all the details pertaining to a given Release (for example, key dates, collaterals, presentations, meeting minutes and more).

3.7.2. Process phases

The Enterprise Release Management ((eRM) process activities have a sequential workflow with task dependencies linked to activities from other process areas and groups. The following lists and tables provide a high-level overview of the eRM process for both the Service Management Readiness and Deployment Coordination Service as well as a description of the key milestones.

3.7.2.1. Service management readiness process phases and milestones

The following list outlines the sequential workflow for Service Management Readiness.

Phase 1 - Initiate

• Determine scope of a project.
• Confirm release type.
• Confirm costing (if applicable).
• Assign release coordinator (if required).

Phase 2 - Planning

• Timelines.
• When or whom.
• Collateral and training.
• Stakeholders.
• Communications.

Phase 3 - Build

• Build support.
• Collateral and training.
• Pilot (plan).
• Communications.
• Workshop.

Phase 4 - Test

• Pilot (execute).
• Go/No-Go.
• Communications.

Phase 5 - Deployment

• Activation or deployment.
• Stabilization period.
• Maintain issue log.
• Reporting.
• Communicate results.

Phase 6 - Close down

• Create scorecard.
• Lessons learned.
• Communications.
• Close release record.

The following table lists the key milestones within the Service Management Readiness at a high level.

3.7.2.2. Deployment coordination service process phases and milestones

The following list outlines the sequential workflow for the Deployment Coordination Service.

Phase 1 - Initiate

• SMEI or SPIM
• Assess Change Request
• Determine Release Category and Type
• Assign Release Coordinator (If required)

Phase 2 - Planning

• Prepare and create Deployment Collateral
• Engage stakeholders for release info
• Communications

Phase 3 - Build and test

• Release Dashboard
• Gather Content for MoP
• Conduct Walkthrough Meetings
• Finalize all Release Collateral

Phase 4 - Deployment

• Pre-Deployment Activities
• Manage and coordinate Release Deployment
• Validate Release Deployment

Phase 5 - Close down

• Post Deployment Activities
• Communication
• Close Release Record

The following table lists the key milestones within the Deployment Coordination Service at a high level.

3.7.3. Service management readiness release types

Within the Operational Readiness process stream, a project could fall under 4 types or categories of releases based on the recommendation from the Service Planning and Intake Management (SPIM) committee. The following table provides a description of each release type:

Minor / Localized (X-Small)

Release criteria

• Service change is seamless to operations and transparent to users.
• Small group of users affected by service change.
• Minimal to no end-user involvement.
• Minimal training requirements for staff and support levels.
• None to minimal external resource requirements.
• No Service Management procurement activities.
• No Service Design Package.

Level of work effort and estimated timelines

• No cost if assessment is completed and no formal Release activities are required.
• a "Minor or Localized" release is often one or more small corrective modifications to a specific error and/or to previously implemented solutions.
• May require Change Request (CRQ).

Moderate / Limited (Small)

Release criteria

• Service change is seamless to operations and transparent to users.
• Small group of users affected by service change.
• Minimal to no end-user involvement.
• Minimal training requirements for staff and support levels.
• None to minimal external resource requirements.
• No Service Management procurement.
• Update or review of Service Design Package.

Level of work effort and estimated timelines

• Level of effort is estimated to be less than 30 business days.
• May require eRM and/or Change Request (CRQ).

Significant / Large (Medium)

Release criteria

• Multi release jurisdictions required.
• Registered project required.
• New service for small group or specialized user or groups such as Lines of Business, Branch or Section.
• Service change to existing service affecting multiple businesses.
• Require internal approvals by governing bodies such as ITSML, ACT/ARB.
• Multi-party service chain.
• Moderate end user involvement.
• Requires training such as complex processing.
• Multifaceted dimensions to roll-out businesses, different functionalities within the service, dependencies with other services or technologies.
• Decommissioning or retiring services.
• Has potential to impact end user experience or productivity such as major technology upgrade visible to users.
• Create new or update existing Service Design Package.

Level of work effort and estimated timelines

• Level of effort is estimated to be between 30 and 60 business days.
• Requires: eRM, Change Request (CRQ) and Test or Pilot.

Extensive / Widespread (Large)

Release criteria

• Major new service introduction.
• Other release jurisdictions impact (medium to high).
• Impact public safety or public facing business service.
• Multiple ministries wide business impact.
• Require senior executive approval.
• Executive office or VIP services.
• Highly sensitive such as legislation, privacy, political.
• Significant resource requirement.
• IT standard or legislation driven implementation end date.
• New service provider or owner (for example, network provider).
• The service change is core to transforming and optimizing the service.
• Includes both "Moderate / Limited" and "Significant/Large" release criteria but involves more Stakeholders, has higher visibility, impact and priority than a "Significant/Large" release.
• Creation of service design package.

Level of work effort and estimated timelines

• Level of effort is estimated to be greater than 60 business days (12 weeks).
• An "Extensive / Widespread" release can be complex and/or typically represents a significant roll-out of hardware and software which introduces important modifications to the functionality, technical characteristics and more.
• For example: software releases and hardware upgrades, normally containing large amounts of new functionality, some of which may make intervening fixes to problems redundant. A major upgrade or release usually supersedes all preceding minor upgrades, releases and emergency fixes.
• Requires: Registered Project and eRM.

3.7.4. Deployment coordination service release types

Once the Change Request has been assessed and/or created, the Release Manager will determine the "Release Type" based on the scope of the release and a Release Coordinator will be assigned. The Release Types offered by eRM DCS and the activities found within each type are described in the following table.

Note: Services identified as being required for the different release types below may not be applicable based on individual release requirements.

* Note: Deployment Coordination Service involvement for Urgent Unplanned changes is on a “best effort” basis due to the short timelines provided and resource availability.

Communications-Only Release

• Commonly used when Release Management is not needed to coordinate deployment tasks but there is a need to send executive-level e-mail updates during the deployment period.
• Release Coordinator will send Release Status Update e-mail(s) to management or executives during the deployment timeframe.
• Prior to the deployment, the Release Coordinator will work with the Project Manager or Lead to confirm the following (these activities apply for all Release Types):
  • details to include in the Release Status Update e-mail (such as Summary, Milestones, Outage info and more).
  • frequency of the e-mail updates.
  • recipient list for the e-mail updates.
  • main contact for the Release Coordinator to work with during the deployment to gather updates to include in the communication.
• Project Manager or Lead includes Release Coordinator in Method of Procedure (MoP) or Deployment Plan development meetings.

Simplified release

• Commonly used when a deployment has minimal tasks or resources over a short time frame.
• A formal Method of Procedure document is not required.
• Deployment or validation tasks are confirmed via e-mail with the resources involved but a walkthrough meeting can be scheduled if required.
• A deployment thread e-mail is used to track the progress of the deployment tasks during the deployment period.
• One Release Status Update e-mail is typically sent to management or executives once the deployment is complete.
• Release Coordinator is responsible for coordinating issue resolution and escalating to management during the deployment.

Detailed release

• Most common Release Type and is typically used for a new application deployment or application enhancements which may involve a service or application outage.
• Release Coordinator will create or update and review the Method of Procedure (MoP) with the resources involved in the deployment. The MoP will typically contain pre-deployment, deployment, validation, post-deployment and back-out (if required) tasks.
• One or more walkthrough meetings will be scheduled with resources involved to review or update the MoP.
• Release Coordinator will coordinate the pre-deployment, deployment and post-deployment tasks from the Method of Procedure via a deployment thread e-mail.
• One or more Release Status Update e-mails will be sent from the Release Coordinator to management or executives during the deployment timeframe.
• Release Coordinator is responsible for coordinating issue resolution and escalating to management during the deployment.

Complex releases

• A Complex Release typically consists of multiple related projects, across one or more Ministries, impacting multiple applications, within the same deployment window.
• A “Kick Off” meeting may be scheduled with stakeholders involved to review the scope, upcoming activities and timelines leading up to the deployment date (if required).
• Tasks from multiple CRQs or Method of Procedure (MoP) documents will be consolidated into a single MoP.
• One or more MoP walkthrough meetings will be scheduled with resources involved to review or update the consolidated MoP.
• Release Coordinator will coordinate the pre-deployment, deployment and post-deployment tasks from the MoP via a deployment thread e-mail during the deployment period.
• One or more Release Status Update e-mails will be sent from the Release Coordinator to management or executives during the deployment timeframe.
• Release Coordinator is responsible for coordinating issue resolution and escalating to management during the deployment.

3.8. Process workflow description for Service Management Readiness

The following list provides content related to the inputs or triggers, description, output or completion criteria and common release record status for each process step in the eRM process workflow. 

Engage release management

Input or Trigger

• Service Planning and Intake Management (SPIM)
• Opportunity Assessment from Service Management Engagement and Integration (SMEI)
• Project Charter
• Project Collaterals (for example, Plan)

Description

• Release Manager receives request for Release Management engagement from Service Management Engagement and Integration (SMEI) via SPIM.
• Release Manager reviews the request and confirms if SMR resources are required.
• If SMR activities are required, Release Manager creates release record containing available collaterals and assigns Release Coordinator. Service Management Engagement and Integration (SMEI) updates Dynamics CRM application to note Release activities are required.
• If SMR activities are not required, Release Manager advises SMEI to engage appropriate Stakeholder groups. SMEI updates Dynamics CRM application to note Release Management activities are not required.

Output or Completion criteria

• Applicable Release Coordinator engaged, if required.
• Meeting scheduled with PM to confirm release impact and scope.
• Release record created.

Common release record status

Draft

Create release plan

Input/Trigger

• Assignment of Release Coordinator.
• Project plan template.
• Project collateral.
• Completed opportunity assessment.

Description

Release Coordinator:

• creates Release Announcement
• updates Release Record including proposed timelines
• finalizes Release Announcement after review with Project Manager or Service Owner representation
• drafts Kick-off presentation

Output or Completion criteria

• Updated Release Record.
• Finalized Release Announcement.
• Draft Kick-off presentation.

Common release record status

Planning Milestone

Distribute release announcement

Input or Trigger

Release Announcement

Description

Release Coordinator distributes Release Announcement email to Stakeholders

Output or Completion criteria

Release Announcement email

Common release record status

Planning Milestone

Facilitate kick off

Input or Trigger

Draft Kick-off presentation

Description

• Release Coordinator works with Project Manager to finalize Release Management Kick-off presentation.
• Release Coordinator schedules and facilitates Release Management Kick-off meeting to:
  • provide an overview of the project and scope of release activities.
  • validate Stakeholder involvement and their deliverables.
  • finalize Release Plan.
  • define next steps for Stakeholder workshops.
  • release coordinator updates Release Management record with dates and collaterals.

Output or Completion criteria

• Updated Release record(s) with dates, collaterals and Stakeholders.
• Finalized Release Plan.

Common release record status

Build Milestone

Release status meetings

Input or Trigger

Kick-off Meeting or No-Go Decision

Description

Release Coordinator:

• schedules recurring Release status update meetings
• facilitates end-to-end process or pilot testing, where required
• drafts Go / No-Go presentation
• distributes meeting minutes after each Release status update meeting
• tracks completion of Stakeholder deliverables using the Release Plan
• updates Release Management record with issues, timelines, and relevant associations

Output or Completion criteria

• Updated Release record(s) with issues, timelines and relevant associations.
• Scheduled recurring Release Status Update meetings.
• Drafted Go/No-Go Presentation.

Common release record status

• Build milestone.
• Test milestone.

Facilitate Go or No Go

Input or Trigger

Go / No-Go Presentation

Description

• Release Coordinator works with stakeholders to finalize Release Management Go / No-Go presentation.
• Release Coordinator facilitates Go / No-Go.
• Release Coordinator involved updates Release Management Record:
  • If Go, advance the Release to the "Deployment" Milestone.
  • If No-Go, do not advance Release to the "Deployment" Milestone. Add a Work Info Note indicating the reason why and next steps.
• Release Coordinator sends all Stakeholders an email with the outcome from Go / No-Go meeting:
  • If No-Go, return to 5.0 to resume Release Status Meetings.

Output or Completion criteria

• Go / No-Go Decision.
• Updated release record(s).

Common release record status

• Deployment milestone.
• If No-Go, move back to Build Milestone.

Release deployment

Input or Trigger

Go/No-Go "YES" Decision

Description

• If Deployment Coordination Services are not required for the Release:
  • deployment of service or solution led by Project Manager
  • deployment activities are coordinated by the Project Manager
  • Project Manager confirms success/failure of deployment and advises Release Coordinator of status
  • Release Coordinator sends email to Stakeholders advising of result of deployment
• If Deployment Coordinator Services are required for the Release:
  • deployment of service or solution led by Project Manager
  • deployment activities are coordinated by the Deployment Release Coordinator following the DCS process also outlined in this Standard
  • Deployment Release Coordinator advises Service Management Readiness release coordinator of status of the deployment
  • Service Management Readiness Release Coordinator sends email to Stakeholders advising of result of deployment
• If deployment fails, return to 5.0 to resume Release Status Meetings
• Service Management Readiness Release Coordinator updates Release Record with result of deployment

Output or Completion criteria

• Stakeholders receive email advising of result of deployment.
• Updated Release record(s) with result of deployment.
• Service or solution is now live,

Common release record status

Deployment Milestone

Monitor operations impact

Input or Trigger

Result of Deployment

Description

• Release Coordinator tracks issues in day-to-day operations for a stabilization period of minimum 30 calendar days
• Release Stakeholders report any or all post activation feedback to the Release Coordinator
• Release Coordinator:
  • informs impacted Stakeholders of any issues to ensure remediation activities occur
  • tracks any action items from the Go/No-Go and informs stakeholders on status until completed
  • update Release Record with status or issues and completed action items during the stabilization period and updates Milestone to "Close Down" at end of this period
  • the "Service" field must also be updated before moving to the "Close Down" Milestone

Output or Completion criteria

• Updated Release Record(s) with status or issues and completed action items during the stabilization period.
• Updated Service field.

Common release record status

Close Down Milestone

Close down

Input or Trigger

End of stabilization

Description

Release Coordinator:

• sends email to Project Manager to confirm completion of Release Management activities
• sends Release Record Closure Validation email to Stakeholders
• reviews Release Record to ensure all information gathered and recorded in alignment with Enterprise Release Management Service Management Readiness Process Procedures Guide
• updates Release Record Status to "Closed"

Output/Completion criteria

• Closure Validation email distributed to Stakeholders.
• Updated Release Record Status to "Close Down".

Common release record status

Close Down Milestone

3.9. Process workflow description for the Deployment Coordination Service

The following list provides content related to the inputs or triggers, description, output or completion criteria and common release record status for each process step in the Deployment Coordination Service workflow.

Image

     Enterprise Release Management - Overall Process Flow: Accessible Descriptions

1.0 Engage release management 

Input or Trigger

• Release Management Assessment Task/eSMT Change Request (CRQ).
• Cluster Clients/Release Committees.
• Service Management Engagement and Integration (SMEI).
• Service Planning and Intake Management (SPIM).

Description

Release Manager receives request for Release Management engagement via an Assessment task (eSMT Change Request), a Cluster Client/Release Committee or through SMEI via SPIM.

Output or Completion criteria

• Proceed to assess Release or Change Request Process (2.0).
• Meeting may take place between Release Management and SMEI or a Cluster Client to determine release requirements.
• Release Manager may request Change Request creation if required.

2.0 Assess change request

Input or Trigger

Release Management Assessment Task or Change Request (CRQ)

Description

• Release Manager assesses or reviews the request and confirms if deployment coordination services DCS are required
• If DCS activities are not required, Release Manager advises SMEI /Cluster Clients/Committee members to engage appropriate Stakeholder groups and/or closes the assessment task and notes that DCS services are not required. SMEI updates Dynamics CRM accordingly.
• If DCS activities are required– proceed to subprocess 3.0 Determine Release Type.

Output or Completion criteria

• Proceed to determine Release Type (3.0)
• Release impact and scope gathered
• Assessment task in eSMT Change Request (CRQ) is closed or assigned to a Release Coordinator until further details or collateral are attached to the CRQ

3.0 Determine release type

Input or Trigger

• Scope of Change Request.
• Project collateral.

Description

Release Manager/ Release Coordinator determines the Type of Release required — depending on scope (Communications-Only, Simplified, Detailed or Complex. SMEI updates Dynamics CRM.

Output or Completion criteria

• Proceed to assign a Release Coordinator (4.0).
• Release type determined.
• Discussions and review of Forward Schedule of Changes (Power BI Dashboard) at Team Meetings with Release Coordinators for adjustments, if required.

4.0 Assign a release coordinator

Input or Trigger

• Reference to the DCS Resource Schedule.
• CRQ assessment task status is changed to WIP.

Description

If DCS activities are required, Release Manager assigns Release Coordinator based on the DCS Resource Schedule

Output or Completion criteria

• Release Coordinator assigned.
• Release record created.

5.0 Identify collateral and prepare for release

Input/Trigger

• Release Type determined.
• Assignment of a Release Coordinator.

Description

• Release Coordinator will identify and prepare release collateral (for example, MoP) based on the Release type determined in process 4.0 and the deployment scope.
• Release Coordinator will identify and request resources and stakeholders who will be involved in the deployment activities.

Output/Completion criteria

• When applicable, the following collateral may be drafted:
  • Kick Off Presentation
  • Release Questionnaire
  • Draft MoP
  • Resource Contact List
  • Release Deployment Status Updates
• Deployment resources obtained
• Move Release Record to Planning Phase

6.0 Gather and manage content to update release collateral

Input/Trigger

• Release type.
• Initial MoP or Implementation Plan.
• Feedback from Walkthrough Meetings.
• Stakeholder Feedback.
• Change Request Details.

Description

Release Coordinator is responsible for:

• reaching out to Project Lead or Project Manager to gather release deployment resources and contact information to hold Kick Off Meeting or Walkthrough meetings
• conducting one or more Walkthrough Meeting(s) to gather specific technical contents from deployment resources to update the MoP

Output or Completion criteria

• When applicable, the following collateral will be updated:
  • Kick Off Presentation
  • Release Questionnaire
  • MoP
  • Resource Contact List
  • Release Deployment Status Updates
• Deployment resources confirmed

7.0 Finalize and complete release collateral

Input or Trigger

• Final Walkthrough Meeting.
• Deployment resource feedback and input.

Description

• Release Coordinator leads final walkthrough meeting to finalize and verify all supporting release collateral with appropriate stakeholders.
• Release Deployment Status Updates are drafted once the MoP is finalized.
• Release Coordinator will attach the finalized MoP to the CRQ.
• Release Coordinator will prepare deployment e-mail thread (when applicable).
• Release Coordinator provides deployment status to Release Manager at weekly meeting.

Output or Completion criteria

• Finalized MoP (attached to CRQ)
• Status updates finalized
• Executive summary status update
• Deployment e-mail thread drafted (when applicable)

8.0 Deploy, manage and coordinate release activities

Input or Trigger

• Finalized MoP.
• Change Request approved.
• Deployment e-mail thread.

Description

• Release Coordinator is responsible for deploying, managing and coordinating release deployment activities including Pre-Deployment, Deployment, Post-Deployment and Backout activities (if required).
• When the Change Request is approved, the release coordinator can begin coordinating deployment activities as per the MoP.
• Release Coordinator will begin coordinating deployment activities when the pre-deployment activities are successfully completed.
• During the deployment, conference bridges may be used to:
  • triage any unforeseen issues that may arise and require technical resources or management approval
  • lead Status Checkpoint Calls to provide management and stakeholders updates on the overall deployment status (when applicable)
• Release Coordinator will send scheduled Release Status Update e-mails to Executives, Management and Stakeholders and more.
• Technical, business and/or application resources validate that the deployment activities were completed successfully
• Once deployed, the Release Coordinator will send a final Release Status Update to executives, management and more
• If deployment activities are successful, proceed to subprocess 9.0 Close Down.
• If issues arise during any stage of the pre-deployment, deployment or validation activities, an executive decision may be required to proceed to subprocess.

8.1 Initiate backout (If applicable)

Output or Completion criteria

• Release Record status moved forward to Deployment Phase
• Pre-deployment activities complete
• Deployment activities complete
• Conference calls (triage or checkpoints)
• Release status updates (include deployment issues, service outage and more)
• Release deployment validated and signed off on
• Escalations to management and confirm if backout is required (when applicable)
• Post-deployment activities to be coordinated (when applicable)

8.1.1 Initiate backout (If applicable)

Input or Trigger

• Unsuccessful Pre-Deployment, Deployment and/or Validation activities.
• Executive and/or Management approval.

Description

• If validation of release is unsuccessful, a conference call is chaired with executives, management and more to receive approval to initiate backout activities.
• Once management approval is received, the Release Coordinator will coordinate backout activities.
• Assigned technical, business and/or application resources validate the backout changes were completed successfully.
  • If validation of backout is successful, proceed to subprocess 9.0 Close Down.
  • If validation of backout is unsuccessful, the project team will work with the business on deciding new dates and triage work arounds.
• Release Coordinator sends Release Status Update e-mail to advise of the result of the backout activities

Output/Completion criteria

Backout completed

9.0 Close down

Input/Trigger

• Deployment and validation completed.
• Backout completed (if required).

Description

• The final Release Status update e-mail is attached to Release Record.
• Release Coordinator provides release status to Release Manager at the weekly post-deployment team meeting.

Output/Completion criteria

• Post Deployment Activities completed.
• Close Release Record with Status Reason.

3.10. Common metrics

Metrics are intended to provide a useful measurement of the effectiveness and efficiency of a process. Metrics are also required for strategic decision support. The following metrics should be used to assess process performance, opportunities for service improvements and strategic decision support.

4 Related standards and impacted infrastructure

4.1 Impacts to existing standards

Identify any standards that reference or are referenced by this standard and describe the impact.

4.2 Impacts to existing infrastructure

Identify any applications, systems, solutions and technology platforms that could be affected by this standard and describe the impact.

5 Compliance requirements

In order to manage the effectiveness and implementation of this standard, Ministries, I&IT 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 effectiveness of a standard and for its full life-cycle, including development, reviews, revisions, updates, evaluations, and rescindment. Where a committee owns the standard, the committee Chair is accountable for the standard. There must be exactly one accountable role identified.

Accountable role

Title: Chair, Service Management Executives (SMX)                     
Ministry: Public and Business Delivery and Procurement (MPBSDP)                   
Division: Infrastructure, Technology and Operations Division (ITOD)

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 or I&IT Cluster: Division: Branch: Service Management, Planning, Design and Transition

Support role definition

The support role is the resource(s) to whom the responsibility for maintaining this standard has been assigned. Inquiries, feedback, and suggestions should be sent to this resource.

Support role (editor)

Ministry: MPBSDP                     
Division: ITOD       
Branch: Service Management, Planning, Design and Transition
Section: Release Management Office
Job Title: eRM Manager                     
Name: Victor Krause
Phone: 905-321-3863           
Email: Victor.Krause@ontario.ca

Second support role

Section: Release Management Office
Job Title: Practice Lead
Name: Dwayne Leach
Phone: 905-359-1278           
Email: Dwayne.Leach@ontario.ca

Second support role

Section: Release Management Office
Job Title: Practice Lead
Name: Clayton McIntyre
Phone: 289-241-5952           
Email: Clayton.McIntyre@ontario.ca

7 Consultations

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

8 Document history

9 Glossary

ACT                     
The Corporate Architecture Core Team (ACT) is an integral part of the OPS Enterprise Architecture governance framework. The Architecture Core Team supports the mandate of the Architecture Review Board by providing advice and recommendations on the design of IT solutions. The Architecture Core Team reviews IT project architecture and provides recommendations to the Architecture Review Board

ARB                     
Architecture Review Board (ARB) provides operational level enterprise architecture approval for I&IT related items across the OPS.

Change                     
From an eCM scope perspective, a Change is a modification to a CI in the Production environment including:

• HW/SW components,
• services and service components,
• production support documentation (eg. Service Desk knowledge records, operations procedures)
• eSACM data relating to HW/SW components, services and service components, or production support documentation

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

• capacity
• functionality
• scope
• availability
• data

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

Configuration item (CI)                     
Any Component that needs to be managed to deliver an IT Service.

For more information refer to Enterprise Service Asset and Configuration Management GO-IT Standard 36.

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 or Clients, for example ‘this is a customer-focused Organization’.

Deployment                     
The activity responsible for movement of new or changed hardware, software, documentation, process, etc. to the production environment.

Enterprise change management (eCM)                     
The Change Management Process ensures that all changes to IT Production environment are properly planned, managed, assessed and approved reviewed prior/following their implementation and release.                    
For more information refer to Enterprise Change Management GO-IT Standard 35.

Enterprise service asset and configuration management (eSACM)                     
For more information refer to Enterprise Service Asset and Configuration Management GO-IT Standard 35.

External service provider                     
An IT Service Provider that is part of a different Organization from its customer. An IT Service Provider may have both Internal customers and External customers.

Impact                     
Measure of scope and criticality to business.

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 3 subtypes:
• service Interruption – Fault
• service Interruption – Degradation
• service Interruption – Security

Internal service provider                     
An IT Service Provider that is part of the same Organization as its customer. An IT Service Provider may have both Internal customers and External customers.

IT business solution                     
A combination of IT (Provider) support services that deliver end-to-end value.

IT support service (Provider)                     
A Service provided to one or more customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the customer’s Business Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Specification.

ITELC                     
The Information Technology Executive Leadership Council (ITELC) is a decision-making body that provides functional level leadership and governance for the I&IT organization. It is a forum for identifying and addressing I&IT issues at an enterprise level and for exchanging information and ideas between clusters and corporate offices in support of the I&IT organization and the government’s mandate.

ITSM                     
IT Service Management (ITSM) is a process-based practice intended to align the delivery of information technology (IT) services with needs of the enterprise, emphasizing benefits to customers.

SMX                     
A forum where Service Management Executives (SMX) meet with project leads. The primary goal of the forum is to advise CIOs and represent clusters on matters relating to Service Management strategy, design, transition, operation and continual service improvements.

Known error                     
A problem that has a documented Root Cause and a workaround. Known Errors are created and managed throughout their lifecycle by Problem Management. Known Errors may also be identified by developers or suppliers.

Lifecycle                     
The various stages in the life of an IT Service, Configuration Item, Incident, Release, Change, etc. The Lifecycle defines the Categories for State and the State transitions that are permitted. For example, states for the following CI types might include:

• application - Requirements, Design, Build, Deploy, Operate, Optimize
• incident - includes Detect, Respond, Diagnose, Repair, Recover, Restore
• server: Ordered, Received, In Test, Live, Disposed, etc.

Major incident                     
Major Incidents follow virtually the same steps as normal incidents but with an emphasis on accelerated functional escalation, coordination of resources and enhanced communications management to achieve resolution as quickly as possible.

Operational level agreement (OLA)                     
An agreement between an IT Service Owner and another IT Service Owner within the same organization.

The other Service Owner provides services that support delivery of IT services to Service Owner A’s customers.

The OLA defines targets and responsibilities that are required to meet agreed Service Level Targets in an SLA.

The OLA defines the goods or services to be provided and the responsibilities of both parties. For example, there could be an OLA:

• between the IT Service Provider and a procurement department to obtain hardware in agreed times
• between the Service Desk and a support group to provide incident resolution in agreed times

Post implementation review                     
A review for verification of correct implementation of change by authorized personnel.

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.

Production environment                     
A subset of IT infrastructure that participates in delivery of Service.

Resource                     
Resources are tangible Assets of an Organization. Resources are transformed into value (for example, Services) by an Organization’s Capabilities. Resource assets include:

• people
• information
• applications
• infrastructure
• financial capital

Rollout                     
The activity that involves delivery, installation and commissioning of an integrated set of new or changed CIs across logical or physical parts of the I&IT organization.

Service catalogue                     
The Information and Information Technology (I+IT) Service Catalogue is a reference document describing services offered to staff in the Ontario Public Service (OPS) and the agencies, boards, and commissions supported by the I and IT organization in the OPS.

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 agreement (SLA)                     
An agreement between an IT Service Provider and a customer.

The SLA describes the IT service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the customer.

A single SLA may cover multiple IT services or multiple customers.

(See also Operational Level Agreement and Underpinning Contract)

Service management lifecycle                     
An approach to IT Service Management that emphasizes the importance of coordination and Control across the various Functions, Processes, and Systems necessary to manage the full Lifecycle of IT Services. The Service Management Lifecycle approach considers the Strategy, Design, Transition, Operation and Continuous Improvement of IT Services.

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.

Where there are several Service Providers that enable an overarching service, they are sometimes called Supply Chain (or Service Chain) Partners.

Services                     
The deliverables of the IT Services organization as perceived by the customers; the services do not consist merely of making computer resources available for customers to use.

Stakeholder                     
A term used to describe a user representing an area that is impacted by a given Release.

Supporting documentation                     
From Principle 2: Install docs, users manuals etc.

System/Solution                     
A group of related components, representing a specific type of component set, that work together to perform a specific function in support of one or more IT (Provider) Support Services. Examples include:

• an application solution that may include numerous modules, data, documentation and processes that are designed to perform a set of related functions
• a hosting system, including hardware, network, standards and documentation that support one or more application-based solutions

User                     
A person who consumes the IT Service on a day-to-day basis. Users are distinct from customers, as some customers do not use the IT Service directly.

10 Appendices

10.1 Normative references

GO IT Standards

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

Note: A normative reference can include other supporting GO‑IT Standards. May also include requirements published by the Standards Council of Canada (SCC) or other equivalent international, regional, and National Standards Bodies (source: Standards Council of Canada – Guidelines for Incorporating Standards by Reference in Regulations to Support Public Policy Objectives.)

10.2 Informative references

10.2.1. Differentiation: Process, procedure, work instruction

There are three levels of task descriptions that are often confused with one another:

• 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

10.2.2. Procedural localization guidelines

The standard content applies to all organizations and groups within 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 eRM. Procedures define the detailed How and Who (role) in support of the process.

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.

10.2.3. Localization principles

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

10.2.4. Local procedure guide content

All process standard content plus:

• local Operational Principles, Guidelines and Activities
• business-specific standards (for example, HIPPA)
• additional roles and responsibilities that augment but do not replace or deviate from the standard roles and responsibilities
• local RACI Charts
• local Procedures (such as Escalation and Line of Business Communications)
• local Reporting Metrics

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