Agile development more about being imaginative, less about contract type
Developing more efficient and imaginative ways to craft agile IT contracts is about practical thinking, not contract type, says one expert.
DevOps, development sprints and agile techniques can seem formidable to federal contracting officers, but agile contracting boils down to being imaginative and not being wed to routine contracting ideas.
"Forget about contract type," especially when writing IT contracts, said Matthew Kennedy, a program manager at the Office of the Comptroller of the Currency.
Contract types such as firm fixed price, cost reimbursable, and time and materials should not be upfront considerations, he added during a presentation at the Association for Enterprise Information's Aug. 19 workshop on agile contracting.
"You have to figure out how to fit agile into your contract," he said. Those options are unique to each contract and depend budget, effective program management and a well-written contract that doesn't necessarily lock in project specifics, he added.
Including detailed requirements in a contract can make it obsolete from the start. Kennedy, who has more than 16 years of IT contracting experience at the Defense and Treasury departments, said a study showed that of the 32 major federal information system acquisitions, the time to delivery from requirements to users' hands averaged 91 months -- or about 7.5 years.
That long procurement process happens in an IT environment that changes in the blink of a diode. Requirements for IT projects change by about 3 percent per month and as much as 18 percent over six months, he said. By the end of 7.5 years, requirements will have changed 273 percent, making the procurement obsolete, he added.
The key to agile procurement is thinking about the Federal Acquisition Regulation differently. Kennedy said the FAR values personal initiative and sound judgment to provide the best value for products and services that meet customers' needs.
Contracting officers should forget about choosing among the traditional contract types and instead let customer needs drive the procurement, he said, adding that the approach can lead to more effective contracts.
That doesn't mean those contract types won't be used in an agile procurement.
"18F prefers time and materials contracts for agile," Kennedy said, while the U.S. Digital Service tends to use firm fixed price contracts. But both organizations structure contracts to fit agile services into them and not vice versa.
"Forget about contract type," he said. "It's about what you want. The contract type will figure itself out in the end."