BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
If you are banking on long-term tenure in IT, chances are you will be involved in a merger or acquisition during your career. In fact, M&A activity is on the rise. According to Bloomberg Finance, global M&A activity in 2014 surpassed $ 3 trillion, the highest since 2007. This trend makes M&A activity par for the course for technologists who want a seat at the table with other business-line executives, not to mention the vast impact M&As have on the IT department itself.
But if M&A activity presents an opportunity for technologists to work more closely with their business-line counterparts, it can easily go awry if IT doesn't consider some of the technology and business implications of these events. IT departments should think carefully about how these changes will affect existing technology purchases and licensing, costs and the staff you have in place to manage your IT infrastructure, and of course, the impact it might have on the value of the M&A deal itself.
There are 3 distinct stages of any M&A in which an IT department may be called on to participate: due diligence, contract and integration.
The three phases of M&As
1. Due diligence. In the M&A context, due diligence involves the acquiring company gathering data about the company being acquired prior to closing the deal. During this phase, a cross-functional team that often includes IT can validate financial results, expose risks and estimate synergies that can be expected from combined operations (if any). The ultimate goal is to confirm (or refine) the offer.
From an IT perspective, during the due diligence phase, the acquiring company should consider issues that affect the total value of the deal, such as whether the company being acquired is compliant with software licensing or has long-term contracts with high cancelation penalties , and whether IT integration is also high on the list: which systems will the joint company use? Who will provide infrastructure support?
2. Contract negotiation. The contract phase is critical: The two companies involved might have to live with terms they agree on for a long time. Business development and legal units typically drive this phase, using information provided in due diligence reports. I believe IT must remain connected in this phase as well, especially if the integration strategy requires two IT departments to collaborate for the purposes of integration.
3. Integration. Sometimes the acquiring company lets the acquired operate independently, in which case integration isn't an issue. In most cases though, in order to achieve synergy, integration includes tasks that require IT support, such as converting data between systems, closing facilities, moving or laying off employees.
How IT adds value
IT pros are uniquely positioned to identify some of the issues that arise during these phases of M&A. Technology departments can see how to combine the resources of both companies, streamline processes, consolidate systems and facilities and, ultimately, reduce costs. But that takes understanding of the strategy and a fair amount of planning.
Consider this M&A scenario: the acquiring company buys a subsidiary of another large company, so there is an acquisition and a divestiture involved. In this case, IT assets and operations first have to split off from the selling company and become integrated into the buying company, which involves a transition.
IT groups from the acquiring and the selling companies need to work together during the transition, with the acquiring company taking the lead. Now consider the perspective of the IT employees of the selling company: They may assume their jobs are at risk. And in some cases, they're right: with the divestiture, the load on IT is naturally reduced, and so is the revenue to pay for IT expenses.
So the transition must be well thought through and documented in a contract while negotiations are ongoing. This is called the transition services agreement (TSA). IT should be involved in crafting this contract with the legal department.
From the acquiring company's perspective, a TSA must include clear descriptions and service-level agreements (SLAs) of services to be provided during the transition, such as temporary support for infrastructure, help desk, support, phones, etc. It should also name those who will perform these services and hold the selling company accountable for keeping them until the TSA expires. It should consider record retention after transition (for example, copies of invoices) in case of a tax audit.
The TSA should establish who is responsible for transferring or reassigning software licenses and costs -- this is often a tedious and time-consuming issue. In fact, if the selling company uses its own software licenses to provide chargeable services to a third party (the acquiring company), it might require special consent from the software provider -- this is typically overlooked and could generate serious penalties. Finally, the TSA should have a flexible term that can be shortened or extended depending on how the integration goes. And the cost should be consistent with the run rate identified in due diligence.
The selling company wants the TSA to contemplate all these issues, but from the opposite side (i.e. narrow scope, no SLAs, ability to reassign or terminate people, etc.). As you can imagine, there is a great deal of negotiation involved here, and IT can add a great value in advocating for either side of the merger.
As an IT leader involved in M&A activity, you should be involved throughout the process. In particular, if you work for a company that's acquiring another company, you'll need a TSA -- ask your legal department to assist you. If your company is divesting, the TSA is just as important to protect your interests (which are likely to be opposite to those of the acquiring company). And if your company is being acquired or divested, brace yourself.
How the CIO job is changing