Banking

10 ways for IT to survive a merger

Consolidating staff and system platforms during a merger is a highly charged and complex undertaking -- and IT is right in the thick of it. Here's what you should know going in.

Mergers are a fact of corporate life. They also require IT to play a major role because different systems must be consolidated. The work IT performs in mergers is so mission-critical that if it's determined that systems can't be readily consolidated and made to work together, the merger might be called off. Needless to say, performing IT work for a merger is risky -- not only technically but politically. Here are 10 things to think about if you are tasked with IT for a merger.

1: Understand what is at stake

Mergers aren't just "clinical" projects that convert systems so they work together. For IT and throughout the organizations involved, mergers mean that some jobs are likely to be consolidated as well. Some IT staffers are going to keep their jobs, while others might not. The IT staff also has technical allegiance to systems it's familiar with. So if a favored system is designated for termination, there can be fear and bitterness because that also potentially eliminates a particular technical skill set.

Finally, there is the IT consolidation project itself. System merger work is major. Often, the systems that have to be converted are scantly documented, and the people who know about them aren't overly helpful. The more you understand about this complex of conditions going into the project, the better you'll be able to weather the pressures and the conflicts that are likely to arise.

2: Consider sabotage in your risk management strategy

Once I was tasked with a major system consolidation project for two behemoth companies that were merging. The "victim" company whose systems were going away had IT staffers who were uncooperative and withheld vital information needed to safely convert their existing system to the new system platform. It was a subtle form of non-cooperation, so there wasn't really a way to call this "sabotage" out loud -- but it was indeed a kind of sabotage of the low-grade variety.

Getting the situation under control extended the project timeline several months. It took numerous conversations with executives and managers in both organizations to convince them why a project extension was necessary. I also communicated regularly about the inherent risks of converting "black box" software routines without documentation. We factored in extra testing time to ensure that the converted software worked in every imaginable situation. This slowed the project down, but at least we didn't have a disaster!

3: Know when it is ill-advised to convert a system

Sometimes, organizations wish to merge, but their systems are so incompatible that it doesn't make sense to consolidate them. In these situations, CIOs take a longer view. They allow both companies to continue to function with their existing systems, and they identify a third "long-term destination system" that everyone will ultimately be on. If new organizations come on board and don't have a previous history established with the unworkable systems, they are often placed on the final target system from the start. This at least pares down the future conversion effort.

4: Communicate

Even If project news is bad, give it to the people straight and as quickly as you can. I've known project managers who became so nervous at having to deliver bad news, they just wouldn't. Consequently, small problems festered until they were nearly insurmountable. Seasoned business executives understand how difficult system consolidations are, so they expect to hear some bad with the good.

5: Lay out your go-forward staffing as soon as possible

If some staffers are going to lose their positions because of the merger, work hard to negotiate decent settlements and employment assistance for them. It's the right thing to do -- and it sends a message to remaining staff that management is taking the high road. For remaining staff, communicate as rapidly as you can what their individual roles are going to be and what the new IT organization is going to look like. This relieves anxiety and allows staffers to focus on the job at hand.

6: Manage by walking around

We've all heard "manage by walking around" so often that it has become trite. But the actual practice never goes out of style. Mergers mean change, even to those who get promotions because of them. By walking around, you can visit person to person with staff, see how they are doing, and observe body language. This puts you in a position to see whether staffers are comfortable or need to be reassured. The system consolidations brought about by mergers are always emotional projects. Make it your job to watch the people side of the project as closely as you watch the progress of the work itself.

7: Develop a vendor strategy

Vendors don't like to lose accounts. So if a vendor's system is designated for de-implementation as a consequence of the merger, beware. You might find that the vendor is unusually slow to respond to requests for de-conversion programs, data, and documentation -- or slow to respond if you run into a problem while de-converting. This is an important area to check out while you are still analyzing the system merger project. The vendor contract should be reviewed to see what the conditions for a de-conversion are -- or whether there are any provisions at all. You should assess the level of risk from vendor non-cooperation and convey this to other top-level managers so everyone has up-front awareness of the issue.

8: Have a fallback plan

Once you've performed all your testing and you're ready to cut over to the consolidated system platform, make sure that you have a "way back" for failover in case something unforeseen happens. It never hurts to have a plan B -- and your auditors will love you for it.

9: Provide visibility

It's impossible to overdo visibility in a project with so many complications and sensitivities. Whether the system consolidation project is running smoothly or whether it's in the rough, let key stakeholders know present status and what you're going to do next. Projects are never perfect. But for most stakeholders, half of every project's success is feeling that they're in control.

10: Don't cut over to production until you are ready

I've seen project managers get so pressured by their bosses to cut over to production that they proceeded even though they knew the system wasn't ready. What these project managers invariably discover is that they're in an even bigger mess than the one they would have been in if they had stood their ground and said the project wasn't ready to go yet. If your boss overrides you, there isn't much you can do. But you owe it to your boss and to yourself to speak up and say that the project requires more time if you think that is the situation.

Other advice?

What other suggestions do you have for handling the technical and political issues surrounding a merger? Have you been involved in a relatively smooth one -- or seen the wheels come off as the merger progressed?

About

Mary E. Shacklett is president of Transworld Data, a technology research and market development firm. Prior to founding the company, Mary was Senior Vice President of Marketing and Technology at TCCU, Inc., a financial services firm; Vice President o...

8 comments
Dyalect
Dyalect

Just a way of life. You can't pile/duplicate/create redundant resources (people) and expect to be a smooth transition. You can only hope you land on the "winning" side of things and retain control and influence.

rkuhn040172
rkuhn040172

Having recently gone thru a company split, I can say they aren't any easier either. Lack of communication, costs overruns, and missed deadlines galor. For costs reasons, many projects are still just now being completed as the price factor required them to be done piece by piece by piece. If management can't afford to split a company, it shouldn't be split!

gscratchtr
gscratchtr

"... and be prepared to pay" Having been a software vendor whose solution was "the loser" during a merger of our customer with another company, we were not surprised that the merged company wanted our help to migrate to "the winner". They were quite put-out when we said that we would charge for such a service, and refused to pay. They ended up trying to handle it as "Support".

rotvic
rotvic

Seldom there are "mergers of equals", although for tax and investor purposes many mergers are labeled that. The "winning" company in the merger decides what goes and what stays, usually for political purposes - if a solution from the other company is superior and gets adopted, it may be hard to explain why it wasn't implemented in the winning company to start with. The result is a paradox: the winning company is sabotaging the project by hiding the short-comings of the selected solution while the "loosing" company cooperates in all aspects under the naive assumption that decisions will be based on merit! Remember, there is no failure until someone has the courage to call the project a failure - and provide the necessary explanations what went wrong. In most cases it is a lot easier to hide the failures and pretend everything is working fine and present the necessary fixes as "enhancements" that require additional time and budget. If you start in the “loosing” company, survival in these conditions is probably impossible. It is important to realize the fact early, cooperate as much as possible (you can’t cooperate if you are not asked to or your opinion is ignored), see if you might get some consulting work in the transition phase and plan for the future – there are other companies out there.

mwclarke1
mwclarke1

Well, if only focus on the bad stuff mentioned (and much more) would describe my company's merger. Big conglomerate, buys us and our competitor, Not so well performing company and great performing company, mergers both, keeps low performing company exec team. Great performing company had all its employees engaged in the decision making and running the company. Now only VP and above makes all decisions even technology, which sometimes replaces already working good with something bad, then eventually gets scraped because someone higher up saw it somewhere else or read about it. Were expected to consolidate all redundant systems in one year, was decided without asking anyone how can do it. then was 18 months, now many years later, a few but not most. For one, they saw it as having twice the staff, so some had to go, not accounting for twice the systems and devices and applications, now understaffed projects got behind. Having the redundant systems remaining they did not realize the cost saving quick enough, more people had to go, more project got behind, no more consolidation. Now, are outsourcing many IT operations and other company AP, billing, etc but were keeping key personnel. The ones that are good, are leaving regardless now, way many more than the company thought would, and they are puzzled as to why. The comments from the top are the company will meet EBIDA numbers regardless, this is their only focus, and will be as they one day are going out of business, and they still not know why. I am looking forward to getting in with another start-up, innovating, growing company and not looking back.

neilson
neilson

I was brought in as a contractor (at a very high hourly rate) for a project that turned out to be the remains of a merger and restructuring. I immediately encountered sabotage, but failed to recognize it. My desktop computer mysteriously proved unable to allow me to do my assigned work. Other IT people told me it was fine and that I simply didn't know how to do my job. Well, after three weeks I located someone from another part of the company who said he'd look into my difficulties. "This system's hosed! No wonder you can't do anything," he said. He fixed it. Suddenly I could access the working version of the data for my project, instead of the stubbed version I'd previously been seeing. My contract was ended two days later. I still have no idea what my actual purpose was in that crazy exercise.

TonkaToys
TonkaToys

Wow... you didn't work where I do, did you? That sounds exactly like what happened here.

NickNielsen
NickNielsen

that the project couldn't be done by an outsider.

Editor's Picks