Post-Merger & Acquisition IT Integration

This blog has moved

noreply@blogger.com (Clive Taylor) — Fri, 30 Apr 2010 22:04:00 +0000

This blog is now located at http://wisdomofchange.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://wisdomofchange.blogspot.com/feeds/posts/default.

An introduction to Mergers & Acquisitions

noreply@blogger.com (Clive Taylor) — Mon, 21 May 2007 16:52:00 +0000

The key objective behind a merger or an acquistion is to create shareholder value over and above the value of the two separate companies. Merger synergies include:

improving market reach or market share
improving industry visibility (bigger companies can raise capital more easily)
strengthening/increasing the product portfolio
improving operating efficiencies
securing greater economies of scale
acquiring new technology.

Strictly speaking, an acquisition is when one company takes over another, maintains itself as owner and the acquired company ceases to exist legally e.g. the Royal Bank Of Scotland's takeover of the National Westminster Bank in 2000 (though note that the NatWest brand has been retained). On the other hand, a merger is when the two companies agree to go forwards as a single, new company e.g. when Chrysler and Daimler-Benz became DaimlerChrysler in 1998.

The legal framework not withstanding, the real difference in integration approach comes from whether the deal is friendly or hostile and how it is communicated to stakeholders.

There are typically five steps in delivering value from mergers and acquisitions:

Determine objectives
Identify & evaluate candidates
Do the deal
Plan post-merger integration
Deliver post-merger integration

Determine objectives
The business defines its strategic objectives to determine the kind of merger or acquisition and the types of candidates to look for. For example, it could expand horizontally to increase market share and increase economies of scale or it could expand vertically to decrease dependence on suppliers and decrease costs. A business could also seek to expand its products to increase sales to existing and new customers or it could acquire new technology for new/improved products to increase sales or lower costs.

Identify & evaluate candidates
Based on the overall objectives, a business will draw up a list of public companies, divisions of companies and private companies that might be suitable candidates, including competitors, suppliers and new emerging companies. Candidates are prioritised based on agreed criteria, such as: are they too large or too small, where are they located, are some business segments unattractive (and is so, could they be profitably sold), are the well run (and if not, could it be improved), would it be friendly or hostile, are they any barriers (political, legal etc)?

Having drawn up a short list, the remaining candidates are valued. As part of this process, the business also needs to define how it will get back the takeover premium (through real synergies, restructuring and financial engineering opportunities, for example).

Do the deal
The business decides the maximum price it's prepared to pay and establishes its negotiation strategy (understanding the background and incentives of the other side, and the value that might be paid by a third party). It then negotiates, conducts due diligence and closes the deal.

Plan post-merger integration
Planning for the integration is undertaken while the deal is being negotiated and closed. The business and operating models are agreed, the initial organisation structure determined, those who stay are identified, draft communications prepared, transition service agreements set up where necessary, and the Day 1 plan confirmed.

Deliver post-merger integration
Delivery of the IT benefits of a merger or acquisition is typically in three phases: day 1 imperatives, year end transition projects, and the post-merger realisation programme. Managing the integration process will be the subject of a future blog.

Cost reduction opportunities

noreply@blogger.com (Clive Taylor) — Fri, 04 May 2007 14:32:00 +0000

Over 50% of the back office synergies possible in a merger can be IT-related; ranging from accounts payable, through procurement, to IT economies of scale. Many of them will involve the consolidation of central business functions, such as Payroll, Finance, Purchasing and HR. Typically, they will either be one-time savings or a reduction in on going costs, such as:

Eliminating redundant positions in the consolidated business functions
Eliminating operating, maintenance and support costs for redundant business applications

Reducing the total cost of operating the combined IT infrastructure (consolidate data centres, standardise core applications such as email, standardise PCs/printers/servers/networks etc)

Reducing the cost of mobile phones by negotiating a single contract (for each country)

Reducing the cost of voice and data calls by consolidating equipment and contracts (you may even be able to develop a case to jump straight to a next generation technology, such as Voice Over IP)

Reducing the buildings portfolio by consolidating similar operations and the location of central functions

Reducing the number of suppliers and leveraging discounts based on increased volumes for the remaining suppliers

As CIO, you will need to work closely with your senior management colleagues to draw up the list of opportunities and then prioritise the projects to deliver the savings (see also Prioritising the IT integration projects).

Prioritising the IT integration projects

noreply@blogger.com (Clive Taylor) — Fri, 20 Apr 2007 12:26:00 +0000

The high priority and big ticket IT integration projects should be clearly identifiable from your IT due diligence report and based on the integration approach your business adopts. Projects like common branding, linked email/voicemail/networks and consolidated financial reporting.

However, the increased reliance of all parts of the business on technology means that there will be a large number of department-specific requests that aren't on this "top list", but which will nonetheless have a significant impact on the business's ability to operate. Some of these may come from the acquired company, particularly if its owners improved short term profitability by reducing IT investment in the run up to the deal.

First, get closely involved in every department's integration planning process. You may need to allocate responsibilities across your team in order to cover them all. Aggregate the emerging requirements. Understand the pain that each department will go through with and without IT support. And try to differentiate between “need” and “want” – people will use the integration as an opportunity to slip in requests for projects that would not otherwise get air time.

Determine, in broad terms, the capacity available from the two IT teams now available to you. Then calculate the maximum capacity if external suppliers were used as well. The latter is bounded by your people’s ability to oversee and then integrate what is being delivered. Next, trim this maximum capacity back to what the business says it can afford (as a general rule, large teams of consultants are expensive and so should only be considered for equally large, discrete, non-repeating projects such as an ERP system replacement). Look at backfilling operational roles with contractors to release IT staff for key integration positions. And consider performance-related retention bonuses to motivate those staff whose roles will not exist beyond the integration.

You are now ready for the business integration team’s prioritisation process. You will have developed a view about which projects must be done, which should be done if funds allowed, and which could wait. And you may be more aware than most of the cross-department synergies and dependencies relating to each project. You will have two hats: as a department head (your IT integration projects [such as core infrastructure] will be prioritised along with everyone else's) and as the supplier of integration capacity. Make sure you are seen not to abuse this unique position of trust - it will reinforce your standing with senior management.

Start to manage people’s expectations as early as possible. Your experience will indicate to you how many of the “should be done” projects are likely to make the cut. Let the business integration team know this. Funds may be moved from another initiative to the IT integration if the benefits are deemed to be greater from delivering the appropriate IT project.

Importantly, the resulting list of prioritised IT integration projects will be a sub-set of the business’s overall prioritised list. A business decision, not an IT decision. You will end up reminding people, politely, of this point throughout the integration.

Transitioning the acquired IT team

noreply@blogger.com (Clive Taylor) — Thu, 12 Apr 2007 10:58:00 +0000

Delivering infrastructure economies of scale is a requirement of most mergers or acquisitions. And whether it is reducing application duplication or consolidating servers, there will be staff whose job it is to develop and support the technology that is going to be eliminated. Some may be redeployed, but it is also likely that some will not be needed.

As soon as the transaction is announced, expect CVs to be dusted off and sent to recruiters. And not just from those in the acquired IT team – your own team may be concerned that a reorganisation could put their own roles at risk.

Whilst you shouldn’t expect to reorganise the IT function each time your company acquires another business, you may need to increase the capacity in some areas to accommodate the additional needs placed on them. That said, you should also take the opportunity to reorganise any areas in your existing team that are under-performing.

The IT due diligence report should already identify which of the four approaches your business will be adopting and what is required from each of the three main phases of the IT integration. With this, you should be able to plan your resources. Although the end-point may not be clear yet, the short term needs of the transition can be defined.

Open, honest leadership is what is needed. People can deal with bad news if they have enough time to plan and act. And you only have one chance of gaining the trust of the people you will want to keep. So develop your plan quickly, gain agreement from the business, and then communicate it to everyone.

Staff will generally find themselves in one of four categories:

their role disappears from the date of the transaction (which means you should have been involved in the decision while the deal is being put together)
their role disappears but there is a transition role for them for a defined period
their role disappears, there is a transition role for them and there may be a role for them in the new IT organisation
their role continues in the new IT organisation.

Work closely with your HR function. Although employment legislation varies from country to country, in most cases the job/role is made redundant, not the person. Your business may offer a voluntary severance package, redundancy, or both.

For those people who are required for the transition only, consider offering them a performance-related retention bonus in addition to redundancy so that they stay and complete what is needed of them for the integration.

For those who may have a role after the transition, consider the performance-related retention bonus as well, but on the understanding that, should they be offered a role in the new organisation, it will be reduced to whatever the ongoing staff get for their part in the integration.

But expect that, while the business will have budgeted for the cost of voluntary severance/redundancy, retention bonuses will not have been considered. Leverage your good relationships within the business to secure the best you can for each person.

Then implement with care and attention. Maintain a regular dialogue with transition and permanent staff. Deal with issues quickly and sensitively. And maintain your honesty and integrity throughout.

IT Due Diligence : ensuring "Fit to Buy"

noreply@blogger.com (Clive Taylor) — Thu, 05 Apr 2007 13:22:00 +0000

In a previous post, I talked about detailed IT integration planning starting with a solid IT assessment. This should be provided by a thorough due diligence process. So what is due diligence, and how should it be undertaken from an IT perspective?

What is Due Diligence?
Your company has decided to grow by acquiring another company. It will want to make an investment decision based on the worth of, and the risks associated with, the target company. Due diligence informs this decision-making process of the risks, exposures, financial requirements and opportunities relating to the acquisition. A key objective is to uncover any material issues that would cause your company to cancel the deal or to revalue the purchase price. You will find issues (every company, including your own, has them). The key here is whether they are material or not.

Due diligence can take from 30 to 90 days to complete, depending on the size and complexity of the target company. It is undertaken in the period after the initial approach has been made and before the deal is closed. Some acquiring companies focus just on the financial aspects of a deal and don't leave sufficient time for a thorough due diligence. Caveat emptor - let the buyer beware.

Undertaking IT Due Diligence
The IT due diligence report provides an assessment of the target company's IT, quantifies any risks to business continuity, outlines the required operational and capital expenditure for the first 12 months of the merged company, identifies the opportunities for synergy and defines the high level integration plan. The steps in its development are:

understanding your business's expectations and assumptions relating to the acquisition (for example: will the target company be fully integrated, kept as two separate entities, or a hybrid; are cost savings being factored into the deal business case; and is there a timetable associated with the integration?)
collecting and reviewing the available IT documents relating to the target company's business applications, IT infrastructure, IT organisation, operating & capital budgets, and current IT projects
conducting interviews in the target company of senior/department management and key individuals in the IT organisation. Providing the interviewees an outline ahead of time will enable them to prepare and bring along any appropriate detailed information
reviewing the non-IT business documents collected by the other due diligence streams to see if anything impacts the technology assessment (for example, procurement agreements and office space contracts)
analysing your findings, which includes quantifying the key business risks you've identified
producing the IT due diligence report and presenting the executive summary to your company's deal team

Except where Stock Market disclosure requires it, due diligence is often undertaken before a formal announcement is made. The target company will be nervous about word getting out to its customers and employees before the agreement to sell has been reached. You could be competitors. Uncertainty creates unrest. So be discreet (something for which IT folk are not best known!). Don't mention due diligence in any interaction with the target company. And have agreed answers to their employees' questions such as "Who are you?", "What are you doing?", and "Why do you need this information?".

One last point. The availability and quality of the documents you request will tell you a lot about how well the target company's IT organisation is run. If the boot was on the other foot, what impression would an acquirer get of how well you run your company's IT? [For example, when I was CIO of PwC Consulting in Europe, I undertook a regular assessment of our IT. As well as providing a very useful review point for us, it positioned the IT team extremely well during the company's flotation and subsequent acquisition by IBM.]

When the target company is a division of another company

noreply@blogger.com (Clive Taylor) — Thu, 29 Mar 2007 10:36:00 +0000

The complexity and risk of the integration increases when the target company is a divestment i.e. a division or unit of another company. Additional steps need to be undertaken and a working relationship agreed that continues beyond deal closure:

the divested company will need to continue to receive IT services from the selling parent company until it is sufficiently transitioned
the buyer will need to extract the IT infrastructure and business data of the divested company from the selling parent company (which will require the help of the seller).

The transition services agreement (TSA) establishes how the buyer and seller will work together to effect this transfer between them. It lists the roles and responsibilities of both parties and the schedule of charges payable to the seller for the services they provide. These charges put further pressure on the integration team to complete their work quickly. IBM, for example, calls this the process of replacing "green" dollars (real cash being paid to the seller) for "blue" dollars (their internal recharges for the IT infrastructure).

The TSA will look like an outsourcing agreement, with a scope of services, performance standards, service terms and fees. However, it will differ in three important areas (unless the seller has already outsourced its IT to a third party):

the seller is not in the business of providing outsourced services
the seller does not want to maintain a long term relationship with the buyer
there will probably be no incentive for the seller to provide any more than basic services.

For these reasons, the buyer should take particular care defining the detail of each service and allow each to be terminated when it is no longer required. In this way, the buyer gets what they need only for as long as they need it.

Integration progress: when red is good and green is bad

noreply@blogger.com (Clive Taylor) — Wed, 21 Mar 2007 17:12:00 +0000

Integration programmes never go according to plan. They will have many significant issues that cannot be resolved by the integration team alone. So a key activity for the team is to foster an on going dialogue with the business that informs, captures issues, and secures timely decisions.

A popular way of communicating programme progress is by using traffic light reporting. The visual representation of all programme activities onto a few pages can highlight exceptional items that might otherwise be missed and the overall frosting of colour gives a good sense of progress, areas for attention and so on.

Usually the traffic light colours represent the following:

Red - there is a significant problem and urgent and decisive action is needed
Amber - there are problems and action is needed, though the project team has this in hand
Green - implementation is progressing to plan and there are no serious issues

with White denoting "not yet started" and Black showing "completed".

As the integration team, if you’re not reporting (often large) areas of amber and red, then ask yourself if you are managing everyone’s expectations appropriately (remember, forewarned is forearmed and the business can take mitigating action if it gets enough notice).

As the business, if you’re not seeing areas of amber and red, then challenge your integration team about the issues and the decisions that they need you to make. It could be a sign that one of the merging businesses, unbeknownst to the other, has a “no bad news culture”. And the result of this was, for one acquisition, an additional £3m of cost and a four month delay to what should have been a nine month integration.

Five "killer" questions for your CEO to ask

noreply@blogger.com (Clive Taylor) — Fri, 16 Mar 2007 14:40:00 +0000

The deal's been done and the City's expectations set in terms of additional pre-tax profit or earnings per share. The integration timetable has been agreed and the project is well underway.

So how is it going? And how is the current business being affected?

Once the status reports, risk/issue logs and traffic light summaries have been reviewed, here are five questions that your CEO should be asking:

how are we mitigating the impact of competitive attacks on our customers and employees?
how are cost reductions being delivered without impacting short term service levels or the overall business strategy?
how are the integration biases of our business units, product teams and technology groups being balanced to maximise profitability in line with our customers' needs?
how is the dialogue with our customers and employees ensuring (a) that everyone knows what is happening, when and why, and (b) that their issues are being captured and resolved?
how is the integration impacting our base revenue and growth targets?

How well could you respond?

Start with a solid IT Assessment

noreply@blogger.com (Clive Taylor) — Wed, 07 Mar 2007 16:27:00 +0000

To be able to do the detailed planning for the IT integration, you have to know your starting point. Two things will help inform this baseline: the business assessment and the IT assessment. Views of each of these should have been produced as part of the M&A transaction process. In the case of IT, the due diligence report should include:

an inventory of what is there (business applications, infrastructure, organisation, processes and level of automation)
the risks (technology stability, technology ownership, software licensing, staff support, vendor support and major expense needs)
the IT budget for the next 12 months
the capital expenditure needs for the next 12 months
the IT project initiatives
the leverage opportunities
a high-level transition plan.

BEFORE you do anything else... suspend all on going projects. THEN, if the due diligence report doesn't exist (or is lacking in detail), undertake/complete the IT assessment. This sounds obvious, but you will be under pressure both to allow certain projects to finish and to start the transition based on the high-level plan.

Once the baseline has been established, then the overall phasing and extent of the IT integration can be agreed and the detailed plans developed.

Beware "one size fits all"

noreply@blogger.com (Clive Taylor) — Wed, 28 Feb 2007 15:34:00 +0000

The pressure to deliver an integrated IT service at a reduced cost can result in the adoption of the systems from one or other of the legacy organisations without fully considering the options or impact of such a decision. We know of an acquiring business that imposed its systems and processes on the much smaller company it acquired, even though the smaller company had developed some good practices that would have benefited the whole organisation. Within a year, many of the acquired staff had left.

There are broadly four options for integrating the IT of two businesses:

Retain both models
Establish critical inter-business linkages
Migrate major functions to common systems
Adopt one model / migrate to new (Enterprise-wide solution)

If the new business is going to be division-oriented with division-level IT systems and little integration of the legacy businesses, then retaining both models could be the most appropriate solution. It would minimise the impact to the business and to its people. IT integration might then just focus on branding (websites, email) and consolidating infrastructure (networks, data centres, procurement).

At the other end of the scale, major integration of the legacy businesses and/or the creation of new lines of business would require a high degree of process change and likely result in migration to a common model and systems. Since this couldn't be achieved in a short period of time, the organisation could follow each of the four options above as phases in its integration.

How to avoid losing your job

noreply@blogger.com (Clive Taylor) — Tue, 20 Feb 2007 12:59:00 +0000

A merger or acquisition can represent a substantial opportunity for everyone in the IT team, both during the integration phase and in the post-merger realisation activities that follow. But the nature of the opportunity will vary dependent on the kind of transaction and the business rationale behind it.

A merger tends to offer a more level playing field, so the better prepared you are, the stronger your position will be. In an acquisition, irrespective of what might be said, the acquirer's IT organisation will have the natural upper hand. This makes preparation even more important if you are part of the acquired company. And, whilst aggressive growth was a rationale of M&A's during the 1990's (so almost everyone could find a role in the expanding business), infrastructure economies of scale are now the recurring theme. So, it pays to prepare.

The key to effectively weathering a merger or acquisition is to be more than the executive responsible for IT; you must be seen as a valued member of the management team.

What are the sources of value in your business? How does IT affect them?

The Finance Director doesn't just talk about finance; nor should you. Help your CEO to achieve their objectives. Develop partnerships with other business functions. Be seen to have moved beyond the narrow technology focus that many on the board will associate with IT people in general. Build relationships within your existing business that position you as a valued executive rather than just as "Head of IT". Develop a strong IT leadership team. And, as far as possible, implement an IT infrastructure that is scalable and flexible.

Do all this now, before a deal is on the table.

Will your acquisition add value?

noreply@blogger.com (Clive Taylor) — Wed, 14 Feb 2007 13:50:00 +0000

More than two thirds of acquisitions fail to create meaningful shareholder value. The majority attribute this to one or more of: unrealistic expectations; a lack of sufficient pre-merger due diligence; or under-estimating the difficulties involved in integrating operations, processes, systems and technologies.

Strategy consultants Bain & Co rank the ability to successfully integrate acquired companies as the single most important factor influencing acquisition success. It is not surprising, therefore, that integrating the back office often represents the biggest challenge in realising the value of a deal, where over 50% of the synergies can be IT-related.

Delivery of the IT benefits of a merger or acquisition is typically in three phases: day 1 imperatives, year end transition projects, and the post-merger realisation programme.

Day 1 Imperatives
There will be a small number of critical business objectives for day 1 of the merged business, such as delivering a consistent brand to customers. These objectives provide the short term focus for all the integration teams. For IT, this often means:

re-badging existing web sites
providing new external email addresses for all staff
integrating phone and address books
providing the ability to transfer phone calls between legacy buildings.

Year End Transition Projects
The financial markets usually only like to see exceptional one-off transition costs in the accounts for the year of the merger or acquisition. After that, although integration activities continue, they will be delivered as part of the new business-as-usual operations. As a result, the financial year end often becomes a hard date for the next wave of integration deliverables. The amount of time left in the year will dictate what can reasonably be completed. IT projects may include:

consolidating data centres
linking email, voicemail and networks
consolidating IT procurement
consolidating financial systems, chart of accounts and reporting
consolidating HR data
eliminating redundant positions in the emerging IT organisation.

The Post-Merger Realisation Programme
While the first two integration phases are underway, a separate team works with the business to update (or replace) the IT strategy in line with the new business strategy. This sets the stage for the longer term projects, that are generally more difficult and time-consuming, such as:

standardising and converging enterprise systems (e.g. ERP, CRM, Supply Chain)
consolidating the application portfolio
standardising the infrastructure
transforming the IT organisation.