5.2.1 Approach #1: The Heilmeier Questions

For about five years,³ I served on a US Government advisory panel called the Defense Science Board.⁴ One of the other (more senior) members of the board was Dr. George Heilmeier. Dr. Heilmeier was a distinguished engineer, best known for having been part of the small team that invented the liquid crystal display, which is used throughout the world on millions of electronic devices. He also served from 1975 to 1977 as the director of the US Department of Defense's Defense Advanced Project Research Agency (DARPA; originally called ARPA). During his tenure at DARPA, he started using a set of questions to help people within that agency who wanted to start a project sharpen their thinking about whether or not this was actually a good project for the agency to undertake. I have seen more than one version of these questions, but Figure 5.2 shows the version presented on the DARPA website.⁵

By the time I worked with Dr. Heilmeier, he was advocating that teams who were going to prepare competitive proposals for engineered systems use these questions to guide their planning and preparation process. That is, he advocated using them for what we are calling Step 3.

Note, however, that these questions are similar in many ways to the questions that I posed above, for Step 2.

Let's look at each question in a bit more detail:

• What are you trying to do? Articulate your objectives using absolutely no jargon. That is, what is the goal of this project? If you are completely successful, what will you have created?
• How is it done today, and what are the limits of current practice? The item that you wish to create is intended to help someone perform a mission; how do they do that mission today? This might be represented by the mission thread that represents current practice, as we described that item earlier.
• What is new in your approach and why do you think it will be successful? The first portion of this question can be answered by the new mission thread diagrams. The second portion of the question asks two separate things: why is that approach likely to be an improvement for the users (e.g. what are the operational performance measures that indicate improvement) and why is your approach to implementing that likely to be feasible (e.g. what are the technologies that you will use to implement the new mission threads, and what are the technical performance measures that indicate that it can actually be achieved).
• Who cares? If you are successful, what difference will it make? The first portion can be answered by identifying the users and other stakeholders for this mission. The second portion again can be answered by the operational performance measures. (I would put this question much earlier in the list.)
• What are the risks? That is, what can go wrong? For each of those items, if one did go wrong, what would result? For each item, how can we lessen the likelihood of such an occurrence? For each item, how can we (separately) lessen the negative impact, if in fact one of these items did occur anyway? (We will discuss these items in greater detail in Chapter 9.)
• How much will it cost? Not only how much to build and test the new system, but how much to operate and maintain it over its entire anticipated lifetime. How much will it cost to dispose of the system when its useful lifetime is ended? What is the time phasing of these costs? What is the range of uncertainty for those estimates? We will discuss this subject in detail in Chapter 7.
• How long will it take? Not only how long to build and test the new system, but also the range of uncertainty for those estimates. We will discuss this subject in detail in Chapter 7 as well.
• What are the mid‐term and final “exams” to check for success? That is, how do we objectively measure progress along the way? We will discuss this subject in detail in Chapters 10 and 11.

This is a pretty good list. As you can see, we have either discussed each subject already in this book, or are going to do so in a future chapter. Certainly, you need to address each of these items in a competitive proposal, whether the audience for that proposal is external to your company or internal to your company.

I do believe, however, that this list misses a couple of vital points, and so in order to address those particular items, I now present the method that I created and used during the time that I was writing (and winning) a lot of competitive proposals.

5.2.2 Approach #2: Neil's Approach: Achieve Positive Competitive Differentiation

My approach is slightly different. I focus on a systematic series of steps that lead to the creation of what I call differentiators, and what I call the socialization of these differentiators with the users and stakeholders, especially the buying customer. I created a sequence of steps aimed primarily at achieving that particular purpose.

What do I mean, in this context, by the term differentiation? By this, I mean creating a story line, supported by facts, so that the customer will conclude that my proposal offer is different⁶ from the other, competing proposals in tangible and important ways that are beneficial to the customer. Of course, to be pedantic, I should have said positive differentiation; one can be differentiated in a negative sense too. That is not what we want; we want to be better than the competition.

My view is that in order to win a competition, you must be – in the eyes of those who are scoring and evaluating all of the proposals – the best among those submitted. That is, you win by achieving relative merit (i.e. merit relative to the other bidders), not by achieving any absolute level of quality. If you are manufacturing an item, you may aspire to an absolute measure of quality (e.g. 1 defect per 1 000 000 items manufactured, or whatever), but in order to win a competition, you must be the best of those who submit proposals, rather than meet some absolute standard of quality.

What I decided during my tenure as the person responsible for winning competitive proposals was to focus on achieving this relative advantage. In order to do that, for each proposal, I defined a set of specific topics in which I aimed to make our offer clearly the best: the specific areas where I desired to achieve positive differentiation. Since one usually cannot afford to be the best at everything, I also therefore accepted that I would only be just even with the other bidders in everything else; there might even be some areas where I accepted that some other company might be better than mine. But the idea was to carefully pick the areas where I believed that being the best would cause the buying customer and the source‐selection process to choose my proposal offer over all of the others. That is, I pick the areas where I want to achieve positive differentiation and craft my proposal and marketing efforts so as to convey that message to the customer, and get them to believe it. If I choose the items where I want to achieve such differentiation properly (that is, I am able correctly to determine those items that are really most important to the customer), and I can actually convince them that I have credibly established that positive differentiation, then the customer will want my company to do the work … and we will win the competition.

This approach seems to work. Using this approach, we won far more competitions than probability would indicate. In competitions that routinely had three or four other serious competitors (and therefore, if we won only an average percentage of these competitions, we would have won 20–25% of the time), we won nearly 75% of the time, over many competitions and over many years.

The written guidance that I created in order to accomplish this is pretty simple; it consists of just three pictures. The first is depicted in Figure 5.3.

First of all, you can see in that figure that quite a bit of the content is similar to that of the Heilmeier questions, although the sequence is quite different, and at times the focus. But there are also items on my list that do not appear on Dr. Heilmeier's.

As I do throughout this book, I start with the users, the other stakeholders, and their mission. We can use all of the techniques and methods that we discussed in Chapter 4 to understand the users and their coordinate system of value, and then use those insights in order to create the operational performance measures that they will recognize as measuring value that matters to them.

In the next step, I diverge significantly from the approach recommended by Dr. Heilmeier: I try to define the features of a potential design and offering that would make the customer want our company to do the work. This becomes my list of desired differentiators. I will describe below my technique for creating this list.

I must, however, limit the set of items that I place onto this list in two ways:

1. I must be able to afford to implement (and have the time to implement) all of the items on the list.
2. Each item on the list must not only be technically feasible, but I must also have a method for conveying that feasibility to the customer in a way that they will believe. Remember what we said previously: many of the customers are not engineers or scientists, so the explanations must be accessible to an adult of ordinary education and experience.

The idea of obtaining positive competitive differentiation from your competitors may sound obvious, but in my experience most proposal teams simply do not make such a list. It is not surprising, therefore, that the proposals that result do not convey strong positive differentiation. I believe that it is essential – absolutely the core of a winning proposal – to do this step explicitly, and to create a written list of candidate differentiators that are then explicitly discussed among the team, with your management, and (once you think that you have a pretty good list) with every element of the customer: the buying customer, the paying customer, the users, the other stakeholders, the nay‐sayers, and so forth. This is not, in my experience, common practice. But having such a list provides guidance to every person participating in the proposal, and provides your potential customers with a clear view of what you are offering. In my view, every proposal ought to do this.

The next step is story‐telling: how to tell the story about our differentiators, and their feasibility, in a clear, comprehensive, and easy‐to‐understand fashion. This is a separate step because I have found that it is often the case that the people who can identify the good candidate differentiators – and can do the technical analysis to demonstrate their feasibility – simply cannot tell the story in an effective and convincing manner. They tend to get caught up in confusing technical details. Therefore, once you have the list and the technical analysis, I have found it worthwhile to then recast the differentiators into an effective story line. This must often be done by people other than (or in addition to) those who actually create and validate the differentiators.

The next step is data‐gathering: how will we actually make the measurements that prove our story? To do that, we need at least a preliminary design, so Steps 4 and 5 go hand in hand, and may proceed in parallel.

Good proposals have more than text; they have a small number of key depictions (figures, tables, and graphs) that concisely convey our key points. We next create these depictions. We also write theme sentences (or short paragraphs) to go with each depiction. Together, the depictions and the theme sentences are the artifacts that will tell our story, both in the proposal and in our face‐to‐face interactions that lead up to the formal submission of the proposal, and the eventual selection of a winning contractor.

Steps 7 and 8 are similar to several of the steps that are included in the Heilmeier questions. What could go wrong, and how do we mitigate those risks?⁷ How will we evaluate progress?⁸ How long will it take? How much will it cost? (Notice that I will always discuss schedule before cost; I will tell you why in Chapter 7, and revisit the subject in Chapters 10 and 11.)

The last step – Step 9 – is another step that I have found is often done poorly. It is not enough for us to create great differentiators; we must get the customer actually to believe them. In my experience, explaining these great differentiators to your customer for the first time in the proposal is not sufficient in order to get customers to believe in your differentiators. In order to get them to believe in those differentiators, we must socialize those differentiators (and our other key ideas too) via face‐to‐face meetings with the customer before we submit our proposal. We do this for two reasons:

1. First, we are likely to learn something from such interactions with the customers that allows us to refine and improve our differentiators, and our other ideas.
2. Second, people are always reluctant truly to believe other people's ideas; they are far more likely to believe an idea if they feel that they have had a hand in creating it. You therefore need to allow your customer to have intellectual skin in the game of creating your differentiators. I like to say that we must transfer some emotional ownership of our ideas to our customers; if we can make them feel that these ideas are in part theirs, they are much more likely to believe in those ideas, to accept the arguments that led to them, and to accept the inferences that derive from them. That is what we want!

The value of your differentiators must be measured in the customer's coordinate system of value, not just in the engineer's coordinate system of value. We have talked about this before: customers are seldom engineers or scientists, and therefore have a different “coordinate system of value” than we do. Therefore, if we want them to like our ideas and select our proposal (especially if we want them to like us so much that they will pay a price premium to get us – always a great aspiration), then we must convey our value proposition in their coordinate system of value. We are engineers, so we measure things … even when they are in the customer's coordinate system of value.

Here's a little complication: almost always, there is more than one “customer.” There will be multiple influential people within the buying organization, multiple influential people within the user's organization, and multiple influential people in other places. We must therefore determine the “coordinate system of value” for each of these people and/or groups. Usually, the needs and desires of these various groups will be in conflict in some ways. We must resolve that, through balance; we must convince them that our proposed balance is the best possible outcome.

That seems like a lot of trouble. Can't we just ask the customer what would constitute a set of differentiators?

The conventional wisdom, of course, it that “the customer is always right.” My view is different: my experience suggests that many customers are so busy operating their mission that their view of the future is “three minutes from now.” They know well what they do now (and you should learn from that), but you usually cannot depend on them to create an effective vision for revolutionary future improvements.

In any case, if they did it for you, they would have to share that information with all of your potential competitors (in a competition, the customer will try to be sure that they are providing all of the bidders the same information, so that the competition is fair). And, since all of the potential bidders could avail themselves of that knowledge, this would deprive you of any potential differentiation from your competitors!

But if you create a vision for the future for the customers – and then convince them that it is valid, valuable, and feasible – they need not share that information with the other bidders, and therefore the differentiators that we create can provide you with competitive differentiation.

Now let's return to the meat of the discussion: how to choose those desired differentiators.

When the competition is finally over, the customer will have a set of reasons for why they selected a particular offer. In competitions for US Government contracts, the Government will actually tell you in advance what the “source‐selection criteria” are going to be:

• It might be price. City governments do this when buying a commodity, or a low‐tech service (such as repairing potholes in streets).
• It might be the lowest price among those technically acceptable. In this situation, bidders whose offer does not seem credible, who don't have qualified people, who don't seem to understand the problem, and so forth, are eliminated from the competition before the customer looks at the prices offered by each bidder. They will then select the lowest‐price bidder among those left.
• For most engineered systems, however, the source‐selection criteria are something more complicated: an approach called best value, which consists of what – in the judgment of the customer – seems to be the most advantageous combination of price, capability, risk, schedule, credibility, and contractual terms.

Since the customer has criteria for how they are going to select the winner, you must be able to credibly show that your proposal is superior in a set of factors (some of which are quantifiable; price is certainly quantifiable) that relate to those criteria. And remember the want factor too. You therefore need differentiators for each of the following:

• The explicit source‐selection criteria
• The unstated source‐selection criteria
• The “want factor.”

The general process for selecting differentiators that I use is as follows:

• Understand the customer's point of view:
  • What they do now, and why they do it that way
  • What they have tried and rejected in the past
  • Their “unwritten rules.”
• Use this to derive a statement of what they value.
• Use that to create actual quantifiable metrics (the operational performance metrics) that can express the goodness of a candidate solution in their coordinate system of value.
• Now that you have metrics that reflect the customer's coordinate system of value, you next (and this is the critical step) create ideas for what the system ought to do to score well against those metrics; these are the core of your potential differentiators. I do this by creating alternative versions of the mission threads, and by working through the process depicted in the matrix that constitutes Figure 5.5.
• Socialize the above with the customer, continuously.

You must plan where you want to achieve differentiation. You must figure out in which factors you want to be superior, and in which factors you are content to be even with the competitors (it might cost too much to be superior in every factor). Those factors where you intend and plan to be superior to all other competitors are your intended differentiators; you might prioritize your differentiators, so that you have primary differentiators and secondary differentiators (Figure 5.4).

Remember, if the customer has identified something as an explicit need (usually, by writing a mandatory requirement), every bidder will claim that they are doing that. Therefore, the mere fact that you are meeting a requirement cannot be a differentiator. It may be, however, that there is something superior about how you are implementing that requirement (e.g. something about your design that lowers risk, provides more design margin, or some other characteristic that is of benefit to the customer). That how may be an opportunity for differentiation. This is a frequent mistake that I see teams preparing competitive proposals make over and over again: they believe that the mere fact that they are meeting a mandatory requirement can constitute a differentiator. That is never true.

One way to test the effectiveness of your candidate list of differentiators is to write the briefing slide that you imagine the customer would use to brief their boss about why they chose you over the other competitors.

To guide the overall process of creating and proving differentiators, I use the matrix depicted in Figure 5.5.

The first column lists the key customer wants and needs. These, of course, are usually measured by operational performance measures, rather than by technical performance measures. The matrix works its way through a series of topics and questions; when you have completed every column for each of your desired differentiators (e.g. one row per differentiator), you are ready to start socializing them with your customers.

Examples of questions to ask the customers during the socialization process are:

• “If we could do this, would it help?”
• “What would constitute adequate proof that this idea is credible?”

Such socialization is a long‐term process, never accomplished in a single meeting.

A word about where to look for potential differentiators. I find that most people today think that competitive differentiation comes from improved technology. I believe that this is generally wrong, on two counts:

1. Technology by itself tends to provide small, incremental improvements (this year's disk drive has 15% more capacity than last year's, and costs the same). But systems are expensive, and no one buys big expensive systems to get small incremental improvements.
2. And even if a specific set of commercially available technologies provides a big improvement, they are probably available to the other competitors, and therefore do not provide competitive differentiation. You must look elsewhere for the differentiation that you need in order to win.

Of course, if you have a proprietary technology, that will not be available to your competitors. But the first point still applies; my experience is that big improvements tend to come from changing the business process of a mission (which we represent in the mission threads), rather than solely from improved technology. This is not at all the “conventional wisdom,” but that is fine by me; it gives me the opportunity for differentiation from my competitors!

Let me say that again: in my experience, instead of coming from technology, the differentiators seem to come from improvements to the mission threads. Only after you have created the specific ideas for what the system must do in order to create that differentiation (by creating the new mission threads) do you start to think about technology. The role of technology is seldom to create differentiation; instead, it is to make the implementation of your desired differentiation feasible. Your differentiation comes from the improved mission thread; that will usually relate directly to the operational performance measures, and therefore be credible to the customers.

Having differentiators is necessary, but not sufficient. The step of socialization with customers is also vital. As I have said previously, most of us can be counted on liking our own ideas, but are far less open to the ideas of others. Therefore, in order to get the customer to like your idea, you need to allow it (at least, in part) to become “their idea.” My phrase for this is that I want to transfer emotional ownership of the idea to the customer. Then it is (at least in part) “their idea,” and they are far more likely to fight for it!

There are many ways to accomplish the transfer of emotional ownership:

• Joint brainstorming
• Collaborative research, under some sort of formal agreement
• Grant generous intellectual property rights
• … and many, many others.

A few examples of actual differentiators will probably help. Here are some that I have created over the years:

• Example 1. Prescribing drugs
  • Desired differentiator: Significantly decreased number of deaths due to adverse interactions among multiple prescription drugs taken by a patient.
  • Associated operational performance measure: Patient deaths per year in the United States, due to adverse interactions among prescription drugs.
  • Discussion: When we started, the number of deaths due to interactions among prescription drugs in the United States was estimated to exceed 100 000 per year. We were able to show that our improved system for managing and monitoring the prescription process would avoid a majority of of those deaths. As a result, our approach was eventually adopted, despite intense resistance by doctors.
• Example 2. The US Army's Blue‐Force Tracker
  • Desired differentiator: Significantly improved land combat power, at a modest cost (e.g. a small percentage of the cost of the brigade's equipment, and far less than competing approaches to obtain a similar increase in combat power).
  • Associated operational performance measures:
    • The loss‐exchange ratio, a direct measure of improvement in combat power.
    • The ratio of the cost of fielding the Blue‐Force Tracker to the entire Army, versus the cost of upgrading every tank in the Army.
  • Discussion: We were able to show that the Blue‐Force Tracker would provide far more increase in combat power than a particular anticipated upgrade to the fleet of tanks. After conducting its own modeling efforts, and a series of large‐scale, unscripted, force‐on‐force exercises, the Army accepted this estimate. The Army's own assessment showed that the anticipated cost of developing and fielding the Blue‐Force Tracker to the entire Army was far less than the anticipated cost of fielding the upgrade to the tanks. As a result, the Army funded our Blue‐Force Tracker, and elected to upgrade only a small number of the tanks an Army‐wide upgrade of the tanks.
• Example 3. The US Army's short‐range air defense
  • Desired differentiator: Significantly increased number of enemy aircraft shot down, while still never shooting down a US aircraft
  • Operational performance measures:
    • “90% of the time, the correct target shall be in the narrow field of view of the weapon's optic, and correctly enter auto‐track” (remember Chapter 2!)
    • Ratio of achieved shot opportunities (that comply with the rules of engagement) with and without the system, against a set of standardized scenarios.
  • Discussion: We were able to show a better than 5× improvement in the number of shot opportunities achieved for a set of standardized, realistic scenarios, as proven through free‐play field exercises, while also meeting the “90% in the narrow field of view” measure, which ensured that US aircraft would not be shot down.

This creation of differentiators all sounds pretty complicated. Why not instead just aim always to be the lowest‐priced bidder?

First of all, you might be the lowest‐priced bidder and still not win. If this is a best‐value competition (as are most competitions for complex, engineered systems), and I have made the customer want my system through the creation of strong and credible differentiators, I will likely win even if your price is lower than mine. I once won a large contract for an engineered system, even though my bid was for twice as much money as any of the other bidders. Also notice that most of the cars sold in the United States are not the lowest‐price model, and that Apple sells more phones that their lower‐priced competitors. Lowest price is not a reliable path to winning!

Furthermore, life is not always pleasant for those who aim to win only by being the lowest‐price bidder. You might be forced to bid such a low price that you can't make a profit; you can't pay your employees enough to attract and retain good talent; you can't provide benefits (vacation, retirement, sick‐pay, medical insurance, suitable offices, etc.) to your employees sufficient to attract and retain good talent; and so forth. In my experience, you cannot build a great business around only being low cost.

But what about WalMart? Didn't they do exactly that? Actually, no. They do use their automated supply‐chain management tools to try to achieve costs below their competitors. But they do many other things too; things that cost a lot of money, and thereby actually drive up their prices! For example, they have lots of locations, because they believe that having locations nearby is convenient for (and important to) their customers and potential customers. They also do many things that they believe improve the quality of the shopping experience: lots of free parking, greeters at the front of the stores, lots of checkout lines, no‐hassle return policies, and many others.

They clearly believe that these items (even though they drive up their prices!) are an important part of their selling strategy – their differentiation! They pioneered many of these things, most especially the no‐hassle return policies. I believe the most important single ingredient to WalMart's original success was their no‐hassle return policies, not their prices.

Figure 5.6 summarizes my key suggested steps to winning.

In contrast, Figure 5.7 summarizes some of the typical mistakes that I see over and over again; these cause you to lose competitions for project contracts that you could have won.⁹

While we are talking about mistakes, I want to say something about the topic of past performance. The buying customer for a complex engineered system will certainly want to understand how your company has performed on previous contracts. Did you finish the contract on time? On price? Did you deliver everything that was promised in the contract? Did the users find the system suitable, as well as effective (remember that we defined these terms in Chapter 3).

The buying customer will also try to determine if some of these previous contracts on which your company has performed are relevant as indicators of how well you are likely to perform on this contract. Are some of those previous contracts of the same order of size and complexity as this new system? Do some of those previous contracts involve similar capabilities and/or make use of similar technologies as this new system? Are there portions of those previous systems that can credibly be repurposed by your company for this new system? Are some of the key technical personnel that contributed to the success of those previous projects committed by name to this new project? Your company is likely to be claiming all of these things, in order to show that you will be a reputable supplier, and that the low price you are bidding is credible.

In my experience, however, companies often seriously hurt their proposals through overly broad and overly generic claims about past performance.

How do proposal writers hurt themselves in this manner? First of all, customers are in fact not particularly interested in the fact that you solved some different problem for a different customer; they want only to know about your approach to solving their problem. They will also want to know why your approach for doing so is feasible and credible.

Therefore, you must tell them first how you will solve their specific problem; this is based, of course, around your design for their system, and your methodology for organizing and conducting the work: the tools you will use, and so forth. Past performance has nothing whatsoever to do with establishing this part of your proposal story.

Then, you must convince them that your design and methodology are feasible and credible. This is where past performance comes in: you successfully built the XYZ system for customer ABC last year, and it uses three of the same critical algorithms as you are proposing for this system. This provides a credible method for you to show the performance of those algorithms: you can run actual benchmark assessments on the XYZ system. This shows that your staff know how to properly code those algorithms in software. It might even back up your claim that you can reduce risk and cost a bit (but don't exaggerate how much) by reusing some of that software in the new system. And so forth.

What is to be avoided is the overly broad claim (e.g. “Our company built the XYZ system, so of course we can build your system”). The customer only cares about their system, and is far less willing to believe than you might expect that the experience of building the XYZ system for a different customer will be relevant to their system. You must prove, via tangible examples, every single step of relevancy, as described in the previous paragraph. If you are too broad in your claims, or too generic, you will create an air of charlatanism among the buying customers and the users, and end up not being believed, not just about past performance, but in other portions of your proposal too.