Which Office 365 infographic to use when

As Office 365 has grown in complexity and feature set richness there have been many attempts to provide guidance for customers and end users. Initially these came in the form of whitepapers and eBooks of varying length – some over 100 pages. More recently we have seen the rise of the infographic with different takes and interpretations.

Looking back at historical journals my earliest recollection is the Sharegate wheel which dates back to 2015:

You can find it online here: https://en.share-gate.com/blog/what-is-in-office-365

Australian-based trainer Kirsty McGrath copied and updated the wheel with her vision:

You can find an updated version on her blog: http://www.onpointsolutions.com.au/adoption-blog/2016/11/30/office-365-isnt-it-just-office-2106-in-the-cloud

I originally referred to her wheel in my own blog which focused on the services side of Office 365. Initially when starting my independent consultancy early this year I adapted the graphic to reflect what I felt, in my opinion, to be a more accurate depiction (again, focusing on the relevant services more than what is shown in the app launcher):

Since then I’ve actually stopped using the wheel at all, more on why later.

Matt Wade has created the famous periodic table format:

Fellow MVP Patrick Guimonet created the Office 365 clamp:

I’ve also seen this decision tree:

(Unfortunately I can’t recall where I saw it, so if you know the creator please let me know so I can credit them.)

AvePoint (among others) has a fantastic comparison chart of the various front-ends:

These are all fantastic creations and efforts, and certainly help drive awareness and understanding of Office 365 for customers. The reality is that there is overlap between a number of Office 365 components – in some cases considerable overlap. For example, there are 4 tools to communicate with varying degrees of interoperability, 2 video streaming services (for now), 2 places to store files but they are surfaced in various portals and systems, different ways to interact with external parties, etc etc.

I speak specifically to this confusion amongst users in my “Groups and Teams: Friend or Foe?” presentations at Microsoft Ignite 2017 or Tech Summit Sydney 2017 (slides available online in my Slideshare but recordings were not made unfortunately).

Every organisation is the same to a point, while also unique. The same job in one organisation may work differently in another organisation of the same type. We are all the same in being unique.

My favourite books as a child were the “Choose Your Own Adventure” series as they allowed me to explore different paths – some that would end positively and some that wouldn’t.

Organisations must do the same to find what component of Office 365 suits them well and not just at an organisational level – down to the individual team and user level.

An example I sometimes refer to is the suitability of Microsoft Teams. If the marketing collateral is to be believed, then Microsoft Teams works in every situation:

The practicality for one of my clients is that it doesn’t work in their project management team (known as “Major Projects”). Why? Because they are a team purely for organisational purposes. The reality is that the members of the team are largely individual contributors who predominantly work with one internal stakeholder and an external project manager. Teams doesn’t work in this case as creating a Team for each project with only 3 members would create a considerable amount of Team/Group sprawl.

There is minimal communication between the team members within Major Projects, and for that they could use Yammer or possibly even classic tools like email coupled with Skype for Business and OneDrive for Business.

Similarly, I’ve seen a Sales team in a Microsoft partner that rarely used Yammer or Teams. They stuck to emails, phone calls, and Skype for Business when they were on a desktop (not a mobile phone). This is because again they are not a team who really work together. However, another sales team in another organisation may work completely differently. Part of this comes down to culture, and part of it comes down to using the right tool.

You could argue that more training or change management needs to be done and while this may assist, the reality is you need to find the tool that is fit for purpose.

Another example of this is Yammer – generally seen as a community tool. But what if that community wants to have ad-hoc or scheduled video meetings? Do they need to switch to Skype for Business or are they better off using Teams in the first place?

Office 365 evolves and iterates every day in some way. A component that wasn’t suitable last week is ideal this week. Before Teams supported guest access some people thought it wasn’t viable, but as soon as that feature came along a few months ago the floodgates opened for them.

So, what’s the answer?

The answer is that none of us know the answer. This is why pilot programs and champions are needed, and investment in these will result in creating the guidance you need: “what to use for my organisation, department, team and scenario”.

In the early days of Office 365 pilot programs were about ensuring the service worked sufficiently. It was about performance and user experience of the same thing they were using before. Nowadays pilot programs need to be more about determining use cases for the tools inside of Office 365, and whether they are right for certain scenarios.

Think of when a new system is rolled out to an organisation – usually it is a single product, potentially with multiple modules. At the end of the day the users generally have to only know one name. In Office 365 they have to remember a bunch of different products names, and that’s confusing enough for them.

Use infographics at your own discretion – they certainly help visualise the capabilities of the Office 365 platform. But don’t expect your users to understand them. For that you will need to map out your own Office 365 journey.

How to keep email signatures out of Teams and Yammer

While Teams and Yammer provide us a way to communicate without email, sometimes we still need to connect the conversation threads together.

Already in Teams we can surface Yammer threads, and in both products we can send emails in to become a thread in those platforms.

The problem is that when sending an email in to Teams or Yammer the entire content of the email goes across. This is most annoying when any email you create attaches an email signature – which generally occurs in Outlook be it desktop, mobile or web.

Effectively what your colleagues will see is a thread that starts with your email signature – at which point many people will stop reading as there is no context.

Using Exchange transport rules you can actually exclude email signatures from going along with your email to Yammer or Teams, however the requirement is that your signatures are applied by a cloud-based service on transit – and not by Outlook itself.

Continue reading this over at Exclaimer.