Learning from Failure: When Sharing Software Doesn’t Work

April 12, 2022 – By Margaret Lin

When our Intergovernmental Software Collaborative (ISC) set out to learn more about the landscape of cooperatives that share software, we came across dozens of state and local governments actively working together to buy or build software for shared needs. We also heard anecdotes about failed cooperative efforts. Knowing we can learn just as much—if not more—when efforts fail, we began documenting those lessons, too.

Unsuccessful software cooperatives are difficult to study because they rarely have well-documented governance structures and no longer retain knowledgeable staff or project members. From what can be studied, frequent causes include lack of clear project governance and inexperience with integrating projects into budgeting cycles. Below, we provide several examples of unsuccessful cooperatives to demonstrate the key improvements needed for more complete governance and budgeting structures.

For the vast majority of state benefits and services—including health insurance, unemployment benefits, and emergency response—many states’ software needs are the same or similar, making a collaborative solution feasible and attractive. States taking a collaborative approach risk failure, however, if they do not invest upfront in a clear governance structure and alignment on members’ needs. 

The ISC at the Beeck Center for Social Impact + Innovation at Georgetown University works to learn from and document the history of successful and unsuccessful past state software cooperatives and to normalize the process of entering into collaboratives to inform future efforts. It is imperative to address known challenges when advocating for future state software initiatives.

 

Too many cooks, too early

WyCAN was a collaboration between the states of Wyoming, Colorado, Idaho, Arizona, and North Dakota, beginning in 2009. It was funded by a $62.2 million U.S. Department of Labor grant and developed under a cooperative purchasing governance agreement that was unique to this model. The goal was to build a monolithic system for unemployment insurance (UI) that would be able to process tax and benefits claims, among others. However, it was ultimately too difficult to resolve the differing states’ UI needs. After facing difficulties within the project, the consortium decided to release the vendor from their contract and disband. At the time of disbanding, the states had spent a total of $15.4 million in federal funding, plus millions more in state funding.

WyCAN’s governance model faced difficulties because it brought in too many state partners with differing needs at one time early in development, without the transparency needed for states to understand the specific features they saw as fundamental to a UI tax/benefits system.  

“It’s important that co-ops start small. More members means more problems,” wrote Waldo Jaquith,  a former Beeck Center Fellow now serving as a senior advisor to the Administrator of the U.S. General Service Administration. “By starting small, those problems can be dealt with at a small scale, and new problems can be dealt with on a per-member basis as the co-op grows.” 

Wyoming eventually joined a new consortium with Missouri, Mississippi, Connecticut, and Rhode Island, in which all member states share the same base code for their IT systems. Taking this approach or starting small by building a functional base system shared between two governments first before opening the project up to new members are two tactics that may benefit future consortia. Wyoming’s continued interest in software collaboration despite the difficulties of WyCAN demonstrates the value of continued efforts with this software purchasing model.

 

Misalignment of members’ roles in product roadmap 

Idaho founded iUS in 2012, building atop the successful work that the state had already done to modernize its unemployment software infrastructure, with Iowa and Vermont also participating. (Iowa later dropped out and was replaced with North Dakota). The project continued through 2019, with the Idaho team performing the software development work. At the beginning of 2020, Vermont raised the alarm, complaining of governance problems. Specifically, Idaho was willing to let other states borrow iUS, but was unwilling to let them make any modifications to it, and prioritized the needs of Idaho over those of Vermont or North Dakota. The governors of the three states tried to resolve these conflicts and, when unable to do so, agreed to dissolve the iUS consortium.

The iUS governance model faced issues because the states had different interpretations of what consortium membership entailed. While Idaho, the primary developer, was under the impression that it was a “Built Here, Others Use” type of model, states like Iowa, Vermont, and North Dakota clearly interpreted it as more of a “Built Here, Others Contribute” type of model that would allow for greater flexibility to their unique unemployment systems. This type of issue could be resolved by seeking to establish a direct governance outline document, like the kind ActivitySim uses.

 

Prioritizing speed over transparency and required process

Previous to a 2013 agreement with Michigan, Illinois had been looking to upgrade their 1970s-era Medicaid system for years. After learning of Michigan’s contractor-built, federally certified system, Illinois reached out and eventually approved of the creation of the software initiative as a rational and inexpensive way to address the state’s needs. The software collaboration was slated to save Illinois and Michigan $10 million each in procurement costs, and the federal government $76 million in procurement costs. 

However, officials did not conduct a federally mandated cost-benefit analysis beforehand, and government watchdog groups raised concerns because Michigan’s contractor, CNSI, had troubled pasts in Arkansas, Louisiana, Utah and Maine. Based on these concerns, it appears that Illinois decided to shelve the collaboration and return to the competitive procurement process.  Despite that decision, two years later, Illinois selected CNSI to support the state’s MMIS modernization, now apparently contracting with them independently instead of cooperatively with Michigan. 

MI/IL MMIS’s lack of success differs from many other software collaboratives because they did take steps to ensure their systems were coincident. In 2012-2013, Illinois and Michigan conducted a systems evaluation process that ultimately concluded that their Medicaid systems were similar enough to use common software. The issue with the MI/IL collaboration appears to be a lack of transparency. In their haste to develop a collaborative software process that promised potentially great savings, they failed to follow the structured processes, like conducting a legally-mandated costs-benefits analysis. This could have been solved by consulting with experts who had previously aided other software collaboratives, or by attending a joint meeting with software collaboratives like the kind the Intergovernmental Software Collaborative project hosts.

In all of these examples, the common threads of governance, transparency, and proactive budgeting arise. As coops plan for new collaborative software projects, it will serve them to spend the time upfront planning and documenting the proposed governance structure, principles of working in the open, and their alignment on how to resource their shared work.

 

Margaret Lin is a Georgetown University sophomore in the College of Arts and Sciences, pursuing majors in government and mathematics. She was a Student Analyst at the Beeck Center in the Fall 2021 semester. Connect with her on LinkedIn.