Monthly Archives: September 2014

Going global – things to think about

I finished work on another project recently that allowed me to consolidate some ideas on how to make implementing software outside your home country more successful.

Obviously planning is key, but often the plan doesn’t follow activities right through until the final outcome. I came across several instances where a planning decision had been made before people had thought through the full impact of that decision, resulting in confusion, loss of time and wasted effort. Of course you can never know *everything* about possible impact, but you can certainly get some of the bigger things right.

In my experience, these things are:

Localization – will the product be localized for each market? If so, how will training be conducted? How will support be handled on an ongoing basis? How will ongoing changes to the product be handled? If you’re not going to localize at all, think through the impact of asking everyone to use your native language.

Security and Application Management – can people access the product within their current IT structure and who will be managing access? If it’s IT, do they have the desire and resources to do so? If it’s the business side, same question. If you’ve never implemented a product of this type across different markets before, you’ll need to do a lot of testing. This means engagement with local IT teams who may not have your project even on their radar, let alone have resources assigned to support you.

Data Security and Granularity – where will data be stored (as in general, data storage in the US is not sufficiently secure for Europe)? Does the data need to be encrypted at rest?

What granularity of data will be required for reporting at the most senior level, and at what point will data differences not matter to the higher level reports?

People in constituent markets need detail, and that detail can differ from country to country. What you need is to understand how data in one country stacks up against data in another, and then tune your high-level reporting accordingly. Many companies implement a global software solution to drive standardization across process, products and pricing, but in some environments that simply isn’t possible. You have to decide where the “break-point” is for reporting and then work to that point in every market.

Communications Alignment – this is a fairy standard principle, but I’ve seen many instances where broad, high level goals had been communicated in a pretty generic way but not broken down into specific messages. It made things difficult for us, as not only did people not know what we supposed to be doing, they didn’t understand how they needed to participate or contribute.

So, not too many things to think about really, but time spent working through each of these areas will pay dividends, I promise you! I’m happy to answer questions on this topic if you have them,

Advertisements