GO-ITS 40 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 IT Standards describe where the application of an IT standard is mandatory and specify any qualifications governing the implementation of the IT standards.

2 Summary

2.1 Standard name and description

This document defines the technical standards 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 40 Enterprise Release Management (eRM) process standard was implemented with the primary focus of protecting the production environment and its services. eRM works to ensure IT solution/service projects are successfully released to production and that post-implementation support structures are in place across the end-to-end I&IT supply chain. As a result, the role that eRM plays for each release to production is that of a guide, facilitator, coordinator, and checkpoint gatekeeper.

In line with the Information Technology Infrastructure Library 4 (ITIL 4), GO-ITS 40 Enterprise Release Management has been updated to include further details regarding the Deployment Coordination Service (known as the Deployment Management Technical Management Practice in ITIL V4). There is also a distinction made 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 oversight of all operational support activities required for activating or decommissioning IT solutions/services in the Production environment. The SMR provides assurance that the IT Service Owner is operationally ready to activate/decommission the solution or service.

Deployment Coordination Service (DCS) focuses on the planning, execution, and oversight of all activities required to successfully deploy, migrate, or decommission IT hardware/software into or from the production environment. The DCS provides assurance that the new/enhanced IT solution/service is properly implemented into a production state with minimal disruption to production operations.

Having the distinction between SMR and DCS also aligns with ITIL’s integration into the DevOps software development practice which combines software development and information technology operations to shorten the systems development life cycle while delivering features, fixes and updates frequently in close alignment with business objectives.

2.3 Target audience

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

• Infrastructure Technology Services (ITS)
• I&IT Clusters

2.4 Scope

eRM aims to plan, schedule and control the testing and deployment of application and infrastructure releases to production environments. The primary goal of the Enterprise Release Management process is to facilitate 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 structures are defined, validated, and in place across the end-to-end I&IT supply chain.

eRM also ensures that a "handover" to Operations takes place and that suitable training and documentation exists to ensure ongoing support of the new service

2.4.1 In scope

• updates/changes that impact end users
• activities to build operational support structures
• changes/modifications to existing I&IT infrastructure, solutions or services
• implementation of new / Decommissioning of existing I&IT infrastructure, solutions or services

2.4.2 Out of scope

• updates/changes that do not impact end users
• identifying operational support teams and defining operational processes
• change Management related activities associated with a project
• project Management related activities associated with a release such as technical build, test, certification and deployment

2.5 Applicability statements

2.5.1 Organization

All Ministries and I&IT Clusters are subject to Government of Ontario IT Standards.

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

All other agencies that are using OPS information and information technology products or services are required to comply with Government of Ontario IT standards if they are subject to either the Governance and Management of Information Technology Directive OR Government of Ontario IT Standards by memorandum of understanding.

As new GO IT Standards 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 for ensuring that adequate change control, change management, and risk mitigation mechanisms are in place and employed. For the purposes of this document, any reference to Ministries or the Government includes applicable agencies.

2.5.2 Requirement 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 (for example,, business functionality, security, cost) must be understood and carefully weighed before choosing a different course.

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. The following are some of the key objectives of eRM:

• define and agree upon release activities and plans with customers/Stakeholders
• ensure that both technical and non-technical aspects are considered when a change to an existing IT service or creation of a new service occurs
• deploy into production while protecting the environment’s integrity and establish effective use of service to delivery
• enable greater consistency in how IT services are delivered, driving increased quality and effectiveness at optimum cost and low risk
• ensure that IT production environment changes are managed, tracked and verified during the release deployment and can be backed out if appropriate
• record and manage deviations, risks, issues related to the new or changed infrastructure, solution or service, and take necessary corrective action
• ensure that skills and knowledge are transferred to operations and support staff to enable them to effectively and efficiently deliver, support and maintain the infrastructure, solution or service, according to required warranties and service levels
• improving the service management process across the I&IT organization

3.3. Value to the business

The implementation of the eRM process enables the careful oversight of changes to IT solutions/services ensuring implementation is in accordance with other ITSM processes and aligned with business needs. In addition, eRM enables successful activations by ensuring effective pre-operation communications between all groups involved in IT solution/service projects.

eRM provides value to the organization in the following ways:

Risk reduction

• ability to cope with higher frequency of releases without sacrificing IT service quality
• opportunity to test/pilot prior to launch of service
• 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
• awareness and advanced communications of releases

Cost reduction

• stability in production environment through testing
• reduction in Incidents caused by a poor release
• efficient and effective use of resources by following best practice process

Service quality improvement

• collaterals needed for releasing IT solution/service projects
• accelerated time to value by delivering services to customers on shorter release cycles
• greater success rate of releases with minimal service disruptions while maintaining IT service quality through a unified and controlled release process
• input into IT service descriptions
• input into how IT Services are measured

3.4. Basic concepts

eRM aims to plan, schedule and control the movement of releases to the production environment thus ensuring that the integrity of the production environment is protected and that the correct components are released.

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

3.4.2. Outputs from the process

Outputs from the eRM include:

• release plan / service activation checklist
• Method of Procedure (MoP)
• release announcement
• Go / No-Go decision
• deployment communication
• 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/solutions being released into the production environment.

Rationale

• adopt 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
• avoid rework

Implications

• requires adherence and integration to existing GO-IT standards

Principle 2

A single Release Repository will be utilized to track and manage information for each release as well as act as a document repository for all Supporting Documentation related to each release.

Rationale

• protects accuracy of information by ensuring that only authorized roles can update information
• protects accuracy of information by enabling View / Read Only access
• provides traceability and auditability of releases to the production environment
• provides the ability to 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, etc.).

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 life cycle 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
• own 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
• interface and communicate with I&IT Clusters and ITS 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
• provide leadership and direction to the enterprise release management team
• assign 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
• ensure 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, deployment statistics and configuration status reports, 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
• assess and determine risk to applications through assessment tasks within Change Request(s)
• 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

The Release Coordinator role within the Service Management Readiness 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
  • facilitate Go/No-Go
  • prepare and send Go/No-Go decision communication
  • update Release Repository accordingly
• Deployment
  • monitor / track Post Activation Items during Release stabilization period
  • facilitate any stabilization efforts
  • update Release Repository accordingly
• Close down
  • use closure validation template, 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

The Release Coordinator role within the Deployment Coordination Service 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
  • prepare and chair Release Kick Off Meeting; if required
• Planning
  • ensure information in Release Log and or Release Calendar is accurate
  • accountable to own the planning and/or coordination of all phases of release deployment activities for systems, applications and the production environment
  • ensure Client Communication is scheduled; if required
• Build and test
  • 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
  • develop detailed Method of Procedures (MoPs) for production environment deployments involving numerous stakeholders, clients and vendors to deploy successful I&IT releases; while adhering to the IT Service Management processes
  • facilitate walkthrough of the MoPs to make refinements with deployment teams, identify stakeholders involved and avoid any potential conflicts (for example, infrastructure, resourcing, etc.)
  • facilitates release planning and walkthrough meetings with key stakeholders to identify the appropriate sequencing of deployment activities. This ensures issues and risks are identified and dealt with prior to the deployment schedule
  • provides outage information to stakeholders and ensure a communication to end client is received
• 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 deployment phases of technical releases and ensure Incident Management protocols are followed for necessary escalations to stakeholders
  • setting up communication bridges during production deployments if issues arise or triaging is required
  • coordinate post-deployment activities and validation based on MoP
  • provide Release Stats to Release Manager to distribute to cluster clients through Executive Summary
• Close down
  • coordination of backout, backout verification and communication activities if backout permits

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 meeting to review scope, timelines and tasks
• scope out and identify specific deliverables
• responsible to complete tasks
• report on status of deliverables / issues at status 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/No-Go and provide readiness recommendation response (when applicable)
• help resolve outstanding tasks from Pre Go/No-Go (when applicable)
• attend final Go/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 ITS 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 etc.
• represents the service across the organization
• understands the service (components etc.)
• 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 a 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 / 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 / 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)
• validate release costs with intake group
• attend release-related meetings (for example, Kick-off, Status Updates and Go/No-Go),
• provide project updates on service technology and user development status / 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 Enterprise Relationship Management (ERM) to liaise with the Cluster/customer
• include Release Management in Post Implementation Review and/or Lessons Learned activities (when applicable)

DCS

• provide deployment-related resources from the application, technical team and business (when applicable)
• liaise between the business/application resources and the portfolio resources to schedule release deployment change windows that will have minimal impact and risk to the service, the production environment and shared infrastructure
• provide MoP(s) to the Release Coordinator to create a single MoP for execution (when applicable)
• attend release-related meetings (for example, Kick-off, Walkthrough Meetings and Deployment Status Updates) (when applicable)
• communicates application service outage windows to the CIOs office (when applicable)
• include Release Management in 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 Enterprise Relationship Management to the Service Owner and/or his/her 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, etc. to the production environment.

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, etc.

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 includes Service Owners and Release Stakeholders impacted by the change.

Initiative complexity and effort sizing (ICE)
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.

ITS release resource calendar
A word document which contains the deployment and release schedule for the Deployment Coordination Service.

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 (ie. Simplified, Detailed, Vendor, etc).

Opportunity assessment
The Opportunity Assessment is a meeting between Enterprise Relationship Management and the Project Manager 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 / Release objectives that is sent to a set distribution list of stakeholders. This Distribution List includes ITS Management.

Release calendar
A Release Calendar includes a forward schedule of approved upcoming release deployments specific to a portfolio within eRM.

Release deployment status update
Release Deployment Status Update(s) 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, etc.

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 log
A Release Log includes the approved upcoming release deployments specific to a portfolio within eRM for the year. Details may include: Service Outage, Impacted Application(s), Change Request date and time, etc.

Release plan
A document used to outline and track the deliverables for each Stakeholder participating in a given 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, etc.).

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 the Operational Readiness Service.

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 / 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/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

• 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 information
• communications

Phase 3 - Build and test

• release log and calendar
• 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 four 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 / 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 / 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/groups such as Lines of Business, Branch or Section
• service change to existing service affecting multiple businesses
• requires 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/technologies
• decommissioning or retiring services
• has potential to impact end user experience / 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 / Pilot

Extensive / Widespread (Large)

Release criteria

• major new service introduction
• other release jurisdictions impact (med-high)
• impacts public safety or public facing business service
• multiple ministries wide business impact
• requires senior executive approval
• executive office / 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, etc.
• 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 below. Note: Services identified as being required for the different release types below may not be applicable based on individual release requirements.

* Note: Includes Planning and Deployment Activities

** Note: A Simplified and/or Full Release may need to be completed within 1 to 2 days if the CRQ is Urgent and Unplanned (UU).

Simplified release

• Method of Procedure is a required collateral
• coordinated via working group e-mail thread or confirmed upon validation
• may or may not include a Release Deployment Management Status Update upon completion
• suitable for small release deployments that are or may be:
  • planning to implement a small number of deployment tasks
  • used to coordinate deployment validation activities (When applicable)
• may include source code management coordination
• PM or Technical Lead may coordinate deployment activities or confirm completion
• CRQ creation is not required
• may include service/application outages

Full release

• Method of Procedure is a required collateral
• coordinated through Working Group E-mail Thread or Task E-mails
• can be used for net new application release or high impact application enhancements
• work is dedicated to one project
• stakeholder Walkthrough Meetings lead by Release Coordinator
• source code management coordination (When applicable)
• may include service/application outages
• release Deployment Status Updates / Communication Coordination required
• requirement to manage post deployment activities (When applicable)
• outline of Back-out activities is required

Operational and maintenance releases

• Method of Procedure Document (If Applicable)
• scheduled releases with appropriate CRQ lead time
• additional documentation required as part of release collateral (ie. kick-off presentation, etc)
• requires engagement between ITS and eRM to discuss scope requirements
• may include an SMR component only tracked by the DCS RC
• may impact one or more OPS ministries and/or jurisdictions
• kick-off presentation / chaired meeting
• deployment strategy and consultation required with Project Team
• communication strategy can differ per project and is required to be discussed
• stakeholder Walkthrough Meetings lead by release coordinator
• radia deployment (When applicable; core focus or subprocess)
• may include Pilot Testing activities
• source code coordination and promotions (when applicable)
• include service/application outages and I&IT Client Communications
• release deployment status updates
• CRQ Management (Drafting and Submitting to be completed by Project Team)
• complex communication coordination required
• requirement to manage post deployment activities

3.8. Process workflow description for the operational readiness service

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

Engage release management

Input/Trigger

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

Description

• Release Manager receives request for Release Management engagement from Enterprise Relationship Management 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. Enterprise Relationship Management updates Dynamics CRM application to note Release activities are required.
• If SMR activities are not required, Release Manager advises Enterprise Relationship Management to engage appropriate Stakeholder groups. Enterprise Relationship Management Updates Dynamics CRM application to note Release Management activities are not required.

Output/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 / Service Owner representation
• drafts Kick-off presentation

Output/Completion criteria

• updated Release Record
• finalized Release Announcement
• draft Kick-off presentation

Common release record status

Planning Milestone

Distribute release announcement

Input/Trigger

Release Announcement

Description

Release Coordinator distributes Release Announcement email to Stakeholders

Output/Completion criteria

Release Announcement email

Common release record status

Planning Milestone

Facilitate kick off

Input/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/Completion criteria

• updated Release record(s) with dates, collaterals and Stakeholders
• finalized Release Plan

Common release record status

Build Milestone

Release status meetings

Input/Trigger

Kick-off Meeting or No-Go Decision

Description

Release Coordinator:

• schedules recurring Release status update meetings
• facilitates end-to-end process/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/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 / No Go

Input/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/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/Trigger

Go/No-Go "YES" Decision

Description

• if Deployment Coordination Services are not required for the Release:
  • deployment of service/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/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 Operation Readiness Release Coordinator of status of the deployment
  • operational readiness release coordinator sends email to Stakeholders advising of result of deployment
• if deployment fails, return to 5.0 to resume Release Status Meetings
• Operational Readiness Release Coordinator updates Release Record with result of deployment

Output/Completion criteria

• stakeholders receive email advising of result of deployment
• updated Release record(s) with result of deployment
• service / solution is now live

Common release record status

Deployment Milestone

Monitor operations impact

Input/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/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/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/Completion criteria

• updated Release Record(s) with status/issues and completed action items during the stabilization period
• updated Service field

Common release record status

Close Down Milestone

Close down

Input/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\triggers, description, output\completion criteria and common release record status for each process step in the Deployment Coordination Service workflow.

Engage release management

Input/Trigger

• Release Management Assessment Task/eSMT Change Request (CRQ)
• Cluster Clients/Release Committees
• Enterprise Relationship Management
• 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 Enterprise Relationship Management via SPIM.

Output/Completion criteria

• proceed to assess Release/Change Request Process (2.0)
• meeting may take place between Release Management and Enterprise Relationship Management or a Cluster Client to distinguish release requirements
• Release Manager may request Change Request creation if required

Assess change request

Input/Trigger

Release Management Assessment Task / Change Request (CRQ)

Description

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

Output/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
• implementation task is added by Release Manager for eRM within eSMT Change Management Module

Determine release type

Input/Trigger

• scope of Change Request
• determine Release Type
• project collateral

Description

• Release Manager/ Release Coordinator determines the Type of Release required – depending on scope (Simplified Release, Full Release, Operational Maintenance Project Releases). Enterprise Relationship Management updates Dynamics CRM.
• Release Manager/Release Coordinator will update the Release Log and or Release Calendar to reflect information captured in the Change Request. It may or may not include the type of MoP required as well.

Output/Completion criteria

• proceed to assign a Release Coordinator (4.0)
• release type determined
• portfolio specific Release Logs and or Release Calendars are updated with Forward Schedule of Changes
• discussions and review of Forward Schedule of Changes at Team Meetings with Release Coordinators for adjustments; if required

Assign a release coordinator

Input/Trigger

• assessment task is closed
• reference to the ITS Release Resource Calendar

Description

• If DCS activities are required, Release Manager assigns Release Coordinator(s) based on the ITS Release Resource Calendar and project scope.
• If more than one Release Coordinator is assigned; Release Coordinators distribute or divide the workload.

Output/Completion criteria

• Release Coordinator assigned
• Change Request details retrieved
• Release Log and/or Calendar reviewed
• Release record created

Identify collateral and prepare for release

Input/Trigger

• Release Type determined
• assignment of a Release Coordinator to a deployment in the Release Log and or Calendar
• draft of release collateral
• access Restrictions or Application Service Outages during a deployment window
• impacted application(s) or service(s)

Description

• Release Coordinator will identify and prepare release collateral (for example, MoP, CRQs) 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.
• If Impacted Application(s) or Service(s) will experience an outage, ensure I&IT Scheduled Maintenance Management Announcement is drafted or ITSM Communications group is engaged (when applicable).

Output/Completion criteria

• when applicable, the following collateral (may) be drafted:
  • Kick Off Presentation
  • Release Content
  • Release Plan
  • Release Questionnaire
  • CRQ(s)
  • MoP
  • Contact List
  • Release Deployment Status Updates
  • I&IT Scheduled Maintenance Announcement
• Technical, Business and Application Resources obtained
• Move Release Record to Planning Phase

Gather and manage content to update release collateral

Input/Trigger

• release Deployment Type Determined
• vendor MoPs Gathered
• feedback from Walkthrough Meetings
• Release Collateral
• Stakeholder Feedback
• Change Request Details

Description

Release Coordinator is responsible for:

• reaching out to portfolio/cluster management teams to gather release deployment resources and contact information to hold Kick Off Meeting/Walk through meetings
• conducting one or more Walkthrough Meeting(s) to gather specific technical contents from Subject Matter Experts, Stakeholders and/or Project Managers to update the MoP
• working with Project Managers and Stakeholders to collect and receive input, data and collateral necessary to complete all Release Collateral previously drafted in process 5.0

Output/Completion criteria

• when applicable, the following collateral will be updated:
  • Kick Off Presentation
  • Release Content
  • Release Plan
  • Release Questionnaire
  • CRQ(s)
  • MoP
  • Contact List
  • Release Deployment Status Updates
  • I&IT Scheduled Maintenance Announcement
• Technical, Business and Application Resources confirmed

Finalize and complete release collateral

Input/Trigger

• final Walkthrough Meeting
• stakeholder 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 all supporting documentation to Change Request and Release Record after release collateral is finalized.
• Release Coordinator will prepare deployment e-mail thread (when applicable).
• Release Coordinator provides deployment status to Release Manager at weekly deployment readiness meeting.

Output/Completion criteria

• finalized Release Collateral (attached to Change Request)
• status updates finalized
• executive summary status update
• working group e-mail thread drafted (when applicable)
• task e-mail draft (when applicable)

Deploy, manage and coordinate release activities

Input/Trigger

• finalized MoP
• Change Request approved
• deployment activities are scheduled to begin
• working group e-mail thread

Description

• Release Coordinator is responsible for deploying, managing and coordinating release deployment activities including Pre-Deployment Activities and Go Live tasks.
• If the Change Request (CRQ) is approved, the release coordinator can begin coordinating activities as per the MoP.
• Release Coordinator will coordinate pre-deployment activities. These activities are pre-requisites to the deployment activities.
• Release Coordinator will begin coordinating deployment activities when the pre-deployment activities are successfully completed.
• During the deployment, teleconference bridges may be utilized 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)
• The Release Coordinator will send scheduled Management Deployment Status Updates to Executives, Management Teams, Stakeholders, etc.
• potential Lessons Learned items captured (if applicable)
• technical, business and or application resources validate that the deployment activities were completed successfully
• upon completion of the deployment, the Release Coordinator will send a final Release Deployment Status Update to executives, management, etc.
• 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 Back Out

Output/Completion criteria

• unforeseen deployment issues are resolved or tracked
• service outages are managed
• pre-deployment activities complete
• deployment activities complete
• teleconference calls (triage or checkpoints)
• release status updates
• release deployment validated
• management deployment status updates sent (when applicable)
• issues managed or result in executive decisions on deployment backout activities
• Move Release Record to Deployment Phase

Initiate back out (If applicable)

Input/Trigger

• unsuccessful Pre-Deployment, Deployment and/or Validation activities
• executive and/or Management approval

Description

• If validation of release is unsuccessful, a teleconference is chaired with executives, management, etc. to receive approval to initiate back out activities.
• Once stakeholder management approval is received, the Release Coordinator will coordinate back out activities.
• Assigned technical, business and or application resources validate the back out 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.

Output/Completion criteria

Back out completed

Close down

Input/Trigger

• deployment completed
• back out completed (if required)
• deployment validation completed successfully
• input from Project Managers / Stakeholders

Description

• If Post Deployment activities listed in the MoP(s) are scheduled the Release Coordinator will coordinate activities.
• The Final Deployment Status is attached to Release Record and Change Request for auditing purposes.
• Release Coordinator provides release stats to Release Manager at the weekly post-deployment team meeting.
• Release Coordinator sends e-mail to stakeholders involved in the Release to gather feedback / lessons learned from the deployment (when applicable).

Output/Completion criteria

• Post Deployment Activities completed
• Close Release Record

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/I&IT Cluster: Division: MPBSD, Division: Infrastructure Technology Services

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/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/I&IT Cluster: MPBSD
Division: Infrastructure Technology Services
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

2^nd support role

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

2^nd 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 any of the above

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 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.

10.2 Informative references

1.13. 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

1.14. 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.

1.14.1. 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

1.14.2. 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.