Finding the Time Bombs

Knowing your own IT operation is the key to sizing up the other company's.

Amidsize Midwestern bank learned a painful lesson last year when it acquired a savings and loan (S&L). During the premerger due-diligence phase, the bank was given an IT head count by the S&L. The head count hinted at a time bomb that would later destroy the financial projections on which the deal was based.

"We got initial staffing numbers, and it looked like a very small IT organization," recalls Julie Giera, a vice president at Cambridge, Mass.-based Giga Information Group Inc. who observed the acquisition but declines to give the real names of the banks involved. Nevertheless, the bank made assumptions about the types of people in the S&L's IT shop. "Unfortunately, after the deal was done, it turned out that all the technical expertise - software development, maintenance programming, all of it- was delivered by a consulting firm. What was left [inside the S&L] were project managers.

"The bank was held hostage," Giera says. The consultants' rates zoomed from $65 to $150 per hour, causing the bank to overshoot its consulting budget by 560%. Worse, the time needed to merge IT and other operations increased by 50%, from 12 to 18 months.

Sizing up another company's IT systems before signing a merger or acquisition deal is difficult because time for such due diligence is usually short, and the parties are fearful of giving up confidential information in case the deal falls through. Nevertheless, there are ways to spot time bombs and to see if all those IT cost savings the CEO is promising are really attainable.

Peter Campbell, CIO at XO Communications Inc. in Reston, Va., is a veteran of mergers and acquisitions in the telecommunications industry. Given some metrics about one's own IT, it's possible to get some quick insights from the other company's financial data, he says.

Campbell splits IT into two big groups: applications and operations. Applications are divided further into categories such as billing, customer care and budgeting, while operations are broken into groups such as mainframes, midrange, end-user computing and networking. Costs in the various categories are then related to overall business metrics such as number of employees or revenue.

"For example, I see that for every dollar of revenue, we spend 5 cents on mainframe operations, but they spend 10 cents," Campbell says. "With that kind of benchmarking as a starting point, you have a basis for discussion. Why do you cost 10 cents and I only cost 5 cents?"

That kind of analysis can spotlight areas that may cause problems after the merger or acquisition deal is signed. And it helps home in on areas where cost savings are most readily obtainable. For example, Campbell says, his company may have one desktop support person for every 120 employees, while the acquisition target serves just 80 employees with each support person. Campbell says he might then project a 33% savings in support costs at the target company by moving it to his model of centralized support and automated software upgrades.

But Campbell cautions against comparing the cost of apples to the cost of oranges. For example, if one company leases PCs and the other buys them, or if one company assigns them to IT and the other to end-user departments, it may be difficult to compare their costs meaningfully. "You may end up finding some interesting accounting issues," he notes.

The analysis and benchmarking that Campbell recommends may well spotlight your own weaknesses, he adds. "What you have to guard against is the arrogance of the acquirer," he says. "You are after best practices, and you should see efficiency gains in both companies."

Know Thyself

Indeed, any evaluation of another company's IT systems should begin with a self-assessment by the acquiring company, says Joel Goldhammer, a vice president at A.T. Kearney Inc. in Chicago. "What's the state of my architecture? How's my network? What ERP systems do I have? Where am I getting most customer complaints?"

The strengths and weaknesses so identified can then be weighed against those of the other company. For example, Goldhammer says, "if I feel that my biggest problem is getting my call centers to work well and they have outstanding call centers, that's a synergy I can get really excited about."

Goldhammer adds that detailed "best-of-breed" comparisons of every application at each company are a waste of time. "It's at too low a level of detail. You need a plausible answer that's quickly implementable with high reliability. The cost of the last 5% isn't worth it," he says.

Michael G. Parks, CIO at NorthPoint Communications Group Inc. in San Francisco, was an IT executive at Wells Fargo & Co. in 1998 when it merged with Norwest Corp. Parks says Norwest hadn't bothered much with IT due diligence when it acquired smaller financial institutions.

"Norwest used a cookie-cutter approach," he says. "They really couldn't care less about the systems they were acquiring, because they are just going to walk in and impose their own systems in a very routine way." Norwest's due-diligence checklist focused on business and customer issues, not on IT, Parks says.

But that approach may not make sense when merging with a large, complex organization, Parks says. "You can't migrate those customers down a cookie-cutter path, because you have so many specialized products and a lot of automation to back them up," he says. In the Wells Fargo/Norwest "merger of equals," for example, the parties combined their respective applications very slowly, one by one, with a keen eye on customer impacts, he says.

Indeed, "where companies trip up is they make a decision that's completely logical, except that they forget the customer. At every decision point, you have to test it: If I do this, what will my customers see? What will they feel? Can I explain it to them? How do they adapt and cope?" Parks says.

Jonathan Poe, a vice president at Meta Group Inc. in Stamford, Conn., says evaluating another company's IT systems must be framed by an understanding of why the company is being acquired. Is it to acquire market share? An expanded product line? Access to key customers? State-of-the-art operating facilities? Brand reputation? An e-commerce capability?

The answers to those questions will tell you how to judge the merits of the acquisition's IT assets, Poe says. "When I'm going in to look at a company, I'm looking to see what unique things there are, as opposed to 'How do you do accounting?' " he says. "I have to understand what my basic infrastructure model is and where I'm adding value and where I'm not."

The Price is Right - Maybe

Investment bankers who put together merger and acquisition deals often project IT savings far in advance, based on experience with similar deals. Then some hapless CIO is expected to make it happen, no matter what. Analysts say the CIO should try to validate those estimates as early as possible.

"That's one of the toughest things a CIO has to do, but you should be able to master it," Poe says.

The CIO should look at a merger just like he would any other major IT project, he adds. Therefore, the CIO should already have established methodologies - supported by project-management, cost-estimation and portfolio-analysis tools - used to plan and budget projects and for make-vs.-buy decisions, Poe says.

"I should already have a fast assessment capability to show my business partners and [Wall] Street that we are making progress," Poe says.

P.P. Darukhanavala, chief technology officer at BP Amoco PLC in Chicago, says companies can generally expect to save from 15% to 40% of their combined IT budgets when they merge. When processes and geographic areas overlap to a significant degree, savings will be near the high end of the range, he says.

Darukhanavala, who led IT integration when British Petroleum and Amoco Corp. merged, says a decentralized IT organization is a red flag.

"If things are centralized, it's much easier to rationalize and combine processes, but if IT is dispersed all over the place, just collecting everything together is much, much harder," he says.

Indeed, even veterans of mergers and acquistions say combing IT systems always has pitfalls.

"At the end of the day, you will have made a lot of good decisions and a few bonehead decisions. You'll have to go fix them," says Parks.

"What you want to do in the initial stages of due diligence for a merger is assess risk," says Julie Giera, a vice president at Giga Information Group. Giera says the following are among the areas to look at:
  • Hardware, software and IT services vendors: Look at viability, flexibility, financial position, market share and service qualifications of major suppliers.
  • Disaster recovery: Look at procedures, audit findings, suppliers and contracts.
  • Security: Look for fraud by insiders when a merger or acquisition is announced. Pay special attention to the security surrounding contract management, procurement, accounts payable and accounts receivable systems.
  • Mean time between failures for critical systems: Look at frequency of maintenance requests and the frequency and duration of downtime.
  • Capacity: Look at capacity/scalability and percentage utilization of hardware and systems.
  • Hardware and software maintenance: Look at service contracts for critical systems and components. Leave contracts in force for at least six months.
  • Change management and approval: Look for tight controls on system changes during the turbulent merger and conversion period.
  • Out-of-date systems: Look for systems that aren't compliant with Y2k, the Euro currency or government regulations. Systems that are more than seven years old should get detailed scrutiny for "land mines."
  • Personnel issues: Look at attrition rates. Is key labor coming from inside or from consultants? Who maintains the legacy applications?
  • Outsourcing and lease contracts: Look for clauses that specify huge termination penalties.
  • Project plans/budgets, help desk reports, audit reports, service-level reports: Look for poor performance and chronic trouble spots.

For more information, head to Computerworld's Merger Resources Center.

Copyright © 2000 IDG Communications, Inc.

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