![Advisera Branimir Valentic](https://advisera.com/wp-content/uploads/blog_authors/branimirvalentic.jpg)
May 30, 2017
Maybe you have heard the proverb saying that preparation is half the battle. The same is true for release and deployment of new service, or changes to existing service. The point is that the IT services we use today are rising in complexity. Once we start using them, it’s hard to be aware of the effort needed to get them into the live (productive) environment.
The complexity of the services and the expectations of their users require proper planning while creating the service. For the purpose of this article I will not go into details of the service design (the Service Design Package is a comprehensive description of the future service and the trigger for service transition activities; you can learn more in the article ITIL Service Design Package – everything under one roof), but I will focus on how to be as prepared as possible to transition the service (or change an existing one) from design into the live environment.
No matter whether you are implementing ITIL or ISO 20000, the Release and Deployment Management (RDM) process (read the articles ITIL Release and Deployment Management Part I – General principles and service testing and ITIL Release and Deployment Management Part 2 – deployment methods and early life support to learn more about the process) is one of the most important processes in any IT Service Management (ITSM) organization. RDM connects design of the service (or change to existing service) and operation (where service is in the live environment), whereas quality of delivered service is set at the end of RDM activities.
But, RDM is never efficient if Change Management and Service Asset and Configuration Management (SACM) are not implemented. Change Management is particularly important. Actually, RDM is executing what Change Management authorizes. That means, once a change is authorized, RDM takes over and implements the change. But, Change Management is still (actively) present and manages the change implementation.
Release planning is one of the first activities once the change is authorized and given to RDM for the implementation. Release and deployment planning begins once the change is authorized and ends when Change Management authorizes implementation of the release.
The Release and Deployment Plan, as its name implies, is your document where all details necessary to successfully deploy a new service, or change an existing one, will be assessed and activities in the scope of the RDM planned. ISO 20000 sets requirement to plan deployment and provides some necessary details. ITIL gives extensive recommendations about items that need thorough analysis and preparation in order to efficiently deploy new or changed service.
The inputs to create the Release and Deployment Plan are functionality (what does the service do?) and components in the scope. So, the content of such a plan (typically) includes:
Figure: Excerpt from the Release and Deployment Plan
Arguments regarding the Release and Deployment Plan’s content could last for some time. But, the fact is that if you want to keep efficiency inside the ITSM organization and in the services (and changes) you put into the live environment – you can’t sit still and expect that everything will run smoothly because it’s logical to be like that. That’s where a good plan comes into play. Content – well, that depends on the service, its complexity, the environment, the ITSM organization …
And, last but not least, why would you do that – proper planning? Either you control the process, or the process controls you. If you want to have the release under your control (which I would strongly suggest), you must implement management mechanisms. The Release and Deployment Plan is just one of these. Use it to the maximum, as it pays back well once the service is in the live environment. Services in the live environment have a “judge” – your customers. It’s better to impress them, than to disappoint, isn’t it?