Policy Clarifications of Automated Systems in Title IV-D Child Support Enforcement Program
DATE: August 11, 2006
TO: STATE AGENCIES ADMINISTERING CHILD SUPPORT ENFORCEMENT PLANS APPROVED UNDER TITLE IV‑D OF THE SOCIAL SECURITY ACT AND OTHER INTERESTED INDIVIDUALS
SUBJECT: Policy Clarifications Relating to Planning, Design, Development, Installation, and Operation of Automated Systems in the Title IV-D Child Support Enforcement Program.
RELATED REFERENCES: 45 CFR PART 92; 45 CFR PART 95, SUBPART F; 45 CFR PART 307.
PURPOSE: This Action Transmittal (AT) sets forth Federal policy in the most frequently questioned areas of automated system projects and clarifies areas where States have frequently encountered problems and difficulties in interpreting Federal regulations relating to those projects.
BACKGROUND: In 1990, the Federal Office of Child Support Enforcement (OCSE) issued AT-90-11, which provided policy clarifications in a number of areas for States’ use in acquiring and implementing automated child support systems. Since OCSE-AT-90-11 was first issued, the underlying basis for some of the policy interpretations contained therein have become obsolete or overtaken by events, regulations or statute. To bring up-to-date various policy clarifications related to the acquisition and implementation of automated child support systems, this AT is being issued. This AT supersedes OCSE-AT-90-11.
The policy topics covered by this AT are as follows:
- Alternatives Analysis And Consideration Of The Transfer Of Other States’ Systems.
- Acquiring A System Through Transfer Of Other States' Automated Systems.
- Automated Features Beyond Specified Federal Functional Requirements.
- Cost Allocation For Equipment And Systems.
- Depreciation Of Hardware/Individual And Unit Acquisition Cost.
- Free And Open Competition/Organizational Conflict Of Interest.
- Hardware Installation During Development Of New Systems.
- Interim Software Development During Development Of A New System.
- Allowability Of Federal Financial Participation In Failed State System Projects.
- Two-Tiered System Certification Review Process.
- Prompt Action On State Requests For Prior Approval.
- Independent Verification And Validation (IV&V).
- Office Automation, Planning, Development, Implementation, And Maintenance And Operations Expanded Definitions.
OCSE POLICY CLARIFICATIONS:
A. Alternatives Analysis And Consideration Of The Transfer Of Other States’ Systems
When States conduct planning to determine the best, most cost effective and efficient path to take in building a new or replacement human service system, certain minimum requirements apply if Federal Financial Participation (FFP) is expected. Foremost of these requirements is the need to conduct a rigorous Feasibility Study, including an Analysis of Alternatives with a Cost-Benefit Analysis of each alternative examined. The Administration for Children and Families (ACF) has created and provided considerable guidance to States on how to conduct Feasibility Studies, and Alternatives and Cost-Benefit Analyses, all of which is available online on the internet. Child support-specific guidance is available online on OCSE’s internet website at: http://www.acf.hhs.gov/programs/css/state-systems.
Federal regulations at 45 CFR 95.605 of Subpart F stipulate that systems transfer is an option for consideration, and that, if not chosen as an option to be considered, the decision be explained as part of any Implementation Advance Planning Document (IAPD) for Federal funding.
Previous policy: Section A of OCSE-AT-90-11, dated October 9, 1990, provided an interpretation of the regulatory requirement regarding systems transfer at 45 CFR 95.605, namely that, in practice, ACF required States to transfer existing systems. That policy interpretation was revised on July 22, 1994, with the issuance of OISM-AT-94-5 to reflect that, although systems transfer was the preferred alternative, it was no longer a requirement in systems acquisition.
Current policy: ACF does still require that States at least consider transfer as an option in any Feasibility Study conducted to define an automation solution, such as in acquisition of a new child support system. Feasibility Studies and their accompanying Alternatives Analyses that do not contain a State system transfer as one of at least three alternatives considered and evaluated, are deemed fatally flawed and will result in disapproval of any resultant IAPD. However, in no way does this policy interpretation suggest that systems transfer is required. Rather, systems transfer must be appropriately considered as one possible alternative when seeking acquisition of an automated child support system.
B. Acquiring A System Through Transfer Of Other States' Automated Systems
Based on Federal regulations at 45 CFR 95.605 and 307.15(b)(11), OCSE maintains a policy that all States must consider the transfer of another State’s system as part of any planning effort to acquire a new automated child support system. This policy promoting the sharing of technology among States markedly decreased the installation timeframe for automated Child Support Enforcement Systems (CSES) and reduced the risk of system failure due to poor system design or inadequate planning.
Previous policy: OCSE-AT-90-11 declared that while States could express a preference for the operating characteristics of a particular State’s CSES, they could not name-select that State’s system because they would usually be utilizing contractor resources to affect the transfer. This name-selecting of a system utilizing contractors was deemed to place a clear restriction on free and open competition by not allowing contractors to propose systems they might otherwise have more experience with while still meeting a given State’s requirements. At the time, this restriction was necessary due to a lack of experience among the vendor community with certain systems, some of which became quite popular as transfer candidates. Though this requirement did not apply to States that chose to transfer, modify and install a system utilizing in-house staff, all States were still encouraged to review multiple State systems in order to select the transfer candidate that best fit the requirements identified in the planning phase of the State’s project.
Since OCSE-AT-90-11 was first issued, much has changed in the child support systems arena. Numerous second-generation system development projects are underway nationwide. The vendor community doing business with child support now possess a breadth of experience in multiple “families” or “flavors” of systems. Because of these factors, the need to restrict the name-selection of transfer systems in the name of encouraging competition is no longer necessary. This further applies when considering the trend towards cross-pollination of various systems into hybrids; combining best-of-breed components from multiple State systems to arrive at a best-value solution for the acquiring State.
Current Policy: Transfer is one of the alternatives that States must consider in their alternatives analyses, but it is no longer the preferred alternative, and there is no longer a restriction on name-selecting the State system, or sub-system to be transferred.
OCSE believes this revised policy recognizes and balances the need to allow States maximum flexibility in determining automation solutions while ensuring open and free competition.
C. Automated Features Beyond Specified Federal Functional Requirements
Development by States of Federally funded, automated CSES requires construction in accordance with a prescriptive set of functional requirements. Though this process has arguably resulted in a consistent and extremely cost-beneficial approach nationally to the need to automate the child support enforcement program, more can be done. States are strongly encouraged to use state-of-the-art automation approaches that provide capabilities beyond the requirements specified in Title IV-D’s systems requirements document, Automated Systems for Child Support Enforcement: A Guide for States (The Guide). Numerous capabilities above and beyond those found in Federal certification requirements have been shown to further enhance customer service, worker productivity and cost savings. For example, to provide better service, a State might consider the inclusion of one or more of the following features in its system:
- An automated voice response (AVR) system for improved customer service; or
- Internet-based customer service websites allowing client access to or interaction with their own case data.
To improve worker productivity and effect increased cost savings in a given area, a State might choose to implement one or more of these features:
- A document imaging system to enhance information access while reducing document storage, handling and processing costs;
- Internet-based interagency access websites allowing worker interaction with related cases and case data residing on another agency’s system; or
- Data warehousing across multiple programs to improve the timeliness and reliability of data and reporting.
The purpose of these examples is not to propose them as preferred enhancements, or present them as otherwise Federally pre-approved; approval of any enhancement requires justification, including its cost and benefit. Rather, the examples above represent a few of the many innovative State initiatives being used to improve program performance. Federal policy recognizes that States are uniquely positioned to determine how best to enhance existing automated systems to improve service to their constituencies. OCSE supports and encourages enhancement of existing automation when such augmentation can be shown to be beneficial from a cost and program performance perspective.
Previous policy: The previous policy set forth in OCSE-AT-90-11 section B was related to whether enhanced funding would be available for functionality that exceeded the functional requirements set forth in 45 CFR 307.10 and, by inference, in 45 CFR 307.11.
Current policy: Enhanced funding is no longer available for systems development for child support. OCSE’s The Guide is being updated in 2006 to incorporate additional functional objectives. While any States whose systems are not yet Family Support Act (FSA) and Personal Responsibility and Work Opportunities Reconciliation Act (PRWORA) certified will be reviewed based on the October 2000 version, OCSE is updating The Guide to encourage States and Territories to enhance and expand the automation in their Statewide systems, including web-based technologies. This additional functionality could include the electronic income withholding order (eIWO), the QUICK (Query Interstate Cases for Kids) pilot, and other innovative solutions and best practices in automation. OCSE anticipates soliciting input on the revisions made to The Guide from States in the summer of 2006.
D. Cost Allocation For Equipment And Systems
Federal regulations at 45 CFR Part 95, Subpart E mandate that all States develop and maintain an approved cost allocation plan to identify, measure and allocate all State agency costs incurred in support of all programs administered or supervised by the State agency. While this assures the equitable distribution of funding among Federal funding sources, many States have expressed concern about the organizational structure of some public human service agencies. One such example is a Title IV-D organization’s need to share hardware and software with State Courts. This is particularly applicable in States that utilize, under cooperative agreements, central data processing agencies to support the maintenance and operation of multiple public human service systems. To make matters more complex, Federal rules also specify that cost allocation of maintenance and operations be based on a Cost Allocation Plan (CAP) approved by the Division of Cost Allocation (DCA) in the Department of Health and Human Services (HHS), whereas a CAP for system development costs is handled differently. A systems development CAP must be approved by the applicable Federal funding source agencies under an Advance Planning Document (APD). But both types of CAPs must be clearly described in an APD if Federal funding is to be requested.
Current policy: The systems policy in this area has not changed. However, at the request of States, ACF, along with the Centers for Medicare and Medicaid Services (CMS) and the Department of Agriculture’s Food and Nutrition Service (FNS), created the Cost Allocation Methodology (CAM) Toolkit. The toolkit will assist States with building useful cost allocation algorithms that can equitably distribute to benefiting programs, the costs incurred in developing automated human services systems. This toolkit is available to States and other interested parties on ACF’s internet website. It was announced to States in a Dear Colleague Letter (DCL 04-17) dated April 19, 2004.
Beyond the requirements for allocation of systems planning and development costs as defined in the CAM toolkit, which are not repeated here, a few additional clarifications of our position on Federal funding in these situations are provided as follows:
- A State’s APD may request approval for acquisition and operation of hardware and related software to be used by a contracting agency (e.g., County Attorney, Court, Data Center) under a service or cooperative agreement.
- For both development and operations, when any agencies outside of the Federally funded agency are performing services under a cooperative or service agreement, the APD must contain a description of this agreement as part of the APD’s documentation of the State’s approved CAP.
- State IV-D agencies must include a description of the cost allocation methodology authorized by the HHS/DCA in its APD. Further, even in cases when total project costs are under applicable prior approval thresholds established at 45 CFR Part 95, Subpart F, costs for ongoing operational expenditures must be allocated in accordance with a State’s approved CAP.
- In States where the Federally funded public human service agency acquires resources from a central data processing (CDP) facility, costs at the applicable matching rate for equipment must be charged in accordance with an approved CAP. Often, a non-developmental CAP is based on the percentage of use by each agency utilizing the equipment, though we recognize caseload size may also be employed as a CAP methodology. Regardless of how operation and maintenance costs are allocated, including in the cost of an equipment acquisition, the CAP used must be approved by HHS/DCA before FFP may be claimed.
- For application development in the Title IV-D environment, the State Title IV-D agency must assess the costs of developing any application software that pertain to non-IV-D activities to ensure that the Title IV-D share of allocated project cost is equitable. This need for cost allocation applies even when, for example, functionality being developed in the application software to meet Title IV-D program rules or requirements could also be used to meet non-IV-D requirements.
- Equipment acquired for, or dedicated solely to the use of a given Federally funded public human service program, such as Title IV-D, in a central data processing facility, may be charged 100 percent to that program at the applicable FFP rate. We view this as unlikely in most instances in that we would normally expect that the equipment acquired and installed at a central data processing unit would also support other agencies utilizing the equipment, and thus need allocation of its cost. In these instances, additional supporting documentation may be requested.
- In all cases, the acquisitions of equipment and services are subject to the prior approval thresholds set forth in 45 CFR Part 95, Subpart F.
- States are reminded that, in accordance with the Office of Management and Budget Circular A-87, costs must first be direct-charged to the benefiting program before any allocation of remaining expenditures can be pursued. Federal funding agencies reserve the right to retroactively adjust any previously approved FFP based on a CAP in an APD if it is later found to be in error, including when there was a failure to direct-charge costs to the fullest extent possible.
E. Depreciation Of Hardware / Individual And Unit Acquisition Cost
Previous policy: In accordance with 45 CFR Part 95, Subpart G, it has been the policy of HHS to require States to capitalize and depreciate, over its useful lifecycle, all hardware having a unit acquisition cost in excess of $25,000.
Current policy: On July 22, 1994, ACF issued ACF-AT-94-05 modifying this policy. From that date forward, only individual Automated Data Processing (ADP) equipment items having an individual acquisition cost in excess of $5,000 require depreciation. The significance of this change can be found in the use of the term “individual” versus “unit” when referring to acquisition cost. Now, the purchase of 50 “individual” personal computers (PC’s) at $1,000 each can be expensed in the quarter acquired, whereas under previous policy (pre-July 22, 1994) those same 50 PC’s would be considered a “unit” of acquisition cost totaling $50,000, and therefore, being over the $25,000 threshold, they would have to be depreciated over the equipment’s expected lifespan. The following specific principles apply to the revised depreciation policy first set forth in ACF-AT-94-05:
- Individual items of ADP equipment (e.g., personal computer, or a printer, or router, etc.,) with a useful life exceeding one year and costing $5,000 or less need not be depreciated. Rather these individual pieces of ADP equipment may be expensed in the fiscal quarter acquired. Any individual piece of ADP equipment costing in excess of $5,000 must be depreciated over its expected useful life.
- For purposes of further defining the term “individual” in individual acquisition cost, the following is provided: an individual piece of ADP equipment is comprised of all sub-components that make up a working piece of equipment. Computer memory chips, hard drives, motherboards, etc., are not considered to be individual pieces of ADP equipment, but rather components in an individual piece of ADP equipment, such as a computer server.
- No equipment expensed under provisions of this policy is expected to have a useful life of less than three years. Should a State seek a shorter lifespan for its ADP equipment (e.g., 18 months), a request for approval of the shortened equipment lifespan is needed from the respective Federal funding program(s) in the form of an As-Needed APD.
- Quite often, as is the case with computer servers, PC’s, etc., software must be procured with the hardware in order for the equipment to work. It is Federal policy that software purchases are not subject to depreciation requirements, regardless of the cost of the software. Depreciation applies only to equipment, including ADP hardware.
- Under the provisions of 45 CFR 95.641, a State may request an exemption of the depreciation provisions of Subpart G. However, given the revised policies toward depreciation provided under ACF-AT-94-05, any request for an exemption of depreciation will require rigorous, documented evidence that an exemption is in the best financial interest of the Federal Government.
F. Free And Open Competition / Organizational Conflict Of Interest
Federal regulations at 45 CFR Parts 92.36(c) and 95.613(a) mandate that all procurement transactions, regardless of whether by sealed bids or by negotiation and without regard to dollar value shall be conducted in a manner that provides maximum free and open competition. States need to be alert to organizational conflicts of interest or other noncompetitive practices that may restrict or eliminate competition. States have a responsibility to not only comply with Federal regulations mandating free and open competition, but also to be perceived by the vendor community as conducting procurements fairly, openly, and without prejudice.
In most cases, States acquire public human service systems in two phases. The first phase (planning) usually includes contractor assistance to develop and define functional requirements for the purpose of issuing a Request for Proposal (RFP) to, for example, transfer another State’s system. The second phase is construction of the defined system, be it a transfer, new construction, major rewrite, etc.
In addition to utilizing a contractor to help define and compile system requirements, some States also use the contractor to help write the RFP. Regardless, in order to eliminate the appearance of unfair competitive advantage, contractors who assist a State during planning phase activities, and develop or draft specifications, functional requirements, statements of work, invitations for bid and/or RFPs, must be precluded from competing for subsequent phases of the respective system development and installation project. This preclusion extends to the contractor acting as a sub-contractor to another prime contractor on such projects. To prevent delays, misunderstandings and procurement protests, all State solicitations for contractor services to assist with the planning phase of system projects should contain a clause making this point clear to prospective bidders. Moreover, any development phase solicitation should state that any contractor who participated in the planning phase, and developed or drafted specifications, functional requirements, statements of work, invitations for bid and/or RFPs, may not bid on the subsequent system transfer/development effort.
States must also ensure, when developing procurement actions, that the solicitation for application development is based upon a clear, thorough description of the State's technical and functional requirements. Such descriptions may not contain features that unduly restrict competition by:
- Specifying software, application frameworks and tools proprietary to a specific vendor and not available off-the-shelf to the general public;
- Or for which special consideration or relationships are required in order to acquire access to the proprietary software but which have the effect of unduly limiting competition; and
- Otherwise containing specifications that only a single vendor could meet.
In hardware acquisitions, OCSE recognizes that a State must consider already operational systems that share existing equipment needing upgrade or replacement. In instances where a State determines it must upgrade or replace existing equipment proprietary to a specific vendor, essentially sole-sourcing the equipment acquisition (a comparative cost analysis or Feasibility Study [FS] to determine the most cost effective approach for meeting all needs) must first be conducted. This cost analysis, or FS, may necessarily need to include an examination of the cost to convert all programs’ software applications to a new, more competitive platform. The results of such cost analysis must be included in the State’s request for approval of the subject procurement.
Finally, States need to be aware that Federal regulations at 45 CFR 92.36(c)(2) prohibit “geographical preferences” in the solicitation, selection and award of Federally funded acquisitions. Essentially, States may not favor in-State corporations versus those based out-of-State in procurement actions.
Current policy: This policy has not changed since OCSE-AT-90-11.
G. Hardware Installation During Development Of New Systems
Hardware eligible for Federal funding during the early stages of planning and development of a software construction project is limited to that which is necessary for the purpose of project definition, project management, application development, prototyping and for defining and describing performance and technical specifications. During this early development phase, large acquisitions of operational computer hardware and operating system software, and communication lines and equipment may not be charged to the project.
In general, hardware expenditures during the development phase are expected to be incurred in one central development site; however, OCSE recognizes that system performance testing may be more effective at pilot sites. Therefore, OCSE will approve Federal funding at the applicable matching rate for equipment at up to three pilot locations, dependent upon the composition of a State's caseload and/or organizational structure.
All other hardware delivery should be phased to coincide with the system’s implementation schedule. If hardware is acquired early for any reason, the State may not claim FFP for those expenditures unless the acquisition is approved on an exception basis by the respective Federal funding program(s), or until such time as the hardware is installed and in use in support of the applicable public human service program(s) and system(s). For hardware acquired prior to the implementation of a Statewide system, the following guidelines apply:
- If hardware is acquired but stored prior to its installation and use, the State must pay the entire cost of the storage. FFP is not allowed in storage costs.
- If the early acquisition and use of hardware is approved for conversion preparation activities, the State may expense or begin to depreciate the cost, as appropriate, upon its installation and use.
- FFP is not allowed in hardware acquisition costs more than 90 days prior to the actual installation of the equipment in question. In addition, for purposes of establishing the hardware’s useful lifespan, for example, to determine depreciation schedules or replacement cycles, the start of the equipment’s useful lifespan calculation cannot begin until the equipment is installed for operational use.
Current policy: This policy has not changed since OCSE-AT-90-11.
H. Interim Software Development During Development Of A New System
Title IV-D regulations at 45 CFR 307.15(b)(1) require that the Statewide, comprehensive CSES be the sole systems effort being undertaken by the State in support of program operation. However, during the development and implementation process, OCSE recognizes that in certain instances, the existing system in operation in the State may have to be modified to accommodate Federal or State regulatory changes and/or new legislation until such time as the new CSES is operational. Under such circumstances, a State may be required to modify its already operational system, or develop an interim system solution, to allow the State to meet those new State and/or Federal requirements.
The conditions, under which OCSE will grant approval of Federal funding at the applicable matching rate for interim systems activity, are:
- The proposed development or modification is essential to implement mandatory State and/or Federal regulations or legislation relating to the Title IV-D program.
- The State must agree to use the new Statewide system when it is implemented, at which time FFP in the costs of the interim CSES will cease.
- The State must document the cost-benefit for development of an interim system or modification of the existing CSES, such that the cost-benefit will prove positive or, at a minimum cost-neutral, and that all such development will be completed prior to the implementation of the new, Statewide CSES.
- That data input or converted to the interim system solution can be easily converted to the new, Statewide system.
- If a major hardware acquisition is associated with the system modification, the hardware must be utilized by the new Statewide system when that system is implemented and operational.
Current policy: This systems policy has not changed, but has been updated to more accurately reflect that the majority of States now operate certified, Statewide CSES, and to address the fact that as second-generation systems are now being planned and developed, and as new legislation and/or regulatory changes occur at the State and Federal levels, issues surrounding interim systems may rise anew.
I. Allowability Of Federal Financial Participation In Failed State System Projects
In instances where a State does not complete an ADP system development project because of faulty project planning or management, including any circumstances beyond the State’s control, OCSE will conduct a close-out review under the provisions of 45 CFR Parts 95.612 and 95.621 to determine the amount of Federal funding that must be recouped from the State’s failed project. Upon completion of the close-out review, a subsequent determination will be made as to any supplemental requirements to be imposed upon the project and incorporated into an APD prior to the State receiving FFP in a restart or reacquisition of the automation project.
Allowability of costs in a failed system development project use the following guidelines based in precedent, which in turn are based in Federal regulation. Federal regulations at 45 CFR Part 95.611, and for the Title IV-D program at 45 CFR Part 307, form the basis from which these project close-out funding determination policies are derived. These policies are further based in precedents established in close-out reviews of past failed projects in which FFP was recouped.
Whether specific costs in a failed system development project are ultimately allowed or disallowed for FFP reimbursement is dependent on four criteria:
- Whether the costs were incurred in a “Good Faith” attempt by the State to design and develop a fully functional, Statewide system that would ultimately meet all conditions for approval in the respective, approved APD.
- FFP at the applicable matching rate is available only in the procurement of automated ADP system expenditures that meet the requirements specified under the conditions for APD approval including any CAP should such plan be incorporated to and approved under an APD. Costs incurred but not identified and/or approved in an APD prior to project failure are unallowable for FFP.
- Whether the expenditures in question were obligated and/or expended prior to, or after, either a Federal notice of APD suspension was issued or other State action for project termination was executed.
- Although certain costs may be deemed allowable if incurred as part of a “Good Faith” effort to develop the Statewide system, costs related to the implementation of the failed system are not allowable. These unallowable costs include charges incurred in such areas as data clean-up and conversion, training, operational hardware and operating system software procurements and costs associated with installation. These “implementation” costs are wholly unallowable irrespective of the “Good Faith” efforts of the State to develop the system in question when that project fails and is subsequently terminated.
FFP at the applicable matching rate is available only in the procurement of ADP system expenditures that meet the requirements specified under the conditions for APD approval including any CAP should such plan be incorporated to and approved under an APD. Costs in system procurements that fail to comply substantially with an APD approved under regulations at 45 CFR Parts 95.611 and 307 are subject to disallowance by HHS. It is this “failure to comply substantially with an APD” that identifies when an ADP project is deemed to have failed. Costs disallowed under an APD are not subject to appeal beyond a request for reconsideration to the respective Federal funding agencies. APD suspension, likewise, is not subject to appeal beyond a request for reconsideration to the respective Federal funding agencies.
During any period of suspension of an APD, FFP is disallowed for all expenditures obligated or incurred during the period of suspension. As such, suspension disallows all costs from the date of suspension forward, until such time as the respective Federal agencies funding the APD notify the State in writing of a determination that the reason(s) for the suspension have been eliminated and the APD is once again approved. FFP lost during a period of APD suspension cannot be recouped.
Current policy: While this is not new policy, and this policy and process has been applied to previous failed system development projects, OCSE decided that it was important to share this process and policy with all States.
J. Two-Tiered System Certification Review Process
Previous policy: Under the FSA of 1988, all States were required to implement comprehensive CSES Statewide. Further, OCSE established a systems certification process that included support for two-tiered reviews. These reviews, called Level I and Level II reviews, were created to assist States in meeting the system certification objectives. In the past, some States, especially those using contractor assistance to transfer in and modify another State’s CSES, asked that OCSE review the modified system during the pilot test phase to help the State determine if it met Federal certification requirements. This review was labeled a Level I or functional certification review. Its purpose was essentially to determine if additional design or development work was needed to achieve certification; a necessary insight prior to rolling out the system Statewide. If this review found the system certifiable, then the Level II, or full certification review, would be conducted at the time the State’s CSES became operational Statewide.
Current policy: During the time States were building and implementing systems to meet the mandates of FSA, and later of PRWORA, OCSE encouraged States to take advantage of this two-tiered certification process. The process offered early identification of system deficiencies and provided otherwise valuable technical assistance, including providing a clear indication as to whether a vendor’s work building or modifying a State’s CSES was acceptable and complete. Though this two-tiered certification review process is no longer necessary, OCSE believes future CSES system redesign and replacement projects could also find benefit from the process. Therefore, in order to continue to offer technical assistance to the greatest extent possible, OCSE is retaining the option for States to request a two-tiered certification review process. Our policy for Level I and Level II system certification is as follows:
- Level I Certification. States may request certification when an automated CSES is installed and operational in a pilot or multiple pilot locations. If a mandatory function of the automated CSES, (e.g., Medicaid interface or a security procedure) is not being performed during pilot operation, the State must be able to demonstrate that the system has the capability to perform the function. In addition, the State should be able to provide at a minimum, system design, program documentation, user training and operational manuals. Functional certification will normally be based on the use of live data; however, test data may be used at the option of OCSE.
- Level II Certification. States should submit requests for certification upon the completion of Statewide installation of the functionally comprehensive CSES in all political subdivisions and agencies involved in child support enforcement within the State. The system must meet all functional requirements and be fully operational and include all active and otherwise appropriate cases. The State must have completed and provided to the Federal Office conducting the review all required system documentation. All system security, privacy, backup and recovery procedures must be in place. States not meeting certification requirements will be required to take corrective action, as specified and documented in a certification review report.
K. Prompt Action On State Requests For Prior Approval
Previous policy: At the time of the issuance of OCSE-AT-90-11, the Federal regulations at 45 CFR 95.611(d) specified that States shall receive an FFP determination decision for all actions within 30 days.
Current policy: In July 1996, this regulation was revised to give OCSE 60 days, but also set a new policy of, “provisional approval if the Department has not acted on the request within 60 days.” Federal regulations at 45 CFR 95.611(d) specify that States shall receive an FFP determination decision for all actions submitted for approval under 95.611(b) within 60 days, or be notified by OCSE or appropriate Federal agency regarding the status of their request. Please note that internal practice is not to wait the full 60 days. OCSE acknowledgement letters usually indicate that if the Department has not reached a decision within 30 days, the responsible OCSE staff member will contact the State to let it know the status and request any additional information. The 60-day “clock” begins from the date of the letter to the State acknowledging receipt of the subject request. State requestors must be vigilant about ensuring they receive this acknowledgement letter from OCSE.
Also note that, in Dear Colleague Letter DCL-05-01, a new submission process for approvals of Information Technology (IT) requests was announced. State requests that involve more than one Departmental program (e.g., Title XIX and Child Support) should be sent to the Deputy Assistant Secretary for Administration, ACF, and include “to the attention of the State Systems Coordinator for HHS.” State requests involving just one program (e.g., Child Support) should be sent to the Commissioner of the Office of Child Support Enforcement, and include “to the attention of the Director of the Division of State and Tribal Systems, OCSE.” Normally, when an action is approvable, States receive a written decision within the specified timeframe. In some cases, when incomplete documentation is received, and/or where the nature of the State’s request is complex, OCSE may be unable to meet the 60-day timeframe. In instances where a State’s request for prior approval is not responded to by the responsible Federal Office(s) within the 60-day timeframe, the State’s request is automatically deemed to have provisionally met the prior approval requirements effective as of the 61st day after the date of the letter to the State acknowledging receipt of the subject request.
Provisional approval essentially means that the State may proceed, assured that as long as the request is approvable, Federal funding in the request is available as of the that 61st day. There is, however, some risk for States in that, if the request is eventually denied and the State has already expended funds, FFP in those expenditures is unallowable. Before commencing any action in which there is an expectation of FFP, States should weigh the risks involved in pursuing activity, including any expenditure of funds, under a provisional approval scenario.
L. Independent Verification And Validation (IV&V)
Current policy: This is a new policy prompted by regulatory changes to 45 CFR 307.15 (b)(10) in 1998. Software verification and validation is a systems engineering discipline that helps the development organization build quality into the software during the software development life cycle. Validation is concerned with checking that the software meets the customer's needs, and verification is concerned with checking that the system is well engineered. This is sometimes expressed as, "Are we building the right system?" and "Are we building the system right?"
OCSE based its implementation of verification and validation on the Institute of Electrical and Electronics Engineers (IEEE) standard for software verification and validation (IEEE Std 1012-1998). The IEEE standard includes assessment, analysis, evaluation, review, inspection and testing of software products and processes. Verification and validation processes assess the software in the context of the system, including the operational environment, hardware, interfacing software, operators and users. Further, software verification and validation is performed in parallel with software development, not at the conclusion of the software development.
However, OCSE’s implementation of this IEEE standard varies in one important aspect: it must be performed by an organization independent of the software development project. OCSE’s Independent Verification and Validation (IV&V) process came about as a result of passage of the PRWORA of 1996. The definition of activities included under IV&V are found in Federal regulations at 45 CFR 307.15(b)(10). The definitions are appropriately quite broad, and include both technical and management activities. Those regulations also lay out certain criteria that can initiate the requirements for IV&V on a State’s CSES development project. These criteria, also referred to as “triggers,” are:
- The State does not have in place a Statewide automated CSES that meets the requirements of the FSA of 1988;
- The State has failed to meet a critical milestone, as identified in its APD;
- The State has failed to submit timely and complete APD updates;
- The State's APD indicates the need for a total system redesign;
- The State is developing systems under waivers pursuant to section 452(d)(3) of the Social Security Act; and,
- The State's system development efforts are determined to be at risk of failure, significant delay or significant cost overrun.
When one or more of these triggers are present in a State’s project, OCSE conducts a preliminary IV&V on-site assessment to determine what IV&V services are required for the project. After the IV&V assessment has been performed, the assessors will report on the extent of the IV&V services the State will be required to obtain. The assessment report defines specific areas and tasks that must be addressed by the IV&V provider. Typically the requirement will not be for continuous analysis and testing, but rather in-depth audits of specified aspects of the project (e.g., configuration, requirements and/or risk management, etc.) at specified intervals (i.e., once every six months until project completion).
IV&V services may be obtained from a contractor via competitive procurement or from a State agency approved by OCSE. To qualify as an IV&V provider, a State agency must demonstrate to OCSE that it has both the technical capability to perform IV&V services and managerial independence from the State’s child support enforcement agency, the system development organization, and in most cases, from the Title IV-D program’s umbrella agency or department.
If a contractor is used, the procurement document (e.g., RFP) and contract (or similar interagency cooperative agreement if IV&V is performed by another State agency) must be submitted to ACF for prior approval, regardless of the cost. The contract must include the names and skills of key personnel who will actually perform the IV&V analysis. The contractor or State agency will then provide the following services as defined in CFR 307.15(b)(10):
- Develop a project work plan. The plan must be provided directly to OCSE at the same time it is given to the State.
- Review and make recommendations on both the management of the project, both State and vendor, and the technical aspects of the project. The results of this analysis, usually a report, must be provided directly to OCSE at the same time it is given to the State.
- Consult with all stakeholders and assess the user involvement and buy-in regarding system functionality and the system's ability to meet program needs.
- Conduct an analysis of past project performance (e.g., schedule, budget) sufficient to identify and make recommendations for improvement.
- Provide a risk management assessment and capacity planning services.
- Develop performance metrics that allow tracking of project completion against milestones set by the State.
All of the deliverables of the IV&V service provider, be they work plans or reports, must always be provided to OCSE at the same time they are provided to the State. FFP at the applicable matching rate is always available through request in an APD.
M. Office Automation, Planning, Development, Implementation, And Maintenance And Operations - Expanded Definitions
The purpose of this clarification is to expand upon some of the definitions provided in 45 CFR Parts 92 and 95. These are: office automation, planning, development, implementation, and maintenance and operations. These clarifications should help to eliminate any confusion as to when, for example, a State is deemed to have begun development work on their system versus what might erroneously have been referred to as a maintenance activity. The demarcation between the two is key, as it helps define for a State when an APD might need to be opened or reopened.
The regulations at 45 CFR Parts 92, 95, or 307 do not provide a definition of office automation. Unlike an ADP system, office automation is not specifically designed to meet the programmatic or business needs of an organization. Rather, office automation supports routine administrative functions in an organization. It can also be used to provide some limited functionality in support of an ADP system. For example, office automation might provide standalone word processing capabilities. That same word processing software might also be used to support the CSES’ (the actual ADP system) production of summons and petitions. Office automation can also provide a means to create certain reports or accounting spreadsheets that serve to streamline an otherwise wholly manual business function. Office automation components can include some or all of the following:
- Personal computers and workstations
- Networking and application servers
- Telecommunications and network wiring to connect the computers in a unified network environment
- Network Operating Systems (NOS) and workstation and personal computer operating system software, such as Microsoft Windows XP©, Red Hat Linux©, or Sun Solaris©
- Office productivity software, such as Microsoft Office©, Filemaker Pro© or WordPerfect©
- Electronic mail and Internet access services, (e.g., T-1, DSL, or 56K dial-up via a V.92 modem)
The Planning Phase includes technical and management activities necessary for initiating and providing guidance for a software project. The first activity is to create a development plan to give a detailed description of the nature and scope of the activities to be undertaken and the methods to be used to accomplish the project, including defining the project life-cycle and the processes, methods and tools for software development. The plan should describe the projected resource requirements for staff, hardware, and other needs and the resources available or expected to be available to meet the requirements. The plan must also contain a proposed activity schedule for the project, a personnel resource statement indicating availability of qualified and adequate staff, a proposed budget including a description of estimated expenditures by category and amount, and the estimated total project cost. The plan should define the project’s deliverables, work breakdown structure, quality goals and risks, as well as processes for monitoring, controlling and reporting on the project throughout its life.
Activities in this phase may include (in addition to creating the development plan): performing a Requirements Analysis, preparing a Functional Requirements Specification, assessing other systems for transfer, prototyping all or part of a proposed new system, installing hardware and networks for development and testing and preparing a General System Design.
The Development Phase includes all of the activities required to create acceptable software deliverables as required by the development plan. These activities should include general and detailed design (defining how the system is decomposed and organized into components), construction (the building of working, meaningful software through a combination of coding, validation and unit testing), system testing (the dynamic verification of the behavior of a program on a set of test cases) and integration and user acceptance testing.
The Implementation Phase generally picks up where the development phase leaves off, though they can and often do overlap in the area of test as Pilot Test can be in either the development or implementation phases of a project lifecycle. Implementation is that set of activities needed to successfully install the system into the target organization. These activities may include the integrated testing of software and hardware subsystems including pilot test and capacity analysis, data clean-up, training, data and system conversions, hardware and operating system software installation and network build-out, implementation of security procedures and backup and contingency plans and turnover to operational status.
Maintenance and Operations Phase
The Maintenance and Operations Phase in a project lifecycle is often the most misunderstood as activities undertaken by States after a system is implemented are assumed to be maintenance when in fact they are often more appropriately defined as development. System Maintenance is the totality of activities required to provide cost-effective support to an operational software system. Maintenance activities can be performed during the pre-delivery stage, as well as the post-delivery stage. Pre-delivery activities include planning for post-delivery operations, supportability and logistics. Post-delivery activities include minor software modification and testing, refresher training and operating a help desk. We find, however, that States often struggle to discern when maintenance activities are actually more appropriately defined as software development. This is an important distinction as approval of an APD may be needed to secure Federal funding before any software development effort begins.
Generally, routine software maintenance include activities such as: revising/creating new reports, making limited data element/data base changes, table changes, making minor data presentation changes or altering data input on display screens and software bug and error corrections.
What are not considered maintenance are the more substantive development activities, such as: significant application software changes like the redesign of a child support system’s enforcement module or document generation module. Similarly, substantive redesign or replacement efforts include: new electronic interfaces; development of a graphical user interface (UI) to replace a character-based UI; rewriting a set of underlying business rules in system logic; installation of a document imaging component to the system; and application system migration from a mainframe-based to a client-server architecture, etc.
Operations activities are primarily those tasks taken to actually initiate and sustain on-line computing access of the system across an organizations network and communications infrastructure. Keeping all of the ADP equipment in good working order, as well as effecting scheduled hardware, operating systems and Commercial Off-The-Shelf (COTS) software upgrades, are also considered operations activities. In a development project, the initial installation of hardware and software is classified as part of a development or implementation phase activity. All subsequent hardware and operating system and COTS software replacements or upgrades are then classified as operational phase actions.
SUPERSEDED MATERIAL:OCSE-AT-90-11, dated October 9, 1990 is superseded by this Action Transmittal.
INQUIRIES: Inquiries should be directed to Robin Rushton, Director, Division of State and Tribal Systems, Office of Child Support Enforcement, 370 L’Enfant Promenade, SW, Washington, DC 20447.
Office of Child Support Enforcement