5 Tips for a Successful Microsoft Teams Deployment

Guest Blog by Tamsin Deutrom-Yue, Managing Director at Support to Win

4
5-tips-successful-Microsoft-Teams-Support-to-win
Collaboration

Published: June 29, 2020

Guest Blogger

MS Teams has emerged as a highly popular choice for enterprise deployment in the wake of pandemic lockdown, and we see many organisations in a hurry to implement Teams-driven solutions.

Going fast is achievable, even for larger organisations, but our experience highlights that the most commonly encountered sticking points relate to the integration of core telephony features from a separate PBX. The lessons learned are instructive to businesses of all sizes embarking down this route.

So if you’re planning an implementation of MS Teams in your business, be mindful of the following 5 best practices used on big projects in order to avoid project overruns and ensure business continuity.

1 – Gain Full Visibility Of Current State

Having accurate, up-to-date information on the current telephony setup is crucial to enabling a smooth lift and shift. A solid understanding of the telephony configuration from old to new prepares you for the complexity of the transition and any issues arising that require workarounds e.g. identifying where Teams may need to deliver certain services in a slightly different way.

With little or no access to this data, it takes longer to get to order provisioning as potentially it means starting from scratch. And all that could need buy-in from each Head of Department, and will take time to gather, validate and implement.

ACTION: Conduct a thorough audit to capture and cleanse current information. This is also a great opportunity to ‘spring clean’ services and challenge what needs to be carried across. Specialist software can be used to automate rapid, accurate data collection without requiring onsite access.

2 – Clarify the Dividing Lines Between Telephony PBX and Teams PBX

In all instances of direct routing from our experience of large deployments, the breakout from MS Teams is provided by a separate PBX with its own features and functions. There needs to be a decision made before implementation as to which PBX will be controlling these features.

Voicemail is a simple example ­– either Teams or a separate platform can manage this depending on which VM the customer wants to use and manage moving forwards. What’s important is to ensure that features from the telephony PBX do not conflict with the features in Teams, and vice versa. There are likely to be features currently unsupported by Teams which will need to be managed by the telephony PBX.

Some customers use Teams as the soft client only and everything is managed through the telephony PBX. This is simpler, but requires adjustments to the default configuration in Teams.

ACTION: Don’t begin without making these decisions first. Consider the needs of different worker styles and how these user groups can be supported going forward. Ensure information is properly documented to enable future service handovers and starters/leavers provisioning. Do you need to maintain two platforms? How does this affect BCDR plans?

3 – Scope All Technology Refresh Dependencies

Migrating to MS Teams is typically part of a larger wider technology refresh project within the business. You need to fully understand the drivers for this migration and what dependencies are interlinked.

For example, a move to Teams telephony may have a dependency on a Microsoft Dynamics implementation. If there are any delays with that rollout, or upgrades required to get that moved forwards, how does that affect the Teams project?

ACTION: Get to grips with the wider context for the Teams project. Beware of too many minor implementation projects that could confusion among users as each week they are forced to adapt their way of working with the introduction of new features. Get progress moving faster by showing internal stakeholders the impact of unwarranted disruption on project delivery targets.

4 – Prepare to Absorb Change Mid-Project

Staged rollouts are inevitable, especially in larger organisations that are dependent upon buy-in from each department to agree parameters, communicate the change and facilitate training. If any steps are missed, it has a snowball effect down the line to each department thereafter.

At some stage you will need to ‘freeze’ the data driving the project, but how you manage this is incredibly important especially over a rollout that may take months. A large business will have starters and leavers on a weekly basis, for example, so consider how to manage that churn over time, what change processes are required and how to audit this at the end of each phase.

ACTION: Accept that staged rollouts are necessary and prepare to accommodate change during the project lifecycle. Plan for how users in the new state contact those in the old state seamlessly between two technologies. Look for automated processes and establish a single place where admins can manage starters, leavers and new requests. All that should changes for the end user is their endpoint – but accomplished that takes smart processes and systems integrations.

 5 – Determine Clear Ownership of Third-Party System Integrations

Something commonly overlooked when moving to MS Teams is interoperability with existing third-party suppliers (for functions such as WFM, payments, auto attendant, etc.). It is very important to decide if those third-parties are intended to provide the same services in both the old and new ‘world’.

Often you will need to upgrade to new technology to ensure service continuity – or even seek new supplier relationships to get the requisite functionality –­ but this always comes with a cost which needs to be understood and evaluated upfront against the cost of the project. Sometimes, underlying infrastructure needs to be upgraded too (i.e. not just a service upgrade), forcing project costs and timelines to be completely reworked.

ACTION: Ensure the project is properly costed by considering all third-party dependencies, including the ownership of supplier relationships. Invariably, the communication and management of the third party is owned by the customer organisation, but the entire project team needs to be mindful of responsibilities between all stakeholders of the solution being delivered.

 

Guest Blog by Tamsin Deutrom-Yue, Managing Director at Support to Win

 

BlogMicrosoft Teams
Featured

Share This Post