Change management case study: the parts worth your attention

One rollout, followed from the decision to the eighth week. It is invented, the numbers are placeholders, and no organization is described. What makes it worth reading is that nothing in it went wrong in the way the plan anticipated.

The switch itself was clean. Everything that mattered went wrong in the two weeks afterward, which is the part that had no plan.

What to take away

The change

A team handling incoming case work moved from a shared mailbox to a queue with defined states. Reasons: no record of what arrived, no way to see load, and two cases lost in the previous year.

The plan ran to several pages and covered the migration, the training, the field mapping, and a rollback. It did not cover what would happen to cases already in progress, and it assumed the team would be at normal speed within a few days.

The diagram that accompanied the plan looked like the one above: boxes, arrows, and a decision point. It described the intended route accurately and contained none of the four things that later caused trouble, because none of them are the kind of thing a flowchart holds.

Week by week

Week minus one. A dress rehearsal ran on a copy of the system with three volunteers. It went well and took ninety minutes. Nobody noted that the three volunteers were the three most experienced people on the team.

Week one, day one. The switch happened on a Monday. Cases in flight were handled by asking people to finish them in the old mailbox, which most did. Two people were on leave and their in-flight cases sat in a mailbox nobody was watching for nine days.

Week one, days two to five. Throughput dropped to roughly half, which had been expected. The queue filled correctly, the states worked, and the reporting produced its first numbers. By Friday the plan was recorded as successful.

Week two. Throughput did not recover. It sat at about two thirds. Three separate people had begun keeping a personal list beside the queue, because the queue showed them everything and they needed to see their own next action. Nobody reported this because it did not feel like a problem, it felt like a habit.

Week three. The first customer complaint arrived about a case that had been reclassified twice and had moved between two people. In the old mailbox it would have stayed with whoever picked it up. The queue distributed by state and nothing carried ownership across a reclassification.

Week four. The manager, reading the new reports, saw that average handling time had risen and asked why. The team said the system was slower. The system was not slower. Reclassification was creating rework, and the report had no way to show a case that had been through a state twice.

Weeks five to eight. Two small fixes were made. Ownership was made sticky across a reclassification, and a personal view was added so people could see their own work. Throughput returned to the old level in week seven and exceeded it in week eight, for the first time.

What the record shows

Four failures, none of them technical.

The dress rehearsal missed all four because the three people least likely to hit them ran it. A rehearsal staffed by the most experienced people tests the system, not the operation.

That selection effect is ordinary, and it is the same effect that makes any self-selected sample flatter what it measures, described generally as selection bias.

What was done differently the next time

The team ran a second, smaller change three months later. Three things changed in how it was run.

The rehearsal was staffed with two people who had joined in the last year. It took four hours instead of ninety minutes, which was the useful result.

Every open item had a named owner for switch day, written down, including for people on leave. One person kept a dated log for the first three weeks, recording anything anyone started doing differently.

The log turned out to be the highest-value item. It cost about five minutes a day and it is the reason there is a week-by-week account at all. Reconstructed a month later, the second and fourth failures above would have been invisible, because nobody remembers the day they started keeping a list.

Reading this without over-learning from it

Nothing here transfers as a conclusion. Your rollout will not fail on reclassification ownership, and going looking for that specifically wastes the effort.

What transfers is the shape: the technical work was fine. The failures were in work in flight, in an unnoticed function the old way provided, and in a measure that could not see the new failure mode.

Those three categories recur. The caution about reading a single account of somebody else's work, including this one, is in operations case studies.

The method for finding the unnoticed functions before you switch, rather than in week two, is in change management framework. The conditions worth confirming at each phase are listed in change management checklist, and the mechanics of the switch week itself, including cover and rehearsal, are in change management guide.

Why a report can show a rise in handling time while nothing about handling changed is the measurement problem treated in operating processes metrics. The broader point, that the described process and the operated one diverge quietly until something forces the comparison, is documented in the UK Health and Safety Executive's material on managing human failure.

Common questions

Was the change worth making?

By week eight, yes, and that is knowable only because there was a before-reading. Without one, the honest answer would have been that people had got used to it, which is not the same thing.

How long should the log be kept?

Through the degraded period, which here was about six weeks. Stopping at the end of the switch week would have missed three of the four failures.

Should the rollout have been staged instead of switched at once?

Possibly, and a staged version would have traded a shorter disruption for a longer period of running two ways at once. Neither is free. The choice depends on whether you can afford a long parallel period, which is a capacity question rather than a preference.

Who should keep the log?

Someone doing the work, not the person who designed the change. A designer's log records whether the plan was followed. An operator's log records what actually happened, and only the second one contains the surprises.