Change Advisory Board Change Request Form

Dissecting the requirements for a change request, define the success criteria up front, and define the “what” and “why” behind the change request, will provide GCU IT with the reasons for and benefits of the change – leading to changes succeeding.

 

Change Advisory Board Request
Name
Name
First
Last
Select the type of change request:
1. Emergency Changes: These require an immediate change implementation, usually to address some sort of incident in the environment with a high risk associated. 2. Small Changes: These changes are pre-authorized in an environment via a standard change catalog, do not require a CAB meeting and are classified as low risk. 3. Normal Changes: These require different levels of approval, are more complicated strategically, and are based on the change management processes in place and the risk associated with the change request.
What is the title of the change request?
A 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.
Check for conflict. This should always be done. 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 running multiple changes at the same time.
What date does the change have to be completed by?
Rate the impact of this request. On a 1-5 scale, 1 being low impact, 5 being high impact.
Describe the risk of not following the requested change. The risk of not going forward is the same as the justification and should be documented in this field. How long will the service be down or degraded? How will the user experience be different after the change?
If something goes wrong, how do you recover? In some cases this is not possible. Most systems, however, have some means of recover from changes. Answer "If making changes on a VM, does the implementation plan include taking a snapshot first?"
The implementation plan should be complete enough such that anybody familiar with the system can implement it based on the steps described. One goal of change management is to document the change for future review. Is the implementation plan sufficient such 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.
Ensure the change includes both pre- and post-implementation testing. PRE Answer: 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? POST. Answer: Who is your test group? Do you have a go-no go decision point? If it fails, will you backout or push forward?
Whom will this impact? Have we communicated properly with all clients? Will GCU Campus Technology need to change procedures or be inundated with calls? Are they aware? Have the current and future communication plans been documented?

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.