Published: April 25, 2008 | Updated: October 10, 2008
The next process is to classify the requested change.
Figure 5. Classify the change
Activities: Classify the Change
After the RFC is initiated, the next process is to classify the request.
The following table lists the activities involved in classifying the change. These include:
Identifying the priority of the change.
Identifying the category of the change.
Checking and validating the configuration, assessing th risk, and updating the RFC.
Table 6. Activities and Considerations for Classifying the Change
Activities
Considerations
Identify the priority of the change
Key questions:
Is this a low, medium, high, or emergency priority change?
Priority levels should be designed with specific time frames and should support the business requirements. A typical priority ranking includes:
Low. The change can wait until the next scheduled release.
Medium. Because of its impact level, the change cannot wait until the next scheduled release.
High. The change needs to be released as soon as it is complete and has been tested.
Emergency. The change needs to be released as soon as possible; many of the approval and the development steps are abbreviated.
Best practices:
The Change Manager and RFC initiator might need to negotiate the priority if they are not in agreement about it. Define an escalation process.
If there are too many emergency and high-priority changes, review the reasons for the volume. This may indicate that staff members are avoiding the process or that the process is not effective.
Identify the category of the change
Key questions:
What category does the change belong to?
Categories take into account the resource requirements for the change, the impact to the business of doing or not doing the change, organizational experience with the change, and new technology or processes. Typical categories include:
Standard change. This category is low risk because it has a set release path that has been proven to be successful, it has minimal business impact, and it has a known set of release procedures.
Minor change. This category affects a small percentage of users and resources. Also, the risk of an outage is less because of the organization’s experience in implementing this type of change.
Significant change. This category has a moderate effect on users, resources, and the business. It might involve downtime of services and may also involve a situation in which the organization has less experience with the product, infrastructure, or the client involved in the change.
Major change. With a high risk and high cost, this category involves the greatest potential impact on users and resources. It might also affect a business-critical system and could involve downtime of the service.
Emergency change. This category is high risk because of the urgency of release and the minimal time in which to test it. It is relatively uncertain if the change will succeed, and there is a big impact on the business if it fails. This type of change is often a result of an urgent incident. These changes are escalated to the Change Advisory Board/Emergency Committee (CAB/EC) for fast-track approval. (For more information about the CAB, see Process 4: “Approve the Change.”)
Unauthorized change. This level involves changes that occur outside of the agreed-to change management policies or that are specifically forbidden.
Best practices:
Effective use of standard changes is important for keeping the process manageable and usable. Evaluate minor changes that go through the CAB process for recategorization as future standard changes.
Be as specific as possible in defining what is and is not a particular type of change.
.jpg "Change process 3.jpg")