Help Desk Software World  
Help desk software and  
Help desk outsourcing  

 The Directory of Help Desk Software Solutions and Information Contact Us Help Desk Software Solutions

Help Desk Software World:
Handcuffed by Standards?

In an attempt to cut support costs, the IT folks at Disney announced their decision to standardize on which PDAs they�ll support internally. As expected, this attempt to bring order to the chaos of unrestrained PDA proliferation has resulted in outraged wails of anguish. Even outsiders seized the opportunity to comment on their internal policies. �Disney Lays Down Anti-Palm PDA Policy� was the headline of one article, �Walt Disney bans every PDA but two� being another.


While I suppose these headlines make good copy (they certainly caught my attention) they don�t really reflect the good intentions of anyone attempting to create a standard.


Standards allow support groups to maximize the efficiency of limited budgets. It would be incredibly na�ve to believe that any IT department can provide a consistent level of competent support for every device, operating system and application available to a credit card crazy consumer. The alternative is to zero in on a handful of products devoting all our energies to their support.


 �Zeroing in� poses a challenge, how does a support group decide which products to support? How do we create standards while minimizing the wails of anguish?


Just have some FAITH.


Future growth: Regardless of what you chose, does it have a chance of meeting those ill-defined future needs? Remember the early competition between IBM PC and the Mac? The IBM PC had several expansions slots, the MAC had none (one in later models). What would we use those slots for? Who knew? But we knew one thing with a certainty. A device with fewer slots was less flexible than one with more slots. We chose the IBM PC over the Mac for this reason more than any other.


Integration issues: How well do the different alternatives under consideration fit into the context of existing technologies and services? The closer the match, then the more reasonable it becomes to standardize on that alternative.


Acquisition cost: This is a one time cost. It�s incurred once and usually pales next to ongoing support and integration issues. Never the less it is something that figures strongly in the standardization process.


Training issues: Ultimately the purpose of standardization is to make the user�s life easier NOT that of the support team. A user community will resist any difficult to learn product, regardless of how glowingly you paint the future benefits.


Handholding cost: (If FAITS was easier to remember than FAITH then this would be labeled �Support costs�.) What will it cost to support this product into the future? Which is �easier� to support?


Look at these five issues and ask what happens if you�re attempting to support a dozen different products. You�ll notice that training and acquisition costs only increase incrementally as you add products. It�s the future issues, integration and general support costs that skyrocket out of control when you try and support the world.


Standardization is one of those management strategies that make so much sense, everyone sees the benefit.


So? In the interests of good management we should go through the FAITH analysis, decide what�s best and then announce our decision. Right? Wrong! Do that and you�ll create more problems than you can possibly handle. In the resulting firestorm of office politics, you�ll be lucky to keep your job. Imposing standards this way, is almost impossible, despite our best intentions when we attempt it.


The trick is to work through the FAITH process with those who will be affected by the final decision. Every decision has a cost associated with it. You could provide the highest level of support for all products if you had an unlimited budget. If users understand all aspects of the FAITH process, if they understand the consequences of choosing one standard over another, then they can, will and do make the decisions that serve them best.


Of course there�s a catch. If IT has a built-in bias that has nothing to do with the FAITH process, then handing the decision of standards to the user will thwart that hidden agenda. A question IT always has to ask themselves is - Are standards intended to serve us or our users?


Peter de Jager is a speaker, writer & consultant. Contact him via [email protected]

Return To Help Desk & ITIL Papers

Back to Main Page


Help Desk Software Papers

Copyright © 2003