Change and Release Management
There are many classifications in ITIL and Agile alike. Different components of the methodologies include a variety of different actions, which are aiming to help the client better utilize its resources. Sometimes, these resources need updating or upgrading as part of the continuous improvement those frameworks are offering. Inevitably, this leads to some kind of change of the status quo or some kind of new release of the upper-mentioned resources - it depends on the point of view of how you look at it. There are various titles you will stumble upon when the time comes for a radical improvement of the software, the process, the marketing strategy, you name it. Some are calling it Change management, others will title it Release Management, third will have implemented it as an Improvement cycle, it all depends on the structure and the iteration of the methodology you are using.
According to some in ITIL, the categorization if a change is corrective or evolutive. "Corrective" is only a word we use to describe the nature of this type of change. You will not find it as an official term in ITIL. So depending on the choice you have, you will be either fixing flaws or upgrading a service. Though the corrective iteration should be constant with every version of the product you produce. Because normally it is accepted that changes that fix bugs are good, but in order to reduce reactive/amending necessity you need to first get your testing right in the phase of service transition.
And on the other hand, a record is always obligatory when there is a change in production, no matter what the reason (fix bugs or produce a new version). There is an undisputed saying in ITIL: "Incident drives problem, problem drives change, change drives release". So in this case, you have some overlapping of change and release management, but it is just a separate occasion. You can still combine terms or production cycles, but that won't be a pure ITIL, if such animal exists. The trigger of a corrective change is incident/problem management; while the one for the evolutive/developing change is demand (of a new feature, from the client, the obsolete version of the product, etc.)
It should be acknowledged that the distinction of the two approaches is driven not by the methodology itself, but by need and practical implementation. That is why ITIL has up-to-today three versions already and keeps evolving and adding new features or requirements. And they should not be mistaken with the same separation in Release/Deployment Management, where you could have major, minor and maintenance changes.
Let's go back to "corrective" change. So far, it is obvious that the latter is connected in a way with a relevant problem or incident record. The goal is to show how the processes interconnect and communicate among themselves to find a solution. Here comes the question: What is a standard or a normal change? Was it the one we have implemented successfully many times before this occasion? Can it be logged as one change for one year or for a particular period of time and carry out the activities or it should be spread to smaller changes with every phase of the project?
Again here the opinion is not unanimous. If you have a low risk profile that might also include, but is not limited to downtime, and there is no danger when you go forward with the change, it can be nominated for the "fast Track" as a standard change. And still you will need a schedule approval of all the cycle, including the "fast Track". To build or accept a standard change, we will need documented knowledge to perform it, and that should be pre-approved. That is a prerequisite for the "standard" change. So let's sum it up: we raise a change to provide the management team with accountability and they should have the possibility to say why and when they need something. The standard change is pre-approved, low risk, repeatable changes that can be verified by the change process owner.
Here is an example: As part of a problem investigation, until permanent solution is found, server is set to be rebooted daily on a schedule at a time agreed with the business. The question arises how this automated reboot will work alongside Change Management process:
1. Is a standard change required to be created for each automated daily restart?
2. No standard change request raised, reboot information captured in the problem record.
Some specialists might say this is a workaround to a known problem in an open change request attached to an open record. Hence this will give you the evidence to implement the workaround. As in every change, there should be an approval document attached to the problem. This saves the multiple change requests and the change control should be sufficient. Thus it becomes a standard operating procedure. There is one record to implement the procedure. Adequate testing is necessary to prove the repeating cycle. Once a working solution is found, raise another change request to implement it permanently and remove the workaround from the configuration files.
This is a simple example of a "corrective" change. Do not get frustrated by all the terms, but try to visualize the situation. Once you do that, you will see that Change management is not at all a scary beast.