Monday, 12 March 2012 22:07

The Lexicon of Solutions - Down with the Customer

Written by

Well, no not really. Not the customer him or herself, although I’m sure there have been many times when that phrase was uttered in frustration within the comfy confines of the war room. No, I’m talking about the label “customer” that we might want to consider eliminating as it refers to the internal organization people we in IT work with.

Back in the day (I won’t get into exactly when in modern history the phrase “back in the day” refers to), the customer was the one who paid for the software development regardless of whether the customer was involved in what was requested. The “customer” was clearly distinguished from the sponsor, or the users, or the other stakeholders. After all, the definition of a customer is “a person who purchases goods or services from another.” (Note that a colloquial meaning of customer is “a person one has to deal with: a tough customer.” This may more accurately reflect some people’s concept of customer.)

Nowadays the customer refers to anyone who has a request, and/or the primary point of contact, and/or people who use the system, and/or just about anyone in the business community who is involved with the project. We’ve probably all worked with projects that have had several “customers,” most of whom better fit the colloquial definition above. Some IT departments tend to reference anyone in the business as their “customer.” And this is OK since from some perspectives everyone requiring services from IT, whether it be resetting passwords or developing a brand new accounts payable system, meets the colloquial criteria that defines a customer.

Back in the day (same timeframe), no one outside the organization, certainly none of the organization’s customers, saw the results of IT projects. This meant that confusion about the customer was minimal. IT’s customers were internal and those customers provided a barrier between IT and the “real” customers of the organization.

However, today, since a much greater percentage of our systems are aimed externally, the term “customer” brings about confusion. Suppose we have a project that creates a new portal to increase our online sales. Our “customer” is marketing who is defining the content, functionality and appearance of the portal, but we are creating the portal for existing and potential customers of the organization. You see the issue. Which customer has precedence? Are we satisfying the internal “customer” or the external “customer”? (Of course one would assume that by satisfying the internal customer we automatically satisfy the external customer. But then, ignoring the cases where that is not true, why have two “customers”? Why not have everyone focus on the external?)

So I’m thinking that it is time we retired the term “customer” from our IT vocabulary at least as it refers to someone in the business and reserve it specifically for those to whom the organization provides goods and services.

In essence, there are four reasons to stop using the term “customer”:

  1. “Customer” is ambiguous. To some in IT, the customer is the person in the business who has the problem they are solving while to others that is an SME. To some the customer is the one who pays the bills and everyone else is a user. Even within a single company the meaning can change project to project and person to person. The term can also get personal and possessive when business analysts and others refer to “my customer.” (At times I wonder about the connotation of that possession. Does it mean the same as “my client,” or perhaps “my spouse” or maybe “my pet dog, Jackson.”) And then you get into conflicts between or among customers for various projects.
  2. “Customer” is no longer truly applicable. At one time we could call the business person with the problem a customer and there would be no confusion with the organization’s customers. We simply did not do systems that involved people outside the company. Those customers, the ones who bought our products and used our services, were a distance away from the accounts receivable, and inventory control and accounting systems we were creating and maintaining.

Nowadays, most of our systems are externally visible to the real organization’s customer. It is probably time to start focusing on the organization’s customers. We all serve the same customer: the person who buys our products and services and keeps the organization alive.

  1. The term continues the chasm between IT and business. Customers are always on the other side of the counter, usually separated by money from the person waiting on them. It is hard to imagine full collaboration with a customer (the kind of collaboration we would like to have) who is paying the bills and has the power to pull the plug. Moreover, the term perpetuates the barrier between IT and the organization’s real customers by continuing the belief that the people we have to satisfy are those within the organization as opposed to those who are supplying the revenue to keep the organization going. Focusing only on one “customer” means that the business and IT can forge a collaborative relationship to enhance the experience of the organization’s customers.
  2. Customers can go elsewhere and buy their desired goods and services from another source, say a different store or supplier. Internal customers are stuck with us. We have a monopoly for the most part on their IT service needs.

What term to use instead of customer? “Partner” might be applicable since the goal would be to partner with the business person to develop systems that better serve the organization’s customers. But “partner” is already reserved for the organization’s compatriots and supply chain members. Besides, there is an implication of lawyers, which we don’t want to get into.

How about “problem owner”? They are coming to us with a problem and we are helping them solve it. They must stay in the loop and collaborate with us to make sure their problem truly gets solved. Together we can solve the problem. It may be an accurate term, but it sure sounds negative and ominous. There are probably many people who would not want to be labeled a “problem owner” even in a friendly way.

One alternative to “customer” is “product stakeholder.” The “product stakeholder” refers to anyone who has a stake in the result of the project — the product. So anyone making requests of the product might be termed “product stakeholder” rather than customer. We can then separate product stakeholders into those affected by the problem and those impacted by the solution for purposes of elicitation and delivery.

What do we call the upper-level manager who controls the purse strings? How about the old stand-by sponsor? Or if the purse string controller is actively involved in the project, how about the Project or Product Champion? These are older terms that may be worthwhile to recycle for clarification. (Note that the definition of “champion” in days gone by identified the person from the business community who most wanted the product implemented, for whatever positive or personal reason.)

There may be a better appellation for IT “customer” that removes the ambiguity and confusion and describes the collaborative partner we want the business to be. Do you have a suggestion?

Don't forget to leave your comments below.

Read 7723 times
Steve Blais

Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development.  He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.

© BA Times.com 2019

macgregor logo white web