Process improvements have a half-life. The gains achieved in the first weeks after a redesign go-live are real, but they are not self-sustaining. Without a structured review at a defined point after implementation, most organisations find that performance has drifted back toward the old baseline within three to six months. The drift is usually gradual and not immediately visible in headline metrics.
Why twelve weeks specifically ¶
Twelve weeks is long enough for the initial novelty of the new process to have worn off, for informal workarounds to have started developing, and for edge cases that were not covered in the design to have appeared. It is also short enough that the drift, if it has started, is still correctable without a full redesign. Earlier reviews tend to catch problems that are still in the adjustment phase and would resolve themselves. Later reviews tend to find problems that have become entrenched.
What to measure in the audit ¶
The audit should compare current performance against the baseline recorded before the redesign, not against the performance recorded immediately after go-live. The immediately-post-go-live numbers often reflect a temporary improvement driven by heightened attention, not a sustainable change in the process. Compare against the pre-change baseline. Measure cycle time, error rate, and rework percentage at minimum. If you measured step-level timing at the start, measure it again now.
Common sources of post-go-live drift ¶
The most common sources of drift are: informal exception-handling steps that were not addressed in the redesign and have re-emerged; staff turnover that has introduced operators who were not trained on the new process; approval gates that have reverted to the old frequency because the manager who changed them has moved on; and system workarounds that reappeared when the new process encountered a transaction type that was not included in the pilot dataset.
How to respond when performance has drifted ¶
The response depends on the cause. If the drift is due to a design gap, the gap needs to be addressed in the process documentation and the affected steps need to be re-trained. If the drift is due to a management change, the new manager needs to be briefed on the intent of the redesigned steps. If the drift is due to a system workaround, the workaround needs to be either formalised in the process or eliminated by fixing the underlying system issue. Treating all drift as a training problem is the most common mistake.
Building the audit into the original engagement ¶
The most effective post-implementation audits are ones that were planned and budgeted before the redesign began, not ones that are commissioned after problems become visible. When the audit is planned from the start, the baseline measurements are taken with the audit in mind, the audit criteria are agreed before go-live, and the team knows from the beginning that there will be a formal review. That knowledge alone tends to improve twelve-week performance.
A twelve-week audit is not a sign that the redesign did not work. It is the mechanism by which you confirm that it did, and fix the things that only became visible once the process was running at full volume.