Making Exceptions To IT Rules

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:

• Cheap Vs. Quality IT
• IT Doesn't Have To Be Annoying
• Standardizing for Efficiency - The Question is "More Efficient for Whom?"
• Or the posts in the "Strategy & Management"  category.

Comments

[doug goldberg]

Hey Mike:

Thanks for another great article. I wanted to elaborate a hair more on something you mentioned....
.....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.....

You're absolutely correct here. In fact, I believe it's more than just a recognition that the exceptions will occur. I think it's important to actually factor in exception paths to standards and especially processes when they are written in order to allow the integrity of the standard/process to remain when the exception occurs.

My two cents.

Doug

[Mike]

Doug,

Thanks for commenting. I agree , we do need to do more than just recognize the possibility that there may need to be exceptions and formalize the process we go about making them.

Mike

[twitter.com/Chris_P_Intel]

Mike, Great discussion. For client systems, Intel IT has progressed from no corporate standards (circa 95) to one standard (98-08) and drove dramatic cost reduction and efficiency. Now we are at a few standards based on the user's role in the organization (sales road warrior, factory worker, exec, etc). We see the future evolving with client virtualization technology to device independent computing where users could choose their own laptop and companion smart phone/netbook, etc and IT could deliver services in an any where, any time, any device. Pretty interesting concept and starts to remove some of this tension between what is good for user vs what is good for IT.

two resources for you and your readers:
20 years of learning and evolution on Intel IT client standard: http://download.intel.com/it/pdf/Evolving_Centralized_IT_Client_Management.pdf

A vision of Device Independent Computing http://www.intel.com/it/pdf/Client_Computing_with_VUE.pdf

Chris

[Peter Thompson]

Totally agree with you Mike, recently told my team the same thing, it's OK to make exceptions if you believe it will help the recipient and the bottomline of the company. I also requested they publish these exceptions so we can all learn from them. Standards, policies and rules can be used as an excuse not to take action and you find your team dumbing down and not being able to deal with a situation that needs them to think. Not sure if you have seen this inspiring video from Barry Schwartz http://bit.ly/1aB27F at the TED conference in February earlier this year. He states "a wise person knows how and when to make an exception to every rule".

[Mike]

Chris,

Those are great articles. Thanks for sharing them. I like the concept of letting user select their own platform of choice. As you say it does help to remove some of the tension between what is good for the user and what is good for IT. It helps get towards the goal of IT being there for the benefit of the users not the other way around.

Mike

[Mike]

Peter,

I hadn't seen that video but I'm glad you shared it. All I can say is "Wow". What an excellent video. Barry Schwartz is spot on. I especially liked his comments on the need to incorporate kindness, care and empathy and how we never see these elements in job descriptions but they are so crucial to someone being successful in their job.

As you point out, too often we use standards and policies as an excuse. That ultimately results in poor service levels. Standards and polices are good but I'll reiterate, "they are the means to an objective and are not the objective".

Mike

[Douglas Schultz]

Mike - Good posting. I've been in IT organizations like this and also with exception processes that were described by someone earlier. This article I read this morning also has similar themes in IT working with the new technologies and the new workers and I wanted to point it out to you in case you hadn't read it. I thought it was great.

http://www.thomaspurves.com/2009/09/17/how-to-be-a-cio-in-a-20-world/

Really enjoy your postings.

[Mike]

Douglas,

That is a great article. The point it makes about the impact of our policies and standards on recruiting and retaining employees is an excellent and often overlooked one. The part about "Try to spend most of your day enabling rather than denying the use of technology" is spot on. Doing otherwise which is what IT often does is what I call "The un-marketing of IT" http://mikeschaffner.typepad.com/michael_schaffner/2008/10/the-un-marketin.html

Thanks for sharing that link.

Mike

[Arun Manansingh]

Mike,
Great post.

I remember our transaction pipeline was very specific to each customer so we had to make exceptions quite frequently. I told my staff that it was all right to make exceptions if it will help close a deal. As Peter Thompson mentioned, I also requested my staff publish these exceptions so we can all learn from them. We tried to develop standards and policies to capture these exceptions an address how best to manage them. Standards, policies and rules should ever be used as an excuse not to take action especially when it will impact the company’s bottom line.

[Mike]

Arun,

Thanks for commenting. I agree we should never use standards as an excuse. As you and Peter have pointed out using exceptions as an improvement opportunity is a great way to improve your service levels.

Mike