1

Overview

A statement of work (SOW) is the written description of an agency requirement, used in the acquisition of supplies or services. The Federal Acquisition Regulation (FAR)¹ mandates that government requirements be described in a manner that promotes full and open competition to the maximum extent practicable and that restrictive provisions or conditions be used only to the extent necessary to satisfy the needs of the agency or as authorized by law. The FAR² goes on to say that requirements should be stated in terms of the functions to be performed, the performance required, or the essential physical characteristics of the requirements.

WHAT IS A STATEMENT OF WORK?

Although commonly used throughout the government, the term “statement of work” is not defined in the FAR. The FAR uses the term “work statement” when discussing research and development (R&D) contracting and uses the term “statements of work” in the coverage of performance-based contracting, but no specific definition is provided. For our purposes, the term “statement of work” is used in this book to refer to the document that completely describes the contractual work requirement. Unless otherwise noted, the term also encompasses the term “performance work statement” (PWS) used in performance-based service contracting (PBSC).

To put the term “statement of work” in the context of the FAR language, the following are some of the terms that the FAR uses when discussing the description of a work requirement:

• Specification. A specification is a description of the technical requirements for a material, product, or service that includes the criteria for determining whether these requirements are met. Specifications state the government’s minimum needs and are designed to promote full and open competition, with due regard to the nature of the supplies or services to be acquired.

  The two sources of formal government-approved specifications are: (1) the General Services Administration Index of Federal Specifications, Standards, and Commercial Item Descriptions, which lists federal specifications and standards that have been implemented for use by all federal agencies, and (2) the Department of Defense Index of Specifications and Standards (DODISS), which contains unclassified federal and military specifications and standards, related standardization documents, and voluntary standards approved for use by DoD.

• Standards. Standards are documents that establish engineering and technical limitations and applications of items, materials, processes, methods, designs, and engineering practices. Standards include any related criteria deemed essential to achieve the highest practical degree of uniformity in materials or products, or interchangeability of parts used in these products. Formal government-approved standards are found in the documents listed above.

  The FAR³ states that agencies shall select existing requirements documents or develop new requirements documents that meet the needs of the agency in accordance with the guidance contained in the Federal Standardization Manual, FSPM-0001; for DoD components, Defense Standardization Program Policies and Procedures, DoD 4120.24-M; and for IT standards and guidance the Federal Information Processing Standards Publications (FIPS PUBS).

• voluntary Consensus Standards. Voluntary consensus standards are standards established by a private sector body (other than a private standard of an individual firm) that are available for public use. The FAR⁴ states that in accordance with OMB Circular A-119, Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities, and Section 12(d) of the National Technology Transfer and Advancement Act of 1995, Pub L. 104-113 (15 U.S.C 272 note), agencies must use voluntary consensus standards, when they exist, in lieu of government-unique standards, except where inconsistent with law or otherwise impractical.

• Purchase Description. A purchase description is a description of the essential physical characteristics and functions required to meet the government’s minimum needs. A purchase description is used when there is no applicable specification that adequately describes the requirement. This term is usually associated with acquisitions using simplified acquisition procedures.

• Product Description. The term “product description” is a generic term for documents such as specifications, standards, and purchase descriptions.

Each of these terms addresses only part of a complete description of a contractual requirement, generally just the technical requirement. A complete description would include what you want to buy; why you want to buy it; where the work is to be performed; when the work is to be performed; what the work is to accomplish; what, how much, and when it is to be delivered; and how the government will determine that the work has been performed satisfactorily. The SOW encompasses all of these elements and may, as appropriate, include other documents such as specifications, standards, voluntary consensus standards, and purchase descriptions.

IMPORTANCE OF THE SOW

In the past, the government stressed the use of formal government-approved specifications and standards when describing requirements; however, that is no longer the case. Current policy encourages the acquisition of commercial items (i.e., any item, other than real property, that is of a type customarily used by the general public or by non-government entities for purposes other than governmental purposes) or non-development items (i.e., previously developed items or previously developed items that require only minor modifications of a type customarily available in the commercial marketplace). In other words, government agencies now must first consider acquiring supplies or services available in the commercial marketplace rather than using government specifications and standards.

Agencies are now permitted to choose whichever requirements documents they deem to be most suitable. They may use existing requirements documents (federal or DoD specifications and standards), modify or combine existing documents, or create new requirements documents. When creating new requirements documents, the FAR⁵ cites the following order of precedence:

1. Documents mandated for use by law

2. Performance-oriented documents (e.g., PWS, SOO)

3. Detailed, design-oriented documents

4. Standards, specifications, and related publications issued by the government outside the Defense or federal series for non-repetitive acquisition of items.

This book is written primarily for those who develop SOWs for negotiated procurements. While the principles of developing an SOW are the same regardless of the method of procurement, certain caveats apply with respect to sealed bidding. These are addressed at the end of Chapter 5.

NEED FOR A CLEAR AND CONCISE SOW

An SOW is usually developed by the person responsible for ensuring that an activity’s technical requirements are met (i.e., the requisitioner), with the support of contracting personnel. Because the SOW describes the contractual work requirements, it is the heart of the procurement action and must include a clear and concise description of the work requirement. Developing the SOW is, without a doubt, the most important step in the procurement process. A poor description of the work requirement is likely to be misunderstood, leading to—if not causing—problems throughout the procurement process and subsequent contract performance. Although a clear and concise description of the work does not guarantee the contract will be successful, it does significantly reduce the likelihood that problems will arise.

The author of the SOW is usually part of the organization for whom the work will be performed and therefore has a vested interest in the quality of the SOW. If the SOW does not work, the project may fail. Because it usually takes longer to solve a problem than it does to avoid one, it makes sense to take the time to do it right initially.

A clear and concise SOW is essential both before and after contract award and serves three main purposes:

• Establishing performance standards and a contractual baseline

• Providing the contractor with a basis of estimate

• Communicating effectively.

Before Award

Contractors must understand the SOW requirements to be able to develop their technical, management, and staffing plans and to price the proposal properly. The SOW in the request for proposals (RFP) is the only official description of the work requirement. Accordingly, it must provide prospective contractors enough information to develop and price the proposal—without the need for further explanation. A clear and concise SOW helps ensure the receipt of a well-written proposal. It also establishes a uniform basis for evaluating proposals (matching the proposed effort to the stated technical requirement) and for comparing prices.

If questions about the SOW arise during the solicitation process, you must answer them, but use care when providing explanations. Oral explanations, unless put into writing as an amendment to the SOW, are usually not binding. Refer the questions, along with the appropriate answers, to the contracting officer for an official response.

If deficiencies in the SOW are identified before award, the RFP must be amended to correct the deficiencies immediately and prospective contractors must be given additional time to consider the corrections and make appropriate revisions to their proposals. Do not wait and make the corrections after award. Keep the pricing of the corrections in the competitive pre-award environment; modifications after award are likely to cost more. Delaying changes until after award can also make your agency vulnerable to protests from unsuccessful offerors who perceive the delayed changes as favoritism to the successful offeror.

After Award

After award the contractor must understand the SOW requirements to be able to perform the work properly. The SOW in the contract is the only description of the requirement that the contractor is legally bound to follow. Accordingly, it must clearly and concisely describe what you want to buy and any special considerations or constraints that apply.

The SOW, as published in the contract, defines the contractual scope of work—the contractor is required to do only what is written into the contract. A poorly defined SOW therefore often results in a need for changes in the technical requirements, opening the contract to pricing and delivery changes. The number of changes and difficulties in negotiating their scope and price are usually directly related to the quality of the SOW. If the SOW is ambiguous or unclear and a dispute arises over contract interpretation, the courts will follow the contractor’s interpretation, as long as it is reasonable. The courts generally hold the originator of the SOW responsible for its clarity.

To Establish Performance Standards and a Contractual Baseline

The SOW, through its description of the work requirements, establishes the standard for measuring performance effectiveness and achievement both during contract performance and upon contract completion. The work description establishes goals that become the standards against which contract performance is measured. The SOW is not complete unless it describes both the work requirements and the criteria for determining whether the work requirements are met.

The SOW also establishes the baseline from which the degree, extent, and ramifications of proposed contract changes are determined. Proposed changes are checked against the SOW to determine if they are within the scope of the contract. If the proposed change is within the scope of the contract, the change is handled by a contract modification. If it is not within the scope of the contract, a new contract is required. The clarity and conciseness of the SOW are, therefore, important throughout the life of the contract.

To Provide Prospective Contractors with a Basis of Estimate

Prospective contractors need sufficient information on which to base the estimated cost of contract performance. This information or “basis of estimate” is provided in the SOW through the description of the task requirements, a statement of the estimated level of effort required (when appropriate), or both.

Contractors develop cost estimates based on the work description in the SOW. First, they break the work description down into its smallest components, and then, starting from the bottom up, they develop estimates of the resources necessary to complete each component of each task. Cost figures are developed for the estimated resources required. Overhead and general and administrative (G&A) expenses are added to make up the total estimated cost. Profit or fee is then added to the total estimated cost to come up with the total estimated price.

Therefore, the work requirement must be described in a manner that will enable prospective contractors to develop an accurate cost estimate. This is important. If the successful offeror’s estimate is too high, you will pay more than you should for the contract effort. If the estimate is too low, the contract requirement will be underfunded. If your contract is cost-reimbursement, underfunding usually results in a contract modification for additional funding or in contract termination. If your contract is fixed-price, underfunding puts the contractor in a loss position, because the contractor must complete the effort regardless of its own costs. Contractors in a loss position will try to minimize their losses by cutting corners or making contract changes, if they can. Cutting corners adversely affects the contract quality, and changes usually increase the contract cost. Neither of these actions is in your best interest.

A well-written SOW is no guarantee that the contractor will develop an accurate cost estimate. Many requirements (such as studies, analyses, R&D, and software development) are inherently difficult to estimate because of the nature of the work. Therefore, it is important to write the SOW as accurately as possible. A well-written SOW helps minimize the differences between estimated and actual costs by providing the offeror with the best possible basis for cost estimating.

To Communicate Effectively

The SOW is ultimately a vehicle for communication. It must communicate your requirement in a manner that can be understood by all personnel involved in the solicitation process as well as those involved in contract performance. This includes government as well as contractor personnel. Various people must read and understand the SOW during the course of the solicitation, award, and performance of the contract. These include the contractor’s technical personnel, accountants, and cost estimators; government accounting and auditing personnel; government and contractor legal and contracting personnel; and subcontractors. Readers must be able to understand the requirements without having to interpret, extrapolate, or otherwise guess at the SOW’s meaning.

It is a mistake to use the SOW language as a test of a contractor’s ability to understand the requirements by writing a broad and generalized SOW just to see how contractors will respond. Misunderstandings may well be carried through into contract performance. The SOW must be written clearly and simply. The quality of the SOW directly affects the quality and pricing of the contractor’s proposal and, eventually, the quality of the contractor’s performance.

Before addressing how to write an SOW, however, it is necessary to discuss two other topics: the relationship of the SOW to the solicitation and contract, and the use of proposal preparation instructions with respect to the SOW. You need to understand how the SOW fits into the solicitation and contract and how it affects other parts of the solicitation. You also need to understand the relationship of the SOW to the proposal preparation instructions and how you can use them most effectively.

RELATIONSHIP OF THE SOW TO THE SOLICITATION AND CONTRACT

Two types of solicitations are used in government contracting (other than simplified acquisition procedures). If the procurement is negotiated, an RFP is used. If the procurement is by sealed bidding, an invitation for bids (IFB) is used. Both use the same format, but the contents—primarily the solicitation provisions and contract clauses—are different. This is true of both the solicitation and the resulting contract.

During the solicitation process, contractors use the SOW to develop and price their proposals; the government then uses the SOW in evaluating the proposals. The SOW also serves as the basis for information in other sections of the solicitation document. After award, the SOW becomes the only basis for contractual performance. Thus, the SOW is a key document from initiation of the procurement process through completion and final close-out of the contract. Understanding the format and content of the solicitation and contract is therefore crucial to developing an effective SOW.

Format and Content of the Solicitation and Contract

Solicitations and contracts are written using the uniform contract format established by the FAR.⁶ This format organizes the solicitation and contract into four parts, as shown in Figure 1-1, and makes it possible to use the same document as both a solicitation and a contract.

Parts I–III of the RFP make up the contractual document. In Part I, Section A is a standard form; Section B itemizes the required supplies or services; Section C contains the SOW; and Sections D through H contain specific clauses related to the topic of each section. As part of the contractual document, the SOW describes only those actions that take place after contract award. Do not include any information related to the solicitation process in the SOW. Part II contains the standard contract clauses related to the type of contract and what is being procured. Part III contains a list of those documents or exhibits that are attached to the RFP. It is not unusual for a lengthy SOW to be referenced in Section C and included in Section J as an attachment.

Part IV of the RFP is the solicitation portion. It contains information related solely to the solicitation process. Section K describes the information that the contractor must provide to establish its eligibility for award of a government contract. Section L contains solicitation provisions related to the terms and conditions of the solicitation and the proposal preparation instructions (instructions related to the form and content of the contractor’s proposal). Section M contains the evaluation factors and information about how the proposals will be evaluated.

FIGURE 1-1:
Contents of the Request for Proposals/Contract

The entire document (Parts I–IV) is used during the solicitation process by the prospective contractor to develop its proposal and pricing, and by the government to evaluate the contractor’s proposal. When the contract is awarded, the solicitation portion (Part IV) is deleted. Section K is incorporated into the contract by reference and retained in the official contract file. Sections L and M can be discarded because they do not apply to contract performance. (In practice, however, a copy of Sections L and M is usually retained for reference purposes.)

As indicated by the arrows in Figure 1-1, the developer of the SOW is primarily interested in the development of Section C, the SOW, and Sections L (proposal preparation instructions) and M (evaluation factors). The contracting officer is responsible for developing the remaining coverage in the solicitation and contract; ultimately, the contracting officer becomes responsible for the entire solicitation and contract.

Relationship of the SOW to RFP Sections L and M

Responsibility for developing the SOW usually includes responsibility for developing the proposal preparation instructions in Section L and the evaluation factors in Section M. The SOW and RFP Sections L and M are directly related in several key ways, as illustrated in Figure 1-2. These relationships should be kept in mind when developing the SOW.

FIGURE 1-2:
Relationship of the SOW and RFP Sections L and M

Section M of the RFP contains information about how proposals will be evaluated, including the evaluation factors and their relative importance. The evaluation factors and their relative importance are developed by analyzing the SOW to identify those aspects of the requirement that are most important to the accomplishment of the work. These generally fall within the areas of technical, management, corporate experience, and cost, but the specific description and their relative importance depend on the contents of the SOW. The evaluation factors are set forth in Section M in descending order of importance, along with an indication of the relative importance of each factor. Publication of this information ensures that contractors understand how the proposals will be evaluated and that they will tailor their proposals to address those areas that you consider most important.

Section L contains the solicitation provisions appropriate to the requirement and the proposal preparation instructions. The proposal preparation instructions provide guidance on how you want contractors’ proposals organized and how to identify information that you want the contractor to provide. The proposal preparation instructions are used to amplify the evaluation factors in Section M and the work requirements in the SOW. The proposal preparation instructions provide an outline for the proposal format based on the evaluation factors listed in Section M. They identify the specific information required in support of each evaluation factor and specify other constraints, such as page limitations.

USE OF THE PROPOSAL PREPARATION INSTRUCTIONS

The term “proposal preparation instructions” encompasses all information provided to a contractor regarding the format and contents of its proposal. Although this term is not in universal use in federal contracting, it is used here to describe the consolidation of all proposal preparation information in one clearly identifiable place in the RFP. If communication is to be effective, all information of a similar nature should be grouped and presented in the same place.

Proposal preparation instructions are used to ensure that prospective contractors submit proposals that facilitate full evaluation of each offeror’s expertise and ability to perform the required work. Generally, these instructions are for guidance only, but you may want to make compliance mandatory for some instructions, such as paper size, type size, font style, and particularly page limitations. If you do, this must be spelled out in the proposal preparation instructions. While an offeror has the right to respond to a solicitation in any manner it sees fit, an offeror would be foolish to ignore the proposal preparation instructions; at the very least, doing so would reflect poorly on the offeror’s ability to follow instructions.

Proposal preparation instructions are used to: (1) ensure appropriate coverage in the proposals, (2) standardize proposal format, and (3) require the submission of specific information.

To Ensure Appropriate Coverage

The primary purpose of proposal preparation instructions is to ensure that each proposal addresses your areas of interest as expressed by the evaluation factors in Section M. The contractor should be required to structure its proposal in the same order of importance as the evaluation factors listed in Section M. For example, if the following evaluation factors are listed in Section M in descending order of importance, require that the proposals address the same factors in the same order. This ensures that the proposals will discuss your areas of interest in the same order and with the same level of importance as you will use in evaluation. For example:

Presenting Primary Evaluation Factors

Section M presents each primary evaluation factor with a title and a short narrative illustrating the salient characteristics of the factor. Your proposal preparation instructions should present each primary evaluation factor in the same manner. This is redundant, but repeating the narrative description from Section M reinforces the connection between Section M and the proposal preparation instructions. You may choose simply to paraphrase the narrative description in Section M, but if you do this, exercise care in your wording. A paraphrased description can confuse the offeror, particularly if paraphrasing causes the requirement to appear different than in Section M.

Presenting Significant Sub-factors

Sub-factors are used to amplify the primary evaluation factors; therefore, the sub-factors should be presented somewhat differently. The subfactor narrative begins with a general statement (the same as used in Section M) followed by a statement of the specific information requirements that support the subfactor. The specific information requirements will vary depending on the circumstances, but they should amplify the general statement, explaining what information you expect to see in the proposals.

Information requirements should specify both form and content. These requirements may address the submission of charts or graphs, a discussion of methods and methodology or specific technical considerations, technical or management plans and schedules, staffing levels and labor mix, and any other information you consider necessary to evaluate an offeror’s response to a particular evaluation sub-factor. If certain tasks in the SOW require specific supporting information, you should reference those tasks to ensure that the connection is made.

For example, in a requirement for a study, the technical factors and significant subfactors could be presented as follows:

• Technical [primary factor]

  Proposals will be evaluated on the basis of the soundness and workability of the proposed technical approach, the demonstrated understanding of the requirement, and the validity of the technical plan and proposed methodology [the same as set forth in Section M].

• Technical Approach/Understanding the Requirement [significant subfactor]

  The offeror shall demonstrate a sound and workable technical approach that ensures a high probability of successful performance. The offeror shall demonstrate its understanding of the requirement through the degree of thoroughness, soundness, and comprehension expressed by the proposed technical approach [the same as set forth in Section M].

  The offeror shall describe its technical approach in sufficient detail to demonstrate its soundness and workability. Identify the scope of the study and how its purpose will be accomplished. Provide an analysis of the complexity of the requirement and indicate how any anticipated problems will be identified and resolved [specific information requirement].

• Technical Plan/Methodology [significant subfactor]

  The offeror’s technical plan, schedule, and the methodology to be employed to identify, obtain, research, and analyze articles, reports, and other information sources will be evaluated for its appropriateness for this study and the extent of effort proposed [the same as set forth in Section M].

  The offeror shall fully describe its plan for its technical approach, demonstrating that it complies with the tasks set forth in the statement of work, including the phasing of tasks, scheduling of work effort, staffing, and the methodology to be employed. The discussion of methodology shall include the methodology to be used for data collection and that to be used to analyze the data and draw conclusions. Identify other methodologies that might have been applicable and indicate why they were not selected. Identify the proposed sources of information to be used and discuss the methods to be used to identify and obtain the information required. Indicate the volume of the anticipated research material and the research techniques to be used. Propose questions or areas of interest for the study when these are not provided in the SOW [specific information requirement].

The specific information requirements for technical sub-factors vary considerably depending on what is being acquired. Information requirements that would facilitate the evaluation of the offeror’s technical expertise and understanding of the requirement might include the following:

• Discuss specific work elements of particular interest (indicate if this information will be incorporated into the contract)

• Provide specific technical information such as graphs, drawings, charts, and other technical information needed for evaluation

• Discuss technical performance problems that the government has identified in the SOW or are otherwise known to the offeror and how they might be resolved

• Provide details of the proposed effort that demonstrate how the offeror will meet the requirement

• Discuss the proposed methodology or technical approach to be used, including an explanation of why the particular methodology or technical approach was selected, where more than one is available

• Provide a risk assessment that identifies risk areas and recommend approaches to minimize the impact of the risks on the overall success of the contract

• Provide a performance assessment, as appropriate, on past or current contracts that identifies contract performance problems and indicates how they were, or will be, corrected

• Define milestones or specific work schedules, including a work plan and performance schedule

• Propose details of scheduled technical meetings (e.g., purpose, when, where, who attends), when such meetings are dictated by the government in the SOW

• Discuss the technical data requirements and format

• Discuss the proposed quality assurance procedures

• Propose a test plan, including information on how the tests will be conducted and test results analyzed, if specific testing requirements are not dictated by the government in the SOW.

Providing a general statement followed by the specific information requirements ensures that the offeror understands how each sub-factor will be evaluated and that you get the information needed for evaluation. You must be as explicit as possible. Instructions that help offerors write their proposals are a plus, not a minus. You want offerors to write proposals that are responsive to your concerns. This makes the evaluation easier. At the same time, you should keep in mind that your job is to evaluate the offeror’s technical expertise and ability to perform the contract, not its proposal-writing ability.

The following are examples of how other evaluation sub-factors could be presented and some of the types of information that might be needed for evaluation. Tailor the specific requirements to the procurement. Do not list something as a requirement unless you are sure that you know how you would evaluate the information submitted.

• Management Approach

The general statement should require the offeror to provide a detailed discussion of its approach to overall management and integration of all activities required by the SOW. This discussion should also address the management objectives and techniques that demonstrate how the work requirements will be met.

Specific information requirements might include the submission of organization charts, discussion of the lines of authority and responsibility, a demonstration of how the proposed organization will be prepared to respond promptly to problems or program changes, how the proposed project manager will obtain support from other corporate elements and subcontractors, and his or her ability to access higher levels of corporate management. Other useful information might be how the offeror prepares its internal management reports and how long after actual performance this information will be available (this helps in developing a meaningful schedule for submitting reports to the government).

• Staffing Plan

The general statement should require the offeror to describe the proposed staffing plan, including how long it will take to staff the contract fully, and how peak workloads, overlapping or simultaneous task assignments, and sick and vacation leaves will be covered.

The specific information requirements might include a discussion of how the offeror’s resources are allocated, how the offeror plans to retain the proposed staffing levels, information on turnover rates and related recruiting efforts, and, when appropriate, how the offeror plans to maintain the required level of personnel with security clearances.

• Key Personnel

The general statement should require the offeror to describe the educational background, directly related work experience, professional development, and demonstrated performance record of the proposed key personnel.

Key personnel requirements and other resource requirements, such as minimum or maximum staffing levels, are not generally appropriate for performance work statements used in performance-based contracting (see Chapter 3). Such requirements tend to inhibit the contractor’s ingenuity in developing its approach to meeting the contract requirements. (This does not, however, prevent the government from evaluating the key personnel or other resource requirements proposed by the offeror.)

Specific information requirements usually include a description of what is required in the résumés of key personnel, such as information demonstrating that the individual meets the minimum qualification criteria described in the SOW. You should also obtain information on the current employment status of the proposed key personnel. If the individual is not currently employed full-time by the offeror, require a letter of intent or some other indication of the individual’s commitment to work under the contract, as well as an authorization to use the individual’s résumé in the proposal. You may also want the offeror to indicate the amount of time (usually as a percentage) that each key individual will devote exclusively to work under the contract. It is important to identify any other contracts to which the individual is committed, because you could have a problem if the individual is already fully or substantially committed to other work.

If past performance is also an evaluation factor, require the offeror to indicate any involvement of proposed key personnel with any of the contracts referenced for past performance. You may want to question the offeror about the involvement of proposed key personnel in a contract that receives an adverse past performance report. Such questions, however, should be reserved for discussions (after establishment of the competitive range) because, while the offeror’s response might require a proposal revision to name a different individual, it would not, in and of itself, require a proposal rejection.

• Corporate Experience

The general statement should require the offeror to describe the corporate experience that demonstrates the contractor’s ability to efficiently perform the tasks required under the contract.

The specific information requirements usually include a requirement for the offeror to demonstrate previous experience similar to the current requirement. Require the offeror to identify the contract number, type of work done, contract type and dollar value, and name and telephone number of the contracting officer’s technical representative (COTR) for each referenced contract. Require the offeror to demonstrate how each previous contract relates to the proposed effort. To ensure that the corporate experience is relevant, limit the time period for referenced contracts. The typical time periods used are three to five years, depending on how technological changes or other events may have affected the relevance of past contracts.

• Past Performance

The general statement should require the offeror to identify current or past contracts that identify the offeror’s ability to perform the required effort successfully.

The specific information requirements usually include a requirement for the offeror to demonstrate previous experience similar to the current requirement. Require the offeror to identify current and past contracts for the same or similar work, including the contract number, dollar value, dates, name of the contracting agency, a contact telephone number, and a brief description of the work effort that demonstrates how the referenced contract relates to the proposed effort.

Require the offeror to identify any performance problems with the referenced contracts and the corrective action taken to resolve the problems. Inform the offeror that if past problems are not addressed fully, the government will assume that they still exist.

To ensure that the past performance information is relevant, limit the references to current contracts and contracts that have been completed within the past three to five years, depending on how technological changes or other events have affected the relevance of past contracts.

Although past performance information is similar to the information required for the corporate experience evaluation factor, it will be evaluated differently.

Corporate experience is used to assess a contractor’s technical expertise and is typically evaluated on the basis of the contractor’s experience with the same or similar work. It is related to whether the contractor has done such work in the past—not how well the contractor performed. Past performance is used to assess the quality of the contractor’s performance and is typically evaluated on the basis of how well the contractor performed the same or similar work in the past and how that past performance is likely to affect the current effort.

• Cost or Price

Under cost or price, you should describe how you want the contractor to present its cost or pricing proposal. These directions will vary depending on the contract type and the estimated dollar value. For example, if the requirement is expected to exceed $550,000 and a cost-reimbursement contract is contemplated, the following might be appropriate.

The general statement should indicate that cost data must be fully supported, documented, and traceable. The data must identify the basis of the estimate for each cost element, discuss how it was developed and calculated, and indicate which are based on actual and verifiable data and which are based on projections. For projected cost elements, the offeror must discuss the judgment factors used to project from the actual and verifiable data to the estimated value. Any contingencies or allowances used in developing the proposed costs and prices must be identified and discussed.

The specific information requirements vary. The FAR⁷ states that if the submission of cost or pricing data is required, the contracting officer may require submission in the format indicated in Table 15-2 of 15.408, specify an alternative format, or permit submission in the contractor’s format. If information other than cost or pricing data will be required, it may be submitted in the contractor’s own format unless the contracting officer decides that use of a specific format is essential for evaluating and determining that the price is fair and reasonable, and the format has been described in the solicitation. If data supporting forward-pricing rate agreements are required, then the data supporting forward-pricing rate agreements or final indirect cost proposals should be submitted in a format acceptable to the contracting officer.

To Standardize Proposal Format

While the primary purpose of the proposal preparation instructions is to obtain information for evaluation, a secondary purpose is to make the evaluation process easier by standardizing the proposal format. Requiring adherence to the outline of the evaluation factors in Section M helps ensure that all proposals will present the information in the same format. Standardization makes the evaluation process easier because the evaluators will not need to search through differing proposal formats to find the necessary information. Standardization also assists offerors in their proposal preparation by eliminating the need for them to guess the proposal format that would be most acceptable to the government. This leads to better proposals.

Standardizing proposal format involves more than just providing an outline to follow. Standardization also includes establishing the number of proposal volumes, indicating the number of copies to be provided, setting page and type size preferences, and, when appropriate, limiting the number of proposal pages.

Proposal Volumes

Typically, the technical and management proposals are evaluated separately from the pricing proposals, by different evaluation teams. To permit both to be evaluated at the same time, offerors should be directed to divide their proposals into separate volumes. At a minimum, separate pricing and technical volumes should be provided.

Include a statement that pricing information is to be provided only in the pricing volume. This is necessary to protect the objectivity of the technical evaluation. Knowledge of the pricing can bias the results of the technical evaluation. In most instances, the technical evaluators know how much funding is available. It is difficult to evaluate a proposal objectively when you know that the proposal price is significantly higher or lower than the funds available.

As proposals become more complex, the need for additional proposal volumes increases. Often a management volume is required in addition to the technical and pricing volumes. Large, complex requirements may require additional volumes dealing with specific areas, such as specific tasks in a large, multi-tasked requirement. An examination of the evaluation plan can help determine how many volumes are required. If the plan indicates that a number of different evaluation teams will be evaluating different tasks, each team should have its own volume, if feasible.

In some instances you may want to include an executive summary as a separate volume. Be careful with executive summaries. They are not a substitute for close examination of the detailed proposal. Define this requirement carefully—make sure that offerors understand that the purpose of this document is simply to provide an overview of the proposal contents. Instruct offerors not to include pricing information in the executive summary. It is also a good idea to place a stringent page limit on this document.

Number of Copies

The number of copies to be provided is a function of the number of evaluation teams and how you will conduct the evaluation. Generally you should require enough copies so that each evaluator has a copy; however, if you do not plan to have each evaluator review each proposal, you will not need that many. Do not require more copies than will actually be used in evaluation. Proposals must be safeguarded in a manner similar to classified material—you do not want extra copies lying around.

Paper Size, Type Size, and Font Styles

Indicate the paper size, type size, and font style or styles to be used in the proposal. This helps avoid unnecessarily elaborate or hard-to-read proposals. Such standardization is also needed when page limits are used.

Paper size is usually established as the standard 8½ × 11 inches to discourage the use of legal-sized paper (which does not fit well into standard government files and provides an unfair advantage when page limits are dictated). You also may want to limit the size of fold-out pages. Fold-out pages are usually limited to non-text information, such as charts, tables, or diagrams, and the size is commonly 11 × 17 inches. Margins are often set at 1 inch. Some agencies require that proposal printing be double-spaced rather than single-spaced. Other agencies dictate the maximum number of lines that may be printed on a page.

Type size is usually set at no smaller than 10-point character height (vertical size) and no more than an average of 12 characters per inch to avoid the use of small print that is difficult to read.

Font styles are usually established only where provisions are made for proposals to be submitted in both hard copy and electronically or where page limits are set. If offerors will submit proposals electronically, the word processing program used must be compatible with your systems.

Page Limits

Page limits are used to preclude the submission of unnecessarily elaborate or lengthy proposals. A necessary prerequisite to the use of page limits is, of course, that you know how many pages constitute a reasonable proposal for your particular requirement. If you set the page limits too low, you may not get all the information you need. If you set the page limits too high, you are encouraging elaborate proposals. The best guideline to use is the complexity of your requirement. If you have a complex requirement (this will be reflected in the size of your SOW and the number of evaluation teams), you should probably establish a page limit. Examine previously submitted proposals for similar efforts to see if an average can be established, or simply use your best judgment. If the requirement is not complex, page limits are not necessary.

When using page limits, specify exactly what counts as a page. Generally, page limits are applied only against the basic text of the technical and management proposals. Attachments may or may not be included in the page limit. You may want to include page limits for attachments that amplify information in the technical and management proposals; otherwise, you may end up with slim proposals and fat attachments. You may also want to limit the types of information included in the attachments to technical supporting information that would not influence the evaluation of the technical and management proposals. Pricing proposals are usually not included in page limits.

In addition, you must state how you will determine which pages are excess and what will happen to excess pages. Typically, excess pages are determined by counting from the first page of the proposal. When the count reaches the page limit, the counting stops.

Pages in excess of the page limit are physically removed from the proposal (before the evaluation starts) and returned to the offeror. Offerors should be reminded that when excess pages are removed and not evaluated, this usually results in substantial proposal deficiencies, the correction of which is not permitted.

When you find formatting problems, such as the wrong type size, too many lines per page, and wrong page size, you should either recalculate the page count based on what it would be if done as directed, or simply remove the offending pages.

The use of page and format limitations depends on current circumstances. You should, however, have a valid reason for the limitations you do use. Keep in mind that when used, page limits must be followed in the evaluation and cannot be waived, unless the RFP is amended to revise the page limits for all offerors. If your limits are too restrictive or confusing, you may end up having to reject what might otherwise have been one of the most highly rated proposals.

You should note, however, that a proposal is not rejected simply because it exceeds page or format limitations. A proposal is rejected only when, after removing the excess pages, evaluation of the remaining proposal pages results in a determination that the proposal is technically unacceptable. It is the deficiencies that result when only part of a proposal is evaluated that causes the rejection, not the failure to adhere to the page or format limitations. Rejection is required because a technically unacceptable proposal is not subject to correction; to allow correction would give the offeror an unfair competitive advantage if it was permitted to have its noncompliant proposal evaluated as is, while other offerors adhered to the limitations in their proposals.

Figure 1-3 is an example of how a page limit could be established in the proposal preparation instructions.

To Require Specific Information

The proposal preparation instructions may also be used to elicit specific information that you need to amplify your initial SOW when you intend to incorporate all or part of the successful offeror’s proposal into your final SOW. Incorporation by reference is accomplished by inserting a clause in the contract to the effect that all, or specified parts, of the contractor’s proposal are incorporated into the contract by reference, and including the incorporated portions as an attachment to the contract. The incorporated portions become part of the contract, and the contractor is legally required to perform accordingly (contractors are required to do only what is written into the contract).

Generally, incorporation by reference is used in instances where the requirements are difficult to describe. You may not know how to go about meeting the requirement because of its technical complexity (as in software development). You may not be sure the requirement can be met, and part of the purpose of your requirement is to find out (as in R&D). There may be a number of ways to meet the requirement, and you do not want to predetermine the way by specifying it in the SOW. You must, therefore, get the offerors to provide the necessary details in their technical proposals.

FIGURE 1-3:
Establishing a Page Limit

In such instances, you should provide a broad functional description of your requirement in the initial SOW and use the proposal preparation instructions to require offerors to explain the details of how the work will be done. The successful offeror’s proposal would then be incorporated by reference (in whole or in part) into the final SOW.

To do this, you must tell the offerors the level of detail to be provided, such as the technical approach, work plans, methodology, analytic techniques, management reporting, and other details as to how the offeror proposes to meet the requirement. This is not dissimilar to what might be required in any event, but you must also indicate that the successful offeror’s proposal will be incorporated by reference into the resulting contract and provide the offerors information about how to write a proposal to ensure that the wording used is contractually viable (see Chapters 4, 5, and 6).

It should be noted that you do not have to incorporate proposal detail by reference to include such information as a contractual requirement. You could amend the RFP to include the information in your SOW before award. To do this, the RFP must inform all offerors that you intend to revise the SOW to include certain information (specify the information) from the successful offeror’s proposal. Or, you could simply revise the SOW in the award document for the successful offeror. You must be careful, however, to ensure that the revisions do not constitute a change to the nature of your requirement. Unsuccessful offerors can protest last-minute changes that could have affected the competitive standings.

A contractor’s proposal is a promise to perform in a particular manner, but the contractor is not legally bound to perform in that manner as long as the contractor’s performance meets the contractual requirements. If you want to hold the contractor to all or particular parts of its proposal, you must take action to include the pertinent parts of the contractor’s proposal in the SOW. As noted, this can be done by incorporating by reference or by revising the SOW, but it must be done before contract award.

FORMATTING THE PROPOSAL PREPARATION INSTRUCTIONS

The purpose of proposal preparation instructions is to provide guidance on the format and content of proposals. How you provide this guidance is a matter of choice. The important thing to remember is that the instructions should be grouped together in a logical manner, clearly marked as proposal preparation instructions, and contain only information related to the development of the offeror’s proposal. Do not include any information that applies to activities taking place after contract award. Information of this nature belongs in either the SOW or a contract clause, as appropriate.

There are a number of ways to present the proposal preparation instructions. Figure 1-4 provides one example of how it could be done.

FIGURE 1-4:
Sample Format for Proposal Preparation Instructions

NEED TO CHECK YOUR WORK CAREFULLY

The proposal preparation instructions are an important part of the solicitation process. The contractor relies on this information in preparing its proposal. The efficiency of the evaluation process depends on how well the proposal preparation instructions direct the contractor to provide relevant information and a proposal format that facilitates the evaluation.

Check your proposal preparation instructions carefully before the RFP is issued to ensure that they are properly presented. Ambiguities, inconsistencies, or outright errors in the proposal preparation instructions can cause considerable confusion among the competing offerors and can result in the disqualification of an otherwise qualified offeror.

Check the proposal preparation instructions against the RFP as a whole, but pay particular attention to ensuring that the SOW requirements and the evaluation criteria and procedures listed in Section M are compatible.

Most offerors follow the proposal preparation instructions because they realize that proposals tend be scored lower if the evaluators have difficulty locating pertinent information due to a differing format or if required information is not provided.

An offeror appreciates and benefits from clear and thorough proposal preparation instructions because the more an offeror knows what the government wants to see in the proposal, the better it can respond to the government’s concerns. Both the government and the contractor benefit from a responsive proposal.

The proposal preparation instructions are the final part of the evaluation plan. Keep in mind that the evaluation factors, their relative importance, and the proposal preparation instructions are published in the RFP. This enables you to influence the structure and content of the proposals and to expedite the evaluation process by reducing the possibility of confusing and conflicting proposal structures.

This concludes the introduction to the SOW and how it interacts with the other parts of the RFP. Chapter 2 addresses the planning and preparation necessary before you begin writing the SOW.