So, Paul Murphy got me thinking with his recent post challenging the conventional wisdom of making feature comparisons when judging open-source versus Microsoft applications. Or, actually, a subsequent commenter who leveled a challenge to him as to the efficacy of adopting many specialized programs versus a large, monolithic program which itself embodied all the features of the others (only the commenter used much worse grammar and spelling... but I believe that was what he was getting at).

My reply, to the challenger, was:

You can use an M1 tank to go grocery shopping. But it's certainly not the most efficient way to do it. You're conflating productivity with singularity, which is just silly. There are a lot of tasks you can do more easily in Writer than Word, even if you can't do as many. So you're saying you should stick with a program that is more complicated and difficult to use for 90% of your day to day tasks just because it can also do that 10% that you perform once a month?

That's not even the most common situation to be in. Typically, the bulk of the users in an organization only ever use a small fraction of Word's capabilities; only a few power users ever get into the more advanced features, and would be served just as well, every day, by Writer or similar. So it's more efficient for the organization to equip workers according to their task, isn't it?

But not so fast. Turns out that increasing the number of applications in an organization is one of the key factors in increasing the support burden and IT staffing costs. From a support perspective, it may well be cheaper to just run Word for everything. When you extend that logic to the entire Office suite, you increase the savings... one mouth-breathing MCSE has all the fundamental knowledge to support the whole package without having to go out and learn anything novel or new. Take that same MCSE, ask him to support Office, OpenOffice, Abiword, Google Docs, etc, etc, and he suffers brain melt and suddenly needs an assistant or a pay raise (as he has just become a Unix administrator).

It's not exactly conventional wisdom that driving down application numbers drives down support costs, but among those who bother to study such things, it's generally accepted as fact. I doubt that is actually what drives most organizations to select Office, of course; they do it because everyone else does. Were they to attempt to abandon it and move to a flurry of free, open-source alternatives, though, I think they may well run into that particular challenge.

Murph has an answer for this, too, though:

However.. what actually happens when you deploy specialized tools is that the users form their own support groups - so the sysadmins never acquire "help" functions for the specialized tools.

While this has certainly been true in some organizations I have worked with, in others it hasn't developed that way. But when it does, it's probably more efficient than having IT develop the expertise for a relatively limited pool of potential support candidates. The real challenge from the IT perspective, I think, is in letting go of the need to have all the expertise "in-house" or at least be seen has so having, and in fostering the user to user support function in some official way which doesn't step on outside managers' toes. Few non-IT managers want to see their staff spending time on it support tasks, anymore than CIOs want to see their techs adding up columns of numbers or doing gardening work.

In point of fact, I've never seen user-to-user support formalized to any degree greater than an in-house wiki or something similar, so now I am curious: does anyone out there approve of and put together such a thing?