Release and Deployment of Production-Ready Software: Software Configuration Management Implement, Control, Manage and Integrate Best Practices Handbook - Ready to use bringing Theory into Action

Release and Deployment of Production-Ready Software: Software Configuration Management Implement, Control, Manage and I...

Author: Ivanka Menken | Gerard Blokdijk

21 downloads 428 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Release and Deployment of Production-Ready Software: Software Configuration Management Implement, Control, Manage and Integrate Best Practices Handbook - Ready to use bringing Theory into Action

Notice of Rights: Copyright © The Art of Service. All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Notice of Liability: The information in this book is distributed on an “As Is” basis without warranty. While every precaution has been taken in the preparation of the book, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the products described in it. Trademarks: Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this book. ITIL® is a Registered Community Trade Mark of OGC (Office of Government Commerce, London, UK), and is Registered in the U.S. Patent and Trademark Office.

Write a Review and Receive a Bonus Emereo eBook of Your Choice

Up to $99 RRP – Absolutely Free If you recently bought this book we would love to hear from you – submit a review of this title and you’ll receive an additional free ebook of your choice from our catalog at http://www.emereo.org.

How Does it Work? Submit your review of this title via the online store where you purchased it. For example, to post a review on Amazon, just log in to your account and click on the ‘Create Your Own Review’ button (under ‘Customer Reviews’) on the relevant product page (you’ll find plenty of example product reviews on Amazon). If you purchased from a different online store, simply follow their procedures.

What Happens When I Submit my Review? Once you have submitted your review, send us an email via [email protected], and include a link to your review and a link to the free eBook you’d like as our thank-you (from http://www.emereo.org – choose any book you like from the catalog, up to $99 RRP). You will then receive a reply email back from us, complete with your bonus ebook download link. It's that simple!

Release & Deployment Management Table of Contents INTRODUCTION ROADMAP ................................................................................................... 5 RELEASE & DEPLOYMENT MANAGEMENT PRESENTATION ........................................... 9 SUPPORTING DOCUMENTS ................................................................................................ 43 Policies, Objectives & Scope .............................................................................................. 45 DML & DS............................................................................................................................ 49 Examples of Service Manageability Tests .......................................................................... 53 Deployment, Planning & Activities ...................................................................................... 59 Communication Plan ........................................................................................................... 63 Example Business and IT Flyers......................................................................................... 69 Deployment Aspects to Assess........................................................................................... 73 Forward Schedule of Releases ........................................................................................... 75 Roles & Responsibilities...................................................................................................... 81 Business Justification Document ........................................................................................ 85 Reports, KPIs and other Metrics ......................................................................................... 91 IMPLEMENTATION PLAN – PROJECT PLAN...................................................................... 97 FURTHER INFORMATION................................................................................................... 107

3

Also from Emereo Publishing:

CMDB and Configuration Management Process, Software Tools Creation and Maintenance, Planning and Implementation Guide A professional technical roadmap to Configuration Management Database (CMDB) Management, with templates and design documents, mindmaps, roles and responsibilities, KPIs, audit plans and other IT Service Management resources for organizational implementation.

Release & Deployment Management

INTRODUCTION ROADMAP Many organizations are looking to implement Release and Deployment Management as a way to improve the structure and quality of the business.

This document describes the contents of the Release and Deployment Management Workbook. The information found within the book is based on the ITIL Version 3 framework.

The workbook is designed to answer a lot of the questions about Release and Deployment Management and provide you with useful guides, templates and essential, but simple assessments.

The supporting documents and assessments will help you identify the areas within your organization that require the most activity in terms of change and improvement.

Presentations can be used to educate or be used as the basis for management presentations or when making business cases for Release and Deployment Management implementation.

The additional information will enable you to improve your organizations methodology knowledge base.

The workbook serves to act as a starting point. It will give you a clear path to travel. It is designed to be a valuable source of information and activities.

The Release and Deployment Management Workbook: Flows logically, Is scalable, Provides presentations, templates and documents, Saves you time.

5

Release & Deployment Management Step 1 Start by reviewing the PowerPoint presentation: 1. Release & Deployment Management Presentation – This presentation provides a detailed and comprehensive overview of Release and Deployment Management in the specialist areas of ITIL Version3 and in particular, Release and Deployment as part of the Service Transition phase.

This presentation will give you a good knowledge and understanding of all the terms, activities and concepts required within Release and Deployment Management. It can also be used as the basis for management presentations or when making a formal business case for Release and Deployment Management implementation. Make sure you pay close attention to the notes pages, as well as the slides, as references to further documents and resources are highlighted here.

6

Release & Deployment Management Step 2 If you did not look at the supporting documents and resources when prompted during the PowerPoint presentation, do this now.

Below is an itemized list of the supporting documents and resources for easy reference. You can use these documents and resources within your own organization or as a template to help you in prepare your own bespoke documentation.

Release & Deployment Management ITIL V3: 1. Policies Objectives Scope 2. DML & DS 3. Example Service Manageability Tests 4. Deployment, Planning & Activities 5. Communication Plan 6. Example Business and IT Flyers 7. Deployment Aspects to Assess 8. Forward Schedule of Releases 9. Roles and Responsibilities 10. Business Justification Document 11. Reports, KPI’s & Other Metrics

7

Release & Deployment Management Step 3 Alternatively, continue by working through the Implementation Plan & Project Plan with the focus on your organization. This will help you ascertain the Release and Deployment Management maturity for your organization. You will able to identify gaps and areas of attention and/or improvement. The supporting documents and resources found within the toolkit will help you fill these gaps by giving you a focused, practical and user-friendly approach to Release and Deployment Management.

8


RELEASE & DEPLOYMENT MANAGEMENT PRESENTATION

GOAL: To deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to Service Operation.

There is a Policies, Objectives & Scope document, available on page 39.

9


DS and DML are part of the CMDB as all CI information is stored in the CMDB.

It is important to understand the difference between Change MGT vs Release & Deployment MGT

Change MGT authorizes and coordinates the Changes. Release & Deployment actually plans, distributes and releases the changes

Some options for deploying new releases to multiple locations: •

‘Big Bang’: the new or changed service is deployed to all user areas in one operation

•

Phased: service deployed in multiple rollouts to user groups

•

Push: service or application is stored centrally and pushed out to user groups and not at their choosing.

10

Release & Deployment Management •

Pull: Services or applications are stored centrally and users are free to pull the software at their leisure.

•

Automated: automated release mechanisms – need to be well-designed and efficient

•

Manual: manual activities required for releasing, slows down release and can create capacity issues

11


•

A Release Unit describes the portion of a service of IT infrastructure that is normally released together according to the organizations release policy. The unit may vary depending on the type(s) or item(s) or service asset or service component such as hardware or software.

The following factors should be taken into account when deciding the appropriate level for release units: •

Ease and amount of change necessary to deploy

•

Complexity of interfaces between proposed unit and the rest of the services

•

Storage available in the build, test, distribution and live environments

12


An area should be set aside for the secure storage of definitive hardware spares. These are spare components and assemblies that are maintained at the same level as the comparative systems with the controlled test or live environment

There is more information on the DML & DS, available on page 43.

13


The general aim is to decide the most appropriate release-unit level for each service asset or component. An organization may, for example, decide that the release unit for business critical applications is the complete application in order to ensure that testing is comprehensive. The same organization may decide that a more appropriate release unit for a website is at page level.

The following factors should be taken into account when deciding the appropriate level for release units: •

The ease and amount of change necessary to release and deploy a release unit

•

Amount of resources and time needed to build, test, distribute and implement the release unit

•

Complexity of interfaces between the proposed unit and the rest of the services and IT infrastructure •

Storage available in the build, test, distribution and live environments.

14


•

Releases should be identified according to a scheme defined in the release policy. The release identification should include reference to the CI’s that it represents and a version number that will often have two or three parts.

15


Service Design will define the approach to transitioning from the current service to the new or changed service or service offering.

The SDP defines the service and solution design components to be transitioned to deliver the required service package and service level package.

The selected option will have a significant impact on the release and deployment resources as well as the business outcomes. It is essential to understand the patterns of business activity and user profiles when planning and designing the releases.

16


This will be the case in many scenarios such as in retail organizations for new services being introduced into the stores’ environment in manageable phases.

There are some variations of the Phased Approach:

•

Portions of the service are delivered to the live environment in phases, but all end users are affected simultaneously (e.g. incremental changes to a shared application).

•

Each release is deployed gradually across the total population of end users (e.g. one geographical location at a time).

•

Different types of service element are deployed in separate phases, e.g. hardware changes are first, followed by user training and then by the new or changed software. 17


•

Combination of all these approaches is usually adopted, and the plans may deliberately allow for variations in the light of actual deployment experience.

18


•

In terms of service deployment, delivering updated service components to all users, either in big bang or phased form, constitutes both push, since the new or changed service is delivered into the users’ environment at a time not of their choosing.

19


The use of ‘Pull’ updating a release over the internet has made this concept significantly more pervasive. A good example is virus signature updates, which are typically pulled down to update PC’s and servers when it best suits the customer; however at times of extreme virus risk this may be overridden by a release that is pushed to all know users.

In order to deploy via a ‘push’ approach, the data on all user locations must be available. Pull approaches do not rest so heavily on accurate configuration data and they can trigger an update to user records. This may be through new users appearing and requesting downloads or expected users not doing so, triggering investigation into their continued existence.

20


Whether by automation or by other means, the mechanisms to release and deploy the correctly configured service components should be established in the release design phase and tested in the built and test stages.

Automated: Many of the release and deployment activities are capable of a degree of automation e.g. •

Discovery tools aid release planning

•

Automate builds reduce time taken this in turn can resolve scheduling conflicts and delays

•

Automated configuration baselines procedures save time and reduce errors in identifying the status of CI’s and releases during build, test and deployment etc

Manual: Too many manual activities will slow down the release team and create resource and capacity issues that affect the service levels

21


22


The Definitive Media Library ( DML) is the secure library (previously known as the DSL) in which the definitive authorized versions of all media CI’s are stored and protected. It stores master copies of versions that have passed quality assurance checks. This library may in reality consist of one or more software libraries or filestorage areas, separate from development, test or live file-store areas. It contains the master copies of all controlled software in an organization.

The DML should include definitive copies of purchased software, as well as software developed on site. Master copies of controlled documentation for a system are also stored in the DML in electronic form.

DML will also include a physical store to hold master copies, e.g. a fireproof safe. Only authorized media should be accepted into the DML, strictly controlled by the SACM.

23


Key Points: •

Release Policy is overarching strategy for releases and was derived from the Service Design phase of the Service Lifecycle.

•

Release Plan is the operational implementation for each release.

24


Release and Deployment plans should be authorized through Change Management and should define: •

Scope and content of release

•

Risk assessment and risk profile for the release

•

Organizations and stakeholders affected by the release

•

Stakeholders that approved the change request for the release and/or deployment

•

Team responsible for the release

•

Approach to working with stakeholders and deployment groups to determine the; delivery and deployment strategy, resources for the release and deployment and amount of change that can be absorbed.

25


Build and test planning establishes the approach to building, testing and maintaining controlled environments prior to production, the activities include: •

Developing test plans from the service design package

•

Establishing logistics, lead times and build times

•

Testing the build and related procedures

•

Scheduling the build and test activities

•

Assigning resources, roles and responsibilities to perform key activities e.g.

•

Security procedures and checks

•

Technical support

•

Preparing build and test environments

•

Managing test databases and test data

•

Software asset and license management

•

Configuration Management – configuration audit, build and baseline management.

•

Defining and agreeing the build exit and entry criteria

There is a list of Example Service Manageability Tests, available on page 47.

26


Included in the ITIL v3 Service Transition book is the V Model.

The V Model concept of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered for the degree of integrity and competence that would justify release to the customer for trail and assessment. The diagram above provides an example of a model that can be used to deliver a service capability.

The left hand side represents the specification of the service requirements down to the detailed Service Design. The right hand side focuses on the validation and test activities that are performed against the specifications defined on the left hand side, there is direct involvement by the equivalent party on the right hand side.

27


It shows that service validation and acceptance test planning should start with the definition of service requirements. E.G customers who sign off the agreed service requirements will also sign off the service Acceptance Criteria and test plan.

28


Tests that are conducted as part of the service operational readiness test include: •

Deployment readiness tests

•

Service Management test

•

Service Operation test

•

Service Level test

•

User test

•

Service Provider Interface test

•

Deployment Verification test

29


Release and Deployment Models define: •

Release structure – the overall structure for building a release package and the target environments

•

The exit and entry criteria including mandatory and optional deliverables and documentation for each stage

•

Controlled environments required to build and test the release for each release level

•

Roles and responsibilities for each configuration item at each release level

•

The release promotion and configuration baseline model

•

Template release and deployments schedules

•

Supporting systems, tools and procedures for documenting and tracking all release and deployment activities

•

Handover activities and responsibilities for executing the handover and acceptance for each stage of release and deployment.

There is more information on the Deployment Planning and Activities considerations available on page 53. In addition, there is a Communication

30

Release & Deployment Management Plan on page 57 and examples of some Business and IT Flyers available on page 63.

31


Although the deployment assessment should be conducted early, it should be revisited periodically. The results of this assessment are fed into detailed implementation planning for the target deployment group.

A list of Deployment Aspects to Assess, is available on page 67.

32


Once the overall deployment approach is understood, develop the logistics and delivery plans. These plans deal with aspects such as: •

How and when release units and service components will be delivered

•

What are the typical lead times are; what happens of there is a delay

•

How to track progress of the delivery and obtain confirmation of delivery

•

Availability of secure storage where required

•

Managing customs and other implications of international distribution.

Financial/commercial aspects will need to be specifically checked before the deployment and activities added to the deployment plans where necessary. E.g. •

Working capital

•

Contracts and licenses

•

Funding

•

Intellectual property.

33


Key Points: •

Change driven by customer demand,

•

Version control of Release through lifecycle,

•

Close relationship with Change Management.

Why keep old versions in DML/DS? For rollback/integrity purposes, in case something goes wrong deploying the release.

An example of a Forward Schedule of Releases template is available on page 69.

34


35


It is advisable at this point to: •

Gather feedback on the deployment process to feed into future improvements e.g. using satisfaction surveys.

•

Report issues and incident and take corrective actions.

•

Successful confirmation of the deployment verification triggers the initiation and launch of early life support for the deployment group.

36


Each deployment should consider whether any relevant issues have been detected that should be passed through the Continual Service Improvement phase, such as: •

Feedback on the deployment model and pain

•

Errors in procedures detected

•

‘Near misses’ where things could have gone wrong in foreseeable circumstances or where intervention was required

•

Incorrect data or information in relevant records

•

Incident and problems caused by deployment

•

Problems with updating records

•

Deployment is completed with a handover of the support for the deployment group or target environment to Service Operations.

37


More information on the Roles and Responsibilities of Release and Deployment Management is available on page 75.

38


Well planned and implemented release and deployment will make a significant difference to an organization’ service costs. A poorly designed system will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. At worst, it can cripple the environments and degrade the live services.

There is a Business Justification Document, is available on page 79.

39


There is more information on Reports, KPI’s & Other Metrics, available on page 85.

40


41


42


SUPPORTING DOCUMENTS Through the documents, look for text surrounded by > these are indicators for you to create some specific text.

Watch also for highlighted text which provides further guidance and instructions.

43


44


Policies, Objectives & Scope

IT Services Policies, Objectives & Scope Process: Release & Deployment Management

Status:

In draft Under Review Sent for Approval Approved Rejected

Version:

Release Date:

45


Refer to the Implementation Plan & Project Plan on page 91 and the Policies, Objectives and Scope document on page 39 for planning and implementation guidelines.

Policies, Objectives and Scope for Release Management This document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered.

Policy Statement A course of action, guiding principle, or procedure considered expedient, prudent, or advantageous

Use this text box to answer the “SENSE OF URGENCY” question regarding this process. Why is effort being put into this process? Not simply because someone thinks it’s a good idea. That won’t do. The reason has to be based in business benefits. You must be able to concisely document the reason behind starting or improving this process. Is it because of legal requirements or competitive advantage? Perhaps the business has suffered major problems or user satisfaction ratings are at the point where outsourcing is being considered. A policy statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHY question for this process.

The above Policy Statement was; Prepared by: On:

And accepted by:

46

Release & Deployment Management Objectives Statement Something worked toward or striven for; a goal Use this text box to answer the “WHERE ARE WE GOING” question regarding this process. What will be the end result of this process and how will we know when we have reached the end result? Will we know because we will establish a few key metrics or measurements or will it be a more subjective decision, based on instinct? A generic sample statement on the “objective” for Release & Deployment Management is: The Release & Deployment Management objective is described as a process for controlling and coordinating the release of software and associated hardware needed to maintain and improve the IT Services that will be provided. Release & Deployment Management will provide a structure and repeatable process to support releases without affecting the levels of service. Note the keywords in the statement. For the statement on Release & Deployment Management they are “controlling and coordinating” and “without affecting levels of service”. These are definite areas that we can set metrics for and therefore measure progress. An objective statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHERE question for this process.

The above Objective Statement was; Prepared by: On:

And accepted by: On:

47

Release & Deployment Management Scope Statement The area covered by a given activity or subject Use this text box to answer the “WHAT” question regarding this process. What are the boundaries for this process? What does the information flow look like into this process and from this process to other processes and functional areas? A generic sample statement on the “scope” for Release & Deployment Management is: The Release & Deployment Management process will be responsible for managing releases involving the following aspects of the IT Infrastructure: • Hardware • Software • System Software • Etc • All Documents pertaining to the above Systems and Services Release& Deployment Management will be responsible for those components that exist under the banner of Applications Development, including their supporting hardware, thus ensuring compatible development, test and production environments. A scope statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHAT question for this process.

The above Scope Statement was; Prepared by: On:


48


DML & DS

IT Services Definitive Spares (DS) Definitive Media Library (DML) Checklist Process: Release & Deployment Management

Status:


Version:

Release Date:

49

Release & Deployment Management DS and DML Design Document for Release and Deployment Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a CHECKLIST FOR TOPICS TO CONSIDER WHEN

LOOKING AT THE SELECTION OF AN AUTOMATED TOOL for the Release and Deployment Management process. This document provides a basis for completion within your own organization. This document was; Prepared by: On:


50

Release & Deployment Management The DS and DML Without knowing it there are already many organizations engaged in Release and Deployment Management practices. Most already have some form of DML or DS. These are often located in someone’s desk drawer, their laptop bag, in a cupboard, on a rack in a spare room. However the growth in size and complexity of IT environments has dictated the need to adopt a more sophisticated way of storing hardware and software. The following checklist will help the reader identify the salient characteristics that are required of a well designed DML or DS. Use the list to assess tools being promoted or as a list to put in a tender or request for information when investigating different tools. The DS and DML should provide Characteristic

Notes/Comments/Relevance

Security controls that will restrict access as appropriate. Ability to support and hold information on CIs that have a varying degree of complexity (from entire stand-alone systems (e.g. Mainframe) to simple, single hardware items or software applications and all the associated relationships that are possible between them). References to this information will be stored in the Configuration Management Database. An ability to use heuristics to create automatic relationships between certain components within the tools recording information about the DS and DML. Ability to easily add, modify or remove components, without undermining the integrity of the stores. This process should be subject to change management and ensure only authorized access. Validation and duplicate avoidance through physical auditing

51


Tightly coupled link to data in the CMDB. Recording of updates and version numbers following releases, etc. Ensure that each new release will store an authorized original in the DS or DML. History section to allow a review of past events to components in the DML and DS (including changes to versions, installation date, RFCs, location changes, etc.) Powerful reporting ability, with both pre-defined reports and the ability to create custom reports. Also the ability to perform trend analysis to help facilitate future requirements. Based on logical divisions of your organization the ability to store components by geographic location or functional department or network segment, etc. Parent/Child display

DS and DML back-ups, archives and housekeeping Regular back-ups (combined with secure storage) are an important element of managing a DML or DS. This is more applicable to the DML, as some organizations keep authorized versions on backup tapes. The DML and DS should be regularly checked to ensure that only authorized versions are being recorded and stored. Refer to Release Management Implementation Plan / Project Plan on page 91 for more information

52


Examples of Service Manageability Tests

Service Management function

Examples of design phase manageability checks

Examples of build phase manageability check

Examples of deployment phase manageability checks

Examples of operating manageability checks

Examples of early life support and CSI checks

Release and Deployment Management

Do the service designers understand the standards and tools used for releasing and deploying services?

Has the service, application and infrastructure been built and tested in ways that ensure it can be released into the environment in a simple and efficient way.

Is the service being deployed in a manner that minimizes risks, such as a phased deployment?

Does the release and deployment process ensure that deployment information is available to the operations teams?

Do members of the CSI team understand the release process, and are they using this for planning the deployment of improvement s?

How will the design ensure that the new or changed service can be deployed into the environment in a simple and efficient way?

Security Management

How does the design ensure that the service is designed with security in the forefront?

Is the build process following security best practice for this activity?

Has a remediation / back-out option been included in the release package or process for the service and its constituent components?

Can the service be deployed in a manner that meets organizational security standards and requirements?

Do the Service Operations teams have access to release and information even before the service or application is deployed into the live environment?

Is Release and Deployment Management involved in providing advice to the assessment process?

Does the service support the ongoing and periodic checks that security management needs to 53

Release & Deployment Management complete while the service is in operational use?

Incident Management

Does the design facilitate simple creation of incidents when something goes wrong?

Is the design compatible with the organizational incident management system?

Does the design accommodate automatic logging and detection of incidents?

Problem Management

How does the design facilitate the methods used for root cause analysis used within the

Is a simple creation-ofincidents process, for when something goes wrong, built into services and tested (e.g. notification from applications?)

Has the compatibility with the organizational incident management system been tested?

Has the method of providing information to facilitate root cause analysis and problem management

Does the operations team have access to the incident management system and can it update information Do the members within this system? of the deployment team have Does the access to the operations incident team management understand its system so that they can record responsibilities in dealing with incidents and incidents? also view incidents that relate to the deployment? Is the operations team provided with reports on how well it deals with incidents, and does it act on these?

Do members of the CSI team have access to the incident management systems so that they can record incidents and also view incidents that may be addressed in optimization?

Has a problem manager been appointed for this deployment and does the deployment team know who

Is the optimization process being provided with information by problem

Does the deployment use the incident management system for reporting issues and problems?

Does the operations team contribute to the problem management process,

54


Capacity Management

organization?

been tested?

Are the designers aware of the approach to capacity management used within the organization?

Has the service been built and tested to ensure that it meets the capacity requirements?

How to measure operations and performance? Is modelling being used to ensure that the design meets capacity needs?

it is?

Is capacity management involved in the deployment process so that it can monitor the capacity of the resources Has the capacity involved in the deployment? information provided by the service been tested and verified?

ideally by assisting with and facilitating root cause analysis? Does the operations team meet problem management staff regularly? Does the operations team see the weekly / monthly problem management report?

management to incorporate into the assessment process?

Is capacity management information being monitored and reported on as this service is used, and is this information provided to capacity management?

Is capacity management feeding information into the optimization process?

Are stress and volume characteristics built into the services and constituent applications?

55


Availability Management

Does the design address the availability requirements of the service?

Has the service been designed to fit in with backup and recovery capabilities of the organization?

How has the service been built to address the availability requirements, and how has this been tested?

What testing has been done to ensure that the service meets the backup and recovery capabilities of the organization?

What happens when the service and underlying applications are under stress?

Service Continuity Management

How does the design meet the service continuity requirements of the organization?

Will the design meet the needs of the business recovery process

Has the service been built to support the business recovery process following a disaster if one should occur during or after the deployment or this service?

Is availability management monitoring the availability of the service, the applications being deployed and the rest of the technology infrastructure to ensure that the deployment is not affecting availability?

How is the service’s availability being measured, and is this information being fed back to the availability management function within the IT organization?

Does the assessment use the availability information to complete the proposal of modifications that are needed for the service?

Is the business recovery process for the service tested regularly by operations?

What optimization is required in the business recovery process to meet the business needs?

How is the ability to back up and recover the service during deployment being dealt with?

Will any changes be required to the business recovery process following a disaster if one should occur during or after the deployment of this service?

Is any improvement required in the service’s ability to be backed up and recovered?

56

Release & Deployment Management following a disaster?

Service Level Management

How does the design meet the SLA requirements of the organization?

Does the service meet the SLA and performance requirements, and has this been tested?

Is service level management aware of the deployment of this service?

Does this service have an initial SLA for the deployment phase?

Does the service affect the SLA requirements during deployment?

Financial Management

Does the design meet the financial requirements for this service?

How does the design ensure that the final new or changed service will meet return of investment expectations?

Has the service been built to deliver financial information, and how is this being tested?

Is management accounting being done during the deployment so that the total cost of deployment can be included within the cost of ownership?

Is the SLA visible and understood by the operations team so that it appreciates how its running of the service affects the delivery of the SLA?

Is service level management information available for inclusion in the optimization process?

Does operations see the weekly / monthly service level report?

Does operations provide input into the financial information about the service?

Is financial information available to be included in the assessment process?

For example, if a service requires an operator to perform additional tasks at night, is this recorded? 57


58


Deployment, Planning & Activities There are many planning considerations that need to be considered. Planners should be able to answer the questions included in Table 1. Table 1

Deployment question

Examples

What needs to be deployed?

Do you have a good understanding of the service and release that is being deployed? What are the components that make up the release package? What are the business drivers for the deployment? Is it required to meet a critical business need?

Who are the users?

Which users are affected by the deployment? What language do they use? Do they need any special training?

Are there location dependences?

Are there are holidays, shut-downs or other interruptions to normal business at this location? What level of detail needs to be recorded, e.g. building, floor, room?

Where are the users?

Are all the users and systems local to the deployment, or are some remote, and how will this affect the logistics?

Who else needs to be prepared well in advance?

Do the service desk and support staff need training? Are there any access issues to be solved – security or physical?

When does the deployment need to be completed?

Does the deployment need to be completed by a certain date and time or can it be completed by following a flexible schedule?

Why is the deployment happening?

Is the deployment needed to fix a problem or is it required for some new functionality that has been requested, and do the users understand what is coming?

What are the critical success factors and exit criteria?

How will you know that the deployment has been successful? Who will authorize the deployment? How will you know when the deployment is finished?

What is the current What are the current services, processes and Service Management capability of the capability – capacity, financial aspects, current systems and service provider? infrastructure?

59

Release & Deployment Management Plan and Prepare for Deployment The planning and preparation activities prepare the deployment group for deployment. This is an opportunity to prepare the organization and people for organizational change. During the actual deployment stage the detailed implementation plan is developed. This includes assigning individuals to specific activities. For example a specific individual may be assigned to deliver training for a training activity on the deployment plan.

The entry criteria for planning and preparing a target deployment group or environment include: •

Deployment stakeholders are sufficiently confident in the service release to

deploy the release, own their aspects of deployment and they are committed to the deployment •

Senior management, customers, the business and service provider teams

accept the deployment costs, management, organization and people implications of the release as well as any organization, function and process changes.

An example of the deployment activities that apply to the deployment for a target group is shown below.

Preparing for deployment includes assessing each deployment group’s readiness to receive and implement a release package, identifying gaps that need to be filled and planning the activities required to deploy, transfer or decommission / retire services or service assets. It will also include transferring a service or a service unit as well as move and disposal activities.

60

Release & Deployment Management Manage RFC D1

RFC Authorize Authorize D2 deployment activation start Manage deployment/decommission/transfer for each target group BL

BL

BL2 Change/ transfer financial assets Transfer/ transition business and organization

Assess readiness of target group

Plan and prepare for deployment

Decommission, retire and redeploy service assets

Deploy processes Test deployment and knowledge readiness and activate the service Deploy service management capability

Review and close deployment

Remediate/ back-out release

Transfer Services

Deploy Services

Request for Change that

RFC governs the deployment B

Baseline

Deploy applications, data, information Deploy infrastructure and facilities

61


62


Communication Plan

IT Services Communication Plan Process: Release & Deployment Management

Status:


Version:

Release Date:

63

Release & Deployment Management Communication Plan for Release & Deployment Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered.

This document serves as a GUIDE FOR COMMUNICATIONS REQUIRED for the Release & Deployment Management process. This document provides a basis for completion within your own organization.

This document contains suggestions regarding information to share with others. The document is deliberately concise and broken into communication modules. This will allow the reader to pick and choose information for e-mails, flyers, etc. from one or more modules if and when appropriate. This document was; Prepared by: On:


64

Release & Deployment Management Initial Communication Sell the Benefits First steps in communication require the need to answer the question that most people (quite rightly) ask when the IT department suggests a new system, a new way of working. WHY? It is here that we need to promote and sell the benefits. However, be cautious of using generic words. Cite specific examples from your own organization that the reader will be able to relate to. Generic Benefit statements

Specific Organizational example

Release and Deployment Management provides accurate information on our IT components. Allows us to more carefully control the valuable IT infrastructure. Helps us to more effectively manage our expenditure on IT. Assists with protecting against illegal or unauthorized software.

This is important because…

In recent times our control on IT has… Apart from the obvious benefits, the IT department in recent times has… A recent example of … saw the individual and the company face severe penalties.

The above Communication module (or elements of) was/were distributed; To: On:

By:

65

Release & Deployment Management Release & Deployment Management Goal The Goal of Release & Deployment Management The Goal of Release and Deployment Management can be promoted in the following manner. Official Goal Statement: To deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to Service Operation. •

High visibility and wide channels of communication are essential in this process. Gather specific Release Requirements from nominated personnel

(Special Tip: Beware of using only Managers to gain information from, as the resistance factor will be high) •

Oversee the monitoring of IT Infrastructure releases to ensure that the business needs of IT are not impacted, but taking into account that releases are required to ensure continued high levels of IT Service Transition.

•

Provide relevant reports to nominated personnel.

(Special Tip: Beware of reporting only to Managers. If you speak to a lot of people regarding Service Transition and Operation then you need to establish ways to report to these people the outcomes and progress of the discussions). Always bear in mind the “so what” factor when discussing areas like goals and objectives. If you cannot honestly and sensibly answer the question “so what” – then you are not selling the message in a way that is personal to the listener and gets their “buy-in”.

The above Release and Deployment Management Goals was distributed; To: On:

By:

66

Release & Deployment Management Release & Deployment Management Intrusive & Hidden Activities

The list of actions in this module may have a direct impact on end users. They will be curious as to why staff have a sudden interest in working with them on releases, rather than the historical method of just “doing it”. There could be an element of suspicion, so consider different strategies to overcome this initial scepticism. Release Scheduling • Set out clear procedures to release software and hardware. • Make a clear distinction between a change and a release Release Planning Reviewing the scheduled releases and the potential impact that they will have on the business and allocate a priority level for completion accordingly. Release Categorization All organizations will have differing categories of release that have to be implemented. Pre-defined categories of release allow faster implementation. For example minor, large, and emergency are all categories. Having the way that each of these release types is handled is a sign of an efficient and effective process. Release meetings With the Release Management process we establish a release policy and planning group. The release team should meet on a regular basis to review and discuss proposed releases. The members of the planning committee can change according to the releases proposed. Impact assessment One of the key activities for release management is to review the potential cost and potential risks that the release will bring Approval, Schedule, Build Once approved the release has to be scheduled. This step is done in conjunction with a review of the Forward Schedule of Releases and a review of availability requirements from Service Level Agreements that are in place. Urgent Changes and the Review Despite all the best planning, there will be occasions that an emergency release has to be approved. The major characteristic of this release is that most of the planning work, documentation updates, etc. is done AFTER the release, not before. The review process can be carried out on all major or randomly selected processes. Usually emergency release would be reviewed to see if there are lessons that can be learned. Information regarding activities was distributed; To: On:

By: On:

67

Release & Deployment Management Release & Deployment Management Planning Costs Information relating to costs may be a topic that would be held back from general communication. Failure to convince people of the benefits will mean total rejection of associate costs. If required, costs fall under several categories: •

Personnel – audit verification staff, database management team (Set-up and ongoing) • Accommodation – Physical location (Set-up and ongoing) • Software – Tools (Set-up and ongoing) • Hardware – Infrastructure (Set-up) • Education – Training (Set-up and ongoing) • Procedures – external consultants etc (Set-up) The costs of implementing Release & Deployment Management will be outweighed by the benefits. For example, many organizations have a negative perception of releases that are made by the IT Department. There is a lot of thought that too many releases are made and the releases that do take place cause more problems than they solve. A well run Release & Deployment Management process will make major inroads into altering that perception.

Details regarding the cost of Release & Deployment Management were distributed; To: On:

By: On:

68


Example Business and IT Flyers

IT Services Business and IT Flyers Process: Release & Deployment Management

Statu s:


Versi on:

Rele ase Date:

69

Release & Deployment Management Introduction

The following pages provide 3 examples of flyers that can be printed and distributed throughout your organization. They are designed to be displayed in staff rooms. Note, they are examples, and your input is required to complete the flyers. Remember, the important thing is to ensure that the message delivered in the flyer is appropriate to the audience that will be reading it. So think about how and where you will be distributing the flyers.

70


IT - Release & Deployment Key Points: •

Faster, Timely Releases.

• Accurate Releases. •

Services You Need.

•

Services at the Right Time

• Improved IT Services • Less Disruption • >

IT Services Department Wanted: Improved IT Services The IT Department is constantly improving on the services we deliver. Our most recent focus has been on the Release and Deployment Management process.

it contains, for example, IT employees or Business staff.

>

If you are posting the flyer in staff rooms, then the content needs to reflect the information that will be of use to them. For example, list the benefits to them for following a release management process. This will help set the expectations.

First, determine the audience of this flyer. This could be anyone who might benefit from the information

Where are you going to send this flyer? Which locations will the flyer be posted at?

What process do they need to follow when recording information about releases? What information should they have ready? How does this relate to Change Management? What is the difference? Provide phone numbers for the Service Desk so that they can ask questions about Release and Deployment Management and

THE BENEFITS

THE PROCESS

CONTACTS

71



Where is your authorized software? KEEP YOUR AUTHORIZED

KEEP YOUR AUTHORIZED VERSIONS UNDER CONTROL! Good Release & Deployment Management helps ensure well represented environments.

Release & Deployment Management causes less Disruption!

(ENTER: TELEPHONE NUMBER) IMPROVED SERVICE DELIVERY IS OUR GOAL KNOW YOUR SERVICE RIGHTS!

Sponsored by IT SERVICES

“Constantly improving and aligning to your needs”

72


Deployment Aspects to Assess The aspects to assess include: •

•

Financial aspects and assets: o

Current and required working capital

o

Establishing new or changed contracts, licenses, IPR and digital rights

Issues and risks in delivering the current services that may affect the deployment

•

Applicable health, safety, security and environmental regulations, supplier and procurement aspects

•

Current capability of the business customers and users to use and gain value from the new or changed service

•

Current service, service capability and resources used including: o

Service structure

o

Service dynamics

o

Service metrics and reports, including warranties and service levels achieved

•

Current Service Management capability and resources: o

Differences from the prerequisites for deployment, e.g. inadequate licensing arrangements, network bandwidth

o

Current operations and support resources, e.g. tools, people

o

Support resources and workloads as there may be a significant increase in the number of incidents per user that can stretch the resources for managing incidents, problems and fixes

o

Performance reports and improvement plans

o

Ability to predict and track the actual incident and problem volumes during deployment; this may require updating asset or user records with the date and time of installation or deployment to enable trend analysis

•

Identifying requirements to tailor the new or changed service or underlying solution, e.g. processes, procedures, work instructions

•

Organizational readiness: o

Role, resources and skills gap analysis 73

Release & Deployment Management o

Training needs analysis

o

Ability to assign competent individual to the required roles

o

Motivation and empowerment – does the current organization and culture encourage the application of the required skills? Is there the right leadership and commitment?

o

Assess the readiness of customers, users, service provider staff and other stakeholders such as suppliers, partners

•

Aspects relating to applications, information and data: o

Access to application, information and data

o

Accessing secret, restricted or confidential documents and data

o

Knowledge and experience in using the application – users and support staff

•

Infrastructure and facilities: o

Difficult access, e.g. located high up in a building without appropriate lifting equipment (elevator or crane, etc.); city centre with restricted parking; remote locations

o

Intermediate and final storage and stores for definitive hardware and media

o

IT equipment space and capacity requirements such as: Size and equipment footprints Power requirements and circuit-breaker ratings Uninterruptible power supply (UPS) and generator loadings Temperature and humidity requirements Heat outputs and air-conditioning requirements Door clearance and engineering access requirements Cabling requirements

o

Electromagnetic interference (EMI) and radio frequency interference (RFI) requirements

o

Air quality requirements

o

Weight and false floor loadings

o

Network considerations

o

Equipment health, safety, security and environmental requirements

74


Forward Schedule of Releases

IT Services Forward Schedule of Releases Process: Release & Deployment Management

Statu s:


Versi on:

Rele ase Date:

75

Release & Deployment Management Introduction

Purpose The purpose of this document is to provide the IT Organization with the specifications of the information to be captured on a Forward Schedule of Releases (FSR).

Scope This document provides the following: details of the Forward Schedule of Releases

Audience This document is relevant to all staff in

Ownership IT Services has ownership of this document.

Related Documentation Include in this section any related Release Management reference numbers and other associated documentation:

Release Management Implementation Plan / Project Plan Release Management Policies, Guidelines and Scope Document Release Management Process Objectives and Goals

76

Release & Deployment Management Executive Overview

Describe the purpose, scope and organization of the document.

Release & Deployment Management Overview

The document’s intent is to provide an example of a Forward Schedule of Releases.

It is considered that in order to correctly facilitate the Release & Deployment Management process, the Release & Deployment Manager should be able to coordinate the distribution and activation of software and associated hardware in such a manner as to not cause conflicts and impact on the agreed levels of service. A process in facilitating this is a “Forward Schedule of Releases” (FSR).

Releases that have been approved will be listed in the FSR along with their proposed release, installation and activation dates. The FSR will contain details of those releases that may affect the agreed Service Level Agreements and service availability resulting from such releases.

This step in the process is critical for the success of Release & Deployment Management. As such it is important to ensure the FSR is agreed upon with the Business and the IT Departments.

The parties that will typically be involved in determining and structuring an FSR will include relevant Customers, Service Level Management, Service Desk, and Availability Management.

Agreements on the FSR and its subsequent communication will be performed by the Service Desk.

It is also advisable that the FSR be published via the organizations Intranet or where applicable, the internet.

77

Release & Deployment Management Forward Schedule of Releases The following table provides a template for a Forward Schedule of Release. Release #:

This is the Release Number. This will be allocated either manually by the Release Manager or automatically by an IT Service Management Tool.

Release Type:

This defines the type of release. For example: Major, Significant, Moderate, Minor, Emergency, etc.

Description:

A brief description of the release will be listed.

Status:

Shows the current status of the release. For example: pending release, released, installed, activated.

Approval Status:

This column shows the current approval status of the release. For example, Pending Approval, Approved, Under Review, etc.

Risk Level:

The risk level will indicate the risk of the release to the business. A High Risk would indicate that the release, if unsuccessful, will impact immensely on the organization itself.

You may have your own ideas of a scale to use instead of High, Medium and Low.

Priority:

Performed By:

Priority is used to sort out which releases will occur first. This will be a constant changing value, especially as the needs of the business may change.

You may have your own ideas of a scale to use instead of High, Medium and Low. Shows who will actually be performing the release.

Planned Start Date:

The planned start date for starting the release.

Planned End Date:

The expected end date for the release.

Release Date:

The actual day that the release will be released into the IT Infrastructure. 78

Release & Deployment Management The following table is a template for a Forward Schedule of Releases (FSR).

Release # RFC653

Release Type Minor

RFC654

Significant

RFC655

Major

RFC657

Major

Description Generic Description of release Generic Description of release Generic Description of release Generic Description of release

Approval Status Pending

Risk Level High

Approved

Priority High

Performed By R. Smith

Planned Start Date 10/25/2007

Planned End Date 10/26/2007

Release Date 10/26/2007

Low

Low

B. Jones

10/25/2007

10/25/2007

10/25/2007

Review

Medium

High

A. Thom

10/10/2007

10/11/2007

10/11/2007

Review

Low

Medium

R. Price

10/05/2007

10/29/2007

10/27/2007

79

Release & Deployment Management Appendices

Include any applicable appendices that are needed. Terminology

Make sure that all terminology is captured and documented correctly.

80


Roles & Responsibilities Release and Deployment is primarily responsible for managing all aspects of the end-to-end release process. The release and deployment manager will report to the Service Transition manager as will the Service test manager; however these roles should always be undertaken by separate people, and never be combined, to ensure that there is always independent testing and test verification.

The Release and Deployment Manager

The release and deployment manager is responsible for the planning, design, build, configuration and testing of all software and hardware to create the release package for the delivery of, or changes to, the designated service.

The release and deployment manager has the following responsibilities: •

Manage all aspects of the end-to-end release process

•

Update Service Knowledge Management System

•

Ensures coordination of build and test environments teams and release teams

•

Ensures teams follow the organization’s established policies and procedures

•

Provides management reports on release progress

•

Service release and deployment policy and planning

•

Deals with release package design, build and configuration

•

Deals with release package acceptance including business sign off

•

Deals with service roll-out planning including method of deployment

•

Deals with release package testing to predefined Acceptance Criteria

•

Signs off the release package for implementation

•

Deals with communication, preparation and training

•

Audits hardware and software before and after the implementation of release package changes

•

Installs new or upgraded hardware

•

Deals with storage and traceability/auditability of controlled software in both centralized and distributed systems

•

Deals with release, distribution and the installation of packaged software.

81

Release & Deployment Management However, some of these responsibilities will be delegated to the relevant release team subprocess.

The main components to be controlled are: •

Service documentation including: •

Service Portfolio

•

Service Catalogue

•

Service Level Agreement, OLA’s and UC’s

•

Service Design and specification

•

Application programs developed in house

•

Externally developed software (including standard off-the-shelf software as well as customer-written software)

•

Utility software

•

Supplier-provided system software

•

Hardware, and hardware specifications

•

Assembly instructions and documentation, including user manuals.

Release Packaging and Build

Release packaging and build management is the flow of work (establish requirements, design, build, test, deploy, operate and optimize) to deliver applications and infrastructure that meet the Service Design requirements. The Release Packaging and Build Manager

The release and packaging manager has the following responsibilities: •

Establishes the final release configuration (e.g. knowledge, information, hardware, software and infrastructure)

•

Builds the final release delivery

•

Tests the final delivery prior to independent testing

•

Establishes and reports outstanding known errors and workarounds

•

Provides input to the final implementation sign-off process.

The release packaging and build manager cannot perform this role in isolation: other functions with which there will be significant interface are: 82


•

Security Management

•

Test Management

•

Change and Service Asset and Configuration Management

•

Capacity Management

•

Availability Management

•

Incident Management

•

Quality Management.

83


84


Business Justification Document

IT Services Business Justification Process: Release & Deployment Management

Status:


Version:

Release Date:

85

Release & Deployment Management Business Justification Document for Release & Deployment Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a reference for HOW TO APPROACH THE TASK OF

SEEKING FUNDS for the implementation of the Release and Deployment Management process. This document provides a basis for completion within your own organization. This document was; Prepared by: On:


86

Release & Deployment Management Release & Deployment Management Business Justification A strong enough business case will ensure progress and funds are made available for any IT initiative. This may sound like a bold statement but it is true. As IT professionals we have (for too long) assumed that we miss out on funds while other functional areas (e.g. Human resources and other shared services) seem to get all that they want. However, the problem is not with them, it’s with US. We are typically poor salespeople when it comes to putting our case forward. We try to impress with technical descriptions, rather than talking in a language that a business person understands. For example: We say

We should say

We have to increase IT security controls, with the implementation of a new firewall.

Two weeks ago our biggest competitor lost information that is now rumored to be available on the internet.

The network bandwidth is our biggest bottleneck and we have to go to a switched local environment.

The e-mail you send to the other national managers will take 4 to 6 hours to be delivered. It used to be 2 to 3 minutes, but we are now using our computers for many more tasks.

Changes to the environment are scheduled We are making the changes on Sunday for a period of time when we expect there afternoon. There will be less people to be minimal business impact. working then.

Doesn’t that sound familiar? To help reinforce this point even further, consider the situation of buying a new fridge. What if the technically savvy sales person wants to explain “the intricacies of the tubing structure used to super cool the high pressure gases, which flow in an anti-clockwise direction in the Southern hemisphere”. Wouldn’t you say “too much information, who cares – does it make things cold?” 87

Release & Deployment Management Well IT managers need to stop trying to tell business managers about the tubing structure and just tell them what they are interested in. So let’s know look at some benefits of Release and Deployment Management. Remember that the comments here are generic, as they have to apply to any organization. Benefits

Notes/Comments/Relevance

Through a properly controlled and structured Release and Deployment Management process we will be able to more effectively align the delivery of IT service to the business requirements. This is achieved through involvement that it is anticipated business people will have with releases. (Clever Tip – appoint a Project Manager to the role of Release and Deployment Manager!!) There are clear links between this process and the Change Management. A well run Release and Deployment Management process will ensure that the best returns on the investment are made in implementation of structured processes. A heightened visibility and increased communication related to upcoming release to both business and IT support staff. The reader should be able to draw upon experience regarding the overall negative impact that an unscheduled release has. Also the negative impact on staff morale that has to be dealt with from a release that they weren’t even aware of. Organizations and therefore IT environments are becoming increasingly complex and continually facing new challenges. The ability to meet these challenges is dependent on the speed and flexibility of the organization. The ability to cope with these changes at an increasing cycle time is a direct by-product of a good Release and Deployment Management process. (Reader, here you can describe a missed 88

Release & Deployment Management opportunity, due to slow Release and Deployment Management or a process dragged down by bureaucracy) Noticeable increases in the potential productivity of end users and key personnel through less interruption, higher quality services and less diversion from planned tasks due to urgent or failed releases. The goal statement of Release and Deployment Management is to deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to Service Operation. By the very nature of this statement we can expect less user interruptions. Whether end users and staff take advantage of this reduced down-time is not an issue for IT professionals to monitor. Knowing that we have made more working time available is what we need to publish – NOT productivity rates. An ITIL Release and Deployment Management process will guide you towards understanding the financial implications of a release prior to starting the release process. This has real benefits as it may prevent an organization from starting a change then losing money later as they realize the funds are simply not available for completion. The Release and Deployment Manager will ensure that the risks of the release have been fully assessed prior to starting the release. Risk assessment methodologies form part of other ITIL processes, but the Release and Deployment Manager has the responsibility of making sure that all potential impact areas have been understood. This can be done through site surveys. As a by-product they will also ensure that a sound back-out plan exists that is viable, in case an unforseen event occurs. With a sound Release and Deployment Management process we can expect an overall declining cost of release as fewer and fewer releases have to be backed out. 89

Release & Deployment Management Any ITIL process has the potential to increase the credibility of the IT group, as they offer a higher quality of service, combined with an overall professionalism that can be lacking in ad-hoc activities.

90


Reports, KPIs and other Metrics

IT Services Reports and KPI Targets Process: Release & Deployment Management

Status:


Version:

Release Date:

91

Release & Deployment Management Reports and KPI Targets for Release & Deployment Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE ON SUITABLE KEY PERFORMANCE INDICATORS (KPIs) and REPORTS FOR MANAGEMENT for the Release & Deployment Management process. This document provides a basis for completion within your own organization. This document contains suggestions regarding the measures that would be meaningful for this process. The metrics demonstrated are intended to show the reader the range of metrics that can be used. The message must also be clear that technology metrics must be heavily supplemented with nontechnical and business focused metrics/Kips/measures. This document was; Prepared by: On:


92

Release & Deployment Management Key performance indicators (KPIs) Continuous improvement requires that each process needs to have a plan about “how” and “when” to measure its own performance. While there can be no set guidelines presented for the timing/when of these reviews; the “how” question can be answered with metrics and measurements.

With regard to timing of reviews then factors such as resource availability, cost and “nuisance factor” need to be accounted for. Many initiatives begin with good intentions to do regular reviews, but these fall away very rapidly. This is why the process owner must have the conviction to follow through on assessments and meetings and reviews, etc. If the process manager feels that reviews are too seldom or too often then the schedule should be changed to reflect that.

Establishing SMART targets is a key part of good process management. SMART is an acronym for:

Simple Measurable Achievable Realistic Time Driven

Metrics help to ensure that the process in question is running effectively.

93

Release & Deployment Management With regard to Release & Deployment Management the following metrics and associated targets should be considered: Key Performance Indicator

Target Value

Time Frame/Notes/Who

(some examples) Using data from the Configuration Management Database (CMDB) indicate any particular Configuration items that are going through continual change.

Number of Releases Scheduled Successful releases implemented Number of releases rejected or failed Number of releases backed out (indicating the reason why).

Reason for the release (e.g. Problem Management, business requests, training improvements, etc.)

Incident count related to releases made in previous period.

Number of release reviews completed.

Quantity of releases implemented with an indication of which CI or service was affected. Others

Special Tip: Beware of using percentages in too many cases. It may even be better to use absolute values when the potential number of maximum failures is less than 100.

94

Release & Deployment Management Reports for Management Management reports help identify future trends and allow review of the “health” of the process. Setting a security level on certain reports may be appropriate as well as categorizing the report as Strategic, Operational or Tactical. The acid test for a relevant report is to have a sound answer to the question; “What decisions is this report helping management to make?” Management reports for Release & Deployment Management should include: Report

Time Frame/Notes/Who

The number of releases lodged, quantity rejected and the percentage that were issued as emergency releases. As well as the numbers, a very concise view of major releases can also be included. Summary of releases that are still to be implemented and / or activated. Management will be interested to see the number of higher priority releases still in these states. Importantly each outstanding release should show how long it has been in this status. Releases that have been in waiting for long periods of time may be downgraded or even scrapped. This is to be avoided, as it will increase the costs of IT Services. Backlog details of process activities outstanding (along with potential negative impact regarding failure to complete the work in a timely manner) – but also provide solutions on how the backlog can be cleared. The number of releases attributable to different business areas is also useful. This will help Management to understand departments that are in a state of continual change. Frequent or numerous releases can indicate poor management, fluctuating internal or increasing pressures from external forces. Analysis and results of meetings completed The situation regarding the process staffing levels and any suggestions regarding redistribution, 95

Release & Deployment Management recruitment and training required. Human resource reporting including hours worked against project/activity (including weekend/after hours work). Relevant Financial information– to be provided in conjunction with Financial Management for IT Services This information will include a cost per change summary.

96


IMPLEMENTATION PLAN – PROJECT PLAN

IT Services Implementation Plan/Project Plan Skeleton Outline Process: Release & Deployment Management

Status:


Version:

Release Date:

97

Release & Deployment Management Planning and implementation for Release & Deployment Management This document as described provides guidance for the planning and implementation of the Release and Deployment Management ITIL process. The document is not to be considered an extensive plan as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered for planning and implementation of this process. Initial planning When beginning the process planning the following items must be completed: CHECK

DESCRIPTION

☺ or 2 or date Get agreement on the objective (use the ITIL definition), purpose, scope, and implementation approach (e.g. Internal, outsourced, hybrid) for the process. Assign a person to the key role of process manager/owner. This person is responsible for the process and all associated systems. Conduct a review of activities that would currently be considered as an activity associated with this process. Make notes and discuss the “re-usability” of that activity. Create and gain agreement on a high-level process plan and a design for any associated process systems. NOTE: the plan need not be detailed. Too many initiatives get caught up in too much detail in the planning phase. KEEP THE MOMENTUM GOING. Review the finances required for the process as a whole and any associated systems (expenditure including people, software, hardware, accommodation). Don’t forget that the initial expenditure may be higher than the ongoing costs. Don’t forget annual allowances for systems maintenance or customizations to systems by development staff. Agree to the policy regarding this process 98

Release & Deployment Management Create Strategic statements. Refer to Policies, Objective and Scope document on page 39 for more template information.

Policy Statement

The policy establishes the “SENSE OF URGENCY” for the process.

It helps us to think clearly about and agree on the reasons WHY effort is put into this process.

An inability to answer this seemingly simple, but actually complex question is a major stepping stone towards successful implementation

The most common mistake made is that reasons regarding IT are given as the WHY we should do this. Reasons like “to make our IT department more efficient” are far too generic and don’t focus on the real issue behind why this process is needed.

The statement must leave the reader in no doubt that the benefits of this process will be far reaching and contribute to the business in a clearly recognizable way.

Objective Statement

When you are describing the end or ultimate goal for a unit of activity that is about to be undertaken you are outlining the OBJECTIVE for that unit of activity.

Of course the activity may be some actions for just you or a team of people. In either case, writing down the answer to WHERE will this activity lead me/us/the organization is a powerful exercise.

There are many studies that indicate the simple act of putting a statement about the end result expected onto a piece of paper, then continually referring to it, makes achieving that end result realistic.

As a tip regarding the development of an objective statement; don’t get caught up in spending hours on this. Do it quickly and go with your instincts or first thoughts – BUT 99

Release & Deployment Management THEN, wait a few days and review what you did for another short period of time and THEN commit to the outcome of the second review as your statement.

Scope Statement

In defining the scope of this process we are answering what activities and what “information interfaces” does this process have.

Don’t get caught up in trying to be too detailed about the information flow into and out of this process. What is important is that others realize that information does in fact flow.

For example, with regard to the RELEASE & DEPLOYMENT MANAGEMENT process we can create a simple table such as:

Release & Deployment Management Information flows Process Process Information Release & Deployment

to

ConfigMgt

Release Notification

ConfigMgt

to


Information on attributes and relationships of Configuration Items


to

Change Management

Release Notification

Change Management

to


Control of Releases


to

ProblemMgt

Release Notification with any known errors

ProblemMgt

to


Report of problems introduced by release

Management

100

Release & Deployment Management Steps for Implementation There can be a variety of ways to implement this process. For a lot of organizations a staged implementation may be suitable. For others a “big bang” implementation – due to absolute equality may be appropriate. In reality however, we usually look at implementation according to pre-defined priorities. Consider the following options and then apply a suitable model to your own organization or case study. STEPS

NOTES/ /RELEVANCE/DATES/ WHO

Define the Objective and Scope for Release & Deployment Management Establish and agree on a clear definition for the different types of release within the context of the IT Infrastructure. Seek initial approval Establish and Define Release roles and responsibilities Establish and Define Release Types and their processes. Especially catering for events that can be considered disasters. Establish Release Process Establish and Define Relationship with Configuration Management and Change Management This is one of the most important activities in implementing Release & Deployment Management. Establish monitoring levels Define reporting standards Publicize and market

The priority selection has to be made with other factors in mind, such as competitive analysis, any legal requirements, and desires of “politically powerful influencers”.

101

Release & Deployment Management Costs The cost of process implementation is something that must be considered before, during and after the implementation initiative. The following points and table help to frame these considerations: (A variety of symbols have been provided to help you indicate required expenditure, rising or falling expenditure, level of satisfaction regarding costs in a particular area, etc.) Initial Personnel Costs of people for initial design of process, implementation and ongoing support Accommodation Costs of housing new staff and any associated new equipment and space for documents or process related concepts.

During

0

Ongoing

/

☺

Software New tools required to support the process and/or the costs of migration from an existing tool or system to the new one. Maintenance costs Hardware New hardware required to support the process activities. IT hardware and even new desks for staff. Education Re-education of existing staff to learn new techniques and/or learn to operate new systems. Procedures Development costs associated with filling in the detail of a process activity. The step-by-step recipe guides for all involved and even indirectly involved personnel.

In most cases, costs for process implementation have to be budgeted for (or allocated) well in advance of expenditure. Part of this step involves deciding on a charging mechanism (if any) for the new services to be offered.

102

Release & Deployment Management Build the team Each process requires a process owner and in most situations a team of people to assist.

The Release & Deployment Management process is one of the processes in the Service Transition phase that has a large amount of initial and on-going activity.

The team size may or may not reflect this. Of course a lot will be dependant on the timing of the implementation and whether it is to be staged or implemented as one exercise.

Refer to Release & Deployment Management Roles and Responsibilities on page 75 for more information.

Analyse current situation and FLAG Naturally there are many organizations that have many existing procedures/processes and people in place that feel that the activities of Release & Deployment Management are already being done. It is critical to identify these systems and consider their future role as part of the new process definition. Examples of areas to review are: Area

Notes

Power teams Current formal procedures Current informal procedures Current role descriptions Existing organizational structure Spreadsheets, databases and other repositories Other…

103

Release & Deployment Management Implementation Planning After base decisions regarding the scope of the process and the overall planning activities are complete we need to address the actual implementation of the process. It is unlikely that there will not be some current activity or work being performed that would fit under the banner of this process. However, we can provide a comprehensive checklist of points that must be reviewed and done. Implementation activities for Release & Deployment Management Activity

Notes/Comme nts/Time Frame/Who

Review current and existing Release & Deployment Management practices in greater detail. Make sure you also review current process connections from these practices to other areas of IT Service Design, Transition and Operation. Review the ability of existing functions and staff. Can we “reuse” some of the skills to minimize training, education and time required for implementation? Establish the accuracy and relevance of current processes, procedures and meetings. As part of this step if any information is credible document the transition from the current format to any new format that is selected. Decide how best to select any vendor that will provide assistance in this process area (including tools, external consultancy or assistance to help with initial high workload during process implementation). Establish a selection guideline for the evaluation and selection of tools required to support this process area (i.e. Release & Deployment Management tools). Purchase and install tools required to support this process (i.e. Release & Deployment Management tool). Ensure adequate skills transfer and on-going support is considered if external systems are selected. Create any required business process interfaces for this process that can be provided by the automated tools (e.g. reporting – frequency, content). Document and get agreement on roles, responsibilities and training plans. 104


Communicate with and provide necessary education and training for staff that covers the actual importance of the process and the intricacies of the process itself.

An important point to remember is that if this process is to be implemented at the same time as other processes that it is crucial that both implementation plans and importantly timing of work is complementary. Cutover to new processes The question of when a new process actually starts is one that is not easy to answer. Most process activity evolves without rigid starting dates and this is what we mean when we answer a question with “that’s just the way it’s done around here”. Ultimately we do want the new process to become the way things are done around here, so it may even be best not to set specific launch dates, as this will set the expectation that from the given date all issues relating to the process will disappear (not a realistic expectation).

105


106


FURTHER INFORMATION For more information on other products available from The Art of Service, you can visit our website: http://www.theartofservice.com

If you found this guide helpful, you can find more publications from The Art of Service at: http://www.amazon.com

107

Release and Deployment of Production-Ready Software: Software Configuration Management Implement, Control, Manage and Integrate Best Practices Handbook - Ready to use bringing Theory into Action

Capacity Management Handbook, Monitor, Analyze, Tune, Manage Demand and Plan Your Organizations IT Capacity Demands Best Practices Handbook - Ready to Use Bringing Theory into Action

Software Configuration Management

The Build Master: Microsoft's Software Configuration Management Best Practices

The Build Master: Microsoft's Software Configuration Management Best Practices

Availability Management for IT Services Best Practice Handbook - proactively manage and maintain Service Levels to meet SLA expectations in Reliability, ... - Ready to use bringing Theory into Action

Software deployment, updating, and patching

Release It!: Design and Deploy Production-Ready Software

Software Process Quality: Management and Control

IT Services Portfolio Management Best Practice Handbook: Planning, Implementing, Maximizing Return on Investment of Strategic IT Portfolio Management - Ready to use bringing Theory into Action

Agile Software Development: Best Practices for Large Software Development Projects

Software Architecture Knowledge Management: Theory and Practice

Software Architecture Knowledge Management: Theory and Practice

Software Deployment, Updating, and Patching (Information Security)

Software Deployment, Updating, and Patching (Information Security)

Software Project Survival Guide (Pro -- Best Practices)

Software Metrics: Best Practices for Successful IT Management

Software Management Approaches: Project Management, Estimation, and Life Cycle Support: Software Best Practice 3 (Software Best Practice, 3) (v. 3)

Automated Defect Prevention: Best Practices in Software Management

Automated Defect Prevention: Best Practices in Software Management

Web Application Design Handbook: Best Practices for Web-Based Software

Software Metrics and Software Metrology

Software Metrics and Software Metrology

Accounting Control Best Practices (Wiley Best Practices)

SAP Security Configuration and Deployment: The IT Administrator's Guide to Best Practices

Accounting Control Best Practices

On Time, Within Budget Software Project Management Practices and Techniques

Release and Deployment of Production-Ready Software: Software Configuration Management Implement, Control, Manage and Integrate Best Practices Handbook - Ready to use bringing Theory into Action

Capacity Management Handbook, Monitor, Analyze, Tune, Manage Demand and Plan Your Organizations IT Capacity Demands Best Practices Handbook - Ready to Use Bringing Theory into Action

Software Configuration Management

The Build Master: Microsoft's Software Configuration Management Best Practices

The Build Master: Microsoft's Software Configuration Management Best Practices

Availability Management for IT Services Best Practice Handbook - proactively manage and maintain Service Levels to meet SLA expectations in Reliability, ... - Ready to use bringing Theory into Action

Software deployment, updating, and patching

Release It!: Design and Deploy Production-Ready Software

Software Process Quality: Management and Control

IT Services Portfolio Management Best Practice Handbook: Planning, Implementing, Maximizing Return on Investment of Strategic IT Portfolio Management - Ready to use bringing Theory into Action

Agile Software Development: Best Practices for Large Software Development Projects

Software Architecture Knowledge Management: Theory and Practice

Software Architecture Knowledge Management: Theory and Practice

Software Deployment, Updating, and Patching (Information Security)

Software Deployment, Updating, and Patching (Information Security)

Software Project Survival Guide (Pro -- Best Practices)

Software Metrics: Best Practices for Successful IT Management

Software Management Approaches: Project Management, Estimation, and Life Cycle Support: Software Best Practice 3 (Software Best Practice, 3) (v. 3)

Automated Defect Prevention: Best Practices in Software Management

Automated Defect Prevention: Best Practices in Software Management

Web Application Design Handbook: Best Practices for Web-Based Software

Software Metrics and Software Metrology

Software Metrics and Software Metrology

Accounting Control Best Practices (Wiley Best Practices)

SAP Security Configuration and Deployment: The IT Administrator's Guide to Best Practices

Accounting Control Best Practices

On Time, Within Budget Software Project Management Practices and Techniques

Recommend Documents