Published: April 25, 2008 | Updated: October 10, 2008
The next process is to have the change approved.
Figure 6. Approve the change
Activities: Approve and Schedule the Change
Approval of a change is driven by its category. Approval for a significant or major change usually begins by presenting the change to the appropriate approving body—a team of reviewers typically known as the change advisory board (CAB). These are key people who represent many perspectives and who will be held accountable for the results of the change. The considerations involved in establishing the CAB are discussed in the Governance, Risk, and Compliance SMF. Emergency changes are normally reviewed by an emergency committee of the CAB for fast-track approval.
It is up to the CAB to determine if the change should:
Be approved and scheduled.
Be refused and ended.
Be returned to earlier processes of this SMF for further clarification and consideration.
Understanding the potential impact of change is fundamental when making approval decisions. The inputs for the approval process include:
The category of the change—Standard, Minor, Significant, Major, or Emergency—which summarizes the complexity and resources required, including people, money, and time.
The potential impact of the change on the organization’s configuration and users, including service downtime.
This information helps in the identification and selection of appropriate reviewers with sufficient knowledge and authority to make a decision.
Standard changes require little effort to implement, carry a low level of risk, and have pre-defined approval. If a change has been classified as a standard change, it promptly moves through the minimally required approval and documentation process to release. Minor changes can be approved by the Change Manager. All other change categories require approval of the CAB.
The methods for reaching a decision to approve or reject a change should be determined before the CAB reviews the change. Depending on the governance models chosen by an organization, voting is often employed to reach a decision and move the change into another activity or to stop it altogether.
Once the CAB reaches a decision, it is important that the conclusion be documented in the RFC so that the knowledge gained during the processing of the change is captured. This allows for more efficient auditing of the change management process as well as providing information that can be used in additional iterations through the change process.
The following table lists the activities involved in approving the change. These include:
Routing the change to the correct approving body.
Processing standard changes to release.
Analyzing the impact of the change and identifying reviewers.
Approving or rejecting the change, or seeking additional information.
Updating the RFC.
Table 7. Activities and Considerations for Approving the Change
Activities
Considerations
Route the change to the correct approving body
Key question:
According to the IT governance processes, what governing body has the approval authority for this change based on its classification?
RFC added to the CAB’s agenda or given to the Change Manager
Standard or minor changes given to the Change Manager
Best practices:
Approving bodies should have some members that participate in change approvals on an ongoing basis. These standing members should be well versed in weighing the broader implications of making changes.
In addition to standing members, include personnel and experts from parts of the organization affected by the change or who can add value to the discussion of the change. These additional members are chosen on a case-by-case basis.
Beware of the “this is obvious, just do it” decision. Solicit sufficiently broad input by involving a variety of parties in the approval body so that there is rigor in identifying tradeoffs.
Process standard changes to release
Key questions:
Has this change been classified as a standard change?
Are the change tasks well known and proven?
When this standard change has been performed, has it always resulted in expected outcomes?
Does this change fit in the next available change window?
Inputs:
The RFC under consideration
List of approved standard changes
Outputs:
Identified standard changes proceed directly to development (if needed) or to release
Documentation of a standard change having passed through approval (see Process 6: “Release the Change” for more information)
Best practices:
”Tried, Tested, and True”. These are characteristics of standard changes. Early examples of these changes were not standard, but as more examples of these changes were done, knowledge about them was captured. There is a high level of predictability and confidence that a standard change will yield expected results, without exception.
Because the types of changes that have been pre-approved as standard changes are known to have a low impact on the environment and are a low risk to it, they do not need to be reviewed again by the CAB or even the Change Manager. This, however, means that care must be taken during the initial screening to ensure that a change request that has been categorized as standard is, indeed, one of the pre-approved change types and fits in the change window.
Document the approval of a standard change including when it was approved and the intended results of the change.
Analyze the impact of the change and identify reviewers
Key questions:
Who can best perform and evaluate an impact analysis for the change?
Does the impact analysis support the classification of the change?
Will policies, procedures, or any aspect of regulatory compliance be affected by this change?
Has the business case changed since the change was initiated?
Who in the business is most likely to be affected by this change in terms of either its success or failure?
Who has the most relevant IT technical knowledge?
Who would best understand the implications to the business of not making this change?
Who will best understand the security and privacy implications?
Who can represent the policy and compliance issues that might result?
Inputs:
The RFC and any related RFCs under consideration
Additional information about impacted areas needed in the review process
Outputs:
Standing members of change review bodies
Invited experts and affected user representatives
Best practices:
Completeness in impact analysis includes looking across all requests for changes affecting a service so that impacts are evaluated comprehensively. The evaluation procedures include processes to evaluate the costs of the changes and a means to verify that the expected business benefit exceeds cost (or that the change is mandatory).
Revisit the business case and impact analysis of the change to help ensure that the change and the business case still make sense. Use the impact analysis to determine the areas of the organization that should participate in change review and to identify the potential experts or user representatives who should participate in the review.
Record how reviewers were identified and the fact that they agreed to participate in the review. Demonstrate that the impact of the change was considered from a broad perspective when identifying reviewers so that best efforts could be given to the approval decision.
Approve or reject the change, or seek additional information
Key questions:
Are all members of the change review body prepared to make the decision?
Is there a predetermined approach to resolving impasses in approving decisions or determining tie-breakers in voting?
Does the change really need to be made?
Is the timing right to make the change or is there a better change window?
Input:
The RFC with change log and any other accompanying information from the analysis process
Outputs:
The RFC is approved and scheduled or rejected or returned
Any required contingencies for implementation
Documentation of the approval process
Best practices:
Implement all approved requests on a timely basis. Keep the business case and impact analysis close in time to the approval of a change to help ensure that the change is still relevant and the right thing to do.
Retain minutes of the change approval meetings as part of the documentation of the process and participants.
Identified contingencies should be kept as simple and direct as possible to minimize additional judgments or interpretations of the RFC.
Update the RFC
Key questions:
Is all information available to complete the documentation requirements for the RFC?
Who will update the RFC?
Who needs to know the results of the CAB review?
Input:
The RFC and change log
Output:
Updated RFC and change log
Communication to affected groups
Best practices:
Timely completion of documentation and status of the RFC will reduce confusion or ambiguity around the status of the change.
Timely documentation also aids management’s assessment of change, risk mitigations that depend on changes moving into production, and accurate metrics indicating the maturity of the change process (for example, the number of changes authorized per week, the number of changes denied approval, and the number of standard changes automatically approved each week).
When a change is approved and scheduled, update the CMS with the future state and date of the configuration change. This will be used in evaluating other proposed changes.
.jpg "Cc543246.image6(en-us,TechNet.10).jpg")