A friend of mine recently took a break from his daily routine to do some consulting for a few days. Specifically, he helped another organization roll out a new email infrastructure based on Exchange. The company was running a different system and is in the process of moving toward a Microsoft stack. Prior to his onsite visit in early May, my friend helped the organization design the new Exchange-based infrastructure after which they asked him to help them in person.
What did he find upon his arrival? There is significant infighting internally in the IT group with one group initially refusing to support a particular need. This refusal would have doomed the project, but after some wrangling, the refusing individual eventually relented and the project could move ahead. At this organization, Active Directory is apparently supported as a part of the overall responsibilities of the network group, while the Exchange system is supported by the applications group - these are different units within IT. As you know, Exchange is heavily dependent on AD, so a high level of cooperation between the two groups is essential.
A little background: The company moved toward Exchange at the specific behest of the CEO and with the full support of the CIO, who also made it a priority project. There are good reasons for the migration and the merits of the migration are not discussed in this posting.
How do some in IT feel about the migration? Evidently, some are not so happy about it. While Active Directory has been in place for a number of years, it's not been considered a critical service, nor has it been treated as such. As I mentioned, AD has been supported by the network group. This group is seriously concerned about encroachment of other applications into the AD space and appears to be particularly territorial in this regard.
Now, my friend completely understands the importance of securing the AD infrastructure, but it was relatively difficult to get things done while he was on site a few weeks ago. Although IT as a whole was completely aware that a migration to Exchange would be taking place, the network group did not prepare in any way. It was understood that some of the Exchange domain preparation work needed to be tested, but this was not done before the on-site visit. Further, no one was able to locate the Exchange media in order to extend the AD schema. Moreover, no one could locate the individual that could get the media. A comedy of errors! Finally, my friend downloaded the Exchange media and gave it to the network people along with complete instructions and implications for extending the schema. The task was completed, but it seemed to take quite a bit of what seemed to be unnecessary effort.
When it came to domain rights, it finally came down to the CIO telling the manager of the network group that he could make one of two choices (1) Make a staff person immediately available at all times throughout the term of the consultant's visit or (2) Provide a trusted member of the applications group with enough rights to be able to join Exchange servers to the domain and be able to perform any administrative and troubleshooting steps that needed to be undertaken. The network manager chose the second option.
From what my friend could tell, it looked like the network group was attempting to block the project or, at the very least, were upset that it had such an impact on their infrastructure. The word "security" was mentioned quite a number of times as well. While security is always an important consideration when rolling out any new service, "security" can also be used to accomplish the goal of task avoidance. Heck, the most secure network is the one that has every service blocked and has no users. Any time a new service is introduced that opens more ports; an organization is consciously making the decision to increase their overall attack surface with the trade-off that there will be better business processes or increased sales. I, personally, have seen the security excuse used for both positive and negative purposes. If something is going to truly endanger the organization, then tell me what we're facing so I can make a better decision. However, if you're interested in simply eliminating change and that's your primary motivation, then save it.
The result: Days of delays with an expensive consultant struggling through organizational dynamics. To be fair, the CIO at the organization was, at the time, facing a unique situation that made it difficult for him to effect some changes that could have cleared up this situation.
In my organization, when I outline an organizational priority for my staff, I expect that they will work together to see the job through. I do not expect to have to constantly get involved in interpersonal disputes and bludgeon people into doing their part. I'm more than willing and happy to listen to arguments and concerns ahead of time (and even along the way) but once the decision has been made, roadblocks should cease and solution-finding should begin.
Infighting between groups should never derail or stall a project. Of course, there might be concerns shared between groups regarding prioritization of tasks and people, but these should be laid out at the start of the project so people know what to expect. Obviously, if the CIO is pushing the staff to do something completely ridiculous (i.e., "Hey! Let's take out the firewall to make the Internet faster!"), someone can go talk to HR or to the CEO.
Healthy debate is an integral and critical part of any project; without it, poor and incomplete decisions are made. However, if that debates turns into something more - passive aggressiveness, for example - something is wrong and the users and the organization will suffer.
What do you think? Am I full of hot air? Unreasonable? Or, does this outlook make sense?
Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at email@example.com.