You’re San Francisco, they’re New York.
You’re Mac, they’re PC.
You’re laid back, they’re locked down.
Congratulations. Your organizations are merging, and you’re in charge of IT integration.
What do you do now?
Pretty much everyone agrees that it’s important to slow down and figure out where you’re going as a merged organization before you do anything – and to realize that there is no one perfect solution, and each possibility has its own advantages and disadvantages. “The #1 thing the CIO wants to do is build a broad consensus around the collection of minuses the company is willing to accept,” says Jeffrey Bolden, managing partner and technical architect for Blue Lotus System Integration and Data Conversion, a Princeton, N.J. consultant that specializes in this area.
Step One: What is the Current State?
First, take stock – not just of hardware and software, but processes and people as well.
“It was the first time I had done it, and it was a trial by fire,” remembers Jeremy Colwell, owner of CPG Systems, in Vancouver, Canada, who used to work for a multinational manufacturing firm that took part in a series of consolidations and acquisitions. “The lesson I learned is that the first thing you have to do is understand completely what you have – hardware, software, then understand what you have in terms of expectations of service levels.”
The problem, Colwell explains, is that some users are accustomed to higher service levels than others. It’s like the scene in Annie Hall, where the therapists of the Woody Allen and Diane Keaton characters ask them how often they have sex, and he says “Hardly ever – maybe three times a week,” and she says “Constantly – I’d say three times a week.” The facts are the same; it’s the expectations that are different.
The reason this was a problem for Colwell is that when migrations actually started, performance changes were noted by some people and not noticed by others. “That led to a lot of grief,” he says. For example, when the system was set up such that all the users had access to Microsoft Exchange over a virtual private network (VPN), the users who were accustomed to network access to the Exchange server weren’t used to waiting a few seconds to download a large attachment to the server, he says.
The other advantage of doing an audit of IT applications is that it gives the organizations an opportunity to search for redundancies, says Christian Weichelt, a director at alfabet, a business management vendor.
In addition, Colwell says, it’s important to make sure the licensing is in line. “As an IT guy, for me to be sitting there doing all this paperwork and documentation so I understood what was there, what the licenses were, where the software was, a paper trail for the Microsoft licenses – it was a killer for me,” he says. “I hated doing paperwork, and I was unprepared for the amount of it.”
Integrating with the other IT staff is also important, says Sarah Baker, director of operations for mSpot, who has been in the position of being both the acquired, when Compaq acquired Digital Equipment Corp., and the acquirer, when Webvan acquired Homegrocer. “It's important to connect with the staff you are inheriting as soon as possible, and while you set a new path,” she says. “They are experts in their company. Treat them as such. They are important for a smooth transition.”
For example, make an effort to understand the existing staff’s plans and goals before you came on board, and see whether you can leverage their projects into your overall scheme and get some things done that you had on the back burner. “That gives them an immediate win as a partner in the merged organization,” she says.
Step Two: What Sort of Integration Will You Do?
There’s four options, says Bolden:
- Treat the merger as though Company A is basically buying the client list of Company B.
- Move Company B’s customers into the Company A system in a gradual process with customization.
- Run both systems simultaneously and pass data between them.
- Initiate a system integration and data conversion project, which might end up using different hardware and software altogether.
There are advantages and disadvantages to each of these methods, Bolden says.
For instance, the first method is the cheapest, though the prospect of keeping Company’s B’s client list can be low, if Company A changes things too fast. “But it’s super cheap, very efficient, and the stock price will look good for the next quarter or two,” Bolden says. “It’ll be around three years when this will bite you, and bite you hard. But CIOs may not be around that long.”
The second method may seem like the best of both worlds – compromising – but it can often be a dismal failure when the two companies are just too different, Bolden says. What’s more likely is that the compromise will end up regressing to one of the other three solutions – after the organization has already spent time and money on it.
For example, when Webvan acquired Homegrocer, the IT staff were not local, which made it hard for them to see a way to gain a place in the larger organization, which was focused on the Bay area, Baker says. “They were not too happy with the acquisition itself, and they all left soon after.”
“When a company I worked for was acquired in 2009, I found myself in the position of assisting two integration managers – one from the original company and one from the acquiring company,” recalls Tim Havenith, now a first-line engineer for Information Technology and Services, Swindon, U.K. “We looked at the difference between the two systems and the risks that we would face by changing the current system to that of the acquiring company. We detailed every point that we could back out if there were errors."
One thing Havenith discovered is that the acquiring company was overconfident in terms of the time required to complete the changeover. Consequently, he recommends that IT administrators ask to be shown the new setup on a blank machine at a nearby office. “Then you not only understand the time for setup, but will be in a good position to start preparing users for the new software,” he says.
The problem with the third method is that it doesn’t result in any synergies or efficiencies of scale, Bolden says. In addition, it can be irritating to customers when they run into different corporate “silos” of people and policies instead of the level of cooperation they expect, he says. On the other hand, it is also the least stressful for the employees.
Step Three: Crafting a New IT Organization
The fourth method is basically starting from scratch, beginning with a systems integration and data conversion project. “Here are the customer bases, here are the vendors for Company A and Company B and their relationships, here are the things Company A did well, here are the things that Company B did well, here’s what we aimed to achieve from the merger, here are areas where the systems perform well, and here are the areas where they did badly,” Bolden says. At that point, a team needs to do a serious assessment of what the merged company needs to look like, using the strengths from both partners, he says. In addition, this can be difficult to do when the two organizations are greatly separated in size, Baker says.
Don’t assume that Company B employees will hate everything about Company A and vice versa, Bolden adds. Though Company B “failed,” which is why it was able to be acquired in the first place, Company B has things that are attractive to Company A – which is why it was acquired – and employees from Company B are aware of the advantages Company A has, he says.
“Not all your existing policies may transition seamlessly,” Baker says. Make sure to have Company B study Company A’s processes and participate in the transition plans. “Look for an opportunity to adopt a better plan from their organization and drop ‘bad habits’ from your own organization,” she says.
That’s where creating your integration team comes in, Bolden says. “The CIO is not going to have time to chair that committee,” he says. “Answer the basic questions, like ‘Why did we buy Company B?’ and make sure the things they want are still there and not the things they don’t want. You spent millions of dollars to buy Company B. Why throw them away?”
So the people from Company A who should be assigned to the integration committee are the ones who saw value in Company B and who can also do self-criticism – as well as ensuring that they don’t want a “separate but equal” parallel system like option 3, Bolden says.
However, don’t have Company B lead the transition plan project, Baker suggests. “You do not want the person least likely to stay on to run the transition,” she says.
Also watch for “responsibility collapse,” Baker says. “Some tasks will be combined into one, and somebody loses a responsibility,” she says. “Somebody may lose their pet technology.”
If downsizing is part of the acquisition, it’s just going to be tough, Baker says. “You will not have experience with their staff, so you have to use historical data to make decisions. Then do it as fast as possible – don’t let it linger. Letting them linger to ‘battle it out’ doesn’t work in many cases.”
As far as the actual process of how the team should tackle the problem, there are a number of approaches, including hiring a consulting company to work on the details, or using a process definition like that Merging Information Technology – An Organized Approach (PDF), from Jefferson Associates, a technology and IT business process consulting firm.
The downside of the fourth method is that it’s the most expensive, Bolden says. “You’re paying for analysis, labor, and the new system,” he says. “Merger timelines can be in years. So you’re running three systems for a while” – Company A’s, Company B’s, and the new one. “The advantage is you actually achieve what you wanted to achieve with the merger.”
Most important is to make sure you do your homework and look out for problems. “If I had to do it over again, I would spend more time looking for the ‘gotchas’ instead of waiting for them to hit me,” says Colwell. And due diligence in advance is a thousand times more useful than anything that can be done after the fact, Baker agrees. “Know how you match, and how not.”