CPQ (Configure, Price, Quote) or Quote to Cash projects, over and over people ask me which delivery methodology is the best for CPQ projects. In most cases, folks go with either Agile or Waterfall, with Agile being more and more common these days. And, it is for a good reason, many projects suffered significantly while trying to deliver the projects in Waterfall. However, it is also possible that the folks who have seen project being delayed or gone over-budget, might not have much to do with following either Agile or Waterfall, rather it might have to do with the project management issues itself. Anyway, here’s my view about the delivery methodology for CPQ/Quote to Cash projects.
Agile project management is an iterative approach to delivering a project throughout its life cycle. Iterative or agile life cycles are composed of several iterations or incremental steps towards the completion of a project. Iterative approaches are frequently used in software development projects to promote velocity and adaptability since the benefit of iteration is that you can adjust as you go along rather than following a linear path. One of the aims of an agile or iterative approach is to release benefits throughout the process rather than only at the end. At the core, agile projects should exhibit central values and behaviors of trust, flexibility, empowerment and collaboration.
Benefits of Agile for CPQ Projects:
a. Agile comes with better stakeholder engagement during the lifecycle of the CPQ project, as the stakeholders get to review the work done at the end of each sprint. One of the most significant benefit of Agile delivery method is the ability to review the products as it is being built, this alone avoids culture shock (which is a common problem with Waterfall delivery) and enables the stakeholders to make necessary changes upfront (if we remember, earlier changes are easier to make and less costly).
b. Agile allows for changes to happen, and because CPQ projects can go on for four to six months (complex ones could go for 1 year or longer), ability to change the scope (where possible) ensures that the CPQ scope has the latest product and pricing information when it goes live.
c. Quality is another benefit I’ve seen from using Agile delivery method; if we go for 2-week sprint, then at the end of the sprint, the work will get verified by the product owner/stakeholder. Even though SIT (system integration testing) cannot be done until all of the parts of the project is ready, each segment can get tested way earlier during each iteration, and issues can be captured/fixed way earlier in the process. Agile allowed us (in one instance) achieve 0-issue go live, by taking advantage of early testing, avoiding ‘issue tsunami’ during SIT/UAT.
There are many other benefits of Aigle, for example, faster prioritization, user focused, early realization of benefit and so on, the following two articles do provide some of these benefits.
There are some disadvantages, as all delivery methodologies do, of Agile. For CPQ side, if we’re not careful, the strength of Agile could turn into its biggest drawback, which is frequent changes, creating widespread scope creep and pushing the project scope further away from the original goals. Also, a project needs to have a defined budget and defined end date, if the backlog continuously changes, it makes it very hard for the PM to achieve go live dates, which were estimated based on original scope of work. Another challenge of Agile is the delay in technical design for CPQ products. The design of agile stories get finalized after grooming session, instead of up front during dedicated design sessions in Waterfall, sometimes that’s too late in the project lifecycle, if the design is found to be too hard to deliver or, even worse, previous work has to be altered to accommodate newly found design constraints. For example, if the story about integrating CPQ with SAP forces a new API design, it might force the re-design/update of the configuration and pricing/part structure, which could have been built already. Anyway, with some good PM-ism and control in place, being flexible and with end in mind, it is possible to overcome such challenges.
Based on this methodology, the terms of the software development require that the transition from one phase of product creation to another occurs only aftr the full completion of the previous phase. There is no phase overlap. The budget and timing is strictly fixed.
The classic implementation of the Waterfall model involves phases of project development in the following order:
These listed stages are performed sequentially, and the obtained results are documented. The change in the finished product functionality occurs only after its release to the consumer market.
There are certain benefits of waterfall delivery method, making it an attractive option for green-field CPQ projects:
a. For this method, the requirements are clearly stated way early in the process, and they are kept mostly unchanged for the duration of the project. This defines the scope, which, in turn, defines the delivery timeline and the budget. Hence, it is called a predictable model. It works well when the product & pricing configuration in the business is very mature and stable, minimizing guesswork while building the requirements.
b. For companies which have stringent documentation need, waterfall provides the opportunity to get the documentation done properly. Unlike Agile, Waterfall is heavily dependent upon documentation and the completeness of such. Because of strong documentation need, it is a common choice for turn-key green-field CPQ projects, where such documentations could be used to clear out any confusion between the requirements and delivered CPQ products.
c. Waterfall projects have defined start and end dates, defined scope, defined budget and clear project delivery plan. All these makes it a much easier for the PM to manage and control the every step of the project, and run measurements to check the progress as well.
There are other benefits of waterfall as well, can be found here:
In addition to the drawbacks mentioned in the articles above, for CPQ projects, there are a few distinct problems I’ve seen with such delivery:
a. Delays and over-budget, very common for Waterfall CPQ projects; as it doesn’t account for unknown challenges during planning stage, especially unforeseen ones, and which can be found while the development is going on; also, by definition, changes are very hard in this method, the CPQ projects using Waterfall get delayed frequently.
b. CPQ projects following Waterfall delivery might see the tsunami of issues during SIT/UAT, as these tests are conducted after the development of all key components are completed. Because the testing is conducted so late in the process, it is common to find many issues during the testing phases. Unfortunately, fixes to these issues also become very time consuming, costly, prone to more issues, and frequently contributing to delays in going live.
c. Biggest headache I had with Waterfall delivery of CPQ project is the what I call ‘culture shock’; when requirements were given by the stakeholders very early in the project, they always have ‘something’ in their mind as the final product (Porche); but they don’t get to see it until UAT starts, which is at the tail end of the project, and it is common for them to get surprised to see the product might not be the one they had in mind (Porche vs Toyota Yaris). Again, it’s always too late at this stage to make any significant changes to the scope anyway.
Now, a picture worth a thousand words, here’s the best one I’ve found:
A quick story, few months back, I met an Agile Coach, and he was having very hard time understanding why pure Scrum might not work for CPQ projects. Coming from one set mindset, he was lacking the flexibility and adaptability that we look in CPQ Project planning. For CPQ projects, ability to change is crucial, as the project may go on for a long time, and as the product changes with the market, we need to make sure the product & pricing configuration is still valid when the CPQ goes live, hence the ability to update the rules during the project execution is important. In addition, option to review the development with the stakeholders and incorporate the feedbacks, also important for CPQ projects to be successful, and only Agile delivery allows it
At the same time, a project, by definition, has 3 constraints: budget, scope and timeline. If we do not constrain the CPQ project within this boundary, it becomes an endless pit of money waste with no end in sight. I did see one job in the South, where the project consumed double the budget, but still failed to deliver a working copy of CPQ. On the other hand, rigid scope of waterfall delivery just doesn’t meet the need of the flexibility and nimbleness that a CPQ project demands.
My recommendation is always to go with the best of two worlds, sometimes it is called Hybrid, please check the article below. What I’ve found works the best when we put the border around the project budget, scope and schedule, but execute using Agile. So, the question came out which is the best for CPQ projects then, and the answer is “it depends”. For PMPs like us, we know that we need to tailor our delivery methods to ensure project success, blindly following one over another method might not take us to the successful delivery. The readiness of the product, the readiness of the enterprise, stakeholder & SME availability & dedication, management commitment, all of these factors will define the best approach for a given organization and project to follow. The project delivery methodology needs to be flexible, adapting to the unique business need, and focus on the main goal of delivering a successful CPQ project, which should deliver the promised business benefits in future.