State Automation Systems Study

              mzs
Unrted States
Department of
Agriculture
Food and
Consumer
Service
OMce of
AnolyMs one
Evaluation
State Automation
Systems Study
Volume I
December 1995
L'*>'*"Ar £1
United States Food and 3101 Park Center Drive
Department of Consumer Second ROOT
Agriculture Service Alexandria VA 22302
State Automation Systems Study
Final Report
Volume I
Executive Overview
Jack Slocum
Elizabeth Wenchel
Carolyn Lichtenstein
Chris Fortune
Julie Neafach
Ann Perper
A product of:
The Orkand Corporation
8484 Georgia Avenue
Silver Spring, MD 20910-5695
December 1995
This study was conducted under contract number 53-3109-2-007 with the
Food and Consumer Service. U.S. Department of Agriculture. Points of
view or opinions stated in this report do not necessarily represent the
official position of the Food and Consumer Service.
1
ACKNOWLEDGMENTS
The authors would like to thank the many people who made important contributions to this
report. The following individuals deserve special recognition.
• Diana Perez, Christopher Beavers, and Shelia Little of the Food and Consumer
Service provided overall leadership, direction, and support throughout the study.
• The study could not have been completed without the cooperation of clients and
staff from the Food Stamp Program and the individual State agencies.
TABLE OF CONTENTS
I. EXECUTIVE SUMMARY 1-1
A. Purpose of the Study 1-1
B. Conduct of the Study 1-1
C. Findings 1-3
C.l State Food Stamp Systems 1-3
C.2 .1 DD Process 1-4
C.3 System Functionality Summary 1-5
D. Welfare Reform Considerations 1-7
D. 1 Client-Server Technology and Distributed Processing 1-7
D.2 On-line Eligibility Determination/Computer Matching 1-7
D.3 Imaging 1-8
D.4 Joint Development Consortiums 1-8
D.5 Customer Service 1-9
D.6 User Satisfaction 1-10
II. BACKGROUND II-l
A. Food Stamp Program Automation Requirements II-l
B. Basis for the State Automation Systems Study II-l
III. METHODOLOGY III-l
A. Study Objectives III-l
B. Methods HI-2
C. Areas of Study I1I-2
C.l Food Stamp Operations IH-2
C.2 Cost and Cost Allocation III-3
C.3 Systems Hl-3
C.4 Special Circumstances Encountered HI-3
D. Study Limits ons III-4
Volume I 0 Page i
IV. INDUSTRY TECHNOLOGICAL STANDARDS APPROPRIATE TO THE
FOOD STAMP PROGRAM 1V-1
A. Hardware IV-1
A.l Vendors IV-1
A.2 Application Growth IV-2
A.3 Software Support IV-3
A.4 Vendor Maintenance IV-3
A.5 Performance IV-3
A.6 Telecommunications Networks IV-4
A.7 Use of Intelligent Workstations IV-5
B. Software IV-6
B.l Software Tool Standards IV-6
B.2 Development Standards IV-7
C. Contractors IV-9
D. Project Management Standards IV-10
E. Balance Between FSP Needs and State-of-the-Art
Data Processing Systems IV-11
V. IMPACT OF CURRENT AND FUTURE SERVICE DEMANDS ON FOOD
STAMP PROGRAM AUTOMATION REQUIREMENTS V-l
A. Current Service Demands V-l
B. Future Service Demands V-2
C. Impact of Demands on Food Stamp Program Systems V-3
D. Developmental Directions to Meet Changes V-S
VI. RECOMMENDED GUIDELINES FOR FCS VI-1
A. Proposed Standards for State Systems VI-1
B. Approving APD Requests VII
C. Technology Transfer Analyses VI-6
Volume I i/ Page ii
I. EXECUTIVE SUMMARY
A. PURPOSE OF THE STUDY
In the 1990 Farm Bill. Congress requested that the U.S. Department of Agriculture (USDA) Food
and Consumer Service (FCS) conduct operational reviews of State public assistance systems to
determine:
• The extent to which State agencies have developed and are operating effective systems
to support Food Stamp Program (FSP) delivery.
• State compliance with conditions of initial funding approval.
• Whether ihe States are providing adequate support for FSP delivery, as required.
In response to this legislative requirement, FCS implemented the State Automation Systems
Study. The primary purpose of this study is to determine whether systems being developed are
effective, efficient, and meet the needs of the Food Stamp Program. During the course of this
effort, the study also built an inventory of the status of systems development and operations in
the States and examined the current process through which States request Federal funds to
develop and operate automated food stamp processing systems.
B. CONDUCT OF THE STUDY
The tasks performed in conducting this project involved:
• Reviewing State systems supporting food stamp operations; evaluating the planning,
implementation, and transfer processes used; identifying the hardware and software
platforms in place to process the application and their adherence to "industry standards";
and evaluating cost accounting and cost allocation procedures and making
recommendations for enhanced FCS guidelines in these areas.
• Evaluating the current Federal Advanced Planning Document (APD) oversight and
approval process and recommending improvements in the process.
The study was conducted in two separate steps:
1. Visits to every State and the District of Columbia to review the p'annmg and
implementation of public assistance systems.
2. A review of the FCS APD review and approval process.
The State visit portion of the study addressed a wide variety of activities that impact tht
development and operation of a food stamp system. Aspects of the States' project management
approach, staff commitments, use of contractors, and strengths and weaknesses of the APD
process were discussed. State staff demonstrated the functionality of the current operational food
Volume I £ Page 1-1
stamp system, and the project team reviewed planned and actual systems costs and cost allocation
methodologies. A series of questionnaires and interview guides were used to capture data from
State staff. These data were used to develop the technical conclusions discussed in Volume II
of this report. In addition to the questionnaires and interview guides, a User Satisfaction Survey
(USS) was developed and mailed directly to randomly-selected eligibility workers and supervisors
in each State to better determine their level of satisfaction with the current operational system.
A combination of data obtained using these methods was analyzed to gauge the effectiveness and
efficiency of a State's system.
The evaluation of FCS oversight consisted of a review of the current APD process, which is
addressed in the FCS Handbook 901, Advanced Planning Document Handbook. The handbook
outlines an effective and thorough process for the States to follow when requesting Federal
financial participation from FCS. This part of the study involved meetings with all seven FCS
regional offices (RO) and FCS headquarters (HQ) staff to discuss their approaches to APD
reviews and determine their abilities to review State APDs within stated time guidelines.
This report is organized into two volumes:
• Volume 1 addresses the Executive Summary, project background, objectives, and the
methodology used in conducting the study. In addition. Volume I discusses automation
industry standards applicable to food stamp processing, the impact of service demand on
the FSP, and recommended guidelines that could be adopted by FCS to improve the APD
oversight process.
• Volume II contains an analysis of the data collected during the State visits and our
findings based on the information gathered. Areas addressed are: degree of automation,
the system development process, the impact of system transfers, project costs and cost
allocation methodologies, implementation of regulatory changes, and the level of
automation and FSP automation needs.
Conclusions, observations and findings are included in both volumes since they are tied to the
location of the item discussed.
Volume I / Page 1-2
M
C. FINDINGS
The findings detailed in this section relate to the two major areas described above.
C.l State Food Stamp Systems
The study findings concerning the automated systems that support the Food Stamp Program are
as follows:
• Virtually all States have centralized, mainframe-based systems with terminal workstations
and a centralized database. New technologies, such as client-server, distributed
processors, and intelligent workstations, are not widely used.
• IBM and IBM-compatible platforms, which are considered to be "industry standard" for
hardware, are used by over 80 percent of the States.
• Use of System Life Cycle Development (SDLC) methodologies for system development
and maintenance is becoming the norm, and its use should be encouraged in those States
where it has not been implemented. Recognized, established SDLC methodologies are
proven procedures that create a formal process requiring all software development and
maintenance personnel to follow the same procedures and processes for all projects. Its
use promotes uniformity and helps ensure adherence to establish standards. In the long
term, maintenance activity can become more effective when all software projects have
followed the prescribed design and documentation procedures and personnel can better
understand and support the software logic flow .
• With respect to implementing regulatory changes, States experience more difficulty with
issues related to adequate notification and clarity of the changes than with the
technological impact of making the change. There does appear to be a need, however,
for some central authority to determine, in general terms, the potential impact of a
regulatory change on the automated systems into which the change will be incorporated.
This determination would not require a detailed knowledge of State and Federal
regulations, but would more logically assess the technical steps necessary to incorporate
the type of regulation proposed in light of the type and configuration of "average" systems
used by States at that point in time. The outcome of this review could be used as a form
of "feedback" to regulators that could be factored into the regulatory deliberation process,
either as a method of establishing the implementation timeframe, or for a more accurate
evaluation of the costs likely to be incurred to implement the desired change.
• Successful project planning should involve user departments and field staff to ensure a
functionally improved design during the planning, development, and testing phases of the
project.
• Cost accounting and cost allocation plans are being performed and developed according
to industry standards and acceptab'e practices; however, there are so many variations that
it is virtually impossible to accurately compare State costs.
Volume I n Page 1-3
• A number of findings related to the State's level of automation and the needs of the Food
Stamp Program, as discussed in detail in Volume II, Chapter VII of this report, can be
summarized as follows:
no statistical relationship was found between the number of food stamp
cases and the average Federal administrative cost per household, nor was
any relationship established between a State's degree of automation and the
Federal administrative cost per household.
the analysis indicated that there is no statistical relationship between error
rates and the degree of automation. While we feel that error rates remain
an important measure of overall program effectiveness, too many factors
associated with error rates make them a poor measure of system
effectiveness.
no relationship was discovered that confirmed that higher levels of
automation resulted in higher levels of claims collected.
users tend to be more satisfied with less complicated systems and newer
systems if they have recent experience (within the past 6-18 months) with
an older system that was less effective in supporting their efforts to service
the client.
C.2 APD Process
Another area of interest during this study was the ability of RO and HQ staffs to evaluate APDs
submitted by the States to obtain approval for Federal funding. Our findings in this area are:
• The cost ofdeveloping and operating these Federally-subsidized systems justifies increases
in both headquarters and regional office staff to oversee these projects.
• RO staff should conduct regular (no less than quarterly) visits to States that are actively
developing systems. RO staff should visit States running operational systems at least
twice a year to observe and evaluate the ongoing operation and learn of any problems
first-hand. This visitation schedule will allow FCS staff to more fully understand the
development processes and the strengths and weaknesses of particular systems.
• Technical training or technology updates for FCS staff should be conducted once or twice
a year to enable staff to remain current with respect to technological developments. This
is especially important since many FCS staff do not have the opportunity to maintain
technical currency through "hands-on" exposure to new technology and cannot effectively
evaluate the strengths and weaknesses of State development alternatives without this
knowledge.
• Since new system development projects in the 1990s are averaging over $29 million, the
limit for regional office approval should be raised. This will allow reasonable
Volume I ^ Page 1-4
enhancements and system upgrades to be reviewed at the regional level and reduce the
Executive Oversight Committee's workload of routine APD updates and funding requests.
• Improvements are necessary in the coordination of reviews for integrated systems that
require both FCS and Department of Health and Human Services (DHHS) approvals.
Extraordinary delays can be experienced in gaining dual approvals since conflicting
changes may be requested by the agencies.
• A more clearly defined cost allocation requirements document must be created to avoid
delays and confusion that exist in current documentation. Virtually every State has
suggested that dramatic improvements are needed in this area. A new, joint DHHS/FCS
cost allocation procedure should be developed to allow the States to create acceptable cost
allocation documentation for both agencies and help eliminate costly delays in the review
and approval of the State submissions.
C.3 Summary of System Functionality
During the State visits, a demonstration and discussion of the food stamp system functionality
were conducted to identify those functional areas and automation techniques that were most
common and appeared to be most efficient and effective in supporting the program.
Appendix A in Volume II of this report contains a detailed listing, by State, of the automated
system functions created to support the Food Stamp Program and the level of integration and
automation that States achieved in their systems. As a way to visualize the types and numbers
of these functional activities, Table 1.1 summarizes the number of States performing some of the
key functions.
Table 1.1 System Functionality Summary
System Function Total Number
of States
Check for duplicate participation - home state only
- adjoining States
38
6
Duplicate participation searches - by name
- by social security no.
- by race
- by sex
- all household members
- on-line, real-time response
42
39
13
28
40
10
System assigns caseworkers 10
System schedules appointments 12
System indicates expedited service qualification 15
Volume 1
<\
Page 1-5
Applicant data entry - clerical after interview
- Eligibility worker (EW) after interview
- EW at time of interview (interactive)
14
28
21
System determines eligibility 37
System calculates benefits 41
System tracks outstanding verification requests 29
System automatically alerts EWs of missing verifications 28
System forces resolution of all verification request 26
Computer matching performed - at registration
- at certification
- at re-certification
46
31
31
Matching is reported against all databases 16
System reports matching resolutions to EWs 16
System sets priority for all matching hits for the EW/Supervisor 6
System automatically generates notices 44
EW input capability to customize notices 26
System reporting capabilities - ad hoc
- daily standard reports
15
18
System has an E-Mail function 33
System has an on-line problem reporting function 15
Claims collection - integrated into food stamp system
- separate system that provides data to food stamp
system
31
8
System tracks claim status 40
System generates payment notice 33
System determines - benefit claim amount
- calculates recoupment amount
- determines collection method
- maintains files/tracks claims status
14
46
11
44
Volume I 10 Page 1-6
D. WELFARE REFORM CONSIDERATIONS
In today's era of re-engineering government and finding new ways to reform the welfare process,
automation can play a leading role in assisting the Federal government in providing more
effective services for its clients. Some steps are already being taken to create new paths towards
improved service levels, more controlled and accurate eligibility and benefit calculations and
benefit distribution, and improved performance and reliability for all system users.
In this section, we provide insights regarding technology areas into which FCS may want to
direct some of its new efforts.
D. 1 Client-Server Technology and Distributed Processing
The demise of centralized mainframe-based data centers, forecasted by many as inevitable, has
not yet occurred It is unlikely that it will ever occur, but it is clear that newer platforms are
providing more cost-effective solutions to current automation requirements.
The vast majority of States are still developing large, mainframe-based systems to support public
assistance systems, just as they did 15 to 20 years ago. Newer technologies, such as client-server
and/or distributed processing platforms, might enable States to achieve significant benefits. By
viewing the current environment as a wheel -- with the data center at the hub and the field units
at the end of the spokes ~ one can visualize how these new platforms could provide more
efficient and. hopefully, more cost-effective systems. One promising scenario involves using the
data center as the central repository for the State's master file. At the end of the nightly update
cycle, the mainframe would download each region's new client files to the regional server or
distributed processor. Processing would be handled between the regional server or processor and
its connected workstations. If a client applies for benefits outside the region where he or she
currently receives or previously has received benefits, the information would be retrieved from
the central mainlrame and 4 wnloaded to the processor. This level of support would enable the
regions to be more self-sufficient, make them less vulnerable to Statewide system outages, and
reduce the cost and size of the central processor complex. With the processing capacity more
closely aligned with the user locations, specialized processing requirements could be customized
more easily to meet the needs of the local users.
FCS should acquire the technical expertise through adequately trained staff or external contractor
support to provide technical guidance to the States that will help identify those projects which
have the greatest potential for benefitting from client-server or distributed processing technology.
Those candidate projects could be useful in gaining valuable practical experience in these newer
technologies.
D.2 On-line, Real-time Eligibility Determination and Computer Matching
In today's communication-intensive environment, access to information can be performed quickly
and efficiently. Credit checks, account balance information, and inventory status can be
determined with a touch-tone telephone In the world of Federal assistance, the ability to
determine applicants" eligibility for specific programs relies on data that may be several months
Volume I I \ Page 1-7 l\
old and only can be verified through comparisons performed during nightly batch update runs
While it is understood that there are data security and sensitivity issues associated with this type
of data verification, it would be much more effective if the processing organization had direct,
real-time access to databases that could be used to verify an applicants information In turn, this
would enable eligibility determination to be completed quickly and allow benefits to be disbursed
sooner. I hrough cooperative efforts with those agencies where the most useful matches typically
occur. FCS should be able to facilitate a standard access and query process that could be
incorporated into any State's system to enable on-line access to these files.
D.3 Imaging
Any organization that creates and retains paper files could benefit from the use of imaging
technology. The technology would allow States to create electronic client files that could be used
to verify eligibility from different counties or even different States without having a clerk or
eligibility worker dig through paper files Client applications, signatures, and birth/death records
could be stored, tracked, and merged with other electronic information from a variety of sources
to create a complete and consolidated history file on the client. Older files could be archived to
tape or other long-term storage media that could be electronically retrieved when required.
Benefits that could be realized include: savings in storage space, more accurate client files, and
longer-term storage and retrieval.
D.4 Joint Development Consortiums
Historically. State development processes have fallen into one of two categories: unique, custom
development efforts and packaged (transfer) software acquisitions. Recently, a number of States
have worked together to attempt a joint development venture for electronic benefits transfer
(EBT). A similar approach might be useful for developing new tools and technologies to meet
the changing needs related to State systems for processing food stamp activity. With the
capability to understand each State's automation priorities and plans from the A D process, FCS
is in a position to link States with similar plans and priorities together. By combining the talent
and insights of multiple States into a common project, it is possible that a more effective planning
and development process could result. The joint development process could shorten development
time for each State and reduce development costs I nique system requirements would be handled
by the individual States as enhancements to the basic system
Taking this approach further. FCS could fund the development of a national food stamp system
design that would encompass all Federal processing and calculation requirements and Iv easily
incorporated into other Federally-supported development projects. Jt is also possible that an
integrated system design could be created jointly by all pertinent Federal age^ies that would
address all assistance-processing requirements from each program and provide the States with a
fully-supported, consistent and maintained processing system into which they could incorporate
their individual, unique State requirements. The cost of developing and maintaining the national
system would be generated from the savings of not having to share in Federal financial
participation with States in the development of individual systems for each new system State
modifications would be funded by the States without Federal participation. While this approach
would appear to be cost prohibitive, an examination of the current development costs would
Volume I J^ Page 1-8
indicate that there are tens of millions of dollars that could he reallocated annually to a national,
centralized approach
D.5 Customer Service
The major focus of this study is to determine the methods and results used hy the States to
develop and implement sound and effective automated systems to support the Food Stamp
Program. While conducting the State visits, it became clear that the vast majority of States are
delivering the correct benefits to the customer within the prescribed timeframes. Delivery of
these services does not appear to be an issue.
At the same time, a number of States have implemented attractive features to their systems that
make the process of applying and receiving public assistance benefits easier on all parties
involved, both customers and State workers.
The ability to capture customer information only once is an ideal situation. The process of filling
out long, tedious forms, having a State data entry clerk key the entire form into the system, and
then having an eligibility worker review and refine the data during the client interview is too
cumbersome, aggravating and error-prone. Systems are being developed (21 States have or are
developing such applicant data capture systems) to allow the customer to fill out and sign a
single-page form that can be used to perform duplicate participation searches, and provide all the
additional information to the State worker during the interview which can then be ca tured and
validated by the system during the interview. This approach shortens the amount of time clients
spend in the State"s offices and enables *he State worker to develop eligibility and benefit
calculations interactively, dealing with only those issues pertinent to the specific client. A
number of States have implemented this approach, and while it takes more time and money to
develop, the returns in the form of improved customer service, reduced transcription errors, and
use v^f computers to perform many of the clerical checks and verifications greatly improves the
overall system efficiency.
Many of the out-of-State data verifications are still being performed with older data transmitted
from the supplying agencies weekly or monthly and checked overnight during batch update runs.
Today's telecommunications networks and software should be used to provide on-line access to
these databases to validate customer information while the eligibility determination process is
being conducted. At present only 10 States are using this technology. If this process is
performed during an interactive customer interview, data discrepancies can be more quickly
identified and resolved with the customer*s help. If it is an innocer.t error, it can be quickly
corrected. If it is an attempt to commit fraud, the attempt can be quickly stopped and appropriate
corrective actions can be U. ;en.
The ability to deliver benefits to the client (issuance) is still being handled as a separate function
b\ most States, with only 16 States having full or partial on-line access to the issuance function.
While the current process does not appear to create an undue burden on States, improvements in
the issuance arem :an produce tremendous returns in the areas of customer satisfaction and.
potentially, fraud control With the advent of electronics benefit transfer (EBT) capabilities, the
customer may be able to receive their benefits more quickly and conveniently
Volume I 1| J3 Page 1-9
D.6 User Satisfaction
The purpose of the Slate User Satisfaction Survey (USS) was to gain an overall view of
eligibility workers* and their supervisors' perceptions of the system supporting the Food Stamp
Program. It was not designed to elicit specific likes and dislikes of the particular system. In
some cases, the limited responses did not provide enough of a cross-section to reach any
meaningful conclusions. Specific results of each State's responses are addressed in detail in the
individual State reports provided as part of this stud*'.
There are some general conclusions that can be drawn, based on the overall review of worker
comments.
Virtually every State's programmatic and systems management teams and public assistance
workers felt that without access to the automated systems the tremendous increase in customer
demand for food stamp assistance, as well as other federal assistance programs, would have
crippled their ability to provide timely and accurate benefits. This was true regardless of whether
the systems were viewed as productive and helpful or archaic and disruptive. This universal
acknowledgement presents a strong message that automated systems are a requiremerit in today's
public a 'stance work environmei Staffing levels have been consistently reduced since the
1980s; caseloads per worker have been increasing as the number of people on public assistance
grows at the same time that staffing levels are shrinking; and, the implementation of more
effective automated systems takes years to design, develop, and implement.
Overall, systems that were viewed as useful we: those that provided a logical view to the worker
that enabled them to easily navigate through the various components to meet the needs of a
specific customer. Highly-sophisticated, complex solutions added more stress and confusion to
the process and are not well-received by the workers.
Timely and effective training is another area that can have a major impact on the ability of the
workers to assimilate knowledge of the system's capabilities. Use of a "Train the Trainer"
method where each office sent one or more representative to a comprehensive training class and
then had them return to train the remaining office workers appears to be very effective, especially
when implemented at nearly the same time as the office's implementation of the new system so
they can use their training immediately and reinforce what they have learned.
On-line regulatory documentation and function-specific HELP capabilities are also high on the
list of desired features. The HELP function appears to be a fairly common feature, although
sonr* MI -nuch more productive than others. Use of eligibility workers in the design phase of
the Hfcl.P function could greatly enhance the usefulness of the feature. Accurate and complete
information for on-line regulatory documentation is not nearly as well developed. In many cases,
the capability is not used by the workers because the information is incorrect or too old to be
useful.
Volume I /WI Page I-10
II. BACKGROUND
A. FOOD STAMP PROGRAM AUTOMATION REQUIREMENTS
The Food Stamp Program (FSP) is designed to supplement the food buying power of eligible
low-income households. The program is administered nationally by the U.S. Department of
Agriculture's Food and Consumer Service (FCS) and locally by State welfare agencies. The State
welfare agencies, through their local offices, are given the mission of establishing recipient
eligibility and issuing benefits, reconciling the two. and reporting to Federal FSP officials.
The complexity of the data analysis and decision-making processes associated with executing this
mission, along with the massive caseloads carried by many State and local agencies, has
encouraged States to develop automated data processing (ADP) systems. Because these systems
are relied upon to determine the eligibility of individuals and households and calculate grant and
food stamp benefit amounts, the systems must be dependable and accurate with respect to Federal
and State regulations and treat all applicants and recipients uniformly.
The Federal government funds a percentage of both the developmental and operational costs of
automated systems that support Federal public assistance programs. For integrated systems,
reimbursement is provided by the Department of Health and Human Services (DHHS), FCS, and
other system users according to pre-approved cost allocation plans.
B. BASIS FOR THE STATE AUTOMATION SYSTEMS STUDY
In a 1990 study, the General Accounting Office (GAO) reviewed the status of food stamp
automation in several States. The GAO report documented that Food Stamp Program operations
in all States were automated to a certain extent. Twenty-four States had Statewide automated
systems that integrated FSP functions with those of the DHHS-administered Aid to Families with
Dependent Children (AFDC) Program. The GAO report indicated that few States had been able
to realize the benefits of automation that were originally anticipated.
Virtually all State systems are undergoing constant revision and enhancement and, as a result,
there is an ongoing need for FCS review and approval of system development efforts and Federal
funding requests. Twenty-one States have systems that are 10 to 25 years old and no longer meet
State and program needs. Other States are enhancing systems that have been implemented more
recently, and still other States are implementing totally new (or transferred) systems.
Another factor underlying this study was FCS' interest in issues related to development and
operational costs. FCS noticed that ongoing operational costs for ADP systems and support vary
greatly from State to State as do the costs associated with system development efforts.
Furthermore, FCS staff noted that the actual development costs and operating costs frequently
exceeded the estimated amount that originally was approved by FCS. To control these escalating
costs, FCS began to require that States investigate the transfer of existing, successfully-implemented
systems from other States. Nevertheless, most States found it necessary to
customize the transferred systems to meet their own needs and requirements, which increased
development time, funding requirements and, as a consequence, total cost.
t Volu-ne I ' Page II-1
In the 1990 Farm Bill (Section 1763) Congress requested that FCS conduct operational reviews
of State systems to determine:
• The extent to which State agencies have developed and are operating effective systems
to support Food Stamp Program delivery.
• State compliance with conditions of initial funding approvals.
• Whether these State systems adequately support Food Stamp Program delivery, as
required.
In response to this legislative requirement, FCS implemented the State Automation Systems Study
to determine whether new regulations and procedures should be developed for State system
development and implementation and FCS oversight of these activities.
Volume I If, Page II-2
III. METHODOLOGY
A. STUDY OBJECTIVES
The State Automation Systems Study has several related objectives. A major goal of this study
is to develop guidelines for FCS review of State system development efforts in the areas of FCS
oversight and monitoring and in determining the reasonableness of State funding requests.
Another objective of the study is to review standards for State automation (e.g., standards for the
development of automated systems and standards for cost accounting and cost allocation).
Findings of this study also will be used by FCS to reevaluate the current standards and procedures
for State automation efforts.
To evaluate the current environment, information has been collected from every State to identify
those factors that affect the following areas:
Success of system transfers
Success of system development efforts
Development costs
Operational costs
System Functionality
Degree of automation
Level of integration
FCS monitoring and oversight
The objectives of this study are as follows:
• Describe and assess the current degree and state of development of State automated data
processing and information retrieval systems.
• Assess and evaluate FCS' ability to provide oversight and to determine appropriate
funding levels for the development of State automated systems through the Advanced
Planning Document approval process.
• Compare State system development and maintenance processes with industry standards
for technological development.
• Determine the level of automation that is necessary, technically sound, efficient, and
effective for handling Food Stamp caseloads and the needs of the Food Stamp Program.
• Provide guidelines for assessing the reasonableness of State funding requests for ADP
development activity.
• Examine operational cost accounting and cost control measures and practices which are
or should be built into the project planning process.
Volume I / " Page III-l
• Identify factors influencing a State's ability to implement regulatory changes in a timely
manner.
B. METHODS
For the purpose of this study, data were collected from five data sources - FCS headquarters
monthly and quarterly reports, questionnaires sent to State personnel. State personnel interviews
conducted in all 50 States and the District of Columbia, State Advanced Planning Document
(APD) documentation, and survey forms completed by randomly selected eligibility workers and
eligibility worker supervisors within each State. The data collection period for the study was
June 1992 through December 1993. Historical information was obtained from FCS data sources,
APDs, and correspondence provided by State staff. State personnel working in the Food Stamp
Program, ADP groups, and State data centers were interviewed during the visit to each State.
Data gathered during the State visits included State responses to questions from various structured
interview guides and additional information requested by FCS for inclusion in the individual State
reports.
Another component of the study was the creation of a detailed report about each State and the
District of Columbia. Individual State reports provided data regarding State public assistance
participation, system functionality, cost justification for developing the public assistance system,
hardware and software platforms supporting the FSP system, performance characteristics of the
system at the time of the State visit, future changes anticipated in the configuration supporting
the program, and cost allocation procedures and practices used by the State to track and report
system development and operational costs. In addition, the project team reviewed the project
management staffing levels, participation in system planning and development, reasons for project
cost overruns and development schedule slippages, and benefits and drawbacks of the current
APD approval process during State visits and incorporated this information into State reports.
C. AREAS OF STUDY
The study has three main areas of concentration: Food Stamp Program operations; cost and cost
allocation; and systems planning, management, development, and ongoing support of the
automated system supporting FSP.
C.l Food Stamp Operations
The focus of our review of FSP operations was to determine the impact of the automated system
on the overall operations of FSP and the extent to which FSP staff participated in planning,
developing, and implementing the system as well as reviewing the ongoing performance of the
system.
This area was reviewed in several ways. A questionnaire sent to the State several weeks in
advance of the visit requested information about the State environment, historical caseloads and
error rates, impact of implementing specific regulatory changes, APD history, caseworker counts,
job descriptions and responsibilities, system transfer process, system performance issues, and
system functionality. Once at the State site, interviews were conducted with FSP operations staff
Volume I J/O/ Page III-2
to review their roles and participation levels in planning and implementing the automated system,
relationship with Federal agencies, and training and conversion approaches used to implement the
new system. State staff provided a demonstration of the system to enable the project team to
view system functionality and capability that would be experienced in a production environment.
Additional information was gathered regarding the State's claims collection data, administrative
costs, automation plans, cost/benefit reviews and results, strengths and weaknesses of the APD
process, and relationships with Federal agencies.
G2 Cost and Cost Allocation
The cost area was addressed through the use of two vehicles. A cost survey was sent to the State
several weeks before the scheduled site visit and requested information about the State's cost
allocation methodologies and FCS-approved cost allocation plans, cost pool descriptions, and
APD submission and approval history. During the site visit, actual APDs and correspondence
files were reviewed and interviews were conducted with State cost accounting staff to review
operational and development costs, as reported on SF-269s, and clarify any discrepancies that
were identified in reviewing documentation. The majority of the data reported in the individual
State reports was compiled based on the on-site documentation reviews and discussions with State
staff.
C.3 Systems
The State Automation Systems Study data collection effort focused on the activity of the internal
State systems staff and their roles and leve' of involvement in supporting the food stamp system.
The information was gathered through several vehicles. Two pre-visit questionnaires addressed
hardware and software configurations, staffing levels, technical capabilities of the State staff,
performance data, managerial insights into performance monitoring, planning techniques, and
future changes planned. The on-site interview addressed change control, roles played by
contractors, relationships with Federal agencies, and innovations and efficiencies built into the
automated system. A separate discussion with the State's project manager for the development
effort and/or the project management staff was conducted to review the approaches used to plan,
staff, develop, and implement the automated system. This included examining the roles and
responsibilities of user and field staff, presence of disaster recovery and security plans, and the
opinions of project management staff regarding the APD preparation and Federal review
processes.
C.4 Special Circumstances Encountered
Since the purpose of the study was to capture information regarding State automation processes
and the results of their endeavors, no effort was made to conduct an audit or verify that the
information provided was correct. Cost and performance information was accepted as accurate
and questioned only if conflicting information was found in other documentation. The
availability of documentation and correspondence files was very important in gathering useful
information, especially historical and cost data. Its absence directly impacted our ability to
prepare detailed State Reports. Some documents, for States in the initial stages of vendor or
contractor selections, were not available for review; however, these occurrences were infrequent.
Volume I /*j Page III-3
D. STUDY LIMITATIONS
In-depth reviews of the effectiveness and efficiency of each State's automated system were not
attempted as part of this study. The evaluation of the integrated components of a multi-agency
integrated public assistance system (i.e., a system supporting the FC ^-administered FSP, the
DHHS Agency for Children and Families (ACF)-administered AFDC Program, and the DHHS
Health Care Financing Administration (HCFA)-administered Medicaid Program) was not included
in this study due to the decision of the Department of Health and Human Services not to
participate in this effort.
Accuracy of the information captured was not audited or verified by the site visit teams. Answers
to the questionnaires and interviews were recorded as given and not questioned unless the
response was unclear or directly contradicted information gathered from other sources. When two
sources conflicted, we attempted to ascertain which information was more accurate and reported
it as our finding.
Despite our best efforts to capture all pertinent information, in every State, some portion of the
data to be collected was not available for a variety of reasons. For example, many States did not
perform post-implementation benefit reviews to determine what actual savings or improvements
had been achieved. In some situations where data was unavailable, projected analyses using this
data had to be altered or eliminated from the evaluation.
Volume I O.U Page III-4
IV. INDUSTRY TECHNOLOGICAL STANDARDS APPROPRIATE TO FOOD
STAMP PROGRAM REQUIREMENTS
Overall industry hardware, software, and development standards are basically the same across all
types of industry classifications. The standards are not written policies or procedures. They
consist of hardware configurations and software versions that are supported by the vendor
community as "current" and provide the newest capabilities and performance levels for hardware
and software systems.
FSP automation needs are not unique from other government agencies or private industry. FSP
requires a hardware environment that can be expanded to meet the needs of its growing
application base without major redesign of its programs and databases. Software must be capable
of providing improved functionality and supporting hardware capability enhancements.
Communication networks and protocols must follow the needs and design constraints of
interconnected agencies or organizations to facilitate the exchange of data in a timely and
effective fashion.
Software development within food stamp systems has been accomplished, primarily, through the
transfer of Family Assistance Management Information System (FAMIS)-certified systems from
other States. The primary benefit of transferring these systems would appear to be faster and less
expensive project implementations. The only comparable industry standard would be the use of
commercial-off-the-shelf (COTS) software packages to provide "standard" processing functions.
Since most States felt that the transfer process was preferable to "home-grown" internal system
development, this approach is somewhat different from industry standards of either COTS or
internally-developed software solutions.
Discussion of industry technological standards can be divided into five categories: hardware,
software, use of contractors, development standards, and the FSP need for hardware/software
currency. Each of these areas is described below.
A. HARDWARE
Hardware standards focus on several areas including: vendors, application growth, software
support, vendor support or maintenance, performance, telecommunications networks, and
intelligent workstations. Issues related to each area are presented below.
A.l Vendors
Current Environment
The vast majority of States are using mainframe-based systems with centralized files and
processing. Of the 51 entities (50 States and the District of Columbia). 41 are using IBM or
IBM-compatible (Amdahl and Hitachi) systems, five are using Unisys equipment, and four are
using Honeywell systems. California is not counted since it has no Statewide system in place.
Volume I Jl| PageIV-1
Findings
Each of the vendors provides a family of hardware configurations to enable a State to migrate
to more powerful systems as the workload increases. None of the States are using equipment
more than one generation removed from the current vendor product lines; this enables States to
take advantage of many of the most current technological features available. The use of hardware
provided by a vendor that provides a family of compatible hardware configurations with the
ability to support growth requirements characterizes the typical environment preferred by the
majority of centralized processing facilities in any industry.
Recom mendations
No specific areas of concern were noted in the State's use of hardware platforms. The
introduction of cost-effective distributed solutions discussed later in this chapter is another
hardware issue that should be thoroughly reviewed.
A.2 Application Growth
Current Environment
All of the vendors discussed in the hardware section provide system software and hardware
processing functions that enable the system supporting food stamps tt« migrate into more powerful
processing mainframes and peripherals (such as tapes, disks, printers and telecommunications
processors) equipment as the transaction volume increases.
Findings
Expansion capability is crucial in providing adequate processing capacity to meet unanticipated
caseload growth, as experienced in the FSP between 1989 and 1994. The only limitation on
growth occurs with applications that are using the most powerful processor in a given product
line, as is the case in Pennsylvania. This type of situation could result in the redesign of the
application to fit the processor limitation or decision to distribute some functionality to other
processors, such as minicomputers, file servers or desktop workstations.
Recommendations
Special attention should be given to those States whose hardware or software platforms are
beginning to reach the limits of the platforms ability to meet the workload requirements. In most
cases, the larger States, such as Pennsylvania and New York, with non-IBM platforms and older
systems are at risk of overrunning the system's ability to process the workload. The most logical
solution is to undertake a multi-year developmental effort to correct the problem. These
situations should be identified as quickly as possible and efforts should be undertaken to solidify
an action plan before the problems begin to appear.
/*-
Volume I X ^ Page IV-2
A.3 Software Support
Current Environment
All mainframe vendors provide full support for hardware and software systems, including
operating systems, language processors, system utilities, and functional software programs such
as IMS, DB2, ADABAS, CICS, and IDMS.
Findings
The operating systems being used are either the current version or the previous version of the
software and will be fully supported for years to come. For State systems, normal migrations to
current software versions or release levels usually are accomplished within three years of
availability and are not a concern.
Recommendations
No specific recommendations or concerns are noted in this area.
A.4 Vendor Maintenance
Current Environment
Since State food stamp systems are run from large-scale centralized data centers with vendor
support for telecommunications and local office equipment, there are no major deviations in
vendor maintenance support from accepted industry standards.
Findings
There appears to be adequate response time to resolve problems and sufficient technical
knowledge and corporate technical support staffs to help to create and maintain a stable
automation environment. No obvious issues or concerns were noted by the States.
Recommendations
No specific recommendations or concerns are noted in this area.
A.5 Performance
Current Environment
Normal expectations for system response times, batch turnaround times, and system functionality
apply to users of FSP systems. Those systems that process many functions in an on-line, real-time
environment are much more sensitive to overall response time, but do not require different
performance criteria than other on-line, client-oriented systems. Most of the food stamp systems
Volume I <If-*> Page IV-3
share a processing environment with other State systems, but tend to receive higher processing
priority than almost every other application except for the law enforcement systems.
Findings
Areas of difficulty and user concern center on the length of time required to perform the
eligibility determination/benefit calculation on those systems that perform the function while the
client is seated at the eligibility worker's desk. Problem were also found in typical bottlenecks
areas: telecommunications networks are overloaded, certain functions use a high percentage of
central processing computation time and require an inordinate amount of time and resources to
function, and channel and disk file contention can occur if care is not taken in data-set placement.
All systems reviewed provided for a method to determine eligibility and deliver coupons for
expedited food stamps within the regulatory guideline timeframes.
Recommendations
During acceptance testing, performance tests should be done to validate the system's ability to
provide reasonable response time for all functions under heavy volume simulations. These tests
will help determine how well the system can be expected to perform under heavy volumes.
Another solution would be to provide a secondary platform for processing system-intensive
functions, such as client servers or distributed processing capabilities at the worker's intelligent
workstation to free the mainframe for more file access/data manipulation activities.
A.6 Telecommunications Networks
Current Environment
All States are using standard protocols to tie local offices to the central computing site. Twenty-nine
States have Statewide backbone networks that have shared access by all State agencies.
Several States have implemented networks supporting voice, data, and video transmissions
through the backbone network and are continuing to expand their capabilities to include more
users. A number of States, including Alaska, Michigan, Arizona, and Missouri, are still using
4.8 KB circuits, especially in rural areas. Several States still use microwave transmissions to
augment land lines.
Findings
Telecommunications networks are one of the primary causes of poor systems performance across
industries. In support of the Food Stamp Program, most States are sharing the
telecommunications network with other State systems. Ten States indicated having response-time
problems that State staff considered to be of nrior significance.
Virtually no States are tracking response time to food stamp transactions at the local office
workstation. This type of monitoring has been replaced by more sophisticated network and
Volume I fit/ Page IV-4
central processor software and hardware monitors. It is difficult to determine how problematic
response- time performance is since no records are being kept at the local office. If a
performance problem is being caused by the network, mainframe and telecommunications
processor timings will not tell the technicians where the problem lies.
Recommcndation %
As part of systems design and planning, and again as part of the acceptance testing,
telecommunications network analyses should be performed. The analyses should cover how well
the network will perform at peak load conditions, but also to attempt to quantify at what volume
the network begins to degrade below acceptable performance levels. Knowing the transaction
volume level where performance will become unacceptable will help in network monitoring and
network upgrade planning.
Efforts should be undertaken to provide for workstation response monitoring. Without this data,
performance planning data is incomplete.
A.7 Use 01 Intelligent Workstations
Current Environment
Many States that implement personal computer (PC) workstations are still using the equipment
primarily as a terminal, not as a desktop computer. While a great deal of planning revolves
around decentralized processing, much of the development activity still occurs on a centralized
processor. Downsizing from central-site mainframes to minicomputers and/or microcomputers
has been a strong trend for the past several years. Expected benefits include faster and less costly
application development, less expensive hardware platforms, and more functionality and
performance for the end user. Whether these goals will be achieved remains open for review.
Findings
The use of distributed intelligence in either regional file servers or at the individual workstations
has not been used to any great extent within the States. Some use has been made of regional data
entry on minicomputers that can function even when the mainframe computer is not available,
but the only significant attempt to use distributed intelligence extensively is occurring in Merced
County, California. California's current development effort involves migrating a mainframe-based
system, NAPAS, rather than the Merced County system, into a Statewide system over the
next 8 to 10 years.
Recommendations
Distributed processing technology has progressed to the point where it should be given equal
consideration with mainframe-based systems when alternatives are reviewed. Reliability,
performance, and software support has reached a point where the approach should no longer be
considered high risk. Several States expressed interest in examining distributed intelligence
solutions. Several States who wanted to use PCs as their workstations encountered resistance
Volume I %<h~>* Page IV-5
because of the cost differential between PCs and terminals. Until recently, DHHS would only
reimburse the State for the terminal cost. Other States became discouraged enough to drop the
idea altogether and stay with the traditional dumb-terminal approach.
B. SOFTWARE
Software standards focus on two areas: software tool standards and development standards.
B.1 Software Tool Standards
Current Environment
Only one State was found to be using an outdated operating system to support the food stamp
application. Of the 51 entities (only 50 of which have Statewide systems), 40 are using IBM's
MVS/ESA (32) or MVS/XA (8). Rhode Island is using DOS/VSE under VM. The other nine
States are using either EXEC 1100 (Unisys) or GCOS8 (Honeywell) operating system software
to drive their hardware. With the exception of the DOS/VSE software, all States are using
mainstream vendor software and relatively current releases of the operating systems to place them
well within accepted industry standards.
The majority of States also used vendor-supplied transaction processing packages such as IBM's
CICS, Honeywell's TP8, and Unisys' CMS 1100. CICS and CMS 1100 are the vendors most
current products to handle transaction processing; TP8, although still supported by the vendor,
eventually will be replaced by DMIVTP, which is being used in New Jersey.
Database support has a wider assortment of products with several of the more popular products
being more than 20 years old. IBM's IMS and Software AG's ADABAS, which are used in 34
of the 50 States' database management systems (DBMS), have been available since the late 1960s
and early 1970s. Comparable offerings from Unisys and Honeywell are also dated systems.
Database software technology does not change as quickly as its hardware counterparts, and these
database products still are considered to be part of the industry standard for database systems.
Newer products such as IBM's DB2 are beginning to make small inroads, but most changes will
come very slowly and be tied to a State's desire to migrate all of its database applications to a
new platform over an extended period of time as major revisions or rewrites of applications
become necessary.
Findings
States using systems with common mainframes and transaction processing, operating system, and
database software are most likely to be compatible with each other. Tables B-8, B-9, and B-10
in Appendix B of Volume II indicate the type of mainframe, software, and communications
network supporting ^ach State's system. This finding applies to IBM, Unisys, and Honeywell
systems. Rhode Island's system is not compatible with other State systems because it alone uses
the DOS/VSE operating system. The Honeywell and Unisys systems are not compatible with
IBM platforms or each other. For purposes of backup/disaster recovery discussions, these
differences are of little consequence since those States with workable plans are not using a
Volume I Aj tr Page IV-6
neighboring or compatible State, but more likely another agency data center within the State or
a commercial disaster-recovery vendor
The process of establishing a process to manage changes or modifications to the production
environment has been labeled change control. Of the 50 States and the District of Columbia,
only 27 had any form of coordinated process to review and plan for implementation of
modifications to the software environment Since production systems are most vulnerable when
changes are made, it is prudent to ensure that all concerned parties be appraised of and review
the potential impact of any and all changes to the environment. Of the 27 that have some form
of change process, several States io not include ail types of changes such as hardware, system
software, application software, facilities, network, or environment in the review process.
Recommendations
The use of current and standard system software products positions the States to be able to
migrate their systems to new platforms or backup processing centers without undue effort.
While any major redesign is a massive undertaking, beginning from a standard platform makes
it much more conducive to a controlled and well-executed effort.
The change control area is an important aspect of maintaining application stability which should
be strongly encouraged by FCS as an integral part of the ongoing operational support of the food
stamp system and be a factor in the review of APD funding requests.
B.2 Development Standards
Current Environment
The process of engineering automated applications still depends on performing a comprehensive
and accurate requirements analysis and creating reliable and efficient program code to instruct
the hardware and manage the data. The use of Standard Development Life Cycle (SDLC)
methodologies has provided a blueprint from which any organization can develop efficient
application code by following specific steps and procedures. In addition, new development tools
and techniques such as Joint Application Development (JAD). CASE, and Data Dictionaries have
been developed to assist in the design and development of new applications.
These processes have been developed to enable an organization to approach the project process
with consistency and to help ensure a timely and cost-effective project. In reality, most major
projects now span a number of years from initial conception to full implementation. During this
time, a variety of factors impact the original design and scope of the project, resulting in major
changes and added cost to the initial estimates. Virtually all food stamp system projects have
been affected by these types of internal and external influences and have exceeded initial
projected cost estimates. The use or lack of an SDLC to plan and implement a food stamp
system cannot be measured in the overall project performance because of the myriad of
overlapping factors that impact these types of complicated, lengthy projects. Most States can be
considered to be within the industry norms for planning and implementing systems.
n Volume I (K \ Page IV-7
Findings
Only 14 States were found to be using a standard, accepted methodology for the development of
the food stamp systems. More than half of the States (30) are using some form of SDLC
methodology to design and develop systems. Even among those States that did not claim to be
using a formal SDLC process, most used a standardized form of application design and
development to implement new projects. Eight States did not provide ny information concerning
their use of SDLC.
Nearly every State was using some form of programming aid in the development or support of
the application Data dictionaries, software library management tools, and CASE tools are the
most frequently referenced products. The enhanced productivity that can be achieved through
the use of these types of tools makes their acquisition and use much more prevalent and useful
to the application developers.
Virtually no State system can be considered to have been designed to meet the Federal standards
for interoperability or transportability. Systems are still being designed for a vendor's hardware
product, coding, and protocols rather than for mobility among other vendors' products. There
is some portability built into those State systems that have developed workable disaster recovery
procedures so that the system can be moved to a backup data center if a serious interruption of
service is encountered; however, many States have only a sketchy outline of disaster recovery
plans and would be unable to move their systems to an alternate site without a major undertaking
and extensive amounts of time and technical resources.
Recommendations
Very little emphasis is placed on the technical age and developmental basis of State systems
reviewed as potential transfer candidates for a new food stamp system. Most of the criteria used
reflects hardware platforms (vendors), software products (DBMS), caseloads, and othei State
characteristics. The vast majority of States are still looking at mainframe-based systems even
though distributed and workstation-based intelligence has become more accepted and more cost-effective
in ;ecent years. This results in technically old architectures being the foundation for
new systems that will reach production status in the mid-to-late 1990s, when newer technologies
could be functionally superior and tremendously more cost efficient. More emphasis should be
given to exploring the newer products and approaches and using some of the more promising
solutions to gain valuable insights and experience with the technologies.
Volume I 4j Page IV-8
C. CONTRACTORS
Current Environment
Approximately halt" the States transferred existing systems as the basis for the development of
their food stamp system, and the vast majority used an external contractor to provide some level
of support during the planning, design, testing, conversion, and implementation of the system.
Reasons for using contractors ranged from lack of internal staff resources or expertise to
expectations that experienced contractors would help ensure a successful project. States that have
developed their own systems do not use contractors to any great extent and tend to fall into one
of two categories: 1) they possess a strong internal management information system (MIS)
department with the resources and expertise to design and develop a large, complex system; or,
2) States with older systems (more than 10 years old) who developed smaller, less complicated
projects before there were many comparable systems to evaluate for possible transfer. Many of
these States are beginning to evaluate the benefits of new systems and almost all are expected to
use a contractor.
Findings
Contractor involvement usually is at the highest level during the general and detail design stages
and begins to drop off during the training and conversion phases of a project. State staff play
a more active role during the planning and APD approval stages, final conversion, and full
Statewide implementation.
Once full implementation is achieved, contractor staff frequently remain to provide warranty
support for the system and work with State staff as they begin to assume responsibility for system
support. Many States do not have adequate staff to assume support of the full system due to
hiring freezes and reductions in force that have occurred during recent years. It is expected that
contractor support will be necessary for the foreseeable future to provide adequate system support
in the face of the current staffing restrictions. The difficulty that States face with using ongoing
contractor support is that over time it will become increasingly more difficult to maintain any
level of expertise among State staff in developing state-of-the-art systems since the presence of
contractors will severely limit the opportunities for State staff to gain any experience with newer
techniques and technologies. It would be more practical to hire contractors to support older
systems and release the internal State MIS staff to learn and support the newer applications by
working directly with the development team during design and implementation. This approach
would enable the State to maintain the desired level of staff and keep its own staff technically
current and motivated to remain in State service.
The majority of States are retaining the responsibility for preparing APDs. A few of the smaller
States have delegated the preparation process to contractors with APD experience because they
do not have the time, expertise, or motivation to undertake what is perceived to be a complex,
lengthy, and frustrating process. This is somewhat consistent with the experience in many
industries, where the function of supporting the data-processing environment is totally controlled
within the organization with little, if any. contractor support for planning or acquisition activities.
Volume A Page IV-9
Many States are using contractors to monitor the performance of contractors responsible for
creating new food stamp systems and perform quality control tasks on the products and processes
being delivered. This is not a standard data-processing practice within other industries or
organizations. Most projects are evaluated on their time and cost performance against plan, the
functionality and performance delivered to the ultimate user, and the efficiency of the system's
utilization of computer resources. In the case of food stamp systems, contractors are used to
monitor the progress of the project during development, but not to measure the ultimate result,
the system itself.
Recommendations
State use of contractors should continue to be determined by the needs of the individual State.
States should be encouraged to use their own staff to work on the new development project with
contractor staff to gain valuable insights into the design and development strategy of the system.
With this knowledge, the State will be in a better position to direct the support and enhancements
of the new system without having to rely on the external contractor for this type of suppo.t.
D. PROJECT MANAGEMENT STANDARDS
Current Environment
The project management standard in any organization requires that the management team have
three major components if it is to be successful:
Strong, experienced project manager
• Representation from all pertinent departments within the organization
• Active support from senior management
The majority of States appear to be following accepted staffing and management principles in
conducting food stamp system development projects.
Findings
The projects currently underway or recently completed have had active user participation in all
phases, and in many cases have had user leadership in many of the non-technical tasks, such as
testing, screen layout design, and conversion planning. Executive oversight committees are now
an integral part of the project process and take an active role in helping resolve conflicts that
arise, which can subvert technical progress by placing political or administrative roadblocks in
the project's path, and in formulating new policy to meet the needs of today's integrated systems.
User project involvement has led, in many cases, to the formation of liaison groups between the
user and MIS areas to facilitate the implementation of regulatory and functional enhancements
to the system as change occurs after full implementation. These approaches (i.e., active user
involvement, executive oversight group, and liaison groups) not only improve the MIS/user
interaction, but are positioned to improve the requirements definition phase of future projects.
Recommendations
Volume I 30 Page IV-10
FCS should continue to encourage States to involve all pertinent areas in the planning, design,
development, implementation, training, and conversion aspects of system development projects.
Total user involvement, along with State systems staff and external contractor support, can help
ensure a thoroughly planned, designed and executed system, one that will be fully supported by
management and staff when implemented.
E. BALANCE BETWEEN FSP NEEDS AND STATE-OF-THE-ART DATA
PROCESSING SYSTEMS
Current Environment
FSP has standard functional needs from its automated systems; these include:
• On-line processing of high volume transaction systems
• Management of customer files
• Inquiry capability into internal and external files
• Reliable, efficient processing platforms
Findings
Hardware and software platforms are changing with increasing frequency, but the basic processing
and storage/retrieval of data remains fairly constant. FSP is not required to implement new,
leading edge technology to meet its functional requirements, so States can take advantage of
proven, cost-effective hardware products and established software to meet all FSP functional
needs. Even new directions, such as electronic benefits transfer (EBT), use technology that has
been available for more than 10 years; nevertheless, EBT provides exceptional improvements in
the ability to deliver FSP benefits to clients.
Recommendations
Distributed intelligence technology is becoming more cost-effective and easier to implement with
each passing year and holds tremendous potential for use in the food stamp operation. Its
potential future uses may provide greater local office capability and faster client service. Since
all the logic and functional capabilities will reside at the local office, all client services, including
applicant registration, eligibility determination, benefit calculation, and benefit issuance, could
be performed while the client is being processed and approved. This could eliminate return trips
for the client and improve the overall delivery of benefits.
FCS may want to use more demonstration projects to determine the possible benefits of newer
technologies. Experience with products such as imaging or distributed food stamp systems sooner
in the product's life cycle may provide valuable insights into how a specific technology might
be used to control or reduce costs, or improve service to public assistance clients.
Volume I D I Page IV-1
V. IMPACT OF CURRENT AND FUTURE SERVICE DEMANDS ON FOOD STAMP
AUTOMATION REQUIREMENTS
The goal for automated support of FSP is to provide accurate eligibility determination and timely
benefit issuance to clients receiving food stamp assistance. Automation provides an effective
vehicle to process the myriad of requests for information pertaining to the eligibility, issuance,
and reconciliation of food stamp benefits. By designing systems that utilize the most cost-effective
and useful automation functionality for their requirements, a State could provide an
efficient and beneficial automated solution for food stamp processing requirements. To keep
current with improvements in techniques and technologies, an organization must review present
and future demands to ensure that the public assistance application is providing the best possible
support.
A. CURRENT SERVICE DEMANDS
Current Environment
During the past four years, virtually every State experienced unexpected growth in the number
of clients applying for and receiving Federal assistance. During the same period, resources
available to support this increasing demand were being reduced as a result of a strong
recessionary trend. States were forced to meet the demand with their existing automated systems,
a shrinking work force, and, in some cases, additional problems and confusion related to difficult
conversions to new systems.
The current level of new system design and implementation continues to be significant. States
still face high levels of demand for public assistance benefits, error rates have not always been
reduced as anticipated with the implementation of new systems, and there is increasing pressure
from Federal agencies to find additional ways to reduce costs and improve the effectiveness and
efficiency of benefit authorization, issuance, and reconciliation.
Findings
States still are attempting to create automated tools that will enable them to treat public assistance
clients with dignity while providing fast and accurate eligibility determination and benefit
calculation functions. To achieve these goals, States continue to need capabilities to capture
client information quickly by eliminating multiple-processing steps, such as manually entering
data from client-prepared paper applications. States also must be able to interface with every
available information file to confirm the accuracy of client information, especially income and
asset data, and issue the proper benefits as soon as possible.
State workforce staffing levels are not keeping pace with the growth in demand for benefits.
Caseloads per worker are increasing in virtually every State. For example, West Virginia
averages more than 500 cases per worker, with one county having workers handle over 800 cases
each.
Volume I J2/<>S~l Page V-l
Regulatory changes issued by both Federal and State governments continue to place heavy
burdens on the States to keep their systems current. In many States, support for multiple public
assistance programs has been integrated into a common system. Changes to any program will
have a potential impact on every assistance program supported by the system and tax the
capability of limited State MIS staff to support all application maintenance and enhancement
requirements. In addition, the more changes introduced into a production environment, the higher
the level of unscheduled service interruptions. Systems with integrated Medicaid support appear
to have experienced a high L-vel of regulatory changes over the past five years; these changes had
a direct impact on States' abilities to meet all of their regulatory change implementation
timeframes.
Recommendations
State systems should continue to eliminate duplicate steps and enable the automated system to
perform as many validation and edit checks as possible. Interactive interviewing will reduce
duplicate data capture steps; on-line verification will reduce the time and effort to perform batch
or manual lookups. These and other automated solutions can help reduce non-productive
administrative burdens of the eligibility worker and allow more time for client interaction to
facilitate the determination and issuance of benefits and allow the worker to deal with more cases.
B. FUTURE SERVICE DEMANDS
Current Environment
Increasing pressure is being applied to reform the current welfare system. The emphasis
continues to be on providing cost-conscious and effective support for public assistance recipients,
but renewed attention is focused on welfare reforms that will require tracking more timely and
pertinent information about recipients. As the dynamics of the economic health of the country
and the impact of changes in Federal administrations continue to interact, change - sometimes
dramatic change -- will continue to be required of today's public assistance systems.
Findings
In the future. States will face the need to gain faster access to more information to determine
client eligibility. Today's systems still rely on batch data updates that are processed during
overnight batch processing to validate client-supplied application information.
As more functionality is provided by the automated system and fewer functions are performed
manually by caseworkers, the need for high levels of system reliability and working disaster-recovery
plans becomes more critical. In today's environment, many States have the ability to
manually process client assistance requests without the automated system. They simply capture
the information manually and update the system when it becomes available. If an extended
outage is experienced, manual issuance processes can be implemented without too much
difficulty. In the future, capabilities, such as EBT, will result in the elimination of the need for
staff to perform manual issuance, and it will become much more difficult for a State to revert to
manual methods. Similarly, as workers become more dependent on the system to perform
Volume I 32i33 Pa8e v_2
analysis and calculations, their ability to perform any of the necessary steps without the system
will be reduced.
Most State systems have been able to achieve and maintain high levels of reliability due primarily
to very reliable hardware, software, and telecommunications environments: however, any
environment that experiences regular and extensive changes is much more vulnerable to an
outage. Since the level of system change is expected to remain constant or increase, risk to the
reliability of the processing environment will be high. Dependence on sound policy and
procedures to manage change will become more important as the degree of automation and
integration of compatible systems increases. Many States have begun to implement change
control processes; however, other States should be encouraged to create and staff the process.
Although disaster-recovery processes are mandatory, very few States have any semblance of a
well-planned and tested process. Reviewing some of the events of the past two years reinforces
the criticality of having a workable disaster-recovery plan. The Los Angeles earthquake,
extensive flooding in the Midwest, and Hurricane Andrew in Florida are clear examples of how
quickly a State's processing resource can be put at risk. At the same time, the need for public
assistance support increases dramatically under disaster conditions.
Recommendations
To support future requirements, more real-time, on-line interfaces to Federal, State, and private-sector
files will need to be developed. These interfaces will be needed to access and review
client financial data to make more timely and accurate calculations of a client's eligibility and
benefit allotment amounts. To support this requirement. States will need more sophisticated
interface programming, improved access and file security, and larger, more expensive
telecommunications networks.
There are pending recommendations that the amount of time a person can receive benefits be
limited to two years. If such a requirement is added to the current regulations, much more
extensive client tracking procedures and processes will need to be incorporated into many of the
current State systems.
Future systems must have the ability to be transported to an alternate processing facility in the
case of elongated emergency shutdown of the processing complex. Development of reasonably
transportable systems is necessary to be able to achieve the type of backup support the future
systems functions.
C. IMPACT OF DEMANDS ON FOOD STAMP PROGRAM SYSTEMS
Current Environment
Hardware and software components that can support the future levels of performance and
functional capabilities for FSP are not a significant concern since there are not any foreseeable,
unique requirements.
Volume I 2/f Page V-3
Findings
In larger States, it might be necessary to segment the system into several subsystems to provide
acceptable levels of hardware and/or software performance. For example, California may choose
to create several regional centers for Los Angeles and other high-population centers to support
high-transaction volumes and lower telecommunications costs to a single central-processing
complex.
Telecommunications networks are moving towards a common. Statewide network supporting all
transmission requirements of State agencies.
Recommendations
Regional client files could be maintained locally and all local processing could be performed
without involving a central State facility. A centralized facility could be used to consolidate all
regional-processing files, handle client transactions for those who are applying for services outside
of their normal regional area, and provide updated regional files to each processing center after
the consolidated lightly processing is completed at the central site.
The same concept could be used to create distributed processing nodes throughout a State. Each
node could have the capability of storing and processing data from clients within their
jurisdiction. Full functional capability would be provided at each node for applicant registration,
eligibility determination, benefit calculation, notices, alerts, and issuance. Interconnection among
nodes would be required to support clients who require assistance when they are away from their
normal processing area. Depending on how the system was designed, a centralized processing
site may or may not be needed to enable every processing node to communicate and access
information from the other nodes.
Elimination of stand-alone, dedicated networks should help reduce the overall telecommunications
costs for FSP and provide enhanced levels of performance and capability. Transfers of large
client files will make the use of distributed intelligence more feasible and connections to external
agencies, such as the Internal Revenue Service (IRS) and Social Security Administration (SSA),
for inquiries and confirmation of client information, more effective.
Intelligent workstations, in conjunction with distributed processing nodes and/or client servers,
could be used to provide enhanced processing capability at the local office, reduce
telecommunication costs, and improve functionality. Interactive client registration, eligibility
determination, benefit calculations, notices and alerts could be generated and supported locally.
Control and maintenance of policies and regulations could be performed centrally and
downloaded to the workstations to provide current and accurate State and Federal regulations.
Programming changes also could be developed and tested centrally and downloaded to each
workstation as necessary. Bypass processing could be provided at another node or at a central
site to support those local areas impacted by an interruption of service.
Volume I ij. ff Page V-4
D. DEVELOPMENTAL DIRECTIONS TO MEET CHANGES
Current Environment
States are using standard development processes for planning, designing, and implementing large,
complex centralized systems. The use of proven system development life cycle methodologies
has been established for many years, and all States should be strongly encouraged to use the
accepted industry standards as a regular part of all development projects.
Findings
Today's systems development solutions for public assistance processing are still geared to
centralized, mainframe-based, unintelligent terminal systems. Their creation is costly and time
consuming; by the time the effort has been completed, the original needs of the programmatic
area have changed. As new technologies emerge and become more cost effective. States should
begin to assess how the new technology may be able to support the needs of the Food Stamp
Program. For the most part, those types of assessments are not being undertaken today.
Recommendations
Architectures incorporating distributed system intelligence, including client-server,
regionalized/stand-alone processing sites, or decentralized processing nodes as part of a
centralized system approach, are potential alternatives to centralized mainframe-based solutions
and should be considered by a State examining its options for meeting public assistance
automation requirements. With distributed approaches, the capability of the hardware and
software is comparable to mainframe solutions. Tele- communications networks can be
configured to handle transmission of large data files without crippling the throughput for extended
periods of time, and price/performance capabilities of distributed intelligence solutions are
becoming more competitive with large mainframe alternatives.
There are several features that, if included in new systems, will enable the caseworker to handle
more cases with improved efficiency. These features include the use of system-generated alerts
and notices, follow-up notification to caseworkers and supervisors, electronic issuance and
reconciliation, on-line policy manuals, and client data validation and verification by means of on-line,
real-time inquiries to pertinent databases throughout the country.
Creation of technical and financial checkpoints will help to assess the progress being made
against the project plan. By being able to track the project status, slippages in the project
schedule or deliverables, and cost overruns, the impact of any necessary adjustments can be
evaluated more quickly. Problem areas can be identified and corrective actions implemented
sooner.
The use of developmental and planning tools also has been an important asset in improving
overall project and staff efficiency. Standardized use of these types of tools should be part of
a project* s documentation to enable other States to realize the same benefits achieved by the
originator during the implementation cycle. FCS should encourage the use of standard products
Volume I <?, / Page V-5
%
to ensure the continuity of such endeavors. The use of customized software tools only increases
the development costs and inhibits the transfer of experience to other States.
For each new State system, development staff should evaluate the strengths and weaknesses of
all possible technical alternatives and determine which approach best meets the needs of that
particular State. The process of transferring existing systems as the basis for a State's new food
stamp/assistance system may continue to be the preferred solution for many States; however,
other alternatives also exist.
A system transfer provides a starting point from which modifications can be made, even if the
vast majority of the application is changed. Another alternative may be to subsidize the creation
of an application framework that supports the core functionality needed by every Federal system.
The core product would be used as the basis for supporting all Federal processing requirements
and the State could then customize the system, at its cost, to meet its specific requirements. The
need for each State to investigate and evaluate transfer candidates would be eliminated, and
regulatory updates and core enhancements could be provided as regular new releases of the core
system, which would greatly reduce the time and effort required for each State to plan and
implement every change. Other potential benefits would include faster development and
implementation time, lower development costs, less dependence on external contractors to provide
technical and manpower resources, and more effective review of the technical and monetary
impact of making regulatory changes to systems.
Volume I ^7 Page V-6 37
VI. RECOMMENDED GUIDELINES FOR FCS
Volume II of this report addresses the objectives of the State Automation Systems Study. One
of the study requirements was to recommend guidelines to FCS for use in evaluating State
systems, APDs, and technology transfer analyses. The following sections present a summary
view of the findings of Volume II regarding these three areas.
A. PROPOSED STANDARDS FOR STATE SYSTEMS
Current Environment
Public assistance systems exist in the same form as they did 20 years ago. The vast majority of
systems use a mainframe-based, centralized approach with terminal access to database files that
are updated through overnight batch runs. Functionally, the systems allow for some form of
basic activity that can be made more sophisticated based on the specific needs of the State. Basic
functions supported include: client registration, eligibility determination, benefit calculation, and
notice generation. Additional features that may or may not be included in the same system are
issuance, reconciliation, and claims collections.
The majority of the installed or planned systems are run on IBM or IBM-compatible mainframes
under the MVS/XA or ESA operating systems and use one of several industry standard databases
(i.e., ADABAS, IMS, or NATURAL). The remaining systems are on either Unisys or Honeywell
platforms.
Problems Identified
During State visits, the project team did not observe any specific problems with the functionality
of the systems. Some of the older systems no longer meet all FCS requirements, but most States
are in the process of replacing these systems. Every State had its own specific method and
reasons for designing the format and functionality of their operational or planned system. The
activities supported by each system are driven by the needs of the Federal Food Stamp Program
and do not allow for major deviations; however, a number of areas where improvements could
be made were discovered:
• Registration - Some States have multiple steps during which client registration
information is captured more than once. Multiple handling steps are inefficient and create
the potential for data entry or interpretation errors. In some States, clients are required
to go to multiple locations to apply for individual Federal assistance programs, even when
a single automated system provides support for many of the Federal programs.
• Eligibility Determination - The processes of checking the validity of the client's
registration information and determining if additional assets exist that have not been
reported by the client are still being determined by manual or batch processing, despite
the fact that nearly all of the pertinent information is available through on-line access.
The current processes create delays in eligibility determination, allow decisions to be
made using out-of-date information, and do not appear to add any tangible benefits or
Volume I % V Page VI-1
reasonable safeguards to the eligibility determination process. Since data matched may
be several weeks or months old, based on the method and frequency of acquisition of data
from other agencies' files, delays and inaccuracies are a constant problem in the current
computer-matching process.
• Issuance - In many States, the food stamp issuance function is separate from the
eligibility determination/benefit calculation process and is handled outside of the main
public assistance system. Information from the benefit calculation process is fed to the
issuance process, and issuance data is returned to the public assistance system for
reconciliation.
• System Platforms - The majority of the current and planned systems are designed for the
historical high-volume, database-driven configuration on a large, centralized mainframe.
Very little consideration appears to have been given to other platforms that provide
excellent and cost-effective solutions to other applications today - client-server and
personal computer/local area network (LAN) configurations. While a number of States
have distributed nodes to enhance data entry or provide some semblance of ongoing
service during mainframe outages, only a few States have done any work on using
distributed databases tied to a centralized State network to handle food stamp processing.
Alternative Solutions
While it is impractical to impose strict functional requirements on every State system, there are
practical guidelines that FCS can propose and support that wi!! enable the States to more
effectively design and support these types of systems.
Data handling should be minimized in any system design. If possible, data should be handled
or entered only once. Information that has been electronically captured should never be re-keyed.
Use key client information (e.g., name, Social Security number, address, data of birth, etc.) to
build a registration form electronically and perform duplicate participation checks and begin
eligibility determination at the same time. By using on-line inquires and look-ups, much of the
current manual processing can be performed more quickly and accurately by the computer.
Review and clarification can be performed during the client interview.
Computer matching only should be performed on those data elements where it can be cost-justified.
The savings can be compared against the cost of performing the matching procedure
to determine if the process saves more than it costs. If a cost comparison cannot be made and
it does not appear that a specific match process is finding a reasonable number of discrepancies,
the process should be eliminated.
More emphasis needs to be placed on evaluating new technological approaches that may be
beneficial to both FCS and the States. The use of client-server technology, intelligent
workstations, and distributed processors have been ignored, for the most part, when evaluating
new system solutions during the past few years.
Volume 1 <rq Page VI-2 W
Recommended Guidelines
This section provides FCS with functional and platform-related guidelines for State systems.
Functional
FCS should create a Federal/State committee to review the standard features to be included in
every public assistance system. This group will review recommendations from subgroups formed
in each FCS region to better represent the specific needs of every State in the particular region.
The information supplied by the subgroups will include recommendations about which aspects
of client registration, eligibility determination, benefit calculation, notice generation, issuance,
reconciliation, and collections should be automated and to what extent the automation level
should reach (i.e., on-line capture of client registration information versus interactive
interviewing).
The Federal/State committee will develop more specific guidelines addressing the minimal and
reimbursable aspects of automated systems for future systems. States tha wish to include
capabilities and features that exceed the Federal guidelines should be required to exclude their
costs from APD requests for Federal financial participation and include those expenses in the
State's portion of the development costs. This would remove the need for FCS to review and
negotiate each State's requirements definition to determine the hows and whys of each design,
and reduce the Federal financial participation costs.
Platforms
FCS should encourage the States to evaluate all types of system platforms for future systems.
Using existing FCS Information Resources Management (IRM) resources, FCS should provide
an overview of what capabilities and limitations exist in the distributed environment as a basis
for new State analyses. Since distributed solutions available today are limited, extraordinary
efforts may be needed to document the potential and risks associated with this type of alternative
solution. FCS should be prepared to assist States in making this evaluation until there are
alternative models from which to choose, as u the case in the system transfer process.
B. APPROVING APD REQUESTS
Current Environment
Based on the FCS 901 Handbook issued in April 1992, the process to request approval and
funding for an automated system supporting the Food Stamp Program entails:
The State creates a Planning APD (PAPD), a reimbursable cost based on a Federally-approved
PAPD and cost allocation plan, that addresses the justification for the system,
a general functional design, estimated planning cost, development cost, and operational
cost of the final system as well as the cost allocation methodology and cost allocation plan
for the project and a preliminary cost/benefit analysis.
Volume I Uf\ Page VI-3
ft
• FCS reviews the plan and requests clarification and/or changes.
• Once FCS approves the PAPD. the State is allowed to begin the planning process and is
eligible for Federal financial participation based on the approved cost allocation plan for
the project. Any request for proposal (RFP) to be used to obtain contractor assistance also
must be submitted to FCS for approval before being let for competitive bids.
• An Implementation APD (IAPD) is one result of the planning effort. The IAPD addresses
the specifics of the system's functionality, hardware/software platforms considerations,
development timeframe estimates, cost and cost allocation plans, overall development and
operational costs, and cost/benefit analysis.
• The appropriate FCS regional office reviews the IAPD. requests clarifications or changes,
and responds to the State within 60 days. If the requested amount is less than $1 million
for the entire project, the RO can make the decision to approve and notify the State of its
findings. If the request exceeds $1 million, the RO summarizes the IAPD and sends the
summary to FCS headquarters for the Executive Oversight Committee's review and
concurrence. Headquarters staff have 30 additional days to respond to the request.
• Once the IAPD is approved, the State can begin implementation. FCS oversees the
development process and deals with any issues that arise during the development cycle.
Each year the State produces an APD Update (APDU) to address what has been
accomplished and present any changes to the original plan. Any significant design
changes and requests for additional funding are requested through an APDU.
• When the system is completed, FCS conducts a formal system review to ensure that all
functions planned are present and performing properly. [Note: Due to limited personnel,
FCS no longer conducts post-implementation reviews. Upon receipt of notification that
the system has been fully implemented, FCS closes the project as completed.]
Problems Identified
For the most part, both the States and we feel that the APD process is necessary and beneficial.
The structure requires States to plan and document their activities and report on their progress.
Specific aspects of the process, however, generate some concerns among States:
• RFP reviews - Nearly every State has a Purchasing Department where contracts are
negotiated. The need to have FCS also review the contract for content is redundant for
those States and creates delays in the review and approval process. If the only FCS issue
is to ensure that the RFP allows open and free competition, review could be limited to the
section that contains the work specifications (Statement of Work) to ensure that no
specific product or vendor has an unfair advantage. Approval of this limited scope should
facilitate quicker approval of State RFPs. Those States without an adequate internal RFP
creation and review process could still send the full RFP to FCS for review and
comments. It would add some time to the approval process, but would help ensure the
development of a thorough and acceptable RFP.
Volume I W// / Page VI-4
• Cost allocation plans - Guidelines for the creation of cost allocation plans do not enable
the States to adequately address FCS' allocation concerns. The content and format,
although generally well-documented, usually do not meet with FCS approval on the first
submission. Part of the problem can be tied to having multiple federal agencies review
a single cost allocation plan. Each agency appears to have unique matching rates,
different acceptable cost allocation methodologies, and separate ways of calculating the
agencies* appropriate portion of the development cost. The States' biggest concern with
the process is lack of understanding and guidance from FCS regarding its view of cost
allocation. Approval of cost allocation plans appears to create the most disagreement and
the longest delays in the APD •'oproval process.
• Lack of consistency and contradictory requests from FCS and DHHS in their
respective reviews of APD requests - The States view their role as having to act as
intermediaries between the two Federal agencies to reconcile the differences in the APD
to obtain Federal funding approval from both groups. In some cases, delays exceeding
one year have occurred in attempting to resolve differences, which usually related to CAP
issues, between the agencies.
Delays in gaining APD approvals - Nearly every State felt the process took a great deal
longer than the 60 to 90 days specified in the APD Handbook. In several States, staff
thought that the 60-day window pertained to the amount of time within which the RO was
required to send a letter to the State claiming receipt of the APD and indicating it was
under review. In most cases, the APD approval process appears to take from four to eight
months for review, clarifications, and approval.
Alternative Solutions
The current process is well conceived and effective. Its difficulties are tied to the lack of
adequate staff to thoroughly absorb and understand a detailed and voluminous document (APD)
within the 60-day timeframe.
Witn an integrated system, FCS and DHHS review the same document concurrently and arrive
at their separate conclusions, usually without consulting each other. This creates a dual
environment in which the State must operate. The logical solution is to have both FCS and
DHHS jointly review the APD and prepare a consolidated list of items for clarification or
modification instead of two separate processes. While this addresses a difficult coordination issue
between two distinct Federal agencies, the agencies are given the same APD and have similar
review processes. Although a coordinated review process would require a much closer working
rt'ationship between the agencies, it could pave the way for additional improvements in the
oversight process that would benefit both agencies.
Recommended Guidelines
To improve the APD approval process, the following guidelines should be adopted.
• Develop a series of RFP clauses to protect the Federal agency's participation in the
project - FCS review and approval of the RFP would be done to ensure that the required
Volume I \j%_ Page VI-5
text was included. FCS would review the entire RFP document only for those States that
specifically request it.
• Allow for more RO trips to States during the planning and creation of the APD -
This would allow the RO staff to be more familiar with the logic and plans for the
development effort and more effective in their review of the formal document.
• Create a workable cost allocation process among FCS, DHHS and the States - This
could eliminate the confusion and delays that have occurred in with most APD
submissions during the past few years and resolve States' biggest complaint, the lack of
consistency and guidance from the Federal agencies regarding cost allocation plans.
• Institute a requirement for all States and FCS ROs to maintain cost records of all
project activities for up to 10 years after the completion of the project - If historical
cost information is of any importance in the review of project performance and future
Federal assistance requests, formal requirements for retention of cost data is necessary.
For many States with older systems, and even some of the systems under development,
very little cost information was maintained by the States and the ROs since there are no
requirements to maintain the documentation. At a minimum, the original cost estimates,
supporting documentation, all revisions, and all actual costs incurred should be
maintained, along with pertinent documentation and correspondence. The RO should be
responsible for ensuring that the documentation is complete and accurate.
• Conduct post-implementation and cost/benefit reviews for completed systems -
Currently, there is no requirement for FCS to conduct a post-implementation review. We
recommend the practice be re-instituted and expanded to require a formal cost/benefit
review to document actual cost savings/losses experienced. If each system must be
justified at its inception, there must be a requirement to document the results achieved or
the process is worthless. In addition, a post-implementation review should enable FCS
to gain valuable information regarding the positive and negative aspects of a State's plan
for use by future development efforts.
C. TECHNOLOGY TRANSFER ANALYSES
State/Contractor Views of Technology Transfers
As discussed in Chapter IV of Volume II, most States felt the transfer process was a more
practical solution than beginning the development process from its inception each time. More
than half the States did transfer a system, and many States that did not execute a transfer had
developed a system before there were candidate systems from other States to transfer. Many
States do not have large system staffs to undertake major development projects and depend on
external contractors to augment their in-house personnel. While this encourages future system
transfers, it does not address some of the shortcomings of the transfer process.
From our perspective, transfers provide a proven foundation from which a new system can be
created; however, system transfers do not appear to provide any tangible cost or time advantages
Volume I JJIL Page VI-6
compared to new development. This does not mean, however, that transfers are not cost-effective.
The major benefits of transferring are:
• States begin with a process and set functionality instead of having to develop and design
from scratch.
• The learning curve is shortened if contractors with knowledge of the system are used.
Problems Identified
States are required to perform their own investigations of all transfer alternatives since there is
no consistent vehicle for getting information about all State systems. This process can be
streamlined to provide a clearinghouse of information to States and shorten the time they need
to identify and investigate alternatives.
The quality and accuracy of State documentation for their systems varies widely. In some cases.
States transferred a version of another State's test system rather than version being used in
production. In other cases, transfer system documentation is so poor that the receiving State must
take time to determine the program functionality for itself. In both cases, some measure of
consistency should be established to enable a system to be a transfer candidate. Establishing
some minimum performance and documentation criteria may help eliminate these problems in the
future.
Recommended Guidelines
To ensure that future system transfers are reasonable, the following guidelines are suggested:
• Establish a national clearinghouse at FCS to capture, analyze, store and distribute
information to States - Information in the clearinghouse should relate to the capabilities
and liabilities of installed and developmental State systems supporting the Food Stamp
Program. The data would be acquired through proactive contacts with each State.
Specific information maintained should include: hardware/software platforms, performance
statistics, planned and actual costs, planned and actual timeframes, project management
team, project management approach, conversion and pilot plans, conversion and pilot
results achieved, current operational status, and any future considerations.
Volume I *j^\ Page VI-7
Have each receiving State rate the transferring State - Criteria on which the transfer
State is rated should include:
Timeliness of transfer - How much time required for the transfer State to
provide all necessary information and source media?
Completeness of transfer - Was all source code and documentation received?
Performance - Were there any aspects of the system that did not perform as they
were represented?
Degree of customization to be performed - How much of the system had to be
changed?
Overall satisfaction level with the transfer system - How well did the system
meet users' needs?
Encourage the development of new technology platforms - This would enable FCS and
the States to determine their usefulness and effectiveness in the food stamp environment.
•U.S. G.P.O.:1996-716-642
Volume I ^r/ Page VI-8