Crucial IT Checkpoints in M&A
When mergers fail, as often as not, somewhere in the blame line will be a technology issue undiscovered or neglected in the pre-transaction dealing. By knowing when to add well-timed Information Technology (IT) checkpoints to their process, acquirers can avoid unpleasant surprises later.
The M&A process often shines a bright light on the different perspectives of finance and IT. Most pre-offer due diligence teams are experts in finance, not technology, and due diligence is not designed to assess technology issues in depth. And yet, curiously, a good portion of the predicted “saves” – the efficiencies the buyer expects to effect in order to realize a sufficient return on his investment – are technology-based.
When the CEO’s credibility with shareholders rides on an assumption about a target bank’s technology, it is only wise to validate IT assumptions with experts who can take the analysis a layer or two deeper. While it’s rarely practical for the buyer to send an army of technology experts to examine every system at the target bank, being aware of the main situations in which merger teams overlook technology pitfalls clarifies when to make judicious use of the bank’s IT team.
CEOs and CFOs often have high expectations of technology. They are well aware of the accretive and dilutive effects of good and bad technology initiatives. They are ever alert to attractive technologies that will lead to more customers, loyalty, and profits. They are accustomed to presenting their business problems to the IT team and having them solved with new technology.
So when it comes time to create a technology vision for the merged organization, it is not surprising that they do so with every expectation that IT can implement whatever scenario serves their cost/benefit analysis. It’s not exactly, “Here’s the plan, how fast can you convert?” but neither is it, “Here are our assumptions about our next acquisition’s technology – do they ring true?”
So here’s where you need checkpoint one, when the acquisition team has tentatively greenlighted a targeted bank. This is where the IT team should be asked to examine the high-level assumptions about the convertibility, extensibility, and other “ilities” of the target bank’s technology infrastructure. Their task is not a detailed analysis, but rather an informed questioning of the assumptions and a chance to raise red flags about known issues and previous complications of those technologies.
In finance, numbers are empirical. Accounting rules surround every financial calculation. Arbitrary outcomes are virtually impossible. Not so with technology. A particular commercial loan system in one bank, by the time it is installed and interfaced to all the other systems, may not look much like the same system in another bank. Customizations done over the years can create surprises when it comes time to convert. Unexpected interdependencies can roil any conversion schedule.
So it might seem reasonable for finance to suppose that if a previous acquisition involving certain core systems went well, so should the next acquisition with those same systems. Tempting but dangerous. Heavily customized systems require more people to run them, more interfaces to be written, and more time to convert. Since worker productivity can decline by up to 50% in post-acquisition months, customized systems can upend assumptions about headcount saves. There may also be volume considerations, where vendor pricing could change the total cost of ownership.
Checkpoint two occurs when the acquisition team determines that the target bank’s systems appear to have been heavily customized. This is the time to run the customizing scenario past the IT team and get a high-level assessment of the relative ease and timing of converting. If they are experts in the systems involved, they will be able to make informed if not firm predictions about possible delays and added costs.
One experienced acquirer we know had set its sights on another bank to fill out its footprint – a bank slightly larger than the community banks it usually targeted. As due diligence proceeded, it became apparent that the target bank was operating a successful technology-based downstream operation. It was tempting for the would-be acquirer to take over the business and create a new revenue stream, scaling it up to serve more downstream banks across is larger footprint.
But just before pulling the trigger, they brought in their IT team which did a fast but informed analysis and advised: “We can do this, but we will have to invest a lot of capital – the business is established but not extensible with current technology. Your top line will improve, but not right away, and your bottom line will not.” What looked inviting from a financial standpoint turned out to be perilous from a technology standpoint.
That brings us to checkpoint three, when the acquisition’s return on investment (ROI) depends on a technology-based business model substantially different from what the IT group currently supports. The question for the IT team is not, “Is this an attractive business for us?” Or, “Can you expand this business across our footprint?” Rather, it’s, “What would be, at a high level, the total cost of our getting into this business?”
Web-based technologies flourishing at community banks can also lead acquirers to overestimate the value of their purchases. It is easy and relatively inexpensive for community banks to adopt consumer-pleasing technologies (e.g., mobile alerts, remote deposit, and ATM image capture) that vault them past large banks in capabilities and attract desirable customer segments. When acquirers come shopping, it is reasonable for them to estimate the value of extending those new products to their larger base and capturing desirable segments.
Spreading this Web-based technology across a huge customer base, however, usually entails new equipment, upgrades and complicated interfaces. Often the acquirer fails to deploy the products and often loses the acquired bank’s customers who once had the technology. When a bank acquires another institution that is significantly more advanced technologically, 15% to 25% of the acquired customers will be gone in less than two years. And those are the customers on whom the acquisition’s projected ROI was based.
So checkpoint four comes when the acquisition team begins calculating the benefit of rolling out a small-volume, Web-based product to a much larger customer base. That’s when you should ask IT to do rapid due diligence on the scalability of the technology, the new equipment the acquirer would have to purchase to make it work and any product compromises that might be necessary.
Sometimes mid-sized banks acquire smaller banks mainly for the purpose of making themselves attractive acquisitions. In many cases, when they acquire, they don’t go to the expense of converting systems, knowing that their eventual owner will probably want to convert again to something different. If that situation is not apparent to the acquirer, the hodgepodge of systems can pose data integrity issues and high costs of maintenance that the acquirer cannot solve quickly enough to make its numbers.
So we reach our final checkpoint, when the acquisition team learns that the target bank is itself composed of unconverted acquisitions. It won’t take long for the IT team to identify the key systems at each unconverted holding and make a high-level estimate as to the relative ease of bringing them into the acquirer’s structure. Since the answer could range from “very easy” to “very difficult,” it could also make a difference in the offering price.
Obviously, due diligence needs to be conducted discreetly and rapidly. But there is a proper and defined role for the IT group at critical junctures, when IT can bring crucial insights and accuracy to financial estimates. The time to learn of IT unknowns is before making the offer and making promises to shareholders.
Mr. Choudhry is a managing partner, consulting solutions, at Morristown, N.J.-based Collabera Inc. and can be reached at [email protected]. Mr. Mealey is also a managing principal and can be reached at [email protected].