IT Service Level Requirements Template

Service Level Requirements (SLR)

[the_ad id=”667″]

It is the collection of requirements that is gathered by the IT service provider detailing the service requirements with respect to description of the service, availability, capacity, continuity, service level objectives, service level targets, suppliers needed, roles and responsibilities needed, etc.
SLR’s are the initial documents prepared by the service provider, with reference to the discussions made with the customer. Based on the SLR’s, service level objectives and service level targets will be drafted, negotiated, agreed and consolidated into SLA’s.


  • To define the functionality and non-functional requirements of the IT service.
  • To define the core service, enabling service, and enticing services.
  • To define the utility and warranty specifications.
  • To capture all the customer requirements as defined without missing any information.

Transfiguration of SLR to SLA

[the_ad id=”667″]

IT Service Level Requirements Template
IT Service Level Requirements
Sl. No. Procedure Description
1 Requirement understanding from customer
  • Service Level Management team will understand the initial requirements from the customer which could be gathered through emails, documents, direct conversations in meetings or phone calls.
  • The focus areas in gathering requirements would be:
    • Understanding service description
    • Understanding the service start date
    • Service success criteria
    • Service availability
    • Service capacity
    • Planned service interruptions
    • Security requirements with respect to identity and access
    • Business continuity
2 Drafting SLR’s After gathering requirements, the service level management team and design coordination manager will refine those gathered requirements and will document them into a document called service level requirements. Drafted SLR’s are then sent to the customer for their consent. If the customer doesn’t agree, then the requirements are gathered again.
3 Approved SLR If the drafted SLR’s are as per customer expectations, then the customer would approve the SLR’s.
4 Preparation of SLO’s and SLT’s Based on the approval of SLR’s, SLO’s and SLT’s are prepared by the service level management team.
SLT: Targets, which are SMART (Specific, Measurable, Achievable, Relevant, and Timebound) and is usually based on KPIs.
SLO: Objectives, which define the service description and criteria.
5 Drafting, negotiating and standardizing SLA’s
  • Service level management team along with Supplier management, IT service continuity management, Availability, Capacity, Information Security management teams will draft the SLA’s.
  • Then SLA’s are negotiated with the customer.
  • After the negotiations, the SLA’s are standardized, defined and published to all stakeholders.

Service availability: Details the service availability for example:
Service availability during weekdays, weekends, timings

Service capacity: Details the service capacity for example:
Number of users who can use the service concurrently
Number of transactions to be processed at a point of time
Peak usage during days, weeks, months, or seasons

Service security: Details the service security for example:
Confidentiality, integrity, availability and non-repudiation with respect to IT systems
Confidentiality, integrity, availability and non-repudiation with respect to user credentials

Service continuity: Details the service continuity for example:
Recovery procedures & restoration procedures for IT systems

Download IT Service Level Requirements Template

Release Testing and Verification – ITIL Release Management

Release Testing

Release testing and validation contributes to quality control and assurance of a new release that is Fit-for-Purpose and Fit-for-Use.

Release Testing and Verification, ITIL Release Management
Release Testing and Verification

Release Testing & Verification provides objective evidence that a release of a new or changed service and its service components will support both the customer’s business and the stakeholders’ requirements, including agreed-to service levels. This activity assesses, and addresses issues, errors, and risks identified throughout release life cycle.

Release testing and verification

Release testing and verification is an important activity in release and deployment management which can be explained through the <> phases as:

  • Defining the release test strategy
  • Defining release test models
  • Selecting the type of testing
  • Test execution

Defining the release test strategy:

Test strategy should define the methodology to test and allocate testing resources, which needs to be developed with appropriate stakeholders with respect to the release. To do an effective testing, release management should understand the precise requirements on availability, capacity, performance, security, etc. to plan and design the test approach using information from the service package, SLPs, and SDP.

Defining release test models:

Test models should define the test plans for different types of releases, which should describe what is to be tested, how it is to be tested, and the test scripts defining how each feature and aspect of a release will be tested. A test model defines some predefined and repeatable steps for a release in an effective and efficient way.

Selecting the type of testing:

Type of testing will vary depending on the scope, requirements, risks, constraints, etc. hence there can be different approaches.
Some of the common release test types are service requirements testing, service level testing, service testing, operations testing, deployment release testing, deployment installation testing, and deployment verification testing.

Service requirements testing will verify and validate if the service provider has delivered the service as per the customer requirements.

Service level testing will verify & validate if the service provider can deliver the requirements as per the defined SLA’s.

Service testing will verify and validate if the service provider can manage the new or changed service.

Operations testing will verify and validate if the operations teams like service desk, application management, technical management, etc. can provide the support for new or changed service.
Deployment release testing will verify and validate if the deployment team can deploy the release into the environment in the defined SLA’s.

Deployment installation testing will verify and validate if the deployment team can do the installation of the release components into the environment in the defined SLA’s.
Deployment verification testing will verify and validate if the deployment team has successfully completed the deployment and meets the business requirements and customer acceptance criteria.

Some of the common test types in functionality of a release would be component and assembly testing, release package testing, operational readiness testing, and acceptance testing.
Some of the common test types in non-functionality of a release would be usability, accessibility, availability, security testing, etc.

Test execution

Test execution on releases involves prime activities like:

  • Defining the test plan, schedule of milestones, delivery dates, hardware and software resources needed
  • Preparation of test environment
  • Performing tests and documenting the findings
  • Evaluation of the results with respect to expected results
  • Clean-up and closure of the test environment

IT Service Delivery | Service Delivery Status Report Template

Service Delivery Management

Service delivery status report is an top level service delivery management report which highlights all the achievements, progress and issues happening in ITSM projects.

[the_ad id=”667″]

IT Service Delivery, Service Delivery Management,Service Delivery Status Report
Service Delivery Status Report Template

Service Delivery Status Report

Service delivery status report has to be sent to the customer management team regularly based on the agreed requirements like weekly/ monthly/ quarterly. This report has to be prepared by the IT service provider’s team ensuring all the data is accurate and signed by all the IT service provider’s top-level management.

Why do we need service delivery status report?

Below are some more detailed points elaborating the importance of service delivery status report:

  • To communicate regularly with the customer team.
  • To provide accurate, useful information on the ITSM projects to the customer team.
  • To provide consolidated summary on IT service management projects.
  • Help the customer management to make quick and wise decisions with the reports provided.

Download IT Service Delivery Status Report Template

What is Project Management and its Importance in ITSM

Project management

Project management is the art of managing the project and fulfilling the goals of the project as per the defined time, scope, cost, and quality targets.

[the_ad id=”667″]

Project Management, Project Management and its importance in ITSM
Project Management

Note: Project is any temporary work that has a defined starting time and end time with some defined outputs.

Project management has become an integral practice in any organization, irrespective of the industry (like banking, health care, chemical, manufacturing, hospitality, construction, etc.).

Project management can be broadly classified into 5 phases as initiation, planning, execution, monitoring and closing.

Some of the prime processes that should be there in project management are scope management, risk management, cost management, procurement management, quality management, schedule management, communications management, etc.

Why do we need project management?

Project management practice is essential to follow a defined a process in initiating, planning, executing, monitoring and controlling the project activities which meets the customer requirements and commitments as promised by the service provider.

Below are some more detailed points elaborating the importance of project management:

  • To ensure the project gets completed in time as promised to the customer
  • To ensure the project is not exceeding the planned budget
  • To ensure there is no scope creep.
  • To schedule the work in an appropriate order as per the priorities of customer
  • To identify the potential risks & dependencies in the project work
  • To provide a communication channel to the customer, who can provide the updates and progress on the project status.

Some of the important project management methodologies which are currently popular are Agile, Scrum, & Devops. Certifications that are available in project management are PMP (Project Management Professional), PRINCE2 (Projects in controlled environment), etc.

Project Management Professional (PMP)

Project management professionals can be primarily classified into two categories as project manager and project management coordinator.

Project managers are accountable for delivering the project outcomes, this role will have to plan and organize schemes, resources and people ensuring that the project work is on time, in scope and in budget. This role will have to track the work to be completed, set deadlines and delegate tasks to the project team, identifying any potential risks.

Project management coordinator/ officer works reporting to the project manager to assist and support specific teams on a project. Project Coordinator plans, organizes, and administers projects and coordinates the work assigned to associates on the project teams.

Responsibilities of Project Manager

  • Plan, monitor the work and set deadlines to make sure the project is on time, cost, scope and budget.
  • Motivate project team, co-ordinate the work, identify and manage risks and delegate tasks to the right human resources.
  • Act as a liaison with all internal and external stakeholders, and report regularly to management.

Responsibilities of Project Management Coordinator / Officer

  • Executing administrative duties such as coordinating and scheduling meetings, preparing agendas, and documenting minutes of the meeting.
  • Managing and tracking detailed tasks, milestones and risks in MS Project, Excel and MS PowerPoint.
  • Preparing and assisting the project manager in creating weekly and monthly status reports.

Project management in ITSM

[the_ad id=”667″]

Project management will play a very important role in IT Service Management, because even ITSM’s focus is on achieving outcomes that is customer satisfaction with respect to incident resolution and closure, service request fulfilment and closure, change implementation and closure, problem resolution and closure, etc. in defined timelines, cost, scope and quality parameters.

As project management has five phases initiation, planning, execution, monitoring and closure; in the same way, ITSM can be categorized into five phases as service strategy, service design, service transition, service operations, and continual service improvement.

Though we cannot map the five phases of project management to IT service management, yet the phases, processes, principles and best practices of project management can be implemented in all the 26 processes and 4 functions of ITSM.

For example, implementing and operating incident management:

To implement incident management as a process and execute the operations, you would need an incident manager and incident analysts as human resources, who can follow the resource management process in project management. To maintain quality in incident management, IT governance team can utilize the practices of project quality management from project management.

To maintain good communication to all the internal (problem manager, change manager, etc) and external stakeholders (like customer team), IT governance team can utilize and embed the practices of project communications and stakeholder’s management from project management.

Likewise, one can utilize other processes like risk management, integration management, cost management into the operations of ITSM.

ITIL Service Delivery | Difference Between IT Service Delivery & IT Service Support

Service Delivery

Service delivery has a specific definition and prominence in ITIL v2, focusing on the long-term aspects of IT services like Financial Management, Availability Management, Capacity Management, Service Level Management, and IT Service Continuity Management.

[the_ad id=”667″]

ITIL Service Delivery
IT Service Delivery

Be it any IT organization, no management would create budgets every day.
Be it any IT organization, no team would define availability plans for an IT service everyday.
Be it any IT organization, no team would define capacity plans for an IT service everyday.
Be it any IT organization, no teams would define continuity plans for an IT service everyday.
Be it any IT organization, no teams would define SLA’s for an IT service everyday.

You do the above mentioned activities, once in a month or quarter or half a year, hence these activities are focused on long term. Hence the processes Financial Management, Availability Management, Capacity Management, Service Level Management, and IT Service Continuity Management is categorized under Service Delivery.

Service Support

On the other side, there was Service support which focused on day to day operations. The processes and functions covered in service support are Incident Management, Problem Management, Change Management, Release Management, Configuration Management and one function Service Desk.

Incidents, problems, changes, releases, configurations and interactions with service desk happens regularly in day to day operations, hence these processes and function is categorized in service support.

IT v3 Service Delivery

[the_ad id=”667″]

In ITIL v3, there is no specific definition for IT service delivery, as ITIL v3 is a lifecycle-based approach which runs on the five process areas service strategy, service design, service transition, service operations, continual service improvement.

In practical IT environment, IT Service Delivery means the delivery of IT services which involves defining the strategy, designing the service, transitioning the service, performing operations, and improving the service.

Some of the prime activities involved in IT Service delivery are:

  • Formulating and planning, designing, scheduling and monitoring the strategy, design, transition, operations and continuous improvement related activities to meet time and targets.
  • Providing training to the IT workforce appropriately on the respective processes, tools, technologies to provide good support on incidents, service requests, problems, and change requests in the pre-defined SLA targets.
  • Understanding the ticket volumes and backlog.
  • Leading, executing structured governance and managing the escalations, communications, relationship with the customer, etc.
  • Developing, negotiating and managing the SLAs as per the business unit needs
  • Managing services within budget guidelines, and providing progress, issues, and improvements reports for top, mid, and low-level management.
  • Identifying all possible risks that can affect the IT services with respect to time, cost, scope and quality.
  • Reviewing and monitoring the IT operations performance reactively and proactively to meet SLAs and customer requirements.
  • Defining and evolving the support models / plans for new services.
  • Managing compliance with the defined SOP’s and policies associated with the IT operations and process.

Difference between ITIL Service Support and ITIL Service Delivery

IT Service Support IT Service Delivery
IT Service support focuses on providing day to day support in IT operational environment. IT Service delivery focuses on planning and designing the IT infrastructure services.
Processes involved in service support are Incident management, problem management, change management, release management, configuration management.
Has one function – Service Desk.
Processes involved in service delivery are Financial Management, Availability Management, Capacity Management, Service Level Management, and IT Service Continuity Management.
No functions defined.

Lists 26 ITIL Processes & 4 ITIL Functions

ITIL Processes

ITIL v3 has 26 processes which have been segregated into five process areas service strategy, service design, service transition, service operations, continual service improvement.
Process is a sequence of activities which has some inputs, triggers, outputs and delivers specific outcomes to the customer.

[the_ad id=”667″]

ITIL v3 processes, ITIL process, ITIL processes and function, 26 ITIL v3 Processes
ITIL processes

Service strategy process area has 5 processes:

Strategy management for IT services:

This process has 4 sequential activities which can be mentioned as performing strategic assessment, generating strategy, executing strategy, measurement and evaluation.

Demand management:

This process has 4 sequential activities which can be mentioned as identifying sources of demand and forecasting, analysing the patterns of business activity and user profiles, developing differentiated offerings and managing operational demand.

Service portfolio management:

This process has 4 sequential activities which can be mentioned as definition of the services, analysis of the services, approval and chartering of services.

Financial management for IT services:

This process has 3 sequential activities which can be mentioned as budgeting, accounting and charging.

Business relationship management:

This process has 3 sequential activities which can be mentioned as request and complaints handling, opportunity identification, and managing business relationships.

Service design process area has 8 processes:

Service catalogue management:

This process has 4 sequential activities which can be mentioned as documenting service definition and description, agreeing service catalogue contents, and finally producing and maintaining service catalogue.

Availability management:

This process has 4 sequential activities which can be mentioned as monitoring availability, analyse availability data, investigate service unavailability, availability planning, and finally review availability and testing.

Information security management:

This process has 5 sequential activities which can be mentioned as understanding security requirements, producing security policy, implementing security policy, assessing information assets and risks, and finally reviewing security controls.

Service level management:

This process has 4 sequential activities which can be mentioned as understanding requirements and drafting SLA’s, negotiating the SLA’s, define and standardize the SLA’s, and finally monitor and report service performance.

Capacity management:

This process has 5 sequential activities which can be mentioned as monitor capacity and performance data, analyse the capacity data, investigate capacity issues, define and revise capacity plans, and finally review and optimize/improve capacity.

Design coordination:

This process has 4 sequential activities which can be mentioned as defining policies and methods, planning resources and capabilities, managing design risks, and finally improving service design.

Supplier management:

This process has 5 sequential activities which can be mentioned as defining requirements, evaluating suppliers, selection of suppliers, manage performance, and finally renew or terminate contracts.

IT service continuity management:

This process has 3 sequential activities which can be mentioned as develop requirements, develop continuity plans, implement continuity plans, and finally invoking the continuity plan.

Service transition process area has 7 processes:

Transition planning and support:

This process has 5 sequential activities which can be mentioned as definition of transition strategy, preparing for service transition, planning and coordinating service transition, and finally monitoring and reporting progress.

Change management:

This process has 5 sequential activities which can be mentioned as registration and categorization, risk and impact analysis, approval, coordinate change build and test, authorize change deployment, and finally review and close change record.

Change evaluation:

This process has 3 sequential activities which can be mentioned as plan evaluation, evaluation of predicted performance, and finally evaluating actual performance.

Release and deployment management:

This process has 5 sequential activities which can be mentioned as release planning, build and test release, deployment, early life support, and finally review and closure.

Service asset and configuration management:

This process has 5 sequential activities which can be mentioned as management and planning, CI identification, CI control, Status accounting and report, and finally verification and accounting.

Service validation and testing:

This process has 5 sequential activities which can be mentioned as planning and designing tests, verifying test plans and designs, preparing test environments, performing tests, evaluating exit criteria, and finally cleaning test environments and closure.

Knowledge management:

This process has 5 sequential activities which can be mentioned as defining knowledge management strategy, identify and gather data sources, draft knowledge, technical review, editorial review, and finally publish.

Service operation process area has 5 processes:

Access management:

This process has 5 sequential activities which can be mentioned as access requisition, verification and validation, provision of rights, monitoring the access, tracking the access and finally deprovisioning the access.

Event management:

This process has 5 sequential activities which can be mentioned as event notification, event detection, correlating and filtering events, categorization events, and finally event review and closure.

Service request fulfillment:

This process has 5 sequential activities which can be mentioned as request registration, validating request, categorize and prioritize request, review and authorize request, and finally request closure.

Incident management:

This process has 5 sequential activities which can be mentioned as incident registration & categorization, prioritization, investigation and diagnosis, resolution, and finally closure.

Problem management:

This process has 5 sequential activities which can be mentioned as problem detection and logging, categorization, investigation and diagnosis, and finally resolution and closure of problem.

Continual service improvement process area has 1 process:

Seven step improvement: This process has seven sequential steps which can be mentioned as identify the strategy for improvement, define what you will measure, gather data, process data, analyse information and data, present and use information, and implement improvement.

ITIL Functions

[the_ad id=”667″]

Function is a team or a group of people who perform a set of activities.
ITIL v3 defines four functions as Service Desk, Application management, Technical Management, and Operations Management.

ITIL Processes and Function, 26 ITIL Processes and 4 ITIL Functions
4 ITIL v3 Functions

Service desk

This is a function who will be the first point or single point of contact for end user issues.

Application management

This is a function who will manage the application development and maintenance issues.

Technical management

This is a function who will manage the technical expertise for the ITSM processes and operations.

Operations management

This is a function who will manage the day to day operations with respect to IT operations control and IT facilities management.

6 Goals of Incident Management

The prime goal of incident management is to resolve incidents either with temp fix or perm fix and bring back the IT service. We list here few steps involved during incident process.

[the_ad id=”667″]

Incident Management Goals
Incident Management Goals

Resolve incidents to reduce downtime to the business

The prime goal of incident management is to resolve incidents either with temp fix or perm fix and bring back the IT service. Resolving the incidents, firstly requires to register the incident in the ITSM tool with a unique reference number, then categorization of the incident is done based on hardware, software, etc. and then the incident is assigned to the appropriate team or a person to take quick action, then the investigation and diagnosis is done, then resolution is implemented by searching knowledge articles or reference materials or KEDB and once the issue is resolved then the incident is closed.

Improve the quality of IT service and increase availability of the services operation

Incident management can improve the quality of IT services by identifying the recurring incidents, and logging problem tickets to identify the root cause of the incident/ incidents. If there is any new incident which has no resolution, then a problem ticket is created to identify the root cause and a fix.
By identifying the recurring incidents and its associated CI’s, availability management or capacity management or information security management or continuity management can redefine or revise the respective plans and procedures to improve the delivery of services.

Monitoring of services, detecting and mitigating incidents

As incident management team in many organizations is also involved in monitoring, they will get a complete picture why the incident occurred, what errors or warnings or exceptions have occurred. Accordingly, the monitoring team can consolidate the complete information from monitoring and event management tools and inform the problem management team for quicker resolution of unknown incidents.

Communicate regarding the progress of the major incidents to all stakeholders

Incident management team will communicate the progress of the major incidents to all the necessary stakeholders from the moment it has been registered to the closure.
Incident management team keeps sending notifications regularly after every half an hour or the defined timelines to all the relevant stakeholder giving information on the incident like:

  1. What is the incident?
  2. What is the priority?
  3. When the incident occurred?
  4. Where is the incident happening or happened?
  5. What is the associated CI?
  6. How many people are impacted?
  7. Who is working on the issue?
  8. Estimated time to resolve the incident

Ensure SLA’s don’t breach for any reason

Incident manager and management team will have to ensure the SLA doesn’t breach on any of the incident ticket, for any reason like 3rd party involvement, negligence of the incident management team, dependency on any other problem or change ticket.

Measure the effectiveness of incident management operations

Incident manager has to track the effectiveness of the incident management operations by defining the metrics and KPI’s (Key Performance Indicators) like:

  1. Number of incidents
  2. Number of major incidents
  3. Number of recurring incidents
  4. Average time taken to resolve the incident
  5. Average time taken to resolve the major incident
  6. Incidents that triggered problem tickets
  7. Incidents that triggered change tickets

Release Management Best Practices in ITIL

Release and Deployment Management

Best practices are those real practices that have delivered efficient, effective, and excellent results in the IT processes and real operations.

[the_ad id=”667″]

software release management best practices, ITIL Release and Deployment Management
Release Management Best Practice

Best practices for Release and Deployment management processes and operations can be defined as mentioned below:

Release planning is a must for every major and minor release

Release analysts should do appropriate planning, before the release plans, packages and builds are sent for testing to avoid wastage of time and efforts. Planning should involve analysis on aspects like:

  • What requirements are there for the release, determine which release units to be included in the release and to include complete application and related components into release to ensure proper testing.
  • Release dates of major releases.

Building release packages

release management best practices itil
Release Management Best Practices

The release team must document the manual processes and procedures required to deploy the release into production (or remove it as necessary) in addition to any technology solution, along with the exact order of execution and success indicators of the steps.
The documentation created as part of the build stage should include details of how to monitor and check the effectiveness of the release and how to recognize and react to problems.

Release test plans and review test results

Adequate testing on release is a mandatory activity that should happen without a miss. All the testing work should happen in coordination with SVT process.
Once the build is ready, tests need to be performed to verify in the functionalities of the release are in line with the change objectives. Depending on the nature of the change the test requirements like System integration tests, functionality tests, and UAT/Pilot tests should be performed defined by the SVT process.

Assess the deployment readiness

Assessing the deployment readiness should involve:

  • Identifying the people (deployment stakeholders) who will be involved in the deployment,
  • Taking a baseline of the current configuration before the deployment can start on the production Environment which will be useful when the roll-out fails.
  • Conducting post deployment test on the production environment and the test results to review the release acceptance criteria.

Deployment Documentation

Release notes should be prepared with the content of known issues/bugs identified during the testing and should coordinate with SACM team to strategize for the release documentation updates in CMS/CMDB.

ELS the most important role in Release management

ELS team should provide the support to support staff by providing knowledge sessions and training on the release and the technicalities involved in fixing issues. Also, known bugs, known issues should be explained to resolve any knowledge transfer or training gaps.

Release closure

Release Coordinator should ensure:

  • That all affected CIs (which were created/modified) during deployment are updated correctly in CMDB.
  • That all related release documents are updated correctly in CMDB and are linked to appropriate CIs.
  • All new KB articles prepared during the ELS phase are to be updated at the appropriate location in the SKMS so that those can be easily reused later by the operations/support staff.
  • Analyze the Deployment and ELS Completion reports and results and discuss with the release team to identify what went correct and what went wrong in the release cycle.

Lessons Learned Document

Documentation of lessons learned should be a must, and should be submitted as knowledge articles to verify and validate them and to publish them in knowledge base.

Have a unified calendar with complete visibility

Having an integrated calendar accessible to change, release, and other operational teams like incident and problem would be very helpful to see planned changes and releases by time, day, week and month.

Participation of release management staff in service improvement meetings

Participation of release staff in service improvement meetings is very vital to understand the priorities and goals of IT organization and accordingly release management staff should align its operations. Also release staff can provide many great inputs for improving the IT service delivery.

Regular meetings with other ITSM process owners

Regular meetings with other ITSM process owners should happen continuously to update the trends and patterns of releases and the concerns of EU’s and customers.

Maintenance of ITSM process owners and onsite technicians contacts list

Maintenance of ITSM process owners, onsite technicians and service owner’s contacts details, and being up to date is a must which will enable the change management staff to do the planning & coordination with other service transition stakeholders.

Access to KEDB, CMDB, CMS and SKMS

Release management staff should have access to KEDB, CMDB, CMS and SKMS; accessibility to these tools will help the staff to understand the impact of a release, associated services, SLAs associated, financial value, etc. and will help them to evaluate the risks associated.

Regular training sessions

Training sessions on release management process, policies, procedures and technical knowledge is a must which should happen at regular intervals.
Most of the delays and discrepancies in release management operations happen due to unawareness on process, policies, and procedures; hence, it is a mandatory objective for IT management to conduct training sessions which can bring thorough awareness to all stakeholders. Management should also conduct exams and assessments to evaluate the proficiency of the staff, and reward them with some gifts or incentives.

Download Release Management Best Practices PDF

What is Release and Deployment Management ? | Release Management Process Flow

ITIL Release Management Process

[the_ad id=”667″]

Release and deployment management defines a standardized process for planning the release, building and testing the release, scheduling the release, testing the release, deploying the release, providing early life support (ELS), and closure of releases.

Release Management Process flow

In practical IT environment, release management operations would generally be executed as per the below diagram:

[the_ad id=”667″]

ITIL release management process flow diagram, Release Management Process Flow
Release Management Process Flow Diagram

Process Description of Release Management

Step 1: Create a release ticket

Request for Change (RFC) from the Change Management Process forms an input to Release & Deployment Management process.
For all Releases, a Release ticket is raised in <<tool>> and is to be tagged to the RFC which triggered the Release.
There may be many to one mapping between changes and releases (i.e. many changes can be released together) or one to one mapping (i.e. one change can be released stand alone).
Release can be a normal release (Major or Minor) or an emergency Release.

Step 2: Create a release plan

For every release, the Release Manager will own the responsibility of preparing a Release Plan. Release Manager coordinates with Change Management team and Build team regarding the same.
The Release Plan will be submitted to the CAB.

Step 3: Assign release activities to technical teams

Release Manager will assign the release activities in <<tool>> to the person responsible for those activities.

  • These tasks are tracked and monitored by the Release Manager to monitor the release status.
  • If a release needs a vendor involvement, then the ticket is assigned to the vendor queue in <<tool>> and <<if tool integration exists it is routed to vendor’s tool via the B2B the ticket gets created in their system>>.
  • Release Manager will then publish the release calendar based on the dates finalized in the Release Plan.

Step 4: Release packaging

Release Manager will ensure that releases are packaged and released in a controlled manner as per the plan.
Release packaging includes assembling and integrating the release components as per the dependencies identified.

Step 5: Build the release

Release Manager will coordinate with Build team to build the release and produce the build document which will contain:

  • Build, installation and test plans, procedures and scripts
  • Monitoring and quality assurance of the release
  • Processes and procedures for distributing, deploying and installing the release into the target environment
  • Release unit roll-back procedures
  • Change remediation steps in case of release failure

Release Manager will coordinate with Build and Change Management teams and ensure that the build activity is completed as per the Release plan.
Build team will consider various aspects relating to version control, baseline management, control of inputs and outputs from a build.
Creation of a configuration baseline which is recorded in the configuration management tool for the release before and after installation, to provide a restore point in case of rollback is initiated by the Release Manager along with the Change and Configuration Manager.

Other aspects taken into consideration for a Release are:

  • Checking that the security requirements are met
  • Verification activities to ensure prerequisites are met before a build or test begins
  • Preparing and controlling the service release readiness for deploying into the next environment

Step 6: Service validation and testing

Build prepared by the build team is then moved into Test Environment for testing. Release Manager will initiate testing as per the Release Plan. Service Validation & Testing team will complete testing of the release and will provide test results to the Release Manager.
Build and Test activities will be completed in the stipulated time frame as per the Release Plan. Time allocated to each activity will depend on the release type.

Step 7: Test successful ?

Release Manager will ensure that all mandatory tests are conducted and all tests are successful before a release can be flagged off to production.

Step 8: Update Release Plan & Rollback Plan ?

Once testing is successful, Release Manager will update the Release Plan and rollback plan as required and circulate the same to Change Manager and other stakeholders.
Release Manager will also ensure that Rollback plan is properly prepared and is tested (or verified wherever testing of rollback plan is not possible).
All releases will be subject to pre-implementation checks and the Release Manager will work with the Change Manager for changing, reassessing, and rescheduling unsuccessful release packages.

Step 9: Release preparation and communication

Release Manager will ensure that all the environments are ready for release and will send out a communication to all stakeholders.
Acceptance criteria for the release are documented wherever relevant in the release ticket.
Successful release(s) with the positive test results is now moved to deployment phase.

Step 10: Deployment readiness activities

Readiness assessment for the deployment group will be done to check for issues and risks in delivering the current release that may affect the deployment.
For all non-major Releases, Delivery Manager will give Go/ No-Go decision regarding the releases.
Deployment team will prepare the training plan, training material, training schedule and training communication (for all major releases). Before the deployment they will ensure that the users, relevant support teams and other concerned stakeholders are appropriately trained.

Step 11: Initiate backup

Release Manager will coordinate and ensure that the backup is taken for the current release. This is to ensure that rollback to previous baseline is possible in case the deployment of the release fails.

Step 12: Deploy release as per plan

Release is deployed in the environment as per the deployment plan. Release Manager broadcasts the down-time related information wherever necessary in advance.

Step 13: Test Deployment

Success of the deployment is tested during this activity. Health check will be conducted by the Release Manager in coordination with the deployment team to verify the success of deployment.

Step 14: Change evaluation

Change evaluation process will evaluate the release.

Step 15: Change Management

Change management process will own and perform the Post Implementation review (PIR).

Step 16: Rollback required due to failed change?

During PIR Change Management will decide on the success or failure of the change.

Step 17: Rollback release

If a release fails, Release Manager will authorize (on the advice of <<Customer>> Delivery Manager or Change Manager) and initiate a Rollback of the release and restore the services to normal stage.
A root cause analysis for the failure of the release may be triggered (on need basis) via the Problem Management process.

Step 18: Change management

Change Management will ensure update to the RFC and related updates to the requester. Required communication regarding failure of change will be sent as per the Change Management Process.

Step 19: Update and close release ticket

Release Manager will resolve the release ticket and pass on the status update and post-implementation status to Change Management and update/ close the release ticket accordingly.
Release Manger will update the RFC with release closure comments.

Step 20: (If the change fails): Ensure CMDB update

Release Manager will ensure that the CMDB is updated with new (or updated) configuration details as per the release documentation and that a new baseline is created in the CMDB.

Configuration Manager will update the CMDB with the new or updated CI details.

Roles and Responsibilities in Release and Deployment Management | RACI Matrix Template

Roles and Responsibilities Template

Generic roles that are available in Release and deployment management are Release manager, deployment engineer, and CAB (Change advisory board).

[the_ad id=”667″]

Roles and Responsibilities in Release and Deployment Management, RACI Matrix Template for Release and Deployment Management
RACI Matrix Template for Release and Deployment Management

Release Manager Roles

  • Release manager will need to interface and communicate with test managers, IT operations,
  • Development team and the PMO on a daily basis and keep track of multiple project release timelines.
  • He/she will liaise with and manage the Release process with the Quality Assurance team, Service
  • Management teams, business users, developers and technical support specialists on product issues.
  • Creating Release Plans providing timelines for release build and test, deployment, early life support and closure.
  • Maintaining and publishing project Release Plans, Release Calendar and managing schedules and resource allocation and adhering to the timelines to ensure timely product delivery.
  • Does the critical review on all the release and change collaterals (change requests, release plans, build and test plans, deployment plans, etc.)
  • Maintains the track of all releases that are to be implemented and that have been implemented.
  • Directs and leads the release management team members with appropriate trainings.

Release and build Engineer

  • Development, monitoring and maintenance of release and build pipelines
  • Development of release and build infrastructure
  • Design and run quality tests on the builds and releases
  • Creating packages, builds, releases and patches as well as the software deliverables for the customers
  • Identify defects and inform them to the release manager

Deployment engineer

  • Create deployment plans
  • Automate the manual work related to deployment configuration in day-to-day tasks.
  • Improve deployment procedures with automation and documenting the deployment procedures
  • Documenting change logs accurately in build and deployment processes.
  • Identify defects and inform them to the release manager

ELS Engineer

  • Provide technical support on releases in production issues.
  • Monitor and keep a log of the issues being raised by end-users.
  • Provide trainings and prepare manuals with respect to every new release

How to implement RACI matrix?

[the_ad id=”667″]

  1. First, define the process, which will be a sequence of activities that will result in a specific outcome with the help of some roles and capabilities. Here you need to define the different roles needed for the process like release manager, build engineer, deployment engineer, test engineer, etc.
  2. Second, Identify the sequence of activities in a life-cycle based approach. For example: Raise release request, Categorize the release request, etc.
  3. Third, Identify the decisions in every activity. For example: Approve the build plan, Approve the deployment plan, etc.
  4. Fourth, each and every defined activity and decision should be tagged to a specific role.
  5. Fifth, define the matrix with columns and rows. Naming the first column heading as ‘Activity’, and below it (that is Activity column) define the different activities in a sequenced order. Define the other columns headings with the respective roles defined in the process.
  6. Finally, populate the information ‘R’, ‘A’, ‘C’, ‘I’ in the rows and columns ensuring there is:
    • One and only one ‘A’ (i.e. accountable role) for a specific task
    • Every task should have one ‘R’ and can also have many ‘R’s (i.e. responsible roles) based on the task
    • Lastly, tasks can have one or more ‘C’s (i.e. consulted roles) and ‘I’’s (i.e. informed roles) based on the task.

Download RACI Matrix Template for Release & Deployment Management