This is the fourth excerpt from the first book in the Defen series: The Board Member's IT Brief.
Three kinds of IT proposals come to the board for decision:
These come to boards through two kinds of processes:
The stealth approach, in which something that isn't an emergency issue referred to the board by a committee head or the chairman, first comes to the typical board member's notice as a hopefully entitled agenda item like "Approve Web Services Expansion", is fundamentally inappropriate.
What management is usually looking for in a situation like this is pro-forma approval: legal cover for their actions. In the United States giving it to them without learning a bit more about what's going on then you're likely to get in the basic presentation isn't going to meet your legal responsibilities -and in the rest of the world it won't meet your fiduciary responsibilities either.
You see this kind of thing a lot, but it usually represents someone's attempt to end run the board and should generally be quashed. The right process starts when either the board as a whole or a qualified committee authorizes the work leading to an eventual presentation calling for a yea or nay ruling by the board.
That prior board or committee authorization is the time to separate the strategic decisions from the merely tactical. Rule 0: Tactical decisions aren't worth your time For a decision to be strategic, and therefore worth board time, it must have real organizational consequences.
Decisions to do more or less of something the organization is already doing routinely represent tactical choices, as do decisions to change suppliers or methods within an existing information architecture. As such they're in management's purview, not yours.
Thus if you find management repeatedly bringing you decisions on things like changing suppliers for standardized IT services like PC help desk support, you should ask yourself whether there might not be some deeper governance issue at work.
A lot of volunteer agencies, for example, have grown large enough to maintain professional management while retaining the appearance of volunteerism at the board and fund raising levels. In these, bombarding the board with essentially pointless brand A versus brand B decisions is often management's easiest way of ensuring the board's irrelevance with respect to the real strategic decisions driving the organization - decisions they're inappropriately abrogating to themselves.
Rule 1: it's easier to criticize than propose, but some risks are worth taking and some worthless proposals contain gems
Before any board level IT decision comes up you should receive an advance information packet describing the objectives, recommended methods, and expected costs of both the decision management prefers and at least the do nothing alternative.
In evaluating those it's important to start from a negative perspective while looking for things you can support in the proposal. This sounds conflicted, and is, but "Rule 1" reflects a simple but brutal truth: most IT proposals are deeply flawed, and it's just far more efficient, and less frustrating, to weed those out early. At the same time, however, even the worst proposals often contain gems - low risk things of real potential value to the organization.
Equally importantly, I think there's a responsibility to sometimes say "Yes." That may seem odd too, but one of the problems with IT governance is that simply saying "No" to everything, especially if you lose most votes, will eventually earn you a reputation as a tremendously effective judge of IT projects --because almost all fail to meet at least one, and usually two or three, of the usual criteria for success: on budget, on time, and "meets user expectations".
The hidden message here is that IT appears to be about technology but is really more about people. Good people working in supportive environments can make miracles happen regardless of the technology available to them - but it's your job to focus on the human issues that dominate governance, and one of those issues is your own role in creating and maintaining the needed "supportive environment." So by all means attack bad proposals with gusto, facts, and determination; but make sure you also take the time to find ideas, and people, to be positive about.
In a perfect world the person you put in charge of IT will keep the board informed throughout the process leading to a request for decision. If the decision involves significant strategic risk that involvement should have depth - a real commitment to understanding, and incorporating, board level concerns before developing the recommended action plan. If, on the other hand, the project is sufficiently important to warrant board attention but involves little overall risk to the organization, a few informal briefings will usually suffice.
Rule 2: The slicker the pitch the steeper the slide to disaster - so break away to talk to those who do, not just those who talk.
Either way, who gets the face time with you during the entire process gives you an important clue as to how the project is likely to end. In an ideal world you will hear, during the pre-decision briefings and interviews, from the junior staff directly involved in researching the options. When that process matures and a board decision is finally called for, the ideal CIO should say something like: "I support this, I think it'll be good for the organization, and I'm fully prepared to wear the consequences; but Joe here dreamt it up and did most of the research, so with your permission I'd like to ask him to talk about it."
That's the ideal, but it's not what usually happens. Instead you normally get what I think of as the "craven clutch" - a couple of senior IT people and/or their consultants who are far more interested in budget and span of control issues than in technology or your organizational success.
In the worst cases your own CIO will hand over to an outsider, a consultant or supplier executive who does the actual board interviews and briefings, including the final presentation.
If so, this is likely to be an extra-ordinarily gifted salesman capable of delivering a polished presentation and appearing totally in control of the facts when asking or answering questions. Unfortunately, it's usually an empty facade. Every big IT services supplier has its closers - the people they send out to do board level interviews, briefings, and presentations like these; but they're sales people, not IT people.
Such people are simply far too valuable to waste their time actually doing IT, really studying your business needs, or meeting one on one with those of your people who will have to make this thing, whatever it is, work. All of that is done by their juniors, who then brief them on the way to meetings but aren't invited to speak because they're techies, and both the senior presenter and your own IT guy, who's introducing him, are afraid they'll blow the sale with too honest an answer if allowed to speak.
The guy they front, however, probably looks, acts, and sounds just like you would if you had time to read a good tech guide - he's got the charm, the savoir faire, the contacts, the soothing words and social skills that go with being a board member. He's one of you, he fits right in, and he's very effective. That makes him extremely valuable to his employer, but dangerous to you. What you need is a good techie, and he might once have been one, but now he's fallen victim to his own promotions.
The rule to remember here is simple: the longer and more impressive the guy's resume, the longer it's usually been since he's done any real hands-on work and therefore the further out of touch he'll be with respect to current technologies and current means of meeting your organization's needs, and - most importantly- the longer the resume, the shallower his judgements will be about your organization.
Remember: he's not compensated for, or interested in, getting the job done, he's just compensated for, and therefore interested in, getting the job.
The answer, right from the initial briefings forward is simple: always speak directly to the real players. There will be people in your IT group who're deeply involved: find them and listen to their concerns. There will be people in your user community who are deeply involved (if there aren't, cancel the project early): find them, and listen to their concerns.
This is usually easy if your board represents something small like a community theatre because the players are in one place, formal barriers are minimal, and nobody's career is at stake. It's a lot harder in a big company or government agency where just finding the people may be hard, travel may be required, and lots of heavyweight organizational players will feel seriously threatened by your interest.
Ignore them. How hard, how easy, or how acceptable or unacceptable, an action is socially doesn't affect whether it's right or wrong - and speaking directly to the people on the front lines is always right.
In a big organization, you'll have a research capability and budget: use them, but take the time speak to some of the junior players yourself. Remember: the more barriers your systems management throws up, the more suspicious you should get.
Rule 3: buyer beware, but keep a sense of perspective
The general rule in buying anything, of course, is "buyer beware." In the particular case of IT project proposals, bear in mind that just about all significant IT projects fail to meet expectations with respect to one or more of budgets, timelines, specifications, or performance --but that essentially 100% of IT resumes report nothing but the outstanding success of every project the hero of the piece has ever been near.
Some truths don't sell, and therefore get elided. The resume bragging about the hero's contributions to a brilliantly successful SAP implementation isn't likely to mention that he was laid off when the thing was cancelled - and you won't hear a discouraging word from the reference who planned the project, hired him for it, and survived the ensueing debacle either.
In IT failure is the norm, but it is always someone else's fault.
Some lies sell, and therefore get widely used - there's a multi-billion dollar industry, for example, selling third party Windows security products.
Some lies are wink and nudge accommodations to stupidity. It's common, for example, for governments and others to require that temporary staff (aka consultants) have at least three years of hands-on experience with whatever technology they're being brought in to help with - even if it's brand new - and the consultants, of course, routinely sign off on this.
The bottom line is simple: in IT everyone lies, but you have to understand the source of the lie before you can decide whether it matters.
Rule 4: If the expertise doesn't match both the problem and the solution, the project will certainly fail.
But some lies do matter, especially the really big ones and, in IT, the biggest lie of all is that a computer is a
computer is a computer. Specifically, that expertise earned working with one information systems architecture applies
to all of them.
This is widely accepted, but absurdly wrong. If Dick and Jane are two systems experts with differing views on a
technical issue, those views will reflect what Dick and Jane are absolutely certain they know about using computers
and therefore the differences in the forces which shaped their opinions.
In most cases these differences, if they were clear to you, would seem technical and of minor importance relative to
their managerial skills and understanding of the business - but experts see and fight over differences where
outsiders see only commonalities, and just as the protagonists in racial or religious wars are usually willing to die
to perpetuate differences that are invisible or unimportant to outsiders, so too will Dick and Jane unknowingly
sacrifice your business to the unalterable certitudes imposed by their backgrounds. In fact, expecting Dick's ideas
to work with Jane's technologies, or vice versa, will predictably have roughly the same effect as hiring a Catholic
principal for a Protestant school in Belfast.
There is no such thing as generic IT experience. Experience pertains to an IT environment, a particular information
architecture: put a Solaris guy in charge of a mainframe and you will get an organizational disaster- just as you
will if you let a Windows guy run a Linux shop.
Remember: each technology community is defined by the management methods that it has evolved to fit its unique
combination of opportunity, history, technology, and applications. Put someone from one community in charge of
technology from another, and the knowledge he brings with him will be disconnected from the technology in use
-meaning that almost all of the things he is least likely to ever question, will be wrong.
Thus Rule 4 is critical: for any strategic project: if the expertise doesn't match both the problem and the proposed
solution, the project will fail. No ifs, no buts, no maybe's: it's guaranteed.
Rule 5: ignore the cost and benefit numbers, but look cynically at the issues and periods they apply to
Every project proposal comes with some estimate of costs and benefits. These are guesswork; don't take them
seriously. Instead, look first at what the cost numbers focus on, and secondly at the time periods the benefits apply
to.
Projects that are important to IT people, but not the organization they serve, are often characterized by a lot of
detail on capital and deployment costs within IT, and the absense of comparable detail with respect to user costs and
risks during installation.
There are exceptions: small project proposals may consist of little more than a plan to buy some hardware or software
and make it work, but projects like that usually aren't worth board time either; and, of course, smart consultants or
IT staff can make a resume builder project look strategic - so remember rule 3: buyer beware.
What you're fundamentally looking for in your evaluation is realism. It's perfectly reasonable for the plan to say
that costs to users are unknown, but they have to be acknowledged - and that's true across the board for lots of non
capital costs. If you don't see that acknowledgement together with a real attempt to come to grips with both risk and
change costs, assume somebody has a nice fantasy life, but get more cynical about the project.
The same principle applies on the time horizon side of the initial analysis. Basically, if the time period for
benefit realization exceeds your board's stable planning horizon -just write the project off, it's either a total con
or hopelessly naive.
In general, the longer the benefit period, the more you should get concerned. Everything changes, the hardware and
software used in IT, cost structures, key staff, the tax and regulatory climate you operate in. Everything changes -
so how well do you think multi-year benefit projections are going to work out?
A good way of looking at this is to look backwards instead of forwards. If they give you five year cash flow
projections, get a proposal from five yeaars ago and see how well they did as forecasters then.
For example, if this is 2008 and they're asking you to approve an advanced XML document integration solution for
breakeven on cash in 2011, you're entitled to ask how their 2005 case management project is turning out. If that
still isn't working as predicted, and particularly if the failure excuse is "scope creep" (an IT phrase meaning that
they didn't get the requirements right and have been fighting users from the gitgo), you'll have no obvious reason to
believe today's effort will fare any better.
A lot of popular press articles, and even some serious academic analysts, will tell you that the more complex an IT
project is, the less likely it is to succeed; but this isn't true. In IT complexity is not, by itself, a determinant
of success: but duration is. The longer a project is expected to take to reach the point of technical and financial
success, the less likely it is to ever do so.
In other words, if the time period shown for either or both the costs and benefits section in the project proposal is
unrealistic, the thing is almost certainly a loser.
This, however, is one place where positive thinking can help. The right question may be whether the project can be
broken up into independently specified and implemented pieces that can be rethought as things change around them.
The even righter question, of course, is why IT management didn't do this before the project got to you.
Summary:
The rules for making decisions about board level IT issues are simple: start with rule 0 - question management if
they waste your time on tactical issues, and then apply the other five:
Some notes:
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.