Chapter 2—Understand who the customer is
Why it is necessary to have a chapter such as this? Surely we know who the customer is. Everybody knows it’s the Federal Aeronautical Commission on Safety. Or is it Xanadu Incorporated? Could it be both?
Maybe it’s both. Maybe it even includes others. Imagine this scenario.
Because of the complexity and difficulty of the project goals, Xanadu Inc., a consulting outfit that does a lot of engineering studies related to the airline industry but builds no hardware, has been selected as a “system integration” contractor to guide the integration of the project into major airports across the U.S., and perhaps eventually around the world. You hope to be selected as the “prime” contractor that will design and build the system.
Who is the customer? Is it Xanadu because they will have a strong influence in approving your design and will be monitoring your tests? Is it FACTS because they are the proximate source of the money and have ultimate approval authority for what you do? Or maybe it’s the legislature because of certain language in the authorizing legislation? Or, maybe it’s the airline industry because they lobbied hard for the robotic runway cleaner and will be watching its development closely. Or maybe in some ways it’s all of the above.
The point emerging here is that you shouldn’t be too quick to jump to judgment as to who is the customer. You need to have a practical working definition for “customer” and a means to test for “customer-ship.”
We offer the following definition of customer:
The customer is that group of people whose collective goals the contractor must satisfy.
There are advantages in keeping a definition simple, as we have tried to do here. The downside is that full understanding may come only after a fair amount of explanation.
Parsing the definition, it seems that the words or phrases most in need of elucidation are “group of people,” “collective goals,” and “satisfy.” Let’s take them on one at a time.
The group of people
Our definition of customer intentionally emphasizes the notion that it is not really a company or an agency you are dealing with. Those are just convenient abstractions. It’s the people who count. They will determine whether you win or lose the contract. They may even determine whether you can execute it successfully if you win it.
As the scenario that began this chapter suggests, some members of the group you need to deal with as “customer” may wear different badges or may get their paychecks from different payroll departments. You must always be open to that possibility.
In dealing with any group of people in business, it is important to sort out and identify members of three major types: Deciders, Influencers, and Passives. We can define these as follows:
Your business development team and your pursuit leaders and key players should share a common understanding of who the Deciders and Influencers are in a given pursuit situation. You often can learn a bit by looking at organization charts, but these charts can be deceptive. A lot depends on hidden delegations and the so-called virtual organization (i.e., who really does what, regardless of title and size of office). Personal contact and observation are far better than looking at organizational charts.
Observers can be deceived, but over time they can get a pretty clear picture. The picture comes from asking and answering questions like these:
Formal lists of Deciders and Influencers together with notes about their observed behavior and areas of influence are useful, and should be created by your pursuit team, but their distribution and content must be carefully managed. It will not do to have an unflattering observation leaked either intentionally or inadvertently to a Decider or even to an Influencer.
A point worth noting is that Influencers and even Deciders may not all be outside your own organization. One reason you could be hired to perform a certain contract is because you have people in your organization whose skills and expertise are widely recognized. Although they presumably owe first allegiance to your organization (which writes their paychecks), they may become so closely entwined with the concerns of the external customer group that they become a de facto part of it. This is especially likely to happen with retired technology superheroes and retired vice presidents who are called in as consultants. Not to say that situations like this are necessarily bad; they just need to be recognized for what they are.
Here are some thoughts on Deciders, Influencers, and Passives:
Collective goals
Now is a good time to introduce a useful concept that will appear elsewhere in this book. It is the notion of positive and negative goals. We define:
All pursuit situations encounter both positive and negative goals. All project customers have positive things they want to get done and also things they are not willing to give up to get them. It is fair to say that:
The measure of success in any project is the extent to which the positive goals are accomplished and the negative goals are not violated.
In a perfect project, both things happen, 100 percent!
[As an aside, please note that in this book we carefully segregate goals from what are often called requirements. In this book, goals are what the customer wants, positive or negative, while requirements are needful things that arise out a particular project plan or design solution. If the plan or the design changes, so may the requirements, but the goals are still the goals. This is not to say that goals are always stable. Customers don’t always have a clear and stable view of what they want. Let’s rephrase that – in the high tech arena, customers seldom have a clear and stable view of what they want.]
What about that word “collective” in collective goals? It certainly does not mean that every Decider and Influencer is necessarily 100% in agreement that a given set of goals should be the goals of a project. That degree of agreement will probably never happen. Here’s what it means as far as this book is concerned:
The collective goals of a project are the apparent goals for which the strongest evidence of customer intent exists.
This definition basically says that if a pursuit team wants to understand the goals of a project, it must look at all of the available evidence and judge accordingly.
Generally, the strongest evidence for the existence of a goal is that it is clearly and unambiguously recorded in an official document issued by the people who will pay for the project, and that the means for satisfying it are clearly visible. Written requests for proposal and written specifications generally are such documents. But these documents may not be the only evidence. Not all valid goals are recorded religiously in formal written documents. Some may be recorded in informal memos, meeting minutes, or even in e-mails. Some may have been spoken orally in a meeting or in a telephone conversation.
If a goal is stated orally only, and it is more than trivial, it is important who stated it and what the circumstances were. It is also important that an orally stated goal not conflict with a written goal. Legally, that which is in writing is almost universally held to have precedence over that which is stated orally. Writings may have precedence over other means of expression such as pictures. For example, goals stated in words generally have precedence over goals stated in any graphical form.
A goal stated by an Influencer should be assigned less credibility than one stated by a Decider. The more senior the Decider the greater his credibility in this regard.
For a variety of reasons, goals pronounced by the part of the customer group that is paying for the project generally have precedence over those pronounced by non-payers in the customer group. And finally, goals stated in formal contract documents have the highest precedence of all.
Goals have many issues; we will not attempt to discuss all of them in this chapter. For example, there are issues of clarity, conflict, precedence, realism, and visibility, to name a few. Chapter 6 has a comprehensive discussion of this topic.
Satisfying the goals
Are goals satisfied only when the customer says they are? That may be the case in certain projects where the customer pays or reimburses all costs, no matter how high. But in most projects, the notion that the customer is always right must be tempered by reality. Satisfaction of a goal should be something that is easily and immediately recognizable by both contractor and customer. That will be the case only when the goals are truly clear.
The notion of a clear goal is important. In this book, we define a “clear goal” as follows:
A clear goal is one whose criteria for satisfaction are obvious.
If all goals are clear, then the only issue of satisfaction is when we fail to meet the goal. Then we must pay whatever price or penalty the contract calls for. Unclear goals lead to arguments and dissatisfaction.
We have observed that unfortunately many project goals are not clearly expressed. That is a major reason why we have lawsuits, mediations, and unhappy customers.
Unclear goals are such a detriment to both customers and contractors that both sides should always go to great lengths to keep them from happening.
Here are some examples of goals that may be unclear, depending on the context:
Sorting out the true goals in a project is similar to what a communications engineer would call a signal versus noise problem. The stronger the signal, and the weaker the noise, the easier it is. The need for a strong signal versus noise ratio becomes even more imperative when you consider that you need to do more than just figure out what the goals are. You also need to figure out how important they are relative to one another. Sometimes a customer will volunteer that information for a few top-level goals, but more often it will not be disclosed unless you ask. Not too surprisingly, when you do ask, your customer will sometimes have to stop and think before giving an answer. In the rush to get his projects organized, a customer will often not be too clear on his priorities or his value system.
Why is it important for the customer to know the relative importance of goals and to share that information with bidders? Here are three reasons:
What is “relative importance” in this context? It comes in two “flavors,” ordinal scale and ratio scale. If we are asked our order of preference for three particular movies, we might rank them like this:
1. Star Wars
2. Matrix
3. Die Another Day
This is an ordinal statement of preference. Such a statement might be perfectly adequate for certain decisions, but possibly not for others. In certain situations, we might want to know how much more we like Star Wars than Matrix, and how much more we like Matrix than Die Another Day. This type of information can be key to a decision process. Merely to know the order of preference is to know a lot less than knowing that with Star Wars at a ten on a ten-point scale, we would place Matrix at a 6 and Die Another Day at a 3.5. This is ratio scale knowledge and it can be precious in making decisions about levels of resources or degrees of application. A practical method for obtaining subjective ratio scale rankings is discussed in Appendix C.
A very useful way to view goals is to classify them as either tradable or non-tradable. A tradable goal is one for which options exist as to how to satisfy it. A non-tradable goal is one which can be satisfied in just one way. Tradable goals are desirable because they give the contractor an opportunity to flex his imagination and find more cost effective solutions. Non-tradable goals may be necessary in some cases to fulfill the customer’s wants, but they can result in higher costs to the customer.
Chapter 2 Review Questions
1. Have you ever worked on a project where there seemed to be more than one customer telling you what to do? How did you deal with this?
2. Has any project team you have worked with made a list of customer people and characterized them with respect to their true roles, not just their titles?
3. Does the organization chart for your own organization accurately reflect who does what?
4. Positive and negative goals create stresses and risk in every project. What do you think is the best way to keep these tensions from damaging the project’s chances for success?
5. Can you think of an orally transmitted customer goal on any project you worked on? Was it a tradable goal? Did it cause any problems?
6. In your projects, have you ever encountered any problems with unclear goals? What was the ultimate outcome?