Tuesday, November 15, 2011

Part 3 - Keep your phaser set on stun.

(This is part 3 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)

For those not familiar with Star Trek, “phasers” are the weapon of choice in the future. IT departments can wield a certain amount of control and influence in organizations and the application of this influence should be governed by rules similar to how phasers are employed in Star Trek.

IT's power needs to be used wisely. Like a phaser on Star Trek, you really should keep it set on stun. In many distributed organizations, such as a university culture, there are very few rules about what computing you can and cannot use. But there needs to be some policy around things like standards and security. My advice is to play nice, but don’t tolerate complaints caused when someone consciously chooses not to follow your standards.

For example, at my university we implemented an imaging and workflow project. The big problem was that desktop computers on campus were as unique as snowflakes. The rough breakdown was 30% Mac, 60% Windows, and 10% “other.” To make matters more interesting, most machines had a unique software image, so even Windows PCs weren’t “standard.”

When we rolled out the new imaging and workflow software, Macs didn’t work, many PC’s had problems, and Linux was completely unmanageable. We had huge implementation problems for this project because each desktop was unique. Software and hardware variety across campus made it nearly impossible to deploy enterprise software quickly and efficiently. Serious concerns were raised about the project and the software quality.

Instead of reacting in a knee-jerk manner to the issues, we stepped back and looked at the big picture. In culture such as an university environment, there is a key equation:

Freedom of Choice + Academic Independence = High Cost + Loss of Functionality 

We decided to use this to our advantage. We said if folks across campus want to make their own choices about desktops, then the issues with the imaging and workflow software are the price to pay. If clients don’t want this to happen again the future, we need organization-wide desktop and laptop standards. This clarity of choice gave us the ammunition necessary to make a change. We used these results to help justify a desktop standardization program across campus with the support of administrative and academic leaders.

We set our phasers on stun and turned a nasty problem into an opportunity. We leveraged a problem into an opportunity to convince folks that we need better standards across campus.

Another example of this Star Trek rule is how to enforce IT security. Traditional passive policies where you only take action after a security issue occurs are too dangerous to the network. Pro-active polices where you take action as soon as you realize a security issue may exist are necessary. The danger is that a proactive policy is very powerful. Like a phaser set on kill, if you use it indiscriminately you will do more harm than good. If you shut someone's computer access down arbitrarily without warning, you will destroy any future potential relationship with that person. My advice is to apply pro-active policies only as the last resort. They can be used as a threat of shutdown in order to convince someone that they should upgrade or fix their potential security issue. You can have the policy in your back pocket, but don’t use it unless you must. In other words, try to keep your phasers on stun wherever you go on campus.

Of course there are times when you can consider breaking the rules. Sometimes you need to set your phaser on something more potent. Several years ago I had been working closely with a department to develop a business case to implement a multi-million dollar system. Everything seemed to be going well until the client told me they would hire their own people to perform the ongoing support and maintenance of the system and manage it independently of the rest of IT. That’s when I set my phaser on kill. I stopped the project dead. They backed down and we were all a happy family again.

There are always exceptions to every rule.


No comments:

Post a Comment