States struggling to manage their large technology projects often face similar issues in assessing the risk, optimal contract length or quality assurance of potential new services. A handbook released this week by 18F, a civic innovation office within the General Services Administration, is dedicated to helping state budget and technology officials realize they’re not alone — and explain the best practices for overseeing state technology projects.
The 40-page handbook, titled “De-risking custom technology projects,” is a guide for the non-technical decision makers in state government that often oversee technology procurement, like agency executives, budget specialists and lawmakers. The purpose is to increase the success rate of large government IT projects, which sits at just 13 percent, according to the IT research firm Standish Group.
According to the handbook’s authors — 18F employees Robin Carnahan, Waldo Jaquith and Randy Hart — the executives in charge of the majority of these failed projects need to understand the basics of modern software development to effectively procure any technology. For public officials to make good decisions, Jaquith said, they have to understand what systems they’re choosing between.
The authors explain six basic tenets of modern software design: user-centered design, agile software development, product ownership, DevOps, building with loosely coupled parts, and modular contracting. While some of these — like agile development — are familiar to engineers, they might not be top-of-mind for policymakers. Other tenets, such as user-centered design and modular contracts (rather than monolithic, long-term contracts), are simply best practices that budget experts should familiarize themselves with, the authors say.
The handbook also includes a list of best practices for project management that budget officials can follow once they’re familiar with the technology they’re procuring. One of the list’s best practices directs agencies to set expectations for human outcomes, as well as technical elements such as data security, use, interoperability, monitoring and evaluation. It also says agencies should ensure that each “request for proposals” includes quality assurance check-ins and regular demonstrations of the software, not just progress memos.
“You want the back-and-forth where the customer is driving the vision and not being forced down,” Joshua Whitworth, Idaho’s chief deputy controller, told StateScoop.
Agencies should also assume product ownership of whatever technology or service they are procuring, according to the handbook, and try to hire in-house developers wherever possible.
“From a state security perspective, you have to balance using outside resources with what you can develop with internal resources,” Whitworth said.
The handbook also addresses common IT budget pitfalls like budgeting for software as a one-time expenditure and neglecting to include maintenance costs, or procuring a new legacy system to replace an old one instead of building incrementally with small, lower-cost contracts.
The handbook also recommends that states expand their vendor pools to try new, lesser-known software vendors that may have more experience with agile software development than legacy companies that have used the same strategies for decades.
“Ultimately, mission agencies must have the knowledge in-house to comprehend what they need, what they should be asking of vendors, and assessing the work done by vendors,” the handbook says.