Chapter 11: Projects Die on Org Charts

The ruleset was pristine. Months of modeling, every constraint verified with engineering, technically the best configuration model I had seen in years.

Within a week of go-live, sales had a nickname for it: the trap.

Pick an option, and somewhere down the line a red error announced that your configuration was invalid. No reason given. No route out. The system delivered its errors like verdicts, and the sales team responded the way sales teams always respond to verdicts: they went around the judge. Back to spreadsheets, back to calling engineering, back to everything the project was supposed to end.

Here's what makes this story worth a chapter: the fix involved no new rules. The team exposed the why: which constraint fired, what it protected, what the nearest valid alternative was. Same logic, now visible. Usage climbed within days. Escalations halved.

Sales doesn't fear rules. They fear not knowing why. A salesperson works in a commission world where uncertainty is personal financial risk; a black box that says no without reasons is asking them to gamble their quarter on its judgment. Refusing isn't resistance. It's rational rejection. Correctness is the floor. Confidence is the ceiling, and adoption lives at the ceiling.

The corollary bothers perfectionists: 100 percent coverage that confuses is worse than 60 percent coverage that earns belief. I've watched teams double adoption by cutting scope in half: fewer products modeled, but modeled so clearly that the field trusted every answer. Trust, once earned, buys you permission to grow the scope. Completeness first buys you shelfware.

The quiet go-live

The best implementation story I know ends in silence.

Cytiva, the life-sciences equipment company, had run for roughly two decades on a homegrown configurator that everyone knew how to work around. Read that sentence again, because it describes half the manufacturers I visit: the workarounds were the process. Product changes had started to slow down to accommodate the system's limitations, which is the tail wagging the dog at industrial scale.

They chose to rebuild rather than patch, and three decisions made it work. First, before writing new rules, they collected between fifty and a hundred real historical configurations as a test harness: the new system had to reproduce reality before it earned trust, and they ran old and new side by side, publishing the comparisons weekly. People stop arguing with a narrative when the evidence is theirs. Second, they built an internal team to own the system, with the vendor's hours designed to step down month by month: lead, then co-build, then review. Ownership was a deliverable, not an aspiration. Third, they treated the beloved old tool with respect. "The only thing that never lets me down" isn't nostalgia talking; it's risk management, and it deserves evidence, not slogans.

The go-live signal was silence. No war room. A quiet support channel. Nobody reached for Excel. If your go-live needs a war room, you're launching noise, not trust. Boring is the point. Boring scales.

Compare the counterexample, which I've also lived: a manufacturer with 600 licenses and 80 weekly active users. That gap is where CPQ ROI goes to die, and no feature fixes it. (For the record: that team got to 290 weekly actives in eight weeks, by redesigning the three most-used flows and publishing a visible changelog. The system started answering to its users.)

Anti-pattern: The Everything Box. The project scoped to model all products, all markets, all price logic before anyone sells with it. It optimizes for the demo at the steering committee instead of the Tuesday afternoon in the field, and it ships, at best, a museum.

The pattern across every failure I've catalogued in twenty-five years: the technology was rarely the cause. Ownership was unassigned, scope was unbounded, explanations were missing, and the org chart never committed. These projects don't fail on technology. They fail on ownership.

So how do you start one without dying? Small, fast, and with a stopwatch.

These projects don't fail on technology. They fail on ownership. Adoption is the only metric that matters.