Imagine a start-up. It has seed capital and a pristine whiteboard on which to map business processes. With no constraints tying managers to how they operate today, they can design and implement sales tools and systems that reflect their optimal desired state.
They can deliver these solutions to the organization’s new employees as the only way to manage and conclude a sale. It’s such a nice dream!
The longer a new startup operates without implementing an overarching quote-to-cash (QTC) system1, and the more complex and variable the products, channels and governance structures it sells, the more likely a delayed QTC implementation will be fraught with pitfalls.
An effective change management framework will maximize the benefits of a QTC system while avoiding pitfalls early on -- like these:
- not detecting blind spots that can derail the workflow and misalign QTC processes;
- being unaware of hidden requirements;
- failing to align concepts, common usage of internal terms correctly for all parties;
- codifying traditional, weak practices that no longer work;
- failing to include stakeholders when realigning workflows; and
- failing to carefully train your workforce.
Today, few startups have the capacity, business maturity and forethought to build a scalable QTC system when they are just getting started. This means that by the time a QTC strategy becomes part of its growth and efficiency roadmap, it already has established expectations regarding how sales opportunities should -- or should not -- be moved through a workflow.
A simple way to examine a QTC system is to imagine it as having three separate stages. Each will likely have an obvious owner:
- Configure Price Quotation (CPQ) – defining a sales opportunity and determining pricing and discounting.
- Contract Lifecycle Management (CLM) -- presenting the approved offer to the customer in a template contract.
- Enterprise Resource Planning (ERP) -- implementing and billing the customer-accepted offer.
Be suspicious of traditional methods – detect blind spots
For example, Finance or Marketing might own the CPQ; Operations and Accounts Receivable might handle ERP and billing. Any of those groups might own a QTC project, and would look to key functional groups in the workflow as their key stakeholders. These key stakeholders would likely define most of the system’s requirements.
Although this approach adheres to traditional project management governance, it only expands its own blind spots. The QTC workflow is like a conveyor belt on which most -- if not all -- of a company’s revenue is processed. So, it cannot be overstated how deeply the QTC workflow will integrate into all areas of the business. Put another way, a QTC system isn’t a sales tool -- it’s a business tool.
Look for hidden requirements of stakeholder groups
They could impact your customers! Keep in mind, the following are some potential stakeholder groups whose day-to-day -- or occasional functions -- might be tied up in both the current and future QTC workflows: product, marketing, product development, go to market, tax, audit, regulatory, engineering, deal desk, bid management, credit, legal, operations, customer care, reporting, revenue recognition, compensation.
And it would be remiss to think of sales as the overarching beneficiary of the entire QTC workflow, because the sales focus starts in the middle of the process and tapers off at the extremes.
If there is one major beneficiary of the system, it is a company’s customers. With very few exceptions, efficiencies and rational sequencing of processes in a QTC project will impact end customers whose viewpoints and needs cannot be discounted.
Maintain a common vocabulary to identify your product or service
Almost all major business groups should be represented when the requirements for a QTC system are being finalized. The next hurdle is how to collect those requirements using a common vocabulary. In all likelihood, some of the identified stakeholders aren’t even aware that they have input or reliance upon the company’s existing sales processes. And even if they are aware, their concept of that input or reliance will be colored by their own internal systems and processes.
What if a stakeholder’s concept is correct in one sense, but skewed in another? For example, a regulatory group would recognize a product by the nomenclature used by a regulator. The marketing team would describe that same product using its branded name. An operations stakeholder might use a former name that aligns with how the product is referred to in a legacy provisioning system.
All three stakeholders are correct, and all have very valid business reasons for using the names that they do, and yet QTC requirements can’t be effectively gathered and understood until a common vocabulary is adopted for the product. Multiply that exercise by a thousand!
Map your opportunity
Another way to expose hidden requirements of an “as-yet-to-be-built” system is to “linear map” the opportunity as it flows through the sales cycle.
- Start with a simple acquisition order and describe the steps a “happy path” opportunity would take -- from identifying the customer to scoping, to pricing, to approvals, to quoting, to contracting and so on.
- Then, for each step along the “happy path,” think of potential spurs into other groups or processes. You might need to answer:
- Is there an existing tool for engineering plans?
- Does Finance need visibility to Marketing campaign information to do an exceptional approval?
- What is the process when an order reaches the contracting stage and then needs to be rescoped?
You would then duplicate this same linear mapping for each different sales scenario: an upsell, a renewal, an incremental order, etc. With these rough proxy workflows in hand, each stakeholder group could be asked to identify the areas they actively impact, and the areas they rely on for output.
Again, it’s important that everyone speaks from a common vocabulary when having these conversations. This would also be an opportunity to identify business processes that will not likely change through the QTC implementation.
- Are any of your processes impinging on the optimal functionality of the QTC system?
- Were they built to accommodate previous constraints that will no longer exist in the new system?
If so, it’s time to revisit those processes, keeping in mind that their owners might not have the same sense of immediacy or same desired outcome in mind. An example would be a credit review process that was designed around a legacy system that didn’t tie into a Customer Relationship Management (CRM) or couldn’t ensure customer contract signature prior to implementation kick-off. Always err on the side of caution when planning for the amount of time these incidental business process conversations will take.
Don’t codify old weaknesses – build a better system
By simply describing functionality as it exists in the existing processes and systems, and then converting those descriptions into requirements, the QTC project would effectively be codifying the weaknesses and gaps of the present day, rather than building a better system for the future.
So, when gathering requirements from any stakeholder, it is critical to encourage “blue-sky” thinking2. But also keep in mind what to avoid: If the QTC project were to completely redefine every business process associated with sales workflows, it would strongly destabilize the organization as a whole.
The middle ground between these two extremes depends on variables such as the…
- timeframe allotted for the project;
- willingness of the organization to undergo significant change; and
- amount of training resources available upon project rollout.
Invite stakeholders to identify workflow oddities
Another strategy for uncovering potential blind spots is to invite stakeholders to identify the least intuitive parts of their jobs. Then, using the 80/20 rule3, identify the oddities and exceptions of the current workflow. This will probably require the greatest degree (80%) in the new workflow finding solutions and 20% making exceptions or compromises in the new workflow.
Future-proof your changes
Also, don’t be afraid to ask for requirements that don’t exist yet. The more of these anticipated requirements the system can accommodate, the more future-proof it will be. You might want to ask and answer:
- What could change?
- Will a new accounting rule invalidate half of the work done on the CPQ functionality?
- Are a new set of products likely to launch that won’t fit into the designed workflow?
Make a smooth transition into the new system
Having mapped the proxy workflows and solicited input from all stakeholders impacted along those flows, another technique for ensuring a smooth transition to the new system is to identify the way the data within the system is structured and the limitations of those structures.
For example, if the QTC system is going to integrate to a billing system that uses nine-digit account numbers to identify unique customers, you don’t need to develop a unique customer identifier in the QTC system. If a product needs to be presented to a customer as a menu of feature options, then make sure the quoting and discounting functionality accommodates this presentation.
If the QTC project is managed in waterfall format4, it’s a good time to define the detailed business requirements. Even in an agile delivery, until comprehensive stakeholder requirements have been defined, only the most foundational user scenarios should be worked on. Conversely, as soon as a minimum useable system is available for testing, it makes sense to expose all stakeholders to that test system, so that they can frame and fine tune their requirements for the system architecture.
No business is going to stop the sales pipeline or product evolution because it is rolling out a QTC system. So, everything described above is going to be happening while the organization is in a state of flux. Building out capacity to incorporate these evolving conditions is vital to the success of any QTC project. And those evolving conditions will likely not disrupt the rollout if they can be shaped to match the system’s proposed design.
To seamlessly integrate into the system, it is critical to be aware of the upcoming QTC system launch and the best way to frame new products, pricing and processes. You can avoid much future rework and costly delays if you identify the source of these new requirements and constantly reinforce the structure and methodology that ensures these requirements can be easily accommodated into the new system. Using this discipline sets the groundwork for steady-state governance of the system once you have launched it.
Closely train your workforce
As soon as system functionality and user experience in the system is relatively firm, you need to focus on communications and training and ensure that all communications and training personnel view this as a series of changes to underlying business processes.
Too often, a business transformation project of this nature is packaged as a software launch -- as if the end goal is to train a user on which buttons to push. But, If the project is well-designed, the resulting user experience inside the QTC system should require very little explanation.
Get feedback from Super Users’ testing teams
Be sure to look for any non-intuitive outliers. The best source for this information comes again from the stakeholder community, who should now be converted into a team of User Acceptance Testing (UAT) Super Users5 who can perform a series of pre-defined and ad hoc use cases inside the test environment.
Their feedback should shape the resulting communications and training focus. No project, no matter how minutely detailed, is going to account for every scenario, so this is also the time to consider workarounds, and how best to communicate them as well.
When planning, think about the most logical way for different user groups to access support. War rooms are popular, but not always optimal if they are not staffed with experts in all areas of system functionality and process flow. Other options could include support cases that triage (prioritize and assign) to the appropriate team or existing collaboration tools with topic-specific help groups.
Change management isn’t an activity that happens after a QTC project has been scoped, built and delivered. It should inform the transformation inherent in the project itself, so that the change is organic to the needs of the business, and the QTC system becomes simply the tool by which those needs are met.
ABOUT THE AUTHOR
Michelle Asselin was a presenter Oct 12 during IACCM’s Americas Conference 2017 on the topic, The Importance of Change Management in Quote to Cash Deployments. She has 20 years’ experience in the legal, contract negotiation and contract management fields of the telecommunications industry. Since 2014, she has held the role of Director, Deal and Contract Management for the Enterprise Business Unit of Rogers Communications. In this role, she leads teams with accountabilities for contract systems, commercial contract management, revenue assurance, and deal governance. Michelle is based in Ottawa, Ontario where she lives with her husband and son.
- Integration and automated management of end-to-end business processes on the sell side. (Wikipedia)
- Blue sky thinking – creative ideas not influenced by traditional or current thought
- 80/20 rule: “…or many events, roughly 80% of the effects come from 20% of the causes.”
- Waterfall format – sequential, linear process
- A Super User is an end user having in-depth knowledge of workflows and software or IT applications being supported. See also: User Acceptance Testing – last phase of Super User review or testing.