Keys to Transitioning to a Cloud Service Effectively

There are many moving parts in a collaboration solution transition. I outlined the top-level issues here and tackled the network challenges here. In this article, I discuss the steps of the transition process itself.

 

Since collaboration services are such an integral part of users’ daily work, the transition process for large organizations need to be carefully orchestrated – problems with using a new service will cause immediate frustration. This directly impacts the adoption rate for the service and also impacts the transition period. If multiple solutions are operating during the transition, this adds complexity and cost for the IT team and the enterprise, diminishing ROI. The goal is to minimize the time-to-value by moving users and rooms rapidly and smoothly to the new solution.

 

Preparation is key. Ensure you have the needed capabilities and support structures operational before jumping into a Beta test, so user impact can be minimized. Before going to Beta testing, ensure these items are fully vetted and lab-tested:

In most IT situations, we transition small or large blocks of the organization at different times, thus spreading out the burst of support needed for new users of the service. Often, this isn’t possible with a collaboration solution because the old approach and new approach aren’t compatible.

 

Scheduling is a classic example of this. If we are using solution A to schedule collaboration conference rooms, and we wish to move to solution B, we must move all users across the organization to using solution B at the same time. If we don’t, users may try to schedule the same room on solution A and solution B for the same timeslot, and it will become double-booked. The same challenge occurs if laptop or mobile users need a new client to support the new solution. The big value of a collaboration solution is that we can collaborate across the organization, so isolating user groups runs counter to our goals.

 

From a deployment support approach, however, there are huge advantages to transitioning smaller groups, both to help manage the support load and to allow IT to find and fix issues that arise without making the entire user group experience those problems. Where it is possible, I highly recommend transitioning a portion of the user base or portions of the solution.

 

Portions of a solution like the scheduling platform, video conferencing rooms, and special user groups (for example, a top executive group) are candidates for transitioning independently.

 

If video rooms are transitioned independently from end users, there will need to be an interim approach to integrating end-users into meetings that include rooms. If this can be supported easily by either the old or new vendor, or if you manage those room-based calls with a video network operating center (VNOC) either in-house or with a managed services vendor, a process can be put in place to support this split transition. Avoid the scenario where users must do something different either at the point of scheduling or call initiation, as we don’t want to have to train them twice.

 

Likewise, transitioning executives separately may be possible if their calls are highly managed either by a VNOC or by their executive administrators. Be warned: Training executive administrators twice is also not something you want to do.

 

End users can be transitioned as a group once the full solution is ready. Some organizations will have a subset of users that largely communicate within the group, either because of the business structure or a geographic or language difference that naturally causes the division. I have found in numerous organizations that Latin America or South American teams are often avid users of video collaboration and tend to operate as a group due to cultural and language differences. But there will still be cross-group collaboration requirements that can’t be ignored.

 

An organic transition is also possible for end-users. Once the management and scheduling solutions are in place, users can move to the new capability as they see fit, through a registration process or a client download. If the solution is attractive, and especially if management is actively using the service, users will move relatively quickly over time to jump on board. The schedule may not be as fast as your ROI demands, and de-commissioning the old solution may take longer with this approach, but it will reduce the anxiety of users who don’t want to be pushed onto an unfamiliar solution.

 

A proof of concept (PoC) test is important to validate your chosen solution works as advertised, but also to identify key changes that will be required in your enterprise and the impact of those changes. You don’t know what you don’t know until you try it.

 

Validate key technical capabilities important to your organization that your vendor has promised will work. Compatibility with your current equipment, conference sizes, scheduling methodologies, integrations, scale, management interfaces, automation, and other functions might be important to verify. Identify these items and build a test plan to ensure each is tested.

 

As a part of this testing, determine how responsive your vendor is to support needs. Try to engage with the vendor’s support team rather than their technical sales team, so you can experience the service team’s skills and responsiveness.

 

Keep track of firewall changes required to make your new solution work. PoC testing is often done in a lab environment, so the team can make quick changes and get the solution working rapidly. In this lab setting, firewall changes might not be carefully tracked. Use a process that will capture all the details of the needed firewall changes, so they can be reviewed with your security team for conformance with corporate standards.

 

Also, during the PoC track the availability of the service, especially if you are testing features new to your provider. Are these features ready for production deployment?

 

Use the PoC to identify changes that will be required in your enterprise processes. Consider how users and rooms will be enabled and licensed, how this integrates with your active directory, how much work this will entail, and how this management can be automated. Consider how usage tracking can be done, especially if you are considering cost-sharing the service among departments or businesses in your enterprise. Does the service provide sufficient detail to make those allocations?

 

What about service desk support? How will users reach out to your team or to your vendor’s team to get the support that they need when they are unable to schedule, initiate, or participate in a call? How much training is required for your current help desk to give them the knowledge they need to support your users? Will you need to share tickets with your vendor, and can that ticket-sharing be automated?

 

Beta testing differs from PoC in two important ways. First, Beta testing is done on the production network with the production firewalls. Secondly, some level of scaling is important, meaning that you need to provide a sufficient load to the service provider and the surrounding processes needed to support your users. This will determine if they can meet the demand when the volume scales up.

 

Beta testing can be challenging if you are trying to move users from old to new technology, as there may not be compatibility between systems. Choose a group that primarily collaborates within the group (e.g., a department, or a geographic area with a common language). This will help minimize the cross-group collaboration requirements and allow the Beta team to be successful.

 

During the Beta testing, we are looking for the issues that didn’t appear in the PoC because we had insufficient scale. Examples might be laptops with insufficient power or older OS software that is incompatible with the new solution. Headsets and speakerphones are another area with integration challenges, especially if users are using their headset on multiple applications and switching from one to the next. The compatibility of room systems was probably tested during the PoC, but there may be a few older systems or systems from an untested vendor that folks are still using. There also maybe use cases or features that teams have come to rely on but aren’t available in the new solution or complex to replicate. And there will be more. If we could predict them all, we would have solved them before this stage. This step is to find unaddressed issues and get them resolved before rolling out the solution to the whole company.

 

As the transition gets underway, understand that you don’t know what you don’t know, and the transition process will certainly find those issues for you. Knowing that issues will arise, put in place a check-in process for users and for the support team, so problems can be identified early and resolved quickly. This approach looks a lot like an agile development process with frequent meetings, identification of issues, prioritization based on the number of users (or rank of users) impacted, and assignments of these issue to be resolved by the next time period (e.g., 24-hours).

 

Analytics are key to ensuring progress is being made, and issues aren’t stalling. A Kanban board is a useful tool. With this board, you can keep all the topics listed and also identify which ones can wait and which ones need immediate attention. Giving a team the top 25 priorities usually means no tasks get done, so tackle the top three and then look at it again a day later.

 

Use this same process to identify how many tickets are opened, closed, or outstanding per the period, and how long each ticket has been open. Plot this data over time, and use it to determine when more support resources are needed, and when they can be reassigned because the problem set is dropping off as the system matures and the users accommodate it. Track user adoption in parallel to ensure the drop in support calls isn’t matched by a drop in usage.

 

A well planned and supported transition will pay back large dividends measured in adoption rate, increased employee productivity, reduced time-to-value, a shorter ROI for the solution, and positive visibility for the proactive IT team that made it happen.

---

Looking to avoid other team collaboration pitfalls? Then, check out this session at Enterprise Connect! Register today with code NOJITTER to save $200 off the current rate. Early bird rates end Friday!