Are You M&A-Ready?

Quick IT integration is a key to successful mergers. Here's how to line up your pieces.

CIO Jerry Bartlett is on a 12-month countdown. His company, online broker Ameritrade Holding Corp., announced last June that it would acquire rival TD Waterhouse USA for $2.9 billion. On Jan. 25, 2006 -- the day after TD Ameritrade became a legal entity -- Bartlett was already in execution mode, acting on decisions made months earlier, such as which of the acquired company's IT systems and applications would be absorbed, which would continue to run alongside existing Ameritrade systems and what the size of the combined IT organization would be.

TD Ameritrade, along with many other companies schooled in mergers and acquisitions, knows that successful M&A outcomes depend heavily on the expedient integration of the merging companies' IT systems.

"The longer you wait to move to a single set of systems and retire applications, the more expense you carry in terms of staffing and hardware costs and maintenance," says Bartlett, who has shepherded Ameritrade's IT department through seven previous M&A deals. Besides, Bartlett has shareholders to answer to: A 12-month IT integration window was built into TD Ameritrade's earnings expectations.

Twelve months sounds about right to another merger veteran, Norbert Kubilus, CIO at Sunterra Corp. The Las Vegas-based resort company has made dozens of acquisitions in its 16-year history. "My experience has been if you don't complete a consolidation within a year, you rarely realize the financial benefits of the consolidation," says Kubilus, who has been directly involved in 15 acquisitions and has consulted on a dozen more.

And it's not just a question of cost. In many industries, technology is so integrated with business processes that to merge operations, you have to merge IT, says Christophe Duthoit, vice president and director at Boston Consulting Group, a global business consultancy in Boston. "IT can help to achieve a number of merger objectives," he says.

That's why the ability to integrate two disparate IT departments -- and do it quickly -- has become a highly valued skill, particularly in light of today's heightened M&A activity. In 2005, the total volume of global mergers and acquisitions reached $2.9 trillion, a 38% increase over 2004, according to Dealogic LLC, a capital markets technology vendor.

And experienced CIOs have learned that there's a lot they can do before a merger is even contemplated that will increase the chances of success down the road.

Don't Be a Statistic

Although experts say that more than half of mergers fail, a prime way to avoid becoming part of that statistic is to integrate quickly, according to a 2003 study by the U.S. Federal Trade Commission. And that means getting started well before what M&A veterans term "Day One," or the first day the two companies are considered legally merged.

Indeed, while IT has often been "the forgotten child" of postmerger integration, according to Duthoit, more companies today are building an IT postmerger integration capability upfront -- well before they actually go through a merger, acquisition or divestiture, he says.

And all that planning just gets you into that 12-month window; it takes a lot more to get you out the other side. "Even with a well-planned and agile and simple infrastructure, it still takes eight to 12 months to integrate IT functionality," Bartlett says. "You have to assess what gaps you need to fill, and there's a lot of analysis that goes into that."

Since any merger will require a comparison of each company's technology capabilities to identify redundancies, synergies and gaps, a good first step in becoming M&A-ready is to thoroughly document your own infrastructure components and applications, as well as their strengths and weaknesses. This includes an assessment of application availability, scalability, reliability and total cost of ownership, Bartlett says.

"We look at all that, even though we go into the deal with the hypothesis that Ameritrade is the system of choice," he says. "We have an obligation to our clients, shareholders and associates to conduct a transparent analysis."

Northrop Grumman Corp., which has acquired three multibillion-dollar companies since 2001, takes a different approach. Tom Shelman, CIO at the $30 billion global defense company, has defined which of the company's infrastructure components and applications are "non-negotiable" and must become the standard for acquired companies. These include its approaches to security, network access, e-mail and directory services, as well as its IT governance processes. "It's nice to go through an acquisition and not have those arguments and religious wars," he says.

But Shelman has also defined areas where standardization is less important or even impossible. An example occurred during Northrop's 2002 acquisition of Newport News Shipbuilding, which builds nuclear-powered aircraft carriers. "We could never have integrated everyone because of the specialized requirements of being a nuclear company," Shelman says. "Some of their processes required additional oversight."

While documenting your systems, you should also define your core business processes and analyze how well your existing systems support them. "There might be specific applications where you could benefit from the more advanced model of the company being acquired," Duthoit says. "You want an objective and factual decision-making process that enables your systems selection to be done quickly."

Once a merger hits, you'll be happy to have at least some of that analysis work documented in advance. You'll also want to have a process for managing the integration, because two or three months after the deal closes, "the CIO needs to be prepared for absolute chaos, and he'll have to find a way to put that chaos in order," says Dries Bredenkamp, director of the Western region merger integration practice at PricewaterhouseCoopers.

This is the time frame in which the business units begin submitting their systems requirements, which could include anything from 100% data transfer to the acquirer's system, integrating the best functionality from each company's applications or running the systems in parallel.

"If you don't have a project management system in place to accommodate all those changes, you'll not only fall behind, but the costs will add up," Bredenkamp says.

Reducing Chaos

One way to stave off some of this chaos -- or at least divide it into manageable chunks -- is to organize the IT department so that "account managers" coordinate technology efforts for individual business units, Bredenkamp says. That way, not only do you have IT people with intimate knowledge of how well core processes are being supported by existing systems, but you've also got the key relationships and an effective planning method to manage all the components of the integration.

Acquisition-minded companies also work on simplifying their technology infrastructures and applications through standardization. This drives out costs and creates a more agile environment, Bartlett says. "It makes your choices easier when it comes to integration, because you already have a well-thought-out architecture and road plan," he says.

A related effort is to minimize software customization, Kubilus points out. He recalls being involved in an acquisition in which both companies used the same version of Oracle Financials, but because one system was heavily customized, it was difficult to integrate the applications.

Another key area to analyze in advance is the terms of your hardware contracts and software license agreements. For one thing, make sure your software licenses are easily transferable. "If the license isn't written correctly, the software isn't good for anyone you acquire or transferable to anyone you divest," Kubilus says. It's important to know beforehand about hidden costs resulting from the need to buy new licenses.

Kubilus tells of one merger in which a company believed it had 90 licenses for a particular piece of software because it owned 40 licenses outright and 50 through a previous acquisition. Closer inspection of the license agreement revealed, however, that the 50 licenses were invalid because during the prior acquisition, nobody had notified the software vendor of the license transfer, which was a requirement of the license agreement.

"Bottom line," Kubilus says, "make sure that with any agreement you get into, they're extendable to the acquired entity, and if you're acquired by somebody, that you don't have minimum purchase levels you're still locked into."

Integration Aid

Merger veterans have also learned to invest in their technology infrastructures to facilitate integration with those of potential acquisitions. Northrop Grumman, for instance, uses IBM's WebSphere as its enterprise application integration (EAI) hub.

Kubilus has moved a number of Sunterra's systems to the Linux platform to increase their adaptability. He also uses Web services to bridge the gaps between systems.

Based on transaction volumes and a desire for real-time data transfers at Las Vegas-based Harrah's Entertainment Inc., CIO Heath Daughtry chose the EAI approach, using integration software from Tibco Software Inc.

TD Ameritrade has adopted a service-oriented architecture model, in which it has defined 40 to 50 key services. When it needs to add a new function as a result of a merger - such as a certain type of balance transfer or enhanced report -- IT can bundle existing services to create a new application, written in Sun Microsystems Inc.'s J2EE, rather than starting from scratch. "It's something we can do in a standard eight-to-10-week development cycle," Bartlett says. "That makes us agile."

The specific choices you make are less important than the planning itself, Shelman says. "Once you get into the acquisition, that's the wrong time to start that debate," he says.

But beyond any technology measures, by far the most important preparation is to figure out how IT can insert itself at the front end of the merger decision-making process. This means playing a key role in due diligence and, better yet, if you're the acquirer, making sure you're on the team that selects the target company.

"For any company that's heavily reliant on IT as an enabler, the CIO should be there at the get-go," says Harold Schroeder, president of Schroeder & Schroeder Inc., a management consultancy in Toronto. "Only he can say whether the companies' systems are compatible, whether the target firm is being held together with Band-Aids and bailing wire, and how difficult it would be to move to a single system."

Michael Spellacy, a partner at Boston Consulting Group, recounts a recent near-merger between two major banks in the U.S. that fell apart when the due-diligence team estimated it would take five years to integrate the two entities' extremely complex IT infrastructures.

Even when IT doesn't play a deal-breaker role, it's the only department with enough insight to estimate integration costs and potential IT cost reductions with some degree of accuracy, which can ultimately affect the numbers on the table, Shelman says. And if IT is not involved, it may find itself having to live up to overly aggressive savings commitments.

"If we're buying a company whose security or IT systems were in such disarray that it would cause a huge investment just to keep the audit committee happy, we'd want to know that before we finalized the offer," Shelman says. "And I don't think anyone other than the CIO can make that evaluation."

In reality, however, "CIOs still don't have enough of a voice in the deal process," says Gregg Nahass, a partner at PwC Advisory Co. and leader of the company's Western region merger integration practice.

Indeed, Shelman had to make his own way onto the due-diligence team at Northrop. "The CEO never said, 'Call Tom. He'd better be involved in this,'" Shelman says. Instead, after Northrop's first merger, Shelman took it upon himself to meet with the M&A team and gave it a blueprint of how to make the next merger happen more smoothly. When that input proved valuable on the next deal, Shelman's team was recognized as a linchpin. "If you're not involved, you need to find out how to get involved," he says.

Spellacy says that looking at a potential merger from the IT perspective comes down to answering two key questions: What level of commonality in systems and operations can you help achieve by bringing the two parties together, and what is the integration effort required to make that happen? "Is it just people and time, or do you have to write new software or middleware or entirely new systems?" Spellacy asks. "Or do we need a fundamental rethink of how you service the new business line with the systems you have?"

Preparing now so you can answer those questions early in the game can mean the difference between success and failure.

Brandel is a Computerworld contributing writer in Newton, Mass. Contact her at

Copyright © 2006 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon