it handbook on mergers acqui 130975

ResearchPublication Date: 16 December 2005 ID Number: G00130975

© 2005 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner's research may discuss legal issues related to the information technology business, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice.

IT Handbook on Mergers, Acquisitions and Divestitures Robert Mack

Gartner provides comprehensive guidance for IT organizations on the planning, preparation and activities required during the six phases of the merger-and-acquisition process — from initial candidate screening to post-transformation review.

Publication Date: 16 December 2005/ID Number: G00130975 of 65

© 2005 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

TABLE OF CONTENTS

1.0 Overview...................................................................................................................................... 5 2.0 Introduction.................................................................................................................................. 6

2.1 M&A Business Drivers.................................................................................................... 6 2.2 Why Mergers Fail ........................................................................................................... 8 2.3 The M&A Approach: Three Models .............................................................................. 10

3.0 M&A Process Stages: An Overview .......................................................................................... 11 4.0 Stage 1 — Screening ................................................................................................................ 12

4.1 Screening Activities ...................................................................................................... 12 4.2 What IT Can Do............................................................................................................13 4.3 Key Actions................................................................................................................... 13

4.3.1 Constructing Cost Scenarios........................................................................ 15 4.3.2 And Then There is Time............................................................................... 17

5.0 Stage 2 — Initial Candidate Evaluation..................................................................................... 17 5.1 Action Items Resulting From Screening ....................................................................... 17 5.2 Preliminary Analysis ..................................................................................................... 18 5.3 What IT Can Do............................................................................................................19

6.0 Stage 3 — In-Depth Candidate Evaluation: Due Diligence....................................................... 19 6.1 Due-Diligence Assessment Criteria.............................................................................. 20 6.2 What IT Can Do............................................................................................................20

6.2.1 Preparation ................................................................................................... 21 6.2.2 On Site.......................................................................................................... 22 6.2.3 Wrap-up........................................................................................................ 24 6.2.4 Remember the Strategy ............................................................................... 24

6.3 What to Do When Target Access Is Limited................................................................. 25 7.0 Stage 4 — Closing the Deal ...................................................................................................... 25

7.1 Negotiation ................................................................................................................... 25 7.2 Due-Diligence 2 ............................................................................................................ 25 7.3 Transition Planning....................................................................................................... 26 7.4 What IT Can Do............................................................................................................27

8.0 Stage 5 — Executing the Merger/Acquisition............................................................................ 28 8.1 The Integration Process ............................................................................................... 29

8.1.1 Integration Planning...................................................................................... 29 8.1.1.1 The Core Transition Team ........................................................... 29 8.1.1.2 Defining the Scope of Work to Be Done ...................................... 30 8.1.1.3 Schedule Development ................................................................ 30 8.1.1.4 Personnel ..................................................................................... 31 8.1.1.5 Communication............................................................................. 31 8.1.1.6 Balancing Long-Range Strategy with Current Tactics ................. 32

8.1.2 Early Projects ............................................................................................... 33 8.1.3 Business-Process-Originated Projects......................................................... 34

8.1.3.1 Business Projects: Absorption Model........................................... 35 8.1.3.2 Business Projects: Stand-Alone Model ........................................ 36 8.1.3.3 Business Projects: Merger of Equals Model ................................ 36

8.1.4 IT Infrastructure Operations Projects ........................................................... 37 8.1.4.1 IT Infrastructure Operation Projects: Absorption Model............... 38 8.1.4.2 IT Infrastructure Operation Projects: Stand-Alone Model ............ 38



8.1.4.3 IT Infrastructure Operation Projects: Merger-of-Equals Model .... 38 8.1.5 Employee Change Projects.......................................................................... 39 8.1.6 Building a 90-Day Plan................................................................................. 39

8.2 Sample Template for Stage 5....................................................................................... 39 8.3 What IT Can Do............................................................................................................41

9.0 Stage 6 — Operational Review ................................................................................................. 42 9.1 Determining Whether Acquisition Value Expectations Will Be Met.............................. 42 9.2 Determining How to Improve the Process.................................................................... 44

9.2.1 Was It Based on a Faulty Assumption? ....................................................... 45 9.2.2 Was It the Result of Poor Execution?........................................................... 45 9.2.3 Was It a People Problem?............................................................................ 46 9.2.4 Can It Be Corrected Now, and Is It Worth It?............................................... 47

9.3 What IT Can Do............................................................................................................47 10.0 Divestitures.............................................................................................................................. 48

10.1 Creating New Systems and Modifying Established Ones .......................................... 49 10.1.1 Developing the New System ...................................................................... 49 10.1.2 Modifying the Remaining System............................................................... 50

10.2 Duplicating or Spinning Off a System......................................................................... 51 10.3 Providing a System as a Service................................................................................ 52

11.0 Software to Manage M&A Activity ........................................................................................... 52 11.1 Software Tool Criteria................................................................................................. 53 11.2 M&A Software Candidates ......................................................................................... 54

11.2.1 Valchemy (valchemy.com) ......................................................................... 54 11.2.2 FastFuse (fastfuse.com)............................................................................. 55

12.0 What Acquired IT Organizations Can Do ................................................................................ 56 12.1 Stage 3 and Stage 4 IT Actions for Target Enterprises.............................................. 56

12.1.1 Asset Evaluations....................................................................................... 57 12.1.2 Business Operational Reviews................................................................... 57 12.1.3 Evaluations of People................................................................................. 58

12.2 Stage 5, IT Actions for Target Enterprises ................................................................. 59 13.0 Due-Diligence Checklist .......................................................................................................... 59

13.1 General Information.................................................................................................... 59 13.2 IT Standards/Architecture........................................................................................... 59 13.3 Business Process/Applications .................................................................................. 60 13.4 Application Portfolio.................................................................................................... 60 13.5 Application Change in Progress/Backlog ................................................................... 61 13.6 IT Operations Infrastructure ....................................................................................... 61 13.7 Operations Capability ................................................................................................. 62 13.8 Data Centers .............................................................................................................. 62 13.9 Financial ..................................................................................................................... 62 13.10 Contracts .................................................................................................................. 62 13.11 Assets....................................................................................................................... 63 13.12 Intellectual Property.................................................................................................. 63 13.13 Organization/Sourcing.............................................................................................. 63 13.14 Internal Staff Skills and Competencies..................................................................... 63 13.15 Externally Sourced Skills .......................................................................................... 64 13.16 Organizational Change Management....................................................................... 64



LIST OF TABLES

Table 1. Sample Template for M&A Integration .............................................................................. 40

LIST OF FIGURES

Figure 1. M&A Activity, 1999 to 2004 ................................................................................................ 7 Figure 2. Change Absorption Rate.................................................................................................. 10 Figure 3. Strategic Fit: Business Model Combination Options........................................................ 14



STRATEGIC PLANNING ASSUMPTION(S)

Through 2010, 70 percent to 90 percent of Gartner's clients will be involved in some form of merger and acquisition activity as an acquirer, a target or part of a divestiture (0.8 probability).

ANALYSIS

1.0 Overview During the next five years, 70 percent to 90 percent of Gartner's clients will be involved in some form of merger and acquisition activity as an acquirer, a target or part of a divestiture (0.8 probability). For many of these transformations, IT organizations will help determine success — or failure.

This research provides a guide for how IT organizations can effectively support a merger or acquisition. We give an overall view of what happens in each phase. We examine the factors that dictate the strategy and rationale of the mergers and acquisitions (M&A) transaction, which help to set the agenda for the IT organization's action. We then provide guidance on what IT organizations can or must do during each phase of the M&A process, using a six-stage framework that highlights the enterprise and IT activities appropriate for each stage:

1. Screening: During this phase, the enterprise's finance, marketing or business development groups consider acquisition candidates. Because financial models influence the decision process, realistic cost/benefit analyses for the IT management aspects of potential targets are important for managing the eventual expectations of IT contributions.

2. Initial candidate evaluation: At this point, a specific candidate has emerged and the bidding process begins. Typically, there is little in-depth IT information available, but judicious use of public information can provide educated guesses for inclusion in the financial model.

3. Detailed candidate evaluation (that is, due diligence): This is probably the most-important stage for the IT organization. It provides the initial opportunity to obtain factual information to estimate the IT-related costs and risks of the transformation.

4. Closing the deal: The parties agree to the final contract terms and conditions. Because the IT transformation effort is typically greater than perceived, the quality of due diligence will serve well in keeping the realities in perspective during this negotiation period.

5. Executing the M&A: After the deal is done, the transformation begins — that is, tackling the operational business transformation processes and preparing employees for the new operational environment.

6. Operational review: A post-transformation review helps companies determine what went well and what didn't. By building this knowledge over time, the enterprise can reap the benefits of its M&A experience in future transformations.

IT and business managers must carefully examine the impact of a merger or acquisition on established projects and infrastructures. Choosing the systems to integrate and the timeline for their integration will depend on strategic, cultural and competitive considerations. The larger the acquisition, the more complex the integration process becomes and, therefore, how effective an



organization is in planning and execution will determine its success. A carefully implemented and managed M&A process, as discussed in this report, ensures the likelihood that the enterprise will achieve intended benefits from the acquisition.

2.0 Introduction Too often, mergers, acquisitions and divestitures can pose a "forced march" for IT managers. Commonly lost in the M&A process is the strategic objective — that is, enabling a new business model and/or culture to emerge — a transformation for which IT will be a critical component. An M&A focus is typically one of several strategic initiatives a company can pursue and, as such, must be viewed in the larger context of strategy management. Gartner research dedicated to presenting this larger picture from the IT perspective are:

• "Six Building Blocks for Creating Real IT Strategies"

• "Real IT Strategies: Steps 1 to 4 - Laying a Foundation"

• "Real IT Strategies: Steps 5 to 8 - Creating the Strategy"

• "Real IT Strategies: Step 9 -- Managing Transformation"

The goals of the M&A process are the same as taking two buildings and combining them into one — or, alternately, to moving them closer together and building bridges across various levels. In this process, the IT infrastructure and business process applications combine to create the new enterprise structure and its bridges.

It is critical, therefore, for IT managers to understand the strategic factors governing M&A activity, and the key considerations that enterprises and their IT organizations will face during each phase of the process. This section sets the topic in perspective by examining strategic considerations, such as M&A business drivers and pitfalls, as well as the various forms of M&A. Subsequent sections will explore each of the six phases of the M&A process in detail. The final three sections cover divestiture, software to manage the entire M&A process and what to do if you are being acquired.

2.1 M&A Business Drivers The security market meltdown in 2000 had a negative impact on M&A activity worldwide (see Figure 1). The number of international deals was approximately twice that of the U.S., while the value total is similar — that is, more, smaller deals.



Figure 1. M&A Activity, 1999 to 2004

Non-U.S.U.S.

Value($ in Billions)

500

750

1,000

1,250

1,500

2,000

1,750

20021999 2000 2001 200320021999 2000 2001 2003

5,000

7,500

10,000

12,500

15,000

20,000

17,500

Numberof Deals

20042004

22,500

25,000

27,500

30,000

2,250

2,500Non-U.S.U.S.

Value($ in Billions)

500

750

1,000

1,250

1,500

2,000

1,750

20021999 2000 2001 200320021999 2000 2001 2003

5,000

7,500

10,000

12,500

15,000

20,000

17,500

Numberof Deals

20042004

22,500

25,000

27,500

30,000

2,250

2,500

Source: Thomson Financial

Even with the slowdown, the underlying drivers have not gone away. For example, a 2005 Bain & Company survey of 960 global executives found that 55 percent agreed that "acquisitions will be critical to achieving our growth objectives over the next five years." The drivers for M&A can be classified into several categories, but at the heart of each is growth, as the survey indicated. There is no denying that senior management teams are driven to increase the size of their organizations because growth is viewed as successful. As most organizations grow, the "law of large numbers" causes them to run into a "growth wall" in their internal operations, and they are forced to look outside for help. The mind-set becomes "buy or die." It isn't unusual to see a corporation report revenue growth of 12 percent to 15 percent, with only 5 percent to 8 percent of that growth coming from internal operations and the rest coming from acquisitions.

Gartner has identified numerous M&A drivers and objectives. Multiple objectives for a single acquisition are not uncommon, and the following list is not meant to imply an order of preference.

Economies of scale (market share): The most-significant driver is a business leader's desire to leverage increased size to reduce the per-customer costs incurred by the enterprise. Typically, M&A driven by this goal are executed in the same or similar markets, thereby reducing the time and cost of integration, and leveraging increased size, geography or product reach. This approach is sometimes referred to (although not by its participants) as "buying market share." The typical promise to shareholders is that consolidation will improve savings, which will increase earnings, often through the merging of IT infrastructures, consolidation of production, and reduction of operations or selling, general and administrative (SG&A) costs.

Customer demand (market awareness): As consumers become more knowledgeable and demand lower costs and better service, competition for customers increases. At the same time,



customers are more in control of the terms of this competition than ever. Increasingly, acquisitions are being driven by the objective of capturing more customers to ensure a constant revenue stream, or to expand the market within which new products and services can be delivered. This facilitates cross-selling and common branding — common tactics for growth strategies.

Changing business models (market/channel creation): Many businesses are rethinking not only how they interact with customers, but also who their customers are. This has led many to acquire companies that provide complementary products and services to expand a one-stop-shopping concept.

Globalization: An expanding global economy has increased opportunities not only to ship product/service build/deliver offshore, but also to tap the global workforce to supplement internal staff or to extend the enterprise. As a result, activity has increased for acquiring offshore subsidiaries and service organizations to extend the enterprise's business or to add needed skills. "Going global" means that the time to establish and grow foreign businesses, especially in unknown markets, far exceeds that needed to execute an acquisition strategy. The consolidation of currencies and policies in Europe has contributed to increased M&A activity there, making it potentially more profitable to create North American/European business models.

Diversification: Companies often pursue acquisitions to fulfill a need externally, rather than in-house. They often need to obtain external competencies that cannot — or, for reasons of economy, should not — be developed internally. Such competencies include:

• Knowledge (for example, intellectual capital, skills or innovative techniques)

• Products (for example, to build a wider range of products and services that address convenience-based competition and keep the customer from looking elsewhere)

• Technology (for example, infrastructure, processes and capital)

Ego: The vision of business leadership is an important component in M&A activity. It is worth considering the degree to which the restructuring serves the personal agenda of the enterprise's leadership, or helps establish senior management's place in history.

Scavenging for value: Numerous acquisitions are made with the sole intention of imposing new management and cost-cutting practices, then reselling the company. This has been the practice of venture capital firms for some time, and is not the typical acquisition strategy of most other businesses.

2.2 Why Mergers Fail It has been widely reported that M&A failure rates are high —from 30 percent to 70 percent, depending on studies' methodologies and definitions of "failure" (which range from "broken" to "didn't achieve expectations"). The most-thorough study was conducted by Robert F. Bruner, recently named dean of the University of Virginia's Darden School. During his 20-year study, Bruner reviewed 130 scientific studies of M&A performance that considered stock market returns at the announcement of deals through the subsequent five-year period. The study results for buyers were startlingly simple: one-third reported M&A destroyed value, one-third claimed they broke even and one-third found M&A created real economic value. If two-thirds conclude M&A losses or a break-even stat, then that doesn't bode well for this strategic option. It emphasizes that senior management should carefully review those potential causes of failure to ensure their strategic M&A choices do not fail.

The most-common causes for M&A failure are.



Vision vs. Strategy: "Visions" are repeatedly mistaken for strategies. Visions are lofty ideals, basically setting up an infinite number of choices for the company to achieve. Strategies, however, focus on implementing tactical projects to achieve measured objectives. For example, "to be No. 1 in our industry" is a vision, while "doubling our market share by expanding X family of products" is a strategic objective. A strategy recognizes resource constraints and directs enterprise activity to maximize the deal's effectiveness. It's not unusual to read that the purported strategy for an acquisition is "to become the most dominant player in the market." Clearly, this doesn't provide direction for how to structure or execute the merger.

An effective M&A strategy addresses the desired business model, critical success factors, how to achieve competitive advantage and how to create shareholder value. Failure often occurs when, part way through the implementation, no one is certain what the business model should be and how it should operate. Unless quickly corrected, these situations can result in the merger becoming uneconomical or, even worse, detrimental to its survival.

Culture Shock: Culture essentially refers to decision making — that is, how individuals will deal with each other as they perform their roles. It is defined by the decision processes that will be used in the new organization, popularly known as "governance." Most public relations messages regarding mergers focus on how wonderful the new organization will be, and how well everyone will work together. In reality, most mergers turn into acquisitions, with the acquired organization forced to adopt the acquirer's decision processes. These processes are embedded in all business management practices — for example, decentralized vs. centralized management, authoritative vs. team-based management, strong vs. weak financial control, the treatment of people as valued resources vs. expendable commodities, and defined vs. ad hoc processes. Failure sets in when these processes disenfranchise groups of employees, making them feel like they are on the outside looking in or, worse, if they judge the processes as being "stupid."

Mergers are intense, complex activities and need everyone pulling in the same direction. Like a strategy, if this point is ignored, a quick remedy will be needed to keep the merger from grinding to a halt.

Overpayment: A company that finally understands it paid too much for the acquisition also realizes that expectations were set too high. Unfortunately, it must acknowledge lower-than-expected revenue or higher-than-expected costs. The IT organization's involvement is more closely associated with the cost side. Failure in this case is financial and usually does not mean that the merger cannot be completed, but it means that the benefits couldn't be achieved.

Inadequate Due Diligence: The three failure factors mentioned above can be mitigated through effective due diligence — that is, understanding risk and reducing it to its minimum. The acquirer gets to probe into an acquisition's assets and operations, forming an opinion of its value and creating a basis for all implementation plans. Failure sets in when the execution slows or stops after encountering the reality of the unknowns missed during due diligence.

Poor Execution: This means that the acquisition process has not been managed properly. In these cases, Gartner often sees a lack of senior management involvement, resulting in decisions not getting made in a timely fashion and thus prolonging the agony. A PricewaterhouseCoopers report ("Evolving Approaches to M&A integration") published in 2004, based on a roundtable discussion among 11 well-known Silicon Valley companies active in M&A, underlined this point. Virtually all of the participants admitted that their early M&A activity gave little thought to integration, with the result being a chaotic inefficient aftermath. They all have since transformed their programs to an execution framework that actively engages management at all levels in both companies using repeatable but adaptable processes.

Ignoring Customers and Business Partners: A business is acquired because it has a market value defined by its customers and business partners. This value must be preserved and,



therefore, requires a careful balance between getting the integration done and getting it done right. When integration alone becomes the driving focus, then customers and business partners may see a loss of value to themselves, prompting them to sever relationships with the merged company.

Negative Market Response: This occurs when the acquirer fails to anticipate what others may do to counteract the deal's benefits. Executing an acquisition can take six months to three years, and during this period the acquirer is committed to a course of action. If the market is at a flex point and can move in a different direction, the competition can trump the acquisition by changing the game, leaving the acquirer with a bad investment. This is less likely to happen in a known market (that is, one in which the acquirer already competes), but it is more likely to occur when an acquirer enters a market as a neophyte.

Too Much Change: Every organization has its own absorption threshold after which less, not more, change can be assimilated (see Figure 2). Management can improve this capacity for change through effective change management, but the extent of this improvement will also be limited. Enterprises executing mergers often set high expectations for achieving a high degree of change within a short time frame.

Figure 2. Change Absorption Rate

Amount of change that can be absorbed in a given period

(volume, velocity, complexity)

Percentage of organization's

capacity for change

Absorption Threshold

0%

100%

Change Management Effect

Amount of change that can be absorbed in a given period

(volume, velocity, complexity)

Percentage of organization's

capacity for change

Absorption Threshold

0%

100%

Change Management Effect

Source: Gartner (December 2005)

Failure occurs when organizations are pushed past their thresholds — the transformation slows, and the more that senior management presses, the less gets accomplished. This is most obvious when companies are working on radically changing their business models, while simultaneously making acquisitions. Unfortunately, there isn't a measure for an organization's change capacity, but most employees know what they can handle, at which time management needs to slow down and evaluate what they are asking employees to do.

2.3 The M&A Approach: Three Models At an early stage — certainly by Stage 3 — most companies will identify the best approach for integrating the organizations.

Gartner has identified three principle models for corporate consolidation, specifically as they affect business processes.



1. Absorption: The acquired organization is completely absorbed by the acquirer. The acquirer's business processes dominate, and the acquired organization must adopt them. This focuses the IT effort into one of understanding how much difference exists between the target organization's former business processes and the new ones it must accommodate. These differences typically center on how the business sells to its customers and the associated underlying contracts.

2. Stand-alone: The acquired organization remains independent. In this approach, the company being acquired remains a separate, stand-alone organization with only some integration of support services (for example, phones, networks and data centers) to achieve economies of scale. Financial reporting is the one business process that typically must conform to the buyer. This is, by far, the least-disruptive model.

3. Merger of equals: A best-of-breed organization is developed from both parties. In this approach, the strongest components of each organization are used to build a new business model. Each business process in the merging companies is evaluated, and the best are selected and integrated into a new set of processes to serve the new business model. This model entails the highest degree of change and risk.

These are mutually exclusive models but can be combined in a merger event. For example, one business unit may be targeted for divestiture and, therefore, run as a stand-alone unit, while the others are absorbed. Divestiture activity could take place within any of the models. For a divestiture, a choice of models is again made, but by the new acquiring organization.

3.0 M&A Process Stages: An Overview The M&A process consists of six stages, each of which has a distinct purpose and depends on the stages that precede it.

• Stage 1 — Screening: Most acquisition opportunities don't just "come along"; usually, the acquiring enterprise has had a small group working internally, searching for opportunities. The participants typically are involved in finance, marketing or business development.

• Stage 2 — Initial Candidate Evaluation: In this stage, a specific candidate has emerged and the negotiation process starts. Typically, little in-depth IT information is available at this point, but judicious use of public information can provide educated guesses for inclusion in the financial model.

• Stage 3 — Detailed Candidate Evaluation: The principal activity in this stage is due diligence. The IT organization must be involved at this stage because it gives them an opportunity to see how the target truly operates its business. This is also the final opportunity to obtain the factual information needed to estimate the costs of the transformation and to understand the underlying risk before the deal is closed.

• Stage 4 — Closing the Deal: The agreement is not truly a "deal" until the final contract terms and conditions have been hammered out. This is where "the squeeze is applied," and cost takeouts often grow to justify the offer price. For the IT organization, the transformation effort is usually greater than perceived. The quality of due diligence will serve well in keeping realities in perspective during negotiation.

• Stage 5 — Executing the Merger/Acquisition: There are four phases to this stage:

1. Intensive planning for business and IT projects, and the resolution of personnel-related issues



2. A focus on early transformation projects to achieve momentum (for example, infrastructure, finance and HR)

3. Tackling all the operational business transformation processes

4. Preparing employees for the new operational environment

• Stage 6 — Operational Review: This is the process employed to help the newly consolidated organization get past the problems of newness and stabilize enterprise operations. The company uses a post-transformation review to learn what went well and what didn't. In this way, knowledge is built over time so that everyone involved in the M&A process can benefit from the experience by applying the lessons learned to the next event.

The next sections explore these stages from two perspectives: what is happening overall, and what the IT organization can and should do.

4.0 Stage 1 — Screening A key contributor to M&A failures is the lack of a clearly defined strategy or the failure to communicate the strategy completely and effectively. The screening stage is focused on defining the goals, strategies and initiatives of the acquiring enterprise or business unit. In larger companies, this is typically the responsibility of business-unit management, with the participation of the enterprise business development team. In smaller companies, this activity typically is managed at the enterprise level. It is relatively rare for anyone from the IT organization to be directly involved at this stage. Most of the available information at this stage is financial or demographic; there is almost nothing of an operational nature in the public domain.

4.1 Screening Activities Key enterprise activities during the screening phase include:

• Develop the business strategy that will become the bounded framework for candidate selection.

• Identify and prioritize potential markets or business areas of interest.

• Evaluate the enterprise's own strengths and weaknesses. Risk will be proportionate to the organization's ability to support its extension into other markets (for example, global).

• Select and prioritize possible acquisition candidates.

• Seek service providers to help with the acquisition activities to strengthen M&A capabilities (that is, offset weaknesses).

• Conduct an initial investigation of an acquisition candidate (that is, gathering information about the target enterprise) that may include a preliminary, exploratory meeting with the candidate's management or other principal players. Individuals in a specific business unit or the business development team may undertake this investigation. The person responsible should write a set of standard questions about the situation.

• Schedule preliminary "get acquainted" and "determine mutual interest" discussions with company's initial contact.

Among the many ways to execute a search is to use Gartner's target attractiveness indicator (TAI). This tool leverages Gartner's Magic Quadrant research. TAI adds the financial metric enterprise value multiple and positions companies in a market segment based on two axes



(Ability to Execute and Completeness of Vision) of the Magic Quadrant. The resulting graphic presents companies on a comparative basis, thereby facilitating the decision as to whether to pursue an acquisition and identifying the level of due diligence required (see "Growth Through M&A Is Not a Panacea").

4.2 What IT Can Do Every merger comes down to integrating the operations of two or more companies, and this is where the IT organization gets involved. The ultimate success of a merger will greatly depend on understanding the operational variables involved.

At the center of all acquisition efforts is a spreadsheet — or a software package, if more sophisticated tools are used — that models the financials of the deal. At this early stage, financial data will be limited and, therefore, many estimates will be used to fill out the picture. Using the spreadsheet, a buyer will attempt to predict cash flow streams that will balance revenue and expenses, providing the basis for an eventual price. A good place for the IT staff to begin supporting this stage is to lend their expertise on what it costs to provide and run the IT infrastructure to support the enterprise's operations. Much of this knowledge will feed the estimates used in the spreadsheet.

At this stage, a sense for which of the three M&A models will define the acquisition's approach should emerge. Each has a dramatically different cost profile that will affect the values used in the spreadsheet:

• In the absorption approach (that is, complete absorption by the acquirer), the candidate is typically within the acquirer's industry. In this case, the IT organization's financial data is likely to be accurate and should be the primary source of estimates.

• The stand-alone approach (where the acquired organization remains independent) would simply use the candidate's own financials, although some infrastructure consolidation estimates could be used in areas such as telephones, data networks and data centers. Reliable savings are difficult to estimate at this early stage; therefore, Gartner recommends waiting until Stage 3, due diligence, letting target costs represent a conservative estimate of IT cost.

• The merger-of-equals approach is the most difficult for which to estimate reasonable integration costs. Again, Gartner recommends waiting until Stage 3, when necessary information becomes available.

The important IT contribution for Stage 1 is to determine appropriate cost estimates, enabling the buyer to evaluate the candidates. Because financials can be "set in stone" quickly — often long before necessary details are known — it will behoove the IT organization to get its perspective on "what it will really take to do the job" incorporated into the financial-planning process as early as possible.

4.3 Key Actions The IT organization's contribution in this phase is to develop two sets of financial estimates: IT transition cost and ongoing IT operating cost. These costs will be affected by differences between the acquirer and acquiree's business models; therefore, a framework is needed to guide financial model development. For absorption and merger of equals, the principle factor affecting costs is the degree of business process integration. Since IT organizations can't see inside potential target companies to evaluate this, one needs a publicly available approximation. Business-unit structure and management style offer such an alternative. Within this, the critical dimension of



decision control as it shifts between the business unit and the enterprise provides a good correlation with the degree of business process/application integration.

To keep this simple, we select three models from the spectrum of decision control (see Figure 3) or process integration. At one extreme is centralized management, where decisions and applications defer to the enterprise's needs, typically resulting in well-integrated applications. At the other extreme is decentralized management, where the business unit is in control and the typical result is duplicate applications spread across all the business units. In between is a federal model that selectively shares responsibilities and applications. Cost, value and effort will vary in each M&A and divestiture activity based on how these business model types match up between target and acquiring organizations.

Figure 3. Strategic Fit: Business Model Combination Options

Target M&A Model You

Enterprise

Federal

Business Unit

Absorption

Equals

Stand-Alone

Enterprise

Federal

Decision Control (Process Integration)

Centralized(Enterprise)

Decentralized(Business Unit)

Selected Sharing(Federal)

Business Unit

Target M&A Model You

Enterprise

Federal

Business Unit

Absorption

Equals

Stand-Alone

Enterprise

Federal

Decision Control (Process Integration)

Centralized(Enterprise)

Decentralized(Business Unit)

Selected Sharing(Federal)

Business Unit


Between the target and acquirer business models we need to put the M&A model used —that is, how will the merger be implemented? There are theoretically lots of pairings, but only a few will be relevant to your organization. Select a few that best represent the real options to be used in your M&A and divestiture activity, and then develop more-detailed financial models for each. The exception is a merger of equals, where a general-purpose estimating cost model will not work because it's too complex. These are rare events and should be managed individually.

Some exploratory thoughts based on acquirer business model:

• Enterprise — An organization that has an integrated business model will typically absorb the target. Therefore, the effort required will increase as the target business model shifts from enterprise to federal to business unit. For example, if the same vendor software (for example, SAP or Oracle) is used in an enterprise-to-enterprise situation, then the absorption effort will be straightforward.



• Federal — The shared components are usually at an administrative support level, such as finance, HR or purchasing. Typically, a business unit will make the acquisition and, therefore, will likely adopt the absorption or stand-alone model. A conspicuous exception has been the financial services market, where business models remain federal and the high-profile mergers have executed a merger-of-equals approach.

• Business Unit — The principle issue is how many business units in the target and in the acquirer will map to each other. The transition potentially requires disassembly and assembly processes to execute. For example, an enterprise-model target would have to be deconstructed to then be absorbed into the appropriate business units of the acquirer, each with its unique systems.

4.3.1 Constructing Cost Scenarios

We introduce the concept of cost scenarios in this stage. The objective of later stages is to refine these estimates and get them as accurate as possible. This methodology is designed to work for the absorption type model only. The stand-alone type will have some IT operations savings, but the savings is typically not large and is only reasonably definable in Stage 3, due diligence. Up to that point, target operating costs represent a conservative estimate of IT operating costs. The merger of equals is too complex in their individuality to be reduced to a dependable cost-estimating model. Stage 3 offers the first opportunity to evaluate reasonable IT merger costs.

The best available data to use in estimating IT acquisition costs lies within the acquiring company. By applying Gartner's methodology, the IT organization can develop representative cost models for finance to use in its considerations of target companies. Three unique financial sets of IT data are needed:

1. Capital costs to execute the acquisition

2. Expenses to execute the acquisition

3. Ongoing operating cost

We will first discuss baseline cost models and then apply them to the option sets identified by the dashed lines in Figure 3.

The methodology uses acquirer cost profiles that are known — that is, the information it acquires itself and adjusts based on the rather limited publicly available information. A foundation set of scalable parameters based on publicly available information includes:

• Revenue — Because the target is probably in the same industry, revenue can be translated to the number of transactions that, in turn, drive the scale of the IT infrastructure to support business operations. This represents the basic cost that the remaining parameters would increase or decrease by adding, subtracting or multiplying.

• Number of employees — This drives costs associated with the employee desktop infrastructure. It overlaps with the base cost but represents a distinct cost pool and introduces a degree of conservatism.

• Geographical presence — This determines the degree of overlap with the acquirer's geography. If a match, then it becomes largely a network and computing capacity issue. The less overlap present poses new issues of extending the network or adding new support capability and, possibly, computing centers, especially if it involves several countries.



• Sophistication — This is an option to introduce a factor to cover the possibility of the target having a better operating environment than the acquirer. It introduces additional conservatism to the estimate.

• M&A model mapping — Figure 3 shows the possible complexities that need to be accounted for.

Although these five parameters interact, they are valuable for estimating costs. There are two ways to build a financial cost model: designate a value for each variable that can be multiplied by the number of employees, for example, or build a table of representative values for parameter ranges. The single-factor method has a drawback in that it can't recognize the nature of some IT costs not being a straight line, but a series of steps. Using a table enables the IT organization to deal with all the parameters, factoring in subliminal issues surrounding cost buildup while giving the financial people an easily used set of numbers.

The model will consist of five tables, one for each of the variables described above. A row in each table has four columns:

1. A variable value range (for example, 1,500 to 2,000 for the employee table)

2. The associated capital cost

3. The associated conversion cost

4. The ongoing operational cost

The first step in filling in the tables is to estimate the three cost values for acquiring and integrating through absorption a company like yours. These values become the anchor row in each table from which all other entries are based — that is, scale up or down from your baseline entries. The key to each table is the variable description that defines each row. Determine what is a reasonable cost estimate for that range. When the estimate doesn't seem right for either extreme, then define a new range.

The tables based on revenue and employee count are straightforward because they deal with specific numbers. The values in these tables would be populated by estimating absorption costs for companies that are larger or smaller than yours.

Geography ranges can be defined by a set of the most likely combinations beyond your base — for example, Western/Eastern Europe or North/South Asia — with their detailed descriptions placed in footnotes. Some combinations may force you to consider placing additional computing centers in other regions. Remember that the basic premise of this model is to provide conservative estimates of potential future costs, not exact costs.

Ranges for the sophistication factor could be defined by scenarios describing operational differences known in the industry whose cost value is simply a number (for example, 1.2) representing how much better operationally the acquired company is than your company. These multiples would be the cost variable entries for each row.

The M&A model mapping factor is a multiple that increases the costs based on which path in Figure 3 is being followed. The baseline multiple of 1.0 is for the path where you and the target have the same business model. Generate a row for each path that it seems you will encounter, and add appropriate multiple entries for each cost value.

For a specific target, the financial staff would develop a cost scenario based on the five tables.

• Find the appropriate key description in each table using publicly available information.



• Select the associated costs from the revenue, employees and geography tables and create three subtotals.

• Multiply each of these subtotals by their corresponding sophistication factors.

• Multiply each of the original subtotals by their corresponding M&A model mapping factors.

• Add the two calculated sets of costs to get final cost scenario totals for capital, conversion and operations.

Admittedly, these values may not hold up as more is known. For example, capital expenditures are dependent on actual IT infrastructure capacity at the time of acquisition. These are intended to be conservative, initial estimates that will be refined as more information becomes available in later steps.

4.3.2 And Then There is Time

The companion to cost is time; however, schedules are one of the most perplexing things to deal with in an acquisition. Management is understandably eager to complete it quickly. They want all the benefits as soon as possible. There never seems to be enough time allocated to executing the merger. However, companies that spend "too much time" contemplating a deal may lose out to competitors. Logically building a framework on which to construct a hypothetical transition time schedule has great value.

The value generated for transition cost correlates to the people time associated with executing the merger. Developing an appropriate divisor that represents the cost of the people pool available will yield project duration. To do this:

• Develop a standard employee cost for a fixed duration, such as a month or year.

• Develop a standard outside source cost for a fixed duration.

• Estimate the number of people who can be made available for the project from each source, inside and outside the company.

• The product of each set is summed, with the result being a standard cost for a fixed duration.

• Divide this standard cost into the total transition cost and project duration is the result.

This is a rather crude method but is relatively simple for a financial analyst to use. Guidelines can be added to alert an analyst to times when IT should be involved with the estimation.

5.0 Stage 2 — Initial Candidate Evaluation This stage begins when a specific candidate has emerged and the bidding process starts. As in Stage 1, in-depth IT information is not typically available, but judicious use of public information can provide educated guesses for inclusion in the financial model.

5.1 Action Items Resulting From Screening Stage 2 starts with a series of steps resulting from the activities performed in the screening phase. These steps include:

• Debrief the initial contact, and "brainstorm" possibilities with business development staff. Consider integration with established company priorities.



• Analyze each acquisition candidate to determine whether to proceed, defer action or remove it from consideration.

• If the decision is to proceed, consolidate information from the initial contact.

• Schedule initial meetings and invite appropriate participants from:

• Sales (for example, U.S., Europe and Asia/Pacific)

• Marketing

• Finance

• Legal

• Market research

• IT organization

• HR

• Facilities

5.2 Preliminary Analysis In the preliminary analysis, the target enterprise is mapped against the business-unit requirements. Initial synergies, market opportunities, and "stalking horse" revenue and growth assumptions are articulated. Typical questions you should answer during this phase are:

• Does this candidate offer products similar to ours?

• What are the gaps, and how significant are they?

• To what extent do these products account for the candidate's total revenue?

• How much profit is derived from these products' revenue?

• Does this candidate sell products in a manner similar to ours?

• How do the geographies line up between the organizations?

• Is this candidate engaged by us now, or has it been during the past 12 months?

• What is this candidate's culture and how is it different from ours?

• Will this acquisition lead to market consolidation or will it extend our breadth?

• Does this company have a "good reputation"?

• Does it have significant brand equity?

• Is any significant legal action pending against this company?

• What is the likelihood of retaining key people?

• Is there a possibility that some part of the candidate enterprise will be divested?

• What does the industry think of the candidate's management team?



• Do our associates know of any adverse reaction to the candidate?

In the case of auctions, the process typically involves data access through a third party brokering the deal, on-site visits or, increasingly, through use of restricted-access Web sites.

5.3 What IT Can Do After you've identified a specific candidate, the IT organization can gather more-refined information. For example:

• The principal focus is to enhance the accuracy of the financial estimates embedded in the controlling spreadsheet. Because not much more is known about the target, this is the chance to validate the original scaling parameters and change calculations, if appropriate.

• If the candidate is in the same industry, you can garner information from contacts in the IT or enterprise community. For example, an employee who participates in a best-practice group with someone from the target enterprise may have valuable insight to deliver.

• These contacts may also provide valuable "soft" information, which should be reported to the business development group. This includes information about the target company's reputation, its recognition as a leader in certain areas, or key projects or initiatives that may be exceptional or in trouble.

• Some employees may have worked for the candidate and have detailed knowledge of various operations that can be translated into better support cost data.

• If there is a potential for divestiture, the associated costs must be added to the spreadsheet. The IT organization should establish a set of assumptions that the business development group can use when analyzing the candidate. Like mergers of equals, the divestiture issue is a relatively infrequent component of M&A. Most acquirers will not offer to buy that part of the company. However, if the divestiture is under consideration, bring the IT organization into the deliberation to get a better idea of the issues and cost.

• If it appears that this will be a hostile takeover, remember that "hostile" is just a term meant to reflect the opposition of the target's board and senior management, and does not extend below that. Because a confrontational attitude will increase the risk of failure during integration, the people involved in the merger must take as nonhostile an approach as possible.

6.0 Stage 3 — In-Depth Candidate Evaluation: Due Diligence Every acquisition goes through a due-diligence process designed to gather the information needed to determine whether and how an acquisition offer will be made. Most early due-diligence activity is hidden from view, but, at some point, it usually becomes necessary for the acquiring organization to conduct an on-site visit with the acquisition target.

This is probably the most-important stage for the IT organization, because it provides an opportunity to see how the target enterprise operates its business. From a business perspective, this stage focuses on three main areas: financial, business operation and legal. In addition to examining general due-diligence criteria, this section contains extensive guidance on the IT organization's role in conducting an on-site due-diligence visit with an acquisition target. This will



typically involve three perspectives: IT infrastructure operations, business process/applications and IT organization.

6.1 Due-Diligence Assessment Criteria A typical feature of successful M&A programs is the development of a series of questions or criteria designed to help companies understand the gaps between the acquirer and target organization. This gap analysis should lead to a sense (whether formal or informal) of the size of the integration effort. The ability to make these assessments is the essence of the due-diligence stage. In addition, information is collected to estimate asset value and expose potential risks — financial and operational. Because this stage does not take a long time, IT management can only make educated guesses regarding many of the issues raised.

Companies that have a business strategy of growth through acquisition usually have a designated team of M&A specialists and a defined process for integration that can be activated at any point in time. If the acquisition process is always active, then the organizations that are best at acquiring businesses use a corporate project office to keep all the stages of multiple events under control. Gartner recommends that all enterprises anticipating repeated acquisitions as fundamental to their growth strategy should adopt this approach.

The foundation of due diligence is a checklist or questionnaire for organizing a comprehensive evaluation of the target's assets, liabilities and capabilities. The IT organization is typically asked to contribute its list to be incorporated into the overall master checklist. Each company will often have additional entries that reflect its specific interest. We used the combined term of checklist and questionnaire because companies often use a questionnaire to solicit target answers before an on-site visit. The checklist points to areas of interest, but it can easily be converted to questions by using phrases such as "What does your…?" or "Provide a list of …". Avoid asking questions that can be answered with a "yes" or "no" because for every "yes" answer, you'll need to ask an additional question.

6.2 What IT Can Do If the IT organization has been engaged in the first two stages, it will be in an excellent position to support the due-diligence stage. Unfortunately, Gartner has found that such prior IT involvement too often has not taken place. More typically, this is the first stage in which IT managers become aware that any M&A activity is under way. As a result, IT managers often have little time to assess and integrate all of the factors that might affect the successful transition and integration of technology-based infrastructure and applications. It is not uncommon for the IT organization to have only two or three weeks for the due-diligence phase of the M&A.

In this section, we present a best-practice approach to due diligence, where target access is open, allowing for a reasonable in-depth evaluation to be made. Unfortunately, there are situations where the target company severely restricts access, limiting information gathering activity.

For most acquisitions, the IT organization has one opportunity to "get it right" — the due-diligence on-site visit. Within a typically tight time frame, the IT organization must develop credible cost and time estimates for executing the integration. It must gain agreement from each functional group regarding what applications will be used, and what modifications will be necessary to effect the transition.

The due-diligence visit typically consists of three phases:

• Preparation

• On-site execution



• Wrap-up

6.2.1 Preparation

The following organizational elements should be in place.

• Enterprise leadership is committed to a strategic outcome for the M&A.

• A senior-management sponsor — an individual or a steering committee composed of business and IT leaders — is responsible for overseeing the M&A's progress.

• A business program manager or similar leader responsible to the senior-management sponsor is in charge of the execution of all M&A projects (including IT-related ones).

• An IT program manager leads the IT team and is responsible to the business program manager.

• A group of IT application specialists is responsible to the IT program manager for the execution of focused projects — for example, functional review, data integration and IT liaison with target for special projects.

• An IT due-diligence leader and team, responsible to the IT program manager, consist of all the personnel necessary to assess the acquisition target's IT operating infrastructure and assets.

• An acquisition target's team members will serve as interfaces for the acquiring enterprise during the due-diligence visit.

Typically, IT organizations that perform due-diligence work most effectively have implemented a reasonably formal process (that is, one that can be repeated and improved on) to integrate their and the target teams' work. Careful preparation prior to the due-diligence visit will maximize the effectiveness of interaction with the acquisition team. Courteous, thoughtful questioning will lead to valuable insights on how the acquisition target operates and will provide a sound foundation on which to make preliminary integration estimates. This visit will typically be a "one shot" opportunity to get the information needed because access to further information will likely be limited once the visit is over.

During the visit preparation, the acquirer appoints a team leader who selects knowledgeable people across the domain of the business processes affected. The acquisition target will usually limit the total size of the team, which can range from 10 to 50 people, depending on the scope of what is being acquired. IT people on the due-diligence team will usually include one or two experts on IT infrastructure, and one to three experts on application software.

At this point, the integration approach that will be used should be known, or at least limited to two of the three potential M&A models.

• If an absorption approach is expected, the focus is on understanding the changes that may need to be incorporated into the acquirer's systems and processes.

• If a best-of-breed approach is anticipated, the focus will be on a strong dialogue between functional counterparts, with the objective of establishing some mutual agreement on which systems are best. A common problem is that this effort can quickly become one-sided because the acquisition target cannot examine the acquiring enterprise's systems. To offset this, a visit can be set up to acquaint the acquisition target's team with the acquirer's systems. Another option is to install some workstations at the acquisition target's site to demonstrate the systems in parallel.



• For the stand-alone option, because the focus is on the quality and integrity of the acquisition target's systems, the approach used will be akin to an audit.

The time for on-site due diligence is typically limited to one week or less. Therefore, the acquisition target should be asked to gather essential information prior to the team's arrival.

In addition, the acquisition target must be provided with a list of the interviews it will have to set up for the due-diligence team. IT infrastructure interviews are exclusive to the IT organization, but functional interviews should be coordinated with the business function due-diligence teams. Omitting this step will irritate the acquisition target because it is forced to do the same thing repeatedly. In addition, it is poor image management; the acquirer looks disorganized and not in control. Because the IT people needed for the on-site visit are typically not needed for the entire duration of the due-diligence process, they should be scheduled to keep the overall process manageable. The due-diligence team leader should stress the importance of professional and courteous conduct during the on-site visit, and should prepare the team with some rules of engagement. For example:

• Remember that acquisition target personnel are likely to be nervous, so it is important to leave a good impression.

• Be courteous at all times.

• Respect their knowledge.

• Don't discuss due-diligence team business in front of the acquisition target's personnel.

• Never make negative or judgmental comments.

• Never reveal information about your recommendations.

• Remember that the target company is evaluating the potential acquirer as well.

• The acquisition target will share negative impressions of due diligence with management, which will act to address them.

• The wrong attitude can kill a deal.

6.2.2 On Site

On arrival, the IT people need to get organized.

• Locate the due-diligence team room. Acquisition targets like to limit the mobility of the team members and control their access to employees. An exclusive team room resolves these issues and gives privacy to team members.

• Find the requested data, often partially available online.

• Confirm the team's plan of operation with the business program manager or due-diligence team leader.

• Based on preliminary planning, build a schedule of activities based on availability of the acquisition target's staff.

• Meet and talk with the designated application target's lead. Review the process and time frame needed, and settle on a target work plan (what to cover when, and what information is available or missing).



• Confirm plans for functional demonstrations in conjunction with functional teams.

• Establish an IT liaison with the acquisition target for supporting special due-diligence team requests.

A typical day's activities for the IT due-diligence team leader include:

• Prepare data for interviews.

• Meet with appointments, and coordinate with functional leaders.

• Push to get demonstrations of processes in operation, and obtain information about process details and people.

• Develop business process flowcharts for reference by the due-diligence team.

• Cycle through team members several times a day to address needs or issues, such as problems with data.

• Keep checking off requested data items as they are received and completed.

• At the daily debriefing session, meet with the team to refine the financial model and identify areas for further review. Come away with a "to do" list of IT activities.

• Obtain functional members' impressions of application systems, and pinpoint potential integration issues.

• Debrief the IT team at day's end and plan the next day's schedule.

• In the evening, expand and update the integrated set of process charts, and post them in the due-diligence team room.

As a result of data review, due-diligence team members will often request additional data, typically in the form of a report. To avoid traps in technology translation, the team IT support person and the acquisition target's IT liaison should talk to each other.

Each group on the due-diligence team is assigned to gather specific information that will be used in the acquisition financial model. For the IT organization, these items include an IT infrastructure disposition, IT staff disposition, and application transition cost and timing estimates. The information gathered will fall into one of four categories: acquisition model financial data, functional knowledge, organization knowledge and "deal breakers" —items that, in all likelihood are rarely found by the IT organization, will terminate acquisition activity.

It can be important for the team to see how, and whether, the business processes interface. Simple diagramming tools can be used to build an overall picture. These process charts can serve as a collective memory to help the due-diligence team build an overall understanding of the total business operation.

Effective due diligence is all about asking good questions. Acquisition target personnel may have things to hide, but they will be obligated to answer questions truthfully. In-depth questioning on functional business processes will lead to planning the transition for each set of processes, often resulting in modifications to established systems. Gaining concurrence with due-diligence functional team members is key to understanding the true scope of the eventual acquisition integration.

If the company expects to use the absorption model, then it must understand any impact on the target's customers and vendor relationships. The acquirer cannot afford to lose these clients and,



therefore, must evaluate what activities or projects must be completed to ensure client and vendor retention. The eventual list of projects will need to balance ongoing retention efforts and timely completion of the merger.

Because most acquisitions require staff reductions, it is important to remember that people-related assessments are an essential part of the due-diligence process. Organizational change costs will be fed into the financial model.

Conversely, the due-diligence team should be aware that, because its enterprise may be competing with other organizations that also want to acquire the target, it is being evaluated by the acquisition target as well. Part of the due-diligence team's task is to convince the target that the acquiring enterprise is the strongest candidate with whom to merge; therefore, they will have to reveal something about themselves and their company. When acquisitions become auctions and the asking price becomes inflated, the quality of the acquirer's organization can, to some extent, justify a lower offering price.

6.2.3 Wrap-up

After the on-site phase is complete, create a formal report that summarizes the information supporting the early estimates posted to the financial model during the due-diligence visit. Sample sections include:

• An assessment of each functional area

• Recommendations for transitioning the IT infrastructure

• An estimate of the IT resources and time required to effect the transition

• People assessments and recommendations for IT organizational-structure changes

• Estimates of transition costs

6.2.4 Remember the Strategy

When an enterprise strategy emphasizes growth through acquisition, the perspective of what this entails often gets lost when working on a single event. Everyone focuses on getting the acquisition done quickly, while taking as much cost out as possible. Although cost takeout pays for mergers, the real objective is to increase revenue. If the merger model is absorption or stand-alone, then, as each event is executed, the resulting operating environment gets increasingly compromised. In the case of the stand-alone model, duplication of business processes raises the cost of doing business, which lowers revenue and defeats the overall growth strategy. Cost bloating happens in absorption as well, except the constant growth creates scaling problems that eventually erode profit.

An aggressive acquisition strategy must keep in the forefront the notion that business operation of this expanding enterprise must be efficient to protect the added revenue being purchased. The solution inevitably involves increased investment in IT projects to build correctly scaled and integrated applications. Unfortunately, this means that each M&A event has to contribute to a fund that is directed at the strategic evolution of applications in support of business operations. This is a true cost of acquisition, but one that is almost always ignored.

At the very least, the IT organization needs to keep management aware of the implications of its acquisition strategy. It must present a realistic picture of business operations to senior leadership. The best vehicle for accomplishing this is an IT strategy tied to the business strategy — that is, don't just chase tactical M&A events but keep the overall strategic end game in sight. During the M&A event, the company must balance acting tactically with planning strategically.



6.3 What to Do When Target Access Is Limited The discussion so far has assumed access to the target, but there are times when that access is limited to a few high-level executives. These executives may not be knowledgeable about daily operation and therefore can't be expected to go to the depths we have presented. The most-important point is that those executives must understand they are being restricted from getting valuable information necessary to estimate the true value of the merger and the cost to execute it. They must understand that critical decisions are being pushed into Stage 5, where time becomes an enemy — the window is limited for executing the operational aspects of the merger.

All that we have presented has to be resolved eventually, if not in this stage then in Stage 4 or Stage 5. The work doesn't go away simply because it wasn't done in the appropriate stage. Deferring the effort raises the risk for having to live with uninformed decisions. Because there are degrees for limiting access, there really isn't a magic "must do" list when in this situation. Be aware of what should be done, and get as much of it executed in this stage as possible. Any information is better than none, and that should be the credo in situations such as this.

7.0 Stage 4 — Closing the Deal During this stage, the deal is consummated, documents are signed and funds are transferred. Execution of this stage is usually assigned to corporate staff, although it may involve external staff.

7.1 Negotiation Negotiation is the process of defining an initial offering price for the target enterprise, and identifying nonnegotiable items (for example, an independent sales force). Factors in determining the initial offering price include:

• Continuous and noncontinuous revenue streams

• Historical and projected growth rates

• Profitability

• Impact on earnings per share (including calculations for foregone interest on the purchase price and amortization of goodwill)

Participants in the negotiation process are typically corporate and business-unit business development personnel, with support from corporate financial-planning and business-unit management. Negotiation activities include:

• Performing a preliminary price assessment

• Developing a letter of intent

7.2 Due-Diligence 2 Once a letter of intent has been issued to, and signed by, the target enterprise, a second round of due-diligence activities commences, known as due-diligence 2. This stage includes a detailed look at terms and conditions, an examination of contracts and leases, and a review of detailed corporate financial statements, customer lists, facilities and personnel. Participants include key business-unit personnel, corporate and business-unit business development staff, and corporate departments, such as IT, finance, HR, facilities, sales, production and distribution.

Areas of due diligence 2 activity include:



• Final pricing and payment

• Terms and conditions

• Payment and holdbacks

• Management

• Operations

• Benefits

• Employment letters

7.3 Transition Planning Transition planning begins during the initial due-diligence phase, and continues in parallel with negotiation and due-diligence 2 activities. The objective of transition planning is to develop product, operating management, budget and marketing programs for the integrated entity. Participants in transition planning include personnel from all corporate departments and business units affected by the acquisition.

Areas of transition-planning activity include:

• Management and staff issues

• Senior management

• Analysts/consultants

• HR

• Benefits transition

• Public relations

• Investor relations

• Finance

• Payroll

• Accounting

• Operations

• Production

• Facilities

• IT organization

• Product marketing

• Product planning

• Product integration

• Branding



• Pricing

• Distribution

• Sales

• Sales force integration

• Sales management

• Quota impact

Tactical guidelines for effective transition planning include:

• Use speed to counter anxiety and reduced productivity — that is, keep everyone busy.

• Don't try to understand everything. Instead, focus on the main issues, applying the 80/20 rule (80 percent of what is important will be represented in 20 percent of what needs to be done).

• Decision making is key, so organize to get decisions made quickly. Don't become a democracy — there isn't time.

• Keep everyone informed of what is important. If the deal is global, this communication must be sensitive to cross-cultural issues.

• Resolve organizational-structure issues as quickly as possible. People need to feel comfortable with how they fit in, and often see their value to the enterprise in these terms.

• Strong leadership throughout the M&A process has proven to be one of the most-significant determinants of achieving expected results.

7.4 What IT Can Do The principal role for IT in this stage is to be the integrator among all the operating and administrative groups involved. The IT systems that support their processes form the framework for the eventual execution of the merger. The more IT can engage all the parties in serious, detailed planning, the higher the probability for eventual operational success. Obviously, a successful execution of Stage 3 lays a solid foundation for what needs to be done. Unfortunately, Stage 3 activities are often overlooked in many mergers because senior management views price negotiation as the sole remaining obstacle. IT organizations, along with its business partners, must keep applying pressure to execute as much planning at this point as possible.

The single point of leverage is to talk about money, the language of Stage 4. Executing the planning activities will lead to a more-refined understanding of true transition costs that, in turn, can refine the acquisition's financial model. Most acquisition activity relies heavily on assumptions, and the more integrated planning and thinking that takes place, the more likely it is that any falsehoods underlying these assumptions will be exposed. Such falsely supported assumptions are the place where most cost "surprise packages" will be hiding.

All the analysis, assessment and planning finally makes its way to the schedule. For M&A projects, this schedule is effectively unchangeable once stated. The enterprise has too much riding on getting it executed in the time frame announced/implied to the marketplace and those being bought. The unvarnished truth is slippage, which senior management typically views as failure. Therefore, it is essential to scope out the schedule as realistically as possible and to involve all the stakeholders. Regretfully, scheduling is typically done before the merger is



finalized, once again emphasizing the critical nature of planning in this stage to shore up the practicality of public pronouncements made by management.

8.0 Stage 5 — Executing the Merger/Acquisition A common recommendation is to move quickly in executing Stage 5. Reasons for proceeding as expeditiously as possible include:

• High-cost takeout creates uncertainty in the operations ranks, lowering efficiency and effectiveness.

• Speed helps avoid getting caught up in lengthy decision cycles that give the appearance of losing control.

• Communication, a major problem for any merger, is easier because it is always focused on doing things now and not at some vague time in the future.

• Speed instills a sense of momentum that, in turn, means there will be an end.

• Speed impedes competitive reaction by reducing the window of exposure.

• Realizing merger value is critical. An A.T. Kearney study underlined the speed issue, finding that nonmanufacturing deals reaped 85 percent of all merger synergies in the first year and only 15 percent in the second. After that, the deal yielded negative returns. Similarly, manufacturing results were 70 percent and 30 percent.

In some cases, a slower, more-gradual transition approach can be successful. This is particularly true when the merger of equals (that is, best-of-breed) model is used. Such an approach needs powerful vision at the top and strong backing along the way. It requires an acquisition price that doesn't need to be justified with a high-cost takeout. The lower the number of people facing termination, the more likely it will be that a stable transition can span an extended period and remain focused on creating a better operation and business model.

Whether the slow or fast approach is appropriate depends on senior management's objectives for the M&A event. Regardless of which approach is used, keep the following pointers in mind.

• Attack fear. It undermines everything.

• Watch for inconsistencies with what has already been stated. It is important that management's "story" remains consistent with integration actions.

• Develop an integration process that responds to the situation, adapting to the uniqueness of each M&A event. The companies most adept at this view integration as a collection of processes, out of which a unique process set will be applied to the transition based on the nature of the transaction.

• Speed is relative; it can kill. Some decisions should be made quickly, especially those that set the bounds for integration planning. However, the balance between moving quickly and taking the time to make the right decision is a delicate one, and the group must recognize that some decisions deserve more time.

• Build in reverse communication. That way, the organization can be monitored to see if it is approaching its capacity for change. As capacity is being closed, noise levels and complaints build; but when actually reached or exceeded, everything often suddenly becomes quiet.



• Use an acquisition dashboard. Monitor progress over four metric areas: customers, employees, economic benefits and project risks.

8.1 The Integration Process Stage 5 is complex and encompasses the most time and activity of the six stages. To better understand what is involved, this stage is best divided into four phases, each of which affects the others.

1. Integration planning: Conduct intensive planning for business and IT projects and to resolve personnel-related issues. The planning done in Stage 3 and Stage 4 sets the foundation for this phase.

2. Early projects: Focus on early transformation projects to achieve momentum (for example, infrastructure, finance and HR).

3. Operational business process projects: Tackle all the IT components of operational business transformation. Everything has been leading up to this.

4. Employee projects: Prepare employees for the new operational environment.

8.1.1 Integration Planning

Planning that wasn't accomplished in Stage 3 and Stage 4 has to be addressed here. If an integration manager hasn't been appointed by this point, selecting one will be the first order of business. The choice will depend on the merger model being used. If absorption is used, then no entity survives from the target. In this case, a manager is only needed for the duration of the project. If not treated correctly, candidates from the business can view this as a temporary halt to their careers — that is, their peers in operating business units could be seen as still moving forward. To entice the best candidates, the enterprise needs to position this role as a stepping stone to a promotion. For example, if a new combined entity is being created, this position could be positioned as an audition for the new business-unit manager job. An alternative is to draw on highly experienced retirees who like the idea of occasional three-to-nine-month projects.

Integration managers practice project management, but not necessarily the traditional variety. People don't report to them, and they have direct access to senior management. Their responsibilities are to organize and define the process, facilitate integration, work with people and keep everything on schedule. Unlike traditional projects, M&A integration activities often lack detailed plans at the outset. Many things get worked out in detail as they progress, and simple methods are required to manage the rapidly changing direction. The integration manager's job is primarily about managing people: getting them to understand what needs to be done, and being creative and supportive in helping them execute the tasks.

Project management can make or break a merger. Good project management is at the core of avoiding poor execution, while poor project management is one of the major reasons that mergers fail.

8.1.1.1 The Core Transition Team

A core transition team must be appointed. This team should include representatives from all affected business operation and administrative areas.

It is essential that each of the members of the core team is capable of making most decisions on behalf of his or her assigned responsibilities. Some of the bigger decisions (for example, involving money, affecting many people or altering the schedule) will get bumped up the management chain. If members are chosen too far up the management chain, they often won't have the



necessary time to devote to the core team's efforts. Members chosen too far down the chain may be too limited in their capacity to make decisions.

The core team is responsible for the M&A schedule and needs the backing of senior management to assign additional resources. Decision-making time is the single largest contributor to "schedule creep." Some organizations use a guideline that all decisions must be made within a 24-hour period. In any event, one of the key organizing tasks for the transition manager is to structure a decision-making process for his or her core team and for those assigned to support that team. Successful M&A execution is mostly about moving quickly and decisively.

8.1.1.2 Defining the Scope of Work to Be Done

The first step in this phase is to verify the work accomplished to date, and to identify what remains to be done. A key constraint to Stage 5, and thus the scope of planning, is the targeted completion date. An unfortunate byproduct of earlier stages and pricing is the need to establish a cutoff date that represents when merger integration is to be completed. The more complete the planning in earlier stages is, the more realistic the selected date will be. Regardless, a date has almost always been set by this point and will ultimately determine how much can be done. If no date has been chosen, it is likely that the deal follows the merger-of-equals model and finishing it will be couched in terms of "some number of years" to accomplish.

The level of effort required in this initial step of the planning phase is inversely proportional to the effectiveness of earlier due-diligence efforts:

• Effective due diligence: The major tasks are evident, along with most of the smaller ones. The planning effort starts with reviewing decisions made during due diligence and verifying that they are still accurate. The limited availability of information during due diligence may have led to some erroneous assumptions, so it is important to revisit these assumptions once complete access to the acquired company is available. The goal is to arrive at a set of requirements from all of the operating and administrative groups affected, which becomes input to project definition. This should take only a few weeks.

• Little or no due diligence: Gartner sees far too many of these situations, and considerable catch-up activity is required in these cases. Use the planning discussions from Stage 3 and Stage 4 to review the potential areas where effort or a project may be needed. It is best to do what everyone believes must be done. Don't attempt to prioritize at this time, as it complicates the picture. To prioritize effectively, view the total picture at the end of the gathering stage. There are often subtle points that become evident only when everything is gathered. In the ineffective due-diligence scenario, this early step can take several months to complete, depending on merger complexity. Enterprises in this situation often assume that they need to catch up on a five-day due-diligence effort. That approach doesn't take into account the work that should have taken place before and after the on-site due-diligence visit. To ensure success, the team must absorb and understand a considerable amount of information and translate it into action items.

8.1.1.3 Schedule Development

The merger model (absorption, stand-alone or merger of equals) will affect the ultimate schedule to a great extent. Schedule planning requires a balance between the end date, the resources available and the work to be done. One method of controlling the requirements is to first "stack rank" them in a most-needed to least-needed sequence. Invariably, some organizational units will put in their personal needs along with the acquisition needs, hoping to get previously unapproved project requests in under the guise of an M&A event. The necessary items automatically make



the list. The objective is to find a minimal set of requirements quickly and apply any refinements of value assessments used in the enterprise. Don't put everything through a rigorous value judgment; it isn't worth the effort.

With the requirements ranked, the next step is project definition, and assigning resources to projects. When the available time and resources have been consumed, the remaining requirements will be taken up with senior management to make a case for getting more resources or extending the completion date. The results of this process will be the finalization of the project mix and the generation of an overall schedule. All parties involved should agree that this project mix and resulting schedule are realistic, even if some extra work or time is involved.

8.1.1.4 Personnel

Parallel to the work-definition efforts, the company needs a quick, efficient process to resolve people issues. The HR group typically is responsible for this process. The focus is on which people to keep and which to let go, considering when that would be. If prior due-diligence efforts were effective, much of this will already be understood. If those efforts were done poorly, a quick assessment will be needed. The financial model has already presented the requirements based largely on the cost reduction needed to support the eventual price. The final selection of requirements and resulting projects will determine the outcome.

Time is crucial here, because almost everyone on the acquired side will feel insecure. The longer people are kept in the dark, the more likely it is they will find other jobs. Unfortunately, the people who are most needed to effect the merger are usually the first to leave.

Those people chosen to be retained must to be told quickly how they will fit into the new organization. They want answers to questions such as:

• What will be my position and responsibilities?

• Who will be my manager?

• What are my career opportunities?

Those not selected to be permanent employees comprise two groups: those that can go immediately and those needed to execute the transition. For the latter group, packages must be put together to encourage them to stay (the cost of which should already be factored into the financial model). These packages can contain any of the following:

• A bonus deliverable on project completion.

• A bonus delivered incrementally as the project advances.

• Higher pay for the duration of the project.

• Retention of PC equipment if working remotely.

• An offer to work elsewhere in the enterprise.

8.1.1.5 Communication

Prior to Stage 5, determining which communication approach to use is not necessarily an important consideration, because communications will often reflect whatever approach is typical for the enterprise. However, starting in Stage 5, communication becomes critical.

From a planning perspective, M&A execution can be viewed as a collection of projects working their way along a timeline; but this doesn't consider the impact these projects have on the lives of



others being affected. Something new is being created to replace something known, and the uncertainty will be palpable for everyone involved, including customers and suppliers, as well as employees.

It is important to communicate early, honestly and consistently. One misstep could mean a loss of credibility. The point of the communication is to inform. A common mistake is to gather everything together to present a total picture. This inevitably lengthens the time between people knowing something is up and finding out what that is. It is more effective to inform people often, even if this means admitting that some decisions haven't been made or repeating decisions that have been made.

Another common mistake is to churn out a high volume of communication with no apparent organization. It is more helpful to decide at the onset what general categories will be addressed, and then organize the communication campaign accordingly for each group. This will enable information issuers to check with each group to see how a particular communication would affect that group.

To be effective, communications must be tailored to the audience. The following is a sample list of audience types and topics:

• Employees

• M&A event (for example, closing and transformation status)

• HR issues

• Enterprise culture

• Employees of acquired organization

• Customers

• M&A event (for example, key dates and what will change)

• Effects on them

• Suppliers

• M&A event (for example, key dates and what will change)

• Effects on them

• Investors

• Media

8.1.1.6 Balancing Long-Range Strategy with Current Tactics

The urgency of executing a particular merger often obscures the strategy that drove the event. The planning process for a particular event should optimize strategic objectives, but the reality is that few companies actually prepare for this. The vehicle to accomplish this is a document that lays out the options for transforming the current business model into the future one based on a string of acquisitions. One doesn't know the specific events, but their cumulative effect leads to a predictable transition path.

All mergers unmask the same operational problems of scale and cost inefficiency. Resolving these is at the core of a long-range business and IT operation strategy. At its most basic:



• Adding businesses as stand-alone entities increases business process duplication and underlying support costs, eating away at the bottom line and reducing competitiveness.

• Absorbing companies will eventually lead to scaling problems that again introduce cost inefficiencies and reduce competitiveness.

A long-range strategy should provide interim tactical advice for how an event should be executed to satisfy near-term timing needs and long-range strategic operating objectives. For example:

• If the business model operating objective will be integrated globally using an ERP package, such as SAP, then the company needs a strategic implementation plan that transforms the current implementations to that environment. Acquisitions will eventually have to migrate to that platform, meaning that they should run stand-alone until they fit into an appropriate time slot in the strategic planning timeline. When executed, the actual transformation will follow templates used in prior conversions. An option at each event could be to go directly to the SAP platform.

• If the business operating objective is to outsource back-office operations while integrating the remaining critical internal processes, then the acquisition choice is having an internal development schedule and ensuring that the outsourcer can absorb new work. The development schedule will continually evolve internal application capability, making it a moving target for acquisition integration. The stand-alone model may make more sense to minimize the effort needed to tie in an acquisition operation — that is, build in stages where acquisitions can slip in and be converted with the rest of the enterprise. Later, when development is more advanced, the absorption model eliminates a step.

8.1.2 Early Projects

During the planning activity just discussed, a set of projects will emerge that can be executed sooner than others. These typically involve IT infrastructure and administrative activities.

IT Infrastructure

• Telephone networks

• Data networks

• Telephone equipment

• E-mail systems

• Document systems

• Videoconferencing

• Hardware/software infrastructure sizing

• Supplier contract renegotiation

• Help desk support

Business Administration

• Financial reporting

• HR



These are typically stand-alone-type projects involving little integration with operational business processes. They also typically represent the lowest-risk projects and, therefore, have a high likelihood of success, which can help boost the morale of those working on the more-complex integration projects. Implementing a string of projects quickly also helps get everyone engaged and presents the merger as an activity that is actually happening.

IT Organization Rationalization

The first two project sets above looked to the business of IT. This one looks internally to the organization of IT. The planning stage should have resolved what was to be done because stabilizing the combined organization as quickly as possible is critically important. Each of the M&A model types provide the appropriate guidelines for what projects are needed:

Absorption — Because the acquired organization will disappear, the principle organizational projects will involve the acclimation of those employees to their new environment.

• Resolution of employment offers and notices of termination.

• Adjustments to the organizational structure.

• Integration into assigned organizational teams and positions.

• Training in new technology/business operation environment — for example, tools, standards and policies.

Stand-Alone — Because the operations team is running on its own, it usually reports into its own business-unit management, leaving a fiduciary responsibility for the centralized IT organization.

• If this is the first occurrence for this type of relationship, then the acquirer organization needs to expand its operating principles and policies to reflect the needs of a matrix management environment.

• If the IT infrastructure operations function is being consolidated into the acquiring company, then the projects listed under absorption apply.

• Introduce the acquired IT organization to the acquiring IT organization. Establish processes for information transfer and decision making per policies of the acquiring company.

Merger of Equals — Early projects will center on establishing good communication links between the two organizations. This type of merger is too complicated for quick organizational changes. The objective is to settle everyone as soon as possible and get them all focused on the large task at hand.

• Establish a clear decision-making structure/process that will manage the transformation planning process fairly.

• Formally introduce the IT organizations to each other.

• Form business/IT teams with members from both businesses that evaluate business process components, and define what their expected future state should look like in the new company.

8.1.3 Business-Process-Originated Projects

The bulk of merger efforts lie in the integration of the processes that define the new business. Depending on the M&A model, the scope of such projects can be minimal (as in the stand-alone



model) to extremely large (as in the best-of-breed approach, which requires a complex set of interface/integration projects).

For almost any industry, approximately six key business processes will suffice to define the structure of the business operation at the highest level. This set of key processes can serve as a basic sorting mechanism for what effort will be required. Each of these key areas contains subprocesses that employees recognize as a definition of where they work. The actual projects will be defined here.

8.1.3.1 Business Projects: Absorption Model

Typically, all systems from one of the merging entities will be used and the others will be discarded. Project definition falls into two categories:

• Projects related to the migration of data from the discarded systems to the surviving ones. Data mapping should be the first project initiated because it will uncover anything missed during due diligence while there is time to do something about it. This project starts with a dictionary of necessary data elements from the acquirer's and target's systems. This is usually available in the database software or system documentation. The acquirer's dictionary must be converted to a tool (for example, a spreadsheet or database) that can capture the resolution of predefined conversion rules as each retiring data element is reviewed. This review requires assembling teams of people knowledgeable about the data elements in the merging systems. Each acquirer data element will be mapped to its corresponding data elements in the retiring systems. These mappings can be one-to-one, many-to-one or one-to-many. The rules for conversion become the programming requirements for the data conversion project. For acquirer data elements with no source, decisions need to be made to resolve these situations.

• A review of requirements the retiring systems need that the surviving ones don't, thereby dictating system modifications. These needs may be related to contractual commitments or they may reflect better ways of doing business that the capturing entity wants to incorporate into its operation. The resolution of these requirements (most of which, ideally, will have been identified during due diligence) is performed in conjunction with business process managers. Discipline may be needed to let business requesters know how much effort will be required to make modifications. Old project requests are likely to be inserted under the cover of the merger. The key point is that the time frame to complete projects has probably been set, and projects selected must be completed within that schedule. Striking the right balance in the selection process is an important factor in determining the ultimate success of any absorption-type merger, at least from an IT perspective.

To the extent that the effort required to perform the modifications is inadequately defined, the team may have to eliminate some requirements as implementation realities challenge the schedule deadline. The initial requirement list that ranked priorities from most critical to those that can be dropped can again be applied. Unfortunately, such dropped projects tend to erode the credibility and perceived success of the merger integration process.

Most organizations believe there is something unique to an M&A event at this point, even though they use the same methodologies as regular project definition and selection. The only difference is the potential range of projects going into the acquisition portfolio. Defining requirements, developing costs, estimating time frames, evaluating resources and assigning value should be components of your project management process.



8.1.3.2 Business Projects: Stand-Alone Model

The definition process tends to be simple because business operation processes are unlikely to be replaced in the acquired entity. However, administrative processes are frequently modified, most commonly in the financial arena. Other administrative functions, such as HR, are less likely to require projects at the IT level.

The acquired entity must report its financials; therefore, a mechanism must be devised to consolidate the numbers. This is typically a "rush project" because corporate management must continually report financial data. The effort usually involves developing interfaces between financial systems or through intermediate feeder systems. The acquired financial system is completely replaced. If necessary, it would likely require a follow-up project driven by factors other than a merger.

Processes not left as stand-alone should follow the absorption model.

8.1.3.3 Business Projects: Merger of Equals Model

Among the three M&A approaches, the merger of equals poses the largest project definition effort. Due to the sheer size of the effort, organizations typically jump directly to tactical considerations, overlooking the need to create an overall strategy that will guide those tactical decisions. This requires an in-depth look at how the new company will bring its products and services to market. By placing the initial transition focus on its future operating state, the organization defines strategic objectives that will direct the flow and sequence of projects necessary for achieving those objectives. When this step is not taken, organizations inevitably get bogged down in execution.

The most-practical approach to defining and communicating a strategic future operational state is to use scenarios. The focus is on operations and, therefore, engages key marketplace players — for example, customers, tax payers, vendors, distributors and service agents. For each of these key entities (typically four to six), select a high-profile transaction type and use a scenario to describe how the entity would interact with your organization for delivering a key product/service. Usually, two paragraphs will suffice. When constructed correctly, the scenarios encompass at least 80 percent of what is critical for describing the future operating environment of the new business.

Because best-of-breed business processes and applications are what will survive, the project definition effort will divide into three cascading categories.

The winning application: The first step involves deciding which applications "win." Functional business managers are key to this selection process. The distinction in decision making between having a strategy and not having one is clear. Pictures of future operations quickly focus on application/business process strengths and weaknesses, resulting in project definitions that most efficiently resolve the strengths and weaknesses. With no strategy, the decision process remains rooted in the present, resulting in the need to compare each application pair's functional capability and efficiency.

With a strategy, project decisions basically fill in the gap between the future and present ("now") states. This is more complicated than a typical strategy transformation because the now consists of two versions. The process would involve multiple versions between future and now states, interchanging each company's applications. Two to four consolidating stages within the gap bring transformation efforts to stabilizing points along the way. These points also focus application choices on achievable, lower-risk project sets.

Without a strategy, a process for making impartial decisions is necessary to ensure fairness and consistency. An enterprise that doesn't have an established methodology for managing IT



selection decisions should consider using the Analytical Hierarchy Process (AHP), introduced by Dr. Thomas Saaty in the 1970s. The AHP is a method for decision support based on breaking down the elements of a complex problem into a multileveled structure of objectives, criteria and alternatives. It forces users to structure their problems into hierarchies and to judge the relative importance and impact of the various factors. By making paired comparisons between the factors (thus developing ratios), the AHP enables users to develop ranked alternatives and a formal representation of intuitive and quantified results. The AHP can be highly complex and, in some selection decisions, its use may be "overkill." We recommend that organizations learn more about the theory in detail before adopting it.

A key mistake made when using the comparison methodology is to get too granular. Granularity exposes too many components for eventual knitting back together into a whole end-to-end process. The more components you use means that you have to build more interfaces. Interface development is typically a lengthy, complex and costly process. Gartner recommends that you limit the set of process components to be compared to approximately six end-to-end processes any business uses.

New functionality: The second category of projects results from a situation similar to that described under the absorption model, where requests are made for extra functionality to be built into the applications you've selected. Such modifications will define a set of projects and must be diligently controlled to manage scope creep. It is critical to define these additions prior to addressing integration projects associated with the integration category.

Integration: The third category involves tying together all the selected applications and their modifications so they can operate as an integrated set of business processes for the new entity. Such integration efforts have challenged IT organizations for the past decade, as enterprise-level decision makers have increasingly demanded a seamless business operation.

Although too complex a topic to cover in depth in this report, integration is enabled by middleware. The resulting projects are typically a blend of multi-vendor and "homegrown" applications. Even the occasional pure ERP solution will have to deal with this issue at some level. The challenge is to get the applications to "know of one another's existence." Middleware tools specifically designed to handle the kinds of tasks encountered in integration have been evolving since the mid-1990s. They are becoming more sophisticated and complex (for example, service-oriented architectures). To do the job properly, enterprises committing to a best-of-breed merger approach must commit to implementing integration middleware. The value of having a strategy is apparent because the future operating environment is defined by its scenarios. Senior management has committed to rebuilding the infrastructure of their business operation, and it follows that the IT infrastructure must also be rebuilt. The IT organization needs a strategy to "sell" the idea of an integration architecture to senior management. In the end, it's a "pay me now or pay me later" decision, but when the choice is "later," the price paid will be much higher.

The sequence of staging the implementation is complex, involving the organizations of the acquirer and acquired companies. Changes will be felt enterprisewide, and the degree of application/business process integration will determine how changes are executed. Most organizations would never contemplate turning off all systems one night and turning on new ones the next day. The consolidation staging sequence inevitably leads to additional work on temporary interfaces. Because of these complexities, this model has the longest integration cycle, typically two to three years. The merger-of-equals approach is the most daunting of the three M&A models and used the least.

8.1.4 IT Infrastructure Operations Projects

Acquisitions almost always have a cost-reduction component, and IT almost always contributes through IT infrastructure operation rationalization or consolidation.



8.1.4.1 IT Infrastructure Operation Projects: Absorption Model

In most cases, this involves shutting down the target's IT infrastructure and using, selling or discontinuing its component pieces. The exception is when its operating locations are better positioned geographically. When consolidating the IT infrastructures, a company should follow a typical set of preparatory projects.

• Decide how much scaling is necessary across the infrastructure components to make the integration happen.

• Review the list of purchased assets, captured in due diligence and later confirmed, to see what components can be used to satisfy the scaling requirements.

• Review the contractual constraints for those components. Evaluate components that have contractual issues to resolve which option is least expensive — sourcing new components or disposing of the asset.

• Source components for which there is no resolution.

• Dispose of components not being used.

The remaining projects all flow from preparing and executing the necessary infrastructure scaling. This should be familiar territory to IT infrastructure operations staff because they monitor and respond to capacity in the normal course of business. One set of projects that goes beyond infrastructure involves coordination with the business regarding acquired employee training to using the application and operating the help desk.

When operating centers are retained, projects continue to address the same areas, but with a different emphasis. The activity is the same as for the stand-alone model.

8.1.4.2 IT Infrastructure Operation Projects: Stand-Alone Model

The activity is redirected to address two additional perspectives:

• Cost reduction focused on leveraging cost efficiencies using the acquirer's contractual base. The most-common starting point is network consolidation to reduce redundancy and gain efficiency of larger scale communication networks — data and voice. The mitigating factor for taking action on any savings is the current contract obligation of retained components.

• Reconciliation of the acquiring organization's infrastructure standards with the retained operations. These standards are in place to promote cost efficiency and consistent IT use enterprisewide. Therefore, each of the areas is reviewed with projects developed to bring them into standard compliance.

8.1.4.3 IT Infrastructure Operation Projects: Merger-of-Equals Model

The typically long planning cycle for this type of merger precludes significant infrastructure changes in the months following closing the deal. Larger organizations tend to negotiate longer-term contracts that further slow consolidating changes. In the near term, projects will follow the stand-alone model, searching for nondisruptive or constraining efficiencies. As the future business model is clarified and new operating models are defined, projects will surface that will begin implementing business transformation.

The pressure will build to consolidate IT infrastructure operations to reap cost savings. The decision is not a simple one, but will hinge on a few key points:



• The degree of difference between established operating models and the new one. If the difference is little, then infrastructure consolidation should be straightforward. If the difference is great, then the critical factor is identifying the new enterprise architecture. The consolidation will have to provide the base for this new architecture, while supporting the current business process operation and its transition.

• Costs to undo contractual obligations.

8.1.5 Employee Change Projects

These projects involve preparing employees to function in their new environment. This is a separate consideration from the communication issues discussed above. Employee change projects primarily involve training.

Training will be divided between administrative functions (for example, e-mail or office support) and applications. If an ERP implementation is already established, training is typically in place to manage changes. In addition, the surviving office applications are likely to have established training materials and processes.

Training projects emerge from a review of the early and business process projects discussed above. There is nothing unique here. These projects have to be taken care of to get the new business organization operational as quickly as possible.

8.1.6 Building a 90-Day Plan

Ninety days is a popular time span used by organizations to bring a sense of urgency to the effort. Clearly, the plan will depend on the M&A model that the company uses.

Stand-Alone: Typically, the plan should encompass all necessary projects because most acquisitions using this merger type can be completed within 90 days.

Absorption: Simple, small absorptions can be accomplished within the period. Most others will take up to six months. Candidates for the plan are:

• The near-term projects.

• Projects that fall into the 90-day time frame and are preparatory to an eventual cut over.

• A rigorous 90-day review to validate schedule progress.

Merger of Equals: Ninety days is typically not enough time to finish the planning process. Candidates for the plan are:

• Resolution of employee status

• Organizational changes

• Decision-making process, tools and structure

• A preliminary high-level planning output

• A rigorous 90-day review to look in depth at schedule expectations and practicality

8.2 Sample Template for Stage 5 Table 1 is a sample summary template for the M&A integration process. Its purpose is to provide an example of the form that the sequence of integration activities can take.



Table 1. Sample Template for M&A Integration

Process Step Deliverables Time Frame Participants Comments

Identify integration managers

Signing of letter of intent

Integration manager

Preliminary integration assessment — key issues

Document During due diligence

Integration manager and acquisition team

This is a "30,000 foot" view of potential integration issues and an outline of the integration plan.

Identify integration team

Prior to close Integration manager in conjunction with M&A management

The integration team includes members of the acquiring and acquired companies

Develop communication strategy

Document Prior to close Integration manager in conjunction with line-of-business and functional management

This strategy includes internal and external communications

First meeting of integration team

Close Integration team Introduce integration manager, agree on team objectives, schedule integration plan review meeting and work out team logistics.

Develop integration plan

Document Two weeks after close

Integration team Include objectives for the first 90 days

Integration plan review and approval

Presentation After completion of integration plan

M&A management team and other functional management areas

Revise plan based on feedback from meeting.

Execute 90-day plan

Integration team reviews

Status reports Weekly Integration team Identify key obstacles to the completion of integration.

Monthly status reviews

Status reports Monthly Management Identify key obstacles to the completion of integration.



90-day review Presentation 90 days after close M&A management team and other functional management areas

This is an assessment of the integration to date, and of key issues and obstacles to completion.

Integration team reviews

Monthly after 90-day review

Integration team

Six-month review Presentation Six months after close

M&A management team and other functional management areas

This is the conclusion of the integration team's efforts, providing feedback into the process.


8.3 What IT Can Do The focus of Stage 5 is on the execution of projects. The most-important success factor is to have an effective project management process. Most organizations that excel at project management have adopted a project office competency by building a strong, concentrated specialization in project management.

The idea of developing an enterprise discipline for project management has been around for years. Gartner has observed the renewed use of a dedicated organizational structure to project management is a "professional" role for application development, infrastructure change and large-scale system migrations. Management's goal is a base-level improvement in project completion within schedule deadlines and budget estimates, while delivering the expected functionality with satisfactory quality. World-class organizations complete nearly 90 percent of their projects within 10 percent of budget and time estimates.

A project office is responsible for:

• Standard methodology: The key to implementation is a consistent set of tools and processes for measuring performance and that can act as a communication and training vehicle for developing project skills.

• Resource evaluation: The initial assessment of resources (people, money and time) is critical on several fronts. Based on experience and evidence from previous projects, the project office acts to validate business assumptions about the project and life cycle costs. It also serves senior management by giving them information that may alter project priorities, based on resource availability or cross-functional project conflicts.

• Project planning: The project plan is a cooperative effort coordinated by the project office that serves as a competency center and as a library for previous project plans and results.

• Project management: Consistent practices, frequent review and a governing responsibility are the baseline roles for management within the project office that need to be in place. In most initial implementations, project managers are not staffed directly from the project office. In some organizations, the project office is also the source for project managers who are deployed as consultants for the life of the project.



• Project review and analysis: Enterprises need to know if project goals are achieved as designed, on time and within budget. The review and analysis phase is a loop back to the resource evaluation role.

Thus, a project office is designed to integrate project management within an enterprise. We recommend that it be used to ensure successful, on-time completion of merger integration efforts.

9.0 Stage 6 — Operational Review This last stage of M&A focuses on critically examining what was accomplished. Experience shows that future integration efforts are more likely to succeed if early reviews are conducted with the acquired team to ascertain the success of its integration. The goal of Stage 6 is to create, or improve, a repeatable M&A process. If the enterprise already has a core M&A integration team, this phase is simply part of its closing-out activity. For the IT organization, a program management office is a logical place to position the M&A team because it is a specialized project. An M&A integration team is needed to capture the best practices learned for the benefit of other teams formed to manage new merger activities. Even if the company doesn't have a team, the IT organization should build that competency internally to best manage what is often a highly disruptive event.

The operational review should take no more than two weeks and should address two areas:

• An early assessment of the merger's value — that is, whether expectations are likely to be met in the time frames originally planned.

• Lessons learned about the process itself; what can be done better next time.

One approach to minimizing bias is to assign responsibility for conducting the review to an executive who was not involved in the acquisition.

9.1 Determining Whether Acquisition Value Expectations Will Be Met At this point, the original assumptions for why the merger was a good idea are revisited. It is still too early to make a final judgment, but using this review to look closely at what was achieved can lead to adjustments to ensure the merger's ultimate success. This area is the responsibility of the business, but the IT organization's participation will open more opportunity for better understanding the business values involved, as well as how the applications can better serve those businesses.

Unfortunately, this activity coincides with the period when many of the participants will want to "get this all behind us" — and may be tempted to declare victory, regardless of the facts. If the M&A event was a one-time activity for the enterprise, overlooking problems may not be critical. Most companies, however, go through periods where they are on the prowl for additional acquisitions. In this case, they should learn as much as possible from the merger and apply the lessons to future M&A activities.

To re-examine the original M&A value expectations, write questions based on the assumptions that underpinned the original thinking about the acquisition. To provide a broad perspective, the following is a general list of questions organized by the M&A drivers. For each negative response, follow-up with questions such as "Why not?" "What should be done about it?" and "How do we avoid this the next time around?"

Economies of Scale (Market Share)

• Was the market share expected realized?



• What is the cash flow, and does it meet expectations?

• Have we achieved the cost reductions expected due to increased purchasing power?

• Were the expected reductions in SG&A expenses achieved?

• Were the expected components for SG&A achieved?

Customer Demand (Market Awareness)

• How have customers reacted to the change?

• Have customers been retained as expected?

• Are the purchased products or services what they were assumed to be?

• Have new customers appeared as expected?

• Do cross-selling opportunities still seem possible?

Changing Business Models

• What has been the effect on suppliers?

• Has a cogent, easy-to-understand definition of the new organization's strategy emerged?

• What is the planning and budget model for the next annual cycle?

• Were distribution improvements realized?

• Did the products or services bought deliver their expected synergy?

Globalization

• What do the markets look like from the inside?

• How much synergy can be extracted in the near term and for the long term?

• Can business processes be brought under one global set? If so, what are the difficulties and what time frames are needed to make globalization work?

• How realistic is it to have global products? Do markets want them? How difficult is it for product design teams to operate globally?

• What do the country-by-country legal and financial environments look like now? Are they more complex than expected, and not as well-understood as assumed?

Diversification

• Does the product or service bought live up to expectations?

• Will the product or service deliver the anticipated revenue stream?

• Do the cost structures for the product or service match what was originally understood?

• Do the skills that were acquired exist to the extent expected?

• What does the market purchased look like now that it can be seen from the inside?



Organizational Culture

• What has been the result of combining organization cultures?

• Who are the "winners" or "losers"? What has been the impact?

• How has senior management from both companies settled into the new operation? Is there an unspoken lack of support by those from the acquired enterprise?

• How realistic was senior management's original vision for this acquisition and its potential for succeeding?

• To what degree is senior management supporting the transition to ensure success of the acquisition?

Scavenging for Value

• Were head count reduction synergies achieved as expected?

• How do the actual integration expenses compare with those used in the financial model that drove the merger price? What factors led to material differences above or below these estimates?

• If there is an overage in acquisition expenses, how much must be recovered from current operations, and how will that be done? How will this affect goodwill accounting and impairment evaluations?

• Did undoing contract and lease obligations cost more or less than expected?

• Did unforeseen legal problems arise?

If the acquisition is judged to be unsuccessful after the scrutiny of a value review, the review team should analyze the reasons for failure presented at the beginning of this research. The objective is to get to the root causes for why the acquisition didn't measure up to expectations and do something about it. It takes great discipline to admit to management failure and, hopefully, punishment will not be the reward. The result should be recognition that, in the rush to close an acquisition, there will always be some unknown facts. This knowledge may help the company be more thorough for its next acquisition.

9.2 Determining How to Improve the Process This activity amounts to writing a chronicle of what didn't work well. During each stage of the acquisition, the results of activities often cause participants to say, "I wish we had done that differently." The process review starts with gathering information on these situations, and staying focused on important issues.

In creating the list, the group must keep a watchful eye on what it will take to implement the changes. The idea is to not try to fix everything, but rather to filter out the marginal problems. Most organizations have limited resources, but those people will stay committed to the review if they feel they are tackling meaningful problems.

Once it has generated the list, the group should discuss and categorize each problem by answering four key questions:

• Was it based on a faulty assumption?

• Was it the result of poor execution?



• Was it a people problem?

• Can it be corrected now, and is it worth it?

9.2.1 Was It Based on a Faulty Assumption?

By the time the deal is signed in Stage 4, all assumptions underlying the decisions that drive planning are firm. Due diligence and the early activities of Stage 5 are the sources for gathering necessary information and the time to challenge assumptions that inevitably fed the decision process.

Most flawed assumptions are not obvious. How many will be unmasked will depend on how skeptical the due-diligence team was. An obvious one pertains to the quality of data that can have a tremendous impact on conversion timing and effort. From an IT perspective, other assumptions surface in the business processes — for example, when practices were believed to exist as the acquisition target described them, rather than being observed firsthand and examined in depth. The business side is often surprised by the quality of assets failing to live up to initial representations, which may create additional work for the IT organization to reconcile the differences.

The resolution to this type of problem is to strengthen the due-diligence process. The key to adding strength is to put knowledgeable process people from the business units on the M&A team. They should follow transactions through the system, asking the IT staff as many probing questions as they can think of. Select people for the team who are naturally curious and have experience in the process being reviewed.

Another valuable concept in executing due diligence is to continually ask, "What is being assumed here?" Most reviewers automatically view what they are examining in reference to their own process operation knowledge and, naturally, fall into the trap of assuming something works as they are used to seeing it work. The best questions are raised when nothing is assumed and the process is tracked as if it were the first time anyone thought of doing it.

9.2.2 Was It the Result of Poor Execution?

Companies may think a merger failed due to poor execution. Many problems may have caused the failure, but the problems can be traced to work product or project management.

Work product concerns the quality of decision making for each project. Problems can arise in several areas.

• Gathering the correct information to set up project design. This is especially difficult when operating under the pressure of short time frames, typical of most mergers. If everyone does his or her best, problems will be the exception rather than the rule. However, end-user specialists are often insufficiently engaged in the definition process. IT staff members frequently make decisions about end users' issues in a vacuum, which naturally causes end users to criticize the results. To avoid these problems, put the most committed and knowledgeable process people on the project. They must be accountable from the initial design to signing off on training. This can put strain on the end-user community, but there isn't any other way to reduce the risk from this problem area.

• Understanding how the process works. Informal processes can cause problems. They often reflect process exceptions that system designers never contemplated. End users find workarounds to get the job done. The more workarounds there are, the more difficult it is to make changes to any single process. This is also a symptom of the assumption problem — that is, no one looked carefully enough at the process to identify



potential exceptions. Surprises that result from these unidentified exceptions can frustrate end users and cause them to claim the acquisition is unsuccessful.

• Estimating the work effort. This is a perennial problem for many IT organizations and can be the source for a consistent end-user refrain: "They never get anything done on time." The previous mentioned types of failures will naturally lead to late completion dates. Given that the work is understood in its entirety, nothing develops better estimates than a focused effort to learn from each estimate. Successful organizations recognize that not everyone working on a project has the same level of competence. Build realistic estimates, balancing the range of people's skills against the difficulty of the work. In addition, build in some slack to account for unforeseen events. The more interfaces a project has, the more complex the timing for completion will be. This area also touches project management.

• Training end users. Providing adequate end-user training is complicated in M&A efforts because there are two groups of trainees with different needs. People from the acquired organization typically need complete training, while those from the acquiring organization may just need an update to understand the changes that were introduced. Training is often overlooked or underfunded, which becomes quite evident during mergers. Determining whether there is a problem in this area is easy, simply ask any end user (include new hires) if he or she has had adequate training. There are many options for developing and delivering training; remember that training must cover business processes and office support.

Project management encompasses issues related to the management of the entire integration process. Problems arise from:

• Wrong choice for overall project manager. This often happens when the person selected is not viewed as an authority. The biggest responsibility facing any merger project manager is to make a long series of important decisions, often under time pressure. The person must have the authority to speak for the enterprise in most situations — for example, adjudicating conflicts among different organizations. Often, this manager must decide in favor of the enterprise's interests over those of an individual business unit or administrative department. This takes power. The entire process can quickly get bogged down in governance issues and tie up too much senior-management time, which is often the major cause for missed schedule deadlines. Some companies assign the new business leader, if there is one, to driving the change. A best practice is to put those who will have to live with the result in charge of executing the integration. This practice helps balance the opposing forces of "getting it done quickly" and "getting it done right."

• Inexperienced individual project managers. A natural evolutionary career path is to have IT people become project managers. Nothing is wrong with this as long as they are trained in what project management means. Lack of formalized project management will condemn the IT organization to inconsistent work products and to enterprise dissatisfaction with the service it provides.

9.2.3 Was It a People Problem?

Project Execution Personnel: Within this group, people problems often arise from two sources.

• A skills mismatch in IT. This will be affected by how rigorously the IT organization manages its people and their competencies. If skills mismatch is a recurring problem, get help from management. At the core of resolving this problem is being realistic about what the individual knows and how much he or she can grow. Unless there is a



disciplined commitment to managing people's performance, there is little hope that the IT organization can hire and retain the "right" people.

• A skills mismatch with an outsourcer. It is common for IT organizations to supplement their skills with resources external to the organization, especially during activity peaks. Organizations that use outsourced staff tend to treat them differently than they treat full-time employees. Every individual brought in must be vetted to ensure he or she has the required skills. All too often, suppliers will feature the best people but assign less-skilled people. In addition, disciplined service-level management will be needed to ensure that the arrangement works as expected.

End Users: People problems in this group are based on two perspectives.

• As acquirees. They are likely to be defensive, fearing that their worth could disappear with the demise of their old company. A large part of the people-related effort required in any merger focuses on getting these employees to feel like part of a new team. The success of this effort will figure heavily in the attitude of these employees. Uneven effort across organizational units not only makes the transition difficult, but festers over time, making operations inefficient and expensive. Beyond effective communication from senior management, good training will figure heavily in resolving this issue because it provides tangible proof of the concern the acquirer has for the employees' well being. It is natural for many people in this group to feel that their way of doing business was better than the "new way." The best way to resolve this is to sell them on the new way through effective, compassionate communication and training.

• As employees. It is common for problems in this area to result from an imbalance between established and new employees. Established employees may have taken over and forced the new people to lower levels, reinforcing fears of many new employees. This is often indicative of a poor performance management system. Correcting the situation will require a complex and comprehensive effort to overhaul HR practices in general. A less-likely scenario is that the acquired personnel took over and pushed the established people into the background. In this case, the same approach to resolving the problem applies.

9.2.4 Can It Be Corrected Now, and Is It Worth It?

Usually, problems are corrected along the way, but sometimes there just isn't time to meet schedules. Although the main goal of this problem review is to highlight what didn't work, it's also an opportunity to correct something that may have been missed.

Asking whether each problem discussed can and should be corrected now, and then acting sends a powerful signal that the enterprise is willing to admit it made mistakes and to resolve those mistakes. This touches on an important cultural issue of business in general. People are likely to understand and accept that not everything will work well all the time, but they're less likely to tolerate failure.

9.3 What IT Can Do The IT organization will be fully engaged by Stage 5 and, as such, will be focused on the process of integrating the organizational components. Typically, there is little the IT organization can do about the accuracy of the value proposition of the merger because it is based on assumptions built into the first four stages.

Regardless of whether a value review is performed, the IT organization should always ensure that a process assessment is completed. The better the M&A process is to begin with, the more



effectively the IT organization can apply resources to support acquisitions. The process engages the enterprise, and its effectiveness is a reflection on all participants.

10.0 Divestitures Many acquisitions involve divesting some part of a business entity prior to the M&A event by the seller, or afterward by the seller or buyer, depending on how the deal is structured. The same activities are required, regardless of who actually executes the divestiture. In a 2003 Accenture study, 73 percent of the Fortune 1000 executives surveyed found acquiring easier than divesting, while 11 percent thought the opposite.

A simple way to view the effort is to see it as the merger process in reverse. It is more complicated than that, because the process typically involves divesting part of an organization (usually within the acquired enterprise), which introduces some new twists. This is true whether the seller offers only part of the business, keeping the remainder intact for its own operation, or the buyer does so after the sale is complete.

If the divestiture is of a stand-alone entity from a system's perspective, then little or no IT activity will be required. This is rare, however, because most organizations have some degree of shared systems. In most cases, considerable IT work will be required, primarily related to creating, splitting off or retaining systems for the use of the divested and divesting organizations.

Divestiture usually entails carving out or retaining manufacturing facilities, products, services or assets. Processes related to these entities are embedded in a set of systems that manage their operation. The actual sale of assets is usually not an IT responsibility in an acquisition and will not be examined here. There are a number of options for how to perform a divestiture.

• If the seller divests portions of an entity prior to selling it; it will discard these portions, keep them for its own operations or offer them separately for sale. If the divested portion must be operational for the seller's use or separate sale, then the seller essentially becomes its own buyer — that is, it must adopt one of the buyer's options.

• Other options from the seller's perspective:

• If the buyer's M&A model is absorption, the buyer/seller relationship will work its way through the six M&A stages, and all system-related changes will be handled on the acquirer's side.

• If the buyer's model is stand-alone, it is typically the seller's responsibility to ensure that systems are in place to manage the divested entity prior to transfer.

• Since the seller is divesting, the buyer can't use the merger-of-equals model.

• If the buyer knows it will have to divest portions of the entity being bought (that is, it becomes a seller), the options are similar to those described above, but with some added considerations:

• The portion to be divested could adopt the stand-alone model — that is, preparing it for divestiture.

• If the seller won't agree to support different merger models, then the buyer may decide to create a stand-alone portion on its own during the acquisition process.

• If the buyer already has a buyer lined up for the divestiture, then it could negotiate as a middle person between the seller and new buyer to select the acquisition model and execute the final divestiture.



• If the decision to divest comes after the acquisition, then the buyer becomes a seller with the options noted above.

From all of this complexity, we extract three basic approaches related to preparing systems for divestiture:

• Develop new systems to manage specific elements for the divested entity, while retaining and modifying the established system to manage the remaining elements for the seller.

• Duplicate or spin off systems.

• Provide systems as a service to the acquiring enterprise

10.1 Creating New Systems and Modifying Established Ones This option requires not only developing a new system to manage specific elements for the divested entity, but also retaining and modifying the established system for the seller's ongoing use.

10.1.1 Developing the New System

At the core of the new system will be operational components that execute day-to-day operations, such as order entry, manufacturing, distribution, billing and collection. Administrative components, such as accounting and HR, are usually not included because the buying entity will typically want to keep these consistent across its enterprise. The activities to support these administrative functions may require interface feeds from the operational-based systems being assembled.

The following is a representative list of key task areas necessary to carve out a new system:

• A decision must be made about whether the system's capabilities will be satisfactory or will need enhancements. This leads to a defined set of functionality that must be in the system on its hand off. These issues should be resolved between buyer and seller IT and functional experts prior to closing the deal to allow for adequate estimation of effort and cost. Barring that, the deal should contain a clause defining the scope of the effort and a mechanism to resolve scope creep (that is, to keep the costs within the original pricing parameters of the deal).

• If the new system starts with a copy of the old one or uses any components, all the services and contracts associated with the IT infrastructure serving that system/components must be reviewed. The scope of this review ranges from software contracts to service contracts with outsourcers that operate parts of the system. Decisions must be made for all infrastructure components with regard to how they will be supplied or handled in the new environment. The associated costs should be identified before the deal is closed and can be quite high, especially for software licenses.

• If the new system is built from scratch (for example, using a smaller version ERP vendor), then tasks revolve around a new implementation. Because most divestitures are small, this type of effort evolves from a strategic requirement to create a lower-cost operating model — that is, established systems serve large business units and entail higher cost and more functionality than can be afforded.

• Most applications have master information associated with their operation and maintenance, and the larger environment in which they operate often constrains the data and numbering schemes. For example, product numbers may be restricted to



certain ranges based on their business unit, or customer numbers may be built based on some accounting-code structure. The new systems will likely need these restrictions removed to provide the buying organization the liberty to manage the operating environment from its own perspective or to meet its design needs.

• All database elements must be reviewed to determine their relevancy. For those that are not, will they be stripped for the new version or simply left blank? This sets up programming requirements for creating the new system. For example, if fields are deleted, program references to them must be purged. If fields are rendered null, the program impact must be considered as well.

• Historical data is often forgotten or difficult to address. The key questions to resolve concern how much history there is and whether it is consistent. Data elements used in forecasting or comparisons are candidates for consideration. This becomes critical if the acquiring organization uses such data to predict activity and therefore needs it available through interfaces, a requirement that the old system may not have been designed to address.

• If the buying organization has standardized user interfaces, what will this mean for the new programs? This can be a sensitive question if Web-based technologies are used for customer interfaces. Replacing an entire front end is time-consuming.

• Each administrative-support application has defined interfaces, and the new systems must conform to deliver data through them — accounting information, for example, for cost-accounting purposes, or reporting operating results to the general ledger.

• Interfaces necessary to other buyer applications

• Documentation for the buying group so it can set up its system maintenance capability.

• End-user training documentation, as well as support for the training. This brings together people from the buyer and seller sides to integrate this activity into the buyer's training capability.

• Maintenance of purchased system, time and extent

10.1.2 Modifying the Remaining System

After extracting the functions and data that will go into the new system, the IT organization may have to change the remaining system to make it functional in its new environment.

• Typically, some operating components will no longer be covered by the ongoing business. Most end-user interfaces are replete with references in pull-down lists. To prevent confusion, all such references should be removed.

• Some aspects of the system may have to be removed completely. For example, if the sold-off portion accounted for all the global business that posed international complexities to the system for currency exchange, should these complexities be removed from the system to make it easier to update and enhance?

• All reports must be reviewed to ensure that the content, control breaks and columns still make sense. For example, data associated with the sold business components may need to be purged from databases simply to get the reporting accurate. In addition, if fields pertaining to these sold-off portions contain nulls, how will that look in reports?



• Infrastructure components must be examined to ensure they are still scaled and priced appropriately. For example:

• Is the computing engine the right size?

• Can a mainframe or part of a server farm be eliminated?

• Is there enough network traffic to support the established network configuration?

• Does the remaining business transaction volume imply outsourcing may be a better option?

• Will outstanding system change requests need to be done?

• Will alternatives better satisfy the remaining operational needs? For example, should the remaining system be replaced by another package or merged into other operational systems in the enterprise?

10.2 Duplicating or Spinning Off a System Occasionally, a buyer will want a copy of the system that already operates the business component being bought. If the selling enterprise no longer requires it, the system can be spun off in its entirety to the buying enterprise.

Issues that need to be resolved include::

• The software licenses needed to operate the system must be reviewed with regard to their transferability. Most, if not all, will be transferable on some level. The key questions are: How much will it cost, and will these costs be accounted for in the acquisition pricing model?

• The buyer's IT infrastructure must be reviewed to ensure it can operate the system. If not, how much will the required modifications cost? Questions to ask in this review include:

• Are operating systems and versions compatible?

• Are the systems' software components available and compatible?

• Is the networking protocol supportable?

• Is the database software and version already being licensed?

• In conjunction with the infrastructure review, determine whether there are outside service components needed to maintain, operate or support the system, and resolve replacement or continuation issues. These are mostly cost-variable issues, which should be accommodated in the pricing model.

• If an outside firm maintains the system programs, contracting with this vendor for continued support is appropriate. Problems may arise if the vendor's staff is located in close proximity to the seller, but not to the buyer.

• If an outsourcing firm is operating the system, decide whether to retain these outsourced services, source them from another vendor or move them in-house.

• If the help desk was outsourced, the buyer must consider whether to retain these services, source them from another vendor or bring them in-house.



• The buyer will have new control data elements to fit into its environment, and all tables will need to be updated. Alternatively, if control fields are to be changed, all historical data being transferred will need to be corrected accordingly.

• References to the selling company on screens and reports will need to be removed.

• System documentation will need to be assembled.

• Decisions regarding ongoing system support will need to be made.

• If the seller agrees to maintain the system, negotiate the extent and duration of this maintenance service. If the buyer agrees to maintain it, train the company's IT staff.

• Develop a process to train end users. The type of system maintenance chosen will affect the amount and extent of this training.

10.3 Providing a System as a Service A key challenge in any merger is that day-to-day business must continue. Often, an arrangement emerges wherein the selling company agrees to provide operational systems for a period of time while the buyer assemblers new systems. This is a particularly valuable option when the changes to be made on the buyer's side are extensive, complex and not clearly understood. It provides an insurance policy for the buyer that the acquired entity's operations will be free from system-related disruptions while the buyer prepares to assume responsibility for its technical operation, and that it won't be forced by time pressures to develop rushed, inadequate solutions.

This system-as-a-service option can pose some limitations. First, the systems may continue to linger longer than expected, restricting the seller's ability to move on. Because the divesting enterprise elected not to keep this entity, it probably won't want the long-term responsibility for operating it. If the divestiture is the result of an acquisition made by the divesting enterprise, this system-as-a-service option usually won't become available until the divester has absorbed the original purchase. The timing will depend on the M&A model being executed.

The difficulty with this option is that two independent companies will be using the same system. Unless internal blocks are created, they may be privy to each other's data. Often, this is anticipated but not viewed as a problem. This assumption can quickly be unmasked as the day-to-day reality of running into another business becomes too troublesome for the functional units involved. At the very least, reporting must be changed, and the accounting interfaces for both companies modified accordingly.

With the passage of the Sarbanes-Oxley Act in the U.S., the issue of fiduciary responsibility between the buyer and seller is more complex. Because the divester is providing the underlying processes that feed the buyer's financial organization, the issue of compliance responsibility needs special attention. Outsourcers face the issue as a standard business practice, but it may be a rare or one time event for a divester.

11.0 Software to Manage M&A Activity Each M&A event is unique, which drives the ad hoc nature of activity where the process must identify activities, capture issues with them, assign responsibilities for activity and issue resolution, notify others of potential impact, add issues, collect documentation and track the path to activity/issue resolution. The dynamic nature of this type of environment distinguishes it from project management, where the objective and tasks are largely fixed. This is seen in our six stage process where, in Stage 5, there is a subtle transition to traditional project management with the



need to define specific project requirements, level resources for all the projects, develop timelines and critical paths, and monitor a project's progress.

11.1 Software Tool Criteria When evaluating software to manage the M&A process, look at three complementary components: a framework to organize the flow of M&A activity, best practices for executing the event and a management process for controlling execution.

M&A Process Framework

• A set of stages that define the overall flow of any M&A event. Each stage has its unique requirements for activity to be performed.

M&A Best Practices

• Within each stage, a structure that organizes work to be done into logical groupings. There are often hundreds of potential or actual tasks to be executed in a stage, and this simply serves to organize them into a more manageable, comprehensible form.

• Within each logical grouping, a set of potential work to perform.

• For each of the work activities, advice for how to do them.

• The capability to select specific work from the list of potential choices to build a specific event set.

• The capability to maintain best practices for current or future events.

M&A Process Management

• Identify tasks for a particular M&A event.

• Assign responsibilities for task execution.

• Capture task issues.

• Notify other affected tasks of issues.

• Capture path of issue resolution.

• Capture documentation.

• Manage exceptions.

• Provide traditional project management capability for the implementation stage (in our case, Stage 5).

M&A practitioners typically are very good at doing their jobs (estimated at 10 percent) or aren't sure how to go about M&A (the vast majority). When it comes to software, the very good practioners are uninterested in being told how to execute their mergers (checklists and best practices), while the less-inclined are very interested in best practices (what to do and how to do them). These two user bases place a different emphasis on the above criteria for determining whether a software package will work for them.

The very good people already have figured out the first two categories, while the not so good need that advice. Both groups converge at the management component. However, the not-so-good group is further split between those willing to go forward on their own using a software tool



and those who don't, opting for outside help. M&A practitioners who supply outside help will have their own management tools, which are typically proprietary. Therefore, we will focus on the groups seeking software to help them manage their own M&A event.

11.2 M&A Software Candidates A search of the Internet in August 2005 made it clear that this is a small market. We kept our search to products that served management of the M&A process, excluding:

• Products that serve application-specific components of the process, for example, asset valuation and selection.

• Firms offering services to assist a company with an M&A event.

• Project management software designed to handle projects. Although feasible, it is a less-than-optimal solution due to the volatile nature of M&A events. Project management software expects a defined environment to manage, not one that is constantly being altered.

Only two software products met these criteria: Valchemy and FastFuse. Both are relatively new to the market. With almost $1.5 trillion deal value worldwide in 2004, it seems remarkable this market is so tiny. How well are those deals are being managed?

11.2.1 Valchemy (valchemy.com)


The product is designed to manage a merger across selection, due diligence, pre-close planning, integration execution, post-deal monitoring and reporting. These directly map to the six stages presented in this report.

M&A Best Practices

The product is rich in best practices, offering more than 2,500 milestones and tasks that act as guideposts and road maps for executing an M&A event. The due-diligence stage has more than 1,000 milestones, and integration and planning has more than 1,000 milestones, with the remainder split among the other stages. The product supports users adding to this best-practice database as they gain experience in their own M&A activities. Valchemy facilitates a quarterly meeting with clients to share experiences and upgrades the best practice database. Templates are used to organize the work into groupings. The product comes with approximately 50 preconfigured templates built from the best-practice database and are designed to get clients started. These templates can be easily modified to manage situations unique to a client. The best practices are basically focused on what to do; there is little in the way of explaining how to do it.


The work templates are the foundation for managing the M&A process. They capture essential data on the deal phase, department responsible, the team or individuals assigned to tasks, expected completion times, financial measurements and dependence on other tasks. An e-mail notification can be sent to individuals as the person is assigned to a task or to resolve an issue that includes a URL to the project template. As tasks are executed, team members update these work templates. They provide progress reports and relevant documentation to capture a history and a sense for current status.

These work templates are input to report templates that are used to manage the M&A process. More than 50 preconfigured report templates are provided to get clients started. Clients can modify the report templates to create new ones, reflecting their unique needs. The report



templates use dynamic, self-selectable filters to create hundreds of versions. With so much information available, reports focused on exception management become the key management tool. Because related tasks are linked, everyone affected sees the exceptions. These reports also form the basis for meetings to resolve issues.

Another tool is used to manage collaboration, not projects. There is considerable information available that a project management tool can use. To accomplish this, the product supports identifying database fields for extraction to an Excel spreadsheet that, in turn, interfaces to a Microsoft project.

Operation

The product is Web-hosted, requiring only a Web browser. Security is granular, allowing for adaptation to fit a client's needs based on corporate policy, roles and user profile.

Conclusions

Valchemy understands the dynamic nature of collaboration required throughout the M&A event. The product provides a solid foundation for clients. The ability to create new work and report templates in support of each client's unique needs is essential as clients become more sophisticated with acquisitions. Judicious capture of information during each event builds a database for clients to reach back and draw on for each new M&A event. Nurturing a client community to share best practices and experience enables clients to see the larger world and learn from it. As a collaboration tool, it is equally applicable for other ad hoc events, such as divestitures and joint ventures. This tool is applicable to all enterprises, regardless of their level of expertise.

11.2.2 FastFuse (fastfuse.com)


The product as delivered picks up merger management after the deal is closed, typically somewhere during Stage 4 and Stage 5. This reflects the current target market of consultancies serving clients during an acquisition event. If the due diligence and execution stages are involved, then a new database for execution is built from due-diligence data already gathered. The product is designed for three layers of control: a steering committee (merger board), program/project management and focused teams.

M&A Best Practices

The product uses a document library to store templates, checklists, process steps and so on. An initial set of approximately 40 integration items and their detail comes with the package, which FastFuse updates periodically. Although designed for the implementation stage, the product is extensible to the other stages in the M&A process by creating new initiatives, which are then managed the same as the prepackaged set. Typically, consulting firms have the expertise and load the library with their methodology, using the product to manage the process. Prepackaged integration items include teams, individuals, initiatives, milestones, key accounts, risks, forecasts, redundancy matrix, synergy matrix and surveys.


For each of these integration items, templates exist for users to enter information using portals designed for each member. These templates are input to 112 available reports that have eight levels of view, depending on the user ID and password. Warning thresholds facilitate exception management. In addition to reporting, there are three tools to support a "war room," online chat and a documentation library. Because this product was designed for consultants, it also manages



M&A events across multiple clients. The interface to traditional project management software is through a batch file export/import.

Operation

A Web-based, hosted service requiring only a Web browser.

Conclusions

This product is more appropriate for an enterprise with expertise in managing M&A events. Although designed for the execution/integration stage, it is adaptable to the other M&A stages with client modifications.

12.0 What Acquired IT Organizations Can Do Most of the IT perspective offered in our M&A research has focused on the acquiring enterprise. However, IT organizations in the company being acquired have considerations and responsibilities of their own to address.

The first consideration is an obvious one: Whenever it becomes known that a company is being sold, the initial question in most employees' minds is: "Will I still have a job?" This issue is more complicated for managers because they operate with the added burden of concern for their people: "Will they have a job, and how can they be protected?"

For the target enterprise staff and managers alike, many factors dictating their own employment fate will be outside of their control. They may have an opportunity to influence this by participating in the due-diligence and integration process. Because all three M&A models involve retaining acquired employees and, possibly, their processes, it is important to be actively engaged in the M&A process to gain advantages. People will gather information and evaluate the company, and decide what goes and what stays. In these interactions, employees from the target enterprises will have an opportunity to influence their personal outcome.

In general, this opportunity won't become available until the due-diligence efforts of Stage 3 and the due-diligence 2 portion of Stage 4 get under way. During these relatively short periods of time, many decisions will made that will determine the fate of most of the target enterprise's IT staff and IT infrastructure. By Stage 5, the people involved will already be part of the merged organization, and will generally know whether they will be kept for the long term. Employees from the acquired company who participate in the post-transformation review activities of Stage 6 have obviously secured a place in the new organization.

Therefore, for IT people in the target enterprise, the critical periods in the M&A process will be Stage 3 and Stage 4 (when they still have an opportunity to influence decisions) and Stage 5 (when they will be fulfilling responsibilities for executing those decisions).

12.1 Stage 3 and Stage 4 IT Actions for Target Enterprises Review pertinent sections of this report from the perspective of the organization being bought, but pay attention to what is important to the buyer and how to proceed. It is valuable to see the big picture and understand what actions are appropriate during the process.

• First impressions are important, and Stage 3 is the time to ensure they are positive ones. Stage 4 is the last decision point.

• The due-diligence team will also be nervous about the effort. The members will be concerned about executing the process well, making the right decisions and trying not to



miss anything that could come back to haunt them. Any help you can provide them to assuage these fears can reap rewards long term.

• Your environment is foreign to the buyers who have been given little time to understand it. These are your leverage points.

• The due-diligence team values people who are open, fair, cooperative and reliable. Avoid presenting issues in an unrealistically positive light to curry their favor. Eventually, the reality of the operation will become apparent to all, so the last thing you want to do is hype something that, under scrutiny, loses its luster.

During due diligence, three basic sets of activity take place simultaneously:

• Evaluating assets

• Understanding how the operations work

• Evaluating people

The following sections examine each of these areas from the IT perspective of the acquired enterprise.

12.1.1 Asset Evaluations

Reviewing IT assets involves assessing the infrastructure. This is a basic area of review, where the focus is on obtaining an inventory, a sense of contract liabilities and operating effectiveness. For IT people in the target firm:

• It is important to ensure that everything is presented that was asked for. Don't "doctor it up" or attempt to obscure troubling items.

• Although nothing is likely to be a deal breaker in this category, the due-diligence team may have doubts if strange things start showing up when individual items are pursued further.

• Some things may simply be embarrassing, such as a software contract portfolio that became fat and mismanaged. These are mistakes of the past, and nothing can be done about them now.

• The due-diligence team must evaluate your company, and you should help them do that. "Technology hyping"— that is, regarding why one choice is better than another — can start here but usually leads nowhere, unless the acquirer is buying the target company's IT expertise.

12.1.2 Business Operational Reviews

Functional and IT people are usually combined for business operational reviews.

• The best strategy is to go out of your way to be helpful and to be perceived as trying to get the best deal for both parties.

• Operational knowledge is respected in this step and quickly becomes obvious to all those involved.

• Unless the choice will be a stand-alone M&A model, all functional people must understand how the operation works. This becomes the foundation for determining a successful merger.



• If the buying team reveals details about its operations environment, you have the opportunity to compare systems and have a dialogue on best and worst points of each. When this happens, the due-diligence team is showing respect for the target organization and raising its people to the level of peers.

• If it appears that modifications to the target enterprise's systems are needed, the seller should ensure that the IT people on the due-diligence team understand the complexities involved, because it's the buyers who have to estimate the time and resources needed.

• Often, the IT organization must write reports to fulfill the due-diligence team's information requests. It is helpful for the target to assign a group of IT people to the due-diligence team with the sole purpose of generating reports.

• Time is short for the due-diligence process, and the due-diligence team will be aware of who is helping to ensure that their needs are met.

12.1.3 Evaluations of People

Judgments about people take place quietly all the time. A formal process can be useful to people in the acquired organization:

• The team's observations of how target people interact with one another and how they deal with management will provide subtle clues as to the true environment being bought.

• The due-diligence team is new to the operation being reviewed and can easily get sidetracked in a confusing area. Seeing this happen, a representative from the target company has the opportunity to resolve the buyer's confusion and get the questioner back on course. When done carefully, this is helpful and a sign of a valuable individual.

• Unless this is a hostile takeover, IT staff in the acquisition target will need to strike a balance between being helpful and doing all the due-diligence team's work for them. After all, the seller basically wants to be bought by the best buyer.

• When people learn that their organization is being sold, a natural reaction is to feel they have failed or "didn't measure up." This can easily be felt in other due-diligence activities by attitudes such as "Let's see how smart they really are" or "If they aren't smart enough not to ask the right questions, why should I help them do their job?" These attitudes should be discouraged because they help no one during due diligence.

• The environment also needs to be evaluated. For example, the condition of the working space, cluttered vs. organized, says a lot about an organization's culture. Addressing such issues before the due-diligence event puts the target in a better light.

• In many ways, due diligence is an interview process for the target. Every merger is a two-sided deal, and the seller wants to do everything possible to get the best deal.

The evaluation stages should also be viewed as an opportunity to interview a prospective employer. Some ideas to consider:

• The M&A event can become a transition point in your career, a time to re-evaluate your options.

• You should gather all the information possible about the acquirer to get a feel for the company. Annual reports and 10-K forms can provide considerable information about prior acquisition activity, although these sources are unlikely to explain how past acquisitions were executed.



• Anecdotal evidence is usually available. However, ensure that the sources of such information aren't limited to people who were unhappy with the outcome.

12.2 Stage 5, IT Actions for Target Enterprises By this point, most of the major decisions will have been made, although not necessarily in detail. Nevertheless, during this stage, the IT organization in the target enterprise can still influence the outcome.

• From a positive perspective, if you are part of the new organization, then you can secure the best position possible. Even if you weren't selected to stay on after this stage, your work ethic may change that decision, given that circumstances may change and other people may leave.

• From a negative perspective, being seen as an obstructionist to the transition will shorten your stay, regardless of whether you were being kept for the transition or the long term.

From a business perspective, employees have a responsibility to do their jobs as best they can as long as they are still drawing a paycheck. Having observed numerous acquisitions, Gartner has found that, in general, almost everyone displays personal integrity and does the job asked of them. By Stage 5, everyone is merely executing projects, just as they were prior to the acquisition.

The new dimension is coming to grips with how you will fit into the new environment. The project work provides the first real view of the new organization, and enables you to resume managing your career. The projects come first, but you should be seeing support from management in terms of helping resolve personal, transition-related issues. If such support isn't evident, contact an HR representative, who should be in tune with these issues.

13.0 Due-Diligence Checklist This section contains Gartner's list of potential focus areas for M&A due-diligence efforts. It can easily be turned into a question list by selecting a set of focus areas and using appropriate phrasing.

13.1 General Information • Business model structure (for example, customers, products, services and competitors)

• Business strategy

• IT strategy

• Office locations

• Number of people per office

• Cultural differences and/or similarities

• Availability of housing, schooling and family infrastructure

13.2 IT Standards/Architecture • IT architecture documents:

• Applications architecture



• Information/data architecture

• IT hardware architecture

• Standards development, management process

• Established IT standards

• Network

• Database/information

• Middleware

• Platforms

• Management software

• Desktop

• Mobile/portable

• Non-PC end-user devices

• Embedded technology

• Operating systems

• Use of operations standards, such as ITIL or CobiT

13.3 Business Process/Applications • Diagram of key applications and their relationships

• Data warehouses

• Sarbanes-Oxley Act compliance capability

• User/desktop application delivery environment

• Platform analysis (client/server vs. mainframe vs. Web-based)

• Workgroup computing

• Workflow computing

• Commitments for joint venture or partnership arrangements

13.4 Application Portfolio • Customer-facing (for example, customer relationship management)

• Back-office (for example, manufacturing and logistics, unless viewed as single end-to-end process with customer)

• Support (for example, finance and HR)

• Package or developed in-house

• Applications operated globally, tax and financial considerations



• Middleware requirements

• Documentation status

• End-of-life status

• Replacement status

• End-user-developed applications, support expectations

• Industry-specific technology (for example, asynchronous transfer modes or robotics)

• Application security

• Digital signatures

13.5 Application Change in Progress/Backlog • Active project status

• Backlog project status

• Application supportability — for example, ease of change and change resource availability/capability

13.6 IT Operations Infrastructure • IT installed equipment — leased, owned and outsourced

• IT equipment on order — ownership and delivery commitments

• IT software — owned, licensed or contracted

• IT software on order — ownership and delivery commitments

• Local telecommunications infrastructure

• Local network infrastructure

• WAN structure

• Internet capability

• Servers

• Databases

• Middleware

• Storage

• Output management

• Network and systems management software

• Desktop environment description

• Remote access capability

• Equipment use



• Security systems

• Seasonal patterns that indicate an unusually high-peak requirement

13.7 Operations Capability • Capacity planning

• Contingency planning

• Storage management

• User management

• Administration

• Problem management

• Service-level management

13.8 Data Centers • Physical security

• Disaster recovery capability

• Service providers

• Power availability, obligations

13.9 Financial • IT investment decision process (governance)

• IT expense budget (line of business and corporate)

• IT capital budget (line of business and corporate)

• IT metrics used and results from the past 12 months

• Restrictive government regulations — for example, encryption algorithms

13.10 Contracts • Contracts and licenses — cost, duration, renewal options, early termination penalties,

transferability and liabilities — for:

• Equipment and maintenance

• Software and maintenance

• Application services and maintenance

• Contracts with external service providers (for example, consultants, integrators and contractors)

• Agreements concerning installment purchases, franchises, employment, suppliers, customers, confidentiality/non-compete and warranties



• Utility cost to operate data centers

13.11 Assets • Owned IT equipment

• Owned software

• Furniture, fixtures and office equipment

• Real property obligations, contracts

• Capital asset depreciation schedule, status

• Debt servicing (for example, a special bond financing for a facility)

• Taxes (for example, property taxes)

• Geographic issues (for example, foreign financial commitments)

13.12 Intellectual Property • Copyrights

• Patents

• Service marks

• Trade secrets

• Trade names

• Employee obligations (for example, can they claim ownership of any intellectual property?)

13.13 Organization/Sourcing • IT organization charts

• Consolidated/centralized and distributed to business units

• Number of people

• Location

• Management competencies

• Operate as a team

• Understand business operational details

• Business perception

• Use of competency centers and/or project office

13.14 Internal Staff Skills and Competencies • HR policy



• Compensation

• Hiring and retention practices

• Training strategies

• Bonuses and indirect benefits

• Skills management process and structure

• Skills needed to maintain infrastructure during M&A

• Project leadership capabilities

• Project on-time, on-budget results for the past 12 months

• Application support and maintenance approach

• Application development methodologies

• Team leaders assessment

• Core IT competencies

• Training issues

• Technology transfer and learning opportunities

• Local competition for IT resources

13.15 Externally Sourced Skills • External supplier relationship management

• Local availability of external services

13.16 Organizational Change Management • Cultural differences

• Leadership style

• Management style

• Time period for accomplishing change (up to 36 months)

• Need for outside help

• Cost to maintain services (for example, retain skills during transition)

• Cost to retrain and retain employees

Acronym Key and Glossary Terms

AHP Analytical Hierarchy Process

CobiT Control Objectives for Information and Related Technology

ITIL Information Technology Infrastructure Library



M&A mergers and acquisitions

SG&A selling, general and administrative

TAI target attractiveness indicator

REGIONAL HEADQUARTERS

Corporate Headquarters 56 Top Gallant Road Stamford, CT 06902-7700 U.S.A. +1 203 964 0096

European Headquarters Tamesis The Glanty Egham Surrey, TW20 9AW UNITED KINGDOM +44 1784 431611

Asia/Pacific Headquarters Gartner Australasia Pty. Ltd. Level 9, 141 Walker Street North Sydney New South Wales 2060 AUSTRALIA +61 2 9459 4600

Japan Headquarters Gartner Japan Ltd. Aobadai Hills, 6F 7-7, Aobadai, 4-chome Meguro-ku, Tokyo 153-0042 JAPAN +81 3 3481 3670

Latin America Headquarters Gartner do Brazil Av. das Nações Unidas, 12551 9° andar—World Trade Center 04578-903—São Paulo SP BRAZIL +55 11 3443 1509

it handbook on mergers acqui 130975

Business

initial candidate screening

screening activities

integration process

integration planning

initial candidate evaluation

ma process stages

acquisition process

research publication