Changing RMM Software: 5 Secrets to Managed Services Success
Sometimes you need to look back to get ahead. A case in point: Clint Harder and Craig Carter — two managed services experts — recently offered some valuable insights to MSPs that are in the process of replacing their RMM (remote monitoring and management) software platforms. Here’s the insight from Harder and Carter, plus my open perspectives.
First, a little background. Harder is principal of The Corvid Group — a consulting firm that works closely with MSPs. Craig Carter is CTO of Micromenders, a highly successful MSP. Both experts spoke on a recent MSPmentor Live webcast titled RMM Software: 6 Questions to Ask. They teed up guidance that any MSP can use to anticipate, plan, and execute a remote monitoring and management (RMM) tool change.
In my previous post, we excerpted the six stumbling blocks that spur MSPs to make a change in their RMM platform. So once you’ve decided to make a change—what next? Here’s some great direction from Harder and Carter to see the tool change through to increased operational effectiveness.
1. Cross-functional Input is Key
Fundamentally, the decision to switch RMM platforms must be a business driven one, but one that’s closely aligned with technical requirements and realities. Further, sales, marketing, finance, and technical teams need to be involved early on in the selection of a new platform. For example, sales and marketing can provide critical insights up front: Where are we losing opportunities? How do we eliminate a perceived weakness? Choose a team that will own the tool selection—and make sure the team includes representatives from each of the key business units.
2. Lock Down the Criteria
Up front, you need to decide on key criteria and objectives, as well as price point. It doesn’t do any good to have engineers research tools and come back with recommendations the business isn’t able to afford.
You need to get buy in on what the five or six key criteria are—and keep to that list. Too often, folks will stay silent when it comes to providing input for the purchase criteria, but then start adding requirements at a later date. Do whatever you can to ensure that criteria and objectives don’t start changing midstream.
3. Selecting the Right Tool
- ITIL and process alignment. Regardless of where your business is in the spectrum of ITIL adoption, the fact is that your team will have already invested a lot of time and effort in developing its existing processes and workflows. It’s critical to ensure any RMM platform works with your processes, rather than forcing you to realign workflows to suit the platform.
- Integration. How does the RMM platform get integrated with other tools? For example, can monitoring alerts automatically open in your help desk or incident management tool? If engineers close out an alert, can that update be reflected in the CMDB, so they don’t have to make the update twice?
- Comprehensive, emerging technology and service support. You need to evaluate a solution with one eye on today’s needs, and one eye on the long term. Things change, and the broader service and technology support an RMM platform may provide, the fewer the potential roadblocks it may present down the road.
4. Picking the Right Vendor Partner
- Strong, viable business. Clearly, the longevity of a platform is tied to the longevity of the business that supports it. How many customers and employees does the vendor have now vs. two years ago? Look at the list of customers they have. Are they able to point to companies in your segment? Are their customers recognizable and successful?
- MSP alignment. Given the growth in the market, it’s no surprise a lot of vendors are looking to sell to MSPs. The fundamental question is, do they really deliver value to an MSP business? Early on, ask questions like, “How does your pricing model align with how I make money?” They should understand your organization, and speak intelligently to how their business model aligns with yours.
5. Measuring Success with the New Tool
- Key performance indicators. Some of this is just basic blocking and tackling: understanding what metrics you’re trying to improve, establishing baselines with the old platform, and measuring the delta over time. Think about business indicators, rather than technical. Can we improve gross margin by 5%? Look at your key labor ratios. For example if you do server support, how many servers can one engineer support, and how does that number change?
- Measure holistically. Don’t focus solely on the numbers, at the expense of the bigger picture. While some metrics will lend themselves to a balance sheet analysis, other may be more difficult to quantify, but demonstrate value nevertheless. Can we change hiring criteria of engineers because of the reduction in manual coding?
- Timeframes. Try to devise a realistic timeframe for when the investment will pay for itself, and track those numbers. Look to recoup your investment in 6-12 months, and if you don’t, make sure you determine why.
Those are five solid pieces of advice. But did we miss any steps or considerations? I’m all ears.