Procurement of Automated Child Support Enforcement Information Systems

PROGRAM INSTRUCTION

ACTION TRANSMITTAL

OCSE-AT-77-17

December 9, 1977

TO:STATE AGENCIES ADMINISTERING CHILD SUPPORT ENFORCEMENT PLANS APPROVED UNDER TITLE IV-D OF THE SOCIAL SECURITY ACT AND OTHER INTERESTED INDIVIDUALS

SUBJECT:Preparation of Requests for Proposals/Support Services for the Procurement of Automated Child Support Enforcement Information Systems

BACKGROUND:The attached guidelines were developed to assist State IV-D agencies in preparing requests for proposals (RFP's) to acquire automated child support enforcement information systems from contractors or from an in-house centralized ADP support organization of an umbrella agency. The intent of the guidelines is to familiarize State IV-D agency staff with the structure and content of an effective RFP which will then allow for the satisfactory execution of a contract with a vendor organization or a services agreement with an in-house support organization.

CONTENT:The first section of this document provides an overview of the acquisition process, thus providing the IV-D agency with a general picture of what actions should occur in the preparation of an effective RFP. The process is broken into three stages: the planning aspect for system development, contracting for services, and the activities which should be addressed in system development.

The second section further defines the material highlighted above into the basic components of the RFP, which include the framework of the requirement, proposal requirements, contract/in-house service requirements, and the Statement of Work. The Statement of Work is given particular attention, since it informs the contractor or in-house support staff of the project requirements, and serves as the IV-D agency's basic control over the performance. It presents all the specifics of the project, including background information, project objectives, specific work requirements, milestonesand deliverables, and documentation and performance standards.

Following the 20 pages of the main text are three appendices: Notes on Planning, Notes on Contracting, and Notes on System Development. This material has been included to provide the IV_D agency staff with a more complete reference for the planning, data processing, and contracting concepts involved in the preparation of RFP's. A review of this conceptual material should be helpful in gaining a better understanding of what actions need to take place to procure a IV-D system. It is particularly recommended that those who possess little knowledge of the activities normally associated with computer systems development projects carefully review Appendix C, "Notes on System Development."

We recommend the use of this document by all State and local IV-D agencies to help ensure that the IV-D system development project is effective and to facilitate FFP approval for data processing services by OCSE.

ATTACHMENT:"Guidelines and Standards to be Used in the Preparation of Requests for Proposals for the Procurement of Automated Child Support Enforcement Information Systems"

INQUIRIES TO:Regional Representatives, OCSE

Deputy Director

Office of Child Support Enforcement

GUIDELINES TO BE USED IN THE PREPARATION OF REQUESTS FOR PROPOSALS FOR THE PROCUREMENT OF AUTOMATED CHILD SUPPORT ENFORCEMENT INFORMATION SYSTEMS

ISSUED BY:

THE OFFICE OF CHILD SUPPORT ENFORCEMENT

PARENT LOCATOR SERVICE DIVISION

DECEMBER, 1977

TABLE OF CONTENTS

Page

I. INTRODUCTION 1

1. Expected Guideline Use 1

2. Guideline Structure and Contents 2

II. OVERVIEW OF THE ACQUISITION PROCESS 4

III. GUIDELINES FOR REQUESTS FOR PROPOSALS AND/OR SUPPORT

SERVICES 6

A. Components of a Request for Proposals/Support Services 6

B. Framework of the Request 7

1. Summary Description 7 2. Proposal Submittal Parameters 8

3. Type of Contract Anticipated 8

4. Performance Period 9

5. Estimates of Magnitude 9

C. Statement of Work 10

1. Background Information 10 2. Project Objectives 11

3. Specific Work Requirements 13

4. Milestones and Deliverables 14

5. Documentation and Operation Standards 15

D. Proposal Requirements 18

1. Technical Proposal Instructions 18

2. Business Proposal Instructions 19

3. Evaluation Criteria and Procedures 19

E. Contract Requirements 20

1. General and Special Provisions 20

2. The Schedule 20

3. Incorporations by Reference and Attachments 21

TABLE OF CONTENTS (Cont'd)

Page

APPENDIX A -- NOTES ON PLANNING A-1

1. Determining System Requirements A-1

2. Identifying Resource Alternatives A-2

3. Preparing a Project Plan A-2

APPENDIX B -- NOTES ON CONTRACTING B-1

1. The Presolicitation Process B-1

a. The Advance Procurement Plan B-1

b. The Work Statement B-2

c. The Purchase Request B-3

d. Sources to be Solicited B-4

e. The Request for Proposals B-5

2. The Solicitation Process B-5

3. The Contractor Selection Process B-6

a. Proposal Evaluation B-6

b. Negotiation B-7

c. Contract Execution B-7

4. Contract Management B-7

5. Contracting Approaches B-8

APPENDIX C -- NOTES ON SYSTEMS DEVELOPMENT C-1

1. Project Initiation C-2

2. System Design C-2

a. Requirements Analysis C-3

b. Cost-Benefit Analysis C-4

c. Conceptual/General/Functional Design C-4

d. Detail Design C-5

3. System Implementation C-6

a. Software and Procedure Development C-6

b. Testing C-7

c. Conversion C-8

d. Documentation C-8

e. Training C-9

TABLE OF CONTENTS (Cont'd)

4. Systems Operation C-10

a. System Production C-10

b. System Maintenance C-10

SECTION I

INTRODUCTION

1. INTRODUCTION

1. Expected Guideline Use

These guidelines are intended to assist State and local IV-D agencies in identifying their objectives for system development and the methodology to accomplish these objectives. A comprehensive range of material has been included to provide a broad understanding of both contracting and data processing requirements as they relate to the preparation of requests for proposals (RFP's) for soliciting contractor assistance or the preparation of requests for proposals (RFP's) for soliciting contractor assistance or the preparation of requests for proposals (RFP's) for soliciting contractor assistance or the preparation of plans, work statements, and service agreements when utilizing the in-house resources of a centralized data processing organization.

Child Support Enforcement program requirements are quite similar in that they include such functions as case management, parent location, accounts receivable, fund distribution, Federal and State reporting, and administrative accounting. Each IV-D program is unique because of State or local legislation, organization, agency structure and even the degree to which automation is required to support the program. It follows that each system is also unique. For this reason the material presented in the following sections should be adapted to individual program requirements.

It is expected that utilization of these guidelines will benefit both the OCSE and the State in the following areas:

OCSE

149RFP's submitted for review will be more uniform, which will

facilitate review and subsequent FFP approval;

149Problems of insufficiency and ambiguity will be reduced and

hopefully eliminated;

149Communication will be clearer and more direct using the guidelines as a basis of discussion; and of discussion; and

149Transfer of technology, ideas, etc. will be facilitated.

State Programs

149OCSE's RFP and work plan requirements will be understood;

149RFP's will be more clear and complete, and thereby yield better system development products;

149 RFP's can be developed more quickly and effectively;

149 OCSE's review can be performed more quickly and effectively; and

-2-

149IV-D Directors can gain a better understanding of the RFP and/or work statement process and input to it.

Note:Although throughout this document RFP's refer to contractor assistance, they can also be used to solicit proposals and service agreements from in-house data processing departments. An in-house data processing organization supporting IV-D should respond to the IV-D Director's data processing requirements in the same manner as a contractor.

2. Guideline Structure and Contents

The material contained in these guidelines has been organized into two major sections. The first section is a brief overview on acquiring an automated system. The second section, which is more detailed, spells out guidance on each of the key steps leading up to the actual start of system development. Appendices have also been included to reinforce the presentation in several areas. Appendices A, B, and C contain a far more detailed discussion of the various stages of the acquisition process, which is described in Section II. Specifically, the structure and content of these guidelines is as follows:

Section II, Overview of the Acquisition Process

Relative to IV-D information systems, the system development process consists of the separate functions of planning, contracting and data processing systems implementation. In this section, these three areas are discussed and described as they relate to the acquisition of a IV-D system. A broad understanding of these functions provides the proper perspective on which to base the development of the RFP for contractor assistance or work plan with an in-house centralized data processing organization. It is important for the IV-D Program Director and staff to have some knowledge of the fundamentals of contracting and system development as well as an understanding of the necessity of comprehensive project planning.

Section III, Guidelines for Requests for Proposal

This section further defines the material highlighted under Section II into the basic components of the RFP, which include the framework of the requirement, proposal requirements, contract/in-house service agreement requirements, and the Statement of Work. Subsections are included to describe each of these areas. While IV-D program staffs are directly responsible for the Statement of Work, they should understand the purpose and relationship of the other components of the RFP. The Statement of Work is the heart of any request for ADP services, and should be prepared under the direction of the IV-D program staff because they are responsible for the success of the program and they are in the best position to identify system objectives and overall project plans. Section III suggests items to be included in the Statement of Work, which are especially related to IV-D systems. Many of these suggested items come directly from actual RFP's submitted to the OCSE for review or from OCSE's recommendations concerning RFP development.

Appendix A - Notes on Planning

This material supplements Section II by providing a more detailed presentation of the role of planning in the acquisition of computer systems.

Appendix B - Notes on Contracting

This material supplements Section II by providing a detailed description of the many aspects of contracting relating to RFP preparation.

Appendix C - Notes on Systems Development

This material is presented to provide a more complete understanding of the various activities required for information systems development. While not all activities or development phases are required for each IV-D system, it is important to understand the overall life cycle of information systems.

SECTION II

OVERVIEW OF THE ACQUISITION PROCESS

-4--

II. OVERVIEW OF THE ACQUISITION PROCESS

This brief description of the acquisition process provides the general context for the preparation of a request for proposals for ADP services. Such a process would apply when soliciting contractor assistance or in-house data processing assistance. Detailed notes on the three stages of the acquisition process are provided in Appendices A through C. The appended material has been included to provide the IV-D agency staff with a more complete reference for the planning, data processing, and contracting concepts involved in the preparation of RFP's. A review of this conceptual material should be helpful in gaining a better understanding of what actions need to take place to procure a IV-D system. It is particularly recommended that those who possess little knowledge of the activities normally associated with computer systems development projects carefully review Appendix C, "Notes on Systems Development."

To acquire a new or modify an existing information system, the acquisition must be planned, the services must be secured, and the system must be developed. These three stages -- planning, service contracting, and systems development -- comprise the acquisition process. Specifically:

Planning is a prerequisite to the success of any system development project. Plan development should be a coordinated effort of program and ADP staff. Major steps in the planning stage include requirements determination, resource identification, and project plan preparation. See Appendix A for a detailed discussion on planning. The final plan must be approved by the IV-D Director.

Contracting for Services includes all activities leading to and facilitating the management of the contract(s) for services required for systems development, from the approved decision to contract through its completion. Major steps in the contracting stage include presolicitation, solicitation, contractor selection, and contract management. When using in-house resources, some of these stages are not applicable.

Systems Development includes all activities involved in the actual development of the information system(s), from the formalization of system requirements through its ongoing operation and maintenance. Major phases in systems development include requirements analysis, design, implementation and operation.

The request for proposals or support services is very important to the IV-D Director. It is far more than an invitation to propose; more accurately, it is the foundation upon which any contract or agreement and resultant system is built. Once issued, the request conditions the way in which proposals areprepared and subsequently evaluated and establishes the basis for contractor selection and contract award. For in-house support, the response to a request for services serves as the basis for negotiations between the IV-D agency and the data processing director.

SECTION III

GUIDELINES FOR REQUESTS FOR PROPOSALS

AND/OR SUPPORT SERVICES

III. GUIDELINES FOR REQUESTS FOR PROPOSALS/SUPPORT SERVICES

A well-prepared request for proposal or support services is the single most important step that can be taken by the IV-D agency to assure selection of the right contractor or in-house resources for systems development. An inadequately prepared request can substantially impede the timeliness and/or quality of the system being developed. The early investment of proper time and attention to prepare a sound request will yield significant returns on that investment thereafter. The importance of a sound request cannot be overemphasized.

The heart of the request is the Statement of Work which outlines the project requirements, IV-D functions requiring automation, and specific performance and method standards. The preparation of the Statement of Work must be carefully directed by the IV-D program staff to lay the groundwork for development of a well-designed system capable of supporting and improving their program. Because of the importance of the Statement of Work, a major part of these guidelines concerns its preparation, and a separate section (Ill-C) is included.

In preparing RFP's for contracting assistance, there must be early and close coordination with contracting agencies supporting the program. These guidelines should equip the IV-D agency with the necessary understanding of contracting, thereby enabling the IV-D agency to communicate with contracting staff. That is why these guidelines address all of the RFP components in their customary order of appearance.

A. Components of a Request for Proposals/Support Services

As system requirements and consequent developments all differ, so do requests for proposals or support services. Each request is and should be different, tailored appropriately to the unique requirements to be satisfied. Despite such expected content differences, any FFP must set forth a descriptive framework of the request, proposal requirements, and contract/in-house service agreement requirements as well as the statement of work.

The framework of the request highlights essential information about the requirement. It typically includes a summary description of the requirement, the performance period expected, any estimates of the magnitude of the effort envisioned, and the type of contract anticipated when using the services of a contractor.

Proposal requirements must provide all information needed to prepare a responsive proposal to a request. They typically included detailed instructions for preparation of a technical response, a business response, and a description of the criteriaand procedures to be used in proposal evaluation when soliciting from several vendors.

Contract requirements must provide all of the information one would expect to find in a resultant contract or in-house service agreement. They typically include general and special provisions that will provide the administrative framework, legal framework, the unique technical and managerial requirements for contract performance (the "Schedule"), and various incorporations, when appropriate, by reference or attachments.

B. Framework of the Request

The two major purposes of an RFP are to describe the requirements of services being solicited and the proposal to be submitted. A framework for such requirements should be provided at the outset. Its purposes are to summarize the request and highlight essential information warranting the immediate attention of prospective proposer(s). In essence, it serves as the introduction to and a synopsis of the requirement.

The framework can be presented in a transmittal letter or in whatever format the IV-D agency may choose to answer the following questions typically raised by a prospective proposer or data processing department:

149What are the services to be contracted (a summary description)?

149When and to whom should the proposal be submitted (proposal submittal parameters)?

149What will be the duration (performance period) of performance?

149What are the size and scope of the expected effort (estimates of magnitude)?

It is recommended that the following subsections be included:

1. Summary Description

2. Proposal Submittal Parameters

3. Type of Contract/Agreement Anticipated

4. Performance Period

5. Estimates of Magnitude

1. Summary Description

The summary description may be nothing more than the title of the requirement (e.g., "design, implementation, and operation of a Financial Accounting and Management System for the State Child Support Enforcement Program") or it may provide a brief narrative about the system organization and the specific services to becontracted.

Titles, once introduced, tend to endure. Care at the outset is encouraged. Narratives likewise should help the outsider capture the essence of the requirement without having to wade through the bulk of the RFP. Brevity and clarity are required.

2. Proposal Submittal Parameters

To facilitate "bid" or "no-bid" decisions by prospective vendors and to help plan for proposal preparation, certain submittal parameters should be presented.

Timing is one factor in proposal decisions. The time and date by which proposals must be submitted to the IV-D agency must be established in the RFP. Except in extraordinary circumstances, a minimum of 30 days from the request issuance should be permitted. Related provisions for handling proposals received after closing ("late proposals") should also be included.

In addition, prospective proposers must know to whom proposals should be submitted (by hand or through the mails) and through whom any other essential information concerning the proposal and its submittal (numbers of copies, required component parts, preproposal conferences, and the like) should be directed. The IV-D Director should be directly involved in making these decisions.

3. Type of Contract Anticipated

The pricing arrangement ("contract type") is an essential part of any contract negotiated as a result of the RFP. The contract type generally is prescribed by the agency, to permit comparable bases for evaluation, although alternatives may be invited or even requested. The contract type must be selected in conjunction with procurement staff and clearly stipulated in the RFP.

Under Federal procurement regulations, two families of contracts are described -- fixed price and cost reimbursement -- within which various "family members" are further delineated. Since numerous types exist, it is recommended that the agency refer to Federal, State, or local procurement regulations for detailed descriptions for each alternative type.

The pricing arrangement (contract type) prescribed or ultimately negotiated serves three basic functions. First, it governs the basis for payment, and the residual earning of profit or fee. Second it describes the extent of the contractor's risk, promise, and obligation to continue performance once initial funds are exhausted (in fixed price contracts, the contractor's risk is high, his promise is to deliver, and he obligation to continue until such delivery is provided is absolute; in cost reimbursement contracts, the contractor's risk is low, hispromise is to try, and he is obliged to continue after funds are exhausted only if supplementary funds are added). Third, the contract type implies the degree of agency direction or control expected and the relative administrative binders assumed (higher in cost reimbursement contracts).

Although the aforementioned contract provisions do not apply directly to in-house effort, it is still equally important to have a formal service agreement with the data processing organization. Such an agreement should spell out:

149 Identification of ADP services to be provided

149Schedule of charges for each service

149A statement that charges apply equally to all users

149A statement identifying the method of accounting for services rendered under the agreement.

4.Performance Period

The basic requirement of the schedule for performance should be highlighted, although it will be detailed in the Statement of Work. Of particular interest to prospective proposers are the duration of the contract and any phasing or options anticipated. The project duration may be described by a specific completion date or by a period of time after contract award. This prescribes the boundary within which resources must be available and services provided. This is true regardless of whether a contractor or in-house ADP department is providing the services.

Project phasing that may be contemplated describes the limits for increments of performance (e.g., design, then implementation, then operation). Options describe unilateral rights to extend performance beyond the initial period contracted. Either generally includes critical milestones for review and approval, and, in the aggregate, defines the total potential period of performance. Such information is critically important to prospective bidders and should be highlighted for immediate attention.

5. Estimates of Magnitude

Funds administratively reserved for a procurement normally will be based on the IV-D agency's best estimate. This estimate should be the result of the most realistic assessment of probable costs plus a fee or profit, if applicable, for the work described in the Statement of Work. Disclosure of the agency's estimate of the magnitude of the effort may be helpful in assuring a greater degree of technical competition and precluding wide variances in proposed costs. Such information may consist of the agency'sestimate of the level of effort (person-years or person-months) anticipated, or other reasonable indicators of the contemplated scale or magnitude of the services required. Such indicators may include available funding.

These measures should never be used as a substitute for effective descriptions of the effort. Indeed, a complete description of development goals and objectives may provide sufficient detail to promote effective technical and price competition without unduly restricting proposal creativity.

C. Statement of Work

The Statement of Work is the heart of a request for contractor or in-house services, since it informs either of the project requirements and it serves as the IV-D agency's basic control over the performance. In this section all of the specifics of the project are presented. Included are:

1. Background Information

2. Project Objectives

3. Specific Work Requirements

4. Milestones and Deliverables

5. Documentation and Performance Standards

1. Background Information

The background information frames the project, allowing prospective contractors or in-house data processing personnel to better understand not only the stated requirements but also the setting in which the system will be developed and operated. Attention must be given in the structuring of this material to provide a comprehensive picture of those things which have led to the existence of the request. Such a structure would include a discussion of the program, agency and program status.

a. The Program

This topic would briefly describe the Child Support Enforcement program at the Federal, State, and local levels, the functions of the IV-D program, who performs them, the legislative origins of the program, the relationship to other programs such as IV-A, and current legislation and regulations. This discussion need not be extremely detailed, but must be sufficient to answer the question, "What is the overall problem?" The agency should completely and concisely describe:

149 The basic purpose of the IV-D program

149The program itself - all elements, including: case management, parent locator, accounts receivable, fund distribution, Federal and State reporting, and administrative accounting

149Federal legislation/regulations

149 State legislation/regulations

149Relationship of IV-D to IV-A and other pertinent programs

149State and local relationships, responsibilities, etc.

b. The Agency

It is important to relate the IV-D agency to its organizational environment. This could include the relationship and function of the State umbrella agency, regional offices, counties, district offices, etc. Also,it should identify the other external organizations in the overall structure which participate in the execution of the Child Support Enforcement program, and describe the role and function of each, e.g., District Attorneys, Courts, Sheriff's Department, Probation Department, etc. Organizational charts supplemented with functional descriptions greatly simplify this presentation. This discussion should answer the question "Who are we and how do we operate?", and include:

149 The overall State organization

149The agency organization

149The agency's relationship to external organizations with IV-D responsibilities, such as judicial, financial, computer center, etc.

149The agency's constraints, including resources and workloads

c. Program Status

While the objective of the request may be to fully automate the agency's Child Support Enforcement program, some functions of the program may already be automated, or are better performed manually. Identify all IV-D functions presently being performed and provide a description of past and present problems and accomplishments. This information will aid the contractor/inhouse data processing department in identifying the current status of the program and therefore provide a better appreciation of the problem and objectives.

In summary, this status information should answer the question "What have we done so far?", and identify:

149The related IV-D functions currently being performed and how they are performed

149Past, present, and projected problems, achievements, and plans

2. Project Objectives

Having provided background material, the agency should then articulate objectives. Objectives are fundamental to successful systems development, because they provide the target at which to aim. Too often they are not included in the Statement of Work. Without specified goals, project activity cannot be controlled and project momentum can carry the project into undesirable areas. System objectives must be carefully developed and stated at a workable level of detail, answering the question "What do we want to do?". If they are not, a project can be nearing completion status with some very important aspects overlooked.

While the underlying project objective is to improve the State's ability to operate an effective and efficient IV-D program, specific objectives should be conveyed in programmatic and technical areas.

a. Programmatic Objectives

These objectives are program "mission" oriented and may include:

149 Improve Child Support Enforcement services

149 Improve operational efficiency and effectiveness

149Improve administrative control with reduced costs of operation

149Improve Federal/State/local communication, reporting, and interaction

149Reduce excessive and costly manual procedures and backlogs

149Ensure that funds are properly accounted for and accurately disbursed

b. Technical Objectives

These objectives are process or "mechanism" oriented and may include:

149Centralize or decentralize the recording and processing of collection and disbursement of all child support payments

149Provide adequate financial, management, and audit controls

149Eliminate redundant IV-D operations at the county level

149 Improve user access at all levels of IV-D operation

149 Improve uniformity and consistency of data

149Provide system backup, restart and security

149Provide for sufficient security/privacy safeguards

149Provide on-line input and/or inquiry of IV-D data

149Provide for match update/maintenance of IV-D master files

Anything that the IV-D agency believes to be critical to the mission of the program, and must be satisfied at the absolute minimum, must be stated in this section.

3. Specific Work Requirements

This section requires the above-stated objectives by further identifying what must be done to accomplish the project. This further definition of work requirements permits contractors or in-house support organizations to identify their plan for project accomplishment. Should staff directly assigned to the IV-D agency perform any of the tasks required to develop and implement a system, the results and products of these efforts must be provided in the RFP. If, for example, IV-D staff have already performed the requirements analysis phase of the project, it is important that the documented outcome of this task be presented in the RFP.

In Appendix C, "Notes on System Development," the various activities associated with computer systems development have been identified. In preparing the specific work requirement, those activities which are appropriate to the stated objectives should be included. Whenever possible these activities should be amplified and directed to specific IV-D agency requirements. The more detail provided in this section, the clearer the communication of the requirement to prospective contractor or in-house ADP unit. Not only will contractor's or data processing departments better understand these requirements, but they may see deficiencies and suggest improvements in their responses.

Just as important as the structuring and detailing of these specific requirements, is the planning and scheduling to accomplish them. A plan for project accomplishment with major task phasing is essential. There is a logicial progression for each specified requirement which leads to overall project accomplishment. While several requirements may be accomplished concurrently, the project schedule must structure these requirements into independent tasks or activities, which must be accomplished in a serial fashion. Subsequent tasks must not be initiated until the current activity has been successfully accomplished and signed off by the IV-D Director. The best way of measuring task accomplishments is through the identification of milestones and deliverables as requirements for each task. Again, for those unfamiliar with computer systems development, Appendix C, "Notes on System Development," will be helpful in drawing up task phasing.

This component of the Statement of Work must be detailed sufficiently enough to answer "What exactly do we want done and how do we expect it to be accomplished?". A general project plan should be provided which includes direct references to contracted milestones and deliverables. Specifically, this section should identify:

149 The required system development activities

149 Responsibility (contractor, agency, other) for both project activities and related functions

149 A logical and detailed project task plan which can be accomplished in a serial flow

149 Deliverables for each task, tied to the detailed contract/service agreement deliverable section

149 A review and approval period for each deliverable; while this period should be sufficient to allow a comprehensive review by the IV-D agency before subsequent tasks can be initiated,it must be structured so as not to unnecessarily disrupt project momentum

149 Complete requirements, including all levels of user training and all aspects of conversion and implementation

149 The detailed requirements associated with each desired IV-D function (i.e., case management, parent location, accounts receivable, etc.) to be addressed

149 A project plan which leads to the accomplishment of stated project objectives

4. Milestones and Deliverables

a. Milestones

A milestone is simply a significant event by which progress can be measured. For example, if a single tunnel connected Los Angeles to New York City, it would be difficult to measure progress along the way since no landmarks would exist. Whereas using the highway system, the various intersections, cities, mountains, etc., would represent milestones. Progress can be measured by reaching a milestone. Task accomplishment is a milestone. Examples of significant tasks that could serve as milestones include an analysis of requirements detail design of software and procedures, software and procedure development, and documentation of the system--all described in Appendix C, "Notes on Systems Development."

Such checkpoints must directly relate to the time-phased project plan, and must:

149 Be structured to allow sequential accomplishment of tasks

149Lead to the logical conclusion of the project

149Allow meaningful review and checkpointing of project progress.

b. Deliverables

How can one tell if a task is complete? Tangible evidence is an excellent indicator. Project tasks must be structured to have an end product which verifies accomplishment of the requirement. If the product is a major one and is critical to the start of subsequent tasks, it should be specified as a deliverable of the contract. Design specification, system documentation, program source code as well as the initial IV-D system requirements are examples of major deliverables. The IV-D Director should officially approve any document.

Project deliverables must be clearly identified and should directly relate to those specified in the project activity plan. Specifically, they must:

149Progressively lead to the final project deliverables

149 Represent commitments

149Specifically reflect task activity or indicate/verify task completion

149Include all developed software, which should be stated as belonging to the agency rather than the contractor.

149 Include all project documentation, reports and materials

149Include all manual procedures and management and user guides

5. Documentation and Operation Standards

The identification of documentation and operation standards is very important to the Statement of Work. They may take the form of either method standards or performance standards. Method standards represent the acceptable or specified approach to be used in accomplishment of some element of project activity, while performance standards set the constraints that must be satisfied by the resulting information system. For example, a performancestandard could specify that the information system must be written using only ANSI COBOL computer language and that program documentation must be present for each program. Related method standards could exist to describe the required COBOL coding conventions (i.e., structured techniques, use of language verbs and features,etc.) and specify the required format and content to be followed in developing program documentation. Technical standards should be made available by the data processing department. The IV-D Director should coordinate technical specifications with the data processing manager at the outset of the RFP preparation.

Most State and local IV-D agencies plan for systems to be operated on in-house computers. Maintenance and operation is usually to be done either by the umbrella agency data processing section or through an agreement with a support agency. Very often these organizations require systems they are running to be developed in accordance with their standards. Should such standards be applicable and documented, they should be referenced in the RFP and made available to proposers. In any event, the IV-D agency should work closely with data processing personnel to define this area.

Standards and constraints under which the project must be developed and operated must be clearly identified in the Statement of Work. These standards typically relate to and are a further detailing of the stated objectives of the project. This section must answer adequately the question "What format and content is expected for the deliverables, and what are the constraints that must be satisfied to indicate successful performance?". These standards and constraints are typically presented in two major categories -- documentation and operations.

a. Documentation Standards

These standards are typically presented as both method and performance requirements. In the performance operation, these may include:

149 Project plans

149 Analytical reports

149 Design reports

149 User manuals

149 Procedure flow charts

149 Test plans

149 Software listings

149 Progress reports

The method aspect of documentation standards involves the specification of how these documents are to be structured and formatted. Many common sources exist for these standards, and these requirements can be included by simply referencing this existing material. Possible sources include:

149 In-house computer center documentation standards

149OCSE documentation guidelines (when completed and published)

149U.S. Department of Commerce Federal Information Processing Standards (FIPS) publications

149 ADP text books

b. Operational Standards

Operational standards are not typically divided between those pertaining to performance and those pertaining to method in RFP's. These standards can be more effectively described by topical area with the performance aspect or methods aspect of a standard stressed as needed to reflect its importance. It is recommended that operational standards cover both technical and administrative areas.

Technical Standards

These standards should cover computer hardware and software requirements, and may also address performance limits. Examples are:

149 The specification of the computer system hardware/software on which the IV-D system must run

149the computer application programming language or software package that must be used to develop the IV-D system

149system design techniques to be used

149required system response time (very important for interactive systems)

149 limitations on computer resources

149acceptable failure rates

149privacy/security technical safeguards that must be in the IV-D system

Administrative Standards

These standards directly relate to expectations of project management. They may cover:

149 progress reporting

149time keeping and invoicing

149 team structuring

149 quality control

These standards should be primarily directed by the IV-D agency.

D. Proposal Requirements

To assure that all prospective proposers are on equal footing at the outset when soliciting contractual services and to provide the basis for proposal analysis and contractor selection thereafter, the RFP should provide explicit instructions for proposal preparation and describe the criteria and procedures for proposal evaluation. It is suggested that the subsections listed below be included in the proposal requirements:

1. Technical Proposal Instructions

2. Business Proposal Instructions

3. Evaluation Criteria and Procedures

Some agencies choose to conduct separate and, in some cases, sequential evaluations of the technical and business aspects of proposals. Others combine the two. To facilitate the process, separately bound and packaged technical and business information is required. Evaluation procedures, whether separate or combined, should be explained.

1. Technical Proposal Instructions

Tremendous variations in length, organization, detail, and, indeed, basic information can be expected in technical proposals unless instructions are provided in the RFP for preparing them. The nature of such instructions will dictate the types of proposals submitted and the ease with which subsequent technical evaluations will be conducted.

At a minimum, such instructions should include:

149 The numbers of copies to be submitted

149Any exhibits or listing to be provided (e.g., milestone charts, manloading tables, resumes, prior contracts, samples, and the like)

149Specific requirements for work plans, management controls, or other descriptions of how the work will be performed and managed

149Admonitions, if appropriate, for exclusions of certain information (e.g., costs) that should be provided elsewhere

149Any specific format or structure desired

What specifically is instructed is a function of agency preference. Too many instructions may provide a straight-jacket for creativity. Too few instructions may result in the need for straight-jackets for technical evaluators. A reasonable balance avoids either extreme.

A useful tool for both proposers and evaluators is to key the technical response to the evaluation criteria. In this way, proposers can determine the most critical information and relative emphasis desired and the evaluators can more easily find the information requiring evaluation.

2. Business Proposal Instructions

"Business" information generally required in proposals includes the following:

149 A summary and detailed breakdown of estimated costs

149Various representations or certifications that may be needed or desired

149Any financial or administrative data that may be used to demonstrate the proposer's responsibility (i.e., his financial and managerial capacity to perform)

149Such other information not appropriately placed in the technical proposal that describes the administrative side of the proposal (e.g., duration of the offer) or projected performance (e.g., location of the principal effort).

For subsequent evaluation purposes, the cost data are probably most critical. Instructions on the format for submission, the level of detail desired, the cost elements to be included or excluded, and, if appropriate, assumptions to be used for bidding purposes can be extremely helpful in promoting proposal comparability and in facilitating the evaluation and negotiation process.

3. Evaluation Criteria and Procedures

The agency should include in the RFP the criteria selected to evaluate and reconcile technical and business proposals, the relative importance or weighing of the criteria, and the procedures to be used in determining proposal acceptability, competitive ranges for negotiations, and ultimate contractor selection. Such disclosure will aid proposers in deciding to propose and in shaping their proposals, and will aid responsible agency officials in evaluation of proposals and selecting contractors in the most equitable fashion. The absence of or inattention to such critical information does disservice to both the proposers and the agency.

E. Contract Requirements

The remainder of the RFP, if properly structured, should provide the essential ingredients of the resulting contract. The contract requirements of the RFP should include the subsections listed below:

1. General and Special Provisions

2. The Schedule

3. Incorporation by Reference and Attachments

1. General and Special Provisions

Articles or clauses common to most contracts frequently are "institutionalized" and included as general provisos. Such provisions have little to do with the substance of the work to be performed. Rather, they provide the legal and administrative framework (i.e., the contractual environment) within which such services will be provided. Some provisions are mandated by law and must be included in all contracts. Others are tailored to particular types of contracts or types of procurements. Such provisions embody a comprehensive range of rights, obligations, and remedies of both contracting parties. Designations of appropriate provisions are best left to agency counsel and contract/procurement departments.

2. The Schedule

The "Schedule" of a contract contains all of the specific requirements for technical and managerial performance and such other terms and conditions that are unique to that particular procurement.

a. Technical Requirements

The Statement of Work describes all of the specific requirements for technical performance of the contract.

b. Managerial Requirements

Requirements for contract management not otherwiseincluded in the Statement of Work can be isolated in a separate section of the Schedule. Such requirements may include the following:

149 Reporting formats and schedules

149 Invoicing and payment procedures

149 Meetings or briefings expected

149 Acceptance procedures

Related organizational and staff roles and responsibilities may also be specified, and might include:

149 Designations of key personnel assigned

149 The contractor's project management responsibilities

149 Responsibilities and authorities of the contracting officer and his designated technical representative

149 Relationships between such parties and other agency groups or other contractors

c. Other Terms and Conditions

Any terms and conditions not already incorporated in the General and Special Provisions nor covered in the technical or managerial requirements of the Schedule can be collected for inclusion in the final portion of the Schedule. Such terms and conditions relating specifically to the individual procurement might include:

149 Limitations on certain types of expenditures

149 Advance agreements on the allowability of certain cost elements

149 Use or ownership rights to the products of performance`

149 Any other constraints or allowances that influence contract influence or administration

3. Incorporation by Reference and Attachments

Items not conveniently included in the Schedule of the contract (and RFP) can be incorporated by reference and simply attached. Incorporations by reference in the RFP (and resultant contract) might include pertinent laws or regulations, agency manuals or standards, and such other documents too bulky or readily available to warrant attachment.

APPENDIX A

NOTES ON PLANNING

APPENDIX A

NOTES ON PLANNING

Contracts are not secured or managed nor systems developed effectively without proper planning. Planning should both precede and continue throughout the contracting and development stages. Notes on the major steps of planning follow.

1. Determining System Requirements

All system acquisitions start with a requirement. Probably the most important and most neglected step in the acquisition process and its planning stage is the determination of that requirement. Requirements determination necessarily involves definition of the problem, identification of user needs, and assignment of priorities to such problems and needs. Responsibility for articulating requirements should be vested with the IV-D agency. It stands to reason that program staff are in the best position to know and understand their requirements.

Problem definition starts with an examination of agency objectives and long-range plans. Against that backdrop, current processes, procedures, and systems can be evaluated for sufficiency and responsiveness in supporting such objectives and plans. Deficiencies can then be identified from an overall agency perspective as problems to be resolved or, more positively, challenges to be confronted through new or enhanced information systems.

Needs identification involves a similar analysis, but from the more specific perspective of individual users of such systems. Such user needs uniquely result from managerial and programmatic responsibilities and viewpoints. If those needs and their differences are not surfaced initially and if the user groups at all levels are not involved actively in their identification, then the odds for ultimate system effectiveness are substantially reduced. User participation at State and local levels from the outset and continually thereafter cannot be overemphasized. Therefore, if the system objective is to centralize accounts receivable under a locally administered program, heavy involvement from the outset by local IV-D staff is essential.

With problems defined and user needs identified, priorities should be established. Aggregate information requirements should be analyzed, validated, and ranked. The product of such activity would be a statement of management and program information requirements, in priority order, to be served by the system development.

The requirements statement, at a minimum, should distinguish between needs and wants, mandatory and desired capabilities,current and future needs, and feasible versus unrealistic system performance. As such, it serves as a benchmark for examining resource alternatives and subsequent project planning.

2. Identifying Resource Alternatives

Each system requirement can be converted into specific development tasks, for which, in turn, resource needs can then be identified. Such resources include people (skill levels and numbers), computer hardware and software, other logistical arrangements, and, resultantly, money.

To support decisions concerning in-house development versus contracting, the resource inventory should identify and compare available resources required for system development. Such comparisons not only will permit evaluation of development alternatives, but will help identify potential contractor resource requirements, should a contracting alternative be chosen.

Alternatives to a completely new system might include modification or redesign of existing systems (if any) by internal or another agency's personnel, adoption of all or part of another agency's system, or acquisition of a commercially available system. Such alternatives as acquiring contractor services or using State resources, or some combined approach will depend on analyses of available resources, time constraints, and cost implications.

Once alternatives have been identified and analyzed, a project plan can be prepared.

3. Preparing a Project Plan

Regardless of the alternative selected for system development (internal, other agency, contract, or some combination), the development effort can be usefully considered a project (or series of projects) and a project plan should be prepared, accordingly. The project plan serves three purposes. First, it documents the analyses of requirements and resource alternatives and reflects the agreements reached among the participating agency components (including, importantly, the user groups). Second, it serves as the vehicle for obtaining project review and approval from top-level agency management after approval by the IV-D Director. Third, and assuming its approval, it provides a roadmap for the contracting stage (if a contracting alternative is selected) and a benchmark for the initial phase of system development.

The project plan should detail system and processing requirements, estimate resources, describe system constraints and cost-benefit expectation, and outline the tasks to be performed during the appropriate phases of system development. Additionally, for services to be contracted, it should serve as an advance procurement plan, prescribing the steps to be taken in the contracting stage, assigning responsibilities and milestones, and setting forth such other parameters and schedules as may benecessary to assure that the contract and the resultant services are responsive to the IV-D agency's needs. Notes on contracting follow.

APPENDIX B

NOTES ON CONTRACTING

APPENDIX B

NOTES ON CONTRACTING

The objective of contracting is to acquire through a contractor the necessary services of the desired quality, in a timely manner, and at fair and reasonable prices. Meeting that objective requires certain processes before, at, and after contract award. Contracting, therefore, comprises such processes -- presolicitation, solicitation, contractor selection, and contract management. The contract itself simply represents a legally enforceable agreement between two competent parties to do or not to do something (not otherwise prohibited by law) for a legal consideration (the seller receiving payment and the buyer receiving services). The contracting processes include all steps taken by both parties from the decision to contract through its award and to its ultimate completion. Notes on each of these processes follow, with emphasis placed on presolicitation, wherein the request for proposals is prepared.

1. The Presolicitation Process

Presolicitations begin with the decision to contract and ends with completion and approval of a request for proposals. As noted in the preceding section on acquisition planning, a project plan should have been prepared to describe the work to be performed (a work statement), facilitate the decision to contract, and provide a roadmap for the contracting stage (an advance procurement plan). If such a project plan has been properly prepared, the foundation for the presolicitation process has already been constructed. Otherwise, two indispensable documents must be developed: an advance procurement plan and a work statement. Based on these documents, a purchase request can be prepared, potential sources can be identified and listed, and a request for proposals can be developed. Each of these steps in the presolicitation process are summarized below.

a. The Advance Procurement Plan

An advance procurement plan is a roadmap for accomplishing an individual procurement. It is the summation of all the significant procurement management decisions that must be made prior to the contract award. The IV-D Director should coordinate the procurement plan with Contracts and Procurements Department supporting the IV-D program.

In a descriptive sense, the procurement plan identifies the

requirement and its relation to the program of which it is a part, the method of procurement (formal advertising or negotiation), the type of contract contemplated (within the fixed price or cost reimbursement families of pricing arrangements), potential sources or methods of identifying such sources, delivery or performance schedules, and pointsof procurement responsibility within the contracting components of the agency. In a scheduling sense, the procurement plan establishes milestones for each significant event leading to contract award. In presolicitation, milestones might include completion of the work statement, identification of prequalification evaluation of potential sources, issuance of a purchase request, preparation of the request for proposals, and completion of presolicitation approvals. In solicitation, milestones would include issuance of the requests for proposals and receipt of proposals. And in contractor selection, milestones might include completion of technical and business evaluations , conduct of negotiations , completion of precontract approvals, and contract award.

The greatest possible benefits are obtained when procurement planning covers the entire period from the inception of the requirement to award of a contract. Since the basic planning inputs are generated by the IV-D agency, typically, procurement planning must originate with agency personnel, However, it is the contracting officer's responsibility thereafter to provide the direction necessary to assure that the planning effort actually produces the desired results.

The effectiveness of the contracting activity is greatest and the interests of the program organization, are best served if procurement planning is initiated before purchase requests are prepared. Thereafter, planning must continue, with appropriate revisions as circumstances dictate, until the contract is awarded.

b. The Work Statement

The work statement is the backbone of any procurement. Its

clarity and completeness will determine to a large extent the ease with which proposals are evaluated and the contract awarded and then completed.

Simply put, the work statement describes the objectives of the procurement and its performance requirements. As the controlling device of any procurement, the work statement should be sufficiently specific to protect the agency's interests, yet broad enough to encourage a contractor's creativity.

Beyond its ultimate role in directing the contractor's effort, the work statement serves a number of critical purposes:

149It will affect the number of qualified sources willing and able to respond. If too broad, the risks may be perceived to be too great. And if too narrow, over-direction may be suspected, thereby stifling creativity.

149It will affect the type of contract that will tie written (fixed price or cost reimbursement), and thus the manner in which the work will be directed by the agency and implemented by the contractor.

149It will influence greatly the evaluation of proposals, since proposed approaches will be affected and evaluations must be based on the statement requirement.

149 It will affect contract administration, since it

defines the scope of work -- what the contractor does

and how the agency directs -- and, thus, the relations

between the contracting parties.

Guidelines for preparing the statement of work are provided in Section III-C.

c. The Purchase Request

The purchase request is the document prepared by the IV-agency which formally asks the contracting officer to initiate procurement action. Informal discussions between program and contracting personnel as the purchase request is being prepared will not only help assure the sufficiency of the document for procurement purposes, but will also help the contracting officer grasp the technical nature of the project. The contracting officer must understand the essence of the requirement and its underlying rationale to be able to accept the request for procurement action and successfully conduct solicitation and negotiations thereafter.

The purchase request provides the blueprint for the request for proposals. In addition to the work statement, it should provide the following:

149The estimated cost of the proposed work. Such estimates provide the initial basis for the administrative reservation of funds for the procurement and the subsequent framework for cost or price analyses of proposals submitted thereafter.

149The period of performance. The stipulated performance period must be sufficiently reasonable to promote maximum completion and realistically scheduled to provide adequate lead time for procurement and performance.

149Special formats or information desired in the technical or business proposals. Failure to describe the scope and formats desired may create needless delays and extra administrative delays during the contractor selection process.

149Criteria and their relative importance for evaluating the technical and business proposals. Such factors and weighings will help provide proposers with a common understanding of the requirement and the method of evaluation and will permit a fair and equitable comparison of the proposals received.

149Reports and other documentation required. The type, content, and frequency of reports needed to monitor technical and financial progress should be specified. And, since the products of performance in systems development are frequently written (a requirements analysis or flow charts or software programs), documentation requirements and standards should be identified.

149Other requirements that uniquely describe the proposal or performance requirements.

Once the purchase request is submitted, potential sources can be identified and a request for proposals can be developed.

d. Sources to be Solicited

Competition generally is valued in procurements to assure that qualified sources unknown to the IV-D agency have opportunity to propose a variety of technical approaches are surfaced, and fair and reasonable prices for the effort are established. As a general rule, unrestricted competition should be encouraged ,unless restrictions are justified on the basis of timing of the requirements, unusual technical competencies or previous experiences needed, or other unique circumstances of the procurement which legitimately limit potential sources to a few organizations or even a single prospective contractor. Any limitation of potential sources must be completely justified. Federal procurement standards require fair and open competition.

Potential contractors, may be identified from source files already, maintained by either the IV-D or contracting agency, or through advance notice of solicitation. Indeed, if time permits, the qualifications of prospective sources can be sought and evaluated prior to release of the request for proposals to assure that only qualified organizations subsequently propose. Such prequalifications procedures can save considerable time and talent of both the agency and prospective contractors that otherwise might be wasted in either preparing or evaluating proposals that clearly should not be considered for potential award.

The exact number of sources which should be solicited, for a procurement is a collective and sometimes subjective judgement of the contracting and program personnel. Thefinal number should be determined by evaluating the estimated dollar value of the procurement, the time allotted for performance, the estimated costs of proposal preparation and evaluation, and its relative importance to the agency.

e. Request for Proposals

A request for should provide contractors with all of the information they need to prepare proposals that are

complete and responsive to agency requirements. As such, the request for proposal is the culmination of the presolicitation process and provides the foundation for the solicitation and contract selection process and, indeed, the management of the contract, thereafter.

2. The Solicitation Process

The solicitation process begins with the issuance of the request for proposals and the ends with submission of the proposals. During this period, the most constructive contribution that can be made by the soliciting agency is to assure that any communications with prospective contractors be handled in such a manner that all proposers are treated equally and without competitive advantage. Occasions may arise where such communications become necessary and bear noting, accordingly.

A preproposal briefing or conference may be useful to promote uniform interpretation or clarification of work statements and proposal requirements. It can be used to encourage contractor interest, increase understanding of the request for proposals, and, consequently, facilitate the contractor selection process. Proposal conferences or briefings, attended by all interested proposers, are particularly appropriate to amplify or otherwise supplement information provided in the request for proposals and to provide an opportunity to such proposers to ask questions, the answers to which can be heard by all.

Whether as a result of a presolicitation conference or briefing or through any other occasions that may arise during the solicitation period, the request for proposal may need to be amended. Such amendment may be required to:

149Correct or clarify significant ambiguities, mistakes, or omissions uncovered

149Make material changes to the specifications, terms, or conditions

149Share with all organizations solicited the answers to questions posed any potential contractor, in any circumstances where nondisclosure might give the requestor a competitive advantage.

Written amendments should be cleared by the IV-D Director.

Any other communication, during the solicitation and the contractor selection process, are governed by the same principle: once prospective sources have been solicited, all must be provided with identical information and no action may be taken that might afford one organization any advantage over the others. To assure that equal opportunity is preserved, a contact point normally is established (generally the contracting officer) through which any communications are channeled. In this way, unfair disclosures and the integrity of the procurement process can be maintained.

3. The Contractor Selection Process

The contractor selection process begins with receipt of the proposals and ends with award of a contract or contracts. Although the specific steps may vary, the selection process generally involves proposal evaluation, negotiation, and contract execution. Brief notes on each follow.

a. Proposal Evaluation

Once the closing date for proposal submission has passed, the proposals received must be evaluated from both a technical and business perspective. The framework for evaluation -- that is, the evaluation criteria and their relative importance -- should have been clearly established in the request for proposals and responsibilities within the IV-D agency for conducting the evaluation already should have been assigned. At a minimum, the IV-D agency should have at least fifty (50) percent representation on evaluation panels.

Technical evaluations generally focus on two major considerations: who the proposer is and how he intends to perform. The former considers the relevant experience of the proposing organization and the qualifications of proposed personnel. The latter considers the proposer's understanding of the requirement and his consequent technical approach. Proposals are thus technically evaluated in accordance with a predetermined evaluation plan, rankings are determined accordingly, and those exceeding certain thresholds may be considered further for possible award.

Business evaluations generally center on analyses of proposed costs or prices and on the responsibility of the proposing organization. Cost or price analysis involves examination of the reasonableness of the cost estimated and the fee proposed for the quality and magnitude of the technical performance intended. Responsibility determinations require appraisal of the financial, managerial and administrative capacity to so perform. Costor price analyses may be confined only to those proposals considered technically acceptable or within competitive range of technical acceptability. Responsibility determinations may be deferred until the prospective contractor has been selected. Regardless, business evaluations, as with technical evaluations, should be conducted in accordance with a predetermined evaluation plan.

b. Negotiation

Under standard procurement regulations, negotiations generally are conducted with all firms whose proposals have been determined to be within a competitive range. That range and the selection of firms for negotiation requires reconciliation of the technical and business evaluations. Although no generalized guidelines can be offered for such determinations, suffice to note that the selection must be justified and should be based on criteria established during the presolicitation process.

During negotiations, the firm or firms may be:

149 Invited for written or oral discussions

149Required to provide additional technical information to clarify their proposal and to obtain assurances of the accuracy of representations made

149Requested to submit proposal revisions by specified dates, as supplemental or "best and final" offers.

The confidential nature of information submitted by a proposer must be respected and preserved, lest competitive advantage be inadvertently provided, and effective competition be destroyed. Therefore, the same communication safeguards maintained during the solicitation process extend to contractor selection.

c. Contract Execution

The basis for contractor selection is the best buy for the IV-D agency -- price, technical, and other factors considered. Again, establishment of such factors and their relative importance in the presolicitation process will help guide the evaluations and negotiations and facilitate the final tradeoffs and ultimate selection made.

Once the successful proposer has been selected and his responsibility determined, the contract is prepared andsubsequently signed by both parties. As such, it contains all agreements of the parties and serves as the sole basis for contract performance and administration.

4. Contract Management

Contract performance begins when a binding contract has been signed and ends with acceptance of all required contract deliverables. Contract administration extends throughout the performance period and ends with final payment and closeout of the contract. The IV-D Director must exercise some authority over and have final sign-off on all contract deliverables.

The individual rights and obligations of both parties for performance and administration are clearly established by the contract. A contract partnership, in a sense, also exists when considering that the actions of one party will condition the others's ability to fulfill his responsibilities. Planning is needed before and during performance to integrate the actions of both.

The agency's responsibility;y for many of such actions makes it an active participant in contract performance. Delays or omissions in performing review, giving approvals or disapprovals, or furnishing required information may influence greatly the contractor's fulfillment of related performance obligations. Likewise, conflicting direction from multiple parties can only create problems.

Administration of the contract, by IV-D agency personnel covers a broad range of administrative tasks, from evaluation of progress through payments and approvals to contract modification, as appropriate, and ultimate closeout. Most administrative functions and duties derive from general or special provisions of the contract. They should be anticipated and expressly included in the contract.

5 Contracting Approaches

In the description of the systems development process presented in Appendix C, twelve activities have been identified. While there is a logical progression to the accomplishment of these activities, there exist many philosophies as to how to contract the entire development effort. A single contractor may accomplish all or only some of these activities, or a split of these activities among in-house staff, contractor or multiple contractors is possible. Unfortunately, there is no universal "best" approach. Logical division points exist at the completion

of the following phases/activities:

149 Project initiation

149 System design; conceptual/general and detail products

149 System implementation

149System operation, sometimes between system production, and system maintenance

A single contractor can completely develop the entire system under a single contract, or a separate contract can be let for each phase or activity. Where separate contracts are used, often the winning tractor is precluded from bidding on the following system development phases. While this contracting approach virtually ensures completion of one phase before initiation of subsequent phases, it is sometimes costly in terms of the orientation of the new contractor staffs.

While there is no universal "best" approach, there is a key to projects success, which is project control. The IV-D agency and its contracting agency must choose the approach which best assures project control while it facilitates, not impedes, systems development.

APPENDIX C

NOTES ON SYSTEM DEVELOPMENT

APPENDIX C

NOTES ON SYSTEM DEVELOPMENT

While the actual development process may be unique for each IV-D automated information system, each system must evolve through the same general activity phases during its life. Simply stated, these activities are:

149 Problem identification

149 Requirement analysis

149 Cost-benefit analysis

149 Conceptual/general/functional design

149 Detail design

149 Software and procedure development

149 Testing

149 Conversion

149 Documentation

149 Training

149 Production

149 Maintenance

Many naming variations exist to describe these activities, but the names themselves are not significant. It is of far greater concern to understand that separate, definable activities exist and there is a logical order for their accomplishment. While these activities overlap during the development process, each has a fixed set of sub-activities that must be planned, controlled and accomplished, and each typically has two products: the accomplishment of the activity itself and a document which describes that accomplishment. Development plans should require this documentation to be the foundation on which subsequent activities are based. This approach is especially critical if different personnel are involved in the various activities. It is important that IV-D Directors and staff, as a matter of course, review and sign off all documents output during the system development. It is extremely critical that they concur with the resultant products of the requirements analysis and conceptual and detail design. For after these phases are completed, changes to the design are costly and can only result in confusion.

Conceptually, a IV-D system's overall life cycle can be viewed as consisting of four major phases: project initiation, design, implementation, and operation. For presentation purposes this framework is used to describe the relationship of the twelve activities listed above as well as the documentation associated with each of these activities.

1.Project Initiation

The project initiation phase consists of identifying the initial problem, outlining and evaluating alternative solutions and selecting the superior solution to use as a basis for formulating a project plan. This phase begins when the IV-D staff recognizesprocessing problems that might be solved by an automated system and ends when they are satisfied that a solution of merit has been proposed that warrants proceeding to the design of a system.

The IV-D agency must be heavily involved at this stage and be at a point of control.

The programmatic analytical activity of this initial phase is critically important in the determination of whether or not and in which direction to pursue the project. The problem identification and feasibility studies need to be documented for use in this analysis and any future planning. The problem identification should be thorough, including such information as:

149 Factors giving rise to the study

149 Existing "state" of the requesting organization

149 Scope of the problem, including:

-- Organizations involved (direct, interfaces)

-- Policy and legislative needs

-- Processing functions included

-- Constraints (environmental, time, cost, etc.)

-- Ultimate users of results

149 Objectives, including:

-- Purposes to be served

-- Products which satisfy the purposes

-- Requirements giving rise to products

-- Constraints on processing and reporting requirements (when, where, how)

-- Special considerations (security, etc.)

149 Problems discovered in existing processes, such as:

-- Data or product content

-- Accuracy of data or products

-- Process input problems

-- New functions imposed

-- Product output problems

The expected value of any proposed alternative for automating the IV-D operation shall be evaluated in terms of:

149 Existing systems or manual processes

149 Alternative solutions

149 Technical feasibility

149 Economic feasibility

149 Operational feasibility

149 Other projects competing for the same resources

This preparatory material and the results of the project initiation analysis should be captured in a project plan document. The project plan provides a justification and general direction for the design of a system.

2.System Design

The system design phase consists of analytical and designactivities necessary to refine system development plans to the point at which system processing methods are fully outlined to meet specific user needs and programmers can begin writing computer instructions (software).

This phase begins when the IV-D staff and computer system development team start to define what an automated IV-D system should do and ends when the IV-D staff is satisfied that the system design, as documented by the computer systems team, meets their needs.

Although the computer systems people will be heavily involved in this phase of development, it is critical for the IV-D staff to participate in planning and evaluating proposed system processing. An open dialogue on a day-to-day basis between the computer system developers and the IV-D staff during this phase will greatly improve the chances of developing a useful, efficient IV-D system, particularly by revealing ambiguities in system objectives, conflicts between the proposed system design and the IV-D staff's view of what the system should do, and requirements previously undefined.

The following activities must be accomplished in this phase: requirements analysis, cost-benefit analysis, conceptual system design, and detailed system specifications. The activities to be included in these steps are described below.

a.Requirements Analysis

Using the problem identification documented during the initiation

phase, the need for improvement must be translated into schemes for automating work processes. A IV-D system has many potential users at the State and local levels -- program, financial, ADP, legal staffs, etc. All potential users at all levels supported by the system should be included in a survey to determine what the system should do,and their various needs should be coordinated in the evolving schemes.

An analysis of requirements includes a determination by level and function of:

149 Functions and activities performed

149 Organizational responsibilities

149 Users of the products generated

149 Information flow including sources and types

149 Processes existing, manual or automated

149 Deficiencies noted in

-- Content (creation, retrieval, storage)

-- Accuracy

-- Timeliness

149 Difficulties existing in system inputs, outputs, and processing

It sets the stage for computer systems planners to developalternative approaches to meet the requirements.

Both the requirements of a IV-D system and alternative plans for computer software development must be documented in clear, non-technical terms. Before proceeding further, the IV-D staff must be confident of the basis of this documentation and the technical developers must fully understand the scope and functions required of the IV-D system.

b.Cost-Benefit Analysis

Upon approval of the requirements analysis document by the IV-D staff, a cost-benefit analysis is performed to select the most cost-beneficial of the alternative approaches, if any. There are three steps to this analysis:

149 Identification of all costs to implement and operate each system

149 Identification of all economic and other benefits resulting from the implementation of each system

149 Development of a method of weighing the costs and benefits to obtain a cost-benefit relationship

Investigating comparable existing systems in use by other jurisdictions can be helpful in arriving at the best estimate of cost and in anticipating weak areas in the design alternatives. In many cases, financial benefits may not be placed on each end-product and on the timeliness and accuracy before one alternative can be selected over another. The cost-benefit relationships may be based on: a purely economic benefit to cost ratio, a return on investment calculation, or a subjective assessment of the non-financial benefits with a resultant relationship. From this analysis the "best" system is selected.

c.Conceptual/General/Functional Design

In this step an overall blueprint for the development of the selected computer system is drawn up. With the problem identification, requirements, and cost-benefit analysis materials as a basis, the proposed system should be defined in terms of the environment in which it will operate and how its processing flow will handle all requirements of the various IV-D organizational components, i.e., case management, parent location, accounts receivable, fund distribution. This description of the functions performed by the system needs to include:

149 System description

-- Processes

-- Inputs and outputs

-- Control routines

-- Logical dependencies for record keeping, i.e., relating absent parents to children and, further, to the AFDC unit

-- Processing methods

-- Processing specifications

149 Summary of costs and benefits

149 Alternatives considered

149 Immediate and future impact of the system

-- Time and manpower requirements

-- Integration and/or phaseout of existing systems

Obviously, again at this step it is critical for the IV-D staff to carefully review and evaluate this general design plan developed by the computer development team before proceeding to the detail planning. Additionally, it should be understood that it may be necessary or desirable at this stage to proceed with the development and implementation of only part of the proposed system before a decision is reached to develop all of the system.

d.Detail Design

Using the approved conceptual system design as a base, the system is progressively refined to the technical detail necessary for the software and procedure development activities. This design effort should be expended in the following areas:

149 Data Storage Specifications

This step includes the analysis of data elements and the development of file structures. It includes:

-- Identification of required data elements

-- Analysis of data element characteristics

-- Classification of data elements by type, function, and relationship

-- Classification of data elements by specific requirements

-- File and record organization

-- Preparation of data element descriptions

-- File specification preparation

149 System Input Specification

This involves the following steps:

-- Identification of automated and manual inputs

-- Description of input functions

-- Formatting of input

149 System Output Specifications

This step includes:

-- Identification of system outputs

-- Description of system outputs

-- Preparation of report layout sheets

149 System Processing Requirements

This includes processing necessary to satisfy the requirements and includes:

-- Run time

-- Run frequency

-- Relationships

-- Equipment requirements

-- Special constraints (security, privacy, etc.)

The documentation of the detail system design is very important and will remain a permanent description of the process. It should include the following items:

149 General description

-- Purpose and functions of major processes (programs)

-- Files maintained and affected

-- Input and output requirements

-- Interfaces to other systems

149 Master system flow chart

149 Data element dictionary

149 Subsystem flow charts showing data flow and relationship to the processing functions

149 Function descriptions

-- Performance characteristics and limitations

-- Inputs and sources

-- Outputs and report layouts

-- Interfaces with other subsystems

-- Data base and logical files

-- Processing algorithms

149 Identification of general resource requirements

149 Program descriptions

-- Program identification

-- Input and output requirements

-- Detailed processing functions

-- Major decision rules

-- Specific environmental or processing constraints or requirements

3.System Implementation

This phase involves the actual accomplishment and testing of the specified software and procedures, as well as the conversion of existing data. Also included in this phase is the finalization of all system documentation and the training of all levels of system users. It begins when the computer development team starts writing the computer instructions (software) and ends when the IV-D staff is able to satisfactorily utilize the system for its program functions as specified in the design. These activities typically include the following:

a.Software and Procedure Development

This activity is actually the fulfillment of the previous design activities. With the detail system design providing the framework, thisactivity involves simply the coding and documenting of the specified procedures into computer programs. Only relatively minor design considerations should surface, which typically relate to minor processing decision points and detailed software interfacing specifications.

Directly related to the software coding activity is the completion of individual program documentation and the program-level testing and check-out. Program specifications are adjusted and detailed as appropriate to form program documentation. In addition to these software related efforts, manual and operational procedures should be established and documented at this time. (See Section d, "Documentation.")

b.Testing

A major aspect of this activity is the preparation of a test plan covering the use, operation and maintenance of the system. This plan should include written procedures for all operational aspects of the system, including the manner in which programs and their associated operational procedures will be integrated into the job streams developed in the design activities. The test plan should include the test criteria to be used and a specific description of how the tests will be conducted. The test plan will insure that the following criteria will be met:

149 Adherence to approved system and program design specifications and capabilities

149 Adherence to user operating conventions and standards

The test plan must specify the documentation to be prepared during system testing to show procedures and the results obtained. While the initial test data will be prepared during the programming activity in conjunction with developing and testing the programs, additional test data required for module, unit or system testing will be prepared during this activity. A variety of data should be fed into the system for appropriate evaluation in terms of acceptance or rejection. Default options must be tested for operability. Each output report must be run to test functional reporting capabilities. All outputs from the test runs should be correlated to the specifications to determine acceptability of the programs, and if the results differ, a closer analysis of automated outputs must be made. The test data must be comprehensive enough to form a basis for generating various information in output reports and file maintenance runs.

Additionally, other aspects of the system should also be tested in a comprehensive manner to insure operability. Typically these items include:

149 Source documentation preparation and associated controls

149 Source data entry procedures

149 Editing and verification of data entry

149 Data entry controls

149 File maintenance and retrieval functions

149 Terminal ad hoc retrievals

149 Output reports

149 System security features

c.Conversion

This activity shall include establishing the initial IV-D data base and converting the data and users from existing procedures to the new system procedures. This last aspect typically involves the modification of existing information and/or systems and the creation of one-time interface mechanisms to these related systems.

d.Documentation

Documentation is not a self-contained activity, but rather an integral part of the work to be done in each step of the development phases. However, at this time in the system development, the documentation needs to be finalized into polished manuals that can serve all personnel having contact with the IV-D system -- IV-D program and financial managers and staff, and legal/judicial staffs, data entry/clerical personnel, ADP managers, computer operations personnel, and computer programmers.

Although the preparation methods and organization of documentation may vary, they should be selected to provide documentation that is:

149 visible

149 useable

149 flexible

149 maintainable

It is strongly recommended that the various sections of documentation be written on a stand-alone basis, so that the documentation can be assembled into a variety of packages, each containing only sections relevant to a particular type of user. Wherever possible, documentation should be prepared on a word-processing, mag-storage-type machine or computerized text editing system to assure ease in updating and elimination of duplicate effort.

The IV-D system documentation should, at a minimum, contain the following forms of documentation. These can be organized into separate sections or documents.

1)Specifications and Requirements Documentation

This documentation is basically the product of the requirements analysis. It should provide a general description of the IV-D program organizational relationships and the scope of the IV-D system's role in supporting the program functions.

2)General System Overview

The material for this section is derived from the conceptual/general/functional plan for the IV-D system. It should describe the processing flow, special features of the system, and the computer environment in which the system is to operate.

3)Detail System Documentation

The effort involved for this section should primarily be polishing of system specifications outlined in the detail design step, as necessitated by any changes that occurred during coding, testing, and/or implementation. It should include descriptions and flow charts, where applicable, of major system procedures and all programs, reports and files.

4)Operations Documentation

This documentation must include all general and technical information necessary to communicate to computer operations personnel how to run the system. On a job-by-job basis, it should provide:

149 The purpose of the job

149 A step-by-step description of programs executed

149 The user described input parameter cards necessary

149 Sample output

149 Error messages and recommended actions

149 Restart procedures

5)User Guides

These guides need to explain in non-technical terms how the IV-D staff can utilize various system features. Because of the variety of users and the likelihood of separate functional subsystems within the IV-D system, it may be desirable to develop several user guides. The user guides should address specific uses within the system and may contain:

149 A description of what the particular system features can do for the user

149 What input is required

149 How to interpret/use end products

149 How to make corrections

149 Who to contact for assistance

e.Training

Like the finalization of systems documentation, training must be accomplished in this phase and involves the development of a training plan for the IV-D users and preparation of trainingmaterials required to accomplish the training. The principal documents on which training and operational use will be based will be the IV-D system User's Manuals prepared in the previous activity. They should be written in a manner that permits stand-alone use by most non-EDP-oriented users. The training plan should include a formal presentation during system testing and prior t.o the scheduled operational date of the system provide an orientation for all potential users of the system. This should be followed by hands-On training with the operational system for those individuals who will be working with it on a regular basis, to provide them with a greater depth of understanding of how the system operates. Training materials should include sample copies of system outputs, a simplified instructional brochure explaining terminal operations, and the User's Manual discussed above.

4.Systems Operation

Since information systems such as IV-D are dynamic in nature and generally require ongoing tuning, adjustment or enhancement, this last phase is included as part of the discussion of the "development process." This phase involves the on going system production and maintenance activities.

a.System Production

This activity is the most important stage of the IV-D system. It is the accomplishment of the objectives of the system. If the previous activities have been properly carried out, especially the requirements analysis, this production activity will be long term in duration and hopefully relatively static in nature. Specifically, this activity involves the execution of all aspects of the system. Of paramount importance is the dependable processing of system inputs and the timely distribution of system outputs. Obviously, detailed method standards or procedures must be documented and maintained and performance logs must be kept to insure simplified and consistent operation.

In short, this activity must be made as routine or automatic as possible.

b.System Maintenance

Child Support Enforcement systems must be made to operate as effectively, dependably, and efficiently as possible. However, these systems are dynamic in nature. Evolving program requirements at the Federal, State, and local level, technology advances in computer hardware and software, and external forces often necessitate adjustment to system software as well as production procedures. Operational performance must be evaluated against system objectives, original and current, and appropriate adjustments must be made to insure effectiveness, dependability, and efficiency. Not only must these reviews be conducted on a scheduled basis, but the required changes must be planned accomplished, tested and implemented without interruption to the operational system. The changes themselves must be reflected in the appropriate system documentation, and users must be made aware of these changes in advance if they are affected.