Jim Atkisson
Mary Boehly
Carolyn Conroe-McMillan
John Corso
Jo-Lynn Davis
Tony Harvin
Pam Hitz
Karen Maris
William Pulman
Michael Rebain
Shari Reid
Kent Rosenlof
Planning A Performance Based Statement of Work For Software Development Contracts
Examples - Performance Requirement Summary
Performance Based Service Contracting focuses on three critical
elements, a performance work statement, a quality assurance plan
and appropriate incentives. Additional information on the
concepts being implemented for contracted services can be found in
the OFPP Guide to Best Practices for Performance-based Service
Contracting. This document discusses these elements as they
relate to the performance-based work statement for contracts.
The performance work statement defines the Government's
requirements in terms of the objective and measurable outputs. It
should provide the vendor with answers to five basic questions:
what, when, where, how many, and how well. It is important to
accurately answer these questions in order to allow the vendor the
opportunity to accurately assess resources required and risks
involved.
It is recommended that a team of specialists be assigned to
facilitate developing more comprehensive statements of work that
efficiently structure and clearly define the requirements,
performance standards, acceptable quality levels, methods of
surveillance, incentives (positive and negative), and evaluation
criteria. The team should consist of contract specialists,
computer technical specialists, and subject matter specialists
representing customers within the scope of the project.
This document describes items that can be included in performance
work statements for acquiring computer application systems or
software development services through a contracting effort. These
items are discussed as follows:
1.0 INTRODUCTION, OVERVIEW, OR BACKGROUND
This section provides background and descriptions of the Agency's
organizational structure, where the services are to be provided,
the importance of the software development effort, any previous
efforts germane to this effort, and the hardware and software
resources in use. This section could also include agency or
organization specific information about government furnished
items, working hours, federal holidays, and a glossary to define
terms used within the body of the work statement.
2.0 OBJECTIVE
This section includes a brief description of the purpose of the
contract.
3.0 SCOPE
This section defines how the contracting effort fits within the
existing or intended customer environment both technically and
organizationally. Examples of items to include here are a
detailed description of the software development requirement(s),
the number and location of users, the target processing
environment including operating systems, system and data
architecture(s), communications topology, and any other pertinent
information.
4.0 PERFORMANCE REQUIREMENTS
Performance requirements are statements describing the required
services in terms of output. They should express the outputs in
clear, concise, commonly used, easily understood, measurable
terms. They should not include detailed procedures that dictate
how the work is to be accomplished. The following statements are
examples of the kinds of information to be included in the
performance requirements section:
For New and/or Conversion Software Development -
* During the life of the contract verify conformance with
agency specific information processing standards and
functional requirements. Prior to delivery of new
software, demonstrate the operational capability of the
system software.
* Interfaces must contain compatibility among system
components in the operational environment.
* Documentation for deliverables must match the agency
specific system processing and operational procedures.
* Meet the following delivery dates/milestones; phasing
is an optional approach. Dates are specified according
to agency delivery requirements.
* Training may vary according to user levels/needs (e.g.
end users, administrators, analysts, help desk support,
management, etc.).
* Security - meet all Government and agency specific
requirements.
For New Software Development -
* For new software development, delivery of fully
operational systems conforming to the operational
environment and specified user requirements.
* Newly developed software shall not adversely affect
system performance.
* New releases of software must maintain previously
provided functionally, while providing enhanced
capabilities or systems corrections.
For Conversion Software Development -
* For software conversion projects, provide an inventory
of programs and a description of the complexity of the
existing systems and programs for transfer to another
processing system or hardware and software platform
operational environment including but not limited to
databases, files, programs, lines of code, and
interdependencies.
* For software conversion efforts involving rehosting to
another platform, architecture, operating system, data
base, programming language, and/or communications
system provide an inventory of system and application
programs, descriptions of the current hardware and
software environment, and if applicable data
distribution methods.
* For conversion projects of mission critical systems,
provide parallel processing and/or system validation of
the old and new systems prior to implementation.
For each requirement, there should be a corresponding standard(s),
a statement of the maximum allowable degree of deviation from the
standard, the method of surveillance to determine whether the
standard is met, and a positive and/or negative incentive based on
adherence to the standard.
5.0 PERFORMANCE STANDARDS
The performance standards establish the performance level(s)
required by the Government. These standards are driven by the
application system(s) being converted or developed. The agency
should ensure that each standard is necessary, is carefully
chosen, and not unduly burdensome. (See Performance Requirements
Summary for a listing of examples of standards.)
6.0 QUALITY ASSURANCE PLAN
The quality assurance plan gives the Government flexibility in
measuring performance and serves as a tool to assure consistent
and uniform assessment of the contractor's performance. This plan
is primarily focused on what the Government must do to ensure that
the contractor has performed in accordance with the performance
standards. It defines how the performance standards will be
applied, the frequency of surveillance, the maximum acceptable
defect rate(s), and the value of each performance requirement as a
percentage of the overall contract. A good quality assurance plan
should include a surveillance schedule and clearly state the
surveillance methods to be used in monitoring the contractor's
performance.
The acceptable quality level as defined in the quality assurance
plan establishes a maximum allowable error rate or variation from
the performance standard(s). Depending on agency level policy and
procedures the quality assurance plan may or may not be included
as part of the performance work statement in the contract;
however, the methodology for evaluating performance of the
contract must be included.
7.0 INCENTIVES - Positive and Negative
Incentives should be used when they will encourage better quality
performance and may be either positive, negative, or a combination
of both; however, they do not need to be present in every
performance based contract as an additional fee structure. In a
fixed price contract, the incentives would be embodied in the
pricing and the contractor could either maximize profit through
effective performance or have payments reduced because of failure
to meet the performance standard.
Positive Incentives - Actions to take if the work exceeds the
standards. Standards should be
challenging, yet reasonably attainable.
Negative Incentives - Actions to take if work does not meet
standards.
The definitions of standard performance, maximum positive and
negative performance incentives, and the units of measurement
should be established in the solicitation. They will vary from
contract to contract and are subject to discussion during a source
selection. It is necessary to balance value to the Government and
meaningful incentives to the contractor. Incentives should
correlate with results. Follow-up is necessary to ensure that
desired results are realized, i.e., ensure that incentives
actually encourage good performance and discourage unsatisfactory
performance.
8.0 EVALUATION CRITERIA
The evaluation criteria is defined under Section M in the
solicitation document. This section describes how proposals will
be evaluated in terms of technical merit and costs. The criteria
are developed based on the requirements of the specific project.
Critical areas discussed in the performance-based work statement
and the relative order of importance assigned to each of these
areas must be identified. The elements are usually presented as a
matrix to be used in evaluating the technical proposals. Past
Performance must be included as a criterion. Section L of this
same document contains instructions for the preparation of the
prospective offerors' technical and business proposals.
9.0 PERFORMANCE REQUIREMENTS SUMMARY
The performance requirements summary can be presented as a matrix similar to the examples starting on the next page. This type of chart could be included in the performance work statement or placed elsewhere in the contract to summarize the requirements and display the relationships of each of the elements in the performance work statement. The summary chart is a tool that can easily summarize the elements presented in the performance work statement. Notice, for each requirement there can be one or more standards, defined maximum allowable degree of deviation from the standard(s), method(s) of surveillance to determine adherence to the standard(s), and positive and negative incentives for meeting, exceeding, or failing to meet the standard(s).
|
REQUIRED SERVICE (Performance Requirements) |
STANDARD (Performance Standards) |
MAXIMUM ALLOWABLE DEGREE OF DEVIATION REQUIREMENT (AQL) |
METHOD OF SURVEILLANCE (Quality Assurance) |
MAXIMUM PAYMENT PERCENTAGE FOR MEETING/EXCEEDING THE AQL (Incentives) |
|---|---|---|---|---|
|
1. During the life of the contract verify conformance with agency specific information processing standards and functional requirements. Prior to delivery of new software, demonstrate the operational capability of the system software. |
Functionality of the software to meet required systems architecture and processing capabilities. |
All requirements mandated by law or regulation must be 100% compliant. Functionality defined in the requirements must be prioritized and tolerances for deviation assigned for each component. %* of operational capability is acceptable, as determined by the Quality Assurance Plan. * Value to be determined by the Agency's requirements, on a case-by-case basis.
|
Independent verification and validation (IV&V) for testing new releases of software to determine that previous functionality is maintained. Customer satisfaction as measured through limited validated customer complaints, feedback, and surveys. For conversion projects, independent verification and validation (IV&V) for developing or maintaining system processing/benchmark during parallel processing. |
100% payment for meeting all mandated requirements. Nonconformance is unacceptable. Payment is contingent on amount or degree of functionality delivered, according to priority of each function.* * Value to be detemined by the Agency's requirement on a case-by-case basis. Percentage of payment for each component shall be determined in the Quality Assurance plan.
|
| 2. Interfaces must maintain compatibility among system components in the operational environment |
Service Levels for software: Through-put in terms of processing response time, number of transactions processed per second; volume of data processed over time. Compatibility with particular hardware and software
within the existing processing environment.
Functionality of software to meet required systems architecture and processing
capabilities. |
No deviation |
Customer satisfaction as measured through limited validated customer complaints, feedback and surveys. Operational monitoring by use of system statistics and logs Independent verification and validation (IV&V) for testing new software, including verifying results to determine that requirements and specifications are met.
|
100% payment
|
| 3. Documentation for deliverables must match the agency specific system processing and operational procedures |
Documentation meets agency specific formats for accuracy and completeness |
%* of deviation. * Values to be determined by the agency's requirements on a case-by-case basis.
|
Independent verification and validation (IV&V) for determining that documentation delivered by the contractor matches the system processing and operational procedures. |
100% payment |
| 4. Meet the following delivery dates/milestones (phasing is an optional approach) - Dates are specified according to agency (delivery) requirements
|
Delivery dates are met, or exceeded |
%* of deviation. *Values to be determined by the agency's requirements on a case-by-case basis.
|
100% inspection |
Early delivery bonus* *Value determined by the agency's on a case-by-case basis. There may be excusable delays in which it may be in the Government's
best interest to grant forbearance, on a case-by-case basis. Forbearance or excusable delays to be considered on a case-by-case basis
|
| 5. Training (may vary according to user levels/needs) (e.g. end users, administrators, analysts, help desk support, management, etc.)
|
Proficiency levels on software required for job performance ( %) of students at level of competency)* (Levels: Knowledge, Comprehension, Application, Analysis) * Values to be determined by the agency's requirements. |
% of students not performing at required level of proficiency |
Surveys Proficiency exams Validated customer calls to help desk Random evaluation of training |
Proportional reduction in contract line item price, or overall contract value , attributable to training.
|
| 6. Security |
Meet all Government and agency specific requirements. |
No deviation |
100% inspection to ensure that all Government and Agency specific requirements have been met. Independent verification of security procedures - defined by agency (could be performed by a third party, or another agency according to current security regulations and measures) |
100% payment
|
| 7. For new software development, delivery of fully operational systems conforming to the operational environment and specified user requirements. |
Service levels for software: Through-put in terms of processing response time, number of transactions processed per second; volume of data processed over time. Compatibility with particular hardware and software
within the existing processing environment. Functionality of software to meet required systems architecture and processing capabilities. |
All requirements mandated by law or regulation must be 100% compliant. Functionality defined in the requirements must be prioritized and tolerances for deviation assigned for each component. %* of operational capability is acceptable as determined by the Quality Assurance Plan. * Values to be determined by the Agency's requirements on a case-by-case basis
|
Customer satisfaction is measured through limited validated customer complaints, and surveys. Independent verification of software functionality to meet required systems architecture and processing capabilities. Operational monitoring by use of system statistics and logs. |
100% payment for meeting all mandated requirements. Payment is contingent on amount or degree of functionality delivered according to priority of each function.* * Value to be determined by the agency's requirements on a case-by-case basis.
Percentage of payment for each component shall be determined in the Quality
Assurance Plan.
|
| 8. Newly developed software shall not adversely affect system performance. |
Standards affecting system performance include but are not limited to: response time for resolving problems; CPU busy; response time; memory utilization; storage utilization. |
Base line functionality is met at 100% Non critical functionality is met at %* *Values to be determined by the Agency's requirements on a case-by-case basis. |
Operational monitoring by use of system statistics and logs |
100% payment for meeting all mandated requirements. Nonconformance is unacceptable. Payment is contingent on amount or degree of functionality delivered, according to priority of each function.* * Value to be determined by the agency's requirements on a case-by-case basis. Percentage of payment for each component shall be determined in the Quality Assurance Plan.
|
|
9. New releases of software must maintain previously provided functionality, while providing enhanced capabilities, or systems corrections. |
Software adds value and improves existing functionality without negatively impacting the existing operational environment. |
Base line functionality is met at 100%. Non critical functionality is met at %* *Values to be determined by Agency's requirement, on a case-by-case basis. |
Independent Verification and Validation (IV&V) for testing new releases of software to determine that previous functionality is improved. Customer satisfaction is measured through validated customer complaints and surveys. |
100% payment for meeting all mandated requirements. Nonconformance is uacceptable. Payment is contingent on amount or degree of functionality delivered, according to priority of each function.* * Value to be determined by the agency's requirement on a case-by-case basis. Percentage of payment for each component shall be determined in the Quality Assurance Plan.
|
| 10. For software conversion projects, provide an inventory of programs and a description of the complexity of the existing systems and programs for transfer to another processing system or hardware and software platform operational environment including, but not limited to: databases, files, lines of code and interdependencies.
|
Inventories shall be complete and accurate. Systems descriptions accurately identify the existing systems complexity. Adhere to Agency configuration management standards. |
Less than %* of inventory omissions. * Value to be determined by the Agency's requirement.
|
Independent verification and validation (IV&V) of the software inventory and system descriptions. For conversion projects, Independent verification and validation (IV&V) adherance to Agency configuration management standards. |
100% payment for meeting all mandated requirements. Proportional reduction in contract line item price, or overall contract value, attributable to inventory omissions. |
| 11. Software conversion effort for rehosting from one platform, architecture, operating system, database, communication system, programming language, and/or data distribution method to another. |
Service Levels for software: Through-put in terms of processing response time, number of transactions processed per second; volume of data processed over time. Compatibility with particular hardware and software
within the existing processing environment.
Functionality of required systems architecture and processing capabilities.
|
Base line functionality is met at 100%. Non critical functionality is met at %.* * Value to be determined by the Agency's requirement. |
Customer satisfaction is measured through limited validated customer complaints and surveys. Independent verification and validation (IV&V) for testing new releases of software to determine that previous functionality is maintained. For conversion projects Independent verification and validation (IV&V) for developing or maintaining system processing/ benchmarking during parallel processing. |
100% payment for meeting all mandated requirements. Proportional reduction in contract line item price, or overall contract value, attributable to loss in functionality, or degraded system performance. % of overall contract payment will be witheld until * number of production processing cycles. * To be determined by the Agency's requirement. |
| 12. For conversion projects of mission critical systems, provide parallel processing and/or system testing of the old and new systems prior to implementation. |
Service Levels for software: Through-put in terms of processing response time, number of transactions processed per second, volume of data processed over time. Compatibility with particular hardware and software
within the existing processing environment.
Functionality of software to meet required systems architecture and processing
capabilities.
|
Data must be 100% accurate. |
Pre production testing of all functional components within the processing environment (e.g., hardware, software operating system, interfaces, etc.) Independent verification and validation (IV&V) for testing new software including verifying results to determine that requirements and specifications are met. |
100% payment for meeting all mandated requirements. Nonconformance is unacceptable. |
Last Updated: May 22, 1997