In IT circles, the name "user" is as bad as the name Montague. It evokes images of drug addicts or sociopaths. Although Juliet may have rejected the observation, we don't dare mention that name anymore.

The demise of the name "user" led to a debate as to what to call all those consumers of IT products and services. And while we may not argue the question with the same heated passion we do politics, it's an important debate.

"What's in a name? That which we call a rose By any other name would smell as sweet."

William Shakespeare Romeo and Juliet (II, ii, 1-2)

How important is semantics? Very! Language affects the way we think. A pejorative word like "user" induces IT staff to consider them powerless dependents, sometimes nuisances, or perhaps little more than a mechanical part in a system IT is creating. It certainly doesn't sound appreciative of their unique knowledge of their businesses, respectful of their right to choose what they want from IT, and, well, human.

Partner

A popular alternative is the name "partner." It evokes images of a warm, cozy working relationship.

Indeed, as a verb, "partner" means establishing a close working relationship between parties who have a common interest. Think, for example, of a partnership between two businesses. Each company contributes its unique products and services, and the whole is greater than the sum of the parts.

But there's another interpretation of the word that has some terrible side effects. Some use the term "partner" to imply shared decision making, as in the context of business partners who together own a business. Co-owners share decision making and profits.

In this meaning, IT staff have some say over what IT products and services the business gets. IT has a vote in deciding priorities, requirements, and price point (Rolls Royce versus Chevrolet).

Consider the "golden rule" of organizational design: authority and accountability must always match. If IT staff have some degree of authority over what factors of production the business gets, then IT staff must accept shared accountability for business results.

I don't mean just accepting accountability for the success of the IT project. IT staff have to accept accountability for the business' bottom line -- for its profitability. After all, if IT has some authority in deciding that the business will get this instead of that, pay this instead of that, and change their business processes in this way, then IT has a direct impact on their bottom line.

Of course, this is absurd. There's so much that IT staff cannot control in producing bottom line results. And the business is not the least bit interested in giving up control over its processes or its factors of production.

Meanwhile, if IT has some authority over (and accountability for) business decisions in a partnership, then to be fair, the business must have some authority over IT decisions. "Users" will expect to participate in decisions like technology designs, infrastructure, project plans, which staff work on their project, whether those staff take time for training, etc. They'll claim the right to micro-manage IT.

In doing so, they should be held partially accountable for the success of the entire IT department. Yeah, right!

This whole muddle of shared accountability and authority leads to confusion, tussles for control, strained relations, and ultimately no clear accountability.

Furthermore, each party is given some control over the other's area of competence -- and their own area of incompetence! Instead of tapping the unique differential competencies of IT and business staff, it has each meddling in decisions they're not qualified to make.

Is this any way to run a successful business!?

Customer

A highly effective working relationship is indeed based on common interests, but it also establishes clear and distinct authorities and accountabilities, and it aligns these distinct roles with the parties distinct competencies.

The best way to think about such a working relationship is from the perspective of a business within a business. IT is a competitive product/service provider, and the rest of the business is its marketplace.

In this context, we'd call non-IT people "customers."

Customers are 100 percent accountable for their own bottom lines. Therefore, they must have 100 percent of the authority to decide how they work (their processes), how they spend their money (priorities and price points), and what they buy from IT.

Meanwhile, IT staff are 100 percent accountable for delivering their products and services as promised. Therefore, they must have 100 percent of the authority to manage their staff, their infrastructure, and their internal methods.

This taps everyone's unique competencies. Business customers know how to run their businesses, and it's just arrogance for IT staff to claim they know what's best for them. Customers decide their processes and what they'll buy from IT.

Of course, IT knows its products and services, so it can offer lots of help. It can help customers diagnose their requirements (a facilitative process, not a matter of studying and recommending). It can offer alternative solutions at varying price points (Chevrolet, BMW, Rolls-Royce), and explain the trade-offs of each.

IT staff can also help customers understand what process changes would best take advantage of the capabilities of new IT tools. But IT cannot be held accountable for changing the business. Change cannot be forced on the business from outside.

In practice, a respectful customer-supplier relationship leads to the best working relationships -- to the closest "partnerships" in the first meaning of the word.

Client

The name "customer" is certainly better than the name "partner," but there is a problem with it, and that has to do with teamwork.

Within the IT organization, a number of different groups may participate in a project team. Here too, shared authority and accountability does not lead to effective teamwork. While everybody should help the team succeed, clear individual accountabilities are essential to performance.

Again, the customer-supplier relationship applies. Consider an applications development project. An applications engineer (project manager) must be held 100 percent accountable for delivery of the project. But like the general contractor who builds your house, this project manager is a "prime contractor" who may subcontract to other IT groups for help.

For example, an information engineering group may be called upon to develop the data model, platform engineers may help the applications engineer design for performance on the intended platform, and the operations group is accountable for installation into the production environment.

In this way, every team member is individually accountable for his/her contribution, while the prime contractor is totally accountable for hiring all the right subcontractors, putting the pieces together, and delivering the complete results to the business.

For exactly the same reasons as described above, the customer-supplier relationship leads to the best working relationships within the IT organization -- high-performance teamwork.

With that in mind, your customer may be the ultimate consumer in the business (if you're the prime contractor), or your customer may be a peer within the IT organization (if you're a subcontractor).

"Customer" and "supplier" refer to roles, not to a set of people. Thus, we need a different name to describe customers in the business (nee "users").

I've adopted the name "client" to refer to people outside IT who consume IT's products and services -- the ultimate customers in the business.

QUICK LEXICON

Client: someone outside the IT organization, formerly known as a "user."

Customer: in the context of a specific project/service, the party that buys and owns/consumes your product/service; may be a client or another IT group.

Supplier: in the context of a specific project/service, the party that provides to you a product/service; may be a client or another IT group.

Partner: 1) [preferred] A customer or supplier with whom you have a close working relationship; clarifying roles requires more specific language.
2) [confusing] A co-owner with whom you share authority and accountability.

Applying the language

With this language, conversations become very clear. You'll know exactly what I mean by the following:

Clients are accountable for their businesses, and hence have the authority to decide what they buy from IT. They're customers to IT.

As a trusted supplier, IT makes every effort to help clients understand their options and make the right decisions, but they ultimately respect customers' right to choose what they buy.

Within IT, the prime contractor may subcontract to other IT groups for help. Nonetheless, the prime is completely accountable for delivery of the total product/service.

With the prime's accountability comes authority. Subcontractors within IT recognize that their customer is the prime, not the client directly. All strive to help the team please the client, but ultimately the prime is in control and is fully accountable for results.

On occasion, the prime contractor may need help from another client group. For example, to deliver a system to Manufacturing, IT may need to subcontract to Corporate Procurement for help. In this case, the client called Corporate Procurement should consider IT its customer. IT considers the client called Procurement a supplier, and the client called Manufacturing a customer.

Make sense? Clear language leads to clear communications.

Clear language also leads to clear thinking. With these names, roles, authorities, and accountabilities become very clear. Working relationships are highly effective; and ultimately, great long-term partnerships result.

What's in a name? A lot -- a way of thinking about your role and theirs, the foundation for customer focus and teamwork, and the basis for successful working relationships with the business and with peers.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....