by David F. Carr

What IT Leaders Need to Know About Getting Mergers Done Right

Dec 23, 200817 mins
Mergers and Acquisitions

Whether it's a shotgun merger or a planned acquisition, chances are you're not ready for it. Here's how to change that.

In good times, mergers and acquisitions are often driven by dreams of synergy, the idea that two successful companies can unite to capture a bigger piece of the market and be more profitable through economies of scale. In bad times, they can be driven by desperation, with one company leaping into the arms of another to avoid collapse.

More on

How to Get More from Mergers and Acquisitions

When Your Company is a Target

‘Shotgun’ Mergers in Financial Services Put IT Teams and the Success of the Deals to the Test

7 Tips for Surviving a Merger or Acquisition

How CIOs Can Make Mergers, Acquisitions and Divestitures Work for Them

In Tough Economy Chrysler Looks to IT to Trim Expenses, Improve Business

How Coty Tackled Post-Merger Supply Chain Integration

In the past few months, we’ve watched mergers between distressed financial institutions arranged over a weekend, with the federal government playing matchmaker to address a severe financial crisis. The rushed nature of these transactions presumably means that the companies skipped some steps in the normal merger and acquisition planning process. Ideally, the parties to a merger go through due diligence to assess each others’ strengths and weaknesses, which includes examining information systems and networks to assess the likely length, cost and feasibility of systems integration.

For the CIO to be intimately involved in that process is a best practice. Or so says every CIO. But in reality, that doesn’t happen often enough, even in the absence of an economic meltdown. According to a 2007 study, “Wired for Winning,” by Deloitte, fewer than 30 percent of companies get IT involved in the planning process before a deal is closed. The study also found that this lack of involvement has serious consequences. In one case involving a global manufacturer, IT integration costs exceeded premerger estimates by more than $100 million. CIOs feel the pain: Only half of respondents to our 2009 “State of the CIO” survey said they are involved appropriately early on in mergers and acquisitions.

So face it. The CEO and the board, in hot pursuit of a market opportunity or acting in response to competitive pressure, are likely as not to stampede past the CIO and set goals for the transaction based more on back-of-the-napkin estimates than thorough study. Even when the CIO is intimately involved, he probably won’t have veto power over the deal. Instead, the CIO’s role is more often to set realistic expectations for how long integration will take and what it will cost. Here, CIOs who have been through multiple mergers and acquisitions share their best advice for what to do when a deal is less than ideal from the IT perspective.

You Figure It Out

“At least in my experience, never once did a deal get stopped because of some technical issue,” says Allan Hackney, SVP and CIO at John Hancock Financial Services and veteran of more than 50 M&A transactions stretching back to his days at AIG and GE Capital in the ’80s. Joe Beery, the former CIO of America West and US Airways, agrees. “The CIO’s role is figuring out how we will accomplish the integration.”

Beery presided over systems integration for the merger of the two airlines. Although he was involved with the due diligence, he never felt he had the power to say no to the merger, he says. “It was more like, ‘We’re going to do this deal. Joe, go figure out how to get it done.'”

Beery is now CIO at life sciences company Invitrogen (currently merging with Applied Biosystems to form a new company, Life Technologies). He describes the experience of integrating the airlines so that they could operate as a single carrier within 24 months—a goal CEO Doug Parker had publicly committed to achieving—as “tough and grueling”. The “single carrier” goal meant US Airways had to meet specific Federal Aviation Administration standards for unified operations, requiring the integration of many back-end systems. Although he pulled it off, Beery says, “I’m not sure I would wish that kind of activity on my worst enemy.”

Charles Beard, who spent years consulting at the Oliver Wyman division of Marsh & McLennan and KPMG Consulting (now BearingPoint) before becoming CIO at Science Applications International Corp. (SAIC), notes Beery’s experience as an example of how the structure of a deal can significantly influence the IT strategy that a CIO must follow. In the America West and US Airways transaction, the decision to immediately integrate the two carriers had a major impact on the IT environment.

If the carriers could have come together under a holding company structure operating separately, that business strategy would have dictated an entirely different—and more easily executed—IT strategy for supporting the merger. Beery could have provided some common services to two independent air carriers as an interim step. For that reason, Beard argues that even the due diligence phase is too late for the CIO to be getting involved. He or she should really be part of the discussion about the shape of a deal to help guide decisions by handicapping the odds of success. Depending on the intent of the transaction, the CIO can design the technical due diligence and contemplate the impact on the current IT environment. He can provide these findings to corporate development during transaction negotiations.

Beery says he was involved in making those strategic decisions and ultimately saw the logic of pushing for full integration. Too often, however, the CIO’s role is merely to cost out the implications of a decision that’s already been made, Beard says. And even when the CIO is consulted, he says, “once the decision is made, it’s our job to salute smartly and carry out orders.”

The Top Priorities

The good news, sort of, is that whether or not you’ve been involved with due diligence, your first steps after a merger or acquisition may be similar. The systems of a large organization are too complex to be taken in by the quick peek the acquiring firm is allowed before a merger is consummated, says Graham Seel, CIO at California Mortgage and Realty. Seel spent two decades at Bank of America and worked on mergers including those with NationsBank and FleetBoston and the acquisition of Continental Illinois.

But in a shotgun merger, there’s pressure to work faster and more intensely to prioritize which systems must be integrated first, as well as to structure the new IT organization, says Peter Blatman, a principal with Deloitte. So when the order to merge comes (whether from your CEO, a bankruptcy judge or the Secretary of the Treasury), it’s a good idea to know where to start.

“If it were me in one of these situations, I would concentrate on a few things that are must-dos, where the faster you do them, the more likely you are to avoid problems,” says Hackney, the John Hancock CIO. First on his list would be to control and integrate financial systems—not necessarily merging general ledgers but figuring out how to consolidate the numbers and integrate accounting practices. “In those systems lies the truth about what’s happening with the company,” he says. “The sooner you can peer into that data and really understand the situation—and the sooner you surface any surprises, any issues, any smoking guns lurking in the background—the better.” Even when there’s adequate time for due diligence, you learn to expect some surprises, he says.

Second on Hackney’s list: network and IT security integration. “The sooner you can reconcile their security policy to yours, the sooner you can link their networks to yours, which allows you to assimilate the acquired people more quickly,” Hackney says.

Unfortunately, the CIO typically doesn’t find out about security weaknesses until after the deal is executed, he says. In a previous role, Hackney saw security weaknesses surface with the acquisition of relatively small firms in India and Southeast Asia. They had a greater tolerance for information security risk. “Security can be a real hindrance to bringing an acquired entity into the fold,” he says.

Hackney would make integration of financial, security and also distribution systems his top priorities in any acquisition, but he says they would be even more urgent in a distressed one.

Maintain Momentum

While no one likes to be rushed, in some ways urgency is a CIO’s friend. That’s because the early days of a merger are when you’re likely to get the most accomplished. “If you can’t get majority of the work done on IT integration within the first six months, it doesn’t happen,” says Deloitte’s Blatman.

The merger team typically builds up “a good head of steam” at the beginning of the process, Blatman says, but tends to run out if integration drags on too long. Often, a merger team that was pulled together ad hoc, on short notice, can lose momentum as people drift back to their old jobs. In many instances, hybrid solutions and workarounds that were supposed to be temporary tend to calcify and become permanent.

Blatman has seen the consequences in a series of recent consulting engagements where “companies are asking us to help them consolidate systems that are the results of acquisitions that happened years ago, but the integration was never done.”

“The back office is where you tend to lose momentum,” Hackney says. In the short term, systems that aren’t visible to the customers can operate in parallel without any dramatic consequences. The pain comes later, when the business must meet some broad requirement like compliance with the Sarbanes-Oxley Act, which requires programming changes to be made in multiple systems that serve the same function.

“The other place it hurts you is with your next acquisition,” which will need to be integrated into multiple back-end systems rather than a unified one, Hackney adds. “If the possibility exists that you’re going to be doing another two or three acquisitions, that’s going to become unmanageable at some point if you don’t do the integration.”

One obstacle to speedy integration may be the aversion IT managers have developed to “big bang” integration projects that often fail. Jan Brecht, VP of IT management and CIO for the Americas with Daimler Financial Services, was advised by consultants to take an incremental approach to spinning off Daimler Financial’s operations after Daimler and Chrysler decided to split up in 2007. But with the support of his CEO, Brecht successfully squeezed it down to eight months, rather than the recommended two years.

Although this was a divestiture rather than a merger, the scope of the challenge was similar, involving a transition for all Daimler Financial’s systems away from Chrysler’s applications and data centers. The incremental approach would have been the safer course, Brecht says, but it came with trade-offs. During the transition, Daimler would have had to maintain temporary interfaces between the new systems it was phasing in and the old Chrysler systems, and those interfaces would have introduced their own complexities. Brecht ultimately decided the cost of that hybrid solution outweighed the risks of the alternative. “If you’re determined to do it as fast as possible, while having enough contingency plans in place to manage the risks, then you can dare to do a big bang,” Brecht says. Making it work required a tightly coordinated plan in which many tasks that are usually performed sequentially, such as development and testing, were instead performed in parallel (with incremental testing of functionality as it was delivered).

The team also went through five practice launch events before the official “go live” and drew up 14 contingency plans for potential problems they anticipated. For example, before going live on the newly separated system, data had to be ported over from Daimler Chrysler over a Saturday night. If testing revealed problems with data accuracy, the first contingency was to retest and reextract the data up until a deadline of Sunday at noon. If that didn’t work, the next backup plan was to abort and go back to using the DaimlerChrysler systems for one week, then try again.

Like Blatman, Brecht says that in a merger, he would be wary of temporary solutions that bridge between the systems of two firms rather than combining them. For example, if IT does too good a job of providing management with a unified business intelligence view that obscures the lack of integration between the underlying systems of merger partners, the funding to complete that integration may never materialize, he says.

Architect for Success

If you’re trying to figure the odds that a merger is in your future, the fact that we’re heading into a recession actually has a mixed impact. Particularly in combination with tight financing, a poor economy saps the confidence and ability of firms to execute these transactions, says Tayo Olatoyan, a senior research analyst with the FactSet Mergerstat service.

According to FactSet, there were 295 mergers between U.S. companies in November, down 38 percent from the peak of 653 in July. During this period, the dollar value of those deals dropped 98 percent. A similar pattern unfolded during the last recession, which started in the wake of the 9/11 terrorist attacks and stretched into November 2002. The total number of merger transactions for 2008, as of late December, looked likely to drop about 32 percent, compared to 2007.

On the other hand, when mergers are driven by desperation (or, in the case of some financial services companies, the promise of a big tax break), things can happen suddenly. Whether or not you see a merger coming, you can increase the chances that you will be successful by being prepared.

For example, you might be able to make your systems more merger-ready by embracing service-oriented architecture (SOA), a network-centric approach to defining modular information services that can be recombined to create new applications. Because it anticipates the need for integration, SOA is supposed to make it easier to connect systems from two different companies so they can function as one.

“I think a CIO today really has to be planning and designing and developing their architecture to accommodate merger and acquisition activity,” says Beery. SOA is “one good option” for pursuing that goal, he says.

Beard notes that SOA would be more useful if both parties to the merger had embraced that style of integration than if only one had. That’s part of the reason why, if you can, it’s so important to find out early what a merger partner’s systems architecture looks like and how up to date it is, he says. Beard sees potential merger help coming from other recent technological innovations, such as software as a service and cloud computing, because the merged organization can more easily tap into an externally hosted customer relationship management application or storage utility than it can integrate in-house systems. “You can use these solutions and not have to bring them into a data center that may already be constrained,” Beard says.

Deloitte’s Blatman says the client who impressed him most with its acquisition prowess made technical architecture part of a broader strategy, which also involved developing several standardized “playbooks” for handling different sizes and types of acquisitions. “They asked themselves, ‘If we’re going to continue to grow by acquisition, what do we do with our IT infrastructure to make it acquisition friendly?'” he says. Among other things, the company’s approach led to a decision to phase out proprietary software applications in favor of commercial packages. One reason: It tends to be easier to import another company’s business data into a more broadly used commercial application than a homegrown one, Blatman says.

Put People First

Integrating technology is important, but it’s not the main reason mergers succeed or fail, argues Seel of California Mortgage and Realty. “To state the obvious point that gets ignored all the time: Mergers are about people. I’ve seen that obeyed to great success and I’ve seen it ignored at great cost.”

Other key factors Seel considers obvious but which “in the heat of battle we tend to forget” are how well the merger team bridges corporate cultures and pays attention to customer needs.

When Seel worked at Bank of America during its merger with Continental Illinois, he learned quickly how vehemently many at Continental Illinois opposed the deal. During a visit with the Continental Illinois team in Chicago to work on IT integration and related aspects of the merger, he identified one influential, midlevel customer service executive who was outspoken in her opposition. A key turning point in the merger process came when he, somewhat nervously, took her to lunch.

“I made her aware that she had enormous influence and that she had a choice of how to use that influence. It was about an hour-long conversation, and at the end of it we went into a meeting, and from then on she was talking about, ‘Here’s how we’re going to make this work,'” Seel says.

Later, during Bank of America’s acquisition of FleetBoston, Seel recognized that the IT staff had been given very little information about how they fit into the merged IT organization. To bring them into the fold, he asked them how they saw their role. “I asked them to tell me: What are you proud of? Tell me what you think you bring to the table. And they were still talking about that years later.”

Of course, the problem with easing employees into a merged organization is that they already suspect, with good reason, that some of them will wind up losing their jobs. That can be a terrible distraction, says Steve Terry, CIO and senior vice president of customer operations with Beneficial Financial Group. “So what you want to do is find the keepers and the people who are going to be set loose,” he says. “The sooner you do that, the sooner the acquisition is going to be successful.”

Unfortunately, when everyone is under pressure to do more with less, you can’t offer even the survivors very many assurances that their jobs will be secure for more than a few months, Terry says. But you should try to offer whatever conditional assurances you can, he says. “You may be able to say, ‘This is the team for the next six months, and if we do everything we can to be successful—and we can do it—then there should be no more layoffs.'”

While Terry has definite opinions on how to manage mergers and acquisitions, Beneficial’s strategy has been to avoid them. “We had some very significant conversations about how we pursue growth,” he says. Their analysis of the cost of acquisitions led them to a strategy of organic growth through new products or geographies. “It turned out to be a good education for my peers to understand the cost of technology if we take on something different than what we have,” he says.

In particular, he underlined the challenge that would come with absorbing another company’s policy management system and possibly having to run it in parallel for years if they could not find a single system to model the logic behind both firms’ insurance policies.

The business world would be a better place if that kind of analysis were more common, Terry says. “I believe the CEOs and CFOs who come to value IT’s contribution as a deal maker or deal breaker will make much wiser investments of corporate capital.”