Procurement and Acquisition
Lead Author: Dick Fairley, Contributing Author: Alice Squires
Procurement is the act of buying goods and services. Acquisition covers the conceptualization, initiation, design, development, testing, contracting, production, deployment, logistics support, modification, and disposal of weapons and other systems, as well as supplies or services (including construction) to satisfy organizational needs intended for use in, or in support of, defined missions (DAU 2010; DoD 2001).
Acquisition covers a much broader range of topics than procurement. Acquisition spans the whole life cycle of acquired systems. The procurement of appropriate systems engineering (SE) acquisition activities and levels of SE support is critical for an organization to meet the challenge of developing and maintaining complex systems.
The Guide for Integrating Systems Engineering into DoD Acquisition Contracts addresses how systems engineering activities are integrated into the various elements of acquisition and procurement (DoD 2006a).
Acquisition Process Model
Multiple acquisition process models exist. An acquisition process for major systems in industry and defense is shown in Figure 1. The process of acquisition is defined by a series of phases during which technology is defined and matured into viable concepts. These concepts are subsequently developed and readied for production, after which the systems produced are supported in the field.
Acquisition planning is the process of identifying and describing needs, capabilities, and requirements, as well as determining the best method for meeting those requirements (e.g., program acquisition strategy). This process includes procurement; thus, procurement is directly linked to the acquisition process model. The process model present in Figure 1 allows a given acquisition to enter the process at any of the development phases.
For example, a system using unproven technology would enter at the beginning stages of the process and would proceed through a lengthy period of technology maturation. On the other hand, a system based on mature and proven technologies might enter directly into engineering development or sometimes even production.
Systems Engineering Role in the Acquisition Process
The procurement of complex systems usually requires a close relationship between the offeror and supplier SE teams due to the breadth and depth of SE activities. SE is an overarching process that the program team applies in order to transition from a stated capability need to an affordable, operationally effective, and suitable system.
SE is important to every phase of the acquisition process. SE encompasses the application of SE processes across the acquisition life cycle and is intended to be an integrating mechanism for balanced solutions addressing capability needs, design considerations, and constraints. It is also intended to address limitations imposed by technology, budget, and schedule.
SE is an interdisciplinary approach; that is, it is a structured, disciplined, and documented technical effort to simultaneously design and develop system products and processes to satisfy the needs of the customer. Regardless of the scope and type of program, or at what point it enters the program acquisition life cycle, the technical approach to the program needs to be integrated with the acquisition strategy to obtain the best program solution.
Acquisition and procurement in the commercial sector have many characteristics in common with their counterparts in the realm of government contracting, although the processes in the commercial world are usually accomplished with fewer rigors than occur between government and contractor interactions. Offshore outsourcing is commonly practiced in the commercial software arena with the goal of reducing the cost of labor. Commercial organizations sometimes subcontract with other commercial organizations to provide missing expertise and to balance the ebb and flow of staffing needs.
In some cases, relations between the contracting organization and the subcontractor are strained because of the contracting organization’s desire to protect its intellectual property and development practices from potential exposure to the subcontractor. Commercial organizations often have lists of approved vendors that are used to expedite the procurement of needed equipment, products, and services. In these situations, commercial organizations have processes to evaluate and approve vendors in ways that are analogous to the qualification of government contractors. Many commercial organizations apply SE principles and procedures even though they may not identify the personnel and job functions as “systems engineers” or “systems engineering.”
Importance of the Acquisition Strategy in the Procurement Process
The acquisition strategy is usually developed during the front end of the acquisition life cycle. (For an example of this, see the Technology Development Phase in Figure 1.) The acquisition strategy provides the integrated strategy for all aspects of the acquisition program throughout the program life cycle.
In essence, the acquisition strategy is a high-level business and technical management approach designed to achieve program objectives within specified resource constraints. It acts as the framework for planning, organizing, staffing, controlling, and leading a program, as well as for establishing the appropriate contract mechanisms. It provides a master schedule for research, development, testing, production, fielding, and other SE related activities essential for program success, as well as for formulating functional strategies and plans.
The offeror’s program team, including systems engineering, is responsible for developing and documenting the acquisition strategy, which conveys the program objectives, direction, and means of control based on the integration of strategic, technical, and resource concerns. A primary goal of the acquisition strategy is the development of a plan that will minimize the time and cost of satisfying an identified, validated need while remaining consistent with common sense and sound business practices. While the contract officer (CO) is responsible for all contracting aspects, including determining which type of contract is most appropriate, and following the requirements of existing regulations, directives, instructions, and policy memos of an organization, the program manager (PM) works with the CO to develop the best contract/procurement strategy and contract types.
Relating Acquisition to Request for Proposal and Technical Attributes
There are several formats for requesting proposals from offerors for building complex systems. Figure 2 relates acquisition program elements to a representative request for proposal (RFP) topical outline and key program technical attributes that have been used by the Department of Defense. In general, programs have a better chance of success when both the offeror and supplier understand the technical nature of the program and the need for the associated SE activities.
The offeror and supplier need to clearly communicate the technical aspect of the program throughout the procurement process. The offeror’s RFP and the associated supplier proposal represent one of the formal communications paths. A partial list of key program technical attributes is presented in Figure 2.
Contract-Related Activities and the Offeror’s Systems Engineering and Project Management Roles
A clear understanding of the technical requirements is enhanced via the development of a Systems Engineering Plan (SEP). The SEP documents the systems engineering strategy for a project or program and acts as the blueprint for the conduct, management, and control of the technical aspects of the acquisition program (DoD 2011). The SEP documents the SE structure and addresses government and contractor boundaries. It summarizes the program’s selected acquisition strategy and identifies and links to program risks. It also describes how the contractor's, and sometimes the subcontractor's and suppliers', technical efforts are to be managed.
Once the technical requirements are understood, a contract may be developed and followed by the solicitation of suppliers. The offeror's PM, chief or lead systems engineer, and CO must work together to translate the program’s acquisition strategy and associated technical approach (usually defined in a SEP) into a cohesive, executable contract(s).
Table 1 shows some key contracting-related tasks with indicators of the roles of the PM and LSE.
| Typical Contract-Related Activities | Systems Engineer and Project Manager Roles |
|---|---|
| 1. Identify overall procurement requirements and associated budget. Describe the offer’s needs and any constraints on the procurement. | 1. Lead systems engineer (LSE) provides program technical requirements. PM provides any programmatic related requirements. |
| 2. Identify technical actions required to successfully complete technical and procurement milestones. The program’s SEP is the key source for capturing this technical planning. | 2. LSE defines the technical strategy/approach and required technical efforts. This should be consistent with the program’s Acquisition Strategy. |
| 3. Document market research results and identify potential industry sources. | 3. PM and LSE identify programmatic and technical information needed and assist in evaluating the results. |
| 4. Prepare a Purchase Request, including product descriptions; priorities, allocations and allotments; architecture; government-furnished property or equipment (or Government-Off-The-Shelf (GOTS); government-furnished information; information assurance and security considerations; and required delivery schedules. | 4. PM and LSE ensure the specific programmatic and technical needs are defined clearly (e.g., commercial-off-the-shelf (COTS) products). |
| 5. Identify acquisition streamlining approach and requirements, budgeting and funding, management information requirements, environmental considerations, offeror’s expected skill sets, and milestones. These should be addressed in the Acquisition Strategy. | 5. The procurement team work together, but the CO has the prime responsibility.
The PM is the owner of the program Acquisition Strategy. The LSE develops and reviews (and the PM approves) the technical strategy. |
| 6. Plan the requirements for the contract Statement of Objectives (SOO) / Statement of Work (SOW) / specification, project technical reviews, acceptance requirements, and schedule. | 6. LSE is responsible for the development of the technical aspects of the SOO/SOW. |
| 7. Plan and conduct Industry Days as appropriate. | 7. PM and LSE support the CO in planning the meeting agenda to ensure technical needs are discussed. |
| 8. Establish contract cost, schedule, and performance reporting requirements. Determine an incentive strategy and appropriate mechanism (e.g., Award Fee Plan and criteria). | 8. LSE provides technical resource estimates.
LSE supports development of the Work Breakdown Structure (WBS) based on preliminary system specifications, determines event-driven criteria for key technical reviews, and determines what technical artifacts are baselined. The PM and LSE advise the CO in developing the metrics/criteria for an incentive mechanism. |
| 9. Identify data requirements. | 9. LSE identifies all technical Contractor Data Requirements List (CDRL) and technical performance expectations. |
| 10. Establish warranty requirements, if applicable. | 10. LSE works with the CO to determine cost-effective warranty requirements. |
| 11. Prepare a Source Selection Plan (SSP) and RFP (for competitive contracts). | 11. PM and LSE provide input to the SSP per the SOO/SOW. |
| 12. Conduct source selection and award the contract to the successful offeror. | 12. PM and LSE participate on evaluation teams. |
Offeror and Supplier Interactions
There should be an environment of open communication prior to the formal source selection process. This ensures that the supplier understands the offeror’s requirements and that the offeror understands the supplier's capabilities and limitations, as well as enhancing the supplier's involvement in the development of a program acquisition strategy. During the pre-solicitation phase, the offeror develops the solicitation and may ask suppliers to provide important insights into the technical challenges, program technical approach, and key business motivations.
For example, potential bidders could be asked for their assessment of a proposed system's performance based on the maturity level of new and existing technologies.
Contracts and Subcontracts
Typical types of contracts include the following:
- Fixed Price: In a fixed price contract the offeror proposes a single price for all products and services to implement the project. This single price is sometimes referred to as low bid or lump sum. A fixed price contract transfers the project risks to the supplier. When there is a cost overrun, the supplier absorbs it. If the supplier performs better than planned, their profit is higher. Since all risks are absorbed by the supplier, a fixed price bid may be higher to reflect this.
- Cost-reimbursement [Cost plus]: In a cost-reimbursement contract the offeror provides a fixed fee, but also reimburses the contractor for labor, material, overhead, and administration costs. Cost-reimbursement type contracts are used when there is a high level of project risk and uncertainty. With this type of contract, the risks reside primarily with the offeror. The supplier gets reimbursed for all of its costs. Additional costs that arise due to changes or rework are covered by the offeror. This type of contract is often recommended for the system definition of hardware and software development when there is a risk of stakeholder changes to the system.
- Subcontracts: A subcontractor performs work for another company as part of a larger project. A subcontractor is hired by a general contractor (also known as a prime or main contractor) to perform a specific set of tasks as part of the overall project. The incentive to hire subcontractors is either to reduce costs or to mitigate project risks. The systems engineering team is involved in establishing the technical contract requirements, technical selection criteria, acceptance requirements, and the technical monitoring and control processes.
- Outsource contracts: Outsourced contracts are used to obtain goods or services by contracting with an outside supplier. Outsourcing usually involves contracting a business function, such as software design and code development, to an external provider.
- Exclusively Commercial Off-the-Shelf (COTS): Exclusively COTS contracts are completely satisfied with commercial solutions that require no modification for use. COTS solutions are used in the environment without modifying the COTS system. They are integrated into an existing user's platform or integrated into an existing operational environment. The systems engineering team is involved in establishing the technical contract requirements, technical acceptance, and technical selection criteria.
- Integrated COTS: Integrated COTS contracts use commercially available products and integrate them into existing user platforms or operational environments. In some cases, integrated COTS solutions modify the system's solution. The cost of integrating the commercial COTS product into the operational environment can exceed the cost of the COTS product itself. As a result, the systems engineering team is usually involved in establishing the technical outsourcing contract requirements, technical selection criteria, technical monitoring and control processes, and technical acceptance and integration processes.
- COTS Modification: COTS modification requires the most time and cost because of the additional work needed to modify the COTS product and integrate it into the system. Depending on how complex and critical the need is, the systems engineering team is usually involved in establishing the technical outsource contract requirements, technical selection criteria, technical monitoring and control processes, and technical acceptance requirements.
- IT services: IT services provide capabilities that can enable an enterprise, application, or Web service solution. IT services can be provided by an outsourced service provider. In many cases, the user interface for these Web services is as simple as a Web browser. Depending on how complex and critical the needs are, the systems engineering team can be involved in establishing the technical outsourcing contract requirements, technical selection criteria, and technical acceptance process.
References
Works Cited
DAU. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/US Department of Defense (DoD).
DoD. 2011. Systems Engineering Plan (SEP) Outline. Washington, DC, USA: Office of the Undersecretary of Defense for Acquisition, Transportation, and Logistics (AT&L), US Department of Defense (DoD).
DoD. 2006. Guide for Integrating Systems Engineering into DoD Acquisition Contracts. Washington, DC, USA: Office of the Undersecretary of Defense for Acquisition, Transportation, and Logistics (AT&L), US Department of Defense (DoD).
DoD. 2001. Systems Engineering Fundamentals. Washington, DC, USA: Defense Acquisition University Press/US Department of Defense.
Primary References
DAU. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/US Department of Defense (DoD).
DoD. 2011. Systems Engineering Plan (SEP) Outline. Washington, DC, USA: Office of the Undersecretary of Defense for Acquisition, Transportation, and Logistics (AT&L), US Department of Defense (DoD).
DoD. 2006. Guide for Integrating Systems Engineering into DoD Acquisition Contracts. Washington, DC, USA: Office of the Undersecretary of Defense for Acquisition, Transportation, and Logistics (AT&L), US Department of Defense (DoD).
Additional References
MITRE. 2011. "Acquisition Systems Engineering." Systems Engineering Guide. Accessed March 9, 2012. Available: http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/.