In this series of blog posts I want to share how we implemented Microsoft Teams for collaboration. It's been a while since it was delivered (summer 2018), but I think there is still value in sharing. Up until now, I haven't seen any blogs or case studies sharing anything similar. The end results (with the necessary custom development) are still making me happy and proud, and I hope that it might inspire people.
In this first post, let's start with some context on how all this came to be.
About 1,5 years ago (summer 2017) I started working as a consultant on a new project. The company, a multinational, ran an existing SharePoint 2013 environment for both collaboration and communication.
I joined an ongoing process of moving the collaboration part from SharePoint 2013 into SharePoint Online/Office 365. The architecture had been discussed for months already, based on existing best practices and was almost finalized. This meant doing a setup of a classic site collection per division/department and subsites for projects.
Just to sketch the timing, at this moment:
- Modern team sites were announced 1 year before
- SharePoint Framework (SPFx) was GA'd 6 months before
- Microsoft Teams was about 5 months old
- Modern communication sites were in process of being rolled out to our tenants
- Hub sites were not a thing yet
One of my first tasks (after getting up to speed) was onboarding the first department into Office 365, so I called some key users from the business in a meeting room to discuss how we would approach this. Two things became very clear, very fast:
- these business users were never consulted on designing the "new" collaboration approach (IT was the driving force)
- these business users didn't like what I was proposing, saying "this is not how we work"
A lot of work was already done before I joined the team and, for that moment in time, it was a solid and proven architecture. So we spent the next 2 months collecting feedback, adjusting the plan and returning to the users. Rinse and repeat.
Sadly, we never got it right.
So we decided to start over, putting the user requirements first and trying to adapt the requirements of the the IT department. Together we set the following goals and scope for the new collaboration environment:
- It should improve collaboration, not stand in the way of effectively working together
- It should require no extensive manual or training
- It should be empowering users, without administrative burden or any other friction
- It should be focused on working together for projects, with a start and an end date
- It should limit context-switching, keeping everything together
- It should scale to 25 000 users
- It should limit duplication of workspaces
- It should have good discoverability of workspaces
- It should allow working with external people
- It should not increase the workload of the Service Desk
- It should provide monitoring for the administrators of the platform
That's when we decided that we would go in a completely different direction and went with Microsoft Teams. A young product, with a lot of potential and an active product team, but also a very immature (at the time) development model.What could possibly go wrong?
As it turned out, a lot of it did actually go wrong, and next posts will show the result and the issues we had to deal with.
This post is part of the series Automate governance in Microsoft Teams:
- Context and Goals [this post]
- The Result
- Implementation, v1
- Implementation, v2
- Reporting
- Improvements and Wishes