The production environment is holy. It is the most important component that we have in our IT service. Thus all changes that will enter it needs to be “certified”, or else, expect a chaos.In IT Service Management, two processes are focused on this- Change Management and Release Management, both of which are part of Service Transitions lifecycle.
Change Management is the IT Service Management process focusing on managing all of the changes in your IT service. This encompasses all environments- production, development, test, and even QA. It has 2 main goals as follows (1) Ensure that standard method is being applied for all changes, and (2) All changes in service assets and CI ( Configuration items) are recorded in the CMS (Configuration Management System). Change Management therefore avoid several risks that we have whenever we deploy something in production – by reducing the unplanned outages, unauthorized changes, project delay, low Quality of Change score, and high number of emergency changes.
Release Management on the other hand is the process responsible for build, test, and design phase of the project that was aligned in Service Design. It also includes a quality service transition or handover plan to the ongoing operations to ensure that everything that they need will be present once the project or change is moved to production. The primary goal of release management is to ensure that the projects and changes are developed with quality and will be deployed to operations with reduced or zero business impact. Usually, release managers maintain a release to operations checklist which will ensure that everything they need from the project team is well-documented and tracked.
Now, let’s go to the topic on how can these two processes help protect the production? At first, you might think that this will just be an additional incremental cost with an average business value. But if you will try to dig down, you can see how it will help your IT service to be a lot better.
Change and Release Management work hand in hand to ensure that there will be zero gap during the handover of Project team to Operations. As I mentioned earlier, usually, there is a checklist called “ Service Transitions Checklist” . This is a long and detailed file documenting all of the requirements of Operations before something is moved over to production. It should be put in place even as early as Service Strategy. Major buckets of requirements for this checklist are (1) Costing and Budget, (2) Resources/People, (3) Processes, (4) Documentations, (5) Quality Gates/Checks, and (6) Test Results/Simulations. To give an example, if there is an expected market expansion happening, you need to prepare a checklist which contains the additional support needed for that market and the budget needed for it.You also need to ensure that the development work going on for the market expansion is in place, and all of the test results submitted passed with no open issues. At the end of the tracking and monitoring of this checklist, and at the end of the project, there should be a meeting to formally check with the operations team leader on whether he or she is aligned for the project to be moved to production already. If the team will not be able to meet this approval, then they need to fulfill the remaining conditions/requirements of the ongoing support team for their project to go live.
As you can see, Change and Release management together helps form a strong foundation for production releases.