For all the large IT modernization projects happening in government, only about 13 percent of them actually succeed.
For all the large IT modernization projects happening in government, only about 13% of them actually succeed.
To keep this work from losing steam, 18F, the digital services office within the General Services Administration, has released a de-risking guide that pinpoints common areas of risk for agile software development.
Alicia Rouault, the acting director of product at 18F, said in an interview that common risks such as projects running over budget, falling behind schedule or not meeting their intended goals can often stem from a disconnect between the client agency, its IT vendors and end-users.
The guide walks agency executives through everything they should consider when it comes to making foundational decisions, such as whether agencies should develop their IT project internally or contract the work.
To avoid contracting pitfalls, Rouault said agencies should draft statements of objectives, rather than statements of work, and use a time-and-materials contract type instead of a fixed-price contract.
“It allows you to bill for time, which is really what you get when you hire a team, and so when you’re implementing custom software projects, that’s what you’re buying — a team’s time,” Rouault said.
The 18F guide also recommends shorter windows of performance — no longer than three years — and taking an incremental funding approach to avoid vendor lock-in or making big bets on projects that don’t come together.
The latter approach has gained momentum at the Internal Revenue Service. Its pilot IRS program allows the agency to incubate projects through incremental funding and pull the plug on funding those projects if they don’t yield results.
When it comes to measuring the success or impact of an agile project, Rouault said an agency’s most meaningful metric is whether it meets the needs of end users. But under an agile framework, where new outputs are released about every two weeks, she said that end-user feedback needs to continue throughout the lifecycle of the project.
That feedback, she added, can be as simple as troubleshooting whether a webpage loads properly, or taking a human-centered design approach to address whether users are having problems with the workflow of a process.
“Making sure that you’re learning as you go, really collecting feedback, using it to inform decisions as you go down the road of implementation, and ensuring that you’re delivering value to end users incrementally — that looks like weeks, not years,” Rouault said.
The guide also walks agencies through the benefits of open-source code. Rouault said agencies have embraced this trend because it’s easy to reuse for multiple projects and when agencies own their own code it helps avoid vendor lock-in with the project.
“Open-sourcing your code allows you to make those changes without being locked-in to a specific vendor, and sometimes it can actually improve the quality of the product. There’s a giant open-source community of programmers and designers, out in industry, and this approach really invites feedback and participation from those folks,” she said.
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
Jory Heckman is a reporter at Federal News Network covering U.S. Postal Service, IRS, big data and technology issues.
Follow @jheckmanWFED