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
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
Planned service interruptions
Security requirements with respect to identity and access
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.
If the drafted SLR’s are as per customer expectations, then the customer would approve the SLR’s.
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.
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
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 & 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.
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 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
Service delivery status report is an top level service delivery management report which highlights all the achievements, progress and issues happening in ITSM projects.
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
This process has 5 sequential activities which can be mentioned as incident registration & categorization, prioritization, investigation and diagnosis, resolution, and finally closure.
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.
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.
This is a function who will be the first point or single point of contact for end user issues.
This is a function who will manage the application development and maintenance issues.
This is a function who will manage the technical expertise for the ITSM processes and operations.
This is a function who will manage the day to day operations with respect to IT operations control and IT facilities 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.
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:
What is the incident?
What is the priority?
When the incident occurred?
Where is the incident happening or happened?
What is the associated CI?
How many people are impacted?
Who is working on the issue?
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:
Best practices are those real practices that have delivered efficient, effective, and excellent results in the IT processes and real operations.
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
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.
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 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.
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:
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.
Generic roles that are available in Release and deployment management are Release manager, deployment engineer, and CAB (Change advisory board).
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
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
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?
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.
Second, Identify the sequence of activities in a life-cycle based approach. For example: Raise release request, Categorize the release request, etc.
Third, Identify the decisions in every activity. For example: Approve the build plan, Approve the deployment plan, etc.
Fourth, each and every defined activity and decision should be tagged to a specific role.
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.
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.