The RevOps Show

Episode 43: What to Expect When You're Expecting a CRM Implementation Part 5 - To Pilot or Not to Pilot

Written by Hannah Rose | Jan 4, 2023 4:00:00 PM

Happy New Year everyone! We hope you were able to spend time relaxing and recharging for the new year. I know that’s what Doug and Jess had in mind - to do absolutely nothing for a few days. Today we’re finishing off our series on What to Expect When You’re Expecting a CRM Implementation. Before we get into it, Jess did make it back from Disney and the weather was beautiful and there was Christmas everywhere. 

The day this episode was filmed was also Festivus and Doug wanted to air grievances the entire episode, but alas that couldn’t happen because we have a series to finish!

Audio:


Video:

 

Additional Resources:

Show Notes:

To pilot or not to pilot. That is the question. Let’s start with the challenge with CRM implementation and why people want a pilot versus why they should pilot.

The challenge of implementing a new CRM so tightly wound to the idea of “piloting” or the idea of “let’s start small” is that they’re two sides of the same coin.

To Jess, people want a pilot because it gives them a security blanket. Everyone is terrified to launch and to ship, so piloting enables you to dip a toe in the water. It’s lower risk, so you can put in a small group and see how things are actually going to work. Where people get piloting wrong is they’re expecting the pilot to be like a full launch. Most people don’t look at it from a learning experience, so they put in a small group of people thinking everything is going to be totally smooth when the larger group goes in. 

Doug points out that when the conversation is real and that we’ve talked to clients about being afraid to ship or launch, the issue actually comes way before that. Doug thinks people like the idea of piloting, but most people don’t use it properly.

If you’re launching a new CRM, it’s a risky experience and the reason it’s risky has very little to do with the actual tech. The risk is all about change management. This comes up at the moment of choice; it’s the decision mode. What piloting does is it should be something that allows you to test a concept, very similar to proof of concept. It allows you to test, enables you to build a business case, is a learning signal so you can make better decisions, and reduces your risk. Piloting is a risk mitigation strategy.

The thing to keep in mind about piloting and starting small then expanding is that they aren’t the same thing. If you want to start small, you’re really trying to reduce spend. It’s not an actual piloting strategy. You have to be really clear on what you are piloting, what the purpose is and what it is you’re testing. It’s a controlled experiment. You have to ask yourself, what are you going to learn from the pilot? There’s a lot of reasons that piloting increases the risk because it increases the likelihood of failure.

Why does piloting increase the likelihood of failure?

We’ve had multiple people say, “if this isn’t successful, my job’s on the line,” and “we’re going to the board, we’re asking for a significant investment. If this doesn’t work, we’re in trouble.” We look at this and ask how we’re going to deal with the resistance to change. If this has to be successful, piloting can make it feel unsuccessful. We infer that the status quo is low risk, but if you pilot to see if your status quo is correct, that can actually increase the likelihood of failure because what if the status quo isn’t correct?

Should you go to a new CRM platform? What’s the reason for change? Is that reason clear? What piloting is doing is it’s testing, do we want to change? How long is the test? By the way, does change management have a better chance of being successful when an entire organization is moving to the place or if a small part is moving? That’s why you have to be really clear on what it is that you’re piloting. 

A pilot is based on the idea that the status quo is not causing harm. If the status quo is causing harm, then everyday you aren’t changing, things are getting worse. Doug refers to it as a vertical mindset to the process. You can’t pilot a sales process transformation. You can pilot a change to the first conversation. You can pilot marketing stuff much more easily than something like email automation. One of the problems with testing in the pilot A/B model is that it’s a form of A/B testing. You’re only testing one element, so if that’s valuable, great. But if you’re talking about changing your sales approach or platform, you can’t do that vertically (with changing one element at a time).

You can’t really pilot change management, especially with sales. Think of it this way. If someone says they want to pilot sales development, how long is it going to take for us to know if that is going to work? To do that, the first thing we need to know is how long the sales cycle is. Then you have to look at how long it’s going to take to get a meeting. To know the outcome here, it’ll take you between 12 and 15 months, notwithstanding that you have to learn things along the way. This isn’t a good idea or use or piloting. You’re going to learn some things faster with piloting, but it’s going to take you longer to allow for full learning. 

Piloting is an investment because you have to run support on multiple systems. One of the big risks, especially when it comes to sales teams, is it fragments your focus. When people want to pilot the CRM, you have to ask whether the CRM can do what it needs to do. If you’re “piloting” the CRM, you have to clearly define sub-process optimization because that’s part of a business process. The other thing when piloting is that you can’t really pilot from anarchy to structured. Piloting works when you’re coming from a clearly defined system. If your process is clear and you aren’t really looking to change much about your process management, you can pilot that because your systems are in place. You’re just dipping your toe in the water. There is no such thing as an easy implementation because if it were easy, everyone would be doing it. It wouldn’t be risky. There’s risk in everything that you do. You need a critical mass when piloting. If you pilot with a 30 person sales team out of 5,000 people, you aren’t going to learn a lot from that. You’ll learn a lot from a 500 person team.

What does it look like if you don’t pilot? What’s the approach if you’re not going to pilot?

Doug thinks always be piloting is how you do it. All jokes aside, piloting is a day one focus. What he means by that is that piloting is a launch and it’s complete. You’re testing in iterations and using your learnings to test more iterations. That’s why you should be launching your CRM 2, 3, or even 4 times per year. Every pilot is feeding into the next pilot. It’s what Doug refers to as the simple and complete approach.

What we’ve found is that when change management is key, viewing things horizontally tends to be more powerful than viewing things vertically. You’re really looking at it through the lens of solving for certain jobs across the organization and across the people that are impacted. You don’t want to have two versions of the truth. This approach says we’re going to take one, two, or three months to configure and then we’re going to launch and it’s going to be a one, two, or three month launch. This is not a pilot. There’s nothing that creates more friction and makes an implementation heavier than when some people are using this and other people are using that. There’s an element that says “Hey, let’s get over here as quickly as possible.” What you’re doing with a simple and complete approach is you’re looking to increase your velocity. The way that you increase velocity is figuring out what isn’t going to work. The downside is that this requires more attention upfront.

Doug isn’t anti-piloting, there are places where he’s a firm believer in piloting, but in most cases when we’re talking about a full CRM implementation, a simple and complete approach does require a greater capability in the underlying design.

More often what is happening is that the technology is leading the business process and the business process isn’t leading the technology. When this happens you can’t learn anything.

Jess’s Takeaways: 

  • Clearly define what you’re going to learn from the pilot.
  • If the status quo is okay, that’s when you pilot.
  • The biggest thing is that pilots rollout constantly. We get people referring to a rollout as a pilot and they are not the same thing.

Next Steps: 
View full post