Sabotage and the cost of change

One of the hidden costs of change is the cost of getting past antagonistic perceptions - and that cost means that change is often good for the organization but not worth it for you.

Once upon a time, not so long ago and in a province well north of most of my American readers, I developed a complete membership management update strategy for a provincial political party. The key to the plan was ultimately the replacement of the four part paper card issued to members with a plastic card that carried both embossed and magnetically encoded information, enabling it to be used as a combination identity and credit card at party events.

As part of this, information switching was going to come from an international bank (and member of the VISA consortium) then setting up business across western Canada and eager to build local connections - meaning that constituencies would essentially get free transactions support on everything from membership sales to dutch auctions while the party's crown jewels (its membership lists) would be secured by the bank for commercial purposes and by centralization on two Solaris servers at headquarters for non financial processing.

I thought it was all pretty cool, the demos went well, and the constituency people involved were enthused - but a couple of senior players at headquarters had bought into a relationship with a national client server development company that had them throwing out their Macs in favor of custom code development on Windows 98 and 2000.

Told by the board to print the cards for the first 1,000 member pilot, the guy they put in charge of the process signed a contract to take 100,000 cards, finalized the pre-print design, and ordered the first 1,000 cards - all without consulting us and in Portrait mode rather than Landscape; thus making the card unusable with any standard reader.

As it turned out, I had never specified that the card be printed landscape, and the guy who did the semi-final drawings had drawn it landscape, but put a "scale to fit" note somewhere - so that's exactly what they did in the nicest bit of obstructive sabotage I've ever seen.

What the story (which I've twisted a bit for use here) illustrates in the present context, I think, is that the real determinant on whether the cost of change is justified is what other people do with it once you put it into play- and that's often well outside your control.

It's obvious, for example, that most companies could easily change from Windows to Linux on their desktops - because everyone's terminal emulator: the web browser, works about the same on both and for most purposes Microsoft Office vs. OpenOffice is a case of tweedle dum vs. tweedle dee. Since doing it would generate savings on licensing and hardware while somewhat reducing security and reliability issues, the question to ask is why lots of people aren't doing it.

I think the right reason for not doing it is that client-server is client-server no matter which OS you run on the client, and so replacing Windows with Linux just exchanges one headache for another; but the more common reason is that your users and support troops will usually work together to sabotage this type of change.

As an IT manager you may know perfectly well that some function or other works better on Linux than Windows Vista but if the same users and support people who won't make it work on Linux - and therefore make a federal case out of its not working because of your incomprehensible Linux decision- are willing to silently accept continuous mediocrity as the Windows standard, what are you going to do?

In my case I gave up and waited for them to get shelled - and three years later most party members were indeed getting personalized direct mail from the opposition parties while headquarters was contracting for yet another round of Windows applications development.

And in the cases of most IT managers I know the attitude is just the same: "Yes" they say, "doing it makes sense, I could save some money, improve security, and do a few things I can't now - but I'd have to change a lot of staff and there are bigots out there who will fight this every single day until I leave and the next guy puts Windows back - so why bother?"

Since I think they're right, this means that the real cost of change isn't a measure of what it takes to make change happen, it's a measure of what it takes to make change stick over the long term; and that means including the cost of changing IT staff, of changing user attitudes, of rooting out hidden IT staff (user department staff who've stopped doing their jobs to become the local go-to people on "computer" issues) and educating new recruits to user communities.