Taming Teams: Starting Right

2019 is likely to be known as a year when many larger organizations began a methodical, stepwise transition of users to Microsoft Teams for both collaboration and communications.

 

In this new “Taming Teams” series of articles, I sort through the confusion, decode the messaging, decipher the meaning, and separate the reality from the marketing fluff with the ultimate goal of helping you best leverage Teams to deliver quantifiable business improvement.

1. Defining your expectations. Are you deploying Teams as a new collaborative chat tool or intending to transition to Teams as both your primary communications and collaboration tool? How will you measure the success of your introduction of or transition to Teams? Are you expecting a reduction in email volumes, cost savings, increased user satisfaction, or speed to task completion? Do you expect adoption to happen over a specific period?
2. Understanding what leadership is expecting. Sadly, you could possibly succeed technically with a transition to Teams but fail politically. You could drive rapid adoption and deliver great end-user satisfaction, but if your boss (or your boss’s boss) expected cost savings instead, then you wouldn’t receive the expected accolades. Beyond measurable organizational success criteria, make sure you understand the specific expectations of your leadership related to budget and timelines.
3. Planning for and testing interoperability. Both Skype for Business and Teams provide chat, presence, calling, and meetings. While Teams works with Skype for Business, you’ll have a choice of multiple interoperability strategies, each with strengths and weaknesses. Additionally, the interoperability capabilities have been changing and evolving over time, especially related to how external participants join meetings and channels (federation versus guest access). Testing and understanding your selected interoperability approach in a lab environment before introducing Teams is critical so that you can support the situation where large groups of users only have Skype for Business, only have Teams, or have both.
4. Piloting Teams first with “techies” and then with the business. Get your IT staffers to use Teams by letting them (making them!) use it first. IT professionals are generally happy to experiment with new technologies, although with Teams we’ve seen some pushback from current Skype for Business groups in some larger enterprises. Once your IT support staff has gained familiarity, pilot your draft rollout communications, training, and technical deployment of Teams with a targeted group of business users.
5. Surveying pilot users and refining based on the results. Survey your pilot business users related to your communications and training. Was it too little, too much, clear, confusing? Was training provided in the right format at the right time? Was Teams easier than expected, harder? What did they find easy? What did they find hard? What didn’t work for them? Was the interoperability strategy well explained and did it work as expected? Gather testimonial quotes. Also gather support desk tickets from the pilot users. Then analyze the less favorable results and discuss how to modify your rollout process to address the problem spots.
6. Helping users understand what to expect and when. Equipped with feedback and refinements from your initial business pilot, ensure you clearly communicate the “why” and “what’s in it for me” related to your Teams rollout. Don’t assume yet another application is necessarily going to be welcomed or embraced by all business users -- tell them how Teams will improve their days; sell it!
7. Measuring, considering, and acting on the results. As you roll out Teams to more user groups, regularly measure and compare results with defined project objectives. Are you achieving anticipated adoption, user satisfaction, cost savings, and support ticket volumes? If yes proceed. If no, modify your technical, communications, or training approaches as required.