Branimir Valentic 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.
Where does it fit?
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.
What kind of plan is it?
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:
- General elements – this includes information like description of a release, scope, or reference to, e.g., Request for Change (that triggered the release), roles involved in release deployment, etc.
- Risk assessment – RDM is an activity-intensive phase in the service (or change) lifecycle. That imposes a need for thorough risk management and risk remediation measures. This is an important prerequisite to achieve the desired quality level of deployed service.
- Build planning – build depends on the service, technology, etc. and is not detailed in either ISO 20000 or ITIL. But, building a service (or changing an existing one) needs to be planned from a resource point of view (e.g., necessary environment, licenses, people …)
- Testing – this is a very important part of the RDM process (read the article ITIL Transition – All about testing in Release and Deployment Management to learn more).
- Service release and deployment – there are various approaches to release and deployment of the service. This is where the IT service provider gets in touch with the live environment. Therefore, errors should be minimal and activities planned in as much detail as possible. This also includes a remediation or back-out activities plan (activities that take place if deployment is not successful and you need to bring the service back to its previous state before deployment started).
Figure: Excerpt from the Release and Deployment Plan
And … the purpose?
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?
