Vendors: Ernst & Young;
Jurisdictions: North Dakota, Mississippi, Arizona, Florida, Maryland, federal government, California, Nebraska, Massachusetts, University of Washington, Merced County Human Services Agency,
By Rita Kidd
Columnist
Capacity planning in welfare system development has not evolved into an exact science. Since the problem was first recognized a decade ago, vendors and state project teams, in project after project, have underestimated required processing power, causing states to lose control of service delivery.
The seriousness of the issue - as a critical element in the short and long-term cost of systems - was first noted in 1986 and 1987, during the first large state system transfer from North Dakota to Mississippi.
Progress on the project was halted for six months to project equipment needs. With only 12 percent of cases loaded, Mississippi had reached 40 percent of planned system capacity in an implementation that did not include Medicaid eligibility determination.
From that point forward, capacity became a point of discussion by most vendors in proposals where there was shared risk. The topic is ongoing among state project teams attempting to better understand the dynamics of welfare system capacity demand. In spite of gradually dawning recognition of the seriousness of capacity issues, there are still no tools to resolve the problem, nor is there a government structure in place to properly address it.
INADEQUATE CAPACITIES
Following startup capacity issues in states as diverse in caseload size as Arizona and Florida, workers continue to suffer significant response-time delays brought on by inadequate machine capacity. Most states have experienced similar problems. Legislatures are continually forced to allocate funds for capacity upgrades as caseloads grow, policy becomes more complex, and greater integration of systems is needed to provide "one-stop" service to the public.
If federal officials had taken a proactive role in evaluating the factors inherent in traditional FAMIS system development - specifically those which cause severe capacity planning problems - perhaps the outcome would have been different for states capable of using newer technology approaches available in the 90s. Now, however, the majority of states have already completed FAMIS systems and cannot control equipment and operation costs.
Capacity problems - extending user response times to minutes in many cases - confound workers struggling to meet case processing targets, create backlogs in eligibility determination and degrade client service. These delays create additional processing loads as departments provide emergency stop-gap services. Unions and line workers seek to reduce caseload targets to align with slower response time, while administrators are pressured to downsize staffing levels to control costs.
The cost of meeting system capacity demands - rather than program business needs - dictates a level of automation so low in some situations that cumbersome manual systems are rebuilt to support case management processes.
Daily batch windows creep into early morning, and the work day is compressed to allow batch processing to begin earlier in the evening, . Month-end batch processing may steal entire workdays each month. It becomes harder and harder for workers and clients alike to avoid accusatory phrases like "the system is too slow." This threatens worker and client acceptance and confidence in automation as a better way to do welfare.
CAPACITY DEMAND GROWS GEOMETRICALLY
Welfare system capacity planning differs from other automated systems as the following factors increase capacity needs by geometric, not linear, proportions:
+ The level of program integration and amount of machine-based, rather than human-based, decision making.
+ The complexity of the eligibility and benefit calculation rules for individual programs.
+ Treatment of client data with complex relationships across multiple programs, each of which may treat the same person or case differently.
+ The mix of program case types within individual households.
+ Old rules must be retained and maintained to rework cases as rules change.
+ Legislative and congressional action keep programs and policy in flux.
In a given month, a single case could be worked multiple times by different functions in today's rules, last month's rules or each month's rules for the past two years - as in the case of a fraud investigation. As government sets more exacting rules to limit welfare benefits, systems must manage not only periods of eligibility but also periods of ineligibility. The rate of change to state and federal participation rules or requirements across programs worsens this situation.
In California where the rate of change is said to be "one rule change per day" - and where clients are required to report household status information monthly - one can intuitively understand the impact on capacity, but projecting need accurately in order to avoid response-time delays is a different story.
PROGRAM INTEGRATION AND CASE COUNTS
As states have attempted to fully integrate their systems and have one worker responsible for multiple program eligibility in a single household, sizing exercises have failed to take into account that capacity is determined not by household counts but by fully duplicated program case counts. This lack of understanding was pointed out again recently in an Ernst and Young report on California welfare systems. The report states: "To size mainframe equipment, we used revised estimates of 1994-95 `non-duplicated' welfare cases (one person receiving public assistance from two programs typically has two duplicated case folders opened, but would be one 'non-duplicated' case when automated)..." Ernst and Young understood the impact of non-duplicated case counts on workload, but misfactored the information in projecting capacity.
In reality, such data must be applied differently for three separate capacity purposes: (1) staffing; (2) data storage; and (3) CPU sizing. "Quick and dirty" calculations can use non-duplicated case counts to project needed staff numbers. Depending on system design and level of integration, some combination of non-duplicated and duplicated case information is applied to data storage needs.
In the case of CPU sizing to handle transaction volumes in integrated systems, however, fully duplicated case counts must be used because each program benefit must be determined independently, requiring multiple passes at case information.
The transaction volume must further be expanded by factoring the number of times per month the case may be touched by different functions, the number of back months of rework on average, any impact created by specialization of workers and the effect of case processing methodologies and hardware and software architectures and products.
THE ARCHITECTING FACTOR
Vendor proposals and state choices for combinations of database management systems and third- and fourth-generation software languages add a very critical component to computing capacity needs. As system designs have moved from using hierarchical DBMS to relational DBMS, states like Maryland are encountering even more severe capacity problems. Rather than managing the contributing factors in advance through conscious architecting of the system software and hardware for an advantageous long-term cost picture, states have made decisions based on technical preferences and then were faced with managing the problem by reducing the level of automation or making major equipment upgrades.
SIMPLE SOLUTIONS?
Looking for simple solutions - in the absence of comprehensive capacity planning reference data - some systems innovators believe that substitute hardware configurations, which eliminate the mainframe processor altogether, will solve the problem. Federal agencies and the industry should closely follow outcomes in the Nebraska and Massachusetts projects both of which are using distributed approaches with an expert system running on workstations, one with a mainframe back end and the other with a UNIX-based mini-computer back end. Information from these two projects should round out information from other system developments over the past ten years.
It is an open question as to whether welfare system capacity demands will be solved entirely by moving from mainframes to UNIX-based minicomputers. However, I concur with Tom Martin, director of system development for University of Washington Medical Centers: "While capacity demands may shift from mainframe transactions to the network and servers," he said, "scalability of new solutions will allow states to control the long-term cost of systems." Vendors must be incited to do a better job of designing welfare systems that address the inherent capacity issues by tying compensation to overall outcomes. Martin recommends modifying the current structure that rewards project teams based on the first year's outcome rather than the longer-term view. They should be based instead on long-term operations and maintenance costs on a per-worker/per case basis.
NEED FOR FEDERAL LEADERSHIP
The current state and federal funding and oversight relationship prevents airing of "negative" capacity demand information. It isn't too late in the process for the federal role to be redefined and the structure put in place to encourage exchange of complete, accurate information. The desired result would be to set standards for optimum cost ratios on machine/human performance in order for public administrators to pre-evaluate solutions and post-evaluate results. This type of strong business need standard would provide a much-needed guide for states as they begin to explore cost-effective solutions for controlling the ongoing cost associated with state welfare systems implemented during the last ten years.
As data accumulates on the problems, successes, long-term outcomes and overall cost of state welfare system implementation efforts, federal leadership is needed to commission a study and report on the relative impacts of contributing factors. The study would facilitate the setting of standards for architecting systems that are financially manageable without dictating either technology or functionality.
WHAT IS NEEDED
The study should survey and address:
+ Each state's implementation and post-implementation experience and cost in managing capacity based on combinations of hardware, DBMS, software employed in batch and online processing, level of program integration, number of cases vs. number of households, caseload targets, staff-to-case ratios, case processing methodologies, levels of policy automated, and amount of worker decision-making vs. machine processing.
+ A description and evaluation of specific state system capacity issues. The study should attempt to factor the above pieces of information as components of the overall problem.
+ Identify causal factors in detail. Delineate these from common welfare system components that do not impact capacity. Define the contributing level of impact of the defined causal factors.
+ Describe the steps required to correct capacity deficiencies, size of upgrades and whether there was excess capacity following the upgrade, including changes to data storage and communications peripherals. Identify the point at which capacity was reached again, and the factors leading to using up the excess capacity; e.g., new programs previously not automated, new policy in automated programs, caseload growth, increase in number of workers or users.
+ If some states have not experienced capacity issues - why? What specific contributing factors were absent or how were they managed differently?
+ The study should draw conclusions suitable for guiding future projects, identifying viable practical solutions that can equally serve states that have not yet built a FAMIS system, as well as those states beginning second- and third-generation development efforts.
There is too much information available on this problem to have it be an ongoing issue a decade after first reported. Welfare administrators who must make the choices that either incur excess cost or save tax dollars should not have to do so in a vacuum. We must develop an effective toolset to support capacity planning and end dependence on "good will" between states which results in passing what amounts to scanty information at best.
Rita Kidd provides commentary and analysis on human services and other large-scale automation efforts in state and local government. Her experiences as former deputy director of Merced County, Calif.'s Human Services Agency, and as director of MAGIC - Merced County's welfare automation system - provide valuable insight into the complexities of welfare automation and approaching welfare reform. She is now a government reengineering consultant residing in Cathey's Valley, Calif. Her opinions are her own, and not necessarily those of GT or its editors..
