While Doug contemplates how he’s going to get through a week without Jess, Jess is eager to get to Disney. But she’s got a little more RevOps work to get through before she can fly out. Part of that was recording this episode. And yes we are still talking about what to expect when you’re expecting a CRM implementation - specifically how long an implementation should take.
How long should a CRM implementation take?
5-7 days. At least that’s how it feels sometimes when Jess looks at the project scope. To Jess an implementation should take as long as it should take. In other words it depends on what your configuration is.
We have to look at what has an impact on timing. Think about team size, whether there are already processes in place, which hubs (for HubSpot) are being implemented. Is there an integration involved? What does the data migration look like?
Going down a bit of a rabbit hole, what’s the difference between a customer and a native integration? In Jess’s words, a native integration is and out of the box integration. You don’t need to know code to do it and you don’t have to program it. To Doug a native integration is a pre-existing integration.
What is the volume effect? If you’re seat based, how many seats? If it’s a marketing product, then how many contacts and what’s your volume of activity? We could implement a CRM in five days. It is possible. Here’s the danger of missing complexity. The way that you simple down, you look at it on average. Doug was listening to a book called The Neuroscience of You and it was talking about brains. The person got into the problem and she discovered quickly as she was doing research that the way we define the brain being left sided and right sided was wrong. Not wrong in the sense of what it was, but the fact that no brain was like that. When you’re talking about something as dynamic as sales and marketing, average is always wrong. Another way to look at it is if you have one foot in a boiling hot pot of water and another in an ice bucket, on average I’m probably okay. I’m in a lot of pain and if I stay too long I’m going to lose my feet.
When you go to averages, it never actually works. Why do I use it? This goes back to the Inverse Complexity Principle. The ease or effortlessness of a user’s experience has an inverse relationship to the complexity of the design. In Part 5 (yes, another part is coming - to pilot or not to pilot), one of the things we think about when we think simple are piloting ideas and things that come from taking a vertical slice of something. When you do something like marketing automation, you can do that, but if you’re talking about building a source of truth it has to be complete. The way you can shrink your time to implementation is by slicing horizontally. The difficulty is most people want to slice vertically so they want to focus on creating something where everything gets logged correctly. That’s easy, but no one will use it.
An example of slicing horizontally: You’re going to focus on just prospecting. You could say that you’re just going to focus on managing the active sale, but you still have to look at everything. When you go horizontally across, the job to be done by the people that are doing it, you find that there’s a place where there isn’t enough juice for the squeeze. The other thing that happens with a lot of systems is if you’re not testing it right, you have to make sure that you’re coming through. The best example Doug has is when he coached baseball, he could always tell when someone knew the game versus someone who didn’t. The person who knows the game, when they’re looking at someone who’s hitting, they diagnose from the bottom up. If you don’t know the game, you diagnose from the head town.
Horizontally it’s all about the foundation and then layering on top of that. What are you coming from? Where are you going (size complexity)? The third area is breadth - what functions are we covering? What’s the underlying data structure?
We had a recent implementation that was a bit complex and that is how Jess framed it to the point of contact, so when the sales reps launched the system, it was far less disruptive because everyone expected it to be bumpy. When those items are communicated up front, people are far more satisfied with it because they had a heads up going in. One of the things that gets in the way is if you aren’t taking that horizontal function to be accomplished, you end up emphasizing the wrong things that slow you down.
One place where this happens is with integrations. If you’re coming from nothing or coming from a non-integrated system, Doug isn’t saying not to integrate. He’s saying that if the integration is going to slow you down, then it does make sense. When you build an integration, there’s an element that really locks you in. You find out that your data structure isn’t right.
If you break up different elements, that’s how you can shorten time to implementation. Remember, you’re going to launch this every quarter, every period, every half year. Your CRM isn’t a one and done thing. It’s progress and roll, progress and roll, etc.
What Doug has found is if you go more than about a third of the project timeline from the roadmap being locked in, you’re going to at least double the effort required to get to full launch/full implementation. You’re going to have an impact, but it’s going to take at least twice the effort and you’re going to get half the result. This is because as time flows, you can’t help but find other things to focus on.
The question you all have been waiting for - how long should an implementation take?
Jess says 12 to 16 weeks. If you go back to episode one where we talked about different types of implementations, we are talking here about a full new implementation. Doug would say three months is where you start. There are situations where it could take less and there are situations where it could take more.
Doug would say 13 to 17 weeks because 12 weeks is not three months.
If you want to bring costs down, you can go longer, though Doug cautions doing this because the longer you go the more at risk you are to lose momentum. You can also go shorter, but it’s going to cost more.
You’re also going to have a higher cost on you because you’re going to need to think through everything and turn things around faster. You’re taking away the margin for adjustment. Why can’t we go faster? Why can’t we start using this three or four weeks in? Because, to Jess, it’ll wreak havoc. And that’s because you don’t want to be punished and you want everything to be easy. The reality is there is going to be frustration on all sides because it’s all new. And to people that are used to doing things the way they’ve done them, the juice isn’t worth the squeeze.
What you’re doing is bringing people into your alpha, and everyone says “but Doug, just do an MVP.” Who are you looking to attract with a new product? Early adopters. Early adopters like chaos and want to be involved up front because they want to have tremendous influence on what’s going on. Because you sign up for something in alpha, you know there are going to be bumps in the road. How does that work for your salesperson? It doesn’t.
To sum it all up, 13 to 17 weeks is the normal for a CRM implementation, but if you start seeing it go to 26, 27, or 28 weeks and above, which is very possible, then what you need to do is break that into two launches.
It is unwise to take too long, but it is worse to take not enough.
Follow Jess, Doug & Imagine on socials for updates on the show or other insights:
Doug Davidoff: Twitter - @dougdavidoff | LinkedIn
Jess Cardenas: Twitter - @JessDCardenas | LinkedIn
Imagine Business Development: Twitter - @DemandCreator | LinkedIn
Subscribe to the show on Spotify & Apple Podcasts
Check out Let's Play RevOps on Twitch for more commentary on this topic