Old info below:
General Information
This form must be completed by the requestor before submitting the change request. All the fields are mandatory. The list of fields for this section includes:
- Request Title: Brief Description of the change requested.
- Request Classification: Business as Usual (BAU) and non – Business as Usual (non-BAU) are classifications that determine the path of approval for all changes that are requested. The Change Advisory Board (CAB) or Emergency Committee (EC) must approve the non-BAU changes. The BAU changes can be approved by the requestor’s manager.
|
Classification |
Explanation |
|
BAU |
Abbreviation for “Business as Usual.” Changes that are frequent and have very minor impact to the business. Operationally, these changes are generally associated with monthly patches, changes to non-customer facing systems or services, OS upgrades on development, test, staging and some production equipment. Routine firewall policy pushes may also fall into this category. The manager’s approval is only needed for all BAU selected changes. |
|
Non-BAU |
Abbreviation for non-“Business as Usual.” These types of changes do not occur frequently and have significant to major impact to the business. These changes will generally require an outage, if no redundancy exist, and will result in loss of service or functionality during the scheduled maintenance window. Redundant systems or services are not exempt from approvals. If the change is not done on a routine basis, then Non-BAU should be selected. The CAB / or EC must approve these changes. |
- Request Priority: Reflects the urgency of the business need and the risk of not implementing the change. It determines how quickly the change should be evaluated and implemented. The following priority definitions were derived from the ITIL Service Management framework.
|
Priority |
Explanation |
|
Immediate |
Requests that, if not addressed immediately, will create a large risk to the University, impacted business group(s) or functional area(s). Immediate action is required. The CAB/EC must be convened and resources may need to be allocated immediately if the request is authorized.
|
|
High |
A request that is important for the University, impacted business group(s) or functional area(s) and must be implemented soon but not immediately.
|
|
Medium |
A request that should be implemented to gain benefits but that is not time pressing.
|
|
Low |
A request that is nice to have.
|
- Requested By: Requestor’s name and title.
- Contact Information: Requestor’s contact information (phone and e-mail).
- Application / System to Change: The system or process to be changed.
- Description of Change: Detailed description of the change request.
- Target Implementation Date: Date when the change is desired to be finished.
- Reason for Change: Define as precisely as possible, the justification for the change. Indicate why the change is needed, including critical dependencies such as a new statutory requirement.
- Impact if Change is Not Implemented: Describe any risks or inefficiencies that the University will be incurring if the change is not implemented (e.g. missed deadlines, legal penalties, delays, anticipated failures).
Assessment and Implementation
This section is particularly important for the approving manager and/or Change Advisory Board (CAB) members in order to understand the potential risk associated with the change request. It is critical to the approval process and must be completed.
It is advisable that the requestor and the approving manager collaborate on the thoroughness of this section.
The request impact category dictates which fields must be filled for this section:
|
Impact Category |
List of Mandatory Fields
|
|
Major |
|
|
Significant |
|
|
Minor |
|
The list of fields includes:
- RFC ID: Unique identification of the request (ideally should be automatically assigned by Numara Footprints. If Numara is not available, then this field will be assigned by the change manager upon verification of completeness of the request. Once the RFC ID is assigned, the change manager must inform the requestor of the ID.
- Request Impact Category: Reflects the impact of the change requested in the organization.
|
Impact Category |
Explanation
|
|
Major |
A change that impacts a massive group of users or a business critical system (e.g. change to Phone system, Email or Blackboard). The change involves downtime of a system or service.
|
|
Significant |
A change that affects a high percentage of users (e.g. a change affecting a group within a department or a specific group of users). The change may involve downtime of a system or service.
|
|
Minor |
A change that impacts a non-critical system and a small number of users (e.g. change to an application used by a small team).
|
- Business Units and Processes Affected by the Change: Describe the business units, business processes, and process owners affected by the change.
- Impact on Current Applications and Infrastructure or Roles: Describe the potential impact on existing applications and infrastructure. Potential changes to user roles should also be described if applicable.
- Required Resources to Implement the Change: Describe any dependencies for the operational implementation of this change or business solution (e.g. people, skills, roles, tools, systems, processes, organization, and technology).
- Communications Plan: Explain who is communicating the change to the user community and how. If IS Alerts is to be used, who will initiate and close the communications when the change has been successfully completed. The verbiage of what is to be communicated can be included here. Will there be internal communications to Operations, other Managers or technical resources outside of the IS Alerts process?
- Implementation Plan: This should invariably require that an attachment of a checklist, project plan or a link to the implementation plan depending on the change be included here. Otherwise, describe the steps that will be used to complete the change.
- Testing: Explain the testing method, environment and status of any ongoing testing for this change.
- Risk Assessment: Describe the risks that could affect the implementation of the change, indicating its probability of occurrence, the impact, and the action to be taking if facing the risk. Does the change jeopardize security, backups or require the modification of the business continuity and contingency plans? If so, describe here specific changes that need to be reflected on documentation and testing procedures to maintain security, ensure the integrity of backups and keep the continuity and contingency plans accurate.
- Rollback / Back-out Plan: An exit strategy must exist to reduce risk to the production environment in case the change doesn’t work. Describe your trigger for rolling back your changes. Provide the link to the location of your plan or attach your checklist/back-out plan.
- Other Comments / Special Considerations: This section offers some flexibility in adding any comments. It can be used by the requestor and approving manager to track the progression of the changes when done in stages.
Status and Approvals
This section is mandatory and must be completed. If the request impact category is minor, the requestor’s manager can authorize the change himself/herself.
Otherwise, this section will be completed after the CAB (or CAB/EC) has met to analyze the request and determine a course of action. The possibility of a virtual CAB meeting exist when the RFC is submitted in Numara Footprints with the approval process built in to notify CAB members to act on each Change Request outside of the scheduled review meeting date.
The list of fields includes:
- Request Status: The status of the request (i.e. logged, assessed, rejected, accepted, on hold). This field is mandatory.
- Reason for Status: Document here the reasons that led the CAB to decide the course of action for the change. For example, if the change is rejected, list here the reasons for the rejection. This field is mandatory.
- Approvals: Include authorization signatures of the person responsible for the business unit, product or processes affected by the change; and operation teams within IS. Include date of the approval. This field is mandatory. Numara Footprints will be used to auto-populate the appropriate CAB members based on the functional area of the requestor. The intelligence capability is still being explored and will not be described in this document. When Numara is not available, signatures will be required on the forms for each request.
---------------------------
The following data is incompatible with the receiving workspace:
Field: Change Type (Workspace field not present)
Original Data: BAU