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 CIO.com
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
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
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
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
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
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
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
“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
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
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
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.”