18F instructs federal agencies on ‘de-risking’ agile IT projects

A new field guide from 18F breaks custom technology projects down into three phases.
Inside 18F's headquarters in Washington, D.C. (Tajha Chappellet-Lanier / FedScoop)

The 18F team has issued official recommendations for how agencies can reduce risk when adopting agile and user-centered design methodologies for developing software.

The De-Risking Government Technology Field Guide, released this week, focuses on what to do when buying software, writing contracts for support, choosing between contractor proposals and establishing metrics for development.

The guide represents the first comprehensive attempt by the digital services arm of the General Services Administration to help federal cross-functional teams avoid failed IT projects and compliments the Agile Budgeting & Oversight Guide for State Governments published in 2019.

Custom technology projects are broken down into three phases: planning, deciding what to buy and doing the work.


During the planning phase agencies are advised to empower a product owner to lead development, seek constant end user feedback, default to open source code, tightly scope development to avoid overspending, and rely on remote collaboration tools among other recommendations.

18F suggests an agile contract format, time and material contract types, and evaluation of proposals based on best practices, during the research and solicitation phase of custom agile development.

“Review the strengths, weaknesses, and risks of contractors’ proposals and then invite the most highly rated for a verbal interview,” reads the guide.

‘Value to end users’

In the post-award phase, a kickoff meeting is recommended to energize the team. End-user outcomes should be measured, rather than setting deadlines for tasks, according to 18F.


“Requiring that project teams accomplish tasks by a specific date prevents them from responding to user needs and makes them build to predefined requirements,” reads the guide. “The only meaningful measure of success of an agile project is the delivery of value to end users through working software.”

18F warns that agile contracts require more post-award administration from product owners and contracting officers because rather than establishing discrete requirements, they’re responding to user needs throughout the project.

Government should always write the quality assurance surveillance plan (QASP) and monitor conformance at the end of every sprint, per 18F. The technical lead is ideally a government employee, but a contractor is permissible so long as they’re not on the same contract as the developers.

“An agile QASP ensures that code is tested, properly styled, secure, documented, deployed, and based on user research, at the end of every sprint,” reads the guide.

Dave Nyczepir

Written by Dave Nyczepir

Dave Nyczepir is a technology reporter for FedScoop. He was previously the news editor for Route Fifty and, before that, the education reporter for The Desert Sun newspaper in Palm Springs, California. He covered the 2012 campaign cycle as the staff writer for Campaigns & Elections magazine and Maryland’s 2012 legislative session as the politics reporter for Capital News Service at the University of Maryland, College Park, where he earned his master’s of journalism.

Latest Podcasts