Home �   ITIL�  Index

The Importance of Change Advisory Boards

Mar 10, 2004

George Spafford

CAB Meeting Topics

The group should meet weekly, or on some appropriate regular schedule, to discuss change-related matters. Topics for discussion include:

  • Newly submitted requests for change (RFCs) -- The CAB reviews change requests and makes a determination to change, reject, or request more information.
  • Review of the minutes from the last meeting -- Ensure that people are aware of the decisions made last time and review the status of any open actions.
  • Review change status -- Update the status of approved change requests in regard to schedule, implementation phase, priorities, etc.
  • Post Implementation Review -- For completed changes, successful or not, review what went good, bad and lessons learned.
  • Review health of the change process -- There are two parts to this. First, a detective control system, such as Tripwire, should be used to detect all changes. These changes should then be reviewed by the CAB to ensure that they tie back to approved changes. If there are unapproved changes, then the CAB should launch an inquiry to determine the source and reason for the change. Second, the CAB must ensure that service-level agreements are being met. If not, then corrective actions must be taken.
  • Membership Composition

    For each class of system, or specific system depending on its criticality to the organization, a change advisory board should be defined. The goal is to have the right people in attendance to ensure that the necessary considerations are made. For example, Saturday's maintenance window may look great to IT, but make accounting a nervous wreck because it has a financial period close coming up and can't risk the proposed general ledger change corrupting the system.

    As you can imagine, the composition of the CAB will vary. The following list is to foster discussion about who should attend.

  • IT Operations
  • Development
  • Security
  • IT Management
  • Vendor Manager
  • Project Manager
  • Vendor representatives
  • Customer
  • Customer Advocate
  • User
  • User Advocate
  • Vendors?
  • You'll note that the above list includes internal vendor management as well as vendor representatives, and for good reason. Even though IT may not own the code and hardware changes on a vendor-managed server, it has every right to request involvement in changes to ensure that availability and security are not compromised. In the end, the vendor may cause the problem, but it will be your organization that pays the price!

    Want to discuss this article and/or Change Mangement and the Change Advisory Board further? Visit our IT Service Management Forum .