Embarking on a CPQ project can be daunting, but it yields big rewards for your organization. Understanding some key ground rules before beginning your implementation will help make your CPQ project a successful one. Simplus has years of expertise integrating CPQ into various customer environments with successful outcomes for our clients. Take a look at seven of our best practices before starting your CPQ project. 

1. It’s all about adoption. Unless the sales team adopts the solution, our efforts are pointless.  We provide our clients with a best practices document that summarizes all of the activities we recommend for obtaining adoption at kickoff. We can also run change management processes and provide materials to help ensure that you don’t suddenly discover issues weeks from launch. Our methodology is geared towards realizing that our end goal is to have the solution adopted by the users. This key consideration is incorporated from the beginning of the project and examined regularly throughout the process.

2. Commitment! Projects fail when teams are not adequately staffed with the necessary resources and the time to complete the activities required. This is true for the service provider as well as the customer. We require that all customers engage in their project in a manner that allows us to progress quickly and that the executive stakeholder for the project attends the stakeholder review meetings every month. We have long known what the Project Management Institute (PMI) recently pointed out in a report: that a lack of stakeholder engagement tends to lead to problems on projects and is a foundational factor to success.

3. CPQ is a unique beast. The ROI on CPQ is significant, but with that pay off comes a level of complexity that can be hard for some companies to fathom until they are knee-deep in it. As an example, CPQ will be the first time that legal, finance, sales, pre-sales, product management, product pricing, and downstream ordering all work together in the same unified business process. With all those intersections, there’s a complexity and contention that needs to be resolved early in the requirements gathering phase. It is critical that the people involved in the project can alter business workflows to accommodate; otherwise, it will cause delays and impact project success.  A proven implementation partner will be able to help your organization navigate the journey.

4. Pure Agile won’t work. We’ve learned over many years that an Agile development approach doesn’t work for the first implementation of a CPQ solution. I know strong supporters of Agile will balk at this statement, but I challenge anyone to find a CPQ solution that iterated its way to a fully paid first solution for a customer. While there are a lot of benefits to an Agile approach, the interdependent complexities of CPQ and Agile’s lack of detailed end-to-end design tend to mean that each subsequent sprint requires more rework. This eventually leads to sprints that are filled with rework instead of the completion of new user stories. We have to remember that Agile’s original intent was focused on product development environments, where there is no rigid customer budget. It’s simply a matter of “fit for purpose,” and we have plenty of customers who can attest to this approach failing dismally. Instead, we recommend beginning with a Waterfall approach through to the end of the design phase. At that point, stakeholders can choose if they want to go through development sprints (iterations) or continue with a traditional waterfall method. 

5. Don’t bend the product. CPQ products were made for one thing:  quoting. There’s a tendency for customers to want to build in other processes that are within their sales cycle into the CPQ platform. This is a recipe for failure. Our teams are taught to get customer’s live with the product the vendor has today and not the product they promised tomorrow. We’ve found that in too many instances tomorrow never arrives and that can cause issues for the implementation. CPQ is just one tool in a larger quote-to-cash journey, and other tools will be needed to build in other processes.

6. Architecture is the key to performance. Our best practice is to have every architecture that comes out of the design process reviewed by our architecture review board. The purpose of this is to ensure the product is being used correctly and doesn’t contain any areas of concern.

7. Use the methodology. Our methodology has been purpose-built for the Salesforce platform. We have a purpose-built methodology for every product we implement. We do this so that we can merge the concept of best practices for project management along with the best practices for that product. This makes for a seamless methodology that is focused on achieving one goal—successfully getting our customers across the finish line and the platform implemented with a high user adoption rate. Our methodology is also attached to the customer’s project workspace within our Salesforce environment, which means that it isn’t just kept on a drive somewhere. This methodology is actively used by the project team to ensure the project is on track.

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