The Change Management process is one of the most problematic processes between operations and development because it ends up blocking processes and changes, especially when the company has agile processes, where changes happen constantly, almost every day.
Of course, you understand that the change process has to bring that balance into the IT area, right? It has to approve changes but also manage risks.
Understand what Change Management is, the Authority within this subject, and the types of changes that exist.
About Change Management
Also called Change Enablement, Change Management can be easily defined as a practice that ensures that risks are properly assessed, authorizing the continuation of changes and managing the change calendar in order to maximize the number of successful changes to services and products.
That is, Change Management deals with the balance between the beneficial effects of change and the effort to protect against its adverse effects.
Thus, the term change is the addition, modification, or removal of anything that may have a direct or indirect impact on services.
The scope of Change Management is defined in each organization.
Typically, it includes all IT infrastructure, applications, documentation, processes, agreements, and contracts with suppliers, as well as anything that may impact – directly or indirectly – a product or service.
What is the Change Authority?
In summary, Change Management must balance the need to make beneficial changes that will deliver additional value with the need to protect customers and users from the adverse effects of these changes.
Therefore, all changes must be evaluated by people capable of understanding the expected risks and benefits. Then they must be authorized before implementation. However, it should not introduce unnecessary delays.
Thus, in Change Management, there is an entity that authorizes a change. And this is known as the change authority.
Because of this, it is essential to designate the correct authority for each type of change to ensure that change control is effective and efficient.
In the case of extremely fast-paced organizations, it is common to decentralize change approval, making peer review one of the high-performance indicators.
Whoever the change authority is, broader communication may be necessary in the evaluation activity to obtain specific knowledge and ensure that people – in IT and in the organization – are prepared before implementation.
Types of Changes
An important aspect for the success of Change Management is knowledge of the three types of changes that need to be managed, each in its own way:
Standard Changes
Firstly, Standard Changes are low-risk, well-known, and fully documented changes.
That is, these are the changes we consider pre-authorized: we can implement them without the need for additional authorization.
Often, we initiate this type as a service request, but it can also represent operational changes.
The rule is: when creating or changing the procedure for a standard change, it must undergo a full risk assessment and authorization like any other change. In this case, all standard changes should be treated as a “normal” change the first time.
It is not necessary to repeat this assessment for each implementation of the standard change, but only when there is a change in its treatment and execution.
Normal Changes
On the other hand, Normal Changes are those that require scheduling, evaluation, and authorization, following a defined process.
Such change models, based on the characteristics of the change, will determine the roles for evaluation and authorization.
Some normal changes are low risk and the change authority for them can make quick decisions, often with the aid of automation to speed up the steps.
Others are much larger and significant, and the change authority may be from senior management, such as the executive committee.
In short, a normal change starts with a change request, which can be created and updated manually, or through automation tools, such as continuous integration and deployment, present in agile or DevOps organizations.
Emergency Changes
Finally, these are the changes that need to be implemented as soon as possible. For example, to resolve a more severe incident or implement a security update.
In general, we do not include emergency changes in a change schedule or agenda. And the evaluation and authorization process is executed more quickly to speed up implementation.
Emergency changes, as far as possible, should undergo the same tests, evaluation, and authorization as normal changes.
However, some documentation may be postponed until after implementation. And even reduce testing due to time constraints, but never dispense with risk and impact assessment.
In addition, it is worth mentioning that it is common to have a distinct change authority for emergency changes. When it is made up of a small number of senior managers who know the risks involved in the business.
If you have any questions about Change Management, feel free to comment.
English 
