We live in the information age, or so I’m told. We’re bombarded with the stuff — it’s kind of like cosmic rays in that respect — and we’re spending an ever-increasing amount of time and energy dealing with it all.

I’m not at all sure we’re really living in the information age. Information is defined as the stuff that reduces uncertainty, and most of what I’m bombarded with is marketing material, political speeches, redundant stories generated through the process of herd-journalism, and overheard descriptions of what was on Jerry Springer last night.

Information age? There’s little that reduces uncertainty. It’s more the age of noise. Whatever it is, though, it isn’t the decision age, which is why most IS Strategic Plans produce three-ring binders that sit on the shelf gathering dust.

Since June, in fits and spurts, this space has presented a framework for an integrated IS plan. Not a strategic plan, but an integrated plan. The difference between the two is that a strategic plan ignores the day-to-day realities of leading IS. Why bother?

An integrated IS plan describes what you’re really going to do next year (and further in the future), putting your strategic goals and how you’ll survive until the future gets here in a single context where they don’t compete for attention. Since it describes what you’re really going to do, it presents decisions, not just information.

To recap, we began by exploring and documenting the company’s strategic, tactical, and infrastructural goals, presenting them in the context of the programs that will be needed to achieve them. We then reviewed your technical architecture to determine how it needs to be reinforced, improved, and extended so as to support the programs defined in the first section.

Now it’s time to take on those pesky human beings who work for you and who will be doing (or failing to do) all the work. In several upcoming columns we’ll review the topics you should cover in your integrated plan.

The human dimension — the human factors plan — divides into three sub-plans, covering processes, leadership, and organization.

Processes are how people get work done. No, that’s too facile. Processes, or at least the ones you care about, are how people do repeating work — stuff they do over and over again. Your process plan lists the key work of your organization, identifies which processes you most need to define or improve, and sets the basic direction for how you’re going to improve them.

Leadership sets direction and gets people to do the work. Leadership establishes goals, holds employees accountable, makes sure they have the right skills, energizes them, makes sure they’re fairly compensated, and otherwise deals with their needs as individuals. A lot of the work done in IS happens outside the boundaries of defined and documented processes, so a key role of leadership is creating an environment that encourages employees to figure out how to deal with situations as they arise.

Then there’s the ever-popular organizational design. You have to have one, I suppose — employees need to know to whom they report and who is responsible for the various kinds of decisions that have to get made. The main role of the organizational chart, though, is to define what my work isn’t. Designing your organizational chart comes last, and it should be pretty obvious once you’ve figured out everything else. The two most important things you can do with your organizational chart are to (a) focus attention on everything else; and (b) don’t change it any more often than you absolutely have to. Improving your organizational design doesn’t do all that much to help people get work done, but reorganizing creates lots of barriers.

Sounds like a lot of work, doesn’t it? Creating a coherent plan that hangs together is a lot of work. That’s one reason empowerment is important. The more time you spend planning, the less you have for important decisions like whether Joan should be allowed to get a new mouse for her three-year-old computer.

But we’re getting ahead of ourselves. We’ll get there, but first we have to talk about processes … and that’s what we’ll do next week.

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.