Need a Use Case for a Teams Proof of Concept?
I recently had the pleasure of working with a multi-tenanted client that made a wise decision and wanted to start their Teams journey with a proof of concept (PoC). They were interested in doing a PoC before potentially rolling out a full implementation.
What problem should they attack for this PoC?
Before we started the workshops, we met with the leaders who had contacted us. He advised us of how the organisation was structured and even provided us with a problem that we could use for the PoC. We proceeded with the Teams workshops, where we introduced what Teams can do and how it addressed the problem. What we soon found out was what one department thought was a good idea the others had already implemented it or didn’t have the same issue. This was not the heartfelt problem that would make a good test case for the Teams PoC.
As well as this misaligned problem, there was a plethora of blocking questions that would have stopped any implementation.
- How does MS Teams fit into the rest of the applications?
- Who can create Teams?
- How do we stop 100s of Teams being built?
- Where do documents get saved, what happens to them after the project has finished?
- What is the process…?
I am sure you get the picture.
Use Case for a Teams Proof of concept – The lightbulb moment!
It hit from the corner of the table. A lone voice said, “why don’t we collaborate on the governance rules that we are talking about now”. Insert light bulb here. Eureka, you could see from the faces in the room and the silence that there was something in what was just said.
Imagine a team working with Teams to work on the governing rules that would guide the implementation and use of MS Teams throughout the organisation. As they used the application they could see what it did (and didn’t). They could make decisions based not only on reference material but on real life.
Advising the organisation that the rules were created from people from across the distributed sections and teams, (L&D, Project Office, Doc control and IT) and that this team used MS Teams to collaborate would make adoption so much easier. A great success story to use for the whole of organisation roll out.
The PoC ticked many boxes: cross tenant membership, cross organisational collaboration, multiple disciplines, different languages and time zones, and it was what people could get. There weren’t too many things that this group would have varied to the teams that would eventually be using MS Teams.
How creation started
The sponsor of the PoC created a charter with objectives for each channel and the roles and responsibilities for the individual channel lead.
The channels were created, and the staff were empowered to build the materials for their channels. More staff were added to the team to get greater buy-in and knowledge. Things started to happen; questions were being raised, conversations were happening. Then like a flick of a switch the Teams conversations stalled. Did they have face to face meetings? Were conversations happening outside of the Teams? Within a couple of days, we went from delight to dead.
Well, this is nothing out of the ordinary for most project or collaborative work. People have their day to day jobs to contend with on top of the activities asked of them by the new team. The good news is that the sponsor was also aware of the situation and set up a team meeting to discuss the work being carried out.
Being a good community manager, he kept the momentum going; he didn’t want his Teams to dissolve. He was quite active not only within Teams but also generating discussions with others outside of the original group. These new members gave the teams a jolt of enthusiasm just when it was needed. It wasn’t that the original team stopped, it was merely more hands make for lighter work.
The channels covered many aspects of what you should understand before starting to use MS Teams. If you can appreciate the potential questions and address them in some form, then you are ready to embark on the MS Teams journey. The channels discussed the topics of naming conventions, workflows, how to request a new MS Team. Reduce site duplications, the life cycle of Teams and the artefacts, archiving, what to do, what NOT to do, ongoing training & support.
Getting clear on naming conventions
The naming conventions document was the first to be uploaded into MS Teams. We saw by the conversation around the paper that it was well received. Not that many organisations have multi-tenant, but with this organisation, it was too easy to create Teams with a name and have another division under their tenant with the same name. Duplications would make things very confusing for users if they were members of two or more Teams with the same name. This problem was the higher priority deliverable, and they did well to get this up and running early.
What started as a standard PoC task of solving a specific problem turned into a rewarding journey with some significant deliverables. If you cannot think of a problem to solve in your journey of discovery using Teams or another collaborative tool, try addressing the governance challenge.