Although it doesn’t get as much attention in the conversation around improving government acquisitions, one area that really does matter is the style of solicitation documents. The format and structure of contracts has a huge impact on vendor participation, the competition process, finding qualified vendors, and, therefore, contract outcomes. When I started as a contract specialist, I was given hand-me-downs of past solicitations. It’s a fairly common practice to start the acquisition process by asking others for their documents, or just searching the internet or document repositories like FedBizOpps to replace names and dates.
Unfortunately, this practice means new contracts often repeat the shortcomings that are inherent in the structure of previous contracts. To improve outcomes, contracting officers should move away from these habits in favor of something that better fits the work to be done. The Technology Transformation Services’ Office of Acquisition has been developing an Agile Contract Format (ACF) to produce simple, effective contracts that also take advantage of post-award agile methods.
The role of the Uniform Contract Format
If you’ve ever been involved in the government acquisition process, you’ve almost certainly encountered the Uniform Contract Format (UCF), whether you realize it or not. Though the UCF is common, the Federal Acquisition Regulation (FAR) only requires the use of the UCF to create a solicitation in very limited circumstances — mainly FAR Part 15. For almost any type of IT acquisition, using FAR Part 15 - Contracting by Negotiation should be avoided at all cost. Using the UCF in conjunction with FAR Part 15 is the reason why so many government acquisitions involve a timeline of 18 to 24 months when another format could be much faster.
Using the UCF for a contract causes the government to issue solicitations thicker than great works of literature, but far less enjoyable. The crux of the problem rests with the UCF’s use of a Statement of Work (SOW) to describe the government’s need, or what acquisition professionals call the “requirements.” SOWs are the least desirable format for the government to communicate its requirements for industry’s services because it tells companies how to do something not what needs to be done. Making SOWs prescriptive rather than descriptive, is like telling a doctor what surgery you want before there's even been a diagnosis. Additionally, SOWs don’t account for pivots or design changes based on user feedback. What this usually means is that the government tries to imagine everything that may possibly happen or be needed and add it to the UCF’s SOW like a wish list.
An advantage of agile work methods is that they focus on discovering a solution to a problem after the contract is awarded, that is, during post-award execution, rather than specifying the detailed solution up front as with Part 15. An agile contract tries to specify problems requiring detailed solutions, often as Product Backlog Items that describe high level contract delivery areas.
Understanding this problem, the Office of Management and Budget and Office of Federal Procurement Policy directed agencies to stop using SOWs and shift to using a Performance Work Statement (PWS) for acquiring services. A PWS “should state requirements in general terms of what (result) is to be done, rather than how (method) it is done” Good contracting officers advise agencies that by buying expert services, it implies that you’re not the most knowledgeable in “how” work is done. As the mission owner, you are the expert in “what,” must get accomplished, but conflating the two puts your mission at risk and makes it harder for a contract to provide value.
Rather than make this substantive shift from how to what, some government buyers just retitle their old Statements of Work to be a “Performance Work Statement.” This helps agencies comply with oversight mandates, but doesn’t actually change the nature of their requests to industry. The length and complexity remains the same, so industry continues to lose time and effort just getting through documents to try and understand what the government wants from it. The government gets to be in the perennial position of saying, “That’s not what I wanted.” There’s an easier way to get started, especially when it comes to agile development.
What the Agile Contract Format (ACF) improves
Contracting officers can avoid the negative side effects of using SOWs by instead structuring solicitations into Statements of Objectives (SOO). Despite being around for a long time, SOOs are infrequently used across government even though they make it much easier to write solicitations that center on outcomes instead of process. A SOO is the core of the ACF.
A SOO is:
A summary of key agency goals, outcomes, or both, that is incorporated into performance-based service acquisitions so that competitors may propose their solutions, including a technical approach, performance standards, and a quality assurance surveillance plan based upon commercial business practices.
FAR 37.602(c) provides that a SOO only requires a few sections:
- Purpose;
- Scope or mission;
- Period and place of performance;
- Background;
- Performance objectives, i.e., required results; and
- Any operating constraints.
By focusing on the information that vendors need to deliver, a TTS project team is able to rapidly discover discrete chunks of value for developing useful software features.
How to make an ACF
At 18F, we typically do our work in four person teams comprised of an agile coach, product lead, technical lead, and contracting lead. This team works together from start to finish. The cross-functional nature allows each group to write documents collaboratively, as opposed to waiting on input from other teams.
We meet with the agency we’re partnering with for a multi-day workshop that is designed with three objectives in mind:
- Establish a baseline of vocabulary and knowledge about agile product development methods.
- Create initial, high-level user personas and a product backlog that describes the major features of the system to be built and identify the scope of the first modular contract.
- Create a draft of the first solicitation.
At the end, we get something that looks like this:
| SOO Section | Agile Output | | ------------- | | Scope or mission | Product Vision or MVP Statement | | Performance objectives, i.e., required results | Product Backlog | | Any operating constraints | Non-functional Requirements or Definition of Done|
At the end of the workshop, there is a draft solicitation ready for release. We go from a process that people typically expect will take months to something that takes a few days.
Learning the hard way
I’ve been a contract specialist for over five years now, and I’ve been involved in awarding hundreds of millions of dollars in contract awards. Awarding contracts for waterfall IT projects has been the norm despite incredibly low success rates in terms of cost, schedule, and performance. Using the same traditional contract methods for agile methods is inappropriate and unnecessarily burdensome. To fix this, all you need are a few adjustments already available from the FAR.
Instead of years and back and forth, by going through agile workshops and using the ACF for solicitations, we can finish the requirements gathering and drafting parts of the acquisition process in days with value being delivered in months not years.
Towards better contracting
Delivery is the strategy here at the TTS Office of Acquisition. The contract is the means not the end. Writing down every possible future requirement you can think of can feel like it reduces risk and ensures the project will succeed. But that’s not borne out by the evidence of years of government contracting.
This is one piece towards a broader method of contracting for agile development services. Through this method, you can save time, reduce risk, improve quality, and avoid agilefall by allowing industry to apply their expertise. That’s why you’re contracting in the first place.
If you’re looking for examples we’ve done to date go here, and if you’re interested in chatting with TTS on how we may be able to help email us at inquiries18F@gsa.gov.