Additional Topics

Incentives and/or disincentives should be linked in an unambiguous manner to the AQL and performance metrics to define what actions are taken when the contractor deviates (plus or minus) from the AQL. The PWS and QASP define all elements that form a direct linkage between the requiring agency's performance requirements and the application of incentives for the contractor. These are expressed in textual form in various sections of the PWS and QASP in accordance with the ITES-2S Ordering Guide (1.2M MS Word file). These linkages may not be as evident as they should be.

SAIC recommends development of a table to manage the data BEFORE the PWS and QASP are developed. This table, albeit a bit cumbersome to work with for large requirements, is an excellent way of managing the critical data that underlies the PWS and QASP. And thus, more relationships are evident in the beginning and throughout the task order requirements development.

As the requiring agency, all elements must be considered carefully to assure a sound PBSA strategy for the task order. While providing the supporting data management discipline to aid in making all parts of the task order request, this table will also aid in making the documents internally consistent as well as complete.

Constraints

One of the objectives of PBSA is to provide greater flexibility for contractors in accomplishing the required services (outcomes) of a task order. But, the approaches, methodologies, processes, etc., employed by a contractor often must be constrained by the operating environment of the requiring agency and end users. These constraints are unavoidable, so they should be documented in the PWS.

Applicable Documentation - Directives may include, but are not limited to: technical orders, regulations, military specifications, government documents, programmatic documents, manuals, or industry documents. Following analysis, these are then documented in the "Application Documents" section of the SOW or PWS or in the "Operating or Programmatic Constraints" of the SOO. The key here is that the requiring agency must determine the specific applicability of each item. Several suggested considerations:

• Collect information on all agency directives and for the local (end user) levels
• Make sure that all identified items are completed cited, i.e. title, identification nomenclature, version or date, etc.
• Avoid directives that specify "how" work is to be done or note that these sections of the directives are not mandatory for the contractor (Often directives are written assuming that the government would be performing the work, therefore the procedural "how" aspects may not be applicable under a PBSA.)
• Narrow any citation to the specific sections of a directive that are applicable to the contractor’s performance and exclude sections that are not applicable
  

Workloads – Historical and Projected

Workloads, in a broad sense, are characteristics of a service. Typically these data are very significant in the sizing, design, or scope of a service (or product) being acquired. Workload data may include such things as numbers of items ordered (per day, per week, per month, etc), average rates for performance, current defect rates, total numbers of lines of code to be maintained, etc. This represents a large universe of information that can be documented as applicable to the services being ordered.

For example, in call center operations the historical data is usually a good basis for forecasting routine call loads and as an indicator of the peak or surge requirements experienced over time.

Task order requests often represent a new order to continue (expand or change) services that are already being provided by the government or a contractor. The SOW/PWS/SOO will define the government's requirements going forward, but often omits valuable detail information regarding the actual workloads involved.

Workload data is often closer to the daily management metrics than to the metrics that ultimately form performance standards. Rarely as an organization transitions from classical services acquisition to PBSA do they have the historical data captured in a manner that is consistent with the new view of required services and outcomes.

Without this data, responders to the task order request must make assumptions about workload, both historical and projected into the future. Providing historical (and projected) workload gives the bidder a better understanding of the magnitude of the requirement and necessary basic understanding of the requirements. Some might say that this data "levels the playing field," giving all bidders an equal opportunity to respond to a task order request — and so much the better for the government — more valid bids means more competitions and better value.

While a tenet of PBSA is shifting additional responsibility and risk to contractors, an unfortunate side effect is predictably higher pricing for the services offered in consideration of perceived risk. Where solid, germane workload data can be made available, bidders will be able to "sharpen the pencil," both in terms of price and quality offered.

Comprehensive and accurate workload data directly contributes to the quality of a PBSA solicitation - both the task order request and the quality of the task order proposals (and pricing) from contractors. Additionally, workload analysis can also be very useful in building a surveillance plan, especially with regards to sizing the surveillance effort with regards to quality/cost trade-offs.

Evolution of Performance Standards, AQL, and Incentives

Metrics, and all the processes that surround them, must be viewed as evolving — "sun setting" or cancelling ones no longer needed, revising others, and creating new ones where needed. This is especially true for longer tasks. Typical drivers for this include:

• Task changes, e.g. a project progresses through a development/sustaining life cycle such that the services being performed are changing significantly
• Process improvements may make initial standards “too easy”
• Issues or external factors may make initial standards unrealistic
• Customer objectives change
  

A process for mutual agreement and change should be put in place. The QASP is an excellent place to describe a process for this evolution. This affects the standards, metrics, AQL and potentially the incentives (or disincentives) that are awarded based on the metrics. It is important to identify changes to metrics and incentive structures well enough in advance for the contractor to prepare to be evaluated against the new metrics.

In some circumstances, performance standards may not be readily definable at the time the Task Order Request and PWS/QASP are prepared. Potentially, the Task Order could specify a subtask to develop performance standards, metrics, and AQL for the task or for a follow-on to the task.