Overview
The objective of Change Enablement is to enable calculated and deliberate changes that have clear and transparent risk, impact, benefit and communication .
The Change Enablement practices will be incorporated into TeamDynamix on Monday, October 2, 2023. Use the Quick Reference guide below to assist in tracking and resolving Problems.
To see instructions on how to conduct Change Enablement in the TDX tool, including how to access the Change Enablement desktop, how to create and complete and RFC, and how to review and vote on an RFC, see "How to conduct Change Enablement in Team Dynamix (TDX)."
Details
Overview of the Change Enablement process
Terminology (Types of changes)
- Change: The addition, modification, or removal of anything that could have a direct or indirect effect on services.
- Standard Change: A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction.
- Normal Change: A change that follows the complete change management process. It is not a standard or emergency change.
- Emergency Change: A change that must be introduced as soon as possible to resolve a major incident or mitigate extreme risk.
- Latent Change Record: A record of a change that was made without appropriate authorization.
Standards
- Log: All changes, regardless of origin, will be logged and updated in TeamDynamix.
- Document: Change documentation must be concise, readable, and thorough enough to facilitate approval processes.
- Review: Post implementation information must be accurate and timely.
Understanding RFC Work flow
Important Fields
Note: It’s the responsibility of every technician working on changes to review RFC data for accuracy and to correct it when necessary. It’s important that field data reflects reality and fields are not set to influence metrics.
Risk and Impact Analysis
- Standard Changes: Always Low Risk
- Normal Changes
- Impact of RFC
- Likelihood of impact
- Risk analysis: memo field with pre-defined prompts
- Actual risk is set by the SME/Technician responsible for the RFC
- Emergency changes: Always High Risk
- Latent changes: There is no risk documented.
Approval Authorities
Approval Authorities
| Change Type |
Approval Authorities |
Approval Parties |
| Standard RFCs |
Pre-approved |
N/A |
| Normal, Low Risk RFCs |
Manager |
All Purdue IT Managers |
| Normal, Medium Risk RFCs |
Local CAB |
Managers & Directors within an area |
| Normal, High Risk RFCs |
Enterprise CAB |
Purdue IT Directors |
| Emergency RFCs |
Emergency CAB |
Purdue IT Senior Staff |
Local CABs Design/Purpose
- Approve medium risk, normal changes
- More review / authority than a single manager can provide
- Less review / authority than a peer review, ROC Review, Enterprise CAB review and discussion.
- Possible review/approval scenarios
- A director reviews and approves within or outside a meeting.
- Multiple managers review and approve within or outside a meeting.
- One for each Director (small director areas can share a local CAB)
Work flow stages
Work flow stages
| Stage |
Purpose |
| 1. Draft RFC |
When an RFC is being created or modified. |
| 2. RFC Review |
When an RFC is being reviewed by an individual or group that is not an approval body |
| 3. RFC Authorization |
When an RFC is being considered by an approval body. |
| 4. Scheduled RFC |
When an RFC has been approved by an approval body and is waiting to be implemented. |
| 5. Processed RFC |
When an RFC has been fully processed regardless of the outcome. |
- Stages are reportable
- Stages are determined by the work flow and cannot be overridden.
Change Processes
Standard Change Process
- RFC is documented and marked as ready for review.
- Manager is notified of a new Standard RFC.
- Once work has been attempted (or a decision has been made not to attempt it), the responsible party updates the Change Outcome fields and marks the RFC as such.
- The RFC is set to “Closed” status.
Normal Change Process: Low Risk
- RFC is documented and marked as ready for review
- Manager is notified to review a new Low Risk RFC for completeness of documentation and acceptance of risk.
- When the documentation is deemed complete and the risk is deemed acceptable, manager approves the RFC.
- Once work has been attempted (or a decision has been made not to attempt it), the responsible party updates the Change Outcome fields and marks the RFC as such
- The RFC is set to “Closed” status
Normal Change Process: Medium Risk
- RFC is documented and marked as ready for review.
- Identified peer is notified to review a new Medium Risk RFC for completeness of documentation, plan and risk analysis.
- When the documentation, plan, and risk analysis is deemed complete, peer provides their approval.
- The identified Local CAB is notified to review a new Low Risk RFC for completeness and acceptance of risk.
- When the documentation is deemed complete and the risk is deemed acceptable, the local CAB approves the RFC.
- Once work has been attempted (or a decision has been made not to attempt it), the responsible party updates the Change Outcome fields and marks the RFC as such
- The RFC is set to “Closed” status
Normal Change Process: High Risk
- RFC is documented and marked as ready for review.
- Identified peer is notified to review a new High Risk RFC for completeness of documentation, plan and risk analysis.
- When the documentation, plan, and risk analysis is deemed complete, peer provides their approval.
- The ROC is notified to review a new High Risk RFC documentation, plan and risk analysis. They have 2 business days to provide feedback.
- The Enterprise CAB is notified to review a new High Risk RFC for completeness and acceptance of risk. They have 2 business days to provide feedback.
- After two business days, the RFC waits for final approval during the weekly meeting.
- Once work has been attempted (or a decision has been made not to attempt it), the responsible party updates the Change Outcome fields and marks the RFC as such.
- The RFC is set to “Closed” status
Latent Change Process
- RFC is documented and marked as ready for review
- Manager is notified to review a new Latent Change Record for completeness of documentation.
- When the documentation is deemed complete, manager approves the record.
- The RFC is set to “Closed” status
Emergency Change Process
- RFC is documented and marked as ready for review.
- The Emergency CAB is notified to review a new Emergency RFC.
- When the documentation is deemed complete and the risk is deemed acceptable by a senior staff member, they can approve the RFC.
- The emergency CAB and service desks are notified that an Emergency RFC was approved.
- Once work has been attempted (or a decision has been made not to attempt it), the responsible party updates the Change Outcome fields and marks the RFC as such.
- Notify Emergency CAB and service desks that the emergency RFC has been completed.
- The RFC is set to “Closed” status.
Scheduling RFCs
Change Calendar Contents
Blackout Windows
- Periods of Heightened awareness
- High visibility sporting events
- Significant academic events
- Significant business events
Maintenance activities
- All RFCs (including latent change records) should have maintenance activities defined appropriately.
Change Window vs Maintenance Tasks
-
All RFC have a Change Window Start and a Change Window End that is intended to specify a window of time in which all maintenance activity tasks will be performed. This window can stretch over days to accommodate RFCs that require work to be completed over time. Change windows do not appear on the change calendar.
-
All RFCs have a Downtime to specify the number of time in minutes in which services will be impacted during each maintenance activity.
-
A maintenance activity task represents a specific window of work that begins and ends at a specific date and time. RFCs may have more than one maintenance activity task. Maintenance activities appear on the change calendar.
Blackout Window vs Maintenance Windows
-
Blackout Windows are periods of time in which RFCs are not approved or are put under further scrutiny to reduce negative impacts during business-critical times. Blackout Windows appear on the change calendar.
-
Maintenance Windows are periods of time in which specific assets may undergo their normal maintenance. When assets are associated with an RFC, conflicts between work and maintenance windows can be detected.