#1 Reason G Suite Deployments FAIL!

Video Transcription:

"This week I want to talk about the number one reason that G Suite deployments fail.

Okay, so let's get started. This week I wanted to talk about the number one reason that we found that your G Suite, or Google Rollout, is going to fail. If you don't want to watch the rest of the video, the answer is change management. The challenge for a lot of organisations is that they think of a G Suite deployment as a technical rollout, similar to that of replacing a server because it's replacing the email system within their organisation. And so for them, they feel that it's extremely similar. When it comes to a transformational project like implementing G Suite, it's important to take it out of the technical. Yes, the technology is important, but what people forget about is the process and the people.

And the magic happens in the middle of those three things. So, just thinking about change management for a moment. And thinking about the reasons that organisations generally depend G Suite. It's very often part of a larger project. Maybe a digital transformation project, or an innovation project, or something where they want to increase collaboration and innovation across the organisation.

When I say change management, what do I mean? Well, for a G Suite deployment, change management can be broken down into four key areas. S-C-O-T, or SCOT. The S is for sponsorship. C is for communication. O is for organisational analysis. And T is for training. Let's dive into these four areas in more detail now.

So, the first area is sponsorship, and having executive sponsorship for a project that's impacting people within your organisation is vital. It's important for a couple of reasons. Firstly, it's useful to have someone on the executive team that is a champion for your project. They can ensure that there are key resources and people available so that your project can be a success. However, you don't just want to have one executive sponsor. It's actually very useful in a Google deployment to building out a stakeholder map ofthe organisationss, and ensuring that you actually have sponsorship across key different areas within the business that are important to ensure the success of your project.

If you don't have executive sponsorship for your project, it is very unlikely to be successful. And I would recommend that most organisations, companies, IT teams, or Google partners, don't proceed with a Google project until they have this sponsorship.

Another area within sponsorship is an innovation council, or innovation team. And this is generally the group of people who've been part of the deployment, and they very often will go on to be the team, the business transformation team, within the organisation that continues and beds down the processes that you're training the employees on when it comes to G Suite.

The next area is actually organisational analysis. I'm swapping the C and the O, because organisational analysis comes next. Once you've got that executive sponsorship, it's really important to analysis the organisation or business that you're rolling G Suite out to. If you're internal within the business and you work in the IT team, you may already be aware of the company culture. If you're an external Google partner, then it would be ideal to have some conversations with the IT team, but also outside of the IT team, with different people and different business units, to try and get an idea of company culture.

Google often say that you should interview people to try and get an idea of the project and how they feel about it, what concerns people might have. I find a lot of Google partners can be quite negative towards the term interview. I really think of it as having conversations. That's all that you're doing. You're talking to people within the business to get an idea of what they feel, or how they think about this particular project. Are there concerns or apprehensions that they have about this change that is about to happen within their organisation?

And then the other is surveys. Surveys are very valuable. Now, depending on how the survey is done, it will have a different impact. So, if you ask for people's information, like who is filling out the survey, you're going to get a different response than if you leave it anonymous. There are pros and cons to each approach, and I would really take it on a case by case basis. If you're doing an extremely large deployment, surveys can be very valuable that are anonymous, and just getting a finger on the pulse of how the organisation feels. If it's a small deployment of maybe only a few hundred users, then maybe having a more personalised approach would be valuable, because you could reach out to individual users and maybe help them with some of the challenges that they have.

Within the organisational analysis piece, you very often find out what are the change impact. Change impacts are very important and an often ignored part of a Google deployment. Change impacts are essentially areas within an employee's day to day job that is being changed by this migration or this move to a new product.

Now, very often, these change impacts will be the same across most of the organisation, but for some particular business units, there will be very, very specific change impacts. For example, a support team within the organisation may have a different change impact compared to a PA or compared to an executive. And it's important to look at the changes that are happening based on the tool that you're implementing, and that you put in place the training and the supports and resources for the users within those business units.

The final area within organisational analysis is success criteria and metrics. It's really important to identify what these are, what success looks like for you, before you actually start your project. And make sure that these are agreed upon, not just with the IT team if you're a Google partner, but also with the executive sponsors, because you don't want to be arguing about whether the project was successful afterwards because you haven't decided what success looks like.

The next area is communication. And this is a vital part of any project. You need to communicate to the end users when is it happening? What's happening? And for a Google deployment, it's no different. For your communication, it's really important to get your elevator pitch right. Your elevator pitch is just like your 60 seconds about the project, why the organisation is moving to G Suite, when is it happening, how are you going about it. And it's important to agree this and write it down so that the rest of the team know what it is, and you have consistency across your communication channels.

The next area is your marketing channels, and it's really important to diversify your marketing channels. You don't just want to have one way of communicating with people. They're definitely going to ignore that email, so having the executive sponsor send out the first email is really, really important to announce the project. But also, coordinating your communication as well. So, we would try to have posters go up. If you're going to do a video, have the video go out from the CEO. Very useful in large organisations, or large roll outs. Having the email from the executive sponsor or CEO go out. And having all of that happen at the same time. That's very, very valuable, because it shows this rush of communication information.

People are much more likely to take a look at the email if they've also seen the poster and seen the announcement in the staff meeting, and gotten the video from the CEO. You've not just got the different forms of channels, but you're actually getting people excited about this project. This is a digital transformation project, where we're taking it out of IT, and we're making sure that end users realise that this is not just an IT project, but a digital transformation project.

So, I want to cover a quick tip for the communications section. When doing up a Google poster, there are four key elements that we include. The first is a little blurb on G Suite and the project, the elevator pitch. Sort of telling people what's happening, and why it's happening. That's what most users want to know. The next is when is it happening, what is the go live date for the project? So, when can people expect to be on this new system? The third is training. Users want to know when they're being trained, if they're being trained, what resources are being dedicated to them? And the final one is data. We come across so many employees that don't realise that their email and calendar and documents are being migrated by the IT team. They think that it's maybe something they're going to have to do themselves, or that the information won't be brought across onto the new system. It's really important in the communication to ensure that you cover this. You want to answer the question before they ask it.

Another great tip is creating a strong FAQ. So, there will be users within the organisation who won't feel that they can ask particular questions, or will just never get the change to, or feel that they have the opportunity to. The final area is training. And training is really, really important. I find that there are many organisations that feel that maybe training isn't necessary, particularly with Gmail. They'll say things like, "But everybody already has a Gmail account." Or, "Everybody already knows how to use Gmail, they have one at home."

And that's true, but what you need to remember is that the training isn't really to train people on how to compose an email in Gmail, or send an email, they're the simple things that probably people will figure out, or already know. But they haven't used Gmail, or G Suite in a business environment, and that is really what the training is about. It's about helping users map those business processes that they do every single day in Microsoft Outlook, or Lotus Notes, into the G Suite environment. And helping them with that transition, because if you don't, you're going to get a lot of negativity from the end users who maybe are going to find this transition a challenge.

In terms of my tips around training, I would ensure that you organise and book in training early. And this just ensures that you're going to have the best turnout for your training, and therefore the most success when you go live. Decide what type of training you're going to do. Are you going to train everybody within the organisation? Are you going to do a train the trainer, or Google guides program? The Google guide program is highly recommended, particularly for large deployments, where maybe it's not possible to train everybody within the organisation.

The Google guide program is where you have people who have been trained to a higher level in different business units across the organisation. And also making these people identifiable on go live day is also extremely valuable. I would also recommend diversifying the training that you provide. We would very often do a webinar, or a live event. We would then do in person training for certain teams. And we would also have a training site. And this would be common in most of the deployments that we do. Employees learn in different ways, and it's useful to provide different resources and different ways of learning.

The next area is business transformation. It's not part of the standard change management piece, but it is an important tool that you can use to get users excited about the change that's coming within the organisation. Now, transformation labs are usually the best way to do this. Inspiration, discovery, prototyping, and then iteration. The inspiration piece is showing the team how other organisations have changed their business processes using this particular workshop.

The second piece is discovery, and this is where employees will actually brainstorm out their particular processes. And the workshop is very interactive. In fact, most of it people are up on their feet and filling these things out on post-it notes, and brainstorming on whiteboards, and things like that. And it's often the first time that people have gotten the change to look at all the business processes within their organisation, so they very often get very excited about it.

The next stage is prototyping. And this is where you look at how Google and G Suite and the entire Google platform could potentially benefit these particular business processes, and maybe increase collaboration, or increase efficiency, or remove steps in the particular process that you're looking at. It ensures that the organisation is leveraging the most value from the investment that they've made in the Google platform.

I hope you enjoyed this week's update on the number one reason why G Suite deployments fail, and what you can do to ensure that your project is a success. My last tip, which probably isn't going to surprise you, is that you should engage a Google partner, even if it's not Damson Cloud. A Google partner has a huge amount of knowledge from hundreds of other deployments that they've done, and they can ensure that your deployment is as successful as it can be.

Don't forget to hit that subscribe button!"