Change Request

Description

Features

Request Process

Updating and Closing Change Tickets

Campus Tech Responsibilities

Description

Per the Change Enablement and Control Policy and Standard, Campus Technologies will document changes to Parkland College’s IT assets and resources. A change request must be submitted anytime something is altered, modified, updated, reconfigured, adjusted, or otherwise made to be different from the current state outside the normal, day-to-day intended operation of the system. Use this form to submit Normal, Standard (Preauthorized), and Emergency change requests. 

  • Normal (i.e., a new system or software implementation):
    • Most changes are considered 'Normal'
    • Reviewed and approved or denied by the Change Advisory Board (CAB) on a bi-weekly schedule
    • Must complete all preparatory tasks, testing, and stakeholder approvals prior to submitting your request for CAB review; incomplete submissions may be rejected
    • Normal changes with an urgency of 'High' or 'Critical' may be approved and implemented off-cycle, but will involve the CAB chair polling the CAB electronically and recording the decision (THIS IS DIFFERENT THAN AN EMERGENCY CHANGE)
  • Standard (Preauthorized) (i.e., server or desktop maintenance for which a procedure exists)
    • Considered low risk and routine
    • Must have an associated CAB-approved 'Standard Change Template' populated for it within the Change Request Form 
    • Follows the same process as a 'Normal' change except for the approval which is delegated by the CAB to the requestor's Campus Tech supervisor. 
    • Must be submitted via TDNext as opposed to TDClient because ticket templates are only available in TDNext
  • Emergency (i.e., server outage requiring immediate replacement or a patch for a major security vulnerability)
    • A change that is necessary to avoid major impact to business and/or resolve a severe incident (THIS IS DIFFERENT THAN AN URGENT NORMAL CHANGE THAT NEEDS OFF-CYCLE CAB APPROVAL)
    • Approval is required from the CIO or a Director via a response in the CTH All>ECAB channel in Teams
    • Requires review by the CAB after-the-fact
    • Typically includes lessons learned and action items to avoid recurrence 

Features

Every change must include the following for ticket submission (please see 'help' text within the Change Request Form for more details):

  1. Event Type (Normal, Standard (Preauthorized), or Emergency)
  2. Requestor
  3. Department 
  4. Title
  5. Description and Change Benefit must make sense to non-technical users
  6. Start and End Date/Time of change
  7. System Steward ensures the system functions as intended and meets the College’s needs
  8. Responsible for implementation and any adjustments (one main point person)
  9. Notification describes who should receive the IT Event notification email
  10. Communication Plan includes the target stakeholders who will be communicated with throughout the change process and the timing for delivering that information to them
  11. Testing Plan includes testing activities and the verification criteria
  12. Implementation Plan is an ordered list outlining the high-level steps needed to perform the change​​​
  13. Backout Plan is ordered list outlining the steps needed to reverse the change
  14. Risk Analysis describes what could go wrong and how that could affect people/systems/data/processes. What are the risks for NOT performing or delaying the change? 
  15. Impact is qualitative metric based on the 'Impact Description' below: Extensive/Widespread, Significant/Large, Moderate/Limited, or  Minor/Localized
  16. Impact Description describes the scope of who or what this change will affect and how and must make sense to non-technical users
  17. Urgency is qualitative metric based on the importance of the change and how quickly it needs attention: Critical, High, Medium, or Low 
  18. Priority is auto calculated based on your selections for 'Impact' and 'Urgency' and it denotes the relative importance of the change: P1-Critical, P2-High, P3-Medium, or P4-Low. Click on the image below to see the 'Priority Matrix' defined.

Uploaded Image (Thumbnail)

Emergency changes will also require the following. If the emergency change was due to something outside of Campus Tech's control such as a patch for a major security vulnerability, you may enter N/A in these required fields. 

19. Lessons Learned as a result of having to implement the emergency change

20. Action Items to Avoid Recurrence is a list of measures that will prevent this type of emergency change from being necessitated again in the future

All changes require the following to be updated within the ticket 'Update' window:

21. New Status MUST be updated throughout the change by the responsible technician

22. Deployment Success value MUST be selected prior to closing out the ticket

Request Process

 

To access the Change Request Form within TDNext, select IT Tickets>New>Change Request. 

 

Normal Changes:

  1. Within the Change Request Form, select Normal for the 'Event Type'. Once completed, select Submit.
    • Be sure to complete all preparatory tasks, testing, and stakeholder approvals prior to submitting your request for CAB review; incomplete submissions may be rejected.
    • Must be submitted in advance of the biweekly CAB meeting if deployment is to occur within the two week time-frame between meetings.* If you are unsure of the schedule or need to request an invite, please contact the CAB chair. The CAB meets every two weeks (Mondays), from 11:00 AM through 12:00 PM. Membership includes stakeholders from across the college who decide as a group to approve or deny the change request.
  2. You or your director should be prepared to talk about your request and answer any questions the committee has.
  3. Once approved, you will receive notification and may proceed with the change event on the scheduled date and time. 

*Normal changes with an urgency of 'High' or 'Critical' may be approved and implemented off-cycle, but will involve the CAB chair polling the CAB electronically and recording the decision. Please reach out to the CAB chair immediately after submitting your change request.

Standard (Preauthorized) Changes:

  1. Select the CAB-approved template from that dropdown field at the top of the Change Request Form. Once selected, the rest of the fields, including Event Type, will auto-populate. If there is not an associated CAB-approved template, you will instead need to select 'Normal' as the event type and follow that process above. You may also wish to submit a Standard Change Template Request.
  2. Do NOT edit the majority of the fields since those are details that were approved by the CAB. The following fields can be modified:​​​
  • Requestor
  • Start/End Dates/Times
  • Responsible
  1. Select Submit.
  2. Once approved by your supervisor, you will receive notification and may proceed with the change event on the scheduled date and time.

Emergency Changes:

  1. Inform the department immediately via a post in the CTH ALL>ECAB channel in Teams. True emergencies typically don't allow for enough time to fill out a change request prior to enacting the change. If that is the case, be sure to include at minimum a brief description, start/end time, impact, and notification details in your post. 
  2. Before you can proceed, a Director or the CIO must indicate their approval (this may be done with a simple thumbs up response).
  3. After the emergency is mitigated, select Emergency for the 'Event Type' within the Change Request Form. Emergency change requests require the inclusion of lessons learned and action items to avoid recurrence (these fields will populate at the bottom of the form). If the emergency change was due to something outside of Campus Tech's control such as a patch for a major security vulnerability, you may enter N/A in those two required fields. 
  4. Select Submit.

The CAB will review the emergency change details after the fact at their next regularly scheduled meeting. A task gets automatically created for the CAB to perform this review, even though the ticket will have already been closed by the responsible per the steps in the Updating and Closing section below. 

NOTE: If an emergency arises as a result of a 'Normal' change (that has been closed and initially appeared successful), do NOT open a new emergency change ticket. Instead, add a post to the ECAB channel, describe the adverse outcome, link to the original change ticket, and indicate you will begin the backout plan. There is no need to wait for approval since the backout plan was already approved by the CAB. Once the emergency is mitigated, open the original request, update the deployment success field to reflect something other than successful and in the Comments field, enter any lessons learned and steps to avoid recurrenence. 

 

Updating and Closing Change Tickets

  1. Within TDNext, open the change ticket and select Actions>Update.
  2. In the 'New Status' field, enter a value other than 'New'. This field should be updated at each stage of the change.
    • New is the default upon ticket creation as well as after Normal and Standard (Preauthorized) requests are approved.
    • In Process indicates that the change has begun.
    • Cancelled indicates that the requestor changed their mind -OR- the request was rejected by the approver. 
    • On Hold may be utilized in rare circumstances by CAB if questions arise during the approval process. The CAB can opt to place a request On Hold, as opposed to approving or rejecting it, until a minor preparatory action has been taken and is resolved. This may be a final testing component, approval from a stakeholder who has been difficult to reach, etc. The expectation is that the person responsible will complete that piece prior to the deployment date and time. Once that final piece is taken care of, the responsible MUST update the ticket with a comment indicating preparatory completion. Next, they MUST reach out to the CAB chair who will approve the request and remove the hold. If the CAB chair is not available, please contact in this order: Director of Technology Client Services or Associate Director of Technology Support Services or CIO. If the request is not taken off hold prior to the deployment date and time, the change should not take place and will be reviewed again at the next CAB meeting. 
    • Closed indicates that the change event has been completed, however, that does not necessarily mean that the deployment was successful or that it was deployed on the approved date and time. Before changing the status to closed, you MUST first complete steps 3 and 4 below.
  3. In the 'Deployment Success' field, select the appropriate choice. If something other than Successful is selected, you must include an explanation in the Comments field within the ticket update window. The CAB may review this at their next regularly scheduled meeting. 
    • Successful
    • Successful with some issues can be used even if the change was implemented successfully, but you needed to back out for any reason
    • Failed and backed out
  4. In the 'Was the Approved Deployment Date/Time Met?' field, please select Yes or No.
  5. Select Save.

If any issues arise during the change, the person responsible will follow the steps listed in the Backout Plan, if need be, and will update the parties listed in the Notification field.

 

Campus Tech Responsibilities

  • Campus Technologies will ensure that the person responsible for the change request will be the one responsible for the implementation.
  • Campus Technologies will document change tickets within the ticketing system.
  • The person responsible for the change will update the ticket status throughout the event and, upon completion, will enter a value for the 'Deployment Success' field prior to marking the status as Closed.