Buying and Selling Collaborative Software across Governments
It’s impossible to escape the topic of procurement when discussing government technology. We hosted a webinar on challenges and opportunities in local and state procurement earlier this year, and in September we dove into the topic at a monthly ISC member meeting.
During our meeting, we discussed how both existing software collaboratives and stand-alone governments aspiring to join a collaborative or use a collaborative solution face unique procurement challenges. Our conversation explored some touchpoints where each of these groups experience frictions throughout the procurement pipeline.
Procurement challenges for existing government software collaboratives
Navigating the RFP process
Existing collaboratives may run up against procurement challenges when they want to expand or sell into a new jurisdiction. In this case, they may need to submit a response to an open Request for Proposals (RFP), which governments issue when they are looking for a vendor to sell or build a solution.
Unlike large, established, private-sector vendors, who have entire teams dedicated to finding and responding to RFPs, a smaller collaborative might not have the capacity, experience, or skillset in house to submit a competitive bid.
This problem isn’t unique to software collaboratives – in fact, it’s a widespread obstacle to greater vendor diversity, fair competition, and inclusivity for small and minority-owned businesses. Collaboratives can likely learn from existing resources and strategies designed to help mitigate this challenge.
Crafting a competitive bid
When a collaborative does submit a bid, it’s possible the government they’re submitting to may not have the level of digital maturity or tech culture needed to successfully implement the collaborative’s solution.
Collaborative software tends to prioritize modularity and interoperability, for example by taking an API-first approach, being open source, or using new or developing standards such as FHIR in the healthcare or public health space. Meanwhile, the government they wish to expand to may be locked into a proprietary vendor solution, have outdated policies or attitudes regarding open source software, or not currently be able to use the APIs or standards-based exchanges a collaborative is offering.
Collaboratives need to take these considerations into account and offer clear, practical guidance and support for the change needed to adopt their solution. They might consider talking with that government’s digital service or innovation team, if one exists, about ways to help advance technical and cultural change to support open source software, interoperability, and agility. Regardless of if a government has a digital service or innovation team, the collaborative can invest in user-centered documentation and reusability features aimed at lowering the barrier to entry for implementation (e.g. having a web interface for a script instead of requiring the user know Python to run a script in their computer’s command line).
Procurement challenges for governments aspiring to use collaborative solutions
Finding collaborative solutions
On the other side of the procurement process is the government who may be looking for a collaborative solution. The first obstacle governments may encounter is finding collaborative solutions available to them which meet their needs.
Governments should look for joint procurement opportunities, such as checking CoProcure’s cooperative procurement search platform. They should also invest in landscape research to identify possible open source or collaborative solutions, including referring to our growing collaborative catalog and reaching out to peers in other governments to see what they are using and brainstorm possible collaborations.
Meeting security requirements
Another issue governments may face is related to security: if a government team is considering using an open source project which was created and is primarily maintained by a foreign country’s government, such as Notify, they may need to go through extra hoops related to security documentation to get approval for use.
Inefficient federal funding strategy
Finally, we should look at the system overall that these governments and collaboratives have to operate in. As one collaborative pointed out, it’s grossly inefficient for a federal agency to hand out $70 million to states/territories in the form of $1.3 million each to build the same system. Instead, the agency should just build the system once for all to use. This would end up costing the agency but a small fraction of the $70 million doled out for the redundant systems.
If federal agencies aren’t willing to change their approach and start building shared solutions, then at minimum federal agencies could issue guidance and support for states/territories to pool federal funding to build collaborative solutions. Likewise, if Congress isn’t willing to explicitly fund federal shared services, then state legislatures could pave the way for states to prioritize spending on collaborative solutions rather than reinventing the wheel with individual, siloed systems.