I work in a K–12 organization serving roughly 30,000 users. Our change process starts with a ticket that goes to the requester's supervisor. After approval, it is routed to every IT director, and only after all of them approve does it reach the CTO.
Most changes are approved with little discussion, so the process feels more like a notification than a request. However, the workflow cannot continue until every approver responds, which means I spend time chasing people who missed the email or are out of the office. We are expected to submit changes that could affect the district or its users, and I understand the need for accountability, but the current system feels unnecessarily slow and dependent on rubber-stamp approvals.
How does change management work in your organization, particularly in environments with thousands of users? Do you use a CAB, peer review, delegated approvals, separate notification lists, or an expedited process for routine and emergency changes?
4 Answers
A practical workflow is: submit the change, have someone on the technical team peer-review it, get review from the affected service owner, then obtain the required management approval. Everyone else receives the approved schedule and impact summary. Routine patching and other repeatable low-risk work should be covered by standard changes instead of requiring a new approval chain every time. Track success rates, rollback frequency, approval delays, and emergency changes so you can show where the process needs improvement.
A scheduled CAB or change review meeting usually works better than an email approval chain. Changes are submitted before a deadline, reviewed by representatives from the affected teams, and discussed in one place. Routine, low-risk changes can be pre-approved, while higher-risk changes receive a full review. You also need named backup approvers so vacation or missed email does not create a single point of failure. Keep a separate emergency-change procedure with a retrospective review afterward.
For an organization of this size, formal change management is normal and often required for compliance, audits, cyber insurance, and accountability. The issue is probably not the existence of the process but that everyone is being treated as an approver. Separate people who must approve the change from people who only need to be consulted or notified. A RACI-style model can help, with meaningful technical review up front and only the appropriate manager or executive approving the final risk.
That is the direction I am considering. I would rather have knowledgeable peers review the technical details first, then send the request to the director and CTO in parallel. Other department heads could simply be notified instead of blocking the workflow.
In larger environments, approval should be based on impact rather than organizational seniority. A change affecting one service might need the requester's manager and the service owner; a district-wide change may need broader leadership approval. Requiring every director to click approve creates a bottleneck and encourages rubber-stamping. Use defined risk categories, approval thresholds, automatic delegation, and a clear list of who is notified.
A weekly review meeting can also expose issues that an approval chain misses, such as a second team changing the same system, missing user communications, or a service that was retired months ago.
We use a similar approach twice a week. It gives everyone a chance to ask questions and catch missing communications or conflicts, although urgent changes sometimes have to wait for the next meeting unless they qualify as emergencies.