Modernization Hub

Modernization and Improvement
G Suite Migration: Success Factors for the Large Enterprise (Cloud Next ’19)

G Suite Migration: Success Factors for the Large Enterprise (Cloud Next ’19)


[MUSIC PLAYING] SHAWN IVEY: You will hopefully
take some good tidbits away today. I’m going to kick us off. And to do that, I
want to first make some quick introductions
so that you know who’s up here on stage. I’m Shawn Ivey. I run our Google workplace
productivity practice at Accenture and it’s
obviously focused on G Suite. And I am here with
three amazing colleagues who you’ll hear from the
majority of the session today. I think combined 22
plus years experience doing G Suite implementations
for large organizations. So some fantastic experience
both on the technology side, but also on the
change management side, which of course is very,
very important in this space. So glad to have the
team here with me. To keep things on
a light note, I’m sure everyone has
had the pleasure of working in a large
complex project at one point or another. So you can appreciate lots of
moving pieces, lots of risk. And of course, none
of us want to be that guy that just
hopped on the scooter there and fell into the big hole
in the middle of the street. Not quite sure where that’s at,
but I don’t want to go there. What we do, of course, want,
understanding there’s still lots of moving
parts, understanding there’s still lots
of complexity, we want to have
enough preparation and some good
information that allows us to navigate and ideally avoid
major injury, which you can see is the case here. So what we’re going
to talk through today, and I’ll get a little bit
to the context of this, but what we’re going to talk
to today is to share with you hopefully some
experience some feedback, some success factors as
the title of the session would indicate based on our
experience implementing G Suite for large organizations. Now I do want to highlight
that we’re Accenture. We like to work with
large enterprises as I think most people
probably appreciate. And certainly for G Suite
moving into the large enterprise space, it’s an interesting
sort of transition. Right. And part of why we
wanted to do this session was to highlight the fact
that in the large enterprise space obviously there can often
be different dynamics that you may want to consider both from
an organizational perspective but also from a
technology perspective. And certainly it’s been our
experience that this is, again in the large enterprise,
this is more than just bringing in some new tools,
implementing the tools, moving onto the next project. This is often part of a
much broader initiative around workforce transformation
in these companies, right? So kudos to those early
pioneers, those early adopters who are not just,
again, implementing some new technology. They’re fundamentally trying
to change, in many instances, the way work gets done. It’s a major culture change
throughout the organization. I’m going to end my brief
introduction here and hand it over to Keith in a second. But I wanted to just
give a shout out to those who have kind
of paved the way for many of the rest of us as we’re now
seeing greater adoption of G Suite in the enterprise. And we’re going to
spend some time with you in fairly rapid fire motion. We’ve got a lot
of content, so we won’t be able to go particularly
deep on anything in particular. We want to get across as many
of these key concepts as we can. So it’ll be fairly rapid fire. But we’ll be around
both after the session and throughout the week. Accenture, of course, has a
booth there in the expo hall. So we would welcome
questions after the session. Come find us during the week. We’d love to talk
to you some more. So with that, I will
hand it over to Keith. KEITH VARNADO: Thanks, Shawn. All right. So in the interest
of time, we’re going to go ahead
and get started here. Good to be with you guys. So what we have here is a
typical G Suite deployment, including all of the
relevant workstreams. So today we’re going
to focus on technology. And we’re also going
to talk about user adoption and managing change. So at the top there, you’ll
see Google’s recommended three phase approach, which
is going to include core IT, early adopters,
and global go-live. And it lasts about
90 days typically. So as we’ve done
these deployments over the years, what
we’ve come to realize is that even though
all of your users are successfully
migrated to G Suite, there are still other
deployment activities that need to be done. So we’ve coined those as
post deployment activities. And what we’ve done
is we’ve actually started to modify our
methodology to include these post go-live activities. Some of them may include things
such as end user file migration from a network file share
over to Google Drive, migrating applications that
have integration or dependencies on the Microsoft Office suite,
also looking at your business processes and workflows
and understanding if we can solution them
either in G Suite or GCP. So there are some
current programs that provide
guidance around some of these topics such as
Google’s Next Mile program as well as business
transformation workshops. So it’s our recommendation
to actually break these activities away from your
standard deployment methodology timeline to avoid project delays
as well as so your project key stakeholders can
visualize, create, and meet short term milestones
such as migrating your users to G Suite as
well as long term integration milestones. So here are some topics
within the actual technology workstream, a lot of them
we’re going to cover today. If you engage a partner
such as Accenture, it is their responsibility
to actually take you through a deep dive of
all of these projects in what we call a DPW, which
is a deployment workshop, or a TKO, which is
a technical kickoff. So during these sessions,
it helps move things along if you do your own due diligence
and bring information specific to your organization
to the plate so that we can have
discussions and make decisions based on your organization’s
culture, infrastructure, and internal policies
and processes. So to help guide
our discussion, this is what we’re going
to focus on today. Security and compliance. This comes up a lot
during deployment. Today we’re going to
focus on alignment and getting sign off
from key stakeholders. The second one we’re
going to look at is what we call
application and business process and integration. So what is that? Think. If you unplug your
messaging infrastructure, what do you bring? So we’re going to identify
some of these risks and discuss why again we
want to branch those off from your typical end
user deployment timeline. The third area we’re
going to look at is around infrastructure
integration, specifically focused on
networking, authentication, and provisioning. So our assumption is that
you have these processes and systems already in place. So we want to look at watch
points and best practices around each of these areas. And then finally, we’re going
to talk about user adoption and change management. These are part of post
deployment go-live activities and also can be an indication
of a successful deployment. So the bulk of our
discussion today is going to be around
technical considerations. So this is not just unique to
enterprise level organizations. This happens with
all deployments. But typically, with
large organizations, this is a more
complex discussion that we have and is often
more difficult to solution. So I’ll let Shamus go
ahead and kick it off with security and compliance. SHAMUS SAMBORN:
Thank you, Keith. And thank everyone
for coming today. Quick show of hands. Who’s in the middle of
a G Suite deployment? Cool. Who’s actually done
a G Suite deployment? OK. Great. So security is a top
priority, of course. G Suite’s security
features and best practices are well documented
we’re not going to walk you through the
list of those today. As a large organization,
your challenge is ensuring you’re deploying
G Suite while meeting your security requirements. Yes, G Suite has enterprise
security features. But maybe there’s simply some
gaps with your requirements. Maybe you’ve already
invested significantly in existing controls
and now you want to integrate these with G Suite. So for example,
your infosec team may want to use
your existing DLP and integrate that with G Suite. And you find out that
that’s going to take three months and $200,000. And now you’re looking at budget
issues and potentially timeline issues. So the number one thing is
to engage your infosec team as early as possible. Make them an integral part
of the deployment team. The key here to success
is to have alignment with your project team,
infosec, and your stakeholders so issues and risks
can be documented and decisions can be made
quickly and efficiently. To help you with this, we
recommend executing a security control analysis. This is a plan that’s
going to include an analysis of your requirements
and your existing controls, the current
corporate tools being used to implement
those controls, and the G Suite considerations,
the equivalent features and functionality. You want to ask is there
functionality in G Suite that meets our requirements for our
existing security policies or, if not, can G Suit be integrated
into our existing controls to meet our requirements? The outcome of this should be a
clear disposition of controls, where they will be implemented,
and, most importantly, where the gaps are that
you need to prioritize. And maybe, hopefully, this
will be an opportunity to deploy more security policies
than you currently enforce. This exercise will expose
those options for you. Here’s some key areas
that need to be evaluated. Email hygiene and protection. So the key decision
point is if you’re going to use your existing
email hygiene solution or switch and use Gmails. This decision will have
major implications on mail routing design, which is a
huge success factor for G Suite deployment. It’s something that
needs to go right. So if you’re
deciding to integrate Gmail into your existing
mail routing, or either way lock yourselves in a room. Figure out your mail
routing as early as possible in your deployment. DLP information
rights management. The key here is to understand
G Suite’s capabilities in these areas and
make sure that they meet your current needs
or future needs as well. Get a dev environment. Get your hands dirty. Test these out. There’s tons of
documentation out there, but you really need to go in
and understand how to use these, how do they work, so you know
exactly what you’re getting. If you have an existing
DLP or IRM system, understand if Gmail can
integrate with that. And if so, what is
exactly supported? Regulatory compliance. So these typically
come up very often. It’s a big concern. The associated risks with
this should be closed prior to the project kickoff. But a common issue we see is
that something gets missed and it doesn’t come up until
later in the deployment. The example would be let’s say
you’re kicking off a project. You invited business
stakeholders from pick a European country. And they start bringing
up all the requirements and their concerns
with moving to G Suite and now you have issues. So get those solved earlier. Get those out of the way
so you can move forward with your deployment. Legal requirements. So the task here is to
identify your email retention requirements, legal holds,
and e-discovery needs and implementing them
before migrating data or putting users on the platform
to make sure that you’re still going to be in compliance. Also engage your
legal team so they can update their operational
procedures for the new system and processes. You may have an archiving
platform already. Assuming that you’re
going to use Google Vault, you’ll need to consider
what to do with that data. Again the goal here
with all of these is to be aligned with
infosec so everyone can agree on the
impacts and the plan and move forward
with your deployment. Now let’s take a look at
some other things that may be new or inherent
to moving to G Suite. I’ll have Keith
talk about those. KEITH VARNADO: All right. So sharing. So one of the functions
and features around Google that’s very, very powerful is
their sharing and collaboration platform. So you want to understand how
sharing, specifically external sharing, may impact your users. You want to have a good
understanding of the options and functions within
G Suite as it relates to sharing so you can
establish a policy that aligns with your
current security posture but keeps your users productive. Once you have this
policy, you want to communicate
that to your users as well as provide
them some guidance around sharing usability. For example, if you decide
to restrict external sharing for some or all of your
users, you probably want to develop a process
where they can request an exception to that policy. You also may want to
think about things such as alternative options
for them to either share or collaborate with external
vendors or partners. There’s also a few
security features within G Suite that will help
you protect your data once it’s stored in Drive. Some of these we’ve
already talked about. Right. So DLP helps you protect
from data leakage. Information rights management
helps protect yourself from unauthorized access
of files within Drive. Auditing. So there’s audit
logs that captures all of the different changes
to files that are in Drive. We recommend that your
security team periodically reviews these files looking
for data overexposure based on sharing. And then finally, alerting. We recommend that
you proactively set up alerts that’s
triggered by sharing changes to any files that
contain sensitive data. Managing access to
third party to apps. So once your users are
on the G Suite platform, they’re going to have access
to the Google Chrome Web Store as well as G Suite marketplace. So these places host a
lot of applications that can access your user’s data. So this could be a
gift and a curse. Right. So it gives your users
a great user experience, but from a security
perspective it can cause you some
concerns and headaches. So let’s look at some
ways we can manage the way that these third party
applications access your users’ data. So these applications
access your users’ data leveraging Google’s APIs and
using the OAuth authentication protocol. So within the admin
console, you have a couple of options of
how you manage that. Right. So one is to disable
what we call high risk APIs for all users unless
you’ve identified them as a trusted app. Right. So this gives the
users the freedom to download and install any
app that’s considered low risk. So for example, one could
download the ESPN Chrome app and watch their bracket bust
on the first week of NCAA March Madness. Not telling on myself. The second option
is to basically disable access to all apps
unless you’ve identified them as trusted. This is a more
aggressive approach. But what it does is it allows
you can– well, actually, what you want to do if you’re
doing that option is you want to also develop a process
where users can request access to additional apps. And by doing so, you
allow your security teams to run any type of security
assessment or penetration testing before you
make those generally available to your users. Now we talked about the
ability to monitor via logs. You can do that as well here. So you have OAuth logs. And so your security
teams can again periodically review
those looking for dangerous or suspicious
apps and revoke that access if needed. You can also educate your users. They have the ability
to actually perform a self security assessment and
look at what apps have access to their data. And then they can take
action to revoke that access if they choose to. So, at the end of the
day, what you want to do is you want to determine what’s
your approach to managing access of these applications. Do you want to be
more proactive or do you want to be more reactive? Operations. So from an operations
perspective, you want to identify
your team members and understand what their roles
and responsibilities will be. That way when you assign
administrative privileges, you’re going to follow the
principle of least privilege and only assign them the
minimal administrative privilege that they need to
perform their job. At that point, you can also
identify training needs and understand what
administrative training that they may need
within G Suite. You also want to make sure
they understand the tools that are available to them
to support G Suite and how those tools relate
to any existing processes and tools that they
already have today. So for example, there is what we
call the G Suite security tool box, which allows you to
identify, triage, and remediate security incidents, such
as a compromised mailbox. You want to make sure
your teams understand how to use those tools and when
to use those in conjunction with your already
well-established processes. So what we typically see is
sometimes these discussions actually fall by the wayside as
you focus on end user migration activities. So you want to make sure you
have these discussions early on in the deployment
process so they feel comfortable with supporting
your users upon go-live. So mobility. So we’ve seen a lot of
changes in this space when it comes to G Suite. And you may be aware G Suite
does have an end solution that comes with G Suite. And it’s included
in your licenses. So this may be appealing
from a cost perspective. However, you want to
do your due diligence and understand the
capabilities of this solution to make sure it’s the
right solution for you. You want to familiarize yourself
with all the capabilities and functions around
managing mobile devices. So there’s a lot of
information out there regarding support articles and
knowledge based articles around these functions. But we recommend that you
work with your partner and create and
use test use cases specific to your organization. That way you can understand
the actual user experience when they enroll their
devices and you also understand the
different policies that apply to iOS versus Android. So some things that
may help you here is understanding the device
types your organization has. Hopefully it’s no Blackberries. Understanding what your
mobility strategy is, right– BYOD, CYOD, COPE,
corporate only. What are your existing
MDM security requirements and any future requirements? Will I have the
same policy applied to all users and all devices
or different policies to a different set of users
and different devices? Do you have an existing
China access policy or is it something that
you need to develop? So again, you want to make
sure that the solution checks all of your required
boxes when you make a decision of which
MDM solution to use. SHAMUS SAMBORN: Thank you. OK. Next section here, application
and third party integrations. There’s a reason that
this is a major topic today is it’s often
overlooked in the early stages of the deployment with the
potential for some pretty big risks, namely business
disruption if something breaks. So again, the way that
we like to frame this is imagine if you’re ripping
the plug on your email infrastructure. Daunting thought, right? But what’s going to break,
besides people complaining that they’re not getting
email, are your applications that are integrated with
your email infrastructure. Some example types of
these would be SMTP, so applications relaying
through, for example, maybe your exchange environment,
IMAP and POP applications processing email in
some fashion, even deeper integration
from an exchange perspective with EWS and MAPI. Also in this category would be
dependencies on email clients like Outlook plugins,
connectors, Salesforce plugins, telephony, things like that. So your first task is to
take inventory, of course. Document the type
of integration. Prioritize the solution. You’ll know your
heavy hitters here. You’ll know your biggest risks. So you can manage these
tasks and properly get these implemented without
breaking anything. What about ones with
really high complexity? And honesty, we’ve seen
these take months to do. Maybe it’s a code rewrite. Maybe it’s a new application. That’s why it’s
important, and Keith talked about this earlier, is
to decouple this application integration workstream from
your end user deployment. We can configure
mechanisms with Gmail and using routing controls to
ensure that these keep working, and give you time to implement
these properly and minimize the risk, and make sure you’re
keeping on with your end user deployment timeline. Again, documenting and
understanding the impacts here so you can manage these
appropriately is the key. Shared mailboxes. Oh boy. This is my favorite topic. I finally get to tell the
world about shared mailboxes. This is something that probably
doesn’t come up that often if you’ve been talking about
G Suite and deployments. And even if it does
get talked about it, it tends to get
swept under the rug. And then you have issues at the
end of deployment with them. And it’s just no fun. So part of the
reason these may not come up in your pre-sales
discussions from a standpoint number of licenses– how many
user mailboxes do you have? Oh, we have 20,000
end user accounts. So they’re using
that to scope your– estimate your licensing costs
and also for statement of work if you’re going
through a deployment. So you can see that this
could be a budget issue where you have a scope for that
additional work that’s going to come later. Also, you may need to purchase
additional G Suite licenses for these shared mailboxes. We’ve seen organizations
with shared mailboxes into the many thousands
so it’s important to be aware of potential
cost implications here. Step one is simply getting
an estimation on the number of these that you have. So now that you know you
have shared mailboxes, where do you go from here? There is a detailed
methodology that we have and that we would take you
through in a deployment. But the main aspects you need to
consider in the planning stages are taking inventory
of what you, have what needs to go into G
Suite, who needs access to those, how you’re going to
provision these in G Suite. That’s a whole other topic. There’s a couple of
different ways to do it. But it’s really important
that you understand that the pros and cons for those. End user access–
how you’re going to manage giving/taking
away users’ access to shared mailboxes. End user training and support. They’re going to be
accesing these in Gmail now or maybe Google Groups, so
preparing the documentation, the communications, and the
support for day one is key, and administration
from your team onboarding/offboarding
these shared mailboxes. All that stuff
needs [INAUDIBLE].. The other risk is
you need to start planning these early
to avoid delaying the migration of these. So the biggest thing we see
is we deploy our end users but now we have all
these shared mailboxes. They’re not ready to go. So now we’re extending the
project one, two, three months trying to get all these in and
do all this work around them. So starting these
early, your goal is going to be to cut these
over with your users on day one. It may seem like a
lot of work, but it’s going to save you a lot of
pain and a lot of trouble. If you don’t, you’re going to
be extending that deployment timeline and costs. So the takeaway here, by
knowing you have these, understanding the potential
for budget and timeline risks, you’re already on your way to
a properly managed transition. What you don’t want is this
to come up as a surprise and scramble to
get these in place. KEITH VARNADO: OK. Infrastructure integration. Again, we’re going to talk
about networking authentication and provisioning. Our assumption again
is that you already have these strategies or
these processes in place. And it’s important
to understand how these work within
your organization and how these moving
pieces fit together, because we want to
minimize disruption as we deploy G Suite. So we’re going to focus
on these three topics. And there’s other topics
that are part of, quote, “infrastructure integration.” And we’ve already touched on
some of these today, right? So we’ve talked about
mobility, security, application integration,
and administration. So from networking, so when
we go into a deployment, a lot of times there’s
a myth that you have to make major
changes to your network. Typically, this is not so. All right. Large organizations
already have some type of SaaS application
or applications that they’re using. So the whole concept of
accessing an application in the cloud is not a new one. So you’re typically fine there. The other concern, or
typically the other top concern is how much additional
bandwidth am I going to utilize by using
this application in the cloud. All right. So there’s no quick
dirty math that we can do when we come
into the front door and say it’s going to
go up by x percentage. All right. So what we want to do
is we want to identify some best practices
and some things to avoid so that when you
do your network discovery you understand how
network ready you are. Right. So identify. You want to identify any
locations that may already have high bandwidth
utilizations or have slow access to the internet. Simplify. Decentralize your network. Get your traffic
onto Google’s traffic as soon as possible by
leveraging local egress points. Localize. Use local DNS servers
so that users– I mean so that Google
can geolocate your users and route their traffic to the
closest Google data center. Snapshot. So take a snapshot of your
existing bandwidth utilization as it is today before you even
start the deployment process. Then take additional snapshots
after each deployment phase. That way you can understand
the network impact that you’re making as
you’re moving users to the G Suite platform. And then plan. Develop a plan for China
access and also develop a plan to mitigate
any issues that you may have discovered doing your
network discovery process. A few things to avoid. Filtering. So you don’t want to use things
like proxies or web content filtering solutions to send
your Google traffic through. Whitelisting. Avoid using fully
qualified domain names or IP to whitelist
Google traffic in things such as firewalls. Prioritizing. Don’t try to prioritize
different traffic within the G Suite services. So don’t try to prioritize
mail over calendar. And then finally
synchronization. So you want to use
some caution if you want to deploy things
that synchronize large amounts of data such
as like fat email clients. Right. You want to understand
what impact that may have to your network, if any. If you’re doing
data migrations, you may have to make special
considerations or configuration changes for that if you’re
leveraging your local network. So authentication. So we like to use what we call
the use what you have strategy. Right. We don’t want to go in and add
another authentication method and provide users with
another set of credentials if they don’t need it. Right. So we recommend
leveraging an SSO solution for authentication. And we hope you have it. Right. That makes our job easier. So if you do have SSO,
there’s some certain things that you want to understand
within the actual G Suite console when you
go to enable that. All right. So one is you can only point it
to a single identity provider. So all of your users need to
be within that SSO solution and be able to
authenticate against it. So that may come into play
if you’re a company that does a lot of acquisitions. When you enable
it within Google, it uses what we call
the big bang approach. So it’s usually
either all or nothing. There’s some exceptions,
but it’s really IP based. So you can’t really deploy SSO
for a limited number of users and slowly roll that out. If you need to do any
type of SSO testing, we recommend using a
test domain for that. And then finally, remember
your super admins can always bypass SSO in the event
your solution goes down and they need to go in there
and disable it for your users. So if you don’t have
an SSO solution, again we recommend that
you do invest in one. And if you’re going to
implement an SSO solution, we recommend that you decouple
that from your G Suite migration. So we’ve seen
issues where people try to deploy both
at the same time. SSO solution is not ready. And all of a sudden your
users get a bad perception around G Suite. Right. G Suite is not available. And it’s not a G
Suite issue, but it’s more of an SSO solution. So some considerations
that you want to think about if you’re
thinking about actually deploying a new SSO solution. Do your load testing. You want to make sure
all of your users can authenticate to G Suite
through your SSO solution and any other application. We’ve seen issues where
everything looked fine for core IT and global– I mean core IT and
early adopters and then global go-live. All of a sudden SSO
is not available. So we’re not speaking
from experience. But we’ve heard it’s a
very, very, very bad thing. All right. The second thing you want
to do is high availability. You want to make sure that the
solution is always available. Not typically an issue today,
because most SSO solutions are at least partly in
the SaaS if not 10% SaaS. Again, not something
that we’ve been through, but we’ve had to deal with
100% on prem solutions that were not
available for go-live. And the last thing you
want to do is latency test. So you want to make sure
that all of your users have the same or
similar experience when authenticating
through your SSO solution regardless of where they’re at. All right. So provisioning. So from a domain
perspective, you want to take inventory
of all your domains but then you want to make sure
you identify only the ones that have to do with mail routing. Right. This is typically not a lift
and shift of all of the domains that you currently manage. From a user perspective,
you probably already have a process where you
provision your users. So you want to understand
how that relates to G Suite. Do we simply just put that
as a downstream application and our users get provisioned? Many of our clients actually
synchronize their user objects from a directory service. If you’re doing
something like that, it’s Google’s recommendation
that all of those users are in what we call a
single source of truth. Right. So if you have objects
that are stored in different
directories, you either want to think about
consolidating those or investing in some third
party applications that will allow you to sync objects
from multiple directories. So distribution lists. So probably within
your organization today, you probably
have a process where different
types of groups are created for different purposes. Right. You may have some completely
security groups and then others that are used
for mailing list. So within G Suite,
you want to understand that those groups,
there’s really a one concept of a
group, but that group can be used in different ways. So you may have a group
that’s been created and it can be used as a
distribution list or a mailing list. That same group can be used
to provide access to Drive or files in Drive. You can also share
calendars with those groups. So you want to make sure
that you understand that and realize how that applies
differently within G Suite. Management. So there is a function
within G Suite that allows you to have your
end users create and manage a group, specifically the
settings and the membership of that group. So on the surface, it
sounds like a good idea, because you’re pushing
that functionality away from IT onto your end users. You want to use some
caution if you’re thinking about
this, because that can turn into what we call
the wild wild west of group creation. And as we talk
about group usage, if you’re using these
groups to provide access to, say, resources in
GCP or products in GCP, you probably don’t want
a standard end user managing those membership lists. Timing. So when you’re
pervasive in your group you want to make
sure that they’re fully provisioned in
Google before you direct any internet inbound mail. OK. Again, we’re not
speaking from experience. But we’ve seen issues where mail
is already flowing to G Suite and then people try to
provision their groups. And what ends up happening is
the mail is not consistently delivered to all the members
because they’re still populating as mail is being
delivered to those groups. So operations. So operations you want to look
at onboarding and offboarding and how that integrates
with your current onboarding and offboarding workflows. So a couple of things
that we’ve seen here. A lot of applications when
they deprovision a user actually suspends it. And it doesn’t delete the user. So what ends up happening is you
have a lot of suspended users that are consuming
your licenses. Right. So you want to come
up with a process, either automated
or manual, where you review these
suspended accounts and then delete them to
recover those licenses. Now before you
actually delete them, there’s a couple of things
that you want to be aware of. So one, you want to make sure
that you meet any policies that you have to maintain
accounts and their data for a specific amount of time. The second thing you
want to understand is that you do have
the ability to transfer some data to other accounts
prior to deleting them. So you want to work
that into your workflow. And then the third
thing, if you’re utilizing Google Vault,
today if you delete a user account from G Suite,
it also delete the data from G Suite as
well as Vault even if that user is on legal hold. So in summary, you want to
identify your mail writing domains, understand end to
end provisioning from a user perspective, understand
when to provision groups and who is going to manage
them, and also have a process to recover licenses
for suspended users. SHAMUS SAMBORN: OK. So we tried to
identify areas that tend to get pushed to the back
of the line in deployments. Within nearly all the areas
we talked about today, there are some common themes– starting early, involving
the right people, and getting alignment. But there’s so much
more to talk about. Keith and I have been doing
this for a long, long time. We love the G Suite community. Come find us if you
want to talk shop. So with that, I’m
going to hand it over to our training and change
management expert, Emeline. [APPLAUSE] EMELINE HUNTER: All right. Thanks, everyone. So you’re all probably
here to understand how to make your G Suite
deployment a success from a technical perspective. But indulge me in
a few moments as we talk about how to make it
a success from a people perspective. And also it would be
weird if you all just got up and left right now. So you can spend a
lot of time and money to ensure that the technical
deployment of G Suite goes without any issues
for your organization. But a perfectly migrated
mailbox and calendar does not equal a successful
G Suite migration. You really need to
focus on how that is going to affect your people. So organizations tend to focus
a lot on the technical aspects of the project, but you will
fail if you do not plan or put a plan into place
that’s going to support your users through this change. So a properly thought out,
a well planned and executed change management
approach is the key to success of your
G Suite migration and adoption of the toolset. So we usually kick off our
deployments with this phrase. Change is not an event. It’s a process. To be successful, you need
to plan for the change before and long after the
deployment of G Suite within your organization. But we so often
lose sight of this as we shift our
focus to tactically preparing for the main
event, the cut over, the G Suite go-live. But you have to remember that,
for your users, go-live day, that is just the beginning
of their adoption of G Suite. That is just the
very, very beginning of figuring out what the heck
is going on in this new world of messaging. And so much more is
available in G Suite than just messaging as we know. So let’s talk about
what else we should be doing throughout the process
of migrating to G Suite. I’m going to wrap up
today’s conversation by talking about what you
should be focusing on before, during, and after your
deployment on the people side of things. So planning your change
the right way probably starts way before you even
select your technology, much less the partner
that’s going to help you through the process. You need to start
by understanding your people, the people that
make up your organization. And I don’t just
mean head counts in the various countries that
are a part of your company. What I mean is who
are your people and how is this
going to affect them. So you choose G Suite. Maybe before that
you set a goal. What do you want for
your organization? What do you see as the future? So maybe that goal is
transforming the way that your people work together,
that your company becomes more digital and a more
agile organization. You have to understand that
a technology change is not enough. That is just the
beginning of that type of huge cultural shift
within your company. So remember, and you’ve
probably heard this before and it’s probably a little
corny in this day and age, but organizations don’t change. People change. So you need to spend
the time upfront completing your
stakeholder analysis, understanding who
your people are, and how you can start to
organize them together into user groups, and then
really documenting the change impacts and how they will
affect each of those user groups or those personas. Ask yourself these questions. Who makes up your organization? How can we group those
users together into personas so that you can start building a
change plan around their needs? How will this change affect
each of these employees? And how will this
change affect overall your different user groups
that make up your company? And what measures do
you need to put in place at the end of the day to make
sure that all of your employees are supported through this
change over to G Suite? A true understanding
of your organization and the makeup of
your organization is really important
and we sometimes forget to spend
enough focus on that. It will help you inform
your change planning across your communications
and engagement activities, your training offerings, and
your sponsorship activities. And it will help you make the
right decision for your people. All right. So during the deployment. Now that you’ve spent the
time and the resources on really understanding your
organization and the impacts that are going to come with this
major change over to G Suite, and you can really deploy
now in a very strategic way to meet the needs of your
different types of users. You’ve put in the legwork. You understand who
your people are. Let’s plan towards making this
successful in a strategic way for each of our
different user groups. You’re able to map out
what the user journey looks like for each of your personas
that you’re deploying to and really understand
how they’re going to go through this
journey at what time we might need to have special
considerations for them. Are there special
training offerings? Are there previews for
our executive assistants that are going to make them more
comfortable with this change overall? Are there considerations we need
to make from a communications or training perspective for
our highly mobile workers? So if you break out your
company into user groups, you can really start to
map out those user journeys and understand how they’ll
go through that process, because we’re not all the same. We all have different needs. You can develop training
that meets the specific needs of each group as well
so that you can really train on the moments that
matter for those groups. Everyone’s got different pieces
they want to focus on day one, after six months, after a year. Everyone has different needs. And finally, post deployment. So by now you’ve spent the last
few months really understanding your people and the personas
that make up your organization, and you’ve planned a
deployment that’s been tailored specifically for them. So because of that,
you’ve got the insight that you need for
each of these groups so that you understand the
impact for them of moving to G Suite and you understand
also the appetite for change that each of these groups have. You’re now better equipped to
set realistic adoption metrics that can be measured long term. Don’t set yourself
up for failure. If you really know your
people, and their processes, and their needs, you
know that it’s unlikely that we’re going to achieve
100% adoption right away, or sometimes maybe even ever. So go-live is just the beginning
of the journey to adoption of G Suite for your users. Make sure that your
change planning includes communications and a training
approach for your users posts go-live so that you
can drive adoption with realistic goals in mind. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *