How program managers can guide custom software development
Connecting state and local government leaders
Although agency programs often rely on custom software, managers' lack of development expertise can get in the way of the program meeting its goals.
Although many agency programs rely on custom software, program managers who lack expertise in software development may be delivering digital products whose functionality and user-interface shortcomings get in the way of the program meeting its goals.
A primer from 18F's Kaitlin Devine, "Managing custom software development in government when you’re not a software engineer," targets managers who don’t have a background in software engineering.
Failed projects often had managers who didn't want to spend the time and attention required to develop a great software product, Devine said. "Focusing your attention on building a great product lets the software get out of the way of your team's work…. Leadership and management for [the alignment between program and policy work and program-specific software] cannot be outsourced."
The guidance offers two implementation strategies to help managers new to project ownership: agile development and user-centered design.
Agile development "really just means continuous and incremental improvement," Devine wrote.
"Don't try to plot the three-year path of your product in one sitting," she said. "Instead, focus on steady and demonstrable progress on individual features rather than detailing every possible requirement up front."
But what does that look like in practice?
At a minimum, she said, agile software development must entail frequent demos of working software, regularly dedicating time for the development team to reflect on demos and tests and think about how to improve the product, as well as making a clear hierarchy of priorities.
Additionally, managers in charge of software products must also make sure they're building something for which users have a need and want to use, she stressed.
Collecting feedback on products from "actual users is relatively cheap when compared to the cost of the added software development time you’ll spend on a feature,” Devine said. “That cost is only compounded when you find out nobody wants the feature or can figure out how to use it."
Common or repeated themes should be included in future design iterations. Devine stressed the importance of testing products before investing too much time or resources into them, only to later find them not to be useful.
"If it's just confusing your users, it's doing more harm than doing nothing at all," she said.
Read the full post here.
This article was first posted to FCW, a sibling site to GCN.
NEXT STORY: How to survive the 'silver tsunami'