_______________________________________________

SOFTWARE DEVELOPMENT CONTRACTS

PERFORMANCE-BASED SERVICE CONTRACTING (PBSC)

WORK STATEMENT


_______________________________________________

Prepared by
Software Development Committee
March 1997

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



CONTENTS

Planning A Performance Based Statement of Work For Software Development Contracts

Examples - Performance Requirement Summary


PLANNING A PERFORMANCE-BASED WORK STATEMENT FOR
SOFTWARE DEVELOPMENT CONTRACTS

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).



PERFORMANCE REQUIREMENTS SUMMARY


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.

     Delivery dates are met or exceeded.


     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

TOP OF PAGE