IE11 Not Supported

For optimal browsing, we recommend Chrome, Firefox or Safari browsers.

Culp: The Real Reason California’s Child Welfare System Is Too Important to Fail

Agile presents an opportunity to improve collaboration and trust, but it’s not the only way.

If you’ve been following the Child Welfare Services (CWS) — New System news, by now you know that the state is pursuing agile procurement and software development strategies. A letter to the vendor community just before Thanksgiving hinted at a more modular, phased procurement approach. A vendor conference in early December extended the new approach to choice of software development methodology as agile. Listening in to that vendor conference, I lost track of how many times I heard reference to the idea that this project is too important to fail for California’s most vulnerable children. This is a poignant reminder of the beneficiaries of the new system, but I think we shouldn’t miss the opportunity to recognize what really is at risk of failure here.

Let’s start with a couple of facts. First, there is a system in place already that has been used for more than 20 years. The primary motivation to replace the existing system has been federal pressure for California to avoid sole-source contracts with the present vendor. A project to improve the competitive climate by moving the hosting of the present application to a state-run data center was completed in 2007 to that end. The CWS ReHost project was completed flawlessly, on time and $8 million under budget, I might add.

It’s also worth mentioning that the existing system is not deemed to be Statewide Automated Child Welfare Information System (SACWIS)-compliant, even as the federal Administration for Children and Families has wrestled over the last half-dozen years with just what that definition actually is. Would the possibility of a new system be an opportunity to move toward more modern architecture and technology? Absolutely, but if the new system “fails,” the old system is still in place and still works, even though it may be ugly.

Second, the biggest improvements to the Child Welfare system, whether it is new or existing, SACWIS-compliant or not, would be the sharing of data between entities, such as courts and social workers that presently does not exist. An agile software development methodology implies agile architecture and the ability to implement technology that can facilitate the person-centered, or family centered, view but does not address the vexing issue of organizational dynamics and change.

We have known for some time that technology is not the limiting issue in sharing information between service silos, the present system could actually accommodate this, with some modifications. Some years ago, the Administrative Office of the Courts sponsored a workshop to open dialog between courts and child welfare programs to tackle this issue head on. Despite the positive conversations that occurred at the event, little to no progress has been made. In such initiatives, we tend to cover the same territory over and over regarding the privacy and confidentiality “barriers” that prevent the sharing of information. In truth, we manufacture these barriers, so we know how to disassemble them; the barriers themselves are far easier to deal with than the cultures that erected them.

With our rhetoric and choice of agile, what seems like a signaling of “no confidence” in the waterfall method of project management and software development is tempered by a revised waterfall approach recently implemented by California’s Department of Technology. In spite of the fact that we have applied the waterfall approach to projects badly in many highly publicized instances, the method still serves us well and is appropriate for many projects, and used quite successfully for the CWS ReHost project mentioned previously.

But the waterfall method of project organization and management itself is not the culprit. The real determinants of project failures are more insidious — such as failure to recognize appropriate roles and resource them effectively — do members of the project team still have their day job? This situation often manifests in delays in key reviews and approvals. Closely related to this is the failure to understand how projects operate and structure program engagement effectively. This situation may derive from a failure to trust members of the team to make decisions, and to what end? It’s incredibly difficult to keep the team engaged when its members have no clear investment. We see this often when the program folks either disappear from meetings where important issues are discussed, or a program executive oversteps the governance process and makes unilateral decisions, or worse, a program executive who countermands the decisions his or her team has made. Closely related to this is the failure to avoid too many cooks in the kitchen trying to manage the project, and the developing paranoia that there is a general lack of control, which there is, if you have gotten to this point, and project failure is imminent — a sometimes self-fulfilling prophecy. Perfection is unobtainable, and I would argue, unnecessary, as this move toward agile attests.

Would an agile method fix this? Maybe. There is certainly a temporal aspect that’s a function of the design of a “big bang” waterfall approach. But most of this is a function of an organization’s culture. Collaboration is not an inherent part of government’s culture, and trust between vendors and customers, program and IT, control agencies and service delivery departments is just as elusive. That we could consider a model (agile) that’s completely reliant on these behaviors is a step forward, but does not guarantee any kind of success, and comes with its own giant pile of risks.

The real risk of failure is the risk that we fail to realize this opportunity to change how we do things and to make progress toward a culture of communication, collaboration and trust. We need to define projects in smaller ways that will help us deliver functionality more quickly and then build on that functionality while building confidence in our ability to collaborate effectively. Agile presents this opportunity by default, but the concept is by no means confined to agile. If we fail at this, we have failed everyone — ourselves and all the people of California — not just children.

Thinking it all the way through and addressing the culture issues will help us realize agile success.


This commentary appears in the spring 2016 issue of Techwire magazine.

Shell Culp is a senior fellow at the Center for Digital Government, senior adviser for Public Consulting Group and principal with Almirante Partners. She formerly worked as an agency information officer for the state of California.