Enterprise IT change management · worked example
Turning a change calendar into a real control
Why a blanket 24-hour change lead time is ceremony rather than governance, and the risk-tiered change lane structure data teams should propose instead.
This is a worked example drawn from an observed change-management review and a published field note. It is not a client engagement. The organization, the director, and the teams involved are not identified.
Client context
The situation.
In a change-management review, a director announced that every change ticket must be submitted 24 hours before the meeting, with no exceptions and late tickets rejected, and described it as an organizational maturity step. The rule treated a column-comment update and a production schema change feeding executive dashboards as the same kind of risk, and left data changes under a generic IT change authority that could not evaluate them.
Symptoms and risks
- One process and one lead time for every change type
- A change board approving nearly everything it saw
- Lead time tied to meeting cadence rather than blast radius
- Data platform changes reviewed by people who could not assess them
Review approach
How the problem was examined.
The work focused on evidence and decision quality before prescribing implementation.
Asked what a flat lead time actually controls: rollback quality, blast radius, or approver competence
Compared the policy with ITIL 4 change enablement types and change authority
Weighed DORA's findings on external approval boards against the maturity claim
Tested whether data teams belong under generic IT change control or under change enablement
Engagement timeline
How the work unfolded.
Phases are listed in the order they happened. Durations appear only where they can be stated without exposing client detail.
- 01
Classify before scheduling
Type every change as standard, normal, or emergency before it is scheduled. A change nobody can classify is a change nobody understands well enough to approve.
- 02
Change lanes with named owners
Split review into infrastructure, application, and data platform lanes, each with one change authority who owns that domain's blast radius and approves its normal changes.
Accountability follows competence rather than org-chart altitude.
- 03
Lead times by risk tier
Give a high-risk change touching regulated data 48 hours and a real review; let a net-new integration landing in an isolated dev environment ship same-day with peer review.
- 04
Pre-approve the repeatable
Write and review the runbook for standard changes once, then let them flow with an automated audit trail.
Meeting time returned to the changes that need human judgment.
- 05
Demote the board to coordinator
Keep the cross-functional meeting for scheduling conflicts, cross-lane dependencies, and the rare change that needs several owners in one room. It advises and coordinates; it stops pretending to control changes it cannot evaluate.
Findings and recommendations
A sequenced path, not an unbounded backlog.
- Data changes belong under change enablement, not exempt from it and not under a generic IT change authority
- Measure governance by when the process last caught something, not by how orderly the meeting feels
- Put change authority with the owner closest to the risk
- Reserve the board for what genuinely crosses boundaries
Outcome
What changed.
The diagnosis in the room was right: the organization needed a maturity step. The prescription was a placebo. The change lane structure gives leadership a control that can say no, and gives data teams a review by people who can tell a Delta table from a dinner table.
Related service
Explore data architecture consulting
Review the service boundaries, typical deliverables, pricing context, and evidence before deciding whether to schedule.