% fortune -ae paul murphy

Brief: 5

This is the fourth excerpt from the first book in the Defen series: The Board Member's IT Brief.

From chapter 2 "Evaluating IT Proposals

Section 2.2.1 "Mergers and acquisitions"

You usually have no real choices on post merger or acquisition IT proposals aimed at integrating the two sets of systems - it's either spend the money or write off management's integration plan for combining the old business with the new.

Of course such expenditures should have been considered as part of the original decision to combine the operations, but the more common thing is for the senior executives involved in the merger talks to keep their IT people in the dark until the deed is done -and only then give them the task of coming up with the integrated information systems needed for the merger to actually succeed.

The easiest mergers happen when the target has outsourced its systems support

There are two reasons: Out-sourcing usually indicates that their executives were not paying attention to systems and did not value information - meaning that there should be lots of room for the kind of operational improvements your people can bring to the merged entity; and Their users won't fight to keep what they don't like; instead they'll see your incoming IT staff as potential saviors and willingly learn whatever they have to, to adopt your systems.

If the two groups don't have fundamentally the same systems architecture in place then you need to understand that the resulting systems conflicts will not end until either the merger is undone, or the last adherent of the losing technology leaves the organization.

Don't kid yourself about this: if the merger partner isn't a significant fraction of your size, their user resistance will be futile; but, in the most common case the merger partner is big enough to matter; IT integration planning is forgotten until well after the public hue and cry of the merger arrangements; and the two information architectures are not the same.

Remmber rule 4: If the expertise doesn't match both the problem and the solution, the project will certainly fail.

In that situation it's usually best to pick IT winners and losers right from the start: forget staff integration, think invasion in force and get it over with before anyone has time to dig in for a long period of resistance.

Remember: if the partner is big enough to matter, IT conflicts can easily make the merger fail - and it isn't likely to be deliberate. If you use Unix, your partner uses a mainframe, and the negotiators put their CIO in charge of the combined business -you're in deep trouble: not because he's a bad guy or incompetent, but because your side made a serious mistake by putting a person from one IT community in charge of a system drawn predominantly from another.

In deciding what, and who, to keep, and what to throw out: get outside help -and don't assume that your organization's IT people are any better than the other guy's. Different may mean no more than different, but it can also mean better or worse.

Don't confuse multi-system experience and expertise with dishonesty

Picking consultants for this is risky, but it's not generally technology bias that you have to worry about. That is what you'll hear about - but it's not usually the key issue. Thus your systems executives, or the other guy's, may object loudly to a particular choice because he's known to have offended in some way, or to favor the "wrong" information architecture- but the reality is that the legitimacy of the fears behind such charges depends on the individual's integrity, not his technical opinions.

I, for example, am a Unix guy; so if you have Windows, your merger partner uses Solaris with Sun Ray desktops, and you hire me to adjudicate, it's not going to be hard to predict which side I'll favor. That may look like bias, but it isn't: bias requires that an opinion be held in the absence of facts - i.e. bias consists of a demonstrated willingness to substitute someone else's opinion, usually that of a perceived majority or other source of social power, for independent thought.

Basically, any sane person who has to choose between different information architectures is either going to be incompetent with respect to at least one of them, or biased in favor of one over the other(s). What you should be worried about in choosing consultants is unrevealed bias and the pressure that comes with long term business relationships.

Consultants, like kidnap victims, often become enamored of the companies that hold their jobs hostage - and all of the big firms are dependent on the goodwill of suppliers like IBM or Oracle and the IT community leaders they influence, because these are the people who control access to most of the IT consulting market.

Basically you're going to hire them once, and for a relatively small job, but your consultants have to work with the same supplier communities all the time - and that makes these suppliers far more important to the consultant's future than you are.

In other words, you can hire them, pay them, build a relationship with them, and work through their conclusions with them, but their real loyalties will usually lie with the companies and senior IT executives who control their marketability - not with your organization, and certainly not with you. Nevertheless, outside help is usually needed, so get someone selected and then hold your nose to vote money for three things:

1. having that person adjudicate systems and staff survival;

2. helping displaced IT staff find other jobs; and,

3. spending lavishly on user reassurance (aka training).

Some notes:

1. These excerpts don't include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.