a Human Servicer NUMBER 25 SEPTEMBER 1981 MONOGRAPH SERIES Planning and Implementing Jodal Service Information Systems: A Guide for Management and Urerr PROJECT — A National Clearinghouse for Improving the Management of Human Services U.S. DEPOSITORY NOV 02 1980 ldumoan Servicer NUMBER 25 SEPTEMBER 1981 MONOGRAPH SERIES a. Planning and Implementing Jocial Service Information System: A Guide For Management and Urerr Barbard Cotter ANational Clearinghouse for Improving the Management of Human Services Af "2 CY SPAT Cac OHA TOS 0 Pal Project SHARE has contracted for the preparation of a monograph series in order to survey the state of the knowledge or the state of the literature in selected subject areas of importance to the human services community. The monograph series provides an opportunity for authors to offer their views and opinions on these topics. It is the aim of Project SHARE to stimulate discussion through the publication of these monographs. This monograph was prepared in fulfilment of a contract with Aspen Systems Corporation, publisher, as a contribution to the Human Services Monograph Series, Project SHARE, Department of Health and Human Services, Washington, DC. The views and opinions expressed in this monograph are entirely those of the author and are not necessarily those of DHHS or Aspen Systems Corporation. Va/ 77 I / p (Cb No Acknowledgments /98/ 12) / 7 / Vi J | wish to thank the many persons and organizations that provided valuable ideas for and assistance in the preparation of this monograph. Without their support this work would not have been possible. | appreciate the aid received from the staff of Project SHARE, particularly Becky Elson who first suggested this effort. Special thanks are due to: Merle Springer who is Deputy Commissioner, Mary Birnbaum, Mary Hansen, and other staff from the Texas Department of Human Resources; Richard Pryor, Barry Meese, and colleagues from the New York State Department of Social Services; Jeanette Gagnon and Lynn Koontz from the New Hampshire Department of Health and Welfare; Robert Lewis, Bart Hopkins, and staff from the Utah Department of Social Services; Pat Schene, Cynthia Mohr, and staff from the American Humane Association; Victor Capoccia from Boston College; and Richard Greenberg from the U.S. Department of Health and Human Services. They arranged interviews and provided information, documents, and assistance on their social service information systems and system development methodology. Warm thanks also go to the Virginia Department of Welfare. | should like to thank William L. Lukhard, Commissioner; Ray Goodwin, Deputy Commissioner; and D. Ray Sirry for their invaluable encouragement. Many colleagues and staff also contributed to my work with their recollections, advice, and help including Joan Ehrlich, Dr. Elizabeth Whitley, Phyllis Breiden- baugh, Bernard Eudailey, Connie White, Kathryn Myers, and Dan Moore. Their suggestions greatly enhanced the final product. I am most appreciative of the dedication and meticulous typing of Alyne Kennedy who made it possible to complete the manuscript. Finally, | wish to thank my husband for his patience and understanding during my preoccupation with this project. Barbara Cotter, 1981 n U''724 wo ] i . i | TET ey Se 2 py CPE sp Contents I. Introduction 1 Il. Management Strategies for System Development 5 Top Management Support Phases of System Development 7 Costs of System Development 10 Project Management 13 The Use of Consultants 18 Ill. Involvement of the User 23 Benefits of Involvement 23 User Leadership 24 User Leadership in System Development Phases 26 Methods of Involvement 27 Facilitating or Hindering Factors 30 IV. Planning a Social Service Information System 33 The Planning Phases of Development 33 Study or Transfer of a Comparable System 36 Conceptual Framework for Information Requirements 37 Defining System Reports 39 Information Requirements for Standards 46 Forms 48 Determining the Need of Data 51 Computer Design 54 V. Privacy, Confidentiality and Security 59 Growth in Data Collection 59 Risks and Implications 59 Safeguarding Information 60 Security Measures 63 VI. Implementing a Social Service Information System 67 The Implementation Phases 67 Testing 70 Preparations for the System Installation 73 Documentation 75 Traning 76 User Advocacy Unit's Support for System Operations 80 Evaluation Process 81 VII. Acceptance of the Social Service Information System 87 Acceptance and Resistance 87 The Caseworkers’ Concerns 88 Building System Acceptance 89 Major Changes Affecting People 90 VIII. Child Protective Service System 95 Purposes and Functions of the System 95 Decisions 99 Utilizing the System's Information 105 Summary 107 IX. Systems for Foster Care and Adoptions 709 Foster Care Functions Supported by Systems 170 Adoption Functions Supported by Systems 113 System Support for Interstate Transfer of Children 116 System Design Choices 116 Summary 119 X. A Comprehensive Social Service System 121 A Conceptual Description 122 Case/Client Subsystem 124 Provider/Resource Subsystem 127 Service Delivery Subsystem 130 Financial Management Subsystem 134 Potential Online Inquiries 138 Potential Reports 139 Payoffs for the Service Staff 141 Payoffs for Management 142 XI. Beyond the Implementation of Systems—Using the Information 145 Reasons for Low Utilization 145 Strategies for Effective Utilization 147 Transformation of Data to Management Information 150 Trends in Utilization 154 Glossary 157 Bibliography 161 Appendix A. Planning the System 165 Appendix B. Implementing the System 171 Appendix C. Utilization of Information 779 Vi List of Figures Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9. Figure 10. Figure 11. Figure 12. Figure 13. Figure 14. Figure 15. Figure 16. Relative Cost To Make System Changes and To Fix an Error by System Develop- ment Phase 12 Level of User Interest by System Development Phase 25 Typical Functions of a User Group 29 Social Service Information System for All Management Levels 38 Typical Example of Batch Processing 55 Example of Online Processing 56 The System Acceptance/Resistance Continuum 87 Social Service Information System Model 123 A Departmentwide Case/Client Subsystem 125 Social Service Programs: Unique Requirements 127 Provider/Resource Subsystem 130 Service Delivery System 132 Direct Service Reporting 133 Financial Management Subsystem 135 Comparison Between the Tabular and Graph Formats: Child Abuse and Neglect Reporting 152 Example of a Line Graph, Multiple Years 153 Appendix A Figure 1. Figure 2. Figure 3. Guide to Describing a Report 167 Suggested Format for Specifying Standards or Rules To Be Monitored by the Computer 168 Data Directory Outline 169 Appendix B Figure 1. Figure 2. Figure 3. Figure 4. Comparison of Possible Testing Plans for Small and Complex Systems 173 A Sample Training Outline for the Supervisor and Service Worker 174 A Sample Training Plan for an Online Social Service Information System 176 A Sample Set of Questions for Evaluating a Report 177 vil Wax . . . ) . os - BA yr v Ld ~ . R . - . . oo ) - - oo - oo B - B a: a - E pe E E Ei g } : y - ET So : ) |. Introduction More and more administrators of human service agencies are turning to automation to provide operational support for and to identify accomplishments of social service programs. The new era of accountability requires more than ever before that agencies demonstrate achievement of results to receive funding for expansion or even continuation of present services. All levels of government are less willing to support services without understanding what services do for people. Greater attention to results is also needed to allocate increasingly limited resources to services offering the most benefit. Beyond accountability, the value of an information system lies in its support for decision- making at all levels of the organization. Traditionally, information has not received much attention or high priority. Service systems have been a relatively loose amalgamation of data and reports to fulfill basic accounting and legal requirements that lack an overall consistent pattern. With the impressive developments in computer technology—the whole body of knowledge relating to data collection, measurement, storage, manipulation, transmission, transformation, and use—information is now beginning to be available, and the potential impact on social service agencies is great. The computer opens possibilities that are not attainable with manual approaches. While today’s social service information systems may be developed primarily to accommodate demands for better accountability, their value should be considered for developing the overall capabilities of an agency at all levels and for supporting management’s functions. The real potential of the computer lies in more efficient and effective service delivery systems and in more knowledgeable management decisionmaking in budgeting, planning, policy redirection or change, resource allocation, and other administrative concerns. Social service agencies are increasingly expending enormous energy and millions of dollars on the development of automated information systems. The proper design and implementa- tion of the system will determine the realization of its benefits. If handled poorly, the system may become a nightmare and a failure. Unlike the nationally standardized medical assistance and income maintenance systems, the social service systems are largely customized products of their State and local environ- ments and priorities. They reflect the particular State/local organizational structures and agency relationships for social services. The service system may be narrow or broad in scope, and may stand independently or be part of a larger human service system. Some organizations may have responsibility for social service programs financed by title XX and/or child welfare programs, while others may have direct authority over all human service programs—title XX, child welfare, substance abuse, aging, mental health, mental retardation. When children’s services are completely autonomous from other human services, the systems related to children are often developed separately. Related potential influences on the design are service delivery modes, involvement of the voluntary sector, types of clients served, and the services provided—all varying among States and localities. Together these factors render impossible the development of a single social service information system model and make the system development process more difficult and costly. Federal legislation has reinforced this diversity among social service systems. The enact- ment of title XX of the Social Security Act loosened Federal requirements and allowed States considerable flexibility in developing social service programs, allocating social service funds to multiple organizations and expanding the use of services purchased from the private sector. Further encouragement for fragmentation has come from multiple Federal legislation for social services, including the Child Abuse and Neglect Prevention and Treatment Act and titles IV-A, IV-B, IV-C, and XX of the Social Security Act. Consequently, State and local organizations must decide on the configuration of their own social service system. Recognition of the value of social service information systems comes at a time when most State and local organizations have reached their maximum amount of funding for services. In fact, inflationary pressures are causing a struggle simply to maintain the existing level of services. This coincides with increased demands for higher levels of service by clients increas- ingly knowledgeable about their availability. Social service organizations are confronted with the ironic situation of requiring better information to make difficult resource allocation decisions while having no financial resources to develop the needed system. Unless organiza- tions have received a special grant or funding from their legislative body or city council, social service information systems must come from program dollars. Competition between dollars for services and expenditures for management enhancements limits opportunities for im- provements in social service information systems. Despite the overall financial picture, social service organizations are taking substantial steps to develop social service information systems. The funding, however, makes it critical to succeed in developing the system as economically and efficiently as possible. In the long run, the system may be able to recover its cost by its providing information that helps determine where limited resources can have the maximum impact and where actual savings of service funds can occur. In addition, a comprehensive service information system could replace multiple service reporting systems and more effectively utilize those funds. This monograph approaches the design of a social service information system as a man- agement issue, not a technical problem. The document identifies critical elements, effective strategies, and potential pitfalls in the planning, implementation, and utilization of systems and brings out the complexity and long-range nature of a system development effort. The information is intended to help administrators and users establish successful social service information systems, anticipate and avoid problems already faced by similar agencies, and maximize the use of existing and future systems. The document also gives managers and service staff an understanding of how automation can help and how information systems can be flexible in accommodating different service programs and future changes. This monog- raph covers the following major areas of interest and concern to management and users: Management strategies for system development; Involvement of users; Planning the system; Privacy, confidentiality, and security; Implementing the system; Acceptance of the service system; Examples of systems; and Utilizing the system. The following is a summary of each of the chapters. Chapter Il, Management Strategies for System Development, describes the need and value of top management support, an organizational approach for system development, and effec- tive project management. It brings out the importance of managers taking responsibility for systems and providing leadership to the development efforts. Important considerations for management are discussed, such as the costs of system development, potential cost overruns, resource requirements, and the use of consultants. Chapter lll, Involvement of the User, looks at the role of users in all phases of planning and implementing systems, covering the traditional contributory role and recommending a user advocacy unit to be active and directive throughout the system's life. The involvement of user groups and other techniques for participation are discussed. Chapter VI, Implementing a Social Service Information System, reviews the activities of the system development, installation, system maintenance, and operations and evaluation phases, and gives a detailed discussion of areas of major concern to management and users—testing, pilot site testing, preparing sites for installation, training, and providing assis- tance to the newly installed sites. Chapter V, Privacy, Confidentiality, and Security, discusses the impact of computers on the individual's right to privacy, the confidentiality requirements for agencies, and the various procedural and technical security measures that can be incorporated into the system’s operation. The privacy-confidentiality controversy that surfaces around the development of a child protective services system is also discussed. Chapter VI, Implementing a Social Service Information System, reviews the activities of the system development, installation, system maintenance, and operations and evaluation phases, and gives a detailed discussion of areas of major concern to management and users— testing, pilot site testing, preparing sites for installation, training, and providing assistance to the newly installed sites. Chapter VII, Acceptance of the Social Service Information System, looks at possible user responses to the new system, the likely reservations of service workers, and the impact of resistance on the system's operation and use. It also brings out the importance of service worker ‘‘payoffs’’ in the acceptance of the system. Chapters VIII, 1X, and X focus on the three dominant social service systems: child protective services, foster care, and comprehensive social services. The chapters relate the history of the different types of systems. The child protective services have emerged as a result of the Child Abuse and Neglect Prevention and Treatment Act and of State statutes requiring a central registry of reports of child maltreatment. Foster care systems have ties with permanency planning efforts to prevent drift of children in care as well as with the Adoption Assistance and Child Welfare Act of 1980 (Public Law 96-272). The general social service information system has links with title XX reporting, State and local needs for client registration, service delivery tracking and payments, and vendor/provider listings. The chapters give social service organi- zations a basis for choosing systems through presenting alternative approaches for each type of service system and describing a comprehensive service system that includes foster care and child protective service systems as part of the larger system. Chapter XI, Beyond the Implementation of the System—Using Information, deals with the organization ‘payoffs’ of the system that require effective use of the system to realize its anticipated benefits. This chapter addresses the problem of a system’s information being ignored or little used, even where the system has gained commitment from administrators and has been geared to agency purposes. It covers the data quality issue and other constraints limiting the use of data and proposes methods for insuring data utilization by management, service workers, and other staff. oo CELE Sa She Sse a Sn i oo - ea IR ta i | a B . - a . a a, - . "oe oo . t a > [ele y h on - : = EE or En CoE he a oo NS 3 - a TPR Il. Management Strategies for System Development Many social service organizations are struggling to implement a viable information system and others are contemplating such an implementation even in the face of the high cost of a system and increasingly limited funding. Management must give leadership to the develop- ment of the system to insure that it is a valuable tool for the organization and that it requires minimal resources. Management leadership is of paramount importance to minimize and eliminate typical problems that occur during development: underestimated projections of costs and develop- ment times, late completion of the system and major products, delayed management deci- sions, poor system design, exceeded capacity of computer equipment, cost overruns, poor relationships and misunderstandings between technical and user staffs and between consul- tants and the organization's staff, and, finally, implementing systems still experiencing prob- lems. In addition, problems may exist because of pressure to automate everything, service worker resistance to the system, and ineffective utilization of the system. The worst situation results in abandonment of the system development effort and total system failure. Management can make a difference by its approach to system development efforts. Factors having considerable impact on the successful planning and implementation of a social service information system include: ® Top management support—the direction, support, and control provided by the agency's highest administrative levels. ® Phases of development—the adherence to the fundamental processes for planning and implementing information systems. eo Cost-benefit analyses—management’s understanding of the system’s major costs and its assessment of whether the system is worth the probable cost. ® Resources—the availability and provision of funds, staff, and hardware for the development and operation of the system. ® Project management—the programmatic and technical leadership provided for the infor- mation system effort combined with realistic planning, control over timely completion of activities and quality products, and avoidance of cost overruns. e Team approach—the effective collaboration of technical and user staff for building and installing the system. ® Use of consultants—the organization's careful selection and effective management of contractors to maximize their contribution to the development effort. By understanding these factors, management can play a critical role in committing to the development effort, overseeing the proper administration of the process, and approving continuation of system work at key points. The development effort therefore becomes a management issue rather than just a technical matter. This chapter discusses each factor. Top Management Support The involvement of high-level management in planning and implementing systems is key to the successful use of computer technology. An ever larger share of an organization's re- sources are being devoted to information systems, and executives should play a major role in establishing system objectives, priorities, and policy that fit the needs of the organization and its units. Since many new systems are closely woven into the main organizational fabric, there must be much closer attention to these efforts than in the past. Top management leadership allows an organization to move more smoothly through the development and implementation of systems by providing equipment, good project structure, and other re- quired resources. This is particularly important for expensive, complex systems needing long-term administrative commitment. Executives should participate in the following areas to insure optimal decisions for the organization on the automation of systems: e Establishment of selection criteria for evaluating and selecting system projects. e Unification of management information system efforts and establishment of short-term and long-range plans for system development. ® Response to emergency system needs resulting from State or Federal mandates. ® Selection of all projects to be undertaken and approval of their time frame. Determination of project priorities, selecting alternatives for implementation of single applications or choosing from among a list of competing applications. Approval of specific proposals for acquisition of major items of data processing equipment. Resolution of functional interface and territorial conflicts. Establishment of a proper project structure. Establishment of a management control document listing the various decision items, checkpoints, and signoffs needed for the project. ® Oversight of activities completed on time and within budget and establishment of accoun- tability and corrective action plan for missed target dates. eo Review of project progress and determination of whether projects should progress to the next phase or be abandoned. The long-term plan for systems development should define the individual systems, subsys- tems, and the interfaces and should facilitate the development and integration of individual systems through the framework provided. The master plan also constrains development by its defined boundaries and interfaces. A plan facilitates the gradual progressive development of systems that fit together well at the least possible cost. While many human service agencies have established successful systems without even an idea of a master plan, this is more difficult and problematic today with the increased number of systems and the growing shortage of funds. In establishing priorities and selecting projects, management must consider the preliminary cost-benefit analysis and payback, anticipated impact on the organization, consistency with the organization's long-range plans, and compliance with mandates. Management must also look at the organization's capability to handle the sophistication of the proposed system and the anticipated costs for development and operation. Negative consequences occur when executives fail to cope with and control the develop- ment of automated systems within the organization. The more obvious characteristics of these problems are poorly defined objectives or none at all, piecemeal development of systems without an overall plan, hurried automation of major and minor systems, low project team morale, disregard of management's information needs, problem-ridden implementations, and abandoned systems. Top management's abdication of responsibility for the new information technology may be the major cause for automated data processing efforts failing or falling far short of the organization's expectations. The executive director and his immediate assistant have been the significant executive actors in the successful development of systems. Some organizations are using a senior executive group to support the agency head in prioritizing and leading system development efforts. The executive group, sometimes called a management information systems board or the department information systems steering board, develops and maintains overall depart- ment policy on system development and computer hardware acquisitions and approves and reviews system development projects. Certainly, with the executive's knowledge of the or- ganization’s overall goals, objectives, and plans, it becomes possible to establish system short- and long-range plans, determine the appropriate level of data processing expenditures, and assign financial and staff resources. This planning should follow the overall organiza- tional planning. In a highly centralized organization where final decisions, including budgetary ones, are made only by the executive director, an executive group can still play a significant role. The group could recommend decisions on systems that would be optimal for the organization as a whole and could have considerable impact on the organizational direction in systems and the funding and resources allocated. In the face of political changes and the short tenure of most top executives in human services at the State level, a steering group provides continuity and organizational stability to long-term system development efforts that require substantial investments for 5 or more years. The group can communicate the value of the development effort for the organization to the new executive and continue to support the provision of the necessary resources. Executives may need to know about computers and their capabilities and the processes and elements of developing systems as they assume a leadership role and recognize that informa- tion systems are not only a technical undertaking. An involved manager must be informed. Knowledge of the system development phases and the associated resource requirements and costs are basic for providing active leadership. The next two sections discuss these areas. Phases of System Development Successful planning and implementation of systems depend on an organization's under- standing and following the fundamental processes—the system development phases—that all computer projects should go through regardless of system complexity. The phases are important for planning, management, and control. The development of automated informa- tion systems is inherently difficult from inception to operation, and neglecting any process may have serious consequences for the end result. There are essentially seven progressive phases for an automated information system: Needs assessment and requirements analysis, General design, Detailed design, System development, Installation, System maintenance and operation, and Evaluation. The needs assessment phase involves study of the problem or need, defines possible solutions, recommends a feasible course of action, and estimates cost. The next two phases, general design and detailed design, define the requirements for the selected solutions and translate them into a system with procedures, data dictionary, design of system input and output, and the file structure. System input includes equipment needs as well as collection of data. System output includes reports and inquiry output formats. Design ends with a decision on the appropriate technical solution, and the computer project moves into an execution phase—system development and implementation. System development is the writing of program specifications and the testing and documen- tation of programs, ultimately creating the computer system. Development also includes operations documentation. Installation is the implementation of the system in a real environ- ment on a trial basis, followed by training in all sites and transition from the old system to the new. Conversion of automated and manual files to the new system is performed. The system can be implemented into a production mode after the conversion is complete. Operations is support for the functioning of the production system, and maintenance is the elimination of faults and problems to help production. To complete the cycle, an evaluation of the system assesses how well the system performs from both the technical and user perspectives, compares operations to the cost and performance specifications, and identifies the necessary adjustments and changes. The early stages are critical, for they establish the scope, structure, timing, and cost of the new system and set the stage for all subsequent work. Management must avoid the temptation to move into system development too quickly before the design is completed and it is clear how all parts fit together. Sufficient time for testing and trial implementation of the system is vital because they help work out many system problems prior to full implementation. The division of system development into these phases is not arbitrary. Each phase has standard functions leading to an increasingly specific description of the new system and, ultimately, to a greater readiness for the system’s operation. If the system is to be effective and realistic and receive long-term support, management should require, at the conclusion of each phase, visible end results in the form of a descriptive report on the system and a plan for proceeding with costs and resource requirements. Management, users, and technical staff should review and approve, taking time for second thoughts, before the next and usually more costly phase of system development is initiated. Two major considerations in approving a proposal to move into the next phase are the organization’s resource constraints and the confidence level of proposal estimates on time and resources. Resource Constraints Management must examine the immediate and long-range resource requirements and assess the organization’s resources and constraints prior to proceeding to the next phase of development. Serious drawbacks for continuing a system project are constraints related to equipment availability, financial resources, and/or staff resources for planning, implementing, and operating the system. The availability of the equipment relates to the existence of computer hardware, the social service agency's access and claim to computer time controlled by State or local computer centers, the capability of the computer system to accommodate an additional workload, and the requirements of a sophisticated social service information system. Without equipment or access to the needed computer time, the system cannot function. Therefore, equipment constraints must be addressed early by adjusting the system design to operate within the limitations or by procuring additional equipment capabilities. The financial demands of the computer system and its usage are another constraint. Although computer costs are decreas- ing and the advent of the minicomputer has introduced more economical technology, hardware is expensive and computer usage costs are high. These costs begin late in the design phase and are part of the maintenance cost. The development of an information system is heavily dependent upon staff resources throughout the design process and into system operations. The system development phase is especially labor-intensive. Staff may not be available internally as a result of external controls on government staff growth, an organization’s inability to recruit and retain staff with techni- cal expertise, or the lack of financial resources to cover the costs. An alternative to internal resources is the use of consultants; however, the financial resources must exist because a contractor is significantly more costly than internal staff. The system development effort must take into account the specific resource constraints in planning and implementing the system. Action is necessary to remove the constraint, or its existence must be reflected in the system planning. For example, if computer equipment cannot handle the proposed system, the organization must order new or upgraded equipment or the development staff must scale down the proposed system to operate within existing computer capabilities. Dealing effectively with constraints requires management's recogni- tion of their existence, study of alternative courses of action, and selection of the best alternative. The project’s staff mu .t then proceed with the development effort in accordance with the selected alternative. Estimates Management should assess the confidence level of the proposal estimates so that, in approving the system plan, they are aware of the time and resource risks. A low level of detail on the system provides veiy uncertain estimates of costs except for the costs associated with the next phase of development. Only at the conclusion of the detailed design can firm projections be made on system development and tentative projections provided on equipment requirements to support the new system and on probable operational cost. The complexity of the proposed system increases the uncertainty of projections while the organization's experi- ence with comparable system development increases the likelihood of accuracy. As a greater level of detail becomes available from later phases in the project, management should require that estimates be reevaluated and revised in terms of cost and time. Estimates are difficult and time consuming and should be handled by the most experienced staff. Since estimates drain valuable staff time often needed for other work, they should be completed to the level of detail necessary and possible. Management should request only an approximation when this is sufficient. Some rough methods exist for judging estimates. One approach is studying the experiences of other systems similar in content, complexity, and volume and using the results to develop or evaluate the estimates for the new system. The value of other experiences, however, has limits because of the unique character of social service information systems and the important differences in the computer environment. An alternative method is requesting an independent review of the original estimates. A second opinion is leverage for making the first estimate as thorough and accurate as possible. It also may offer different costs and time frames that help in judging the reliability of the original figures and that indicate the potential range. From this, management has a firmer basis for approving or rejecting all or part of the proposed system. Approval to Proceed Management's approval takes into account the system's value and the organization's ability to afford the system. Any risks and uncertain factors in the predictions of resource require- ments, cost, and time for the system development effort must also be considered. Manage- ment can generally regard estimates as accurate for the next phase of development and as “ballpark” figures for the following two phases. Management may not be able to make a long-term commitment to implement the system, particularly if funding is very limited, until the conclusion of the system design. The system design work provides a relatively complete projection of development and operations costs. It also offers a conclusive cost-benefit analysis report, which gives management better informa- tion to judge the importance of continuing the project. The final decision may be to proceed with the project as proposed, reduce the scope, or end the effort. To provide management a greater understanding of the cost issues so critical for beginning and maintaining a system, the next section discusses costs associated with each system development phase and potential cost overruns. These must be weighed in giving approval to system efforts and later must be controlled to prevent data processing services from exceed- ing available funds. Costs of System Development The high level of funding required for developing an automated system makes the budget a critical factor in light of the increasing cutbacks on social service funds. Planning for a system within the organization's budget and keeping the development and operation expenditures to a minimum requires management's full understanding of the different expense areas of a system and the variables that increase or reduce costs. The consequences of poor financial planning may be abandonment of the system or reduction in parts of the system. The major types of costs for a system from planning through operation are: e personnel costs for designing and developing the system and for its implementation and maintenance, e hardware costs, and ® computer processing costs. The cost in each area varies significantly depending on many factors: the system development phase, sharing the computer with other systems and organizations, whether the system has totally centralized equipment or is decentralized with computer terminals and/or printers, the experience level of staff, the use of contractors and the company’s experience with the system being developed, the pace of system development, and building a system “from scratch’ as opposed to transferring the concepts or the forms/reports/computer structure of one operat- ing elsewhere. The cost for building a similar system is the same for small and large organizations because the design and development efforts require the same level of support. This gives larger organizations a greater economy of scale and encourages smaller ones to borrow systems from other States. On the other hand, training, conversion, and other implementation costs are proportionate to the size of the organization as well as to the operational costs of the system. The system development phases have different costs and vary in their financial demands. The least costly phases are requirements analysis and general design, followed by the detailed design. They may require high-level expertise for designing parts of the system, but costs relate primarily to systems analysts and user staff. On the other hand, the systems develop- ment phase is labor-intensive with systems analysts, programmers, other technical staff, and user staff, and also requires significant computer time for programming and testing the new system. The installation phase has multiple costs related to changing from one system to another, the publication of new procedural manuals, procurement of worker tools and forms, user personnel for training staff who will use the new system, technical personnel for resolving problems and maintaining the system, and finally equipment and computer usage costs. The operations and maintenance costs are the ongoing technical and user personnel required for support and the production system’s utilization of equipment and computer time. Evaluations require technical and user personnel time and often lead to the identification of some changes in the system and new development work. Sharing the computer with other systems and organizations can distribute costs propor- tionately to users and reduce expenses. The lack of control and possible low priority on a 10 central computer facility could cause access problems and increase other costs. A decen- tralized system with online capabilities brings additional costs for the terminals, printers, telecommunication lines, other related equipment, additional computer usage for software and application programs, and costly security and backup data-recovery procedures. The experience level of staff and their technical expertise also affects cost. Unless personnel have expertise corresponding to the complexity of the system development effort, the trial- and-error experiences bringing staff to the required technical level may increase the cost of the system development effort. The performance level of staff may be a serious constraining factor, and their inexperience and mistakes may make the system unaffordable. Contractors are expensive, but the cost may be offset when they have greater expertise than internal staff and can do the work in less time. The contractors’ knowledge of social services is invaluable for the first three phases and their basic technical expertise is of greater importance in system development and installation phases. The pace of system development relates to the amount of time given to planning and implementing the new system. The time can be shorter or longer: short time frames usually require more resources and higher costs for a briefer period, and vice versa. A longer schedule may be preferable where resource and funding problems exist. The last factor affecting cost is building a system from ‘‘scratch.” Starting the development of a system from ‘‘ground zero” is the most costly approach. Studying existing comparable systems, modeling the new system on an existing one, or transferring and utilizing actual computer design documents and other products of an existing system can reduce develop- ment costs. Study offers the least savings; transferring the computer design, the most. Cost Overruns Cost overruns are a frequent problem and appear to be the rule in the development of most systems. The major causes relate to the following areas: Managing and planning the project, Design of the system, Accommodation of system changes, Poor programming procedures and techniques, Decisionmaking and approval processes, Equipment availability, and eo Greater utilization of the system than anticipated. Management needs to be alert to these cost risks to reduce them to the extent possible and to have some allowance for accommodating the unanticipated. Poor management and planning can cause costs to exceed projections. Where management does not have tight control over project activities, work may not be completed on a timely basis. Poor planning involves underestimating (or even overestimating) the time required to complete work, unrealistically appraising staffs’ capabilities to perform, and/or failing to identify all resource requirements. These problems can cause schedule delays and increase the personnel costs for completing the work. If the project is under a tight time frame, it may be necessary to obtain additional, more expensive resources to finish the work or, otherwise, shortcut parts and reduce the quality of the effort. Cost estimates often focus on the analyst and programming support required and do not take into account other personnel requirements. The completion of the project requires much user assistance such as test case development, user guide preparation and training, and technical support for such areas as conversion, equipment installation, and data entry. Management is later unpleasantly surprised at the unexpected demands the system places on the organization and the adverse impact that it has on the performance of regular functions. In 11 fact, the costs for support activities required to implement the system may exceed the cost of systems analysts and programmers. Design problems relate to poor definition of the system in the requirements analysis and design phases. A poor design increases the system changes required. New dimensions of the system or gaps may be uncovered and parts of the system may require a substantial redesign. Any changes that occur that were not anticipated in the design effort need to be included in the system. The adverse effects are extension of the time and additional personnel costs to complete the design. In the maintenance phase, poor design causes inefficiency from the standpoint of computer usage that can significantly affect the cost for running the system. The timing for accommodating system changes can affect costs. As figure 1 shows, the cost for incorporating and correcting design problems is lower in the early phases of the project. The obvious implication is that changes should be made as early as possible. While incorporat- ing change increases costs, delaying system change raises the long-term costs because late changes require more modifications to the past system work. However, at a certain point a design freeze is necessary because further system changes will delay conclusion of the planning or implementation time frames and increase the development costs for personnel. To avoid cost overruns and obtain an operational system, it is imperative to postpone these changes until the system is implemented. These system changes can become part of those made after the formal evaluation process of the pilots and full installation. Figure 1 Relative Cost To Make System Changes and To Fix an Error by System Development Phase 100 [ | | $ | | | 0 Requirements G | Detailed Sy I lati Op Analysis Design Design Development 12 The accessibility of the computer for the system development phase can increase costs. If technical staff experience delays in access to the computer when programming and testing is in progress, they can become idle and thereby require more elapsed time for completing work, resulting in higher costs. The system development phase is costly not only for intensive technical staffing require- ments but also for computer usage in developing programs and testing the system. The latter cost is often hidden although the computer usage charges could be in excess of the contrac- tual support costs for the same time period. Poor programming procedures and techniques rapidly escalate costs beyond their normal levels. These poor techniques may also create an operating system that is inefficient in using computer time and increases operational costs. The approval process involves signoff by management on significant interim and final products of each phase and signoff by users and technical staff on system components related to their responsibilities. While these approvals are essential for assuring the quality of the system work and continuing the effort, any delays in reviewing and signing off can cause both idle and lost time and increased costs in the system development effort. Delays or reversals in other decisionmaking areas can have the same effect, insuring along development effort with higher costs. The operational system can also incur higher costs in relation to the computer's accessibil- ity, particularly with online systems. Slow system response time increases the time required to perform certain functions (data entry, data retrieval) and therefore increases staff require- ments. For example, a 2-minute delay in entering needed data rather than 10 seconds for each incident accumulates and requires additional staff support. The operational costs can be higher than anticipated when the volume of system reporting exceeds predictions because of poor planning or the staff's greater acceptance and use of the system. Worker reporting may increase (even double), inquiries may occur more frequently, and users may request more special reports from the computer. These increases affect computer use and costs, but also require additional technical and other support staff and affect administrative costs. Effective management and planning is a key to overall reduction of costs and time in the development of a system. The next section examines the critical importance of project management. Project Management The establishment of a project structure is the first step in initiating a system development effort. Top management must set forth the formal structure defining roles, responsibilities, and authority, and recognizing the major organizational units involved. The initial project leadership may come from the user side or data processing, provided that the leader has a good understanding of both the user operation and automated systems combined with strong commitment to the project. Traditional leadership usually has come from data processing; however, the user has ultimate responsibility for the success of the system, and appreciation of the leadership role of the user is growing. System leadership is critical for bringing an information system project through the inevita- ble abundance of issues and through the formally structured system development cycle with major documents completed and the system successfully implemented. The demands for this effort, which increase with complex systems, clearly point to the need for at least one strong individual. The leader must have many skills as well as the respect of top management. The person must be able to assess accurately the political environment encompassing system development and to get attention from top management for establishing a high priority for the effort and for obtaining needed resources. Decisionmaking capabilities are another require- ment that involves understanding who makes what type of decisions and serving as a central point to make decisions, force them at lower levels, or obtain them at higher levels. 13 Preferably, leadership exists on both data processing and user sides, with a mutually supportive leadership effort from both users and data processing. Users may have the primary lead in planning and implementing the system and data processing may take the lead in the system development phase. The quality of leadership rather than the location is the more important factor. Generally, the leader is the project director and the focal position on the project who gives day-to-day leadership and specific directions for creating the system. The director's respon- sibilities are to plan the development effort, estimate the resource requirements and costs, and exercise direction and control over the use of resources and time in the process of completing the system work. The project director, with the support and guidance of management, must establish the new project structure, insuring a clear description of the authority, responsibility, and accountabil- ity of all staff so that development work can proceed in an active and orderly fashion. Formal communication channels must be developed to insure the proper information flow to man- agement and within the project. The following areas should be considered in building the project structure and carrying out the system work effectively: Team effort, Decisionmaking, Planning, Project control, and Quality assurance. All areas interrelate, but each is discussed separately. Team Effort Planning and implementing the information system requires team effort and the blending of multiple skills under strong leadership and project direction. The primary contributing mem- bers of the development team are: e the project director, ® systems analysts, ® programmers, and ® users. Many cumulative skills—both general and technical—are needed of the project team. Management, supervisory, and communications skills are basic for directing the project and leading the implementation of the system. Planning skills help in preparing work plans and setting realistic time frames, and resourcefulness insures getting staff needed before and after implementation to carry out the plan with the least cost. Coordinating and integrative skills insure involvement of all appropriate organizational units. Strong analytical ability combined with creativity are important for designing a workable, meaningful system. Negotiation skills are useful to bring about consensus and decisions where disagreements exist. Strong computer skills are essential for designing and programming a technically feasible and economical system that is also suitable for the users. Good communication skills are important for building, documenting, and training on the system; training skills are necessary for implementing the system. The project director is the manager of the project and may come from the technical or the data processing side, as already discussed. If the director is from the user side, a technical 14 project manager is usually designated to lead the data processing side of the system effort. Strong management, supervisory, planning, and communications functions are essential to . lead the project and must not be sacrificed to the technical work demands of the development effort. The director is critical for carrying out project controls and quality assurance efforts and for reporting project status, bringing up major issues, and presenting final products and work plans to management. Heavy management demands exist in the installation phase for directing and sequencing many concurrent technical and user-oriented activities. At the maintenance and operational phase, lead persons are usually designated from both the technical and user sides. The systems analyst is involved throughout the life of the project, working with managers and users to define system needs and design the automated system from conceptual system definition to detailed system design. The analyst also works with the computer programmer and user to implement the system by supervising the programmer, overseeing the testing, obtaining the necessary computer equipment, and participating in the installation of the new system. Some analyst support is also necessary for the maintenance of the system. The computer programmer begins in the system development phase. He works with the detailed program specification produced to design and code computer programs and then tests and documents each program and the interrelationship of programs. The programmer also continues to provide some support when the system is in the maintenance phase. The users play a significant role in all system development phases, which is the subject of discussion in the next chapter. Some users are participants on the project team, but most are contributors to the system effort. The most extensive involvement occurs during the require- ments analysis and general design phases when users participate in defining design require- ments and reviewing and accepting the proposed system. Users also have an active role in the implementation phases, participating in the testing of the system, planning the installation, and carrying out the training. In the maintenance and operation phase, they handle user problems, requests for information, and periodic training. The installation of the system brings additional and different personnel into the project effort, as the system shifts to becoming another operational automated system in the organi- zation. These personnel run the computer system and the entry and control of the data. They are not members of the project team, but carry on the results of the system development effort. The project director brings together the different skills to create a team effort and to maximize each member's contribution in developing the system. At the same time, the director must insure that each member has a clear job assignment for which he can be held accounta- ble. Because few organizations have an abundance of trained, effective, and available staff, it is necessary to find ways to use all team members as efficiently as possible. All staff need to work collaboratively on their interrelated tasks and appreciate the importance of getting work done on time and within budget. Decisionmaking The need for clear and definitive decisionmaking is a critical requirement for completing a system on time. A complex system may require 12,000 or more decisions that are urgent or important. Decisions need to be made as rapidly as feasible. Once the decision is made, it needs to be respected and followed, not reversed. The project should have rules regarding the specific period of time within which reviewers must signoff on a product. The rules should include a default clause that allows the project to move ahead with its own design if the manager or other user does not meet the deadline. The greatest source of delay in systems development efforts is getting the many people involved in decisionmaking within the organization to reach agreement. Such a rule forces agreement and closure because the staff does not want to forfeit the right to comment. Consistent 15 enforcement of this provision and holding to a tight timetable produces timely responses, forcing issues to be resolved and forcing people to compromise on their requirements. It is necessary to apply the same rule to user groups. The decisionmaking process should be delineated. All participants in building the system should know how decisions are made, when they are made, and who has the final say. As many decisions as feasible should be delegated. The project director or another key person should be identified as the central point for handling problematic decisions. Planning Planning is essential to the successful completion of each development phase and to the implementation of the system. Planning proceeds from the proposals and time and resource estimates presented and approved by management in the preceding development phase. A good plan should indicate the schedule for completing the major products and show the associated work with time frames realistic for the resources available. Management needs a plan indicating activities and milestone products and dates to oversee the progress of the project, while the project manager requires a detailed plan at the task level to direct and monitor accomplishment of the work. The specific content of the plan should reflect the following: ® The major activities necessary to complete the development phase(s), ® The specific tasks related to the activities and their dependencies, ® Resources and time requirements, ® Persons responsible for completing tasks and activities, and ® Review points for detailing the schedule. The activities should be broken into manageable task units. Generally, the specific tasks cannot be completely detailed and scheduled more than several weeks in advance. Activities should remain fixed and on schedule, with further detail added prior to beginning a new activity. Assignments should be organized to insure accountability. A good plan with realistic target dates is essential for implementing effective controls to keep a project on schedule. Project Control Control is the oversight of the project's performance of planned activities for the purpose of maintaining the effort on schedule and identifying problems in time for management to correct them. The need for tight management controls is critical for data processing projects, given their traditional notoriety for cost overruns and failure to meet deadlines, causing management and user disillusionment. Management and the project director must not as- sume that everything is on schedule, but must utilize a control system to confirm and insure that it is. The control processes involve (a) comparing and monitoring the completion of tasks and activities in relation to the plan and work schedule, (b) assessing what remains to be done, (c) evaluating the causes of any significant deviations from the plan and possible alternative actions, and (d) correcting, to the extent possible, any unfavorable situation. Early completion of tasks and activities may also offer an opportunity to complete other tasks sooner and gain time for any unforeseen problem while holding to the overall schedule. The project director, supported by management, must create the work environment that challenges individuals to their best performance and simultaneously encourages honest reporting of accomplishments and problems without risk of retribution or reprimand. Double management messages implied by “Let me know if problems occur’ and “The work is still on schedule, isn't it?’ cause problems to fester beneath the surface until it is too late for management to do anything but delay the schedule. In a supportive environment, regular 16 status reports should bring out schedule deviations and potential problems. Staff should be encouraged and expected to report: ® any problem and cause, e expected impact (schedule, budget, resources, other), e action taken or recommended and its likely results, and e what top management can do. These control activities allow the director to have information and solutions soon enough to correct many situations and keep the project on schedule and within budget, but, realistically, problems overwhelm the system development effort at certain points for many reasons, as discussed in the section on cost overruns. As problems occur, the general tendency is to adjust the schedule and provide greater resources, butitis also necessary to examine critically the project director's performance. The change needed may be in the project director, not in the plan. Quality Assurance Another dimension of control is evaluating the quality of the systems work as parts are completed. This involves analyzing the accuracy of the system design, confirming consistency between the computer program design and the specifications in the detailed design, uncover- ing logic and coding errors in program design, reviewing for efficient processing logic, and insuring the completeness of work products. Early detection of errors, deviations, and incon- sistencies within the work product or in its assumptions and representation of the user environment allows quick, inexpensive correction of problems that might not otherwise be identified until systems testing or operation in a pilot site. Pennsylvania uses a review strategy called ‘‘structured walk through’ during different phases of the system project to critique the system products of all technical staff, from most senior to most junior. Generally it involves a 1- to 2-hour review session for each work product with four to six people who have an interest in the product and are effective at identifying problems. Generally, the reviewers are members of the project team and may include a user representative. The walk through follows a standard process. Reviewers read the material prior to the meeting and comment on the completeness, accuracy, and general quality of the work product. At the meeting, they express major concerns and identify areas for potential followup. The reviewee then gives a brief tutorial overview of the product and walks the reviewers through the work in a step-by-step fashion that simulates the function under investigation. He attempts to take the reviewers through the material in enough detail so that the major concerns that were expressed earlier in the meeting are either explained away or brought into focus. Typically, new thoughts and concerns arise during this “manual execu- tion” of the function, and the ensuing discussion of these points crystallizes everyone's thinking. Significant factors that require action are documented as they emerge, and this record becomes an action list for the individual whose product is under review (Pennsylvania Department of Public Welfare, 1980, pp.4-31). Other methods may work as well. In Virginia, one quality assurance method employed for a social services information system was to have users review system specifications to verify accuracy within each specification and overall consistency. They documented all identified problems and, before giving the user approval on detailed design documents, they checked on the correction of all problems. Management should insure that the system development effort has and applies formal methods for insuring the accuracy and quality of the system work. The review checks should occur during the course of development phases and not just at their conclusion. These methods not only improve the system products but give management greater guarantees of quality work. By early identification and correction of problems, they help to contain costs. 17 The next section discusses the use of consultants. Often, organizations turn to consulting firms to obtain the staff resources required to design and develop a system. Therefore, it is important to look at their place in the systems development effort. The Use of Consultants A major decision for an organization is whether to use their own staff to build and implement the system or to contract with a consulting firm for one or more phases of the system development effort. Consultants can be valuable under the proper circumstances for their technical assistance or leadership, which is often outside the expertise of agencies, and for their staff support during the peak-load periods to carry the system project to conclusion. Many social service organizations use consultants for the design and system development phases. The contractor's role ranges from assuming full responsibility for completing the total system from the requirements analysis phase through installation, to providing a single individual to be part of the organization’s project team. Preferably, the organization assumes responsibility for doing as much of the system development work as possible, reducing the use of consultants as the organization gains greater capability for maintaining the system. Often the reality of available experts and resources, however, forces the organization to seek consultant support. To make effective use of consultants and to avoid the typical consultant problems of poor products, itis important to understand how to select consultants and how to manage the contractor's support. How To Select Consultants The right firm is of great value; the wrong one can create tremendous problems. Several types of consultants exist: freelance individuals with special skills, small firms with specialists, and larger diversified consultant firms. System development projects giving a major role to consultants for a large system require a firm with much experience and sufficient resources. The normal method of obtaining a contractor is through the preparation of a request for proposal (RFP) and the use of competitive bidding. Requesting several bids helps insure that the organization is contracting for projects at the lowest cost consistent with the consultant's ability to deliver a quality product. Generally, 6 months are necessary for concluding the procurement process, from the preparation of the RFP to the initial start of the contractor. The RPF sent to prospective contractors is an important document because it sets the parameters for the development of the project in terms of the phase(s) of development and the nature of the system. The requests for work in the early phases require less description of the - system, but later phases need the complete documentation available so that the vendor can adequately prepare his bid and the organization can evaluate the company’s capability to provide the needed services. The RFP should cover the following areas: ® procurement scope, requirements and conditions to be placed on the contractor, proposal specifications, procurement schedule and selection process, and descriptive appendices. The general background of the project is also helpful in understanding the history of the project and the current status of the work. The procurement scope specifies the specific tasks to be performed and within what time frame, the existence of constraints (hardware, interface requirements with other systems, 18 etc.), the organization’s project management and control structure, the resources available to the project, and finally the position of the contractor in the project structure. If the procure- ment scope involves the contractor in assuming responsibility for one of the development phases, promises of the organization's staff support should be given cautiously so that the contractor cannot use lack of resources as an excuse for not completing work on time. This section of the RFP should also indicate the terms of the contract: e time and materials, e time and materials with an upper limit, or e fixed price. “Time and materials’ refers to paying the consultant for all time allocated to the project at the vendor's rates and all other expenses incurred; no limit exists on reimbursement to the contractor, and the price connection to the end product is loose. ‘Time and materials with an upper limit” is similar; however, costs more closely relate to the product provided, and expenses incurred above a certain limit are not reimbursed. The fixed-price contract estab- lishes a direct relationship between product and costs; essentially, the contractor promises to deliver a product at a fixed cost and cannot change the price even though it turns out to be more or less. For any fixed - price contract, the contractor does only those tasks outlined in the RFP; other work has to be covered through a time and materials clause or an amendment to the contract. Consultants prefer ‘‘time and materials’ because it minimizes the risk of lost income; fixed price increases the danger. Organizations should go with the fixed price only when the requested product is fully defined and the contractor carries full responsibility for the effort. Otherwise, the contractor may shortchange the work to keep costs within the fixed amount and relations between the consultant and organization's staff may deteriorate. In the RFP process, the organization holds the greatest power and staff should use it by defining in the RFP, and requesting a prospective contractor's agreement to, the conditions and requirements that will become part of the contract. The requirements and conditions should give the organization strong controls over the contractor's performance and provide protection for the proper completion of products. Unless an acceptable reason is provided, any contractor not willing to meet the conditions should be automatically disqualified. The proposal section of the RFP requests information on corporate capabilities and refer- ences, the company’s plan to carry out the project, the approach in managing the project, the staff plan showing individual agreements to project tasks, staff capabilities (indicated through charts on levels of different relevant experiences and resumes in a specified format), and finally the cost proposal. The RFP should require mandatory minimum skills and provisions. The corporate references are valuable for confirming the bidder's past successes and uncov- ering potential problems. The procurement schedule and selection process concern information on key events (bid- ders’ conference, due dates, award of contract) and a summary of the evaluation process and criteria for judging proposals. The appendices should summarize information available and useful to bidders in understanding the project, such as the work already completed and technical requirements. This information enables the bidder to prepare a proposal more directly related to the needs of the organization. The evaluation relates to the nature and scope of the work to be performed and to the contractor's role in the project. Requests for supplemental technical support require a straightforward assessment of the proposed individual's technical abilities, related to the specific work to be performed. Consultant support involving the management of a project, as well as technical staff support, require more careful study. This involves evaluating manage- ment and planning skills, corporate and proposed individuals’ experiences and success records in designing and implementing comparable systems, technical expertise, their under- standing of the proposed project work and plan to complete such, and, finally, the competi- tiveness of the cost proposal. Cost should not be the sole or primary factor in selecting a 19 contractor. The final selection should come after careful consideration of all bidders. If none appears qualified to undertake the work, the bidding process should be started again rather than awarding the contract to an unqualified firm. Managing the Contractor’s Support Only the organization's active management of the contractor's support can guarantee that the services are satisfactory and the products valuable. The first step toward this is manage- ment’s insuring that consultants are fully aware of their obligations and responsibilities. The capability to hold consultants accountable for their performance and to control the cost of these activities comes from the contract and its explicit provisions of control. The contract should include statements governing (1) the scope and nature of services to be provided by the consultant, (2) the responsibilities of and resources to be provided by both parties to the contract, (3) the project schedule, (4) the method, schedule, and total amount of payment, (5) the procedures for amending or cancelling the contract, (6) the procedures for resolving disputes about the contract, and (7) the provision for withholding final payment until the contracting agency is fully satisfied with the project results. Other more specific provisions that strengthen the organization’s control over the contractor are: ® onsite requirements for personnel, eo commitment of personnel for the duration of the project unless the organization has given written approval for diversion of staff or resignation has occurred, ® ability of the organization to request removal of any or all individuals, training of the contractor's new personnel at the contractor's expense and not the organiza- tion's, training of the staff on equipment as the responsibility of the contractor, specific timetable for all major deliverables, specific arrangements for organization's approval of the contractor's deliverables, fiscal penalties if the products are not delivered on time because of the actions of the contractor or if the product is not satisfactory, ability of the organization to review any and all documents of the contractor's staff, eo estimates of computer charges for system development and potential penalty if overage occurs, ® correction of program errors within 2 weeks of written notice, organization’s ability to increase or decrease task requirements and corresponding charges, contractor agreement to use the organization's documentation standards, contractor observation of confidentiality standards of the organization, methods for resolving disputes, conditions under which the organization may cancel the contract, restriction of the use of design materials by the contractor with other organizations, and restriction of the contractor to hire staff from the organization. As mentioned before, the organization holds the most power during the RFP process. This leverage is lessened once the contract is signed. Any contract items not included in the RFP could be subject to intense negotiations by the contractor. All later agreements and under- standings should be put into writing and, if they affect the clauses of the contract, the organization should develop amendments. Control of the contract also depends on a clear definition of the work. The most common problem in contract administration is the use of vague project specifications that do not clearly establish what the consultant is to accomplish. Vague contract provisions are of little 20 value in providing direction to the consultant and lessen the contract's legal value as a means of protecting the organization’s interests. The statement of work should include the scope and specific tasks, products and delivera- bles, and the contractor's degree of responsibility. The frequency and method of reporting accomplishments should also be included. A poor contract can also cause the relationship between the State and the contractor to become acrimonious as they interpret the clauses of the contract and debate its significance. With a good contract, the organization should have a greater possibility of setting a positive tone and achieving the desired products. The one group receiving little attention in this chapter is the user. The next chapter focuses completely on the role of users and their leadership role in the systems development effort. 21 a Ill. Involvement of the User The successful development, operation, and utilization of an information system require cooperative and constructive involvement of users throughout the life of the system. Without this involvement, significant problems are likely to be encountered at many points but notably atimplementation when the design flaws become evident and revamping is costly. Following a discussion of the specific benefits derived from user involvement, the chapter recommends a formal structure for involvement that presents many significant roles for users and their contribution to each system development phase. Benefits of Involvement The involvement of users brings many benefits to the development of a system including designing the right system for the user, controlling and validating the accuracy of the system at different points, and establishing an understanding and acceptance of the system. Information needs and their relative importance are difficult to determine and more difficult to combine into a realistic system. Involvement provides the most important method for ascertaining these needs and judging the design’s feasibility and its compatibility with the user’s environment. This is summarized by one user's reason for involvement, “to keep the consultants honest.” The extent of involvement is a probable indicator of how well users have had their needs represented, heard, and addressed. Involvement is also a control mechanism on the accuracy of the system. Through their review and approval process, users confirm the validity of the needs assessment and planning documents describing the organization's problems and offering solutions. Then, at the end of the development phase, their testing the system verifies the integrity of its operation and assesses the readiness either for a pilot test in a real environment or for overall installation. These control points can save the organization a substantial investment in system develop- ment or installation by preventing a premature and unwise progression to the next phase of development. ' User involvement also develops interest in the system, gives affected persons an under- standing of what the system will do and what new methods are being sought and why, and reduces unfounded fears. These factors significantly reduce resistance to implementation and increase the probability of acceptance and effective utilization of the system. Otherwise, at implementation, the users might strongly voice disapproval and express antagonism to- ward the system. Disapproval and antagonism are difficult to address and can cause installa- tion trainers to shift their focus from teaching to persuading and cajoling staff to work with the new system. The involvement of management brings their support and commitment to the system’s success and increases their willingness to allocate the necessary resources at the appropriate time. Involvement may have even greater importance for centralized systems developed in a State-supervised/locally administered environment. It provides the basis for building a con- sensus and widespread acceptance and reduces the possibility of local rejection of the system. The method, quality, and quantity of user participation affect benefits derived from involve- ment. A new role for users is discussed in the next section. 23 User Leadership Users can have many different roles that can be valuable to an information system project. There is growing recognition of the need for the user to have a prominent position during all phases of systems development. This is necessary to achieve more completely the representa- tion of the needs of the user organization and to complement the analyst bias toward creating a design related more to the system's efficient use of the computer rather than the user's needs. Social service programs have many complexities that are considerably difficult for the analyst to understand and design into a system, particularly where the focus is on manage- ment information requirements. The user can acquire sufficient knowledge of the computer and system development methods to have an effective role in the project more quickly than an analyst can understand service programs and the related management decisionmaking necessary for developing an effective system. Traditionally, the user's role has been limited to individual consultation with the systems analyst and participation in an advisory group. Now organizations are appointing full-time user advocates for systems and in some cases establishing a user department. User leadership for system projects requires the appointment of at least one full-time person, the user advocate, who has the right combination of knowledge and skills. The person should be knowledgeable about the organization and its social service programs and be in touch with what is happening at the diverse levels from the field worker to executive manager. An understanding of computers and system development methods is a desirable background, but, unfortunately, few in social services have this. At a minimum, the person should ap- preciate the value of computers for social services and be willing to be trained in basic data processing. The user leadership role will also require logic and analysis, planning, interper- sonal relations, and management skills for carrying out the user/advocacy work. Obviously, the appointment of the user advocates cannot be a dumping ground for incompetents, but must be for the more competent and highly regarded staff members. The user advocate can have a number of roles depending on the organization's preferences. These roles include: mobilizer of user involvement, liaison between users and data processing staff, user spokesperson and decisionmaker, troubleshooter, information systems consultant, and e director of user efforts. In selecting the appropriate roles for the organization's user advocates, management must define the corresponding authority to be exercised, the interfaces with data systems, and the matters requiring the attention or approval of higher levels. The user advocate is the mobilizer of the user's participation in the project. The importance of this involvement has already been discussed. The advocate must identify the potential users of the system at all levels of the organization and determine the method and extent of involvement feasible within the project schedule. In another section on user groups, the many options available from single steering committees to multiple user groups and their short-term or permanent nature are discussed. Whatever involvement strategy is employed, the user advocate must integrate all activities and bring together the ideas and critiques for proposing effective system solutions and incorporating them into the system development effort. Another role for the user advocate is the liaison between the users and data processing staff, to facilitate communications and provide the proper interpretation not only of system 24 capabilities and constraints to the users but also of user needs and priorities to the systems analyst. The advocate helps users and managers know what to expect from an automated system and articulate their requirements. The systems analyst usually works directly with the users in close collaboration with the advocate. The user advocate should review and consoli- date all user recommendations and requests for consistency, accuracy, clarity, compatibility, and reasonableness with the complete system requirements and should advise from the user standpoint on the suitability of different general design strategies. At times the advocate must work extensively with users to clarify hazy ideas and resolve other problems with requests, some of which may relate to the computer's constraints identified by the analyst. For the analysts, the advocate is a single contact with whom they can address all their questions and make requests. Getting all levels of users to contribute their best thinking is difficult in the early and critical stages of a project, as indicated by figure 2, which depicts the level of user interest by system development phase. Users tend to feel not only that they have no time to analyze their information needs, but also that such analysis is not important anyway because the system is in the distant future and may never become a reality. Unfortunately, a poor definition of needs increases the chances of major gaps and system design errors that may be costly to correct if not identified until late in the project. In other words, the user's interest is lowest when the cost to fix an error or gap is lowest. The user advocate can modify this attitude or at least offset the negative situation through vigorous work with the staff, compelling them to take time to identify requirements. Figure 2 Level of User Interest by System Development Phase User Interest HIGH Low Requir G Detailed Sy Installation Operation Analysis Design Design Development 25 The user advocate also acts as spokesperson for user interest and views and the user approval point for the project's milestone products. The spokesperson role involves repre- senting the user perspective, insuring its adequate consideration during the system develop- ment effort, and pressing data systems to develop a reasonably user-oriented design. This usually requires approving all interim and final system reports and documentation related to the users. On all documents ready for review, the advocate must obtain input from other appropriate persons to insure a complete appraisal and should base his approval on other users’ assessments. Generally, an acceptance of the document authorizes the work to pro- ceed to the next step unless management approval is required. The “‘troubleshooter” is another role for the user advocate. This role generally surfaces at the time of testing, converting to, installing, and operating a system. The information systems consultant role begins when the system is operational and users want assistance on retrieving information from the computer, analyzing reports, obtaining additional information from the system, and interpreting its significance. Directing and organizing all user efforts for the project involve planning the user work, assessing and requesting user resource requirements, monitoring the users’ timely comple- tion of scheduled activities, negotiating agreement among different users, resolving conflicts between different user areas and between data processing and users, and, finally, briefing management on key areas. The user advocate reports on the project status, recommends management’s approval of work and proceeding to the next phase, requests allocation of resources, and presents issue papers on programmatic or technical problems for manage- ment’s resolution. Three phases of development—needs assessment, design, and installation—require sig- nificant user leadership and could easily be under the direction of the user advocate. In some cases, management may expand the role of a user director to include overall project responsi- bility for all or certain phases of the system, limiting data processing to the provision of technical services as part of the total project. User Leadership in System Development Phases The user advocate leads the user effort in all phases of system development, getting users involved directly as needed. Their knowledge of the organization’s structure, spheres of influence, functions, and procedures and their awareness of current and future trends provide a strong baseline of realism for the system that is probably most important for the needs assessment and planning phase. In the needs assessment and planning phases, the user advocate insures a correct state- ment of the organization’s problems and the development of effective solutions to address requirements. As a sounding board for design concepts, the advocate and users evaluate and advise on the suitability and realism of different design strategies. Part of this evaluation is determining the system's fit with the environment and its noninterference with the user's primary activity. They examine the adequacy of reports for present and future needs, the ease of new input procedures, and other areas relevant to users. The benefit of this involvement is the establishment of a formal document of proposed solutions acceptable to the users, followed by the validation of the system design. This validation determines whether the system is ready for the system development phase and prevents a premature investment of substantial resources. As the information system project moves into the programming and testing stages of the system development phase, the user advocate’s role shifts to resolving unforeseen design problems and controlling the system’s development in accordance with the previously ap- proved system specifications. Upon completion of the programming, the advocate partici- pates in the simulated testing of the system to validate the system's satisfactory operation. He also determines its readiness for a test in a real environment where it is possible to judge the acceptability of the newly operating system for full implementation. This approach insures the correctness of the system before its costly installation. The user advocate’s testing of the system provides a verification of the system’s operation beyond the verification of the technical team that produced the system. Testing also gives the user staff the necessary comprehensive understanding of the system essential in the de- velopment of user guides and training materials. Concurrent with testing the system, the user advocate is establishing the methodology for converting to and installing the system, preparing the training plan and user guide materials, and setting the schedule for the pilot tests and full installation. The advocate also identifies and handles any necessary preinstallation preparatory work necessary. Upon the acceptance of the new system, the focus is on its installation and on training all primary persons affected by the system. The user advocate contributes to the maintenance of the system through provision of regular training, answering questions for users, monitoring input and output, and dealing with problems that point to system problems to be tracked down and resolved. Unresolved prob- lems will adversely affect the credibility of the system and the integrity of the data base; therefore, it is important for the user department to maintain a log documenting all system- related problems and their resolution. This is essentially the establishment of quality assur- ance, error control, and troubleshooting processes. In addition, the advocate must evaluate the system and identify the need for system changes supporting their development, and subject them to user acceptance tests. Another area of significance is handling requests for information from the system. Methods of Involvement The user advocacy unit establishes a consistent, user-oriented approach during the de- velopment of the system and provides the structure for other types of involvement. Other methods of involvement are information sessions, short-term and long-term user groups for different management levels and functional areas, interviews, and lastly, the simulation of a “fairy-tale” system. Information-Sharing Information sessions provide basic facts and an opportunity for limited exchange and feedback with people and organizations affected in some way by the system. An information session is valuable prior to beginning the design to explain the need and expected approach, including the involvement of users. At the end of the design phase, information-sharing is necessary to inform people about the proposed solution, whom it affects, and when it will happen. This avoids the spread of wrong information that can create unnecessary concerns. The information session should occur prior to the introduction of the system to give advance notice on the implementation steps and psychologically prepare people for the upcoming changes. Postimplementation sessions provide an opportunity to discuss concerns, obtain recommendations for the system evaluation, and give the latest information on the system status and future directions. User Groups User groups provide a more intensive form of participation that can be structured in many different ways, from a single project steering committee to a network of user groups. Planning 27 the incorporation of user groups into the system development effort requires (1) identifying the intended users and other groups affected by the system, (2) determining the ideas and assistance each group could offer in the development, and (3) assessing the need for one or more groups and their short-term or long-term nature. It is also necessary to consider the project schedule, staff resources to lead the involvement, scope of the system, and the uncertainty of the design. Unquestionably, involvement brings many immediate and long-range benefits as already discussed. The project schedule must be developed to allow time for user involvement during planning and preimplementation phases; however, system installation dates connected with legislative or regulatory mandates may preclude any extensive participation, and the adverse effects will have to be addressed during the installation and evaluation phases. A user advocate must also have time available to work with the user group(s). Of course, the loss of time is usually more than offset by the instructive critiques and assistance offered by group members. When the system has a broad scope and affects many groups of people, more than one user group is probably necessary to obtain sufficiently comprehensive and qualitative ideas and reactions. A system planning effort initiated with much uncertainty about the design needs greater involvement to shape the system properly. Most user group involvement is representative rather than total participation. Unless the social service organization is small, the representation strategy is the only feasible approach in structuring groups, but it does suffer from the traditional question of ‘how representative is representative.” Sound, broad-based input requires at least several of the same group af- fected by the system, preferably with each member having responsibility to seek the views of similar staff prior to and after user group meetings. This encourages the surfacing of varied perspectives and different procedures that exist and should be addressed early rather than late in system development. User meetings with many staff holding the same position creates the opportunity for negotiating and concluding on the best strategy. Groups with single members representing different major interest groups have great difficulty in providing specific system guidance, but they may serve as a general sounding board. Foster care and child protective service systems may obtain sufficient assistance from only one user group, while the social service information system may require several due to its broader scope. The potential members of user groups for social service information systems are: caseworkers, supervisors, administrative staff of all levels, finance/accounting staff, statistical, planning, research, and evaluation staff, clerical staff, and vendors. Caseworkers and supervisors are essential group members for all service systems to insure the system places realistic demands on the worker and offers them “payoffs.” The support of administrative staff is important for the system to succeed in its objectives. Financial staff are valuable group members where the service system is handling service or foster care mainte- nance payments. Where it exists, union participation may be useful for the system’s accep- tance by the caseworkers. The voluntary sector's heavy involvement in the organization’s service delivery process may require its inclusion in user groups as well. The organization's requests for assistance and challenges to work partly determine the contributions of the user group(s) to the system development process. Another factor is the organization's desire for genuine participation rather than window-dressing consultation. 28 Where suggestions are not sincerely sought and evaluated and the staff member chairing the group fears loss of control over the development process, the group will probably remain silent and hostile during the design phase and later fully resist its implementation. To the extent possible, systems should be a product of joint ideas and labor between the user groups and project staff. The group can assist in developing the design approach and in carrying out some of the key tasks. See figure 3 for typical functions of a user group in the planning and implementation of systems. The initial approach with the user group may be a presentation of the documents, the data elements, flow of the data collected, and preliminary listing of the reports that the system might generate for the service workers and agency management. Questions and reactions should be encouraged and the agencies should be asked to evaluate the documents in terms of their own operations to see if the they will fit with the agency flow. Further activity can involve the group in reviewing more of the material designed for the system and providing suggestions. Figure 3 Typical Functions of a User Group Purpose: The mission of the user group shall be to identify supervisor/worker issues regarding the design and implementation of the Social Service Information System (SSIS) and to make recommendation on these issues and related problems to the user advocacy staff. General Functions: To be knowledgeable about the system and to express issues related to implementation and operation that are of concern to various types of workers affected by the system. Design Functions: 1. To understand the design, relate it to the operation, and identify problems with the design and needed improvements. To provide ideas on possible reports. To review and test draft forms and recommend changes. To review screens. To review and evaluate preliminary design work of the SSIS project team. To provide ideas to and/or review the final products of specialized user groups. To set priorities for the reports needed by agencies. To review the major design documents. ® NON EBN Pre- and Postimplementation Functions: 1. To identify potential problems related to implementation, including the effect of local agencies’ uniqueness. To provide input to and to help evaluate or review user guides and training plans for each subsystem of the SSIS. To provide input on the test data for each subsystem. To provide input on the processing of documents in the local agencies. To review the necessity of the reports in each subsystem. To discuss error reports. To discuss worker attitudes toward the system, to bring problems to the attention of the user advocacy staff as implementation of each subsystem proceeds, and to make recommendations as to possible solutions. 8. Toassistthe departmentin communicating implementation efforts and to provide a core of knowledgeable users able to assist in informing other agency staff. 9. To review policy and procedural changes for their potential impact at the worker level. Nn Noon» 29 A management user group may also be necessary to identify specific needs for information, processing, etc. During the preimplementation period, they could identify the impact of the new system on staffing patterns, funding requirements, data management, reporting proce- dures, training requirements, classification and compensation schedules, etc., on their opera- tions. In addition, the management group could assist in drafting needed policies and proce- dures of a management nature to insure an orderly transition from a manual to an automated system. The key to productive user groups is establishing a “real issues” agenda. The members work during and between meetings, resolving areas of disagreement in the group setting whenever possible and demonstrating the utilization of the input. Participation can be forced by insistently asking questions, presenting alternatives to determine the preferred one, and regularly emphasizing the seriousness of their participation. It is also important to match the tasks with the right functional or management level groups so that members are addres- sing issues on which they are experts. Interviews, Consultations Planning the system requires many interviews and consultations that involve considerable personal engagement in the system development effort. The consultations may occur at the operational level, working through the handling of finances or the assignment of case num- bers. Extensive interviews may be part of defining social service management reports, helping professionals unfamiliar with the value of information to determine reports needed. This individual participation helps promote understanding and acceptance of the system. Simulation of a Service System Defining requirements for useful automated information does not come easily when work- ing with any level of social service staff. Simulating a social service system is a method that allows users to experience a mock system and explore and define what they need and what does not work. Their reactions give an invaluable base for judging the suitability of the potential system and needs of users and the subsequent planning of the system. The State of Georgia used this methodology in designing a child welfare management information system. The Georgia staff studied the State of New York's child welfare system and developed a mock design for users to experience and evaluate. They trained selected groups on the “fairy-tale” system—eventually 250 people —and introduced staff gradually to the concept of a management information system, a system overview, and, finally, basic forms and reports. They increased the staff's knowledge of what could be available, letting different management and functional groups experience different aspects of the system in relation to responsibilities. The imagination and futuristic thinking of staff were stirred so that they could more precisely define what a system should do in Georgia and what particular design strategies were preferable. The intended users of most social service information systems are inexperienced with having useful information and well-designed systems. The fairy-tale system experience in the early system development phases gives users an opportunity to participate in a novel way, which can occur independently or in concert with other user involvement methods. Facilitating or Hindering Factors Organizations are likely to have greater user involvement when agreement on project objectives comes early and users are the sponsors or major supporters of the project. Facilitat- ing factors for involvement are a user director and advocacy staff committed to support the project and approve milestone products, sufficient advance warning to other users to obtain the commitment of their time and effort required at each phase, adequate time allowed in the 30 schedule for consultations and approvals, reports and presentations on the system's products that are intelligible to management and users, and wherever possible, a presentation of alternative courses of action with sufficient information so that management and users are permitted to make a choice of direction. User involvement is marginal in organizations where users have a poorly defined and limited project role, management does not recognize the importance of the user role, and/or data processing staff is initiating and providing leadership for the project. The project schedule can also inhibit user participation in the project if it lacks user approval points or does not allow time for obtaining and considering user ideas. Data processing staff can also kill effective involvement by holding back on the documentation and suddenly submitting a massive quantity of materials, such as an overwhelming 5,000-page document of system design. Poor communication between data processing staff and users is another inhibitor. Other factors negatively affecting user involvement are data processing staff's rejection of many user suggestions as not feasible or data processing staff's presentation of material after decisions have been made. 31 SH eI Ta Yo br pea I EY | RVR SRE RETRY 2a DI IV. Planning a Social Service Information System The early phases of an information system project are critical because they establish the need for the system and clarify what the system will do before beginning the costly develop- ment phase. Planning is important to assess the user requirements and current operations so that the system design closely meets user needs. If the system objectives and the correspond- ing functions and products are wrong, no amount of programming can make the system useful. The temptation can be great to leap from identifying the system need to immediately detailing and programming it, without realizing the disastrous consequences of a poor design. This chapter describes the interactive process of planning a system, moving through three levels of design—conceptual, general, and detailed, determining information requirements and specifying reports, forms, and the computer design. Within this planning process, thousands upon thousands of decisions are made to shape the appearance and operation of the system. This occurs in an environment where users are often uncertain about what they want and how they want it, and where users and technical staff may not agree on what the system should do. Taking the time to think through the choices and make the right selection contributes to the value of the system by improving the quality of the design, the key determin- ant of the system’s benefits. Time to identify design errors and omissions is also critical because the relative cost to correct them in the planning phases is much lower than in the later phases. On the other hand, the system cannot be all things to all users. The design process must recognize the probable costs of the system and the limitations of the computer so that the proposed system is technically and economically feasible, as well as suitable for users. The Planning Phases of Development Planning the system involves three successive phases of development: ® Needs assessment and requirements analysis, ® General design, and ® Detailed design. These phases provide three levels of design, from conceptual to very detailed, that on comple- tion can be transformed into an automated system. The needs assessment phase has two successive stages. The first is recognizing that a need or problem exists. It also includes discussing and documenting the need or problem and determining the applicability of the computer. Depending on the results of this stage, the information system project will or will not be approved to address the problem or need. The second stage analyzes the information system requirements of the problem or need and sets forth potential solutions and their feasibility and benefits. Based on the requirements analysis report, management can decide to proceed with the full planning of the system. The report then serves as the foundation for the design and a reference for all subsequent development phases. 33 Recognition of the Need or Problem The recognition of a need or problem potentially amenable to resolution by an information system may occur at any level of management of either programmatic or data systems staff within the organization. The scope of the identified problem or need may vary from simple to complex, as the following indicates: ® Problems with the operation of a system, ® Enhancements to an existing system based on an evaluation of problems and deficiencies, ® Automated system for new needs, or ® Development of the organization's master plan for data processing needs. After the organization is aware of the need or problem, a study may be performed to define the need/problem more fully, to judge its significance for the organization, and to determine the relevance of a data processing solution. Sometimes the value of an information system and the urgency of a need are so obvious that management may wish to proceed immediately to the requirements analysis stage. If undertaken, the study should focus on gathering additional information on the need, assessing the use of automated data processing, and developing alternative solutions. Wherever possible, the study should describe not only the relationship of the need to the organization’s major goals but also of the potential solutions to the data processing master plan. The end result should be a brief report providing management with enough information to understand the need or problem, the impact on the organization, and the opportunity for cost savings and improved performance. The contents of the needs report should include: ® A needs and problem statement; ® Potential solutions; ® |mpact on the organization; ® Relationship to the management information systems master plan; ® Time, cost, and resource constraints; ® Tentative cost-benefit analysis; and ® Requirement analysis plan. If an information system project seems indicated, an estimate of the probable complexity of the undertaking and a proposal for a requirements analysis and feasibility study should be made. The requirements analysis proposal should define the objectives, methodology, work plan, schedule, resource requirements, and estimated cost. Finally, the proposal should identify the products expected from the next successive stage of work. If management accepts the report and approves the proposed plan, the information systems project moves into the requirements analysis stage. The Requirements Analysis and Feasibility Study The requirements analysis is vital to defining the need/problem and proposing the general data processing strategy. The contents of the requirements analysis report should include: ® restatement of the problem, ® general description of the proposed system, ® constraints, ® expected benefits, ® alternative approaches, and ® recommendations, with a work plan and identification of resource requirements and a budget. 34 The requirements analysis report does what its name implies. It provides a broad description of the design requirements for the proposed information system, based on the initial analysis of the need or problem. The resulting report provides the first level of the information system design. The restatement of the problem/need elaborates on the needs study, providing greater detail on its nature, extent, causes, and consequences. For example, a description of the number of child abuse and neglect complaints and the role of reporting may indicate that the volume of reports will outstrip the organization's space and filing capabilities and adversely affect the maintenance of the central registry and the ability to track children. The requirements statement, which is a general description of the proposed system, covers the system goals and objectives, functions of the system, types of data to be collected, anticipated forms and reports, general procedures, and computer equipment requirements and access methods. The description should be as complete and detailed as possible. Even initial system interfaces should be included since this section comprises the system require- ments. It is also important to know the areas of the organization that the system will serve or affect and the ways in which they will be affected to insure full consideration of all require- ments. Some impacts may require policy and procedural changes. Analyzing requirements involves study not only of present conditions but also of the organization’s future plans and potential changes caused by internal or external forces. The proposed system description should be evaluated in terms of its capability to accommodate the tentative future. If it falls short, the design should be adjusted accordingly. The importance of the future of the design is obvious in the situation of complex systems requiring 5 years from design to implementation; the future may have become a reality by the time of implementation. Some indicators of change for social service agencies are pending State and Federal legisla- tion, draft Federal regulations or State policies, and new directions in service programs. A permanency goal orientation for the foster care program, for instance, could significantly affect a general social service or foster care information system. Other descriptive information to include in the requirements analysis on the proposed system are the benefits and constraints. The expected benefits of the system give justification forthe project and provide baseline information for evaluating the system's effectiveness after implementation. The constraints set controls on the project’s development and have many different sources—Ilegal, policy, financial, staffing, and technical. The requirements analysis report should describe the recommended and alternative methods for addressing the system requirements and provide a work plan, with projected time frames, resource requirements, and costs. The projections should be firm for completing the next system development phase, but can only be estimates on the remaining development work and the subsequent operating costs. The report must provide management with sufficient information to judge the proposed system’s significance and operational suitability and to evaluate its technical and financial feasibility. Generally, many competing demands exist for data processing resources, and, based on the report, management must decide whether the project is justified sufficiently to be a high priority and to allocate the necessary staff and financial resources. Justifying the project and reaching adecision on its priority status should involve considera- tion of the following criteria: e Organizational goals—The computer system is recognized as critical for improving the administration of social service problems, achieving the goals of one or more programs, or upgrading management techniques. e Savings—Over the long run, cost savings and cost avoidance made possible by the system exceed the cost of the system development effort and the operating costs. 35 eo Mandates—Federal or State legislation or regulations require reporting, tracking of chil- dren, etc., that in effect mandate an information system. ® No Alternative—Massive clerical data, reporting that exceeds filing and space capabilities, intricate tracking of financial data, or a heavy computational workload cannot be accom- modated reasonably without computer support. Approval of the project shifts the system development efforts into an intensive design phase. General Design and Detailed Design Following the approval of the requirements analysis, the general design and the detailed design willbe done. The general design proceeds from the conceptual design presented in the requirements analysis report, and the detailed design uses the general design document as its foundation. Both design phases focus on: Description of functions, Description of the data, Initial mockups of forms and computer-generated (turnaround) document, Listing and description of reports, Design of terminal screens, Listing and description of standards to monitor by the computer, Confidentiality and security requirements, Data base and computer design requirements, System interface descriptions, and Equipment requirements. The general design specifies what these products are and what the system must do to satisfy system objectives. This phase of the design concludes with a document oriented to manage- ment and all users. The detailed design produces system specifications for the user input (forms), output (reports), and screens, and the technical computer system design—file contents and formats. The major work completed includes report formats, designing and specifying transactions for input and output, designing the process for inquiries, incorporating any standards to be monitored by the computer, the data dictionary, and designing the system's structure (files and data base). This level of detail provides the basis for specifying equipment requirements and providing a final cost-benefit assessment and a plan for the subsequent system develop- ment steps. The detailed design document is largely directed toward data processing staff who must use the information to create the computer system. Study or Transfer of a Comparable System In evaluating various approaches to satisfying information system needs, consideration should be given to investigating other organizations’ systems that appear to be working satisfactorily and have similar characteristics to those desired. Such systems can be identified from a review of publications of relevant professional societies and discussions with know- ledgeable Federal agency personnel, other public agency staff with similar missions, and consultants. Another organization's system may serve either as a model for guiding the development of the new system or as a system transfer candidate. The use of an operating system may offer substantial savings in time and resources in the development of a new one, depending upon the level of transfer. 36 As a model, the operating system could provide concepts or techniques adaptable to the new environment. It can help an organization define more specifically its needs, evaluate the practicability of initial design plans, and uncover successful strategies and potential problems in the development of such systems. More specifically, a model of comparison by offering the components and choices of a working system facilitates users in defining information needs and evaluating the requirements for forms, procedures, reports, and system interfaces. The practicability of system objectives and early concepts can be examined under the light of actual operating conditions and the requirements definition or general system design ad- justed accordingly. Ideas for data handling concepts, reports, file organization, probable operational cost, and other areas can be most beneficial in reaching conclusions on the definition of requirements and estimating the resource requirements, costs, and time frame. Georgia's development of a child welfare management information system based on New York's system is an example of model transfer. A group that included key management of the organization and data processing and project staff went from Georgia to New York. They studied the New York child welfare system and evaluated its potential use for Georgia and were further aided in this effort by New York staff going to Georgia. Program managers and selected service workers contributed to the evaluation process and eventual design as well by participating in a training session on the fairy-tale system that created a simulated system experience and provoked positive and negative responses. These reactions combined with New York's system concepts gave much guidance to Georgia's development effort. The actual transfer of a system, moving the system from the operating site to the new site, is much more difficult to accomplish because of the need for compatibility between the donor and recipient environments. Transfer may occur at the design level or even at the operating software level. The more advanced level of transfer provides the greater potential savings, but it also presents more difficulties. Conceptual Framework for Information Requirements The initial step in planning is defining what the system must do and for whom to achieve the objectives and desired benefits. The system functions relate to the program focus and the specific objectives such as tracking foster care children, making service payments, handling protective services investigation reports, or performing the eligibility determination for all services. The thrust of a system’s functions may be operational support, statistical reporting, control over social service actions or procedures, or support for management decisionmak- ing. The system's functions and direction determine what data to collect, what computer processing should occur, and which reports to produce. This section presents the general framework for planning the system. Defining information requirements in conceptual terms leads to a detailed presentation of the processes for defining system reports, establishing requirements for standards, developing forms, and determining the final set of data needs. Figure 4 is a conceptual representation of asocial service information system data base. The upward-pointing arrows mean that the same data obtained for client processing can be used to meet information requirements at successively higher levels of management. The horizon- tal arrows depict potential information demands on the data base and representative outputs in response to those demands. Child protective services, foster care, and general social service information systems are increasingly accommodating the multiple requirements for operations, control, and management into one system. 37 Figure 4 Social Service Information System for All Management Levels Legislation, Demand Reports, Executive Orders, Top Study of Management Funding Changes, Information Historical Data Legal Actions, etc. (Planning) Identification of Operating Management Automatic Reports on Problems, Information skid Standards, Demand Requests (Control) Reports, Selective : : : Inquiries Scheduled Reports, Routine § 2 . ; Ss 2 § Standard Input - © c 85 88 8 i Inquiries HRI GE 3 a a a aq S (OPERATIONAL) The operational level information requirements are concerned with client identification, service delivery, resource utilization, and payments. For this level the system may produce purchase orders, vouchers, invoices, payments, and scheduled reports on workload identify- ing specific clients, resources, and actions due. Other examples of operational support are maintenance of enormous files for adoptions and child abuse and neglect or for tracking interstate transfer of children. The control (operating management) level information requirements are concerned with workload distribution, compliance with standards, and client outcomes. Automatic reports are produced for noncompliance and overdue actions; demand reports get requested in response to ad hoc requirements. Some typical control functions are monitoring the report of abuse and neglect investigations within the legal time standards and checking on the adoptive exchange registration of foster care children legally free and with the goal of adoption. Both aggregate and client-specific information may be needed. Top management-level information requirements are concerned with organizational goals, planning objectives, strategies developed in response to legislation, new regulations, funding changes, legal actions, and other demands on the organization to carry out or modify its functions. The process involves deciding on the resources used to attain these goals and objectives and on the policies to govern the use of the resources. Some typical information requests are the number of people served, average cost, outcomes, the number of people to be affected by cutback in services, and the financial implications for increasing rates for certain services. 38 Information must be focused for the particular level, the functions to be performed, and the specific decisions their users will be facing. Well-focused reports aid in making better deci- sions, and save much time and confusion in the process. It should be noted that the hierarchi- cal uses of information occur within as well as between different management levels in the organization. For example, service workers report to supervisors, who report to chiefs, who report to directors within the operational level. In the interactive communication processes within and between all management levels, synthesis of information is a constant requirement. The characteristics of information vary by organizational level and management function. Operational activities require the most accurate, precise, current, and detailed data and generally use data identifying specific clients or resource providers. Control tends to use the data in a less detailed form, but some identifying information will be necessary. Planning usually requires only summarized data, which is less accurate, more historical, and indicative of future trends. This framework of information needs, from very specific at the operational level to general at the policymaking and planning level, provides a reference point for defining reporting re- quirements for the different levels within the organization. The next section describes the process for defining reports. Defining System Reports One of the major products of the system is reports. A careful analysis of management reporting needs is essential for developing reports that are sufficiently complete and approp- riate to their intended use. In determining reporting requirements, all needed reports and the resulting requirements for data input, computer - produced data, and data relationships within the computer should be identified. Systems are not usually capable of meeting the demand for every user report and information request. The user must be made aware of this fact. A totally flexible system is impossible unless cost is unimportant and the herculean task of recording and saving every raw data element and establishing all possible data relationships can be accomplished. The final set of reporting requirements should reflect the critical needs of the organization. An attempt should be made to anticipate future demands and ad hoc requests. These efforts should reduce the risk of producing useless reports and allow greater capability to accommo- date future needs. Linking the system with areport generator and standard statistical software packages increases the system's flexibility to produce planned reports. The quality of the management reports depend upon the thoroughness of the design work, the system develop- ment constraints, and the design team’s imagination and familiarity with the social service organization. The process of defining reports is protracted and time consuming. Defining management reports is an iterative process of defining requirements, designing reports, followed by rede- fining requirements and redesigning reports as many times as necessary within a reasonable time frame to establish a complete and useful set. This effort is costly but worthwhile because reports are expensive to produce. The initial costs relate to the user advocate’s time for designing the report and data processing staff's time for preparing the system specifications; additional costs come from programming, testing, and documenting the program, and com- puter processing time for testing. The largest cost relates to ongoing production, which includes machine time for data retrieval and printing, paper, file storage, coding techniques, distribution costs, and user maintenance costs (binders and file cabinets). If the reports are thrown away or stacked in a corner after receipt, the costs incurred for producing the report are wasted funds and the users are likely to feel dissatisfied with the system. 39 Failure to identify all needed reports is also expensive. Addition of new reports or changes to existing ones may be possible only at a substantial cost if revamping the computer design or user forms is involved. Unearthing information needs in the design phase may require consid- erable investigative skills. The reports give visibility to the system, exposing users to their products and inevitably affecting their perceived value of the system and willingness to report data. Historically, many information systems, particularly in the human service sector, have not been sensitive to their users in two important respects: ® They have either provided the user with insufficient or incomplete data, or ® They have provided the user with voluminous, unmanageable data. The first condition usually applies to service workers, who directly feed data into the sytem and become frustrated and disillusioned with the system when it does not respond to their information requirements. This is particularly evident when a new system results in a net addition to the number of forms required. The second situation usually applies to administra- tive personnel who are inundated with computer output and are frustrated by the sheer volume of papers (Mott-McDonald Associates, Volume lll, 1975, p.1). It is important to develop the reporting around the following principles: ® Every user who inputs data must receive information, ® Statistical and financial reporting will be a byproduct, and e Generated information will be selective in nature. The first principle pertains, in most cases, to service workers. They are the individuals who feed the data banks and who maintain the integrity of its contents. If the information system is not responsive to their needs, the data base will deteriorate as will the quality of information generated for administrative purposes. The second principle pertains to obtaining required statistical and financial reporting as a byproduct of the data collected rather than as a focal point. This minimizes interference with the worker's basic processes. The third principle concerns providing selective information related to its planned use. The reports can be produced on aregular basis or an ‘as needed’’ basis with the appropriate degree of aggrega- tion for each management level. A wide realm of information needs can be accommodated without creating a ‘‘paper blizzard” (Mott-McDonald Associates, Volume lil, 1975, p.2). The typical user-oriented products of a social service system are: 1. Billing and payment documents such as: e Purchase orders, ® |nvoices, e Billing lists, and eo Checks with stubs or payment lists. 2. Index Cards. Inquiry Screens. 4. Reports: e Scheduled, eo Automatic, when certain conditions exist, or ® On request. The products replacing existing documents, files, or traditional statistical or financial report- ing may not be difficult to define if the thrust is to have a more efficient, streamlined collection and to maintain the same products. The others are most difficult to describe completely and quickly. w 40 There are three stages in defining reporting requirements— setting the stage, defining each report, and refining the parts. A document detailing all the reporting requirements should result at the end of this process. Setting the Stage for Report Definition The initial stage of defining reports has the design team acquiring a greater working familiarity of the organization and its decisionmaking related to the system under design. They must learn what the types of decisions for the different functions are, when and where they are likely to occur, and who the decisionmakers are at different levels. The decisions and their characteristics represent the information required to produce an effective information system. The user advocate plays a major role in this process. From this, the design team should be able to identify not only all potential users of the future system but also the general categories of reports that could be helpful. Now the design team is ready to begin work with users in developing reports. The team must provide the users with a clear understanding of the objectives of the future system, probable benefits, and realistic reporting capabilities. The users should be ready to identify general report needs in relation to the suggested categories and proceed to defining specifics. Multilevel groups, single-level groups, multifunction or single-function groups, individual consultation, or some combina- tion may be used to define reports. Many factors affect the process of defining reports that have value for the organization. The most critical may be management's and staff's capabilities to understand the system's poten- tial offerings. They must know what to request and then be realistic about the data system’s capabilities to convert programmatic information needs for decisionmaking into system requirements. Some users may not have the analytical ability to define their reporting re- quirements properly. Those with knowledge and previous positive experience in data proces- sing can strengthen staff's capability in defining requirements. The user advocate must work around the users’ limitations, provide supportive consulta- tion, and wherever necessary weed out ill-conceived and hazy ideas. Not only must the design team give users time to analyze their requirements, but also the users must take sufficient time to do so. The attitude of users toward the future system affects their participation in designing reports. Users must believe that identifying requirements is important and recognize the special significance of doing so in the planning phase. A lack of interest in the system and a feeling that “it does not do anything for me” or “it is too theoretical at this point’ adversely affects the planning of the system. Of course, the greater the span of time between defining report requirements and system operation, the more difficulty the user has in taking things seriously. A belief that the design team knows best and overreliance on their suggestions may also adversely affect the quality of reports. Reports are difficult to identify and define. The question “What information would you like out of the system?” is only the starting point in determining report needs. The quality of the response depends on how well the user has analyzed his decisionmaking and control func- tions in relation to the potential information availability. In human services, both management and staff may be unfamiliar and uncomfortable with using information and may give only a limited response to the question. A few staff eagerly awaiting the development of a system may request more than they can reasonably use. The user advocate needs to assist in analyzing information requirements, current and future. To stimulate the users’ thinking, the user advocate may suggest that staff consider reports needed for general management functions that the system is intended to address. Examples could be planning and policy development, staffing, supervision, budgeting, monitoring, and evaluation. The user advocate should ask the agency executive what information he needed in 41 the past that was not available and what information was useful. Reports related to program areas rather than general management may be of equal or greater interest. Users should be encouraged to consider reports for such areas as foster care, adoption, child protective services, adult protective services, adult services, day care, WIN (Work Incentive Program), etc. Once the user has identified one or more reports in this brainstorming effort, the report definition process can begin. Definition of Reports Careful analysis is needed to determine the information requirements for the selected reports. Client-aggregated reports can be developed in multiple ways, and statistical data can be developed on an infinite number of aspects of an organization's activities. Only some of these aggregations (information and statistics) provide a basis for making a significant difference in activities. The definition process helps determine the reports of consequence and the information to be displayed. Effective reports grow out of an intensive dialogue between the user and the system design team. In the development of statistical reports, collaboration between the design team and the organization’s evaluation and statistical staff may be needed to identify and select the most useful facts and indicators on reports. The human services sector has personnel oriented largely toward people and not toward numbers. Many are unfamiliar with any statistics beyond simple frequencies or counts. The percentage and its appropriate use is sometimes a mys- tery— even with staff who enjoy using the information from a system. Most data for management and planning are used in the form of relations between various factors. Examples are active cases per worker, the number of placements by the length of time in care, etc. Selecting the factors and their relationships and then determining the most important is a difficult undertaking. For the reports to be most useful, these relevant ratios need to be readily visible. This situation brings about a problem for the design team. The user advocate needs to work with staff to help them determine what ratios are likely to be important before the system is producing information. The user advocate walks the users through the following questions for developing reports: Name: What is a descriptive name for this report? Purpose: Why is the report needed and how will it be used? User: Who is the user and what will each user do with the report? Medium: Is a paper report needed? How large will the report be? Can microfiche be used? Would an inquiry screen be sufficient? Copies: How many copies are needed and for whom and in what medium? Frequency: How often should the reportbe produced? Is it the same foreach user? Description: What information is needed and how should it be organized for easy reading and understanding? Data/Source: What data must appear on the report and where will it come from? Priority: How critical is the report? Sample: What will the report look like? Credibility: What degree of accuracy is required and why? Replacement: What existing documents, files, reports, etc., will be replaced by the report? Consequences: What are the consequences of not having the report? Purpose. The report should have precise statements on its purpose and use in sufficient detail to confirm that the report is necessary and critical as opposed to being “nice to have.” Each user should be identified, and if the purpose varies by user, each purpose should be 42 identified by the user. The user should also have a good justification for the number of copies, the frequency of production, and the data elements to appear on the report. All data reporting has its costs, and even some usable data or computer calculations may not be worth the added cost. Therefore, it is necessary to define purpose and uses and what difference each can make, so the cost-benefit balance can be assessed. It is important to bring out what the report alone or in combination with others will replace (documents, files, reports, etc.) and the cost savings or cost avoidance associated with this. The consequences of not having parts or all of the report should be explored to evaluate further its value if the significance of the data remains unclear. Some initial consolidation or elimination of reports must take place. Description. The next step is describing the report if sufficient justification exists. (See appendix A, figure 1 for a guide to describing a report.) The user should write the description with some consultation from the user advocate. Some specific considerations that are often overlooked until the computer actually produces the report are: ® Issuing reports monthly, quarterly, and/or annually; e Displaying comparative year reports; ® Having totals at the end of a report or at the end of the information for each agency, region, and State; ® Having cross tabulations, percentages, other statistics; ® Showing at bottom of page items deleted from this report that were in previous one; ® Having report levels, with first reports being highly aggregated and depending on informa- tion shown, requesting a second, more detailed report, a third, etc. ® Determining which management levels should be informed when exceptions occur in standard policy and procedure. For example: Advance warning and overdues = Worker Overdues Supervisor Beyond 15 days overdue Region Beyond 30 days overdue Central Office ® Using the computer's special features to: 1. add, subtract, calculate, compare; 2. generate new information from original (e.g., length of from dates, age from birthdate); and 3. asterisking key items for any identified purpose. Refinement of Reports At this point it is necessary to review the full set of reports to determine if all recommended or needed reports are identified. All traditional statistical and financial reports related to the new system should be included unless they will become obsolete; this is almost always routinely done in a new system effort. More difficult is the evaluation of whether or not all levels are getting appropriate reports to support their decisionmaking and control functions. The user advocate may share the ideas of some organizational units or levels with those with weaker analytical skills to help them reconsider the possible uses of the system and their report requirements. The reporting demands of some individuals or organizational units may be greater than their capability to utilize them effectively. Once their list of reports is complete, study is necessary to determine the capacity of the position or unit to utilize and benefit from the reports. Questions to be considered include: What is the probable size of the report? How many is one person or 43 unit receiving per week, per month? Are they inviting a paper blizzard? Can they feasibly handle the reports? Should the development of reports be spread gradually over time, starting with the simple and concluding with the complex, so that experience can test the report's relevance and the user's readiness to handle them? In this instance, it is important to rethink the type and frequency of reports and to assess the possibility of consolidation to bring the requested reports in line with workload capacity. Looking at the total set of reports, it is important to identify overlapping and duplicative reports, some of which may have been requested by different levels or organizational units. Efforts should be made to consolidate as many as possible and bring together similar reports with different levels of summarization. If the future system will have online capability, the user advocate should determine how the inquiry screen might meet the need and present that as an alternative. The complete description of each report needs careful review and study to verify consis- tency, relevance, timeliness, completeness, and importance. The description statement should clearly explain what to expect from the report and should be consistent with the purpose and use statement. The purpose and user descriptions probably need further critical examination because they are still likely to be general. The purpose statement should really answer HOW the report will be used and WHY each user needs it for WHAT. Again, a judgment is probably necessary to assess the real need. The following questions can help in reaching this decision: 1. Are the identified uses of the report valid? 2. Are all the purposes (uses) of the report defined? e What are they? ® Are other data elements necessary to satisfy other uses? 3. Is the purpose for each prospective user stated? 4. Are the identified users valid? 5. Are there other people who could or would use the report? e Who are they? e How would they use it? eo Would they require additional data? 6. Are the consequences for not having the report serious? The schedule and frequency may need refinement. Greater frequency may be helpful for some reports and lesser frequency for others. A critical factor on frequency is the user's ability to handle the information effectively. The frequency may also vary by user and must be specified. Users may also wish a report staggered by, for example, localities and program areas over the year to coincide with their work plan. The staggering should be included in the report description. Frequency of reports needs to be coordinated with the optimum frequency or use for the data by those receiving them. Some reports are essential weekly or at the end of the month, while others are used only quarterly or annually for planning purposes or annual documents. The format of the report is the layout of the information; the sequence is the outline order of information—that is, how the information should be organized. The key is how the information is looked up and used. Several sequences may be identified. For example, an action due report on protective service reports may have the following sequence: action due (first sequence), most overdue action (second sequence) and case name (third sequence). The design of a sample report shows what the actual report will look like and provides a final test of the report’s value. The sample report should contain the full range of data and possible variabilities. The mock-up report would then allow questioning of what the user will do with 44 various pieces of data. Under questioning, some data may hold no interest, others may lead to action, and some may require additional information for action to be taken. This is the “consequence test.” Calculated data elements (for example, age derived from birthdate) are more complex to provide then straight ones (birthdate), so further questioning on their need and the complexity of calculation may be necessary. During this analysis stage, the questions to ask are: 1. What are you going to do if you see x ory or z? 2. Is there enough information in the report to be meaningful? Can you think of additional information needs? 3. Are all the designated data elements appropriate? ® Are other elements needed? Why? (Identify use) e Should some elements be deleted? Why? 4. Would the data elements on the report be clear enough for an average employee to readily understand without comprehensive training? 5. Does each report contain enough aggregate totals of information to be helpful? 6. Are all the comparisons that may be made within the report present? For example, are more percentages needed? Is more extensive analysis needed? 7. Are comparisons over a longer or shorter period necessary for the report to achieve its purpose? The conclusion of this test identifies data elements that may be eliminated, enlarged, or added. The validity of the report may finally be determined as weak, and therefore the report should be abandoned. Different users of the same report may have slightly to radically different content and format requests. When this occurs, the user advocate must negotiate a consensus and in some instances decide alone on the best format. With agreement on the reports and the content, it is important to review the priority status of each report and rank them in order of relative importance. If there are many requests for reports, some form of priority setting must be undertaken to bring the needs for information in line with the resources available for filling them. These priorities can also serve as the basis for scheduling their development. Clearly, the system should provide information and reports for decisions where system information can make a significant contribution. It is important to narrow the set of decisions to which the system intends to be responsible to one of manage- able dimension. Evaluating the critical nature of the report and its rank compared to other requested reports and identifying the derived benefits and cost savings allows final conclusions on what reports the system should produce. Concurrent with this effort of defining system reports are other related activities that feed into and modify the process. The other activities are the study of the standards to be incorpo- rated into the system, the methods for collecting the data, the characteristics of the data, and the computer design required to produce requested reports. The usefulness of various kinds of data needs to be weighed against the cost of getting them, and against the reliability, validity, and timeliness of the data that can be obtained. These areas are examined in the next sections. 45 Information Requirements for Standards Information requirements exist for monitoring standards of performance that have a base in law, Federal or State regulations, policy, or administrative procedures. Since monitoring compliance with standards is a principal control task of a manager that the computer can improve significantly, the information requirements for standards merit special discussion. The computer improves the operational and management control processes significantly in several ways. ® The standard can be more complex. Computational simplifications are not necessary. ® More standards can be measured than in manual processing. ® The computation of deviation and identification of cause can be more sophisticated. Management can examine successive levels of detail data to locate causes behind the condition. ® The computer can monitor performance continuously rather than just periodically, and the reporting can use irregular time intervals (Davis, 1974, p.134). All of these are difficult if not impossible to do with manual handling of information. The computer supports the control process by comparing the operational transactions entered in the system with the predetermined standards, budgets, etc., programmed in the system, that define management's expectations about performance. These standards may stand alone or be part of a monitoring control effort that uses both the computer and manual processes. To effectively support management in the control process, the information processed and produced by the computer must have a high degree of validity, accuracy, and precision. The control system requires six elements: 1. Predetermined standards of performance exist and are incorporated in the computer, 2. Management and workers have a common understanding of standards, 3. The computer can compare and evaluate actual performance periodically or continually against the standards, 4. A deviation report goes to management, 5. Management takes appropriate action to change current or future performance, 6. In the event of failure to bring unfavorable performance closer to the standard, a method exists for higher level management to take appropriate action. (Davis, 1974, p.135). The system may monitor and control compliance with standards through several methodologies: edit criteria, advance warnings, exception reports, funding controls, identificaton of wrong actions, and others. Unacceptable actions and plans may be rejected before they occur through the use of edit criteria. Edit criteria is the system's check on particular data elements for accuracy, complete- ness, and consistency in terms of conditions specified in the computer. Some edit criteria relate to standards; others relate only to the accuracy and consistency of the data. One example of an edit criteria related to a standard is that a client who is not currently identified as eligible for receiving services may not have any services ordered until the eligibility status 46 becomes current. In effect, the use of edit criteria prevents noncompliance with standards. The system may produce an error report listing the unacceptable service order and giving the reason. The advanced warning is a report that informs personnel that required actions are due or that certain situations have changed that could affect compliance with standards. For in- stance, the client's eligibility determination must be made within 30 days for the client to continue receiving services. Or, a notice that a day care provider will no longer be approved means that the approval must be renewed or that the client's child must be transferred to another provider to continue day care services. Exception reports show a variance from planned performance— overdue action—by more than a threshold value. It isimportant to define at what point various levels should be informed for what standard; arrival at that threshold value automatically triggers a report identifying the actions out of compliance. Below is a possible method for structuring exception reports: e Advance warnings and overdues go to the worker, e All overdues go to the supervisor, ® All exceptions beyond 15 days overdue go to the director, e All exceptions beyond 30 days overdue go to the regional office, and ® All exceptions beyond 60 days overdue go to the State office. The system may also include controls related to: allowable services—services are included in the title XX plan, client groups—foster care, etc., may be entitled to services other groups are not, client need—day care can be offered only for employment or protective service needs, funding—payments for services are within time standards, expenditures within budgeted amounts, funding sources allocated to the right services and client groups, and e approved vendors or providers—services are requested only from approved resources, the contract date or amount is not exceeded. Any data entered out of compliance, including purchase orders and invoices, would be rejected, producing an error message. Appendix A, figure 2, gives the standard format for specifying the rules to be monitored by the computer. Special documentation is essential for all standards monitored by the computer to maintain a current and complete list and to insure the incorporation of all changes, which may be considerable over time. The suggested format can serve as the base to evaluate and determine what standards to include in the system. The new system may be limited in the number and type of standards that can be accommo- dated in the system. Therefore, an evaluation of each proposed standard and its relative importance is critical. A statement of the purpose of the standard, its legal or regulatory base, and the consequent benefits, cost savings, or penalty avoidance are indicators of its value. Another measure of significance is the anticipated corrective actions on any deviation. The practicality of including the standard can be derived from the user’s description of the method for monitoring and the response time. The method of monitoring gives the analyst the information needed to assess the complexity of the standard, a ‘ballpark’ cost, and the system’s capability to include it. The response time defines how fast the control and identifica- tion of deviations to the service worker must occur so that the standard’s inclusion does not interfere with the service delivery process. 47 Forms Any automated system imposes an unavoidable burden with the forms caseworkers must complete to provide the required information. The extent of the burden depends on the quality of the form design, the fit with the work flow, the data elements collected, and the workers’ perception of direct and indirect benefits for themselves and the service programs. This section presents some guidelines for developing forms that are acceptable to workers and insure the feasibility of data collection. Many factors affect the quality of the data collection process and result in related form(s). Quality is a measure of the compatibility of the process with the work environment and of the reduction of negative impact on the time and effort involved in collecting and reporting the data. The design of data collection procedures is difficult and time consuming. Only careful analysis of jobs and processes combined with imaginative consideration of the choices in data collection techniques can provide the best possible design. This analytical process involves answering the following interrelated questions: ® Clustering—What data elements correspond to what positions and organizational proces- ses? e Compatibility—Are the proposed data collection procedures compatible with the work environment? e Ease—Are the data collection methods easy to use? ® Feasibility—Is the data set feasible in light of the proposed data collection design? ® Review and Feedback—What review is necessary on the data collected and how will feedback occur on the quality and quantity of data provided? Clustering is the determination of which data elements should be collected together and sets the parameters for the data collection design. The identification of such elements emerges from the analysis of the organizational processes from which the information comes and the determination of who is the information provider. From this clustering, the system designer can determine the combinations of data needed. The next step is to fit the data collection with the flow of work so that compatibility exists between the system’s input requirements and the work environment. Accommodation of compatibility facilitates complete and accurate reporting of information. If the input proce- dures do not follow the workers’ activity flow, either the day-to-day work becomes harder or the workers resist providing the information. With a protective services information system, for example, a system requirement to provide demographic and family stress data after the first investigatory visit is in many instances impossible and could interfere with achieving the purpose of the initial family contact. Any mandate to report the information immediately leads to providing bad data—excessive reporting of ‘unknown’ or guesses. A good design allows for the initial collection of known information, with the provision for adding more detailed data as the situation becomes clearer and more defined. The timing of the data collection also affects the compatibility. Some systems allow daily entry of data while others permit changes only monthly or quarterly. The ability of the worker to enter changes when they occur is easier than having to remember the changes until the end of a reporting period. Daily reporting promotes the provision of complete, current data and reduces underreporting and perpetuation of outdated information. Other considerations for making data collection compatible with the work environment are discussed next. Form Design Techniques Different techniques exist to streamline and facilitate the data collection process and even make reporting easy. The design of forms and procedures should place the least burden 48 possible on the staff, such as structuring the form to serve as the basic, unduplicated source document in the manual records, as well as the system’s input mechanism. In some cases, the entry of information can be part of a larger task—for instance, computation of a client's eligibility for services—and data reporting becomes a secondary factor in the performance of a primary function. Online systems may offer the opportunity to enter and inquire about data without the use of a form. Forms are the primary means of collecting information, even in online systems. Therefore, it is important to study the techniques that make it easy to record and enter data. Some considerations in forms design are: number of forms, size of the form, type of form, spacing and form readability, self-explanatory data elements and values, English terms and abbreviations, updating the data, sharing the form, and ® capability for changing or adding elements and values. With the advice of the analyst, the administrator and users must choose the best forms strategy for the system. This involves selecting the right combination of features at the right price, weighing computer concerns versus user concerns and the relative merits of two good but incompatible user-oriented techniques (for example, two-page form with values vs. one page without values). Number of Forms. The system should have the minimum number of forms necessary to perform the required functions. For example, structuring the reporting forms for a child protective services system on the family rather than on each individual child can dramatically reduce the number of forms. This is also true for a social service system using the same form for identifying the case and household members. While some families are always larger than the number of persons accommodated on the form, a second page of the same form can allow the reporting of additional members. The same principle applies to other functions of a service system. For instance, a service plan may also suffice as a purchase order or voucher for services. Size of the Form. The size of the form can make a difference in its utility and its convenience for copying, sharing, and filing. An 8-1/2 by 11 inch form can be placed in the folder and may replace previous manual documents, especially if the form is readable and has space for free-form input. Caseworkers consider these features important and strongly request them during their participation in the system's design or the subsequent evaluation of the operating system. Their preference is also for an 8-1/2 by 11 inch form with the printing on the short width. Ifinformation is too great for one page, an alternative is a form double the standard size that can be folded and still conveniently placed in the file folder. Type of Form. Choices exist on the type of form that the system could use. Essentially, two types of forms exist, with variations on each. The first is an input form that has no counterpart generated from the computer. Any additional information to be entered requires the use of a similar blank form. The second is a combination input form with a counterpart document, a turnaround, produced by the computer for future updating of the same or additional informa- tion. The first type is significantly less expensive and is appropriate for situations with a low volume of data and without successive layers of information requiring updating. A copy of the initial entry may or may not be retained for reference. A second type greatly facilitates the reporting of information because the basic data are already present on the turnaround document and only a changed or new element needs to be noted. This form strategy is useful 49 for high-volume data involving successive levels of changes over time and for staff who grumble and resist providing data. Texas has developed innovative turnaround documents of three pages—the first, as the turnaround from the input; the second with only key data to record the changes; and the third, a copy of the update. These forms are expensive and should be considered only for the most critical data collection activities. New York offers another alternative for some turnaround documents, which is the printing of the turnaround on standard computer paper in report format that keeps down costs and allows the immediate printing of forms in remote sites. Spacing and Form Readability. The utility of the document corresponds to the visible meaning of the information and its readability. Good spacing between words and plenty of space between lines, clear headings, and self-explanatory data elements improve the readabil- ity of the form. Numerical codes reduce the amount of space necessary to record and report information but also adversely affect the readability of the form. No one understands the meaning of a sheet of numbers. Readability is important for all documents retained by users for their records. The significance of self-explanatory elements and English terms for code are discussed further. Self-Explanatory Data Elements. The form is easier to complete when the data element names are self-explanatory and do not require checks on their definition. It is also preferable to include self-explanatory values on the form wherever possible, but their inclusion could make a form too busy or create a multipage document. Texas’ social service system shows the values on the input documents; in cases of elements with many values, a sheet is attached at the back of the document that can be seen at the same time the document is being completed. The display of values is an effective forms strategy for users who are working under pressure and are not likely to complete the information accurately if they must remember values or use a cumbersome look-up procedure. Less satisfactory alternatives to the inclusion of values are handy worker tools such as a ‘cheat sheet,” plastic cards with the elements and values back and front, or rolodex card holders. User guides are generally too ponderous for the quick reference checks needed by the impatient caseworker at the time of completing a form. One problem with forms printed with values is the costs incurred when values change. A forms revision is an additional cost and the obsolete supply of old forms is a wasted expense. Sometimes organizations refuse to destroy the obsolete form and use it until the supply ends, risking incorrect data entry and inconveniencing staff. English Terms. The inputdocument may require the recording of data elements in allnumer- ical codes for English words and abbreviations; if a turnaround document exists, it may have codes and/or English. This issue is important when the document does not have values identified and serves purposes beyond entering data into the system. Users prefer English words and abbreviations for ease of use and understanding the situation reported, while data processing staff want to use all numbers to maximize the computer's recording and printing and the form’s space. Numbers allow a great deal more information to be recorded and printed on one sheet. A compromise is to use numerical codes on the entry of information and to print English words and abbreviations on the turnaround document. In this situation, it may be necessary to list the codes at the bottom so that the user can determine if a problem in coding or data entry produced incorrect information. Updating, Sharing, Changing. Other considerations in designing a form include updating, sharing, and changing elements. Updating has already been partly covered in the discussion on turnaround documents, but it is important to recognize again that the design of data collection procedures must take the updating of data into account. The turnaround offers the best strategy for implementing a form that allows easy updating. It also facilitates information-sharing by producing enough copies for all workers involved in the case. Chang- ing elements and forms is easier when elements or values are not preprinted on the form. 50 User Versus Computer Concerns Computer concerns emphasize the most economical use of the computer. Some of these are using codes, displaying as much information (preferably in codes) as possible within as small an area as possible, using standard computer paper, and printing horizontally rather than vertically. User concerns center around using English words and having plenty of space. Ideally, the computer allows the entry of free-form words and prints them on the form. User needs are not always compatible. A request for a one-page, 8-1/2 by 11-inch form may not be possible unless the user is willing to sacrifice readability and let the form become ‘busy’ for the convenience of one sheet, or is willing to have two forms rather than one. These choices are not easy, often requiring judgment as to the best strategy in the milieu of conflict and disagreement. Too much time cannot be spent on good forms design. Good forms design facilitates the completeness, accuracy, and consistency of data and reduces the cost for monitoring data quality. The user advocate must represent the needs of the user and negotiate the balance between the user and computer with the design team. The next section discusses the method for evaluating the necessity of collecting each data element. Again, the process is concurrent with defining reports and designing forms. Determining the Need of Data The system should collect only the information necessary to accomplish its objectives. Extensive, time-consuming, and careful investigation and analysis are necessary to identify the information that meets this beguilingly simple but complex criterion. The decision to select certain data elements and reject others for inclusion in the system must be based upon an assessment of the feasible amount of data to collect and an examination of each element's characteristics in terms of relevance, availability, and reliability. The study of the data elements may go through several increasingly detailed analyses of the elements’ feasibility and value before a conclusion occurs on the final set of data requirements. This process deserves sufficient time in light of the fact that evaluations of operating systems have revealed that collected data are not used and are no longer what staff want and the right information is often not in the system. The data’s feasibility, relevance, availability, and reliability are each addres- sed independently. Feasibility Feasibility is a question of quantity and capability: How much information does the system need to accomplish its objectives, and what is the capability of the staff to provide the data without causing degradation of normal work functions? Another issue is the computer's capacity to maintain and manipulate data at moderate cost. Each data element has costs, many of them hidden. The primary and most overlooked cost is the time of a worker, which reduces the time to provide services to people, for example. Other costs relate to the time of an operator to enter the information into the system, the computer processing time, and computer storage. Still another set of costs involve around the prog- ramming, documentation, training, tracking, and the later changing of the element. The analysis of information requirements must conclude on data elements that meet in- tended uses of the system and that can reasonably be provided by staff. The proper selection of the data elements requires full study of the elements’ relevance, availability, and reliability in conjunction with the development of feasible collection methods. If the forms and other data collection methods cannot be designed to accommodate easily all information requirements, it may be necessary to reexamine the utility and relative value of each element, and possibly narrow the data set. 51 A tendency exists among program staff involved in the system planning to want everything for fear of leaving out something significant and to ask for too much information without realizing the cost. Many people designing systems have planning, research, and/or systems backgrounds and do not understand what workers do, what it means to request information, and that, when a worker spends a large percentage of time on data collection, the likely results are high levels of worker dissatisfaction and poor data accuracy. Any elements identified solely for the purpose of research and evaluation should be excluded. Relevance Relevance relates to the information value of data elements. The relevance of each data element should be assessed according to its usefulness in performing functions or answering certain questions relating to the system’s objectives. It is extremely important to justify fully each element and to explain how it will be used. A full description and understanding facilitates the acceptance of the elements as a reasonable data collection request. The relevance of the information to the information provider is the most important factor affecting its accuracy. The best incentive for information to be collected and reported accu- rately occurs when the data directly relates to the person's immediate work. For example, when information entered into the system allows the client to receive a purchased service and the provider to receive a payment, the social worker is motivated to enter and update the data. Another type of direct benefit is when the data provide a management report useful for the worker, such as an action due report. This is a reminder to schedule and complete certain activities during the month and eliminates the necessity to maintain a manual reminder file. Where the data do not relate to their tasks, the workers must see how the data are relevant to other organizational functions. Workers’ understanding of the value of certain data for plan- ning and their indirect benefits affects workers’ willingness and accuracy in providing the information. Training may be necessary to help the staff appreciate the value of data, since workers must be convinced that the purposes of the data are important and affect them— even though only indirectly. Otherwise, the data in the system may be unreliable. The process of assessing the utility of data elements is discussed in the sections describing the determination of information requirements, standards to be monitored by the system, and defining reports. Availability and Reliability Availability refers to the likelihood of workers obtaining and reporting the information; reliability, to the likelihood of different workers reporting similarly on the same situation. Low availability causes a high proportion of missing or unknown responses, and low reliability produces inconsistencies in responses, both thereby adversely affecting the quality of the data for management reporting and statistical analysis. Consequently, the characteristics of availability and/or low reliability are important considerations when deciding upon the re- quired data set. The inclusion of a data element on a form does not guarantee that the worker will report the information regularly. The reporting may relate tc the availability of the data. Certain kinds of data are readily available, while other data have inherent collection difficulties that may dissuade the worker from attempting to obtain them. The reporting of some data requires probing, searching for the answer (education levels), overcoming bureaucratic processing (social security number), or obtaining a professional diagnosis (mental retardation). Further- more, a reluctant or a hostile client may refuse to divulge basic information, and, as in the case of a protective services investigation, the provision of service is primary, not the uniform collection and reporting of demographic data. In a few situations a worker may perceive a risk or liability in providing certain information (family stress factors such as alcoholism) and may 52 fail to do so. Experiences of other States or localities may indicate which data elements present availability problems. A reliability test is necessary for each data element and the associated values. The test must measure whether the elements and values are sufficiently precise and mutually exclusive (that is, no overlapping categories) for workers to understand them and to be consistent in select- ing elements and values when recording similar events or situations. When human service information systems include some information of a subjective nature, such as parental condi- tion of a foster care child, the examination of the elements is more difficult and also more critical to insure clear definitions and uniform interpretations. Parental condition could be interpreted as the underlying factor for the child's entry into care or as the need to be addressed for returning the child home. Several different approaches exist for assessing the reliability of data elements. One is evaluating past experiences and those of other States or localities in recording and using the proposed data elements and values. A second is relying on the work of previous system designers or researchers who have addressed the reliability of different types of information; these investigations may have been special studies related to the reliability of particular data elements as part of a formal system evaluation. [Note: James R. Seaberg and David F. Gillespie have tested the reliability of some child abuse and neglect data in their work at the University of Washington School of Social Work. See their article *'A National Child Abuse and Neglect Databank: Inter-Reporter Reliability’ (California Sociologist, Volume 1, Number 2, Summer 1978.] There is a more direct and immediate approach for measuring reliability. After a training session on the use of the data set, caseworkers could receive a group of hypothetical cases on which to complete the proposed form. The level of agreement among caseworkers for the hypothetical cases would indicate the reliability of the data elements. [Note: The American Humane Association presented this as a strategy in their unpublished document ‘“‘Recom- mended Minimal Data Set: Final Report” (1979).] This approach could help reject elements of high unreliability and identify and modify any ambiguities which persist for elements, values, or definitions. Mandating data elements also relates to the reliability of the information because it requires workers to report all data and therefore improves the reliability of the data base for aggregated reporting and statistical analysis. One perspective is that if the data element is sufficiently important to be included in the system, it should be mandated. This requires careful consider- ation. By itself, mandating elements does not guarantee completely accurate reporting be- cause workers may guess or record “unknown,” but it does insure a response and increases the chances of known information being reported. Data Dictionary The conclusion of the investigation and analysis of the data elements determines what elements are necessary and worthwhile to collect in the system. This allows completion of a major planning document, the data dictionary. Figure 3 in appendix A shows the primary description required for each element. The description and purpose are straightforward. The source document is the form on which the element is reported and reporting responsibility is that of the information provider. The values are the multiple or mutually exclusive responses used by the worker for reporting a data element. Other parts of the dictionary outline are more difficult to define. The edit criteria are the checks the computer makes when a data element is reported. For instance, a child identified on foster care must have a custody date. A crossfield edit is the checking on two or more related elements when one of them is entered. For example, a foster child reported as eligible for Aid to Dependent Children income maintenance payments must have recorded in the system a custody date and commitment by the court. 53 History requirements involve defining the number of events that must be kept in the system. Examples are the number of placements of a foster care child, each change in the foster care permanency plan goal, all services delivered. Choices for keeping the history of a data element cover the range from retaining all occurrences, to retaining a specified, limited number, to keeping only the most current. In the last instance, the latest entry ‘overlays’ or covers over the previous record. Another key aspect of history requirements is specifying the length of time the data is kept, either in the online computer system or on a historical tape. This time may range from 1 year to 3 years to 5 years or more, depending on audit and other purge criteria. The decision on history relates more to management uses of the information than to opera- tional uses. The data processing members of the design team expand on the initial data dictionary to include a data element number, a list of data files accessed, the computer's physical charac- teristics, and the frequency of occurrence on the data base. Some of these are not completed until the development of the system. Computer Design The computer design requires careful planning concurrent with the definition of reports, forms, and processing requirements. The design of the system should take into account the adaptability and responsiveness requirements of social services and be structured flexibly. Systems must frequently adapt to unanticipated changes in law, regulations, and policies involved in the delivery of social services, and they must also respond to operational changes. A flexible design accommodates adding or deleting data elements, responding to new re- quirements, and producing special reports on request. The system’s requirements for data collection and reports cannot become final without considering their implications from the technical perspective. The limitations of the equip- ment or the costs associated with the information requirements may cause reconsideration of the reports, the data to be collected, and the processing for monitoring standards. Much discussion needs to occur among the project team, user advocacy staff, users, and eventually management to arrive at the final set of requirements that are the most valuable and economi- cal for the organization. A major decision in computer design is whether the system will be “batch” or “‘online.” Batch refers to organizing the data collected from all sources into small stacks—*‘control batches’ —for processing into some machine-readable form and entering into the computer on a scheduled basis such as every 24 hours or monthly. Batch processing is simple, straightforward, and economical, and lends itself to optimal machine utilization schedules. The disadvantage is that the products are subject to the production schedule that best fits the needs and requirements of the computer hardware and not the users. See figure 5 for a typical example of batch processing. 54 Figure 5 Typical Example of Batch Processing Output Input Cards Punched Input Error Valid Listing pp Run A Case Number | Master Case File Process Input File Modified Case File Select Print File y Turnaround Documents “Online” refers to the capability of communicating directly with the computer system to allow data entry, inquiry, or printing from locations remote to the computer. Data may be captured at remote sites and entered to the computer over telephone lines. Computer reports may be produced at remote locations through the same lines or generated centrally. Site and 55 even State data may also be available for inquiry at any time during the online period through a screen or remote printer. A more intensive use of online processing involves the remote site capturing the data at its source and providing information when needed. Online processing also may provide the user extensive control over his operation by decentralizing to sites the control over data entry and report generation. See figure 6 for a typical example of online processing. Figure 6 Example of Online Processing TERMINAL TERMINAL TERMINAL TERMINAL INPUT AND INQUIRY AT USER SITE ERRORS MAY BE TRANSMITTED BACK TO USER SITE IMMEDIATELY -FOR CORRECTION Host INPUT DATA EDITED IMMEDIATELY Computer Input Data Processed Turnaround Documents The online system is more responsive to the user's need for accurate, timely information. Batch processing, in which documents are entered and processed no more frequently than overnight and errors are returned later, is slow and cumbersome, especially where multiple distant sites exist. On the other hand, the online system can transmit information to the host computer and edit immediately. If any error is detected, the screen of input data is returned with the appropriate error message. If no errors are detected, the transaction is completed and the data are stored in the data base. Inquiry into the data base finds the most current data available. Another possibility is a combination of online data entry and batch update, which generally occurs overnight. 56 The online system makes possible the reduction of voluminous reports and the flow of paperless information. Whenever the organization has or plans online capability, the planning process should carefully examine the use of data entry and inquiry screens on the terminal as an alternative to forms and reports, respectively. Service workers may be able to enter information on a case immediately rather than recording the data on a form to be entered by someone else, and immediate access to the same information through the terminal may preclude the need to retain a form in the record. A massive report on available resources may also become obsolete via access to a resource inventory. New computer technology creates new possibilities for social service reporting that should be considered carefully in the design phases. Another advanced technique in data processing is the use of a data base management system, which is a newer, more flexible method for structuring the data to meet the needs of various users. The traditional structures used in systems have been sequential files and indexed sequential files. The data base system has the advantages of accommodating multiple uses more easily, reducing redundancy of data collection and proliferation of systems, provid- ing easier accessibility to the data and faster response to unanticipated demands, handling more efficiently the storage of varied quantities of the same data, and finally, incorporating changes in the data base without having to redo the program. The trend is toward increasing use of data base systems. However, for some systems, the indexed sequential file or even the sequential file may be a preferable structure depending on the nature of the automated system being planned. On the recommendations of the design team, management must decide on the structure for the new system. Other computer design decisions relate to the inclusion of user-oriented software that facilitate data retrieval and analysis. Examples are report writers, the Statistical Package for the Social Sciences, and emerging simulation and forecasting packages. Man- agement may also specify requirements for quarterly and annual statistical files that enhance the system'’s capability for responding to ad hoc information requests. Another area to address in the design of the computer system is the security requirements. The next chapter discusses the issues of privacy, confidentiality, and security measures and brings out how the need to safeguard the confidentiality of the system information and the type of computer design affect the security requirements. The same security measures are also applicable for addressing special operational needs and preventing tampering with the data and possible fraudulent activities. 57 rs ghd For oa % ~ 3 h pet a 2: 4 a od 4 V. Privacy, Confidentiality and Security The collection by human service organizations of more and more personal data has led to concerns about possible violations of an individual's privacy. Organizational and technologi- cal trends have promoted this increased data collection with resultant risks and implications that have provoked much discussion on privacy and confidentiality and led to greater pro- cedural and technical security strategies to safeguard privacy. At the heart of the privacy issue is the resolution of the conflict between the right of society to have certain kinds of information that contribute to the general good and the individual's right to privacy. Safeguarding personal information collected for information systems is a difficult and complex problem involving the concepts of privacy, confidentiality, and security. Privacy refers to an individual's right to control the use of facts about his life and his willingness to share data concerning himself. Confidentiality refers to the organization's administrative handling and its policies and rules for disclosure of personal information. Because proper handling is basic to the protection of privacy, the organization collecting the information has the responsibility to protect the confidentiality of the information. More restrictive policies, rules, and controls are necessary where greater confidentiality is needed. Security is the specific procedural and technical means to provide the desired degree of confidentiality. Security techniques range from proper disposal of documents, forms, and reports to physical devices such as locks. Security measures can also be programmed into the computer to prevent unauthorized access. Growth in Data Collection The collection of increasing amounts of personal data comes from human service organiza- tions’ requirements for accurate, pertinent, and current information to administer and support multiple social service programs. Greater emphasis on the accountability of programs and the ever-shrinking availability of funds heighten the need for detailed information to evaluate the status and effect of programs and organizations and to justify their funding levels or even their existence. Information becomes an increasingly important foundation on which to plan for pressing social needs and to develop and substantiate legislative proposals. New statutory and government reporting requirements also contribute to the need for information. The radical technological changes of the past decade, which made possible the efficient and effective maintenance of enormous data banks of information, led human service organi- zations to turn increasingly to centralized automated systems for their information needs. At an increasingly lower cost, more data can be recorded in the computer, retrieved, manipu- lated, analyzed, and even merged with other data. In addition, telecommunications advance- ments permit the transmittal and retrieval of data over long distances (even thousands of miles) at different physical locations. Risks and Implications Automated information systems that contain individually identifiable information are poten- tially invasive of the rights to privacy. Abuses of privacy can occur when the system contains 59 unrestricted collection of data about people, stores inaccurate or incomplete data, or allows unauthorized disclosure. These situations can lead to incorrect or otherwise harmful conclu- sions about the persons identified in the system. The capability of the computer to maintain and print volumes of information at tremendous speed creates a potential for access to confidential information previously not retrievable. More data are available because lower computer storage costs encourage the collection of more information and its longer retention. This means that inaccurate information is also more readily accessible to more people in less time than ever before. With data easier to access and share across physical distance, organizations may reference information more frequently, extend its use to new areas, and merge and correlate potentially damaging information from diverse sources. Whether accurate or not, the information can have a detrimental impact on an individual's future. Many organizations may not accept persons with child abuse or neglect records as adoptive or foster parents or day care providers. This judgment of child maltreatment may represent the decision of only the investigating worker, without a judge establishing guilt beyond a reasonable doubt after a fair trial. Identification of a person receiving alcoholism or other substance abuse services may also jeopardize job and other opportunities. With data increasingly being kept for historical purposes on computers, old actions may make it more and more difficult for individuals to start new lives for themselves, regardless of their efforts and capacity to grow and change. The right to privacy and the confidentiality of information is an especially significant issue for human service agencies. These agencies’ social work staff offer services that involve a client-professional relationship built on and directed toward the communication of personal matters. In this computer age when citizens are apprehensive about their privacy, the client- professional relationship can be adversely affected by real or imagined breaches of confi- dence. Conflicts also arise between the information needs of one human service agency and the confidentiality requirements of another. An example is the conflict between substance abuse treatment programs and child abuse and neglect reporting statutes. Legislation creating federally funded drug and alcohol programs provides for strict confidentiality of patient records. In enacting the legislation, however, no consideration was given to requirements for reporting suspected cases of child abuse and neglect. This has caused a nationwide problem for child protective services because Federal requirements prohibit substance abuse coun- selors from sharing any information about clients, including incidents of child abuse and neglect. Safeguarding Information Confidentiality of information must be established and maintained when it is in the interest of the privacy of the individual. Basic methods for preserving confidentiality are collecting data sparingly, limiting dissemination, providing protection, and checking data for quality and consistency. The individual must also be allowed to check on the organizations that collect information about him. Where automated information systems contain individually identifi- able information, the organization must establish confidentiality policies and procedures concerning the collection, recording, and use of the information. These principles must be advocated and adhered to in the design, implementation, and use of automated systems. To minimize the potential threats to privacy and to safeguard personal information, policies and procedures are necessary in the following areas: ® Recording of information, ® Access to records, 60 Expungement of records, Client rights, Monitoring mechanism, and Sanctions. Recording of Information All data elements in the system should be scrutinized to assure the necessity for their collection and to determine the use to which the information will be put, taking fully into account the impact of collection and dissemination on individual lives and liberties. Individu- ally identifiable information should not be recorded or automated unless: ® The expressly stated need to do so clearly outweighs potential misuse and invasions of privacy and confidentiality. ® |t is essential to making effective decisions about the client or family. e Data elements are expressed insofar as possible in objective, factual, and nonjudgmental terms. Identification of handicaps such as mental retardation should be included only when substantiated by a professional diagnosis. ® Explicit documentation exists as to the reason for collecting the information and the purposes for which it will be used. This documentation should be reviewed by an attorney general or local attorney. ® The identity of the client is not revealed when this information is retrieved for management, planning, evaluation, or research purposes—only aggregated, summary data can be made available for these purposes. Access to Records No persons or organizations shall have access to individually identifiable recorded informa- tion except where such access has been approved by the organizations or persons responsi- ble for granting such approval. The dissemination and use of information must be for a necessary and lawful purpose. Approval of access requires consideration of the following: eo Maximum effort to insure the confidentiality of information entered in the system. e |dentifiable personal data are not used for a purpose other than that for which the data are collected. e Information is available only to organizations that can demonstrate the need and have legal rights to such records in order to carry out official duties. Other organizations should have no access. ® Such access will not be approved unless determined as essential to serve the client or the client’s family. Written rules or regulations governing access to information should include identification of persons and organizations authorized and not authorized to have access, a means to identify those given access, any limitation on the potential use of the data, and a method of informing workers and clients of the data use. The rules should stress professional ethics of service workers to respect the privacy of the clients and to use responsibly the information gained in the course of the professional relationship. Expungement of Records Expungement concerns removing or discarding information after a period of time when the data are no longer valid or the information is no longer essential. Policy and procedures on expungement should explicitly list the removal of data in the following conditions: 61 ® When portions of the record are out of date, selective removal of this information should occur. ® The name and other client identifying data should be removed from a client's records as soon as the information contained in them is no longer necessary to serve the client or his family. This could be after the closure of a case, depending on the purpose of the system. Once removal has been determined to be necessary, the expungement of the information should be accomplished so that all future identification of the individual on computer record is prevented. Client Rights Every client should have the right to know the nature of all recorded information pertaining to himself and have the opportunity to inspect it. The social service agency should inform each client fully about the following: ® The nature and use of the information to be recorded, eo The fact that information is as current and as accurate as possible and that safeguards exist to prevent misuse, The agencies or persons authorized to access such information, The client's rights to inspect his records, The client’s rights to have a copy of his records, and The procedures by which the client can request correction or expungement of any informa- tion believed to be inaccurate or potentially detrimental to his rights of privacy. At the client's request, the organization should provide the client the opportunity to read his file and challenge entries that may be unfair, incorrect, or out of date with respect to the purposes for which they were collected. The client should have the right to prevent records kept on him for one purpose to be used for another without his consent and to appeal the content if he does not agree with it. This is particularly true in such sensitive areas as protective services. When disagreement exists over a client-requested correction or amendment, the client's claim should be noted and included in any subsequent disclosure or dissemination of the disputed data. Monitoring Mechanism The manual and automated safeguards to insure the confidentiality of the system are easily forgotten once the system is operating. Therefore, documented procedures should exist for an independent party to periodically audit the system’s operations to insure compliance with all established confidentiality rules and regulations. This internal audit should include: ® Review of established information requirements and actual information collection, ® Review of reasonable precautions that the data are reliable or not misused, ® Review of individual or organization requests for disclosures to see that rules regarding authorized and unauthorized release of information are followed, ® Review of security measures to test the adequacy of the system’s operational and technical safeguards, e Testing of management's compliance with laws and regulations governing computerized information systems, ® Review of individual complaints and dispositions, and ® Recommendations for improvement or change. 62 Sanctions The organization should establish sanctions making it a crime to obtain information from a data bank by fraudulent means. Penalties should include fines and even imprisonment for violations of the provisions. Security Measures No automated information system is totally safe from unauthorized access, but security measures can prevent and deter physical access to confidential data. They are also effective mechanisms for insuring data entry by authorized personnel, reducing the possibility of computer fraud and tampering with data, and preventing inappropriate release of nonconfi- dential information on agencies and service providers. Several types of security strategies exist: ® Procedural techniques: These place constraints on the individual user. ® Physical security: This relates to the protection of and access to the computer environment. ® Internal security: This relates to the controls and protective mechanisms within the compu- ter system. Planning and selecting security measures require balancing the financial and other costs of safeguarding the data against the probability of loss or the potential adverse impact of confidential information. Increasing the stringency of security measures can reach the point of prohibitive costs and an unworkable system. The trade-offs in an extra margin of security must be weighed against increased disadvantages in terms of cost and user inconvenience. Procedural Techniques Many procedural techniques are available that limit unauthorized access to information: e Administrative controls over the use of the system, ® User identification systems, e Data distribution, eo Safe disposal of computer documents and reports, and e Security officers. Administrative controls relate to the use of the system by different personnel. They may decide who uses the system and for what, and may separate sensitive work by its natural divisions. Special identification systems restrict access or release of data on a justified need-to-know basis. The various levels of need-to-know, the type of security measures, the type of access, and the access to which data may be determined by the job classification and position responsibilities. Passwords are used with online systems. In cases of phone contact, matrix codes may be used to be sure that the requester is entitled to know the information. This is critical for a protective services central registry. Both matrix codes and passwords should be changed periodically to reduce the possibility of their use by inappropriate persons, and the holders of passwords and matrix codes should be instructed on keeping them secret. Data distribution is concerned with insuring that documents and reports with confidential data go to the correct source and are properly handled in transit. Proper data control proce- dures should guarantee this. Personnel authorized to receive copies of reports with identify- ing client data should have been determined in the planning of the report. If the material is 63 transported by an individual or company, bonded couriers or drivers should provide a mea- sure of security. The safe disposal of discarded name-identifying computer reports and input forms is also important. Procedures should exist on disposal of all documents bearing client names and preferably include the use of a paper shredder. A security officer should exist, with responsibility to plan and implement security measures. These responsibilities may include briefing new employees on confidentiality requirements and security procedures, managing the password and unique identifier assignment and distribution, authorizing individual's level and type of access to the system, and monitoring and testing security measures to insure their required functioning. The security officer may complete a form assigning an individual's identification and authorizing access level that formalizes access and instructs data systems staff to modify the system accordingly, incor- porating the identifier and access level into the internal computer security. Physical Security Physical security is the protection of the computer and confidential information by choosing a location and/or securing locks to eliminate the possibility of unauthorized access. One measure is to locate the computer, terminals, and confidential reports in physically separate areas. People entering and leaving the area may be required to wear a badge and to sign in. Terminals should be placed in areas not accessed by the general public, but if they are needed by the intake receptionist, the display of data might need to be restricted. Another physical security measure is the lock-and-key approach for locking up terminals or for securing an area with confidential printouts. Internal Security The internal security measures involve computer programs and telecommunications sys- tems. Many measures exist that help protect the privacy and security of records. To breach the computer would require knowledge of computer operations and programming and an under- standing of the system’s automated procedures for acquiring the information. Some of the measures that can be programmed into the system are: passwords, access levels, identifications for terminals, cryptography, and system design features enhancing confidentiality. Passwords and access levels have already been discussed as part of the procedural security measures; they are also part of internal security because they must be programmed into the system. An additional security measure is identifying terminals and tying access to data and performance of certain functions to particular terminals. The system may be designed to provide greater safeguards for confidential information. One example is the separation of name identifiers from specific information on the client. Another is the automatic expungement of names and possibly other information on closed cases. An online information system poses special problems in safeguarding the confidentiality of information that do not exist in batch processing or manual systems. The unauthorized access may occur at a remote site rather than at the location of the confidential information. Some security devices—password control, physical security, and terminal lockup—have already 64 been discussed. When the system transmits sensitive information, additional security techniques to consider are cryptography protection to communication lines or a dedicated line. Terminals may also have features such as automatic removal of data from the screen if no action takes place or shut down if, for example, poor password tries suggest possible system tampering. In planning the information system, the user advocate and other system designers must give careful consideration to the type of data collected and the security measures used in protect- ing the confidentiality of the name-identifying information. The security measures are critical and should be specified in the detailed design document and incorporated into the system in the implementation phases. 65 VI. Implementing a Social Service Information System The conclusion of the system design shifts the information system effort from a planning to an execution mode involving four interrelated phases: eo System development, ® |nstallation, e System operation and maintenance, and e Evaluation. The implementation phases are a challenge to the organization’s capabilities to provide and manage the needed resources for making the system a reality, to rally and orchestrate additional resources for installing the system and preparing the agencies/sites for changes introduced, and to maintain the smooth operation of the system and rapidly correct emerging problems. In addition, management must insure the incorporation of the system’s products into the related organizational functions and require periodic evaluations of the system to identify changes that make it more acceptable to users and more efficient. Each phase brings new challenges. The chapter describes the major activities occurring in each successive phase and high- lights areas of particular interest and concern to management and system users. Some key areas of concern for all levels of management in the organization are acquiring the needed computer equipment, testing the system, preparing agencies or sites for installation, and training all personnel affected by the system. The user advocacy unit and the evaluation process are also described for their importance in resolving problems and building accep- tance and effective use of the system. To enhance management's readiness for dealing with unexpected complications, the chapter also discusses the typical problems encountered during the system implementation. The Implementation Phases The shift of the project from the planning phases to implementation increases the demand for a strong project management structure. Technical leadership is critical during the system development phase, with strong support from the user advocate unit. Then leadership from the user director or a key management person is essential for directing the work of user- oriented staff in installing the system in local agencies or sites, while technical staff establish the data processing foundations and insure continuous, uninterrupted computer support. In the system operation and maintenance period, the leadership demands are significantly less as the new system becomes part of the regular data processing production. During this period, the user advocacy unit resolves problems, trains as needed, encourages the utilization of the system products, and periodically evaluates the system and requests changes and enhance- ments. The project team is under the greatest pressure during the system development phase. Suddenly many more staff and newcomers to the proposed system are part of the team and have roles and responsibilities requiring considerable coordination. A complex effort could increase staff from 5to 40. Their concerted effort to transform the system design to a computer 67 system raises many problems and issues not previously identified, and fast resolution and decisions are necessary for timely completion of work. Project management must also monitor tight time frames and stay on top of the work. This becomes increasingly difficult when pressures mount and problem after problem crops up. The situation can further de- teriorate if staff become reluctant to reveal their work difficulties and delays for fear of becoming the scapegoat for serious project delays. If the project staff is largely internal rather than consultants, data processing emergencies may cause a temporary drain on the project staff and exacerbate a tight resource situation. Another frequent problem in system development is late requests for changes and additions to the system that had not been identified in the design phase. A ‘design freeze’’ on the system design is absolutely essential for the timely completion of this phase within budget. The cumulative impact of many small modifications can be significant. The changes requested to the system design should be held until after project completion in the pilot site except under unusual circumstances. Exceptions might be the identification of a design flaw on the new mandated information requirements. Before any changes are incorporated into the system design, management and the project team should review them for their impact on the esti- mated costs and schedule and give approval for their inclusion. Installation phase complications result from orchestrating and.sequencing all the events that must take place and creating receptivity to the changes accompanying the new system. The effort often involves many nonproject staff and requires organizationwide support for giving the installation the needed priority status and for carrying out the training. The major activities in the four phases are discussed next, followed by a more detailed treatment of critical areas that directly involve management and users and cause them substantial concern. These areas are testing, pilot site acceptance of the system, preparations for system installation, documentation, training, and the evaluation process. The role of the user advocacy unit is described further for these phases. System Development System development covers the activities required to made the design a reality and prepares the system for implementation. The major activities are constructing the information system through the generation of the data base and/or files, coding and testing programs, testing the system in a simulated environment, acquiring the equipment, and organizing for the installa- tion. The major products of this phase are: e Test plan for system acceptance, Data base and files generated, Programs coded and tested, System documentation, Systems test, Conversion plan, Procurement of forms, tools, and other materials, and Hardware acquisition. The major focus of system development is on the computer. The development of the system is essentially moving from the abstract design completed in the planning phase to a concrete representation of the solution in code and procedures that can be implemented. As the system becomes areality, and concurrent with the completion of the computer system and testing, the organization must prepare for the pilot test and become ready for the total system installation effort. For effective computer support, the acquisition of equipment needs to begin as soon as possible to insure its availability for the piloting and installation, and the system documenta- tion and computer operations manual must be completed to insure a smoothly functioning and understood system. A conversion plan is required where existing manual or automated data is to be transformed and used in the new system. If automated systems are available, programs must be written and tested prior to their actual use in transforming the data. Preparation for the users includes ordering forms and helpful worker tools, developing of the user’s guide, preparing the training plan and curriculum, and training the trainers. Once the new system has acquired its computer life and successful testing has occurred, the project moves into the installation phase. Installation Installation is the implementation of the new system in the pilot sites and all locations that require advance preparation with the necessary equipment, training, and support. The major accomplishments in this phase are: ® Pilot site test, Installation plan, Agency preparation, Operations manual, User's guide, Installation of the information system infrastructure, Training plan and curriculum, Training, Conversion, Installation of new procedures, Shutdown of the obsolete system, and Operation of the new system. The pilot site test is the extension of the testing into the real world to judge the system's validity and its readiness for full installation. Meanwhile, the organization must continue its mobilization and preparation for full implementation. The installation plan brings together and sequences all required activities for achieving an operating system. It must weave into a schedule the new activities of installing equipment, preparing sites, training, converting, and introducing the system, with the beginning data keyed to the successful conclusion of the pilot. The shutdown of the obsolete system occurs as the new one is installed. Agency preparation involves setting the stage for the change and leading the way for the initiation of all the interrelated activities. The first major activity is often the establishment of any equipment or data processing structure required for accommodating the new system. Depending on the effort required and the methodology, conversion of automated or manual data to the system may occur early or late in the project. Training is most effective when it occurs just before the implementation of the system. The user's guide comes with the training and serves as a procedural reference for working with the new system. The operations handbook is the reference for data processing to run the system. Operation and Maintenance of the System As the installation takes place, the new system enters the operation and maintenance phase. Data processing has significant responsibility for providing smooth computer support and proper processing of the system's input and output. The user advocacy unit has a smaller but critical role for handling user problems, monitoring input and output, training on the system, and accommodating information requests. The typical information system involves three major operational processes relating to input, the computer, and output. The input process involves the user staff completing a form, 69 possibly other staff reviewing the form for obvious errors, and data entry staff entering the information on terminals or through other methods. The extra steps involved with the form and its review may be eliminated where the user enters the data directly on the terminal. The computer processing then begins validating, rejecting, and accepting data. This is followed by the multiple operations of the programs such as calculations or checks for compliance with standards incorporated into the computer. The processing produces reports and updates the data for inquiry screens. The output process involves the handling of the resulting reports and turnaround documents, which may require bursting, decollating, trimming, and binding; controlling for complete and accurate output; and distributing the documents and reports to the appropriate users. The users have responsibility for using reports and beginning the cycle over again, updating the documents. Evaluation A formal evaluation of the information system is the final phase of system development. A preliminary evaluation occurs during the piloting of the system and immediately after the full installation, but the formal evaluation generally takes place approximately 1 year after im- plementation. By then the system has acquired full stability in the user environment, and evidence of its impact and value is clear. The first formal evaluation of the system has several objectives: ® To assess the achievement of original objectives and benefits, ® To identify newly emerged objectives and benefits, ® To evaluate the viability of the system in terms of user satisfaction, technical and operational performance, and cost, eo To identify satisfactory and unsatisfactory elements of the system, and ® To recommend changes for correcting the unsatisfactory elements and incorporating needed system enhancements. Other subsequent evaluations may identify changes and enhancements needed over time. The evaluation includes (1) a review of the system’s objectives, documentation, and current known problems, (2) fact-finding and analysis process, and (3) conclusions and recommenda- tion. The user advocacy unit should give leadership to the formal evaluation of the system and address the user dimension. Wherever possible, independent evaluators, such as the Ameri- can Humane Association for a child protective services system, should be included to obtain an outside assessment on the system's achievement of objectives and suitability for the users. The data processing staff should undertake the technical evaluation of the system and may include outsiders and consultants in this effort to analyze the efficient use of the system and other computer-related areas. Testing Testing the system is among the most important activities during the system development phase. Perfect programming is almost impossible to achieve, and testing is the most effective strategy for identifying errors. Several levels of testing exist: ® Individual program testing (including string testing), e Systems testing (including backup and restart testing), and ® Pilot site testing. ’ From this testing, management derives assurance that the system performs according to the design, works in a real environment, and is finally ready for implementation. The pilot test results are the guarantee that the system is ‘debugged’ before system installation. This is 70 critical to management because, while a new system causes moderate traumatic change, a faulty system may increase the extent of trauma beyond tolerable limits and destroy the users’ confidence in it. Despite its value, testing is often the most short-changed activity during the system de- velopment phase. Unfortunately, testing frequently begins when the project has encountered schedule delays and may risk not meeting the target date for the pilot site. Pressures mount further on the project staff as the programs working correctly are found to have problems, and analysts and programmers begin to take shortcuts. The proposed painstaking matching of test results with planned results may be replaced by a quick thumbing through the report, saying the programs and system look good. Meanwhile, errors continue to exist undetected until the installation in the pilot site. The systems testing requires an independent group with the explicit responsibility to signoff on the testing effort and verify the accuracy of the results. The group could be data processing staff not involved with the project, but preferably the user advocacy unit provides this check on both the programs and the system functioning. The user advocate has the advantage of extensive knowledge of how the system should fit with the environment, and can more easily detect discrepancies between the system and the environment that were not apparent from reviewing the system specifications. The advocate’s identification with the users and his appreciation of the impact of poorly debugged systems can make him very conscientious in contributing to and reviewing the testing. Other advantages are secondary to the testing but central to the project. It forces the advocates to acquire a profound understanding of the system, which facilitates their preparation of both the user's guide and the training cur- riculum. For the advocates, the testing is also one of the best learning experiences on the system. A testing plan should include the test philosophy, acceptance criteria, and methodology to analyze test data and determine compliance with the acceptance criteria. It should identify the testing tools so that plans can be made for early preparation and application. Test data should represent all realistic conditions but in as small a quantity as possible. Validation is laborious work, and it is not necessary to have more than one example of a possible condition. Another part of the methodology should be the early development of the users guide and its later use in the testing procedures to evaluate its clarity and convenience for such areas as completing documents and understanding error messages. Furthermore, this approach confirms the consistency between the program documentation and the system’s operation, and offers the side benefit of forcing good program documentation. The user advocate has a major role and contribution in all levels of testing. Program Testing Upon completion of each program, testing determines if it performs according to the specifications. String testing is the next level, which shows that the program can function properly within its segment of the system. For example, if program B process requires program A data and then gives data to program C, string testing checks the linkages from programs A to C. It is easier and more economical to detect, isolate, and correct errors at the lowest level of testing. The cost-revealing and rectifying errors become larger with each successive testing step in the development cycle. Test data are structured so that predicted results can be monitored. The testing should verify, for example, that the system accepts only valid data, performs the necessary edits properly, produces correct error messages whenever an error occurs, handles dates and computations correctly, and maintains the proper security. The programmer begins the process by testing his coding and segment linkages. After the completion of the programmer's tests, the user advocate starts his testing on the individual programs with consultation from technical staff and then proceeds to the higher levels of 71 testing. Systems testing begins after the successful conclusion of the individual program and string tests. Systems Testing This testing determines that the system performs according to the agreed-to system design and the intentions of its architects. Management also has a guide for judging the technical adequacy of the computer system and measuring the progress of the project. The testing is sequenced into ‘days’ of work, and ‘‘day 2'’ begins after the successful completion of ‘‘day 1.” The completion of a day requires not only the initial entry and display of information, but also the identification and correction of errors and the subsequent retesting to see that changes have been made and everything is working correctly. A day of testing may actually require 5 to 10 days, especially in the initial period of testing. The testing progressively covers larger and larger groups of programs until the system becomes an integrated and tested whole. The full systems test analyzes and controls for all possible conditions. Some examples are: Error conditions function properly. Exception conditions function properly. System does not accept garbage data. The data base is successfully updated. Turnaround documents are generated correctly. Reports are generated correctly. Online inquiries function properly. User's manual is correct and accurately reflects the system procedures and flows. Backup, recovery, and restart testing is also necessary to determine if the programs and data can be successfully recovered when problems occur. After the test, the system is ready for validation in the real world to ascertain if the model runs correctly and is a true representation of the user's needs. Pilot Acceptance Test The pilot acceptance test verifies the successful operation of the system under varying conditions of the real world and gives management the basis for deciding on its readiness for full installation. A pilot experience also allows the containment of any system problems and major design flaws to a small location and their correction and retesting before the system is extended formally. The pilot site plan can have numerous combinations of locations, site characteristics, and duration of piloting. The choices often relate to the complexity of the new system and its requirements for accuracy. A smaller system, such as one for child protective services, may have a pilot test in a cluster of agencies for 2 months, whereas a complex social service system may have multiple sites introduced gradually one at a time. See appendix B, figure 1 for a comparison of different pilot site plans. Sometimes smaller systems move directly from systems testing to implementation; while this is not advisable, it is possible. Complex systems must go through rigorous testing on a phased-basis “shaking down’’ of the system, identifying and resolving any major “bugs” in a small location. Whenever the system includes financial data, the test site probably needs to duplicate manually all auto- mated records to verify the absolute accuracy of this portion of the system and to have the capacity to handle the financial operations if the system should experience serious system problems. The first pilot has the painful ‘shakedown’ and should be in close proximity to system staff so that immediate help can be available. The start of the next pilot site does not begin until all the problems uncovered in the previous pilot site have been resolved. In effect, 72 this fine tunes the system and allows for the further development of an effective installation team and methodology to carry out the implementation when the pilot testing has been completed. The last pilot confirms the successful system operation and permits formal an- nouncement of the long-awaited fixed date on implementing the system. Pilot testing offers sites several advantages. These sites are the forerunners of the new system and equipment and are in a position to identify and influence the changes and enhancements made to the new system and to receive individualized attention from project staff. A willingness to suffer the system problems while retaining a spirit of cooperation and endurance is the price exacted for the special treatment. The pilots should possess certain characteristics in order to fulfill this painful role adequately. All sites must have experienced persons—not new employees—to test and evaluate the system, and sufficient staff resources to handle the extra and duplicative work. The agency administrator and staff should support the agency serving as a pilot, and if applicable, the local agency board should give its endorsement. Other important qualities are the agency's overall strength and operational effectiveness and, if feasible, the agency's previous participation in the design of the system and support for other implemented systems. To select the sites, visits and study of available management reports in the agency may be necessary to become sufficiently knowledgeable about the agency'’s ability to handle the stress and burden of testing. After the selection of the prospective sites, written agreements are useful in detailing the extent of both the project and the site obligations. Acceptance testing in the pilots provides the ultimate review and refinements in the follow- ing areas: e® Each program, ® The system, e User's manual, and ® Training methodology. Testing also brings to the surface any gaps in the design and their correction. The practical experience in the pilots gives more insight into effective installation methods and procedures and technical assistance necessary for the system’s incorporation into agency procedures. Preparations for the System Installation The installation plan brings together and sequences all required activities for achieving an operating system. The specific purposes are to provide the structure for orchestrating and scheduling the multiple implementation activities, predict and measure progress, identify project roles and responsibilities, and inform management and users what to expect and when. The plan insures smooth implementation by planning and scheduling major activities into manageable units with realistic time frames that can stand up under pressure. The schedule must consider the resources available and avoid wherever possible peak demands on trainers, telecommunications support, and other key implementation staff. The plan must also reflect an acceptable pace of change compatible with the user's ability to understand, tolerate, and incorporate the new system. The size of the system affects the scheduling of implementation activities. Small systems can be introduced at once following a training session; others have several steps in the implementation process—conversion, followed by training and immediate use of the new system. Complex systems may implement not only by subsystems, but also by a series of installation activities within a subsystem. This is often the case where an information system “infrastructure” must precede the introduction of the new system, to provide the prerequisite foundation, such as data entry capability and computer equipment, for its operation. 73 The implementation activities need to begin as early as possible to expedite the process and prevent a bottleneck of activity at the point of introducing the system. Testing and refining the user's guide and the training curriculum in the pilot sites is a major accomplishment that permits almost immediate implementation of the new system in other locations. Equipment procurement should proceed as soon as approval has been given, and other activities can start as early as feasible. Information System Infrastructure The installation of the information system “infrastructure” is the establishment of the data processing foundation for supporting a system. The introduction of a system cannot take place without the prerequisite data processing foundation that allows the entry, processing, and distribution of information. Essential parts are the computer hardware and a data entry capability. A centralized data processing foundation serving decentralized locations may also require a distribution and pickup operation—for instance, a courier service—and/or a tele- communications network. The implementation of the foundation must precede the introduc- tion of the system. For instance, a totally centralized data processing operation serving decentralized locations must have a distribution and collection operation; an online informa- tion system must have the telecommunications network and the terminals in place before the new system begins operating. Therefore, the implementation of the new system may require the simultaneous planning and installing of data processing equipment and structures. Each part of the infrastructure brings its special problems and increases the difficulty of implement- ing a new system smoothly. These problems require speedy resolution for maintaining the user's confidence in the system and proceeding with its timely installation. Data Processing Center The data processing center must be prepared to provide and maintain the computer hardware support as well as the programs (software) that run the new system. Computer hardware may involve only equipment at a central location, or in the case of an online system, terminals and printers along with a telecommunications network. Support for programs requires the organizational readiness to eliminate any system problems surfacing, to adjust the programs for system improvements, and to document all changes. The center must also be able to respond to ad hoc requests for information from the system. The management of the information flowing toward and from the computer requires special support (data control) within the data processing center to insure that the entry, use, and receipt of data is authorized and consistent with procedures. The data control staff also facilitates at an early point the identification and correction of data processing problems such as the production of erroneous reports that otherwise would adversely affect the users of the system. A data control center within data processing must perform the following critical functions as the system is installed: ® Receive all input and determine that data originate from an authorized source, eo Have procedures to insure that all input received is processed by the computer system, e Control input documents so that they are not reprocessed, ® Maintain a schedule of reports to be printed from the computer and identify when areport is not produced on a timely basis, e Control reports in terms of accuracy, completeness, and correct number of copies, and scan for obvious errors, ® Request the correction of bad reports and ask for new runs, and e Distribute correct reports and turnaround documents to the user. 74 Data control prevents the loss of input documents and facilitates their proper processing. It also helps reduce the distribution of reports with visible problems before the user becomes aware of errors. Data control functions must exist for the smooth and correct flow of data at a central point and at decentralized points where multiple user sites exist. The data processing center must monitor the adequacy of the total operation—computer equipment, telecommunications network, programs, data control, and data entry to insure that they are performing adequately and according to plan. Adequate controls must exist to prevent excessive errors in data entry. One method is to rekey the information and compare it to the first entry, thereby verifying the correctness of entry. However, key verification is not available for online entry and other procedures must be developed. Agency Preparation Implementation brings about varying degrees of change in the way an organization and its people work. Introducing these changes is a difficult problem with severe consequences for getting it wrong. Impacts on the organization may exist for both the short term and long term. The agency needs a full understanding of the effects and sufficient time to plan for them before the introduction of the system. The short-term impacts involve the conversion efforts, which often require substantial time, resources, and learning to master the new forms, etc. The long-term changes relate to the integration of the computer process and equipment with the work performed by the people in the organization. Most of the changes in social service systems fall into four groupings: e new documentation methodology, e changed work processes and procedures, e staff, and ® new equipment. Agency preparation is the process of planning for changes in advance, taking into account the human factors that come into play at implementation and must be worked through. Adminis- trators and supervisors can influence the receptivity of staff toward the change. Chapter7, Acceptance of the Social Service Information System, has a section on major changes affecting people. Documentation Documentation insures correct communication about the system to management, users, and technical staff. Throughout the development phases, it is a means of preventing distortion of ideas, promoting project controls, recording design decisions, and making visible the capabilities and limitations of the system. The final set of documentation prepared or com- pleted in the installation phase provides a history of development, a guide to system mainte- nance and operation and a tool for evaluation and changes to the system. Without good documentation, users may not work correctly with the system, and programmers may intro- duce undesirable side effects. The documentation of the system should include the following: ® Functional requirements, System concept and overview, System design specifications, Data dictionary, Programming specifications, Operating manual, User's guide, including forms, reports, terminal uses, and instructions, and Data entry procedures and data controls. 75 The functional requirements, system concept and overview, system design specifications, and data dictionary are results of the planning phases. The others are products of the implementa- tion phases. The operating manual, user data entry procedures, and the user's guide are instructive documents that describe in detail tasks that may or may not be related to auto- mated processes but are essential for the efficient and effective use of the system. The user's guide describes the functions performed by the system and serves as a reference for completing forms, understanding and correcting errors, using terminals, and interpreting reports. The document should also describe interfaces with other systems and identify re- quirements for history, purging, and security. Large systems may have both a complete reference document and abbreviated manuals directed toward the needs of the particular staff using them. Unfortunately, a complete and cleardocument may become large and overwhelm- ing and consequently less useful to staff. It becomes the reference of last resort, if consulted at all. The project team must develop a way of presenting the necessary information into an easily used document. Part of this method may be quick-check worker tools that encourage verifica- tion of data elements reported rather than guesswork and questionable colleague advice. The operations manual describes the technical system and its operational environments and provides the data processing center the information needed to execute the system's programs and to maintain the data. Data entry and data control procedures may be in a separate manual or part of the user's guide; they address the steps to follow in entering data and controlling the flow of data into and out of the computer. Preparation of the manuals requires research, clear writing, and verification of the accuracy and adequacy of the material with the technical and user staff. As changes occur in the system over time, these documents need to be revised and kept up to date so that the system is completely and accurately described in writing. Training Training is critical in implementing a new information system to insure user's understanding of the system and what the changes mean to them and to gain their acceptance of the changes. The user advocacy unit must plan the training structure for its delivery and insure its im- plementation. This requires planning the training curriculum, organizing the delivery, and implementing the training. Planning the Training Curriculum Planning the training requires identifying the trainees, deciding on the performance out- comes that should occur as a result of training, establishing the content, developing training strategies, and defining the evaluation process to assess the attainment of performance outcomes. The trainees for a social service system are those persons affected by the implementation of the new system who will be doing something different related to the computer. Below is a typical list of social service agency personnel and the changes they may experience: e Directors—manage the change process, oversee the data processing operation, and utilize the system’s reports and inquiry screens. e Supervisors—utilize the reports and screens, teach service workers how to complete forms and use the system, and answer questions about the system. e Service workers—collect and report the data and utilize reports and screens. e Financial officer—utilize the reports and screens and adjust accounts through the terminal. 76 e Clerical staff—perform data entry or data control, do name searches and other inquiries, and handle statistical reporting. ® Data processing staff—run the system, handle system technical problems, and retrieve data. These persons should receive training related to their use and involvement with the system. After identifying the trainees, the next planning step is deciding on the performance out- comes expected of each type of staff as a result of the training. The questions to answered are: What should each type of staff be able to do after the training? What kind of change in behavior is needed? The scope of the training effort relates to the difference between current and future activities, the different staff's capabilities to learn, and the length of time required to teach the changes. An assessment of the common and unique learning needs of the different staff determines whether separate or shared training is advisable. Setting the stage for the introduction of the new system and its changes is crucial for the reluctant and possibly hostile social service staff. A presentation of computers and data processing can be an effective beginning, offering an opportunity for some humor as well. This approach gives the users some understanding of the fundamentals of computers and data processing uses and limitations. In addition, it helps dispel misconceptions, reduces the fear of the unknown, and brings out how computers can serve needs. The users are then ready for a comprehensive overview of the new system, the purposes and benefits to be derived, and its place in the organization’s constellation of systems. Service workers also need reassurance on the effectiveness of the system’s security measures to protect the confidentiality of infor- mation on the client, particularly for systems related to protective services. Administrators share the same concern but in relation to agency data such as performance and funds. The content can then shift to the changes that will affect them, the factual information essential for performing activities related to their role, and responsibility with the system such as complet- ing new forms, using new reports, or entering data into the system. See appendix B, figure 2 for a sample training outline for supervisors and service workers. The extent of change intro- duced by the new system and the users’ previous experience and attitude toward systems determine the emphasis and depth required, as well as the number and length of training sessions. Staff's acquiring the necessary knowledge to perform new activities introduced by the system is difficult because of many intervening psychological factors. The trainers strive for the trainees to learn the new, but staff are slow at remembering the new and forget the initial learning at a rapid rate. For service workers, the exacting demands of an information system and their potential view of its requirements as excessive, useless, or boring does not give them strong motivation to learn the changes. Consequently, the planning of the training requires appreciation and application of the principles of learning in the development of training content and strategies in order to increase learning and overcome forgetting. Many different techniques attuned to the psychological principles of learning can facilitate and enhance the learning process. Staff should know what is expected of them, see the value of learning the changes, and be motivated to listen and learn. During training, each person should know where he stands and how well he is doing, and the trainer should recognize progress and successes. The training approach should also insure that in addition to learning the change, staff understand the reason for the change and its intended results. The more effective training strategies emphasize experiential learning and involve active practice rather than passive reception. Some techniques for increasing the staff's involvement in the description or demonstration of the change are: ® using training aides and effective tools that stand out with the combined approach of telling and showing, ® eliciting responses from showing what not to do (errors) as well as what to do, and ® giving opportunities to discuss the new learning and later to practice it. 77 Useful repetition also reinforces the retention of the new knowledge and helps the staff remember more. Teaching the material close to the time of installing the system when the learning can go into practice is also important. Heavy repetition in the early period of learning aids retention of the material. Many effective training aids exist that promote learning. Mixed media can create a lively and entertaining format for presenting systems. Examples are films on how data processing works, colorful slides describing the system, tapes of other users on the system describing their experiences and suggestions for making it work, giant prints of the forms workers will complete, attractive displays of reports on poster boards, and, for systems going into local agencies, slides of the central data processing unit handling the agencies’ data and reports. In addition, the use of online terminals provides effective learning through practice and can demonstrate easily the system's security measures. The user's guide and worker tools should be incorporated in the training so that staff will feel comfortable using them for performing their computer-related responsibilities. The resulting advantages of greater learning are smoother installation and operation of the system, higher quality data, and greater system use. The benefits of a system are often associated with the reports produced and the information readily available by on online system. Therefore, the initial training should cover the reports and their use to insure that the service staff appreciate these benefits and see the value in providing data. However, supervisors’ and service workers’ first concern is likely to be how to complete the forms and handle error messages. Planning a subsequent training session on the reports may be advisable, after the initial shock of the change has passed and the staff can have their own copy of the report. Agency directors and other managers also more readily learn about the reports after system installation. They will have had some experience with them and be able to comprehend their potential value more quickly. The training can offer experiential learning through actual review and analysis of reports when management can gain unexpected insights into agency operation, program management, and other areas. Chapter 11, on utilizing information systems, discusses different strategies for training man- agement and others to make effective use of the reports. The final planning area is deciding on the method for measuring the staff's achievement of the learning goals and evaluating the training effort. The methods may include formal and informal procedures. The former involves the use of quizzes, and the latter relates to observed learning evidenced by participation in the session and responses to questions. Training strategies should also be evaluated to determine the need for improvements. The Training Delivery System The planning for the training curriculum sets forth the requirements for the delivery system in terms of who needs the training, the focus and number of training units for each type of trainee, its length, and the size of training groups. The next step is planning and organizing the delivery system to implement the training. Planning the delivery system requires information on the number of each type of trainee that, combined with the curriculum plan, gives the number of sessions. From this itis possible to assess the financial and staff resources required to deliver the training and to identify the needed number of trainers. The other key planning activities are training the trainers and scheduling and sequencing the required training sessions with other installation activities. Shorter time frames for training require more trainers. The scope of the training effort increases with the complexity of the system, extent of change introduced, and types of personnel affected. A training plan for introducing a comprehensive online social service information system is shown in appendix B, figure 3. A smaller system would require less training, possibly involving 2 days for the initial training and a 1-day followup session on using reports. 78 The trainers for the new system should have good training skills to create interest and provoke learning. The trainers should be able to discuss the system easily and know the system in detail to handle any question or problem brought up by the trainees. Trainers must also be able to see beyond the wonders of the system and to respond to the feelings and needs of trainees. Formal intensive training is necessary to insure a well-informed and effective training force. Trainers involved in systems testing, pilot testing, preparation of the user’s guide, and development of the training curriculum need only practice for the training role, while others may require formal instruction of 2 weeks or more, depending on the system scope. A major decision on the delivery of training is who will train the service workers. They are the largest and most important trainee group, not only bearing the system’s burden of data collection but also determining the accuracy and quality of the data by their cooperation. Service workers need the best trainers to communicate complete information about the system and to create a positive attitude toward the change. Many social service training efforts focus on the supervisor with the explicit or implicit intent of having the supervisor train the workers. While this may be an economical use of central training resources, the service workers receive poor, condensed training and become ill equipped to perform the new computer activities efficiently and effectively. Adverse consequences of training only supervisors on the new service information system are: eo Workers are not given the complete information, or e Workers may not get any information, or eo Workers are not walked through the system with full explanations. Something is lost in the translation from trainer to supervisor to workers. Moreover, service workers do not have the opportunity to ask the system experts questions about handling unusual situations. Since they do not manage cases, the supervisors are unaware of these exceptions. The supervisors may also come back from training frustrated by the demands of training workers and feeling unfamiliar with the system and their training responsibility. Their negative biases on systems may shape and reinforce the service workers. The importance of firsthand training for service workers is also underscored by recognizing their role in future training efforts. Generally, the service worker, not the supervisor, teaches new staff members about the system, and misconceptions and biases may well be perpetuated among workers unless they have the opportunity to participate in the best training on the system. The implications for training are that the system trainers should provide the needed instruc- tion to both supervisors and service workers even though staff and schedule requirements place significant demands on the organization. The short-run effort should reduce long-run special actions to strengthen the system’s acceptance and to improve data quality. The system installation will reveal the ultimate success of the training for gaining accep- tance of the system, teaching the accurate completion of forms, and encouraging the full utilization of reports. Depending on the response of management and service workers and existence of problems with the system, additional training may be necessary. Training new staff on the system may also become part of the organization's overall training plan, particu- larly where a high attrition rate exists. 79 User Advocacy Unit's Support for System Operations The user advocacy unit has six major functions to perform during and after the system's installation: ® Maintain user documentation, ® Handle user questions and problems, ® Monitor input and output, ® Manage information requests, ® Train, and e Identify the need for changes. The advocacy unit monitors the data quality and error control of the system and intervenes as necessary to insure accuracy and reliability. The unit is also the responsive troubleshooter always available to solve problems and give assistance. These functions contribute greatly to building the users’ active cooperation with the system and reducing resistance. The unit maintains the basic documentation that users need to understand and follow the information system procedures. This includes the user's guide and simple worker tools like code cards and cheat sheets. As changes occur, the documentation needs revision and distribution so that staff are not following outdated documents. The unit answers basic questions that are not fully addressed in the documentation. More importantly, the unit responds to the user problems such as inexplicable data on reports, missing cases, corrected information still appearing as errors, or the wrong name with a case number. Inevitably, users experience numerous difficulties with entering data and under- standing unusual data on reports or fitting in unusual cases. The unit gives the needed information and instructions and responds to problems expeditiously. When a problem exists, the unit determines whether the source is the system or the worker's failure to follow proce- dures. The former requires consultation with data processing staff to determine the cause and the time frame for correcting it; the latter requires giving instructions to the staff on what they need to do. In the case of a problem without an identified or immediate solution, the unit explains why and when, defusing hostility and, as needed, creating a more realistic under- standing of the system’s capabilities. A log of all questions and problems is valuable for several reasons. The identification of system-related problems provides documentation of technical instabilities that may justify an overall technical review of the system. The frequency of the problems may be an indicator that the users have a seriously low confidence level in the system. In that case, some formal statement and an emergency corrective action plan are imperative for restoring the confi- dence level to normal. The log of questions also reveals areas where users lack a working knowledge of procedures; if the need is widespread, it may indicate a need for technical assistance or training. An equally important function is overseeing the quality of the data. This involves monitoring error reports and the correction of errors entered into the system and checking on complete reporting. Some systems require more monitoring than others. In some cases, more intensive review is necessary because more complicated error correction procedures cause confusion and difficulty. In other cases, systems have limited rewards or negative consequences for the worker and encourage lazy data reporting unless active monitoring is in effect. For example, only intervention corrected the situation when one service worker in a local agency deliber- ately refused to update the information on his foster care caseload until the monitoring unit contacted him personally about reporting the cases; he had been waiting to see if the unit could identify him. Systems with service payments for day care providers, foster homes, and 80 other providers, and with other worker payoffs provide incentive to report accurately and consequently reduce (but not altogether eliminate) the need for monitoring. System identified errors are the first monitoring priority. Errors adversely affect the accu- racy of the data and the system's reputation on reliability, ultimately reducing all users’ appreciation of the system’s value. The unit must monitor to insure that prompt correction of errors is taking place. When the error levels become consistently high, staff must take action to identify the source and causes and then resolve the problems. The source may be the workers, the data entry operators, or even the system. Correction of the underlying causes of errors helps prevent extra work by the service workers in reentering the same data as well as disillusionment with the system over the seemingly endless work it creates. Monitoring goes beyond examining errors and reviews the overall data quality in the system through two basic methods: 1. Reading a sample of cases in the system and comparing narrative case records with system data, and 2. Identifying a random sample of workers and looking at a certain number of cases to determine whether they have been reported to the system. Texas has staff who do both for their social service system. Virginia does the first as part of their general monitoring of foster care cases. Identification of discrepancies requires action to request accurate reporting. This benefits not only the individual cases reviewed but also the total reporting for the system, because the impression of ‘followup’ or “management taking the system seriously” encourages more conscientious reporting. Another responsibility of the user advocacy unit is responding to different users’ informa- tion requests. The unit may handle these requests by referencing a library of reports or using easy software to produce a report. The latter may be done by the unit's staff or by data processing resources. This is discussed in the chapter on utilizing information systems. The unit also assesses the need for training on the system, based on the users’ questions and problems, results of monitoring, and the utilization of the system. If needed, the staff delivers or arranges for the training. Training needs may center around the forms, reports, or the general utilization of the system, and may vary for different management levels or func- tional groups. More than likely, during the initial training the users concentrated on learning the forms and procedures and retained little on the reports. After the initial shock of installa- tion, they require training on the use of reports and other available information that could be requested. Little experience in using information also increases the need for training. Gener- ally, new supervisors and service workers need basic training on forms and procedures. This occurs more frequently in organizations with high turnover rates. The last responsibility of the unit is identifying the need for system changes and improve- ments, determined as a result of system evaluations and daily contact with the system and users. Throughout their work, staff become conscious of and receive requests for changes needed in forms and reports. New ideas emerge on more effectively gearing the system to the users. Some requirements and enhancements result from users’ increased sophistication in terms of data and automated systems. The user advocacy unit must track the needs, assess their value through the appropriate involvement of users, and determine the user impact and the technical impact with the data processing staff. If the changes are feasible, the unit must plan for their orderly incorporation into the system. Evaluation Process The formal evaluation begins approximately 1 year after the complete installation of the system, when stability has been acquired in the user environment that makes possible an analysis of costs and benefits. The year’s operation also provides users and technical staff 81 sufficient experience to judge the system and to determine needed changes. This section describes some typical problems of an operating system and the method of evaluating the system. Method Review of the system’s objectives and documentation is the first stage of the evaluation. it requires reviewing all available documentation and records on the system that include the aims, benefits, and descriptions of the system. The types of information commonly available and valuable for the initiation of the system study are: System Aims and Benefits e Planned system objectives ® Expectations and projected benefits of the system eo Cost-benefit analyses ® Projected users of the system Descriptions of the System General design document User's guide Forms and data collected Reports generated e Operations guide The purpose, benefits, and functions of the system as originally articulated establish the baseline criteria for the evaluation. The fact-finding and analysis process, the second stage of the evaluation, involves the collection and study of information on the critical areas of the system: Performance of the system Cost User’s guide Forms Error procedures Data control and data entry Reports Utilization of information Computer system design System documentation Hardware support e Staff support Some of the questions are: How is the system working? How well does it meet needs? What benefits emanate from it? How appropriate are the forms and reports? How well can the computer accommodate the workload? How efficiently does the system run? and Does the system operate within budget? The methods for answering these questions are (1) study of the records on the system’s cost and all the critical areas identified above, (2) interviews of key personnel in data processing and the user side, (3) involving the user groups in an ongoing evaluation process, and (4) questionnaires to staff using one or more parts of the system. Known problems are another source of information for the evaluation. Implemented sys- tems may experience one or more problems with equipment, faulty system design, insufficient technical support for operations, poor integration into the user environment, low data accu- racy, and inaccurate estimates on the system's impact. 82 A major data processing problem is the system exceeding the capacity of the hardware, requiring an expensive upgrade of the equipment or, otherwise, the slowing down or curtail- ment of the system. Response time for online systems may become excessively slow, causing users and data entry staff to lose time waiting for the information to appear or be entered. Sometimes these equipment problems occur because of poor original estimates, but other times the volume of reporting increases dramatically because of a higher level of activity than before or greater user acceptance and use of the system than expected. The increased volume often creates a demand for more data entry and data control staff. These situations may also lead to the problem of insufficient staffing for maintenance as well as for data control and entry. If data entry or control are neglected or understaffed for any reason, the entire flow of data between the computer and users may become plagued with countless demoralizing problems and delays. Another data processing problem is equipment breakdowns. Design errors or system ‘bugs’ not properly identified or solved can create havoc with the system. If the recommended testing procedures were followed, these bugs should be few in number. On the user side, the reporting of data and the usage of reports may not happen as planned. Data quality may be poor, the bane of every system. Analysis of Data on the System. The information available and useful for the analysis includes the system development cost, monthly and annual operating costs, documentation on realized savings and avoided costs, and data on workload demands (volumes) on the system and hardware support and usage. Logs tracking system problems and changes recommended by users are valuable keys for guiding detailed study and identifying necessary changes and enhancements. Analysis of the data gives a comparison between the estimates made during the design phase and the actual experience for: ® costs to develop the system, ® volume of system activity, and ® operating costs. The records are usually available for the analysis after some time-consuming tracking and retrieval of the relevant information. Higher volumes and greater operating costs are danger signals for the system exceeding hardware capacity and going beyond the data processing budget. Interviews. Interviews are the best method for appreciating the varied users’ indepth reactions to the system. Interviews should take place with all levels of users and affected functional groups to obtain their view of how well the system responds to their needs and of its value and success in achieving the originally articulated objectives as well as new ones. Their appraisal of the forms, data elements, reports, and the system's suitability with operations or integration with management decisionmaking should provide a comprehensive understand- ing of the system's performance from the user perspective. During the course of the interview, the user will probably bring out problems and desired improvements that require further consideration. Since many social service systems have such a large number of users, indi- vidual or group interviews may be possible only with a ‘representative’ sample of users. The Questionnaire. The questionnaire is an efficient method for obtaining the majority view on a system having many diverse and scattered users. A mail-out questionnaire can obtain the perspective of the majority of users on all pertinent areas of the system—technical assistance and training provided to the user, the users guide, forms, reports, ad hoc usage of the system, data control, and data entry support. The basic questions on the forms and reports are similar to those asked during the design phase. Properly designed questionnaires are effective in bringing out responses useful for determining general system performance and areas needing system changes or enhanced understanding. The responses provide indicators of user satis- faction and system performance. 83 To distinguish between satisfactory and unsatisfactory parts of the system, the questions must relate to each form, each report, etc., and should have the same criteria used in the design process. Questions on usage of reports should provide a continuum of possible responses reflecting the degree of satisfaction and usage. Appendix B, figure 4 shows a sample set of questions for a report. A question asking the ranking of reports from highest to lowest importance and/or usage may confirm and provide further understanding of the relative acceptance of different parts of the system. Questions on forms are similar to those for reports. From this discrete information, it is possible to identify the particular reports, forms, etc., which are useful and easy to use and do not need major changes and further study. The troublesome or little-used parts are also easily visible. Further analysis to determine the underlying problems and changes required should be done on these problem areas. Items showing moderate to marginal acceptance and use frequently require additional investigation for fully understanding needed improvements. Questions may also be included on ideas tentatively formed before the formal evaluation process begins on potential system improvements and proposed alternate solutions for problems, including suggestions initiated by the user. Then the system designers have the opportunity not only to learn about the potential users’ response but also to determine preferred enhancements and solutions. The widespread input through the questionnaire facilitates and expedites the planning of changes. Different users may vary in their use and satisfaction with the system. The questionnaire should solicit information about the individual's position and his exposure to the system through training and technical assistance. This can reveal the real uses of the system, levels of staff and functional groups not working with reports, etc., and what needs for training or technical assistance exist and for whom. Automation of the questionnaire results through a user-oriented software package program like the Statistical Package for the Social Sciences can facilitate the tabulation and analysis of results in a manner more instructive for planning future changes. The format of figure 4 in appendix B is structured for SPSS and data entry's use. Comparisons among regions and differentiation between service workers and agency directors are possible, allowing the development of strategies for specific rather than general needs. Participation of User Groups. The continued involvement of user groups after implementa- tion can facilitate the evaluation if they are encouraged to report formally on troublesome aspects of the system and to recommend both minor and major improvements. With this monitoring of the system's performance, the user group can come to quarterly or semiannual meetings prepared for intensive discussion on the significance of system problems and the relative merits of proposed solutions and enhancements. All individually originated recom- mendations will thus have an opportunity for a hearing with many users, and the consensus of the broad-based group gives credence to the value of a proposal for change. Furthermore, the group can contribute to both the development of the questionnaire and the analysis of its results. Their participation in many ways helps the system evaluators formulate the final recommendations. Conclusions and Recommendations Interpretation of the data from the system’s records, interviews, user groups, and question- naires allows conclusions to be reached on what goals and objectives the system has achieved, which activities the system performs adequately, where technical and user prob- lems exist, which operations and data are unnecessary, and what support to the users is needed. Some of the more specific areas are the technical efficiency and responsiveness of the system, equipment usage, adequacy of data security and control, adequacy and excess of data being collected, quality and accuracy of the data collection, adequacy of reports in terms 84 of quality and quantity, and their usage. The ultimate question is whether the cost of the information system is reasonable in relation to realized and remaining potential value of the system. The assumptions behind the inclusion of data elements on the system should be evaluated extensively to determine their validity. The collection, processing, and storage of data ele- ments have substantial hidden costs, and no data should be retained in the system if itdoes not serve a purpose. The analysis of the actual use of elements should determine what elements should be dropped from the system. Recommending changes needed for correcting the unsatisfactory parts of the system, incorporating needed enhancements, and improving the system support for users should be the end products of the evaluation. The changes may include redesigning the computer system (for example, the data base), adding or dropping data elements, revising inquiry screens and reports in such ways as format and data element changes, and eliminating or adding reports and screens. The proposed modifications should make the system more cost efficient technically and easier for users to handle. The changes in reporting and data accessibility should also enhance the overall value of the system for users. Elimination of unused data elements reduces the data collection burden on the service workers and lowers data processing costs. The additional system support may include training, a new users guide, and emergency phone assistance. Some changes may involve only minimal technical support and cause little or no disruption to the users. Other changes can have a widespread impact on the system and require substantial effort, affecting forms, reports, and user’s guides, as well as the programs and system documentation. The process of change can have an unsettling effect on the user environment, and many significant changes within a 1-year period may return a stable system to the rocky pains of a new system. Changes of magnitude require the same painstaking planning and implementation steps that occurred with the original design. A year may be necessary to carry out all enhancements, and users may need special training to forget the old processes and to learn the new. Changes to the form, its layout, and the data collected (elements and values) have the biggest effect on the worker. Unbelievable confusion can result from changes on just a few elements, with staff mixing up the old with the new even when training has occurred. The hoarders of the old form continue to use it until the supply is gone, and some staff attached to the old elements may complain about the revisions as late as 2 years after the change. Changes on the basic data collection instrument, except for minor cosmetic or spacing changes, should occur as infrequently as possible, provided that users have indicated general accep- tance of the form. Certainly, the changes should not occur more than once a year. A factor to consider in changing a data element or value is the implications for the historical data base and identification of trends, key comparisons, etc. At times it may be more useful to keep a somewhat less satisfactory data element that allows comparison across a 5- or 10-year period than a preferred new data element without a historic base. Changes gaining easy understanding and favorable visible user responses are those related to streamlining or improving reports. Perhaps the problems of the report may relate to format, content accuracy, or the up-to-date quality of the information; some of these aspects may be easily changed. Examples are producing a monthly report less frequently (quarterly or semiannually), combining two reports into one, adding a needed data element or dropping an unnecessary one, and starting certain information on a new page. However, the introduction of a new report requires orientation for its effective use so that workers and others do not feel overloaded by paper. In deciding on changes, it is necessary to consider the cost. New reports or changes to old reports may be expensive depending on the requirements. The correction and/or addition of programs is always a substantial additional cost, particularly if the data are not currently 85 collected, coded, or cross-referenced in a manner suitable for the change. Establishing new relationships between data elements is also difficult. Most costly are changes that require going back to the input forms and introducing additional manual procedures to compensate for omissions. These changes may cause form changes and unplanned increases in data collection, with consequent user dissatisfaction and need for additional training. However, it may be possible to produce many changes without going back to the input forms or changing data relationships; the data may already be on file and can be added to or made available for the report. If the system is linked to a report generator program, a format change may be made easily. The key to successful introduction of change is careful planning, using the same techniques employed in the original design of the system. For significant system changes, a formal evaluation of the system should occur subsequent to their implementation to assess their value. VII. Acceptance of the Social Service Information System Ultimately, people will determine whether and to what extent an information system will succeed or fail. People supply the data to the system, and people use the resulting information. Their response to the system along an acceptance/resistance spectrum affects the quality and quantity of data entered and the accuracy, value, and utilization of the system’s products. Understanding the underlying human factors in responses to a computer system is crucial to improving the chances of planning and installing a well-accepted social service information system. This chapter describes the acceptance and resistance responses to a system, in particular the unique concerns of the caseworker that can adversely impact its acceptance. In addition, the strategies and factors promoting system acceptance and the effect of the major changes occurring during system implementation on people and their attitudes are discussed. Acceptance and Resistance Acceptance and resistance are two counterresponses coming into play at the introduction of an information system. The sponsoring organization strives to maximize acceptance of the system and minimize resistance. Acceptance occurs when caseworkers and their supervisors place a high priority on correctly reporting data into the system and users actively employ the reports as intended. Resistance takes place when workers report partially or inaccurately or fail to complete documents. This may lead to a vicious cycle in which the worker sees the data in the system as erroneous, out-of-date, and consequently useless, and this view instills a negative attitude toward reporting accurately and updating the data. Resistance occurs when users distrust the computer reports, maintain manual systems intended to be replaced by the system, and/or openly criticize the accuracy and value of the system. The behavioral responses related to acceptance and resistance form a continuum ranging from enthusiastic acceptance to deliberate sabotage. The range of reactions is shown in figure 7 (London, 1976, p.89). This spectrum represents the varying acceptance/resistance levels for both the provision of data and the use of the system’s information. While the display is one dimensional, in actuality the user will have varying response positions related to specific system parts rather than to the total system. Figure 7. The System Acceptance/Resistance Continuum High Reporting and Usage (Acceptance) Enthusiastic Acceptance Cooperative Support Acceptance 4 Acceptance Under Pressure Indifference Minimal Requirements Partial Withdrawal ’ Criticism Open Opposition Deliberate Sabotage ¥ Low/No Reporting and Usage (Resistance) 87 High acceptance is needed for a system to operate effectively. This status is difficult to attain for a social service information system because of the caseworkers’ negative attitudes toward systems and computers and the social service field's inexperience in using computer- generated information. The next two sections examine the underlying causes of negativism and suggest strategies for accommodating caseworker concerns and building acceptance of the system. The Caseworkers’ Concerns Understanding and considering the caseworkers’ attitudes and apprehensions about social service information systems can facilitate a system’s design and implementation and help overcome resistance. Caseworkers’ support is crucial because their willingness to provide data directly affects the success of the system. Obtaining their support is difficult because they are more resistant to the introduction of systems than other staff groups. Historically, caseworkers have had little interest in and involvement with information sys- tems. Computers do not hold much appeal for them, and they selected the social work profession over science or accounting fields, etc., because of their preference for working with people rather than numbers. For the most part, schools of social work have not incorpo- rated the computer into the curriculum. Although information systems are being used increas- ingly in the social service field, narrative case recording continues to be emphasized by professors as the documentation method in casework. While the computer cannot replace this documentation, a blending of the two should occur so that the automated information does not duplicate what is already in the case record or vice versa. From the standpoint of support for the caseworker, it is difficult to make an unequivocal case for the computer and for automating social services. While the computer can handle many secondary activities such as statistical reporting and service payments, it is not able to perform any primary casework functions equivalent to, for example, the eligibility determina- tion function for the client's financial assistance needs. The prevalent worker attitude is that computers will never be much help in social services. These factors create a strong reluctance to develop and use social service information systems. Often the surfacing of plans for using the computer in social services causes immediate waves of apprehension among caseworkers. They fear that the system will increase the already excessive paperwork and take more time away from helping clients, a mission of the agency and the workers’ primary source of job satisfaction. In effect, workers feel that pushing pencil and paper will rob time from protecting children, keeping families together, finding housing for the homeless, preventing unnecessary institutionalization of the elderly, etc. System planners promise less paperwork, but caseworkers have not seen convincing proof and disbelieve the promises. In addition, they believe the expense of an automated system uses money that should be available for services to clients. Another fear relates to the caseworkers’ belief that automated information systems invade the individual's or family’s privacy and threaten the confidentiality between the client and the worker. The concern is greatest with systems containing name information and highly per- sonal data pertaining to child abuse and neglect, adult protection, sexual behavior, and other individual or family assessment data. Chapters 5 and 8 discuss this issue further. The system also represents a threat to the caseworkers’ autonomy and flexibility (1) where it monitors and/or requires adherence to procedural rules and (2) where it gives organizational visibility to the workers’ activities. Regarding the first, the computer's tighter monitoring of procedural requirements may sometimes cause difficulty in responding flexibly and in a timely manner to clients in special situations. For example, the system may require a record of current certification or approval of day care providers before a mother can use a provider for her children; the short-term unavailability of the provider with an expired approval may cause the client needing immediate day care services to lose a job or new employment opportunity. The organization may have to restructure its work so that it can accommodate the tighter adherence to procedural requirements yet remain flexible in serving the clients. The second concern affecting worker autonomy is the data available on the worker's activities. This may be the first time the supervisor and organization are given comprehensive information to use in evaluating the caseworker, identifying mistakes, comparing productivity among other workers, etc. In organizations with a past history of punitive supervision, this new visibility may be perceived as a threatening rather than a constructive tool. Moreover, super- visors who have generally been promoted from the casework position are likely to share the workers’ views. Administration is more likely to see the system as an adjunct to their functions and is supportive of its development provided that an inordinate paperwork burden does not fall on the caseworkers. Building System Acceptance Strengthening the acceptance of a social service computer system and minimizing the resistance factor comes from many interrelated sources: Positive communication and participation, Quality system design, Organization’s history with systems, Management's support for and use of the system, Method of installing the system, and Effective operation of the system. Participation and communication are effective strategies for anticipating the needs of users and minimizing the resistance factor during implementation. Participation in the design phase helps overcome resistance because staff tend to accept and be committed to the system they helped design. Moreover, the design is probably superior to one developed without their ideas. Through involvement, staff have the opportunity to be informed regularly about the system, to shape the design, and to exercise some control over the changes caused by the system. Various forms of participation exist, with the more active and authentic being most effective in raising the acceptance level of the system (see chapter 3, Involvement of the User). Along with participation, formal communication provides an essential exchange of informa- tion during all phases of the project. Information sharing on such areas as objectives, ac- complishments, and plans reduces unfounded fears, provides a means of answering ques- tions, and prepares people for the anticipated changes. Secrecy only creates resistance, which becomes stronger when staff never have the chance to explain needs, are kept in the dark, and told to change without any consultation. Communication should occur through the formal announcement of the project, consultations and group meetings during system plan- ning, formal sharing of the system design and plans for implementation, distribution of major descriptive documents, and finally, introductory and training sessions for staff as they prepare for their first use of the new forms, procedures, and equipment. The quality of the system design will affect the caseworkers’ satisfaction with the system and their willingness both to provide data and to use the resulting reports. The critical parts of the design for the workers are the forms, data elements, inquiry screens, computer output, correction of errors, and flow of data. Too many forms, excessive time to complete forms, frequent correction of information already entered, poor turnaround time, and lengthy or useless reports are indicators of design problems. If during the system planning the people factors are considered sufficiently and the users are actively involved, a relatively sound design acceptable to staff should result. Previous system development projects will influence staff's perception of the new system. Positive past experiences create confidence that the organization has the ability to implement a new system successfully. The converse is true for negative past experiences, particularly if the latest negative effort was more complex with a much larger scope. The planning of the implementation should recognize this factor, maximizing the gain of earlier successes or addressing the fears of another disaster. Management's endorsement and support of a system are critical because their views flow downward, establishing an organizational response that influences supervisors’ and workers’ acceptance of the change. Staff are quick to take the cue. By making visible their formal plans to use the information and by actually using the data after the implementation, management can heighten their positive influence and convince staff further of the system's value and the need to make a serious effort at accurate reporting. The introduction of the new system can cause disequilibrium in the organization; however, the methodology for installation can minimize the pain associated with such change and increase the chances for system acceptance. The desirable approach involves (1) presenting the system in realistic terms, (2) preparing the organization and personnel fully in relation to the changes and their probable impacts, (3) setting realistic time frames for converting to and introducing the system, and (4) installing only thoroughly debugged systems. A realistic and complete presentation of the system not only helps staff understand the nature of the changes, the reasons behind them, and the expected benefits, but also encour- ages staff to work with the system less reluctantly, if not willingly. However, the system must be sold in realistic terms because any overpromising will later produce negative counterreaction and disillusionment. The organization and its personnel must be prepared to accommodate and manage the changes associated with the introduction of the system. The scope of the change should be a key factor in determining the preparation, technical assistance, and training necessary for the staff to begin using the new system and to overcome initial resistance. The next section discusses the need for the training program to address the possible changes introduced by the system and their impact on the staff. The time frame for the system installation must be reasonable for all work to be ac- complished and for personnel to have sufficient time to get used to one change before another is initiated. If many changes are to take place, it is preferable to introduce them gradually over time, as a too ambitious time frame may overwhelm and exhaust staff, causing them to fight the change every step of the way. A smooth technical operation is the last factor affecting the system's acceptance and is absolutely essential. This means proper data handling, accurate data entry, correct informa- tion processing and printing, and, finally, the right distribution of forms and reports. The caseworker has no understanding or tolerance for even a 1-percent error rate. Any data processing problem immediately shakes the credibility and perceived value of the system; frequent problems cause hostility and open protests that can approach revolt. The staff's weak faith in data processing demands high operating standards. A counterbalance to implementa- tion problems is a handy emergency phone for staff to get help in solving the latest impossible problem. Major Changes Affecting People The changes associated with the introduction of an automated information system are potentially far reaching. The extent of the impact relates to the difference between the existing operation and the new system. For social service systems, most changes fall into four group- ings: (1) new documentation methodology, (2) changed work processes and procedures, (3) 90 new equipment, and (4) staffing changes. If the system is to succeed, people must be helped through these changes. New Documentation Methodology The automated information system brings a new documentation methodology to the social service organization. The most basic changes are the introduction of computer forms and codes and the production of reports that allow the replacement of manual files, documents, and even narrative case recording in varying degrees. Codes rather than English words are predominant. This documentation may represent an interference with, if not a revolutionary departure from, the narrative case recording encouraged by supervisors and taught by profes- sional schools. It traditionally has provided and allowed insight into a case situation and allowed the supervisors to assess the caseworker’s ability to analyze and solve problems. The new documentation methodology may also eliminate customary paper documents, cards, etc., through the use of computer terminals as a high-technology, paperless reference file. The terminals create a more sophisticated information system that allows access to an immediate visual display of current information on selected topics. Changed Work Processes and Procedures The information system also brings revised organizational procedures regarding the flow and reporting of information and the obtaining of approvals to offer purchased services to the client, etc. Some of these changes allow greater flexibility, but others impose new rigorous standards. In terms of flexibility, the information system may relieve staff of manual controls if the computer can monitor and require certain conditions, thereby giving the staff more ~ freedom of action while insuring management their requirements are met. For instance, the caseworker would not have to request approval of the supervisor or fiscal officer to order certain services for the client; the order could simply be entered on the computer, and the machine could indicate the availability of funds and approve the order. Of course, the savings of time from internal controls would be replaced by a rigid and longer schedule that could make the agency unresponsive to the client. Generally, the information system creates tighter controls over procedures and establishes less flexible schedules that force the staff's adherence to the rules, making it more difficult to accommodate the exceptional situation and bend the rules for the client’s service needs. The caseworker must adjust to having fewer discretionary powers and less autonomy in dealing with the exceptional client. Changed work processes may also occur. A computer report may list actions due and overdue, covering the client eligibility redetermination, approval of a vendor, renewal of a purchased service, court action, etc. It brings the caseworker’s attention to tasks that must be completed immediately or within the near future. The caseworker must adjust to having such a compelling work list and to the negative consequences that might occur if the actions are not completed. For example, the client may no longer receive in-home services if his eligibility has not been redetermined. The computer-produced information may also lead to a reexamination of supervisory and management roles in light of the data available to compare workers, supervisors, and agen- cies, and to assess quantitative and some qualitative aspects of social service programs. The system can provide a richer information base for making supervisory and management decisions, but its full impact in this area will not be realized until the social service field acquires more experience in using data and learning what to do with it. This is discussed in the chapter on utilization of information systems. 91 New Equipment New equipment is another major change. All organizations will need some office equipment to deal with computer input and output. Time should be taken to make the best selection of equipment, so that staff will be comfortable with it. Special binders and shelves facilitate handling and storing the reports. If some output is in microfiche, readers and a microfiche copy machine are essential. Another essential item is a paper shredder to destroy obsolete forms and reports with name-identifying information. All this is helpful for managing computer reports and documents, but is relatively uneventful. The dramatic change is the presence of computer terminals and printers for data entry and visual data display. They require careful planning for appropriate location, use, and staffing, and provoke rethinking on documenta- tion, procedures, and work processes. Staffing Changes Staffing is the last area of major change. The information system may eliminate some jobs, change or combine others, and even introduce new positions. The jobs most vulnerable to elimination are ones involving manual creation of statistics, processing of financial data, and management of card files. In all probability, these positions will be needed for other jobs related to the system or other organizational functions, such as clerical support for casewor- kers. Contrary to theory, implemented systems have rarely caused individuals to lose their jobs. The new jobs usually relate to data entry and data control, management of the data flow, and corresponding documents and reports. For larger service organizations and State agen- cies, positions may be necessary for handling system problems and supporting the utilization of the data. At the caseworker level, the system should not affect the structuring of service staff. Reactions These major changes may trigger many varied reactions among users. Caseworkers’ con- cerns have been discussed earlier. Supervisors and administrators have concerns over the visibility of the worker and agency information that allows evaluations and comparisons among supervisory units and agencies. The system can represent a potential erosion of authority at lower levels and centralization at higher ones. Some local social service agencies in a State-supervised/locally administered system, as in Virginia and New York, may regard a central information system as the first step toward a ‘State takeover.” The social service information system may affect other personnel besides the caseworker, supervisor, and administrator. These staff may include data processing personnel, clerks, statisticians, fiscal officers, planners, and evaluators. Their response to the system also needs to be understood and considered. All personnel will have, in varying degrees, general concerns and questions. A nagging worry for many is whether they will be able to cope with the change and adapt to the new procedures, techniques, and equipment; this anxiety increases when the system is large and complex. Some will see the system as useless and fear where the change will lead to. More supervision and less freedom may occur after the installation. The system may also cause a loss of status and control for individuals who derived their influence from their wealth of information or bestowal of approvals, which are now in the computer. Clerical staff in particu- lar will worry about losing their jobs or having completely new ones; supervisors will be apprehensive about losing positions. General fears exist about the giant unfriendly machine messing things up and making work more difficult. Little experience with information systems is likely to encourage more fearful and irrational views of the computer and its effects. 92 A study of the system’s positive and negative impacts is necessary for each type of staff affected by the implementation. This analysis helps anticipate and plan for staff reactions and makes possible the development of training programs that address concerns, eliminate unfounded fears and create a more positive environment for the installation of the information system. 93 EPR : z ) # 1 : - . v ROR, Ser or E BE Ss is VIII. Child Protective Service System Systems for child protective services have provoked considerable interest among social service organizations. Top-level management and program managers have pursued the feasi- bility of planning and implementing such a system, and today some State and local agencies are operating successful systems. The origins of the child protective services system are in legislation around the reporting of child abuse and neglect. In the 1970's, as the problem of child maltreatment became an area of social concern and public responsibility, States enacted legislation that mandated the reporting of abuse and neglect and in many cases even encour- aged or required private persons to report. The child protective services statutes led to State agencies developing administrative procedures for reporting, investigating, and providing treatment and services to families and children involved in incidents of child maltreatment. Many States established a central registry, a single despository of information about offi- cially reported known or suspected cases of abuse and neglect. In most cases, the approach was a manual effort, but in others an automated system was developed. This automation brought into existence the child protective services information system. Recognizing the continuing interest in child protective service systems, this chapter draws on the experiences of different organizations and discusses the potential scope of the system, as well as options and considerations for management and users about to undertake a system development effort for this service program. Many dimensions of the child protective service system are brought out through a discussion of its distinguishing features, optional charac- teristics, and associated implications. The program manager's specific concerns are addres- sed: the purposes and functions of the system; key decisions for planning the system, such as the inclusion of names; the data collected; and linkages with other systems. The chapter also discusses managers and workers utilizing the information and its value for the protective services program. Purposes and Functions of the System New York, Virginia, Texas, New Hampshire, Illinois, and Utah are among the States that have operating child protective service information systems. Review of their experiences reveals that, despite organizational and geographic differences, protective service systems have a common set of purposes and functions. The purposes encompass not only the maintenance of the depository and statistical reporting on child maltreatment, but also the performance of management functions. A list of these purposes follows: e Supporting the maintenance of the central registry, e Supporting the protective services telephone hotline, Tracking and identifying cases, Monitoring the investigatory process, Purging founded and unfounded cases and old data, and Supporting the management of the child protective services program through a data bank for program planning, public awareness, resource development, training, and statistical reporting and analysis. To provide a full understanding of the purposes and related functions, each is described separately, along with variations in scope and limitations. Central Registry Maintenance Maintaining a central registry for collecting all officially reported cases of child abuse and neglect, whether substantiated or not, is the most basic function of any child protective services system. Automating the central registry can significantly improve the collection, processing, storage, and retrieval of case data while conversely reducing the manual handling and files, particularly where a State has a high volume of reports. Virginia gives an example of maintenance problems and the system as a solution. As the number of child abuse and neglect complaints rose to 21,000 in the central register’s first year, the State's manual information system became incapable of handling complaints in com- pliance with the law. Enormous paperwork problems developed from burgeoning files, misfil- ing, and inability to keep files up to date. Since the cases were filed by the child's name and not identified as part of a family record, it was not easy to know if a reported child was part of an already known abusive family. It was difficult to monitor whether reports were investigated and filed within the time frames specified in law. The manual registry was so unwieldy, little data could be retrieved. Two years later, the State implemented an automated child protective services system and eliminated all manual files. While an automated system can replace manual files, the computer cannot retain in a cost-effective manner lengthy, open-ended narrative describing the rationale for establishing the case founded or not. If this narrative is important to have available in the central registry, all or part of the manual files will need to be kept, possibly transferred to microfiche. New York's central registry consists of both the automated system and the microfiche records on founded cases that detail the basis for determining a report founded. Protective Services Hotline State organizations may have a statewide child protection center operating with a toll-free number to receive reports of known or suspected child abuse or neglect. The center may operate 24 hours a day, 7 days a week. Staff give assistance to persons reporting and then request the local protective services program to investigate and, as needed, provide indi- vidualized services. The information system supports the protective services hotline by various management reports. The hotline’s volume of telephone activity can be indicated by a report showing the volume of specific types of calls and the time of day; supervisors can then determine the appropriate level of staffing for various times and days, particularly in peak periods of tele- phone activity. The need for schedule shifts or additional personnel can be determined through use of the same report. Another support for the hotline is the system's capability for tracking cases to see whether a suspected child victim or perpetrator of abuse or neglect is already known to the protective services program. Tracking Tracking offers benefits through identifying previous reports on a child victim and his/her family or alleged perpetrator. Many State agencies regard this process as critical and invalu- able and believe that it may save a child's life. Its value lies in offering preinvestigative information rather than prevention, as it occurs after a complaint has been made, not before. Tracking gives a partial picture of the situation from earlier investigations and may indicate the need for a more rapid investigatory response than the latest report suggested. It provides minimal diagnostic support for the investigatory and treatment processes. Tracking also allows more effective intervention on borderline cases where previous reports exist. The information collected on previous occasions may be valuable if a case is close to being determined founded. The past evidence of abuse and neglect and the identification of previous workers involved with the family may also be helpful in substantiating court cases. When the worker locates a family in the registry and the system does not have sufficiently detailed current information, he can identify and contact the previous caseworker in that locality for more detailed and current information. Tracking encourages communication between the current and previous service worker and fosters the traditional caseworker consultation for meaningful information exchange and diagnostic support. Sometimes the system reveals that another caseworker within the same agency or in another locality is working with the family, making it easier to coordinate efforts. The system’s abbreviated diagnostic information limits the data’s value for tracking, but it also has a side benefit. It prevents inexperienced or insecure workers from using the system as a crutch. Otherwise, they may rely too heavily on information from past investigations and not evaluate fully the current family situation. This would be giving inadequate child protective services and be a disservice to the family. Tracking capabilities generally do not extend beyond State boundaries. The system can track intrastate family movement but cannot follow highly mobile families moving across State lines unless interstate agreements and legal bases are developed for sharing name informa- tion. Some service workers have felt that some families moved frequently to avoid a full-scale protective service investigation, but research has not documented the scope or existence of this as a problem. How does tracking work? When a suspected case of abuse or neglect is reported by a child's neighbor, friend, family member, or a professional, the central registry worker takes down the information and checks a computer listing or through a computer terminal inquires about previously reported children and the alleged abuser or neglecter. A report is a cumbersome method and not completely current where the volume of cases is high. Computer technology can provide better support for this function through terminals with online inquiry capability. Instead of thumbing through the report, the writer can immediately scan the computer to see whether the person is a previously reported child or perpetrator. Using a technique called Soundex, the computer is capable of scanning all names that sound even remotely like the name being searched for and of matching for characteristics like sex, race, age. If the person is known, it is possible to obtain the past abuse and neglect history. In instances where 24-hour coverage is available and the central registry is receiving calls around the clock, it may be necessary to have some backup reports, preferably in compact microfiche, when the online service is not available. Monitoring the Investigatory Process The child protective services system provides quick access to information on the handling of investigations in compliance with law, gives a clearer picture of what is happening statewide, increases accountability to the State organization, and decreases exceptions to the law. Specifically, the system can determine the status of each child abuse and neglect investigation, assess the local agencies’ and caseworkers’ compliance with some of the statutory and procedural requirements, and provide overdue warnings on actions potentially out of compliance. The determination of each investigation’s compliance is generally accomplished through system checks on the completion of required activities and their performance within time standards. The system’s capability to track a specific worker as responsible for complying with the law on a particular investigation requires a positive, constructive use of the information. Otherwise, it will contribute to resistance and hostility toward the system and to a rift between the supervisors and caseworkers on one hand, and the administration on the other. The split may also occur between the local and central levels. As an effective tool, monitoring supports the worker's timely response to and completion of abuse and neglect reports, the supervisor's review of workers’ compliance with policy and immediate correction of any overdue actions, the local agency director's oversight of the supervisors, and the State's review of localities. 97 The system information also gives an understanding of overall agency and State compliance with the law and reveals the failure of specific localities to comply. Examples of this informa- tion are the average length of time to complete investigations and each phase, and the number of investigations or phases completed within the required time frame or 30, 60, or 90 days beyond. Study and even visits with the agency are necessary to determine the causes for difference among localities. Problems common to all localities may indicate problematic laws or policies. The system can also contribute to a broader monitoring effort and assessment of perfor- mance. The statistical data may reveal agency patterns in reporting that indicate the need for further study to assess causes and the need for any change. The data may show remarkably high or low rates of reporting or of substantiated or unsubstantiated findings. This is discus- sed further in the section on determining the agency reporting status. Another perspective on performance, which may be combined with or independent of the statistical analysis, is the review of the investigation work. The case review focuses on the worker's application of policy in investigating and determining the validity of child maltreatment complaints. The system can support this through the provision of a statistically valid sample of cases or child victims to be reviewed, and later through the provision of system data on these cases to be merged with the study data for analysis and interpretation. The system monitoring of compliance, analysis of statistical data on reporting, and the case review process provide a comprehensive approach for monitoring the investigatory process that can detect problems and lead to their correction. Purging Purging is the physical destruction of automated and manual records pertaining to the abuse or neglect report identifying individuals. Organizations should establish purging policies and procedures that specify which records should be destroyed when. The automated system should be designed accordingly. The policy safeguards the privacy of individuals. It reflects a balance between the responsi- bility of the agency to conduct a thorough investigation and the family’s right to privacy to not share information when there is no clear and convincing evidence of abuse or neglect. For founded cases, it balances the organization's need for the information to protect the child with the family’s right to a new start in life. Purging policy varies from State to State. The policy of one State requires destruction of identifying automated records and manual documents on all unfounded cases. ‘‘Atrisk’’ cases are left in the system for 1 year, provided that no additional reports of abuse or neglect are reported. All founded complaints remain for 10 years after the child's eighteenth birthday. Another State purges all records except those of founded cases. A third State requires by law the removal of all founded reports that have been in the system longer than 5 years. Factors to be considered in establishing the policy are discussed later. The protective services system can support the purge process in two ways. It can apply the rules of purging to the automated records by removing all identifying information and leaving only statistical data. The system can also produce a report for all organizational units holding manual records (including microfiche) to inform staff of the need to destroy particular records and/or, in some instances on founded cases, seal records. The same reports may be used by the security officer to monitor and verify the destruction of records. Management Support The child protective services system can provide support to policy development, planning and funding prevention and treatment programs, developing training both for professionals reporting child maltreatment and for workers investigating complaints and giving services, 98 targeting public awareness campaigns, and evaluating the child protective services program. The system provides administrators at all levels with the capability to quickly and accurately determine the volume of complaints, status of child abuse and neglect cases, and, depending on the system’s capabilities, services rendered. The information shows the magnitude of the abuse and neglect problem and the cases requiring supportive services to prevent further incidence of maltreatment. This can assist management in setting goals and priorities for protective services and in determining the need for and allocation of more staff. Texas has used the system for obtaining legislative support for the program and for addressing many legal suits. Effective use of statistical information can enhance the management and direction of the statewide program at all levels. The organization also has information readily available to respond to unexpected requests from the public, researchers, planners, journalists, and legislators. Information packets and special reports can be generated periodically to focus on key areas related to child maltreat- ment. A special analytical study such as on sexually abusive families, their characteristics, and problems could be used by the press and researchers and be supportive of new efforts in the child protective services program. The section on utilizing information discusses further the system’s support for management. At the worker and supervisory levels, the system can provide tools by which workloads can be better managed through caseload, status, and exception reports supporting the timely completion of work and movement of cases. However, to the extent that workers are carrying nonprotective services or preventive cases, worker caseload reports would be only a partial picture of caseloads unless the system is linked with other social service systems. Decisions The planning and implementation of a child protective services system requires careful decisionmaking in many critical areas, some of which are controversial. The major decisions relate to: The system as a statistical file versus an inquiry and management support system, The inclusion of names, Privacy rights and confidentiality safeguards, Centralized versus decentralized online support, The case dispositions to use for investigations, Purge policy, Data to collect, When and how long to report, and Linkage with other systems. Each major decision area is discussed indepth. Statistical File Versus Name Inquiries and Management Support The question is whether the system should be a central depository of statistical reporting on child maltreatment or an operational and management support system. Except for giving management a statistical data bank for analysis of the protective services program, the functions discussed cannot take place because they require, for the most part, name- identifying information, not just statistical data. All systems identified earlier include names and go far beyond a statistical reporting system. While the experience of organizations with operating systems suggests the inquiry and management support approach, each organiza- tion must decide what is preferable for its environment. The discussion on the inclusion of names covers this further. 99 Inclusion of Names The inclusion of names has significance for shaping the system direction because most functions described earlier require the use of names. Name-identifying data in an automated central registry raise the controversy of the right to privacy and the confidentiality of informa- tion. Many States have succeeded in automating registers with name-identifying information without a major challenge, but others have experienced internal and external obstruction and legal confrontations. Without name data, the system cannot go much beyond supporting statistical reporting and analysis. The central registry could only store and retrieve data by incident and not by family or child. Performing tracking and diagnostic functions and providing certain types of manage- ment support to central and local organizations require name data. Otherwise, most oversight, monitoring, and workload reports would be cumbersome, if not impossible, to use. Number identifiers for individuals are a poor substitute because they require users to maintain sepa- rate manual files for cross-referencing the number with the name. The reports are the motivat- ing factor for workers to document all child maltreatment reports and to give accurate, complete current information on each reported incidence; they are also the controlling point for insuring that this happens. Furthermore, only names make possible the identification of children and family duplicates in the system and detection of data inaccuracies. In effect, names support the integrity of the data base. A decision to leave out names in the automated system requires devising strategies to make the system useful to workers providing information and to minimize the problems of underre- porting and data inaccuracies. Including names requires consideration of strategies to protect the confidentiality of the information and to address worker concerns that could lead to opposition and hostility to the system. Greater care must also be given to another major decision area—the data collected. The inclusion of names also requires recognizing and developing plans to deal with staff resistance. The opposition of some caseworkers stems from several sources: anxiety about the threat to the privacy of individuals, the responsibility of the caseworker to inform the family of the inclusion of their name in an automated system, and the potential negative effect on the worker-client relationship. In addition, clients may appeal the caseworker’s judgment of the validity of the reported abuse and neglect in an attempt to have their names removed from the system. It is useful to give some background for each source of resistance. For some caseworkers, the most serious difficulty associated with keeping names is that it inhibits them from emphasizing their helping role with clients and from remedying the problem causing child abuse and neglect. When they notify families that their names are in a computer and describe their right to appeal, the workers may increase anger in the critical beginning of an investigation and create resistance to receiving services. This may keep them from successfully defining themselves as helpers to a family. A problem for these protective service workers may lie with a serious role conflict, which may occur when they have to balance simultaneously investigatory authority derived from law with a service orientation derived from the social work profession. Workers’ perception of the need to inform the client of his rights as a service barrier may be an extension of the larger conflict. Many workers are able to go beyond this problem and give services to the family. A risk associated with the informing process is that the parent may focus upon this as an issue rather than on the necessary changes in the family situation. The cause may be the client’s lack of understanding and misperceptions about the impact and use of one’s name in an automated system. They may perceive that the system is used by others outside child protective services when in fact it is a closed system. In any case, it increases the difficulties in providing protective services. 100 Every investigation of an abuse or neglect report raises the question of whether there is sufficient evidence to warrant substantiating a complaint, orenough indicators for an ‘at risk’ determination. The identification of names in the system possibly increases worker difficulty in drawing the line between founded, “at risk,” and unfounded complaints because this decision determines whether or not the family and the abuser-neglecter will be identified in the system and for how long. In some cases, the workers may be reluctant to label cases as founded because of the implications for entering them into the system, and some supervisors may support them. Furthermore, the anxiety of name identifiers is also exacerbated by the knowledge that the father who hits his child with a belt leaving marks and the father who kills his child are both defined as abusers and subject to being so identified for the same length of time. Concern about a potential appeal of their decision on the validity of the child maltreatment complaint also make the workers wary. Notifying persons that their names appear in the automated system may lead them to request removal of their names. This has the implications of an appeal of the worker's decision regarding the validity of his reported child maltreatment, given that the investigation findings determine the person’s identification in the system. Removal of name data involves studying the basis of the worker's decision and possibly overturning the previous findings. To the extent a State organization lacks clear criteria, local decisions are likely to be overturned, probably hampering relations between the State and locality and building worker antipathy toward the system. Once the decision is made to include names in the system, it is necessary to determine the procedures for respecting an individual's privacy and the security measures for safeguarding confidentiality. Privacy Rights and Confidentiality Safeguards Confidentiality and security of information are of paramount importance in a child protec- tive services system containing highly private information on a family’s life. Unauthorized access and improper disclosure of information could detrimentally affect persons identified in the system. The development of a plan to address the individual's rights and to protect the confidentiality of the information involves additional study and decisions on: ® notifying an individual about being identified in the system, e determining who has access to the system’s data and for what purpose, and ® choosing the security measures. State law may place requirements on notifying persons of their inclusion and identification in an automated system. If the law is silent, the organization must decide whether to notify the individual. In keeping with national concerns about privacy, it is preferable to inform an individual about his name in the system and provide a right to appeal the inclusion. New York has the most vigorous effort, informing people of the initial entry in the system followed by a letter on the investigation results, which indicates whether the name will remain or be removed from the system. At the same time, clients are informed of their right to appeal and, following this, a fair hearing. Virginia gives a pamphlet to clients at the time of investigation that covers the same areas. Other States inform clients of the manual records (which contain the compu- ter's information), but do not have special informing for the automated system. Who should have access to the system requires determining the legitimate uses and users. Unquestionably, checking the data base for any investigation work is the primary legitimate use. Another use related to protection of children is searching the system to see if foster home and adoptive home applicants are known as abusers or neglecters. In New York, this use has become mandated by law. Other States are performing a similar function. Again, the subject has the right to know any uses of this nature. Users may have direct and indirect access to the system. Direct access involves obtaining directly and often immediately the information for 101 approved uses. Indirect access requires going through a direct user to obtain information. Access issues are discussed further in the section on centralized versus online automated support. Many States have developed elaborate security measures for safeguarding confidentiality. Multiple levels may exist covering matrix code, password control, terminal identification, and dedicated lines, as well as separate physical security. At least one State developed technical security measures so tight (for example, password control for every inquiry screen) that the central registry staff make only limited use of the online equipment. Online Support Online automated support is often available for a child protective services information system and exists in all systems previously identified. The online capability can exist for both access to the information and the entry of data. This support may also be centralized and located with the central registry or be partially or fully decentralized in other sites. The organization must decide on the nature and extent of online capability and the corresponding confidentiality safeguards. The State-administered systems in Texas and New Hampshire have provided remote loca- tions with the ability to access information through inquiries; Texas also allows remote data entry. Two locally administered systems, New York and Virginia, have only centralized data entry and inquiries; however, Virginia may decentralize partially as a telecommunications network is established across the State. Some of the questions to be answered are: What confidentiality safeguards can be incorpo- rated into the organization's computer equipment? Is this sufficient for safeguarding the information in remote sites? How much greater are the confidentiality risks with remote usage of the data? Should the remote sites enter and update information? Should the sites be allowed access to inquiries? A decision to proceed with decentralization then leads to more detailed issues. If the sites have access to information, the limits on access must be defined. Specific questions are: Should they have access to name information only or to total case information? Should they have access to all cases or only their sites? The decision involves consideration of both the convenience and efficiency of decentralized access along with weighing the existence of sufficient security measures for insuring confi- dentiality. The next section discusses the disposition of investigations, which affects the recording of family and child data within the system. Investigations Dispositions The child protective services investigation has two or three disposition statuses. For exam- ple, New York has indicated and pending; Virginia, founded, unfounded with reason to suspect, and unfounded; and Texas, adjudicated, reason to believe, unfounded, and moved. The organization must decide whether to handle the case information differently based on the report disposition. The trend is to retain name-specific information on founded cases, and in some cases, on at-risk groups for 6 months to a year, and to keep basic statistical information forthe unsubstantiated group. This direction is regarded as reducing the confidentiality risks. The program manager needs to define carefully the dispositions and the criteria to be used to insure correct reporting and the proper handling of client information. Definitions of child abuse and neglect are subject to problems of vagueness that can raise the possibility of uneven interpretation and application of policy. The policy must be specific enough to promote consistency in the determination of abuse and neglect. Another programmatic issue related to dispositions is a growing professional concern about the extensive use of legalistic 102 dispositions and the value for greater consideration of the social work judgment pertaining to the family’s need for protective services. In this case, regardless of the disposition on the investigation report, families in need of service would be identified on the system. Purge Policy Purge policy requires decisions on the retention of information on both the automated system and the manual records. The policy has particular importance for the protective services system because of the name-identifying information. The key to determining the retention of names is the information’s value for the protection of the child and serving the family, considered in balance with the family’s right to privacy. Statistical information may be kept longer. Keeping names in the system has already been discussed in part for different case disposi- tions. Some additional questions are: How long should the name-identifying information be kept for each type of case? Is 5 years after the last founded/indicated report sufficient? Should the retention on founded cases vary by type of child maltreatment? Should a founded record of sexual abuse be kept longer than others? The decision should be based on needs related to providing protective services and definitely not on the basis of any nebulous plan for evalua- tion and research. Organizations must weigh the choices, unless the legislature has made the decision. They can draw on the experiences of others, as some existing systems move into 5 or more years of operation. It is possible to start with a policy allowing longer retention, and as the need turns out to be less than anticipated, the system can be revised to allow an earlier purge. Data Collection The planning and enhancement of a child protective services information system require decisions on data collection. Generally, protective service systems cover six major areas of information: number of reports, source of report, alleged perpetrator, nature of the child maltreatment, characteristics of the involved family, and outcomes of protective services investigation. This information provides the number of families and children involved in official reports of abuse and neglect, their characteristics now, and how the children were maltreated. The information also reveals the groups reporting child maltreatment—the com- munity, different professional groups, or even self-referral, and describes what is done by protective services intervention. The difficulty in deciding on which of these data elements to report and the forms on which to collect them can be considerably lessened by drawing on the experiences of existing systems and American Humane Association's work with the National Study on Child Abuse and Neglect (American Humane Association, 1979 and 1981). The National Study, in consultation with States, developed a minimal data set that could best describe the reporting of child abuse and neglect with the greatest comparability and reliabil- ity across States. Data elements were examined, assessing their problems with definitions, varied levels of specificity, and susceptibility to errors. The end result has provided a framework for organizations to determine their systems’ data elements and definitions. Below is a listing of the major elements: Case and Family Descriptors e Date of initial report e Date case status determined ® Location ® Number of children in home ® Source of initial report e Case status 103 ® Services provided or arranged e Type of report e Family public assistance status ® Family stress factors Responsible Caretaker and Perpetrator Descriptors Responsible caretaker’'s age Responsible caretaker’s sex Responsible caretaker’s race Responsible caretaker’'s employment status Perpetrator’'s age Perpetrator’s sex Perpetrator’s race Child Descriptors e Child's age ® Child's sex e Child's race ® Child's relationship to responsible caretaker ® Child's relationship to perpetrator ® Type of maltreatment Unless another social service information system can both provide service information and link it to the specific family needing treatment for abuse or neglect problems, service data should be included in the protective services system. However, difficulties exist in collecting and updating this information and are discussed later. Following the decision on data elements, it is necessary to define the values for each. The National Study can offer some ideas, but it is too sketchy to be sufficient for individual State reporting. Additional decisions are needed on the number of multiple values allowed for an element, such as types of maltreatment and the historical record of the data. History relates to the handling of older information when newer data is entered. The system could eliminate it or allow the recording of multiple time periods and the building of history. The simplest method for reporting data on the family and the child is to structure the investigation form to represent the family and allow identification of each involved child. Instead of four forms to represent a family with four children, one suffices. The purpose of knowing both the number of families and the number of children involved is to be able to assess the extent of the child maltreatment problem. If child-oriented records are used, a method should be devised to determine which children live in the same family. The timing of the data collection effort can be problematic—i.e., when to begin and when to end reporting. Tracking and monitoring functions demand reporting from the onset of the investigation, while other functions can have after-the-fact reporting. For the former func- tions, it is critical to have reporting for each step of the investigation process. At the conclu- sion of the investigation, the issue is when to stop updating. At a minimum, updating should occur through the conclusion of legal action, although this is done poorly in some existing systems because of the time lag between the investigation completion and final legal action. The basic data on the family may be updated, which would make the case information more current for tracking, or the data may remain fixed after the investigation, providing an accurate description of the family for that period. Recording ongoing service data could encourage more regular updating and reporting; however, this data may only be unreliably reported after the investigation. 104 Linkages The operating child protective services systems are all separate systems, but they have linkages planned or in place in varying degrees. The need for linkages comes in part from the child protective services design. For the most part, it is a time-limited system centered on the abuse and neglect investigation and does not include all related client populations (preven- tion or foster care) or support all service activities (service reporting, planning, or payments). Therefore, child protective services must link with other related systems to obtain this informa- tion and have a complete picture of the protective services program. Frequently needed linkages are with client registration systems (general services or foster care) and the tracking of services and costs. In Texas, workers may check a box on the investigation form to automatically register the client in need of services with the social service system. The service system handles the planning and payment for services. In Virginia, the protective service system tracks reports of abuse and neglect while the social service system will eventually handle all phases of service delivery, including payments. The common links, the case number and name, allow the tracking of protective services children to foster care and back home or to adoption. A similar linkage is planned in New Hampshire. This tracking allows long-term assessment of the protective services program’s impact. Utilizing the System’s Information The protective service system provides considerable information on the status of abuse and neglect reporting, nature of maltreatment, family and caretaker characteristics, and outcomes from the investigation. This section addresses each area. Status of Child Abuse and Neglect Reporting The automated system can provide an overview of the extent of reported abuse and neglect for the State, region, or locality and the trends in reporting overtime. An overall profile of reporting emerges from the following information: eo Number of reports, by years. The percentage of change between years and between the first * and last. eo Summary of case status, all reports with the number and percent of substantiated abuse, substantiated neglect, substantiated abuse and neglect, at risk, and unsubstantiated. eo Number of reports, substantiated and unsubstantiated, by years. ® Reporting rate (number of reports per 1,000 population) by years. Showing how the regions or localities compare to the State as a whole may identify areas requiring further study, such as underreporting or reporting a higher percentage of founded or unfounded than the norm. Where agencies have not reported data at a rate within the normal range for the State or region, study may be necessary to examine the characteristics of the agencies and the possible explanatory factors. It may be that areas with lower reporting rates are dealing with more serious problems. Agency characteristics to be studied could include worker caseload, services available, location, existence of multidisciplinary teams, and other components of the protective services program. Further comparisons among localities may be made by ranking the localities within the State on population, total number of complaints, total number of founded, and their percen- tages. Another aspect of the scope of reported abuse and neglect is the recidivism rate— the extent to which children and families are reported more than once. The rate is derived from the number of prior reports and its percentage of the total reports. Recidivism could be an indicator of previous inadequate investigations or legal action and treatment programs. It would therefore be useful to compare its occurrence across the State. 105 The source of reporting suspected incidences of child abuse and neglect to the child protective services program is critical for knowing the public and professional awareness of the problem, and for judging the required compliance with the law by reporters and their understanding of abuse and neglect. Basic information is the source of the report, number of reports, the percentage that represents of all reports, the percent of founded and unfounded reports of the total, and the founded rate (percent of the source’s substantiated reports based on his total reports). These data can show whether professionals, who are likely to be the first to see the problem, are reporting. It is important to know the extent to which each group's reports are substan- tiated for determining whether professional sources have higher substantiated rates than other sources, as would be expected, and what professional groups might need training to detect accurately signs of maltreatment. The relationship of the perpetrator of abuse and neglect to the child victim is a significant factor. To what extent were institutions and foster parents involved, revealing a major devia- tion from their role as service providers? To what extent was the parent-child relationship involved, indicating abuse and neglect as a family problem? A better understanding of the problem requires study of the characteristics of those reported to have been involved in child maltreatment. To uncover the potential scope of the problem with service providers, it would be useful to have and to monitor a count of reported foster homes and institutions by region and locality, identifying whether reports were substantiated. The Nature of Maltreatment The system can also provide a picture of the child victims (distribution of males and females by age group, abuse/neglect by sex), identifying particularly vulnerable groups, and the type of abuse and neglect that most frequently occurs. Information can also indicate an association between special characteristics of children and their likelihood of being maltreated. Since sexual abuse is an area of special concern, it may be useful to identify separately the proportion of children who were sexually abused, according to substantiated reports. The ability to define the nature of the abuse will depend on whether the reporting system requires specifying the particular form of sexual abuse (rape, molestation, deviant acts, incest). Severity would be useful to show for identifying some areas as more serious problems than others. However, it is difficult to measure and report in most cases. The system can also provide a picture of the child victims (distribution of males and females by age group, abuse/neglect by sex), identifying particularly vulnerable groups, and the type of abuse and neglect that most frequently occurs. Information can also indicate an association between special characteristics of children and their likelihood of being maltreated. Family/Caseworker Characteristics The caretaker is most often the source of the problem and also the point needing help to create a protective living situation for the child. The dynamics of the family are critical to understanding and eventually preventing incidents of abuse and neglect. Situational factors concern the parental composition of households, the number of children in the household, family income, and occupation. The information should address such questions as to what extent two parental figures are in the household, whether lack of income is associated with maltreatment, and how these factors relate to the type of maltreatment. Stress factors are part of situational factors. Stress factors include chronic family conflict, inadequate housing, physical disability, substance abuse, mental retardation, and other areas. Two basic questions are, What are the most frequently identified stress factors? and Are different profiles of stress factors evident for abusers and neglecters? The results of the findings may help in targeting prevention and remedial programs. 106 Outcomes of the Investigation The theory behind child abuse and neglect reporting legislation is to identify abused and neglected children and to deliver appropriate services to the troubled family. The system should provide the child protective service program’s response to the child maltreatment. This includes the findings of the investigation, removal of the child from the home, placement of the child into foster care, legal action, opening the case to ongoing protective services, and the planned/delivered services. Tracking of outcomes in relation to services delivered through the child protective services system or linked social service system can be valuable for planning and targeting services. Service data can be used to inform other agencies of the need for certain services believed critical to child protective service clients, to develop joint programs with other agencies, to know service availability and gaps across localities, to determine which services should be targeted for development because they appear to be effective elsewhere, and to justify requests for adding, expanding, or reducing particular services. Summary The chapter has highlighted the many purposes and functions of the child protective services system and the key decisions to be made in planning the system. The system can offer many payoffs to all levels in the organization: operational support for the central registry staff; tracking, reminders, and caseload reports for service workers; and information for monitoring the investigatory process and supporting management. The organization’s improved program planning, public awareness campaigns, and other activities in turn bring additional, indirect benefits to the service workers. The system's primary drawback is its time-limited nature and its focus on the investigatory process. It neither includes families receiving preventive services prior to the investigation nor tracks the family and child moving into other child welfare programs such as foster care. The reporting of services, their outcome, and their cost are also usually inadequately reflected if covered at all. Effective linkages with foster care and social service information systems can overcome these deficits and enhance the child protective service system’s value for both service staff and management. The next two chapters on service systems discuss this further. 107 AER. ae ‘ IX. Systems for Foster Care and Adoptions National studies have estimated that 500,000 children are living away from their families in some type of foster care—foster family homes, group homes, or institutions. These studies have further shown that while foster care was intended as a temporary condition, it has become a long-term and sometimes forgotten arrangement for many children who have been removed from their parents or family. Many children who are coming into the system at a very young age are spending most of their early lives in foster care. They remain adrift in care for long periods of time without a goal and a plan for services to move them toward a permanent living arrangement. The insecurities accompanying separation from family and the frequent moves from one placement to another adversely affect the normal personality development and emotional growth of children in custody. Public social service organizations have been severely criticized for losing track of foster care children who have been entrusted to their care. Largely, they lack basic information about the children in care and have neglected to establish and enforce policies that encourage the finding of permanent alternatives to foster care. Overburdened staff and limited resources have exacerbated the problem. As the Nation gained a heightened awareness of these facts, service organizations moved toward correcting these conditions. The middle and late 1970's brought the introduction of permanency planning—goal-oriented service delivery—for moving children out of foster care. The emphasis was on establishing permanency in the child's living arrangements through returning him to the natural parents, placing him an an adoptive home, or establishing formal agreements for other living situations. Some States received legislative mandates for a foster care tracking system or a child welfare management information system. Reinforcing this approach, the Adoption Assistance and Child Welfare Act of 1980 (Public Law 96-272) recognized the need to make improvements in child welfare for strengthening the foster care program and encouraging adoptions of children with special needs. It also established new reporting requirements. The Federal Government is using these to place mandates on States for building or enhancing child welfare management information systems. Information systems became recognized as critical for supporting, tracking, and reporting a child’s progress toward permanency. Foster care and adoption systems are currently in various stages of development in States across the country, with different levels of scope. The systems can have some or all of the following objectives: ® to determine the number of children being served and their characteristics, ® to determine the movement of children entering and leaving the system, and recidivism, e to track the movement of children within the social service system from primary prevention to reunification with the family, adoption, or emancipation, ® to aid in achieving permanent plans for each child in the system, ® to reduce inappropriate institutionalization and support the least restrictive placement for the child, ® to identify the families of the children, their characteristics, and involvement with the child and the system, ® to identify placement opportunities through an adoption exchange, foster home, and other resource listings, 109 ® to handle the funding and payments for maintenance and care, subsidized adoption, and social services, to support the process for interstate and intercountry movement of children, to support the process for granting adoptions, to maintain a central file on petitioned adoptions, to have accountability for services provided to children and families, and to support management in policymaking, budget planning, program planning, staffing, evaluation, and other functions. Foster Care Functions Supported by Systems The information systems can promote reforms in the foster care program supporting both the permanency planning efforts for foster care children and effective administration. The system can aid many functions of the program as follows: ® Tracking the foster care child from entry to exit, Reducing inappropriate institutional placements of children, Tracking planned and delivered services and the associated costs, Supporting the approval, development, and appropriate use of foster homes, Maintaining an inventory of other resources and supporting their appropriate use, Handling payments for foster care maintenance and social services, and ® Supporting the monitoring and evaluation of the foster care program. Systems for foster care may cover several or all of these functions. Each function is discussed below. Tracking the Foster Care Child The tracking of the foster care child is significantly enhanced by an information system. The system can follow the child from entry into and exit from foster care and identify recidivism. Critical information is available on the child, such as: Characteristics—age, sex, race, handicaps, and legal status, Length of time in care and placement, Parental visiting, and Permanency planning goal and achievement status. The tracking system can call the service worker's attention to actions due and overdue that would otherwise allow the continuation of the “drifting’’ problem. In addition, the system can monitor the status of permanency planning for individual children and the total foster care population. The organization should establish policy defining permanency planning goals and their hierarchy of importance and requiring service workers to select the highest ranking goal feasible for the child. The system can require the reporting of the goal and progress on achievement. Typical goals in order of importance are return to the home, adoption, indepen- dent living/emancipation, planned foster care with written agreements, and continuous foster care. Systems identifying families served before the children come into care may also have a goal —to maintain the family unit—that would have the highest priority. The system should also contain several factors that research has identified as related to permanency outcomes. These factors are length of time in care, parental visiting, and the number of moves while in care. 110 A relationship exists between length of time in care and case outcome (Fanshel and Shinn, 1978). The longer a child stays in foster care, the less likely he is to return to the natural parents or be adopted. The probability of movement out of foster care is greatest during a child's first year in care and is substantially reduced after 3 years in placement. The system can help improve a child's chances for achieving a permanent family situation by tracking the average length of stay in substitute care and calling attention to cases where intervention may be needed. The intensity of worker/parent contact has a significant relationship with movement out of foster care. By providing services to natural parents, an assessment can be made whether the parent can resume care for the child or alternative plans must be made for the permanent care of the child. A strong relationship also exists between parental visiting and foster care discharge, even when children were in care up to 5 years (Fanshel and Shinn, 1978). The foster care program has frequently neglected the parents. The system can help overcome this practice through tracking the natural parents, the worker/parent contact, and child/parent visits. The number of times a child moves from one living situation to another is also a critical factor. The information system should monitor the number of placements and flag providers having frequent turnover of children. This can allow more careful planning of care and identification of potential problems with foster homes and other resources. Reports from the system can give monitoring data useful to all levels of the organization. For example, service workers could benefit from data on the number of planned versus kept parental visits and a child’s frequent placement changes. Supervisors can also use this information to identify problem areas requiring corrective action. In summary, the tracking of permanency planning allows the organization’s establishment and achievement of time-limited and measurable program goals. These goals may concern increasing the number and timeliness of children returning home, reducing the number of children in inappropriate institutional care, reducing the average length of stay in foster care, reducing the average number of different placements per child, increasing parental visiting with children in care, and increasing the number of written case plans. Goals focused on adoption are discussed in the adoption section. Tracking should reduce the number of children who are “lost” or adrift in the foster care program and increasingly improve the accomplishment of permanency outcomes. Institutional Placement Residential or institutional placements offer care and treatment to those children whose social and emotional problems interfere with normal functioning and make it impossible for them to remain in a family or in the community, or to respond to treatment while living there. The children’s level of development, social and emotional problems, or relationships to their own parents are such that they are more likely to benefit by the experience of living in a group rather than in a family. The possibility for placement in the foster home or specialized foster home should have been eliminated before institutionalization is considered. Institutional placements require special attention for several reasons. They have been excessively used. Difficult and sometimes poor matching takes place between the child with special problems and the institution. Lastly, resources are not available for many special needs. Foster care programs have traditionally made excessive and often inappropriate use of institutions for the placement of foster care children. However, the information system can promote permanency planning’s aim of providing the child with the least restrictive setting possible. From the data, program management can study the characteristics of children, an agency's rate of institutionalization, and location of the facility, and make some preliminary judgments about the appropriate use of institutional facilities and take further action. 111 For organizations requiring approval of out-of-State and/or in-State placement of children into residential facilities, the system can identify all children with such living arrangements and allow identification of any placements without approval. Corrective action can turn around this situation quickly. For children needing residential care, matching the strengths of the child with the strengths of the facility is critical to giving the child the living situation that enables him to achieve maximum development within his capacity to change. The system can provide the service staff with listings of available resources, showing the type of children served and the treatment program available. It may even offer a preliminary child-resource match. The third system use for institutional placements is the redirection and development of facilities in keeping with the needs of children that cannot be addressed in foster homes. The program manager can provide facilities and groups with information on the children’s charac- teristics and handicaps that can guide new program planning and improved accommodation of the foster children. This utilization may make possible the return of children from out-of- State to in-State facilities. Services and Costs Permanency planning’s implications for the delivery of services is clear. The service worker must provide and purchase services as early as possible during the child's placement to enhance the achievement of his permanency goals. In most instances, the services should be for both the child and the family. The information system can monitor the existence of a plan for services and their timely provision to move the child and family toward the goal. This should reduce the possibility of children remaining adrift in care. The system can also remind the worker of the plan’s expiration and the need for developing a new one. Costs for services may be determined through payments for purchased services and direct activity reporting of the service worker. The next chapter discusses service planning, reporting, and costing in the sections on service delivery and financial management. Approval and Use of Foster Homes The most important and frequently used living arrangement for foster care children is the versatile foster home, caring for children from birth through adolescence. The information system can support the recruitment, approval, training, use, and evaluation of the foster homes (see the resource section in the next chapter). The system'’s basic information on the number of foster families, their characteristics, and preferences for children can indicate the need to recruit additional or different families. For example, recruitment of black families may be necessary where many foster care children are black and approved homes are predominantly white. Tracking the application and approval process of homes insures their timely availability for the placement of children. Where inordi- nate delays are evident, intervention can correct the situation. The system may also indicate special skills and training in the foster home that could indicate an ability to accommodate children with special needs. The selection and use of the home can be facilitated through the listing of homes and/or automated preliminary matching of the child and the foster family. The system can also prevent the use of a home beyond approved capacity by rejecting the placement plan, leading the service worker to choose another home. Evaluation of the home may be assessed by such factors as the length of time children remain in the home and unplanned removals of children from the home in relation to the types of children served. The organization should find the information valuable for an overall assessment of its performance in attracting, using, and retaining foster families in the program that match the needs of the children in care. 112 Resource Inventory and Its Use Approved foster families are only one resource used by the foster care program. Others are used for providing residential care and social services. The resource inventory, as described in the next chapter, includes all types of resources in service delivery. The system presents resource options for service needs, and the service worker must select the best for the child and family. Payments for Foster Care Children The system may also handle all funding sources for foster care and make the payments not only for social services but also for maintenance and care. Information is then available on the costs of services, different types of care, and average costs by permanency planning goal. Management can use this in budgeting, other financial planning, and policy development. The financial management section of the next chapter presents an approach for handling the finances and payments. Monitoring and Evaluation The system supports the monitoring and evaluation of the permanency planning outcomes in several ways. Reports can identify the need for local reviews of cases. Program manage- ment can have the system produce a sample of cases for a State case review process. Unusual information in the system may also indicate the need for a special study to understand why, for example, half of the children in whose cases parental rights were terminated do not have the goal of adoption. The results of such a study can lead to refinement of policy and reinforce- ment of permanency planning. The next section looks at the support of information systems for the adoption program, discussing further automated support for the adoption of the foster care child as well as other dimensions of the program. Adoption Functions Supported by Systems The adoption program has many functions related to supporting and granting adoptions that serve not only the foster care child available or placed for adoption but also the general community. Information systems can support the organizations’ adoption functions in many ways as follows: Tracking the adoption of foster care children, Approving potential adoptive homes, Maintaining an exchange of available children and adoptive homes, Providing subsidized adoption payments for the special needs of children, Monitoring assistance to courts in the granting of adoptions, Supporting the maintenance of central files on all petitioned adoptions, and Aiding in the provision of information to adult adoptees. The scope of automated adoption efforts relates to their adoption responsibilities and to the volume of activity. Each area for automated support is discussed to bring out the options available in planning service systems. 113 Tracking the Foster Care Child’s Adoption Adoption helps foster care children who have become permanently and legally separated from their natural parents become permanent members of a new family. It involves a complex combination of social and legal processes. The information system can monitor the following steps in the progress of a child to be adopted: ® Selecting adoption as the permanent planning goal for the child, Freeing the child for adoption through termination of parental rights, Placing the child in the adoptive home, Providing services before, at the time of, and after placement, and Finalizing the adoption and terminating the agency's custody of the child. The system can reveal how many children for whom the goal has been adoption have actually been adopted and the average length of time to complete the process. It can also help to identify where the slowdowns occur and what intervention may be necessary. Information should also be available on children in whose cases parental rights are terminated but who do not have the goal of adoption. The agency or service worker may be inappropriately reluctant to consider adoption and may need encouragement to reexamine the child’s goal. Establishing and monitoring measurable goals become possible in adoption. An example is one of Michigan's goals: “To place or facilitate placement into adoption 75% of the children who were planned for adoption within one year of establishing that plan.” (Michigan Depart- ment of Social Services, 1980, p.18) Other goals could focus on placing the older child, keeping siblings together, and placing the special needs child. Full utilization of tracking information can significantly improve the effort of placing foster care children into adoptive homes. Summary reports can give agencies a picture of the effectiveness of a locality’s adoption program in contributing to the timely movement of the children’s planned adoption and to achieving goals. The reports should also show the number of adoptions actually finalized and those disrupted, providing characteristics of children involved. Approval of Adoptive Homes Available and approved adoptive homes are prerequisite for placing children and realizing the goal of adoption. Adoptive homes become available through families and single adults applying to adopt one or more children. Their application to be adoptive parents may be completely on their own initiative or in response to a public awareness and recruitment campaign. The information system may support the establishment of a bank of approved adoptive homes through monitoring the completion of all approval steps and identifying all approved adoptive homes and their preferences for adoption. (Adoptive homes would be an agency- approved provider, discussed as part of the provider subsystem in the next chapter.) The system could help identify delays in processing adoptive applicants. Matching available children and adoptive homes could also be supported, facilitating the placement of children. An Exchange on Available Children and Homes An adoption information exchange increases opportunities for children to be adopted by providing information and referral services to agencies having custody of these children. The exchange maintains a registry of families studied and approved for adoption and a registry of children legally free for adoption. In addition, it performs various activities to assistagenciesin finding adoptive families for waiting children. 114 The information system makes it possible for the exchange to monitor the required registra- tion of children for whom all parental rights have been terminated. For example, it will review whether the goal is adoption, parental rights have been terminated, and an adoptive place- ment has occurred within 90 days. The monitoring insures the visibility of all available children and the maximum opportunity to be selected for adoption. The system can also monitor the registration of studied and approved families interested in children. Depending on the organization's needs, monitoring may be limited to homes willing to take children with special needs. It can insure the required registration within the required time frame (for example, 30 days after date of approval of a home unless a local placement is pending). Subsidized Adoption Subsidized adoption facilitates the adoption of children with special needs. For these children, the most appropriate adoptive parents may be people who do not have enough money to provide for their needs. Subsidized adoption assists people with the cost of raising a child who has special needs. The primary basis for assisting the adoptive family is the special needs of the child, not the needs of the family. Children who are likely candidates for subsidy are hard to place because of their age; physical, mental, or emotional handicap; minority or racial heritage; or being a member of a sibling group. The information system can track the payments for adoptive parents approved to receive a subsidy for the child, differentiate between the types of subsidies, and make the necessary payment. The information on costs can be used to show how public funds are being saved whenever a child achieves adoption with subsidy compared to the cost of retaining the average child in foster care. Assistance in Granting Adoptions The organization may have functions related to the granting of adoptions: assisting courts in granting legally sound adoptions within a specified time period, monitoring and evaluating adoption cases and submitting reports to courts, arranging for investigation and supervisory visits when an out-of-State/country agency is involved, and making an investigation and recommendation on the adoption according to required procedures. This work concerns the adoption of foster care children, adoptions handled by child placing agencies, and indepen- dent adoptions. The information system can track all adoption cases and monitor the timely completion of all work for the court and the key legal events. Actions due and overdue can be produced on a list. For example, the system could confirm that the investigation has been completed, but the court has not acted. Informing the court of the need for the final order can prevent children remaining in alegal limbo or with a family not recommended as an adoptive home. The system can also indicate whether the adoptive parents or adoptee were involved in a previous adoption. For organizations with a high volume of adoptions, the system can significantly reduce the professional and clerical paperwork and streamline the total operation of supporting the finalization of adoptions. Central File on Petitioned Adoptions The organization may have responsibility for establishing a permanent record of all adop- tions petitioned. The same name information used to assist in granting adoptions serves as the central file's entry point that confirms the existence and indicates the location of the confiden- tial adoption case record. With records going back to 1942, Virginia's central file has an index with more than 250,000 names. 115 Aid to Adult Adoptees The growing number of adult adoptees searching for the identity of their birth parents and the advocacy of their position are leading States to consider the establishment of a central file on adoptions. This would prevent the adoptee from having to make an extensive search by geographic location of the adoption records, contacting numerous jurisdictions and courts. The central files, supported by an information system, could be an expeditious resource for acknowledging the existence and placement of the file and then, upon receipt of proper approvals, retrieving the adoption case record. Information systems can obviously provide varied and far-reaching support to the adoptions program that merits careful consideration in planning a service system. The next section looks at automated support for another part of the adoption and foster care programs—the in- terstate and intercountry transfer of children. System Support for Interstate Transfer of Children Interstate and intercountry transfers of children may take place for adoptions and foster care. Procedures governing the interstate placement of children are intended to safeguard the well-being of children while assuring communication between agencies involved in such placements. Members of the Interstate Compact on the Placement of Children are responsible for approving all interstate placements of children. For intercountry placements, the Immigra- tion and Nationality Act requires compliance with a State's respective preadoptive law and regulations before a foreign child can be brought to the United States for the purpose of adoption. For State organizations with a high volume of interstate or intercountry transfers such as Virginia, California, and New York, an automated information system can provide invaluable support for timely and streamlined processing of requests for transfers and related corres- pondence. Substantial clerical labor can be saved through automatic production of the nationally used form “Request to Place a Child.” (ICPC 100 A and B) and more important, the needs of children can be addressed more responsively. The next section focuses on the system design choices for foster care, adoptions, and interstate/intercountry transfer of children. System Design Choices Today's foster care and adoption systems focus on the tracking of foster care children and their permanency planning status. Beyond the common thrust, many choices exist on what the system should do and how it should be structured. Management must decide on the most suitable design strategy for the organization’s needs and capabilities. Several approaches are discussed. In addition, a special system design for the interstate movement of children and unique adoption requirements is presented. The last section examines potential linkages between foster care and adoption systems and other systems. Two Comprehensive Approaches: Foster Care and Adoptions as a Subset One choice is that the development of a foster care and adoption system may be a subset of a more comprehensive social service information system such as discussed in the next chapter. Another approach is the foster care/adoption system as part of a child welfare management information system, which may be comparable to the social service information system, except for its narrower focus on child welfare rather than all the service populations. The foster care/adoption system as a subset of a larger social service system is a popular direction for States with designed and operating service systems, as reflected by systems in Michigan, New Hampshire, New York, Virginia, Utah, and Texas. Preference for this system 116 configuration may derive from its consistency with the organizations’ responsibilities in social services and its making available more design features to support and manage the foster care and adoption programs. The design features may include tracking funds and their sources, handling payments, providing a resource inventory (foster homes, adoptive homes, child caring institutions, and others), tracking the service delivery process, and reporting costs and activities. Both child welfare and social service management information systems may allow tracking the child and family as they move in and out of or progressively through various service programs, such as prevention, child protective services, foster care, and adoption. Com- prehensive systems may also more readily lend themselves to linking together the family and children rather than just tracking the children, thereby giving greater support to family services. An Elementary Foster Care Tracking System A third strategy is a ‘bare bones’ foster care tracking system that involves the collection of only the most important data related to the child's demographic characteristics, legal position, and permanency planning status. It may lack information on natural parents, foster parents and other resources, services, and costs. For organizations without a comprehensive service system in place or planned, this may be the quickest and least expensive approach. Virginia's experience with an interim foster care system of limited scope has demonstrated this approach is feasible. Its system has a sole input document, which contains approximately 50 data elements providing basic information on the child and minimal information on placements, service planning, and family visits. It is completed on each child at the point he comes into custody and updated for changes and visits every quarter. Although the system is elementary, the manipulation of the key elements has maximized the value of the information and produced reports heavily used by executives, program managers, local agency directors, and service staff. Centralized Adoption and Interstate Functions: A System for Operations Organizations with centralized responsibilities and a high volume activity in the areas of adoption and interstate transfer may wish to consider the feasibility of an information system focused on basic support for operations, with extensive monitoring of required activities and some management reporting. The interstate transfer can benefit from automation. Certain adoption functions that also may be centralized and lend themselves to automation are an adoption information exchange, monitoring of assistance to courts in the granting of adoptions, maintenance of an adoption file, and tracking of subsidized adoption. Each of these functions requires its own card files for names and numbers; the greater the volume the more difficult the filing and referencing. Additional files may be created to monitor local agencies for their required activities, the courts, the central offices, and other States. The overall effect is an overwhelming amount of paper burning out clerical and professional staff and usually flowing late. An automated system can eliminate all this through a rapid online search capability of all child and adult names, and online entry of key actions. It minimizes the time spent in filing and referencing them, eliminates filing errors, and provides an easy and quick method for updat- ing information and adding new cases. As a secondary function the system can produce monitoring reports reminding agencies of reports due and reminding courts of legal action due. 117 Virginia found this the only feasible course as a method of escape from over 250,000 cards on adoptions referenced constantly and for timely management of countless pieces of mail coming daily on interstate transfer and adoptions. The system has transformed an impossible drudgery for clerical and professional staff into a reasonable, always current, and even pleasant workload. Linkages The planning of systems for foster care and adoptions requires consideration of many potential linkages. Two of these linkages have already been discussed—the social service information system and the child welfare management information system. Other areas are child protective services, juvenile justice, income maintenance, resource or vendor listings, and fiscal systems. From the perspective of the administrator and program manager, highly desirable system linkages are those permitting the tracking of the child and family through a continuum of service programs. The continuum includes family preventive services, child protective ser- vices, foster care, and adoption. Tracking allows the organization to learn about long-term outcomes from service intervention. It helps answer such questions as, Do preventive services reduce initial or subsequent child maltreatment complaints or removal of the child from the home? How many foster care children returning home experience abuse and neglect? How many children are in foster care as result of reported abuse and neglect? How many adoptees entered the system through child maltreatment? and How many adoptions were disrupted and the child returned to foster care? Upon receiving the initial counts of these occurrences, the administrator will undoubtedly request an analysis of factors associated with these events. The design of the foster care and adoption systems should anticipate these information needs and establish these valuable linkages in a manner consistent with confidentiality require- ments. An equally important linkage is with the juvenile justice sector because of movement, potentially considerable but largely unknown, between its system and foster care. Without a method of sharing information among different programs and sectors, a complete picture of the family and children and the needed services cannot be clear. Furthermore, service delivery across sectors may be conflicting rather than compatible and reinforcing. The income maintenance programs have two connections, one related specifically to foster care and the other generally to child welfare and social service systems. The first is the obvious linkage with the income maintenance program Aid to Dependent Children-Foster Care. This covers the maintenance and care expenses of eligible foster care children, which in some States is as much as 80 percent of all foster care children. Sharing of information and a common approach on handling payments should be more efficient, and merging of information and processes should provide management with an improved data base for analysis and planning. A secondary linkage involves identifying common populations among income maintenance and social service programs that may help identify income-related causes of social problems or pinpoint biases in the population served. The last set of linkages, vendor listings and fiscal systems, are possible systems in existence that could be connected to the foster care and adoption system and offer useful information for management and staff. The design team should be alert to all potential linkages and, as appropriate and feasible, incorporate them into the system plan. 118 Summary The chapter has highlighted the purposes and functions of systems for foster care and adoption and shown how they can enhance the management of the foster care program at all levels—service workers, supervisors, program managers, and administrators. The systems enable the organization to support and direct foster care and adoption activities and de- cisionmaking in away that leads to improved permanency results for the children and families. Some choices in designing systems for foster care and adoption were also discussed, including the potential linkages among social service systems and others. The social service information system may be either the core system or a critical linkage. The potential relation- ship between this system and foster care and adoption systems will become clearer in the next chapter. Chapter 10 describes a comprehensive social service information system and its many design options. 119 Ey Na TN 3h ota 4 AAA CA y “+ A ace gain chp EER Abn aa gd X. A Comprehensive Social Service System The development of a comprehensive social service information system offers an approach for bringing together the information requirements of many different social service programs, serving the needs of many organizational levels and linking the system with other major human service programs. The system’s benefits lie in a more efficient and effective service delivery system and in more knowledgeable management decisionmaking in budgeting, planning, policy redirection or change, resource allocation, and other administrative con- cerns. Management can also accommodate the ever-increasing demands for accountability for all services delivered and funds expended. On the other side, service workers can receive support for performing service delivery functions and making related decisions. This comprehensive system must be developed to accommodate different State and local organizational structures and agency relationships. Differences affecting the system are the organizations’ varied scope of responsibilities in human services, State-administered versus locally administered social service programs, size of agency, service delivery mode, methods for handling purchased services, and the role of the voluntary sector. The organization’s scope varies along a continuum including single-focused (children’s services), multiple (all social services and income maintenance programs), and comprehen- sive (all human service programs) responsibilities. The programs included in the system and the integration efforts often correspond to this scope. Secondly, the level at which social services are administered—State or local—influences how easily the system can be de- veloped. It is much more difficult to develop the system in the locally administered environ- ment because of control issues, local needs, and the inevitable complexity of the system. Involvement is even more critical for developing support and a responsive, well-designed system. Complexity comes from the system’s incorporation of, for example, 50 or more budgets and configurations of allowable services. Size of agency is another consideration, especially in a State organization with local operations. The system must contain enough to meet the needs of the giant agencies but be sufficiently simple to avoid overwhelming very small agencies. The service system must also recognize the different ways of handling case management. Some clients may begin with the vendor and others with the host agency. Case management may be handled differently among agencies or even delegated to the voluntary sector. Lastly, purchased services may be contracted for, ordered, and tracked in many different ways. Nevertheless, the social service system does have a common structure that can be found in many different organizations. The chapter presents a conceptual description of a comprehensive service system, identify- ing the major components and optional design strategies as well as the potential uses and benefits of the components. Possible online inquiries and reports are identified. The conclu- sion focuses on the system’s payoffs for service workers and management. 121 A Conceptual Description A comprehensive social service system typically has four major subsystems: ® Case/client tracking, ® Service providers, e Service delivery, and ® Financial management. The case/client subsystem handles all case and client data, monitors eligibility status, and establishes a record for all persons requesting or receiving social services. The service provider subsystem maintains information on all vendors and other resources used in the delivery of services and monitors required approval processes and rate schedules. The service delivery subsystem supports and monitors the delivery process for both direct and purchased services. The fourth subsystem, financial management, handles all financial aspects of the system. Figure 8 provides a conceptual representation of the system. On the service delivery side is the service worker's registration of clients, collection of special program information, and planning and delivery of direct and purchased services. [Note: Figures 8to 14 were part of the Virginia Department of Welfare social service information system project.] The administrative side gives support to the service worker through the identification of available service provid- ers, checking the validity of the plan, handling funds and making payments for services delivered. The presence of terminals recognizes that a great deal of interaction takes place between the service worker and the information system in the delivery of social services. A comprehensive SSIS preferably accommodates mixed client populations, variation in services provided, different eligibility requirements, and multiple funding sources, and allows for frequent changes in these areas. The system should also address the desire on the part of all management levels and service delivery staff to know more about their clients and to make better decisions regarding services delivered to the clients and policy governing the service delivery process. Both operating and planned social service systems fall within this model or are changing in this direction. Within this framework there are variations in agency preferences and charac- teristics, the scope of the system and its level of operational detail, use of online capability, and the extent of integration among the subsystems. Child protective services, foster care, and adoption systems may be linked to or part of the total system, depending on the organization's interests and concerns. Linkages with other systems such as income maintenance may also vary. The older operating systems often had the subsystems developed as separate systems at different times; various linkages were established later. The newer systems tend to bring everything together and develop the system with tighter integration of functions. In addition, they are often planned as online systems. The following sections discuss each of the four subsystems, identifying options and deci- sion areas. The potential benefits listed for each subsystem relate to the needs and design choices of the organization. The document discusses the value of online capability for social service systems and presents potential online inquiries and reports. 122 Figure 8 Social Service Information System Model SERVICE DELIVERY ADMINISTRATIVE SUPPORT Case e Social Services e POS Vendors e AFDC e Licensed Facilities Document o Food Stamps pers © Individual Providers sCliomts o Medicaid Eligibility Tio © Foster Care XX o Child Protection 4B Social Services | * Adoption Somprshionsive 4c nnual Service 4E Supplemental © Adult Protection Plan Document Service * Donor Safvica ’ Py eed pot af Funis Planning © Direct Contract Document ntracts Billing & Service Payments Terminal Terminal Data = I~ Data Inquiries == ssis = Inquiries Integrated Data Base Management Management and al Administrative Administrative Reporting Reporting 123 Case/Client Subsystem The case/client subsystem provides the framework for the social service system through the identification of the family (case) and the individual requesting and receiving social services. This is the entry point into the system and the beginning documentation of the service delivery process. The case/client subsystem handles all case and client data, monitors case and client eligibility, and establishes a record in the data base for all persons who apply for or receive services. Some potential benefits associated with the case/client subsystem may be: e Confidential name index for current and closed cases of clients across the major service programs that identifies if the family or individual received services previously. Unique case number and unique identifier for each client. Automatic determination of eligibility. Complete history of case and client eligibility. Uniform identification and demographic information for the family unit and individual clients, such as target group (aging, runaway, etc.) and special needs or handicaps. Accurate and timely caseload management and action due/overdue reports. Ability to obtain unduplicated family (case) and child counts. Ability to develop case and client profiles. Tracking a client through the service delivery process. Family or Individual Structure The case/client subsystem commonly focuses on the family as the primary unit and mem- bers as subordinate, requiring the same case number for all members plus a member identifi- cation number. Sometimes the computer may also assign an additional client identification number for the purposes of efficient access to client information and determination of duplication of the client across major systems. For some comprehensive social systems, the individual may serve as the case, with automated linkages among members of the family established through cross-reference numbers and/or a head of household file. The preferred approach depends on the service delivery structure, which may focus on the individual or the family. Advantages of the first method are fewer forms to record data on the family and individuals, a single service eligibility determination applicable in most cases to all members of the family, and easier access to the family information. Social Service or Departmentwide Focus Another major decision is whether the case/client subsystem should include all clients served by the organization or only those in social services. For services, another major decision is often whether and how to include child protective services and foster care cases. If the subsystem includes all agency clients, a common case/client form across major programs is essential as the same system entry for all. Figure 9 shows an organizationwide subsystem with one form, focused on the family, which is the means of bringing diverse areas together. This course is advantageous where the major programs share many clients because it reduces duplicative data entry and data processing efforts and promotes greater communication and coordination within an agency. However, its successful implementation, particularly in a State environment, requires substantial technical expertise and system development experience. 124 Figure 9 A Departmentwide Case/Client Subsystem Generic Case a Document <\ e Eligibility Category e Application Dates o Eligibility Periods AFDC e Common Information Medicaid © Program Unique Data NS Food 7 i < Social Stamps Services Client 1 Client 2 Client 3 Client 4 Client 5 Client 6 o Eligibility Information o Demographic Data ¢ Single Client Entry With a shared form, the organization must determine if all staff have equal rights to update common information on a case or individual or if a hierarchy exists on the type of worker who has the right to change the data. This hierarchy may correspond to the accuracy demands on the worker and the consequences for error. For example, if the client receives all programs, only the AFDC worker can change the common information, and the service worker can change common data only when the family is not participating in other agency programs. Careful consideration is required on the need for a hierarchy, its character, and whether service workers can update more than service data. Case Number The case number is among the most critical data elements in the system for several reasons. It is the unique identifier for a case/client that allows the tracking of all services delivered and establishment of proper audit trails for payment. The number may also link the client's past record of services with the present, provided that the organization checked for and assigned the old case number. Conscientious number assignment is absolutely essential to prevent duplicate numbers on the same case for both social services and the organization. Duplicate members can be the cause of much bad and frustrating data and, at times, fraud. The assignment process should include such screening steps as checking the name for “sound alikes’’ and address matchings. 125 The organization should also have tight rules on changing the case number. The value of the unique identifier is undermined in providing proper audit trails, tracking, etc., to the extent that staff have freedom in dropping one number and selecting another. Loose procedures also encourage careless assignment of the original number. Consideration should be given to allowing only a central point to make case number changes and only when the need has been fully documented and confirmed. A third issue on case numbering is the format of the case number. An initial thought of many system designers is to use the social security number, but this is risky. The social security number is not a unique label because, by the Social Security Administration's own estimates, more than 4.2 million people have two or more numbers. In some instances, more than one person is issued or uses the same number (Adams and Haden, 1976, p.265). Moreover, complications may arise because the number is for individuals, and while children can have a number, they usually do not and one cannot be quickly obtained. Alternatives to the social security number are preferable but are notimmediately evident. Careful study in the context of the system’s environment is the best method for deciding on the case number structure. System Flexibility for Social Service Programs Social services is a complex set of many varied social service programs, several with their own unique requirements that often lead to the development of separate, single-focused systems. A service information system must take these requirements into account to be comprehensive. One effective strategy is to have a second client form in the case/client subsystem that supplements the primary case/client document and collects the unique data on individuals who are being served by the special programs. This is sufficient for the unique requirements and allows the development of an integrated, generic social service system. When the form has capability for expansion, the system acquires greater flexibility to accom- modate changing service programs and new national service priorities. The major social service programs that require supplemental information are: foster care, subsidized adoption, adoption, both for foster care children and independent adoptions, child protective services, adult protective services, and work incentive programs. An information system provides a client tracking system for each of the service program areas and has the potential for creating a central registry for the adult and child protective services programs (see figure 3). Program policy standards may be incorporated to allow the information system to monitor as many policy matters as feasible. Some benefits associated with monitoring are the tracking of children in relation to goals, type and duration of place- ment, and recidivism. It is important to identify and track the natural parents of the foster care children as well, unless the parents are no longer alive or their parental rights have been terminated. System designers need to determine which method allows the most complete and accurate reporting. The method could be reporting parents on the child’s supplemental document or on the generic case/client document. 126 Figure 10 Social Service Programs: Unique Requirements Social Services Supplemental ~ ~ Document Adult Child Protective Protective Services e Program Monitoring Services & Evaluation \ eo Client Tracking / Foster Adoptions WIN Client 1 Client 2 Client 3 Client 4 Client 5 Client 6 Provider/Resource Subsystem The provider/resource subsystem maintains information on all resources used in the deliv- ery of services and monitors the required approval processes. The provider file may include purchase-of-service vendors, approved individual providers (adult and child foster homes, in-home and family day care providers, adoptive homes, etc.), licensed facilities, and other resources (see Figure 4). The information maintained on providers covers the type of client served, services offered, approval/contract dates, location, and service costs. Following are some potential benefits associated with the provider/resource subsystem: ® Resource inventory with information by service or geographic area. ® Provider profiles reflecting services offered, clients served, etc. 127 Automated matching of clients’ needs with providers offering the service. Tracking of potential adoptive homes registered with an adoption exchange. Payment allowed for approved services at negotiated rate, within contract limits. Billing index with payee, address, and cost information. Method of monitoring contract and approval dates of providers. Support for licensing management process. Management reports reflecting actions due and overdue. Record of utilization of providers and associated services and costs. Basis to assess unit rates on a statewide basis and standardize unit of service. Scope The scope of the provider/resource subsystem can vary by the type of resources included, the planned functions, and the corresponding information collected. The resource inventory is the most basic function of the subsystem. The complexity and detail increase with such additional functions as support for the licensing management process or automated match- ing of client and provider. Some types of resources and functions are not applicable in some social service environments. Not all organizations may carry licensing responsibilities or require automated support for this function. Integration A second major decision is the extent to which the system integrates the requirements of the different type resources and functions. Some of the areas to be addressed are common forms, standard data elements, control over providers, sharing data collection, and usage. A generic resource form for all providers is one method of integrating all providers into one system. However, some accommodation of unique requirements by type of resource is neces- sary and can be accomplished by having special areas on the generic form or a supplemental document. The integration of providers into one subsystem also raises the issue of control, evidenced by questions of who can update the data, see and request copies of the information, and use the provider in the delivery of services to the client. Generally, all users can update the common information and their own section. Specific parts on regulated facilities or vendors can be updated only by the staff person responsible for licensing or purchase of service, respectively. Access to information depends on confidentiality restrictions for the regulatory functions and resource competition problems among sites. Competition over scarce resources may be heightened by the visibility of data on such sought-after providers as foster homes and emergency needs groups. The foster home presents a special problem because one site may put forth the effort to approve it, while another proceeds to use the provider. The organization must decide which of the following approaches should be built into the system: e Sites have information only on their providers; ® Sites have information on all providers, but the system only permits usage of their own providers; or ® Sites have information on all providers, and the primary site designates in the system other locations that may share their use of providers. Formal sharing is the best strategy because it expands available resources and reduces the approval process work. However, it demands interagency coordination and communication. An open listing of providers can be valuable for preventing multiple agencies using the same foster home without each others’ knowledge, thereby creating a potentially poor situation for any child or adult. 128 Resource Number Each provider requires a unique identifier. When an individual or facility applies to become an agency-approved provider, purchase-of-service vendor, or licensed facility, or when a service worker decides to include a community resource in the system, an automated or manual search is necessary to determine if the provider already has a resource number. Otherwise, a new number must be assigned. Preferably, the automated search included a check on numbers in all sites. Once the number is in the system, care must be taken to keep the number to provide proper audit trails, track utilization, etc. The numbering system may identify the type of resource. For large organizations, it must accommodate the central agency and satellite facilities. The particular problems relate to the environment of the system. Linkage With Other Subsystems The provider/resource subsystem has links with the service delivery and the financial management subsystems as shown in figure 11. For the vendors, this subsystem indicates the services authorized for purchase and the negotiated cost for each unit. Some systems even indicate the services contracted for and provided to date, while others may reflect this in the financial subsystem. The service delivery link is the reporting of the planned resource on the service plan/purchase order, with service delivery processing confirming the service as au- thorized and the vendor as approved. 129 Figure 11 Provider/Resource Subsystem Provider Set-Up Document he Licensed Community Facilities Resources \. Puishase Nua : / of Service He « (Agency Vendors Approved) Financial Enrolment Information Clients © Approval © Purchase © Service Dates Orders Plan © Services e Invoices Offered o Service Rates Service Delivery Subsystem The service delivery subsystem supports and monitors the delivery of both direct and purchased services, validating all planned services against policy standards. The subsystem also provides a history of all delivered services for identifying services given to a family or client and enabling the analysis of data for management purposes. Some potential benefits derived from this subsystem are: ® Tracking of purchased and direct services by family unit and individual client. ® Monitoring service delivery against policy requirements. ® Initiating an automatic purchase-of-service process. 130 Tracking the delivery of services toward goals and objectives. Determining unmet needs, based on unavailable services or resources. Tracking subsidized adoptions. Planning and monitoring the provision of foster care maintenance and personal care. Reporting information and referral. Giving service workers reports on caseload service activity. Providing the structure for direct time reporting. Generating State and Federal statistical reports. Allowing analysis of service delivery and associated costs by service, client, program areas, etc. ® Allowing a comparison of purchased service expenditures versus direct service costs by service. Reporting Services The typical process for initiating service delivery is for the service worker to develop a service plan that specifies the services to be provided to a client, planned start and end dates, the number of service units, and the resource. The goal or objective for each service or set may be specified. The provider may be the service worker, another agency staff member, or an outside agency that gives purchased services or offers services without cost. The provision of services by internal agency staff is called direct services. For purchased services, the service plan may serve as the purchase order, or it may produce a purchase order after the information passes through the necessary checks. The system should also generate an invoice or payment listautomatically from the same information. The financial management subsystem addresses this (see figure 12). 131 Figure 12 Service Delivery System e Multiple Clients Client Service o Service Worker Orders Services © Multiple Services Plan * Direct e Multiple Vendors Document * Purchased * 6 Month \N By Fiscal Year o State Allowable Services o State Maximum Units e Allowable Services by Local Agency = Eligibility Category » Service/Component » Objective/Goal = Method of Provision + Direct + Purchase * Funding Source > Provider © Validates Provider Contract Dates o Extracts Service Rate Information Financial Management Subsystem Service workers may also give information and referral and unplanned services and perform many other important activities such as adoption supervisory visits for the court or arrange- ment of a foster child's home visits. A special form may be necessary for reporting this work and presenting a complete picture of assistance given to clients (see figure 13). 132 Figure 13 Direct Service Reporting Service Delivery Subsystem -Direct Service Reporting © Direct Services Delivered Direct Service © Time Studies Reporting e Special Studies Form Service Plan Cost Allocation/ Caseload Standards Subsystem o Direct Services Delivered e Service Plan Analysis © Direct Service Cost Calculations = Planned vs. Actual o Caseload and Service Standards * Unplanned Services Delivered e Manpower Projections Validating Services The service delivery subsystem may validate the following information for each service plan submitted for the first time: ® The case is active; ® The client is eligible; ® The service is allowable for the client's program area and the worker's agency; e Special rules on client need, maximum allowable units, etc., are met; and ® The resource is valid when the plan has purchased services. This validation can occur for all planned services prior to delivery. If errors are indicated, the service worker receives the plan back for immediate correction. The service worker should also have the ability to update the plan as the client's situation changes. For direct services, this process would take place after the fact and indicate changes needed in the agency's provision of services to insure compliance with policy requirements. 133 The service delivery subsystem uses a State policy table and a service table for validating services planned or given to the client and for allocating limited social service funds according to the organization's priorities. The policy table lists all possible services/components that are allowable within the service system as services delivered directly by the worker or as purch- ased services on behalf of the client. This listing could include not only title XX services but also WIN services, title IV-B services, foster care, room and board, etc. The policy table may be used by the system to validate that a service requested on a service plan is allowable and to determine if any special edits are required and if the maximum units/rate is applicable. As a further refinement, the service table indicates for each service the valid eligibility category, program area, method of provision, and funding sources. For a State-supervised, locally administered social service program, each local agency has its own local table as a subset of the service table that identifies allowable services in that jurisdiction. Figure 5 presents the service planning process and the validation of all services. Cost Allocation and Time Study Process The service delivery subsystem may also accommodate the Federal cost allocation require- ments through the development of the standards or reporting on the standards. For some States, this plan may require 100 percent reporting on a planned basis; other States may have standards based on staff reporting 100 percent of their time for a list of functions during a study period. Figure 13 shows the use of the direct service reporting form for this purpose as well as its regular use for recording direct services. The figure also shows the flow of data—service data to the service delivery file and all data in the study phase to the cost allocation file. The incorporation of cost allocation requirements integrates further social service information needs and improves the reporting process. Financial Management Subsystem The financial management subsystem handles all financial operations within SSIS. Its design provides an accounting system that can accommodate the small agency as well as the large complex operation. This includes the management and allocation of expenditures to the different Federal and State funding sources, including title XX, title IV-B, title IV-C, and donated funds. The financial subsystem provides allotment and account control, generates purchase orders and invoices, processes invoices, produces payments, and generates a full range of financial management reports. The subsystem validates that funding is available for purchased services specified on the service plan. The allotment and account tables are set up to handle changes in funding and services from one fiscal year to the next and to accommo- date midyear modifications. The potential benefits associated with the financial management subsystem are: Handling and maximizing multiple funding sources. Providing control and flexibility over allotments and accounts. Generating purchase orders and invoices automatically for purchased services. Establishing a complete audit trail through financial reports. Handling payments for purchased services, foster care, etc., through a centralized check- writing system. Generating required State and Federal statistical reports. ® Producing management reports for use by fiscal officers and administrators. ® Supporting analyses of expenditures by service, client, program area, and other areas. 134 Figure 14 shows the structure of the financial subsystem and the resultant documents produced. As indicated earlier, the purchase order may exist as a separate document from the service plan when the order completes and becomes part of the contract with the vendor. The issuance of the service plan may occur at the conclusion of the financial processing to confirm the availability of funding for the planned purchased services. The five major processes comprising this subsystem are described next: allotments, accounts, invoices, encumbering, and payments. Figure 14 Financial Management Subsystem J By Fiscal Year RA Allotment © Monitors State and Federal Allotment Table bo - Pee e Account Setup for Appropriated and Donor Funds Account ® Account Restrictions Table » Eligibility Category * Service/Component ® Service + Geographic Area o Restrict + Provider * Reimburse| Handles Multiple Funding Sources Percent « Title XX o Funding « Title 4A Source « Title 4B « Title 4C © Monthly Encumbrance/Unencumbrance NS Purchase © Generates Purchase Orders Order by Vendor Invoice * Generates Invoices on a Monthly Basis o Client Specific Client Service Plan Turnaround 135 Allotment Process Allotments are set up before the beginning of the fiscal year. A central fiscal point is responsible for controlling Federal and State funds and for monitoring all allotments. Each local agency may be responsible for controlling locally appropriated and donated funds, and for monitoring its specific allotments. Allotments may be established by type such as title XX purchase, title XX direct, AFDC-FC, WIN, State/local foster care, etc. The allotment structure allows a great deal of flexibility. It handles multiple funding sources and can adapt to additions or deletions in funding streams for social services. Block grants can be as easily handled as categorical sources such as title XX. Account Process Accounts are established before and during the fiscal year. Each agency may have respon- sibility for setting up its own accounts, establishing them based on funding source or service. An account set-up document is completed for each account being established. Restrictions are allowed on an account by donor funds, subcategory, services, vendors, special needs, and geographic areas. Computation of Federal, State, local, State administrative, and local ad- ministrative shares of the account are handled automatically by the subsystem. Each account receives a number. Accounts are maintained by adjusting the account balances whenever one of the following occurs: a. Purchase order or vendor invoice is created, cancelled, or processed; b. The transfer of funds out of an account or between accounts. Accounts are automatically selected by the financial management subsystem at the time of encumbering. However, an account override may be provided through the option of entering an account number on the service plan for a purchased service. Purchase Order and Invoice Process The purchase order process is initiated when the financial management subsystem is passed an edited service plan by the service delivery subsystem. The financial management subsystem takes the service plan file and attempts to find funding for all purchased services in each service plan. If the service plan contains errors or sufficient funding is unavailable, the financial management subsystem sends the service plan back to service delivery, where the plan will be rejected. If the service plan is accepted, the financial management subsystem assigns a purchase order number, selects the appropriate account based on the funding and service codes to pay for the service, encumbers an amount to cover the first month's invoice, and updates the account records. In a few circumstances, the whole amount may be encum- bered. A purchase order is generated upon acceptance of the service plan. For each order, individual invoices are generated based on the service plan schedule by month. Copies of the order and all invoices are forwarded to the vendors by the local welfare agency. At the end of each month, the vendor returns the invoice showing the units delivered by day, the total number of units provided, the gross billing amount, deductions for fees or benefits, and the net billing amount. Upon receipt from the vendor, the service worker and the fiscal officer approve the invoice for payment. Each invoice, once it has been sent back for entry into the system, must pass certain edits on the calculations, units, and prices. After the edits, the accounts and other files are updated. If the organization has purchase-of-service contracts for specified sums, the service plan may also serve as the purchase order and encumber funds allocated to a specific vendor. The 136 financial management system rejects any service plan or invoice requiring expenditures in excess of the contracted amount unless contract amendment and transfer of funds to the vendor's account take place. The use of a purchase order or invoice may be inappropriate for foster homes, given the nature of the situation and the ongoing provision of care, unless the child's placement is disrupted. The service plan should provide the necessary placement data, and from this a payment listing could be produced, replacing the other documents. The listing would go to the service worker to verify accuracy and make any needed changes just prior to the production of checks. Since the agency responsible for the child and the worker know his location, this method is easy for handling foster home payments and is in keeping with the home's special status. Subsidized adoption payments for the maintenance and care of the child require similar handling. Encumbrance Process The encumbrance process involves committing funds to accounts selected according to predefined rules and unencumbering funds later if funds encumbered for the invoice were not used. Two encumbrance processes may be designed into the financial management subsys- tem. Under option 1, once the projected encumbrance balance for an account reaches zero, the system will automatically shut off the account. The projected encumbrance balance is the amount of funds that would be available if every invoice within the system were encumbered at that point in time. Under option 2, the approval of service payments from accounts that have demonstrated a high unencumbrance rate may be allowed even if the projected encumbrance balance is negative. This allows greater utilization of available social service funds, but must be controlled carefully to prevent late rejection of service plans and the risk of many service appeals. The process produces financial planning reports for management that display both current levels of expenditure and projections of insufficient funds. Payment Process Once the vendor has recorded on the invoice the actual units delivered, and the agency has approved the invoice and entered it into the financial management subsystem for payment, and the invoice has passed the necessary edit routines, the invoice data will be input into a voucher file. The voucher file may be run to group invoice payments to the same vendor. In State-administered social service organizations, the voucher file may generate a voucher detailing the data for each invoice for which the vendor is receiving payment and provide required payment data for producing checks. Locally administered systems may do the same or provide a billing list to the locality, which in turn would produce vouchers and checks. 137 Potential Online Inquiries This section includes a representative sample of online inquiries that might be included in a social service system with online capability. The use of the inquiries is greatly facilitated by the system having a ‘‘menu’’ screen, which displays all inquiries and allows users access to each with minimal data entry. Case/Client Subsystem Case Name Inquiry: This is a general search based on the case name. Further qualification of the search and a reduced number of tries will occur with the addition of sex, race, date of birth, and social security number. The screen may be a listing of identifying data. Cross-Reference Inquiry: This inquiry displays all cases cross-referenced to the given case. Output consists of identifying data for each case. Case Number Inquiry: This is a specific search of the SSIS data base on the same case number. An option code may allow different assistance areas within the case record to be displayed. Without the option, all client program areas within the case are displayed. Client Name Inquiry: This is a general search based on the name, sex, race, birthdate, and social security number of a client. The name may be Soundexed and the sex, race, birthdate, and social security number used to further qualify the search. The result of the search may be a screen listing of weighted matches. A client-specific screen results when inputting social security number or case number. The result of a specific search is a screen displaying client data, case data, and supplemental data. Foster Care Inquiry: This transaction retrieves and displays foster care data on the specified client. Type of data includes placements, goals, etc. Adoptions Inquiry: Adoptions data are retrieved and displayed by this transaction. Type of data includes adoption placement, subsidy, etc. WIN Inquiry: This transaction retrieves and displays WIN data. Adult Protective Services Inquiry: This transaction retrieves and displays adult protective services data. Resource Subsystem Query by Resource (Provider) Name: This is an online query program designed to accept a name and qualifiers and search the resource subsystem based on ‘‘sound alike”’ Soundex search for matches. Selection may be limited by region and/or locality. Query by Resource (Provider) Number: This is an online query program that allows queries by resource number and displays information related to the given resource. The nature of the display data is determined by the option entered. Examples are agencyv-approved processing, service/rate information, clients using vendor, outstanding purchase orders. Query by Service Category: This is an online query program designed to allow the user to query the system by service category and retrieve all resources providing services in that category. Selection may be limited to region or locality based on the service category and the user. Service Delivery and Financial Management Subsystems Service Edit Table Inquiry: This is an online inquiry program that displays the information contained in the service table file. Services Policy Table: This is an online inquiry to create, update, and inquire against the table. 138 e Allotment Inquiry: This is an online inquiry program that accesses and displays allotment record information. e Account Inquiry: This is an online inquiry program that accesses a specific account record and its detailed records showing balances and current account transactions. e Purchase Order/Invoice Inquiry: This is an online inquiry program that accesses purchase order and invoice records and displays various data depending upon the request. e Service Plan Inquiry: The service plan inquiry may be used to search for client service plans in the system based on case number. The development of an online system requires careful consideration of confidentiality requirements and security measures described in chapter 5. In a statewide system, it is essential to identify what locations and levels of the organization have a need and right to data that can be identified with a particular family or individual. The rights of the agency must also be protected. While it operates under the Freedom of Information Act, the agency has the right to know who wants what information and to release it according to its desired approach. Security measures are also needed on the agency's data, such as allotments and accounts, precluding search expeditions based on curiosity or worse. Substantial justification should exist for any access points outside the agency. Potential Reports The social service information system has the capability to produce an overwhelming number of reports for any user and the organization. It should satisfy the information needs of the various management levels and users of the system and the requirements of the legislature and State and Federal organizations. The reports produced should be based on a thorough analysis of requirements, following the guidance in chapter 4 on defining and selecting reports. This section presents a representative sample of regular reports that could be pro- duced from the social service system, noting where online capability could replace a report. Three major types of reports exist: workload reports, action due or exception reports, and management and statistical reports. Many in the last group are ad hoc reports. Case/Client and Service Delivery Subsystems Workload Reports. The agency needs an alphanumeric listing of open cases and another for closed cases to receive clients, direct them quickly to the right worker in the agency, and provide some initial client information to the worker. This information could be online. The service worker caseload report lists the total caseload to enable planning and manage- ment for service delivery. The report should include child protective service, foster care, adoption, adult service, family, and other cases. Supervisors are able to use this report in relation to their staff to facilitate monitoring progress and the assignment of new cases. Local and State statistical summaries provide higher level management with some abbreviated caseload, application, and case disposition data. Action Due and Exception Reports. Action due reports provide the service worker with information for monitoring the service planning and delivery processes and alert him to key action required for the case. Critical events are listed, such as advance notice of eligibility redetermination due dates related to mandated deadlines, service plan ending dates, notice of required report for the court regarding the foster care child's status, notice of required supervisory adoption visits, etc. The report should reflect all due actions identified by the total system rather than one subsystem. The supervisors often receive a copy of the same report. A statistical summary of due and overdue items for the worker, agency, and State may follow the 139 report. Another report is the case assignment exception report, which identifies new cases in the agency that have not been assigned within a reasonable time frame, reducing the possibil- ity of lost cases. Monitoring efforts by higher levels may require special overdue listings. Many discussed in chapter 9 for adoption and foster care could be included in the social service system. Those related to the child abuse and neglect investigations should remain separate because of the greater confidentiality needs. Management and Statistical Reports. Many possible statistical reports can be produced, preferably on an as-requested basis. Examples are adult protective services reports and disposition, WIN certifications, client characteristics profiles, and foster care children profiles. The system can also produce listings of individuals who meet certain criteria for the purposes of pulling a sample for an evaluation or monitoring effort or of offering special services to a client group through the agency or other organizations. This last report is invaluable for evaluations and many special requests, even at the service worker level. Resource Subsystem These reports will be serving multiple levels and groups: the service workers, community resource coordinators, homefinders, purchase of service staff, licensing staff, and manage- ment. Workload Reports. Resource listings aid service workers in their selection of a resource since it shows all resources available in the locality and, as appropriate, within and outside the State. They also indicate which have been licensed or approved for purchase of service. The type of resources included may be children’s residential facilities, agency-approved day care, foster care, adoption, adult foster care, companion services, chore providers, other individual providers, and other community resources. The report series will be organized alphabetically, numerically, and by type of resource or service, as appropriate for the user. The report series will result in workers’ spending less time locating resources and selecting a better match between the client and provider of the service, leading to more effective services being delivered to the client. The report series will also facilitate the selection of approved vendors for purchased services. Some listings could be replaced by resource index cards. The online system may eliminate the need for reports and cards. The listings also serve as a master list for the person(s) responsible for updating the information, licensure, purchase approval, and/or agency-approved status. Mailing labels for a specified group of resources may also be helpful for such matters as the mailing of a foster home newsletter. Another workload report is clients by resource, which provides a listing of all clients using a specific resource in case an evaluation or other action takes place in relation to a particular resource. It also allows consultation between a service worker considering its use and a second worker who has already referred a client there. Action Due Reports. Resource action due reports provide key information for licensing, purchase-of-service, agency-approved provider,and other personnel for their workload. Re- ports must be tailored for each staff group to reflect their particular information requirements. The reports will facilitate the timely updating of information; approval of vendors; handling of inquiries, applications, etc., related to licenses and agency approved resources; and the handling of licenses renewal and agency approval of resources. Management and Statistical Reports. A statistical summary of action due reports provides management with information on which to base staffing needs and work assignments, to study work flow, and analyze workload problems. Other management reports are statistical summaries of the resources available, services offered, rates, location, and the usage of resources by specific type of resource. 140 - Financial Management Subsystem The system should produce basic accounting tools as well as financial control and planning reports. Standard financial reports on accounts and encumbrance funding status have been discussed in earlier sections. Cash status reports indicate the actual amount spent from each account and the balance remaining. Information is also needed by the source of funds allocated to the agency, includ- ing Federal title XX funds, State funds, local appropriated funds, and any donor matching accounts. The report should alert the agency when pledged donor amounts are not paid on a timely basis. Accounting ledgers show funds encumbered and unencumbered for each account held by a local department, indicating the ongoing balance of unobligated funds. The purchase order analysis report indicates invoices submitted against each purchase order and helps fiscal officers identify outstanding invoices. Warrant registers or some certification method for payments must also be produced. Financial analysis reports produced by type of service provide agencies with timely information on where their heaviest expenditures are and if any modification of funds allocated for particular services are necessary. Many regular and periodic demands exist for expenditures in social services by various combinations of services and population group. Typical requests are costs for each service, service and a population group, cluster of services, and a population group across the dimension of time. The population group may be the elderly or foster children or the hand- icapped, depending on the use of the information. Another important expenditure item is cost by source of funding for particular services. Payoffs for the Service Staff The social service information system affects the work activities of the service workers. The time spent in the performance of certain functions will be lessened. The performance of other functions may not involve less time, but the ability and effectiveness of the social workers in carrying out these functions should be enhanced by the system. The benefits for the service worker relate to both the case management and administrative responsibilities. Some illustra- tive examples are described. Case Management Reports on the total service caseload for a worker and for the agency help in the planning of the overall activity needed. Action required reports also aid in the performance of this func- tion. Management reports should increase the ability to plan and control service delivery and to evaluate the progress made toward meeting the objectives of the service delivery. Service delivery information should be useful in reassessing the case and determining the continued need for service. The system may make the information about resources more accessible and more timely, since it is computer generated rather than obtained through manual searches. The amount of time spent in the selection of a resource for a client should be lessened since data are readily available on service rates, characteristics of clients accepted, etc. The evaluation of resources should be improved by using reports showing such data as expenditures and clients served. Improved and more accessible information provided by the resource profile should reduce the waiting time for appropriate placements and facilitate the placement of hard-to-place children. Knowledge of specialized foster homes and community services should reduce, if not prevent, institutionalization of children and adults. Such information should also assist the worker in returning a child or adult to the community. When institutionalization is the best 141 plan, the resource profile assists the worker in selecting the best possible facility that meets the needs of the individual child or adult. The supervisor has the information on service worker caseloads, actions due on cases and resources, and services delivered; therefore less time is needed to retrieve this type of information for supervisory meetings. More time can be spent on case consultation. The caseload management reports also improve the ability of local agencies to make workloads more equitable among service workers. Administrative Responsibilities The system automatically performs many tedious, time-consuming tasks for which local agency workers are currently responsible. This allows workers to use their time more approp- riately in professional activities. The simplified processes involve eligibility determination of clients, tracking of actions due, production of purchase orders and invoices, and preparation of statistical reports. For eligibility determination, the system may check eligibility automatically for AFDC- or medicaid-related service clients. This avoids the process of the service worker contacting the eligibility worker assigned the case or searching a card file. For other service clients, the eligibility dates are tracked automatically rather than manually in card files. Workers are notified in advance of due dates on redeterminations. The system also monitors required actions for individual case plans by such means as caseload management reports. This prevents the need for card files on required actions and insures the client getting the service. This also applies to actions required for vendors and agency approved providers, that may appear on a separate action required report. Without the system support, the actions due could easily be missed. For purchased services, the system may automatically generate purchase orders and in- voices, performing all needed calculations and checks. Where this is being done manually, this process could relieve service workers of much tedious and time-consuming work. The system’s incorporation of complex policy rules may assist the worker in carrying out the requirements and eliminating manual checks for compliance. The system should generate the financial and statistical reports that are currently handled manually. Workers still have to enter into the system the information that is aggregated to produce the reports; however, they record the information only once, not many times on different forms. The computer manipulates the information to produce multiple reports. In the long run, management's use of such information for developing a more effective service delivery process can also bring benefits to service workers. Staff and funding re- sources could be allocated where greater needs exist. Identification of provider gaps could lead to the development of new resources. Other benefits exist as well. The next section describes management’s payoffs. Payoffs for Management Management can use the information to set organizational goals for social services, to make the operation of the organization more efficient, effective,and responsive, and to communi- cate achievements to higher executive levels, the legislature, and the public. The system also offers benefits in terms of supporting certain operational work and savings. A useful data base exists to query for carrying out various management functions and to respond to external demands for information. It allows the tracking of expenditures, services 142 delivered, and resources available in the major social service programs and the aggregation and analysis of case and client data. An improved intra- and interagency planning process should result since the system can supply data on the types of services provided to types of clients and the associated costs. Better identification of the needs and characteristics of the clients can also come from uniform collection of client data. The system information also facilitates evaluation of all services provided to clients, to eliminate duplicative, ineffective, or obsolete services, to expand services with the greatest benefit, and to develop services to fulfill unmet needs. The system permits the study of the cost effectiveness of a service on a local, regional, and statewide basis, associating actual costs with actual clients served. The system data may be used to establish and monitor measurable program goals. With this combined knowledge, the organization can more effectively set priorities and allocate resources to service programs. The most advantageous and correct use of funds is also realized from the system. The financial management subsystem not only manages all the social services finances but also controls multiple funds consistent with the social service priorities. The system also supports the needs of auditors by providing a mechanism for internal control that may not have existed in the past. The system can also offer savings for the organization. System checks on services should eliminate or drastically reduce services inappropriately provided or purchased. The system should also prevent duplicate payments and insure the correct calculation of charges. Through an increased ability to monitor and evaluate program effectiveness and promote children’s return home or adoption placement, the organization may realize a savings in dollars spent per client on maintenance and care for children. Another source of savings is freeing staff from the manual maintenance of accounts or manual data aggregation for statistical and financial reports. Improved monitoring of adult and children’s programs can insure that the most appropriate services are delivered for supporting community-based care and preventing (re)institutionalization, thereby keeping down service costs and more ef- fectively meeting people’s needs. 143 REE RO TF NR ST RSA Eo) hth it eR ns whey } x DE - = oo *y - Co. - Xl. Beyond the Implementation of Systems—Using the Information Organizations spend substantial sums of money developing information systems, butdo not take the initiative to put it to maximum use at any organizational level and derive the full benefits. This is the situation from service worker to executive. An assumption among man- agement and system planners is that utilization will automatically take place with the installa- tion of the information system and the availability of reports and other system products. Experience has shown otherwise and, unfortunately, realization of the system's projected benefits are predicated on its use. This chapter discusses the primary factors associated with the low utilization of social service systems and highlights effective strategies for increasing the use of the system. The process of transforming ““raw’’ data into management information is also recognized as an important support for using the information. The last section looks toward the future uses of the system for management. Reasons for Low Utilization Low utilization of system products has many different and interrelated causes: (1) organiza- tional resistance to the new system, (2) lack of awareness of what information is available and how to obtain and use it, (3) problems with the data, (4) slow availability of the information, (5) lack of support from data processing staff, (6) limitations of the computer equipment, (7) poor system design, (8) gaps between the information and implications for action, and (9) informa- tion as only one factor in decisionmaking. Organizational resistance has already been discussed in chapter 7, Acceptance of a Social Service Information System, but some aspects are germane to the utilization of a system and deserve special attention here. Social service staff have had little data in their hands to use in working with caseloads, supervising staff, and making judgments about the administration and effectiveness of programs, and they do not know what to do with the data when they are received. Some staff may balk at using the information and express opposition, but indiffer- ence is the predominant response from administrators and staff. Staff are accustomed to making decisions without information and find it easier to proceed in the same subjective management terms rather than give time and effort to incorporating the new information into operational practice. To acquire the ability to make effective use of information often requires changes and the organization's time, effort, and even money to develop a new data analysis capability among staff. Management may not realize the requirements for this or may be unwilling to expend additional resources for insuring the system’s use when, seemingly, it should occur naturally. On the other hand, staff may resist or have difficulty in learning new analysis skills and integrating them into work. A slightly different aspect relates to management's and staff's expectations of the system. Supervisors and service workers may believe that the system cannot offer them any new insights or useful information because they know everything already. In very small agencies this may be true. Some administrators and program managers may have unrealistically high 145 expectations of what the system can do that borders on magic. When the system fails to provide expected information and results, disillusionment may set in and produce a counter- reaction that casts the system as useless and causes little or no utilization. Organizational resistance may occur for other reasons. Staff who deliver services may believe that information diverts the organization's focus from advocating for and helping people to cold management of the organization and programs by numbers. Administrators and program managers may believe that numbers are much less satisfactory than anecdotes to express human needs and achievements sympathetically and to win the support of legis- lators and budgetmakers. Other professional resistance may occur from those fearful that the information may prove embarrassing and lead to legislative or executive requirements for unwanted change. Each concern is different and may be well founded, depending on the organization and external environment. Another reason for low utilization of a system is management's and staff's lack of knowledge of what information the system can offer and how to obtain it. This factor may be a symptom of organizational resistance to the system or merely alack of communication on available system information. The organization may also lack clear and easy methods to obtain information and assistance on using it. Problems with the quality of the data and the presentation of the information create reluctance to use the system. Data quality has already been discussed in terms of accuracy and completeness. Other desirable characteristics needed in varying degrees are objectivity, sensitivity, comparability, and conciseness. Another attribute essential for its use is relevance for the purpose requested, combined with a readable presentation of the information. Some systems focus on providing information to top management and others to service workers, making the information irrelevant for the other group. Many systems do not provide manage- ment with the information necessary to make decisions and frequently produce overwhelming reports with an abundance of irrelevant information. Managers and staff cannot absorb the information provided, lack the time to separate the relevant from the irrelevant, and end up not using the system reports. The availability of the information affects use and is a major issue for management. While operational staff generally receive reports produced automatically because their information needs are predefined and regular, management's needs cannot be anticipated and vary according to changing situations and demands. Information needed immediately for consid- eration in making a decision, planning the budget, undertaking a public education program, etc., has no relevance if it comes after the need has passed. A pattern of slow responses to needs and late reports contribute to underutilization of the system. The lack of support from data processing staff can affect the availability and the timeliness of information and be the underlying cause for management’s low utilization of the system. Two types of support are needed: resources to do the job and a positive attitude among technical staff toward accommodating ad hoc requests. Sufficient resources may not be available to handle requests, retrieve information, and cover the additional data processing costs. Planning for these resources and then allocating available time and money to informa- tion requests may not occur. The other required support is data processing’s recognition of the value of special requests. Often data processing staff believe all information requirements can conveniently fit into regularly scheduled reports, and technical staff discount ad hoc requests and only reluctantly respond. If funds are tight, this gives automatic justification for disregarding them. A poor attitude exacerbates the difficulties of ad hoc reporting because technical staff may hasten to finish them so quickly that the report may have serious design errors that make the report invalid and frustrate users. Difficulties with support can cause the demand for information to dwindle. The computer equipment may limit the responsiveness of the system. When itis operating at full capacity, the computer may have difficulty in accommodating information demands 146 outside operational needs. In these instances, only increasing the data processing capabilities or locating alternative data processing resources can alter the situation. Poor system planning increases the chances of ineffectual utilization of the system. It is often an underlying cause for the system failing to respond to needs and producing data that is often not relevant or that is not presented in a way helpful for making decisions or for other uses. Planning may also not have taken into account the need for the organization and equipment to accommodate the full set of information requirements. In addition, noninvolve- ment of users in the process may have reduced their readiness and understanding of the change, increasing resistance. The last two possible causes for low utilization relate to the limitations of the information for action and decisionmaking. The information provided by the system often does not offer a clear path for action. The value of particular data and their significance is not always obvious. The system data may point toward areas of weakness or areas of strength. However, the information may only provide potential, not actual, indicators, and understanding their mean- ing may require study and analysis before action can be taken. Information is also only one factor in management's decisionmaking. Management draws on the system in reaching decisions, but many other factors come into play, such as experi- ence, intuition, political wisdom, cost, and value base. What the information eliminates is the “plain guessing” factor, not the others. Understanding these reasons for low utilization of the information system can help plan the strategies for the system’s effective use, which is the subject of the next section. Strategies for Effective Utilization Much planning and work are necessary to make the system’s information available, useful, and utilized when needed by all levels of management. Understanding the traditional causes for poor utilization of social service systems gives clues for the development of successful approaches for turning around this situation. Organizations with operating systems have found the following strategies to be effective: ® Training, e User advocate for supporting utilization, e System’s incorporation into the organizational mainstream, ® Capability for providing timely information, and eo Effective data presentation. Training Training is necessary to encourage and improve the use of data and reports available from social service information systems. Different levels of staff and management should receive training focused on their sphere of responsibilities. While the service workers’ needs center around the use of standard reports for service delivery, other levels of management need assistance in using both regular reports and an open-ended data bank. Training for the service workers is straightforward, emphasizing the regular reports. On the other hand, the various management groups require a number of topics, depending on the level involved. The subjects may include the uses of existing data, intent of new reports, uses of the new data bank, various formats of the data, and analysis and interpretation of the data. Service staff frequently need an introduction to data utilization concepts, including how to read and interpret different types of statistical reports—for example, frequencies and 147 crosstabs—and how to calculate percentages and present data on graphs. Training on the utilization of the system may facilitate a mutually beneficial exploration of how different staff in similar positions make use of a system. They can share and learn how others use and present the information in relation to such areas as budgets, planning, board presentations, and community awareness efforts. Service workers and supervisors may share their different uses for managing caseloads or supervising service staff. Organizations must experiment with training to determine the best methods of teaching utilization of information systems. The State of Virginia offered a seminar to key local agency administrative staff on the management use of information from foster care and child protective services systems. Besides receiving a presentation on data utilization concepts, administrators were given “hands on’’ experience in working with reports on their locality and region and developing structured program information books on each child welfare area. The seminar participants transferred the locality and region information to charts, graphs, etc., and identified surprising findings for their geographic area. Then they discussed variances among similar localities, the localities’ relative standing in the region and State, and the significance of these differences. Some administrators uncovered that their agency actually made heavy use of lower ranking foster care goals rather than higher ranking goals, as they had thought. Discrepancies surfaced between what was reported on the system and what administrators and supervisors knew to be the situation. By the conclusion of the seminar, participants had a working familiarity with management reports in both systems, awareness of how to obtain additional information, basic understanding of statistics and data utilization, and program books of foster care and child protective services that could be shared immediately with the board and community groups. Appendix C has a blank foster care program book. The year following showed a substantial increase in the number of special requests for information, and along with management's greater utilization, an improvement in data quality. A user guide on management reports is helpful as an ongoing reference for using the system. The State of New York has developed a guide for managers on foster care and adoption reports. User Advocate in Utilization The user advocate can promote use of the system by consulting, defining information needs, retrieving data, and assisting in its use. The user advocate becomes a utilization agent who works with key staff on interpreting information needs and making available data that fit conditions of the local operation/user environment. The significance of data is not always clear, and it is important.for someone to analyze data and recommend action. The utilization role is new. Much must be done to develop roles, define relationships among management and staff at all levels, and set reasonable expectations. The expertise of the user advocate lies in understanding fully the system data and their characteristics and significance and knowing the data immediately available. They are experts at giving management information and at saving others time. Top managers may often express a need for information, but they may not have time to think through the specific requirements and later to analyze and judge the significance of the data. This falls to the user advocate, with support from other appropriate users. At the beginning and learning stage of the system, other managers may also require extensive assistance in defining information needed to make a decision or to take action. As managers increase their usage of the system and acquire greater familiarity with available information, their dependency on the user advocate decreases. System’s Incorporation Into the Organizational Mainstream The most effective utilization strategy is getting the information into the organizational mainstream so that staff benefiting from the system use the information as part of their normal responsibilities. Social service organizations are just beginning to integrate information into 148 the mainstream. Several approaches exist to build and extend utilization gradually. The most basic step is following up with the potential users identified during the planning phase, determining the use of the selected information, and providing technical assistance if neces- sary. Itis important to assess if relevant information is getting to the appropriate users for making administrative and program decisions. Top management may have questions about what the programs did and the achievement of results. Other managers need data on the relative effectiveness of different service delivery strategies and intensity of services. The integration of the system’s information into the organization may rest with the program managers. Top management may rely on middle management's active use of the system rather than their own. In any case, the information system can facilitate earlier decisions, more analysis of some situations, and consideration of several courses of action on problems or opportunities. Scheduling reports to interface with the planning and budget cycle is another step toward integrating information into the organization. The information can also be an important source for planning units concerned with program development and even budget develop- ment. Feeding data into the ongoing planning function provides leverage. Recognition of information’s value comes from proving its worth in action. All levels of management can promote the system’s integration into the organization's activities not only by their own use of the system but also by setting expectations for staff. Measuring staff cooperation through, for example, performance evaluation ratings might encourage use. Capability for the Provision of Timely Information Management's requests for information are not easily structured into a routine. The re- quirements are created on a demand basis— sometimes as an issue unexpectedly explodes—and the content, format, and usage vary according to the circumstances. For the information system to be useful, it must be capable of providing relevant information on time, even at a moment's notice, for a decision or action. Information available after the need is not very useful. The capability to retrieve information quickly is not easy to establish because it often goes unnoticed as a need. Some specific methods for insuring timely responses to information requests are dedicating staff resources to retrieve “on demand’ information, using of user-oriented software packages to retrieve information and perform statistical analyses, and having procedures to obtain the information and a library of key statistical reports to reference. The user advocate’s role has already been discussed. He can play a critical role in aiding the selection of data needed, retrieving the data, and analyzing it. The same staff may train users in methods for requesting and analyzing information to build greater independence and system use among all staff. The user advocate must handle the retrieval of information through a special program that pulls data off the system or from the reports reference library. The data processing staff may "handle the special request, but, as discussed, it is preferable for the user advocate to retrieve the information, with user-oriented software packages, within the technical framework estab- lished by data processing. Statistical Package for the Social Sciences and many different report writers offer relatively simple and nontechnical methods for performing statistical procedures and obtaining information and statistical results, often within a day. The establishment of formal procedures makes known and insures the organization's capability to provide information as needed. A report order form encourages users to make more frequent requests for information, and staff must be ready to respond. 149 The development of a report or management information reference library is becoming increasingly important. The reference library allows faster response because the information is already available and needs only to be pulled from existing reports. Libraries are an effective approach to keep down data processing costs and provide a historical data base. The major costs for libraries are the space and special filing cabinets required to organize and store the reports. Space requirements can be reduced by use of microfiche as the medium for reports. The State of Texas has taken this approach. Effective Data Presentation The information provided by the system should be tailored to the needs of the user and relevant to what he requires at that time. The report should be immediately understandable and its significance recognizable. The method or format of the data presentation affects its readability. The report should be as brief as possible. Lengthy reports often conceal rather than reveal information. Important facts should not be camouflaged by inclusion of other, less relevant data. On the other hand, the report should contain sufficient information so that the user feels that he has enough information for the intended use. The information also should be timely, trustworthy, and sufficiently current for the planned purpose. Timeliness has already been discussed. Trustworthiness means that data are suffi- ciently accurate for management to have confidence in them. How up to date the information must be depends on its use. Sometimes, for the information to be useful, a transformation process is necessary. This is discussed in the next section and may also be regarded as another strategy for effective utilization. Transformation of Data to Management Information Information systems easily produce quantities of data and countless reports. Data as presented in their ‘“‘raw’’ state on computer printouts are often not in a satisfactory form. In addition, information on two or three reports may have greater impact and clarity if brought together. Several methods of data presentation also make the data easy to understand: text, tables, graphs, trends, and percents. These are the processes for transforming data into management information and are discussed below. Narrative and Numeric Presentation The narrative form is usually desirable when the data are simple. When there is a large amount of complex data, the numeric form is preferable and is usually in the form of a table. Charts and Graphs Charts and graphs are an extremely useful and flexible means of presenting statistical data. The presentation of large amounts of quantitative data can be made simple and clear. Charts and graphs may also facilitate comparison of values and the identification of trends and relationships. Well-designed charts and graphs serve the following purposes: e create interest in the information, ® provide effective visual communication of the information that may be superior to words, numbers, or tabular forms of presentation, e enhance the comprehension and retention of data relationships, 150 ® bring out hidden facts and relationships, and e stimulate and aid analytical thinking and interpretation of the data (Schmid and Schmid, 1979, p.1). They can also save time because the meaning of masses of quantitative data can be presented so that it can be visualized and understood at a glance. Figure 15 provides a comparison of the value of a graph as opposed to a tabular presentation of data. [Note: The Virginia Department of Welfare furnished the data from their Child Protec- tive Services Information System. The Utah Department of Social Services prepared the graphs on equipment acquired as part of a systems development demonstration grant focused on data utilization tools, financed by the Department of Health and Human Services.] Im- mediately apparent in the graph are three trends in the reporting of abuse and neglect that are not obvious in the columns of figures. 151 Figure 15 Comparison Between the Tabular and Graph Formats: Child Abuse and Neglect Reporting Tabular Format Year Founded % AtRisk % Unfounded 9% Pending % Total 1975-1976 4703 22.3 10,031 47.7 6,311 30.0 Hoek war 21,045 1976-1977 3643 19.2 7,998 42.1 6,415 33.7 953 5.0 19,009 1977-1978 7967 35.1 3,651 16.1 7,364 32.4 3728 16.4 22,710 1978-1979 9568 28.8 4,179 12.6 18,864 56.8 617 1.9 33,238 1979-1980 9466 26.6 4,968 13.8 21,193 58.8 397 1.1 36,024 «xx = Not recorded. Graph Format Disposition of Child Protective Services Reports Dept. of Social Services 25,000 20,000 15,000 — 10,000 ?W-HIDOTMIT MO IMWICZ 0 1975/76 1976/77 1977/78 1978/79 Bl rourdedRepos ee At Risk Trend — —— Founded Trend Time Periods (MI untound Reports [J AtRisk Reports =m=== Unfound Trend 152 Three basic types of graphs and charts are frequently used. These are pie charts, line graphs, and bar graphs. Pie charts enable effective visual comparison of data that are expres- sed in percentages. They give a quick visual display of the largest and smallest divisions. Line graphs (see figure 16) are best in representing and comparing data over a period of time (Virginia Department of Welfare; Utah Department of Social Services). In some cases it may be advantageous to show more than one piece of data on a chart to reveal a relationship not as obvious if the data were on separate graphs. [Note: For example, the number of child abuse and neglect reports may be displayed not only according to age but also according to sex. By doing this, a transition may become apparent at age 11-12 from more males being reported than females. This would not be as observable if three separate graphs were used. ] Bar graphs are useful in comparing similar data from the same time period. They are created in the manner of aline graph except that each bar stands alone and is not connected by a line to the next. Bar graphs may be drawn vertically or horizontally, and more than one piece of data may be included on one graph. Bar graphs are also most beneficial when numerous variables are present, such as the source of a child maltreatment report. It may be desirable to show these for informational purposes, but it is undesirable to list them in a written discourse because of length. Figure 16 Example of a Line Graph, Multiple Years Child Protective Service Complaints Number of Complaints By Month and Year 4,000 ~ 3,500 Ss, 1979-80 *. ’ . oo, 3,000 2,500 2,000 1,500 N—HZ=>rvZ200 TO IMWZICZ 1,000 500 153 Graphic techniques are powerful and effective, but a cautionary note is necessary. They should not be a complete substitute for tabular and narrative forms of presentation. Staff must also recognize their limitations as well as advantages and learn when to use graphic methods and what form to select for different situations (Schmid and Schmid, 1979, p.1-11). Trends A trend is the general movement in the course of time (days, months, years) of a statistically detectable change. Trends hold considerable interest for management. They may confirm or reject predictions of change upon which management has based critical budgeting and planning decisions; they also may provide a basis for future planning. Their presentation may bein the form of narrative, numerals, orchartsand graphs. Figure 16 gives anexampleoftrends displayed by the line over bars representing the movement of abuse and neglect reporting over a 5-year period. Percents Versus Numbers Sometimes when presenting data it is useful to present both numbers and percents. Other times it is desirable, for space or ease of reading, to use one but not the other. When one population of data is being presented, it is acceptable to use numbers only. An example is showing the program goals for children in foster care. When comparing populations of data, it is not acceptable to use numbers only, but it is acceptable to use percents only. Often it is necessary to do more than look at the face value of numbers and percents. For example, for judging which of several districts was most successful in freeing children for adoption, the number and percent of children freed are not sufficient; it is also necessary to look at the total foster care population in each area. Interpretation of Data There are variety of ways to interpret data: by themselves or in comparison with similar data; similar localities, regions, or States; the Nation; norms or standards; or census and other data. All forms of data presentation, such as charts, graphs, trends, and percentages, may aid in the interpretation of the data. Trends in Utilization Social service information systems bring an information explosion and an unparalleled opportunity to manage information efficiently. Beyond the utilization strategies already de- scribed, several efforts are underway to chart new approaches for using information: ® Use of graphics equipment, Development of performance indicators, Establishment of data banks for management, and Generation of a microsimulation or forecasting model. Graphics Equipment Computer technology now offers graphics equipment to develop charts and graphs. The equipment can produce complex graphs in a matter of minutes and plot them in various colors and sizes. Figures 1 and 2 are both products of this equipment. As a result of a Federal grant, the State of Utah obtained and made extensive use of this equipment for social services and other human service programs. Staff have found them successful in budget and other presen- 154 tations to the legislature and Governor; they also found them helpful for quickly pinpointing areas where the rate of spending for programs was too fast or slow. Graphics equipment holds much promise for greater and improved utilization of systems. Performance Indicators As social service information systems become operational, more sophistication is possible in developing, analyzing, and comparing performance indicators in the management of service programs. Indicators may relate to processes such as the number of applications, services delivered, and funds expended, or to outcome measures such as the number of foster care children returned home. States are beginning to use systems to monitor key processes and to formulate and evaluate organizational goals. Key information from two, three or more systems can be combined to be more revealing of operational performance and effectiveness than any one system could indicate. Information covering all social service programs and all agency programs has a greater impact than separate, unconnected pieces of information. The States of Texas and Utah have moved toward developing regular reports for the executive manager on total agency operations, drawing in information from many systems and from the budget. More efforts and refinements in this direction are anticipated. Eventually it may allow for more expanded comparisons among States. Data Banks for Management The next step may be the establishment of data banks for management that would contain performance indicators and aggregated statistics, useful historical data, and trends on the client population and service delivery. Managers can perform “what if’ analyses and various data manipulations for decisionmaking on the management-oriented data base. As questions arise, managers can consult the ‘management system’ and have an answer in seconds. Existing online systems provide immediate access to data, but they are focused on indi- vidual events, not aggregated and historical information. Even further in the future is mi- crosimulation and forecasting. Microsimulation and Forecasting Inthedistant future, microsimulation and forecasting may be used with information systems. Simulation is the development of a model that can be used to predict the future state of the system. Vista Research received funding from the Department of Health and Human Services to develop and pilot test a model. Some of the policy questions the model will address are the effect of changes on eligibility, demographic trends, funding levels on clients and providers, or the introduction of new programs or regulations (Caldwell, Hospodar, and Russell,1980). Utah has served as a pilot test. Eventualy this work may lead to a model that can provide quantitative estimates on future demand for social services and on caseload and expenditures under alternative programmatic and economic assumptions. In conclusion, the benefits from the social service information system are obtained through active and creative use of its information. It is necessary to avoid or overcome the problems associated with utilization and to plan and implement effective strategies that support and improve usage. New efforts in using systems—graphics equipment, management indicators, management data base, and forecasting—may eventually bring even greater benefits to social service programs. 155 BR ad Glossary Acceptance criteria—The standards used for approving the new system as operating satisfac- torily. Access—Refers to using or obtaining the data in the system. Audit trail—A record of the origin and flow of computer actions processed through the system, used primarily for financial data. Availability—The extent to which a computer or system is ready when needed to perform desired procedures. Back up—The provision of alternate computer facilities in case of failure or a copy of data for reference in case the original data is lost or destroyed. Batch processing—A method by which a number of similar data or transactions are grouped for processing during a single continuous run on the computer. Batch update—The processing of the most current data using the batch method. Bug—A program error or defect. Centralized data processing—Data processing performed at a single, central location on data provided from more than one physical location. Coding—The writing of instructions that direct the computer to perform specified procedures. This is part of programming. Computer—The equipment capable of receiving data, performing specified procedures, and supplying the results of data collection and manipulation. Computer time—The extent to which the computer is available. Conceptual system definition—A general statement on a system made during the initial planning that includes the purpose, broad description, and interrelationships with existing or future systems. Confidentiality—The organization's administrative handling of, and its policies and rules for, disclosure of personal information. Conversion—The process of changing from one system (manual or data processing) to another system. Data—A general term for the figures, words, etc., processed or produced by the computer. It also implies raw data in contrast to information, which is refined data directed toward a use. Data base—The nonredundant collection of data structured into an ordered and planned relationship to meet the information needs of multiple users and levels of management. Data base management system—A system that establishes the rules for constructing the data base. Data control—The process insuring the proper and correct flow of data into and from the computer. Data dictionary—A listing and description of all data elements in one or more systems. Data element—The smallest unit of data. Data entry—The process for giving the computer data. Data processing—A general term referring to computers and their programmed action upon data. 157 Data processing center—The computer-equipped, central location where the data is proces- sed and possibly converted to desired forms such as reports. Data processing equipment—See “hardware.” Data retrieval—The obtaining of data. Decentralized data processing—Data processing performed in many physical locations rather than at a single, central site. Design freeze—A hold on changes and additions to a system, usually during the system development phase. Detailed design—The specific and detailed planning of the system that includes system specifications. It follows the general design and precedes the system development phase. Documentation—The development of material describing the system, its proper use, and data processing staff's maintenance of it. Downtime—The period of time that the computer is not functional or operating correctly. Edit criteria—The system's check on specified data elements for accuracy, completeness, and consistency in terms of conditions defined in the computer. Error messages—The computer's identification of incorrect data and situations within the system that require correction. Evaluation—The last phase in the planning and implementation of a system that involves judging the efficiency and effectiveness of the system for the user and data processing. Form—The method of collecting and entering data usually referred to as an input (something entered into the computer). General design—An early phase in planning a system that specifies what the system will do in general terms. Hardware—The physical computer equipment. Host computer—The primary or controlling computer that provides such services as compu- tation and access to the data base. Information—Data arranged and displayed so that it has meaning and is useful. Information requirements—Management’s and other users’ data needs. Input—The data to be entered into the computer and the associated data collection tools. Inquiry—A request for information from the system. Inquiry screen—A snapshot of existing information in organized predefined format that can be displayed on the computer terminal. Installation—The phase of developing a system that involves its implementation into the real environment. Management information system (MIS)—A computer system designed to furnish manage- ment with data for decisionmaking. Microfiche—A regular transparency product (output) of the computer approximately 4 inches by 6 inches that reduces data presentation significantly from standard computer reports. Minicomputer—A small computer often used for specific applications, costing much less than large computers and becoming increasingly versatile. Needs assessment—The first phase in defining the requirements and purposes of a system. Online—The capability of communicating directly with the computer system for data entry, inquiry, and printing. Operating manual—The instructions for running the system on the computer. 158 Operation—The running of the system. Output—The reports, documents, microfiche, and screens produced by the computers. Password—A security requirement in the form of a unique word that must be supplied to the computer for accessing the system. Phases—The major steps in developing a system: needs assessment, requirements analysis, general design, detailed design, system development, installation, system maintenance, op- eration, and evaluation. Pilot test—The testing of the adequacy of the new system in a real environment at a trial site. Printer—Computer equipment that prints paper outputs from the system. Printout—Computer-produced paper report. Privacy—The individual's right to control the use of facts about his (her) life and his (her) willingness to share data concerning himself (herself). Program—A series of instructions for directing the computer to perform desired operation(s) to achieve a certain result. Program specifications—The design of a program that is used to write it. Program test—The running of the program against test data to judge the adequacy of the program. Programmers—Data processing staff who design, write, test, and maintain the programs. Programming—Preparing instructions for the computer to use in performing desired opera- tion(s). Project management—The leadership and direction provided for planning and implementing a system. Quality assurance—The action necessary to insure that the system and its parts will perform satisfactorily in operation. Record—A collection of data elements handled as a unit. Recovery procedure—Method for obtaining lost data. See ‘back up.” Remote site—Physical location with terminals distant from the computer. Report—A computer-produced product, an output, displaying key system data usually on paper. Report writer—A program external to the system that can format and process data and generate reports. Many different ones exist, varying in complexity and performance. Requirements analysis—An early phase of planning the system that sets forth its initial purpose and definition, leading to the general and detail design phases. Response time—The amount of time elapsed from the request of an inquiry or entry of data at a terminal to the receipt of data or its processing. Screens—The display of data for input and output on a terminal. Security—Specific procedural and technical means to provide the desired degree of confi- dentiality. Shaking down—Identifying and resolving errors and other problems in the system through testing. Software—The programs used to extend the capabilities of computers. Subsystems—Major parts of the system. System—An organized grouping of procedures and programs that is considered as an or- ganized whole to accomplish specific objectives. 159 System acceptance—The formal approval by users and data processing staff that the system operates as planned and in a satisfactory manner. System changes—Desired revisions to the system as planned. System development—(1) The total process of planning and implementing a system covering all phases or (2) following the detailed design, the building of the information system through programming and testing, and organizing for the installation. System maintenance—Service to the system to insure smooth operation and to accommo- date needed changes. System specifications—The combining of user requirements and needs to formulate prog- ram design and computer file structures in an orderly flow. Systems analyst—The data processing person defining system needs, designing the system, and overseeing its development and installation. Systems test—The running of the total system against test data to judge its adequacy before installation in a pilot site. Telecommunications lines—Telephone communication lines especially equipped used to transmit data from one point to another. Terminal—Computer equipment that consists of a keyboard and possibly a display mechanism connected to the computer system for input and output. It varies in capability. Test data—Simulated input used for various levels of testing the system. Testing—See ‘‘program testing,” ‘‘systems testing,” and “‘pilot test.” Consists of all three. Transactions—A specific type of action such as entering, updating, or closing a case. Transfer—The use of an operating system in the development of a new one, from adopting the concepts and techniques to technically duplicating the system in a new site. Turnaround documents—Forms produced by the computer after the entry of data for the purpose of facilitating future data entry. User—Anyone who needs the services and data of the information system. User advocate—The mobility of involvement, liaison with data processing staff, user spokes- person and troubleshooter, systems consultant, and director of user efforts. User groups—Formal long-term or short-term groups organized to provide input to the development of the system. User involvement—Participation of users in the phases of system development. User's guide—Document that instructs the user on how to provide or obtain data, use reports, and resolve problems. 160 Bibliography Adams, J. Mack and Haden, Douglas H. Social Effects of Computer Use and Misuse. New York: John Wiley & Sons. 1976. Administration for Children, Youth, and Families, Department of Health, Education, and Welfare. ‘Program Information Needs for Service Delivery to Children and Youth.” Unpublished report. December 1978. American Humane Association. “Recommended Minimal Data Set Final Report.” Unpub- lished document. 1979. American Humane Association. National Analysis of Official Child Neglect and Abuse Report- ing (1978). Washington, D. C.: U. S. Department of Health and Human Services. 1980. American Humane Association. ‘National Study on Child Neglect and Abuse Reporting.” Unpublished document. 1981. Bowers, Gary E. and Bowers, Margaret R. Cultivating Client Information Systems. Project Share Monograph Series, Number 5, June 1977. Washington, D. C.: Government Printing Office. Boyd, N. Kent and Silver, Evelyn Stern. Factors Affecting the Development and Implementa- tion of Information Systems for Social Services. Washington, D. C.: Lawrence, Johnson & Associates, Inc. 1975. Busha, Charles H. (ed.) An Intellectual Freedom Primer. Littleton, Colo.: Libraries Unlimited, Inc. 1977. Caldwell, J. George, Hospodar, Joyce A., and Russell, Randall H. “‘Microsimulation Forecast- ing Model for Human Development Services Programs, MICROSIM: Detailed Model Description.” Draft Final Report. Alexandria, Va.: VISTA Research Corporation. 1980. Combs, Joseph J. “An Information System That Measures Foster Care Casework Effective- ness.” Children Today (May-June 1979). Davis, Gordon B. Management Information Systems: Conceptual Foundations, Structure and Development. New York: McGraw-Hill Book Company. 1974. Demb, Ada. Computer Systems for Human Systems. New York: Pergamon Press. 1979. Department of Health, Education, and Welfare. ‘Conference Proceedings Summary: National Human Services Information Systems Conference.” Unpublished document. 1980. Department of Health, Education, and Welfare. Human Development Services Information Systems Strategy. Washington, D. C.: U. S. Government Printing Office. 1979. Dertouzos, Michael L. and Moses, Joel (ed.). The Computer Age: A Twenty-Year View. Cam- bridge, Mass.: MIT Press. 1979. Donaldson, Hamish. A Guide to the Successful Management of Computer Projects. New York: John Wiley & Sons. 1978. Fanshel, David and Shinn, Eugene B. Children in Foster Care: A Longitudinal Investigation. New York: Columbia University Press. 1978. Frank, Michael R. The Effective EDP Manager. New York: AMACOM (A Division of American Management Associations). 1980. 161 Fried, Louis. Practical Data Processing Management. Reston, Va.: Reston Publishing Com- pany, Inc. 1979. Friedman, Robert M. “The Use of Computers in the Treatment of Children.” Child Welfare Volume LIX, Number 3 (March 1980). Howerton, Paul W. (ed.) Management of Information Handling Systems. New Jersey: Hayden Book Company, Inc. 1974. Kerzner, Harold. Project Management: A Systems Approach to Planning, Scheduling and Controlling. New York: Van Nostrand Reinhold Company. 1979. Klaus, Susan L. and Lauscher, Susan D. Child Abuse and Neglect Information Systems. Washington, D. C.: U. S. Department of Health, Education, and Welfare. 1978. Laurie, Edward J. Computers, Automation and Society. Illinois: Richard D. Irwin, Inc. 1979. London, Keith. People Side of Systems. New York: McGraw-Hill Book Company. 1976. McLean, Ephraim and Soden, John, V. Strategic Planning for MIS. New York: John Wiley & Sons. 1977. Michigan Department of Social Services. 1980-87 Annual Plan. Lansing: Michigan Department of Social Services. 1980. Mott-McDonald Associates, Inc. A Child and Youth Centered Information System: Phase II: System Design, Volume Ill, CYCIS Report Structure. Mott-McDonald Associates, Inc. 1975. Mott-McDonald Associates, Inc. A Child and Youth Centered Information System: Phase II: System Design, Volume V Security and Privacy Manual. Mott-McDonald Associates, Inc. 1975. Parker, Donn B. Crime by Computer. New York: Charles Scribner's Sons. 1976. Pennsylvania Department of Public Welfare. “System Development Plan.” Unpublished document. c. 1980. Perlmutter, Felice Davidson and Slavin, Simon. Leadership in Social Administration Perspec- tives for the 1980's. Philadelphia: Temple University Press. 1980. Richey, Betty. “The Computer in a Child Care Agency.” Child Welfare Volume LVI, Number 4 (April 1977). Roth, Richard A. (ed.) Selected Readings on the Enhancement of Social Services Management Systems. Washington, D. C.: U. S. Department of Health and Human Services. 1980. Sanders, Donald H. Computers and Management. New York: McGraw-Hill Book Company. 1970. Schmid, Calvin F. and Schmid, Stanton E. Handbook of Graphic Presentations (Second edition). New York: John Wiley & Sons. 1979. Schoech, Dick J. and Schkade, Lawrence L. “What Human Services Can Learn from Business About Computerization.” Public Welfare (Summer 1980). Seaberg, James R. and Gillespie, David F. “A National Child Abuse and Neglect Databank: Inter-Reporter Reliability.” California Sociologist Volume 1, Number 2 (Summer 1978). Shyne, Ann W. and Schroeder, Anita G. National Study of Social Services to Children and Their Families. Rockville, Md.: Westat, Inc. 1978. Slavin, Simon (ed.) Social Administration: The Management of the Social Services. New York: The Haworth Press and Council on Social Work Education. 1978. Sullivan, Richard J. “Human Issues in Computerized Social Services.”’ Child Welfare Volume LIX, Number 7 (July/August 1980). 162 Taylor, James B. and Gibbons, Jacque. Microcomputer Applications in Human Service Agen- cies. Project Share Monograph Series, Number 16, November 1980. Washington, D. C.: Government Printing Office. Tomeski, Edward A. and Lazarus, Harold. People-Oriented Computer Systems: The Computer in Crisis. New York: Van Nostrand Reinhold Company. 1975. Urban Institute. ‘State Child Welfare Service Reporting: Federal Information Needs Report.” Unpublished document. 1980. Vorch, Jr., Dan, Mottice, Homer J., and Shrode, William A. Information Systems for Operations and Management. West Chicago, lll.: South-Western Publishing Co. 1975. Weiss, Carol H. Evaluation Research. Englewood Cliffs, N.J.: Prentice-Hall, Inc. 1972. Whiting, Leila. “The Central Registry for Child Abuse Cases: Rethinking Basic Assumptions.” Child Welfare Volume LVI, Number 1 (January 1977). Young, David W. “Management Information Systems in Child Care: An Agency Experience.” Child Welfare Volume LIIl, Number 2 (February 1974). Young, David W. and Allen, Brandt. Child Welfare and the Computer: Four Years Later. New York: Edwin Gould Foundation. 1974. Young, David W. ‘Management Information Systems in Child Care: An Agency Experience.” Child Welfare Volume LIIl, Number 2 (February 1974). 163 RETIRE a TF ORG SVa P I SAE PET Et TE rE INN SILER] TNT Bo ay 2 foe a oud Appendix A Planning the System 165 az MEE TO . i = RARE La SUSSETeL TS SRE a Denes SATE Ren Ltn en xia > amet E on<2 ) ris Sais 3 usta dS ae aR, 40 A AM eR A RABAT LF Au 10. 11. Figure 1. Guide to Describing a Report . Title. Specify the name of the report as you wish the computer to print it. Description. Statement of what is on the report. Purpose. Very detailed, precise statements on how the report will be used. If the purpose varies by user, identify each purpose by user. User. Identify each user; this should clearly correspond to the purpose(s). Copies Required. Specify the number of copies to be produced for whom, the sharing of copies, alternative medium. Schedule/Frequency. Specify how often the report should be produced. It could be as needed, quarterly and/or annually, etc. This directly relates to purpose. . Format and Sequence. Identify instructions such as begin recording information on new worker, agency, and/or region on a new sheet of paper. The sequence refers to the outline structure of the information; that is, how the information should be organized by agency, worker, case number and/or case name alphabetically. How the information is presented should be related directly to its use— how is information looked up, who uses it, etc. Several levels of sequence may be identified with each sequence. Details. Specify any particular features of the report such as: — particular client group being presented. Detail on how the group can be identified by the computer, unique processing features of the report, other pertinent information, aggregate totals, etc., the obsolete date. Data Elements. List the data elements in the order of their presentation on the report. Repeat those listed under sequence (e.g., age — calculate from birthdate). Remember asterisks may be used and they count as elements; give their report definition. Priority. Evaluate the critical nature of the report and its rank compared to other requested reports. Identify the consequences of not having the report. Design a Sample Report. On a separate sheet put the title, arrange all information into the desired format and sequence, using the requested title. A sample report gives a visual picture of requested report. 167 Figure 2. Suggested Format for Specifying Standards or Rules To Be Monitored by the Computer Rule Title Definition Purpose Describe the reason for the rule, cite policy or other base for requiring the monitoring of the rule. Specific Application Describe its use for any of the following applicable uses: 1. Edit Criteria (i.e., basis for rejection of information entered into the system). ldentify the following: a. What form(s) would this be related to? b. Would this information lead to rejection of the total form or only the wrong information? 2. Advance Warning. Inform local workers that action is due and/or that client situation is changed which could impact service planning or delivery. 3. Exception. Inform welfare management of overdue actions. Specify at what point local directors, regional staff, and central office should be informed. It may be different for each level. 4. Funding Control. Identify any rules that determine source, percentage amount of funds and total dollar restrictions. 5. Other. Method for Monitoring Identify what information the computer will use and what calculations it will perform in order to monitor the rule. Response Time Specify what turnaround time is required in order to monitor the rule. Identify in terms of hours or days. State if a terminal is needed (and where) in order to monitor it. Benefits/Penalties Identify any benefits and/or cost savings associated with monitoring this rule. Also identify any potential penalties that could be incurred if rule were not monitored. Consequences of Noncompliance Identify what management will do if noncompliance occurs. Specify at what point do different managers take action. Presentation of Monitoring Information Identify on what reports the information would be presented. Responsible Person for Rule Person and/or section which sets requirements as specified in purpose. 168 Figure 3. Data Dictionary Outline 1. Data Element Name: 2. Element Description: 3. Element Purpose: 4. Source Document: 5. Reporting Responsibility: 6. Values: 7. Edit Criteria: 8. Data Relationships: 9. Volatility: 10. History Requirements: Identify the data element name. Statement of what the data element represents. Very detailed, precise statement as to how the data element will be used. If multiple uses, list each purpose. Identify each user of the data element. Source document(s) from which data is directly entered and from which data element is updated. Identify user(s) responsible for initial entry and for updating the data element. Specify coded representation of data element values. Specify single field and cross field edits to be conducted on the data element. Specify any other data elements that are affected by the entry or update of this data element. The data element(s) and nature of the relationship should be specified. Specify how frequently this data element will be updated, based on the nature of the data element. Number of occurrences. Length of time to retain. 169 ETE fa TC Tr AE aT Cosi i Ri PAR IR i aid AGES BT N22 Ha RINSE ei Cit 5 Sad Appendix B Implementing the System 171 Er or FR STR Ee RC Te AV Tp ag Sl oli PE Nl OO CT a He GENS SE CS he Figure 1. Comparison of Possible Testing Plans for a Small and Complex System Small System Complex Selection Method Number Pilot Characteristics Timing of Testing in Sites Introduction of the System Duration of Pilots ® loose o cluster of agencies, unit with an agency ® representative mixture of users ® some participation in the design e all at the same time eo total system ® two months ® rigorous ® 2-4 agencies o small site initially, larger later o efficient, well-managed agencies ® experienced staff ® resources available for testing © board/administrator/staff support for piloting © one site at a time, proceeding to the second, etc. ® only subsystems © 3-4 months for each subsystem 173 174 Figure 2. A Sample Training Outline for the Supervisor and Service Worker General Introduction Brief background on the trainers and trainees ® Objectives of training ® Agenda General Introduction to Computers ® Short introductory film on computer processing ® Discussion about how computers affect all of us (pay checks, banking, bills) ® Brief discussion of computer technology ® Basic computer concepts and terms Introduction to the New System ® Brief definition of the system ® Brief history of the development ® Who has been involved with the development, what user groups have participated e Other systems incorporated into and linked with the system e General explanation of future subsystems and schedule ® Benefits of the system and supervisor and service worker payoffs Specific Information on the New System ® Purpose of the new system/subsystem ® Objectives for detailed training ® Overview of the documents * Relationship of the forms to each other ® Overview of the inquiries e Overview of the reports e Worker tools e Confidentiality and the system's security measures ® Roles and responsibilities ® Service worker's legible and accurate completion of documents ® Data entry function ® Necessary interaction within the agency and among agencies ® Agency example flow * Inquiries, documents, data control, data entry, errors, reports ® Plan for detailed training on forms, inquiries, and reports Information on Each Form e Purpose e When to complete ® How to complete e Orientation to the document = Different section * How lines are lettered * How elements are numbered * Discussion of each data element ® Error messages *» What they are * How to handle them ® How long to save it, when to destroy it ® How to request another copy © Reports produced from each section * Who uses the report * Purpose * Information an reports Inquiry Screen ® Purpose ® Who can access it ® When to use ® How to use Information on Each Report Received by Supervisor or Service Worker ® Purpose e When does it come ® Who else gets it ® How to read it ® How to use it ® How long to retain it Installation Plan ® Future events and the timeframe e Conversion ® Tasks to complete in the agency e How to handle problems ® How to request assistance 175 176 Figure 3. Sample Training Plan for an Online Social Service Information System Training Events Time of Occurrence Duration (in order of occurrence) I. Overview and planning with the administrator beginning/Day One 2 days Il. Data entry training four weeks later 3 days Ill. Training service workers and supervisors on system and forms, with an overview of reports 60 days later 5 days —— ——— — ——— = [NSTALLATION == m= so ce o— ——— IV. Training administrators, supervisors, workers on use of management reports 6-12 months later 2 days Figure 4. Sample Set of Questions for Evaluating a Report LOCAL AGENCY MONTHLY STATISTICAL PROFILE - This is a statistical breakdown of all reports entered into the system for a given month and their disposition. Do you use the Local Agency Monthly Statistical Profile? 1 =yes 2 = no (if “no,” go on to the next section) Do you use the Profile for any/all of the following purposes? Please indicate for each purpose. 1 = always 2 = sometimes 3 =never 4 =N/A For reports to the community For reports to the local welfare board For reports to the local government For requests for additional staff Other (please identify): Do you find the Profile accurate? 1 =yes 2=no Do you find the Profile is clear and easy to use? 1 =yes 2 =no Do you find the organization of the Profile satisfactory? 1 =yes 2 = no (please comment) What should the frequency of the Profile be? 1 = monthly 2 = quarterly 3 = semiannually 4 = annually 5 = eliminate 6 = on request Do you think the data on the Profile should be combined with another report? 1 = yes (please comment) 2 =no Is there anything about the Profile which should be expanded, changed, or added? 1 = yes (please comment) 2 =no Comments: 177 ETE pe Se me wee worn TE rE Tea Ee SES : . : of . \ 4 : . Appendix C Utilization of Information* * Note: Some figures are modeled on those found in Shyne and Schroeder's National Study of Social Services to Children and Their Families (Rockville, Maryland: Westat, Inc., 1978). 179 Sa ge ET 2 i Cha Ir AGENCY PROFILE QUARTERLY REPORT DECEMBER, 1979 PROGRAM INFORMATION BOOK FOR FOSTER CARE 181 GENERAL INSTRUCTIONS In completing the charts and graphs in this booklet, you will need to make reference to the December, 1979, Regional Profile or the Regional Frequencies and Crosstabs. TITLE Age Sex Legal Basis for Custody Foster Care Program Goal Race or Ethnic Origin Judicial Review Length of Time in Custody Handicaps Service Category Profile of Children in Foster Care 182 REFERENCE Regional Profile Regional Frequencies and Crosstabs Regional Profile Regional Profile Regional Profile Regional Frequencies and Crosstabs Regional Profile Regional Profile Regional Frequencies and Crosstabs Regional Profile FOREWORD Who are the children receiving foster care services in your agency? How old are they? How many are boys? How many are girls? What is their legal basis for custody? What is their program goal? How many How many How long How many How many How many How many How many How many How many are black, white, and Oriental? are subject to judicial review? have they been in care? have handicaps? are emotionally disturbed? are mentally ill? are mentally retarded? have behavior problems? have learning disabilities? have physical disabilities? 183 CHILDREN IN FOSTER CARE AGE N = The Agency in December, 1979, had children in foster care. percent were under one year of age. percent were between one and five years old, percent were between six and nine years old, percent were between ten and 12 years old, percent were between 13 and 18, and percent were between 19 and 21. PERCENTAGES OF CHILDRENS' AGES \ 100% } 90x } 8oz | 702 } 60% } soz | 40% 307 } 20% } 10% % % Z % % % z Under 1-5 6-9 10-12 13-18 19-21 Over J \, 1 21 184 AGENCY SEX percent of the children were male and percent were female. PERCENT OF CHILDREN ever) FEMALE SEX OF CHILD © 185 100% 907% 807% 70% 60% 50% 407% 30% 20% 107% 0% 186 AGENCY LEGAL BASIS FOR CUSTODY N = Policy and legislation requires that there be a legal basis for taking a child into custody. The following table gives the categories for the legal basis of custody and the percentages of children in each category. rr LEGAL BASIS FOR CUSTODY 1 Z 2 a — Jo 33 3 10 wn & —< = z= =] -Q & _M % % % % 2 Z Abuse/ Child In Delinquency Entrustment Parents Cannot Neglect Need Of Agreement Requested Be Services To Be Determined Relieved Of Custody \- 1007 90% 80% 70% 60% 507% 407% 30% 20% 10% 0% AGENCY FOSTER CARE PROGRAM GOAL N = Of the children, percent had the goal of return to parent(s) or prior custodian(s), which is the highest ranking goal. percent had the goal of adoptive placement, percent had the goal of permanent foster care placement, percent had the goal of placement with relatives, percent had the goal of continued foster care, and percent were categorized as ''to be determined." ) PROGRAM GOAL Zz i] - a j= — x O Fx _ © wv 3 ~Z ei Z _ = Q 8 — A 3 7 % 7 7 1 % Return Adoptive Permanent Placement Continued To Be Home Placement Foster With Foster Determined Care Relatives Care PROGRAM GOAL 187 AGENCY RACE OR ETHNIC ORIGIN N = Black and white children made up percent of the population served. percent were black and percent white. The remaining were described as Oriental and "other." PERCENT OF CHILDREN SERVED BLACK WHITE ORIENTAL OTHER RACE OR ETHNIC ORIGIN J ( 188 707% 607% 50% 407% 30% AGENCY SUBJECT TO JUDICIAL REVIEW N = Of the children, to judicial review, judicial review, and percent were subject percent were not subject to percent were recorded as a PERCENTAGE OF CHILDREN SERVED "unknown." SUBJECT TO JUDICIAL REVIEW % % % Subject to Not Subject to Unknown Judicial Review Judicial Review 189 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 190 AGENCY LENGTH OF TIME IN CUSTODY N = Of the children, percent were in custody under one year, percent from one to two years, percent from three to four years, percent from five to six years, percent from seven to ten years, and percent more than ten years. a PERCENTAGE OF TIME LENGTH OF TIME IN CUSTODY 2 10 or More Yrs. 7-10 1002 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% I AGENCY HANDICAPS N = A child is considered to be handicapped if he/she have one or more of the following diagnosed handicaps: mental illness, emotional/behavioral disturbances, mental retardation, learning disability, or physical disability. Of the children, percent had emotional disturbances, percent had mental illness, percent had mental retardation, percent had behavioral disturbances, percent had learning disabilities, and percent had permanent disabilities. a HANDICAPS OF CHILDREN Z = = |] = Oo [2 © wn 8 I Ll Z S & = A % Z % 7 % x Emotionally Mentally Mentally Behavior Learning Physical Disturbed I11 Retarded Problem Disability Disability 191 192 HIGHLIGHTS OF FINDINGS The following information generally describes the foster care population in the Agency as of December, 1979. There were children in foster care in the agency. percent of the children were white, percent were black, percent were Oriental, percent were American Indian, and percent were categorized as other. The children's ages ranged from to years, with the largest number of children (____ 7%) being years or older. The predominate handicaps that many of the children had were . The program goal for the largest number ( %) of the children was . percent of the children were subject to judicial review, percent were not subject to judicial review, and percent were categorized unknown. The largest number of children (___ %) were in custody years. The largest number of children (7%) had as the legal basis for custody, percent of the children had and percent of the children had as the legal basis for custody. BRIEF PROFILE RACE White % Black % Oriental % American Indian % Other % 100 7 HANDICAPS Emotionally Disturbed Mentally Ill Mentally Retarded Behavior Problem Learning Disability Physical Disability 100% JUDICIAL REVIEW Subject to Judicial Review Not Subject to Judicial Review Unknown LEGAL BASIS FOR CUSTODY Abuse/Neglect Child in Need of Services Delinquency Entrustment Agreement Parents Requested to Be Relieved of Custody Cannot Be Determined BU. DQ 39 3 ae - GOVERNMENT PRINTING OFFICE: AGES Under 1 % 1-5 % 6 -9 % 10 - 12 % 13 - 18 % 19 - 21 % Over 21 % PROGRAM GOAL Return Home Adoptive Placement Permanent Foster Care Placement with Relatives Continued Foster Care To Be Determined LENGTH OF TIME IN CUSTODY Under 1 Year 1-2 3-4 5-6 7 - 10 10 or More Years 100 8 39 39 39 39 ee 100 38 39 3¢ 38 39 ee 1981-341-155/149 193 PROJECT SHARE THIRD-CLASS MAIL P. O. Box 2309 / POSTAGE & FEES PAI Rockville, Maryland HEW 20852 GERMANTOWN, MD PERMIT No. G45 HUMAN SERVICES — Monograph Series No.2 DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Assistant Secretary for Planning and Evaluation B6167 Project Share DHEW Publication No OS 76-130 U.C. BERKELEY LIBRARIES C028k93277