By
Launch new software tools for your team confidently by covering every important stakeholder. Learn about the different categories of stakeholders and why their participation is critical, then download a helpful template to collect stakeholder information and share it with your team.
There is a moment.
You know that moment? It exists in the space between receiving the budget approval for your new CPQ solution and what comes next. That is a great moment. All your hard work finally pays off. Maybe you gathered recommendations, spoke to vendor references, assessed the budget, and developed an ROI. You prepared presentations. You pre-wired meetings. You honed your pitch. You convinced the budget owners that this is a priority and now is the time. Congratulations! What comes next? Next is the moment when you realize that it’s on you. Your effort has only begun. You made commitments. Your vendor made commitments. You promised that the new software would yield benefits for the firm and now it’s on you to make sure it happens.
There comes another moment. It can play out one of two ways:
Confident launch
It’s launch day. You are ready.
You have a plan and the team is prepared to execute.
You are confident that the new software will deliver on the commitments you made. Your firm will reap the benefits and the project will be a success.
You are so ready.
Or…
Anxious launch
It’s launch day. You are anxious.
You have a deadline. You are not sure if the project is done, but it’s due. It’s good enough. Right?
You review the promises made by the vendor. Your boss just reminded you of the promises you made. Everyone is ready to get on with it. It’s time to launch. You have tested the software. It works, but will it deliver?
You are so anxious.
Importance of stakeholders
So what is the difference between having a confident launch and an anxious launch? One thing that can guarantee an anxious launch is to overlook important stakeholders. You can launch a tool that works as described, but without deeply engaging your stakeholders, you will struggle to get benefits. Identify and communicate with everyone who has skin in the game.
Achieving real benefits is critical to the successful launch of a new tool, especially in the tool-crowded sales systems space. Users need reasons to learn something new and change the way they work. Benefits like a faster, easier, more reliable, and lower error-rate workflow matter. To gain these benefits, you must go beyond software that works as advertised. The firm needs to change in specific ways to gain the benefits.
Achieving benefits from new technology
Dr. Eliyahu Goldratt, the author of the business classic The Goal, father of the Theory of Constraints and arguably modern development methods like agile, said that “technology can bring benefits, if and only if it diminishes a limitation.” Getting rid of a limitation is the reason you buy the software. Consider the limitation to be anything that prevents or diminishes the ability of your system to achieve its objective.
A CPQ solution, especially one that includes CLM (contract lifecycle management), client collaboration, and other features that reduce deal-making effort can create many benefits. The benefits you gain from technology, like reduced costs, improved throughput, more efficient operations, or easier quoting in the case of CPQ, are byproducts of diminishing some root cause limitation. We consider the central limitation to running a commercial process without CPQ to be the inability to follow a designed CPQ workflow. Even if the process exists on paper and users try to follow it, there are too many components and too many people involved to properly follow the process without software.
CPQ can diminish this limitation, but a functioning tool is insufficient. Technology “can” bring benefits, but does not necessarily bring benefits. Behavior also must change to diminish the limitation and achieve the benefits. Firms facing limitations develop accommodations for them; rules they follow to work around the limitation. In this case, some accommodating rules might be:
- “Always go to Sharepoint to get the latest quoting template before creating a quote”
- “Email your manager for discount approval”
- “The manager probably has a similar, email your manager for discount approval under certain conditions”
- “A senior manager reviews every quote”
- “Make sure to increment the document version on the Word document every time you make or resolve redlines”
Rules can be explicit or implicit. You may not even consider them rules, rather, just modes of operation or the way we do this thing around here. When I write about rules, I am including those implicit rules that we follow out of tradition, social pressure, or habit as well.
Because we require new behavior to gain the benefits of our new technology, we need new rules. Our new rules replace our accommodating rules. The new rules might be:
- “Sales pros use the new software to follow a guided selling algorithm to produce consistent, accurate quotes”
- “Approvers and contributors all work with the same document in the new system in real time”
- “Many approvals are automated using logic in the system, so managers no longer review quotes that meet specified criteria”
If this happens, the firm gains the benefits of sales pros following a carefully designed approval process. Customers get their quotes faster, approvals can be easily audited, the process generates fewer errors, and prevents unauthorized discounts, language, and terms which can harm the firm. Benefits.
Not having stakeholders on board can prevent you from changing the rules. If stakeholders don’t buy in, their behavior may not change. Here are some reasons stakeholders could become hold-outs and prevent the firm from gaining benefits:
- They do not understand the new software
- They do not know about the new software
- They had needs that the new software does not address
- The software has problems you did not anticipate, but your stakeholders would have
- They feel excluded from a process that is central to their area of responsibility
This is why it is critical to cover your bases with stakeholders as early as you can in the process, before you select software and through project planning and implementation. Getting stakeholders involved early is the best way to make sure you are in position to change the rules when you launch your new software.
Working with stakeholders
Develop a consistent practice for discovering your stakeholders, interviewing them, and documenting what you learned in the process.
Stakeholder discovery
Not every stakeholder is obvious so make discovery a carefully considered first step. Anyone with skin in the game is a stakeholder. It’s important to include users, administrators, and approvers for a CPQ implementation, but there are others to include. Pay special attention to any stakeholders who make or manage policy. You will find these stakeholders in finance, accounting, billing, legal, contracts, IT, and product management. If you miss these policy stakeholders, changing the rules will be nearly impossible.
Seek out people who provide inputs to the process you are automating and people who will consume the outputs. As with any software, get your IT team involved early. They may have to vet your choice for security, compatibility, and other concerns. Remember that systems like CPQ exist in a context of other systems and the value you get from it is highly dependent on integrations. The owners of these integrated systems, like the CRM or the ERP, will need to make changes to accommodate the software.
Stakeholder interviews and surveys
Make a plan and interview your stakeholders. You can do this in person or through a survey. In a survey, create plenty of room for feedback you did not request. Plan to follow up with stakeholders who do not participate. You will need their input to make a good implementation and their support to change the rules.
Ask them about their important user stories. For example, a product manager might say “As a product manager, I need to review the discounts we include on quotes where we end up winning and losing the deal.” That’s the story. “Ideally, I would receive a report monthly by the 5th so I can review it with my team in the monthly discount review meeting.” That is the acceptance criteria.
Publish stakeholder assets
Publish stakeholder assets and share them broadly with your stakeholders. Ask them to agree or make comments. This will serve as your permission to change the rules.
Writing forces you to think critically and publishing these assets will give you four important advantages. First, when you commit your thoughts to paper, knowing that others will read them, you are more likely to carefully think them through. Second, producing these documents will help you master the content so you are always prepared to discuss the issues of the project in depth, with anyone you encounter. Third, sharing these documents with your stakeholders will cause others to think critically and contribute more thoughtfully. Finally, these documents will serve as the foundation of your project plan. Filling out a project canvas will be a breeze with these assets in hand.
Here is an essential list of stakeholder assets to publish:
- Interview reports
- User stories with acceptance criteria
- Investment premise
Interview reports - Capture everything you learn from stakeholder interviews by publishing interview reports. Record the sessions if you like. Some meeting platforms will even take notes that you can convert into content for your report. Publishing interview reports gives each stakeholder the opportunity to correct the report and will allow you to share what you learned with other stakeholders so they can collaborate with each other on issues that affect them collectively.
User stories and acceptance criteria - Publishing user stories and acceptance criteria for your stakeholders allows stakeholders to see their own requests in the context of others. In addition to being a great way to get your stakeholders on board, you will be in a strong position when it comes time for UAT and QA the software with a list of stories ready to test.
Investment premise - The essentials for our purpose are the following:
- The power of the software
- The limitation diminished by the software
- The accommodating rules
- The new rules (that unleash benefits)
The power of the software is the benefits of the software as described by the vendor. Make sure you include the most important benefits you expect the firm to derive from using the new software. Include a brief description of the key limitation you expect to diminish by implementing the software. Make explicit the rules your firm follows to accommodate the limitation. Then write a summary of the new rules the firm can follow to unlock the benefits of the new software.
The investment premise can be a significant document that you develop to secure the investment. We build an investment premise for new projects, tying financial results to the benefits we expect to achieve along with KPIs we track to confirm or disprove each premise.
With people, go slow to go fast
Launch with confidence. Discovering your stakeholders, interviewing them carefully and publishing the results to share with all interested parties is a great way to secure a restful night before you launch your new CPQ platform. When people are involved, slow is fast. Take a beat early in the process to listen to a wide variety of people with different relationships to your plan.
Stakeholders are the source of your solid plan
Antonio Nieto-Rodriguez, a project management expert and the author of the HBR Project Management Handbook places stakeholders at the center of the project canvas, for good reason. The people who use the new system, who contribute inputs to it, who receive outputs from it, who govern risk and other policies related to it, will determine whether or not your company follows new rules that unlock the benefits of your new system.
Some templates to help you get started
Click the button below to download your stakeholder template so you can publish a document to share with your entire team and keep everyone on the same page.
