In This Chapter

Every opportunity for a government contract begins with a problem to be solved, and every good proposal created to win a government contract must offer a solution to that problem. The technical volume is the portion of your proposal that describes that solution.

The technical volume says not only what you’re going to do but also how and when you’ll do it. Working in consort with the management volume (explained in Chapter 17) and the cost/price volume (covered in Chapter 18), the technical volume is where you build your case for why your company can not only do the work and offer the product or service needed but can also do it better, faster, smarter, or in any other way that blows the competition out of the water.

The first question in creating the technical volume is, “How are we going to organize a solution to the customer’s technical problem?” Your first reaction might be to organize your response in the way it’s laid out in Section C of the solicitation (see Chapter 14). But this is not a good path to take, because the correct answer is that you need to stick with your proposal plan. Pay particularly sharp attention to your attachment 05 Proposal Outline and RAM. This shows that the correct precedence is: First by Section L (Instructions, Conditions, and Other Statements), then within L, by Section M (Evaluation Factors), and then within that, by Section C (Descriptions/ Specifications/Work Statement).

Your technical people are typically the leaders of the technical volume as they are the ones who create technical solutions and have responsibility to describe that solution. Technical writers and others who are not subject matter experts may assist them, but your technical people are in charge of the technical content.

The technical team does not work in a vacuum, however. Coordination among the different volumes is a must as your solution in each volume must match your solution in the other volumes. So cooperation across teams is an absolute requirement. This coordination is best achieved by having everyone physically working in the same location. Rubbing elbows, having impromptu hall conversations, and seeing each other’s outlines and storyboards are all part of the process that is only possible when everyone’s in the same place.

Unfortunately, but typically, the technical experts from your team will resist following the proper order. They would like to give solutions organized either in the Section C order or in some other way that they think makes better sense. However, neither of these is correct. You must use the outline provided by Attachment 03, as created by the proposal manager and the PM’s staff.

The leading paragraphs of your technical volume should describe the conceptual level of the technical solution that is a part of your program plan. So before you launch into a detailed response, give enough of an overview of your solution that the readers and scorers can have an idea—a road map—of where you’re going. Using a clear, but simple visual is a start. (Don’t overwhelm your evaluators with the nitty-gritty details at this level.) A succinct, powerful summary of the technical solution goes a long way to getting a high score on this volume and ultimately a contract award.

Remember, also, that your technical volume is not only about how you are going to carry out the solution but also when you will do it and over what time frame with what sort of schedule. That’s why your “Schedule for Delivery of Products” is so important. This schedule answers the customer’s implicit question, “When am I going to get my stuff?” (See Chapter 12 for a discussion of the 03 Executive Summary and the “Schedule for Delivery of Products,” an important part of the executive summary.)

When presenting your solution, you’re not simply responding to what’s in the solicitation, but rather you’re crafting a response that reflects the procurement, that is the bigger picture context of what has led the customer to the point of having this opportunity—the real problem to be solved. (See Chapter 8 for differences between the solicitation and the procurement.) You’ll be able to describe your solution in a broader context of the procurement if you’ve gained that insight through many pre-solicitation contacts with the customer, including most prominently the technical and marketing interchange.

Two audiences, not just one, will read your proposal, so you must win over two different sets of readers. Those two will be reading and reacting to your proposal in two different ways.

Your first audience is the decision-maker or team of decision-makers, the people who will make the award decision. These decision-makers are interested in concepts and leave the detailed scoring work to others. The impression you must make with a decision-maker is that you do understand the customer’s problem and have a well-planned, comprehensive solution described in your proposal. In the best case, the decision-maker knows the top management of your company. Let’s say your top management is led by Pat. The reaction you want to elicit in the decision-maker after reading your proposal is, ”Good ole Pat came through for me.”

The decision-maker is interested in concepts, not details. That’s why, in the opening paragraphs of your technical volume, you “describe your solution using both words and graphics or visuals. Your plan is to have the decision-maker understand your solution, embrace it, and like it.

The proposal scoring audience members are the individuals charged with evaluating proposal submissions in great detail. Some evaluation teams are made up of “scores of scorers,” with many people doing the evaluation. But for smaller opportunities, there may be only a small handful of scorers on the team.

The mechanism for evaluation is a set of scorecards or score sheets. Each section of the incoming proposals has a matching scorecard, which the customer evaluation team has created in accordance with the solicitation. These cards are not opportunities for creativity but are products of brute force, matching the solicitation to the incoming proposals and weighted consistent with the stated evaluation factors.

The reaction you want to illicit from this audience is, “This is the proposal against which we will judge all others.” You can get this reaction only by strictly adhering to the solicitation sections and in the L, M, C order. Anything else will be inconsistent with the scorecards, and will therefore mean more work for the evaluators. More work for them will undoubtedly result in lower scores for your team.

Anyone can claim they’re going to do something. They can describe a solution and use fancy words and impressive language to claim that they can do it. But if you go on to show, not just tell, you can be much more convincing. Showing can be in the literal sense with visuals that feature your products or service process or demonstrate the flow of your program plan. But showing can also mean describing how you will carry out the solution, not just what the solution is.

The mind thinks in pictures, so use a picture of the device you’re delivering if your solution is complex. Show a high-level system architecture diagram of a large network, or show a flowchart of processes you’re using. What is the most prominent feature (and benefit) of your solution? What characteristic of your solution makes yours stand out above all the noise and details? All these are candidates for helping to explain your solution in terms easily understood by the evaluators.

You can almost say that the proposal that communicates the technical solution most clearly, in visuals, is the one the evaluators will reward with a contract.

A good proposal is a good plan, and vice versa. So your technical solution should show not only that you plan to do something but also how you plan to do it.

This list suggests possible ways you can use to describe just how you plan to do it, where “it” is the customer’s work. All these are simply placeholders, examples of the form of your themes, so it’s unlikely you will be able to lay claim to these exact phrases in your own technical volume:

When you’re really stuck as to how to describe your solution and all else has failed, you can always turn to risk assessments. Very often, those speaking or writing about “risk” are guilty of fuzzy thinking as the term “risk” by itself is unclear. Because there are three distinct types of risk, it’s important that speakers and writers be clear about which type or types of risk they mean.

In an old urban legend, a contractor was asked, “What can you deliver?” and the answer was, “Quality. Schedule. Cost. Pick any two.” There’s certainly truth in that response as trade-offs are often made among these three. If a customer is pushed to the wall, it’s then necessary to choose which of the three to sacrifice. For example, if the program is in trouble and is unlikely to be completed satisfactorily (the product works as specified), on time (consistent with the program schedule), and within budget (for the money stated in the contract), a reasonable way to solve this would be to have the customer choose among these alternatives:

Making that choice is not something you want to force your customer to do. So your technical solution should address these three types of risk individually and then as a set. This will give the customer confidence that you truly do understand the seriousness of the work and that you are fully prepared to achieve the desired results, on time and within budget.

Whatever else you do in creating the technical volume, take care to avoid the mistakes discussed in the following sections.

A “zero-content solution” means that when stripped of the fancy words and all the fluff, your proposal doesn’t say how you’ll do the work or that you have any idea about the work (except what’s in the solicitation). It only says you’ll do the work. Then you fill up space by embellishing the response with claims of previous successes, which might be interesting, but the customer really wants to know how you’re going to do this job.

A well-written solicitation might contain a phrase, usually in Section L, that specifically admonishes the offerors to avoid this mistake. The phrase to look for is something like, “Responses stating that you understand and will comply are nonresponsive.” Even if the phrase isn’t in this particular solicitation, pretend it is, and avoid at all costs solutions that are high on verbiage and low on specifics.

Among the most common and most serious mistakes is the gratuitous substitution of your own terminology for the customer’s. If the customer calls the head person on this contract “Project Manager,” then you call that person “Project Manager.” Never mind that, in your company, project managers get promoted to program managers, and therefore someone who is—within your company—a program manager may resent being “demoted” to a project manager. Again, play back the customer’s language in everything you do in the proposal. Absolutely nothing good happens when you change labels, because changing labels is a sign of technical arrogance, which will be punished by the customer evaluators.

Don’t assume all the evaluators know as much as you do about the subject matter, as the evaluators will come from many different places in the customer community. Some evaluators may be very highly technical; others may be simply someone not on an alternate assignment with a higher priority. You may get entry level evaluators or ones with management expertise. Make your writing simple enough to resonate with all the evaluators. An evaluator who can’t understand what you’re saying is very unlikely to give you a good evaluation.

The Least You Need to Know