Chapter 5—Measure customer value judgments
Chances are that in your previous project pursuits a lot of attention was paid to figuring out what the customer wants, but not a lot of attention was paid to how strongly it is wanted. This chapter will make the case that you should be very interested in just how much, relatively speaking, the customer values the things he is asking for. We will try to show that having this information can improve your win probability. The effect on win probability is much more subtle and complex than factors like bid amount or number of efficient bidders, but it is nevertheless important.
To illuminate and inform this subject, it seems best to start with a simple example. Suppose that the customer has issued a request for proposal for development and production of a laptop computer. You, as a prospective bidder, have managed to elicit the information shown in Exhibit 5-1 from the customer:
Exhibit 5-1—Example Customer Relative Value Assessment
As a prospective bidder, you are concerned that the customer 1) may be asking for more than is affordable, and 2) may be unwittingly adding expensive requirements that are out of proportion to their value to him.
Using the above table of features, you estimate relative costs for each feature as a percentage of total average product cost. Most of the estimates will be simple and straightforward, but some will require careful thought. An example of the latter is the weight requirement. Weight is neither hardware nor software. It is actually a constraint on a physical property of the hardware. How can it have a cost?
That question can be answered in the following way: If the weight requirement can be met without violating any of the other goals, then it has no cost. But if cost must be incurred to reduce the weight of one or more of the components of the laptop in order to meet the weight goal, then that incremental cost should be assigned to weight.
To further illustrate, suppose you add to the above table your estimates of relative cost, with the following result (Exhibit 5-2):
Exhibit 5-2—Example Customer Relative Value/Cost Assessment
An interesting way to present this data for internal review is a radar chart such as the following:
Comparisons between relative cost and relative value should be based on minimal efficient designs. Such design solutions are discussed in Chapter 9.
Aside from possibly helping your customer re-order his priorities to be more in line with costs, what other reasons are there to do the type of analysis shown above? Here are some thoughts on that subject.
How do you go about finding your customer’s scheme of values? You may find little information about this in your customer’s request for proposal. Recall from Chapter 2 that it can sometimes be daunting to find out who really speaks most authoritatively for the customer. It may be necessary to conduct a poll of authoritative customer representatives and average the results. If some customer representatives are not responsive, credible answers sometimes can be had from consultants, especially those who are former customer employees or advisors. Exhibit 5-3 below shows a hypothetical example of a values survey.
Exhibit 5-3—Using Weighted Survey Data to Assess Importance to Customer
Once you have created a table such as the above you want to also determine the weighted costs. With some product features, such as the features of the laptop computer described earlier, it is fairly easy to assign relative costs to individual features. With features such as speed, altitude and payload, it may not be obvious how to do this. So instead you could create a proxy for these relative costs.
An example of such a proxy is the Performance Difficulty Index (PDI). The PDI is a subjective assessment of the relative difficulty of meeting particular goals. A survey process analogous to the customer value process described above can be used. See Exhibit 5-4 for an example.
Exhibit 5-4—Using Weighted Survey Data to Assess the PDI
We are now able to introduce a design balance metric that can be used to track design balance throughout the pursuit cycle. We first combine the results of the above two tables in Exhibit 5-5:
Exhibit 5-5—Combining Customer Importance and PDI
You can immediately see that the effort, as represented by the difficulty proxy, is substantially out of proportion with the customer’s importance ratings. What is the significance of this metric? It basically is a signal that you may be working too hard and spending too much time and money in areas that are not that important to your customer. Then again, you may not be. The metric is not infallible. It’s a flag that you need to look more closely.
For example, payload is the most important goal (50%), yet it represents only 30% of your effort as measured by difficulty. It is just possible that with your design approach, the payload goal is easy for you to reach. In that case, your present approach would be reasonable. On the other hand, you may need to restructure your efforts to put more emphasis on the payload goal, and less on the other two goals
Just what form would a restructuring of effort take? That’s hard to say without examining the reasons why the difficulty assessment came out the way it did. Suppose for example that the team believes that the difficulty with speed arises because of a complex of problems relating to engine thrust, fuselage shape, and other factors. At bottom, these problems loom large because the team’s experience has mainly been with larger, faster aircraft. The remedy may be as simple as hiring a few people with the needed experience.
The comparison approach advocated here is not science, exact or otherwise. It should never be regarded as a positive indicator that the approach taken is wrong. Rather, it should be regarded as a form of self-examination to be sure that what is being done is in your customer’s best interests.
Cost and “difficulty” are just two possible comparisons you might want to make with the customer’s view of relative importance. In your proposal you will want to discuss in some detail how you will approach meeting customer goals. In response to customer goals, many (mostly losing) proposals make terse and uninformative statements such as “The aircraft will be able to carry a payload of 10,000 pounds.” If you know that payload is the most important customer goal, you would be wise to be sure that your customer is convinced that you can meet that goal. You need to be clear on how you know you can meet the goal. This is emphasized in chapter 14.
It would be too simplistic to claim that the number of pages in the proposal devoted to each goal should be proportional to the importance the customer attaches to it. But clearly the strength of the arguments in your proposal should in some sense be proportional.
A common mistake in proposals is to rave on endlessly about the things the project team does well instead of focusing specifically on how the team’s skills can be applied to assuring that the customer’s goals are met.
This is especially egregious when the goals are tradable. The customer will want to know how you have taken maximum advantage of the available trade space, and that requires convincing words of explanation.
Earlier in this book the phrase “project design” was used. We explained that it referred to both product design and programmatic design. Up until now in this chapter, we have focused on matching product efforts with what the customer regards as important. We need to go beyond that to be sure our customer understands that our programmatic efforts also are appropriate.
Customers usually spell out in considerable detail what they expect the product performance to be like. They often are a bit less explicit as to their programmatic goals. Programmatic goals, like product goals, can be either positive or negative, and either tradable or non-tradable. They can also be ranked, just as we discussed above for product goals. An obvious question arises: should they be ranked in the same list with the product goals, or separately?
Separately is probably best in most cases. Separating them avoids the “apples vs. oranges” sense that arises when they are combined. (But see Appendix C for an approach known as the Analytic Hierarchy Process that can make sense out of many “apples vs. oranges” situations.) The important thing is not to focus exclusively on product goals to the detriment of programmatic goals.
Keep in mind that your customer may be much more sensitive to certain programmatic issues than to some product issues. For example, if it has been made clear that a $50 million spending cap is not tradable, you need to be sure that you can do the project for less than $50 million. If you are pretty sure you can’t do it, and that no competitor can either, you should suggest downgrading or elimination of some other goals.
The pursuit manager should have primary responsibility for assessment of customer priorities and values, but she should be assisted by the pursuit team and by the business development team. The information should be logged into a project database so that it becomes available to all members of the core pursuit team. If the proposal has a review wall, it should be posted there.
Chapter 5 Review Questions
1. In the laptop example in this chapter, explain how you might assign a relative cost to the price goal. Hint: Review the discussion of assigning a relative cost to the weight goal.
2. Explain in your own words how a customer having unaffordable wants can lead to project instabilities that adversely affect the customer, the winning bidder, and all of the other bidders.
3. In the example table of values survey (Exhibit 5-3), the Federal Aviation Commission on Safety (FACS) weight was consistently set at 0.6 for all parameters and the Xanadu weight was consistently set at 0.4 for all parameters. Could there be a situation where, for example, one might want to set the FACS weight differently for different parameters, say 0.6 for speed and payload and 0.5 for altitude? What practical problems might this create for building the table? How could you overcome them?
4. If “difficulty” is to be a proxy for cost, what definition needs to be assigned to “difficulty” that is reasonably consistent with typical dictionary definitions?
5. Name five typical elements of programmatic design other than schedule and budget. Hint: Look in Chapter 8 if you can’t think of five.
6. Your contract, in a paragraph titled Period of Performance, says you shall complete not later than 30 September of the current year. Is this a positive or a negative goal? Is it tradable or not? How sure are you about whether or not it is tradable? If not completely sure, describe a way you might become sure. If it is tradable, why do you suppose the contract doesn’t say so explicitly?