Are you responsible for managing remote devices?
Do you need to improve remote device visibility?
Improve issue alerting?
Automate issue resolution?

You likely need remote device management (RDM). But what kind?

If you're looking to manage IT infrastructure (computers, servers, etc.) or connected products (kiosks, security systems, digital signage, etc), you're going to want remote monitoring and management software (RMM).

With RMM, organizations reduce downtime and improve the end-user (employee, customer, etc.) experience. But to fully realize the benefits of remote device management, there are several key steps your organization will need to take to properly deploy and implement the tool.

The implementation timeline for a RMM tool can vary depending on various factors, including the organization's size, the complexity of the infrastructure, and the specific requirements of the deployment. On average, it takes three to six months to go from selecting an RMM tool to realizing its value through a positive impact on device uptime. In this post, we outline a step-by-step guide for what a comprehensive implementation process looks like and how much time and effort your organizations should expect to spend to realize the full value of RMM technology. 

Note that this guide is most applicable to RMM for connected products.

Step 1: Define Clear Implementation Success Criteria

2–3 weeks

Before you can determine how long it will take your organization to implement a new RMM tool, you must decide what will be the measure of implementation completion for your business and the project requirements. 

You should define success criteria based on business needs by identifying current gaps that are most severely impacting uptime and availability (See our research on Overcoming Downtime).

Once you have these gaps identified, you should set achievable uptime improvement goals based on your knowledge of your device, deployment model, technical functionality, etc. Typically, organizations measure improvements by tracking the number of self-healing automations run, the improvement in uptime percentage, and reports on fleet-wide performance. 

Your progress towards these goals relative to your historical performance benchmarks will be how your team measures realized value and, ultimately, the success of the implementation. As a result, setting the right benchmarks for performance success is a critical step and should have cross-functional team alignment. This step may take a few weeks to complete due to varying opinions

Step 2: Determine Your Deployment Strategy

1–5 days

Early in the RMM tool implementation process, you should understand how you will deploy the RMM agent to your devices — or in the case of an agent-less deployment, how you will update your devices to ensure they can communicate with the RMM enterprise. 

The deployment mechanism should dictate how you choose to “go live” with your new RMM software. For example, if you have no way to remotely deploy updates to your devices, then you will need to rely on field dispatches to deploy your RMM, and this will heavily impact your deployment timeline. Dispatches are costly, so some companies choose to deploy new software during scheduled maintenance visits to reduce the cost of dispatching technicians. Keeping this in consideration will allow you to feel comfortable with a possible longer deployment timeline.

If you do have a way to remotely update your devices, then the RMM deployment process and timeline will be very fast. However, having the necessary conversations with key stakeholders across engineering, support, and product is still key to account for any considerations or process delays. Typically, it takes a few days to have these conversations and define your deployment strategy.

Step 3: Evaluate Existing Tools/Scripts

1–2 weeks

Many companies select an RMM Tool after years of operating and growing their business when they outgrow their current tooling, or as requirements change. As a result, it is common to have an established set of actions, tasks, and/or scripts that are being leveraged by existing support processes and teams. It is important to consider the cascading impact on those core remote management processes due to the introduction of a new tool. 

Your team should take time to review and migrate existing scripts and align them with the selected RMM. As part of this review, you should consider where there may be duplicated functionality that can be removed for cost and complexity reduction. This step can often be completed in parallel with other activities and may take a week or two.

Step 4: Gap Analysis in Monitoring Data

1–3 weeks

Commonly, companies determine that to properly monitor and manage remotely, they need better visibility of the hardware or software functionality of their devices. Without understanding the state of things like a user-facing application or the health status of a critical hardware/network component, properly tracking and assessing availability becomes very difficult. 

Often, custom software development is needed to expose hardware components or software application status data for the RMM enterprise to be able to ingest the data. Some RMM tools, like Canopy, allow companies to send data directly to the agent residing on the device or to the RMM Enterprise in the form of an event. These events should contain key status information that you need to know; and that informs the enterprise to drive a calculation, generate an alert, trigger an automated action, etc. 

If you can only determine if the software application is running but not if it is functioning properly (i.e., can end-users interact), then you should update your gap analysis to include the development work required to surface that application data. 

In the case of hardware and network-based components, it may be necessary for the application to publish the hardware state, as it is already integrated with the hardware peripherals. In other cases, leveraging built-in Leaf Services functionality like device connection monitoring or SNMP/ICMP polling for network devices can be sufficient for determining if all critical components are available.

Identifying gaps in monitoring data and defining engineering needs, including potential software development to enhance visibility, is a critical process to getting the full value out of an RMM platform. This is an iterative process that will likely incorporate feedback from multiple technical and support SMEs and may initially take one to two weeks.

‍

‍

Step 5: Lab and Pilot Testing

2–4 weeks

Once high-level success criteria have been set for your RMM tool implementation, you can move forward with lab tests or deployments on live pilot devices, involving adjustments to applications and scripts. Ideally, you’re able to work closely with the RMM vendor's implementation or customer support teams to ensure proper installation, configuration, and data flow. 

This phase, lasting two to four weeks, involves reviewing firewall policies and addressing considerations revealed during field testing. The iterative process allows for natural growth in implementation scope as you learn more about how to collect status data and any potential impacts on device performance from the RMM monitoring agent. 

Consider deferring some of the less critical aspects of the testing process to a later "Phase 2" of the deployment if needed. For example, in the case of Canopy's RMM platform, many customers first use the deploy files feature to get the agent on devices en masse and then later follow up with enhancements in data collection and remote actions.

‍

Step 6: Data Analysis and KPI Development

2–3 weeks

During the pilot deployment phase, focus on identifying data for custom health status Key Performance Indicators (KPIs) to measure device availability and uptime accurately. For a standard deployment, you should anticipate creating three to four custom KPIs, which let your support and engineering teams know if the device is healthy and available.

The data or statuses reported back to the enterprise will vary based on the complexity of monitored devices. This phase aligns with lab testing and pilot deployment, aiming to solidify a core set of KPIs for precise availability calculation before full rollout.

Allocate two to three weeks for the identification, development, and testing of initial KPIs involving customer teams and the RMM provider. This timeframe allows for comprehensive adjustments and refinements as needed.

‍

Step 7: Train Your Support Team

4–8 weeks, in parallel

Training is crucial in implementing any tool, especially when considering the company's size and structure. The number of support levels (e.g., L1-L3) or departments (e.g., Product, Support, & Engineering) that will be actively using the RMM tool significantly influences the training timelines and processes. 

Typically, a specific business area initiates and owns the RMM tool implementation and should become the primary focus for initial training. For instance, if there is a knowledge gap in deploying software updates via the RMM, the team responsible for that function should take the lead in RMM platform training. Once this has been covered, training typically cascades into Support, Management, and other relevant departments, depending on the device type.

Adopting a "train the trainer" model typically involves four to eight weeks of weekly meetings with active RMM tool users. This period allows users to become acquainted with the tool, provide feedback, and engage in Q&A sessions. This iterative approach ensures ongoing learning and proficiency development, making the RMM Tool an integral part of the company's operations.

‍

Step 8: Smart Alerting and Automated Resolution

4–8 weeks, in parallel

Once data collection, KPI calculation, script migration, and remote action development are in progress, the next phase involves actively responding to the received data and implementing automated actions where applicable. This phase, like others in the process, typically extends over time and involves iterative adjustments. This extended timeframe reflects the natural evolution of your RMM tool's functionality over the course of the deployment lifecycle and business growth.

Like the pilot process, starting with a small set of basic smart alerts for issues requiring onsite resolution, such as offline devices or hardware/network faults, is the best place to start when first learning how to build automations in an RMM platform. Testing these alerts lets you see the expected ticket volume, allowing you to ensure usability when alert volume becomes challenging to manage.

In scenarios where software applications can be monitored and managed, prioritizing automations that address issues like frozen apps, memory crashes, or space constraints should be an early focus. This proactive stance helps prevent unnecessary alerts for issues that can be automated through remote actions.

The process of reviewing and creating RMM automations typically initiates during the pilot phase and extends through the training phase, gradually evolving into an ongoing practice. During these phases, dedicating a few weeks to focus on this area is anticipated as part of the comprehensive RMM Tool implementation journey.

‍

Step 9: Monitoring Analytics and Reporting

1–2 days, recurring

As you continue using the platform over weeks or months, various business areas become aware of the implemented changes. Naturally, you'll develop a need for daily, weekly, or monthly reporting to assess performance trends on deployed devices. Leveraging Analytics becomes crucial to evaluating the overall impact of your RMM implementation, such as improved uptime due to automated actions and enhanced real-time issue visibility for faster response.

Many RMM platforms, like Canopy, offer a standard set of reports and analytic dashboards out of the box. However, as you input more custom device data into the platform, there is often a need for creating custom reports and dashboards to reflect that data in the way that your business operates. This requirement may be recognized early in the process when addressing known gaps with the introduction of an RMM tool, or it may naturally evolve during the ongoing utilization of a solution that effectively aggregates your data. It’s important to consider whether custom dashboards will be important for your organization, as it is a less common feature with most RMMs.

Allocate a few days during the measurement and evaluation phases, a few weeks during the pilot or go-live stages, and an additional week or two a few months post full deployment to delve into and refine your reporting needs. This iterative process ensures that your reporting capabilities align with the evolving requirements of your RMM tool implementation.

‍

‍

Conclusion

Achieving complete RMM implementation success will take time, and organizations should plan for a three-to-six-month timeframe to comprehensively go from tool selection to realizing tangible benefits and improved device uptime. 

A well-suited RMM tool should be at the core of daily device management and as a result, will require time to fully integrate into your technology stack and organizational support processes. It's not just an accessory but a crucial component for company success. As a result, when considering an RMM tool for implementation, you should factor in commitment from your product, support, and engineering teams to ensure your company's success with the product.