West Monroe Partners was recently engaged to develop a new Windows image to replace the nearly 100% Windows XP environment at a global manufacturing client. This image needed to support roughly 30 different hardware types and 20 different language/locale options in as many countries – a truly global deployment. Our development efforts culminated in a whirlwind tour of the client’s global manufacturing and major office facilities, to assist local site IT in rapidly upgrading their user base and providing day one support for the upgrade.
While the normal considerations for any OS upgrade and large deployment applied to this project just like any other, there were some additional items that we had to take in to account given the multilingual and multicultural needs of the deployment, and some of these items were addressed on the fly during migrations. The list below captures some recommendations based on what worked well (and what we missed!), designed to help you plan for your next major international migration and deployment, and hopefully handle these items in advance.
1. Ensure That an Application Assessment Is Done
This could apply to any major OS upgrade, but it was especially important when considering that each of the major international facilities included in our scope had some of their own processes and software packages, and these were not necessarily well known to the team developing the new workstation image at the client’s headquarters location. For this reason, it is critical that a thorough assessment of the software in the environment is performed. This assessment should include software compatibility with the new platform being deployed, and software’s availability and support (or lack thereof) for the various languages required by the organization.
Don’t forget to track down copies of the install media! Software may have been purchased by individual business units, and there’s no guarantee that someone held on to installers downloaded from various websites.
2. Engage International Staff
It’s easy to accidentally develop in a vacuum, especially when engaging remote international resources means dealing with time zone differences, communication delays, and language barriers. However, in our recent case, the client’s international service desk and manufacturing IT staff were invaluable in bringing up issues with the current image that were affecting their users – but not were not necessarily affecting users at the client’s main office location. They provided in depth testing with their individual local application subsets, assisted in testing language and localization support, and helped us identify issues that would not have presented themselves if we had developed our image solely at the client headquarters office. In short – they were an invaluable driver for continuous improvement throughout the process, and involving them dramatically enhanced the quality of the final product.
3. Engage International Staff Early
A caveat to point 2 is that your development team should engage international resources as soon as possible. In our case, because the deployment process for the client involved getting hardware and software deployed at each location in order to be able to deploy the new OS, we tended to wait until that hardware and software was in place before engaging the local resource to help us test. At a couple sites, this significantly reduced the time we had to test and address issues, and even left us addressing some problems on the fly when we arrived to actually perform the migration. In hindsight, doing more to engage these resources earlier would have avoided these last minute fixes. Even building laptops at the client’s main location and shipping them back and forth to the various sites, tedious though it might have been, would have caught some of those issues earlier.
4. Confirm Language Preferences
It’s easy to assume, for example, that German people want German language software and use German language keyboards – but it might not be the case in your environment. Our client did need to support roughly 20 different languages, but we were surprised to find that some sites didn’t necessarily want purely localized software. For example, several offices used a localized keyboard layout, but preferred to have English language versions of Windows and Office. One office’s users even primarily spoke one language, but used the keyboard layout for a second language. Our lesson learned was to carefully confirm the language/localization preferences with each site to identify which languages and localizations needed to be supported, and which can be skipped.
It’s also important to confirm support on the proper hardware and with local IT staff – for example, our Japanese language builds seemed to be working properly, but we were testing on a laptop with a US-English keyboard. Once deployed to a machine with a local Japanese keyboard, our Japanese IT resource was able to quickly alert us to a problem with keyboard layout, something we would not have found until the last minute if they hadn’t been involved in our testing process. This is also a great example of something we could have identified early by shipping a laptop back and forth – the problem was instantly obvious to a Japanese speaker, but would never have been caught by an English speaker.
5. Be Aware of User Impact
Any major platform upgrade like we performed is going to include a lot of change. In the case of this client, not only was the OS changing (and bringing along a new user interface), but Office was also upgrading (bringing along the new “Ribbon” interface), and several additional software packages were being replaced or upgraded, all involving their own small amounts of user interface change. Finally, a new full disk encryption solution was added that not only changed the way end users logged on to their PCs, but also changed the way service desk personnel needed to perform tasks such as AD password resets and workstation reassignment.
Where possible, user acceptance testing should be performed early in the process. Allowing a representative sample of users to experience the new software allowed the client to identify what the pain points would be early, and to develop training materials to address those changes. More importantly, it allowed the client to develop that documentation in multiple languages and using local language screenshots, to make the documents more friendly to non-English speaking locations. Feedback from training sessions also prompted the client to offer more targeted and in depth training sessions on specific applications where users had more questions. While change management is key for any major deployment like this, the international flavor of our recent deployment meant it was critical to include international users in the testing – they had different experiences based on different languages or business processes, and all of that data needed to be captured and factored in to the training plan.
6. Don’t Underestimate Logistics Difficulties
Our general process at nearly every site was to start imaging machines as soon as users went home for the day, and to stay on site until each had finished and been run through a short post-imaging QA process. However, the physical difficulties involved in getting to and from one of the client offices forced us to change that tactic, and simply initiate imaging in the evening, leave the office, and return the next morning before users arrived to finish up and QA machines. In some cases, this meant early arrivals needed to wait a few minutes for their workstations, and it caused us to be very careful about prioritizing machines in the order we thought users would arrive.
Similarly, getting equipment in and out of some countries is more difficult than others. For one location in particular, it took nearly 6 months to get our backup storage array delivered and through customs, causing us to postpone the site migration multiple times. To an extent this can be mitigated by purchasing equipment available “in-country”, but depending on the hardware, that is not always possible. And of course, there are always visa requirements simply to travel to some locations.
Be ready to be flexible – both with migration time lines as well as on site activities.
All said and done, our migration was successful, thanks in no small part to a large multinational team of resources, and the lessons we learned, especially around early testing and engaging client resources for specific feedback, can be adapted to fit nearly any migration. Hopefully they’ll help with your next migration or deployment effort – good luck!