Jumping in the Pool – Just get started!

One of the key principles that I like to teach clients, especially when it comes to a huge digital transformation or migration into Office 365, is the concept of ‘jumping in the pool’.

Jumping in the pool is all about enabling your business to try on technologies to understand how you can use them in the future – you can’t start to swim until you’re in the pool.

So, let’s see how this works – you’re moving to Office 365, and you’ve heard of something called Microsoft Teams. You want to enable collaboration in your business but you’ve no real idea what the collaboration is going to look like, meaning when you come to a migration piece, it’s often the case of knowing you need to move the data into a new structure, into the new tool but until your team starts to actually use the tool you haven’t really got a clear idea of what it should look like. It’s a complete chicken and egg situation!

The process of adopting a new technology is a massive opportunity to restructure your data and consider how teams work together collaboratively. If this is missed and a simple left to right migration occurs, then the tools aren’t really being leveraged in a way that’s going to provide the most benefit to the organisation.

To adopt technologies such as Microsoft Teams where collaboration is not just about the document or the conversation but collaboratively a combination of the two technologies cannot easily be experienced on the current data. So, the question becomes how do we address this in a migration piece of work?

Well, the easiest way to get adoption is to allow people to play with the tools, understanding how the tooling works with both the document and the collaboration piece. Trying to design an information architecture without understanding how users are going to adapt to the new tooling is impossible, so our premise is always to jump in the pool first.

One common mistake is to spend too long before jumping in to define exactly what the new world will look like, it’s a bit like asking your teams to understand how they will use a Tesla without even discussing them how to charge it, when to charge it and what distances you can go on a single charge. Too many assumptions will be made, and swiftly proven invalid once the technology is in place, this usually results in a post migration restructure 6 months later when the business understands what it’s doing. So don’t delay, jump in.

What does jumping in the pool look like?  Jumping in the pool is the concept around setting up a minimal information architecture structure that allows the business to move from one platform to the other but isn’t rigid, structured or standardised across the board yet. What this does is it enables the business to start adopting and using the technology in a way that makes sense to them. By jumping into the technology and having the space provisioned for documents to be put in place and for conversations to happen with the right team members, including thinking through who the right team members would be and what the scenarios would be for data and conversation in each team, is all a business really needs to have to get started.

Having got that base structure in place, work with the organisation, team by team, understanding how they are using their data. Once all teams have had a chance to use the technology, we have found that they get into it and self-organise their data in a way that work best for the team. Then supplement this with a follow up training session and support around how they use their data, showing more tips and tricks to improve their usage of that data before then completing the major migration into the platform in a way that suits their method of adoption.

Users often find their own feet, their own way of working as a team and we normally find that across the business there is a massive need to standardise how each team works. This usually doesn’t bring more effectiveness into the business if implemented right at the start, it develops roadblocks in both knowledge and habits around “this is what I was told to do” that is always a best fit for each team.

Allowing teams to create their own structure, in their own space that works for them individually is a huge benefit of the team’s infrastructure. Revisiting this with them later to make sure that they are getting the best use of the tools is also helpful. We often find that skill gaps occur by just handing over, so following up and making sure that that all tools are being used correctly and that they have remembered more advanced features rather than just the basic features is a huge plus and can help them in day-to-day life.

It’s also important to give users the tools to be able to self-serve. Once you’re convinced that the users have understood the technology and how to collaborate with each other, it’s important to allow them the ability to create their own teams. Normally we will disable team creation from the get-go until the users understand the technology.  This is simply to prevent Teams sprawl.

Giving the ability to request a new team with governance tooling, using a flow or allowing teams creation (with a governance structure around naming etc of course) is valuable. Using a Teams Governance tool like Casper365 (shameless plug for my own tech) we’ve found that businesses will turn off group creation and put an approval process on the creation of a team, allowing a centre of excellence body to make sure that we’re not creating teams that already exist. This then prevents Teams sprawl.

It is also key to manage the creation of multiple one to one team creations between a manager and their team. Using Teams for direct report management is the wrong tool for the job and will lead to a swathe of unused Teams to tidy up later. This is a OneDrive piece of work and having a centre of excellence that can spot these requests for any new team sites coming through and act upon them by contacting the requestor and advising the correct technology to prevent this in the future can be a real benefit to any organisation.

Governance is a bit of a dirty word and is associated with policing. However, it’s not policing, its guiding, its helping users understand and keep in mind what the tooling is for, and which tool is the best to use. Using a pillar diagram to show how the business is going to use their data, the kind of segregation between and examples of how to use OneDrive, Microsoft Teams, SharePoint and any additions like Yammer or other tooling is a great idea and helps users to understand which technology to use.

So, what did we achieve? Well, jumping in the pool allowed the users to play with the technology before it became fundamentally part of their working life. With guidance, we then showed them how to swim in the pool but using their own strokes, their own method and adapting that to the technology to make sure that we’re leveraging the best benefit out of the technology and the businesses on the cloud.