Peter de Jager is a provocative Speaker,
Writer and Consultant. His primary focus in on how we manage change,
technology and the future.
In addition to speaking at conferences
worldwide, he also writes monthly columns for CIO Magazine and
His goal is always to question what we
think is so, and in so doing perhaps open up new opportunities.
If you'd like permission to reprint any
of Peter's articles, please contact him directly.
You can contact him at
Or sign the Guest
Book and he'll get back to you.
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" is the headline of an article at www.internetnews.com. At www.chipzilla.com the headline is "Walt Disney bans every PDA but two."
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.
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.
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.
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 – Peter is passionate about change, how it affects both
individuals and organizations and allows them to grow and prosper. To contact him, and
host internal seminars on Change Management visit www.technobility.com
reprint permissions click here.