A Performance Work Statement (PWS) or Statement of Objectives (SOO) is a key document in the Request for Proposal (RFP) package. The RFP describes the purpose of the work to be performed, with the contract requirements set forth in clear, specific, and objective terms with measurable outcomes. A PWS describes the government’s requirements, the tasks that must be accomplished to satisfy the requirements, and when/how the government will know when the outcome has been satisfactorily achieved. A SOO, by contrast, describes the high-level outcomes or objectives the government wants to achieve, giving the vendors an opportunity to propose innovative solutions to meet the objectives defined by the government.

There is no specific format for a PWS/SOO, but they usually contain a brief description of services, background, objectives, scope, period of performance, quality control, and quality assurance.

In the case of Agile development, to the government must first identify if it wants to procure a service or a product. As recommended in the Contact Preparation section, a services contract is often the preferred contract for Agile efforts because it offers the most flexibility to change requirements through the life of the contract. The following questions can be used to help drive the critical thinking behind the development of a PWS/SOO for an Agile development contract.

Questions to help develop the PWS/SOO:

• Has the government determined that Agile is the only acceptable development strategy? Is the PMO open to other development methods proposed by the vendor to best deliver the product or system?
• Will the government or the contractor define the details of the Agile development process?
• What are the government vs. contractor roles and responsibilities?
• What will the government provide to the contractor (e.g., facilities, information)?
• What is the government’s “definition of done”?
• How is the contractor expected to interface with the PMO, testers, engineers, and other contractors?
• What are the government’s expectations of the contractor’s relationship with other contractors in the program?
• What are the government’s expectations of the contractor’s support of systems engineering reviews and test?
• What are the data rights requirements? How will data be transferred by the vendor during transition-out period of the contract?
• What is the minimum set of deliverables required?
• What is the minimum set of metrics that the contractor is required to track and report?
• How will the government measure performance?
• What are the incentives/disincentives associated with the performance measures?
• Does the government have specific job categories in mind for Agile development support, or does the government expect the offerors to propose their own teams to provide an optimal mix?

The PMO must decide who will be responsible for defining the Agile development processes and methodology. In some cases, the government may already have well-established Agile processes within the program, and the government may want to dictate the specific Agile development process that will be utilized in a PWS. Below is sample PWS language that can be used if the government “owns” or directs the Agile methodology or procedures:

Government Directed Agile Methodology:

The program will utilize an Agile development methodology for this program. The program will provide capability deliveries every 6 months in a product release. Each release will be composed of four 6-week sprint cycles. Sprint cycles are composed of a 1-week design period that includes requirements definition and prioritization, a 4-week development and operational testing cycle, and a 1-week end-user demonstration period. The contractor will work with the government in a team-based Agile environment. The program will create and maintain the system architecture, requirements backlog, and roadmaps that will be the basis for the contractor’s work. The contractor shall support the government in the development and estimate of user stories, a release plan, systems engineering products, and acceptance criteria.

Alternatively, the government may want the vendor community to propose the Agile development process and methodology that best suits the outcomes or objectives identified by the government. In this case, it may not even be necessary for the government to dictate the use of Agile, but instead simply to describe its expectations and objectives and utilize a SOO document format. Below is sample SOO/PWS language that can be used if the government wants the contractor to propose the development methodology and processes that will best meet the objectives identified by the government.

Contractor proposed development methodology:

The contractor shall propose a development methodology to best meet the requirements of the contract. At a minimum, the contractor shall develop and deploy usable capabilities to the program in 6-month increments. Each increment should include testing, IA, and deployment to ensure capabilities can be released to the user in an incremental fashion. The proposed solution shall include an explanation of how project and contract management, communication/collaboration with the government, security and privacy requirements, documentation, and reporting will function in conjunction with the proposed development methodology. The contractor shall identify the roles and responsibilities of the contractor versus the government under the proposed development methodology.

Under a services type contract, the government can provide specifications around the type of support that will be provided under the contract. Examples of Agile services requirements include user story collaboration, user centered design, code development, automated testing, usability testing, integration support, data migration, deployment support, DevOps support, configuration management, user training, metrics reporting, transition support, facilitation support, and Scrum Master coaching and training. It is also important to include transition-in and transition-out support as part of the PWS.

Due to the iterative nature of Agile, it is important to have a common “definition of done” agreed upon by the entire team. Therefore, the PWS should include a clear “definition of done.” It will be used to determine whether individual user stories are completed and can be accepted. The government can require the offerors to include a definition of done in their proposed Agile solution that the government will evaluate as part of the technical proposal. As a team matures, the definition can be expanded to include more elements. The contract should include provisions to allow for re-definition by agreement between the government and contractor.

The initial “definition of done” could include any of the following examples:

• All code has been pair programmed or has been code inspected.
• Capability has been delivered to the satisfaction of the user representative
• Coding standards have been met and re-factored where necessary.
• All 508 Compliance, Security requirements, Legal requirements have been factored into released code.
• Decision maker has accepted the final deliverable
• Capabilities are delivered in compliance with the Key Performance Parameters

The focus of the RFP/RFQ will depend largely on whether the government is pursuing a services or a product contract.

If pursuing a services contract, the most important aspect of the proposal should focus on the qualifications of the individual team members and the experience of the collective team executing the Agile development process. The government should request that the technical or management proposal include resumes of the proposed Agile team members, and provide specific examples of relevant experience executing the Agile development process on similar and related efforts.

If pursuing a product contract, the government should focus mainly on how well the offerors describe their plan to meet the government requirements. In this respect, if the contractor delivers to the government requirements, the government should not mandate use of Agile processes, but rather allow the contractor to propose a methodology that best meets the requirements identified by the government.

The table below gives examples of language that can be used in an Agile development RFP, including language for Section L (instructions to offerors) and Section M (evaluation factors for award). The government may use a combination of the below sample evaluation elements, but the authors of this site strongly advise against using too many evaluation factors/sub-factors (more than 3), which will greatly increase the time to evaluate and award the contract.  The government should only use technical evaluation factors/sub-factors that will generate proposal discriminators during the evaluation process. Furthermore, it is considered a best practice in the contracting community to define Section M (evaluation factors for award) before writing Section L (instructions to offerors), as reflected in the below table.

Please note, it is not advised that the government use the below proposal instructions and evaluation criteria when issuing task orders under existing contract vehicles. The government is advised to take full advantage of the flexibilities offered under FAR 15.505 fair opportunity provisions. In these cases, the government should not use a formal evaluation plan or detailed evaluation criteria (for more information, see the Contract Vehicles section under Contract Preparation).

*Evaluating relevant experience in the technical/management proposal is different from evaluating past performance as a separate and distinct factor. Generally, past performance must be evaluated for all major acquisitions; relevant experience (as part of the technical evaluation factor) is not required but it is highly recommended by the authors of this site.

Another popular approach to evaluating Agile solicitations is including challenge-events at which vendors present live demonstrations of their capabilities. For example, the government can require vendors to submit a working prototype based on a common dataset in a 24-hour product development challenge. This event be conducted in conjunction with the technical proposal and/or oral proposal, or can be used in place of a traditional written technical proposal.

Product challenges work well for Agile development solicitations because they require vendors to demonstrate or prove their ability to deliver capability. They also reduce the bid and proposal expenses for the vendors if the challenge replaces the technical proposal. On the other hand, product challenges can create a risk for the government because it has no guarantee that the team that worked on the challenge will be the same team that will work on the resultant contract. In theory, vendors can utilize their “A” team for the product demonstration but subsequently staff the project with less experienced staff. Therefore, it is recommended that the government combine a product-challenge with a “lightweight” technical proposal that presents the staffing plan and proposed development methodology processes. The use of Youtube videos for recorded oral proposals can be used as a “lightweight” technical proposal.

The Department of Homeland Security, Flexible Agile Support for the Homeland Request for Proposal featured a technical challenge.  The details of the challenge can be accessed here.

Below is suggested language that can be used for a video-based oral proposal:

The offeror shall submit a video that is no longer than X minutes in length, that addresses the following evaluation areas (insert evaluation criteria, questions, or scenarios).  It is recommended the video features Agile project team members proposed for this effort.

NOTE: The quality of the video submissions will not factor into the government’s feedback.  The government encourages low-cost video production, such as the cell phone video cameras.

Submission Instructions – Video submissions must be posted to Youtube.com for the government to access.  Videos may be marked public or private.  By XX date, the vendor must send a Youtube link and password to (email address) in order for the government to access the video submission.  The government will not provide access to the vendor’s video outside of the government evaluation team without the permission of the vendor.  Do not provide a shortened URL, such as youtu.be.

The contract should include the agreed pricing methodology or model. Some other considerations for pricing an Agile development include:

• Defining the invoicing periods and pricing instructions for both individual iterations and the project as a whole.
• Definitions of price per unit of work (UoW). Examples of a UoW include price per story point, price per function point, and price per feature point.
• Points are related to an estimate of size or effort; it is critical that each “point” is clearly defined.

Two typical ways to determine price per point:

• An average based on several previous projects
• Customized amount: supplier average point value for a few iterations during which time detailed costs are tracked. Then the supplier and customer agree to a custom price per point (can be FP or T&M NTE).
• Fixed price considerations:
  • Fixed price per iteration (perhaps calculated by reference to the amount of work required for that iteration or the business value of the relevant development items)
  • Fixed price per unit of work (price per user story, or feature point); may be difficult to estimate if the user stories have a different scope or value)

Traditional projects often include a detailed prescriptive list of what the vendor should deliver (usually in the form of lengthy documents) and how the artifacts are accepted. Onerous documentation requirements (e.g., earned value management) take time away from the team that should be focused on delivery. A detailed list of deliverable documents is not required for Agile; when applied appropriately, Agile is a structured and disciplined process and the government will receive “empirical” evidence of performance in the form of working software. The government should request “just enough documentation” to validate that the capabilities are being delivered in compliance with agency governance and IT system lifecycle requirements. Examples of the type of deliverables that could be requested for Agile include:

• Agile metrics reporting (e.g., team velocity)
• System design documentation
• Architecture reference/compliance documentation
• Automated testing results
• Lessons learned
• Periodic progress reports
• Training manual
• Information support plan

• Do the contract strategy and timelines support frequent capability releases?
• Is the program pursuing a services-based contract or completion/product delivery contract?
• Is the government the prime systems integrator?
• Does the program have dedicated contracting support?
• Is the contracting officer co-located with the program?
• Does the contracting environment support Agile development processes?
• Do existing contract vehicles support Agile delivery?
• What is the level of engagement between the contracting officer and Agile team?
• How is the government monitoring the contractor’s performance?
• Does the contract include a process for determining how many high-priority items identified by the Product Owner can be developed during the current sprint?
• Does the contract have to include a definition of “Minimal Viable Product” for each feature?
• Does the contract identify a process for developing and reprioritizing the sprint backlog?
• Does the contract describe how improvements agreed at a sprint review meeting are implemented?