Procurement and Acquisition
procurement is the act of buying goods and services, while acquisition covers the conceptualization, initiation, design, development, test, contracting, production, deployment, logistics support, modification, and disposal of weapons and other systems, supplies, or services (including construction) to satisfy organizational needs intended for use in or in support of defined missions (DAU, 2010). Acquisition is therefore a much wider concept than procurement, covering the whole life cycle of acquired systems. The procurement of appropriate SE acquisition activities and levels of SE support are critical for an organization to meet the challenge of developing and maintaining complex systems. DoD 2006a addresses how systems engineering activities are integrated into the various elements of acquisition and procurement.
Miscellaneous Stuff
- This discussion applies to all phases of the acquisition life cycle. For simplicity, however, it focuses on the front-end of the life cycle where preparing for the acquisition is most important.
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 is defined by a series of phases during which technology is defined and matured into viable concepts, which 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/requirements and determining the best method for meeting those requirements (e.g., program acquisition strategy), including 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, while a system based on mature and proven technologies might enter directly into engineering development or, conceivably, even production.
Systems Engineering Role in the Acquisition Process
The procurement of complex systems usually requires a close relationship among the offeror and supplier SE teams due to the breadth and depth of SE activities. Systems engineering (SE) is an overarching process that the program team applies 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, as well as limitations imposed by technology, budget, and schedule. SE is an interdisciplinary approach or 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.
Importance of the Acquisition Strategy in the Procurement Process
The acquisition strategy is usually developed in the front-end of the acquisition life cycle (e.g. please see Technology Development Phase in Figure 1) and 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 is both: (1) the framework for planning, organizing, staffing, controlling, and leading a program and (2) for establishing the appropriate contract mechanisms. It provides a master schedule for research, development, test, production, fielding and other SE related activities essential for program success, and for formulating functional strategies and plans. The offeror’s program team, including SE, 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 in developing an acquisition strategy is the minimization of the time and cost of satisfying an identified, validated need—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 PM works with the CO to develop the best contract/procurement strategy and contract types.
Types of Acquisition Contracts
Types of acquisition contracts include:
- Fixed Price Contract: Offeror contracts a single price for all products and services to implement the project. This is sometimes referred to as low bid or lump sum. This type of contract transfers the project risks to the supplier. When there is a cost overrun, the supplier absorbs this overrun. If they perform better than planned, the supplier’s profit is higher. Since all risks are absorbed by the supplier, a fixed price bid may be higher to reflect this uncertainty.
- Cost-reimbursement [Cost plus]: Offeror reimburses the contractor for labor, material, overhead, administration costs, plus a fixed fee. Cost-reimbursement type contracts are used where 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 his costs. Additional work performed due to changes or rework, entitle the supplier to get paid for this additional effort. This type of contract is often recommended for the system definition of hardware & software development where there is the risk of stakeholder changes to the system.
These approaches can be tailored to address aspects of these SE activities to support other acquisition approaches, such as sole source; purchase of commercial-off-the-shelf (COTS) products (e.g., software); information technology (IT); or business systems.
Relating Acquisition to Request for Proposal (RFP) 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 RFP topical outline and key program technical attributes that has been used by the Department of Defense. In general, programs have a better chance of success when both the offer and supplier understand the technical nature of the program and the need for the associated SE activities. Given languages are often symbolic, the offer 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.
Role of the Systems Engineering Plan in Systems Acquisition
A clear understanding of the technical requirements is enhanced via the development of a Systems Engineering Plan. The Systems Engineering Plan (SEP) documents the system engineering strategy for a project or program; it is the blueprint for the conduct, management, and control of the technical aspects of the acquisition program (DoD 2006b). A few key contract relevant items are extracted from the SEP Preparation Guide and reiterated here:
- The SEP is about overall organization of the technical effort, including delineation of authorities, responsibilities, and integration across the government and contractor boundaries.
- The SEP shows how the SE structure is organized to provide technical management guidance across the government, prime contractor, subcontractors, and suppliers.
- The SEP provides an overview of government and contractor data rights for the system to include what key technical information and data will be developed during the phase being planned.
- The SEP summarizes how the program’s selected Acquisition Strategy is based on the technical understanding of the problem at hand and the identified program risks to include the list of program risks.
- The SEP describes how the contract (and subcontract and suppliers’, if applicable) technical efforts are to be managed from the Government perspective.
Contract-Related Activities and the Offeror’s Systems Engineering and Project Management Roles
Given a clear understanding of the technical requirements, the next step may be development of a contract and solicitation of suppliers. The offerer's program manager (PM), chief or lead systems engineer (LSE), and a contracting officer (CO) must work together to translate the program’s Acquisition Strategy and associated technical approach, (usually defined in SEP) into a cohesive, executable contract(s), as appropriate. Table 1 shows some key contracting-related tasks with indicators of the roles of the PM and LSE.
Typical Contract-Related Activities | System Engineer and Project Manager Roles | |
---|---|---|
1. Identify overall procurement requirements and associated budget. Describe the offer’s needs and any constraints on the procurement. | Lead SE (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. | 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. | PM and LSE identify programmatic and technical information needed and assists 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. | 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, offer’s expected skill sets, and milestones. These should be addressed in the Acquisition Strategy. | The procurement team work together, but the CO has prime responsibility.
The PM is owner of the program Acquisition Strategy. The LSE develops and reviews (and 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. | LSE is responsible for the development of the technical aspects of the SOO/SOW. | |
7. Plan and conduct Industry Days as appropriate. | PM and LSE supports 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). | LSE provides technical resource estimates.
LSE supports development of the Work Breakdown Structure (WBS) structure 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 | LSE identifies all technical Contractor Data Requirements List (CDRL) and technical performance expectations. | |
10. Establish warranty requirements, if applicable. | LSE works with the CO on determining cost-effective warranty requirements. | |
11. Prepare a Source Selection Plan (SSP) and RFP (for competitive contracts). | PM and LSE provide input to the SSP per the SOO/SOW. | |
12. Conduct source selection and award the contract to the successful offeror. | 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 to: (1) ensure supplier understands the offeror’s requirements and that the offeror understands supplier capabilities and limitations; and (2) to enhance supplier involvement in the Government’s development of a program Acquisition Strategy. During the pre-solicitation phase, the offerer 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 proposed system performance that is achievable based on the maturity level of new technology as well as existing technology.
Subcontracts, Outsource Contracts, and COTS
Subcontracts
A subcontract is a contract by which a company or person performs work for another company as part of a larger project (Reference 3). A subcontractor is hired by a general contractor (or prime contractor, 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, technical monitoring and control processes and acceptance requirements and process.
Outsource Contracts
Outsource contracts are used to obtain goods or a services by contracting with an outside supplier. (Reference 3). The term, "outsource" is used inconsistently. However, outsourcing is usually viewed as involving the contracting out of a business function, such as software design and code development, to an external provider.
- Commercial Off-the-Shelf (COTS) Contracts
For IT projects (business and information systems) and some weapon systems programs there are four types of contracts to be considered relative to the magnitude of systems engineering needed:
- Exclusively Commercial Off-the-Shelf (COTS) contracts
Exclusively COTS contracts comprise capabilities that are completely satisfied with commercial solutions that require no modification for use. COTS solutions are deployed into the user environment without modifying the COTS system, integrated in into an existing users' platform, or integrated it into an existing operational environment. The systems engineering team is involved in establishing the technical contract requirements, technical selection criteria, and technical acceptance.
- Integrated COTS contacts
Integrated COTS contracts are used to obtain commercially available products and integrate them onto existing user platforms or into existing operational environments. In some cases integrated COTS solutions modify the system solution. The cost of integrating the commercial COTS product into the operational environment can exceed the cost of the COTS product itself and as a result, 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 and integration processes.
- IT services contracts
IT services contracts provide capabilities that can enable an enterprise, application, or web service solution. IT services can be provided by an outsource service provider. The user interface for these web services are in many cases as simple as a web browser. Depending on complexity and criticality of need, the systems engineering team can be involved in establishing the technical outsource contract requirements, technical selection criteria, and technical acceptance process.
- COTS Modification contracts.
It is sometimes necessary to modify a COTS product, develop related software, and integrate the resulting product into the operational environment. This type of IT system contract usually requires the most time and costs because of the additional work needed to modify the COTS product and integrate it into the system. Depending on complexity and criticality of need, 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 and process.
Commercial Acquisition & Procurement
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 less rigor than occurs in government/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 exposure to the subcontractor.
Commercial organizations often have lists of approved vendors that are used to expedite procurement of needed equipment, products, and services. In those situations, commercial organizations have processes to evaluate and approve vendors in ways that are analogous to the ways in which, for example, the CMMI process is used to qualify government contractors.
Many commercial organization apply systems engineering principles and procedures even though they may not identify the personnel and job functions as “systems engineers” or “systems engineering.”
References
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.
Citations
(DoD 2006a) DoD. 2006. Guide for Integrating Systems Engineering into DoD Acquisition Contracts. Washington, D.C.: Office of the Undersecretary of Defense (AT&L).
(DoD 2006b) DoD. 2006. Systems Engineering Plan Preparation Guide. Washington, D.C.: Office of the Undersecretary of Defense (AT&L).
Primary References
(DoD 2006a) DoD. 2006. Guide for Integrating Systems Engineering into DoD Acquisition Contracts. Washington, D.C.: Office of the Undersecretary of Defense (AT&L).
(DoD 2006b) DoD. 2006. Systems Engineering Plan Preparation Guide. Washington, D.C.: Office of the Undersecretary of Defense (AT&L).
Additional References
DoD. 2004. Defense Acquisition Guidebook. Washington D.C.: US Department of Defense.
DoD. 2001. Systems Engineering Fundamentals., Washington D.C.: Defense Acquisition University Press.
---
Article Discussion
Signatures
--Bkcase 19:08, 22 August 2011 (UTC) (on behalf of Dick Fairley)