Prodigal System: California's SAWS

After laboring for more than two decades, at a cost approaching $1 billion, California has yet to deliver a statewide automated welfare system.

by / November 30, 1997
Sometime in the year 2002, if all goes well, a county welfare agency in California will throw a switch and end the final chapter in a long, convoluted and expensive plan to automate the management of welfare caseloads in the state. That switch will turn on a computer system, marking the completion of a mammoth project known as the Statewide Automated Welfare System (SAWS).

For nearly 25 years, California has pursued welfare automation in what must rank as the longest-running, incomplete computer project in state government. In the wake of SAWS, the state is littered with the wreckage of not one but several large-scale computer projects that have gone wrong. Evidence of what caused the wrecks is everywhere: Changes in federal funding requirements, vendor wars, state/county disagreements, a creaky procurement system, ineffective project management, inadequate cost estimates and faulty caseload projections.

As time for the project has lengthened, its purpose has continually flip-flopped from a county automation project to a statewide system and back again to a state/county partnership of sorts. "SAWS has been the ultimate zig-zag project," remarked California Assemblywoman Debra Bowen. "It has radically changed direction so often that it looks like the equipment could only be a Singer sewing machine."

Today, SAWS is in a crucial phase of its existence. Two major pieces of the project are to begin operation during 1998. Bids for the next two portions will be completed sometime this year as well. So far, the counties and the state are cautiously optimistic that they've got it right this time.

But potential trouble looms: Welfare reform has added complications to the automation requirements and has already forced delays in the latest SAWS schedule. Other large-scale automation projects for social services in California are under way as well, including statewide systems for child support, child welfare and electronic benefits transfer. Child support is in trouble, and all three projects are voracious -- swallowing resources, funds and legislative patience that SAWS could badly use.

Ironically, the key to SAWS' ultimate success or failure resides not with the counties, state data centers or the hundreds of MIS professionals working on the project; it resides with Gov. Pete Wilson. His understanding of and support for technology in the business of government could decide the fate of such mammoth projects as SAWS. "Unless you have leadership at the top that embraces the idea that technology is how we're going to get to where you need to be," warned Bowen, "you will continue to see some projects that work and some that don't."

Span Falls

California officials like to remind you just how big their state really is. They point out that the population is 45 percent larger than the next biggest state, the welfare caseload for the state exceeds the entire population of most states in the Union, and the caseload for Los Angeles County alone would rank as the sixth largest in the country, if it were a state.

By the same token, welfare automation in California is in a league of its own. You have to turn to the federal government to find projects of similar size, longevity, cost and dubious achievement. The Internal Revenue Service's multibillion dollar, multi-decade tax modernization program comes to mind. So does the Federal Aviation Administration's costly upgrade of its air-traffic control system.

Like SAWS, these two federal projects have also struggled through the years. Their outcome is still far from certain. IRS began its first attempt at modernization in the mid-1970s, when mainframes dominated computing, minicomputers were fast-charging upstarts and PCs were toys made in the garages of college nerds. That's when California's story of welfare automation begins as well. Initially, the Department of Social Services (DSS) tried to build an automated welfare system for counties with heavy caseloads, but the attempt never worked.

In 1979, legislation was passed requiring DSS to create a centralized welfare system. Called the Statewide Public Assistance Network (SPAN), it was to be a single state-controlled system that linked the state's 58 counties via dumb terminals and a wide area network to a centralized database. It was also a plum contract for the vendor who won the bid.

As Frank Mecca, executive director of the California County Welfare Director's Association, recalled, such a massive system was doomed to fail. "The stakes were so high," he said, "that whichever vendor lost the bid was sure to dispute it." That's what exactly happened, as IBM and Unisys challenged the contract and, in effect, halted the program. In 1983, after DSS spent $15 million trying to develop SPAN, the state Legislature cut off any additional funding, citing the agency's lack of progress with the system.

Hoping to avoid another SPAN fiasco, the state took a different tack the following year. This time, the Legislature directed DSS to develop a system that would meet the needs of county welfare administration, while also maintaining state supervisory control. Originally, plans called for developing four or five pilot projects. Counties would then choose the system that best fit their needs. According to Mecca, the approach made sense not only because it gave counties more choice, but it would involve a number of vendors, thus avoiding the high-stakes wars that broke out with SPAN. DSS called the new system the Statewide Automated Welfare System (SAWS).

Federal Dollars, Federal Strings

But a new element added to SAWS was to have a profound effect on the entire project. In 1985, the federal government said it would pay a larger percentage of the automation project if the state cut back on the number of proposed county systems. In response, the state decided to fund just two systems that represented two very different technologies.

In rural Napa County, Unisys and its partner Deloitte & Touche won a bid to develop a system based on mainframe technology. Merced County, much larger in terms of population size and welfare caseloads, became the site for a client/server system built by a team of vendors, including Andersen Consulting, Hewlett-Packard, Hitachi Data Systems and Software AG.

Once the systems were completed and successfully deployed, the rest of the counties -- excluding Los Angeles, which has always been treated as a special case -- were to choose the system that best suited their needs. The two systems couldn't be more different. The mainframe system, known as NAPAS, ran on proprietary software and was designed for small caseloads. The client/server system, called MAGIC, was designed to handle larger caseloads and relied on what was then considered rather innovative open systems technology.

SAWS Timeline

1979 First attempt at a statewide welfare automation system: SPAN (Statewide Public Assistance Network).

1983 State Legislature defunds SPAN. Approximately $15 million is wasted on SPAN.

1984 The Legislature decentralizes welfare automation. Initial plans call for the development of five demonstration projects for counties to choose from.

1985 The federal government declares that it will pay for a larger percentage of the automation efforts if the state builds a single statewide system. The era of SAWS (Statewide Automated Welfare System) begins.

1989 DSS decides to create two pilot systems: MAGIC in Merced County and NAPAS in Napa County.

1991 DSS asks the counties to choose between MAGIC, a client/server system, and NAPAS, a mainframe system. Later in the year, DSS stops all SAWS activities to evaluate the NAPAS and MAGIC systems.

1993 DSS scraps the original plan to operate both systems and decides that NAPAS will be the sole system for SAWS. The feds end the enhanced funding for the state welfare systems.

1994 To test NAPAS as a statewide system, DSS launches the Interim SAWS (ISAWS) in 14 counties and gives Unisys the controversial sole-source contract for the pilot project. (Total costs for SAWS now estimated at $800 million.)

1995 A state auditor releases a scathing report on DSS' efforts to automate welfare. The report shows that NAPAS will never work as a single, statewide system. As a result, Gov. Wilson moves SAWS from DSS to the Health and Welfare Data Center (HWDC). The total costs for ISAWS are estimated at $117 million.

The State Legislature splits SAWS
into four consortia:


2. LEADER (Los Angeles County only)

3. Welfare Case Data System (WCDS)

4. Consortium IV

1996 HWDC reports that ISAWS' costs have risen to $312 million.

1997 Planning documents show that WCDS will cost an estimated $278 million. No figures are available for Consortium IV.

1998 Estimated completion date for ISAWS.

1999 Estimated completion date for LEADER.

2002 Estimated completion date for WCDS and Consortium IV.

By 1991, five counties, representing less than 20 percent of the state caseload, said they wanted to implement the mainframe solution, while 27 counties, representing 40 percent of the caseload, chose the client/server solution. (Los Angeles county, which was building its own system under a special waiver, had a caseload representing 35 percent of the state total.) The remaining counties declared they wanted the state's Health and Welfare Data Center to manage either system centrally. The counties had made their decisions, and the state appeared ready to deliver on welfare automation.

What happened next is still a controversy and a bone of contention among key project participants, analysts and policy makers. Most agree that the tables completely turned on everyone when the federal government -- through the various agencies that provided funding for welfare-related automation projects -- declared that it would only fund one centrally-managed system. Not two systems.

In 1992, when the offer was made, California had a $14 billion budget deficit and was still struggling through the recession. Best estimates at the time indicated statewide welfare automation would cost somewhere in the range of $700 million. An offer from the feds to pay 90 percent of that amount was difficult to turn down considering the state's empty coffers.

Not surprisingly, the counties were outraged at the prospect of seeing their broad-based solution shrink from five to two county-designed systems and finally to one state-controlled system. It was SPAN all over again. "The state reneged on what was supposed to be a multicounty approach," recalled Mecca, who had just started working for the County Welfare Directors Association at the time. As a result, "the counties really lost their confidence in the state."

But according to John Healy, interim director of DSS during the same period, the decision to go with one system was as much to help the counties as an acceptance of badly needed federal funds. "The county welfare program was dying at the time [this occurred]," said Healy, who is now vice president for state government solutions at MCI Systemshouse, a systems integrator. Counties were going broke from the cost of labor needed to manually process the growing welfare caseload. In addition, the welfare agencies were averaging a 35-40 percent turnover in eligibility workers. "The lack of system efficiencies was killing the counties," Healy pointed out.

In November 1991, DSS stopped all SAWS activities to evaluate the two systems and to choose a winner the following June. During what became known as the "SAWS Pause," DSS changed the project from a county-driven approach into a state solution.

On paper, the MAGIC system appeared very strong. The computing architecture was scalable, meaning the servers could be upgraded as processing demands grew. The system also was designed to work with counties that had large IBM mainframes. More importantly, according to Rita Kidd, MAGIC's project director, welfare business practices were completely redesigned to take advantage of the new system. So when caseloads increased by 63 percent between 1990 and 1993, and the amount of staff dropped by 9 percent during the same period, the time needed to determine a client's eligibility actually plummeted to four days or less, compared to the previous 30- to 45-day time frame. For counties groaning under huge labor costs for welfare case management, MAGIC offered a chance to cut costs dramatically and still improve worker productivity.

Acronyms Defined

DSS - Department of Social Services. The state agency that oversees California's welfare programs.

HWDC - Health and Welfare Data Center. HWDC took over SAWS from DSS in 1995.

ISAWS - Interim Statewide Automated Welfare System. ISAWS uses technology developed for NAPAS. It is now one of the four consortia systems under construction around California.

LAO - Legislative Analyst's Office. An independent state agency that monitors state programs for the Legislature.

LEADER - Los Angeles Eligibility, Automated Determination, Evaluation and Reporting. The name for Los Angeles County's automated welfare system. LEADER is one of the four consortia systems under construction around the state.

MAGIC - The county automated welfare system built as an alternative to NAPAS, using client/server technology. The system was deployed in Merced County in 1992.

MAPPER - The name of Unisys' proprietary operating system for its mainframe computers. MAPPER was used to build NAPAS.

NAPAS - The county automated welfare system that became the model for a single statewide system, using mainframe technology. Named after Napa County where it was first deployed.

SAWS - Statewide Automated Welfare System. California's welfare automation welfare project since 1983.

SPAN - Statewide Public Assistance Network. California's first effort at building a statewide welfare system. Started in 1979.

WCDS - Welfare Case Data System. One of the four consortia systems under construction around the state.

But MAGIC was barely operational in 1992 and, according to Healy, hadn't met certain performance objectives set by DSS. And worse, it was much more state-of-the-art than DSS or the feds were willing to accept at the time. In 1994, Joseph Leo, a U.S. Department of Agriculture official who worked on federal matching funds for state welfare automation, told Government Technology that large welfare automation projects, such as MAGIC "shouldn't be on the bleeding edge. California should not be a pathfinder... ."

Kidd believes that it was the business reengineering as much as it was the technology that scared people away from MAGIC. "To everyone else, we must have looked disjointed, trying to use new business behaviors," she said. "I think we looked too foreign."

Winner Takes All

Nearly everyone agrees that the federal funding offer tied the state's hands, forcing it to develop a single system of gargantuan proportions that, with 20-20 hindsight, would never adequately serve the vastly differing needs of 58 counties. But when DSS chose NAPAS as the system on which to base SAWS, it created a major boondoggle that eventually led to one of the biggest project transfers in state government history.

To start, DSS relied on Unisys -- the vendor for NAPAS -- to help evaluate which system was best suited for a statewide rollout, according to a report issued by the state's Legislative Analyst's Office, an independent agency. When DSS chose NAPAS, the agency obtained approval to build the system in 14 counties to evaluate the business case for using NAPAS statewide. The evaluation was dubbed the Interim Statewide Automated Welfare System (ISAWS). Since the software for NAPAS was developed on MAPPER, Unisys' proprietary operating system, the vendor was given a sole-source contract worth $109 million to build ISAWS.

But MAPPER was fast becoming an obsolete software program by this time. To make things worse, NAPAS was not designed to handle the kind of caseload that would exist under ISAWS or even SAWS for that matter. DSS' solution was to try and convert MAPPER to COBOL, a more universal computer language for mainframes and minicomputers. As Mecca pointed out, "the state wanted to change proprietary code on proprietary hardware. There's only one vendor to do that. So Unisys, the pilot winner, wins the entire system!"

Clearly, DSS had no strategy for opening up the vendor bidding on either ISAWS or, eventually, SAWS. The agency's course at the time would have left the entire project in the hands of one vendor. Such a scenario would have drastically shifted the risk of the project over to the state. Already, costs for the closed system were out of control. In 1993, DSS estimated ISAWS to cost $109 million for a caseload of 300,000. By comparison, the state of Virginia, with a caseload of 400,000, spent $20 million for the same system used in NAPAS. To make matters worse, the federal government ended enhanced funding for welfare automation in 1993, eliminating the one requirement for a single, statewide system.

According to Healy, it was never his intention to make NAPAS the sole welfare system for the state. The 2-3 years it would have taken to expand NAPAS into ISAWS would have led to a second phase of the project, based on newer technology, such as client/server, to serve larger counties. "California is so large, you have to view automation in evolutionary stages, rather than do a single solution," he said.

New Strategy

By 1994, Healy had left DSS, and SAWS was in deep trouble. Cost estimates for the entire project now reached $800 million. In fact, the Legislative Analyst's Office (LAO) was forecasting a final bill for SAWS exceeding $1 billion over a 12-year period. Worse, LAO criticized ISAWS' spiraling costs. "Our analysis indicates that the primary reason for the increase in the projected ISAWS costs are various errors in planning for the 14-county implementation of the project," wrote LAO in its annual report to the state Legislature in 1994. The errors included the use of outdated information to make budget requests and the failure to account for critical computing needs in the original planning documents.

When a state auditor issued a report on SAWS in 1994, it found -- among a number of issues -- that DSS had no strategic plan, had not developed measurable objectives, had not established an effective cost accounting system and had not prepared a risk assessment plan.

Assemblywoman Bowen recalled that some aspects of SAWS just didn't add up. "The idea that you would run the entire caseload for a state with 32 million people on a single mainframe in the kind of environment that relied on menu-driven, dumb terminals just didn't make sense," she said. "Their plan was to deploy that version [of ISAWS] statewide, even though scaling the system up to handle larger caseloads slowed down processing so much that it wasn't functional any more."

No longer able to stand by and watch, Gov. Wilson, in an unprecedented move, transferred SAWS, as well as the statewide child support and child welfare automation projects, from DSS to the Health and Welfare Data Center (HWDC). That same year (1995), the Legislature authorized a "multiple county consortium strategy" for implementing SAWS, reversing the project's direction once again. Now, counties could choose the automation strategy that best fit their needs. The single system approach was dead.

Initially, the counties were worried when the state uncoupled SAWS from the state's welfare program, Mecca remembered. "But we found there are benefits to working with a service bureau, such as HWDC, because their job is customer service, not issuing regulations and monitoring compliance."

HWDC divided SAWS into four consortia:

* ISAWS with 13 percent of the caseload and 35 counties;

* LEADER with 35 percent of the caseload and Los Angeles County only;

* Welfare Case Data Systems with 40 percent of the caseload and 18 counties; and,

* Consortium IV with 13 percent of caseload and 4 counties.

According to Mecca, the consortia approach has given the counties the choices they want without forcing the state to give up what it needs to control -- standards, costs and oversight. "This is the only way to balance the needs of 58 counties where demographics and politics are so different," he said. "You can't read the history of automation in California without coming to the conclusion that county involvement in automation projects has led to success. Where counties are not involved, the systems won't work."

From the perspective of HWDC, the data center is bullish that SAWS, in its present form, will succeed under its stewardship. Already, the ISAWS consortia is expected to be in full production by February; LEADER will be tested later this year; the Case Data System consortia will release an RFP by November; and Consortium IV is well into the planning stage.

Richard Radan, deputy director for HWDC, admits that the consortia approach poses a challenge. "You need a multiple approval process and it's technologically challenging to exchange information between the different systems," he said. But the approach has the widespread buy-in of the counties, which also have greater responsibility for the system's success.

But the present success has come at a price. ISAWS' latest price tag is $312 million to automate less than 15 percent of the state's welfare caseload. A state official has reported that LEADER, which will handle 40 percent of the caseload, will cost $90 million, using essentially the same technology from Unisys. And according to LAO, ISAWS is expected to lose money for nearly 10 years.

The Welfare Reform Wild Card

The Welfare Reform Act of 1996 may have changed welfare as we know it, but the Act has created a new tempest among welfare directors. New reporting requirements are forcing welfare data processing departments to spend scarce time and money upgrading and overhauling software and systems.

According to John Thomas Flynn, chief information officer for the state of California, welfare reform will have a staggering impact on the state. "The question we have to ask ourselves is, 'Where do we go? Do we slow down or wait?'" Flynn said the consensus is that states can't slow down welfare automation because of the Act. But neither can California afford to move forward without first establishing a strategic plan. At stake is $625 million the state plans to invest in welfare automation projects over the next three years. Already, welfare reform is costing SAWS time. LEADER, the system for Los Angeles County, has fallen behind schedule more than six months because of changes required by the Act. RFPs for Consortium IV and the Welfare Case Data Consortium also may be affected.

Welfare reform will also have an impact on the diminishing amount of human resources available to work on automation projects. Besides SAWS, HWDC is also directing three other major statewide automation projects: child support, child welfare and electronic benefits transfer (EBT). Flynn admitted that California doesn't have enough project managers who can handle $100 million automation projects. Fortunately, EBT is in good shape, because the counties have taken the lead on the project, said Flynn. According to Radan, human resources at HWDC are always tight, but the center is organized in such a way that professionals for systems support and project management are always available to help staff who are assigned to SAWS on a full-time basis.

An Educational Experience

But can SAWS remain out of trouble? And what has the state learned from its experience with SAWS that can be applied to future statewide automation projects?

One major problem area for SAWS was procurement. Assemblywoman Bowen called the current system antiquated. She pointed out that the process is so slow and painful for public agencies that the natural inclination is to lump everything together so that the process doesn't have to be repeated. Yet, experience shows that the automation projects that are built in phases, using smaller procurements, are most likely to succeed.

Flynn pointed out that the state is moving toward best-value procurements and partnerships with vendors to improve the implementation of IT projects. But he warned that as long as there are federal funds tied to a state project, the state will be forced to follow federal rules, some of which are light years away from procurement reform. It's in those situations where automation projects are likely to stumble.

Training remains a big issue, especially in a state like California, which has such a lucrative high-tech private sector, drawing public sector IS professionals away like a magnet. Bowen believes the state needs to procure systems based on business needs,
not technical specifications. Work arrangements with vendors need to be more collaborative so that knowledge transfer can take place to bolster the technical skills of the existing staff.

The state's relationship with counties needs to improve. California county government is considered strong compared with other states. Most officials -- state and local -- agree that it's hard to strike a balance with projects such as SAWS. "Not everyone is going to be happy with the final results," remarked Mecca, but without county involvement in something so important as SAWS, there's bound to be battles that end up wasting time.

Flynn agrees. But as devolution moves more federal programs down to the state and local level, "the counties will have to step up to the plate in terms of project responsibility," he said.

Finally, projects with the scale of SAWS can't succeed without leadership that is engaged in a substantive manner. Flynn believes Gov. Wilson has amply demonstrated his engagement by creating the state's first CIO position and by championing how the state should tackle the millennium crisis among state IT systems. But Bowen is not convinced. "Information technology is no longer something you can delegate to a bunch of people -- the bean counters -- and then pay no attention," said Bowen. "Technology defines how we work today. Unfortunately, I think California's governor still views technology as a backroom function and doesn't understand how important successful deployment [of technology] is for the state to work in the 21st century."

December Table of Contents