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.
- The Federal Aeronautical Commission on Traffic Safety (FACTS), a hypothetical organization, has been given money by government appropriation for the stated purpose of designing and building a robotic machine that automatically cleans airport runways and taxiways of small foreign objects that can be very dangerous to aircraft, much as a popular roving cleaner automatically cleans swimming pools. It traverses the runway or taxiway from end to end and from side to side. It must be smart enough not to go off the edge of the runway when it’s cleaning, and also must be smart enough never to be on the runway when there is aircraft traffic or even pending traffic. Aircraft safety is a major consideration in its design.
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:
- Deciders are the ones who make the major decisions or who can veto other people’s decisions. Deciders may be Generals or Specifics. A General Decider can decide virtually any kind of issue. A Specific Decider can decide within a particular area of competence, but not in other areas. A General Decider usually can overturn a Specific Decider’s decision.
- Influencers are people whose special knowledge, aggressiveness in solving problems, or panache makes other people willing to listen to and take careful account of their opinions. It’s possible an Influencer should be listened to within an area of expertise but can be safely ignored otherwise.
- Passives are everyone else we encounter in our contract pursuit. Passives may do most of the useful work, but they are not business warriors. They put in their time, they may (or may not) strive for excellence in their work, they draw their pay, and they are content. (Or not.)
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:
- Who shows up at meetings?
- Do they only show up at certain kinds of meetings?
- When certain people talk, does everyone else listen respectfully?
- Who conducts the meeting?
- Who prepared the agenda?
- Who hands out action items?
- Who takes on which action items and why?
- Is anyone consistently called Mister or Sir or Ms. or Ma’m?
- Who signs what kinds of memos?
- Who are designated as “points of contact?”
- When you contact points of contact, do they decide, or do they have to go ask?
- Who do they ask and why?
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:
- In dealing with the military, a senior sergeant or chief petty officer may be a much stronger Influencer than any ten green second lieutenants or ensigns. Similarly in dealing with a civilian organization, a senior and respected but low ranked employee may have more influence than a gaggle of junior supervisors.
- No organization is static. Watch for people whose power is on the wane. Also, watch for people who are “comers” and who may soon be elevated in status if not in formal rank.
- At a personal level, always treat Passives well. If you don’t, you may lose their support and that could damage you. That possibility makes them important, if nothing else does.
- Be careful about organization charts. A Decider or Influencer of great importance may be someone who is not even on the chart, such as a trusted outside consultant, or the CEO’s brother.
- Recognize consensus decision situations. These are commonplace in Japanese and European companies, but certainly are not unheard of in other companies. Many boards of directors and executive committees operate on a consensus basis. Not much happens until they have thoroughly talked the problem through and gotten everyone’s agreement.
- Watch for powers behind the throne. Many organizations have their rough counterparts to Rasputin and Machiavelli, sometimes benign, sometimes not.
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:
- Positive goals. A positive goal is something the customer wants that represents a change in the state of nature. It could be a particular product or service. It could be a continuation of something that would otherwise perish or degrade. It could be a capability or potential that does not now exist. Customer positive goals can have endless variety.
- Negative goals. A negative goal is something the customer does not wish (or cannot afford) to give up in order to achieve desired positive goals. It’s a constraint. It could be a money limit on contract expenditures. It could be a time limit on getting something done. It could be an environmental constraint, or even a political constraint. It could be strictures on labor compensation or access to a site. Again, the possibilities are endless.
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:
- The software shall be user friendly. (What does “friendly” mean?)
- The pipes shall be painted white. (Which pipes? What kind of paint?)
- Contractor shall report status monthly. (Status of what? When in the month?)
- The preliminary analysis shall be completed as soon as possible. (Who decides when as soon as possible is?)
- Contractor shall use computers supplied by us. (For all purposes? When will they be supplied? Will they have the right software?)
- Access to Bldg. 34 is limited. (Limited to whom? Do we need access? How can we get access?)
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:
- The customer, having more certain knowledge of what is wanted, will be able to judge proposals more realistically, consistently, and fairly. Goals are more likely to remain stable throughout the project.
- Bidders will be able to focus their efforts and costs on that which is essential, avoiding unbalanced proposals that overemphasize the relatively unimportant, often because it is simply something the bidder happens to like to do, or can do very well.
- Potential project instabilities are likely to be avoided, as for example when the low and winning bidder has heavily discounted the importance of certain goals that are highly valued by the customer (this often happens when goals are less than clear). If this happens, the customer is damaged, and so are the bidders who guessed right about what was important and what was not. The winning contractor is likely to be damaged also.
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:
- Star Wars
- 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
- 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?
- 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?
- Does the organization chart for your own organization accurately reflect who does what?
- 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?
- 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?
- In your projects, have you ever encountered any problems with unclear goals? What was the ultimate outcome?