GO-ITS 40 Enterprise Release Management

Document history

Requirements levels

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

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

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

Foreword

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

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

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

Applicability

All ministries and I&IT clusters are subject to GO IT standards.

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

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

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

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

Introduction

Background and rationale

The GO-ITS 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.

Target audience

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

• Infrastructure Technology Services (ITS)
• Strategy and Cyber Security (SCS)
• I&IT clusters.

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.

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.

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.

Technical specification

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.

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 each release package consists of a set of related assets and service components that are compatible with each other and the production environment they are being released into
• Ensure that integrity of a release package and its constituent components is maintained throughout the transition activities and recorded accurately in the configuration management database
• Ensure that all release and deployment packages can be tracked, installed, tested, verified, and/or uninstalled or backed out, if appropriate
• Ensure that IT environment changes are managed during the release and deployment activities
• Record and manage deviations, risks, issues related to the new or changed infrastructure, solution or service, and take necessary corrective action
• Ensure that there is knowledge transfer to enable the customers and users to optimise their use of the infrastructure, solution or service to support their business activities
• 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.

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.
• 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.
• Greater success rate of releases as result of following a consistent release process.
• Minimal disruption to service.
• Input into IT service descriptions.
• Input into how IT services are measured.

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.

Inputs to the process

Inputs to the eRM process include:

• Email
• Telephone
• Meeting
• Committee
• Work Intake Review Committee (WIRC)
• Low Intensity Project Mgt. (LIRC)
• Service-Planning-Activation-Release-Kick-Off for Enterprise Services (SPARKES)
• Integrated Enterprise Service Activation

Outputs from the process

Outputs from the eRM include:

• Release plan/service activation checklist
• Release announcement
• Go / No-Go decision
• Deployment communication
• Scorecard
• Satisfied customer

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-ITS 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 audit-ability 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 (i.e. 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.

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.
• eRM activities and deliverables will need to be formally documented, managed and available to relevant stakeholders.

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

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

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

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.
• Identifies functional requirements for the release repository in conjunction with other ITSM Process Managers; conducts acceptance testing for modifications to enabling technology.
• Obtains support for new or changes to existing Enterprise Release Management 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, and configuration status reports, including an analysis of the results to identify issues and make corresponding recommendations to address them.
• Assists auditors to audit the operational activities of the eRM process for compliance with laid-down procedures; ensures that recommended corrective action is carried out.
• Receives release requests, schedules assessments to determine scope and type and assigns a Prime Release Coordinator if required.
• Sends release announcement.

Prime Release Coordinator

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

Accountabilities:

• Initiate
  • Assist in performing assessments; determine scope, priority, impact and urgency.
• Planning
  • Validate output of release assessment.
  • 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 to completion.
  • Facilitate any stabilization efforts.
  • Complete release management scorecards.
  • Update release repository accordingly.
• Close down
  • Use closure validation template, get 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.

Release Coordinator

Release Coordinators participate in eRM as a stakeholder when their release jurisdiction is impacted by the release.

Accountabilities

• Participate in Enterprise Release Management process.
• Attend release assessment and input into scope and release type.
• Attend release kick-off meeting to review scope, timelines and tasks.
• Scope out and identify specific deliverables.
• Responsible to complete release deliverables.
• Report on deliverables status/issues at status meetings.
• Coordinate testing.
• Send all collaterals to Prime 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 jurisdiction post-activation feedback to Prime Release Coordinator.
• Update release repository accordingly.

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 deliverables status/issues at status meetings.
• Perform testing.
• Send all collaterals to Prime 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 Prime Release Coordinator.

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

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 (CAB) 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).

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:

• Provide necessary information required to complete release assessment template.
• Provide an approved project charter with required signatures (when applicable).
• Validate release costs with Release Manager.
• Attend release-related meetings (e.g. 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 in order to assist in the completion of eRM activities.
• Work with the Customer Relationship Management (CRM) team to liaise with the cluster/customer.
• Provide the Prime Release Coordinator with a project post implementation review.

Concepts and definitions

Key terms

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 list provides a high level overview of the eRM process.

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 & Training
• Stakeholders
• Communications

Phase 3 - Build:

• Build Support
• Build Collateral & Training
• Plan for Pilot (if required)
• Build Communications
• Workshop Activities

Phase 4 - Test:

• Execute the Pilot
• Go/No-Go
• Send Communications

Phase 5 - Deployment:

• Activation/ Deployment
• Stabilization Period
• Maintain Issue Log
• Reporting
• Communicate Results

Phase 6 - Close down:

• Create Scorecard
• Lessons Learned
• Send Closing Communications
• Close Release Record

Release types

Each release can be categorized as one of four types based on impact and urgency. The following is a description of each release type including release criteria, level of work effort and estimated timelines.

Minor/localized

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.

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.
• Requires Change Request (CRQ).

Moderate/limited

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.

Level or work effort and estimated timelines

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

Significant/large

Release criteria

• Multi-release jurisdictions required.
• Registered Project required
• New service for small group or specialized user/groups e.g. Lines of business, branch or section.
• Service change to existing service affecting multiple businesses.
• Requires internal approvals by governing bodies e.g. ITSML, ACT/ARB.
• Multi party service chain.
• Moderate end user involvement.
• Requires training e.g. 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 e.g. major technology upgrade visible to users.

Level or 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

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 e.g. legislation, privacy, political.
• Significant resource requirement.
• IT standard or legislation driven implementation end date.
• New service provider or owner (e.g. 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.

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

Release milestones

The following is a description of the activities that occur within each release milestone at a high level.

Initiate

A release request is made and entered in the release repository. A release assessment is held with the Project Manager and impacted cluster release leads.

Planning

A release announcement is sent to potential release stakeholder groups to communicate the upcoming release.

Build

The release kick-off is held and release team stakeholder deliverables are confirmed and communicated .

Recurring release status meetings are scheduled to track the status of release deliverables.

Test

Any sort of end-to-end testing activities are completed in this milestone. The pre Go/No-Go and Go/No-Go meetings are held. Decision from the Go/No-Go meeting is communicated and if the decision is a “Go” or “Go with action”, we move to the deployment milestone.

If the decision is not a Go, we move back to the build milestone and resume release meetings.

Deployment

Any post activation items from the Go/No-Go meeting are monitored and tracked to completion during the stabilization phase which occurs in this milestone.

Close down

Confirmation that release activities have been completed and the release can be closed.

Process workflow description

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

Engage Release Management

Inputs / Triggers

• E-mail
• Telephone
• Meeting
• Committee
• Work Intake Review Committee (WIRC)
• Low Intensity Project Management (LIPM)
• Service Planning Activation Release Kick Off for Enterprise Services (SPARKES)
• Integrated Enterprise Service Activation

Description

• Release Manager receives request for Release Management engagement
• Release Manager reviews the request
• Release Manager determines if other Release jurisdictions are impacted. If other Release jurisdictions are impacted, engage applicable Release Coordinator(s) to participate in joint assessment. If other Release jurisdictions are not impacted, Release Management to complete assessment internally.
• Release Manager schedules a meeting to assess the project with Project Manager and other Release jurisdictions (if applicable)

Output / Completion Criteria

• Applicable Release Coordinator(s) engaged, if required
• Meeting scheduled with PM and impacted Jurisdictions (if required)

Common Release Record Status

• Not Applicable for this stage

Assess Release Using “Criteria Assessment Template”

Inputs / Triggers

• Release Management assessment meeting
• Project Charter
• Project Collaterals (e.g. Plan)
• Work Intake Assessment (WIA)  Description

Description

• Release Manager/Prime Release Coordinator walks through Assessment Criteria template with Project Manager
• Release Manager/Prime Release Coordinator collects information about scope of project
• Release Manager/Prime Release Coordinator determines scope, impact, urgency and priority of the Release
• Release Manager assigns Prime Release Coordinator to project (if applicable)
• All Release Coordinators (including Prime) create a new Release Record
• All Release Coordinators (including Prime) use the appropriate Release Template for the Release:
• If Release is initiated, use the “Active Release” template
• If Release is not initiated, use the “Consulted” template
• Release Manager/Prime Release Coordinator sends email to all participants of the Assessment meeting indicating Release Management involvement
• Confirmation of  actual Prime Release Coordinator (if applicable)

Output / Completion Criteria

• Release record(s) created
• Participants receive email for the Assessment meeting indicating Release Management involvement
• Confirmation of  actual Prime Release Coordinator (if applicable)

Common Release Record Status

• Initiate Milestone

Create Release Plan

Inputs / Triggers

• Assignment of Prime Release Coordinator
• Project Plan Template
• Project Collaterals
• Assessment Criteria Template

Description

• Prime Release Coordinator:
• Consults with Project Manager and Stakeholders to identify timelines etc. using Enterprise Release Management templates
• Creates Release Plan/ Service Activation checklist
• Creates Release Announcement
• Drafts Release Kick-off presentation
• Prime Release Coordinator updates Release Record including proposed timelines
• Prime Release Coordinator finalizes Release Plan/ Service Activation checklist
• Prime Release Coordinator finalizes Release Announcement
• Prime Release Coordinator drafts Kick-off presentation

Output / Completion Criteria

• Updated Release Record
• Finalized Release Plan/ Service Activation checklist
• Finalized Release Announcement
• Draft Kick-off presentation

Common Release Record Status

• Planning Milestone

Distribute Release Announcement

Inputs / Triggers

• Release Announcement

Description

• Release Manager distribute Release Announcement e-mail to Stakeholders

Output / Completion Criteria

• Release Announcement e-mail

Common Release Record Status

• Planning Milestone

Facilitate Kick Off

Inputs / Triggers

• Draft Kick-off presentation

Description

• Prime Release Coordinator works with Project Manager to finalize Release Management Kick-off presentation
• Prime 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
• Define next steps for Stakeholder workshops
• Prime Release Coordinator facilitated Release Management Kick-off meeting
• Prime Release Coordinator validated Stakeholders and their deliverables
• All Release Coordinators  involved (including Prime) update Release Management record with dates, collaterals and Stakeholders

Output / Completion Criteria

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

Common Release Record Status

• Build Milestone

Release Status Meetings

Inputs / Triggers

• Kick-off Meeting or No-Go Decision

Description

• Prime Release Coordinator schedules recurring Release status update meetings
• Prime Release Coordinator facilitates end-to-end process/pilot testing, where required
• Prime Release Coordinator drafts Go / No-Go presentation
• Prime Release Coordinator distributes meeting minutes after each Release status update meeting
• Prime Release Coordinator tracks completion of Stakeholder deliverables
• All Release Coordinators (including Prime) involved update Release Management record with issues, timelines and relevant associations
• All Release Coordinators  involved (including Prime) update Release Management record with dates, collaterals and Stakeholders

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

Inputs / Triggers

• Go / No-Go Presentation

Description

• Prime Release Coordinator works with stakeholders to finalize Release Management Go / No-Go presentation
• Prime Release Coordinator facilitates Go / No-Go
• All Release Coordinators involved (including Prime) update 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.
• Prime Release Coordinator sends all Stakeholders an email with the outcome from Go / No-Go meeting
• If No-Go, return to 6.0 to resume Release Status Meetings

Output / Completion Criteria

• Go / No-Go Decision
• Update Release record (s)

Common Release Record Status

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

Release Deployment

Inputs / Triggers

• “Yes” Decision from Go / No-Go Meeting

Description

• Deployment of service /solution led by Project Manager
• Deployment activities are coordinated by the Project Manager or Prime Release Coordinator
• Deployment activities are monitored by Prime Release Coordinator
• Project Manager confirms success/failure of deployment
• Prime Release Coordinator communicates result to Stakeholders
• If deployment fails, return to 6.0 to resume Release Status Meetings
• Prime Release Coordinator sends email to Stakeholders advising of result of deployment
• All Release Coordinators involved  (including Prime) update Release Record with result of deployment

Output / Completion Criteria

• Stakeholders receive e-mail advising of result of deployment
• Update Release record (s) with result of deployment
• Service / solution is now live.

Common Release Record Status

• Deployment Milestone

Monitor Operations Impact

Inputs / Triggers

• Result of Deployment

Description

• Prime 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 Prime Release Coordinator
• All Release Coordinators involved provide any/all jurisdictional post activation feedback to the Prime Release Coordinator
• Prime Release Coordinator informs impacted Stakeholders of any issues to ensure remediation activities occur
• Prime Release Coordinator tracks any action items from the Go/No-Go and informs stakeholders on status until completed
• Prime Release Coordinator requests Incident Impact Report from ITS Performance Measurement
• All Release Coordinators (including Prime) involved 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
• Request for Incident Impact Report

Common Release Record Status

• Close Down Milestone

Compile Feedback Report

Inputs / Triggers

• Incident Impact Report
• End of stabilization period

Description

• Prime Release Coordinator sends email to Project Manager to confirm completion of Release Management activities
• Prime Release Coordinator creates and completed Scorecard
• Prime Release Coordinator sends Release Record Closure Validation email to Stakeholders
• Prime Release Coordinator reviews Release Record to ensure all information gathered and recorded in alignment with Enterprise Release Management Process & Procedures Guide
• All Release Coordinators (including Prime) update Release Record Status to “Closed”

Output / Completion Criteria

• Completed Scorecard
• Closure Validation email distributed to Stakeholders
• Updated Release Record Status to “Close Down”

Common Release Record Status

• Close Down Milestone

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 also for strategic decision support.

Related standards

Impacts to existing standards

Impacts to existing infrastructure

Compliance requirements

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

Roles and responsibilities

Accountable role (standard owner) definition

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

Accountable role

Title: Chair, IT Service Management Leads (ITSML)
Ministry/I&IT Cluster: TBS Division: ITS

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: TBS Division: ITS Branch: Service Management

Support role definition

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

Support role (editor)

Ministry: Ministry of Government and Consumer Services (MGCS)
Division: Infrastructure Technology Services
Branch: Service Management Process & Operations
Section: ITSM Processes
Job Title: Senior Manager
Name: Arpad Martonosi
Phone: (519) 830-6431
Email: Arpad.Martonosi@ontario.ca

Job Title: Delegate:

Name: Dwayne Leach (Practice Lead)
Phone: (905) 359-1278
Email: Dwayne.Leach@ontario.ca

Consultations

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

Appendices

Normative references

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.

Informative references

Not applicable.

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

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. In this case, our Level 1 Tasks are the Processes that are defined within this eRM Go-ITS 40 Enterprise Release Management document.

• Level 2 Tasks are defined in procedures which break down each level 1 task into more granular operational tasks, and additionally, prescribe how the activity should be performed. For example, in eRM we have an eRM Process and Procedures Guide which would define the various procedures within the eRM Process, such as “Engage Release Management”, “Create a Release Plan”, “Facilitate the Kick Off Meeting”, etc.

• Level 3 Tasks represent work instructions. Work instructions are a further breakdown of procedure-level tasks which typically are defined to address any unique local requirements when performing procedural tasks. For example, within eRM, the Health Services Cluster (HSC) may have a localized set of working instructions unique to their business and clients and the Central Agencies Cluster (CAC), may also have a separate set of localized working instructions which meets their business needs.

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.

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.

Local procedure guide content

All process standard content plus:

• Local operational principles, guidelines and activities.
• Business-specific standards.
• 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.

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 CRQCRQ will transition through various states throughout its lifecycle.

Configuration Item (CI)

Any component that needs to be managed in order 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, 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.

ITSML:

A forum where OPS IT Service Management Leads (ITSML) 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 (i.e. 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.

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 on a day-to-day basis. Users are distinct from customers, as some customers do not use the IT services directly.