People ask what our transformation covered, and the answer sounds like bravado: everything.
By the time the second transformation at the major national retailer was complete, we’d brought accounting from paper to SAP. HR and payroll ran on a SaaS model. Merchandising ran on an actual merchandising system instead of the improvisations it replaced. Every department, every major function, everybody, was on the new equipment, using the new systems. Literally everything.
Each exception is individually reasonable, and collectively they’re how a transformation dies while appearing to succeed.
I emphasize the completeness because it was the hardest-won property of the whole program, and because its absence is the most common failure I see in transformations today. I get angry watching a company spend years and a fortune on a program, declare victory, and leave its three ugliest systems exactly where they were. Those systems are where the next outage comes from, and the people who get paged at two in the morning for it aren’t the ones who approved the exception.
The gravity of “everything except”
Every transformation faces constant pressure to become “everything except.” Except this department, because they’re mid-busy-season.
Except that system, because it works fine and nobody fully understands it. Except the homegrown tool in the corner, because the person who wrote it left. Each exception is individually reasonable, and collectively they’re how a transformation dies while appearing to succeed.
The excepted system still needs to talk to everything you modernized. So you build and maintain bridges between the new world and the old one. Those bridges are the most fragile things you own. The excepted system still needs skills to operate, so you retain expertise in a dead platform, an expense that grows as the people who have it leave.
I’ve never liked calling these things bridges. The word sounds like engineering. In practice it’s a script somebody wrote against a deadline, running on a schedule nobody documented, and when it breaks the numbers on both sides stop matching and somebody loses a week finding out why.
And the excepted system becomes unowned: not in the new support model, not covered by the new monitoring or disaster recovery, drifting toward the fate of the server we found under a desk. That was a system that escaped the transformation’s scope because it had escaped the inventory.
How does transforming everything get done?
By refusing exceptions, and I mean refusing them out loud, in the meeting, to the department head who’s asking. Once one department is allowed to stay on the old system, every department asks for the same deal, and the leader who granted the first one has no ground left to deny the rest.
From the podcast
Ben “The Automator” Christensen names what stalls the scope work before it starts, on Leaders and Their Stories:
A lot of your slow and fatigue points are going to be that tribal knowledge, the lack of documentation, the lack of artifacts that exist, and then whether Timmy and Sally do the process the same or not.Everything means everything, and the parts nobody wrote down are the parts that make the scope real.
Completeness wasn’t achieved by heroic simultaneity. We didn’t convert the company in one gesture; the platform cutover was a big-bang weekend, but the functional transformations around it, accounting, HR, payroll, merchandising, landed as their own efforts inside one program with one non-negotiable rule: the program isn’t finished while anything remains. Sequence is a tactic, and scope is the commitment it serves.
The distinction matters because sequencing pressure and scoping pressure feel identical in the moment. “Let’s do accounting later” can be a sequencing decision or the first exception, and the difference is whether “later” has a date and a budget. In our program it always did, so later eventually arrived for everything.
Years later, after we’d been through some crashes, I applied the same rule to the infrastructure, and it produced the build I’m proudest of. We put about 300 servers on a VMware private cluster, virtualizing everything we could, even machines running older operating system versions, and the whole environment got more secure and more stable for it. We farmed out the VMware management to an outside consulting firm, and it ran beautifully.
Put a number on the exception tax and the scope argument wins itself. Every excepted system carries the bridge (built once, maintained forever), the skills retainer (rarer and pricier each year the platform ages), and the incident premium (unmonitored systems fail into surprises instead of tickets).
In our program, whenever “leave it alone” came up as an option, pricing those three lines made the exception more expensive than the migration in every case except end-of-life systems already scheduled for retirement. Those are the one legitimate permanent exception, and even they need an owner who makes sure the shutdown date holds, because a retirement date nobody enforces can stretch into a decade.
| Cost of an exception | What it involves |
|---|---|
| The bridge | Built once, maintained forever; often an undocumented script that breaks the numbers on both sides |
| The skills retainer | Expertise in a dead platform, rarer and pricier each year it ages |
| The incident premium | Unmonitored systems fail into surprises instead of tickets |
| Lost ownership | Outside the new support model, monitoring and disaster recovery |
| The precedent | Once one department stays behind, every department asks for the same deal |
| The one legitimate exception | End-of-life systems already scheduled for retirement, with an owner holding the shutdown date |
My take
Refuse the first exception out loud, in the meeting. Once one department stays on the old system, every department asks for the same deal. Give every later a date and a budget, or it’s an exception in disguise. Price the bridge, the skills retainer and the incident premium, and the scope argument wins itself. End-of-life systems already scheduled for retirement get a pass, as long as an owner holds the shutdown date.
A transformation that modernizes ninety percent of a company leaves the other ten percent setting the speed.Share on X
The executive’s version of this lesson
If you’re sponsoring a transformation, make your team answer one question: what are we not transforming, and what’s the plan for each of those? Anything on that list without a date and an owner is a decision to run a two-speed company indefinitely, and the slow half of a two-speed company sets the speed. I’d put that question to the team every quarter until the answer is an empty list.
Our program ended with that list empty, and I’m prouder of that than of any go-live party along the way. A transformation that leaves exceptions behind has only moved its risk into the corners where nobody looks, and whoever inherits those corners pays for the shortcut. I’d call that an unfinished job, and I’d tell the sponsor so to their face.
For more from this series, see The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
