Information and Communications Technology
CHANGE ADVISORY BOARD
MODEL
MAY 2014
DRAFT
ICT Change Advisory Board Model
1. CAB DEFINITION
AND
RESPONSIBILITIES
The overall flow of change requests is described in the following diagram: Figure 1 – Change Request Process Flow Diagram
A change to a service is required.
This request can come from a
client, vendor, or from within
Systems.
Start
SystemsCABMethodology
ChangeRequestProcessFlowDiagram
Change to
production
system?
No
This change is not
required to follow
CAB processes
No
Test this change in
development/pre‐
production prior to
proceeding
No
Work with clients to
perform UAT and
select a date for the
change
Yes
Has testing
been
completed?
Change is not approved
Prepare the Change Request using the CAB
Change Request template.
Yes
Have affected
clients been
consulted?
Change
coordinator/
implementer
Change Request
CAB
Recording
secretary
Change is approved
Yes
Complete the change using the plan
documented in the Change Request. Track
progress in the ticket identified as the Change
Log in the Change Request.
Did you
experience
issues?
No
Complete
Yes
Outstanding issues remain
Document the issues in the CAB Issues Doc
template; be sure to include the lessons that
you learned as a result of the issue(s).
Issues Doc
CAB
Recording
secretary
Document is reviewed, no additional issues identified
Document/revise procedures required to
avoid this issue in the future.
Complete
1.1. Purpose In order to minimize risk and impact to the university, the Change Advisory Board (CAB) will review all changes and outages to production services provided by ICT. CAB will ensure that all changes are recorded, evaluated, planned, tested, approved, implemented, and communicated to our clients in an appropriate manner. 1.2. Responsibilities 

Meet weekly to: o Review previously approved submissions for status, issues, and completion. o Review new requests for change to production systems, services, or facilities. Each request will be evaluated in the meeting and approved, deferred, cancelled, rejected, or escalated. o Review outage reports. o Review issues that arise from changes that were not previously brought to the CAB. Manage tools, technology, and templates required for the CAB ‐‐ 1 ‐‐
ICT Change Advisory Board Model
 Provide CAB methodology and guidance to successfully complete changes 1.3. Change Definitions For the purposes of the CAB, a change is an alteration to a production system, service, or facility operated by ICT – whether completed by ICT staff, other university staff, vendors, or their agents. The definition of a production system encompasses all systems, including development systems, where the services provided are required by the university community – including students, faculty, staff, departments, and alumni – to perform their roles. Changes can be originated as a result of a client request, a feature request, a request from within ICT, a notice from a vendor, a security concern, or a bug fix. Some examples of changes include, but are not limited to, a new version of operating system software on a support tool that introduces new features to clients, introducing a new wireless service that will publish a new SSID to users, releasing a new version of application software to resolve bugs, or upgrading a database server to new physical hardware. Standard Change  Change is completed exactly one time  Specific change window; well defined start and end times  Change does not begin until receiving approval from the CAB  Follow the Systems CAB Change Process (see section 2)  Initiated by the Change Planning Process (see section 2.1) Emergency Change  Change is completed exactly one time  Urgent requirement to complete the change immediately  The CAB must be informed prior to the change via an email  Change is completed, but presented at the next CAB meeting  Follow the CAB Change Process (see section 2)  Initiated by the Change Planning Process (see section 2.1); depending on the level of emergency, some of this work may need to be completed after making the change Approved Process  Change is completed multiple times  Varying change windows dependant on the process defined in the Change Request  First change does not take place until the process is approved by the CAB; subsequent changes take place as defined by the Change Request  Follow the CAB Change Process (see section 2)  Initiated by the Change Planning Process (see section 2.1)  Use of the approved process must be documented in an Information Notice to the CAB and will be included in the CAB Calendar for record keeping purposes 1.4. Impact Definitions ‐‐ 2 ‐‐
ICT Change Advisory Board Model
A service impact is defined as a negative impact to the availability or usability of a production system, service, or facility operated by ICT that noticeably degrades the level of service provided to the university community. The definition of a production system encompasses all systems, including development systems, where the services provided are required by the university community – including students, faculty, staff, departments, and alumni – to perform their roles. Some examples of service impacts include, but are not limited to, a group policy update that causes a required piece of software to malfunction in one department, a reduction in commodity Internet speed that affects Internet performance for users, or an issue with email routing that causes a significant delay in email delivery from off‐campus users. Standard Impact  All unplanned impacts to production service(s)  Follow the CAB Impact Process (see section 3) The impact report process flow is illustrated below. Figure 2 – Impact Report Process Flow Diagram
1.5. Information Definitions For the purposes of the CAB, information is defined as a notice that is relevant to the CAB audience, but not a change seeking approval, nor an impact to a service. This information is not necessarily discussed in the CAB meeting, but may be included in the CAB Request Log for informational purposes only. Some examples of information relevant to CAB include, but are not limited to, notice that an approved process is being applied and documenting the changes included in this iteration of the approved process or notice of upcoming power changes that may result in future Change Requests. Information Notice:  All notices relevant to the CAB audience that are not a change seeking approval, nor an impact to a service ‐‐ 3 ‐‐
ICT Change Advisory Board Model

Follow the CAB Information Notice Process (see section 4) 1.6. Change Implementer/Coordinator Definition The Change Implementer/Coordinator is the person responsible for ensuring the change is successfully completed as per the Change Request. Responsibilities broken down by phase: Pre‐change:  Complete a Change Request  Consult with clients impacted by the change to assess and minimized negative impact  Seek input from other units within ICT to assess and minimize consequences of the change  Open a trouble ticket to act as your Change Log and record this ticket in your CAB Request for auditing purposes  Present the change to the CAB During change:  Complete change as per process defined in Change Request  Update the Change Log defined in the Change Request with your progress as you implement the change  Communicate the change as per the Communications Plan defined in the Change Request  Document any issues encountered during the change in an Issues Document Post‐change:  Attend the next CAB meeting to speak to the status of your change  Present your Issues Document (if applicable)  Document/revise procedures required to avoid this issue(s) in the future (if applicable) 1.7. Unit Manager Responsibilities Each Unit Manager is responsible for:  Ensuring that changes to production systems managed by his/her unit follow the necessary CAB process (see sections 2,3)  Member of the CAB and should attend (or send a designate) to each CAB meeting  Report changes to members of his/her unit 1.8. CAB Chairperson Responsibilities The CAB Chairperson is responsible for:  Coordinating weekly CAB meetings  Maintaining the CAB Methodology, including documents, templates, and supporting tools  Escalating issues to the CIO as necessary (see section 5) ‐‐ 4 ‐‐
ICT Change Advisory Board Model
1.9. CAB Attendee Responsibilities Every attendee of a CAB meeting is responsible for:  Reviewing Change Requests, Issues Documents, and Outage Reports during the CAB meeting (see section 5)  Identifying any potential issues with a change that would result in an unexpected outcome, an unexpected impact to a client group, or a detrimental consequence to a dependant system/service ‐‐ 5 ‐‐
ICT Change Advisory Board Model
2. CAB CHANGE PROCESS
The following diagram outlines the overall process required for each change. This process begins after the need for a change has been identified. Each activity is described in further detail in subsequent sections. Figure 3 ‐ CAB Change Process Diagram
2.1. Change Planning Process The Change Planning Process is designed to gather all of the necessary detail required to create a complete Change Request: Test the Change Prior to starting a Change Request, adequate testing of this change is required. Each service offered by ICT is different and the ability to test changes to each of these services varies; however, the following should be considered for every change:  Has this change been implemented in development?  Has this change been implemented in pre‐production?  Has the client or user of the service been consulted to perform user acceptance testing of the change in development or pre‐production?  Has the process used to implement this change in development or pre‐production been documented in a way that can be used to implement this change in production?  Has the back‐out process been tested in development or pre‐production? Consult With Other Units in ICT ‐‐ 6 ‐‐
ICT Change Advisory Board Model
If you believe that this change will have implications for services offered or impacts other unit(s) in ICT, this unit(s) should be consulted so this impact is fully understood before embarking on this change. Some considerations include:  Does this change have an impact on information security?  Will this change impact the availability of a service offered by another unit?  Does another service depend on the service impacted by this change?  In the event that there are issues with this change, will support staff be available to help clients that have been impacted? Consult Impacted Clients Every change to a production system will affect the clients or users of this system. These client groups should be consulted prior to any change to ensure that we fully understand the client impact. Some considerations include:  What is the best date and time to make this change to minimize negative impact?  In the event that there are issues with this change, how will this impact the client?  If the client base is extremely large (e.g. the entire university community) or cannot be directly contacted (e.g. all students), incorporate these considerations when you are speaking with other units in ICT. The Help Desk can provide insight on the client impact of a large change, and functional departments can help to choose a time when a required outage to services will have minimal impact to clients. Change Request After gathering necessary information during the activities above, a Change Request can be authored. This document will be used to speak to the change in the CAB meeting and will act as the plan for completing the change. Submission Procedure: 1. You must complete the CAB Change Request template. Additional information on how to complete this template can be found in the template. 2. Title the resulting Microsoft Word document with your unit, followed by a brief description of the change (e.g. ICT_Banner_Upgrade_v9_Request.doc). 3. Upload the document to the new requests folder in the CAB document library prior to 13:00 the day prior to the CAB meeting. 4. The CAB’s Recording Secretary will assign a CAB Request Number and add this document to the CAB Request Log list in the CAB document library for discussion at the next CAB meeting. ‐‐ 7 ‐‐
ICT Change Advisory Board Model
Presenting the Change Request in CAB The change implementer is responsible for ensuring someone who is familiar with the change is able to speak to the change in the CAB meeting. Ideally, the change implementer will perform this role. The following are possible outcomes: Approved:
 No outstanding concerns regarding this change  Change Request is approved, proceed to Change Implementation Process (section 2.2) Approved process:
 Only applicable to Change Requests of the type “Approved Process”
 Change Request is approved, proceed to Change Implementation Process (section 2.2) as per the schedule of changes defined in the Change Request
Cancelled:
 Change is no longer required  Do not proceed with this change Deferred:
 Change cannot be discussed at the CAB meeting due to insufficient information or the absence of the CAB contact with this information OR  Change needs to be scheduled; schedule changes must be discussed at a CAB meeting prior to implementing the change Rejected:
 Change contains outstanding concerns  Update the Change Request taking concerns from the CAB into consideration  Resubmit to CAB for discussion at the following CAB meeting  Do not proceed with this change Escalated:
 Change contains outstanding concerns that cannot be resolved by the CAB or has a large impact on the university community  Escalated by the CAB Chair to the Director Platform Services for discussion at the ICT Leadership meeting  Do not proceed with this change Further details on the CAB meeting can be found in section 4. ‐‐ 8 ‐‐
ICT Change Advisory Board Model
Special Considerations for Emergency Changes Some changes must be completed immediately and cannot wait for the next CAB meeting to occur. Emergency changes are only to be completed if there is an urgent need, such an actively exploited security vulnerability or hardware failure. In this case, as much of the Change Planning Process should be completed as possible and a Change Request must be completed. This Change Request should be submitted as per the above process, and must be emailed to the CAB distribution list before the change is made. It is the change implementer’s responsibility to make every possible effort to contact clients impacted by this change or other units in Systems who may depend on the affected services to minimize unintended negative consequences or client impact. 2.2. Change Implementation Process The Change Implementation Process makes the change according to the approved Change Request from the Change Planning Process. Implement the Change Complete the change by following the change plan documented in the Change Request. Be sure to document your progress towards implementing the change in your change log, and follow your communications plan to communicate this change to the necessary stakeholders. If you encounter problems while implementing the change that cannot be resolved within the change window, the back‐out plan should be implemented as documented in the Change Request. Note any issues that were experienced, as these will be documented in an Issues Document. Documentation The following documentation should be considered while completing all changes:  Change log, as defined in the Change Request  Enterprise Architecture, as identified in the Change Request (note, the EA will be developed later)  Configuration Management Database (CMDB): record changes to installed software, patch levels, hardware information, network configuration, or other data that may require updates as a result of the change (note, the full CMDB will be developed later)  Standard operating procedures: does this change require a modification to any standard operating procedures, such as backup policies, failover procedures, or processes for future changes  Monitoring or logging systems or processes  Complete Information Notices as required for Approved Processes ‐‐ 9 ‐‐
ICT Change Advisory Board Model
Issues Document If issues were encountered during the change, an Issues Document is required. If you require assistance assessing the Client Impact of this issue, please consult the Manager of the Help Desk. This document will be used to discuss the issues at the next CAB meeting. Submission Procedure: 1. You must complete the CAB Issues Document template. Additional information on how to complete this template can be found in the template. 2. Title the resulting Microsoft Word document with your unit, followed by a brief description of the change (e.g. ICT_Banner_Upgrade_v9_issues.doc). 3. Upload the document to the New Requests folder in the CAB document library prior to 13:00 the day prior to the CAB meeting. 4. The Recording Secretary will link this document to the original CAB request in the CAB Request Log list on the CAB SharePoint site for discussion at the next CAB meeting. 2.3. Post‐change Process The Post‐change Process is the final step to completing a change. Present the Results of the Change to the CAB After the change has been completed, the implementer is responsible for ensuring someone who is very familiar with the results of the change is able to speak to the change at the CAB meeting. Ideally, the change implementer will speak to the results in the CAB meeting. The following are possible results: Complete:
 The change is complete as per the criteria outlined in the Change Request
 No issues were encountered or issues document is complete and has been reviewed
 No outstanding tasks to complete
Complete with Issues:
 The change is complete as per the criteria outlined in the Change Request
 Issues were encountered while completing the change
 Issues Document has been completed
 May have outstanding tasks defined in the Issues Document
 Temporary status, to be reviewed at each CAB meeting
 Change to complete when issues document is complete, reviewed, and there are no further tasks outstanding
Monitoring:
 The change has been complete, but additional monitoring is required to ensure that there are no issues
 Temporary status, to be reviewed at each CAB meeting
‐‐ 10 ‐‐
ICT Change Advisory Board Model

Change to complete or complete with issues depending on the results of the monitoring
Deferred:
 The change has not been completed
 The change is still required and will be rescheduled with the approval of the CAB
 Temporary status, to be reviewed at each CAB meeting
Cancelled:
 The change has not been completed
 The change is no longer required as defined by the Change Request
Further details on the CAB meeting can be found in section 4. Process Improvement Each change presents an opportunity to improve processes with the goal of preventing issues from recurring or optimizing future changes. It is the change implementer’s responsibility to identify and communicate possible opportunities for improvement within his/her unit. There are three primary areas to consider: Lessons learned:
 Each Issues Document will contain lessons learned
 These lessons must be communicated to the unit(s) involved for consideration when making future changes or to update standard operating procedures
 The same lessons learned should not appear repeatedly
Preventative steps:
 Each Issues Document will contain preventative steps
 These steps must be communicated to the unit(s) involved for consideration
 They may spawn a project to implement a new service or tool to prevent this type of issue from recurring
Standard operating procedures:
 Not dependent on an Issues Document
 Standard operating procedures used during a change should be reviewed to identify possible improvements such as accuracy of information (does the information need to be updated as a result of this change) and level of detail (would screenshots or additional steps help to clarify the process) ‐‐ 11 ‐‐
ICT Change Advisory Board Model
3. CAB SERVICE IMPACT PROCESS
The following diagram outlines the process to be followed to report a service impact to the CAB. This process is similar to that of creating an Issues Document and shares the goal of preventing this problem from occurring in the future. Each activity is detailed in the following sections. Start
Impact report
Impact process
Resolve the issue
Process improvement
Assess client impact
CAB
Complete
Figure 4 – Systems CAB Impact Process Diagram 3.1. Impact Process The Impact Process begins when an issue with a production system is reported. The process results in an Impact Report that can be presented to the CAB. Resolve the Issue After receiving a report of a problem, resolve the issue using the processes defined by your unit. Take note of the following, as this will be used to produce the Impact Report:  Impact start and end date & time  Trouble ticket number  The date & time the Informed message was posted and resolved  Timeline of events, starting with the report or discovery of the issue and ending when service was fully restored Issue Response Recommendations The following are recommendations from the Incident Response Protocol managed by Platform Services.  Appoint a Communications Officer during any service interruption or incident. The Communications Officer will be responsible for communicating the status of the issue, but will not be responsible for resolving the issue. This will allow the Systems Administrators to focus on resolving the issue while the Communications Officer fields questions from users or other staff in Systems. ‐‐ 12 ‐‐
ICT Change Advisory Board Model

Interruptions in service will be communicated to members of the university community. The initial message should be posted within five minutes of knowing about the service interruption; detailed information may not yet be available, but it is important to let users know that there is an issue and updates will follow.  The message should follow these guidelines: o Short meaningful subject line o Date and time of the service impact o Type of work (when scheduled) or the type of outage (when unplanned) o Brief reason for the work (when scheduled) o Common names of the services affected o Specific advice for the clients during the issue or how the client will be affected o Date and time the services will be returned to normal operation o Point of contact for any questions or concerns (in nearly all cases this will be the Help Desk) o Signature (as generic as possible to promote the use of the identified point of contact rather than the poster)  Update the message at least once an hour until a reasonably certain estimate of when the service will return to normal can be provided.  Update the message when the service has returned to normal. Assess Client Impact The clients affected by an outage are not as well defined as the clients impacted by a planned change. Assess the client impact by considering the services that were affected by an issue with a system. If this outage affected a large, wide‐ranging group of clients, consult with the Manager of the Help Desk for assistance in determining the client impact. Impact Report The individual who coordinated the resolution to the outage should author the Impact Report. This document will be used to discuss the outage at the next CAB meeting. Submission Procedure:
1. You must complete the CAB Impact Report template. Additional information on how to complete this template can be found in the template. 2. Title the resulting Microsoft Word document with your unit, followed by a brief description of the change. 3. Upload the document to the New Request folder in the CAB document library prior to 13:00 the day prior to the CAB meeting. 4. The Recording Secretary will assign a CAB Request Number and add this document to the CAB Request Log list in the CAB SharePoint site for discussion at the next CAB meeting. Presenting the Impact Report to CAB ‐‐ 13 ‐‐
ICT Change Advisory Board Model
After the Impact Report has been completed, the person who coordinated the resolution to the service impact is responsible for ensuring someone who is very familiar with the issue is able to speak to the issue at the CAB meeting. Ideally, the resolver will speak to the results in the CAB meeting. The following are possible outcomes: Incident:
 The issue is resolved and no longer poses an imminent risk to a service
 The Impact Report has been completed and reviewed by CAB
 There are no outstanding tasks to perform related to this service impact
Monitoring:
 The issue may be resolved, but there are outstanding tasks to perform related to this service impact  The Impact Report has been completed  Temporary status, to be reviewed at each CAB meeting  Change to incident when all outstanding tasks have been completed and the Impact Report has been reviewed by CAB Process Improvement The goal of process improvement in the Impact Process is to prevent this issue from occurring again in the future. It is the resolver’s responsibility to identify and communicate possible opportunities for improvement within his/her unit. There are two primary areas to consider: Lessons learned:
 Each Impact Report will contain lessons learned  These lessons must be communicated to the unit(s) involved for consideration when making future changes or to update standard operating procedures  The same lessons learned should not appear repeatedly Preventative steps:
 Each Impact Report will contain preventative steps  These steps must be communicated to the unit(s) involved for consideration  They may spawn a project to implement a new service or tool to prevent this type of issue from recurring ‐‐ 14 ‐‐
ICT Change Advisory Board Model
4. CAB INFORMATION NOTICE PROCESS
The following diagram outlines the process to be followed to provide an Information Notice to the CAB. This process was implemented as a mechanism of providing information to the CAB that is not a change seeking approval or an impact to a service. An Information Notice serves to document information that is relevant to CAB and is recorded in the CAB Request Log/CAB Calendar. Depending on the nature of these notices, they may or may not be discussed in the CAB meeting. Each activity is detailed in the following sections. Start
Document information relevant to the CAB
Information Notice
Information
coordinator
Recorded in CAB Request Log & CAB Calendar
Optional
Recording
secretary
CAB
Complete
Figure 5 ‐ Systems CAB Information Notice Process Diagram 4.1. Information Notice Process Document Information Relevant to the CAB The information coordinator is responsible for gathering the information required to prepare an information notice. If this notice is a result of an approved process, the notice should include the changes implemented in this iteration of the approved process. For example, a list of patches applied. Information Notice The information coordinator should author the Information Notice. This document will be used to record this information in the CAB Request Log & CAB Calendar and optionally discuss the information at the next CAB meeting. Submission Procedure:
1. You must complete the CAB Information Notice template. Additional information on how to complete this template can be found in the template. 2. Title the resulting Microsoft Word document with your unit, followed by a brief description of the information. 3. Upload the document to the New Request folder in the CAB document library prior to 13:00 the day prior to the CAB meeting. ‐‐ 15 ‐‐
ICT Change Advisory Board Model
4.
The Recording Secretary will assign a CAB Request Number and add this document to the CAB Request Log list in the CAB SharePoint site. Recorded in CAB Request Log & CAB Calendar The Recording Secretary will update the CAB Request Log & CAB Calendar with the Information Notice. This will result in a CAB Calendar that can be reviewed for all changes (including those completed under an approved process) over a given time period. ‐‐ 16 ‐‐
ICT Change Advisory Board Model
5. CAB MEETINGS
The Change Advisory Board meets weekly for one hour to:  Review previously approved submissions for status, issues, and completion  Review new requests for change to production systems, services, or facilities. Each request will be evaluated in the meeting (see section 5.1)  Review outage reports  Review issues that arise from changes that were not previously brought to the CAB These meetings will be scheduled using Exchange. Please contact the Recording Secretary to be included in the meeting invitations. If you are a member of the CAB as defined in the Terms of Reference, you are responsible for attending each CAB meeting. If you are unable to attend, please send a delegate. 5.1. Evaluation Process During each meeting, new or updated Change Requests, Issues Documents, and Outage Reports will be evaluated. The evaluation criteria for each type of document are contained in the following sections. Change Request Evaluation The following table outlines the criteria that will be used to evaluate Change Requests in each CAB meeting. Receiving a “No” does not necessarily mean that a change is rejected, but the CAB contact must be prepared to justify the reason that this requirement cannot be met. Yes
No
Is the CAB contact present to speak to this request?
Are all required fields complete?
Is the request type appropriate for this type of change?
Is the date & time of the change appropriate to minimize client impact?
Does the change justification prove that this change is required?
Is the change plan complete and can it be followed?
Has adequate testing been completed; have all necessary testers been involved? Is the communications plan detailed enough to ensure that impacted clients will receive notification? Does the change log reference a specific ticket number to track this change? Does the client impact reflect all clients that will be impacted by this change? Does the required resources field reflect everyone who is required to successfully complete the change? Will the back‐out plan return the impacted services to a pre‐change level of service? Has the impact on Enterprise Architecture been assessed?
Table 1 ‐ Change Request Evaluation Criteria
Issues Document Evaluation ‐‐ 17 ‐‐
ICT Change Advisory Board Model
The following table outlines the criteria that will be used to evaluate Issues Documents in each CAB meeting. Receiving a “No” does not necessarily mean that a change cannot be completed, but the CAB contact must be prepared to justify the reason that this requirement cannot be met. Is the CAB contact present to speak to this request?
Are all required fields complete?
Has the resolution completely resolved this issue(s)?
Was the back‐out plan implemented? If no, why not?
Does the client impact reflect all clients that were affected by this issues(s)? Has the cause of the issue been identified?
Is this a known issue that has recurred numerous times?
Has this issue been documented in a location that can be accessed by all Systems staff that may require this documentation in the future? Have lessons learned to help prevent this issue been captured?
Have these lessons learned been submitted for the same type of issue in the past? Have preventative steps that could help prevent this issue been recorded?
Are there any next steps that prevent this Change Request from being completed? Table 2 ‐ Issues Document Evaluation Criteria
Yes
No
Impact Report Evaluation The following table outlines the criteria that will be used to evaluate Impact Reports in each CAB meeting. Receiving a “No” does not necessarily mean that the issue is not marked as an incident, but the CAB contact must be prepared to justify the reason that this requirement cannot be met. Is the CAB contact present to speak to this request?
Are all required fields complete?
Has the outage been resolved?
Has the trouble ticket number been recorded?
Was an Informed posted? Is the timeline detailed and accurate?
Was a resolution to the underlying problem found?
Does the client impact reflect all clients that were affected by this issue?
Have lessons learned to help prevent this issue been captured?
Have these lessons learned been submitted for the same type of issue in the past? Have preventative steps that could help prevent this issue been recorded?
Table 3 ‐ Outage Report Evaluation Criteria
5.2. Escalation ‐‐ 18 ‐‐
Yes
No
ICT Change Advisory Board Model
Issues that cannot be resolved by the CAB Chairperson may require escalation. The two types of escalation from CAB are detailed in the following section. Escalation to Unit Manager The CAB Chairperson may escalate the following types of issues to a Unit Manager for resolution:  Lack of attendance/representation from the unit at CAB Meetings  Recurring lessons learned appearing on the same types of issues  Lack of timely submission of CAB documents  Changes to production systems that are completed without following the CAB methodology Escalation to the Office of the CIO The CAB Chairperson will prepare a brief summary of CAB activities for the Director of Platform Services each week for discussion at the ICT Leadership meeting (if necessary). The following be included:  Any issues that have been escalated to a Unit Manager but have not been resolved  Change Requests with the status “Escalated”  Changes to the CAB Methodology including documents, templates, and tools ‐‐ 19 ‐‐
ICT Change Advisory Board Model
6. APPENDICES
The documents are included in subsequent pages:  Change Advisory Board Terms of Reference  CAB Change Request template  CAB Issues Document template  CAB Impact Report template  CAB Information Notice template ‐‐ 20 ‐‐
Change Advisory Board
Terms of Reference Responsive.
Innova ve.
Trusted.
Purpose Scope Membership Process In order to minimize risk and impact to the University of Saskatchewan, the Change Advisory Board (CAB) will review all changes and outages to production services provided by University Systems. CAB will ensure that all changes are recorded, evaluated, planned, tested, approved, implemented, and communicated to our clients in an appropriate manner. All changes to production systems, services, and facilities operated by ICT ‐
whether applied by ICT staff, other university staff, vendors, or their agents ‐ are subject to the CAB process. Outages to production systems, services, and facilities that impact the service provided to members of the University of Saskatchewan community are also subject to the CAB process. This definition of production encompasses all systems, including development systems, where the services provided are required by the university community ‐ including students, faculty, staff, departments, and alumni ‐ to perform their roles. CAB membership includes:
 Manager(s) and/or designate(s) from each unit within ICT  Any persons scheduled to speak to an open CAB request  Recording secretary  Individuals from units outside of ICT will be invited as required Members are expected to review change requests and outage reports prior to attending each meeting. If you originate a change request or outage report, you must attend throughout the lifecycle of your request. The Change Advisory Board meets weekly for one hour to:  Review previously approved submissions for status, issues, and completion.  Review new requests for change to production systems, services, or facilities. Each request will be evaluated in the meeting and approved, deferred, cancelled, rejected, or escalated.  Review outage reports.  Review issues that arise from changes that were not previously brought to the CAB. A change request shall be initiated by completing the CAB Change Request document as per the included instructions and submit the request to the recording secretary. If issues are encountered while performing a change that has been approved by Auditing CAB, the change implementer shall complete the CAB Issues document as per the included instructions and submit the document to the recording secretary. If an unexpected outage to a production service is encountered, the manager responsible for the service or a designate shall complete the CAB Outage Report document as per the included instructions and submit the request to the recording secretary. The recording secretary must receive all submissions to the Change Advisory Board by noon on the business day prior to the meeting. The recording secretary will maintain a log of submitted requests/issues/outage reports and their status. If your submission is missing any required fields, the recording secretary will inform you that your document has not been accepted. Failure to submit these documents in a timely manner will result in escalation to the unit manager for resolution. If no resolution is found, the issue will be escalated to the Director of Platform Services for discussion at the ICT Leadership team. Each change is subject to the following auditing requirements:  The change is recorded in the CAB Change Log and assigned a CAB Reference Number.  The Change Log field of the Change Request contains a reference to the ticket that documents the progress towards implementing the change. This ticket must exist in the official ticketing system in use by the department responsible for implementing the change. This ticket must reference the CAB Reference Number.  In the case of an approved process, each change performed as part of the process must reference the CAB Reference Number of the approved process. The unit responsible for implementing each of these changes must be able to produce a list of the individual changes related to an approved process upon request. It is the responsibility of the change implementer to ensure that these auditing requirements are met. CAB Change Request
Request Number (####) Responsive.
Innova ve.
Trusted.
Date submitted Request type Requestor Implementer Unit CAB contact Proposed date & time of change (24 hour clock) Short description Long description Justification Change plan Testing completed Communications plan Change log Change frequency Expected client impact Potential client impact Risk assessment Resources required Back‐out plan Time to back‐out Current date
Standard, Emergency, or Approved Process
Who is requesting this change
Who will implement or coordinate this request
Which department is implementing this change
Who will speak to this request in CAB (should normally be the implementer)
Start date and time
End date and time Short description of the change for quick reference within the CAB More meaningful description of the change that could be understood outside of CAB including systems affected Describe the justification for the change, or a reference to the justification
Detail the steps that will be taken to make this change
What has been done to test this change
Who will this change be communicated to and how
Specific reference to where this change will be recorded within the unit making the change (should be a specific ticket number) How often will this change be made
Describe the impact that expected to be experienced during this change
What is the worst case client impact this change have on the campus if this change goes wrong (low/medium/high) What is the risk of thus change going wrong (low/medium/high) Who is required to make this change
How to reverse this change and return affected systems to a pre‐change state
How long will it take to complete the back out plan
Identify any impact to ICT’s enterprise architecture (to be developed) Architecture impact Project code for the project associated with this change (if applicable) Project code Other information relevant to this change
Notes * All fields are required, except for notes and project code. CAB Issues Document
Request Number (####) Responsive.
Innova ve.
Trusted.
Date submitted Author CAB contact Current date
Issue description Resolution Back‐out plan Client impact Describe the issue experienced as a result of the change
Who prepared the issues document
Who will speak to this request in CAB (should normally be the implementer)
What was done to resolve the issue noted above?
What was the back‐out plan from the Change Request implemented? What was the impact of this outage? Please provide an estimate of the groups that were affected. For example, all students, faculty, and staff were unable to send email during this outage. What the root cause of the issue?
Issue cause Was this a known issue?
Known issue Where is the issue and associated resolution documented? Documentation What lessons have been learned from this issue?
Lessons learned How can we prevent this issue in the future? What tools or services would Preventative steps have prevented this issue from occurring? What is yet to be done to resolve this issue(s)? Note any follow up Change Next steps Requests as a result of this issue. Other information relevant to this issue?
Notes * All fields are required, except for notes. CAB Impact Report
Request Number (####) Responsive.
Innova ve.
Trusted.
Date submitted System affected Solved by Unit CAB contact Trouble ticket # Outage date & time (24 hour clock) Problem description Information posted Information closed Timeline Resolution steps Client impact Lessons learned Preventative steps Notes Current date
What system experienced the impact?
Who performed the steps taken to rectify the issue?
Which unit was responsible for solving the issue?
Who will speak to this request in CAB? (should normally be the person who resolved the problem) Trouble ticket number
Start date and time
End date and time Description of the problem that caused this outage
Date at hh:mm
Date at hh:mm
Detail the timeline of events related to this outage including when and how the outage was reported and the steps taken to resolve the issue. What was the final resolution to this outage?
What was the impact of this issue? Please provide an estimate of the groups that were affected. For example, all students, faculty, and staff were unable to send email during this outage. What lessons were learned during this outage? How can we prevent this outage from occurring again?
Other information relevant to this change
* All fields are required, except for notes. CAB Information Notice
Request Number (####) Responsive.
Innova ve.
Trusted.
Date submitted Implementer Unit CAB contact Proposed date & time of change (24 hour clock) Current date
Who will implement or coordinate this request
Which department is implementing this change
Who will speak to this request in CAB (should normally be the implementer)
Start date and time
End date and time Description of this notice e.g. a list patches being applied as an approved Description process. Linkage Original CAB request or other document that is linked to this information.
Why is this an Information Notice as opposed to a Change Request (e.g. Justification Approved process notification? Other information relevant to this notice
Notes * All fields are required, except for notes.