Global Go-Live Considerations

[Alex Coope - SN]

I was speaking with a Customer this week and we got on the topic of a Global go-live. One thing to bear in mind is that this doesn't necessarily have a limitation on language usage as it's more to do with where the end-users will be based and thus what their first impression of what-ever new experience that's been developed, is.

Geographies are important in go-lives

When Geographies are a key aspect of a go-live, there's typically a few main lines of thought (which entirely depend on the business structure and your requirements). 

The first idea is a "big-bang" approach:
Simply put, this is where all the functionality goes live all at once (and potentially in all languages) all at the same time on a given day.

There are naturally pros and cons to this approach:

Pro - Everyone can experience the new functionality at the same time. 
Pro - Training for the new experience(s) can be performed at the same time.
Pro - BAU can normalize quicker (aka less swivel chair for certain regions) if migrating from another tool.
Con - It can be extremely draining to line up all stakeholders at the same time due to the amount of inter-department dependencies.
Con - It could prove disruptful to initial BAU post go-live if multiple timezones are needing coverage or assistance (I'll delve deeper into this concept later on in this post).
Con - Testing needs to be extremely thorough and rigorous (not just the functionality, also the UX in other languages, so the translations and how they convey what is required. This also means that all of the material required for Day1 would need to be made ready). If you haven't already, check out our training on NowLearning here, specifically part 4 and 5.
Question - Any post go-live functionality being made available, should it go live all translated by having a "code freeze" until the translations are ready or should it go live and add the translations after, leading to a potential mixed language experience?

The second idea is a "staggered" or "multi-phase" approach:
Simply put, this is where key functionality (suitable for a given region) is made live as necessary per region. E.g. US in Week 1, EMEA in Week 2 etc.

Which also has it's pros and cons:

Pro - Can cater for code freezes which may assist with the time required to perform and test translations.
Pro - Can give regional teams additional time to get up to speed.
Pro - Can allow regional teams to be split up into pilot groups for "early adopter testing" or "pilot groups"
Con - Potential for increased duration of swivel chair activities.
Con - Can lead to a longer period of time required to support the go-live as it would be extended in calendar terms.

Ultimately, there's no right or wrong answer and there are other options as well. It all comes down to what suits your needs best after weighing up all of the options. However, what often gets overlooked until quite late is "when should the switch be flicked" so to speak. Meaning, at what time of the day should things (what-ever they are) be turned on?

Example scenario
If we imagine that my team wants something new to be added to our internal tooling, let's first look at where we're based:

We can see that there's a fair few timezones we need to think about. Ranging from GMT-7 all the way through to GMT+9 (and that's not even for the entire Company, that's just for our team!). 

In the world of software development, it's generally considered "best-practice" to not go-live with something either on a Monday (because in most parts of the world it's the first day back in the week so impact risk could be high, or it could be a public holiday somewhere) or Friday (because it's the last day of the week, and who wants to be that person staying late for an unplanned P1? ).  So usually it falls between Tuesdays and Thursdays. I'm sure someone will raise a good counter argument to my logic in the comments, which is fine, it's just to say these are the general principles.

So let's review what these timezones would mean to our team and review what impacts it could have. Let's look at a mapping of all the timezones between GMT-7 and GMT+9:

If any of you reading this have worked in an "Ops" role, you may likely recognise something like this. It's essentially a mapping of timezones relevant to us in our example. This allows us to check (easily) what timezone our team members might be in should we make something go live on our internal team instance.
I'm based in the UK, currently (at time of writing this) we're in GMT+1 or "BST" as it's known (when we're not in Daylight Saving, we'd normally be in "GMT"). 

What we can see here is that if we wanted something to go live at mid-day here in the UK it would be 8pm in Singapore and 9pm in Japan, conversely it would be 5am for our Californian colleagues.

What if we did Thursday 5pm in the UK?
It would be 1am on Friday in Singapore, 2am on Friday in Japan, but 10am on Thursday in California. 

You'll also notice that I've greyed out example Out-of-office hours in my table. This helps plan for load usage and therefore determine a time that causes the least amount of impact to any given region. 

Summary

Obviously there are many more timezones than this out there, the take away is about being aware of the scenario and planning in advance for it. It's also not to say there's any specific right or wrong answer as no two organisations are the same, however being aware and thinking about these kinds of things can help making a more informed decision when necessary to do so.

Please like, share and subscribe if you found this useful as it always helps.