This is the story of how the State of California changed direction on a $500 million IT project for Child Welfare Services. To a large degree it’s about technology. But it‘s also about leadership, changing frames for assessing risk, and relationships based on trust. Many thanks to guest bloggers and 18F partners, Mike Wilkening, Undersecretary for the California Health and Human Services Agency (CHHS), and Stuart Drown, Deputy Secretary for Innovation at the California Government Operations Agency (GovOps). CHHS is home to the Department of Social Services and the Office of Systems Integration. GovOps hosts several of the state’s control entities, including the Department of Technology and the Department of General Services, which are responsible for large IT contracts and procurement. Here’s the story from Stuart and Mike.
Setting the stage
In November of last year, California was about to release a request for proposal (RFP) for a new child welfare technology platform using a waterfall procurement method. The current system helps the state and counties serve hundreds of thousands of children each year; more than 54,000 of them are in foster care on any given day. More than 25,000 state and county employees use it every day. The current system is functional, but not at the level that the federal government requires, and system updates don’t occur frequently enough to keep up with state and county business needs. In 2006, California committed to building a new system and avoided a $30 million federal penalty.
The release date for the RFP was November 24, 2015. The months leading up to the release were bumpy; lots of back and forth between the Department of Social Services, which was doing the procurement, and the Department of Technology, which does project approval and project oversight.
Unhappily, the state had a string of failed large IT projects with costs running into the hundreds of millions of dollars. The Department of Technology had been regularly called before the Legislature to explain why. At the agency level, there was the recognition that we needed to find a new way, even as we supported and encouraged reforms designed to improve the waterfall approach with the Department of Technology.
At the California Health and Human Services Agency (CHHS), a customer agency and a program agency, there was frustration with the process. On this project alone, we were on version seven of an RFP nearly three years in the making. And despite all the work, few were thrilled with it. At the very best, it would produce a project that was over-budget and overdue, and even well-written specs would produce something outdated by the time it was delivered (which was five years later in the best case scenario).
CHHS wanted to apply procurement lessons learned through the speedy development of California’s healthcare marketplace, CalHEERS (California Healthcare Eligibility, Enrollment, and Retention System), but couldn’t see a way to plug those lessons into the existing procurement process.
The importance of relationships
We were able to change the course of the project in a very small window of time, primarily because of existing relationships. Our two agency secretaries have had a personal connection. Key staff at each agency work together on ongoing projects. There was also a level of respect and familiarity with groups like Code for America and 18F.
Go back two years: Shortly after her appointment, Marybel Batjer, GovOps Secretary, had reached out to Code for America. She had heard Jennifer Pahlka interviewed on television and wanted to learn about this “Peace Corps for Geeks.” In our work on open data and innovation, we were paying close attention to Code for America’s fellowship program as well as its ideas on user-centered design, and later, the 18F design playbook.
Additionally, the Department of Social Services, part of CHHS, was participating in a pilot that started with a Code for America app for enrollees in California’s SNAP program, CalFresh. Because of trust built through that work, Will Lightbourne, director of Social Services, invited Dan Hon from Code for America to review the Child Welfare System RFP and offer suggestions.
In early October, as it became clear that the waterfall RFP was going forward, Jennifer and Dan approached us at the Code for America Summit and laid out their concerns. Fearing the project was headed down a path of failure, they helped us engage both Todd Park and Aaron Snow for ideas on how they could help. Jennifer, Dan, Todd, and Aaron set the table for the course change to line up the help we would need.
The following week, Jennifer, Todd, and Dan met with Marybel and Mike. At the meeting, they summarized the weaknesses of our current plan: a governance structure that featured three committees at different levels of government with no single point of accountability, a reliance on old technology, a delivery date in 2021 that probably wouldn’t hold, and no systematic way for the end users of the system, county social workers, to have input on the design throughout the process.
They proposed another path: an agile procurement process that broke the project into modules that then could be bid out separately, in a sequence that allowed pieces to be put to work in a far shorter time frame and reduced risk of a failed overall system.
Our project, they pointed out, did break nicely into distinct pieces: separate activities such as Intake, Children’s Residential Licensing, Case Management, Resource Management, Court Processing, Eligibility, Financial Management, and Administration. Many of these components are common to other programs. Open source solutions delivered for these components mean solutions would now exist for other systems at other programs, whether in California or another state.
This was of great interest to the Administration on Children, Youth and Families (a division of the U.S. Department of Health & Human Services), which was paying for a large portion of the project, and looking for a successful model to replicate in other states. It also interested 18F, which was looking for opportunities to spread what it had learned about agile development and building and reusing open source code.
The modules would be developed through sprints, with the end user at the table, with a focus on developing a minimally viable product as soon as possible — within weeks or months, not years — a product that then could be revised repeatedly. As this happened, the state would launch the other modules, which would be integrated as they were developed. Open source code would be critical to this integration.
Both Marybel and Mike were receptive. The Secretary had been seeking the right platform to try a new approach to IT procurement since GovOps was formed and CHHS had been looking for a way to build on the lessons of CalHEERS to provide a system in less time. Here was an opportunity to increase delivery speed and to reduce risk by breaking it into little pieces. Not to mention it would get a working product into the hands of county social workers that social workers helped to design.
Better tools delivered more quickly to the front line means that vulnerable children are put in the best-fitting foster care placements the first time, not the second or third time. But agile procurement was something we had never tried.
The strike team
The question loomed: Could we actually do agile? Legally and practically?
Todd Park’s advice was clear: You have to hand pick your team, and this team’s first task would be determining whether an agile path was possible under California laws and regulations. And he emphasized: You already have the right people. Our system had imprisoned them in myth and cultural practices conditioned by fear of risk, Todd told us. We just had to set them free. Once we picked the strike team, our job, he said, was to provide air cover from higher ups. Todd and Jen would work to get it from Washington.
During a very busy week, we vetted and put together the strike team, got them a war room, and put them to work. In addition to Dan Hon, they included subject matter experts from the Department of Social Services (Kevin Gaines, Chief of the Child Protection and Family Support Branch), from CHHS’s Office of Systems Integration (Amy Tong, Agency Information Officer and Chief Deputy of OSI), the Department of Technology (Alex Chin, Procurement Manager), and the Department of General Services (Richard Gold, Senior Attorney). They scoured statutes and regulations to see what was required, and what was myth.
As it happened, Mike needed to be in DC that week. There he met with Rafael Lopez and others in the leadership of the Administration on Children, Youth and Families, to lay out what we were attempting to do and to make the case that his group had the capacity to handle multiple modules at once. Dan was also working with Aaron to finalize the arrangement of 18F working for HHS in service to their California grant. Among one of 18F’s less publicized skillsets at the time: ghostwriting agile RFPs.
From the start, there was support in Washington. Agile wasn’t foreign to DC; they’d seen it and had confidence in the 18F team that was advising us and helping rewrite the RFP.
By November 13, the strike team determined that there were no legal or regulatory obstacles and that we should move to the next step. Marybel and Mike then met with the Governor’s Office and the Department of Finance, which gave us the go-ahead. They then met with the Legislature. Perhaps most importantly, Will Lightbourne had to meet with the counties and assure them that with this new approach they would actually have more input and a better product, faster.
Marybel also had to deal with push back from inside GovOps, from some within the Department of Technology, which was committed to improving the waterfall approach. They were concerned about diverting resources to something that the department saw as untested. She knew that there would never be a better chance, and the alternative would mean a costly, probably unsatisfactory end down the road. Calling it a “demonstration project” persuaded the doubters that the Department of Technology could support the effort.
All of this was held in confidence until November 20, four days before the release date, when the Office of Systems Integration (OSI) and the Department of Social Services announced that we were shelving the RFP. We set a vendors meeting for December 4, and expected the usual turnout of a handful of interested vendors. At that meeting, instead of fewer than a dozen, we had 200 vendors in the room and on the phone. There was a lot of agitation and a lot of intense interest. And a lot of vendors we’d never seen before. The CHHS team explained what it was planning and said they’d have a new RFP out by December 21. We knew we could make that date because we had 18F at our side to help us develop it.
The path forward
Maybe it’s obvious that this was disruptive. It has been immensely so, both inside the government and in the vendor community. Agile? Open source code? We all had a lot to learn and learn quickly.
There are early signs of success. Four RFPs have been released; two contracts have been awarded. We received both more bidders and a new generation of bidders, and products are being developed with users in the open. OSI has been refining its RFP process, iterating as it goes, and in doing so, is providing a template for other projects in other departments.
We worked with 18F to adapt its Agile BPA, and the state launched the Agile Development Pre-Qualified Vendor Pool over the summer. 18F also has been helping our Departments of Technology and General Services scrub our standard terms and conditions — 1,500 pages of requirements we put in our contracts that may not add the value or protection we think they do. And these requirements may preclude some vendors from bidding or trying out for the prequalified vendor pool. The prequalified vendor pool drew new competitors and generated a number of calls from other state departments that wanted to learn more. 18F is helping our departments develop capacity through coaching, so that our people can learn new roles.
A word on context. Even as we go forward with our agile demonstration, we’re not abandoning the waterfall approach. We have to learn which approach is most appropriate for each project. We know that the way we have gone about waterfall hasn’t always produced good results, and we’re working on that. In the past, we tried to fix every previous failure by adding more terms and conditions, insulating the state from risk and moving more risk to the vendor, possibly at the expense of the end user.
18F also is helping us expand our knowledge and understanding of open source code. We need to adapt and update our open source code policy. What would it mean to have an “open by default” policy like the White House model used by 18F? The 18F blog has been a tremendous resource for our teams — lots of ideas and, more importantly, cues to thinking digitally and putting users at the center.
In California, we’re very much engaged in an agile procurement demonstration. More departments have signaled that they want to try this approach. Now the challenges are building capacity, managing expectations, and defining success in terms we can achieve.
The journey is about building a new culture, a new vocabulary, a new view of who the customer is, and making sure the system works for that customer with continuous proof points. Both sides are signing up for a service relationship. No more one and done. Instead, the product will evolve, based on user needs.
Yes, this is disruptive, but in a most constructive way.