In late 2015, officials at two key agencies in California’s state government faced a decision that would have a significant impact on the wellbeing of hundreds of thousands of the state’s most vulnerable residents. The California Health and Human Services Agency (CHHS) and the state’s Government Operations Agency (GovOps) were preparing to replace the Child Welfare Services case management system, and the Department of Social Services (DSS), part of CHHS, wanted to devise a new system that maximized efficiency and impact. Unfortunately, the initial Request for Proposals (RFP) was more than 1,500 pages long and used a monolithic “waterfall” approach that ran the risk of binding the state to an ineffective vendor. Given that the case management system was used by more than 20,000 social workers to monitor approximately half-a-million cases of child abuse and neglect each year, the state had to find a better way to develop the system.
GovOps leaders, together with CHHS, connected with officials at 18F, a recently established federal office housed within the U.S. General Services Administration that helps to develop digital products for other government agencies.35 Working in tandem with Code for America, a non-profit that augments local governments’ efforts involving technological innovation, representatives of 18F proposed an alternative strategy: they could help California officials to develop an RFP that was more concise, employed an iterative approach, and would position California to develop an agile system that incorporated a design-thinking perspective.
The attractive proposal left GovOps and CHHS leaders facing difficult questions. Should they shelve an RFP that DSS had been developing for years and was weeks away from releasing? If they decided that working with 18F was the best option, would they be able to obtain buy-in from other state agencies, the governor, the state legislature, and the counties? How could they leverage user-centered design techniques and new technologies to strengthen structures, systems, and processes? How could they make the design process more agile? Most importantly, how could they navigate the next phase of their digital transformation and reach an outcome that maximized the state’s ability to serve at-risk children?
The difficulties with California’s Child Welfare Services case management system dated to 1993 when the U.S. government had determined that the program was not in compliance with federal standards. However, the situation—for budget and other reasons—did not appear on the “front burner” for state officials until 2003 when the state was penalized $30 million for remaining out of compliance. State officials then committed to developing an entirely new case management system. The responsibility for revamping that system fell primarily to DSS and the Office of Systems Integration (both parts of CHHS) with approval and oversight in the hands of the California Department of Technology (CDOT), one of many agencies and offices that GovOps oversees.36 Yet it was not until fall 2015 that DSS set a date (November 24, 2015) to release the RFP.
GovOps officials feared that more problems lay ahead. In the months leading up to the release, there had been delays due to the extended back-and-forth between officials at CDOT and leaders in the Children and Family Services Division of DSS—the organization that oversees the Child Welfare Services case management system (CWS/CMS).37 Reflecting on the state’s past IT failures, Stuart Drown, the Deputy Secretary for Innovation and Accountability at GovOps, said that the current approach carried its share of risk:
At the very best, it [the RFP] would produce an IT system for a very important population that would be overdue and … over budget because of all the change orders that would come through; and even with the best specs written, even with the best requirements written, it wouldn’t do the job that needed to be done by the time it was delivered, best case, five years from now. And so it wouldn’t get there, best case, five years from now; it would get there, best case, [in] seven or eight years.
In short, a reform process that was already more than 20 years overdue appeared likely to take close to a decade longer.
In October 2015, amid growing concerns about the problems with the RFP, GovOps officials discovered an alternative while attending a summit hosted by Code for America. Code for America had reviewed an earlier version of the RFP, though GovOps had not had the opportunity to read the assessment because that evaluation had been confidential. At the conference, however, Code for America Executive Director Jennifer Pahlka and Dan Hon, then Code for America’s Editorial Director, approached state officials and laid bare their concerns.38 The RFP, they explained, had enormous problems. One was that the proposal called for three different governance committees, which diminished the effectiveness of these accountability mechanisms. Another issue was that the design the state was planning to use was already outdated and would therefore be even more antiquated by the time the RFP was completed. Finally, there was no mechanism to obtain and incorporate input from the tens of thousands of state and county social workers who would be using the system. As a result, as Drown recalled, Pahlka and Hon said, “‘you are on the path for another healthcare.gov failure…and you have to change this.’
Pahlka and Hon needed to talk to GovOps’ Secretary, Marybel Batjer; fortunately, they had a suggestion for an alternative approach. Rather than employing the “waterfall” method in the current RFP, California could use an agile procurement process that separated the project into distinct steps that could be bid on, worked on, and tested individually. This iterative approach dramatically reduced the risk of an overall system failure; it also provided the end users (i.e., social workers) an opportunity to provide feedback about the product at each stage of the development process. To implement this approach, Code for America officials recommended that state officials work with 18F.
Also at the summit were the CHHS Undersecretary, Michael Wilkening, and the DSS Director Will Lightbourne, who had been central players and would soon take on immensely consequential new roles.
For Wilkening and Batjer, the proposal was attractive; but in order to move forward, they needed to secure permission and buy-in from a wide array of stakeholders. This included the Department of Technology, which had invested significant energy in the project, as well as the legislature and governor’s office. Hearing the new approach explained, many senior state officials were enthusiastic about the opportunity to try an alternative, particularly one that would give them an opportunity to offer feedback and monitor incremental progress. Others—notably leaders from the Department of Technology—questioned the wisdom of shifting to something unknown to them when the state was so close to releasing the RFP. In the end, Wilkening, Lightbourne, and CHHS leaders made the decision to shelve the RFP, and GovOps Secretary Batjer green-lighted the modular procurement on a demonstration basis and forged the partnership with 18F.
This was a critical moment, with valuable lessons for other public officials trying to transform their agencies into optimized enterprises. One is the importance of decisive leadership. As Drown explained, “Secretary Batjer made the call to go forward, and that’s one of the key takeaways [because] somebody has to own the risk.” Another important takeaway involves the benefits of inter-agency collaboration. Drown reflected, “This was anti-silo cooperation, and agency heads and department leaders took the risk together because they could envision something that wasn’t only good for this project but could recast how the state as a whole does business.”
While it will take several years to see how this experiment plays out in its entirety, the initial returns suggest that rejecting the waterfall approach and partnering with 18F were risks worth taking. By March 2016, 18F had helped CHHS produce a new RFP that had shortened the prior version (which was 1,500-pages long) to a ten-page Statement of Work and a 60-page addendum that covered mandatory contract language.40 The revised RFP also incorporated user-centered design by providing for alpha and beta phases where services will be tested with local stakeholders; that means that the actual users of the system will be able to provide feedback on the product before it is finalized.41 What’s more, judging by the initial response to the RFP, the new approach was helping the state connect with a wider array of vendors. In the past, when the state had released a new RFP, the initial vendor meeting typically had attracted approximately ten companies. By contrast, when the state held a meeting to announce its new approach to the CWS/CMS RFP, approximately 200 vendors—including many who had not previously responded to state RFPs—attended.42 “There was a lot of agitation in the room,” recalled Drown. “There was a lot of excitement; there was real buzz.”
This latter observation points to a broader transformational benefit of the decision to partner with 18F and employ a user-centered design approach. As Drown said, “It’s building a new culture and building a new vocabulary… in government.” This also suggests a possible endgame for GovOps officials. The RFP for the CWS/CMS delivery system is first and foremost about helping hundreds of thousands of the state’s most vulnerable residents. But it is also the initial step in a longer process to transform GovOps and the California State Government into an optimized enterprise that incorporates employee and citizen feedback and is capable of adopting and pursuing innovative approaches at the outer reaches of the Uptake and Edge Matrix. Thus, employing a user-centered design and agile development approach can help GovOps to accelerate transformation, realize its mission, and, most importantly, better serve the people of California. Drown summarized:
Ours is a story about changing a $500 million IT project at the last minute after 14 years of work and three years on an RFP. But it’s also a story about technology, but, more important, it’s a story about changing the frames for assessing risk and leadership and about relationships and trust.