Government hasn’t kept pace with advances in technology. Only 13% of major government software projects succeed, and the successful and failed ones alike cost 5–10 times more than they should. When these projects fail, so too do the public policy initiatives that depend on them—unemployment insurance, DMVs, healthcare exchanges, paid family & medical leave, etc.—leaving behind the millions of Americans who rely on those programs.
We are knitting together collections of intergovernmental agencies based on common needs to help them cooperatively procure, develop, and maintain the software that they all depend on. This will prevent 56 states, territories, and DC from buying 56 versions of near-identical, overpriced software, and instead allows them to procure high-quality, fair-priced software just once, and share it among themselves.
We hold monthly meetings of software cooperatives, both existing and aspirational. Join our mailing list if you’d like to be invited to future meetings.
Click here to see all updates.
Standards come up again and again when we talk to government cooperatives about their work. It turns out–maybe unsurprisingly–that having a shared system for data vocabulary and exchange formats is critical for jurisdictions to share data and technology. Often, it comes down to the cooperative itself to come up with this system, rather than relying on other industry or government-maintained standards.
In our monthly community meeting in June, we dove into how cooperatives are collaborating on standards. Cooperative organizations in the ISC community range from national associations convening all states and territories (and sometimes Canadian provinces as well), to much smaller local groups consisting of a couple of towns or local entities such as councils of government. Larger associations do more standards creation and management work than smaller counterparts working at the local level, but all recognize the importance of standards, want to use them, and are impacted by them as they change.
Developing standards across jurisdictions is hard – and not just because of the diverse technical capabilities that governments may have. Governments also can have widely varying organizational, political, or vendor landscapes. One community member described getting states to agree as being like “nailing jello to a wall,” and multiple folks shared they must engage vendors as well as government stakeholders to get buy-in and adoption.
To make matters more complicated, governments also have different laws and regulations that a standards group has to navigate. Legislation, policy, and even simply historical practice might affect how a government shares data, but also how it collects and defines data. For the local issue of code enforcement, for example, even between adjacent cities there might be very different definitions of “vacant property” or conflicting ways to identify a parcel. Getting to a shared vocabulary in any domain or at any scale, regardless of the IT, is one of the hardest and most fundamental parts of intergovernmental standards work.
Innovating in such a complex, multi-stakeholder ecosystem can seem daunting, but in reality cooperatives and their members are innovating on standards constantly. One group shared that one of their biggest challenges is that some states who are inclined to innovate get ahead of the standards group. Then the standards group has to run to catch up, without the help of any supporting documentation or tooling, and they also have to figure out how a given innovation fits into the bigger picture, such as integrating with systems, cultures, and needs of other states. They assured us, however, that this is a good problem to have, because it’s a sign of a healthy standards ecosystem.
The independent and cross-cutting nature of intergovernmental collaboratives means that the standards maintained by them may be more resilient than standards solely owned either by a single government entity or by a private industry group. Their very nature is collaboration, so they by default work with governments and industry alike (and may even be funded by one or more!) and therefore can help an entire ecosystem achieve interoperability.
Federal agencies might even mandate that states, territories, or other governments use a standard maintained by a cooperative, as is the case with DOT and AAMVA standards. Notably, some cooperatives that maintain standards also make tooling (e.g. data crosswalks) or act as vendors by providing consulting services to governments to help with standards implementation.
Their independent nature means that these cooperative standards groups can serve as a point of continuity amidst government staff turnover or changing tides of government funding. The ones we talked to take this responsibility seriously, dedicating time and resources for communicating with and onboarding new government staff and stakeholders. This dedicated role for support helps enable greater adoption of standards and even innovation.
Unless a government agency has a mandate to govern or maintain a standard (such as NIEM), then that agency might be a riskier home for the standard than a cooperative. A community member provided an example from their own experience in a Canadian government: when a standard’s champion left the government agency, the standard ended up becoming unused, because there wasn’t a mandate or funding within the agency to keep the standard going. They posed the question: akin to “lex iniusta non est lex,” is an ungoverned standard a standard at all?
Some key pieces of advice emerged in the discussion for groups that are maintaining or are considering maintaining standards collaboratively across governments.
- To keep up with new regulations or requirements, try a representative working group model. It’s not practical to have all 51+ states/territories in a working group, so enlist 5-10 volunteers who are excited about the work to represent groups of governments and attend meetings. Then, these representatives talk to their assigned states between meetings to get feedback to bring back to the working group.
- When ready to roll out a new standards version, plan a phased approach. If every state tries to implement a new version all at once, one group said, headaches ensue. Find a software partner to implement the change first while letting everyone else know what’s actively being piloted. While ideally you’ve also had developers and end users involved early in the development process before the version release to scrutinize and test the proposed changes, it’s still beneficial to pilot the implementation first to identify unexpected issues. This also lets other jurisdictions prepare their own implementation timelines while you’re working out any remaining kinks.
- Host in-person events at least once or twice a year, for training and implementation support as well as to help with all the less technical, more interpersonal aspects of collaboration.
- Provide plain language and training materials in multiple formats, such as online resources, email groups, and webinars.
- Make sure the documentation is accessible to both the technical and business side of a stakeholder organization. If the business side can’t understand the schema and how it’s useful or relevant, no one in their organization will use it.
Interested in learning more or sharing your own experience maintaining standards across governments? Reach out to Shelby - shelby.switzer [at] georgetown.edu.