Tag: Stakeholder

In our continuing effort to create a specific and relatively unambiguous vocabulary for business analysis, we come across the term “customer”. As business analysts we are constantly beset with the term couched in phrases like, “keep the customer satisfied”, “the customer is always right”, “we have to be customer-centric”, and so forth. The dictionary definition of “customer” is “a person who purchases goods or services from another; buyer”. Unfortunately, this definition does not fit all the varying roles who are designated customer, especially in an IT sense. For years, IT has had the business operations as its customer because IT was viewed as a service organization to the business. Now as IT becomes more entrenched and integrated with the business strategies and operations of the organization, the term has evolved and morphed so that sometimes when the business analyst is sent out to “work with the customer to define the solution” the definition of the solution is easier to comprehend than the definition of the customer.

Just who is our customer? This is not a frivolous question. About 15 years ago I was working for an automobile manufacturer and the executives were struggling with that very question. Who was their primary customer, the one that they needed to focus on? Since they owned a variety of other companies producing products not related to automobile manufacturing, their customer could be any one of the consumers of any one of their other products. For example, the company made diesel engines for locomotives and that would make train companies their customers. They also made engines in one of their subsidiaries for jet engines in airplanes. Since the jet engines were designed for commercial aircraft as well as fighter planes, the customers could be foreign governments or commercial airlines, and these were customer with large pocketbooks. It turns out that in the United States, this automobile manufacturer could not sell directly to the public, but only to dealerships who then sold to the public. This meant that the customer of the automobile manufacturer was not the driver of the automobile, but the dealership who sold the automobile. And as with any of the major automobile manufacturers, they had their own financing company, and it was this financing company who finance the cars that you and I buy, making us the customer, but not the customer of a car, we were the customer of a financial institution. So which one of these should be the customer of the organization? The discussion went on for quite a while, and I left before I learned what the answer finally was.

Why was it important to the company? Because knowing who your real customer is basically defines what business you are in. Based on subsequent business decisions and economic climate, it looks like there definition of customer has likely changed over the years.

So as a business analyst who is your customer? And, like the automobile manufacturer described above, does your customer define the business you are doing? How can you satisfy your customer if you are not sure who your customer is, or the definition of ‘customer’ keeps changing? How can you satisfy your customer if you have many customers who may have different and conflicting satisfaction demands? One approach that is sometimes touted is for the business analyst to define the customer of an individual project when the project begins. However, that person might be different depending on our definition of customer. I have been in situations where different people on the project responded to different people outside the project as “customer”. When that happens we get into the Orwellian concept that “all customer are equal, just some customer are more equal” and the business analyst has to sort out the inequalities.

Let’s start our sorting process with the usual suspects. Which of the following do you see as your “customer”? Who do you keep “satisfied”?

The Sponsor

Perhaps the most common definition of customer (especially to IT) is the one who pays the bills. The definition does match the dictionary definition of “purchases goods or services”. The first issue we have is with another common role, the sponsor. Many organizations tag the one who pays the bills as the ‘sponsor’. If that is the case, who is the customer?

Even when the bill payer is called the customer, there is a problem. Many times, the customer or sponsor has absolutely nothing to do with the project itself. For example, in the United States Federal Government, there are senior people who fill the roles of Contracting Officer. To keep the procurement and contracting process objective and as free of graft and manipulation as possible, the regulations state that I, as a staff member of a consulting firm bidding to Federal Government agencies, am prohibited from dirtect intercourse with the Contracting Officer and so I would rarely meet and talk to the Contracting Officer assigned to my contract. Those of us working on the projects for the Federal Government talked to someone called the Contracting Officers Technical Representative (COTR). The COTR had no control or authority over the contract and was not the person who paid the bills. The Contracting Officer did that. The contracting officer’s primary concerns were that all paperwork was filed correctly, all financial matters are handled successfully, and the COTR affirmed that we had done our job so that we could get paid. In this particular arrangement, the customer might well be the COTR as opposed to the contracting officer who paid the bills. After all, we could have some input and influence on satisfying the COTR.

So we might be digging ourselves a hole if we attempt to satisfy the person who pays the bills when the person who pays the bills in not really concerned with what we are doing. If you are working on modifications to the organization’s financial systems under the direction of the Chief Financial Officer (CFO), even though she might be the ultimate customer in your lexicon, your real customer might be someone closer to the project, and it is that person you would need to keep satisfied.

The Problem Owner

Every project solves a business problem. And every business problem must have a problem owner. So perhaps the “customer” of the business analyst and the project team is the problem owner. After all, the problem owner would be the one who determines whether the problem has been solved or not. However, in the world of corporate politics, finding someone who will admit to owning a problem is somewhat difficult. Ferreting out who the problem owner is one of the techniques business analysts use to establish the real problem to be solved, so that the team solves the right problem. However, that task is not easy. You either have no one stepping forward to address the real problem and own it, or you have several who want to own it so that they can put their mark or spin on the problem. There have been many times when, as the business analyst defining the real problem the organization must solve (as opposed to the ‘problems’ that business people present which are usually symptoms), I have become the ‘problem owner’, the one that upper level management expects to take charge and solve the problem. It may be a subtle transference of responsibility to hand over the ownership of the problem to the business analyst but it happens. And then who is your customer? Do you become your own customer? Are you then the customer of the solution team?

Again, it will be difficult if we state categorically that the ‘customer’ is “the one who owns the problem”. Ideally this might be true, but in reality it does not seem to work all that well, and leads to the Multiple Customer Syndrome.

The Business Manager 

It might seem natural and logical that the business manager would be considered to be the customer. After all, the business manager has the authority to approve or disapprove the results that we produce from the project and the business manager is usually a lot closer to the action than the Sponsor. This does present some interesting situations, such as one I ran into five years ago or so when a manager gave us the specifications for a particular financial transaction that was being rewritten for his company. He was the subject matter expert, having worked on that particular financial transaction for years before being promoted to his position of management several years prior to our engagement. We were instructed not to talk to the users because he didn’t want us taking the time away from their productivity and he figured that he was expert enough in the process to provide us with all the information we needed to change the system. However, for a number of various reasons, we decided to run the user interfaces past the users and figured a single meeting with them would not cause too much productivity disruption. The users were united in their dislike of the new process that the manager had laid out for us, pointing out that they no longer performed the process the way he described and had not for a number of years. They told us how they did it today and made suggestions as to how to improve it for the upgrade. This of course put us in a quandary. If we satisfy the users we draw the enmity of the manager, if we satisfy the manager, we produce a system that may not be used. Which one is the customer? Which one do we satisfy?

Assuming the business manager to be the customer might result in inefficient systems that may not be used to their greatest effectiveness. And, again, you face the Multiple Customer Syndrome when there are several business managers all of whom stake out their claim to the overall solution.

The Users

In the end, perhaps the ones we have to satisfy most are those who are using the system. After all, they have to use it day in day out and if they are not satisfied with it they won’t use it. And the problem for which the system was written to solve will not get solved. However, if we think of the users as the customer, we run into the issue of which user is the Real Customer? Users may represent a wide range of both organizational hierarchy and business area penetration and as often as not have conflicting requirements and views of the solution. Now we have the Multiple Customer Syndrome to the maximum. Another issue with defining the ‘customer’ as the user is that the term ‘user’ itself is vague and ambiguous. What precisely is a ‘user’? If we are not sure who the ‘user’ is, how can the ‘user’ be the ‘customer’?

If the user is the customer and we are to ‘satisfy the customer’, which one do we satisfy?

The Organization’s Customers

Perhaps we might possibly consider defining our customer in the same way the organization defines its customers. Instead of talking about internal customers which are satisfied by IT and external customers who are satisfied by the organization, we define one customer: the one (individual, organization, group) who buys our goods or uses our services and keeps our organization in operation.

In the bigger picture everything we do in IT or as a business analyst should be working with the business to satisfy the same customer. And in the end, if we satisfy the organization’s customers, we should satisfy all those we would consider “customers” of IT at the same time. And truly, we have to accept the fact that the consumers of the organization’s goods and services are really the only ones who need to be satisfied.

Why is it Important?

Because there are views of an organization’s ‘customer’ that are both positive and negative. Customers may be extremely frustrating, they may be overly demanding, they are rarely appreciative of the work that we do for them, they are hard to say “no” to, some believe they are always right, and they are always necessary to keep the organization in existence. By calling the people that you work with internally to solve the business problem a “customer” you are visiting upon them all of the characteristics of all customers, and this certainly is not conducive to a successful working partnership.

If we can start evaluating every system we define, every change that we make, every problem we solve with the question: “will this satisfy the customer of my organization?” we will likely be on target with the recommendations we make and all our changes and solutions will be aligned with the overall organizational goals and mission.

The problem then becomes: what do we call all those others whom we previously called ‘customer’ (after all we come from IT and therefore have to either label or make an acronym out of everything). . “Partner” might be a good term for those in IT to call those in the business. How about ‘teammate’, as in member of the solution team?

There is much talk today of convergence, bringing the business and IT closer together as partners. That is one of the precepts of agile no one in between the customer and the solution team. If you want the business to be a ‘customer’ with all the trappings of a customer (think of yourself as a customer in a store) and therefore be on the other side of the table in a negotiating position, then call them ‘customer’. If you want business and IT to be partners, work together and sit on the same side of the table opposite the organization’s real customers, then perhaps you should call them ‘partners’.

People will tend to meet the expectations of the label you give them.

Don’t forget to leave your comments below.