Free IT Manager's Handbook: Getting Your New Job Done by Bill Holtsnider, Brian D. Jaffe

thinking, you can hold your head up with pride.
    The first thing you need to do is make sure that you fully understand what the problem is, what the implications are, and the impact of the various alternatives. Those who bring the problem to you may provide some options, and you may have some of your own. You may want to run the issue by other people on your team to see if they have a different perspective.
    Depending on what’s involved, you may want to alert key people outside of IT, either to make them aware of the situation (such as the users) or to involve them in the resolution (such as the head of Accounting in the example given earlier).
    Sometimes, the decision-making process is easier if you think about having to explain/defend the worst-case scenarios for each alternative—if it should happen. For example:
•Your database server crashed and it’s taken seven hours to restore. To be certain that the restored database is 100 percent functional, you should run an integrity check utility, but that will take another three hours. Do you run the integrity check and sentence the users to another three hours of downtime or just hope for the best and bring the database online as soon as it’s restored?
•If you don’t run the integrity check, you risk the database being down for an additional 10 hours (seven hours to restore again and three hours to run the integrity check you decided against the first time). If you do run the integrity check, you have to explain why you decided against bringing it online as soon as possible.
•Many people might be willing to take the risk by rolling the dice and not running the integrity check, especially if they have reason to believe it may prove to be unnecessary. However, many of those people will also change their mind when asked if they are ready to explain their decision to senior management if they end up being wrong.
    You want to appear confident and calm as you approach key decisions. These traits are important because they are contagious. If others see you keeping your cool, they’ll probably do the same.
    1.8 Two IT Departments—What Happens If Your Company Merges with Another?
    Mergers and acquisitions are pretty common events in the business sector. They come in all shapes and sizes from mutually agreed upon merger plans to hostile takeover scenarios.
    Any sort of organization merger or acquisition can have an enormous impact on the IT department, and you as its manager. Until it is complete, there are two IT teams—each with its own processes, standards, vendors, technologies, and culture.
    With luck, your company has included you in the high-level planning for the merger. This lets you, as the IT Manager, learn about the other company’s IT department. You’ll then be able to report to your management and advise them as to what type of effort might be involved to join two teams, systems, and environments into one.
    From an IT perspective, there are generally three ways to go about merging another company’s IT environment. The path you choose may depend on your company’s management style (e.g., centralized vs. decentralized), available resources, economic and market conditions, timetables, regulatory issues, and so on.
1. Brute force. This amounts to rebuilding everything at one company that isn’t compatible with the other. This approach usually results in a shock to the system of the acquired company and its IT department. It’s pretty painful, but is often the fastest way of getting the two companies integrated and operating as one. Usually, the first technology addressed is e-mail, followed by business applications, user support, operations, OS and database platforms, and networks. This process also includes evaluating procedures and vendors. The brute-force approach won’t be successful unless the appropriate authority and mandate from senior management are in place to see it through, along with the necessary budget and staffing resources. Expect a