Change Enablement: How to Complete a Change Form

Overview

Audience: Technicians on TeamDynamix

This article is to provide detailed directions for filling out each form field on the change form on TeamDynamix. The change form is used to submit a change request (commonly known as request for change RFC) for review and approval. Some of the form fields have things to include to facilitate with reviewing and approving change requests from Change Advisory Board (CAB).

Change Form Fields Explained

Change Type

These are the different change types available. Each has a default Impact/Urgency/Priority and workflow for approval.

• Standard/Preapproved Change - No or low-risk changes that are carried out regularly and do not require approval. Already preapproved with CAB.
• Normal Change - Low to high-risk changes that follow a request and approval process to ensure due diligence is applied as appropriate for the change. Will go through CAB review.
• Emergency Change - Changes that require quick implementation, typically to address significant outage or other urgent matters. Requires Approval from requestor's manager.

Automation Workflow Considerations

• Standard/Preapproved goes to Change Manager for review and scheduling
• Normal goes to Change Manager for review for completeness first, then when ready sent to Change Advisory Board (CAB) for review and approval
• Emergency goes to Technician's manager for review and approval, then to the Change Manager for scheduling

Title

To enhance search-ability of your tickets, this is the recommended naming convention for your change request: [System/Service]: [Action] – [Specific Detail/Impact].

Examples:

• LinkedIn Learning - Create groups - Improve analytics
  • System/Service: LinkedIn Learning
  • Action: Create groups
    • Other options are update, fix, install, rollback, 
  • Specific Detail/Impact: Improve analytics
• Active Directory: Update Group Membership – Finance Users
• VPN:  Investigate Connection Failures – Remote Staff
• Email: Migrate Shared Mailbox – Admissions Office
• Network:  Firewall Rule Update – Allow Vendor Access

Asset/CI

Assets, CIs, Applications, Services, etc. can be selected from the CMDB and added to this field.  If the item associated with the change is not currently contained in the CMDB, Technicians will have the ability to add these items into the CMDB.  Currently, it is not a required field, but as we proceed with the population of the CMDB, there will come a point where we will require this field.

Location

Building locations are currently in the CMDB, but we are not currently requiring this field.

Requestor

The person who has asked for the change. They will only get a notification at the beginning of the ticket submission if the checkbox Notify Requestor is checked. 

Checkbox: Notify Requestor

If checked, the Requestor will get notified of a change form submission. Currently, that is the only notification sent to the Requestor.

Description

Required Field

Provides an overview of what the change is, why it is needed, and the context behind it. At a minimum, it should identify who originally requested the change and whether there is an associated ticket or issue that prompted it. This helps reviewers understand where the request originated and how it connects to ongoing work or incidents. More importantly, the description should explain the origin story of the change, what led to this request: who, what, why, when, where.

Proposed Start Time

To set a proposed Start Time, check the Change Calendar (change.uark.edu) and see if there are any approved changes that conflict with your change, and schedule around those.

It is best to schedule changes during minimal impacts.

If the change request is approved, the Change Manager will consider the time when scheduling deployment window.

CAB will want to know: Is the timing appropriate?

Proposed End Time

Set a proposed End Time that allows enough time for deployment and/or rollback if needed. 
NOTE: Both the Proposed Start Time and the Proposed End Time are used to identify scheduling conflicts, support approval decisions, and populate the Change Calendar once approved.

Impact

Currently, this is not a required field, but can be used to review change requests.

The impact is in terms of number of individuals by the change. What is the scale of the item by defining it in terms of how many people it affects.

• Isolated - Affects individual users, i.e., 1-3 users
• Minor - Affects a group, i.e., 4-10 users
• Major -  Affects a department or building occupants, i.e., 11-200 users
• Critical - Affect organization, i.e.,  more than 200 users

Urgency

Currently, this is not a required field, but can be used to review change requests. 

Urgency measures how quickly it needs to be resolved.  Urgency reflects the time available for repair or avoidance before the impact is felt by the university.

• Low - Work is not stopped nor impaired by affected users
• Medium - Work is impaired by affected users
• High - Work is stopped by affected users

Priority

Currently, this is not a required field, but can be used to review change requests.

Priority is the relative importance of the ticket to the organization compared to other tickets. This field is automatically calculated by TeamDynamix depending on the Impact and Urgency levels selected.

• Standard (Low)
• Escalated (Medium)
• High
• Emergency

Upstream and downstream systems impacted

Upstream and downstream impacts describe the dependency relationships of a system or service when a change is introduced. Upstream impacts are the required preceding considerations. These are the systems, services, or components that the changing system depends on to function, meaning any issue there can affect the success of the change. Downstream impacts are the resulting or following considerations. These are the systems, services, users, or processes that depend on the system being changed, meaning they may be affected by disruptions, failures, or modifications caused by the change. Identifying both is critical during change planning to fully understand dependencies, assess risk, and prevent unintended service disruption across the environment.

CAB will want to know: Upstream systems affected by the Change with the possibility of outage or interruption to their accessibility and downstream systems that may be affected by this change.

Customers impacted

What population of campus will be impacted or affected by this change?

Common campus groupings:

• Students
• Faculty
• Staff
• Users of specific impacted software or service

Impact assessment

What users, systems, services, or infrastructure will be affected or impacted by this change across the environment?

Testing results

If testing was conducted on non-production or test systems, what were the outcomes? From the vendor's perspective, what have been the experiences of other customers? Additionally, regarding previous changes at UARK, what were the documented results?

Implementation plan

Detailed list of actions to take, step-by-step, of the implementation plan. This can be reviewed by a peer to assess if the implementation plan is complete. If none is provided, it will most likely be sent back for revision.

CAB will want to know: what is your complete process in order to assess and review change request.

Necessity

Why is the change being implemented? What would happen if it is not done?

Rollback plan

If there is a failure at any point during implementation, how do we roll back to original state, eg. backups, snap shots of system / state before change.

Communication plan

Who and when do we need to communicate to? Goal is to provide stakeholders enough time to voice concerns before change implementation and no surprises. Provide transparency and collaborate with other departments and teams.

If you’re unsure about including a communication plan to your change request, the Change Manager will help determine what’s needed.

The IT Communications Specialist will attend every CAB meeting to ensure high risk or impact changes have a good communication plan. For lower risk and impact, the Technician will be responsible for communicating to their stakeholders.

Attachment / Attachment link

To maintain privacy, passwords or confidential information may be transmitted via a secure link to prevent direct vulnerabilities. Additional relevant details, such as vendor documentation, testing procedures, or links to the vendor's website, can also be provided as needed.

What's next

If you fully understand the requirements for completing a change form, you can go to the Change Calendar, verify that approved changes will not affect the time that you would like to propose your change, and the fill out the Change Request Form.  Planning, testing, and scheduling are a large part of this process. Insure that you are ready to defend and discuss your change prior to submission.

Need Help?

Need more information? Check the Related Articles or Related Services sections on this page (side or at the bottom) for additional resources that might help. 

• Submit a UARK IT Help ticket for access issues.
• Submit an IT training request for personalized support from the IT Training and Outreach.
• (For Help Desk Use) Responsible Group: Change Enablement group of the IT Change Manager

If this article needs to be updated, please leave feedback on this article and it will notify the owner of the article.