According to my daughters I have a bald spot the size of Jupiter. They delight in informing total strangers of this – a major source of glee. They are, of course, the primary cause of my scalp’s increasing visibility. Knowing this hasn’t instilled even a slight level of guilt, I’m sorry to report, but it has increased their interest in Rogaine ads.

Even before I had kids, though, I’d started down the hair-loss path. It was responsibility for allocating IS resources that started the follicle damage.

This is the third article in our occasional series on creating an integrated IS plan. The last two talked about linking to your company’s strategy. This week we’ll help our companies survive until the future gets here by dealing with tactical issues. (As we’re using the terms, strategy changes the company’s business model – how it thinks about its products, customers, processes and how they interrelate. Tactics, in contrast improves how it accomplishes its current business model.)

At a tactical level you deal with two basic questions: What projects will most improve the company’s core business processes, and how should you allocate resources to get them done?

I’ve seen four basic ways of answering these questions. One is really stupid – make all the decisions yourself in a vacuum and inform the rest of the company what you’re going to do this year. If that appeals to you … well, it’s been nice having you as a reader, and best of luck in your job search.

The first good way to set priorities is to form an IS Steering Committee – really, the heads of your company’s business units, meeting to agree on the company’s IS project priorities and resource allocation. Your role is to set the agenda and facilitate the meeting; their role is to make the final decisions. If everyone agrees to this approach it simplifies your life, because who’s going to argue with what everyone signed up for?

IS Steering Committees also help you reserve resources for strategic projects, and help integrate projects so the company gains maximum advantage from its investments in information technology. When you can make them work, IS Steering Committees are the way to go.

IS Steering Committees fail in two circumstances. The first is entirely your fault – if you miss some significant projects, the committee will allocate all your resources without accounting for all the work you have to do. Solution: Don’t do that. Ask your leadership team to participate in setting the agenda and you’ll get it right.

Here’s the second reason IS Steering Committees may not work: Sometimes a company is too diversified, lacks a strong enough focus, or is too politicized for the group to come to consensus. You can’t control this, but you need to be savvy enough to predict it – don’t form an IS Steering Committee if you don’t expect it to succeed.

If this is the case, go to Plan B – proportional resource allocation. Under Plan B you allocate your developer and maintenance IS headcount to the business units in proportion to their headcount, budget, or political importance. You then work independently with each business unit head (or, one of your managers works with each of them) to figure out the projects each group will work on. If a business unit wants more than you can provide with the resources you’ve allocated, it’s free to allocate some of its own budget so you can hire contractors or additional staff, or to sponsor an IS budget increase.

Be careful of Plan B, though, because it can turn into Plan C in a heartbeat. Plan C is to break up IS, distributing it among the business units. And although this occasionally makes sense, especially for very large, diversified conglomerates, it pretty much relegates IS to a tactical role, because strategic projects rarely respect current organizational boundaries.

Someone once said that insanity is doing the same thing over and over again, expecting different results.

Of course, when you use Windows, doing the same thing twice really can lead to different results, so what does that tell you about our industry?

One of the things we seem to do over and over again in IS is waste a lot of time in studies that never get used. IS strategic plans are a popular example.

Don’t get me wrong. IS needs a plan, and that plan must include strategic considerations. It had better include more than that, too. A “strategic plan” is only about achieving strategic direction, ignoring the practicalities of day-to-day operation that absorb all of your resources and more. Put simply: It’s a castle in the air you can never build.

That’s why you need an integrated plan. An integrated plan includes strategic components — it defines the future — but also deals with the realities of your current operating environment. An integrated plan gives you a roadmap for where you’re going, and it also helps you survive until the future gets here.

You can operate without an integrated plan, but then IS becomes an order-taker, providing nothing more than a lot of unfocused activity that solves small problems without moving the company forward. Your projects may be well worth doing, and may generate a lovely return on investments, or ROI. Best of all, they’re safe. They just don’t change the status quo in any meaningful way.

This week starts a series that gives you an outline for your plan. It isn’t, however, an instruction manual. That would take a book I haven’t written yet.

An integrated IS plan has three main sections: Company Goals; Technical Architecture; and Human Factors. The Company Goals section documents where the company is going and the role technology will play in getting it there. Technical Architecture describes the whole corporate systems framework to be used. And the Human Factors section deals with … well, the people who will make it all happen.

Let’s zoom in on the Company Goals section. It divides goals into three subtopics: strategic, tactical, and operational.

Strategic goals describe a significant change to the company’s business model. They call for the delivery of new capabilities by IS to not just enable, but facilitate, the change. You’ll never demonstrate a return on investment for projects that address them, by the way. In all likelihood, the company itself hasn’t tried to demonstrate a return on investment for achieving its strategy.

Tactical goals make your company better at its core business processes. Satisfying these goals lets your company do things faster, cheaper, or with higher quality, so they generate a solid ROI. Nothing fundamental changes, though. You’re still the same company making the same stuff for the same customers.

Operational goals deal with the company infrastructure … in systems terms, the telephone system, e-mail, and word processing software that is used throughout the organization for a wide variety of general office tasks. It’s plumbing, invisible until it breaks. If you want to sponsor unified messaging technology, here’s where it fits into the big picture.

You aren’t a passive recipient of the company’s goals, for two reasons. First, they’re never expressed in a form you can use — you need to apply a lot of insight to turn the company’s strategic, tactical, and operational goals into IS departmental requirements.

Second, you should actively participate in their formulation, because technology, more than any other single factor, drives the external changes that will make your company’s current business model obsolete. And who on the executive team knows more about the future of technology than you?