Failure of configurator projects: 9 crucial mistakes

Author: Walter Burgstaller

With over 10 years of experience and hundreds of successfully implemented configurator projects, we can now accurately pinpoint why such projects fail. We've had our learning curve as well and, in the past, made or allowed all of these mistakes.

For many years now, we have been managing not only the projects, but also our customers - a factor that should not be underestimated - in such a way that every configurator project we launch is successfully implemented. This does not always automatically mean that customers are successful with the configurator per se. More on this in the blog article: Sales increase through product configurator.

When is a configurator project considered a failure?

Simply when the configurator never goes online or when one or more customer stakeholders are not satisfied. Mainly the management level or sales, but also the users - both internally and externally.

There are 9 common reasons - and the presence of even one of these reasons can be enough to cause the project to fail:

1. Unclear requirements
2. It was not specified for whom the configurator is intended.
3. Insufficient definition of the product scope
4. Not all stakeholders were involved
5. Problematic connections to third-party systems
6. Poor browser support
7. Lack of UI/UX know-how
8. Floating scope
9. Selection of the wrong platform

1. Unclear requirements

When customers only know that they want a configurator, but have not precisely defined it for themselves:

• Who is the configurator for?
• What exactly should the configurator be able to do?
• What exactly is the scope of the project?
• And how should the generated leads be handled?

Then a configurator project cannot be successful. These questions often sound so trivial that they are ignored too quickly, but they must be clearly defined before the project starts.
 

2. For whom - the personas

As mentioned above, the "for whom?" is so important that it needs to be examined in more detail. If the configurator is to address several target groups or different user groups, it is crucial to define clear personas. This point is often underestimated, as stakeholders often assume that the target groups are obvious. In reality, however, there are often different requirements. What internal sales employees need may differ significantly from the requirements of a retailer or potential customer. If these differences are not taken into account, failure is inevitable.
 

3. Definition of the product scope

The configuration options of the product must be clearly defined. What variants and options are available? This may sound simple, but in practice it is often more difficult than expected. Different stakeholders may disagree on what the product should offer. It is important to ensure that all stakeholders agree on the product scope before the project starts. All features and dependencies should be visually represented in a product tree.
 

4. Not all stakeholders are involved

The personas and the definition of the project scope illustrate how crucial it is to involve all stakeholders in a project right from the start. Involving stakeholders too late or even at the end of the project will inevitably lead to failure. This shows that early and comprehensive stakeholder involvement is a key success factor. Obtaining feedback in good time and taking into account the needs and perspectives of all those involved are crucial to getting a project on the right track and bringing it to a successful conclusion.

5. Connections to third-party systems

It must be clear which third-party systems need to be connected. Is it a store system, a PIM, an ERP or "just" Excel? So that data in the configurator can be updated easily and as automatically as possible. Projects can drag on very quickly if this point is not properly defined. Or if IT - keyword: stakeholders - is informed and involved too late.

6. Browser support

For e-commerce customers, this question does not even arise. But B2B customers, especially with CPQ solutions, non-browser solutions are also sufficient, as the configurator is "only" used within sales. We are often shortlisted with pure IT configurator solutions that provide no or only a very limited browser UI. Every one of our customers' configurators goes online at some point. Our recommendation: Plan for full browser support right from the start. Speaking of browsers - customers still underestimate how important it is to also have mobile phone support - and in the case of very extensive products, only in a limited form. However, implementing this at a later stage can be a challenge.

7. UI/UX

A successful configurator must have a good UI/UX (user interface and its behavior), otherwise it will not lead to an increase in sales. Here, seemingly small changes can often make all the difference. What is the aim of the configurator? Who uses the configurator? Keyword personas. Unfortunately, mistakes are often made in the basic approach, especially if the internal view defines the design of the user interface and user experience and little or no consideration is given to the needs of the users.
 

8. Floating scope

One of the most dangerous mistakes is constantly adapting and changing requirements during project implementation. Even if it is always tempting to introduce new ideas and requirements, these always have unexpected side effects. They delay the speed of project implementation (runtime) or change the user experience. A quick go-live and gaining experience are more important than implementing everything immediately at the first attempt. The longer a project runs, the more likely it is that the scope will change - often for realistic reasons. Often simply because the sales product has also changed in reality during the delay.
 

9. Choosing the right platform

Once all requirements are known, it should be checked again whether the platform with which the configurator is to be implemented is also the optimal solution. Is the platform optimized for the requirements or do "workarounds" have to be made or even compromises accepted. Conversely, we also tell our customers if our configurator platform does not meet their requirements. See blog article "When is Combeenation not suitable?"
 

Summary

As with any project, careful planning is of great importance. Avoiding these 9 mistakes lays the foundation for a successful configurator and paves the way to success.
 

The Combeenation path

We avoid many of the problems mentioned above through a concept phase - see "Why a workshop is necessary before buying a configurator". - The following points are ensured:

• Define clear requirements and goal of the configurator
• Define the personas of all configurator users
• Written definition of the product scope
• All stakeholders are involved right from the start
• Interfaces to third-party systems are clarified - usually together with IT
• Browser support and mobile support are clarified and defined
• Well-defined UI in the customer's corporate design and a UX from our UX experts
   

Here are our personal "secrets" for project implementation:

• Projects are only started when all the data from the customer is available - this prevents a lot of problems during project implementation.
• We do not allow a "floating scope". Only changes due to showstoppers are accepted - everything else is put on the back burner after the first go-live. Always in consultation with the customer, of course.

Please feel free to give us feedback on your previous configurator projects. Or are you planning a configurator project? We would be happy to take a look at your project and give you feedback.