18F/18f.gsa.gov

---
title: "Leadership and innovation at California's Child Welfare Services"
authors:
- stuart-drown
- mike-wilkening
tags:
- state and local practice
- acquisition services
- rfp ghostwriting
- procurement
- health and human services
excerpt: "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."
image: /assets/blog/ca-child-welfare/ca-team.jpg
image_figcaption: The team from the State of California, Code for America, and 18F.
---
*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.

## Changing course

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](https://cwds.ca.gov/dashboard/digitalservices.html). 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](https://cwscms.osi.ca.gov/CWDSADPQ) 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](https://18f.gsa.gov/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.