Another article on change management. In "3 Hands-on Techniques for Managing Operational Change in HRIS Projects" I touched briefly on aspects of rollout projects in the second technique. This one is fully dedicated to the world of inter-/multi-/transnational HRIS projects:
Change Management in International HRIS Rollout Projects
“Change management” has recently become a compulsory element whenever managers of large scale IT initiatives presented their project to the board. It gets even more attention, when the project happens in an international / intercultural context.
As it is commonly accepted that a lack of good change management is one of the major sources of project failure, this seems like good news. However there are two problems with this:
• Quite often any reference to change management remains a mere lip service. Once project teams including project managers get entangled into the day to day technical problems, they lose sight of the “soft” elements of their work and quite often they are happy to forget about the change element, because they don’t have the confidence and capabilities to deal with it anyway.
• When solutions already implemented at the corporate centre are to be rolled out to subsidiaries in other countries, the prevailing notion is that these subsidiaries are facing major change and need some help from corporate IT or the business functions affected by the new IT systems. However, in most cases there is also a considerable transformation required at the corporate functions involved in order to manage the international rollout successfully and operate efficiently in a the more diverse context afterwards.
In this article we look primarily at this transformation required at the corporate centre based on our in a variety of projects.
A cooperative approach for change
When an IT system used in the mother country is to be rolled out to a subsidiary, there are two common approached corporate teams take:
• They work on the assumption that they know better and that the subsidiary will put up resistance that has to be overcome by force, usually relying on
support from the executive board or other powerful sponsors. We call this “The Conqueror’s Approach”, because they look at the subsidiary as some kind of castle that needs to be conquered. In most cases the support from powerful sponsors doesn’t take them as far as they hope, if they lack cooperation at a local level. Without local knowledge, the conquerors often get caught in an exhausting siege.
• The second approach also starts with the assumption of superiority, but is based on a charity mind-set. The corporate team believes they are bringing valuable new technologies and processes to the subsidiary and therefore think the local management and employees should gratefully embrace the changes they are suggesting. We call this “The Missionaries Approach”, as it reminds us of 18th century missionaries, who felt they liberated locals from an inferior way of life and thought that everything they brought them was an improvement. While this approach looks nicer than the conqueror’s approach at first sight, it leads to a similar outcome. Local management and workforce consider the corporate team as arrogant and blind with respect to the differences between countries. Eventually it will also cause strong resistance, though probably set up in a more subtle way.
While few people would consider themselves to be using one of those approaches, you can identify strong elements of one or even both of them in most 
international rollout projects, most notably in ERP rollouts, where the implementation of the system is likely to change the way an organisation works to a considerable extend. HR processes, even when excluding payroll, are strongly influenced by local legislation, institutions and culture. When changing them you ignore local knowledge at your own peril.
So the attitude “They have to change and we’ll tell them how” leads to various problems and missed opportunities:
- Many local employees will resist any change and may try to sabotage the project
- Knowledge and relationships required in the local environment will not be used in the project and may even get lost for the business for good.
- Processes made up thousands of miles away and forced upon the subsidiary often don’t work at all.
- Best practise and unique valuable skills of the local subsidiary, which could be leveraged for the benefit of the whole organisation, are ignored.
It is obvious that a more cooperative approach is required. But why is it that so many projects fail to achieve this and therefore don’t bring about the full benefit for the organisation?
The answer is simple: change is always considered to be something for the others, in our case, for the local subsidiary. However, an international rollout brings about as much need for change for the corporate functions involved as it does for the subsidiaries. Our experience shows that it is the transformation in the mother country that makes the whole organisation fit for a global rollout and also makes it much easier to get buy in for global standardisation on the local level.
The forgotten half of change
The need for change on a local level is undeniable and we are not arguing against the fact that some standards need to be applied globally. What we want to emphasise is that local change outcomes will add more value and be easier to achieve, if the need for corporate change is also considered. The change required from the corporate centre can be divided into four different categories:
It is not difficult to guess that having the right attitudes and mind-sets in the corporate team is the most important element. However, the best way to change them and even to demonstrate a need for change in the first place is to start with the other three elements as the need for change is much easier to see there. We will illustrate this with a few examples.
Change requirements in corporate IT processes and technology
If an HRIS team has so far been responsible for running a system in the mother country only, then there are quite a few obvious changes they need to make to their processes, once the system is rolled out globally, such as:
- Different time zones may require a 24/7 support, where 10/6 has been sufficient so far.
- Different languages require a multi-lingual user hotline.
- Changes to the system need to be discussed with many parties and therefore take more time to be approved.
- Patches have to be implemented more often as they have to cater for legislation and other requirements from various countries.
- Change drivers in technology can be as basic as differences in client hardware and software across subsidiaries starting with special characters available on local keyboards
These are only a few examples and often they affect day to day in IT operations far more than generally expected. You should of course try to standardize processes and seek synergies. However, this does quite often require changes in the mother country to get to a process, which can be used globally.
Change requirements in corporate business processes
Again, achieving a certain degree of standardisation across business processes can help to reduce cost, and also increase the quality of global processes. However, legislation, markets, geography, and various other factors set a limit to the degree of standardisation that can be achieved in any business process - be it payroll or recruiting.
The degree of localization required from a global IT system is usually underestimated by the corporate team at least as much as the possibility of standardisation is underestimated by local teams.
Attitudes, mind-sets and culture
Many problems that seem to originate from technology or process are actually due to attitudes and mind-sets on local as well as corporate teams. The biggest problem here is the common attitude in corporate teams that it’s the local subsidiaries that have to change to accommodate the blessings of corporate standardised processes and technology. It is this attitude that leads to the conqueror’s or missionary’s approach mentioned above and causes much of the resistance observed from the local teams.
Therefore, working on the attitudes of the corporate rollout team is paramount to minimize resistance and maximize benefits of the project. This is not as simple as it sounds because the mix of national and corporate culture that needs to be addressed goes right down to the basic assumptions Edgar Schein illustrates as the core of culture:
However, it is worth the effort. Aim at creating an open mind-set, which appreciates that some things that work in one country may not work in others and that best practice from local subsidiaries can also be used to improve processes on a global level. You also need to make it clear that some processes are likely to become more complicated, if they are to accommodate a variety of countries. Just demonstrate the benefits to show the changes are worth the effort.
In the long run, you are likely to find opportunities to develop centres of expertise in subsidiaries to take over some corporate tasks. 
However, this is usually nothing to address in the first step, as it is likely to cause even more fear and resistance on the corporate level.
A few best practises to start with
Some best practises to get the corporate team on board:
- The fact that you’ve done rollout projects already does not mean that it can’t be done in a more efficient and effective way, once the right attitudes and capabilities are in place.
- Demonstrate the need for change and its benefits using simple examples (like the IT processes mentioned above).
- Don’t condemn the “old ways”, but show how to build onto them.
- Make it fun and a positive challenge to explore cultural differences between various countries and discuss their implications.
- Allow for the learning curve by having some training before the start of the project and starting the rollout with “easy” countries.
To make the rollout project work on a day-to-day basis here are some best practises to observe:
- Have face-to-face meetings between corporate and local teams as early as possible.
- Follow up with regular web meetings, e.g. once a week, while the teams are not at the same site.
- Provide a chat room and wiki for online communication
- Define slots for ad hoc communication suiting corporate as well as local time zones.
- If the language at the corporate headquarter is not the project language (usually English), make sure that the corporate team is using the project language for communication and documentation.
- Having someone with local language skills on the corporate team can make a big contribution to gaining local buy-in.
These are just a few small points only scratching on the surface of a huge topic. However, if you get an idea how not only the subsidiaries, but the corporate centre as well, need to change, this is an excellent starting point to get away from the typical single minded change approaches and open your organisation up to exploit the opportunities hiding in an international rollout project. The road ahead is definitely worth exploring:
Enjoy the journey!
You can connect with me on Twitter: @svenringling
- SAP Managed Tags:
3 Comments
