If you missed the news, the population just hit 6 billion.

That’s a lot of people. If we were all to lie down end-to-end on the ground, we would go around the earth about 2,600 times. If someone put us all in a swimming pool, packed tightly together like sardines or flying in coach-class, the pool would have to measure more than a quarter of a mile on each side.

Then there’s the Y3K problem: We’ll just about outweigh the earth itself by the year 3000. It’s enough to make you believe there are limits to growth.

Amazingly, with all these people to choose from, many IS hiring managers can’t find enough qualified applicants to fill their open positions.

We can’t solve everything at once, so today we’re going to focus on just one small part of the problem: the help desk.

For many of those running IS, the help desk is an afterthought. It isn’t strategic, executives don’t interact with it very much (and when they do they get special treatment), and it generates no measurable return on investment.

Let’s recalibrate. The level of trust and respect between IS and the rest of the business is pretty low these days. (I base this on a large volume of anecdotal evidence, not formal surveys; your mileage may vary.) Your help desk is, or at least should be, the most frequent point of contact between your organization and the employees whose trust and respect you need every time you implement new technology.

The first step in making sure your help desk increases that trust and respect is staffing it with people who can actually solve problems instead of simply dispatching a trouble ticket to a technician.

Except … Bob, you idiot! Haven’t you heard there’s an IT labor crunch? If we do find people like this, we have more important places to use them.

News flash: You don’t need computer science majors on the help desk. Chances are, they wouldn’t be able to figure out that the end-user has a notebook resting on one of the cursor keys anyway. Here’s who you do need on your help desk:

  • High school seniors: Sure, you’ll only get them for a few hours a day during the school year (more during the summer, of course). But who better to diagnose PC problems than someone who assembled a high-end gaming system from spare parts? You can pay a lot more than the local Taco Bell and still save a ton compared to those computer scientists you can’t find anyway.
  • College students: Yes, you’ll have to work around class schedules, and you’ll have to pay more than you would pay a high school student. Here’s the upside: You get highly qualified help desk analysts, still at low cost, and they’re all potential recruits when they graduate. After a year, you’ll know who you’re going to want to hire – offer them scholarships in exchange for two years as full-time employees when they leave college.
  • Internal PC mentors: These are the people employees call when they need help because they’ll solve the problem before your help desk would have finished writing up the trouble ticket. They’re already employees, they’ve already proven they can do the job, and many of them would love an opportunity to move into IS.
  • IS analysts: Rotate your analysts through stints on the help desk. Here’s what they’ll gain: humility (as they find out just how much they don’t know how to fix and how knowledgeable and sophisticated those dumb end-users really are); listening skills (because to fix problems they have to hear beyond the symptom to what’s really going on); a better understanding of how work gets done (they’ll see it first-hand); and, most important of all … they’ll learn what the rest of the company thinks of IS.

Staffing shortage? When it comes to the help desk, at least, we don’t suffer from a staffing shortage. All we suffer from is a lack of imagination.

Steven Wright once asked if shaving cream does anything at all beyond helping you keep track.

It’s a good question.

It isn’t just shaving cream whose only role is helping you keep track. Sometimes, that’s the role of the “repeatable, predictable processes” that so many of us high falutin’ consultants promote as the solution to every business problem.

Before we had process redesign we had Taylor’s “scientific management” and its time-and-motion studies, which tried to turn industrial processes into precisely defined repetitive motions. Beginning with the assumption that business works best when human brains aren’t involved in running it, scientific management led inevitably to repetitive stress disorder. Oops.

We’ve replaced scientific management with process redesign. According to the process perspective, “everything is a process,” a phrase I’ve heard often enough to make me want to argue, just out of spite. “My desk isn’t a process,” I hear myself retort cleverly while I watch ’em fold like pawn-shop accordions. “Neither is my car. Or my …”

“No, no!” they sputter, nonplussed. “We meant to say, everything you do is a process, because everything you do is a series of steps that gets you to the end result.”

Which is absolutely, true — everything you do is a process. Everything you do isn’t, however, a Process, a distinction process design consultants often fail to make in their zeal to craft high-quality-producing methods for achieving results. There are three big differences between processes and Processes:

1. Most of the intelligence needed to create the desired results has been built into Processes. In contrast, most of the intelligence needed to successfully follow a process is in the minds of the individuals following it.

2. The products of Processes have well-defined specifications; quality is defined as adherence to those specifications and can be objectively measured. A Process generates either large numbers or a continuous flow of its product. A process also creates an output. That output may be unique or a custom item; often its specifications aren’t known in advance.

3. People fulfill roles in Processes — the Process is at the center. It’s the other way around with processes: People use them to make sure they do things in the right order without forgetting anything. Lower-case processes play a role in employees’ success.

Don’t buy it yet? Think of the difference between the Process of manufacturing a car and the process of creating advertising. You can specify the steps for building a car so precisely that industrial robots can handle it — all of the intelligence is in the Process. Every last detail of the product has exact specifications and tolerances. If you follow the Process exactly, you must end up with a high-quality car.

You can also specify the steps needed to create advertising — you may analyze the marketplace, determine the product’s tangible and emotional benefits for each market segment, and so on. When you’re done, you’ll never end up with a process that can be handled by industrial robots (although many advertisements certainly look as if they were authored by automata). There’s no tight specification for distinguishing good ads from bad ones until you test-market to find out which ones make the cash register ring.

In our quest to make systems development and integration repeatable, predictable, and most important an activity we can reliably budget, we keep trying to turn it into a Process.

Systems development should follow a well-defined process, if for no other reason than to make sure we don’t leave anything out.

But a Process? Nope.

A great system is a work of art, both internally and in use. The processes used to create it help programmers focus on getting the job done instead of figuring out what the job is. Following the methodology facilitates great results. Only talented designers and programmers can cause them.

Here’s the wonderful irony of it all: Process redesign consultants don’t follow a Process. Only a process.