Acquisition of Services

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: Guidance from OUSD(A&S)
Based on DAG CH 10-3.2.1 Step Four – Define Requirements, Jan 2020

Risk is a measure of future uncertainties in achieving successful requirement performance goals. Risk is associated with all aspects of a requirement. It includes identifying events that are reasonably predicted that may threaten a mission. Risk addresses the potential variation from the planned approach and its expected outcome. Risk analysis includes all risk events and their relationships to each other. The risk assessment consists of two components: (1) probability (or likelihood) of that risk occurring in the future; and, (2) the consequence (or impact) of that future occurrence. Risk management requires a top-level assessment of the impact on the requirement when all risk events are considered, including those at the lower levels.

The FSM focuses on the critical areas that may impact the requirement and thus impact the performance results. Risk events may be determined by examining each required performance element and process in terms of sources or areas of risk. These areas are generally grouped as cost, schedule, and performance, with the latter including technical risk. There could be significant consequences if early risk assessment isn’t accomplished. The following are some typical risk areas:

• Business Risk
  • Scheduling issues that may impact success
  • Contractors performing inherently governmental functions or unauthorized personal services
  • Stakeholders engagement
• Technical Risk
  • Maturity and relevancy of technology
  • Personnel turnover
  • Procurement fraud
• Funding Risk
  • Are funds identified for which availability is reliant on pending events or approvals?
  • Have adequate funds been identified?
• Process Risk
  • Are new processes required to be implemented?
  • Will the best contractors have time to propose?
• Organizational Risk
  • Implementing change in an organization
  • Organizational conflicts of interest
• Risk Summary
  • Overview of the risk associated with implementing the initiative e.g., is there adequate service life remaining to justify this change?
• Additional Areas
  • Environmental impact
  • Security (i.e., government property, control and oversight of facility access, clearances, etc.)
  • Safety
  • Occupational Health

Identifying risk areas requires the MFT to consider relationships among all the risks and to identify potential areas of concern that would have otherwise been overlooked. This is a continuous process, which examines each identified risk (that may change as circumstances change), isolates the cause, determines the effects, and then determines the appropriate risk mitigation plan. The MFT may consider requesting a risk mitigation plan be submitted as part of the offeror’s proposal if there is a risk that needs to be addressed immediately. Additional guidance about Risk can be found in the Risk Management Guide, Balancing Incentives and Risks in Performance-Based Contracts and a DAU continuous learning course entitled CLM 017, Risk Management.

Requirements analysis is a systematic review of a requirement, given the data, information, and research gathered during the Planning Phase. This analysis is the basis for establishing high-level objectives, developing performance tasks and standards, writing the performance work statement, and developing the QASP. The preferred requirements document for acquiring services is a performance work statement or statement of objectives. The MFT is familiar with the Performance-Based Services Acquisition Guidebook when acquiring services.

The MFT will review Step Four under the Service Acquisition Mall. In this section of the mall, tools are provided to assist the team in creating a requirements road map, a performance work statement and statement of objectives, and a QASP. Another available tool is the Acquisition Requirements Roadmap Tool (ARRT) Suite. The Suite is a collection of tools that helps build strategic elements of acquisition documents by utilizing structured processes which help the team ask and answer the right questions related to the acquisition. The ARRT Suite includes a Requirements Definition tool, an Evaluation Factors tool, a Performance Assessment tool, and a Cost Estimation tool.

Reference Source: Guidance from OUSD(A&S)
Based on DAG CH 10-3.2.1 Step Four – Define Requirements, Jan 2020

There is no mandatory format for the PWS or the SOO. Follow your agency’s procedures for the proper format required for these two documents. A sample format is provided under the Service Acquisition Mall. Some PWS or SOOs may require that acceptable quality levels be defined in the document.  When developing the PWS, the MFT may consider the following best practices and lessons learned:

• The purpose of defining your requirement at high level objectives and tasks is to encourage innovative solutions for your requirement. Don’t specify the requirement so tightly that you get the same solution from each offeror. If all offerors provide the same solution, there will be no creativity or innovation in the proposals.
• Remember that the way the PWS is written will either empower the private sector to craft innovative solutions, or stifle that ability.

After the MFT has completed the draft of the PWS, the team will review the PWS and answer the following questions to ensure it covers the required need:

• Does the PWS avoid specifying the number of contractor employees required to perform the work (except when absolutely necessary)?
• Does the PWS describe the outcomes (or results) rather than how to do the work?
• What constraints are placed in the PWS that restrict the contractor’s ability to perform? Are they essential? Do they support the vision?
• Does the PWS avoid specifying the educational or skill level of the contract workers (except when absolutely necessary)?
• Can the contractor implement new technology to improve performance or to lower cost?
• Are commercial performance standards used?
• Do the performance standards address quantity, quality, and/or timeliness?
• Are the performance standards objectives easy to measure and timely?
• Are there incentives to motivate the contractor to improve performance or to reduce costs?
• Are there disincentives to handle poor performance?
• Will the contractor focus on continuous improvement?
• Is the assessment of quality a quantitative or qualitative assessment?
• Would two different CORs come to the same conclusion about the contractor’s performance based on the performance standards objectives?
• Are AQLs clearly defined?
• Are the AQL levels realistic and achievable?
• Will the customer be satisfied if the AQL levels are exactly met? (Or will they only be satisfied at a higher quality level, or a lower level?)
• Are the individuals who will perform the evaluations identified?

Reference Source: Guidance from OUSD(A&S)
Based on DAG CH 10-3.2.1 Step Four – Define Requirements, Jan 2020

The MFT will be familiar with the Quality Assurance provisions in the Federal Acquisition Regulation Part 46 and Defense Federal Acquisition Regulation Supplement Part 246, including its Procedures, Guidance and Information (PGI) Part 246, prior to developing the QASP that will be supporting the PWS or SOO.  The QASP is used to manage contractor performance by ensuring that systematic quality assurance methods validate that the contractor’s quality control efforts are timely and effective and are delivering the required results. The QASP is intended to be a “living” document that should be reviewed and modified whenever necessary. The method and degree of performance assessment may change over time, depending on the level of confidence in the contractor. The premise is that the contractor, not the Government, is responsible for managing the QASP quality controls and ensuring that the performance meets the terms of the contract.  A few ways to assess a contractor’s performance that can properly monitor performance and quality include:

• Methods of Surveillance: metrics, random sampling, periodic inspection, 100% inspection, customer feedback, and third party audits.
• Sampling Guide: a written procedure that states what will be checked, the AQL, and how the checking will be done.
• Decision Tables: identify different examples of unsatisfactory performance, probable cause factors, and the resulting consequences. When a service has failed to meet performance standards, a decision must be made as to who is at fault. A decision table is used for this purpose.
• Checklists: Used to record what has been checked by a sampling guide and to record information on contract items not covered by sampling.

After the MFT completes the draft of the QASP, the team reviews the QASP and answers the following questions to ensure the required need is covered:

• Is the value of evaluating the contractor’s performance on a certain task worth the cost of surveillance?
• Has customer feedback been incorporated into the QASP?
• Have assessment tools, i.e., methods of surveillance, sampling guide, etc., been provided in the QASP?

Reference Source: Guidance from OUSD(A&S)
Based on DAG CH 10-3.2.1 Step Four – Define Requirements, Jan 2020

After the MFT completes the PWS and the QASP, the team compares the market research report to the actual requirements to determine if the needs to complete the mission are realistic or if changes to the market research report or requirements should be recommended. Once the analysis is complete, the market research report is finalized in accordance with agency procedures.

Reference Source: DoDI 5000.73 Cost Analysis and Procedures, Section 3.1.d

 

CAPE may conduct a cost estimate for acquisition of a contracted service at Director, CAPE’s discretion. All other cost estimates for contracted services must be conducted in accordance with the policies and procedures issued by the relevant Service Cost Agency.

Reference Source: Guidance from OUSD(A&S)
Based on DAG CH 10-3.2.1 Step Four – Define Requirements, Jan 2020

Based on the market research results, the MFT develops the IGCE which supports the requirement.  The IGCE is the Government’s independent estimate of the resources and projected cost of the resources a contractor will incur in the performance of the contract. The IGCE is very important to the acquisition strategy of the requirement. The IGCE helps determine what other policy, statue, and regulation requirements are necessary in order for this requirement to be released as a Request for Proposal. For example, the IGCE determines which Service Category Level applies and the Decision Authority.

Additional information on IGCEs is available in the DoD IGCE Handbook for Services Acquisition.

Reference Source: Guidance from OUSD(A&S)
Based on DAG CH 10-3.2.1 Step Four – Define Requirements, Jan 2020

Prior to moving onto Step 5 – Acquisition Strategy, the FSM is required to obtain approval from the SRRB chair as stated in Step 2 – Review Current Strategy.

Reference Source: Guidance from OUSD(A&S)
Based on DAU Service Acquisition Mall, Step 4, Jan 2020

As part of the requirements development process you must identify and analyze risk areas that can impact the performance results you are trying to achieve. Identify possible events that can reasonably be predicted which may threaten your acquisition. Risk is a measure of future uncertainties in achieving successful program performance goals. Risk can be associated with all aspects of your requirement. Risk addresses the potential variation from the planned approach and its expected outcome.

Risk assessment consists of two components:

(1) probability (or likelihood) of that risk occurring in the future and

(2) the consequence (or impact) of that future occurrence.

Risk analysis includes all risk events and their relationships to each other. Therefore, risk management requires a top-level assessment of the impact on your requirement when all risk events are considered, including those at the lower levels. Risk assessment should be the roll-up of all low-level events; however, most likely, it is a subjective evaluation of the known risks, based on the judgment and experience of the team. Therefore, any roll-up of requirements risks must be carefully done to prevent key risk issues from “slipping through the cracks.”

It is difficult, and probably impossible, to assess every potential area and process. The program or project office should focus on the critical areas that could impact your program and thus impact your performance results. Risk events may be determined by examining each required performance element and process in terms of sources or areas of risk. Broadly speaking, these areas generally can be grouped as cost, schedule, and performance, with the latter including technical risk. When the word “system” is used, it refers to the requirement for services as a “system” with many different activities and events. The more complex the service requirement is, the more likely it will have the components and characteristics of a “system.” The following are some typical risk areas:

• Business/Programmatic Risk
• Scheduling issues that may impact success?
• Technical Risk
• Maturity of technology and processes reliant on technology
• Funding Risk
• Are funds identified for which availability is reliant on pending events or approvals? Have adequate funds been identified?
• Process Risk
• Are new processes required to be implemented?
• Will the best contractors have time to propose?
• Organizational Risk
• Implementing change within an organization
• Risk Summary
• Overview of the risk associated with implementing the initiative e.g. “Is there adequate service life remaining to justify this change?”

Additional areas, such as environmental impact, security, safety, and occupational health are also analyzed during the requirements definition phase. The acquisition team should consider these areas for early assessment since failure to do so could cause significant consequences. Program/project managers must recognize that any work being performed on government property or government workspace should have the proper control and oversight into access of facilities, clearances, and visitor control.  Identifying risk areas requires the acquisition team to consider relationships among all these risks and may identify potential areas of concern that would have otherwise been overlooked.

This is a continuous process that examines each identified risk (which may change as circumstances change), isolate the cause, determine the effects, and then determine the appropriate risk mitigation plan. If your acquisition team is requesting the contractor to provide a solution as part of their proposal that contains a performance-based statement of work and performance metrics and measures, then it is also appropriate to have the contractor provide a risk mitigation plan that is aligned with that solution.

Reference Source: Guidance from OUSD(A&S)
Based on DAU Service Acquisition Mall, Step 4, Jan 2020

Like risk analysis, requirements analysis means conducting a systematic review of your requirement given the guidance you captured from your stakeholders during the planning phase steps One, Two, and Three.

The objective of this step is to describe the work in terms of required results rather than either “how” the work is to be accomplished or the number of hours to be provided ( FAR 37.602 ). This analysis is the basis for establishing the high level objectives, developing performance tasks, and standards, writing the PWS, and producing the QASP.

The acquisition team needs to identify the essential processes, and outputs or results required. One approach is to use the “so what?” test during this analysis. For example, once the analysis identifies the outputs, the acquisition team should verify the continued need for the output. The team should ask questions like the following:

• Who needs the output or result?
• Why is the output needed?
• What is done with it?
• What occurs as a result?
• Is it worth the effort and cost?
• Would a different output be preferable?
• And so on…

Reference Source: Guidance from OUSD(A&S)
Based on DAU Service Acquisition Mall, Step 4, Jan 2020

The requirements roadmap worksheet provides a method that links required performance to the overall acquisition desired outcomes. The roadmap takes the performance tasks and aligns performance standards and acceptable quality levels (AQLs). It also includes detailed inspection information and responsibilities. Each of these areas will be discussed in greater detail in this step. When using this approach, it is vital that all elements of the document be aligned with the mission objectives you are trying to deliver. If you develop a performance task and standard, but have no way to inspect it, you have a problem. In this case you will need to revisit the objective or find new technology for the inspection. All the elements must fit together as a whole before writing the PWS. As you build your roadmap with high level objectives and task statements, prioritize them in descending order of importance based on risk, criticality or priority. This will help you later when determining what you want to evaluate in a contractors proposal.

Initially, the High Level Objectives (HLO) need to be defined. What must be accomplished to satisfy the requirement? This should have been accomplished during steps 1 and 2 when you were talking with your stakeholders and customers. To define HLOs, list what needs to be accomplished to satisfy the overall requirement, from a top-level perspective . HLOs are similar to level two in work breakdown structures.  Tasks are the results or actions required to achieve the HLO. It may take several tasks to satisfy a HLO. Tasks consist of results, the context of what or who the results pertain to and what actions are required to complete the task. Defining the task goes into greater detail and expands the stakeholder analysis beyond the top-level perspective. The goal of a task is to adequately describe what action or result is required (not how to accomplish it). Tasks are generally nouns and verbs and tend to be declarative statements such as the following:

• Conduct a study on …
• Provide financial analysis of…
• Maintain vehicles…
• Review and assess…
• Develop a strategic plan…
• Identify potential…
• Perform and document…

When developing tasks ask the question “WHY is this action needed?” A “because” answer usually drives the focus on the performance results needed. “Why do you want the river to be dredged?” “Because we want the boats to be able to go in and out.” Bottom line: we need to keep the river navigable. That is the objective.

Next, identify appropriate and reasonable performance standards (i.e., how well the work must be performed to successfully support mission requirements). The purpose is to establish measurable standards (adjectives and adverbs) for each of the tasks that have been identified. The focus is on adjectives and adverbs that describe the desired quality of the service’s outcome. How fast, how thorough, how complete, how error free, etc. Examples of performance standards could include the following:

• Response times, delivery times, timeliness (meeting deadlines or due dates), and adherence to schedules.
• Error rates or the number of mistakes or errors allowed in meeting the performance standard.
• Accuracy rates.
• Milestone completion rates (the percent of a milestone completed at a given date).
• Cost control (performing within the estimated cost or target cost), as applied to flexibly priced contracts.

This should reflect the minimum needs to meet the task results. The standards you set are cost drivers because they describe the performance levels that the contractor must reach to satisfy the task. Therefore, they should accurately reflect what is needed and should not be overstated. In the case of keeping a river navigable, the standard might be: “100 feet wide, 12 feet deep at mean low water.” Thus we have a measure for what we define as “navigable.” Standards should accurately reflect what is needed and should not be overstated. We should ask the following questions in this area:

• Is this level of performance necessary?
• What is the risk to the government if it does not have this level of performance?
• What is the minimum acceptable level of performance necessary to successfully support your mission?

In the case of the navigable river, 12 feet deep means low water might be sufficient for pleasure craft type usage. However, setting a depth of 34 feet which might be needed for larger commercial watercraft that may never use that river would be considered overkill and a waste of money. The standard must fit, or be appropriate to, the outcome’s need.  The performance standards should describe the outcome or output measures but does not give specific procedures or instructions on how to produce them. When the government specifies the “how-to’s,” the government also assumes responsibility for ensuring that the design or procedure will successfully deliver the desired result. On the other hand, if the government specifies only the performance outcome and accompanying quality standards, the contractor must then use its best judgment in determining how to achieve that level of performance.

Remember that a key PBA tenet is that the contractor will be entrusted to meet the government’s requirements and will be handed both the batons of responsibility and authority to decide how to best meet the government’s needs. The government’s job is to then to evaluate the contractor’s performance against the standards set forth in the PWS. Those assessment methods identified in the QASP, together with the contractor’s quality control plan, will also help in evaluating the success with which the contractor delivers the contracted level of performance.