Back to Top

Educating the Aerospace Industry

Blog Archives

Proposal Development

Sources Sought

A Sources Sought Notice is a government market research tool to determine if there are two (2) or more capable businesses or Small Businesses that can perform the requirements of a planned contract.  It is not a Request for Proposal (RFP) or Invitation for Bid (IFB). It’s used by the government in developing Acquisition Strategies.

The purpose of a Sources Sought:

  • Access the market’s capability
  • Determine acquisition strategy
  • Small Business goal attainment

The government is required in certain instances to “set-aside” a certain percentage of their procurements to small businesses. Sometimes the solicitation will specify explicitly that they are looking only for small businesses (or HUBZone, …) to respond. (Even if it doesn’t say “only small businesses” it means only small businesses.)  

AcqLinks and References:

Updated: 7/27/2017

Contracts & Legal

Sole Soure – Justification and Approval

Justification and Approval (J&A) is a document required by the Federal Acquisition Regulation (FAR) (Subpart 6.3) that justifies and obtains approval for contract solicitations that use Other than Full & Open Competition (FOC) . Also called sole source.

The following statutory situations (10 USC 2304c(1)) permit contracting without providing for full and open competition:

  • Only one responsible source and no other supplies or services will satisfy agency requirements
  • Unusual and compelling urgency (schedule)
  • Industrial mobilization; engineering, developmental, or research capability; or expert services
  • International agreement
  • Authorized or required by statute
  • National security
  • Public interest

Quick Sheet: Justification and Approval (J&A) Primer

Guide: Army Justification and Approval (J&A)

Guide: Justification & Approval Preparation Guide and Template 

Form: Justification and Approval Form (1 Oct 15)

Justifications Requirements (FAR 6.303):  
A contracting officer shall not commence negotiations for a sole source contract, commence negotiations for a contract resulting from an unsolicited proposal, or award any other contract without providing for full and open competition unless the contracting officer:

  • A contracting officer shall not commence negotiations for a sole source contract, commence negotiations for a contract resulting from an unsolicited proposal, or award any other contract without providing for full and open competition unless the contracting officer:
    • Justifies the use of such actions in writing;
    • Certifies the accuracy and completeness of the justification; and
    • Obtains the approval.
  • Technical and requirements personnel are responsible for providing and certifying as accurate and complete necessary data to support their recommendation for other than full and open competition.
  • Justifications may be made on an individual or class basis. Any justification for contracts awarded under the authority of FAR 6.302-7 shall only be made on an individual basis. Whenever a justification is made and approved on a class basis, the contracting officer must ensure that each contract action taken pursuant to the authority of the class justification and approval is within the scope of the class justification and approval and shall document the contract file for each contract action accordingly.
  • The justifications for contracts awarded under the authority may be prepared and approved within a reasonable time after contract award when preparation and approval prior to award would unreasonably delay the acquisitions

Justification Content (FAR 6.303-2):
Each justification shall contain sufficient facts and rationale to justify the use of the specific authority cited. As a minimum, each justification shall include the following information:

  1. Identification of the agency and the contracting activity, and specific identification of the document as a “Justification for other than full and open competition.”
  2. Nature and/or description of the action being approved.
  3. A description of the supplies or services required to meet the agency’s needs (including the estimated value).
  4. An identification of the statutory authority permitting other than full and open competition.
  5. A demonstration that the proposed contractor’s unique qualifications or the nature of the acquisition requires use of the authority cited.
  6. A description of efforts made to ensure that offers are solicited from as many potential sources as is practicable, including whether a notice was or will be publicized as required by Subpart 5.2 and, if not, which exception under 5.202 applies.
  7. A determination by the contracting officer that the anticipated cost to the Government will be fair and reasonable.
  8. A description of the market research conducted and the results or a statement of the reason market research was not conducted.
  9. Any other facts supporting the use of other than full and open competition, such as:
    • Explanation of why technical data packages, specifications, engineering descriptions, statements of work, or purchase descriptions suitable for full and open competition have not been developed or are not available.
    • For follow-on acquisitions as described (FAR 6.302-1(a)(2)(ii)) an estimate of the cost to the Government that would be duplicated and how the estimate was derived.
    • When (FAR 6.302-2) is cited, data, estimated cost, or other rationale as to the extent and nature of the harm to the Government.
  10. A listing of the sources, if any, that expressed, in writing, an interest in the acquisition.
  11. A statement of the actions, if any, the agency may take to remove or overcome any barriers to competition before any subsequent acquisition for the supplies or services required.
  12. Contracting officer certification that the justification is accurate and complete to the best of the contracting officer’s knowledge and belief.

AcqLinks and References:

Updated: 7/27/2017

Proposal Development

Software RFP Content

Software is addressed in the Request for Proposal (RFP) in order to solicit proposals that provide the information to support an effective Government evaluation and identification of strengths, deficiencies, uncertainties, weaknesses, and risks related to software. The sections is an RFP that should address software include: [1]

Statement of Objectives
The SOO is a top-level Government description of what is required by the solicitation, based on the content of the Initial Capability Document (ICD). The sole purpose of the SOO is to communicate to industry the Government‘s most important desired outcomes in the performance of the effort. Software goals should be mentioned as one of the main objectives of a software related program. [1]

Statement of Work
The SOW describes the software tasks that must be performed and the conditions under which they must be performed. The SOW should, at a minimum, include software requirements to: [1]

  • Define a software architecture and development approach appropriate for all computer software to be developed, integrated, and delivered under this solicitation
  • Document the software development approach and related processes in a Software Development Plan (SDP), maintain the SDP, and comply with the SDP for all software developed under this solicitation throughout the development effort
  • Support program office integrated product teams and working groups
  • Provide software engineering management and control to ensure all software activities are conducted in accordance with the contractor‘s approved SDP and software engineering processes
  • Conduct technical reviews to verify that the software products meet requirements and are suitable for intended use
  • Collect, analyze, and report software metrics data
  • Maintain consistency among software products (e.g., requirements, architecture, design, code, test cases)
  • Plan the blocks/increments and the requirements to be met in each block/increment
  • Plan, manage, and conduct the integration, regression, and qualification testing of software items for each block/increment
  • Support system, segment, and subsystem requirements flow down and allocate requirements to software items. Maintain the integrity of the segment-wide software products and their configuration management

Section L
Should require submittal of a proposed SDP to document the software development processes proposed for use on the program. The SDP will be evaluated during source selection, and after contract award it should be updated as appropriate and submitted as a Contract Data Requirements List (CDRL) item for approval. [1]

Section M
Each proposal is evaluated against Section L requirements using Section M criteria to identify and document software-related strengths, deficiencies, uncertainties, weaknesses, and risks. The source selection evaluation is strictly limited to the evaluation factors and basis for award disclosed to the offeror’s in Section M of the RFP. [1]

AcqTips:

  • The System Requirements Document (SRD), draft specification, or equivalent, should incorporate unique software requirements which are evidenced at the system level. This typically includes any user sourced requirements as well as typical computing system reserve capacity, growth, and architecture requirements. These requirements are then reflected as appropriate in the RFP.
  • RFP Sections L and M must be consistent. Example content in Appendices C and D is not organized in a consistent manner, and is provided simply for consideration in developing RFPs for specific programs.

AcqLinks and References:

Updated: 7/27/2017

Proposal Development

Software Proposal Evaluation

The Source Selection Evaluation Team (SSET) evaluates each offeror‘s proposal and any subsequently submitted information or proposal revisions against the solicitation requirements and evaluation criteria. The SSET evaluates the offeror‘s understanding of the software task, the viability of the proposed approach, and the offeror‘s capability and capacity to perform. In addition, the SSET identifies and documents the strengths, deficiencies, uncertainties, weaknesses, and risks associated with each offeror‘s proposed approach.

During source selection, the SSET should typically accomplish the following software-related activities: [1]

  • Review and evaluate the offeror‘s CS&S architecture, including all software to be developed, reused, and integrated, to ensure solicitation requirements can be satisfied.
  • Evaluate the completeness and soundness of the proposed technical approach to meeting computer systems and software requirements.
  • Evaluate for realism the size of the proposed software development and integration effort, considering expected software size growth during development, proposed software reuse, proposed modification to existing software, proposed use of Software Commercial off-the-Shelf (COTS) products, and other software development and software integration risks.
  • Determine that the software size, technical content, development effort (cost), and schedule has been appropriately and consistently addressed throughout the proposal (for example, ensure the size of the software proposed in the technical volume is reflected in the cost volume).
  • Develop a conservative estimate of the required software development effort based on the proposed software size and development approach, and crosscheck this estimate:
    • If the SSET estimate shows that the proposed effort is not adequate, adjust the Most Probable Cost (MPC).
    • Develop a conservative estimate of the required software development schedule based on the proposed software size and development approach, and crosscheck this estimate:
    • Assess the software schedule risk in the context of the proposed Integrated Master Schedule (IMS), including software-related IMS task durations, sequencing, and linkages.
    • If the SSET estimate shows that the proposed software development schedule is not adequate, provide inputs to a schedule risk assessment so that any resulting schedule extension can be dollarized and integrated into the MPC.
  • Evaluate the proposed software development and integration processes as defined in the proposed Software Development Plan (SDP).
    • Expect to see evidence of established processes in a company standard development approach, reflected in the program SDP.
    • Evaluate adequacy of and commitment to consistently apply the proposed processes through the SDP, Integrated Master Plan (IMP), Integrated Master Schedule (IMS), and Statement of Work (SOW). (Commitment to processes must be established from the beginning of the contract, across the development team. Required software activities and tasks should be clearly addressed and the temporal (sequential and concurrent) relationships of these activities should be clearly indicated. Event completion criteria should include relevant software engineering process steps. Engineering analysis should be performed to determine that the IMS reflects adequate time to apply the proposed software development processes.)
    • Evaluate the compatibility of the proposed software development processes with the proposed software effort, schedule, and performance baselines.
    • Evaluate the integration of software engineering within Systems Engineering.
  • Evaluate the proposed approach to identifying and managing computer system and software risks, and assess the initial risks and mitigation activities identified by the offeror’s.
  • Evaluate the proposed approach for software activity planning and statusing, including the use of software metrics.
  • Evaluate the proposed approach for software problem reporting, tracking, and resolution.
  • Evaluate the proposed approach for software sustainment planning.
  • Evaluate the block/incremental development approach, and ensure that adequate personnel, development stations, and integration labs are available to support any planned concurrent development.
  • Ensure that any proprietary rights or intellectual property issues are identified, and that appropriate rights are proposed based on the expected operational and support approaches for the software.
  • Ensure that offeror’s propose an adequate approach to testing/verifying Government Furnished Software (GFS) well prior to need, and that offeror’s understand such software is provided ―as-is.
  • Evaluate the proposed approach to managing software suppliers, including flow-down of performance and process requirements, use of common development environments, balance of subcontract type and risk, and approach to insight, communication, and control.

– See Software Source Selection Considerations
– See Software RFP Content

AcqLinks and References:

Updated: 7/27/2017

Proposal Development

Section K – Representations & Certifications

Section K includes solicitation provisions that require representations, certifications or the submission of other information by offeror’s.  The appropriate regulation clauses from the Federal Acquisition Regulations (FAR) and Defense Federal Acquisition Regulations Supplement (DFARS) will be selected and inserted into Section K.

Final Clause determination will be made by the Procurement Contracting Officer (PCO).

AcqLinks and References:

Updated: 7/27/2017

Proposal Development

Proposal Content

Proposal Volumes The proposal volumes and the page allocations should be listed in the Request for Proposal (RFP).  An example is below:

  • Executive Summary: not to exceed 10 pages,
  • Technical Volumes not to exceed 200 pages each volume,
  • Management Volumes: not to exceed 200 pages each volume,
  • Cost Volume: not to exceed 50 pages.

Proposal content structure includes the following:

  • Cover Page
  • Table of Content
  • Volume Detailed Index
  • Volume Title Page
  • Volume Table of Contents
  • Volume Document
  • Volume Compliance Matrix
  • Abbreviations and Acronyms
  • Glossary of Terms
  • References
  • Volume Appendix Enclosure

Proprietary Information The words “Proprietary Information” should appear in the footers of all proposal material — draft and final formats. All working papers should be shredded and properly disposed. Page Numbering All pages preceding the body of the text should be numbered with lower case roman numerals. The first page of the body of the proposal should be 1. New sections should start on the right-hand side of the page. The volume pages should be printed on both sides with odd-numbered pages on the right-hand side, and even-numbered pages on the left-hand side. Allow a page number for left-hand blank pages, even though the page number should not appear on the page. The back of foldouts should be left blank; however, left-hand pages before foldouts should not be blank. Appendices should be numbered by the letter “A” designation followed by the appropriate number (e.g., A-1, A-2.). Glossaries and bibliographies should also be numbered using a letter designation (e.g., G-1, B-1). Covers and Title Pages The following information should be shown on covers and title pages:

  • Proposal title,
  • Customer name,
  • Volume number and title,
  • Proposal request number,
  • Company name and logo,
  • Date.

Page Layout All proposal materials should be prepared on 8 1/2×11-inch paper or as directed in the RFP. Where the inclusion of charts, drawings, tables, or other graphics requires larger format, foldouts should be employed. The proposal should be laid-out in double column, single-spaced lines with integrated graphics. Special care must be taken to justify the right side of each column and to review each line of the text and hyphenation to ensure that there are not any long white spaces between words on a line. The proposal should be prepared using Times New Roman 12-point font. Boldfacing should be reserved for section and sub-section titles. Use boldface for special emphasis, but use it sparingly. Use Underlining for sub-section titles where the sub-sections are not numbered. Section and sub-section numbering should be done using legal numbering (e.g., 1.2.3.4.1). All text should be typed in Microsoft Word. Proposal Compliance Matrix The purpose of the Compliance Matrix is to ensure that the proposal responds to and complies with all the Proposal Request requirements. A Compliance Matrix should form part of each proposal volume. The matrix should be started at the beginning of the writing assignments and should list all the requirements contained in the Annotated Proposal Outline for each volume. The Compliance Matrix should include the elements for both the Proposal Request and the proposal response.

AcqLinks and References:

Updated: 7/27/2017

Production, Quality & Manufacturing

Quality in Supply Management

Quality in Supply Management is a measure of providing products that are free from defects, deficiencies, and significant variations in the purchase-buyer transaction.  High quality is brought about by the strict and consistent adherence to measurable and verifiable standards to achieve uniformity of output that satisfies specific customer or user requirements. Quality management is a major component to supply management’s supplier performance management responsibilities. Quality failures leads directly to cost difficulties that reduce profits, productivity and market share. To preclude such losses, supply management should participate creatively in the corporate quality management program. [1,2,3]

– See Quality Assurance

AcqLinks and References:

Updated: 7/21/2017

Production, Quality & Manufacturing

Production Representative Articles

A Production Representative Article is a system that accurately represents the production configuration system for both hardware and software but is not produced on a final production line. To be considered a Production Representative Article, all of the following reviews must have been completed:

While highly desirable, the item does not have to be manufactured on a formal production line to be considered production representative. Production representative articles must be demonstrated in their intended environment during the Engineering, Manufacturing and Development (EMD) Phase. Production Representative Articles must also be used for the dedicated phase of Initial Operational Test and Evaluation (IOT&E) that supports the Full-Rate Production Decision (FRPD).

AcqLinks and References:

Updated: 7/21/2017

Production, Quality & Manufacturing

Obsolescence Management

Obsolescence is a lack of availability of an item or raw material resulting from statutory and process changes, as well as new designs. Obsolescence deals with the process or condition by which a piece of equipment becomes no longer useful, or a form and function no longer is currently available for production or repair. Implementation of new technology causes older technology to become less supportable because of the diminished availability of parts and suppliers. [2]

Obsolescence management is the discipline that addresses obsolescence and Diminishing Manufacturing Sources and Material Shortages (DMSMS) as the service life of a product extends beyond the technology life cycle incorporated in the design. A Program Manager (PM) must address obsolescence throughout a product’s life cycle and plan ahead to make sure parts are available or new technology is available to replace those parts. The PM should develop a proactive approach to effectively resolve and mitigate obsolescence problems before they have an adverse impact on the Life-Cycle Cost (LCC) and system Availability.

The following are potential approaches the PM should consider: [1]

  • Address Obsolescence management in the Request for Proposal (RFP)
  • Review proposed parts lists for obsolescence
  • Design features that facilitate change/insertion of new technology
  • Establishing a rigorous change management process for life-cycle support.
  • Using performance-based logistics contracts that provide significant latitude to manage technology refreshment. This includes ensuring they are incentivized to maintain currency with state-of-the-art technology and use readily available items to avoid the high cost of diminishing manufacturing sources and materiel shortages over the system’s life.
  • Be proactive in the engineering design process prior to production

AcqLinks and References:

Updated: 7/21/2017

Information Technology

Cyberspace

Cyberspace is the global domain within the information environment consisting of the interdependent network of information technology infrastructures, including the Internet, telecommunications networks, computer systems, and embedded processors and controllers. Cyberspace can be viewed as three layers (physical, logical, and social) made up of five components (geographic, physical network, logical network, cyber persona, and persona).

Cyberspace Levels

Cyberspace Levels [2]

Physical:
The physical layer includes the geographic component and the physical network component. The geographic component is the physical location of elements of the network. While geopolitical boundaries can easily be crossed in cyberspace at a rate approaching the speed of light, there is still a physical aspect tied to the other domains. The physical network component includes all the hardware and infrastructure (wired, wireless, and optical) that supports the network and the physical connectors (wires, cables, radio frequency, routers, servers, and computers). [2]

Logical:
The logical layer contains the logical network component which is technical in nature and consists of the logical connections that exist between network nodes. Nodes are any devices connected to a computer network. Nodes can be computers, personal digital assistants, cell phones, or various other network appliances. On an Internet protocol (IP) network, a node is any device with an IP address. [2]

Social:
The social layer comprises the human and cognitive aspects and includes the cyber persona component and the persona component. The cyber persona component includes a person’s identification or persona on the network (e-mail address, computer IP address, cell phone number, and others). The persona component consists of the people actually on the network. An individual can have multiple cyber personas (for example, different e-mail accounts on different computers) and a single cyber persona can have multiple users. [2]

Cybersecurity threats represent one of the most serious national security, public safety, and economic challenges we face as a nation.” – 2010 National Security Strategy

 Below is a list of the five (5) DoD Strategic Initiatives for Cyberspace: [1]

  • Strategic Initiative 1: Treat cyberspace as an operational domain to organize, train, and equip so that DoD can take full advantage of cyberspace’s potential
  • Strategic Initiative 2: Employ new defense operating concepts to protect DoD networks and systems
  • Strategic Initiative 3: Partner with other U.S. government departments and agencies and the private sector to enable a whole-of-government Cybersecurity strategy
  • Strategic Initiative 4: Build robust relationships with U.S. allies and international partners to strengthen collective cybersecurity
  • Strategic Initiative 5: Leverage the nation’s ingenuity through an exceptional cyber workforce and rapid technological innovation

AcqLinks and References:

Updated: 7/20/2017