Making Exceptions To IT Rules Wed 16 Sep 09
Treating standards as absolutes can be counterproductive.
IT folks often see things as a choice of two absolutes. It suits our way of thinking. It may have started with the days of binary coding where everything was either a 1 or a 0 and only a 1 or a 0. We like the simplicity and elegance of only having a choice between 1 or 0, right or wrong, yes or no, black or white. This black or white perspective would be nice if it could truly be achieved, but the hard truth is that we live in a gray world where absolutes are rare.
So we write our policies and develop our standards. We make them iron clad and air tight. And then inevitably comes an exception. One of the vice presidents at your company wants a special cellphone or new style of laptop. Or perhaps it's an engineer wanting to purchase a new software package that IT hasn't approved.
After a lot back and forth, we may give in begrudgingly or hold fast and have a customer grumble about the poor customer service. Either way we do a slow burn and say to no one in particular, "Don't they know what we're trying to do? Don't they understand we have standards?" The simple answer is "No, they don't."
Although we may know and love our standards, most other people won't be familiar with them. Hey, when was the last time you sat down and studied all the accounting or purchasing policies. Get my point?
Don't hide behind your standards. The next time someone asks for an exception avoid that trite and off-putting phrase, "That's not our standard," and instead explain the situation. You might say: "We're trying to save the company money by reducing support costs by standardizing on one model. How can we work together to meet your needs and still keep costs under control?" If users understand the reasoning, they are more likely to cooperate. Sometimes this cooperation will be going along with your standard, sometimes not, and sometimes it might be a compromise you both can live with.
Don't get me wrong, policies and standards are good things. They help codify what we are trying to do. They help make both IT and our users more efficient, protect the company's valuable data assets and save money.
However, standards are mostly not absolute. There will always be exceptions, so we better learn to live with it. A good friend of mine who leads a human resources group once told me, "We can't write a perfect policy. If we could, we wouldn't need managers. The job of a manager is to understand the policy and be able to figure out when to enforce it and when there is a valid and compelling reason to make an exception."
Other departments seem to have figured this out. It's not unheard of for some deals to have special negotiated terms and conditions, for certain customers to get extra service, for warranty work done beyond the expiration, or for accounting to write off uncollectable debts. The departments that handle these tasks may not especially like making exceptions but they have accepted them under the appropriate conditions. These departments may have even put provisions in the standards and policies on how to handle exceptions. Maybe IT should take a cue from them.
This brings me to my second suggestion on standards. We need to recognize that there will be some situations where exceptions are valid and figure out the best way to address and accommodate them.
Lastly we need to remember that all standards and policies are not created equal. Granting an exception to a user's e-mail inbox standard size limitation is one thing. Allowing a user to disable firewall or anti-virus systems on their PC is quite a bit different.
When developing standards and policies, consider which ones are critical and which ones have some "give" in them if needed.
Standards are good. Just don't forget that they are the means to an objective and are not the objective, and I think you'll find standards can be very useful.
This article is also posted on Forbes.com. Feel free to join in the discussion either on this site or at Forbes.com
If this topic was of interest, you might also like these: