Most software projects fail in some critical way, from scope creep and poor communication to end-user adoption reluctance and higher costs, no matter how much the financial investment. The reality of any IT rollout is that only around 16% of deployments are completed on time and within budget.
Since we started Proton, we’ve witnessed and worked with hundreds of distribution company executives as they grapple with software implementations. Over time, a pattern showed us a handful of critical elements that distinguished successful software rollouts from those that fell short.
It’s important to clarify: the fault doesn’t always lie with the distributors. In many cases, they just need more guidance from their software vendor. A good vendor isn’t just a provider but a partner, guiding customers through their journey to ensure a successful implementation.
Today, we’re sharing some of the things we’ve learned to help those about to embark on an implementation journey.
The Need for a C-Level Stakeholder Champion
We’ve seen first-hand that companies need a C-level stakeholder who prioritizes and champions software implementation. Their buy-in isn’t just desirable, it’s necessary for success.
Choosing this stakeholder is a strategic decision. This stakeholder must be influential enough to set the tone for the software deployment as an organizational priority. Their involvement can shape the attitudes of those who report to them. Executives wield influence, and their priorities set the course for the company. When they champion a new software, it sends a powerful message throughout the organization: This tool matters.
Problems occur when C-level stakeholders are excluded from software purchasing decisions. While the intention might be to save them time, it can unintentionally sideline essential leadership from an initiative that needs their support to thrive.
Bringing in a C-suite champion prevents a common pitfall — investing in software not in tune with the executive’s vision and organizational mission. It’s critical to have alignment between executive priorities and the software rollout. Ultimately, it’s better to walk away from a software purchase than to invest in one that’s not aligned with the organization’s direction.
The Essential Role of a Mid-Level Day-to-Day Owner
With an executive champion in place, it’s time to shift focus to the ground level. Mid-level owners, often a sales or operations manager, are key players in driving software adoption and ensuring success with the new tool. These folks are best suited to translate the software’s capabilities into day-to-day processes. This person needs to deeply invest in the problem the software is solving. That means dedicating significant time — often upwards of three hours daily in the first few months — to driving adoption.
At Proton, we’ve seen how mid-level managers who care deeply about the problems the software solves often helm the most successful software implementations. They see its potential, understand how the tool works, and can rally their teams around it. Their commitment is contagious, and it becomes a catalyst for broader team engagement.
The mid-level manager holds users accountable for adopting the software. Accountability isn’t about policing — it’s about support and encouragement. It involves tracking usage, identifying patterns, and addressing challenges. The manager recognizes the end-users who actively embrace the software and extends additional support to those struggling.
Here are some of the tasks required of these mid-level implementation advocates. They must:
- Become subject matter experts (SMEs) on the new software: This implementation advocate should be excited and on board with RTFM (read the factory manual). They should know the tool inside and out and be available quickly to troubleshoot any issues with the team. Often, this person operates in the middle ground between the software vendor and the on-the-ground corporate team. Instead of sending these users directly to the software vendor’s support every time, the mid-level stakeholder commits to knowing the software expertly so they can answer questions quickly and set the tone for the rest of the team.
- Define what you want your team to do in the software: It’s not enough to tell your team there’s a new tool, throw them a login, and expect results. You must tell users exactly how you want them to use the software versus leaving it open-ended.
Let’s define what it means to do this poorly versus well.
Poorly: “I’d encourage you to use the tool whenever you have free time.”
Good: “Block off the first 30 minutes of your day. From 9 to 10 am, you’ll spend one hour prospecting inside of Proton. You’re going to open the screen that shows your accounts, filter the ones that are ‘at-risk,’ and call them. You will log what you’ve spoken to the customer about and pitch at least two new products on every call.”
There are huge benefits to this hands-on approach. It is specific, actionable, and trackable. It’s something a user can get behind. It prevents overwhelm and ambiguity inside the application.
- Track end-user performance inside the new software: If you want something to work, you need a way to measure it. If you can’t measure it, you can’t improve it. In a new software implementation, the mid-level manager must have a way to gauge the tool’s usage and the desired user behavior. For example, say you’re implementing a tool to help customer service reps upsell more customers. The behavior you’re trying to drive might be the number of customers the rep tries to upsell per day or the percentage of calls where they pitch a new product. Whatever the metric is — you should measure it. The outcome you’re trying to drive is probably the dollar value attributed to those pitches. You should measure that, too. At the start of the implementation, you’ll want to measure these metrics weekly. As your team builds muscle memory with the tool, you can switch to bi-weekly and monthly. Look closely at:
- Overall performance against prior activities
- Team performance
- Individual performance
Sometimes 80% of the results will be driven by 20% of your users. Make sure the success is spread evenly across your teams and users. Ask yourself what that 20% is doing to make themselves so successful. Then replicate the success of these power users and find ways to engage low-usage users.
- Drive user engagement: The manager’s mission is to drive user engagement in the software tool. But you can’t drive usage without measuring it first. Otherwise, how will you know what’s working?
Managers can drive software usage through:
- Regular training: Don’t train 1,000 users at once. It’s best to do this in smaller groups so people can ask questions and get assistance. Remember, the mid-level manager is an internal expert and go-to team resource. They should foster an environment where asking questions and seeking help is encouraged. Training should be a regular workflow to ensure employees stay up-to-date on software use.
- Office hours: One of the things we see in our most successful implementations is managers running weekly office hours. Promoting an open forum for users to join and ask questions is critical to the success of your deployment on the ground.
- Celebrating highly engaged users: You can keep the deployment positive by rewarding the wins. It also allows you to stretch your SME pool by turning these early adopters into relatable champions for the software. These end-users should be encouraged to share their success stories with the rest of the team. It’s both a motivator to continue using the tool and a signal to others that they’re missing out on something that could make their jobs easier, faster, and more productive. You should also celebrate milestones and successes associated with software use to create a positive association with the tool.
Keep Your Goals — and Adoption — Front and Center
We recommend tying software adoption to tangible outcomes and keeping goals and adoption highly visible. Frontline managers should consistently communicate and set expectations around how and why their teams are measured and incentivized. Set SMART (specific, measurable, attainable, realistic, and time-based) goals around usage. For example, a tangible goal a manager set for their outside sales team after implementing Proton.ai was to pitch three new products to 10 customers per week.
Build these goals into performance reviews so employees can understand how using the software impacts their evaluations or compensation.
Once the goals are set, send out weekly scorecards to the entire team, showing who hit their goals for that week and who didn’t.
Managers also need to be held accountable for their teams’ goals. A weekly scorecard sent out to the entire manager group makes it easy to see which teams are hitting their goals and which fall short.
Commit, Then Phase the Roll Out
What we don’t recommend is internally positioning a new software technology as a pilot or trial. That makes it sound like a “flavor of the month” and something not worth committing to because it won’t be around for long. Instead, conduct due diligence and then commit to the tool. Communicate that commitment (“We’ve signed on for a two-year implementation for X software.”). Then create an implementation strategy for a phased rollout.
A phased rollout carves up implementation in manageable chunks with measurable results at each phase. It answers the question: How do you eat an elephant? One bite at a time. A phased roll-out gives everyone the time to learn and adjust workflows as this big new change happens. The phases must include training and measurement but also the development of new workflows as the tool ripples across the organization. In the past, we’ve seen organizations take on big bang adoption, or a simultaneous implementation of new software across departments. A phased adoption, organized logically, allows time to work out kinks as end-users adjust to new workflows and learn new features.
Pro tip: Kick off your software implementation by running a three-month SPIFF, a short-term sales incentive, based on usage to get the sales reps in the habit of and excited to use the tool.
Some of the fun contests we’ve seen include:
- Pizza party for everyone who hits their weekly goal
- Tickets to a sports event for the most active user
- Extra vacation days for users with the most activities related to the desired action
During the three-month SPIFF period, sales reps will experience their own successes with the software. These wins will make them realize the software’s benefits without needing extra enticement post-SPIFF.
Proton is software designed to modernize how you sell. It is the only AI-driven software on the market specifically geared toward helping distributors grow their businesses. Organizations that roll out Proton with our proven implementation processes see ROI in as little as three months. If your organization wants to sell more, the tool puts powerful analytics and automation into the hands of your reps to help them achieve greater revenues, faster.
Distributors who follow these best practices for tech rollouts and change management – and invest into their software deployment beyond dollars – will be more successful. A good vendor will be more than just a provider; they’ll be your partner in software implementation and also act as a consultant to guide you through the process.
To see the possibilities of Proton, request a demo today.