Why CPQ projects fail, and what to settle before you build

A machine builder has spent eight months on its configurator. A configurator is software that lets you build a product from options, like ordering a bike where you pick the frame, the colour and the gears. In the demo, it works. The sales rep picks a setup, the price appears and the quote comes out. But in engineering, nobody trusts the result. Every quote from the configurator gets checked again in the old spreadsheet, just to be safe. So the configurator hasn't become a shortcut. It has become an extra step.

Nobody made one big mistake here. The problem came from a pile of small choices, most of them made in the first few weeks.

The pattern: one poor decision early on

In 2019, Danish researchers (University of Southern Denmark and DTU) studied eight configurator projects that had failed. They kept seeing the same pattern. A poor decision in one phase has bigger and bigger negative effects in the phases that follow. Think of a row of dominoes. A rule that's missing at the start becomes an error in the model. That error becomes a wrong price during testing. In the end, you have a configurator nobody uses.

It is a small study. The authors point out that earlier claims about companies dropping their configurators were based only on the writers' own experience. Little was known about the projects themselves. That fits a wider point made in 2015. Studies do show that configurators save time and improve quality. But empirical research, meaning research based on real data from companies, into what a configurator means for the rest of the business is very limited. Still, the pattern is easy to spot: what goes wrong early carries through into everything after it.

Six types of implementation challenges

A 2018 study lists six types of obstacles when a company introduces a configurator. The researchers used earlier studies and a survey of manufacturers. In practice they look like this:

Notice anything? Hardly any of these are about software. Only one is about IT. Three are about organisation, time and knowledge. Two are about the product itself and how you describe it.

Rules that live in people's heads

Almost every manufacturer has someone who knows things that aren't written down anywhere. For example, that a certain width always needs an extra support, or that two options can't be supplied together. That knowledge sits with the estimator, the production planner or the engineer who has known the product for twenty years.

A configurator can't guess that knowledge. It only follows rules that someone wrote down. A rule is something like: "If it's wider than 120 cm, always add a centre post." If a rule is missing, the configurator gives a result that is technically possible but wrong in practice. That's exactly where the distrust in the example above comes from.

The fix isn't hard, but it takes time. Sit down with those people and get the rules out of their heads. Write them down. Then have the same people check them. How to do that without any software is covered in CPQ data preparation.

Who owns the rules after go-live

A configurator is never finished. Your product changes. Prices change. A new option gets added. Every change has to go into the rules too. If nobody is responsible for that, the configurator falls behind reality within a year. Sales notices and goes back to the old way of working.

So agree on these things before you build:

• who owns the rules: one person or a small team, with the power to decide
• how a change happens: who asks for it, who makes it, who tests it
• how fast a change has to go live: for a new price list, for a new product
• what your own team can change, and what needs the supplier

That last point decides how much you keep depending on whoever built it.

Start small: one product line, one channel

Many projects try to do everything at once: every product line, for sales reps, distributors and the website, all at the same time. That's understandable. But it makes all six challenges bigger at once.

Start small instead. Pick one product line that brings in lots of quotes and whose rules you know fairly well. Pick one channel too, for example inside sales. You'll learn fast where the rules are wrong. Your people will start to trust the output. And the next product line will go faster. Where the time in your quoting process really goes, and so where to begin, is covered in Faster quoting in manufacturing.

A plan before the build

A 2022 longitudinal case study, meaning one that followed the same company over time, looked at a large engineer-to-order company while it built its configurator. Engineer-to-order means the company designs the product for each customer after the order comes in. The conclusion: you need a clear and complete project plan before development starts. It's just one company, but the lesson matches the rest of the research.

The plan doesn't need to be long. It does need to answer these questions:

1. Which product line and which channel come first?
2. Which rules, options and prices are already written down, and which aren't?
3. Who owns the rules, now and after the configurator goes live?
4. Which systems does the configurator talk to, and what exactly goes back and forth? See also CPQ and ERP: who does what.
5. When will engineers trust the output enough to stop rechecking it? Agree how you'll test that.

It helps to have this plan checked by someone who isn't selling you the software. That's what CPQ consulting and selection is for. We look at your product, your rules and your plan with you, before anything gets built.

Want to know where your project carries the most risk? Tell us what you make and how you quote today. Get in touch, or first read how we work on CPQ Consulting & Selection.