Most Exchange Server administrators like to think of themselves as technical people. Technical problems usually have fairly clean solutions, and evaluating things on a technical basis is usually a straightforward and objective process. However, sometimes politics intrude on technical decisions, to the detriment of all involved.
Take the example of one customer I'm working with. The organization has about 10,000 mailboxes spread across various sites in the United States. The primary site, on the East Coast, has most of the mailboxes; individual business facilities in other places have their own Exchange servers. This customer's messaging team designed a consolidated solution that would move all the mailboxes to a central site, using clustering and SANs for better availability, and also added failover capacity to a remote site. After the team proposed this design, the real fun began, as individual business units started objecting to having their Exchange resources centralized. No technical reasons for these objections exist; the centralized environment provides better support and more capability at a lower cost--a cost that the corporate entity and not the business units bear.
The objections to this consolidated solution didn't make sense to me, so I started talking to people to find out more about the kinds of political objections that sometimes derail messaging projects. Boy, did I get an earful! In my role as a consultant and author, I usually get involved after the political arguments have already been settled; only rarely am I called in to settle those disputes. What I found from asking around is that there are several common patterns that occur in messaging projects, ranging from the generic (resistance to change, executive desire to throw business to a particular vendor) to the very specific ("You can't deploy Exchange Server 2003 because it breaks our business-critical application"). The most common objections seem to revolve around control issues: Centralization sometimes seems threatening to groups or individuals who are used to controlling their own messaging systems. Of course, centralization also brings a sometimes-welcome shift of responsibility, which is one argument that's sometimes successful in defusing this particular objection.
Personal preference is another recurring theme. It seems to be most common when a senior executive arrives from outside the company and starts looking for excuses to make the messaging environment conform to what he or she had at the previous company. For example, it's common to see sudden outbreaks of RIM BlackBerry deployment after the arrival of a former BlackBerry user at a company that's not currently using the devices. Of course, this more often works in favor of Exchange administrators than against them, as most of the personal preferences come from people who want new and improved capabilities. (I remember seeing a rash of upgrades from Exchange 2000 Server to Exchange Server 2003, driven primarily by the desire to get the new and improved version of Outlook Web Access (OWA).
What can you do if political concerns are blocking your deployment? I don't have much blanket advice to offer because environments at different companies are so different. In some organizations, making a well-supported technical case is usually enough to dynamite political roadblocks; at others, the IT department is at the mercy of other parts of the company that provide funding for, and thus feel entitled to dictate to (rather than be informed by), the messaging experts. Sometimes the best solution is to wait out the opposition; regrettably, there are times when all you can do is grit your teeth and go along (perhaps sending out resumes as part of the process).
I'm interested in hearing how you've solved these kinds of problems in your own deployments. Drop me a line and let me know what methods have been successful or otherwise. In a follow-up column, I'll present suitably sanitized advice based on your comments.
