10 ways for IT to survive a merger

A lire sur:  http://www.techrepublic.com/blog/10things/10-ways-for-it-to-survive-a-merger/3476?tag=nl.e101&s_cid=e101

By Mary Shacklett

October 29, 2012, 5:02 AM PDT

Takeaway: 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?