I like leading CPQ projects. Those involved in CPQ projects are genuinely passionate about the project and excited about the positive results that CPQ implementations can bring to their organizations. However, these implementations are challenging, in part, because CPQ is complex and it’s usually the first solution that requires sales, pricing, products, finance, and legal to all agree on a unified process for selling. 

I’ve led and participated in several CPQ projects over the last several years, and so I want to share some areas that are prone to difficulty. Scope, pinpointing clear configurations, and data integration are all areas of potential pitfalls—but here’s how to avoid falling flat.
 

Scope

The key to kicking off a positive CPQ project is scope. The scope of the project should be clearly defined in the statement of work (SOW) and estimated conservatively since the beginning of a project is when we know the least about the full scope and final deliverables. The breadth of a project often changes, especially on an initial project. Customers and service providers often use different terminology to describe project elements and outcomes they seek. This is particularly true of CPQ projects because unlike accounting, for example, most organizations’ processes for quotation are unique to them (especially product configuration) and there isn’t an industry or ISO-type standard for quoting customers. 

There are various “aha” moments in the project when one party realizes there’s a discrepancy in expectations about the span of the project. At this point, normal project management practices apply. If the extent of the surprise is low, then it should be absorbable within the project budget. If the impact is high, then a difficult decision needs to be made. The key to project and budget health is to get through the ambiguity quickly. A big surprise introduces significant risk to the project feasibility. It’s better to re-align expectations now and have difficult conversations to keep the project on track and ready to deliver a positive ROI.

Pinpointing clear configurations

Another interesting pitfall is the source of subject matter expertise (SME) related to product configuration. As mentioned earlier, the product configuration is unique for every company needing a CPQ solution, and configuration is usually custom-built, even though CPQ is a platform or “package.” 

Usually, product configuration information is located in the heads of a few, hard-to-access SMEs or in a system where the experts are long gone from the project scene. Assuming the SMEs are available for the project, these individuals very often have difficulty seeing how their requirements translate into a CPQ solution. Further, the level of detail that’s needed is often not apparent to the contributors even after several demonstrations of “similar” solutions. Quick-build prototypes or wireframes of user interfaces can help bridge this gap and can give the suppliers of information the context of what certain information is being asked for.

Data integration 

The last pitfall I will mention is data and data integrations. It may seem obvious, but in CPQ projects, erroneous data manifests in ways not exposed in the legacy processes. This is generally because CPQ is expected to add additional functionality based on data logic. Often, the data is assumed to be correct or is being manually massaged in a way that’s not sustainable in a volume or scalable approach. CPQ projects will often depend on the health of the data, so it’s vital to ensure accurate data sources. Having more than two data sources tends to complicate matters, and multiple integrations to different systems is often an indicator of underlying data issues.

A well-implemented CPQ project can have a truly positive impact on an organization’s business. However, be aware of these three pitfalls from the beginning to ensure a smoother CPQ journey and help in increasing the probability of a successful outcome. 

To find out more of what Simplus can do you for, contact us today!