As both objectives are practically the same, we can wonder why these two processes, Change Management and Release & Deployment Management, were divided into two different processes. Why not settle for only one process!
Hence the necessity of understanding complementary natures between both processes.
► Change Management has the initial role of "checking the advantage of a change", then mainly the role of "quality control" of the whole design, integration and finally deployment process. Note that a change can be a new IT Service or the evolution of an existing one.
► The essential role of Release and Deployment Management is to organize the assembly supply chain of components (subject to change) - previously designed in their test environment - integrate them into a pre-release environment and finally, actually release them.
So, even if their benefits are similar, their types of inputs remain different. The first one is a good quality "controller" while the second one specializes in "logistics". Both guarantee quality, optimized costs and compliance with deadlines in accordance with business expectations.
The following illustration shows the positioning of Change Management and Release and Deployment Management processes on a Service lifecycle.
This picture addresses Build Project Management. It is time now to introduce these activities within Service lifecycle. Project and Activity Management is not developed as a fully fledged good practice in the ITIL framework. It is only mentioned. However, build activities linked to design projects are conducted simultaneously with Change Management process activities. It is important for stakeholders of both processes to clearly locate them and understand their interactions and possible overlaps. (e.g. a change build is nothing else but one of the stages of a project).
The spectrum of action of Change Management overlaps the level where change occurs. It can relate to only one component (or CI), or several. And the latter is/are directly concerned by change.
Release and Deployment Management deals with "Release" units. Release is none other than the minimum unit to produce. It includes a number of components (or CIs) systematically assembled together. A Release can be bigger than the number of components concerned by change. For ITIL, a release not only aims at producing modified components. This model generally meets functional and technical consistency requirements.
But should this release contain one, a few or many changes (i.e. modified components), the unit produced will be the same. That is precisely where the Release and Deployment process brings an optimization.
The illustration below shows the implementation levels of both processes. Change Management relates to components. Release and Deployment Management assembles component releases.
Change Management responds to a logic of individual planning of change. Most activities managed by Change Management are linked to project planning, i.e. are in line with the specific goals of every project customer. Planning is thus made case by case and can be adjusted individually, depending on project progress.
Release planning responds to a different logic. Release takes place according to a schedule set up at the beginning to meet business requirements, such as product launches, functional or basic updates, etc. It can also be linked to technical constraints such as an editor and manufacturer roadmap. But by nature, it is fixed. Should projects be frequent, long or late, this planning remains fixed. However, it shows a minimum flexibility through sufficiently high frequency or revision of set-up planning when new business requirements occur.
This is a search for balance between two objectives which are difficult to combine: "stability" and "agility". How is it possible to avoid regularly penalizing the business because of negative consequences of changes carried out successively? By grouping them*. Also, producing a grouped release makes it possible to set up a unique unit size according to release type. This makes assembly work, integration, tests (validation) and deployment (since size does not change) predictable, and implicitly makes the organization of stakeholders teams in Release and Deployment Management process activities easier.
* This point will be further developed in the paragraph about the "underemployed Release Policy concept" in the chapter entitled "True life".
The illustration below completes the positioning of processes in the lifecycle, adding the notion of successive release "trains" planned by Release and Deployment Management.