A change can be implemented without an immediate incident and still fail to deliver what it was meant to do. In a DEV Community post, Serguey Shinder reports that roughly half of 200 standard changes he reviewed had no evidence of achieving their intended outcomes beyond the service continuing to run. That is a useful warning about what change records measure—not an industry-wide failure rate or an independently audited finding.
What “successful” meant in the review
Shinder describes a prior success rate of 98.6 percent. In his account, a change counted as successful when the implementer recorded completion and no incident was raised during the following hour. That standard establishes that the work was marked done and no immediate problem was reported. It does not show that the requested result occurred.
As an Amazon Associate I earn from qualifying purchases.
The distinction matters: “the change ran without an immediate incident” and “the change delivered the intended result” are different claims. A system can remain operational while a change misses its objective.
How a completed change can miss its outcome
The post gives examples of changes that appear complete but may not affect the intended target:
- A firewall rule is applied to the wrong group and matches nothing.
- A backup policy is changed, although no systems use that policy.
- A monitoring template is updated for future hosts, leaving existing hosts unchanged.
- A patch is installed, but a service continues using an older, already-loaded library.
These are illustrative examples from Shinder’s post, not separately verified incident reports. Each shows why a completion note—or a service that remains online—is not proof of the desired result.
Why the process left verification out
Shinder attributes the gap to the design of the change process. The requester defines the desired outcome, the implementer carries out the work, and the requester is often best placed to judge whether the outcome occurred. Yet the form he describes recorded implementation notes without requiring a statement of what should be observably different afterward.
Without that expected result, closure can become a record of activity rather than evidence of effectiveness. The implementer may have followed the procedure correctly while the requester’s underlying need remains unmet.
Recommended Free Tools
How to verify a change before closing it
Shinder describes revising the change record so that verification is part of the workflow, not an optional follow-up.
- Define the observable result before approval. Have the requester state what should be measurably or visibly different after implementation. Describe the outcome, not just the action—for example, which systems should receive a policy or what monitoring behavior should appear.
- Require evidence before closure. Attach an appropriate record or observation that demonstrates whether the stated result occurred. A completion note alone documents work; it does not establish the outcome.
- Track unconfirmed changes separately. If implementation is complete but verification is pending, use a distinct state rather than counting the change as either a success or a failure.
- Use independent checks where appropriate. The post says one in ten changes in the revised process was checked by someone uninvolved in the work. This is the author’s described practice, not a universal required sampling rate.
A change-management system can support this workflow if it allows teams to record expected outcomes, attach evidence, and represent an awaiting-verification state. The process matters more than the product: fields and statuses only help when people use them to distinguish implementation from demonstrated results.
What the reported numbers do—and do not—show
After the process change, Shinder reports that the success rate fell from 98.6 percent to 91 percent. He argues that the lower rate was more meaningful because unverified changes were no longer treated as confirmed successes. The figures are his before-and-after account; the post does not establish that the workflow caused the change or that the result persisted.
Rank #4
Likewise, the roughly-half finding refers to Shinder’s review of 200 standard changes. The available post text does not provide a sampling method, observation period, organizational context, or independent audit. It should not be read as a representative benchmark for IT teams generally. Its practical point is narrower: a success measure based on implementation and the absence of an immediate incident can overstate how often intended outcomes are actually confirmed.
Measure implementation and outcome separately
Implementation status, immediate incident reporting, and outcome verification answer different questions. Keeping them distinct makes change records more informative: teams can see what was carried out, whether an immediate problem was reported, and whether the requester’s expected result was observed. As Shinder puts it, “We had spent years measuring whether the work happened, and no time at all measuring whether it worked.”
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
