Overview 

The overall goal of the CAB is to ensure that the change presented has an acceptable risk for the desired outcome.  If it becomes obvious during the CAB that clients are unaware of the change, or that a security view has yet to be completed, or that the change is architecturally too complex for a quick CAB discussion, then that change should be held back until those issues are resolved.  Another goal is documentation of the change for reporting and future review.  

The GCU CAB is an advisory board.  In the end it is up to the service manager to make the decision on whether to implement the change.  If the CAB makes suggested modifications to the change and the service manager does not agree, then the CAB manager should escalate these concerns to the _____  for awareness.   

Dashboard 

All GCU changes reviewed at the CAB are available on the change dashboard.  It should be available to all GCU staff.  The dashboard is located: _____.  If you do not have access to the dashboard, contact the change manager.  

CAB Meeting 

The following questions should be considered when running a CAB. 

  Top of Form Fields 

Give the summary fields a quick overview.  Ensure Priority, Risk, and impact are correct.  GCU has no guidelines at present on what constitutes priority, risk, and impact levels, so use your best judgement. 

  Description 

The short description should be specific enough so somebody reviewing just can understand the change.  List the service or server and what the change is to that service.  This description goes out in several reports. 

The long description has more details.  Version numbers if doing upgrades should be included.  Ensure the actual names of the systems being modified are included.  The goal is that somebody can search on reasonable keywords in the future and find this change.  

  Date 

Review the implementation date and ensure it works for the service.   GCU prefers doing production changes outside of business hours, and outside of times when school is in session (e.g. Spring break) but in some cases that is not appropriate.  If the service manager has data that shows when the least impactful time for the change is, then you should follow the recommendation.  

  Conflict Check 

Always check for conflict. Even changes to completely isolated systems can be impacted by external changes such as network maintenance.  A conflict does not preclude the change from going forward but should give you pause to consider the impact of multiple changes at the same time.   

No changes should occur during change “freeze dates” unless the service manager can articulate a specific need for urgency and the impact is minor.  Changes occurring during the change freeze dates may need to be escalated to the ____ for approval.  

  Implementation 

The implementation plan should be complete enough that anybody familiar with the system can implement it based on the steps described.  Recall that a goal of change management is to document the change for future review.  Is the implementation plan sufficient that somebody can come back to it in a year and repeat it?   

It is perfectly reasonable to link to an external article for the implementation plan so that it can remain more dynamic.  

  Risk and Impact 

There are three risks we need to consider.  The risk of not going forward is the same as the justification and should be documented in that field.  In risk and impact ensure that we document the known impact.   

  • How long will the service be down or degraded? 
  • How will the user experience be different after the change? 

Also consider the unanticipated risk — what if something goes wrong?  When touching a system, how would a typo impact you?  Risk mitigations such as ‘we are using configuration management to implement the change and can review it before deployment.’ should be documented.  

High-impact changes or changes to critical GCU services should be escalated to the _____for review.  This can be done via email or meeting.  It is the CAB managers responsibility to summarize CAB recommended changes and send email to ______. 

Backout Plan 

  • If something goes wrong, how do you recover.  In some cases, this is not possible, such as a switch reboot.  Most systems, however, have some means of recovery from changes.  This can be booting a firewall from an alternate partition or deploying the previous version of the software.  
  • Ask “If making changes on a VM, does the implementation plan include taking a snapshot first?” 

Test Plan 

Ensure the change includes both pre- and post-implementation testing.  Ask: 

  • Was this deployed successfully in dev and test? 
  • Do you have a standard test suite you run? 
  • Have downstream clients tested against this?  What were results?  

For post implementation testing ask: 

  • Who is your test group? 
  • Do you have a go-no go decision point? 
  • If it fails, will you backout or push forward?  

Communication and External Review 

Prior to presenting a ticket at the CAB the presenter should been properly vetted with all constituents.  The CAB is not the place to announce the change to the client or to seek peer review on the implementation.  All of that should have been completed in advance.  

Ask questions like: 

  • To whom will this impact?   
  • Have we communicated properly with all clients?   
  • Will ____ need to change procedures or be inundated with calls?   
  • Are stakeholders aware of the proposed change? 

Be sure the current and future communication plans are documented. 

Go to the Change Request Form