Evaluating strategic IT plans
This is the ninth excerpt from the first book in the Defen series: The Board Member's IT
From chapter 2.3 - The strategic plan
The IT strategic plan is often a budget document in disguise; if so, send it to the Finance committee first.
Good IT strategic plans of the kind that warrant board attention say:
- here's what we do
- here's how IT currently helps us do that
- here's what's wrong with the status quo
- here's what we expect to be doing in the short, medium, and longer, terms
- here's how our present IT infrastructure fits with that
- here's what has to change
- here's how we propose to make those changes happen
- here's how we'll ensure that the change doesn't destroy the business
- here's "plan B" for if, or when, implementation goes wrong
- here's what doing it all will cost; and,
- here's how IT costs and benefits to the organization now compare to expected IT costs and benefits after the
In other words, there's a detailed review of what the organization currently does, how IT supports that, and
what the limitations are - followed by a lot of guesses about future needs, future technologies, acceptable
change, and future costs.
In practice most strategic IT plans either, or both, over-estimate the user community's willingness to
change, and/or prove absurdly optimistic with respect to the implementation of a new technology.
As a result most strategic plan implementations falter on one of two conditions:
- the people who cheerfully signed on for business change during the planning processes silently recant as
soon as the reality affects them. Basically, good plans represent compromises - agreements on whose oxen get
gored - but the realities of implementation often cause people to rethink support for those compromises,
thus leading them to sabotage the plan.
A business manager may, for example, agree that he needs better information - but refuse to access it when
it becomes available.
- a new technology may prove inadequate to the task - although that's actually rare. Far more commonly, the
people deploying or using the technology don't change their behavior to accommodate the new realities
brought in with the technology and thereby cause the failure.
A mainframe manager, for example, may agree to bring in a major Unix server but then completely fail to
internalize the reality that the procedures and other tools he relies on to manage his staff and budget
don't mesh with the new gear, and therefore cause unnecessary cost, complexity, and failures when applied to
the people responsible for keeping it running.
When you look at a proposed strategic IT plan the most important questions to ask yourself as you go through
- is this a strategic plan at all? In other words is this board business or is management trying for an end
run on a multi-year IT budget increase, just wasting your time looking for cover on something they're
already doing, or trying to make you responsible for falling into a hole they've dug for you?
- is this an out-sourcing proposal? If so, are your IT needs sufficiently generic that you need no customized
control over your data or services, are reasonably immune from pricing change, and can repatriate processing
at the drop of a contract dispute? In other words, does out-sourcing make sense or is this just senior
management's easiest way of firing an IT department that's not meeting expectations?
- how good is the picture of your organization's present business and IT structure? how good do you think
their future picture is?
- you know (or should know) the key managers involved on the user or business side of this. How supportive are
they going to be when it's their ox getting gored and delays set in?
- have legal constraints on change been considered? does the change put your ability to meet one or more legal
obligations at risk? (An ERP technology transfer could, for example, put your organization's ability to meet
contractual financial reporting or partner access obligations at risk).
- suppose it all works exactly as predicted in the plan. Will the organization really be better off?
- have external factors been considered? For example: is your organization affected by IT decisions made
elsewhere? how rapid is turnover among users? and how that does that relate to IT training provided in the
plan? Does your organization actually have the ability, the independence, and the commitment to affect real
- is the communications and support strategy in place and fully adequate? i.e. is there a clear executive
commitment, supported by tools such as a website with a frequent update commitment, a newsletter, and/or a
clearly announced meeting series, to ensuring that all concerned see continuing executive support for the
plan, see the plan unfolding, and are encouraged to get, and stay, behind the change?
- is the staffing plan appropriate during and after the proposed information architecture change?
If you have Microsoft's Windows client-server architecture installed and the plans says you're going to do
more of this, you don't need staffing change in IT, but this isn't a strategic plan either.
If, on the other hand, you have Microsoft client-server and the plan says you're going Solaris/Sun Ray, your
staffing plan better talk about putting some very different people in charge, retraining a few existing
grunts, and laying off a majority of your IT staff - because you won't need them, but your current staff
won't want to know that.
- What's "plan b" - the rollback and recovery option to be called into play if, or when, the primary plan
implementation process grinds to a halt, proves impractical, or simply starts to look too risky?
- is the technology plan really consistent? i.e. there are no obvious Apples and Oranges at the hardware,
staffing, or application levels and the proposed applications are internally different from each other only
where they need to be.
- Who's responsible? and how is that responsibility enforced? Consultants are bad news, internal staff with
inappropriate expertise are worse news, project managers who want to become consultants or supplier staff
are worst of all. Who's in charge? and what parts of his anatomy are on the line if, or when, things go
Both developing and evaluating a good strategic plan is hard. In both cases the major risk is that you will
inadequately assess the impact of change and the potential for catastrophe.
Remember: it's true that the plans themselves are usually about technology, but the implementation will be
almost entirely about people.
- 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).
- 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.
- 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