% fortune -ae paul murphy

Evaluating strategic IT plans

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

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:

1. here's what we do

2. here's how IT currently helps us do that

3. here's what's wrong with the status quo

4. here's what we expect to be doing in the short, medium, and longer, terms

5. here's how our present IT infrastructure fits with that

6. here's what has to change

7. here's how we propose to make those changes happen

8. here's how we'll ensure that the change doesn't destroy the business

9. here's "plan B" for if, or when, implementation goes wrong

10. here's what doing it all will cost; and,

11. here's how IT costs and benefits to the organization now compare to expected IT costs and benefits after the change.

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:

1. 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.

2. 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 it are:

1. 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?

2. 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?

3. how good is the picture of your organization's present business and IT structure? how good do you think their future picture is?

4. 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?

5. 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).

6. suppose it all works exactly as predicted in the plan. Will the organization really be better off?

7. 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 change?

8. 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?

9. 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.

10. 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?

11. 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.

12. 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 wrong?

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.

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.