Definitions get me into a lot of trouble.

Early in my career, I was asked to perform a “feasibility study.”

“What’s the subject?” I asked.

“An inventory system,” my boss answered.

“OK, it’s feasible,” I told him. “I guarantee it. Lots of other companies keep track of their inventories on computers, so it must be.”

More patient than most of the managers I’ve reported to in my career, he explained to me that in IS, a feasibility study doesn’t determine whether something is feasible. It determines whether it’s a good idea or not.

It turned out to be a good idea (a tremendous surprise), so next we analyzed requirements. You know what’s coming: A senior analyst asked me if the requirements were before or after the negotiation.

“What negotiation?” I asked. “These are requirements. They’re required.”

This is how I learned that we do feasibility studies and requirements analyses in part to test the validity of the requests we receive. The process would be unnecessary if we believed end-users were our customers.

At the supermarket, nobody says to a customer, “Those fried pork rinds aren’t an acceptable part of your diet!” or, “Prove you need that ice cream!” At the supermarket, wanting something and being able to pay for it are all that matter.

In IS we used to view end-users as our (internal) customers, and we figured the relationship followed from the role: If they’re our customers, our job is (as Tom Peters would say) to delight them.

End-users aren’t our customers, though. They’re our consumers – they consume our products and services but don’t make buying decisions about them. But does that really change anything, or is it just a useless distinction?

It does change things. “Customer” defines both a role and a relationship. What does “consumer” say about a relationship? Nothing. Or at best, very little.

“Consumer” defines only a role, and in the context of organizational design, role is a process concept, whereas relationship is a cultural one. (Definitions: Processes describe the steps employees follow to accomplish a result. Culture describes their attitudes and the behavior they exhibit in response to their environment.)

What should the relationship between IS and the rest of the business look like? This is one of the most continuously controversial issues in our industry. When you view it as a clash between process design and cultural cues, the reason our discussions are jumbled is more clear.

Defining the rest of the business as our consumers frees us to define whatever relationship works the best. As with my inventory system, every highly successful result I’ve ever seen in IS has been the result of an open collaboration between IS and end-users, with authority shared and the dividing line between the two groups obliterated.

Yet many of my colleagues and much of the correspondence I receive on the subject still advocate a hard dividing line between the two groups, with formally documented “requirements” defined by a small group of end-users and the authority for “technical” decisions reserved for IS.

Of course, purely technical decisions are few and far between these days. What brand of NIC should you buy? OK, that’s a technical decision, but even something as seemingly technical as choosing a server OS places constraints on business choice. Or, looking at the opposite end of the process, selecting a business application limits IS’s choice of operating system, sometimes to a single one.

Trying to partition responsibilities to preserve the prerogatives of one group or the other leads to nothing but bad results. “You have to do this for me because I’m your customer,” and “You can’t do that because it violates our standards,” are two sides of the same counterfeit coin.

There are few purely technical or purely business decisions anymore. Since form follows function, you should strive for a relationship that recognizes this fact. What kind of relationship should you have with your consumers? One that emphasizes joint problem-solving and decision-making, and working together in a collaborative environment.

Or, in a word, “partnership.”