A lot of my correspondence comes from people who think their employers should do more — or at least anything — to make their workplace more enjoyable and fulfilling.

They’re right. The correlation between treating people well and a higher-quality workforce is not exactly controversial, and even with a cooling economy good employees have no trouble finding other work.

When the shoe is on the other foot, though, a lot of you seem far more interested in keeping your headaches to a minimum than in creating a quality work environment for everyone else in the company.

Yes, it’s mailbag time here at the IS Survivalist Institute, so we’re going to defer our continuing exploration of the integrated IS plan until next week. This week we’ll deal with the mail I received following my column describing how IS botched the introduction of the PC and still hasn’t learned from its mistakes..

The mail I received split demographically into writers who lived through the introduction of the PC and agreed with my recounting of events, and those who didn’t and didn’t. A question: If you weren’t there, how come you’re so willing to disagree with eyewitnesses?

To those readers who pointed out that as company resources, PCs shouldn’t be under end-user control, you make a good point. And since that desk you’re sitting at is a company desk, you won’t mind when internal audit goes through your drawers, file, and interoffice mail on a regular basis, will you?

Besides, IS often causes far bigger problems than individual end-users. When it’s your installation, though, you blame the vendor instead of accepting responsibility for poor planning and testing. (Yes, vendors could make it a lot easier, but they don’t. Deal with it.)

The mutual finger-pointing that goes on between IS and end-users starts with you blaming them. If Dell can build millions of PCs to order, you can do better than delivering a one-size-fits-all minimalist PC configuration and then complaining when employees individualize their systems. Here’s the program:

1. Segment your user community: Talk with a wide variety of end-users and their managers, and define five to 10 logical groupings, such as basic users, travelers, power users, mentors, and heads-down data entry staff.

2. Determine work habits: You may be surprised at the complexity. Consultants, for example, sometimes have network connections, sometimes use modems, and sometimes connect to client networks. If you don’t carefully craft an appropriate work environment, they’ll be in Network Neighborhood every couple of weeks. And you’ll blame them for goofing up their systems.

3. Determine resource needs: For each logical grouping, draw a picture with a member of the group in the middle. Around the periphery draw the resources they need access to. Then figure out how they’ll get that access.

Don’t assume. Ask — and be prepared for surprises. That group you thought was a candidate for NCs may not be, for example, because they send and receive e-mail with Microsoft Office attachments. Don’t argue, either. For example, I refuse to use Outlook as my personal information manager, because I rely heavily on Ecco Pro’s outlining capabilities. I’m willing to use something else, but not to give up capabilities I make extensive use of. Don’t argue: I know how I work better than you do.

4. Plan configurations: Tailor standard configurations for each group. Design them. Show them to group members. Test them. Assign people in your group to try them on for size. Push, poke, and stretch them. Find out where they break and where they develop DLL conflicts. Fix what you can fix and train the help desk on what to expect.

5. Roll them out: You have some retrofitting and training to do, so plan the roll-out carefully to minimize disruption. This should be fun, though, because almost without exception you’ll be improving employees’ work environments in a recognizable, tangible way.

6. Keep it current: Review your standard configurations at least annually to see if there’s anything you need to change.

Sound like a lot of work? Maybe, but it’s both less work and more rewarding than responding to the problems and complaints you get now.

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.