% fortune -ae paul murphy

Questioning IT

This is the 13th excerpt from the first book in the Defen series: The Board Member's IT Brief.

There are, very broadly speaking, two main approaches to managing IT open to board members and senior non IT executives. In the first of these you ask no difficult questions and simply trust IT, your auditors, and other managers to do their jobs. In the vast majority of cases this works well for fairly long periods of time - but there are exceptions.

In most cases these exceptions follow a pattern: a problem develops in the way information systems works in the organization; other managers either work around these issues or take advantage of them; a majority of the most senior people become increasingly isolated as the reports they get diverge more and more from what's really going on; and a board member or senior executive who catches a whiff of what's going on quietly decides that rocking the boat would expose him to personal hostility or liability and either leaves or just shuts up and hopes for the best.

Sometimes the results are public: at MCI and Enron criminal charges were eventually laid; and sometimes they're not: Boeing took almost a decade to recover from a strategic systems error (adopting Microsoft client-server and software from an Airbus subsidiary), and both operating and regulatory problems at Motorola and Nortel today (spring 2008) seem traceable to late ninties strategic systems failures.

Rule 0: for IT: trust - but verify

The bottom line is simple: whether you're a board member or the CEO the right answer when it comes to IT operations is trust - but verify. Ask the hard questions - and if you don't like the answers first get outside help to understand who's really wrong; and if it's not you, then either get changes made or resign - and do it loudly.

So what are the hard questions? There are two sets:

  1. those associated with opportunity cost - the cost of not doing something the organization should be doing; and,

  2. those associated with operational risk.

Opportunity costs

The opportunity cost issue questions whether the expectations your organization has about how its information systems work are the right ones.

There are two big problems with this: the issues this raises tend to be very hard to pin down - and trying to do so will antagonize both those with strong interests in maintaining the status quo and those with different change agendas of their own.

As a result the most common response to the opportunity cost issue is to do and say nothing: to avoid rocking the boat by arguing that you have what you have, and that there's no compelling value to either you or the organization in thinking about changing any of it.

The problem is that the opportunity cost issue strikes directly at the heart of the director's role: as either a board member or a senior executive you have a duty to carefully consider the hard questions and, if necessary, take the heat that goes with raising them.

Note that I'm not suggesting that you rush off to upset any IT applecarts in place in your organization, only that it's important to look both cynically and carefully at what your IT people either are doing, or or could be doing, and then draw your own conclusions.

Operational Risks

The operational risk issues are much easier to deal with, largely because they all relate to aspects of information integrity: the legal and moral risks and responsibilities you undertake simply by being in business.

As a board member (or senior executive) you'll get audit briefings on these issues but as a general rule you'll find these pretty upbeat and professional - meaning that they tend to see disasters clearly only long after the players have changed - and that's not what you want: you want to get ahead of game.

To do that, have some casual conversations with managers both from IT and from user departments or groups. In these you'll want re-assurance on three main topics:

  1. Disaster avoidance - not disaster recovery, although that's the usual term and the usual process. You recover after a disaster, but the smart goal is always to avoid the disaster.

  2. Second is all the stuff associated with rights to data and your organization's responsibilities with respect to data custody and process execution.

  3. And, finally, you get into mushy stuff: understanding the human relationships both within your systems group and between them and their main customers - the rest of your organization.

Notice that cost isn't one of the key issues here - IT cost is both relative to the technologies you use and a consequence of effectiveness: the less effective your IT infrastructure is, the more it will cost relative to what others pay for having made similar technical choices.

That most dreaded of all IT phenonmena - the skills/tech mismatch

Notice too that the most common source of IT problems - a mismatch between the technology in place and the skills available to operate it - has obvious consequences in all three conversational groupings.

Basically if your organization or large project relies mainly on any standard technology, but the IT services promised are often unavailable or bouncing "up" and "down" like yo-yos, your users have quietly implemented work arounds for systems reliability or performance issues, and IT is hiring consultants or otherwise expressing an inability to achieve the expected results with the technology they have, the chances are good that you've in the late stages of a technology -- skills mismatch disaster.

There's a quick bottom line to the technology- skills mismatch: parts from a steam locomotive just do not work in a jet airplane, Windows skills don't carry forward to Linux, mainframe skills cause Solaris to fail. Solaris skills work with Linux or MacOS X, but not with Windows or the mainframe. If you've got a skills/tech mis-match, then you have to change either your technology or your management.

Thus the only question to discuss with your CIO in this situation is which one goes -and if he tells you otherwise, point at the results he's getting and make your decision accordingly.


Some notes:

  1. These excerpts don't include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

  2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

  3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.