NOMADS CSE System Maintenance Plan - DWSS - State of Nevada

Loading...

Nevada Operations of Multi-Automated Data Systems (NOMADS) – Child Support Enforcement Application Assessment Project

NOMADS CSE System Maintenance Plan & Modernization Roadmap October 6, 2011 Revision 4.2

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Revision History Revision #

Revision Date

Revision Description

1.0

01/27/11

Initial draft prepared for internal PSI review

1.1

02/11/11

Revised based on internal PSI review; distributed to DWSS for review

1.2

02/18/11

Revised based on DWSS review; distributed to DWSS for approval

2.0

03/10/11

Initial Deliverable 2 revision; distributed to DWSS for review

2.1

03/24/11

Revised based on DWSS review feedback and submitted to DWSS for final Deliverable 2 approval and acceptance

3.0

04/29/11

Preliminary deliverable 3 update; includes revisions based on DWSS feedback for Assumptions and Constraints, Architectural Principles, Governance Goals and Strategy. It also includes initial draft of TCSA, Maintenance Goals and Objectives and Modernization Vision.

3.1

05/13/2011

Deliverable 3 update; includes preliminary Gap Analysis.

3.2

07/01/2011

Deliverable 3 draft, including final analysis results and preliminary planning results, delivered to DWSS for review.

3.3

08/12/2011

Revised based on DWSS review feedback and submitted to DWSS for final Deliverable 3 approval and acceptance

4.0

08/29/2011

Initial, complete deliverable 4 draft submitted to DWSS for review

4.1

09/22/2011

Revised based on DWSS review, distributed to DWSS for approval

4.2

10/06/2011

Inserted the Steering Committee for the Nevada Operation of Multi-Automated Data Systems (NOMADS) Assessment’s response to this report

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 2

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Table of Contents I. EXECUTIVE SUMMARY......................................................................................................................................6 BACKGROUND ............................................................................................................................................................6 ANALYSIS AND FINDINGS...........................................................................................................................................6 KEY RECOMMENDATIONS ..........................................................................................................................................8 SYSTEM GOVERNANCE ..............................................................................................................................................9 MAINTENANCE AND MODERNIZATION FUNDING OPTIONS.......................................................................................10 CONCLUSION............................................................................................................................................................11 II. BACKGROUND...................................................................................................................................................12 OVERVIEW ...............................................................................................................................................................12 BACKGROUND: SCOPE AND OBJECTIVES ..................................................................................................................12 BACKGROUND: ASSUMPTIONS AND CONSTRAINTS ..................................................................................................14 BACKGROUND: ARCHITECTURAL PRINCIPLES ..........................................................................................................15 BACKGROUND: PLAN MAINTENANCE ......................................................................................................................20 III. NEEDS ASSESSMENT RESULTS...................................................................................................................22 INTRODUCTION ........................................................................................................................................................22 NEEDS ASSESSMENT RESULTS: STAKEHOLDERS AND THEIR CONCERNS ..................................................................22 NEEDS ASSESSMENT RESULTS: BUSINESS PROCESS ANALYSIS................................................................................29 NEEDS ASSESSMENT RESULTS: SUMMARY OF PROGRAM’S NEEDS ..........................................................................32 NEEDS ASSESSMENT RESULTS: REQUIREMENTS ......................................................................................................35 IV. ANALYSIS RESULTS .......................................................................................................................................47 ANALYSIS RESULTS: AS-IS SYSTEM ARCHITECTURE ...............................................................................................47 ANALYSIS RESULTS: GAP ANALYSIS .......................................................................................................................60 ANALYSIS RESULTS: ARCHITECTURAL ALTERNATIVE ANALYSIS ............................................................................73 ANALYSIS RESULTS: TARGET CONCEPTUAL SYSTEM ARCHITECTURE (TCSA) .......................................................79 ANALYSIS RESULTS: ASSESSMENT OF NEVADA IV-D SYSTEM GOVERNANCE .........................................................95 ANALYSIS RESULTS: ASSESSMENT OF EXISTING RESOURCES ................................................................................109 V. PLANNING RESULTS......................................................................................................................................117 PLANNING RESULTS: FUNDING PLAN .....................................................................................................................117 PLANNING RESULTS: SYSTEM MAINTENANCE PLAN ..............................................................................................123 PLANNING RESULTS: SYSTEM MODERNIZATION ROADMAP ...................................................................................167 PLANNING RESULTS: SPENDING PLAN FOR MAINTENANCE AND MODERNIZATION ................................................210 PLANNING RESULTS: ISSUES ..................................................................................................................................214 VI. CONCLUSION..................................................................................................................................................215 NOMADS STEERING COMMITTEE RESPONSE ...........................................................................................215

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 3

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Related Documents The following table identifies key documents that have been used to direct the project and inform its results. This is a partial list of the documents and information referenced during the course of this project. Unless otherwise indicated, the listed documents can be found in the project document repository, along with the full complement of project reference materials. Table 1: Project Reference Documents

NOMADS CSE Application Assessment Project Charter

Project Charter.doc

NOMADS CSE Application Assessment Project Management Plan

Project Management Plan.doc

NOMADS CSE Application Assessment Methodology Plan

Methodology Plan.doc

IEEE 1471-2000 Recommended Best Practice for Documenting Software Intensive Systems

http://standards.ieee.org/reading/ieee/std_public/description/se/14 71-2000_desc.html

Maximus Performance Audit of the State of Nevada’s Enforcement and Collection of Child Support: Final Report Audit Findings and Recommendations

Performance Audit of the State of Nevada’s Enforcement and Collection of Child Support.pdf

DWSS’s Response and Status Report to Maximus Findings and Recommendations

Implementation Analysis of Maximus Suggestions 03-09.pdf

DWSS Child Support Enforcement Strategic Plan 2009 – 2010

NV CSE Strategic Plan 2009 – 2010 3-15-10.doc

DWSS – M205 Alternative (AMPS) Decision Unit – TIR Business Case

TIR_M205 Alternative Ver4.doc

CSP to EGL Migration TIR

CSP Migration TIR v6.doc

PGC Nevada DHHS Eligibility Engine Evaluation and Cost Estimate

HCR NV Report Final.pdf

DWSS Server Application Descriptions

App Description_0.doc

DWSS NOMADS Related Software Systems

DWSS NOMADS-Related Applications.doc

CSE County Business Process Documentation

Business Process.zip

Work Items Executive Summaries and System Requirement Documents

ES, SRD.zip

Software Development Life Cycle documentation

SDLC.ppt, SDLC Process Flow.doc, SDLC Policy.doc

Enterprise Information Technology Services (EITS)’s Mainframe Capacity and Performance Task Force Findings

Mainframe Task Force.pdf

NIST 800-53: Recommended Security Controls for Federal Information Systems and Organizations

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53rev3-final_updated-errata_05-01-2010.pdf

IRS 1075: TAX INFORMATION SECURITY GUIDELINES FOR FEDERAL, STATE AND LOCAL AGENCIES

http://www.irs.gov/pub/irs-pdf/p1075.pdf

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 4

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Document Context This document describes the current state (the as-is) and an envisioned state (the to-be) of the Nevada IV-D1 System. It also discusses the recommended approach for evolving the system from the as-is to the to-be. This document employs concepts of the IEEE (Institute of Electrical and Electronics Engineers) 1471-2000 Recommended Practice for describing software systems and architectures. IEEE is the world’s largest professional association dedicated to technological advancement and excellence. The IEEE 1471-2000 (or simply 1471) establishes a stakeholders / viewpoints / multiple-views model for an Architectural Description (AD). In 1471: Š

Stakeholders (individuals and groups who have an interest in some aspects of the system) are identified up front.

Š

Stakeholder concerns are identified as translated into high-level architectural requirements for the system. The remainder of the AD will address those concerns. The Needs Assessment section of this document describes the identified Stakeholders and the concerns they have voiced about the Nevada IV-D System.

Š

Multiple views are provided. A single view is not considered adequate to address all stakeholder concerns. In describing the Nevada IV-D System, this document concentrates on three main views: Functional, Information Flow, and Development. These three main views are employed to discuss both the as-is and to-be system architectures.

For more information on IEEE 1471, please see the reference to the official standard in the Related Documents section of this document.

Title IV-D of the Social Security Act that is the origin of the child support Enforcement Program overseen and financed by the Department of Health and Human Services/Administration for Children and Families. A IV-D child support case is initiated by a parent’s application for services or as a condition for a custodial parent to receive TANF benefits.

1

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 5

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

I. EXECUTIVE SUMMARY Background   A 2006 Maximus Performance Audit of the State of Nevada’s Enforcement and Collection of Support recommended that Nevada replace the statewide Child Support case management system. The Nevada Legislature in turn authorized funding to perform an assessment for upgrading the current Child Support (IVD) component of Nevada Operations of Multi-Automated Data Systems (NOMADS). However, the Legislature instructed the Division of Welfare and Supportive Services (DWSS) to “…tailor the assessment in such a way as to identify solutions that can be funded by existing resources and …that address technological alternatives to replacement…” DWSS contracted with Policy Studies Inc (PSI), a nationally recognized health and human services consulting firm, to conduct this assessment. PSI tailored a system assessment methodology to DWSS’s needs in order to deliver a System Maintenance Plan that addresses system sustainability issues for the near term, and a Modernization Roadmap to upgrade the IV-D system in incremental steps for the longer term. The scope of the assessment included the additional system applications that have been developed to augment the NOMADS mainframe CSEP components.

Analysis and Findings  In carrying out its comprehensive system needs assessment, PSI reviewed extensive background documents, held structured interviews with key stakeholder groups, and examined selected business processes for their effectiveness. The synopsis of needs resulting from this assessment presents a clear picture of a IV-D system in urgent need of attention with nearly every element of the current system requiring some form of remediation. In fact, PSI’s assessment of the system’s technical needs identified numerous concerns about, limitations of, and deficiencies within the current IV-D system. It is clear from this technical assessment that DWSS should aggressively pursue a Maintenance Plan designed to immediately stabilize and tactically enhance the current system. This will enable the system to remain workable while an incremental modernization effort is executed. This report identifies and discusses the critical requirements that must be satisfied to ensure the system’s viability for the immediate future and to enable the CSEP, administered by DWSS, to complete its business functions in an effective and efficient manner over the long term. The existing architecture of the Nevada IV-D System was analyzed from two distinct views. The Functional View looked at the IV-D System in terms of the business processes it currently supports, while the Technical View looked at the System in terms of architecture, source code, data management and interchanges with external systems. The major system deficiencies derived from these reviews are itemized below: Functional Review: Š

System availability and performance. The current system is unavailable or slow for significant periods of time – negatively impacting worker productivity.

Š

Intuitive/supportive user interface. The current IV-D mainframe application has a dated, unfriendly user interface.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 6

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Automated management tool for assigning, monitoring, reporting and auditing casework. The current system does not effectively support proactive caseload management or prioritization of work

Š

Robust reporting. The current system lacks robust business intelligence capability and reporting. The current mainframe system also lacks ad hoc reporting capability.

Š

Valid locate records. The current IV-D system does little to prevent “bad” data from populating/entering the system.

Š

Reliable IV-A (TANF) and IV-E (Foster Care) Referrals and Updates. Automated IVA referral information is frequently incomplete and/or of poor quality.

Š

Workflow management capability. The system does not inform the user of, move the user to, or assist the user in completing the next process step. Furthermore, the system does not automatically monitor timeframes and prompt users.

Š

Robust financial management and accurate accounting. The system lacks sophistication equal to the complexity of Child Support accounting business rules, resulting in financial data errors. The inability to produce an accurate pay history is a significant shortcoming.

Š

Effective, efficient customer support. The system does not provide staff with ready access to case summary information that would otherwise enable efficient/effective responses to customer inquiries

Š

Consistent program security standards. The system’s security management is distributed and standards are inconsistent.

Technical Review: Š

Reliance upon IBM’s Cross System Product. The current system is predominantly coded in CSP, an unsupported programming language. It is our understanding that DWSS is proceeding with a conversion from IBM’s Cross System Product (CSP) to Enterprise Generation Language (EGL) as part of a legislatively approved Health Care Reform (HIX) initiative with planned completion in calendar year 2012. This conversion is intended to help extend the useful life of NOMADS and transform NOMADS to a database of record.

Š

Aging and brittle architecture. The current architecture is brittle mainframe-based, monolithic, and difficult to maintain and extend.

Š

Lacks a business logic layer. The current monolithic architecture does not permit a separation of the business logic from the other elements of the application, as current Best Practices advise

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 7

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

“Unhealthy” coupling between IV-A and IV-D. Key data elements that are essentially under the control of IV-A processes create data inaccuracies and causes significant inefficiencies in IV-D program operations.

Š

Constrained mainframe capacity. The limited performance and capacity of the existing mainframe infrastructure negatively impacts user productivity.

Š

Fractured security model. The split between NOMADS mainframe applications (using Resource Access Control Facility, or RACF, security) and ancillary applications imposes multiple credentials and logins for users and makes security more difficult for IT to manage.

Š

Lacks a rules engine. The business logic in NOMADS, including the complex financial distribution rules required for IV-D program are essentially hard coded within the screens and programs that make up the system.

Key Recommendations  This report recommends immediately implementing two strategies. The first strategy is designed to stabilize IV-D NOMADS so it can be maintained until it can be modernized. The second strategy is to modernize IVD NOMADS so it effectively supports Child Support caseworkers and the customers they serve into the foreseeable future.

NOMADS IV-D Maintenance Plan The first and most urgent strategy is to invest resources and funding to stabilize the current IV-D NOMADS so it can be maintained effectively while the modernization strategy is planned and funded. To stabilize the system, PSI’s recommended DWSS embark on a number of projects that should not be superseded by other priorities unless absolutely necessary: Š

Define and finish projects already in process and projects already planned that will directly address improvements to the NOMADS IV-D architecture; create projects and assign resources to monitor functional initiatives outsourced to third parties that are already planned/funded

Š

Use the recommended maintenance candidate screening process to rescreen In-Process Candidates that have been identified as Halted or Not Started

Š

Identify discreet components of the NOMADS IV-D financial system that can be fixed as a maintenance item

Š

Develop Mini Business Cases as recommended in the Maintenance Plan for the Top Maintenance Candidates from the recommended screening process

PSI recommends that the first 18 months be devoted to effectively delivering on the work items listed above. After this 18 month period, the focus should shift to system modernization, and maintenance should be scaled back to the minimum necessary to cover maintenance activities. This approach can deliver value to IVD system users in the near term while allowing time to fully prepare for the modernization push that will follow. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 8

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

NOMADS IV-D Modernization Plan The current IV-D system has outlived its useful life and its technical core must be modernized to continue its vital role of supporting the State’s CSEP. Over the course of the IV-D Systems Assessment Project, a clear vision emerged for the future IV-D System. The modernized IV-D system is a more scalable, robust, and easier to modify than the current system. PSI produced rough order of magnitude (ROM) estimates of the level of effort and costs to fully modernize Nevada’s IV-D System. PSI followed these basic steps to produce these estimates: Š

Developed 41 discrete project descriptions (“Increments”) that are based on the Target Conceptual System Architecture (TCSA), the gaps described in the Gap Analysis, and the current state of the system

Š

Estimated each of the increments using the best data available and PSI’s extensive experience working on Child Support systems development projects

Š

Validated and strengthened the estimates using high-level information from other states, as well as PSI’s own experience in other state modernization efforts

Using the ROM estimates presented above, DWSS can incrementally develop a fully modern IV-D system in nine (9) years. The development effort calls for the use of a combination of contractors to make up for shortfalls in DWSS staff resources. The modernization effort is comprised of four phases that in turn help drive the proper sequencing of individual increments. The four phases are as follows: Š

Risk Management phase. This phase includes completing the conversion from CSP to EGL, back filling missing documentation of the existing system, cross training staff, and improving testing toolsets and database assets.

Š

Foundational phase. In this phase “assets” are created that will be leveraged across the remainder of the modernization effort. These include architectural/infrastructural increments. Each foundational increment should seek to deliver, as feasible, functional benefit to users in addition to demonstrating the components’ reusability.

Š

Functional phase. This phase will primarily include functional additions to the modernized IV-D System, leveraging the more complete set of infrastructural components/assets.

Š

Clean up phase. During this phase, the last remnants of the legacy system can be removed as well as any infrastructure specific to supporting legacy code.

System Governance  DWSS and the CSEP will need an effective governance structure and a well-designed, repeatable process for implementing the Maintenance Plan and Modernization Roadmap. PSI examined the strengths and weaknesses of Nevada’s current governance framework for the IV-D System. An overview of PSI’s governance recommendations is presented below.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 9

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Designate and Authorize the C SEP as Owner of the IV-D System. This is the most urgent of PSI’s recommended organizational changes to improve system governance. Elevation of CSEP’s ownership role includes hiring a qualified System Owner who will report to the Program. The System Owner will be directly responsible for, and actively manage, delivery of the modernized IV-D system. Product Owners should be designated to champion each significant maintenance and modernization project, from start to finish.

Š

Align Nevada Child Support Strategic Planning, IV-D System Project Prioritization, and Discretionary Resource Allocation. This alignment includes ensuring the IV-D System Owner’s and key system stakeholders’ participation in Strategic Planning. Strategic Planners should actively consider system solutions to help achieve performance objectives.

Š

Improve the Quantity and Quality of Automation Support and New System Functionality Delivered. A reengineered, more project-focused, more transparent SDLC process is recommended. The benefits of a team approach to projects, the utilization of Business Analyst (BA) positions, and the need for additional dedicated IV-D system resources are underscored. Steps to more accurately estimate and manage project effort are provided.

Š

Leverage and Optimize all Available Resources. DWSS should leverage local resources that have been identified or volunteered – including County IT staff, local subject matter experts (SMEs), and incentive earnings.

As DWSS implements the Maintenance Plan and Modernization Roadmap it will also need to apprise the Office of Child Support Enforcement (OCSE) of its plans via its Annual Planning Document Updates (APDUs).

Maintenance and Modernization Funding Options  In order to develop a Maintenance Plan that can be executed with existing program resources and to develop a Funding Plan for the Modernization Roadmap, PSI examined the basis for, and expenditure of, existing resources. PSI identified three primary state funding sources to support the IV-D systems maintenance and modernization plans. These state funding sources are: Retained TANF Collections, Earned Federal Incentives, and General Fund Support from DWSS. PSI concluded that these primary funding sources can be leveraged to support substantive IV-D system maintenance and modernization. PSI worked closely with DWSS to understand CSEP’s current funding streams, expenditures, and budget process allowing PSI to develop a funding strategy that includes the following elements: Š

Increased amount of incentives expended on technology and the use of this funding to support maintenance and modernization activities

Š

Increase state share of collections expended on technology and the use of this funding to support maintenance and modernization activities

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 10

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Continued use of a portion of DWSS’s General Fund support, temporarily suspended during recent budget cuts and approved for the current biennium, for CSEP for maintenance and modernization activities

PSI further outlines specific recommendations for fully leveraging each primary funding source. Most notable among these recommendations are the following: Š

CSEP should use 75% of any incentives available to spend within a given year (whether final, banked, or estimated incentives) for program-wide initiatives focused on maintaining or enhancing IV-D NOMADS.

Š

CSEP should begin requesting an advance on estimated incentives in the year for which it earns the incentives, and expend 75% of available estimated incentives on maintenance and modernization activities.

Š

CSEP should hold back 25% of the total final and estimated incentives in a year as a contingency to mitigate the risk of data reliability or performance issues. The resulting balance of final and estimated incentives would be available in that year with 75% of that balance to be directed towards maintenance and modernization.

Š

CSEP should direct 75% of additional incentives and all state shares of collections accruing from performance improvements in future years to maintenance and modernization activities.

Š

The state share of collections used to reimburse DWSS’s General Fund expenditures should be redirected to support maintenance and modernization activities, drawing down federal financial participation (FFP) (a restoration of General Funds for DWSS is required to enable this recommendation).

Š

The state share of collections reverted to the state government should be redirected to support maintenance and modernization activities, drawing down FFP.

Conclusion  By leveraging available funding sources, taking steps to strengthen system governance, and executing technical and functional system projects in a rational order, Nevada can realize a fully modernized IV-D system within the next 10 years. In the near term, Nevada’s IV-D system will be stabilized by addressing urgent viability issues. In the longer term, Nevada’s CSEP will be empowered to achieve its objectives and improve the lives of countless Nevada children.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 11

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

II. BACKGROUND Overview  The Nevada Legislature approved funding to perform an assessment for upgrading the Child Support component of Nevada Operations of Multi-Automated Data Systems. To that end, DWSS has contracted with Policy Studies Incorporated (PSI), a national health and human services consulting firm. This project represents the first step towards modernizing the IV-D system and addresses one of the top ten recommendations from the 2006 performance audit. The Legislature instructed DWSS to “tailor the assessment in such a way as to identify solutions that can be funded by existing resources within the program and that the solution address technological alternatives to replacement in order to allow the division to effectively operate and maintain the system and that the solution address the ongoing need to interface with the public assistance portion of the NOMADS program.” PSI, in discussions with DWSS agreed to tailor its standard assessment methodology to DWSS’ needs and focus on the production of the following two key deliverable plans: Š

A System Modernization Roadmap and Funding Plan that addresses the future modernization of Nevada’s IV-D System by presenting a TCSA for a modernized IV-D system, as well as a plan for evolving the current IV-D system to that target architecture in measured, incremental steps

Š

A System Maintenance Plan that contains actionable steps, is funded solely with existing program resources, and addresses Nevada IV-D System maintenance and sustainability issues from a near-term (tactical) standpoint; with the primary objective of extending the system’s serviceable life for a minimum period of five (5) years

Furthermore, it was determined that the scope of this assessment project and its resulting plans would include the IV-D elements of the State of Nevada’s CSE mainframe system—Nevada Operations of MultiAutomated Data Systems (NOMADS)—as well as directly-related IV-D-specific systems developed to augment the mainframe (e.g., Ledgers on the Web (LOTW), Nevada Audit Worksheet Calculator (NAWC). Augmenting systems include those which have been sponsored and piloted in one or more counties (such as EWS and FAST/Compass) but which are intended for statewide roll out. This collection of systems is referred to throughout this document as “Nevada’s IV-D System.” When the term “NOMADS” is used, it is being defined as the IV-D-specific subset of the mainframe system (unless the context makes it clear that it is referring to the entirety of the mainframe application, which includes IV-A elements as well). For more detailed discussion of the background and objectives of the project overall, please see the NOMADS CSE Application Assessment Project Charter document, which is available in the project document repository.

Background: Scope and Objectives  As specified in the NOMADS CSE Application Assessment Project Charter, the scope of this project included producing the following results: NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 12

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Document and deliver Functional and Technical Requirements for a modernized Nevada CSE application

Š

Document and deliver a TCSA for a modernized Nevada CSE application

Š

Develop and deliver a system modernization technology roadmap and master funding plan

Š

Develop and deliver an actionable system Maintenance Plan to extend the NOMADS CSE application’s serviceable and maintainable life

This System Maintenance Plan and Modernization Roadmap represent the key deliverable plan documents that the NOMADS CSE Application Assessment project was designed to deliver. Because there is significant overlap and synergy between the concerns of a System Maintenance Plan and a System Modernization Roadmap, PSI has chosen to combine the documents into one deliverable, with distinct sections that address the unique concerns of both system maintenance and system modernization. Organizing the document this way allows for better sharing of common content and presents key areas of the plan and roadmap in proper context to each other. For the sake of continuity, the remaining required project results and interim project deliverables are represented as subsections within this larger document. The following table identifies distinct project deliverables and the section(s) of this document that constitute the deliverable. Table 2: Deliverables by Document Sections Deliverable

Primary Document Section(s) Deliverable 1.2

D1.2.1 System Modernization Needs Assessment Results

Needs Assessment Results

D1.2.2 Business Process Analysis Results

Business Process Analysis Results

D1.2.3 System Modernization Requirements

Requirements

D1.2.4 System Maintenance Needs Assessment Results

Needs Assessment Results

D1.2.5 System Maintenance Needs Assessment Requirements

Requirements

Deliverable 1.3 D1.3.1 Target Conceptual System Architecture

Target Conceptual System Architecture

D1.3.2 Modernization Assessment Results Document

Analysis Results

Deliverable 1.4 D1.4.1 System Modernization Plan

System Modernization Roadmap

D1.4.2 System Maintenance Plan

System Maintenance Plan

D1.4.3 Funding Plan

Funding Plan

The choice to combine deliverables in this fashion was largely one of convenience to the reader, as well as one of cohesiveness. The PSI team felt that the individual deliverable elements were less useful as standalone documents, and that they function better inside of a larger whole. Each deliverable-section is also designed to be understandable and usable by itself (standalone). NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 13

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Background: Assumptions and Constraints   The following list is a set of assumptions and constrains, which form the context for the system Maintenance Plan and system Modernization Roadmap. These assumptions and constraints were established throughout the course of the project and were used to inform the development of the project results. Š

The resulting system modernization technology roadmap and master funding plan include recommendations for technical, functional, and operational modifications.

Š

The system Maintenance Plan’s primary objective is to address NOMADS CSE application maintenance and sustainability issues in order to prolong the application’s serviceable life for an extended period (five years minimum). The plan’s secondary objectives, which will only be addressed if sufficient program resources exist, are to improve application functionality, CSE program performance, and operational effectiveness.

Š

Conversion of the IV-D CSP code base to a supported technology is one of the primary NOMADS CSE application maintenance and sustainability issues that must be addressed by the system Maintenance Plan. However, given the integrated nature of the IV-A and IV-D CSP code base, the conversion of the IV-D code base must be done in conjunction with the conversion of the IV-A code base. This conversion will be appropriately cost allocated between the programs.

Š

The resulting system Maintenance Plan may include recommendations for technical, functional, and operational modifications.

Š

All system Maintenance Plan recommendations must be actionable, given the State and the program’s technical and funding constraints.

Š

The IV-D system TCSA, Modernization Roadmap, and Maintenance Plan will be informed by the technical direction established by IV-A technical initiatives. The IV-D plans will leverage associated IV-A technology choices and investments when reasonable to do so.

Š

Both the system Maintenance Plan and the system Modernization Roadmap will be constructed based upon the assumption that the IV-A Eligibility Engine Project will be executed in a time and manner consistent with Public Consulting Group’s recommendation. This assumption allows the plan and roadmap to leverage the Eligibility Engine Project’s efforts and results.

Š

Consistent with the Legislature’s instructions provided in funding this assessment, a fullscale system replacement project is not a solution approach that is to be considered for inclusion in the system Modernization Roadmap.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 14

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Background: Architectural Principles  In the context of this document, architectural principles are defined as the rules, guidelines, and beliefs that underlie a system’s design2, construction, and deployment. The architectural principles discussed in this section form the basis for the TCSA. The principles laid out below are not presumed to be either necessary or sufficient for DWSS, but are offered as a “starter set” that will be discussed and refined in later working sessions. Each general principle listed includes the rationale behind it and some discussion of its implications for DWSS and/or NOMADS development.

Principle: Adopt a Service-Oriented Architecture Principle: DWSS will adopt a Service-Oriented Architecture (SOA).

Rationale: SOAs provider many benefits that DWSS would like to take advantage of including: Š

Promotes software reuse. By focusing on developing reusable services, SOA promotes the Best Practice of encouraging software reuse.

Š

Enables integration. Because SOAs are so widely used in current system development and because SOAs include the inherent capability to integrate with one another on the basis of standardized protocols (Hypertext Transfer Protocol [(HTTP) / Hypertext Transfer Protocol Secure (HTTPS), Extensible Markup Language (XML), and Simple Object Access Protocol (SOAP)], it is easier to integrate with partner systems directly when your system is based on SOA.

Š

Promotes loose coupling. Loose coupling is widely acknowledged as a beneficial attribute to instill into software architectures because it produces a more flexible system—one where a major component can be removed or replaced without requiring major modifications to other components. Loose coupling helps reduce software complexity and makes software easier to maintain and modify over time.

PSI defines “system” broadly here—it could be a set of systems as it is with the NOMADS “ecosystem,” which is comprised of the NOMADS mainframe system and the entire set of “ancillary” systems that support and extend the mainframe.

2

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 15

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Benefits from comprehensive vendor support. Most tools and platform vendors support SOA in their toolsets.

Š

Aligns with state technology initiatives. SOA has been announced as the preferred technology direction at several levels within Nevada State government including Enterprise Information Technology Services (EITS) and within DWSS.

Implications: Š

Because SOA has broad vendor support, it is unlikely that selecting SOA will materially limit DWSS’ technology platform options.

Š

SOA will require some training of existing staff and/or acquisition of new staff with SOA skills.

Š

SOA in the context it is discussed here presupposes a layered system model, with system layers being devoted to responsibilities, such as presentation, business logic, and data access. Therefore, SOA should be considered to also include the concept of a layered system and/or an N-Tier system.

Š

Adoption of SOA will require sound SOA governance and associated best practices. Governance structures must be established to align IT service delivery with business strategy. At the core of SOA governance is the application of proper care and diligence to the SOA repository and registry. The repository will help assist in the managing of services and their associated artifacts through their full lifecycle—from planning, to development, to deployment. An SOA management tool may be required.

Principle: Leverage IV-A Architectural Direction and Technology Investment Principle: DWSS will follow and extend the architectural models and styles (as well as directly leverage any technology that is acquired to the extent reasonable) that are established by IV-A projects such as AMPS and upcoming Health Care Reform / Eligibility projects.

Rationale: Consistency of toolsets and architectural styles across different DWSS projects affords the Division efficiencies, helps to maximize technology investments, and can accelerate later projects by providing them with valuable assets to leverage.

Implications: Š

When technology investments are being evaluated for IV-A projects, such as the Health Care Reform / Eligibility project, the requirements of the IV-D agencies will also be considered.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 16

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Direction-setting projects, such as the Health Care Reform / Eligibility project, will include communication and knowledge transfer of the concepts, architectural styles, and patterns that are candidates to be emulated by later IV-D projects.

Principle: Incremental Improvement Approach Principle: DWSS will follow an incremental improvement approach to updating the IV-D system.

Rationale: Because of the fiscal situation in the State of Nevada, the Nevada State Legislature has clearly stated that significant funding to update the IV-D system will not be available in the near term. They have instructed DWSS to identify solutions for the IV-D system using existing program resources until such time that major investment in the IV-D system is possible. These factors make an incremental improvement approach the only sensible one for DWSS to follow in the near and mid-term.

Implications: Š

Since releases will likely be frequent, the “cost” (not dollars, but personnel time and business disruption) of releases needs to be kept at a minimum. Streamlined processes for releasing software to the user community will likely be required.

Š

An incremental approach is made easier by good regression-testing facilities, so that alreadyreleased code does not have to be exhaustively retested by hand. DWSS will need to focus on improving its IV-D system testing facilities with (potentially) additional test regions and facilities for capturing (and sanitizing) production data for use in testing. New test regions will require ongoing maintenance and may need associated support, including additional hardware and software licensing. Resource planning will need to address any additional emphasis on testing. Automated testing tools would be beneficial; however, if they cannot be procured, some amount of home-grown tooling (regression test “decks” and scripts) can be used in their place.

Principle: Develop a Shared Services Model Principle: DWSS will add shared and reusable components to the IV-D system that will be progressively leveraged by future code revisions.

Rationale: There are numerous shared facilities that are needed by a typical CSE system, including document generation and alerts management, as well as other more low-level facilities, all of which may become important parts of the IV-D system’s architecture (e.g., rules engine, workflow support, document management). As much as is possible, these shared services should be identified as shared needs and developed up-front, allowing later specific-functionality development to leverage these shared services. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 17

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Implications: Š

A shared services model will be facilitated by a modern programming environment, such as Java/ Java Platform, Enterprise Edition (JEE), EGL, or .NET. Appropriate facilities for building shared services are not supported by CSP / COBOL.

Š

When promoting a shared services model, it is important to explicitly identify the shared services that are needed up-front, and to be able to invest in their development even though initially no specific functionality is delivered through that development effort.

Š

Having identified a needed shared service, the requirements for the shared service should be considered broadly so the initial development does not have to be significantly rethought with each successive “leverage” of the shared service. (In other words: Build it “right” up front to avoid having to rework it every time it is reused.) At the same time, however, it is important not to over-engineer the initial requirements toward a goal of specifying the “perfect” shared service. The search for perfection can result in shared services projects taking too long and in some cases being unattainable. Some version of the “80/20” rule should guide the thinking here.

Principle: Leverage COTS Products Where Appropriate Principle: DWSS will leverage COTS (Commercial Off-The-Shelf) software products where they advance the IV-D system architecture, but will avoid customization where it restricts support and/or upgrade capabilities.

Rationale: Commercial off-the-Shelf Software (COTS) products that are of a “commodity” nature (relational database, rules engine, workflow engine, accounting package) offer a good cost/benefit profile. The development effort is amortized across many hundreds (or hundreds of thousands) of customers, enabling stronger, more configurable functionality to be built into the products at a lower per-user cost3.

Beware the negative corollary: you are necessarily paying for many features you will never use. But the net effect is still generally positive because you pay very little per feature, and the overall cost still benefits the customer.

3

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 18

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Implications: Š

Licensing and maintenance fees for COTS software can add up over time. It is best to consider the long-term cost profile of each product and determine that its existence in the architecture is justified.

Š

Similarly, many COTS products have a “mindshare” cost. Developers (and other staff such as testers, analysts, and sometimes even users) need to acquire knowledge about the product through training or direct experience in order to use them effectively. Such knowledge acquisition is not free and goes to the maintenance burden of the resulting architecture. It’s another reason each COTS must be fully justified in the overall architecture.

Principle: Sufficient Security Principle: To the extent practical, security will be maintained without inhibiting legitimate use or adversely affecting application service levels.

Rationale: Business efficiency is an important attribute of service delivery and should only be hampered when the risk and cost of a security breach warrants it. In the case of Nevada’s IV-D Systems, this means the systems shall adhere to standards such as IRS 1075.

Implications: Š

Controlling security standards such as IRS 1075 will need to be considered when designing security architecture.

Š

Additional security provisions will be derived through analysis of the risks and cost of security breaches, as well as the cost and impacts of security measures.

Š

State security requirements must be considered when designing security architecture.

Principle: Common Data Formats Principle: The electronic exchange of data will be accomplished using a standard set of formats and protocols based, where appropriate, on industry standards such as National Information Exchange Model (NIEM).

Rationale: Standard formats improve efficiency; increase integration and data interchange opportunities, and lower maintenance costs.

Implications: Data standards, such as NIEM, will be investigated as a primary protocol for data exchange. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 19

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Principle: Identify Controlling Data Principle: Key data structures such as Case and Person should have a single “authoritative” representation in the IV-D system. Where data are spread across multiple platforms (e.g., DB2 mainframe and Universal Database (UDB) server), they will be synchronized so that one source is always known to be authoritative and accurate, with the other following.

Rationale: Data proliferation and unmanaged redundancy tends to make maintaining, modifying, and testing the system more difficult and costly, leads to processing errors, and reduces the user’s trust in system information.

Implications: Š

There will be clear data ownership rules for key data structures such as Person, Case, and Employer.

Š

Data redundancy will be minimized and, when allowed, resynchronized against the ‘authoritative’ view of the shared data.

Š

Coordination among current data “owners” may require the establishment of clear Service Level Agreements to standardize the exchange. This may entail additional cost and may require coordination with stakeholders outside of DWSS.

Š

It may be necessary to involve help desk or other personnel as “data stewards,” whose job it is to safeguard one or more authoritative data resources (e.g., the recently formed “Employer Services” group).

Background: Plan Maintenance  The NOMADS CSE System Maintenance Plan and Modernization Roadmap document will guide and inform maintenance and modernization activities for many years to come. Periodically reviewing the document and making necessary updates is essential to its integrity. PSI recommends that DWSS assign a Document Owner from the Program. Ideally, the Document Owner will be the IV-D System Owner, which was one of PSI’s governance recommendations. The Document Owner is responsible for coordinating document updates. The Document Owner should review the document on an annual basis, whenever material progress is made against the modernization plan, and when material changes are encountered that impact document content. The Document Owner should follow the established document versioning practices when making updates. Each update should include saving the document with an updated name, and annotating the changes in the Document Information, Revision History. Below is a summary of the document sections and the anticipated maintenance requirements for each.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 20

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Executive Summary The Executive Summary will require little if any maintenance. It should, however, be included in the annual review of the document and modified when necessary.

Background The background information should be retained in its original form as it establishes a baseline for the project scope.

Needs Assessment Results The needs assessment results should be retained in their original form, as they capture important point-intime information that served as the foundation for much of the project direction.

Analysis Results The analysis results should be retained in their original form, but the TCSA should be annotated if material changes in the architectural direction for DWSS occur during the life of the project.

System Maintenance Plan The Maintenance Plan objectives and processes should be updated as necessary. The specific improvement candidates and current prioritization should not be updated within the document, since they change constantly; they should be maintained within the screening and prioritization tools developed as part of the Maintenance Plan. Trying to keep these items up to date within the document is redundant and unnecessary.

System Modernization Roadmap The system Modernization Roadmap should be updated when increments are completed, when increments are decomposed into more granular sections, when the proposed sequence for increment change, etc. The Roadmap should also be updated when changes to the funding plan occur, (e.g., when new funding sources become available).

Issues The issues section should be updated as appropriate.

Conclusion The conclusion section should be updated as appropriate.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 21

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

III. NEEDS ASSESSMENT RESULTS Introduction  The goals of the Nevada IV-D Systems Assessment project—to develop a IV-D System Maintenance Plan and a Modernization Roadmap—are directly dependent upon an objective assessment of program needs. To this end, PSI reviewed extensive background documentation, interviewed key stakeholder groups, and examined selected business processes. PSI held structured interviews with the primary IV-D system stakeholder groups including users, acquirers, developers, and maintainers of the system. An overview of these interviews and the concerns expressed by the primary stakeholder groups is presented below in the subsection entitled “Stakeholders and Their Concerns.” (A detailed listing of concerns expressed during these interviews is provided in Appendix B.) PSI also examined selected business processes that can be improved, if not transformed, through automation or system enhancements. Selected Child Support business processes that best illustrate these improvement opportunities are highlighted below in the subsection entitled “Business Process Analysis Results.” (A more detailed discussion of these processes and diagram of workflows is provided in Appendix D.) PSI synthesized: 1) information gleaned from background documents; 2) concerns echoed by stakeholders; and 3) deficiencies identified in the analysis of selected business processes in order to determine the most significant Program needs for the IV-D system. PSI then discussed these needs at length with DWSS/CSEP leadership. A synopsis of Program needs is presented in the subsection entitled “Summary of Program Needs.” Finally, PSI developed functional and technical system requirements based upon these assessment activities, and an understanding of the most significant Program needs. Requirements are framed as strategic conditions or capacities for the IV-D system. These requirements may in turn help inform a Federal Feasibility Study or a Request for Proposals to modernize/rewrite the IV-D system application. These requirement statements for a future, modernized IV-D system are presented in the subsections entitled “Functional Requirements” and “Technical Requirements.”

Needs Assessment Results: Stakeholders and their Concerns  This subsection provides an overview of the stakeholder interview process and the concerns expressed during these interviews. The primary stakeholder groups interviewed included: Š

Users of the system (State and county users including functional user groups comprised of line workers, attorneys, supervisors and/or managers, hearing masters, and program administrators)

Š

Acquirers of the system (DWSS and County Leadership)

Š

Developers of the system (including IT Leadership)

Š

Maintainers of the system (including IT Leadership, help desk, etc.)

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 22

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Users of the Systems The user groups listed below were given an interview guide (see Appendix A) in advance that provided them with project orientation information. They were also queried regarding their concerns about the IV-D system (a complete list of attendees can be found in Appendix C)

County & Regional State Operations: Š

Rural Counties

Š

Washoe County DA and Reno PAO Establishment

Š

Washoe County DA and Reno PAO Enforcement

Š

Clark County DA Establishment

Š

Clark County DA Enforcement and Location

Š

Clark County DA Audit and Court Team

Š

Clark County DA Customer Service

Š

Clark County DA Investigations and Service of Process

State Central Operations: Š

Case Registry

Š

Quality Control

Š

Financials and State Disbursement Unit

Š

Hearing Masters

PSI experienced a consistently high level of constructive participation among participants across these various interview groups. This level of cooperation and engagement was a welcome surprise in light of the adversity represented by an outdated IV-D system and prior studies affirming the system’s shortcomings. While participants across stakeholder groups were vocal in expressing their desire for a new system, they were, at the same time, accepting of the reality that, given economic conditions, significant improvements to IV-D system functionality might not be realized until farther into the future. A willingness to cope attitude was voiced by many participants to the effect of “NOMADS is the system we have and we will make the best of it.” While the individual user groups PSI interviewed may have differed in their emphasis of particular needs or concerns, the level of common concern was very high, far exceeding what one might expect given the varying caseload sizes, demographics, organizational structures, and deployment of staff. The articulation of unmet business needs, pain points, and wish lists echoed loudly across these user groups. These “user themes” have informed PSI’s understanding of program needs and future system requirements. Themes that echoed across IV-D system user groups included: Š

Difficulty using the system

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 23

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Unreliable system performance and availability

Š

Problems with automated IV-A referrals

Š

Incomplete or faulty financial management functionality

Š

Data override problems (e.g., addresses) associated with automated interfaces

Š

Lack of automation/functionality supporting core business activities and workflow

Š

Lack of management tools

Š

Problems with forms and forms management

Š

Inadequate support of customer service

Š

Questions about, or lack of, confidence in the process in regards to prioritizing, executing, and communicating about IV-D system work items

Š

Inadequate resources for training users

The specific concerns voiced by each IV-D system user group, including any concerns unique to a given user group, are listed in Appendix B.

Acquirers of the System General Description Acquirers of the System are those individuals and organizations responsible for providing the financial resources and funding the human resources needed to sustain and modernize the Nevada IV-D system. This group is represented by the following subgroups, which were interviewed (Appendix B includes a list of group members interviewed): Š

CSE Program Leadership

Š

CSE Participating County Program Leadership

Š

DWSS Leadership (Romaine Gilliland, DWSS Administrator)

All participants were asked to: Š

Identify their key concerns related to this assessment and planning project and any resulting implementation project(s)

Š

Provide input on the critical needs for a modernized CSE system

Shared concerns (themes) voiced across subgroups as well as those voiced by/unique to individual subgroups are highlighted below. A more detailed listing of these themes/concerns is provided in Appendix B.

Shared Concerns Shared concerns of the Acquirers of the System stakeholder group that were echoed over the course of the interviews included: NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 24

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Project: Š

Existing resources may be inadequate to implement the resulting plans or address critical technology issues in a timely manner.

Š

The resulting plans may be obsolete by the time they are executed.

Š

The resulting system may be even more fragmented.

Š

The current system development processes are a hindrance and barrier to progress.

IV-D System Needs: Š

More useable system

Š

More reliable/consistently available system

Š

More adequate case and financial management

Š

Greater management capability and more management tools

Š

More automation to improve performance

It is noteworthy that all of the county-leadership representatives expressed a desire to participate in, and contribute to, the resolution of these concerns and development of solutions that will meet these critical needs.

Individual Stakeholder Concerns Certain concerns or system needs were voiced by / unique to a single subgroup of the Acquirers of the System stakeholder group. These concerns and/or needs included:

CSE State Administered Program Leadership: Š

The disparity between State and county technical capabilities could be a barrier to implementation and deployment of future solutions and systems.

Š

Because basic business processes are not automated, individuals must remember to perform critical manual tasks or errors will occur.

CSE Participating County Program Leadership: Rural County Leaders:

Š

Standardized processes should be developed through collaboration, not through the adoption of a single operations practice, regardless of its size. Best practices should be solicited from higher performing operations.

Š

Communication (State, county, inter-county, intra-county, DWSS Information Systems (IS) should be improved.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 25

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Technology outsourcing should be considered for the purpose of better visibility, control, and results.

Washoe County Leaders:

Š

There is a need for consistent user interfaces, system capabilities, and common products for the IV-A and IV-D systems.

Š

There is a need to leverage current and future investments being made in the IV-A system for the IV-D system’s benefit.

Clark County Leaders:

Š

There are financial management deficiencies (provided specific examples where financial data is unavailable, unreliable, and/or unusable).

Š

Data from external interfaces (INTR) does not automatically populate the system; data is not automatically available to case workers.

Š

There are issues with how employer information is received and processed.

Š

Stressed that benefits of customer self-service are important.

DWSS Leadership: Š

The maintenance and modernization plans need to be actionable, realistic, and objective.

Š

The IV-D plans need to leverage current and future IV-A system efforts including AMPS and Health Care Eligibility.

Š

Consider allowing counties with resources to take the lead on technical / system initiatives.

Š

The resulting plans must indicate what can and cannot be accomplished incrementally with limited investment.

Š

In the long term, a full system replacement / rewrite may still be necessary, but it presumably will happen under better circumstances and from a stronger foundation.

Š

IV-D is a requirement of Temporary Assistance for Needy Families (TANF), which creates a clear linkage between IV-A and IV-D, so case management needs to cover both programs.

Š

At the foundation of NOMADS is an obsolete language (IBM’s CSP)—conversion to EGL is included as part of the Health Care Reform Eligibility Engine and a key element of extending the useful life of NOMADS.

Š

Leverage the progress made and further strengthen cooperative relationships with partners.

Š

Focus on improving services and collections through performance measurement.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 26

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Developers of the System General Description Developers of the System are those individuals responsible for delivering the updated NOMADS system and enhanced system functionality4. PSI broke this group down into the following sub-groups (Appendix B lists the individual group members interviewed): Š

DWSS IS Leadership

Š

DWSS developers including software developers, database administrators (DBAs), system engineers, and other personnel who have a direct responsibility for delivering functionality to users.

Š

Clark County Information Technology (IT) – includes developers (and their associated leaders) who augment the system through their own development efforts, and who may become more involved in delivering functionality to users in the future

Shared Concerns Developers voiced shared concerns over the course of numerous interviews and meetings (a detailed listing of these concerns is provided in Appendix B): Š

There is a need to make efficient use of scarce IT resources.

Š

There is a concern about the erosion of talent and institutional knowledge; staff retention is more challenging in the current environment.

Š

There is a need to provide adequate training for development staff.

Š

There is a need for access to current-generation development toolsets.

Š

The security of the sensitive data that the IV-D system maintains must be ensured.

Individual Stakeholder Concerns In some cases there were divergent concerns within the broader group, including the following:

DWSS IS Leadership

“Developers” and “Maintainers” are often the same individuals, as is the case in DWSS. However the “Developer” perspective is often somewhat different than that of the “Maintainer,” so it is useful to regard and discuss them separately.

4

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 27

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Because DWSS’s IS resources are shared by numerous agencies, their perspective is—by necessity—not focused exclusively on Child Support. This is further exacerbated by the fact that NOMADS is a shared IV-A / IV-D system. Risk mitigation and testing are very high on this group’s priority list.

Clark County IT Clark County is responsible for 70% of the statewide caseload and is dependent on the State-run system. The County faces challenges accessing underlying NOMADS data and delivering enhanced system functionality to its users. In addition to discussing these challenges, the Clark County Developers subgroup advanced a number of specific suggestions for system fixes/enhancements and tools.

Conclusion All of the Developer groups have a vested interest in delivering new and enhanced CSE functionality to users.

Maintainers of the System General Description This stakeholder group includes personnel keep the NOMADS system operating and ensure continued user access. Subgroups of this group included the following (Appendix B lists the individual group members interviewed): Š

DWSS IS Leadership

Š

DWSS Help Desk Personnel who provide direct support to IV-D system users across the State and are responsible for performing other “reserved” functions (e.g., adding employers to NOMADS and merging individuals).

Š

DWSS IS Developers who are responsible for assessing the root causes for system issues and / or failures, and correcting them

Š

Clark County Help Desk Personnel who provide first-level support to the county’s user community

Shared Concerns System Maintainers voiced shared concerns over the course of numerous interviews and meetings, including the following (a detailed listing of these concerns is provided in Appendix B): Š

System stability and availability is important.

Š

Access to scarce developer resources to solve maintenance problems is a concern.

Š

Erosion of talent and loss of institutional knowledge in the wake of staff turnover and incomplete system documentation is also a concern.

Individual Stakeholder Concerns There were divergent concerns within the broader group, including the following:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 28

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

DWSS IS Help Desk Personnel: Because the DWSS IS help desk is a shared resource that supports multiple agencies, it is necessary to balance priorities and build knowledge in order to effectively serve the entire customer base. When break-fixes occur, which take priority, “routine” operational work (e.g., person merges) can pile up, leaving users frustrated.

Clark County Help Desk Personnel: Clark County feels the issue of access to developer resources is especially acute, since they are in a different organization and geographically removed from the DWSS developer staff upon whom they must rely. This subgroup also manages a somewhat different portfolio of applications than the DWSS help desk, including applications that DWSS does not support.5

Conclusions The Maintainers stakeholder group shares collective responsibility for ensuring the IV-D system and server applications remain available for Child Support program users. This group’s key concerns included the robustness and stability of the NOMADS system, and resource availability to fulfill their charge.

Needs Assessment Results: Business Process Analysis  

Methodology PSI identified business process improvement opportunities through the review of documentation, interviews with system stakeholders, a demonstration of the IV-D system issues, and consideration of Child Support best practices. PSI targeted a subset of primary business processes6 to illustrate significant opportunities to improve process performance and efficiency through IV-D system modernization. Primary process deficiencies and improvement opportunities are summarized below. For a detailed description and diagram of processes, and a complete discussion of these automation opportunities, see Appendix D.

Business Process Analysis Summaries IV-A Intake and Assessment The goal of the IV-A Intake and Assessment Process is to establish a IV-D case, and initiate appropriate Child Support services for IV-A (TANF) referrals. Automatic referrals received from the Title IV-A (TANF)

5

Because they were developed independently by the County.

6 It is important to note that this analysis was not intended to provide a detailed analysis and redesign of all child support processes as might otherwise be appropriate in a Business Process Reengineering (BPR) study.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 29

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

agency often lack the correct demographics and identifiers for case participants. Incomplete NCP1 screens cause significant delays in the processing of IV-A Child Support cases as well as a disproportionate consumption of Child Support caseworker and IT resources. In addition, the automatic overlay of IV-A, and other automated interface data on top of Child Support data, contributes to inaccuracies in the Child Support case record. There is an opportunity to significantly improve the quality of demographic and identifying information that accompanies the automated IV-A (TANF) referral. This improvement will be effected by 1) collaborative development by IV-D and IV-A of policies and procedures that provide an incentive for IV-A workers to complete a quality referral; and 2) automatic editing of referral screens in support of these policies and procedures. Finally, a modernized IV-D system should also be able to prevent an outdated, previously invalidated address from being automatically read as a good address.

Locate The goal of the Locate business process is to determine and verify the physical location and employer of, or other information regarding, the non-custodial or custodial parent for the purpose of establishing paternity or establishing / enforcing a Child Support order. Staff charged with performing locate tasks is less productive as a result of IV-D system shortcomings. Staff must access and enter data on an extensive number of screens that are not well designed for this purpose, and apply locate tools that are not well integrated. The system also lacks effective locate alerts, and often mistakes outdated information for new information. The flow of locate activities is not effectively managed by the IV-D system. There are significant opportunities to improve efficiency by standardizing and supporting locate activities through automation. For example, the system should automatically generate system locate requests based upon appropriate case status or activity based criteria. Furthermore, the system should automatically monitor locate responses, set follow up reminders, and proactively present responses in a single place, and in a logical, user friendly manner that facilitates screening by locate workers.

Case Initiation-Support Order Entry The goal of the support order entry process is to input accurate information in the system so the amount owed is calculated correctly on the case from the start. The IV-D system is not able to handle the complex terms of support orders and, as a result, users must audit a case’s financial records frequently to ensure enforcement remedies are not being pursued improperly. The system needs to support the terms of complex Child Support orders and appropriately build the debit side of the case financial record.

Enforcement: Driver’s License Suspension The goal of the driver’s license suspension process is to compel a noncustodial parent in arrears to pay Child Support on a regular basis under the threat of having his/her driver’s license suspended. Cases that meet suspension criteria are selected manually; the process is initiated manually; notices are generated manually; and cases are monitored manually. The IV-D system needs to maintain accurate balances on a case so the system can automatically identify cases that meet the selection criteria; the system then must automatically generate and mail the notice of intent to suspend. An accurate balance is further required for the system 1) to identify a case remaining in noncompliance in order to automatically generate the notice of suspension; and 2) to continue to monitor the case for compliance in order to automatically generate the notice to reinstate.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 30

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Enforcement: Income Withholding The goal of the income withholding process is to establish regular payment compliance through the cooperation of the employer community to withhold and remit Child Support payments from employees’ incomes. Reportedly, some location “hits” for employers that should have been treated as verified are mistakenly coded by the system as “completed”. When information is available that verifies a noncustodial parent no longer works for an employer, the IV-D system does not send a notice to stop withholding. The system should automatically send income withholding notices to verified employers and a notice to stop withholding to an employer when the system receives verification that the noncustodial parent no longer works for the employer.

Enforcement: Show Cause and Contempt of Court The goal of the show cause and contempt of court process is to compel a noncustodial parent in arrears to pay Child Support under threat of being arrested, subsequently needing to post a bail bond, or going to jail. The IV-D system is not proactive in identifying cases that qualify for a show cause or contempt action. When the court determines that the noncustodial parent still has not complied with the support order, the judge may order and issue a bench warrant. The warrant process is paper intensive and inefficient. The system should present cases qualifying for show cause to users with background information regarding the case’s circumstances so users can decide whether to pursue this enforcement action. The system should enable users to track the status of the service of process packets and bench warrants to eliminate the doubleentry of data. Furthermore, users should only have to scan documents one time; and the system should transmit the electronic files to all of entities requiring them.

Financials: Adjust Amount Paid The goal of the adjust amount paid process is to correct a case’s financial payment record. It is difficult for users to take an organized approach to working, or to treat a case holistically, because the system generates multiple types of undistributed collections reports. Some payments that go into undistributed collections should have been distributed, and users currently have to correct system errors manually. Accounting controls for payment adjustments are inadequate. The system should issue a comprehensive report of undistributed collections for a user’s cases. The system should also be able to discern when a payment should be distributed or should go into undistributed status in order to reduce the number of errors that need to be corrected manually. The system should support stronger accounting controls (e.g., second level approval) for the release of undistributed payments and the approval of refunds.

Financials: Payment Processing, Disbursement, and Reconciliation The goal of the payment processing, disbursement, and reconciliation process is to process and post payments to the IV-D system/LOTW efficiently, disburse the payments timely, and maintain accounting controls over payments received and disbursed. System limitations require employers to submit separate payment instruments for Child Support and fees. The reconciliation of receipts and disbursements is labor intensive. The receipts and disbursements reported on the IV-D system/LOTW do not balance with the receipts and disbursements that are recorded on the state financial accounting system or the State Collection and Disbursement Unit’s (SCaDU’s) bank account statement

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 31

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

CDS (Collection and Disbursement System) should be able to distinguish between the fee amount and the Child Support amount in the same payment instrument so employers only have to issue one payment. The system should apply the same policy throughout for determining the date of receipt for a payment posted to the system. The IV-D system/LOTW should provide sufficiently detailed reports that automate some of the reconciliation steps. The IV-D system/LOTW should also provide accounting staff with all information they require to complete the reconciliation.

Customer Service Customer Service is not a separate federally mandated Child Support process, but it is a vital function discreetly managed to support efficient program administration and provide maximum customer satisfaction. Effective customer service in Nevada, whether offered by a separate customer service unit or by Child Support staff with more broad case management functions, depends on the ability to access information in the IV-D system. The inability to quickly find requested information in the system, or the reluctance to trust its accuracy, forces staff to spend more time researching routine case information, or passing the routine inquiry on to others. The system should readily provide understandable, summarized case information to staff performing customer service in order to reduce the overall customer service burden across the program. Improved facilities that would enable customers to securely access accurate case data directly through the Interactive Voice Response (IVR), and through newly developed Web-based interfaces (online and possibly through appropriately placed kiosks) would significantly reduce the customer service burden, and leave more time for staff to perform casework/more complex duties.

Conclusion Examining how a sampling of basic Child Support business processes are negatively impacted by system deficiencies sheds additional perspective on opportunities to enhance services and results through system improvements. PSI’s previous interviews with stakeholders pointed to an array of IV-D system weaknesses. However, the “pain points” identified by users were often relatively isolated in focus; i.e., they were expressed in terms of frustration associated with attempts to complete a particular activity or step within a business process or functional area. PSI’s analysis of selected business processes further informed the identification of business needs and strategic requirements for IV-D system modernization.

Needs Assessment Results: Summary of Program’s Needs  PSI synthesized: 1) information gleaned from background documentation; 2) concerns echoed by stakeholders; and 3) deficiencies identified in the analysis of selected business processes to determine the most significant Program needs for the IV-D System. This section presents a synopsis of these needs. It is clear that the current IV-D System is failing to meet the Program’s needs in very real ways. The key needs that have been identified are listed below.

User Interface The current IV-D system mainframe application has a dated and very limiting user interface. Users find it counter-intuitive to find information. They also report that it is difficult to navigate the system due to there being so many screens. A number of screens require codes that users must enter or look up, impairing their productivity and their ability to respond quickly to customers. The system is also designed to require duplicate

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 32

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

data entry often, which frustrates users by creating extra work and an increased risk that data will end up out of sync.

Data Edits The IV-D system also does too little to prevent “bad” data from entering the system. There are numerous examples of how the system allows data to be input, which, through its entry, causes negative downstream effects, such as creating more work for the user, disrupting or halting case processing, or otherwise creating negative outcomes. Users report an inordinate amount of time is spent “checking up” on the system and determining whether it processed the case correctly.

Workflow Support The current mainframe system offers little in the way of workflow support, where the system would identify the appropriate next step that should be taken and assist the user in completing that step. Users feel it is up to them to “move” the case along, and that the system could and should be doing more to automate those processes. At the same time, users expressed caution about attempts to implement a one-size-fits-all workflow. The variety of detailed business practice and work-management models that exist across the offices demands that any business process that is system-enforced must also be flexible and able to adapt to varying in-office realities.

Accurate Financials The financial subsystem of any Child Support system is complex. Users report that the financial data in the IV-D system is often inaccurate and incomplete - that they have difficulty trusting the data at all. Many users report spending an appreciable amount of time recreating financial statements that the system already produces because the system-generated version is so inaccurate. The financial subsystem is also not sophisticated enough in many ways, and doesn’t map correctly to State policy and practice. For example, when a non-custodial parent (NCP) has two cases and one is closed, subsequent payments won’t be applied to cases but will instead begin accumulating in “undistributed.” This is a good example of the mismatch between the system’s implementation of business rules and the real-world expectation.

Management Capabilities and Reports The current system also offers little in the way of usable management tools and reports—the kind of capabilities that allow supervisors, case managers, and caseworkers to monitor performance, proactively manage their caseload, and prioritize their activities.

System Availability There is also a perception that the system is unavailable for significant periods of time, enough so that it materially affects users’ ability to complete their work. Month-ends, year-ends, unanticipated downtime, and daily slow periods due to congestion all affect users and harm their overall productivity.

Work Prioritization Users report that the current process for prioritizing, processing, and communicating with the user community about work items (enhancement requests) is effectively broken. While this is not directly a system NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 33

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

issue, it factors significantly into users perception as to the sufficiency of the current system. There is a strong feeling that the current process does little to deliver system improvements that address users’ needs, and, as a result, the system becomes less and less functional for users over time.

Summary This synopsis of the needs presents a clear picture of a system in need of significant attention, and the most critical areas that need to be addressed. It is a big list and nearly every element of the current system comes into question as needing some form of remediation.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 34

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Needs Assessment Results: Requirements  The Functional Requirements and Technical Requirements subsections below distill and translate the concerns and aspirations echoed in the stakeholder interviews (Users, Acquirers, Developers and Maintainers) and the deficiencies identified in select business processes into a set of requirements that define what needs to be modified in the current IV-D System. These requirements help form the basis for the TCSA, which is a description of the system that is needed to replace the current IV-D Systems. The TCSA will, in turn, be used to develop the all-important System Maintenance Plan and System Modernization Roadmap artifacts, which are the key deliverables of this project.

Functional Requirements In undertaking this assessment of requirements, it was not PSI’s intent to create a comprehensive inventory of all IV-D system functionality. Rather, based on the needs assessment, PSI focused its efforts on identifying the strategic opportunities for system modernization which (along with/based upon the critical technical requirements identified below) will help drive incremental modernization and the target conceptual architecture. The functional requirements are presented as high level statements of the currently unaddressed or underaddressed business needs for the IV-D system. In considering the future system’s strategic functional requirements, the federal program requirements have been taken as givens that must be maintained or, where currently deficient, addressed in system maintenance or modernization plans. In summary, this outline of high level requirements reflects the primary areas for system improvement, not the low level requirements that would be expected to be elicited in joint application design (JAD) sessions or other detailed requirements gathering exercises. These strategic functional requirements will be addressed either by the modernization or Maintenance Plans, or both, consistent with the objectives of these respective plans.

Federal Requirements The Federal Office of Child Support Enforcement (OCSE), under the auspices of the Department of Health and Human Services (DHHS) oversees the Child Support Enforcement program. Enforcement program nationwide and establishes requirements for state programs as well as the automation that supports these program. DHHS and OCSE have developed the Automated Systems for Child Support Enforcement: A Guide for States (the Guide) that outlines specific, state-level, CSE system requirements that systems must meet for federal certification. Accordingly, the modernized the IV-D system must meet the current federal certification standards and requirements.

Nevada Requirements It should be noted that while user groups were invited to prioritize their needs and concerns, this outline of system improvement requirements is NOT ranked or in any order of priority. Each enumerated, higher-order requirement is illustrated by representative examples of business needs (italics) that were derived from PSI’s needs assessment and from PSI’s knowledge of modern Child Support systems.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 35

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The IV-D system’s availability and performance must support consistent worker productivity: Š

The system should be consistently available during business hours.

Š

The response time of the system should hold to industry standards and enable worker efficiency on a consistent basis during business hours.

Š

The system should be available to users for planned special projects during “off hours”.

The IV-D system’s user interface must be intuitive and support efficient user navigation and information retrieval: Š

The system should have a single sign-on to an integrated interface that enables a user to sign on once and navigate any part of the system to manage their caseload or complete their work.

Š

The system should set time-out thresholds that do not disrupt the normal pace and flow of a user’s work. Ancillary applications should have similar time-out settings.

Š

The user interface should be highly intuitive to facilitate efficiency as well as expedite the proficiency of new staff: ƒ

The system should provide a common look and feel for navigating all applications and screens.

ƒ

Navigation and transaction prompts should be consistent across all screens.

ƒ

Field requirements for the same action or value should be more intuitive and consistent across screens and applications. (The system should not require the user to memorize an extensive number of non-intuitive, arbitrary codes to perform actions or enter field values.)

ƒ

Data entry screens should allow mistakes to be corrected in-flight without loss of data.

Š

The system should not require users to enter the same piece of information more than once, regardless of where that piece of information may be displayed on the system. The system should populate equivalent data fields after the initial automated or manual data entry.

Š

The system should support discreet business functions and associated business processes. Users should be able to execute these functions by navigating a reasonable number of logically presented screens.

Š

The system should have a summary screen that includes a digest of all relevant information on a case for quick access and review.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 36

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

The system should provide for efficient retrieval of all person information and related cases and case data from a person search.

Š

The system should organize case notes for easy readability.

Š

The system should have robust editing capability to facilitate data entry standardization and reduce data entry errors.

Š

The system should provide users with a variety of help and support options that enable them to understand and use the system more efficiently. Reference information should be easily accessed and consistently maintained.

Š

The system should not presume the gender of the custodial and non-custodial parent.

Š

The system should allow users to view images of payments (checks) processed through SCaDU without intervention from the Help Desk.

The IV-D system must utilize and support imaging and document management technologies: Š

The system should use a single document imaging/scanning facility and indexing should be coordinated for all functions.

Š

The system should only require that documents be scanned once. The system should be capable of transmitting electronic copies to any other entity that has a just cause for viewing the document.

Š

The system should provide a robust and user friendly document generation capability, automating the accurate completion of forms from system data where appropriate.

Š

The system should provide for the electronic filing and recording of court documents.

Š

Document management capabilities should be integrated with workflow management capabilities.

The IV-D system must support program goals and objectives by providing an automated management tools for assigning, monitoring, reporting and auditing casework: Š

The system should provide management tools to automatically assign, track, and readily reassign cases/tasks in order to balance workloads and availability of resources.

Š

The system should support the distribution of cases by all functional specializations.

Š

The system should have a built-in monitoring process to conduct quality control and quality assurance audits in support of federal reporting requirements.

Š

The system should provide an indicator for each case as to the case’s status within its assigned functional area in order to enable pulling and managing cases with specific status values.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 37

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

The system should provide a facility to complete accurate case pulls for audits and include a filter for closed cases.

Š

The system should provide better utilities for inputting and tracking audit results.

Š

The system should support caseload stratification.

The IV-D system must provide robust and flexible reporting: Š

The system should provide ad hoc queries, standardized reports, and regular management reports for in-state program monitoring and Federal compliance reporting.

Š

The system should monitor and report the productivity of programs/offices, units, teams and individuals.

Š

The system should provide role based access to productivity and other business intelligence data to support proactive caseload management.

Š

The system should allow supervisors to be able to track a user’s productivity and the volume of tasks waiting to be completed.

Š

The system should make business intelligence reports accessible to users on line, on demand.

The IV-D system interfaces must generate and populate useful, accurate information and the system must present that information to the user, all in a manner that advances Child Support casework: Š

The system should be populated with accurate information received through its automated interfaces with other systems

Š

The system should facilitate the transmittal of data between itself and the systems of program partners, such as court calendaring systems and court order registries.

Š

The system should present an efficient user interface with OCSE’s Child Support enforcement network (CSENet), such that transactions are processed promptly, interstate information is loaded timely, and tasks are assigned to appropriate user.

Š

The system should support a business process that promptly updates additions and changes to data tables with third party information, such as employer information and other states’ contact information.

Š

The system should be able to determine which information received through an interface is valid and relevant to the case and present this information to the appropriate user in a timely manner.

Š

The system should utilize the same location interfaces for custodial parents that it utilizes for non-custodial parents.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 38

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The IV-D system must maintain valid locate records. Š

The system should effectively maintain address information and prevent the override of good address information.

Š

The system should be able to discern when a new location “hit” is a duplicate of a location “hit” that has already been verified to be valid or not.

Š

The system should facilitate the efficient inactivation of locate records that have been determined to be invalid.

The IV-D system must support reliable IV-A and IV-E referrals and updates: Š

The system should require IV-A’s legitimate completion of fields required by the IV-D program before an electronic referral can be executed.

Š

System edits should prevent the referral of IV-A cases that are incomplete.

Š

The system must have a more intelligent pairing, if not separation, of IV-D and IV-A applications so that information in one system does not over-write valid data in the other system.

Š

The system should interface with the IV-E automated system so that it receives referrals of foster care cases.

The IV-D system must have workflow management capability to automatically move the case to the next activity or business process or, when appropriate, present relevant information to the user to manually move the case: Š

The system should recognize all primary functions/specializations (i.e., intake or interstate) and be capable of routing work accordingly.

Š

The system should provide a status indicator for each case as to assigned functional area and status within that functional area. For example, establishment cases with service packets out, service perfected, or no legal pleading.

Š

The system should, where appropriate, automatically move the case to the next business process or process activity based upon business rules.

Š

The system should present relevant information to the user for pursuing the next process activity and then guide and prompt the user to perform necessary manual tasks while automating tasks that do not require worker intervention.

Š

The system should automatically monitor time limits associated with business activities.

Š

The system should proactively monitor work progress and prioritize work activities based on case circumstances.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 39

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

The system should automatically monitor timeframes for completing required activities and then prompt the user for timely follow up on activities yet to be completed.

Š

The system should prompt the appropriate user assigned of relevant information on or to complete a task on a case regardless of whether the user “owns” the case.

Š

The system should provide a manageable number of notifications that are content specific, prompt the user to initiate the proper task, and are linked to relevant information necessary to complete the task.

Š

The system should organize worker notifications in a rational order of priority.

Š

The system’s notification functionality should include distributing options.

Š

The system should be able to track the status and location of petition packets and service of process packet, and allow users to update the status as these packets are prepared, reviewed, and delivered.

The IV-D system must have a robust financial management component that maintains an accurate accounting: Š

The system should: ƒ

Have full accounting controls

ƒ

Have appropriate separation of duties

ƒ

Facilitate the timely resolution of payment exceptions

ƒ

Enable the adjustment of payments, amounts owed, and balances

ƒ

Post and distribute all types of payment

ƒ

Make certified financial data available to clients and the public while maintaining appropriate confidentiality of data

ƒ

Enable complete and efficient reconciliations of payment receipt, adjustment, and disbursement data

ƒ

Facilitate the set up and collection of fee and recovery debts

Š

The system should accommodate the terms of complex support orders, particularly for support orders that charge interest differently than what the interest statute has typically been interpreted to allow.

Š

The system should accommodate entry of periods of suspension of support and future adjustments that are specified in a support order, and then the system’s record of the

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 40

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

amount owed must automatically reflect these suspensions and adjustments as they come current. Š

The system should apply the same date of receipt policies to all payments recorded and displayed anywhere on the system.

Š

The system should apply the same date of accrual policies to all periodic and lump sum judgments recorded and displayed anywhere on the system.

Š

The system should maintain an accurate accounting of all payments, credits, the overall unpaid balance on a case, and assigned support balances without regular human intervention.

Š

The system should provide reliable payment histories and account balances and generate notices to non-custodial parents for past due support.

Š

The system should enable disbursement of payments from a case to multiple states for final distribution in accordance with the state’s policies for the distribution of current support and arrears.

The IV-D system must support effective, efficient customer service: Š

The system should provide a secure Web, phone, kiosk based interface for Child Support customers to obtain basic information without program staff intervention.

Š

The system should enable parties to a case to perform “self-service” activities like applying for services, accessing case and financial information, accessing program information, and providing changes to case information, such as address changes.

Š

The system should enable non-custodial parents and employers to remit payments online and by other electronic self-service means.

Š

The system should utilize auto-generated customer mailings and phone calls.

Š

The system should have reliable summary screens for workers responding to customer inquiries.

The IV-D system must employ consistent program security standards: Š

The system should restrict access to conflict of interest and confidential cases based on user identification.

Š

The system should utilize consistent operational standards in the areas of application behavior, access to screen functionality, security roles, and data confidentiality.

Technical Requirements PSI’s Technical Needs Assessment identified numerous concerns, limitations, and deficiencies with the current IV-D system. Additionally significant technical, financial, and organizational impediments exist, which

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 41

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

combine to make the system maintenance and modifications necessary to address these issues increasingly difficult, costly, and risky. It is clear from this assessment that DWSS should aggressively pursue a Maintenance Plan designed to stabilize and tactically enhance the current system, enabling it to remain viable while an incremental modernization effort is initiated and executed. It is only the combination of these two actions that will make it possible for DWSS to provide the CSEP with the vital system services and capabilities required for efficient and effective performance. In support of developing these two actionable plans, PSI’s Needs Assessment has identified the following critical requirements that must be satisfied to ensure the system’s viability and/or enable DWSS to fulfill the functional requirements presented above. These technical requirements are sorted into the following categories, which is discussed in detail below. Š

Architectural / Foundational. Needs having to do with the underlying platform and framework upon which IV-D functionality will be built.

Š

Security. Needs having to do with security, including tools, processes, protocols, and architecture

Š

Supplementary Technologies, Infrastructure, and/or Components. Specific technology additions that will provide some key capability and/or improvement

Architectural / Foundational This category includes needs related to the underlying platform and framework that will enable the delivery of IV-D functionality to users:

Migrate Away From CSP IBM’s CSP is an outmoded and no-longer-supported programming environment which presents several drawbacks to the State of Nevada: 1) it is difficult to find resources trained in CSP 2) it is not a highlyproductive development environment and 3) it is risky to continue to use it, as it is no longer supported by IBM and may cease to work with some future operating system upgrade.

Develop a Unified Database Model Currently the IV-D system has a distributed database model, with a subset of data stored on DB2 in the mainframe, and a wider set of data stored on UDB on AIX. For data that exists in both locations the mainframe is the “controlling” database, push-replicating its data down to the UDB database on a frequent basis. For data that exists only in the UDB database, that database is the controlling database. This presents a more complex database scheme than necessary, and there is significant effort involved in keeping the arrangement working. Processing time goes to keeping the two databases in sync, and DBA / engineering time is spent keeping the databases set up to replicate to one another. The multiple data scheme also affects developers, as they must understand in which database certain data exist, and take care to read from the right location for the data they are interested in. Replication lag also makes reading data from the UDB database more problematic and less reliable. The replication scheme also NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 42

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

makes updating the database more difficult from the “Server” (non-mainframe) side. The developer must be mindful of the “controlling” database whenever they write update statements. Cross-database updates can get tricky and are impossible to put under database transactional control. A unified database schema will remove these problems and significantly simplify development.

Adopt a Service-Oriented Architecture The IV-D system is brittle in its construction, and does not have the clear separation of concerns that is typical of modern software development Best Practice. An architecture based on best-practice SOA will encourage code reuse and provide the State with greater options for system enhancement and integration.

Create a Business Logic Hosting Layer At the same time as the IV-D system is adopting an SOA, it will be necessary to identify a layer in the system that is responsible for hosting business logic, and to establish patterns for how the layer supports that responsibility and interacts with the other layers (typically Presentation and Data Access). This will create the foundation for progressively migrating business logic from its current location (inside screens and batch programs) to a new, more maintainable setting

Refactor and Relocate Business Logic The IV-D system consists of millions of lines of CSP code7, split approximately evenly between batch and online. This body of code represents the business logic that the IV-D system implements, and that is proving increasingly difficult to maintain and extend. Ultimately a more modern IV-D system will have to deal with a migration of this code to a new platform and new architectural paradigm (SOA instead of simple data-in / data-out module construction).

Remove (or Reduce) Coupling Between IV-A and IV-D While the integration of IV-A and IV-D has some benefits, the overwhelming consensus is that the IV-D system mainframe intertwining of IV-A and IV-D functionality and data no longer serves the IV-D agency. There are many negative effects, including impacts on IV-A when IV-D updates the system (and vice-versa), incorrect data semantics (e.g., IV-A updates removing data that is significant to IV-D (and vice-versa), and extended processing times due to a monolithic database structure (that could be sub-divided). Note that this does not mean that the link between the systems is severed. As the systems are separated from one another, the functional elements that must be communicated across the IV-A / IV-D system boundary will be moved to being communicated by a standard system interface (or something functionally similar).

7

These code counts are approximate and count generated artifacts such as data blocks and comments.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 43

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Optimize Mainframe Capacity As long as the mainframe continues to be the foundational part of the IV-D system architecture, it will require long-running batch cycles that limit system availability to users. Continued optimization of the mainframe’s capacity is a necessity. This may be accomplished by some combination of offloading non-active data, spot-optimizing (or rewriting) critical batch jobs, and increasing the mainframe’s raw capacity with upgrades.

Security The key needs centered on improving data security in the system include:

Restructure the Database with Security in Mind Previous IRS reviews of the IV-D system’s security have documented issues with the system’s protection of federal tax information (FTI). The database should be restructured to either segregate highly-sensitive data into specific groupings that can be more closely audited and protected, or an architectural “layering” scheme should be put in place to specifically implement the stratification and data segregation that IRS 1075 / National Institute of Standards and Technology (NIST) 800-53 requires.

Develop a Single User Repository Supporting Roles-Based Access Controls As with many mixed legacy / newer-generation systems, the identity and access management scheme in place in the IV-D system is distributed. All mainframe-specific access controls are being handled by RACF security on the mainframe and all remaining security authorization are being managed by a Novell-based user repository. This creates a fractured setup, allows inconsistent permissions to be defined, and creates more work than is necessary to maintain credentials. A modernized IV-D system should leverage a single user repository, or at a minimum, a federated model with replication of credentials among the constituent repositories.

Supplementary Technology, Infrastructure, and/or Components The needs in this category are centered on technologies that the current the IV-D system does not currently have access to. Some specific items that were identified in this category include:

Implement a Rules Engine Rules engines are key pieces of technology in many modern systems because they can help solve problems that are very difficult to tackle in typical procedural languages. In Child Support, examples of problems that can be more easily solved with a rules engine are financial distribution and applying enforcement remedies.

Implement Data Warehouse Tools Data warehouse and business intelligence (BI) tools will allow for providing better management reports to supervisors and Program management while, as a technical matter, unburdening the transactional database with the need to keep data around that is strictly needed for reporting . Data warehouse tools and data warehouse Best Practice help to define a clear separation between the needs and responsibilities of the transactional database (the database that manages those data that flow through the system in the normal course of processing Child Support business transactions) and the reporting database (the database that supports reporting, and has facilities for trending, data analysis, and point-in-time snapshots of data).

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 44

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Adopt Current-generation System Integration Toolsets. There are a host of specific technologies that have been discussed as having demonstrable benefit to a modern IV-D system’s ability to interact with other systems, including: Š

Web Services. An ability to securely interact, often real-time, with other systems via standard Internet protocols such as HTTP and XML.

Š

SOA. SOA is a different architecture style that embraces concepts of code modularization and reuse by focusing on the creation and consumption of Services as the basis for most or all of the business logic in the system.

Š

Enterprise Service Bus (ESB). ESB is a closely-related concept to SOA (and is almost never implemented outside of a SOA), but one that specifically focuses on building a “bus” inside of the architecture that handles data transformation on the “edge” (when receiving data from or sending data to outside systems). Its main point is to insulate the business code from the specifics of the data-packaging format by creating a buffer between them—the ESB.

Š

Consistent and Feature-Rich Document Generation Tools. There are currently several “flavors” of document generation being used in the IV-D system today. These multiple methods of accomplishing the same basic task results in inconsistent feature sets, additional development effort, and user frustration. Getting down to a single document generation tool that supplies a suitable set of features would reduce the development burden on IT staff and reduce the frustration of missing features in users.

Adopt Additional / Improved Developer Toolsets There are numerous specific tools / capabilities that the development group has noted are lacking, and which, if provided, would materially improve DWSS’ ability to support users. These include: Š

Version Control. At one time, DWSS had access to a version control tool for mainframe code named PanValet. That tool is no longer available, so for mainframe code DWSS has resorted to a set of home-grown tools based on the Rexx scripting language and other locally-built tools. The Rexx routines are becoming less and less sustainable, creating a risk for continued mainframe source control integrity. DWSS uses a tool called Perforce for version control of distributed applications, which may also represent a suitable sourcecontrol tool once a conversion, from CSP to some other language, is accomplished.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 45

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

System Documentation Repository and/or Tools. While the state of the IV-D system documentation is acknowledged to be sub-standard, the situation is worsened by the fact that what documentation exists is stored in a variety of locations, with redundancy and inconsistent naming / indexing schemes. The net result is that even when documentation exists it is not likely to not be found by technologists who need it (and so might as well not exist).

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 46

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

IV. ANALYSIS RESULTS The analysis phase of the project succeeds the needs assessment phase and precedes the planning phase. The analysis results are presented in this section of the document and include a description of the current or “asis” technical architecture. They include identified functional and technical gaps between the current system and the desired modernized system based on requirements identified during the needs assessment. The analysis results provide a TCSA and a validation that the TCSA addresses system requirements. The analysis results also include an assessment of the current IV-D systems governance and a set of recommendations for improvement in support of ongoing system maintenance and modernization. Finally, the analysis results include an assessment of the financial resources currently available to the program. The analysis results build upon information gathered during the needs assessment and lay the foundation for the ongoing Maintenance Plan, Modernization Roadmap and funding plan that are described in the planning results section of the document.

Analysis Results: As‐Is System Architecture  

Background The NOMADS project began in 1988 with a feasibility study completed by the accounting firm of Ernst & Young. The federal government mandated all states develop and implement a statewide-automated CSE system and request federal certification by October 1, 1995. The federal mandate, along with recommendations from the Ernst & Young study, resulted in Nevada's decision to pursue federally certified systems for the major Welfare Division programs: Child Support, Food Stamps (now SNAP), AFDC (now TANF), Medicaid Eligibility, and Employment and Training. In 1992, DWSS released a Request for Proposal (RFP) to secure vendor bids for developing and implementing the system. As federally required, a certified system from another state would need to be transferred and then modified to meet Nevada's needs. Nevada is the only state that chose to develop a fully integrated CSE and Welfare database. Integrated Systems Solutions Corporation (ISSC) was the successful bidder and began work on October 1, 1992. The Child Support component of NOMADS was acquired as a transfer system from the State of Rhode Island, but the code was completely rewritten from NATURAL to CSP. The system was completed and federally certified in 2001. NOMADS currently supports Child Support, SNAP, TANF, Medicaid eligibility, and Employment and Training at DWSS. NOMADS is a monolithic mainframe application, written in IBM’s CSP and COBOL, and uses a DB2 database. The Nevada EITS hosts and maintains the NOMADS infrastructure and the DWSS maintains the NOMADS application. Since its certification, DWSS and County based Child Support organizations have added a series of Web-based and client/server applications to provide needed user functionality. The current DWSS computing environment is illustrated below in Table 3 Table 3: Current Computing Environment DWSS Current Computing Environment (As of 4/15/2011) Description

Name

NOMADS CSE System Maintenance Plan & Modernization Roadmap

1-Year Expectations

Page 47

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

DWSS Current Computing Environment (As of 4/15/2011) Description

Name

1-Year Expectations

Database Management Systems

DB2 FOR ZOS 9.1

DB2 ZOS 9.1

UDB 8.2.2 FOR DISTRIBUTED ENVIRONMENT

UDB 9.5

Computing Platform

AIX V5.3/Windows 2003/ Z/OS V1.7/

AIX V6.1

Network

TCP/IP, WAN, Cisco, Novell

NC

Storage

1 Terabyte

NC

Application infrastructure

JAVA 1.4, MVC, JEE, COBOL, CICS, CSP V4.1, some JAVA 6

JAVA 6

Security

Novell Access Manager v3.1.4

Novell Access Manager (current patch level)

Utilities

iLOG jRules Windows 2003 V 6.1.6*

iLOG jRules Window 2003 V 6.7

Rational Application Developer (RAD) Windows XP V 6.0.1, with some RAD 7.5

RAD Window XP V 7.5

WebSphere Application Server(WAS) V6.0.2 on AIX V5.3/Windows 2003, with some WAS 7.0

WebSphere 7.0 on AIX V6.1

FileNet Windows Server 2003 P8 V 3.5.2, with some FileNet 4.5

4.5

Business Objects XIR2

NC

Entity Analytics Solutions V4.1

NC

Host Access Transformation Services(HATS) 6.0

NC

Adobe Forms 5.0 Portal 6.1.5 Process Server 7.0.0.3 WebSphere Utilities WSRR 7.0.0.3 MQ 7.0.1.3 Source Code Management

Perforce Windows Server 2003 V2007.2 Visual Sourcesafe Windows

Migrate all content stored in VSS to Perforce

File/Database Access Method

SQL, VSAM

NC

Enterprise Servers

1 IBM Z-series;

NC

10 IBM P-series; 18 ESX4 VMware Hosts Over 100 virtual servers 47 Dell Intel Servers Printers

Several IBM and HP laser jet workgroup and individual printers

NC

Reporting

Business Objects/Crystal Reports

NC

Standard Desktop

1-3 GB Ram 80-200 GB drives- Not accessible by users 1 GB Ethernet Dual Monitors Windows XP OS ZEN for desktops (ZCM 10) Microsoft Office Pro 2003 w/Outlook

NOMADS CSE System Maintenance Plan & Modernization Roadmap

NC

Page 48

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

DWSS Current Computing Environment (As of 4/15/2011) Description

Name

1-Year Expectations

Open Office 2.0 or higher Suse Linux Desktop 9 and 10 Microsoft Explorer Symantec Anti-Virus 11 Hummingbird Host Explorer 9.0.0.2 Direct TCP/IP Printing on HP Laser Printers

It should be noted that several of the components listed above are not currently being used to support the IV-D program (such as iLog jRules). This section presents the current (as-is) architecture of the IV-D system in Nevada. This system include the NOMADS mainframe CSE system, as well as the “ancillary” software systems that augment and supplement the core mainframe system. For purposes of this document, the applications making up the as-is system includes the following: Š

NOMADS

Š

ANSRS (Automated Nevada Server-based Reference System)

Š

EWS (Employer Web Services)

Š

Compass

Š

Collections

Š

Disbursements

Š

LOTW (Ledgers on the Web)

Š

NAWC (Nevada Audit Worksheet Calculator)

Š

Unclaimed Property

Š

Warrants

Š

WPS

Š

DWSS Web Site

Š

FlexiForms

Š

CSE Crystal Reports InfoView

Š

Business Intelligence / Management Reports

Except for NOMADS, those applications that are shared by both IV-A and IV-D (largely security infrastructure) are not addressed in this as-is architecture. A summary of the applications making up the IV-D system can be found in Appendix E. For purposes of this section, the term “NOMADS” will be used to refer

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 49

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

to the mainframe application only. The term “IV-D Systems” will be used to encompass all of the applications supporting the Nevada CSEP, including the IV-D components of NOMADS. The as-is architecture of IV-D Systems will be presented as a series of “views,” each of which focuses on a specific way of understanding the system. Specifically, the following views are presented, which is discussed in detail below: Š

Functional View. Discusses IV-D Systems in terms of its main functional elements—the functionalities it currently supports.

Š

Information Flow View. Discusses IV-D Systems in terms of the key types of data it manages and processes. Also discusses data interchanges between IV-D Systems and external systems (data partners).

Š

Development View. Discusses IV-D Systems in terms of its main technological components and programming tools.

Functional View The Nevada CSEP requires a variety of specific functions to accomplish its mission to promote the wellbeing of children, strengthen families, and reduce the demand on public treasuries by securing financial and medical support from legally responsible parents. Within each Program function, such as paternity and obligation establishment, are specific business processes that must be supported by IV-D Systems. Figure 16, below, identifies the major functional areas of the Nevada CSEP and the primary business processes/core activities within each functional division. The listing is not meant to be exhaustive or to reflect the variations in functional divisions and/or alignment of business activities across Nevada’s local programs. The listing is intended to illustrate the variety of Nevada CSEP functions and processes that should be supported by appropriate automation within a modernized IVD system.

Figure 1 - IV-D System Functional Areas

Virtually all functional areas of the Nevada CSEP rely on the Child Support components / database of the NOMADS mainframe system. The level and quality of automation support and ease of use varies considerably from Child Support business process to process as reported in the Needs Assessment section. A number of core Child Support business processes/activities have limited automation support.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 50

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

In addition there are several generic IV-D system capabilities that facilitate work across multiple Child Support functions and business processes. Examples include: Š

Document generation (currently delivered through several separate utilities)

Š

Document/content management (including imaging)

Š

System user management and security (through a suite of security applications)

As described above, the Program also depends on ancillary applications that augment the NOMADS mainframe, including: Š

The ANSRS. The ANSRS application is accessed by IV-D workers to view/verify employment information, activity on EBT cards, and birth certificates.

Š

The LOTW. The LOTW application is accessed by IV-D workers to view financial information (payment history, account balances) for IV-D Child Support cases verify Public Assistance programs that Child Support case members participate in.

Š

The NAWC. The NAWC application is an automated worksheet that is accessed by IV-D workers conducting financial audits of Child Support cases.

Certain pilot applications, that are to be rolled out statewide, are accessed by IV-D workers in the county(s) where the application has been developed or subsequently deployed. These applications include: Š

Employer Web Services (EWS) - providing electronic transmission of employer information and IV-D worker access to an enhanced employer data table (Clark County)

Š

Compass (FAST Document Management Project) – providing imaging, routing and generation of document images and forms and IV-D worker access to automated, indexed case records

Š

Business Objects/Crystal Reports - providing IV-D worker/management access to business intelligence

A more complete list of these applications appears in Appendix E. The Program further depends upon a number of NOMADS data interfaces (SCaDU, OCSE, Motor Vehicles, Vital Records, and Utilities among a host of others) in support of a range of functions including obligation establishment, investigations, parent location, and enforcement. The management of these interfaces by the IV-D Systems is within the scope of this Maintenance Plan and Modernization Roadmap although the external applications that feed these interfaces (including SCaDU) are not. Finally, there are a limited number of locally developed applications/tools, not presently destined for state roll-out, which local IV-D workers utilize for specific operational or managerial purposes. Examples include the Washoe County Court Calendar Application and the Clark County Super Establishment and Enforcement Reports. These local applications are not within the scope of the as-is architecture, nor within the scope of the Maintenance Plan and Modernization Roadmap.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 51

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Information Flow View The Information Flow view describes the way the IV-D Systems architecture stores, manipulates, manages and distributes information. This view identifies the data to be managed, the high-level systems and subsystems that implement Child Support functionality, as well as the interfaces between them, and division of labor regarding data ownership.

Data Structure The IV-D System manages several types of data. Two broad categories of data are functional data and system data. Functional data is the business data which is related to the business performed by the systems, such as person, case and financial processing, and which has meaning outside of the systems. This document primarily concerns itself with the functional data, which it groups in terms of its functional purpose shown in the following table. System data is the technical data the system uses internally (for example parameter data) to govern its own functioning. Because the type and extent of system data is a reflection of specific system implementation choices and not a more general “requirement” of Child Support systems, this data it is not addressed in detail in this document. The IV-D Systems functional data structures include person data, case data, obligation data, financial processing data and a host of related cohorts (such as employer data). Table 4 below provides examples of some common Child Support data groupings. Table 4: Common Child Support Data Groupings Data Cohort

Description Examples

Person

The primary parties associated with a case (Custodial party, non-custodial obligor, beneficiary). Includes person name, type/role, and associated demographics such as address.

Case

The data making up the elements of a specific case (including an obligor and at least one beneficiary). Includes Case identifier, case type, date established, parties, etc.

Obligation

The data making up the Child Support ordered in a case. Includes the Order amount, date, frequency, medical support.

Payment

Data reflecting the payments made by a Child Support obligor. Includes Payment amounts, source and dates.

Event

Case events. Includes hearing date and type, remedies invoked, status changes.

Distribution

Data detailing the distribution of payments. Includes amount, date, case, and beneficiary.

Data cohorts are often represented by numerous tables in the DB2 database and have a variety of attributes. Most of the data in DB2 is currently relational and mostly normalized, (in some cases over normalized), but the data structure is not ideally modeled to support the complex business needs of the Child Support program. A significant concern of the IV-D System’s user community is the current contention over person and associated demographic data (particularly addresses) resulting from the integration of IV-A and IV-D functions in NOMADS and the sharing of this foundational data between the IV-A and IV-D programs. Because IV-A business processes exercise control over person/demographics, many changes to this data by IV-D business processes get overwritten in the system. For more detail on this issue see the discussion of Users Needs in the Needs Assessment sections above. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 52

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Data Sharing The primary data store for the IV-D Systems is the DB2 database. The DB2 store has been supplemented with a UDB database that is more accessible (easier deployment) to ancillary applications developed on more modern platforms such as WebSphere. The UDB database houses a few secondary data tables not in the primary DB2 database. For example, the NAWC application carries some detailed data necessary for calculations that are not replicated in the DB2 database. Accordingly the UDB repository represents a superset of IV-D (and IV-A) data. A replication process runs continuously to keep the data between the two databases in sync, though there is a slight lag between updates that can affect users. Except where specific reference to either the UDB or DB2 database is required, the term “NOMADS database” refers to the combined UDB/DB2 replicating repository. The NOMADS database is comprised of numerous tables representing the bulk of the person, case, financial and associated data upon which the system operates. The NOMADS mainframe application has been supplemented over time with a number of ancillary systems. In many cases these ancillary systems access the UDB database directly to read and display data. For all primary case and party data, however, the DB2 data still represents the official version. Ancillary applications that write data do so directly into the DB2 database. An illustration (not intended to be comprehensive) of this relationship is shown in the Figure 17, below:

Figure 2 - Data Sharing Model (IV-D Perspective)

The day-to-day work of the Child Support program also depends upon a wide variety of data exchanges between DWSS and external partners ranging from the Federal OCSE and the IRS to State licensing bureaus. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 53

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

These data exchanges are vital to many of the key Child Support functional areas including initial case referral and set up, location of absent parties, enforcement and financial reconciliation and distribution. NOMADS maintains data interfaces with numerous entities, including: Š

OCSE – FCR, CSENet, National Directory of New Hires (NDNH)

Š

State Collection and Disbursement Unit (SCaDU)

Š

Nevada Bureau of Vital Records (BOVS)

Š

Department of Prisons

Š

Department of Motor Vehicles (DMV)

Š

Nevada power companies (for locate)

These interfaces involve a variety of distinct data streams. Data exchanges are typically accomplished through batch programs run daily, weekly or at the end of the month. Further examples of the type and frequency of data exchanges occurring between CSEAS and data partners appears in Figure 18, below:

Figure 3 - Example Data Exchanges with Partners

The existing interfaces to external data partner stakeholders are typically implemented as batch routines built in CSP and run during the nightly batch window. These routines are recognized as being a brittle (things tend to break whenever modifications are made on one side or the other) component of the as-is IV-D System environment. The quality and accessibility of partner information are concerns expressed by IV-D System NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 54

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

users. A particular problem is the automatic update of sometimes older, less reliable information from external interface data. This happens with employer data coming from the National directory of New Hires as well as quarterly wage data.

Development View This section discusses the NOMADS mainframe application as well as a number of related non-mainframe systems (e.g., LOTW, NAWC, etc.) from a development point of view. It segregates the system into different areas based largely on the technologies that are employed within those areas. It should be noted that several of the ancillary systems (such as the EWS and the FAST/Compass systems) have been developed as pilots in individual counties but are intended to be deployed program wide. Although NOMADS does not have a strictly “layered” architecture, it is still useful to conceive of the system as a set of distinct layers, each with its own purpose. Figure 19, below, shows the current Child Support program systems using a layered description approach.

Figure 4 - Development View

To describe the current Child Support program systems, the diagram will be addressed from the top to the bottom, discussing each of the identified layers in turn.

Client Layer The client layer isn’t technically a layer of the system, but it’s useful to make note of clients in context of this diagram. The term “client” indicates an entity that connects to the system. This includes system users who use the system interactively, as well as other systems that interact with the system through automated systemto-system means and protocols.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 55

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Typical online users include DWSS staff and County District Attorney Child Support staff. External systems that access Child Support systems include entities / agency systems such as OCSE (CSENet).

Online Access For non-system users, NOMADS offers two primary channels for access to the system: 3270 (Terminal) access and Web-browser access, as described below. 3270 (Terminal) Screens

This access method involves the client using a 3270 terminal emulation package, typically “HostExplorer” in Nevada. This allows the user to access a text-mode (“greenscreen”) terminal interface and to interact with it through keyboard entry and function keys (e.g., F7 / F8 to scroll backward and forward through long listings). In some instances client-side programs have been written that read and parse the data on the 3270 screen (“screen scraping”). In some cases these programs also process the data or perform actions on behalf of the user (i.e., navigate to a different screen, invoke DocGen, other specific macros, etc). Web-Browser

This access method involves a standard Web Browser such as Internet Explorer, Firefox, or Google Chrome to navigate to an internal URL (Uniform Resource Locator) that presents a Web page that the user can interact with. The Web-page typically takes advantage of Graphical User Interface (GUI) design concepts in order to present a more pleasing and easier-to-use experience. Web pages presented to the user are typically limited in scope. These Web pages are usually restricted to presenting data from the back-end database and allowing the user to update and save only a subset of it. Heavy manipulation of the data in order to calculate results is more the province of the back-end system, as will be addressed further in the “Business Logic Layer” section, below.

File Access In addition to these user-focused access methods, system-to-system access channels of the following types are supported by NOMADS: Š

FTP—File Transfer Protocol

Š

Cyberfusion—A proprietary encrypted file-transfer in fairly wide use in government and financial institutions

Š

Email

Š

Web services

Š

Physical files transfer (3480 cartridges)

Direct Database Access A data exchange protocol where the partner agency reads data directly from or writes data directly to the other agency’s database table(s). This method is used heavily in Nevada, for historical reasons as NOMADS is an integrated system for both the IV-D and IV-A programs.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 56

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Application Layer There are four main sub-components to this layer, which is discussed below: Š

NOMADS Online

Š

NOMADS Batch

Š

Web

Š

Client/server

The business logic layer of the system represents the bulk of the current IV-D System’s applications. Nearly all of the code that makes up NOMADS is housed in this layer, with the largest proportion of code being spread across the legacy mainframe batch and online sub-components.

NOMADS Online This layer consists largely of CSP/COBOL programs that implement an interactive “greenscreen”. Often a single program will contain multiple screens to present to the user in some sequence depending on the choices the user makes when interacting with the screens. Most of the architectural and structural issues that have been identified to date exist primarily in the legacy sub-components of NOMADS, which also happen to be the biggest part of the system. The legacy mainframe batch and online sub-components are primarily built in CSP. CSP was an IBM product that provided a set of source code generators to define, test and execute COBOL code. NOMADS IV-D consists of some 500-800 distinct screens (CSP “applications”). There are some common modules (approximately 200) that perform specific services like formatting a date, validating some data, parsing some string data, etc. For each line of CSP code, approximately 10 lines of native COBOL code is produced. The generated COBOL is not maintainable independent of the CSP generator routines. Since the original construction of NOMADS, the CSP product has become obsolete and has not been supported by IBM since 2001. The lack of support and absence of CSP knowledgeable programmers poses a critical problem for NOMADS maintenance and enhancement. The complexity of the NOMADS system is further compounded by the integration of the IV-A and IV-D functions in a single system. According to a product migration survey completed by DWSS, the NOMADS mainframe system is composed of the following CSP programs: Table 5: Survey Results: CSP Programs CSP Applications

6 Char Programs

T Layer Programs

Main or Called Transaction applications

3460

6335

Main or Called Batch programs

1384

2387

Total(Transaction or batch applications)

4864

8772

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 57

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The survey also indicated that 90% of the CSP development uses a Text-Based User Interface or TUI (greenscreen 3270) interface, with 10% devoted to print/reports. Prior estimates indicate that the system as a whole contains some 14 million lines of code8 and that the common code modules make up almost 50% of the total code base. The sheer number of modules makes learning the system daunting and frustrates impact analysis and testing when seeking to make needed changes or improvements in the legacy code. The difficulty inherent in fixing or enhancing the NOMADS CSP code has led to the development of a number of external applications using more modern programming languages and taking advantage of more flexible user interface tools.

NOMADS Batch This layer consists largely of CSP/COBOL “batch” programs, whose execution is managed by a combination of Job Control Language (JCL) scripts and batch scheduling tools. The programs in this sub-component are concerned with specific functions like evaluating and importing data received via an interface file, performing financial distribution, and developing interface files to send to data partner agencies (as described in the preceding section “Information Flow View”). Typically jobs are scheduled as daily, weekly, or monthly, quarterly, with some others being scheduled as “on demand” and for specific timings like “year end.” Because the batch component is built in CSP, it poses the same challenges to necessary maintenance and desired enhancement as does the legacy online component. The consumption of the nightly batch window is also a problem, particularly at month end when batch runs intrude into otherwise normal user business hours, reducing productivity.

Web This layer consists of Web pages generally coded in Java/ JEE and is external to the NOMADS mainframe system. Typically these Web pages interact with NOMADS by querying the UDB database and displaying the data to the user directly (in primarily read only mode). Some applications may pull UDB data to a separate data store for further manipulation.

MS Click Once At least one application uses technology requiring significant client side software. The Compass application downloads client software using Microsoft ClickOnce technology. The application makes use of a separate database to store data needed for the client. Where UDB data is needed or where return data is required to be

The commonly referenced “14.8 million lines of code,” refers to an ESF file containing 14,819,687 lines. These lines, however, are not limited to only code and each line of code is not necessarily unique. Common modules can be expanded and repeated multiple times, increasing the code number of lines. This is in addition to non-application code like maps and also comments. An accurate line count, broken down as requested is not possible with current tools.

8

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 58

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

uploaded to NOMADS, a stored procedure or other interface is used to move data between the UDB database and the client/server database.

Data Layer This layer consists of a set of database resources, using the following three database technologies: Š

IBM DB2. This is a true Relational Database Management System (RDBMS), but many of its relational capabilities and constructs are not being fully leveraged. The data is mostly normalized. Because of the integration of IV-A and IV-D, sharing of data in the same tables causes data ownership issues. IVD-staff cannot update case or person demographic data on their own cases, they must rely on IV-A staff to update/correct data which causes delays in case processing. Merging of data which is done by DWSS IS staff (programmer) can take up to 4-6 weeks.

Š

IBM UDB. As noted above, the UDB database represents a superset of the IV-D data and is more easily accessed by many of the external applications built to enhance NOMADS functionality. By using two databases there is the potential that applications are out of sync, despite the replication processes in place.

Š

Microsoft SQL Server. SQL Server is used exclusively by the client/server and external Web applications described under “Business Logic Layer.” SQL Server databases are populated with daily “snapshots” of DB2 data. The Web applications operate with this data along with data that is unique to the Web application itself (parameter tables, system tables, etc.). The SQL Server databases are constructed to only temporarily house case data. Any and all case data the Web application may collect from a user is quickly transmitted back to the CSEAS DB2 database, so that it can remain the “System of Record.”

As-Is Architecture Primary Concerns The as- is architecture for the Nevada IV-D systems poses a significant obstacle to IV-D program improvement. Its weaknesses lie in the following primary areas: Š

The obsolete code base of the mainframe system which provides the vast majority of the system’s functionality has always been inadequate to efficiently and accurately support the IV-D caseload in Nevada. The basic architecture has a number of significant flaws:

Š

The green screen user interface is both inefficient and inconsistent in its support of standard Child Support functions.

Š

The lack of support for the CSP language, its overall complexity, and lack of documentation make basic maintenance, much less significant enhancement a major challenge.

Š

The lack of adequate code source control poses severe risks to code enhancement.

Š

The dwindling number of CSP resources capable of providing maintenance and enhancement put the viability of the IV-D Systems as a whole at significant risk.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 59

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

The integration of the IV-A and IV-D programs within the NOMADS mainframe greatly increases the system’s overall complexity. Needed enhancements must be analyzed not only for impacts in the IV-D system modules but in the significant number of shared modules as well. The integration also generates contention over shared data. This contention results in continuous make-work to correct changes in person and address data, taking precious resources away from more meaningful Child Support tasks.

Š

The addition of ancillary applications to extend the IV-D system and expand the IV-D System’s capabilities has resulted in increased system complexity, user interface complexity, and support and maintenance costs. While this enhancement approach has provided much needed system functionality, continued reliance on this method of expansion could result in a fragmented and unsupportable system.

Š

The DB2 to UDB replication imposes unnecessary complexity and facilitates the potential for data mismatches. While the database is relational and takes advantage of the relational features of the RDMS, its design may lack some entities that are essential to operating the Child Support program.

Š

System performance/availability constraints pose significant issues for the long term viability of the IV-D Systems. Current system availability problems are having a widespread impact on worker productivity across the program.

Š

While the database is largely normalized and well organized, there are areas of weakness:

Š

Areas of poor modeling of the real world (e.g., employers / employment).

Š

The replication scheme that is currently in place adds complexity and costs DWSS resources on an ongoing basis to maintain insufficient purging and archiving of data in order to improve performance.

Š

Insufficient existing documentation.

Analysis Results: Gap Analysis   The extent and nature of the current Nevada IV-D system’s ability to meet the high level strategic requirements identified during the needs assessment have been analyzed. A gap attribute (fully meets, partially meets, does not meet) has been assigned to each functional and technical requirement as a result of this review and analysis. Requirements, gap attributes and summary comments are first presented in summary tables. The basis of the gap attribute is discussed in terms of the “deltas” of differences between the high level strategic requirements and the current IV-D system. Finally, potential technology solutions are presented for bridging each of the identified gaps.

Functional Gaps Table 6: Functional Requirements Gaps Functional Requirements

Gap Attribute

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Summary Comment

Page 60

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Functional Requirements

Gap Attribute

Summary Comment

Federal System Certification Requirements:

Fully Meets

In 2001 the Federal government certified NOMADS for both FSA and PRWORA requirements.

Consistent System Availability and Performance

Does Not Meet

The system is unavailable or slow for significant periods of time – negatively impacting worker productivity.

Intuitive Interface

Does Not Meet

The IV-D mainframe application is dated and very difficult to navigate – compromising worker proficiency and productivity.

Supports Imaging/Doc Management

Partially Meets

The Compass (FAST Project) document imaging, generation and workflow system has been recently rolled out statewide. Support for document generation is limited. The indexing of documents/scanned images is not uniform statewide.

Automated Casework Management Tools

Partially Meets

The system does not support proactive caseload management. While certain alerts prompt case activity, other alerts provide little or no value. The system does not prioritize work. The system provides only limited case status values. The system automatically assigns cases however this functionality is cumbersome to manage.

Robust Reporting

Partially Meets

The IV-D system lacks robust business intelligence capability and reporting. The new Crystal Reports promise access to business intelligence that users have not had previously.

Generate and Present Accurate Interface Information

Does not Meet

The system does little to prevent inaccurate information received through automated interfaces from overriding more current information. New interface data is not automatically presented caseworkers must take time to search for and verify interface information.

Maintain Valid Locate Records

Does Not Meet

Good employer/person address information is overridden by out of date addresses from system interfaces. INTR and ANSRS do not resolve inconsistent locate information for the same individual. Participant data for IV-A referrals is maintained on the IV-A system application and trumps IV-D information. Management of locate activities is not automated.

Reliable IV-A & IV-E Referrals

Does Not Meet

Automated IV-A referral information is frequently incomplete and/or of poor quality - creating time consuming problems downstream for Child Support and IT. The system does not interface with the IV-E automated system for foster care cases.

Workflow Management Capability

Does Not Meet

The system does not inform the user of, move the user to, or assist the user in completing the next process step. Alerts are often inaccurate and/or non-intuitive.

Robust Financial Management/Accurate Accounting

Does Not Meet

The system lacks sophistication on par with the complexity of the Child Support accounting business rules - resulting in financial data errors. Automatically generated financial statements are unreliable. The system doesn’t fully support data reconciliation or management of undistributed collections.

Supports Responsive Customer Service

Does Not Meet

The system does not provide staff with ready access to case summary information that would otherwise

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 61

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Functional Requirements

Gap Attribute

Summary Comment enable efficient/effective responses to customer inquiries. The system does not support self-service.

Consistent Security Standards

Partially Meets

The system’s security management is distributed and standards are inconsistent. The system components and applications do not have the same time-out, access and confidentiality restrictions. IRS standards for tax information security are not universally applied.

The IV-D System Must Meet Federal Certification Standards and Requirements In 2001 the Federal government certified NOMADS for both Family Support Act (FSA) and Personal Responsibility and Work Opportunity Reconciliation Act (PRWORA) requirements9. Thus, by definition, Nevada’s IV-D system fully meets these collective Federal requirements and the modernized IV-D system must likewise meet these standards. It should be noted that during the needs assessment stakeholders questioned if the current system is compliant with the federal requirements to automatically bill cases with obligations and/or generate an accurate pay history. These concerns are addressed below under requirement eleven (11): robust financial management/accurate accounting.

The IV-D System’s Availability and Performance Must Support Consistent Worker Productivity The current system is unavailable or slow for significant periods of time – negatively impacting worker productivity. These events are both predictable - at month end, year end, and during high use/sign on times of the day - and unpredictable in occurrence. Month end batch process spills over into the next business day for hours at a time when it runs on Sunday through Thursday. NAWC and LOTW applications, relied on for enforcement and financial casework, are frequently unavailable for varying lengths of time. Independent and/or inconsistent server application timeouts likewise impact productivity. While objective tracking of downtime by the helpdesk suggests this system deficiency concern may be overstated, the consistency of and priority ascribed to this concern and the frustration expressed across all primary user groups argues otherwise. One factor contributing to the level of concern that, on its face, may seem disproportionate is that work is not simply interrupted or stalled during periods when the system is unavailable or slow. Incomplete data entry or casework tasks can be corrupted or even lost as a result of down time events. Thus the negative impact is often more than a straight loss of work time but is compounded by additional time spent following up and verifying - if not redoing – prior work. In conclusion the current system does not provide reliable, consistent performance and thus does not meet this strategic requirement.

9

Automated Systems for child support Enforcement: A Guide for States. ACF/OCSE publication, updated August 2000.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 62

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The IV-D System’s User Interface Must Be Intuitive and Support Efficient User Navigation and Information Retrieval The current IV-D system mainframe application has a dated, very unfriendly user interface. There are so many screens that it is difficult to navigate the system. Many of these screens require arbitrary codes that users must either memorize or look up. The system does not automatically populate information across screens and applications and users must enter the same information multiple times and in multiple places. Tasks that are relatively limited in scope often require navigating multiple screens. The current system lacks data entry and navigation conventions. Certain data entry work must be redone because the system will not allow reversing steps to correct data entry errors. Workers must memorize, recognize and work around certain system flaws. Additional user interface issues include multiple application sign-ons and time-out thresholds, very limited screen editing capability, and case notes that must be manually sorted and searched. Worker productivity is significantly impaired by this outdated interface and the learning curve for new employees is long and steep. The current system therefore does not meet the strategic requirement for an intuitive interface that facilitates worker efficiency.

The IV-D System Must Utilize and Support Imaging and Document Management Technologies Statewide implementation of document imaging, generation and management will clearly result in across the board benefits. These include more reliable and more ready access to records, workflow efficiency, more effective casework, more responsive customer service, and savings of time and physical storage space. The Compass document imaging, generation and workflow system has been piloted in Clark County and was implemented statewide in 2010. It should be noted that certain counties elected not to acquire or use the workflow component. Further, stakeholders report Compass’ support of document generation is limited. User concerns and a lack of a statewide indexing convention pose challenges for the efficient statewide use of this application. Workers consistently recognized the value of FlexiForms, an existing document generation process that combines input data produced by a mainframe application with a Visual Basic application to automatically complete forms by leveraging Microsoft Word mail merge functionality. FlexiForms can be printed to the Compass forms printer and concurrently indexed. However, the FlexiForm application is not currently available in many rural areas of the State in part because of the barrier posed by local programming requirements to leverage this application In view of these initial document management efforts the current system partially meets this strategic requirement.

The IV-D System Must Support Program Goals and Objectives by Providing an Automated Management Tool for Assigning, Monitoring, Reporting and Auditing Casework The current system does not support proactive caseload management or prioritization of work. The system automatically assigns cases to workers; however, this functionality is cumbersome to manage (taking days to reset the alpha split) and does not apply to all functional specialties. Although the IV-D system does not launch the next case activity automatically, some case activities are prompted by system alerts. However, alerts are not prioritized and many alerts provide little or no value and may actually get in the way of work. Further, alerts that do have value often do not provide sufficient information as to what event, threshold or new information triggered the alert. Caseworkers then play detective searching for the possible meaning and/or benefits of the alert. The current IV-D system does little to assist supervisors in monitoring worker performance, accuracy, timeliness or productivity. While Crystal management reports / dashboards provide steps in the right direction, more such reports / dashboards are needed and need to be rolled out statewide. The current IV-D NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 63

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

system does not help determine if a given worker is “ahead or behind” - nor does the system monitor the overall productivity of workers. The current system does not monitor and report case status. The system only provides three case status values: Open, Pending closure, and Closed. Specific case actions within functional areas must be manually assessed and tracked. Management spread sheets have been developed to compensate for these system deficiencies. Because of the limited alert and caseload assignment functionalities the current system partially meets this strategic requirement.

The IV-D System Must Provide Robust and Flexible Reporting The IV-D system lacks robust business intelligence capability and reporting – lacking in terms of the number of management reports, lacking in the detail of the information it provides, and lacking the flexibility for users to drill down from available summary data to details and actions relevant to the user. The current mainframe system also lacks ad hoc reporting capability. As noted previously, the current system also offers little in the way of usable management reports—the kind of capabilities that allow supervisors, case managers, and caseworkers to monitor performance, proactively manage their caseload, and prioritize their activities. Reports have been developed to give a snapshot of overall office performance on key measures, but this performance data is not available on a worker basis. These reporting deficiencies constrain the program’s ability to execute strategic initiatives to improve program outcomes. The new Crystal Reports promise access to and customized presentation of business intelligence that users have not had previously. In light of Crystal Reports and the development of a lauded “super enforcement” report in Clark County, the current system was found to partially meet this strategic requirement.

The IV-D System Interfaces Must Generate and Populate Useful, Accurate Information and the System Must Present That Information to the User, All in a Manner That Advances Child Support Casework The current IV-D system does little to prevent “bad” data from populating/entering the system. Failure to screen or edit this data causes negative impacts downstream such as disrupting appropriate case processing and creating more work for the user to correct the resulting chain of events prompted by bad data. Users reported spending an inordinate amount of time under this circumstance verifying that the system processed the case correctly. At the same time, new data from external interfaces is not automatically available or presented to case workers. Caseworkers must search the system to find and verify interface information. Despite the current system interfacing with other valuable systems/databases, the inability of workers to readily access and trust this information leads PSI to find that the current system does not meet this strategic requirement.

The IV-D System Must Maintain Valid Locate Records Good employer and person address information are overridden by older, out of date addresses from system interfaces (see requirement gap seven (7)). False-positive locates interfere with time tracking and case processing. The system does not have locate-response screening/editing capability. INTR and ANSRS do not resolve inconsistent location information for the same individual – workers must research which address is most current. Many of the “new” addresses that are added to the INTR screen are old addresses that had previously been cleansed from the IV-D system. New false hits require manual deletion of the incorrect address, record by record. Participant data for IV-A referrals is maintained on the IV-A application and trumps IV-D information.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 64

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The flow of locate activities is not automated/effectively managed by the IV-D system. Staff must manually initiate many locate functions and manually monitor and screen locate responses. The existing, albeit limited, functionality that moves the case from locate to establishment or enforcement upon the IV-D system’s recognition of a valid address is confounded by the significant number of false positive locates. Finally, while a matter of policy (security roles), it is worth noting that the Clark County Investigations unit is unable to directly nullify an address - even when an investigator or process server has direct confirmation that the address is invalid. In view of the criticality of accurate address information to the program’s mission and the nature of these deficiencies, PSI finds that the current system does not meet this strategic requirement of maintaining valid locate records.

The IV-D System Must Support Reliable IV-A and IV-E Referrals and Updates Automated IV-A referral information is frequently incomplete and/or of poor quality. IV-A workers generally lack incentives for providing high quality referrals and the system does not have automated edits for preventing incomplete or poor quality referrals. Problematic IV-A referrals in turn create time consuming issues downstream for both Child Support and IT. For example, pseudo names on a given IV-A case will need to be “merged” in order to be accepted and processed on the IV-D side – more often requiring help desk support and potentially taking months to complete. Further, the system does not interface with the IV-E automated system for foster care cases. Users must go directly to the foster care system to extract the information they need to set up a case. The program’s inability to rely on IV-A referrals is attributable to gaps in policy and practice as well as system functionality. Nonetheless, relevant system deficiencies must be addressed to help mitigate the significant downstream costs associated with problematic IV-A referrals. Accordingly, PSI finds that the current system does not meet this strategic requirement of supporting reliable IV-A and IV-E referrals.

The IV-D System Must Have Workflow Management Capability to Automatically Move the Case to the Next Activity or Business Process or, When Appropriate, Present Relevant Information to the User to Manually Move the Case The system does not inform the user of, move the user to, or assist the user in completing the next process step. Further, the system does not automatically monitor timeframes for completing required activities and effectively prompt the user for timely follow up on activities yet to be completed. The current mainframe system also does little to assess the enforcement status of the case that would otherwise guide the worker as to the appropriate steps to take. The system is limited to three case status values: Open, Pending closure, and Closed. Although the current IV-D system rarely launches the next case activity automatically, some case activities are prompted by system alerts. However, system alerts can be incorrect, of little value and/or not easily understood. PSI found that the current system has so little workflow management capability that a requirement gap attribute of does not meet was assigned.

The IV-D System Must Have a Robust Financial Management Component That Maintains an Accurate Accounting The system lacks sophistication equal to the complexity of Child Support accounting business rules, resulting in financial data errors. Automatically generated financial statements are broadly perceived to be unreliable. Users spend considerable time recreating financial statements that the system automatically generates. The system doesn’t fully support the complete reconciliation of financial data. Many reconciliation calculations are performed manually on spreadsheets. LOTW and mainframe issues cause the updating of erroneous financial information that must be corrected through balance adjustments.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 65

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

While the system is capable of generating monthly Child Support notices, this functionality is inactive due to the unreliability of the financial data and poor design of the form. The inability to produce an accurate pay history is a significant shortcoming. The current system also does not effectively manage undistributed collections. In many instances the system is not able to determine when a payment should be distributed or go into an undistributed status. In view of these serious deficiencies PSI finds that the current system does not meet the strategic requirement of providing robust financial management and accurate accounting.

The IV-D System Must Support Effective, Efficient Customer Service The system does not provide staff with ready access to case summary information that would otherwise enable efficient/effective responses to customer inquiries. Delays in having to access numerous screens to respond to simple customer inquiries are further exacerbated when the system is slow. The inability to quickly find requested information in the current IV-D system or to trust its accuracy forces staff to spend more time researching basic information or referring the customer and those tasks to others who could otherwise be completing more substantive tasks. The system does not provide much support for customer self-service where parties to the case would be able to readily access case and financial information and initiate appropriate changes to participant or case information. Because the system lacks basic customer service functionality commonly associated with modern Child Support programs/systems PSI assigned a requirement gap attribute of does not meet.

The IV-D System Must Employ Consistent Program Security Standards The system’s security management is distributed and standards are inconsistent. System components and applications do not have the same time-out, access and confidentiality restrictions. The mainframe access controls are being handled by RACF security and all remaining security authorizations are being managed by a Novell-based user repository. This distribution of authority allows inconsistent permissions to be defined. IRS standards for tax information security are not universally applied according to previous IRS reviews. The current IV-D system could also benefit from additional safeguards to further support the secure management of undistributed collections and NCP refunds. While these highlighted issues are each noteworthy in their own right PSI does not wish to suggest an absence of security standards or controls and thus, all considered, the current system partially meets this strategic requirement for security standards.

Technical Gaps Table 7: Technical Requirements Gaps Technical Requirements

Gap Attribute

Summary Comment

Migrate Away From CSP

Does Not Meet

IBM’s CSP is an outmoded and no-longer-supported programming environment which presents numerous drawbacks to the State of Nevada

Unified database model

Does Not Meet

Currently the IV-D system has a distributed database model, with a subset of data stored on DB2 in the mainframe, and a wider set of data stored on UDB on AIX.

Service-Oriented Architecture (SOA)

Partially Meets

The IV-D system is brittle in its construction, and does not have the clear separation of concerns that is typical of modern software development Best Practice.

Business logic layer

Does Not Meet

At the same time as the IV-D system is adopting a SOA, it will be necessary to identify a layer in the system that is responsible for hosting business logic. It will also be necessary to establish patterns for how this layer

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 66

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Technical Requirements

Gap Attribute

Summary Comment supports that responsibility and interacts with the other layers (typically Presentation and Data Access).

Separate business logic from presentation

Does Not Meet

A more modern IV-D system will have to deal with a migration of business logic and presentation code to a new platform and new architectural paradigm (SOA instead of simple data-in / data-out module construction).

Decouple IV-A and IV-D

Partially Meets

The integration of IV-A and IV-D has some benefits, but the overwhelming consensus is that the mainframe’s intertwining of IV-A and IV-D functionality and data does not serve the IV-D program.

Mainframe capacity

Partially Meets

Continued optimization of the mainframe’s capacity is a necessity. This may be accomplished by some combination of offloading non-active data, spot-optimizing (or rewriting) critical batch jobs, and increasing the mainframe’s raw capacity with upgrades.

Security conventions in the database

Partially Meets

The database should be restructured to either segregate highly-sensitive data into specific groupings that can be more closely audited and protected, or an architectural “layering” scheme should be put in place to specifically implement the stratification and data segregation that IRS 1075 / NIST 800-53 requires.

User repository to support role based access

Partially Meets

As with many mixed legacy / newer-generation systems, the identity and access management scheme in place in the IV-D system is distributed. All mainframe-specific access controls are being handled by RACF security on the mainframe, and all remaining security authorization is being managed by a Novell-based user repository.

Rules engine

Does Not Meet

Rules engines are key pieces of technology in many modern systems because they can help solve problems that are very difficult to tackle in typical procedural languages. In Child Support, examples of problems that can be more easily solved with a rules engine are financial distribution and applying enforcement remedies.

Robust data warehouse tools

Partially Meets

Data warehouse and business intelligence (BI) tools will provide better management reports to supervisors and Program management while—as a technical matter— unburdening the transactional database with the need to keep data around that is strictly needed for reporting .

System integration toolsets

Partially Meets

There are a host of specific technologies that have been discussed as having demonstrable benefit to a modern IV-D system’s ability to interact with other systems, including: Web services, ESB, SOA, and robust Document Generation

Developer toolsets

Partially Meets

There are numerous specific tools / capabilities that the development group has noted are lacking, and which, if provided, would materially improve DWSS’ ability to support users. Better documentation and source control are examples.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 67

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The IV-D System Must Migrate Away from CSP The current system is predominantly coded in CSP. For the many reasons outlined in the Technical Requirements, NOMADS’ long term future depends upon moving away from CSP to a more supportable language. Plans are currently underway to contract for a conversion from CSP. Accordingly, PSI assigned a gap attribute of does not meet.

The IV-D System Must Utilize a Unified Database Model All data of record for the Child Support program resides in the NOMADS DB2 database. However, because a second database containing a superset of IV-D data is also being used with a replication scheme in place, PSI assigned a gap attribute of does not meet.

The IV-D System Must Adopt a SOA The current architecture relies primarily on a brittle mainframe based monolithic framework. The age of the code base is consistent with the approach in common use at the time of its construction. The future of NOMADS will be enhanced by moving toward a modular service oriented approach that fosters code reuse. Some move has been made in this direction with the development of server based applications sitting on a common java based platform. Thus while significant work is left to be done, the gap attribute assigned is partially meets.

The IV-D System Must Support a Business Logic Layer The current monolithic architecture does not permit a separation of the business logic from the other components of the application. In moving toward an SOA, this separation should unfold. Currently the gap attribute is does not meet.

The IV-D System Must Separate Business Logic from Presentation This requirement is a companion to the last and promotes a presentation layer that works in conjunction with the business layer to deliver functionality while allowing flexibility to adjust presentation elements without affecting the underlying business logic. The current monolithic application combines logic and presentation and thus the gap attribute assigned is does not meet.

The IV-D System Must Reduce Coupling between IV-A and IV-D Although a significant amount of IV-D data remains untouched by IV-A program functionality in NOMADS, key data elements such as person and address are essentially under the control of IV-A processes. This creates data inaccuracies and causes significant inefficiencies in IV-D program operations. With the implementation of EWS, the IV-D program has begun to decouple some of these conflicting data elements (in this case employers and employer addresses). Use of a master data management schema will help reduce the conflicts between the two programs’ use of the same data. The gap attribute assigned is partially meets.

The IV-D System Must Optimize Mainframe Capacity So long as a significant portion of the functions/data for NOMADS lives on the existing mainframe infrastructure, steps must be taken to maximize the performance and capacity of the hardware and thus reduce some of the system availability issues that currently impact IV-D users. Some steps have been undertaken to improve capacity and EITS plans include significant hardware upgrades. Accordingly, a gap attribute of partially meets has been assigned.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 68

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The IV-D system must adopt and consistently apply data security conventions in the database The NOMADS database, though largely normalized and fully relational, suffers from some design inconsistencies. One area where database design could be improved is the treatment of sensitive data. The current dispersion of such data across a myriad of tables makes it difficult to manage and audit this data for required security protections. However, the data does have security constructs in place, so the gap attribute assigned is partially meets.

The IV-D System Must Use a Single User Repository to Support Role Based Access NOMADS is making use of a robust access platform known as Novell Access Manager. However, the split between NOMADS mainframe applications (using RACF security) and ancillary applications imposes multiple credentials and logins for users. The under use of true role based access is also a deficiency that could be improved. Because the infrastructure is in place and because some use of appropriate tools is in place, PSI assigned a gap attribute of partially meets.

The IV-D System Must Adopt a Rules Engine The business logic in NOMADS, including the complex financial distribution rules required for IV-D program are essentially hard coded within the screens and programs that make up the system. The current system does not make use of a rules engine, although such software is available. Accordingly the gap attribute is does not meet.

The IV-D System Must Provide Robust Data Warehouse Tools Leveraging a pilot project initiated by Elko County, the Child Support program is beginning to make use of a dedicated reporting database and business intelligence toolset. This functionality is in its infancy however, and could be greatly expanded to supply the program with significant information about program trends and performance. Because of the work begun, the gap attribute assigned is partially meets.

The IV-D System Must Employ Current Generation System Integration Toolsets In large part because of the legacy programming platform that makes up the bulk of the Nevada IV-D systems, use of modern system integration tools has been slow in coming. However, there are small steps being taken in that direction. For example an active Web service is being used to support the QUICK functionality. As the system is modernized, greater use of these toolsets and methodologies can and should be made, particularly with respect to SOA application of an enterprise service bus (ESB) (using software already in house) and the like. Although much work remains, the start made by the IV-D program means the gap attribute assigned is partially meets.

The IV-D System Must Enhance/Improve Developer Toolsets As with the system integration tools, improved developer toolsets have been stymied by the outmoded CSP platform. If the contemplated EGL conversion is successful, these tools should improve. Moreover, as functionality is moved to more modern computer languages, existing developer tools for these languages can be leveraged to a much greater degree, allowing new code development to proceed with greater consistency and efficiency. The gap, though still significant, has an attribute assigned of partially meets.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 69

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Functional Gap Solution Options Table 8 below presents solution options for each of the functional gaps identified above. The options presented are not necessarily all-inclusive but demonstrate that functional gaps can be closed through the Maintenance Plan and Modernization Roadmap. Table 8: Solution Options for Functional Gaps Functional Gap

Solution Options

(System Certification)

Š

N/A (Modernized IV-D system must continue to meet certification requirements)

The IV-D system does not provide consistent availability and performance

Š

Optimize mainframe capacity.

Š

Offload non-active data.

Š

Spot-optimize (or rewrite) critical batch jobs.

Š

Increase the mainframe’s raw capacity with upgrades.

Š

Develop a standards based, graphical user interface.

Š

Identify and eliminate unused/unnecessary screens.

Š

Link/automatically populate the same data elements.

Š

Establish a single sign on/timeout.

Š

Enhance participant research capability.

Š

Augment and improve access to step/screen specific system reference information.

Š

Establish case note filtering/sorting capability.

Š

Adopt a single state-wide utility/technology for all document imaging.

Š

Adopt a single document generation tool.

Š

Establish one repository for all documents.

Š

Establish one indexing scheme that meets local needs.

Š

Integrate workflow and document management.

Š

Utilize data warehouse and business intelligence (BI) tools.

Š

Redesign and further streamline alerts/notifications.

Š

Enable system recognition of and status within a case’s assigned functional specialty (intake, interstate, et)

Š

Enhance automation across all functional areas (e.g., intake functionality).

Š

Enhance audit support functionality.

Š

Support caseload stratification.

The IV-D system lacks robust business intelligence capability and reporting.

Š

Continue development and roll out of Crystal Reports statewide.

Š

Develop performance management functionality down to worker level.

The IV-D system does not generate and present reliable interface information

Š

Develop business rules for system screening/editing of address updates from interfaces.

Š

Decouple IV-A and IV-D and replace w/ standard system interface.

Š

Update 3rd party, other State data tables.

Š

Redesign alerts.

Š

Develop CESNet interface/functionality.

The IV-D system does not provide an intuitive user interface.

The IV-D system partially supports document imaging, generation and management

The IV-D system does not support proactive case management

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 70

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Functional Gap

Solution Options Š

Decouple IV-A and IV-D and replace w/ standard system interface.

Š

Link addresses for efficient deactivation/activation.

Š

Develop business rules for system screening/editing of address updates from interfaces.

Š

Develop IV-A referral screen edits.

Š

Establish automated IV-E interface.

Š

(While it is outside the scope of this project it is worth noting that IV-A policy and procedure changes could improve the reliability of IV-A referrals).

Š

Develop business process management capability such as the IBM process server IV-A is using.

Š

Consider strategic custom fixes before full implementation of a workflow engine.

Š

Replace the existing IV-D financial component.

Š

Develop functionality to address greatest pain points/deficiencies (reconciliation, adjustments, reporting, etc).

Š

Recode distribution and other financial components using a Rules Engine.

The IV-D system does not supports responsive Customer Service

Š

Develop a Customer Service summary screen.

Š

Develop self-service Web/phone capabilities.

The IV-D system’s security management standards are inconsistent.

Š

Segregate sensitive data into specific groupings that can be more closely audited and protected or adopt an architectural “layering” scheme to stratify & segregate data per IRS 1075 / NIST 800-53.

Š

Establish a single user access/control repository or adopt a federated model with replication of credentials/security standards across the constituent repositories.

The IV-D system does not maintain valid locate records

The IV-D system does not provide reliable, automated IVA & IV-E Referrals

The IV-D system does not have workflow management functionality

The IV-D system lacks robust financial management and accurate automated accounting

Technical Gap Solution Options The technical gaps identified are rooted in specific technical challenges and recurring technically-oriented problem themes. In some cases candidate technical solutions already exist within DWSS but have not been leveraged within the IV-A Program (e.g., the existence of ILog JRules(rules engine software)). The maintenance and modernization plan must leverage these platforms and tools in support of specific responses to the functional gaps as well as to advance the system towards the goal of sustainability. Table 9: Solution Options for Technical Gaps Technical Gap The IV-D system must migrate Away From CSP

Solution Options DWSS has received proposals for a migration from CSP to EGL that are based on an automated conversion toolset and methodology Alternately, a “handcrafted” refactor-and-translate methodology could be used, but would necessarily take years and a large contingent of technical staff, while delivering a theoretically “cleaner” converted codebase.

The IV-D system must use a unified database model

It is possible to unify the database on the mainframe-based DB2 database platform. This has been prototyped and was judged to be

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 71

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Technical Gap

Solution Options successful. (Note: increased operating costs were observed during as a result of the prototyping.) Alternately, unifying on the server-based DB2 “Universal” edition (UDB) is also an option. “Native” access from any COBOL-based code may be more difficult, but is theoretically possible through middleware. Another alternative would be to migrate to another relational database product altogether (MS SQL Server, Oracle, MySQL, etc.). This would obviously be a larger technology shift, and would add new products to an already-large technology footprint.

The IV-D system must adopt a SOA

While there are numerous architectural alternatives, including the current architecture, SOA is widely accepted in industry as the preferred architecture for systems integration, and provides numerous compelling benefits to DWSS. It is also an established strategic direction for DWSS and has already been adopted on the IV-A side.

The IV-D system must adopt a business logic layer

A distinct layer for hosting domain-specific business logic is a current architectural Best Practice, and typical of newer n-tier software architectures. The current architecture, with presentation code mixed with business logic, is the main alternative, but comes at the price of not being able to reuse existing business logic effectively.

The IV-D system must separate business logic from presentation

As an extension of the business logic layer discussed above, conversion methodologies must strive to separate presentation logic from business logic, in order to create a stronger base of reusable software assets. It is unlikely that the automated EGL conversion will achieve this. The main way of filling this gap may be by choosing to refactor code only when it must be rewritten for other reasons (functionality updates), perhaps adding in some ongoing amount of targeted rewrites for strategic benefit.

The IV-D system must minimize coupling between IV-A and IV-D

It may be possible to separate the databases by “cloning” each into its own instance (one for IV-A and one for IV-D), and then replacing code that updates the non-native (the “other”) instance. Alternatively, it may be possible to separate the data coupling inplace, refactoring shared data tables so that there is a IV-D “private” data set and a distinct IV-A one. Code would also have to be updated to reflect the new data configuration and ownership rules. A Master Data strategy is another alternative, as it explicitly recognizes what data are to be shared between programs (e.g., client demographics), while creating managed program-specific attributes that are protected by stringent update rules and protocols.

The IV-D system must increase mainframe capacity

Data purging and archiving, spot-optimizing, and mainframe upgrades, as discussed in the functional gaps section, should all be considered. A physical separation of the IV-A and IV-D systems through a clone-and-refactor strategy might yield increased performance if it were coupled with the addition of new hardware to run one of the separate instances on.

The IV-D system must employ security conventions in the database

The current system’s rudimentary data controls should be augmented to provide mechanisms (metadata, leveraging database-level security mechanisms) for finer-grained access controls. These additional controls will allow for protection of FTI (Federal Tax Information) and PII (Personally Identifiable Information).

The IV-D system must adopt a user repository to support

With PDS and the Novell Access manager software, DWSS has the foundations of a strong user repository and I&AM (Identity and

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 72

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Technical Gap role based access

Solution Options Access Management) system. An extension of that basic model might be considered to accommodate the needs of higher-volume counties with their larger, more specialized user roles and their very dynamic caseload distribution rules.

The IV-D system must make use of a rules engine

DWSS has ILog JRules software available, but has never used it in IV-D. Rules-management software such as JRules may provide compelling solutions to difficult programming including challenges such as financial distribution, caseload management, and case closure.

The IV-D system must employ robust data warehouse tools

A separate and distinct data warehouse repository, fed by ETL (Extract, Transform, Load) from the transactional database, is the standard solution for data warehouse design. It offloads Business Intelligence (BI) activity from the “main” system, allows the data set to be enriched for BI-specific uses, and offers superior tools for handling time-based “trending” analysis. Alternatively, it is sometimes possible to satisfy modes data warehouse & BI needs by using an in-place data warehouse, often just a specialized set of views that overlay the existing transactional database. Obviously this does less to offload work from the main system, and may be limiting in the kinds of analysis it enables. The IV-D program is already making use of existing business intelligence and reporting using Business Objects and Crystal Reports. It has purchased an ETL tool for Business Objects/Crystal Reports but it has not yet been deployed.

The IV-D system must employ robust system integration toolsets

Additional tools may become available as part of the CSP migration. Additional integration tools, such as an ESB also exist and are being used by the IV-A program. Maintenance candidates and modernization increments should strive to increase use of these toolsets.

The IV-D system must employ robust developer toolsets

Additional tools may become available as part of the CSP migration. Additional integration tools, such as an ESB also exist and are being used by the IV-A program. Maintenance candidates and modernization increments should strive to increase use of these toolsets.

Analysis Results: Architectural Alternative Analysis  As part of developing its TCSA for the Nevada IV-D System, PSI worked with DWSS to consider a variety of alternative configurations for the modernized system, eliminating those that were not viable, practical, and finally those that were less desirable than others. Through this process, the team ultimately arrived at the TCSA that is presented elsewhere in this document (see the Target System Conceptual Architecture section). This section presents a discussion of the Architectural Alternative Analysis for the Nevada IV-D system—the alternatives that were considered and the rationale that helped the team arrive at a definitive conclusion. It must be acknowledged that fewer alternatives needed to be considered (or less consideration given to some) because many elements of DWSS’s technology and architectural direction had already been wellestablished. This established infrastructure largely centered on the IBM WebSphere product line as well as deployed systems that leverage this infrastructure and are generally working well on the IV-A side.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 73

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Foundational Architecture Numerous architectures are possible for a brand new system, from centralized (mainframe-centric) to clientserver or Web-based, with numerous permutations and variations in between. The team ultimately arrived at the foundational architecture presented in the TCSA—a multi-tier Services Oriented Architecture (SOA) leveraging the Java / JEE technology platform and IBM WebSphere server products. Other options, including continuing as a mainframe-based system or converting to client-server, were considered but quickly dismissed as not practical for DWSS and not consistent with the architectural direction that DWSS has already established with its infrastructure and prior work on the IV-A side. In the remainder of this section, PSI will walk through each of the layers that exist within the proposed TCSA, discussing the key technology elements that make up the layers and presenting the rationale and/or decision-making process that undergirds the element’s selection.

Access / Security Layer This layer provides access control services, supporting multiple distinct user repositories (internal users, external users, federated). Š

Novell Access Manager (NAM). NAM is already in use by DWSS and is a solid platform that provides all necessary functionality for the identity and access-management services required by the internal and external user repositories. There is no need to consider an alternative.

Š

A Federated User Repository should be considered at some point in the future. This will allow DWSS to extend specific “slices” of system access to trusted external systems (e.g., OCSE, other states), while delegating the chore of managing those individual users’ credentials to the agency they hail from. (E.g., many states use federated user repositories to enable interstate portals for cross-state case lookup and information sharing.) Because there is no immediate need for this component, no recommendation is being made at this time.

Presentation Layer This layer provides functionality for interacting with human users (by “presenting” information to them and receiving input from them) as well as other systems. Š

Web Presentation. This component is needed to host Web-delivered content, including screens created in EGL.10 IBM WebSphere was selected because it is already in use, and is a

Web pages are not created automatically during the conversion process from CSP to EGL. Creating the Web presentation layer is a manual development process, which is done in the EGL language.

10

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 74

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

robust, mature and well supported platform. This component is suitable; the recommendation is to continue its use. Š

Portal Presentation.11 This component hosts portal-delivered content, including screens generated from current CSP (EGL). IBM Portal Server is already in use by DWSS, and integrates well with the remainder of the existing WebSphere-based product set. This component is suitable; the recommendation is to continue its use.

Š

External system access components. These components offer interfaces for other systems (OCSE, other agencies, other states) to interact with the IV-D System. Specific product choices include: ƒ

Š

IBM WebSphere offers suitable functionality for supporting Web Services and file exchange through file transfer protocol (FTP), SSH file transfer protocol (SFTP), and/or file transfer protocol over SSL / TLS (FTPS). No additional product is needed to fulfill this need.

CyberFusion. A data exchange product required for data exchanges with the federal Office of Child Support Enforcement. This proprietary product is already in successful use, and changing it out would require changes on the external agencies’ part. Because of this negative impact, it would be ill-advised to change it out. The recommendation is to continue its use.

Enterprise Service Bus (ESB) The ESB offers message delivery and message reformatting services in order to create a flexible channel for integrating external systems with the IV-D System, as well as for facilitating internal communication among the system’s layers. DWSS already has the main elements of an ESB in place, including the following specific components: Š

IBM MQ-Series is commonly used to enable reliable and controlled message queuing and delivery between components.

Š

IBM Process Manager also has some capabilities to serve in the ESB space, specifically for rules-based message transformation and routing.

11 Portal presentation and Web presentation differ primarily in that portals are smaller, more task-focused units of functionality (portlets) that are specifically designed for combination into larger screens that the user interacts with. Web presentation is more akin to “traditional” single-purpose screen design, with entire screens changing out depending on the task flow in which the user is participating.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 75

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

IBM Web Services Registry and Repository (WSRR) is an additional component that allows invocation of services by signature rather than hard coded service names or locations.

These components have the benefits of being in place already, and of being likely to work well together because they all come from the same technology vendor. The recommendation is to continue use of these products.

Workflow Layer The workflow layer offers workflow services to the architecture. Š

IBM Process Manager is the presumed technology for workflow services. It is already in place and supports automated workflow. Product usage will be extended to adress manual workflow as well as part of its implementation within Child Support. This product’s feature set provides suitable facilities for full workflow orchestration. This includes features for interacting with human users as will be needed in implementing the kinds of workflows called for by the workflow layer. This is a robust technology, is at least familiar to Nevada, and integrates nicely with the remainder of the existing product suite. PSI recommends building capacity to support and leverage this tool.

Application Layer This layer holds the majority of the business logic in the system, and is where, over time, existing NOMADS functionality migrates. More details of this layer are documented in the TCSA section of this document. Major components of this layer include: Š

IBM WebSphere is an enterprise-grade Java / JEE application container that hosts Java code libraries and routines. This component is already in place and working well; there is no need to change it.

Š

Business Rules Engine (BRE) to implement decision-tree-heavy kinds of business logic (financial distribution, case closure) in a more declarative and straightforward style. ILog JRules is the presumed technology choice for implementing the BRE since it is already in use, an industry leader, and well supported.

Š

Implementation languages underlie all of the runtime components delivered by the application layer. The main implementation languages used by the TCSA will be: ƒ

EGL – IBM’s Enterprise Generation Language, which is the replacement for the CSP codebase, which comprises the current NOMADS system. EGL is indirectly generated from CSP through a conversion process. EGL, in turn, generates native languages such as COBOL and Java.

ƒ

.NET – Microsoft’s .NET platform was considered in the alternative analysis, but was ruled out as a viable alternative for two primary reasons. First and foremost, Nevada has already made a significant investment in Java and JEE, and is Nevada’s stated technology direction for the future. Additionally, there is no current ability to

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 76

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

generate .NET components from EGL, which eliminates, for practical reasons, the choice of the .NET platform as a feasible architectural direction. ƒ

COBOL – it is anticipated that some COBOL will need to be generated from EGL for specific purposes, such as interaction with CICS, Batch, and for instances where “screen scraping” is necessary. This is a legacy paradigm that is necessary in the short term, and there is no anticipation that additional functionality will be developed in COBOL.

ƒ

Java/JEE – Java and the JEE standards are the target environments for future development of the NOMADS system. Generated from EGL, they will allow the Web-enablement of existing NOMADS screens and the creation of a platform for existing as well as new functionality.

The opportunity exists during the maintenance phase of the project to extend the functionality from the Java code generated by EGL by leveraging some of the more important open source Java projects, such as Spring and Hibernate (also supported by IBM WebSphere). EGL already does this with the Rich UI output by leveraging the Dojo JavaScript libraries, as well as the integration with the Eclipse development environment. EGL-generated Java code can call local, native programs written in C, C++, or Java and can call remote CICS, IBM I, or IMS programs. The java code generated can be “straight java”, JEE, JavaScript & Ajax using Dojo or Silverlight, and JSF. Integration between EGL-generated code and native Java code may occur in two ways: Š

Use EGL to access a native Java interface or class from within EGL code. The developer can use EGL syntax to work with Java classes.

Š

Use a native Java class to call an EGL-generated program, via a Java “wrapper” and a set of Java classes that are deployed with the native class. The wrapper acts as an intermediary between the externally created Java code and the EGL generated program (Figure 5).

Figure 5 - Java Diagram

EGL hides the details of data conversion. The native code invokes the wrapper, submitting data to be transferred to the Java program, then calling the program (which might be on a remote platform). The wrapper accepts data returned from the program and relays it back to the native program.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 77

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The Java wrapper is specific to the EGL-generated program that is called and the wrapper and Java program can be generated at the same time (Figure 21).

Figure 6 - Generation of Java Wrapper and Java Program

Data Layer This layer offers data storage and access services (e.g., CRUD—Create, Read, Update, and Delete) to the IVD System architecture. This layer offers the following main elements: Š

A DB2 IV-D database representing the successor to the current mix of DB2 and UDB databases currently in use after they’ve been unified and moved to a single database platform. Much discussion was given to this topic during alternatives analysis, but DB2 on Z/OS ultimately won out over the other options considered, which included: ƒ

IBM DB2 UD. This is the “Server” edition of DB2, suitable for running on Windows or Unix operating systems on server-grade (non-mainframe) hardware. While the deployment cost profile of a non-mainframe version of DB2 has the potential to be better, DWSS personnel had concerns about the robustness of the platform when compared to the performance of the mainframe edition. Further, it was uncertain whether mainframe-based code, which undeniably will continue to exist for some period of time, could access a server-based database as efficiently as a mainframe-based edition. For these reasons this alternative was dismissed.

ƒ

Other Relational Database Engines. E.g Oracle, SQL Server, MySQL, Postgres, etc. While relational database products are “commodity” products to a certain degree, there is also a degree where they are not (each has its own semi-proprietary stored procedure language, administrative interface, and driver suite.) The “porting” cost that derives from these differences would net out to being substantial, and the gain would most likely be nil or inperceptible. Because of this poor cost/benefit profile, this alternative was dismissed.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 78

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

A master data database which will allow for more controlled and effective sharing of key data (e.g., client and employer data) between IV-A and IV-D.12 “Master Data” is both a concept and a product category, which is to say, this component could be fulfilled by buying a “Master Data” product (e.g., Oracle’s MDM product) or by implementing a master-data strategy on top of traditional database architectures. Because there is no immediate need for a master data solution, no specific product choice is recommended at this time. Later modernization increments will need to take up the question of whether to buy a product or simply implment a master data management concept on top of traditional database products.

Š

An ECM (Electronic Content Management) database represents the evolution of the current FileNet image database. There is no anticipation of replacing the FileNet technology since it is in place, it works, and was only recently procured at no small cost.

Š

A Data Warehouse allows you to structure historical data for more effective reporting and data archival. One side effect of building a data warehouse is offloading historical data from the IV-D daily operating environment. Business Intelligence technologies can be applied to purposes such as analytics, business process modeling, predictive analytics, executive information systems, electronic data sharing, regulatory compliance, and many other purposes. DWSS is currently experimenting with strategies that expose reporting “universes” from the current transactional system to solve some reporting / business intelligence needs. In light of these efforts, there is no immediate requirement for selecting a data warehouse tool. Later modernization increments will need to take up the question of whether those universes adequately satisfy all “data warehouse” and reporting needs, or if a more formal data warehouse product will be needed.

Analysis Results: Target Conceptual System Architecture (TCSA)  This section presents the TCSA for the Nevada IV-D System. The Project Team took a pragmatic approach to developing this architecture, with the following factors all heavily influencing the architecture that was ultimately developed (for more on the rationale for the TCSA and the alternative configurations that were analyzed, see the section Architectural Alternative Analysis, earlier in this section): Š

12

Modernized. Ultimately the TCSA must represent a substantially modernized system that is sustainable, meets the IV-D Program’s functional and operational needs, and controls maintenance and operational costs.

See the discussion of “Master Data” in the TCSA section for more background on this.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 79

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Achievable. Is the TCSA an architecture that can be reasonably arrived at from the starting point that is the current NOMADS IV-D System, particularly given the incrementalimprovement approach that will necessarily be used to update the system?

Š

Leverages Existing Assets. A practically-grounded TCSA should acknowledge assets that already exist within DWSS and, to the extent they are suitable for the overall architecture, incorporate them. The Project Team considered the following kinds of assets for leveraging in the TCSA: ƒ

Existing Product Sets and Frameworks. DWSS had made substantial investments in a number of specific hardware and software products (e.g., IBM WebSphere, IBM DB2, ILog JRules, etc.) that were considered for inclusion in the TCSA.

ƒ

Prior Architecture and Development Work. In addition to specific product sets, DWSS also has put these products into service in projects like AMPS, and by so doing, developed a more concrete and DWSS-specific architecture, much of which can be leveraged for the TCSA. (E.g., patterns and tools for registering services in IBM WSRR and looking them up at runtime, for using Novell Access Manager (NAM) to identify and define access levels for users, etc.).

ƒ

Skill Sets & Training. DWSS also invests in its people by training them in its core toolsets and by selecting for skills that match its environment. This is an important element of organizational effectiveness, and so must be considered in any pragmatic TCSA.

The TCSA will be presented as a series of “views,” each of which focuses on a specific way of understanding the architecture. Specifically, the following views are presented in the subsections immediately following this introduction, which together describe the main elements of the Nevada IV-D System TCSA: Š

Functional View. Discusses IV-D Systems in terms of its main functional elements—the functionalities it currently supports.

Š

Information Flow View. Discusses IV-D Systems in terms of the key types of data it manages and processes. Also discusses data interchanges between IV-D Systems and external systems (data partners).

Š

Development View. Discusses IV-D Systems in terms of its main technological components and programming tools.

The Requirements Validation subsection that follows these views provides a summary of how the TCSA supports each of the high-level functional and technical requirements identified by PSI’s assessment.

Functional View For the TCSA, the functional view looks virtually identical to its counterpart in the as-is architecture. The overall structure and mission of the IV-D program is not anticipated to undergo any radical change within the time period of this Plan so the TCSA must support the same program functions, such as establishment, locate and enforcement, that are today supported by Nevada’s IV-D System. Figure 22, below, identifies the major NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 80

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

functional areas of the Nevada Child Support Program and the primary business processes/core activities within each functional division. Like the as-is view, the listing is not meant to be exhaustive or to reflect the variations in functional divisions and/or alignment of business activities across Nevada’s local programs. The listing is intended to illustrate the variety of Nevada Child Support Program functions and processes that should be supported by appropriate automation within a modernized IV-D system.

Figure 7 - IV-D System Functional Areas

The TCSA is intended to provide a foundation for improving the level and quality of automation support and ease of use for the program and thus to address the deficiencies reflected in the Needs Assessment section. For example, the introduction of a business rules engine, workflow support and data warehouse (shown in the development view below), are specifically intended to provide tools for improving identified user needs for more comprehensive automation, directed navigation through functional tasks and better reporting.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 81

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

As is described more fully in the Development View, the TCSA will continue to supply (and improve) generic IV-D system capabilities that facilitate work across multiple Child Support functions and business processes such as: Š

Document generation

Š

Document/content management

Š

System user management and security

Although ancillary applications will continue to exist, the goal of the TCSA is to support the eventual integration of what are now separate applications into a more unified IV-D application layer. Accordingly, it is anticipated that distinct applications like ANSRS and LOTW will no longer stand alone in the “end state” for the system but will be core components of IV-D interface. Despite the integration of functionality currently delivered as stand-alone applications, the TCSA will continue to support separate applications where necessary and desired. While applications like EWS, Compass and Business Objects may live on as distinct elements of functionality with their own infrastructure, the TCSA is designed to facilitate a more integrated user experience across these applications with the goal that users will not perceive these as distinct from the overall Child Support application in which they do their day-to-day work. Better management of the data interfaces (SCaDU, OCSE, Motor Vehicles, Vital Records, and Utilities among a host of others) that support a range of functions including obligation establishment, investigations, parent location, and enforcement is also a desired outcome of the TCSA. As is described more fully in the Development View, the TCSA provides improved tools to manage these interfaces and improve both automation and user access to the information exchanged between the IV-D program and outside entities.

Information Flow View The Information Flow view describes the way the IV-D Systems architecture stores, manipulates, manages and distributes information. This view identifies the data to be managed, the high-level systems and subsystems that implement Child Support functionality as well as the interfaces between them, and division of labor regarding data ownership.

Data Structure As noted in the As-Is System Architecture section, the IV-D System manages several types of data. Two broad categories of data are functional data and system data. Functional data is the business data which is related to the business performed by the systems, such as person, case and financial processing, and which has meaning outside of the systems. Like the as-is architecture section, the TCSA described here primarily concerns itself with the functional data, which it groups in terms of functional purposes shown in the following table.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 82

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The IV-D System functional data structures include person data, case data, obligation data, financial processing data and a host of related cohorts (such as employer data). Table 10 below provides examples of some common Child Support data groupings. Table 10: Common Child Support Data Groupings Data Cohort

Description examples

Person

The primary parties associated with a case (Custodial party, non-custodial obligor, beneficiary). Includes person name, type/role, and associated demographics such as address.

Case

The data making up the elements of a specific case (including an obligor and at least one beneficiary). Includes Case identifier, case type, date established, parties, etc.

Obligation

The data making up the Child Support ordered in a case. Includes the Order amount, date, frequency, medical support.

Payment

Data reflecting the payments made by a Child Support obligor. Includes Payment amounts, source and dates.

Event

Case events. Includes hearing date and type, remedies invoked, status changes.

Distribution

Data detailing the distribution of payments. Includes amount, date, case, and beneficiary.

As with the current system, data cohorts in the TCSA will be represented by numerous tables in a DB2 database and have a variety of attributes. The TCSA contemplates the continuation of a relational and normalized data set with improved data modeling to support the complex business needs of the Child Support program.

Data Sharing The primary data store for the IV-D Systems in the TCSA will be the IV-D DB2 database. The TCSA does away with the UDB database currently supporting ancillary applications in favor of a single data repository. For all primary case and party data, however, the DB2 data will represents the official version. As is described in the Development View, the TCSA contemplates a Master Data Manager to address the conflict between IV-D and IV-A program functions over key data elements (such as Person and Employer) currently impacting program accuracy and efficiency. An illustration (not intended to be comprehensive) of this relationship is shown in the Figure 23, below:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 83

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Figure 8 - Data Model (IV-D Perspective)

The day-to-day work of the Child Support Program will continue to depend upon a wide variety of data exchanges between DWSS and external partners ranging from the Federal OCSE and the IRS to State licensing bureaus. These data exchanges are vital to many of the key Child Support functional areas including initial case referral and set up, location of absent parties, enforcement and financial reconciliation and distribution. These interfaces involve a variety of distinct data streams. The TCSA envisions the use of an Enterprise Service Bus to manage these data exchanges as illustrated in Figure 24, below:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 84

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Figure 9 - Example Data Exchanges with Partners

The ESB is envisioned to improve the quality and accessibility of partner information as well as to ease the work involved in adding or modifying exchange opportunities. The ESB concept in the TCSA is described in more detail below.

Development View This section discusses the TCSA of the IV-D System from a development point of view. It describes the system as a number of distinct layers, each with its own set of responsibilities within the overall architecture (e.g., Presentation, Access Control, Data Access, etc.). Figure 25, below, shows the TCSA using a layered description approach. The narrative that follows the diagram explains the different layers, proceeding from the top of the diagram to the bottom.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 85

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Figure 10 - Target Conceptual System Architecture (TCSA)

Client Layer This layer does not belong to the system, but rather represents a conceptual layer where users of the system exist and access the system. There are several key constituencies who will be accessing the IV-D System, including: Š

The general public can access largely static and non-database functionality (program information, perhaps things like guidelines calculators, etc.).

Š

CSTs, NCPs, and employers are able to create user accounts that grant them limited and specific access rights, perhaps to specific subsets of case information The “employer” subset is not case-based, but instead will model upon and extend the functionality in the EWS system.

Š

State and County Child Support Program users access a Portal layer that gives them access to their caseload, alerts, and other tools for performing their job functions.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 86

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

External Systems conceptually come in via this Client layer, but in reality the actual communication channel will vary, ranging from a node on the same network (e.g., IV-A, SCaDU) to Web Services over the Internet (e.g., other state systems, OCSE, etc.). Please note that there will be many more external systems than the three depicted—these are standins for a wider set of systems. Also note that it is expected that DWSS will expand its use of the OCSE State Services Portal (SSP) in the future, making the OCSE SSP a significant external system to the future IV-D System. In addition to the QUICK functionality that is already being used, the SSP is expected to provide some or all of the following functionalities in the future: ƒ

Employer Search

ƒ

Passport Denial

ƒ

Department of Defense Entitlement

ƒ

Debtor Lookup

ƒ

e-IWO

ƒ

Federal Case Registry (FCR) Locates

ƒ

Voluntary Collection Reporting

Access / Security Layer This layer provides access control, ensuring that users are authenticated against a repository of known users. This layer further ensures that the users are given credentials that allow them to perform only the functions that are granted to their roles. It has the following sub-components: Š

A Security Platform that leverages the Novell Access Manager (NAM) identity and accessmanagement system that already provides sign-on services for existing Web applications and numerous applications on the IV-A side.

Š

A NAM-based Internal User Repository that identifies known internal users (IV-D personnel, county personnel, etc.) to the system. This repository includes a customdeveloped user interface, PDS, which allows administrators to provide security provisioning for all internal users in IV-D.

Š

A NAM-based External User Repository that identifies known external users (CSTs, NCPs, employers) to the system. This repository supports account self-creation and provides mechanisms for users to be given limited functionality until their account is verified.

Š

A Federated User Repository that allows the IV-D System to designated “trusted” external systems (i.e., OCSE, other states) whose users will be granted specific access roles and permissions within the IV-D System. In essence, the federated user repository is a proxy

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 87

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

repository that is always kept up-to-date (by the external agencies that each own part of it), allowing the IV-D System to authenticate against it as though it was a local repository without having to directly manage those users.

Presentation Layer This layer provides functionality for interacting with human users (by “presenting” information to them and receiving input from them) as well as other systems. It has the following main components: Š

A Web component that presents a communication channel for dealing with the general public, NCPs, CSTs, and employers. It services users coming in via the Internet, and offers interactive Web pages customized to the user type. Note that IBM WebSphere is the presumed technology product for developing and/or building out this component.

Š

A Portal component that presents a communication channel for dealing with internal users (State and County staff primarily). This component also services users coming in via the Internet, and differs from the Web component primarily in the constituencies it services and, to a certain degree, the presentation modes and technologies it may (or may not) use. Specifically, it is possible that internal users would benefit from the use of actual Portal technologies and delivery methods—i.e., employing a portal product and establishing portlet standards so that users can customize their pages to be more productive. This is not essential to the definition of “portal” that PSI is using here—“portal” is simply a specific and moretightly-controlled communication channel that services a specific subset of users. Note that IBM WebSphere Portal is the presumed technology product for developing and/or building out this component (although standard WebSphere is also an option).

Š

A System Access component that offers interfaces for other systems to interact with the IVD system. Primary modes of integration are likely to include file exchange (FTP, SFTP, Cyberfusion, etc.) and Web Services. These integration points will leverage the services of the Enterprise Service Bus (ESB) described in the next subsection. Although the diagram does not depict it, IBM WebSphere is the presumed technology product for implementing any Web Services that are developed.

Enterprise Service Bus (ESB) The ESB offers message delivery and message reformatting services in order to create a flexible channel for integrating the outside world with the IV-D system. The ESB can access all the services of the layers of the architecture, notably the Access / Security layer, the Presentation layer, the Workflow and Application layers, and the Data layer. This allows it to support use cases like the following: Š

Accept a fixed-field file from a partner via FTP and move it right to a staging location for processing by a batch job (quality-checking the file along the way, perhaps).

Š

Authenticate an incoming partner against the Security Layer to make sure they are allowed to access an interface. Once authenticated, accept a fixed-field file from the partner via FTP or

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 88

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Cyberfusion, and decompose the file into individual records. Call a specific Web Service in the Application for each record in the file in order to process the file into the system. Š

Accept a Web Service call directly from an external user. After authenticating the user against the Security Layer, reformat the incoming message to “canonical” form so that an existing Web Service can be used to process the message.

Note that the ESB contains a Services Registry component, which is presumed to use the technology product IBM Web Services Registry and Repository (WSRR). A services registry allows all parts of the system to acquire and invoke services via services signatures rather than by hard-coding service names - making the system overall more flexible and loosely-coupled. Also note that IBM MQSeries is the presumed technology product for implementing the messaging elements of the ESB13.

Workflow Layer The workflow layer offers workflow services to the architecture. Workflows in this layer implement specific business processes such as Intake, Establishment, Enforcement, etc., and do so by leveraging lower-level services down in the Application layer. Workflows are easier to modify when business processes change, so this allows the more fluid parts of the Child Support business to be “factored out” of the system and made more maintainable overall. Note that IBM Process Server is the presumed technology choice for implementing the workflow layer.

Application Layer This layer holds the majority of the business logic in the system. Over time, existing NOMADS functionality migrates here, as well as the existing ancillary systems such as NAWC, LOTW, etc. Some key aspects of the Application layer are: Š

Sub-layering. Best Practice calls for this layer to have its own internal “layered” architecture, with distinct sub-layers for: ƒ

A "view" sub-layer, which is responsible for invoking services and returning HTML / XML to the Presentation layer.

ƒ

A "business logic" sub-layer for large-grained business logic (e.g., “account creation” or “case closure”).

13 IBM Process Server also has some responsibility for implementing the ESB, although PSI has placed it in the Workflow layer because it has stronger affinity for implementing that layer’s functionalities.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 89

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

A "services" layer for reusable services and fine-grained business logic (analogous to reusable “called modules” in today’s NOMADS—e.g., "make a pseudo-employer number,” or “take this name and case status and derive a case number from it,” etc.).

Š

Services. Some (large-grained) services are explicitly focused on external users (e.g., “Customer Self Service,” “Guidelines”) while others are more pointed at internal users (e.g., LOTW, Intake, Establishment, etc.). But both internal-focused and external-focused are all fully-privileged services, and can share lower-level services (e.g., code to implement a guidelines calculation) to enable code reuse and consistent application of business logic.

Š

Business Rules Engine. Note the inclusion of a Business Rules Engine (BRE) component in this layer. This component provides specific functionality for implementing decision-treeheavy kinds of business logic (financial distribution, case closure) in a more declarative and straightforward style. ILog JRules is the presumed technology choice for implementing the BRE.

Š

Languages. A major element of the Application layer is represented by the grey arrow depicted towards the bottom of the layer. This arrow describes the main implementation languages that underlie all of the runtime components delivered by the layer. The main implementation languages used by the TCSA will be: ƒ

EGL. The TCSA assumes that the CSP (IBM’s Cross Systems Product) codebase that underlies the current NOMADS mainframe system will be converted to EGL (IBM’s Enterprise Generation Language), which is necessary for reasons discussed elsewhere in this document. EGL is a code generation language, meaning that it does not execute directly, but rather generates one of several target languages, notably COBOL and Java. Because much of the system’s source code will remain in EGL, EGL must be considered one of the languages that underlie the Nevada IV-D System, even though EGL never directly executes on the production system.

ƒ

COBOL. COBOL is one target language that is generated from the EGL source code. It is anticipated that COBOL will continue to be generated, at least for all screens that are “scraped” by HATS applications like AMPS or by client-side macros, for the immediate future. This is a “legacy” construct, however; no new code will be built directly in COBOL.

ƒ

Java/JEE. The other key target language that will be generated from EGL code is Java. EGL-generated Java screens will be used to Web-enable the existing NOMADS screens, and create a platform for improving their functionality in-place, as well as integrating new screens alongside them (that will be coded directly in Java).

ƒ

The TCSA’s Java runtime will also support other DWSS-built application components, such as LOTW and NAWC, that were built directly in that language.

ƒ

Further, new application code will be presumed to be developed directly in the Java language. This will include batch modules, screens, and Web Services that support them.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 90

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

Š

.NET. This language runtime (which supports the C# and VB.NET languages, among others) exists both to support vendor-developed applications such as EWS, as well as to give the architecture access to a wider set of components and implementation languages. Specifically, there are existing .NET software components in Clark County (and perhaps other counties) that already interact with the NOMADS database, and may be candidates for leveraging to supply specific kinds of functionality.

Note that a long-term goal for DWSS is to incrementally replace all of the EGL code with more robust and reusable Web Services. Because of the size of the existing codebase, however, this process may take many years. Accordingly, the TCSA’s support for both EGL and COBOL is likely to be a long-term condition of the NV IV-D System. At some point, however, all EGL code will have been replaced with more up-to-date Java and/or .NET code, and the TCSA’s implementation languages will be reduced to simply Java/JEE and .NET.

Data Layer This layer offers data storage and access services (e.g., CRUD—Create, Read, Update, and Delete) to the IVD System architecture. This layer offers the following main elements: Š

A IV-D Database that represents the successor to the current DB2 and UDB databases, after they’ve been unified and moved onto a single database platform. This data store holds all IV-D Case Management data. Note that IBM DB2 on z/OS is the presumed technology choice for the IV-D database

Š

A Master Data database.14 Specifically, client (person) data and employer data will be put under master data management, which will allow for more controlled and effective sharing of these key data between IV-A and IV-D. While there is no presumed technology choice to mention here, it should be noted that a master data strategy can be implemented with a

14 A master data database holds key record types and implements processes to tightly control users’ and the system’s ability to change those data, with an intention of making sure inappropriate additions / changes are minimized. In child support, key record types might be:

Š Employers Š Persons / Clients Š Cases Basically anything where there is a demonstrated need to share the data across agencies (e.g. client data being shared with IV-A) or a perceived “duplicates” and / or “merges” challenge today is a candidate for applying a master data management strategy.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 91

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

MDM (Master Data Management) tool or within an architecture by implementing MDM patterns and discipline. A modernization increment will most likely be dedicated to developing a MDM strategy and solution. Š

An ECM database represents the evolution of the current FileNet image database.

Š

A Data Warehouse database specifically services data warehouse and business intelligence (BI) functions. It maintains more trending and analysis data than the IV-D database, and it is fed by frequent (weekly, monthly) updates from the IV-D database via an ETL (Extract, Transform, Load) process. There is no presumed technology solution for this component.

Requirements Validation This subsection illustrates how the TCSA supports each of the high-level functional and technical requirements identified by PSI’s assessment. Please see the Needs Assessment Results Section of this document for a full description of these requirements. Table 11: TCSA Support for Functional Requirements Requirement

How requirement is met in TCSA

The IV-D system must meet federal certification standards and requirements.

The TCSA application layer provides flexibility and versatility required to meet current and future federal certification standards and requirements. EGL, Java and JEE provide the tools to meet virtually any application requirement. The business rules engine provides separation, visibility and flexibility for complex program logic. Distribution rules, rules surrounding incoming locate information and enforcement timeframes exemplify the logic that can best be served within the rules engine. The access/security layer provides tools to meet stringent security requirements and control interfaces with external systems.

The IV-D system’s availability and performance must support consistent worker productivity.

The TCSA supports improved system availability and consistent worker productivity in a number of ways. The layered architecture accommodates resource expansion and technical improvements to specific targeted areas of need. Automated workflow and expanded customer self-service options enable workers to focus efforts on tasks requiring human judgment and human interaction. Business intelligence capabilities facilitate efficient and effective use of human and system resources to maintain and improve productivity. The architecture can be deployed in a high availability server environment and is scalable to meet increasing demands.

The IV-D system’s user interface must be intuitive and support efficient user navigation and information retrieval.

The TCSA supports an intuitive user interface and efficient navigation and information retrieval through a separate and modern presentation layer. This includes Web page displays and a portal to facilitate navigation and user customization. IBM WebSphere provides a rich toolset for developing intuitive and efficient user interaction. Developing and following user interface standards ensures the tools are used to their fullest potential and makes the system even more intuitive through end-to-end consistency.

The IV-D system must utilize and support imaging and document management technologies.

The TCSA accommodates not only the storage of images within the data layer but also accommodates tight image integration within the application through coordinated communication between the application, the ECM repository and workflow using the ESB and services registry. The TCSA supports both auditable access to images and the ability to drive and support image-based workflow similar to the way images are currently integrated into workflow within the SCaDU.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 92

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Requirement

How requirement is met in TCSA

The IV-D system must support program goals and objectives by providing automated management tools for assigning, monitoring, reporting and auditing casework.

The TCSA supports program goals and objectives by improving case management through the use of an improved and consistent user interface, automated workflow, a business rules engine, images and business intelligence - all tightly integrated within a single unified application. The TCSA support both specialized and generalized caseload management functionality to meet the needs of both large and small offices.

The IV-D system must provide robust and flexible reporting.

The application layer of the proposed architecture provides for robust and flexible reporting through the use of Business Objects, business intelligence, and custom development. A data warehouse supports these reporting efforts while reducing contention for the primary database.

The IV-D system interfaces must generate and populate useful, accurate information and the system must present that information to the user, all in a manner that advances Child Support casework.

The architecture includes an access layer for carefully controlled external system integration. Business rules within the rules engine control precisely how information received populates the system and provides user visibility into the logic behind the process. The integration of the various components within each of the architectural layers enables the orchestration necessary to present information to users in a manner that advances Child Support casework.

The IV-D system must maintain valid locate records.

The access/security layer and the application layer work together to support the maintenance of valid locate records. Carefully conceived business rules within the rules engine determine when new addresses can supersede previous addresses. Workflow rules control the address verification process. The data layer ensures that a complete and accurate audit trail is maintained for address information both current and historical

The IV-D system must support reliable IV-A and IV-E referrals and updates.

The architecture includes an access layer for external system integration. This layer, in combination with the business rules engine for reliability, services for specific needs, and the ESB for communication, assures that this requirement is met.

The IV-D system must have workflow management capability to automatically move the case to the next activity or business process or, when appropriate, present relevant information to the user to manually move the case.

The architecture includes a workflow layer to process cases through their life cycles. The workflow layer supports both automated and manual activities. The ESB present in the architecture assists in communicating the various states of cases to the user.

The IV-D system must have a robust financial management component that maintains an accurate accounting.

The TCSA supports robust, secure and accurate financial accounting management. The access/security layer provides data security. The data layer provides uncompromised financial records and a comprehensive audit trail. The rules engine and application logic provide auditable financial processing including allocation, distribution and disbursement logic. The ESB orchestrates communication between the various layers involved in financial management.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 93

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Requirement

How requirement is met in TCSA

The IV-D system must support effective, efficient customer service.

The TCSA supports effective and efficient customer service through the application layer for both self-service and representative-assisted interactions. Effective and efficient customer service relies on finely tuned applications that anticipate customer needs and make the desired information readily available quickly and easily. The access/security layer, presentation layer, workflow layer, application layer and data layer must all function seamlessly together, and do, with assistance from the ESB. User interfaces must, and can, be specifically tailored to customer service needs through the power and flexibility of the components comprising the TCSA.

The IV-D system must employ consistent program security standards.

The architecture provides an access security layer through which programs authenticate and authorize internal and external users in accordance with established security policies.

Table 12: TCSA Support for Technical Requirements Requirement

How Requirement is met in TCSA

The system must migrate away from CSP

The TCSA replaces CSP from the current environment with IBM’s EGL (Enterprise Generation Language) and Java.

The system must utilize a unified database model

The TCSA reflects a unified IV-D database using IBM’s DB2 on the mainframe.

The system must adopt a SOA

The TCSA specifies that SOA is a central component of the architecture.

The system must support a business logic layer

The TCSA specifies that a separate business logic layer will exist.

The system must separate business logic from presentation

The TCSA specifies a presentation layer separate from other layers where business logic may reside such as access, security, workflow, application and data layers.

The system must reduce coupling between IV-A and IV-D

The TCSA designates an access layer through which the IV-A system integration can occur as an interface. The TCSA also accommodates services that can support interaction between the two applications. The unified IV-D database presupposes that IV-A data has been separated into its own environment.

The system must optimize mainframe capacity

The TCSA moves much of the processing to server-based technology. The mainframe’s capacity is optimized by reducing demand on it and by allowing it to serve exclusively as the provider of database services. As stated above in response to the functional requirements, the layered architecture of the TCSA accommodates resource expansion and technical improvements to specific targeted areas of need.

The system must adopt and consistently apply data security conventions in the database

By providing an access/security layer, a data layer and an application layer, the TCSA promotes definition of security policies and enforces them at appropriate layers including the data layer.

The system must use a single user repository to support role based access

A security layer is specified in the TCSA which provides for a single user repository for internal users, external users and federated users and supports role-based security.

The system must adopt a rules engine

The TCSA specifies a business rules engine which resides in the application layer of the system.

The system must provide robust data warehouse tools

The TCSA specifies that the data warehouse itself resides in the data layer of the system. Data warehouse tools, such as BI and Business Objects, live in the

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 94

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Requirement

How Requirement is met in TCSA system’s application layer.

The system must employ current generation system integration toolsets

The architecture provides for an enterprise service bus (ESB) which can expose Web services to external systems. It includes service-oriented architecture (SOA) tools for integration of services within and outside the enterprise.

The system must enhance/improve developer toolsets

The migration of CSP to EGL (and from there to Java and JEE) will necessitate and avail the use of new, modern developer toolsets.

Analysis Results: Assessment of Nevada IV‐D System Governance   PSI and DWSS recognize that successfully stabilizing and modernizing Nevada’s IV-D System depends not only on a well formulated plan but an effective structure, sufficient resources and a well-designed, repeatable process for implementing that plan. Accordingly, PSI examined the relative strengths and weaknesses of Nevada’s current governance framework for the IV-D System. Given the primary purpose and scope of the NOMADS Assessment Project, PSI did not conduct a highly formalized governance assessment but instead focused on those governance challenges that will hinder, if left unaddressed, successful implementation of the maintenance and modernization plans. This section provides an overview of this assessment, culls out governance challenges and presents recommendations for strengthening Nevada’s IV-D System governance. “Nevada’s IV-D System”, as referenced in this document, includes the IV-D subset of the system mainframe plus the supporting systems (LOTW, NAWC) that extend its functionality. “Governance”, as discussed in this document, is the process by which an entity organizes itself in order to ensure its objectives are met. Following the clear articulation of objectives, good governance includes the organization, decision making processes, and accountability that will optimize delivery on those objectives. The primary goals of IV-D System’s governance are to 1) assure that investments in the IV-D system produce business (Child Support) value and 2) mitigate operational risks to the IV-D and IV-A programs. With these goals in mind, PSI reviewed the current governance framework and formulated recommendations to address identified governance challenges.

Current IV-D System Governance Structures and Processes PSI has had a chance through its interviews and documentation review to consider many aspects of the existing structures and processes for Nevada IV-D System decision-making. The current organization and decision-making process includes these main elements: Š

DWSS IS is the technology implementation group responsible for the resources and processes that deliver system functionality to users of both IV-D and IV-A systems. DWSS has several additional client agencies as well, and they are responsible for providing resources and technology support to all of them.

Š

The IV-D agency is responsible for delivering IV-D services to clients and is reliant upon the IV-D system mainframe, as well as the ancillary systems that have been developed to supplement it, to deliver those services.

Š

The Department of Human Services/DWSS enters into contracts with participating county District Attorneys to provide Child Support services for those counties. Participating

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 95

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

counties receive federal reimbursements. Counties may opt out of providing Child Support services. The current four year contract expires on 6/30/12. Participating District Attorneys are likewise reliant upon the IV-D system mainframe, as well as the ancillary systems that have been developed to supplement it, to provide Child Support services. Š

The IV-A agency is responsible for delivering IV-A services to clients, and is similarly reliant on the NOMADS mainframe, as well as its own set of ancillary and supplementary technology systems.

Š

DWSS IS has responsibility for keeping the IV-D mainframe system operational. This responsibility extends to developing enhancements, developing supplementary technology systems that support the mainframe, offloading work from the mainframe, or otherwise delivering functionality to both IV-A and IV-D users.

Š

DWSS typically handles sustainable maintenance and minor enhancements. Major system developments are typically outsourced using state procurement rules. In the past few years, County partners have been used to develop and deploy statewide enhancements.

Š

IV-D and IV-A communicate their needs15 to DWSS IS primarily in the form of enhancement requests, which are packaged as Planning Documents or Executive Summaries, and which describe a specific project, enhancement, or other program technology need.

Š

Enhancement requests are approved for work (becoming “Work Items,” or “WIs”) independent of the process that allocates resources to work on them (the so-called “slots” construct). This puts “approved” work items in a sort of “holding tank,” (the “approved WI list”) awaiting resources to develop the WI.

Š

Prioritization and approval of work items is performed on a division-wide basis, without specific consideration of the work item’s sponsoring agency (IV-A, IV-D, or another agency). The result of this process is that approved IV-A and IV-D work items (and their associated efforts) ebb and flow; creating “dry spells” where IV-D is getting few if any resources, and so is effectively stalled on its enhancement request projects.

15 PSI is ignoring “break fix” needs (bug reports) for this discussion, but acknowledges that they exist and follow their own workflow. Aside from competing for the same resources, PSI judges that they do not interact with the process this section is describing.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 96

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Challenges The current governance framework is reasonably well aligned with a “maintenance shop,” where the main elements of the technology are in place, working well, and only need upkeep and occasional updates. It is not optimal for the kind of structure that DWSS needs now in order to modernize NOMADS—a transformational and delivery-oriented structure. Some of the ways that the current framework fails to meet this transformational structure include: Š

Architecture Ownership. The current framework places responsibility for the architecture of the NOMADS system and related systems squarely on DWSS IS, while incentivizing the status quo as much as possible in order to minimize risk of service disruption. This cuts against innovation. This also tends to give the IV-D agency less ownership and control over the evolution of its architecture and how that architecture will meet its technology needs. IVD largely cedes its responsibility for understanding and influencing its technological architecture to DWSS IS, and interacts largely on the basis of suggesting enhancements and “tweaks” to the current system.

Š

Planning Horizon. Because of the uneven way that the current model allocates resources to the IV-D agency, the agency has little ability to plan around the availability of new technology enhancements. Many enhancements are many months or even years in the making, with most of that calendar time being spent in one wait-state or another.

Š

Resource Utilization. The “generalized pool” structure—where development (and other) resources are put into a generic pool and are allocated to work based entirely on the highestpriority, division-wide need—is designed to always deliver the most important work and to break down the “silos” of expertise that tend to develop over time. While it is successful in this regard—to a limited extent—it has a negative effect as well. By treating resources as generic, it often puts resources who are skilled in one area (IV-D financial processing, for example) onto projects they have no specific background for, and makes their time less productive for the agency overall. With the acute resource shortages DWSS is facing, maximizing the knowledge and productivity of resources, which includes leveraging their current skills and experience to the fullest extent possible, would seem to be an overriding priority for the division.

Š

Methodologies. As a matter of course, the current SDLC process is strongly oriented towards risk mitigation over efficient delivery. Additionally, to some degree it is systems and IT risk that is being considered more so than the customer program’s risk. By heavily formalizing and front loading certain kinds of work (requirements, estimation), and by performing these front end processes without securing and committing the resources necessary to quickly follow through on the resulting development, testing, and implementation processes, these methodologies can exacerbate the existing resource shortages. The result of the current methodologies is that projects may be delayed for protracted periods of time waiting on the resources necessary to execute the project’s next

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 97

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

stage. Additionally, in an environment where project priorities and approval are subject to change, a work item being approved does not mean that it will ever be delivered (numerous approved work items have been quashed later in their life cycle), resulting in work expended by scarce resources going for naught (by not delivering anything to a user). Project delays increase the risk that a project may be started, but never completed, and that work performed on a project may be at significant risk of being wasted. Taken as a whole, the current governance structures and processes are not in alignment with the IV-D program’s goals and objectives, or even holistically aligned with DWSS’ goals overall.16 The next section will present recommendations for creating a better alignment between divisional goals and the structures, resources and processes that are used to deliver on those goals.

Governance Recommendations The following recommendations address the governance challenges that must be addressed in order to stabilize and modernize Nevada’s IV-D system. While the maintenance and modernization plans will provide a clear system roadmap, successful execution of those plans will require real changes in how the IV-D system is currently governed. DWSS must transform both the current organizational structure and development process in order to effectively modernize the IV-D system. Most critical among these recommended organizational changes is a significant elevation of the program’s ownership role—including primary ownership of the IV-D system as well as the individual IV-D system improvement initiatives. This elevated ownership role is operationalized below in terms of specific assignments and responsibilities. It is also of vital importance to successful system modernization that the SDLC process be reengineered to be more project-delivery focused, more efficient, more accountable and more transparent. The key components of a redesigned SDLC are also outlined below including the embedding of program knowledgeable analysts in the process. (See Appendix F for a more detailed discussion of these recommendations) PSI believes that the potential of the maintenance and modernization plans can only be realized through explicit program ownership and a system development process that is efficient and properly resourced.

Designate and Authorize the Child Support Enforcement Program as Owner of the IV-D System The program’s business needs and performance goals will only be met if IT resources are effectively leveraged to optimize the future Child Support business processes. While maintenance and modernization plans will point the way forward, effective execution of these plans cannot be assumed. The successful implementation of the maintenance and modernization plans depends on establishing an efficient, deliveryoriented structure. This delivery-oriented structure holds the promise of leveraging limited IT resources to be

Inasmuch as maximizing the effectiveness of individual agencies such as IV-D and IV-A is not an outcome that is delivered by the processes.

16

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 98

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

more responsive to the program’s business needs. In this structure, IT related decisions are made and driven by the business. PSI believes that an effective delivery-oriented structure will require the program to: Š

Assume a much more active ownership role in the IV-D system’s evolution

Š

Effectively collaborate with DWSS Information Services (IS)

Š

Actively monitor the development and delivery of incremental system improvements on an ongoing basis

A higher level of program engagement in system concerns has been stimulated by this project and by preceding IV-D system projects – at least for their limited lifespan. A continuous modernization effort will now require sustained program ownership, engagement and accountability. The Child Support Enforcement Program is clearly in the best position to understand, effectively advocate for and verify satisfaction of its business needs. The Program will be in the role of primary decision maker, focused on delivery and supported by delivery specialists. This ownership role will help minimize any gaps between business requirements and deployed solutions. Therefore, PSI recommends that CSEP be formally designated as IV-D System Owner and, through collaboration with DWSS IS, be responsible for delivery of the future, modernized IV-D system. The CSEP ownership role should be operationalized by: Š

Designating a single IV-D System Owner Representative. This IV-D System Owner reports to the IV-D Director and has both program expertise and a conceptual understanding of the technology underpinnings of the IV-D system and collaboration skills. The IV-D System Owner must hold sufficient authority within the organization and expertise in order to ensure they are empowered to and are capable of making the necessary decisions

Š

Assigning IV-D System Owner responsibility for:

Š

ƒ

Overseeing the maintenance backlog and the prioritization of maintenance projects

ƒ

Overseeing the Modernization Roadmap and the prioritization of modernization projects/initiatives

ƒ

Overseeing the definition, qualification and development-estimation of project candidates

ƒ

Monitoring all active maintenance and modernization projects (The IV-D System Owner should receive weekly status reports from each assigned Product Owner or Project Manager)

ƒ

Being available to each Project Team throughout the life cycle of the project and responsible for mediating or making critical decisions as necessary

Allocating at least 50% of the designated IV-D System Owner’s time to address these responsibilities

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 99

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Assigning a CSEP Product Owner to each system development project or initiative. This role may be filled by the IV-D System Owner or another CSEP SME depending upon the nature and complexity of the project. The Product Owner will champion the project from start to finish. The Product Owner may be supported by a project manager on large projects

Strengthening the program’s ownership role is not intended to diminish, in any way, the essential, active role that IS must play in realizing the IV-D system’s transformation. Successful modernization is clearly dependent upon full collaboration between the CSEP and IS. In the envisioned delivery-oriented structure, IS will not passively support the program but will play an active role in solving problems, creating design options and delivering business process improvements through technology solutions. This CSEP ownership role of course also has constraints including the actual IS resources dedicated and otherwise allocated to IV-D system initiatives and, where relevant, consideration of potential negative impacts of IV-D system initiatives on other DWSS programs.

Align Nevada Child Support Strategic Planning, IV-D System Project Prioritization and Discretionary Resource Allocation. In these times public programs face greater scrutiny, accountability and demands for good governance. With fewer resources and greater scrutiny programs run the risk performance deficiencies and negative exposure. These risks are best mitigated by aligning the program’s strategic interests, integrating independent planning efforts and applying discretionary resources to execute planning decisions. Accordingly, PSI recommends that the program’s strategic planning process ultimately drive the ongoing prioritization of system initiatives and the investment of incentive earnings. This alignment can be established by: Š

Continuing to involve and seek consensus among primary stakeholders in the annual Nevada Child Support Enforcement Strategic Planning process. Membership should include/be limited to those select stakeholders central to planning’s success. In this manner, key decision makers are drawn out of their hierarchical organizations and better positioned to focus on the programs overall best interests. Strategic planning provides a formal avenue for the program to collectively define where it wants to be and to identify the action-oriented strategies to get there.

Š

Including the IV-D System Owner on Strategic Planning and Incentive Allocation committees. The System Owner should be recognized as the champion of statewide system issues and concerns.

Š

Including within the scope of strategic planning potential technical solutions/system initiatives to help achieve program objectives. Engage and collaborate with state and local IT resources during the planning process as appropriate to explore, consider the feasibility of, and estimate the level of effort associated with alternative system solutions. This collaboration will help establish a two-way, symbiotic connection between program strategy and IT.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 100

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Charging the Incentive Committee with allocating state and local incentive shares to support those system initiatives outlined in the statewide Strategic Plan

Š

Updating IV-D system priorities consistent with the statewide Strategic Plan

Improve the Quantity and Quality of Automation Support and New System Functionality While NOMADS is a federally certified Child Support enforcement system, all parties acknowledge it needs substantial enhancement in order to better meet the IV-D program’s needs.17 Yet DWSS’ ability to enhance the system and deliver enhanced and updated functionality to IV-D Program users is noticeably impaired. It is important that these capabilities be improved: Š

Improve the quantity of new or improved system functionality delivered. The backlog of IV-D enhancement requests is large, but the amount of that backlog that is actually delivered is comparatively small. In the past this has been attributed to both scarce-resources and competing priorities. While both of these issues will remain going forward, this recommendation acknowledges that more functionality and more value must be delivered to the IV-D program than the current process produces. In order to deliver more system functionality PSI recommends that: ƒ

Š

Reengineer the SDLC process. Making the current SDLC process more efficient and transparent are the most obvious ways to realize more productivity and promote an accurate perception of work done by Information Systems. Information Systems is already making some changes in this realm. It is beginning to use new tools and has established a PMO position. The following recommendations relate to reengineering the SDLC processes and leveraging the improvements already being made (see Appendix F for a more detailed discussion of these recommendations).

Become more project (rather than process) oriented. Rather than simply routing each “work item” through a series of process-centric queues, consider taking a more project and team oriented approach. Assign teams to one or more related projects and begin developing team synergy. Each team should consist of a product owner, a technical lead (senior developer) and a business analyst that are assigned to the project for its life. Additional resources should then be assigned as required.

17 PSI is talking specifically about the IV-D program in this discussion—the IV-A program is out of scope. From this document’s perspective, the two programs’ fates are tied from a risk management perspective (at least as long as the NOMADS system supports them both), but each can (and should) chart its own course when it comes to its future.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 101

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

Š

The product owner should come from the Child Support program and will champion the project from start to finish. The product owner may be supported by a project manager on large projects and may fulfill the project management responsibilities on smaller projects. The Information Systems PMO position should serve as a project resource and should provide project oversight at the portfolio level. The new PMO position should help develop project-focused policies and procedures.

Project-focused tools. The current Work Item Tracking System (WITS) is structured around a process-centric methodology. The SDLC phase within the system is the driver for work distribution. Work is routed to different groups of resources based on SDLC phase. Adopting a tool that is project focused will make it easier to support a project mentality and maintain continuity of resources throughout the project life. ƒ

As DWSS reengineers its SDLC processes it should consider the capabilities of the tools available to it such as MS Project Server and SharePoint. DWSS should charge the new PMO with determining how to best utilize these powerful tools and addressing departmental training needs regarding the use of these tools and the new SDLC processes.

Š

Assign IV-D knowledgeable resource up front (feasibility assessment, ROM estimation, recommendations, risk assessment).Reengineered SDLC processes should engage program-knowledgeable technical resources at an early step to determine feasibility of work items before significant effort is expended. A ROM level of effort estimate should be prepared and considered prior to final approval of a work item. The program-knowledgeable resource should offer up solution alternatives if less expensive, more efficient or more effective options exist. Risks should also be identified up front and a standard approach for risk assessment should be followed.

Š

Empower the project team. It is important that the project team be empowered to make decisions quickly and to inform stakeholders of these decisions using project communication tools.

Š

Redesign executive summary forms. The executive summary document should be replaced with a form tailored to the reengineered SDLC processes. The form should be designed with progressive elaboration in mind. Team collaboration features of MS Project Server should be used to organize forms, design documents and any other supporting documentation. PSI has provided an Excel based mini business case tool to assist this effort.

Š

Account for all work to be performed through explicit processes, criteria and control. Reengineered SDLC processes should explicitly account for and control all work performed within the Application Development Group. This work will potentially include both maintenance and modernization work. It includes items currently classified as work items, break fixes, projects and ad hoc requests. The same level of visibility and conscious prioritization should apply equally to all types of work.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 102

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

Š

Business analyst positions / roles be established. A shortcoming of the current SDLC processes as cited by multiple staff during interviews is the fact the programknowledgeable business analysts are not embedded into the process. The following recommendations address that shortcoming.

Transition requirements (BPA) positions to Business Analysts (BA) positions. Although the positions with the requirements group are already classified as business process analysts they are currently not used in that capacity. There seems to be a general consensus that significant value could be derived from integrating program-knowledgeable business analysts into project teams. ƒ

Pair BAs with program staff volunteers on projects. Because the individuals currently occupying the BPA positions within the requirements group do not have deep program knowledge, it is important to fill that void and, at the same time, begin developing their program knowledge. One option is to pair them with program SMEs from the field until they can gradually gain the required knowledge.

ƒ

Fill vacant positions. One obvious impediment to increasing the quantity of automation support within the agency is the high number of vacant positions. Currently, Information Systems has an 18% position vacancy rate. The inability to attract applicants and to fill and retain positions appears to be a significant problem especially in light of the current economic conditions where there is considerable competition for available jobs. Vacancies may indirectly impact the quantity of automation support provided to IV-D even if they are not within the IV-D Development branch of the organization.

ƒ

A number of factors may be contributing to these high vacancy rates. Currently, there is a Governor’s mandate that all positions must be filled at an entry level salary for the position. It is difficult, if not impossible, to find applicants with CSP skills. The learning curve is steep and long and new employees put a drain on existing staff while they slowly come up to speed. Furloughs and potential pay cuts are also factors that may contribute to vacancies. There is pressure to eliminate positions that remain vacant for an extended period of time.

ƒ

Unfortunately, there are no obvious and easy solutions to these challenges. DWSS might seek an exception to the Governor’s hiring mandate for these critical IS positions. Another possible solution is to seek approval to hire temporary contract staff for hard to fill positions. This is not an ideal solution due to the steep learning curve related to the Child Support program and its legacy application. It may be possible, however, to bring in technology specialists that can provide value to the agency as it embarks upon modernization efforts. Technology experts might be able to provide mentoring to existing staff and take on tasks that don’t require extensive program knowledge. Developing services with clearly defined inputs and outputs is one example of the type of work that can be performed without deep program knowledge. It may also be possible to bring in some contractors with the sole purpose to work on documentation.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 103

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

Š

Another consideration is to move more quickly to a technology platform where more abundant resources are available at entry level salaries. Leveraging EGL’s capability to generate Java code, for example, might allow DWSS to tap a larger labor market while at the same time promoting development work that is consistent with the TCSA - work that can be preserved as part of a modernized application.

Make the rate of delivery more consistent. It is important to level out the rate of delivery, which in the past has been very episodic. More frequent delivery of smaller increments of functionality would go a long way towards improving the perception that the Program has that “nothing ever gets done.” ƒ

Dedicate more resources exclusively to IV-D. It is nearly impossible to maintain a consistent rate of delivery without a dedicated team of resources. The following suggestions are aimed at establishing a better balance of dedicated and shared resources.

Š

Identify resources with deep IV-D knowledge and dedicate them exclusively to IV-D work

Š

Identify resources with deep technology expertise and make them available as shared resources across programs

Š

Assign resources to project teams based on program and technology needs: ƒ

Š

Maintain a mix of quick wins and longer term projects. Delivering a mix of large and interspersed small projects makes the rate of delivery more consistent from a deployment perspective.

Maintain a mix of large and small projects using up-front assessment of the level of effort required and benefit derived. As part of reengineered SDLC processes, invest a small amount of time up front assessing rough order or magnitude effort and qualitatively scoring perceived benefit. Use these metrics to make sure that current mix of work includes enough small but beneficial items to ensure that improvements are consistently being rolled out. ƒ

Support more accurate perceptions of delivery rate. Sometimes the perception of the delivery rate may differ from the actual delivery rate. During large projects, for example, extended periods of time may pass without deployment of new code. This doesn’t mean that progress is not being made. Promoting accurate perceptions is an important prerequisite for evaluating consistent delivery.

Š

Improve SDLC. Make sure the reengineered SDLC processes accurately capture all effort expended by program and project.

Š

Improve visibility. Leverage improved processes, capture of additional metrics and reporting and collaboration capabilities of tools to share effort expended, progress made, current schedules and results achieved at the state and county levels.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 104

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

Overcome inconsistency of combined IV-A/IV-D slot process. It is difficult to maintain a consistent rate of delivery without a consistent pipeline of approved IV-D work items.

Š

Eliminate 18 slot program. The 18 development slots currently shared by IV-D and IV-A represent an artificial constraint that may get in the way of delivering consistent results to the IV-D program. Replacing the current slot-based approach with an approach that maintains separate IV-D and IV-A priorities combined with more dedicated IV-D resources will help to improve delivery consistency.

Š

Increase the predictability of the delivery. As much as improving the rate, it is important to give the IV-D program a better capability to anticipate how much functionality will be delivered to them over time so that they may plan their own activities better. ƒ

Š

Use progressive elaboration. Progressive elaboration for estimating means to continually refine estimates as the project progresses and more detail is known. An initial ROM estimate (typically -50/+100%) should be made early on and used for cost benefit comparisons. It should also be considered as part of the feasibility decision. Revised estimates should be made at each successive phase of the project. Refined estimates should be made after requirements and after design. Estimates falling significantly outside of specific bounds should trigger a re-evaluation of the project. ƒ

Š

Improve estimates. Accurately estimating the level of effort for work items is a cited weakness in the current SDLC processes. Without accurate estimates it’s impossible to predict delivery schedules and it is difficult to conduct departmental planning. It is essential to estimate the overall level of effort as well as the level of effort for each phase of the project.

Each estimate should be recorded and saved for later comparison against actual results. Records should accountability for the individual making each estimate.

Use estimating techniques. There are numerous techniques for estimating level of effort. It may be desirable to use different techniques at different phases of the project. Examples of techniques are included in the table below. Expert Judgment and Analogous estimating are the most accessible, and PSI recommends DWSS focus on these techniques in the near term. While experimenting with a mix of methods is reasonable, it is recommended that DWSS employ consistent estimation methods within any project's development lifecycle (e.g., if the first estimate is developed using Expert Judgment, the more-refined estimates should be developed in the same manner.) Table 13: Techniques for Estimating Level of Effort Technique Expert Judgment

Description A person with relevant experience develops the estimate based on judgment and personal experience.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 105

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Technique

Description

Analogous Estimating

Estimate based on experience for similar projects +/- deltas.

Parametric 18 Modeling

Capture a set of independent parameters for a project and estimate using a regression model.

Three-Point Estimating

Develop an optimistic, most likely and pessimistic estimate and apply PERT formula, (P+4M+O)/6.

Š

Capture effort expended. Regardless of the technique selected, it is imperative to perform comprehensive time reporting for project tasks by phase, resource and role. Without a complete and accurate assessment of actual effort expended it is impossible to measure the accuracy of estimates.

Š

Continuously improve estimates. By using the same technique, capturing actual results and reporting accuracy, it is likely that estimate accuracy will continue to improve over time. By establishing and capturing a list of independent parameters for each project, it will become possible to employ a parametric estimation tool once a baseline of results has been established, even if another estimating technique is used initially.

Š

Employ portfolio planning. Predictability for individual projects is largely dependent on factors and interdependencies among the entire portfolio of projects. Leveraging the project management office (PMO) to provide a portfolio perspective and enhance predictability is a logical extension.

Š

Employ portfolio management. As IS builds its project management office (PMO), it should create processes to incorporate individual project estimates into broader, portfoliolevel planning and reporting activities.

Š

Increase the visibility of the delivery pipeline. Stakeholder involvement in strategic decision-making and delivery planning will foster understanding and support for program plans. Making project status information readily available will positively influence stakeholder perception of the delivery of automation support. The visibility of the delivery pipeline can be increased by building on current practices:

18 Microsoft

Excel provides a very powerful add-in that can be used for regression modeling. It provides a no cost option to perform very sophisticated estimation. It can be simple to apply but requires an established baseline of known results, i.e., parameter values and actual results achieved.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 106

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

Continue to invite/involve primary stakeholders in strategic planning and other related decision-making sessions (Strategic Planning, Incentives Committee) that will feed the system project pipeline.

ƒ

Continue to publish/post/disseminate the annual Strategic Plan, highlighting newly adopted or refreshed system strategies (action items/tactics) and for each strategic plan objective, differentiating among associated strategies by type (policy, training, technology etc).

ƒ

Publish/post/disseminate the annual Incentive Allocation Plan that will now be aligned with and actively support the Nevada Child Support Enforcement Strategic Plan

ƒ

Post/publish the screening algorithm priority list for enhancement requests (with scores). Make sure this published list is maintained as new projects come on/are completed.

ƒ

For each active IV-D system project, create a dashboard that is: - Accessible to all primary stakeholders - Readily maintained - Populated with up to date summary information about the project’s schedule, current status, ongoing resource allocation, etc.

ƒ Š

Establish other vehicles to ensure system project status information is communicated in an appropriate form to all levels of program personnel.

Utilize, preserve and develop program knowledge. Given the reliance by the IV-D and IV-A programs on their supporting systems, the steep learning curve for those systems and the extensive impact of errors, it is critical to minimize risk to those programs by utilizing, preserving and developing competent technical resources. The following recommendations help to ensure that program knowledge is treated as a valuable and limited resource and allocated appropriately: ƒ

Maintain skills profiles to include program skills areas. Make sure worker skills profiles are current and reflect program expertise as well as specialty areas within the program such as financial processing, federal reporting, etc.

ƒ

Identify projects requiring deep program skills. As part of the SDLC process, include up front identification of skill requirements to reflect specific program expertise required for projects. Identify projects that represent good mentoring opportunities or opportunities to acquire/enhance specific program skills as part of lower risk tasks.

ƒ

Assign workers with deep program skills exclusively to:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 107

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

- Tasks requiring deep program skills - Perform initial project candidate review ROM estimate, recommendations, feasibility, risk) - Mentor workers with less program knowledge ƒ

Š

Carefully assign work to best leverage workers with deep program knowledge. Utilize their knowledge and skills to make better estimates of effort, determine feasibility of tasks up front, make recommendations to improve requirements and reduce effort and recognize and mitigate risk; recognize contributions made toward improved effectiveness and efficiency as well as contributions made toward program knowledge development in other staff as part of performance reviews

Develop system documentation. The applications that support the IV-D program are extremely complex and impact thousands of families on a daily basis. Without adequate documentation, loss of a single knowledgeable developer can be debilitating. It is essential, therefore, to maintain at least a minimum level of system documentation. The following recommendations are made to ensure that a pragmatic level of system documentation is maintained. ƒ

Establish a documentation plan for legacy code. DWSS acknowledges that documentation is lacking for the NOMADS application. As part of a governance reengineering effort it is important to establish a pragmatic documentation plan that identifies necessary documentation. The plan should address how documentation efforts are prioritized and managed along with work items, break fixes and ad hoc reports. Documentation efforts should consider the life expectancy for various programs and effort should not be wasted developing extensive documentation for programs that are not used or are likely to become obsolete in the near term.

ƒ

Leverage CSP to EGL conversion. If the CSP to EGL conversion effort requires any manual analysis or results in any by-products that might be considered valuable for documentation purposes, those efforts should be coordinated with the plan for legacy system documentation.

ƒ

Utilize code freeze period to work on documentation. Take advantage of any code freeze period required by the CSP to EGL conversion to assign resources to a concerted documentation effort.

Leverage and Optimize All Available Resources DWSS has an acute resource shortage, and current economic conditions in the State of Nevada exacerbate this shortage. This environment makes it all the more urgent to use current resources to maximum effect, and to avoid wasting any of the effort these resources might otherwise expend on non-productive activities. Over and above the effective use of resources that are directly available to DWSS, there is also a broader set of resources that may be available to be leveraged further. In particular, county-level resources have a great

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 108

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

deal to offer the program. Given the scarcity of internal resources, it will be important to take full advantage of local resources that have been identified or volunteered. County personnel have a vested interest in IV-D automation. County managers, supervisors and caseworkers can of course serve as SMEs. County IT staff can add expertise and perspective not necessarily represented by Information Services staff. It is a reasonable expectation that they be enlisted as resources to help further automation. PSI’s recommendations in this regard include: Š

Maintaining a list of county resources willing and able to participate on project teams. In addition to financial resources, utilization of personnel resources from the counties can expand the delivery capacity of Information Systems while, at the same time, improving visibility. Accumulating a list of volunteers and identifying their availability and expertise is a first step.

Š

Assigning county resources as required and available. As part of the project initiation, available county personnel should be considered for filling project roles where appropriate.

To the credit of state and local program leaders, a large proportion of the incentive dollars reserved for both state and local initiatives have in fact been applied to initiatives that promise program-wide benefits. Cooperative use of state and local incentives should continue to be the rule rather than the exception. Specific provisions that reinforce this practice were presented above under the recommendation to “Align Nevada Child Support strategic planning ….” Nevada must leverage all available resources including retained collections, incentives, program income and state appropriations. Specific funding strategies will be discussed in more detail in the initial funding plan for system modernization (see System Modernization Roadmap, Modernization Funding Plan subsection).

Summary Implementation of the IV-D system Maintenance Plan will address viability issues and serve to stabilize the system. As a result, Nevada will be able to effectively shift the center of its attention from risk avoidance to innovation. These IV-D System governance recommendations provide the delivery-oriented structure, decision-making process and accountability necessary to modernize the IV-D system. This approach to governance will provide the level of support necessary for the program to implement its plans and achieve its objectives.

Analysis Results: Assessment of Existing Resources  In order to develop a Maintenance Plan that can be executed with existing program resources and to develop a funding plan for the Modernization Roadmap, PSI first needed to understand the basis for and expenditure of existing resources. This section provides an overview of this assessment of existing resources. For a more detailed perspective please review Appendix G.

Methodology PSI’s assessment focused on actual resource levels and expenditures for state fiscal years 2008, 2009, and 2010 as well as expected resources and planned expenditures for state fiscal years 2011, 2012, and 2013. PSI relied on general ledger reports from the state’s financial accounting system, 396A reports to the federal government, the State’s budgets for the CSEP, planned program-wide initiatives and CSEP records and work papers.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 109

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

PSI exercised reasonable assumptions in the course of conducting this assessment, including: Š

Nevada would earn at least the same amount of incentives in 2010 and 2011 as it did in 2009.

Š

State cost allocations for all of state fiscal year 2011 were extrapolated from year to date cost allocations.

Š

County expenditures for all of state fiscal year 2011 were extrapolated from year to date expenses.

Š

Estimated County expenditures for 2012 and 2013 were set to be consistent with 2011 expenditure levels.

PSI classified actual resources for 2008 – 10 and expected resources for 2011 – 2013 by entity including CSEP, DWSS administration, other state agencies (e.g., Attorney General) and counties. Within each entity, resources are categorized by source including state share of retained collections, program income (e.g., fees), state general fund, county general fund and federal financial participation at the 66% matching rate. Incentive resources for these years were treated separately and subdivided into incentives that have been invested in (2008 – 10) or are reserved (2011 – 13) for either program-wide initiatives or local initiatives. PSI examined resource and expenditure data year by year to identify any trends in the growth or reduction of resource levels. PSI worked at length with DWSS administration and CSEP to accurately document these program resources and expenditures. DWSS administration staff assisted PSI in understanding and correctly interpreting the resource and expenditure data. PSI verified its documentation of resources and expenditure with DWSS and CSEP.

Summary of Expenditures The following table summarizes actual expenditures for state fiscal years 2008 through 2010 and planned expenditures for state fiscal years 2011 through 2013. Note that state and county expenditures include the 66% federal match.

Expenditures

Table 14: Summary of Actual Expenditures for State Fiscal Years 2008 through 2010 and Planned Expenditures for State Fiscal Years 2011 through 2013 Category State Expenditures (total dollars) Incentives Expended County Expenditures (total dollars) Annual Total Program Expenditures

SFY 2008

SFY 2009

SFY 2010

SFY 2011

SFY 2012

SFY 2013

$16,836,424 $351,357

$17,346,701 $557,148

$15,821,820 $6,727,251

$16,861,727 $6,921,906

$16,624,321 $6,839,888

$16,927,153 $2,706,815

$33,224,064

$32,533,258

$34,341,218

$34,586,458

$34,586,458

$34,586,458

$50,411,846

$50,437,107

$56,890,290

$58,370,091

$58,050,667

$54,220,426

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 110

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Analysis of Summary Expenditure Trends State Expenditures: Total actual state expenditures varied between 2008 and 2010. These fluctuations were largely attributable to fluctuations in personnel costs as positions are filled or held vacant or personnel were placed on furlough. The planned expenditure levels remain relatively stable for 2011 - 2013. State and County Incentives Expended: In 2008 and 2009, the program saved the bulk of its incentives and wisely optimized them in federal fiscal year 2010 when incentive dollars were temporarily eligible for federal financial participation at the 66% matching rate. Given that federal fiscal year 2010 overlaps state fiscal year 2011 by three months, some of the enhanced funding for the incentives appears in state fiscal year 2010 and the balance of the enhanced funding appears in state fiscal year 2011. Expected incentive expenditures in 2012 remain high as significant, unspent incentives are carried over. However, for 2012, PSI staff assumed that any unspent incentives carried forward and available from 2011 as well as incentives received from the federal government in 2012 would be spent in 2012. For 2013, PSI staff assumed that any incentives received from the federal government in 2013 would be spent in 2013. The expected incentive expenditure level in 2013 is reduced because the previous, temporary federal matching of incentives no longer applies and there is no carry-over of unspent incentives from 2012, as in previous years. County expenditures: A dip in county expenditures in 2009 is an artifact of timing in which counties’ invoices for the end of 2009 were counted in 2010 on the expenditure report to the federal government. From the perspective of when the counties incurred the expenses, as opposed to when they invoiced them, counties’ expenditures remain fairly stable from year to year. Total program expenditures: In 2010 total program expenditures increased to nearly $56,900,000 primarily from the strategic increase in incentive expenditures during the temporary period of federal matching dollars. Total program expenditures are expected to remain elevated in 2011 and 2012, again primarily from the increase in incentives expenditures. In 2013 the total program expenditures are expected to decline to just over $54,200,000 as incentive expenditures are expected to decrease, as explained above.

Allocation Compared to Actual Investment of Incentives The CSEP and the counties participating in the IV-D program have agreed to divide incentives with 25% of the earned incentives being reserved for initiatives that benefit the program as a whole and 75% distributed to the counties and the local state PAO sites for local initiatives. Counties may elect, however, to contribute any or all of the incentives set aside for local initiatives to statewide initiatives that benefit the Child Support program as a whole. CSEP and the counties participating in the IV-D program have established a process to prioritize program-wide initiatives and fund them with available incentives. From 2008 through March 31, 2011, the CSEP and participating counties had spent $14,557,662 of incentives (including temporary federal financial participation explained above). Of this amount, $10,436,660 (72%) was actually spent on program-wide initiatives. In certain instances the counties took on the role of sponsoring, managing the contracts for, and serving as pilot sites for these program wide initiatives. The CSEP and participating counties have allocated incentive funding after March 31, 2011 to complete current statewide initiatives.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 111

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Summary of Resources The following table shows a summary of actual and expected resource levels for 2008 through 2013.

State Recovery & AG Assessment

DWSS Resources

CSEP Resources

County Resources

Incentive Resources

Table 15: Summary of Actual Program Resources for State Fiscal Years 2008 through 2010 and Expected Resources for State Fiscal Years 2011 through 2013 Category Incentives for Programwide Initiatives (total dollars) Incentives for Local Initiatives (total dollars) Subtotal County General Fund Resources Federal 66% Match for County General Fund Resources Subtotal State Share of Retained Collections Federal 66% Match Available for State Share of Retained Collections State Share of Program Income Available to Expend on the Program Federal 66% Match Available for State Share of Program Income Subtotal General Fund State Share Expended on Cost Allocation Federal 66% Match for General Fund State Share Expended on Cost Allocation Subtotal State Share of Expenditure Federal 66% Match for State Share of Expenditure Subtotal TOTAL RESOURCES

SFY 2008

SFY 2009

SFY 2010

SFY 2011

SFY 2012

SFY 2013

$4,727,251

$5,709,409

$1,899,161

$676,704

$351,357 $351,357

$557,148 $557,148

$2,000,000 $6,727,251

$1,212,497 $6,921,906

$4,940,727 $6,839,888

$2,030,111 $2,706,815

$11,296,182

$11,061,308

$11,676,014

$11,759,396

$11,759,396

$11,759,396

$21,927,883 $33,224,064

$21,471,950 $32,533,258

$22,665,204 $34,341,218

$22,827,062 $34,586,458

$22,827,062 $34,586,458

$22,827,062 $34,586,458

$3,935,422

$4,740,368

$4,228,838

$4,357,426

$4,104,231

$4,070,121

$7,639,348

$9,201,891

$8,208,920

$8,458,533

$7,967,037

$7,900,823

$346,010

$420,303

$410,896

$473,485

$414,661

$414,661

$671,666 $12,592,445

$815,882 $15,178,443

$797,622 $13,646,275

$919,119 $14,208,563

$804,929 $13,290,858

$804,929 $13,190,534

$2,503,001

$2,269,124

$1,807,362

$1,588,481

$1,734,306

$1,746,660

$4,858,766 $7,361,766

$4,404,769 $6,673,893

$3,508,409 $5,315,771

$3,083,522 $4,672,003

$3,366,595 $5,100,901

$3,390,575 $5,137,234

$328,900

$243,860

$227,716

$248,103

$433,771

$435,286

$638,453 $967,353 $54,496,986

$473,375 $717,234 $55,659,976

$442,037 $669,754 $60,700,270

$481,611 $729,714 $61,118,644

$842,026 $1,275,798 $61,093,902

$844,966 $1,280,252 $56,901,293

Analysis of Summary Resource Trends Incentive Resources: The amount of incentives contributed to program-wide initiatives and the amount of incentives used for local initiatives from 2008 through March 31, 2011 was determined by CSEP records. The amount of incentives contributed to program-wide and local initiatives after March 31, 2011 is portioned by the 25%/75% allocation agreement applied to expected incentive earnings. PSI set incentive resources to NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 112

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

equal actual and planned incentive expenditure levels for each year respectively. Consequently, the trends are the same as the trends discussed for incentive expenditures. County Resources: For the purposes of this assessment, county resources (excluding incentives) in a year have been set to equal the expenditures. CSEP Resources: These amounts reflect the available resource levels of actual and budgeted state shares of retained collections and program income (e.g., fees). Between 2008 and 2011 these funds fluctuated significantly. Total retained collections and program income are budgeted to decline in 2012 and 2013. DWSS Resources: For 2008 through 2010, DWSS resources were set to equal their respective cost allocation expenditures. For 2011 through 2013, DWSS resources reflect the budgeted amounts that will be cost allocated to CSEP. The level of actual DWSS resources declined from a high of $7,361,766 in 2008 to $5,315,771 in 2010. DWSS resources for 2012 and 2013 are budgeted to be around $5,100,000. State Recovery and AG Assessment Resources: For 2008 through 2010 State Recovery and Attorney General Assessment resources were set to equal their respective cost allocation expenditures. Resources that support the State Recovery and Attorney General Assessment, both directly to CSEP and indirectly through DWSS, have ranged from a low of $669,754 in 2010 to a high of $1,280,252 in 2013.

Incentive Allocation and Future Investment This subsection provides a look at future incentive resources. CSEP’s current practice is to recognize the revenue from incentives two years after the year in which it earned the incentives. While this conservative practice is not common, it is understandable in the wake of past data reliability issues experienced and penalties incurred by Nevada several years ago. For illustration, CSEP does not consider the incentives Nevada earned in 2009 to be “received” until the books are closed on those earnings in 2011 – eliminating the risk of otherwise budgeting on the basis of incentive earnings estimates. The following table shows the sources of incentives after March 31, 2011 to complete those approved program-wide initiatives already underway. Available incentives for these initiatives come from the balance of unused incentives earned in 2007 (or before), 2008, and 2009. Table 16: Detailed Sources of Incentives for Continuing Statewide Initiatives after March 31, 2011

Contributions to Programwide Initiatives after 4/1/2011 25% Put towards Programwide Initiatives (from 2007 and earlier) County Contributions to Programwide Initiatives Subtotal of Available Incentives for Programwide Initiatives Incentives Available for Local Initiatives Total

Available Available Incentives Incentives (Total Available Available (Total Dollars) from All Dollars) from Incentives (Total Incentives (Total Years 2007 Dollars) from 2008 Dollars) from 2009 $1,222,457

$39,239

$506,514

$676,704

$164,000

$153,133

$10,867

$0

$1,386,457 $2,746,616 $4,133,073

$192,372 $82,752 $275,125

$517,381 $798,997 $1,316,378

$676,704 $1,864,867 $2,541,570

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 113

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The data in Table 16 show that the balance of “25% incentives” will cover most of the estimated costs of $1,356,000 for the program-wide initiatives scheduled to continue/be completed beyond March 31, 2011. Also, Elko County has contributed $164,000 of local incentives for the business intelligence program-wide initiative. The following table shows the incentives that will be “received” in 2012 and 2013 and be available for program-wide and local initiatives. Table 17: Detailed Sources of Incentives that Will Be Received in 2012 and 2013

Contributions to Program-wide Initiatives after 4/1/2011

Available Incentives (Total Dollars) from 2012 (Estimated)

Available Incentives (Total Dollars) from 2013 (Estimated)

Available Incentives (Total Dollars) from Both Years

25% Put towards Programwide Initiatives (from 2007 and earlier)

$676,704

$676,704

$1,353,407

County Contributions to Program-wide Initiatives

$0

$0

$0

Subtotal of Available Incentives for Program-wide Initiatives

$676,704

$676,704

$1,353,407

Incentives Available for Local Initiatives

$2,030,111

$2,030,111

$4,060,222

Total

$2,706,815

$2,706,815

$5,413,630

The total amount of incentives available for program-wide initiatives by the end of 2013 would be $1,353,407. As of yet these “25% incentives” have not been designated for specific future program-wide initiatives and likewise, as of yet, no counties have contributed any portion of their 75% local share of incentives towards new (TBD) program-wide initiatives. As mentioned previously, however, as CSEP and the participating counties prioritize program-wide initiatives, many counties historically have agreed to reallocate a significant portion of those incentives set aside for local initiatives, to program-wide initiatives.

Summary of “Unmatched (FFP)” Commitments At the end of each state fiscal year total program resources in excess of budgeted expenditures can either be carried over or committed to other non-program purposes. PSI’s assessment collectively identifies these resources as “unmatched (FFP)” as their disposition is not eligible to draw down the regular 66% federal financial participation. (Note that if these excess, unmatched (FFP), state resources were to eventually be expended on the program or program initiatives, the 66% federal match would apply.) The following table shows the year by year summary of actual (SFY 2008-10) and expected (SFY 2011-13) state share of resources greater than expenditures.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 114

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Table 18: Summary of State Share of Resources Greater than Expenditures for SFY 2008 through 2010 (Actual) and SFY 2011 through 2013 (Expected) Category

SFY 2008

SFY 2009

SFY 2010

SFY 2011

SFY 2012

SFY 2013

Annual Total Program Resources

$54,496,986

$55,659,976

$60,700,270

$61,118,644

$61,093,902

$56,901,293

Annual Total Program Expenditures

$50,411,846

$50,437,107

$56,890,290

$58,370,091

$58,050,667

$54,220,426

Resources Greater than Expenditures (total dollars)

$4,085,140

$5,222,869

$3,809,980

$2,748,553

$3,043,235

$2,680,867

Resources Greater than Expenditures (State share only)

$1,388,948

$1,775,776

$1,295,393

$934,508

$1,034,700

$911,495

In the four rows of the table, PSI calculated the amount of the state share of resources greater than expenditures by subtracting total program expenditures from total program resources in a fiscal year and then multiplying the difference by 34% (eliminating the portion representing the IV-D federal financial participation at a rate of 66%). This difference represents the state share of retained collection resources CSEP generated during the year in excess of CSEP’s budget. In each year of analysis, the resources exceeded the budget. The resources that CSEP does not use in a fiscal year may be carried forward or applied to certain unmatched (FFP) commitments. Examples of these unmatched (FFP) commitments include transfers to the DWSS account to offset certain CSEP costs, coverage of state costs for federal grant projects, and reversions to the State’s general fund, among others. A detailed analysis of these unmatched (FFP) commitments is provided in Appendix G.

Conclusions Foremost among the challenges of this Assessment Project is the identification of existing resources to fund the IV-D Child Support System Maintenance Plan and to help fund the Modernization Plan. PSI’s analysis of existing resources led to the following conclusions that will inform both the Funding and Governance plans for IV-D System Maintenance and Modernization: Not all existing program fiscal resources available in a fiscal year are used in that fiscal year: Š

Incentives: ƒ

Federal incentives earned by the Nevada Child Support program are not estimated and utilized in the year earned.

ƒ

An uncommitted portion of the federal incentives earned by the Nevada Child Support program has accumulated over the past few years.

ƒ

Nevada’s competitive share of the national pool of incentives is based on comparative performance. Nevada’s comparatively poor performance and contingent share of incentives will decline further if the functional and technical limitations of

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 115

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

the system are not addressed. Conversely, addressing these system limitations will significantly improve performance and stem the erosion of, if not increase, Nevada’s share of incentives. Š

State share of retained collections: ƒ

At the end of each fiscal year a portion of the state share of retained collections is carried forward to the following fiscal year.

ƒ

At the end of each fiscal year a portion of the state share of retained collections is reverted to the State’s General Fund.

ƒ

Retained collections that are not spent on the program (e.g., reverted or spent on other programs) could have leveraged 66% federal matching funds (FFP) if otherwise invested in Child Support program initiatives.

DWSS/CSEP and the county partners have demonstrated the ability to collaborate in identifying statewide priorities and the willingness to contribute their respective resources towards these greater ends. Examples of statewide initiatives on which DWSS/CSEP and the county partners have collaborated include, among others: Š

Document Imaging

Š

Employer Web Services

Š

Business Intelligence Reports

CSEP pays for, yet has limited oversight of, a range of personnel services outside of its span of organizational control including: Š

DWSS Administrative Services and Information Systems positions directly within the CSEP budget or cost allocated to CSEP

Š

Field operations positions located outside of the Child Support offices

Š

Department of Employment, Training, and Rehabilitation (DETR) personnel processing new hire reports and income withholding notices for unemployment benefits

Š

Personnel with the Clark County pilot project intended to expand the county’s capacity to hear Child Support cases

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 116

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

V. PLANNING RESULTS The planning phase of the project provides recommendations for funding, maintenance of the existing system, incrementally modernizing the system and how to balance expenditures between maintenance and modernization. The planning results are presented in this section of the document and include a plan for maximizing the existing funding available, a system Maintenance Plan, a Modernization Roadmap and a plan for expending resources to support both system maintenance and modernization in an incremental fashion. The incremental nature of the Modernization Roadmap provides flexibility to adjust if actual funding deviates from the funding plan. The planning results section of the document concludes with the identification and discussion of issues that are central to the overall success and direction of system maintenance and modernization.

Planning Results: Funding Plan 

Introduction The Nevada IV-D system funding plan is designed to: Š

Fully leverage funding sources that can be used for maintenance and modernization activities.

Š

Determine available amounts from these funding sources and when these amounts become available.

To achieve these objectives, PSI first analyzed the existing resources (catalogued in the Assessment of Existing Resources section above) to identify potential sources of funding that could be used to support maintenance and modernization activities. PSI then worked with DWSS to understand CSEP’s current funding streams, expenditures and budget process allowing PSI to develop a strategy to fully leverage these funding sources. Finally, PSI developed recommendations and assumptions specific to each funding source for supporting maintenance and modernization activities. This Funding Plan section includes: Š

A summary of the existing sources of funding for CSEP

Š

An overview of the plan’s general strategy to leverage funding sources for maintenance and modernization activities

Š

PSI’s assumptions and recommendations for leveraging existing funding sources

Š

A conclusion summarizing the amount of funding that is potentially available for maintenance and modernization activities through SFY 2023

For a more detailed understanding of the funding plan’s basis and accounting please see Appendix H.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 117

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Existing Funding Sources for CSEP Technology During the prior Analysis phase of this project, PSI staff examined the five primary sources of funding currently used to support CSEP. PSI’s analysis determined that the funds from three of these primary sources could be used for technology maintenance and modernization activities: Federal Incentives, State Share of Collections, and General Fund Support from DWSS. PSI did not deem fees or county general funds currently used to support Child Support operations to be available for maintenance and modernization activities.

Federal Incentives The federal government offers incentive payments to state Child Support programs based on a state’s ability to meet performance standards and collection levels. Federal regulations require that states reinvest these earned incentives in their Child Support programs – supplementing the state’s existing investment in the program. In recent years, Nevada has earned over $2.7MM annually in federal incentives. The CSEP and the counties participating in the IV-D program have agreed to divide incentives, reserving 25% of the earned incentives for initiatives that benefit the program as a whole and 75% for local initiatives. Counties may elect to contribute incentives set aside for local initiatives towards initiatives that benefit the Child Support program as a whole. In 2010 counties as a whole contributed significant amounts of their local incentives to program-wide technology initiatives. .

State Share of Collections Child support collections that states retain to reimburse the expenditure of public assistance are divided between the federal and state government. States may use the state’s share of collections in any manner, and typically states use it for their TANF programs. In Nevada, the state share of collections is used to fund the Child Support program. In recent years, the state’s share of collections, including FFP, has totaled more than $12MM per year. CSEP uses a portion of the state share of collections to fund staff positions for testing of computer programming, technology support and information services, and the help desk for IV-D NOMADS. PSI considered the funding for these positions to be available for maintenance and modernization activities. Additionally, portions of the state share of retained collections have been applied outside of the Child Support agency, reimbursing DWSS’s General Fund expenditure in support of CSEP and reverting to the state government19. PSI considered these portions to be available for maintenance and modernization activities after state fiscal year 2013.

General Fund Support from DWSS DWSS Administration uses a portion of its General Fund appropriation to pay for services in support of CSEP. Given that these General Fund expenditures support the IV-D program, they are eligible for IV-D FFP. The level of General Fund support ranged from a high of over $2.5MM in SFY 2008 (over $7.3MM

19

Portions put towards reimbursing DWSS and reverted to the State do not draw down FFP.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 118

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

including FFP) to a low of nearly $1.6MM in SFY 2011 (over $4.6MM including FFP). A portion of DWSS’s General Fund support funds technology services for CSEP, including central computing services, computer application development and implementation, and other information services. PSI considered only the funds for technology staff to be available for maintenance and modernization activities.

Funding Strategy During the prior Analysis phase of this project, PSI looked for opportunities to further leverage the primary funding sources to support maintenance and modernization activities. The result of this analysis was the basis for the funding strategy PSI developed for the IV-D NOMADS Maintenance Plan and Modernization Roadmap. The elements of this funding strategy are as follows: Š

Increase the amount of incentives expended on technology and use this funding to support maintenance and modernization activities.

Š

Increase the state share of collections expended on technology and use this funding to support maintenance and modernization activities.

Š

Continue to use a portion of DWSS’s General Fund support for CSEP for maintenance and modernization activities.

Recommendations for Leveraging Primary Funding Sources Federal Incentives Consistent with the funding strategy, PSI’s recommendations increase the amount of incentives available for funding maintenance and modernization activities. The Funding Plan leverages three types of incentives: Š

Final Incentives: The federal government finalizes states’ incentive payments 13 to 15 months after the end of the federal fiscal year in which they were earned. Nevada’s practice has been to “book” the incentives in the fiscal year in which Nevada receives the final incentive award notification.

Š

Banked Incentives: The balance of unobligated final incentives from previous years

Š

Estimated Incentives: The federal government allows states to request an estimated amount of incentives that a state anticipates it will earn in a given year. In a sense, states may request an advance on their final incentives. Although Nevada has received estimated incentives previously, Nevada’s recent practice has been to decline estimated incentives and wait until incentives are finalized. This more recent practice was adopted after Nevada failed data reliability audits for paternity data in 2000, 2002, 2003, and 2004, resulting in the repayment of estimated incentives to the federal government.

Recommendations

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 119

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

CSEP should use 75% of incentives available to spend within a given year (whether final, banked, or estimated incentives) for program-wide initiatives focused on maintaining or enhancing IV-D NOMADS.

Š

CSEP should expend 75% of banked incentives on system maintenance and modernization activities. The funding plan assumes that banked incentives will be expended in their entirety before expending final and estimated incentives.

Š

CSEP should expend 75% of available final incentives on maintenance and modernization activities through the end of the 2014-2015 biennium. The available final incentives for federal fiscal years 2013 through 2015 are forecasted amounts based on the assumption CSEP at least maintains its current performance levels and does not have any issues with the reliability of its performance measurement data.

Š

CSEP should begin requesting an advance on estimated incentives in the year for which it earns the incentives and expend 75% of available estimated incentives on maintenance and modernization activities. The funding plan assumes that Nevada will have a two year period in the 2014-15 biennium where forecasted final incentives overlap with the advanced estimated incentives.

Š

CSEP should hold back 25% of the total final and estimated incentives in a year as a contingency to mitigate the risk of data reliability or performance issues20. The balance of final and estimated incentives would be available for use in that year (75% of that balance would be directed to maintenance and modernization). The funding plan assumes that any portion of the hold back not needed for mitigating data reliability and performance issues will be expended in the following year.

Š

CSEP should direct 75% of additional incentives accruing from performance improvements in future years to maintenance and modernization activities. The available additional incentives in a given future state fiscal year is a forecasted amount based on the assumption CSEP’s performance will improve in the future as the maintenance and modernization enhancements are implemented.

20 The paternity indicator is Nevada’s greatest risk for failing data reliability. PSI selected a hold back rate of 25%, which is the percentage share of incentives Nevada earns with its paternity performance, to mitigate the fiscal risks if Nevada were to fail data reliability for paternity data in the future.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 120

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

State Share of Collections Consistent with the funding strategy, PSI’s recommendations increase the amount of state share of collections available for funding maintenance and modernization activities.

Recommendations Š

CSEP should continue providing the current level of technology services resources, directing the bulk of them to maintenance and modernization activities. The funding plan assumes that the annual average of the 2012 and 2013 biennium’s budget for technology services in budget account 3238 would continue as the annual baseline for subsequent years.

Š

The state share of collections used to reimburse DWSS’s General Fund expenditures should be redirected to support maintenance and modernization activities, drawing down FFP. The funding plan assumes that the annual average of the 2012 and 2013 biennium’s budget for reimbursing DWSS’s General Fund expenditure would be redirected and serve as the annual baseline for subsequent years. (A restoration of General Funds for DWSS is required to enable this recommendation)

Š

The state share of collections reverted to the state government should be redirected to support maintenance and modernization activities, drawing down FFP. The funding plan assumes that the annual average of the 2012 and 2013 biennium’s budget for reversions would be redirected and serve as the annual baseline for subsequent years.

Š

Additional state share of collections earned in future years from program performance improvements should be directed towards maintenance and modernization activities. The available additional state share of collections in a given future state fiscal year is a forecasted amount based on the assumption CSEP’s performance will improve in the future as the maintenance and modernization enhancements are implemented.

General Fund Support from DWSS Consistent with the funding strategy, PSI’s recommendation uses General Fund support from DWSS to help fund maintenance and modernization activities.

Recommendation Š

DWSS should continue providing the current level of technology services resources, maintaining a baseline level of staff to fix critical issues with the system and directing the balance of the Information Systems resources to execute the activities of the Maintenance Plan and Modernization Roadmap. The funding plan assumes that the annual average of the 2012 and 2013 biennium’s budget for technology services in budget account 3228 expended for CSEP would continue as the annual baseline for subsequent years.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 121

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Available Funding - Conclusion PSI’s analysis of existing funding sources and expenditures concludes that the primary funding sources can be leveraged to support substantive IV-D NOMADS system maintenance and modernization. The funding strategy and recommendations outlined above will enable DWSS and CSEP to leverage funding for maintenance and modernization activities with the prospect of limiting the need for General Fund support over the course of the project. However, should certain funding assumptions not bear out and/or PSI recommendations not be implemented, the level of available resources will likely fall short of the resources needed for maintenance and modernization activities. The following table presents PSI’s forecast of the amount from primary funding sources potentially available for maintenance and modernization activities in each of the state fiscal years (SFY) through SFY 202321 The table also shows the total state resources available by funding source for each state fiscal year as well as the state totals matched with the Child Support program’s federal financial participation (FFP).22 Table 19: SFY 2012-23 Forecast of Funding Source Amounts Available for Maintenance and Modernization Incentives State Share of Collections General Fund Support from DWSS Total State Resources Total Resources with FFP

Incentives State Share of Collections General Fund Support from DWSS Total State Resources Total Resources with FFP

SFY 2012 $4,365,159 $77,387 $279,469 $4,722,015 $5,414,734

SFY 2013 $2,167,941 $157,115 $562,919 $2,887,975 $4,285,688

SFY 2014 SFY 2015 SFY 2016 $3,337,391 $4,099,958 $3,119,854 $1,636,450 $1,782,205 $1,952,137 $560,929 $560,929 $560,929 $5,534,769 $6,443,092 $5,632,920 $9,800,269 $10,991,529 $10,511,223

SFY 2017 $2,266,366 $2,122,068 $560,929 $4,949,362 $10,157,533

SFY 2018 $2,356,708 $2,292,000 $560,929 $5,209,636 $10,747,673

SFY 2023 $2,598,548 $3,141,657 $560,929 $6,301,133

TOTAL TOTAL STATE RESOURCES RESOURCES WITH FFP $34,235,327 $34,235,327 $24,028,330 $70,671,560 $6,451,674 $18,975,511 $64,715,331

$11,288,585 $11,828,073 $12,415,758 $12,952,829 $13,488,504

$123,882,398

SFY 2019 $2,397,822 $2,461,931 $560,929 $5,420,681

SFY 2020 $2,437,511 $2,631,862 $560,929 $5,630,302

SFY 2021 $2,525,398 $2,801,794 $560,929 $5,888,121

SFY 2022 $2,562,671 $2,971,725 $560,929 $6,095,325

The total for a given fiscal year is the snapshot of the amount of resources potentially available for maintenance and modernization activities within that year. Please see Appendix H for the details on the types and amounts of funds factored into the annual total for each of the three primary funding sources in the table. If all recommendations are followed, the total state and federal funding available for maintenance and modernization activities is estimated at $123,882,398 through SFY 2023.

21

See the Maintenance Plan and Modernization Roadmap sections for the details of how the project’s time horizon was determined.

The FFP rate for approved administrative expenditures is 66%. Note that state expenditure of earned federal incentives is not eligible for FFP (Incentives were last eligible for FFP in the 2009 and 2010 federal fiscal years).

22

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 122

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

In the following sections, PSI presents the IV-D System Maintenance plan and the Modernization Roadmap. Each of these sections identifies the annual level of resources required to execute these plans. The final Planning Results section to follow the Modernization Roadmap is the IV-D System Spending Plan. This section overlays and integrates resource requirements and the forecast of funding source amounts to define the initial expenditure plan for maintenance and modernization.

Planning Results: System Maintenance Plan   Maintenance Plan Purpose: Develop an actionable system Maintenance Plan, funded solely from existing program resources, to address IV-D system’s viability issues.

Maintenance Plan Objectives The Maintenance Plan objectives support the Maintenance Plan’s purpose of developing an actionable plan to address the IV-D system’s viability concerns. These objectives are informed by the project assumptions and constraints, architectural principles, technical needs assessment results, federal and state requirements, and any functional needs assessment results that have implications for system viability and maintenance. The objectives for the System Maintenance Plan include the following: Š

Provide DWSS with an actionable plan for sustaining and maintaining the NOMADS CSE application in order to prolong its serviceable life for an extended period (5 years minimum).

Š

Improve application functionality, CSE program performance, and operational effectiveness, but only to the extent that sufficient program resources currently exist to implement such improvements.

Š

Leverage IV-A technology direction and investments, to the extent possible and practical.

Š

Align the Maintenance Plan with the Modernization Roadmap, to the extent possible and practical.

Š

Begin to assemble documentation of the current system to help mitigate risk and support and inform future modernization activities.

Š

Utilize limited IT resources more effectively.

Š

Maximize the availability and effective utilization of program resources to support system maintenance initiatives.

Š

Continue to expand county participation and leverage cooperative practices to increase capacity and improve productivity.

Š

Enable CSE Program Management to more fully participate in identification and prioritization of critical Maintenance Plan objectives and candidate tasks / projects.

Š

Align the Maintenance Plan’s processes for managing, prioritizing, authorizing, and executing components of the Maintenance Plan with DWSS methodologies. Optimize and

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 123

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

streamline these processes for effective execution and efficient utilization of program and IT resources. Š

Improve the process for prioritizing IT work to better align with project goals. Add transparency to ensure stakeholders understand prioritization criteria, the current status of work in process and the current status of work in queue.

Š

Improve communication between DWSS IS and stakeholders. Share more information regarding how resources are utilized and the corresponding accomplishments.

Š

Engage in proactive risk management to minimize negative impact on the program and to continuously monitor viability of the Maintenance Plan.

As noted in objective 4, the system Maintenance Plan should align with the Modernization Roadmap. It must support the Modernization Roadmap where intersections occur. This can and should occur in a number of ways, a few of which are listed below: Š

As new work is prioritized, consideration should be given in terms of whether the new work can be leveraged within modernization plans or whether the investment will be made obsolete by modernization plans.

Š

DWSS should align staff development opportunities with the Modernization Roadmap. Opportunities to gradually learn new skills consistent with the Modernization Roadmap should be promoted as a way to help retain current staff.

Š

Improvements that can be made incrementally as part of the Maintenance Plan and that will support the modernization plan should be considered if they offer near-term benefits.

Š

COTS products, infrastructure investments (should any be made), and new technology standards should be assessed for how they align with the overall technical approach established by the Modernization Roadmap.

Š

If possible, consideration should be given to maintenance tasks providing proof of concept for aspects of the Modernization Roadmap.

Viability Scope The purpose of the Maintenance Plan is to address IV-D System viability issues. In order to develop this plan, it is first necessary to define the scope of viability concerns to be considered for inclusion within the scope of the Maintenance Plan. PSI examined potential viability concerns from the perspective of following four categories: Š

Architectural / Technical

Š

Functional

Š

Maintenance Process Improvement

Š

Resource Optimization

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 124

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Within these categories, PSI offered a broad set of examples to DWSS for consideration as potential candidates for inclusion in the IV-D System Maintenance plan. The results of this consideration are presented below by viability category. It is important to understand that these lists are not intended to be comprehensive or inclusive. Rather, they are provided as a representative sample of items to be considered for inclusion in the plan. As such, these examples are intended as a guide for evaluating whether a concern should be considered a viability issue. Representative examples are included below for each of these categories.

Architectural / Technical Š

Convert CSP code to EGL code.

Š

Improve system performance / increase system capacity.

Š

Improve system availability.

Š

Eliminate obsolete code and data elements.

Š

Archive and purge unneeded data.

Š

Address data security.

Š

Document the system.

Functional Š

Address critical user interface concerns: ƒ

Improve standards and navigation for user interface.

ƒ

Eliminate obsolete screens.

ƒ

Address session timeout issue.

ƒ

Improve access to all relevant data from all applications.

ƒ

Improve user guide documentation and training.

ƒ

Improve system availability.

Š

Improve integrity and reliability of financial records.

Š

Improve address data management.

Š

Improve employer data management.

Š

Improve quality for IV-A referrals.

Š

Address federal requirement compliance concerns.

Š

Insufficient automation of critical processes.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 125

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Maintenance Process Improvement Š

Ensure resources are allocated to the most vital initiatives.

Š

Improve communications and transparency.

Š

Integrate Maintenance Plan processes and DWSS methodologies.

Š

Increase stakeholder involvement.

Resource Optimization Š

Leverage and effectively utilize all available staff resources.

Š

Leverage and effectively utilize all available funding resources.

Š

Reduce / Eliminate efforts expended on initiatives that do not produce end results.

Š

Develop depth of knowledge and skills.

Maintenance Candidates As might be expected given the age and issues surrounding the IV-D system in Nevada, there has been an ongoing demand for changes/enhancements/fixes to the system from a variety of sources. One of the key components of Maintenance Planning is to identify and examine all possible candidates for sustaining/improving NOMADS and determine which of those are most important to the ongoing viability of NOMADS and its associated systems. The ultimate goal of the plan is to recommend how DWSS can best use its existing resources to promote the viability of NOMADS for the foreseeable future. The Maintenance Plan should continue to be a living document. Accordingly, it must also offer mechanisms to screen and sort both the current maintenance candidates and those that arise in the future so that DWSS can continues to advance work most vital to the sustainability of Nevada’s IV-D system. The initial task, and the focus of this section, is to identify and begin to compile the universe of ideas and suggestions for improving the viability of NOMADS and its associated systems, into a cohesive list capable of further analysis. The task acknowledges that DWSS has already prioritized some items for work but takes a fresh look by including a number of other sources for potential maintenance candidates that may further advance NOMADS viability: Š

Architectural / Technical Candidates: ƒ

Š

Functional Gap Solutions: ƒ

Š

Architectural / technical candidates were derived from the technical needs assessment, gap analysis and specific discussions held during an April 2011 meeting between DWSS and PSI. Architectural / technical candidates represent examples of improvements cited as being essential for system viability.

The needs assessment and resulting gap analysis served as the source for items listed as functional gap solutions.

Pending Work Items:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 126

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

Š

Planned Independent Initiatives: ƒ

Š

The Work Item Tracking System (WITS) database served as the source for pending work items. Pending work items are items that have been approved but have not yet been assigned to one of the available slots and work has not yet commenced.

A number of initiatives to improve/enhance NOMADS and associated systems have been planned outside of the current maintenance process.

Proposed but Rejected Work Items: ƒ

Rejected work items represent suggested work items that were previously determined not to be of high enough priority to merit inclusion on the active work item list. The list of rejected work items was extracted from the WITS database.

From the sources noted above and in coordination with DWSS, PSI developed an initial list of potential maintenance candidates. The complete list of the almost seventy items, from all sources, is detailed in Appendix J. In the effort to assemble the raw list of possible maintenance candidates, neither PSI nor DWSS attempted to pre-qualify the suggestions or otherwise weed out items that may not be appropriate for inclusion in the Maintenance Plan. On review, however, items were identified that at minimum need further analysis to determine if they should properly remain as candidates for priority work within the context of the Maintenance Plan or be excluded. DWSS made an initial pass at items it believed should be targeted for removal from further screening.

Maintenance Items Targeted for Removal from Further Screening From the raw list of candidates for potential inclusion in the Maintenance Plan, a number of items were suggested as targets for exclusion from further screening based on a variety of criteria. These items and the rationales for their possible exclusion are laid out below.

Maintenance/Enhancement Items Already in Process DWSS has long understood the fragility of the current NOMADS infrastructure and application and has promoted initiatives to improve the stability and sustainability of the IV-D system. Work to improve/enhance NOMADS and provide better functionality for the IV-D program has continued in parallel with development of this Maintenance Plan and Modernization Roadmap. According to DWSS, there are a number of functional and system enhancement items from the list of all potential candidates that are being addressed as part of the current work assignment/prioritization process. These include (Table 20): Table 20: Enhancements Currently Being Addressed Description

Archive non-active data.

Notes

This is ongoing work (from the mainframe task force) outside of the WI process. Additional work,

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Anticipated Completion 09/2012

Page 127

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

including the development of a rational process for optimization has been designated “Project 2.” This includes exploring the viability of using tools such as IBM’s Optim. Optimize/rewrite critical batch jobs.

WI 1379 was the first item in this ongoing work. Analysis has been done to find optimization opportunities that represent “lowhanging fruit”. At least one additional work item is likely to come from this effort.

12/2011

Establish automated IV-E interface.

Work Items have been coded as DCFS (program #16) Work Items rather than IV-D (program #8). WI 281 is in design, WI 1271 is in requirements, WI 1376 is in design. Work Item 1375, the server piece, is associated with 281 and is also in design.

09/2012

Revise Federal Income Withholding Order/Notice

Waiting to determine the best approach (using EWS to make this change or modifying the ASF form)

unknown

Add an ability to resend a case / person to UIB when necessary

This is being covered by Work Item 1254, "Modify ANSRS to provide a method for workers to resubmit a person to DETR for updated employer and UIB information." Coding has been done and test will begin shortly

8/15/2011

Maintenance Items Planned in Independent Initiatives There are several significant enhancements to NOMADS planned and funded as a result of independent initiatives - those outside of normal ongoing maintenance activities (Table 21). Table 21: Planned and Funded Enhancements Description

Notes

Implementation of E-Payment Child Support Options

DWSS issued a request for information (RFI) for vendors who could process electronic Child Support payments through the Internet. Responses have been received and DWSS is preparing an RFP to solicit these services in conjunction with the State Collections and Distribution Unit. In a parallel effort, Elko County is in the process of establishing a merchant account to take credit cards for payment

Scheduled Mainframe Upgrade

The need to make significant upgrades to the NOMADS mainframe hardware and software has been the subject of a mainframe taskforce. In January of 2010, the Task Force recommended an upgrade and expansion of the current IBM mainframe infrastructure that currently supports the NOMADS codebase and data. The new health reform initiatives have made it all the more imperative to increase the capacity and performance of the NOMADS mainframe.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 128

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Description

Notes Nevada (EITS) has independently scheduled an upgrade of the NOMADS Z10 Mainframe for sometime in the fall of 2011.

CSP to EGL Conversion

As a result of a recent legislative appropriation for technology enhancements to facilitate Nevada health care reform, funding exists to complete a long sought-after code conversion of the NOMADS CSP code base to the more flexible and supported EGL. An RFP for the conversion is in process as of this writing and the actual conversion may be started before the summer of 2012.

Compass Finishing

This is an incentive funded project that envisions the correction, improvement of existing functionality and the addition of a variety of functions in Compass to make the product more user friendly.

EWS Call Center

This is an incentive funded project to move funding for the employer customer service staff from Clark County to DWSS. The project assumes the rollout of EWS program wide including the handling of IWOs and employment verifications for all program offices.

Crystal Reports

This is an incentive funded project to complete the rollout of the business intelligence capabilities piloted in Elko County to all program offices as well as to add additional reporting capabilities

Maintenance items Needing Further Definition Several items on the raw list of maintenance candidates were initially thought to need additional definition, represent items too large to be considered as a single maintenance project, or may be more appropriately a modernization increment. These items are noted below (Table 22): Table 22: Items Needing Definition or Review Description

Notes

Consider strategic custom fixes before full implementation of a workflow engine.

This item needs more definition before it can be considered as a specific

Produce an accurate monthly statement of arrears balance.

This item encompasses a wide range of improvements to the accuracy of financial information within the IV-D systems

Replace the existing IV-D financial component

This may more appropriately be considered for modernization

Recode distribution and other financial components using a Rules Engine

This may more appropriately be considered for modernization

Enhance automation across all functional areas (e.g., intake functionality)

As worded this item is too broad to be considered. The request may represent a number of specific automation enhancements.

Items Targeted for Removal for Other Reasons

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 129

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Several items on the raw list of maintenance candidates were targeted for removal from the raw candidate list for a variety of reasons other than those listed above. For example, work already considered complete. They are noted below (Table 23): Table 23: Items Targeted for Removal Description

Notes

Integrate applications (what are now separate Web apps like LOTW, NAWC) into a unified application with a single log on and timeout

If the description was meant to convey a change in internal workflows, role assignments or otherwise, clarification should be made as to the verbiage. Otherwise, there is already a unified timeout for Web based applications like LOTW and NAWC: 30 minutes of non-use for any of these applications. The issue may be environmental timeouts / perception. Compass is separate. Compass is Msclick Once with its own security/timeouts.

Adopt a single program wide technology for all document imaging.

DWSS considers this accomplished with COMPASS

Continue development and roll out Crystal Reports program wide, including data warehouse and business intelligence (BI) tools

This functionality is already available program wide to anyone who wants it.

Distribute UIB Collections in Accordance With Allocation Rules (CSE Priority 2)

A preliminary meeting was held to discuss Work Item 1231 which is currently in the requirements phase. Further research into historical e-mails and comments in the code reaffirms IS's belief that distribution is working in accordance with allocation rules. The code changes are not major but will require a change to policy and carries certain risk. Based on current research, the associated risk includes the potential for invalid distribution resulting in an increase of overpayments, non-retention of state owed funds and families not receiving funds. DWSS anticipates Program staff involved with this Work Item will conduct further discussions on the merits of moving forward. This item needs a formal policy decision to proceed.

OCSE 157 Fix System Problem Creating Erroneous IV-D Case History Tracking

This effort was intended to redesign how the old OCSE 157 report looked at case history tracking. The old OCSE 157 report has been retired therefore this Work Item is unnecessary

HATS - Application Entry (APEN)

This Work Item was of interest to CC DAFS. DWSS is waiting to hear back from CC DAFS with their input. However, HATS is not part of the current DWSS strategic direction.

HATS - Child Support IVA Referral (PRFL) Process

This Work Item was of interest to CC DAFS. DWSS is waiting to hear back from CC DAFS with their input. However, HATS is not part of the current DWSS strategic direction.

Modify the DRM13A Report

This item is part of the 3-year DRA review item already on the candidate list.

Streamline/automate case closure

DWSS considers that case closure has already been automated to the extent possible.

Maintenance Items Not Considered (Items near completion, new bug fixes and help desk items) Ongoing maintenance for NOMADS is dynamic. This project must accordingly accept as a given the virtually daily changes to the workload of maintenance items confronting DWSS. While this plan has attempted to identify and establish a mechanism for organizing and prioritizing major maintenance items, there is and will be an ongoing flow of “fixes” necessary to keep NOMADS and related systems functioning. The list in Table 21 below represents the items that, as of this writing, are either scheduled to be released to the NOMADS NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 130

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

code base or are in process to finish a fix to an identified problem. DWSS estimates that approximately one third of its existing resources (1-2 FTE) are devoted to ongoing bug fixes, help desk items and ad hoc report requests. This is a key metric as it will figure into the resources available to DWSS to tackle the more substantive maintenance items outlines in this plan. Table 24: Ongoing Maintenance Items Work Item #

Title

Program

Phase

Expected Completion

Scheduled Maintenance 1068

Fix DRF51A and DRF52A Reports to Display the Correct Information When Executed After Midnight

1279

Fix IV-D case creation mechanism(s) to always include person flags regardless CSE of the source Program Ref# 00694590

1386

Fix 0 padding code problem in the Warrants application

1402

SCaDU

Test

8/15/11

Test

8/15/11

SCaDU

Test

8/15/11

Fix processing of IRS HRSA TREAS 303 batches

SCaDU

Test

8/15/11

1412

Allow proper docket selection for IWO generation Program Ref # 00761832

CSE

Dev

8/15/11

58

Additional Filtering Needs To Be Added CSE To ESD Interface

Test

9/18/11

Out of Country Money Cannot be Indexed on CDS IMAGING INDEX Station

SCaDU

Dev

10/14/2011

664

CSE

Dev

10/14/11

1180

Income Withholding Order & Employment Verification Forms Data Files For the EWS - New Employer Database System(CSE Priority 7)

901

Fix incorrect deduction of $25.00 annual CSE fee

Dev

10/14/2011

1125

Automated Case Tracking Entries

CSE

Dev

10/14/11

1387

Fix Select Slow SQL/Memory leaks in CDS DAOService

SCaDU

Approved for Dev

10/14/11

Warranty for Work Item 80/1002: CSE Address Display on RMAD - Mainframe Changes

Dev

10/14/2011

1397

Fix the condition causing WNM35M31 to CSE crash on cases with multiple OJRD records

Dev

11/18/11

1292

1405

Warranty - WI 639 Report Issues

Dev

11/18/11

CSE

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 131

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Work Item #

Title

Program

Phase

Expected Completion

1130

IVD Case Assignment Enhancements

CSE

Dev

12/16/11

1353

IVD Case Assignment Enhancements Server Component

CSE

Dev

12/16/11

Unscheduled Maintenance in Development Need Ability toStore Multiple Employer Address Types

CSE

Dev

Unknown – Environmental issue.

Address further PRFL issues

CSE

Dev

Unknown – Waiting for approach concurrence from Stakeholders

Prevent NCPR screen from allowing changes to name and SSN of the NCP when a re-referral is being accepted.

CSE

Dev

1228

Unknown – Waiting for additional input from Stakeholders

Fix re-referral/invalid case creation issue CSE reported on HT#00706199 Program Ref#00706199

Approved for Dev

1322

Unknown – No resources currently assigned

Identify and fix the cause of the SCaDU discrepancy that occurs roughly three to 4 times per week with the SCaDU Daily Recon Reports Program Ref# 720236

Approved for Dev

Unknown – No resources currently assigned

12

1208

1336

Maintenance In Planning Distribute UIB Collections in Accordance CSE With Allocation Rules (CSE Priority 2)

Req

Unknown – still in requirements and there are policy issues attached to this WI

1232

Federal Income Withholding Order/Notice Revision (CSE Priority 3)

CSE

Planning

Unknown - No resources currently assigned.

1395

Federal Case Registry (FCR) Reconciliation

CSE

Planning

Unknown – No resources currently assigned

1231

Ongoing Open Ended Maintenance 1327

1411

FAST (Compass) Warranty Issues

CSE

Test

Open ended and will never close.

Research and correct (if possible) the 32000 character record limitation when processing CTX files

SCaDU

Dev

Open ended for research as time permits

Tools for Assessing a Candidate’s Place in the Maintenance Plan While most of the potential maintenance candidates may have merit, the limited (indeed often insufficient) programming and other resources make it imperative that DWSS tackle its pool of maintenance candidates in a rational order. To be truly actionable, the Maintenance Plan must identify those candidates that are the most important to sustaining or advancing the viability of NOMADS and associated CSE systems.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 132

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

To that end, PSI worked with DWSS to develop mechanisms to screen and prioritize potential maintenance items into a more workable list. As is outlined in the maintenance process sections below, these mechanisms can be used on an ongoing basis to assist the program in setting priorities in the future, helping to make the Maintenance Plan a living document. For the near term, the tools are useful for assigning a rough priority to the many items already suggested for improving NOMADS.

Screening Algorithm The first of these mechanisms is a screening tool to provide a rough initial sorting of the dozens of potential maintenance items. After some initial culling of “ in process” items, items already completed and items planned in separate initiatives (detailed above), the items remaining from the raw list of potential maintenance candidates were loaded into the Maintenance Plan scoring algorithm worksheet shown below in Figure 11. In conjunction with PSI, DWSS established criteria and weighting used to compute the candidate score. The tool first requires an assessment of whether a maintenance candidate represented a viability issue. If not, the candidate receives a score of zero and the candidate is not further scored. The screening tool then asks the rater to assign a score to each criterion for each candidate meeting the viability test. The criteria are listed in Table 25. Table 25: Criterion for Candidate Scoring Criterion

Description

Viability Rating

The viability rating (1-5) indicates the degree to which the candidate is considered essential for viability of the system and/or Nevada Child Support program.

Federal Requirements

The federal requirement scoring (0,3,5) indicates whether or not the candidate is necessary to comply with federal requirements. A score of zero indicates the item is not necessary to comply with federal requirements. A score of 3 indicates the item is necessary to comply with federal requirements but is not time critical. A score of 5 indicates that the candidate is both necessary to meet a federal requirement and time critical.

Requirement Conformance

Requirement conformance (1-5) indicates the degree to which a candidate satisfies a need identified in the Needs Assessment.

Risk

Risk (1-5) indicates the qualitative risk analysis score where a value of 1 represents the highest probability and impact of risk and a value of 5 represents the lowest probability and impact of risk.

Advances Modernization

The advances modernization criterion (1-5) indicates the degree to which the candidate is consistent with and advances the program toward system modernization goals and objectives. A high score indicates that a candidate represents a positive step toward modernization. A low score indicates that a candidate represents work that does not advance the program toward modernization goals and is work that may be made obsolete by modernization efforts.

Local / Program wide Impact

The local / program wide impact criterion (1-5) indicates the degree to which the candidate provides value to a broad set of counties.

Quick Win

The quick win criterion (1-5) indicates the degree to which the candidate provides value quickly and is likely to improve the perception of IS by program staff.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 133

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Weighting Viability Test Figure 11 - Screening Algorithm for Maintenance Candidates

Table 26 below represents the initial scoring of maintenance candidates. This scoring does not include those candidates targeted for removal as described above. Candidates are sorted from highest to lowest score. 23 Table 26 Initial Scoring of Maintenance Candidates Maintenance Plan Scoring Algorithm

Candidates

Viability Issue?

Candidate Score

33. Segregate sensitive data into specific groupings that can be more closely audited and protected or adopt an architectural “layering” scheme to stratify & segregate data per IRS 1075 / NIST 800-53.

Yes

106.5

9. Develop a case summary / customer service summary screen or screens.

Yes

86.5

Define User Interface standards for NOMADS

Yes

83.5

44. Annual Interest Accrued Notice Responding Agency (CSE Priority 5)

Yes

81

12. Integrate workflow and document management (expand capability in Compass/FileNet).

Yes

77.5

23 Numbers in the candidate list represent their non prioritized order in the original raw candidate list and are without other significance.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 134

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Maintenance Plan Scoring Algorithm

Candidates

Viability Issue?

Candidate Score

37. DRA - Mandatory 3 Year Review

Yes

75.5

56. Take Super Reports statewide.

Yes

75.5

Retroactively apply NOMADS User Interface standards

Yes

75.5

43. Change Consumer Reporting Responsibilities from Initiating Agency to Responding Agency (CSE Priority 6).

Yes

74.5

Define User Interface standards for Web apps

Yes

73.5

Correct date discrepancy on date of receipt

Yes

71.5

Correct discrepancy with interest calculation

Yes

71.5

Correct discrepancy with timing of obligation accrual

Yes

71.5

55. Move Order Entry to the Web

Yes

70.5

Retroactively apply Web User Interface standards

Yes

70.5

20. Develop business rules for system screening/editing of address updates from interfaces.

Yes

67.5

6. Integrate a rule-based workflow engine into the application to enhance research and case processing.

Yes

65.5

14. Develop performance management functionality down to worker level.

Yes

63.5

15. Redesign and further streamline alerts/notifications.

Yes

63.5

41. Inter-governmental Case Closure Code (CSE Priority 10)

Yes

63.5

23. Improve CSENet interface, functionality and accessibility.

Yes

62.5

7. Augment and improve access to step/screen specific system reference information.

Yes

60.5

63. Fix process that requires SPUFI to get the "V" back on NCP3 so IRS intercepts happen correctly where NCP has a verified social through NUMIDENT, an "R" goes on the NCP social.

Yes

60.5

25. Develop IV-A referral screen edits.

Yes

59.5

21. Decouple IV-A and IV-D and replace with system interface.

Yes

57.5

42. Automate IWO for SSA Pending Claim File (CSE Priority 9)

Yes

57.5

18. Enhance audit support functionality.

Yes

56.5

65. Open up the IWIT screen to let users enter an "I" instead of having to call the help desk to do it.

Yes

55.5

3. Increase the mainframe’s raw capacity with upgrades (already EITS.

Yes

53.5

22. Update 3rd party and other State data tables.

Yes

53.5

68. Document the system.

Yes

53.5

57. Improve data in testing regions for more reliable/accurate testing.

Yes

52.5

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 135

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Maintenance Plan Scoring Algorithm

Candidates

Viability Issue?

Candidate Score

49. MINS/PINS Disconnect

Yes

49.5

64. Correct process where the case is automatically closed when a user puts "excluded" on a child in PEX.

Yes

47.5

53. Null Value / 0 UPC on UDC

Yes

46.5

39. DLS Process Changes - Mainframe Component

Yes

43.5

40. DLS Process Changes - Server Component

Yes

43.5

16. Enhance case processing workflow to accommodate distribution of work to specialists rather than case owner where appropriate.

Yes

43

5. Identify and eliminate unused screens.

No

0

8. Establish case note filtering/sorting capability.

No

0

19. Support caseload stratification into high, medium and low value cases.

No

0

32. Develop self service Web/phone capabilities.

No

0

38. Death Registry (Common to IV-A / IV-D)

No

0

45. Database Expansion for NVPAID1115 Grant Project

No

0

48. Hyperlink from the SCaDU Receipt Number

No

0

50. File Tracking - Phase 2 (Reports, IV-D, NCP E&T)

No

0

54. Adding International Codes to NOMADS

No

0

58. Allow developers to create their own “views”.

No

0

59. Develop shared drive or SharePoint site for sharing information and coordinating activities between DWSS and DAFS.

No

0

60. Open up the CASD screen to the help desk so the case [status] can be edited even after the case is closed.

No

0

67. Eliminate obsolete code and data elements.

No

0

Mini Business Cases / Prioritization The screening process, including the worksheet tool used to score candidates, provides a way to roughly narrow the items to be worked on as part of the Maintenance Plan. A second step to further refine and prioritize Maintenance Plan work is embodied in the Mini Business Case (MBC). Comparable to the intent of the Executive Summary process developed by DWSS, the MBC provides a relatively quick way to identify the candidate subject, describe the rationale for the candidate, and describe at a high level, both the effort/cost to implement and the benefits that will accrue if the maintenance item is accomplished. In Figure 27 below, PSI illustrates the components of the MBC template, which uses Microsoft Word and Excel as the template format:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 136

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Maintenance Candidate Mini Business Case I.D. Date: Sponsor: Candidate:

Description:

Rationale:

Screening Score (from Screening Algorithm) Enhanc e Viabilit y (yes/N o)

Viabilit y impact (5max, 1-min)

Necessary for federal requireme nts (0,3,5)

Meets technical or functional requiremen ts (5max,1min)

Risk (1=high risk 5=mini mal risk)

Advances modernizati on (5-high, 1-low)

Benefit range (5progra m wide, 1-local)

Quic k win? (1min, 5 max)

Element

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 137

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Score Total Score:

ROM Cost Estimate: Prog. Rep. Hours:

Prog. Rep. Cost:

Developer Hours:

Developer Cost:

BA/SME Hours:

BA/SME Cost:

Tester Hours:

Tester Cost:

PM Hours:

PM Cost:

Training Hours:

Training Cost: Hardware/software Cost: Other Fixed Costs:

Total Hours:

Total Cost:

Estimate ROM hours in man month (160 hours) increments. Cost uses blended rate (does not attempt to use DWSS specific rates). ROM Benefit Profile: Tangible Benefits 1.e.g., Efficiency Hours saved (description/rationale): 2. 3. 4. Intangible Benefits:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 138

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

1. 2. 3. 4.

Add rows as needed. If applicable, Estimate ROM hour savings in man month (160 hours) increments Dependencies: 1. 2. 3. 4.

Add rows as needed. Additional Forces and Factors: 1. 2. 3. 4.

Add rows as needed. Figure 12 - Maintenance Candidate MBC Template

To assist with completing the ROM level of effort/cost, PSI also developed a spreadsheet tool (ROM estimator), to allocate rough estimates of total project hours across likely resources. A screenshot of the tool appears below:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 139

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Figure 13 – ROM Estimator Screen Shot

The MBC summary sheet details the maintenance item, its description and rationale along with any known dependencies and other factors impacting its importance/priority (such as risk). The summary sheet displays an overview of costs and benefits for the maintenance item derived from the estimator and other tools/methods.

Maintenance Item Definition and Thresholds To complete a MBC for a particular item, the item must be defined sufficiently to enable a valid ROM estimate of both level of effort and benefits. If an item is unclear or ambiguous, clarification should be sought from the item sponsor. In completing a MBC for a given candidate item it may become apparent that the item as defined is too large to be considered an element of “maintenance.” For example, the item on the raw list “Replace existing IV-D financials” appeared significantly more ambitious than was contemplated by the Maintenance Plan. Accordingly, for purposes of preparing a MBC the MBC assumes that where developer hours exceeded six man months (960 hours) the work at issue should be reevaluated for continued inclusion as a maintenance candidate. There are two options in cases where this threshold is exceeded: Š

Determine if the item can be broken down into smaller components (if benefits can be derived from these more granular items of work); in this case the smaller components may need to be re-screened/rescored to determine where they belong in the screened maintenance candidates list, or...

Š

Examine whether the item more properly belongs as an increment of modernization and remove it from the maintenance list altogether (elevating other candidates on the screened maintenance list)

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 140

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

As with any rule of thumb, this threshold should not be mechanically applied. Where it makes sense, large items that are in fact critical to NOMADS viability should be addressed with existing resources as part of the Maintenance Plan.

Maintenance Item Prioritization Based on the cost benefit information provided in the MBCs, along with the rough order of magnitudes for the development effort, DWSS can create projects for these items in a logical order and assign project teams consistent with the maintenance process recommended in the sections that follow. This process must, by necessity, be sufficiently flexible to allow DWSS to rationally allocate existing resources across projects. Accordingly, the process is likely to result in a mix of larger and smaller project efforts that do not mechanically follow the apparent cost/benefit priority. The MBCs however, provide valuable information to DWSS as to the items most likely to deliver the greatest benefits to the IV-D program and thereby offer a pragmatic roadmap for organizing maintenance work for the future.

PSI’s Maintenance Plan Content Recommendations From the maintenance candidates assembled, and with the tools developed for screening and elaborating these candidates, it is clear there are a number of opportunities to improve the viability of Nevada’s IV-D system, including NOMADS. This section presents PSI’s recommendations on both the contents and initial priorities for maintenance. A key principle guiding these recommendations is that all potential work to improve NOMADS is presumed to be part of the Maintenance Plan. Certain items may not need to be screened using the

algorithm described above but all maintenance items that may make up a segment of work during the initial phase of the Plan need to be scoped and prioritized using the concepts underlying the Mini Business Case template. This Maintenance Plan assumes that there will continue to be break fixes and other unplanned items that require the attention of DWSS development and other resources. On average, the unplanned work is expected to occupy no more than two FTEs (development) at any given time. PSI strongly recommends that this work be limited to true “breaks” where functionality previously delivered no longer works. All requests for enhanced or different functionality from what has been delivered should be treated as maintenance items subject to scoring and planning pursuant to the maintenance processes outlined in this Plan.

A second key principle is that work scoped and prioritized for the Maintenance Plan is conducted in accordance with the Governance recommendations. It is critically important that DWSS change the way it does business with respect to the maintenance and enhancement of the IV-D systems. Accordingly, each request for improvement/enhancement should be assessed for its impact on viability, scored according to the algorithm provided and fleshed out in a mini business case before prioritizing the item for work. Except for the break fix work identified above, each maintenance candidate identified, scored and detailed should then become a maintenance project with an assigned project team, product owner and project schedule and should

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 141

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

be executed in accordance with the governance and Software Development Life Cycle (SDLC) processes recommended above.

Recommendation: Fully Scope and Complete In Process and Planned Architectural Work As Soon as Possible A number of potential maintenance candidates have been described as already in process. To the extent such work is completed prior to the effective date of the Maintenance Plan24, it would not be governed by the prioritization or processes laid out in the Plan. However, based on the descriptions of several in process and planned items, there is significant work that should become part of the plan. A number of these address baseline performance and architectural weaknesses. This section describes those items and PSI’s recommended approach.

Archive Non-Active Data Mainframe performance has been expressed as a serious issue affecting all NOMADS users. Reducing the amount of active data in the database is a logical and straightforward way of improving performance by reducing the number of rows any specific online or batch function must parse/review. Some archiving has already taken place and DWSS has begun developing a more formal approach to data optimization, designating this work as part of an effort labeled “Project 2.” The effort to archive non-active data directly addresses NOMADS continued viability. Because it is in process, it does not need to be screened for its relative importance. However, this work is likely to extend into the initial phases of the Maintenance Plan. Accordingly, PSI has begun a Mini Business Case for this work which, in collaboration with DWSS, will provide a general scope and ROM level of effort. The MBC, in turn, will be used in assessing the recommended maintenance timeline for the initial phase of the Maintenance Plan, including what work during this phase is possible with existing resources. The ROM level of effort is shown below: ROM Cost Estimate: Program. Rep. Hours:

24

Developer Hours:

336

BA/SME Hours:

24

24 While the process for review and approval of this Maintenance Plan and Modernization Roadmap will occupy time during which maintenance may be conducted using processes in place before this project began, PSI encourages DWSS to adopt, or begin to adopt recommended processes in advance of such final approval.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 142

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Tester Hours:

96

PM Hours:

48

Training Hours:

0

Labor Cost:

$22,116

Hardware/software Cost: Other Fixed Costs:

Total Hours:

528

Total Cost:

$22,116

Cost shown above uses a blended rate and does not attempt to use DWSS specific rates.

Optimize/Rewrite Critical Batch Jobs Like the need to archive non-active data, work to optimize NOMADS batch jobs is all about performance. Since NOMADS regularly overruns its batch window causing downtime for system users (particularly at month-end), optimizing batch jobs and reducing batch overruns offers direct viability benefits. Here again, while part of the work has been done, (WI 1379 was the first item) Analysis to find optimization opportunities that represent “low-hanging fruit” should be included in the Maintenance Plan. Preparation of an MBC for the remaining effort will accordingly be the first step in determining how best to integrate it into the overall maintenance work encompassed by the Plan. The initial MBC can be found in Appendix K. The ROM level of effort is shown below: ROM Cost Estimate: Program. Rep. Hours:

0

Developer Hours:

270

BA/SME Hours:

0

Tester Hours:

135

PM Hours:

24

Training Hours:

0

Labor Cost:

$18,018

Hardware/software Cost: Other Fixed Costs:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 143

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Total Hours:

429

Total Cost:

$18,018

Cost shown above uses a blended rate and does not attempt to use DWSS specific rates.

Monitor and Fully Test the Mainframe Upgrades The mainframe upgrades scheduled for implementation by EITS represent another significant opportunity for NOMADS performance improvement. Although EITS is responsible for this work, DWSS should develop and maintain a MBC, create a project and assign resources to monitor and fully test the impacts of these upgrades. Mainframe capacity is a serious failure point for the NOMADS system and increasing capacity is vital to the continued viability of the technology support currently available to the IV-D program. Should the execution of the upgrades fail to deliver any significant performance improvements, DWSS may be better positioned to argue for more transformational funding. The initial MBC can be found in Appendix K. DWSS anticipates minimal effort to test the effectiveness of the upgrades. The ROM level of effort is shown below: ROM Cost Estimate: Program. Rep. Hours:

0

Developer Hours:

0

BA/SME Hours:

16

Tester Hours:

16

PM Hours:

0

Training Hours:

0

Labor Cost:

$1,344

Hardware/software Cost: Other Fixed Costs:

Total Hours:

32

Total Cost:

$1,344

Cost shown above uses a blended rate and does not attempt to use DWSS specific rates.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 144

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Take an Active Role in the CSP to EGL Migration The CSP migration initiative may well represent a unique opportunity to develop some additional insights and documentation of the existing NOMADS codebase. This opportunity exists because, inherent in any codemigration activity, is a certain amount of inventorying and analysis of the to-be-converted code. It may also be a necessary part of the process for DWSS to compile (or assist in compiling) a list of incoming code modules to be converted. Even this represents a useful piece of documentation, and once developed, it should be made available to the other analysis activities that will take place regarding the long-term migration planning. If nothing else is done, PSI recommends that DWSS insist on the migration vendor producing a list of modules that were converted, including pre-migration module names and post-migration code-module mappings. Further information might be available from the vendor's pre-migration source-code analysis phase. DWSS should ask the vendor to produce as many of the following kinds of information as can be negotiated: Š

Identification of "dead" (never called) code modules

Š

Identification of highly-leveraged (frequently called) code modules

Š

Identification of difficult-to-convert modules (modules that call assembler routines or other libraries)

Š

Identification of redundant code (identical or nearly-identical code)

Š

Identification of logic-dense code modules

Š

Identification of other patterns or "signatures" as the vendor's analysis tools may already produce

In addition, DWSS should use the migration project to bolster the test environment for use in testing the migration and for future testing efforts. This is work which cannot be left solely to the migration vendor. DWSS can and should play an extensive role in the testing effort. The impact of the migration across all of NOMADS will require extensive testing to ensure no program functionality has been lost or broken. This includes creating sufficient test data to fully test the entire NOMADS application. A MBC has been completed (see Appendix K). Well prior to the beginning of the migration, a project team (including CSE program staff) should be assembled to participate in the migration effort. A ROM level of effort is shown below: ROM Cost Estimate: Program. Rep. Hours:

0

Developer Hours:

1200

BA/SME Hours:

0

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 145

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Tester Hours:

1200

PM Hours:

600

Training Hours:

240

Labor Cost:

$136,080

Hardware/software Cost: Other Fixed Costs:

Total Hours:

3240

Total Cost:

$136,080

Cost shown above uses a blended rate and does not attempt to use DWSS specific rates.

Recommendation: Create Projects and Assign Resources to Monitor Functional Initiatives As with several of the architectural initiatives, the CSEP will benefit from work being proposed or done outside of the program or with separate funding. However, the program should take an active role in these initiatives to ensure they deliver the promised benefits. This requires actively monitoring the initiatives and being prepared to assign resources when needed to assist with design or to help test. Should events result in any significant delay or cancellation of these initiatives, DWSS should reevaluate the priorities outlined in the Maintenance Plan and Modernization Roadmap. An initiative which still has merit should be integrated into either the Maintenance or Modernization Plan, as appropriate.

Establish automated IV-E interface DWSS has responsibility for helping develop and test an automated IV-E interface and has begun some preliminary work. However, DWSS anticipates that substantive development is not likely to commence until after the EGL migration. . An initial MBC has been completed. A project team (including CSE program staff) should be assembled to participate in the design and testing effort. A ROM level of effort is shown below: ROM Cost Estimate: Program. Rep. Hours:

256

Developer Hours:

512

BA/SME Hours:

256

Tester Hours:

256

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 146

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

PM Hours:

320

Training Hours:

128

Labor Cost:

$72,576

Hardware/software Cost: Other Fixed Costs:

Total Hours:

1728

Total Cost:

$72,576

Cost shown above uses a blended rate and does not attempt to use DWSS specific rates.

Implementation of E-Payment Child Support Options An RFP to secure vendor services to offer electronic payment of Child Support is in process and as of the effective date of this plan is likely to be well underway. This initiative may have little impact on NOMADS and associated financial applications but to the extent it does, or will otherwise impact program functions (such as customer service), the program should take an active role in testing and assist in determining that the services secured perform as expected. The SCaDU staff will play the primary role here but customer service and other program functions will be affected. As with the other initiatives mentioned above, the program should exercise ownership by participating actively in what and how these services are delivered. An initial MBC has been completed. At the appropriate time a project team (including CSE program staff) should be assembled to participate in the design, development and testing effort. A ROM level of effort is shown below: ROM Cost Estimate: Program. Rep. Hours:

192

Developer Hours:

48

BA/SME Hours:

192

Tester Hours:

48

PM Hours:

48

Training Hours:

48

Labor Cost:

$24,192

Hardware/software Cost: Other Fixed Costs:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 147

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Total Hours:

576

Total Cost:

$24,192

Cost shown above uses a blended rate and does not attempt to use DWSS specific rates.

Compass Finishing Work to finish the implementation of Compass has been funded. This work includes building out additional workflows to improve case management efficiency. The project will involve program resources at a minimum to work with the Compass vendor and may involve some IT effort as well. An initial MBC has been completed (see Appendix K). A project team (including CSE program staff) should be assembled to participate in the design and testing effort. A ROM level of effort is shown below: ROM Cost Estimate: Program. Rep. Hours:

480

Developer Hours:

0

BA/SME Hours:

384

Tester Hours:

96

PM Hours:

48

Training Hours:

96

Labor Cost:

$46,368

Hardware/software Cost: Other Fixed Costs:

Total Hours:

1104

One time vendor costs

$450,000

Total Cost:

$496,368

Cost shown above uses a blended rate and does not attempt to use DWSS specific rates.

EWS Call Center EWS offers a customer service Web site for employers who interact with the Nevada Child Support program. The site provides a way for employers to maintain correct address and contact information and will offer a mechanism to add the correct address to common employer forms and for employers to complete those forms online. The EWS project was initially funded and managed by Clark County. The next phase is to fund NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 148

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

at the state level, the staff currently in place in Clark County to assist employers with the EWS site and provide customer service in general to the Nevada employer community. The project also envisions the ability to support online Child Support forms for all Nevada employers and to add correct address information to income withholding and employment verification forms generated by CSE offices across the state. An initial MBC has been completed to address the system work necessary to generate forms from all CSE county offices. A ROM level of effort is shown below:

ROM Cost Estimate: Program. Rep. Hours:

100

Developer Hours:

200

BA/SME Hours:

100

Tester Hours:

100

PM Hours:

125

Training Hours:

50

Labor Cost:

$28,350

Hardware/software Cost: Other Fixed Costs:

Total Hours:

675

EWS Staff Costs (one year)

$250,000

Total Cost:

$278,350

Labor Costs shown above uses a blended rate and does not attempt to use DWSS specific rates. The project will eventually need to address the logistics of forms generation, printing, mailing for all of the county offices as well as the mechanism for returning electronic responses to the appropriate office.

Crystal Reports

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 149

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Work to finish and then expand the implementation of Crystal Reports has been funded by incentive funds. Vendor resources will provide the bulk of the effort. This will involve program resources at a minimum to work with the vendor and may involve some IT effort as well. A small effort to complete current work has been estimated to finish by September of 2011. The MBC estimates the following ROM level of effort: ROM Cost Estimate: Program. Rep. Hours:

90

Developer Hours:

0

BA/SME Hours:

90

Tester Hours:

90

PM Hours:

13.5

Training Hours:

27

Labor Cost:

13,041

Hardware/software Cost: Other Fixed Costs:

Total Hours:

310.5

Total Cost:

13,041

A MBC has been completed as well for the second phase project which will use incentive funding. A project team (including CSE program staff) should be assembled as appropriate to participate in the design and testing effort. Some coding may also be required to support/configure the database connections. A ROM level of effort is shown below: ROM Cost Estimate: Program. Rep. Hours:

220

Developer Hours:

440

BA/SME Hours:

220

Tester Hours:

220

PM Hours:

275

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 150

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Training Hours:

110

Labor Cost:

$62,370

Hardware/software Cost: Other Fixed Costs:

Total Hours:

1485

One time vendor costs

$656,000

Total Cost:

$718,370

Labor Costs shown above uses a blended rate and does not attempt to use DWSS specific rates.

Recommendation: Re-screen In Process Candidates that are Halted or Not Started In addition to the items listed above, several additional maintenance candidates from the raw list (Appendix J) were excluded from the initial screening as being “in process.” However, these items remain an integral part of the Maintenance Plan. For purposes of the Maintenance Plan PSI assumes that this work will continue to completion. Items of work that are halted, or only partially completed should be considered as maintenance candidates and screened appropriately in accordance with the maintenance processes PSI recommends below. These items include: Š

Federal Income Withholding Order/Notice Revision

Š

The ability to resend a case / person to UIB when necessary

Recommendation: Deconstruct and Address Improvements in Financial Functions As might be expected, a number of requests for improvements in the financial functionality of NOMADS and associated IV-D system made the raw list of candidates. As written, however, several candidates were either too broad (replace IV-D financial component) or too vague (develop functionality to address greatest financial pain points/deficiencies such as reconciliation, adjustments and reporting) to be fairly screened much less capable of being captured within a meaningful mini business case. Replacement of the IV-D financial subsystems will be a key increment in the Modernization Roadmap. Until the funding for that step is available, there are potential improvements in the workings of the NOMADS financial functions that should be capable of completion as part of the Maintenance Plan. To identify specific candidates for enhancement, the currently undefined maintenance candidates should be deconstructed to determine if more fine grained changes can deliver benefits to the program. For example, the details gleaned from the Needs Assessment interviews identified several specific defects behind the item to “address greatest financial pain points.” These include: Charging interest. It has been reported that Nevada law says interest must be charged on all arrears. However, some judges order interest to be charged on the balance of some account types but not other account types (e.g., TANF arrears, family’s arrears, other state’s arrears). When staff follows what the order says instead of the law, NOMADS/LOTW can’t handle it, and they need to update the overall balance each month. A possible fix is to modify NOMADS/LOTW to accrue interest specific to the balance of an account type. As a side issue, NOMADS mainframe needs to allow interest balances in excess of $100,000

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 151

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Date of receipt. When a payment was withheld at the end of a month but SCaDU receives it the start of the following month, Nevada has potentially two different dates of receipt to use for the payment. Unfortunately, LOTW and NAWC use different dates of receipt (i.e., when withheld, when received by SCaDU), and this causes arrears balances between the two systems to be different. NAWC treats the payment as current support for the previous month, LOTW as current support this month, implying an arrearage owed in the previous month. A potential solution is to use the same date of receipt in both systems. This fix has both a policy element and a technical element. Obligation accrual. It was reported that NOMADS(/LOTW?) accrues orders differently than NAWC. It appears that one system posts at the start of the month the amounts coming due during the month and the other system posts the amounts coming due during the month on the day within the month that the amount is owed. So if the due date of a monthly obligation is the 15th of each month, one system displays the amount due on the 1st of the month while the other system displays the amount due on the 15th of the month. The implication of what was reported is that the system that displays the amount due on the 1st of the month includes this obligation amount in its unpaid balance. Therefore, its unpaid balance doesn’t sync up with the other system’s unpaid balance until the 15th when the other system displays the amount as owing. A potential solution is to make all systems consistent in their display of an amount owed in the month. The first step is to define a consistent policy for when an obligation is past due and get county and judicial staff to abide by it. Then make the appropriate changes to the systems. Arrears reduced to a judgment. It was reported that the differences in unadjudicated and adjudicated judgments creates problems. In other words, it’s difficult to make LOTW match what the court determined the arrears should be. A potential interim solution might be to examine the mechanical processes for making the changes and look for ways to automate them. DWSS has done some of this deconstruction and has added and scored several discreet maintenance items to the scoring algorithm list (see Table 23 above). As expected, these items ranked in the top twenty and should be addressed promptly as part of the Maintenance Plan. Because of the importance of the financial components of the Nevada IV-D systems and the benefit of solidifying financial logic in advance of modernization, PSI recommends that all potential financial candidates be examined by knowledgeable program staff to see if specific maintenance solutions can be identified. Once detailed, these candidates should be added to the candidate list and rescored using the screening algorithm.

Recommendation: Develop Mini Business Cases for Top Screened Maintenance Candidates PSI recommends mini business cases be developed for at least the top 20 of the screened maintenance candidates in order to evaluate the potential for their inclusion in the Maintenance focus period as outlined below. As part of this plan, DWSS has prepared MBCs (including ROMS) for the following maintenance items from the initial scoring exercise. Table 27: Screened Maintenance Items with MBCs

Item Number

MBC00010

Title

Segregate sensitive data into specific groupings

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 152

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

MBC 00011

Develop Case Summary/Customer Service Summary Screen

MBC 00012

Define User interface Standards for NOMADS

MBC 00013

Annual Interest Accrued Notice

MBC 00016

DRA - Mandatory 3 Year Review

MBC 00017

Take Super Reports Statewide

MBC 00018

Apply NOMADS Interface Standards

MBC 00019

Change Consumer Reporting Responsibilities

These MBCs can be found in Appendix K.

Maintenance Plan Approach The funding detailed in the Funding Plan section above reveals resources that should allow DWSS to tackle a significant segment of the outstanding maintenance items currently identified, including those that PSI has recommended above and those that have been listed and scored in the Initial Scoring of Maintenance Candidates (Table 23, above). It might seem that the funding appears substantial enough that DWSS should consider foregoing much of the identified maintenance to instead focus on modernization. However, PSI believes this approach is not warranted for a variety of reasons: Š

Major health reform technology projects are now in the initial stages of planning/procurement and will require significant focus, making it difficult to manage any additional major technology initiatives.

Š

Even with highly aggressive scheduling and optimistic assumptions, demonstrable benefits from modernization to IV-D system users are at minimum at least 2-3 years away, while maintenance can deliver significant benefits to viability within the first 18 months of the Plan.

Š

Modernization will require significant planning to maximize the benefit that can be derived from available resources. This planning can begin while significant maintenance progress is made.

Š

Several maintenance items will advance modernization and make moving toward the recommended target architecture easier and faster.

In light of the risks attendant to an immediate move toward modernization, PSI recommends that the first 18 months of the Maintenance Plan and Modernization Roadmap be devoted to effectively delivering on the maintenance items currently in the Plan and those maintenance items which may be added using the processes the Plan recommends. After this 18 month period, the focus should shift to modernization and maintenance should be scaled back to the minimum necessary to cover break fixes and activities to “keep the lights on.” This approach can deliver value to IV-D system users while allowing time to fully prepare for the modernization push that follows. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 153

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Coordinate Maintenance and Modernization A caveat to the recommendation above is that certain maintenance candidates may become obsolete or redundant should modernization be possible beginning soon after the 18 month maintenance focused period. DWSS should fully consider the impact and planned pace of modernization before undertaking specific maintenance items. For example, the development and application of NOMADS user interface standards ranked high in the list of likely maintenance candidates. Before undertaking a wholesale application of these standards to existing NOMADS screens, the likely shelf life of this work should be considered. It may not make sense to invest significant maintenance hours in this endeavor if modernization and the move to a wholly new UI is on the near term horizon. However, it may be beneficial to make selective UI improvements depending on the functional area involved and the time to transition of that function to the new architecture/platform. In contrast, there may be maintenance items that rise in importance as modernization approaches. For example, Web-based user interface standards will be critical to designing the user experience in the new architecture. The bottom line is that as maintenance proceeds, particularly at the accelerated pace recommended, the impact of modernization should be weighed in the project planning for each maintenance item, particularly as the reality of modernization approaches.

Maintenance Staffing Ramp Up and Ramp Down Our funding plan contemplates a maintenance staff of 11 FTEs at the height of the maintenance push. This number appears both possible in terms of funding and manageable within the context of the changing maintenance processes and the current management infrastructure. Not included in this staff number is the Product Owner position, which should be funded independent of any specific maintenance or modernization projects. The Plan also assumes that 2 FTE of the 11 will be devoted to regular break fix and ad hoc work for the life of the Plan, indeed for the life of the current IV-D systems. The Plan does not attempt to predict or dictate the mix of project managers, dedicated business analysts, developers and testers within this maintenance team. Nor does it dictate the portion of team who, along with existing DWSS staff, may be new hires or staff contracted for during the 18 month maintenance push. It should also be noted that the projected 11 maintenance staff does not include program resources that will be called upon on a case by case basis to provide subject matter expertise and other service in support of a particular maintenance item. The Funding Plan would permit additional resources beyond those recommended above (supporting a staff of 13 or more including the 2 FTEs for break fixes). Additional staff would provide additional hours to apply against the list of maintenance items from the scoring exercise. However, DWSS should use caution in opting for this expanded staffing plan and do so only if confident that the resources can be used effectively and that functionality can be delivered to program staff effectively. This will in large part be determined by how well DWSS can implement the governance recommendations proposed above. Sound governance, good communication, solid project planning and execution should all be in place before undertaking a more aggressive maintenance portfolio. PSI recognizes the barriers that have existed to hiring new development staff. However, the funding designated for maintenance provides flexibility for DWSS needs to address these barriers. Creativity in the use of contract staff as well as leveraging County resources should be considered as options. The migration to EGL should also open the candidate pool for development staff.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 154

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The reality of building up the maintenance team also requires a pragmatic ramp up period as new resources are brought on board and brought up to speed. Similarly, our Plan envisions a ramp down period where resources are directed from maintenance to the planning needed to prepare for modernization. As PSI notes in our Modernization Roadmap, the latter period of the maintenance push should include the planning and preparation for the initial procurement activities that will be needed to jump start the initial modernization increments. An overview of this staffing ramp up and ramp down appears in the chart below:

Figure 14 - Maintenance Staffing Ramp Up and Ramp Down

For purposes of our Plan, PSI starts in January 2012 to coincide with the Biennium and to provide DWSS time to absorb and gear up for the actions the Plan recommends, particularly with respect to governance and setting maintenance priorities. It should also be noted that the projected 11 maintenance staff does not include program resources that will be called upon on a case by case basis to provide subject matter expertise and other service in support of a particular maintenance item.

Maintenance Timeline and Current Prioritization Summary of Anticipated Maintenance Hours The current slate of maintenance items, not including anticipated break fixes and other routine maintenance work is shown in the table below. This summary totals the Rough Order of Magnitude (ROM) hours for the in process work outlined above as well as ROMs for several of the maintenance candidates that ranked high in the initial scoring of maintenance candidates using the scoring algorithm.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 155

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Our Plan assumes the 18 month maintenance focus begins in January 2012 so some of the work detailed below (highlighted in green) should already be completed by the time this push begins.

Table 28: Current Slate of Maintenance Items and ROM Hours MBC Summary Data

Start Date

MBC 00001

Archive Non-Active Data 

MBC 00002

End Date

Total ROM Hours

Jul-11

Sep-12

528

Optimize/Rewrite Critical Batch Jobs

Jul-11

Dec-11

429

MBC 00003

Monitor and Test Mainframe Upgrades

Nov-11

Nov-11

32

MBC 00004

Monitor, Test and Document EGL Migration

Jan-12

Apr-12

3240

MBC 00005

Monitor and test IV-E Automated Interface

Jul-11

Sep-12

1728

MBC 00006

Monitor and Test Implementation of E Payment

Nov-11

Dec-11

576

MBC 00007

Assist Compass Finishing

Feb-12

Jun-12

1104

MBC 00008

EWS Call Center and Statewide Implementation

Jul-11

Dec-11

675

MBC 00009

Monitor and Test Crystal Reports Finishing

Jan-11

Jul-11

310.5

MBC 00020

Monitor and Test Crystal Reports Phase 2

Jul-11

Mar-13

1485

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 156

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

MBC Summary Data

MBC00010

Segregate sensitive data into specific groupings

TBD

TBD

2592

MBC 00011

Develop Case Summary/Customer Service Summary Screen

TBD

TBD

373

MBC 00012

Define User interface Standards for NOMADS

TBD

TBD

176

MBC 00013

Annual Interest Accrued Notice

TBD

TBD

432

MBC 00016

DRA - Mandatory 3 Year Review

TBD

TBD

2070

MBC 00017

Take Super Reports Statewide

TBD

TBD

480

MBC 00018

Apply NOMADS Interface Standards

TBD

TBD

3450

MBC 00019

Change Consumer Reporting Responsibilities

TBD

TBD

360

Total Hours for Maintenance items with ROMS

20040

Hours Completed by Jan 2012

2022

Hours Committed for the Maintenance Focus period

18018

The ROM hours estimated for the candidates listed above are below what should be available for maintenance once the maintenance staff has been increased to the level recommended for the maintenance focus period. As shown in Figure 28, above, the ramp up of maintenance staff to 9 FTE (not including two staff dedicated to break fixes) will provide significant hours for maintenance over and above what has been currently estimated.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 157

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Figure 29 below illustrates resource hours that should be present assuming DWSS acts on our recommendation to focus on maintenance with the resources identified in the Funding Plan. The chart shows the available hours by month for the recommended maintenance staff contrasted with the hours represented by the ROMS completed to date for in process and highly ranked maintenance candidates. For purposes of the figure Committed ROM hors have been spread evenly throughout the 18 month maintenance focus period. It may be that some of these projects could be completed prior to the EGL migration (particularly those relatively small in size) or worked on during the migration (those items that do not directly impact mainframe code (such as taking super reports statewide). Project staff will need to plan the appropriate sequence of projects based on resource loads and available skills but PSI encourages moving smaller projects up as possible to deliver value and maximize resources prior to any code freeze required by the EGL migration.

Figure 15 - Recommended Maintenance Staff Hours by Month

Although these estimates are necessarily idealized, the chart shows that there should be substantial hours available to address a number of the maintenance candidates that are already on or may be added to the maintenance candidate list. Candidates already rated highly in the scoring algorithm should be further developed using the Mini Business Case tools and based on the MBC results (including ROMS) a portfolio of maintenance projects should be planned for execution according to a defined project schedule. PSI strongly encourages this planning be conducted well in advance of bringing on additional resources so staff can be immediately assigned to well-understood and planned maintenance projects.

Maintenance Sequencing Sequencing of maintenance items will necessarily be dynamic. The in process items already have at least tentative start and end dates, some of which are outside the control of DWSS. The current backlog of break fixes will also occupy a contingent of the existing maintenance resources in the near term and new break fixes and ad hoc requests will undoubtedly arise. DWSS should begin building project portfolios (including individual project plans with assigned resourcing) for those items they have at least a tentative schedule for.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 158

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

DWSS should attempt to include in the project portfolio projects for one or more of the smaller maintenance candidates from the scoring exercise for which ROMS have been developed (such as the Customer Service Summary Screen). These items should be assigned a project team and scheduled for completion prior to the beginning of the EGL migration effort. An idealized example of sequencing appears in Figure 30 below:

Figure 16 - Recommended Maintenance Staff Hours by Month

DWSS also has a number of process and organizational items to complete in preparation for executing the Maintenance Plan, particularly the maintenance focus period recommended to start January 1, 2012. These include:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 159

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Planning for and executing the governance recommendations

Š

Completing mini business cases and ROMS for at least the top 20 candidates from the scoring exercise (the MBCs already completed are listed below)

Š

Developing and executing a staffing plan to gear up the maintenance organization

With forecasted staffing numbers from the staffing plan, DWSS should begin active planning for the maintenance focus period and schedule additional maintenance candidate projects in the project portfolio. The scores from the scoring algorithm along with the size, cost, and benefit information from the MBCs should be used to appropriately prioritize the maintenance work and then assign them to actual or prospective project teams. DWSS should make use of the code freeze period from the EGL migration to complete projects that are not impacted by the need to leave the NOMADS CSP code unchanged. The makeup and management of the portfolio will of course evolve as information about staffing and other factors changes or becomes more clear. The System Owner in close cooperation with DWSS IT, the PMO and other program stakeholders should actively manage the maintenance portfolio using the plan maintenance processes set out below. The goal should always be to ensure maintenance resources are effectively used for high priority candidates and that scheduled maintenance projects are executed to completion and deliver expected functionality. Completed initiatives should “roll off” to an archive list, and new candidates from the screening exercise should replace them after developing an associated MBC. The mini business cases (MBCs) completed to date are provided in Appendix I. A summary of the completed MBCs appears below. As noted, additional MBCs should be completed and planned based on the current list of scored maintenance candidates as well as those that may be added and scored as the Plan evolves. Candidate:

Archive Non-Active Data

ID: 00001

Sponsor: DWSS IT

Description:

Est. Start: July 2011

Est. Finish: Sept. 2012

NOMADS does not have a sufficient structure for archiving and purging data, which is contributing to sluggish batch processes. Month-end batches often run into the middle of the work day, resulting in downtime for production in NOMADS. It is expected that an additional 1,000,000 records and an additional 400,000 Medicaid cases will be added to the NOMADS database due to Health Care Reform.

The goal of this project is to identify data in the DB2 (and UDB) databases that are no longer needed for current case processing or for current reports and to remove the data from being touched by current NOMADS and associated IV-D system processes. It is anticipated that the data removed will be available for readonly access until a pre-defined retention period has expired at which time the archived records may be destroyed.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 160

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Candidate:

Optimize/Rewrite Critical Batch Jobs

ID: 00002

Sponsor: DWSS IT

Description:

Est. Start: July 2011

Est. Finish: Dec. 2011

This goal of this project is to streamline critical batch jobs to reduce the run time WI 1379 (three month end and daily batch jobs) was the first item in this ongoing work. Analysis has been done to find optimization opportunities that represent “low-hanging fruit”. At least one additional work item is likely to come from this effort. The first pass consisted of tuning SQL where appropriate, ensuring that database reads were using proper indexes and specifying “for fetch only”.

DWSS has identified the 5 largest jobs that consume the nightly batch and has begun analysis of those jobs.

Candidate:

Monitor and Test Mainframe Upgrades

ID: 00003

Sponsor: DWSS IT

Description:

Est. Start: Nov. 2011

Est. Finish: Nov. 2011

EITS will be upgrading the mainframe from z9 to z10. New hardware will likely also be acquired.

Candidate:

Monitor, Test and Document EGL Migration

ID: 00004

Sponsor: DWSS IT

Description:

The migration effort will consist of upgrading from CSP to EGL (Enterprise Generation Language), extending tools to generate maintainable EGL artifacts, test all of NOMADS including ancillary COBOL and Assembler applications and retrain the programming staff. Training will consist of EGL language training and all of the associate WebSphere tools.

Est. Start: Jan 2012

Est. Finish: April 2012

It is anticipated that there will be a mandatory code freeze for the duration of the migration effort. In addition to the training and testing that will occur during the NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 161

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

code freeze, PSI anticipates a certain level of system documentation needs to occur.

Candidate:

Monitor and Test IV-E Automated Interface

ID: 00005

Sponsor: DWSS IT

Description:

Est. Start: July 2011

Create a mechanism for electronically referring child welfare cases to NOMADS for Child Support enforcement purposes. The Division of Child and Family Services (DCFS) UNITY computer system must pass a nightly data file with information concerning non-custodial parents of children in the custody of the child welfare agency to NOMADS for the purposes of creating a Child Support case. NOMADS must be capable of rejecting referrals with missing information or incorrect formats.

Candidate:

Monitor and test Implementation of E Payment

ID: 00006

Sponsor: DWSS IT

Description:

Est. Start: Nov. 2011

Est. Finish: Dec. 2011

DWSS is in the process of securing a third party vendor to process credit card payments made by noncustodial parents and employers. Functionality needs to be added to ensure the payments received via EFT from the third party vendor are properly coded and recorded in NOMADS.

Candidate:

Assist Compass Finishing

ID: 00007

Sponsor: DWSS IT

Description:

Est. Finish: Sept. 2012

Est. Start: Feb. 2011

Est. Finish: Jun. 2012

Correct, improve and add a variety of functions in Compass to make the product more user friendly. These corrections and enhancements include changes in system navigation, the ability to cut and paste data, the ability to tag or flag documents, automatically delete completed tasks from the task list, and document

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 162

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

management.

Candidate:

EWS Call Center and Statewide Implementation

ID: 00008

Sponsor: DWSS IT

Description:

Develop a statewide EWS Call Center that will centralize the responsibility for adding, changing and deleting employer information in NOMADS.

Candidate:

Monitor and Test Crystal Reports Finishing Phase 1

ID: 00009

Sponsor: DWSS IT

Description:

Phase 1 is to finish and extend work already started. The project was developed in Elko County to create a data warehouse that will allow program managers, supervisors and caseworkers to create reports.

Candidate:

Monitor and Test Crystal Reports Phase 2

ID: 000020

Sponsor: DWSS IT

Description:

This is an incentive funded project to expand the capability of the current reporting pilot initiated by Elko County. An RFP may be required.

Candidate:

Est. Start: July 2011

Est. Start: July 2011

Est. Start: July 2012

Est. Finish: Dec. 2011

Est. Finish: Sept. 2011

Est. Finish: Mar. 2013

Segregate sensitive data into specific groupings that can be more closely audited and protected or adopt an architectural “layering” scheme to stratify & segregate

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 163

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

data per IRS 1075 / NIST 800-53. ID: 00010

Description:

Sponsor: DWSS IT

Est. Start: TBD

Est. Finish: TBD

Under the law (Internal Revenue Code Section 6103(p)), IRS must protect all the personal and financial information furnished to the agency against unauthorized use, inspection, or disclosure. Other Federal, State, and local authorities who receive FTI directly from either the IRS or from secondary sources must also have adequate security controls in place to protect the data received. In order to ensure the confidentiality and integrity of FTI, data encryption is an essential element to any effective information security system. It can be used to safeguard against unauthorized disclosure, inspection, modification or substitution of FTI. IRS Publication 1075 utilizes the encryption requirements of NIST SP 800-53 and FIPS 140-2 to constitute the encryption requirements agencies in receipt of FTI must comply with.

Candidate:

Develop Case Summary/Customer Service Summary Screen

ID: 00011

Sponsor: DWSS IT

Description:

Est. Start: TBD

Est. Finish: TBD

Develop a summary screen (or enhance ACDT screen) that provides a digest of all relevant information on a case for quick access and review. Also develop customer self-service features allowing on-line applications updating of personal data (e.g., address) by case participants, viewing payment history, balances, court dates, etc.

Candidate:

Define User interface Standards for NOMADS

ID: 00012

Sponsor: DWSS IT

Description:

Define User interface Standards for NOMADS to improve consistency and ease training.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Est. Start: TBD

Est. Finish: TBD

Page 164

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Candidate:

Annual Interest Accrued Notice Responding Agency (CSE Priority 5)

ID: 00013

Sponsor: DWSS IT

Description:

Est. Start: TBD

Est. Finish: TBD

Create a new automated notice to be sent to responding jurisdictions reporting the amount of interest accrued on each case being enforced by the responding jurisdiction for Nevada. The system must be capable of producing an annual notice of interest charges to be sent to the responding agency in each case in which Nevada is the initiating jurisdiction, Nevada has the controlling order and interest on past due support has accrued. The notice must also be able to be produced upon request.

Candidate:

DRA - Mandatory 3 Year Review

ID: 00016

Sponsor: DWSS IT

Description:

Enhance current system functionality to identify public assistance cases requiring a mandatory three year review, track cases undergoing the review process, and generate necessary notices.

Candidate:

Take Super Reports Statewide

ID: 00017

Sponsor: DWSS IT

Description:

Enhance the system to produce case management reports that will allow supervisors and caseworkers to sort and prioritize work. Several counties have developed case management reports that allow caseworkers and supervisors to sort and prioritize work. This maintenance candidate seeks to make those report formats available for statewide use.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Est. Start: TBD

Est. Start: TBD

Est. Finish: TBD

Est. Finish: TBD

Page 165

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Candidate:

Apply NOMADS Interface Standards

ID: 00018

Sponsor: DWSS IT

Description:

Est. Start: TBD

Est. Finish: TBD

Implement standard user interface changes across NOMADS.

Candidate:

Change Consumer Reporting Responsibilities from Initiating Agency to Responding Agency (CSE Priority 6).

ID: 00019

Sponsor: DWSS IT

Description:

Est. Start: TBD

Est. Finish: TBD

Enhance system functionality to report all Child Support arrearages to consumer reporting agencies for cases in which Nevada is the responding agency in an intergovernmental IV-D case. Additionally, remove the current functionality to report all Child Support arrearages to consumer reporting agencies for cases in which Nevada is the initiating jurisdiction in an intergovernmental IV-D case.

Maintenance Plan Processes This section of the Maintenance Plan describes processes for maintaining the list of maintenance projects. It assumes the adoption of some of the governance recommendations, namely the establishment of a product owner. The product owner’s role is to own maintenance projects from inceptions as maintenance candidates through project completion. The governance recommendations section of this document describes in more detail the product owner’s role. The product owner is responsible for managing the list of pending and in process maintenance projects. Maintenance projects begin as maintenance candidates initiated through the use of a maintenance project request. The maintenance project request is an Excel form that replaces the current executive summary form. The maintenance project request form maintains information about the maintenance candidate / maintenance project throughout its life. As new maintenance candidates are received, they are evaluated to determine whether they are complete, actionable and meet the test for viability issues. If so, the product owner records them into an Excel-based screening tool. The product owner is responsible for assigning attribute values used by the screening algorithm. The algorithm assigns a score to the item. It is then sorted to determine if it falls into the list of the top 20 pending maintenance projects. If so, the product owner develops a business case for the item. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 166

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Business cases include a ROM cost/level of effort estimate and a ROM estimate for quantifiable benefits. If the ROM estimate for cost/level of effort exceeds a predefined threshold, the product owner may consider adding the item to the Modernization Roadmap or may choose to decompose the project into smaller units. The product owner then assigns a priority to the item based on cost and benefits. The development manager uses the priority and level of effort estimates to distribute work. Once substantive work begins for a maintenance project, it is removed from the top 20 list of pending maintenance projects and tracked as an in-process project. Only under rare circumstances shall in-process projects be interrupted or put on hold and assigned resources redeployed. As maintenance projects progress through SDLC phases, level of effort estimates are revised and tested against the pre-established threshold for project size. Maintenance projects determined to exceed the threshold must be re-evaluated and appropriate actions taken. If changes occur that impact the scores for previously scored maintenance projects still pending, those items should be re-scored and the list of maintenance projects re-sorted. Similarly, if the screening criteria or weighting changes, all pending items shall be re-scored and re-sorted.

Planning Results: System Modernization Roadmap 

Modernization Vision Over the course of the IV-D Systems Assessment Project, a clear vision has emerged for the future Nevada IV-D System. The architecture for the future Nevada IV-D System is fully described in a previous section (Target Conceptual System Architecture), and defines a system that is more scalable, robust, and easier to modify than the current systems. It offers key technology elements such as: Š

A multi-tiered, Services-Oriented Architecture (SOA)

Š

A streamlined, unified relational database at its core

Š

Workflow support

Š

Business Rules Management capabilities

Š

Business Intelligence / Data Warehouse components

Š

Leverages COTS applications

As has been discussed elsewhere in this document, DWSS’ funding and resource constraints are significant, and accordingly the Modernization Roadmap must contemplate the dynamic process that will surely characterize the modernization efforts. It should be expected that funding and resources will become available in not-entirely-predictable ways. Given the amount of time that the modernization efforts will be ongoing, it should also be expected that priorities will shift from time to time and new priorities—which may include entirely new modernization increments and/or architectural components—will be introduced. Given these near-certainties, the Modernization Roadmap should: Š

Be adjustable. To the extent permitted by “hard” dependencies, it should be possible to resequence increments and/or insert new increments into the Modernization Roadmap.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 167

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Allow for the composing and refactoring of increments. Increments should be defined at a fairly fine-grained level so that modest amounts of funding / resourcing can be applied to them. Larger infusions of funding / resourcing might come available, and require that several increments be composed into a larger increment that can be undertaken with the available resources. Conversely, increments may need to be refactored25 to adjust to new technologies or changes in program priority.

Š

Coexist with legacy. The legacy components of the system will continue to exist for a number of years. The Modernization Roadmap should accommodate this reality by ensuring that individual increments deal realistically with the legacy system components. They should define how legacy code components will be converted, whether data conversion will be necessary, how data conversion will be performed, and whether / how side-by-side functioning of legacy and modernized will be accommodated.

Š

Tend towards stability. When not deploying new modernization increments, the nature of the system should be stable; it should be possible to live in any of the “interim” system states for an indefinite amount of time. Therefore, each increment should strive to deliver a useful improvement in functionality while delivering a stable system state that could be used asdelivered for the foreseeable future.

Š

Leverage technology wherever possible. There is a huge body of code that comprises the existing IV-D systems, and hand-converting every line of code is simply not feasible. Automated code conversion tools, code generators, and other forms of technology automation should be used when they add value to the project.

Š

Ensure maintainability. At any given point in time, it should be possible for DWSS programming personnel to identify the code that is responsible for any element of the system’s behavior, understand what it is doing, and modify its behavior in a straightforward way.

The later sub-sections within this section will lay out a number of specific modernization increments (concrete and actionable steps) that advance the system towards the goal of a modernized system. These will be followed by a “Sequencing” section that describes the order in which the increments will be performed26.

Rethought to take into account some other adjustments to the system, e.g. the inclusion of a new piece of framework that provides some functionality that previously was assumed to be custom-built.

25

Naturally, this order can be adjusted. The “Sequencing” section exists in part to make that easier and more convenient to do (than would be possible if the increments defined their own order).

26

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 168

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Transitional Architecture The transition from the current NOMADS Systems to the Nevada IV-D Systems described in the Target Conceptual System Architecture section will take some time, perhaps 10 years or more. The Transition from the current architecture to the future one looks like this in concept:

Figure 17 - Architectural Transition

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 169

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

But that ignores the in-process state of the systems that will be in place for a number of years--until the transition is complete and the last pieces of legacy code can be removed. Until all legacy code is removed, the system will be in a transitional state, which will look like this:

Figure 18 - Transitional State

There are several key aspects about this transitional state that should be noted:

Legacy (EGL) Code Exists Throughout Transition Because it is not feasible to rewrite the entire body of legacy EGL (presently CSP, but a conversion to EGL is expected to be completed very soon) code, the EGL code will remain the basis for a big portion of the transitional system. As depicted in the following enlarged figure:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 170

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Figure 19 – EGL Code Basis through Transition

The existing EGL codebase continues to be responsible for some amount of system functionality, though the amount tends to decrease over time (see (3)—Targeted Rewrites as an Ongoing Activity). As the figure depicts, EGL code is used to generate COBOL code, which is very similar to how the CSP codebase functions today. 3270 screens (“greenscreens”) and batch programs are built in COBOL from the underlying EGL 4th generation language (4GL). In a similar pattern--but using different languages and toolsets (some of which are yet to be developed—there will be one or more increments devoted to developing these tools, it should be noted), Java code and Webbased screens are generated from the same EGL codebase, using a combination of EGL’s native ability to generate Java code, as well as new tools to build basic Web-based "ports" of existing EGL / COBOL screens.

Legacy Access Channel Allows Access to Legacy Components The converted EGL code runs inside of a traditional COBOL environment, and is largely unaware of the improved architecture that it is housed in. It ignores the security, workflow, and presentation layers, and deals with the database unaware of improvements like Master Data Management. Implicit to this, the access path that lets legacy users (screen-scraping code, HATS code, or users using a 3270 terminal program) use the legacy code will bypass the upper layers of the architecture, and will route directly to the legacy code modules. This is necessary because the legacy code—for good or ill—performs all of its own security, presentation, and workflow.

Targeted Rewrites as an Ongoing Activity As the diagram shows, existing EGL code will get rewritten on an opportunistic, as-needed basis. These rewrites will likely be manual ports of an individual module (or set of related modules), and will likely not employ a large-scale automated code-conversion strategy or toolset. Depending on the quality (readability) of the migrated EGL code, it may even be necessary / desirable to use the original CSP code as a reference resource when performing the rewrite. Recommended criteria for selecting legacy code to be rewritten include:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 171

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Functional modification is called for. This is the “opportunistic” element. When existing functionality needs to be updated for functional reasons, it is usually preferable to “invest” in that code module by: ƒ

Rewriting it as a native Java program that fully integrates with the new architecture (fully leveraging the “security” and “workflow" and “presentation” layers, as well as the ESB) rather than running in “legacy” mode

ƒ

Implementing the new functional enhancements on the converted code

Š

Modules are identified as “key” components. Certain modules, such as the Document Generation subsystem or the financials subsystem, are so essential to the overall system that they deserve special consideration. Porting those modules early will allow critical components to be optimized for the new architecture, and for the architecture itself to develop a proper set of services that will provide key assets to the later efforts to port legacy code.

Š

Resources are available to undertake optional rewrites. After a certain point, when most of the "key" modules have already been ported, rewrites may be performed less out of specific need than out of a desire to continue to “work down” the legacy codebase.

Little or No Functional Enhancements on EGL Even though it is possible to update and add functionality to the converted EGL code, this is not the recommended approach. As the previous bullet discusses, there are several triggers that should “select” an existing EGL module for a targeted rewrite. Once selected, this roadmap presumes that the module will be rewritten in the target language (Java) rather than being maintained in-place. This is recommended in order to avoid having to work heavily in automatically-generated code, and also to avoid fracturing the codebase any more than is necessary27.

Infrastructure Considerations During Transition While the efforts to modernize the Nevada IV-D System is underway, it must be acknowledged that the existing infrastructure—including mainframe, network and non-mainframe servers—will be increasing as well.

27 There is already “tool-migrated” code and “hand-rewritten” code. It’s preferable to avoid adding “tool-migrated-and-functionallymodified” code to the mix.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 172

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

These state resources are being stretched to the limits. For example, recently mainframe capacity was increased by 10% to relieve overload, since it had been operating at or near 100% of capacity. As of this writing, the mainframe is again operating at or near 100% of capacity resulting in noticeably degraded user response time. As DWSS struggles to ‘do more with less’, technology solutions are being deployed to make the front line worker more productive. Unless the underlying supporting technology infrastructure is in place to support these efforts, these technology solutions will deliver little in terms of real efficiency improvements. During this transition, the State of Nevada must ensure that network, server, and mainframe resources are robust enough to handle day to day operations, new technology components, and also absorb normal “spikes” in system activity so that front line workers actually get effective solutions—supported by sufficient technology infrastructure and resources—that enable them to more effectively perform their duties. As compared to the cost to run a program such as Welfare, the related infrastructure support costs are relatively small, but the lack of these resources can cripple the Program’s ability to effectively deliver services in a timely fashion.

User Experience During Transition While PSI has been focusing on the technical aspects of the transition period, it must be acknowledged that the extended transition phase will have an impact on system users. Specific elements of this transition that will be visible to system users—to a greater or lesser extent depending on a number of factors—include: Š

Two User Interfaces. While there are plans to do work to mitigate the worst aspects of this issue, users will likely still perceive that they are working in two different "systems" (or two different styles of user interface, if one prefers).

Š

Continuing Need to Log in to Separate Systems. The legacy code handles its own authorization and system access rules, which will most likely make it necessary for users to continue to log in to the "legacy side" of the IV-D Systems separately from the more modern screens.

Š

Noticeable Areas of Workflow "Overlap." It is highly likely that, when working across the two different styles of UI, that it will be impossible to fully optimize workflows that cross the boundaries of the UIs. For example, it may be necessary to "set up" an action in legacy screens, then go into newer-style screens in order to complete the activity, with some redundancy in the information the user sees being unavoidable.

Some mitigation of these effects may be possible. For example, there are specific modernization increments (Prototype Web-Based Screen Conversion and Full Web-Based Screen Conversion) described below that are intended to partially address the "dual user interface" issue by converting existing NOMADS mainframe screens into Web-based (functional) equivalents. This may offer an avenue for "smoothing over" the worst aspects of that issue, while not completely solving it. It should be understood that these two increments are, strictly from the system modernization standpoint, optional. This is to say, they do not lie on the critical path to a modernized IV-D system. Instead, they go directly to helping ease the transition during the extended “transitional” phase. DWSS may reasonably make NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 173

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

the choice to remove these increments from the plan, which will most likely reduce costs and the overall timeline somewhat, but at the cost of some additional burden on users during the transition. Because of the age and technology behind the existing NOMADS system, the user experience can only be fully addressed by rewriting most or all of the legacy code, which is, of course, not an option in the short term, but is what is accomplished by the entire Modernization Roadmap.

Modernization Approach Throughout this assessment effort, an incremental approach to modernizing the existing systems has been the desired goal. This incremental approach is at work during the development and ordering of the modernization increments, particularly the early ones. There are four general phases to the modernization effort: Š

Risk Management

Š

Foundational

Š

Functional

Š

Clean-Up

These are not literal phases and some overlap should be expected. They do describe a general prioritization scheme that will help define the proper sequencing of individual increments. As the Modernization Roadmap is being executed, all planning and sequencing of increments will flow through these four elemental phases.

Risk Management The risk management phase overlaps substantially with the activities in the Maintenance Plan, as mitigating risk is a key outcome that is designed into the Maintenance Plan. Specific examples include: Š

Completing a migration from CSP to EGL. This is necessary to minimize risk from running the NOMADS system on a wholly unsupported language, CSP.

Š

Preserving institutional knowledge, arresting “brain drain.” Back-filling documentation of the existing system and improving cross-training among the development staff will help mitigate risk from staff attrition.

Š

Improving testing toolsets & database assets. Deployments always carry operational risk, but testing tools, processes, and database assets can help mitigate such risk.

Foundational In the foundational phase of modernization, key elements of the modernized IV-D System will be developed and deployed, creating assets that will be leveraged across the remainder of the modernization effort (as well as the remainder of the system’s operational life).

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 174

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

For example, increments that develop and prove out key elements of the system’s modernized architecture should be performed as soon as possible (after risk management is largely covered). These will include architectural / infrastructural increments such as: Š

Prototype and Implement a Web-Based front-end to existing NOMADS screens.

Š

Implement SOA components: ƒ

Presentation

ƒ

Data-Access

ƒ

Business-Process Hosting

Š

Implement an Enterprise Service Bus (ESB).

Š

Implement a Workflow Management Layer.

Š

Identify and implement a standardized document generation component.

Š

Implement a Master Data Management Strategy.

These increments, and others of a similarly foundational nature, should be developed early in order to ensure they are available to later development efforts, so that those later efforts can leverage the foundational assets, and to ensure that a the modernized system has a consistent and sound architecture. This is not to say that all functional progress must stop while year’s worth of foundational work is undertaken. Each foundational increment should seek to implement—to the greatest extent practical—a reusable foundational component (e.g., a document generation component, an ESB, a workflow engine) as well as a reference implementation that demonstrates the component and delivers functional benefit to system users.

Functional The third phase will include primarily functional additions to the modernized IV-D System, as the remaining legacy code is migrated to the new architecture. The increments in this phase will have the opportunity to leverage a more complete set of infrastructural components (ESBs, workflow engine, document generation components, etc.), as well as to benefit from DWSS’ greater familiarity, comfort, and expertise applying those components to IV-D business challenges. Examples of increments in this phase include: Š

Financials—Distribution

Š

Enforcement—Payment Monitoring

Š

Enforcement—Wage Withholding

Š

Enforcement—Administrative

Š

Enforcement—Judicial

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 175

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Case Initiation—Intake

Š

Reporting / BI / remaining management reporting functions

Clean Up In the final phase the last remnants of the legacy system can be removed and any scaffolding and infrastructure specific to supporting legacy code can (and should) be removed. Specific elements that should be addressed in this phase will include: Š

Remove the “Legacy Access” channel (specifically, removing support for accessing 3270 screens).

Š

Remove EGL (EGL Æ COBOL & EGL Æ Java) code conversion support.

Š

Remove COBOL runtime support from mainframe.

Š

Remove tools and utilities specific to the COBOL / EGL environment, including any batchmanagement facilities that deal specifically with mainframe batch.

Š

Decommission RACF security database & support.

At the point this phase is fully complete the Nevada IV-D System will have fully realized its modernized state.

Approaches to Sequencing The general grouping and sequence laid out above should not be regarded as the only way to proceed. Numerous variations are possible, depending on the goals that DWSS chooses to prioritize during the execution. The main approaches that should be compared and contrasted are as follows Š

Sequential. This is the “default” approach—the one that results from proceeding generally front to back through the phases, from Risk Mitigation through Clean Up. This approach, which is the one used to build the sequence presented later in this document, is the simplest approach, in that it manages the dependencies in the most straightforward manner. It does not optimize early delivery of usable functionality upgrades to the user community, but instead front-loads essentially all of the framework and infrastructure development, and only then moves on to delivering functionality to users.

Š

Iterative. This alternate approach prioritizes earlier delivery of functionality over simplicity. To accomplish this, early technical increments should be planned so that they deliver only the minimum framework and infrastructure needed to begin delivering user functionality, potentially leaving significant pieces of infrastructure to be “picked up” in later iterations. For example, a DocGen technical increment might be planned entirely around building the batch document generation capabilities, and then immediately followed by functional increments that require only batch documents. By doing this, the critical path to delivering user functionality can usually be reduced and users can start to benefit from system upgrades earlier.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 176

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

There will also be choices that DWSS will need to make with regard to how to handle legacy modules after they have been fully redeveloped in the new architecture. There are two typical approaches that organizations take to this, each approach has pros and cons: Š

Approach 1: “Don’t Look Back.” In this approach, the legacy version of any given screen or module is decommissioned immediately after it has been successfully redeveloped in the new architecture. This is usually the more cost-effective approach (since there is no need to maintain the legacy screen / module), but it sacrifices some safety and flexibility. Safety is sacrificed because there is no ability to fall-back to the old code if the new code is found to have fundamental defects. Flexibility is sacrificed in that there is no option to have certain groups of users continue to use the old system (old screens) during the transition, and only convert to the new interface at the very end28–all users will be forced to move into the twointerfaces mode of operating.

Š

Approach 2: “Side-by-Side.” In this approach, the legacy modules are left in service, and “brought along” to a certain extent, so that they remain compatible with the new system29. This offers the safety and flexibility spoken in the previous bullet, but will require more effort.

The preferred approach should be decided early in the modernization process, since it affects detailed estimating, design and analysis, and project task-level planning.

Batch Module Conversion A final point to consider is how (and whether) to deal with batch modules during the transition. This is worth consideration because batch can often be deferred, conversion-wise, for some period of time. This is because batch, being “invisible” to users, often is not a “sore spot” in the system30—many users find themselves satisfied or indifferent to the batch functionality, but quite vehement about the online elements of the system.

28 This is a choice some multi-year implementations make. Smaller counties in particular sometimes prefer the option of staying on the old screens if they are given the option, because the two-interface burden is just too high for them. Larger counties usually find the functional upgrades compelling enough to want to move to the new modules as soon as each piece of the new system is ready for use. 29 Obviously making them implement everything the new system offers is not likely. But there is often the need to do some updating of the legacy modules to make sure they write records to the database in a way the new system can understand them, for example. Or making sure they clearly stamp records as having been built in “legacy” mode so they can be secondarily processed in a particular way once they hit the new system.

Except—obviously—to the extent it implements the expected functionality incorrectly; some level of functional adjustments to batch modules should be expected, but the point is, it could fall well below the threshold of a full-on rewrite of all batch modules, and if so, might allow the effort to be deferred for some period of time.

30

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 177

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Of course, rewriting the batch modules will be on the critical path to decommissioning the EGL / COBOL environment, so it is probably not an option to never deal with batch. But properly regarding batch in terms of its priority and impact on users would potentially create additional flexibility for DWSS in terms of how it lays out the redevelopment work over time.

Code Redevelopment This section will cover several topics relating to the actual redevelopment of code during the modernization effort. Specific topics include: Š

Potential up-front effort to account for

Š

Goals to be optimized during foundational (technical framework) increments

Š

Waterfall versus iterative approaches to foundational increments

Š

Functional upgrades during redevelopment

Potential Up-Front Effort to account for The increments described in the Modernization Increments section that follows focus on describing the technical and functional development steps that provide a stepwise path to fully modernizing Nevada’s current IV-D system. And while this does represent the most straightforward path to a modernized IV-D system, there is some potential that some directed up-front effort in some specific areas would be time well-spent by DWSS. Specific activities that DWSS might consider “pulling forward” into an up-front and dedicated effort include: Š

Architecture

Š

Business Process Reengineering

Common to these activities is that, while they can be done inline with specific improvement increments31, there is potential additional benefit to pulling them forward and undertaking them with a more whole-project view.

Architecture While the main elements of the Nevada IV-D System architecture have been identified and documented in this document’s Target Conceptual System Architecture section, that level of definition is not enough to put the TCSA into operation. More detailed and concrete design and architecture will ultimately need to be performed, whether up-front or inline within the specific increments. Much of this work will go to defining implementation details such as standard API conventions, standards and protocols (e.g., simple XML or

31 Particularly on a redevelopment project like the NV IV-D System. So-called “greenfield” (new development) projects have no option but to put major design phases up front.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 178

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

require a document type definition (DTD) Element-normal style or attribute-normal?), and project/team environment standards such as naming standards, documentation standards, and engineering practices. While many of these can reasonably be left to be done in the individual increments, the practical effects of doing so are as follows: Š

The early increments will take more of the load. Because standards and conventions tend to come up the first time you need to put them into practice (that is, the first time you need them), the first 2-3 increments will probably take the brunt of the “hit” from these activities, and so will have to be understood as needing a little extra time and effort to account for the work.

Š

It will take more discipline to tie the threads together. Addressing such standards and conventions inline, it is possible for the team(s) to fail to realize that they are, in fact, setting standards, which might lead to the standards not receiving the proper amount of documentation and advertising across the team(s). This can be exacerbated if there is not one consistent team but a team of more-fluid makeup.

Business Process Reengineering In a similar vein, but more focused on the functional side of the world, is the concept of Business Process Reengineering (BPR). With BPR, business processes and practices are analyzed with an eye towards identifying whether they are the right way of performing the work—often improvements can be made. In any enterprise, and no less so in one like DWSS, many processes are put in place and never rethought again for years, even though many of the assumptions under those processes undergo radical change over time. Processes that were designed for a paper-and-phone-call environment continue to be used—effectively just as they were designed—well into an electronic-imaging-and-workflow environment. Examples include decisions such as whether or where a document is printed, who performs the final inspection and quality assurance (QA) of the documents contents, and whether to input data or go and retrieve it from a database. This is, of course, both good and bad. Organizations cannot do any work if they are constantly rethinking every decision they have ever made; decisions must be made and “stuck with” to give the organization the time to focus on just doing the work. But it’s also true that certain events should trigger the rethinking of some fundamental business process decisions. The redevelopment of a major software system should definitely be one of those triggers. The benefits of pulling the BPR effort up front would be that it would allow such decisions to be made ‘in the large’ (rather than ‘in the small’). Specific processes could be rethought ahead of the need to perform the redevelopment work, which will give the team more time to make the adjustments necessary to enable optimizations (e.g., develop a centralized image repository and “back convert” paper documents so there can be a comprehensive “virtual” case file). In both the architecture and BPR case, the execution of a decision to pull the effort forward would be to construct a predecessor increment to implement each effort (that is, one for architecture, one for BPR). The results of the up-front effort would then be used to feed into the later increments, the architecture effort providing later increments standards, conventions, and more detail on the IV-D System architecture, and the

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 179

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

BPR effort providing specific process maps that would be fed into the requirements that inform the designs of the later functional increments.

Functional Goals to be Optimized During Foundational Increments The Modernization Approach section presented earlier identifies several example “foundational” increments— projects intended to deliver key pieces of the Nevada IV-D System architecture. Because of the technical / framework nature of these increments, it would be possible to conceive of and execute them as “purely” technical—that is they deliver the intended framework and nothing more. More to the point, they might deliver no functionality that any user would ever see. A preferable approach would be to conceive of such increments as always including at least one piece of functionality to demonstrate the technical component in both technical and functional terms (its “demonstration use-case”). For example, a Document Generation increment might include one or more actual document templates (instead of just the framework that allows documents to be generated). The benefits of this are several: Š

Users and program management will perceive functional progress sooner.

Š

Such an approach will tend to strengthen the foundational increment by providing it a concrete goal (e.g., producing a specific document) and “road testing” the framework components as soon as they are developed.

Š

In some circumstances, functionality can be delivered to field users sooner.

Š

The requirements for the foundational increments will be grounded in real-world use-cases rather than theoretical ones.

The best choice for identifying a foundation increment’s demonstration use-case would be real-world functionality that can be immediately deployed and put into production. This will not always be practical, especially during the first 12-18 months, because of other technical and business dependencies that might prevent the deployment of any “new style” functionality. If immediately-deployable functionality cannot be identified, then the second-best choice would be real-world functionality that, even though it cannot be deployed, could still be developed and used largely or wholly in a testing or “model office” kind of setting. Finally, if no real-world functionality can be identified and used as a foundational increment’s demonstration use-case, then a small prototype that models real-world use as closely as possible should be identified and used. This would obviously never be deployed to users, but would still go towards strengthening the foundational increment’s requirements and demonstrating that it is working as intended.

Waterfall Versus Iterative Approaches to Foundational Increments The foundational increments that have been discussed are key pieces of the Nevada IV-D system. As such, a natural tendency would be to try to develop each to be as fully-capable as possible, and to encompass every requirement and use-case that could be imagined, then to design, develop, test and implement all of these requirements in turn. For example, a Document Generation increment might encounter requirements to

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 180

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

generate documents in bulk, interactively with the worker, into multiple formats (HTML, PDF, Word doc, etc.), and to feed electronic documents into a workflow or an email delivery mechanism. This is the “waterfall” approach, and, while valid, using it would could delay the delivery of the foundational increment through an attempt to “bulk up” its requirements so they are intentionally comprehensive and then doing the design development and testing based on this comprehensive requirements set. With this approach, no part of the foundational increment could be put into production until the entire increment is complete, unnecessarily delaying real-world testing. PSI recommends the “iterative” approach as a better alternative. An iterative approach seeks to optimize early use of the component over comprehensiveness of implementation in order to get the foundational increment delivered sooner, and, by extension, the first piece of user functionality that depends on it. For example, if a Document Generation component were being designed, DWSS should seek to identify whether there is a near-term need for any of the requirements enumerated earlier (bulk documents, interactive documents, multiple formats, electronic delivery, etc.). As likely as not, only a subset will be required to deliver real functionality to the field. For example, it could turn out that an upcoming functional increment includes no interactive documents, only one output format, and no electronic delivery. In this circumstance, all of those requirements can be ignored, at least temporarily, and the increment can remain focused on delivering a capable set of functionality for bulk document generation. Obviously this leaves some functionality undone, and that functionality will have to be picked up during some later iteration (thus the label “iterative approach”). This should be dealt with by breaking a foundational increment into smaller, functionality-subset-focused increments that can be more flexibly interleaved with functional increments, enabling the execution of the functional increments to be moved earlier in the project timeline.

Functional Enhancements During Redevelopment When this document discusses the “redevelopment” of existing modules into the new architecture, it’s not a particularly precise term. One might ask, What is included in redevelopment? Will the functionality be effectively the same in the new system, only “dressed-up” better and undergirded by a more robust system framework? Of course the answer to this relies ultimately on a choice that DWSS must make. If it is more important to DWSS to move to the new architecture quickly, then doing few or no functional improvements and instead focusing on reimplementing the existing functionality in the new framework would be the preferred approach. Alternately, if what should be optimized is the delivery of new features and capabilities to users as quickly as is practical, then folding functional improvements into the redevelopment work would likely be the preferred approach. This plan, and, more specifically, the estimates within the modernization increments described below (in the section Modernization Increments), were developed under the latter assumption: that time-to-completion is less important overall than delivering functional improvements to users as quickly as is practical. This is driven largely by the results of the needs assessment and gap analysis performed previously—there are many gaps in the current systems, and a key goal of the modernization effort is to fill as many of those gaps as is practical.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 181

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Each increment presented below has a ROM estimate associated with it (see the beginning of the Modernization Increments section for a description of ROMs). While these estimates do not explicitly identify a “porting” component as separate from a “functional enhancement” component, each should be understood to include effort-hours for both. In some sense, the number and magnitude of enhancements that can be entertained within any functional increment (and still stay within the estimated development effort) depends on 1) how much effort is required to complete the mechanical “porting” work (the work needed just to implement the same functionality in the new architecture as the legacy system had); and 2) how good the estimates were to begin with. This is because the mechanical porting work must be completed in order for the new system to meet its requirements—doing so, represents the base functionality needed to perform Child Support enforcement in Nevada. Once that work is done, the amount “left over” can be used for functionality enhancements and upgrades. An additional but self evident factor is how close to the ideal functionality already exists or will be introduced during the maintenance focus period before work on the increment is undertaken. PSI estimates that between 20-35% of each ROM estimate presented for the functional increments discussed below will ultimately be available to implement the functional upgrades DWSS chooses to undertake.

Modernization Increments This section presents a roughly-ordered set of increments, which can be thought of as individual projects that advance the state of NOMADS and its ancillary systems towards the end-goal of a fully-modernized Nevada IV-D system. The specific ordering presented in this section should not be regarded as authoritative. The final subsection within this section, Increment Sequencing and Timeline, presents a more reliable sequencing of increments, as well as some arranging of increments into logical groupings like “SOA,” “Establishment,” “Enforcement,” etc. This section begins by discussing the approach PSI took in developing its estimates of the effort / cost needed to fully modernize the Nevada IV-D system.

Estimating Methodology In order to develop implementation effort estimates for the Nevada IV-D system modernization effort, PSI followed a basic set of steps: Š

Develop a series of discrete project descriptions (“Increments”) based on the TCSA, the gaps described in the Gap Analysis, and the current state of the system.

Š

Estimate the level of effort and cost to develop and implement each of the increments using the best data available and PSI’s extensive experience working on Child Support system development projects

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 182

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Validate and strengthen the estimates using high-level information from other states, as well as PSI’s experience in other state modernization efforts

The estimates PSI developed are ROM estimates. ROMs are deliberately imprecise, as is appropriate for the planning phase of a project such as the Modernization Roadmap32. ROMs are given as specific figures (e.g., 2.5 person-years); they also incorporate a built-in range of imprecision, in this case from -50% to +100%. This means that a ROM of 2 person-years really can be regarded as a ranging from 1 person-year on the low end to 4 person-years on the high end. PSI used a bottom-up / top-down approach to estimating, where estimates are developed both from the bottom-up perspective (looking at the details of any given increment and estimating the effort required to implement the described functionality) and the top-down perspective (where a total-dollars figure from a comparable effort is allocated into specific increments to estimate effort for those increments), and then reconciled with one another to develop a final estimate. As input into the bottom-up estimating exercise, PSI used NOMADS Task Guides as the best-available description of the current system’s functionality. These were the best resource to use since the following were not available: Š

A comprehensive set of technical documentation

Š

Detailed information about the existing codebase (accurate module counts, lines-of-code figures, and reliable mapping of code modules to functional areas and/or function statements)

The general process that PSI followed to develop the effort estimates presented in the remainder of this section are outlined below. Each of these major steps is then described in the subsections that follow. Š

Identify the functional area breakdown.

Š

Develop bottom-up estimates: ƒ

Analyze the NOMADS IV-D system Task Guides.

ƒ

Independently estimate the technical increments using the bottom-up perspective.

ƒ

Establish the value of a NOMADS point in hours.

32 Estimates typically get refined as more information becomes available. During a classic “waterfall” project estimates are typically refined after detailed requirements gathering / validation, and again after a technical approach is identified. PSI will discuss this topic more in the section Modernization Plan Maintenance.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 183

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

ƒ

Calculate estimates of increment hours.

Š

Cross-check the NOMADS-points-derived estimates against a recent comparable systemsdevelopment estimate (Commonwealth of Massachusetts), adjusting outliers as necessary to produce increment-by-increment effort estimates.

Š

Convert to ROM estimates.

Finally, while the arrangement of projects is presented as a starting point, it should be expected that refactoring of increments (breaking increments down into smaller projects and/or building larger increments from smaller ones) will be common in practice during the modernization effort execution. It will also be common practice to revise cost estimates 1) with better-informed figures that come out of development that has already been completed; 2) based on information gathered from better experience with the toolsets; or 3) using information from other areas that has become available to DWSS. These topics are discussed more in the document section Modernization Roadmap Maintenance, which discusses the ongoing maintenance process that exists for the duration of the modernization effort.

Identify the Functional Area Breakdown For the purposes of estimating, PSI identified the following functional divisions of typical Child Support system functionality Table 29: Child Support System Functional Divisions Functional Area

Functional Group

Financials—Billing and Collections

Financial

Financials—Distribution

Financial

Financials—Disbursements

Financial

Financials—Reconciliation

Financial

Financials—Adjustments

Financial

Enforcement—Payment Monitoring

Enforcement

Enforcement—Wage Withholding

Enforcement

Enforcement—Administrative

Enforcement

Enforcement—Judicial

Enforcement

Case Initiation—Intake

Case Initiation

Case Initiation—Assessment/Order Entry

Case Initiation

Locate—Address/Employer Verifications

Locate

Locate—Research

Locate

Review and Adjustment

Establishment

Establishment—Paternity

Establishment

Establishment—Stipulations

Establishment

Establishment—Court Preparation

Establishment

Case Management—Case Assignments

Case Management

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 184

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Functional Area

Functional Group

Case Management—Case Closure

Case Management

Customer Service—Customer Inquiries

Customer Service

Customer Service—Customer Self-Service

Customer Service

Customer Service—Employers

Customer Service

Interstate

Interface

All non-technical work was allocated into one of these functional areas during the analysis and estimating exercise.

Develop Bottom-Up Estimates The Modernization Roadmap includes 41 distinct increments: 23 of which are functional in nature, and 18 of which are technical. To develop bottom-up estimates, PSI took different approaches for the functional and technical increments. Functional work was estimated by analyzing the NOMADS Task Guides, using those documents to estimate the complexity of those parts of the system, which then was converted to hours estimates. Technical estimates were driven off of the work descriptions themselves, as the work descriptions were more complete and there are no task guides to use in any event. Technical estimates were created as hours directly rather than using NOMADS Points. The following sections give more detail on those parts of the process.

Analyze NOMADS IV-D System Task Guides in Bottom-Up Fashion In order to establish the relative size of all of the major Child Support functional areas (e.g., “Case Initiation,” “Enforcement,” “Locate,” etc.) as represented in the current NOMADS-system implementation, PSI analyzed the entire set of Task Guides that DWSS maintains on the current system. The basic premise was to use a variation of the “screen points” methodology (where every field or control on a screen is itemized and used as a proxy for implementation effort) that was based on a) the existing NOMADS screens; and b) the supporting verbiage in the Task Guides. Specifically, PSI established counts of the following items that were present in the task guides: Š

Number of forms

Š

Number of reports

Š

Number of pop-up forms

Š

Number of steps and sub-steps

Š

Complexity

A weighting formula converts these metrics into “NOMADS Points,” which are intended to describe, at least in relative-to-one-another terms, the complexity of each of the functional areas. The analysis described above produced a “Raw” NOMADS Points estimate for each of the 23 functional areas. PSI then took these raw points and applied expert judgment to make adjustments either upwards or downwards to account for factors that are not present in the task guide descriptions. For example, PSI’s NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 185

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

experience in other systems tells us that certain functional areas are poorly represented in system screens, and so the points should be adjusted upwards to account for this. Conversely, some areas may require more training-guide explanation, but still be relatively straightforward to implement. PSI manually adjusted the Raw NOMADS Points to compensate for this, producing a more-normalized set of NOMADS Points. The direction of the adjustment (up, down, or neutral) is shown in the “Adjustment” column, and the rationale for any adjustment is shown in the “Adjustment Rationale” column. This yielded the following set of NOMADS Points: Table 30: NOMADS Complexity Points by Functional Divisions Functional Area

Adjustment (▼,▲, -)

NOMADS Points

Adjustment Rationale

Case Initiation—Intake



3,441

Often the first to be presented in training sessions, these task guides cover more ground than others to establish a base of knowledge. Development is much more one-to-one on business statement to program logic, thus, voluminous but simpler coding.

Case Initiation—Assessment/Order Entry



2,302

(same rationale as above)

Case Management—Case Assignments



751

Task guides can't show the complexity in coding and management overhead in not allowing gaps or overlaps required to assign/reassign cases and the performance restrictions and breadth of conditions under which they operate.

Case Management—Case Closure



1,842

The visible portion of case closure discussed in task guides does not fully represent the extensive logic in case selection or impact of closure across the case's footprint in the database and workflows.

Customer Service—Customer Inquiries



605

Task guides cover human decisions in more detail but the system logic is fairly simplistic concentrating into select and display with little database update (and, thus, isolated impact).

Customer Service—Customer SelfService



406

Modernization is the opportunity to greatly expand self-service capabilities impossible to have before.

Customer Service—Employers



246

EWS completion maintenance task picks up a lot of this and thus estimate reduced to avoid the duplication.

Enforcement—Payment Monitoring



467

Workflow and rules engine are game changers on how this is done. The task guide cannot reflect the extensive logic changes.

Enforcement—Wage Withholding

-

496

Enforcement—Administrative

-

2,590

Enforcement—Judicial



1,179

Coordinating form design with judicial stakeholders is more time consuming than a normal function point.

Review and Adjustment



351

Workflow is a game changer and it has to have sophisticated logic to throttle the volume released for worker review.

Establishment—Paternity

-

1332

Establishment—Stipulations

-

500

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 186

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Functional Area

Adjustment (▼,▲, -)

NOMADS Points

Adjustment Rationale

Establishment—Court Preparation



1,652

Workflow and forms design with judicial and process service staff are more complicated than normal functions.

Financials—Billing and Collections



653

Task guides fail to properly account for the batch logic. Plus since billing is turned off currently, it may be lightly covered in current documentation.

Financials—Distribution

N/A

3000

No task guide for this pure batch function means the estimate is relying on the top down estimate. Complicated logic totally redone with the use of rule engine means complicated and extensive testing.

Financials—Disbursements



1,691

Task Guides don't account for batch logic required. Also tighter controls with heavier testing required than normal.

Financials—Reconciliation

N/A

1000

No task guide for this pure batch function means the estimate is relying on the top down estimate.

Financials—Adjustments



243

Adjusted for “batch heaviness”

Locate—Research

-

1,486

Interstate

-

2,120

Locate—Address/Employer Verifications



1,448

Total Available NOMADS Points

Address hierarchy and false positives logic makes this more complicated than what the task guide can show.

29,802

Independently Estimate the Technical Increments in Bottom-Up Fashion Two of PSI’s technology experts—both with substantial experience in Child Support and legacy-systems development and modernization—independently estimated the hours effort for each of the 18 technical increments. Their independent estimates were then discussed with the entire project team of subject matter experts and reconciled into a single estimate for each increment. This yielded the following set of estimates: Table 31: Estimate of Hours for Technical Increments Increment

Hours Estimate

Migrate CSP Code to EGL

14,560

Implement a Workflow Engine

25,740

IV-D Framework—Alerts Management

12,168

Develop a Unified IV-D System Database

8,112

Implement a Data Mart / Data Warehouse

18,252

IV-D Framework—Document Generation

24,336

Prototype Web-Based Screen Conversion

6,084

Full Web-Based Screen Conversion

8,112

Develop a Presentation Layer

8,112

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 187

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Implement True Portal Environment

8,112

Implement an Enterprise Service Bus (ESB)

8,112

Develop a Unified Security Layer

16,224

Develop a Federated User Repository

2,028

Implement Business Rules Engine (BRE)

16,224

Implement a Business Process Hosting Layer

8,112

Develop a Data Access Layer

8,112

Develop a Batch Processing Facility

10,140

Implement Master Data Management

8,112

Total

210,652

Establish the Value of a NOMADS Point in Hours NOMADS Points are a proxy for functional complexity, but do not directly represent hours. In order to define the value of a NOMADS Point, PSI followed these steps: Š

Establish a “typical” budget for a Child Support systems modernization project of between $60M and $70M, and roughly 800,000 hours.

Š

Factor out what is dissimilar (i.e., platform-specific or state-specific) to identify the strictlyfunctional work as hours.

Š

Treat the hours allocation for strictly-functional work as a constant and divide the strictlyfunctional hours by the total calculated NOMADS Points to identify the conversion of NOMADS Points to hours.

Calculate Increment Hours Estimates The remaining calculation was simple, a straight division of the strictly-functional hours (~550,000 hrs) by the total number of NOMADS Points available (29,802), yielding an hours-per-point figure of 17.75.

Cross-Check the NOMADS-Points-Derived Estimates Against Comparables Finally, PSI identified the amount of effort (excepting pure-technical work) in our comparable effort (Massachusetts COMETS Modernization Roadmap) for the same category of functional work. To do this, the increments were grouped into 15 categories for comparison against similar work categories from the comparable state. Nevada estimates were compared to the comparable state’s project estimates for the same category. Significant differences were discussed and either justified as an explainable difference, or in some cases were adjusted to bring them more in line with the comparable state’s estimate. By and large the numbers were in the same range and relatively few adjustments were made.

Convert to ROMS The final step was to convert the figures to ROM estimates by rounding them to the nearest half-person-year (1040 hours).

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 188

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

This yielded the hours estimates that are presented in the Increment subsections that follow this section.

How to Regard the ROM Estimates ROM estimates, as mentioned earlier, should be understood as representing a range of figures from -50% to +100% of the provided ROM figure. Thus a ROM of 2 person-years could also be understood as a range from 1 person-year to 4 person-years. It is also important to point out that the estimates provided are intended to cover all required project tasks and activities including: Š

Requirements validation and refinement

Š

Analysis and design

Š

Architecture/framework creation & elaboration

Š

Development (both porting and new development)

Š

Documentation

Š

Testing

Š

Project management

Š

Functional enhancements

Regarding the last item, functional enhancements, it should be obvious that not every possible functional upgrade could have been anticipated in any estimate. The rule-of-thumb that should be used is that 20-35% of any given estimate might be available for functional upgrades. This should offer a sufficient allocation of hours to deal with the gaps that have been identified in the Gap Analysis section of this document, as well as a reasonable amount of BPR and/or desirable functional enhancements.

Increment Abstracts Below are brief abstracts for the increments that make up the Modernization Roadmap. More detailed descriptions, risks, dependencies and ROM estimates of the hours and cost for each increment can be found in Appendix M.

Increment: CSP to EGL Code Migration Migrate current (unsupported by any vendor) CSP code to a supported language, EGL. This increment delivers a migrated codebase using EGL as the primary implementation language rather than outdated CSP.

Increment: Develop a Unified IV-D System Database Removes the current system’s distributed database setup, and consolidates on a single database platform. This increment delivers a single, unified database based on DB2 on z/OS.

Increment: Prototype Web-Based Screen Conversion Develop methods and tools that let the existing NOMADS screens be accessed via a Web interface. This increment delivers tools, a process, and a proof-of-concept implementation.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 189

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Increment: Full Web-Based Screen Conversion Fully converts existing mainframe screens to Web-enabled equivalents, allowing users to access the system using a consistent user interface during the extended transition period. This increment delivers a Web-based user interface to the IV-D user community.

Increment: Develop a Data Access Layer A Data Access layer handles all typical Create, Read, Update, Delete (CRUD) functions as well as potentially providing hook-points for implementing a Master Data Management (MDM) strategy. This increment delivers a data access layer as well as guidelines / protocols for deploying new data access modules into the layer.

Increment: Develop a Business Process Hosting Layer Necessary to allow the refactoring of existing NOMADS code into code modules that focus solely on business process while letting other modules control presentation, security access, data access, and other key system concerns. This increment delivers a new system layer that is focused on hosting business process code, as well as general guidelines / protocols as to what kind of code can / should be located there.

Increment: Develop a Presentation Layer A presentation layer creates a mechanism for presenting the system interface to users of the system through specific channels, including the Web channel, Portal channel, and the System Interface channel, each offering different presentation styles and accommodating different groups of system “users.”

Increment: Implement an Enterprise Service Bus (ESB) Essential for flow of information between layers as well as external systems, this increment delivers a basic facility for moving data among the system layers and into and out of external partner systems.

Increment: Implement a Batch Processing Facility The Nevada IV-D System needs a new facility for running batch jobs (daily, weekly, and monthly system modules that perform specific functions like generate checks or IRS offset requests) that is positioned to assume all the responsibilities of the current CSP-based batch processing facility. This increment delivers a batch processing facility that is capable of running scheduled system jobs, splitting work up among multiple servers, logging activity, and restarting failed jobs.

Increment: Implement a Business Rules Engine (BRE) A BRE helps solve intricate problems that must evaluate large numbers of variables such as financial distribution, determining enforcement remedies, and others. This increment delivers a facility for developing and deploying rules-based algorithms using ILOG JRules or a similar product.

Increment: Implement a Workflow Engine Necessary to implement workflows that are revisable and reconfigurable rather than hard-wired into the system and/or entirely implicit and “up to the user” to implement, this increment delivers a facility for developing and deploying workflows into the system that will then be executed by a workflow “engine” product, such as IBM WebSphere or IBM Process Server.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 190

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Increment: Develop a Unified Security Layer Necessary to better comply with IRS 1075 security requirements and other controlling security standards, this increment delivers an improved architecture for enforcing and tracking user activity related to sensitive data such as federal tax information (FTI) and personally-identifiable information (SSNs, income).

Increment: Implement a Data Mart / Data Warehouse This increment implements a data mart and/or data warehouse where analysis and business intelligence tools and techniques can be used to extract decision-making and management information from the system’s transactional data. It delivers a[n upgraded] data mart/data warehouse that supports data mining and business intelligence tools and ad-hoc queries.

Increment: Implement a Federated User Repository This increment creates a facility for managing system access by outside agencies through a “federated” model rather than having to directly manage hundreds or thousands of external-agency users. It delivers an implementation of a federated user repository and a protocol for delegating management of subgroups of users to an external partner agency, such as a Child Support agency in another state.

Increment: Implement True Portal Environment A “true” portal environment allows users to access screens where they can recompose their pages to suit their job functions, hiding tools they don’t need and adding tools they use more frequently. This increment delivers a portal component that can be used to host portal objects (“portlets”), as well as guidelines / protocols for developing and deploying portlets into the portal.

Increment: Master Data Management This increment delivers database structures and tools that function as an authoritative single-source-of-truth clearinghouse of key conceptual data artifacts such as “case,” “person,” “employer,” etc. These first-class data types are treated specially because they are widely shared across agencies and inappropriate changes to them tend to result in negative side-effects, warranting extra protection.

Increment: IV-D Framework—Alerts Management Alerts—system generated notifications of events that happen / need to happen on a case—are a key subsystem in every CSE system and require specific accommodations in the architecture. This increment delivers a standardized facility for creating alerts, expiring them, managing them, and allowing workers to perform the work required to satisfy the alert.

Increment: IV-D Framework—Document Generation Child Support systems generate numerous notices and legal documents in the course of processing Child Support cases. This increment delivers a facility for generating electronic notices (that can be printed with proper formatting) that incorporate case details and that is incorporated into the Child Support processing workflow.

Increment: Financials—Billing and Collections This increment delivers functionality within the financial subsystem that supports billing noncustodial parents for owed Child Support and collecting on unpaid support.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 191

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Increment: Financials—Distribution This increment delivers functionality within the financials subsystem that supports distributing monies received from NCPs according to NV CSE distribution rules and logic.

Increment: Financials—Disbursements This increment delivers functionality within the financials subsystem that supports disbursing monies (via Electronic Funds Transfer, physical checks, other means) to custodial parents (CPs) and other parties.

Increment: Financials—Reconciliation This increment delivers functionality within the financials subsystem that supports reconciling monies received with monies disbursed, and for balancing accounts and demonstrating where money was received and disbursed.

Increment: Financials—Adjustments This increment delivers functionality within the financials subsystem that supports making adjustments to accounts to facilitate the balancing of accounts and the application of appropriate funds-handling practices.

Increment: Enforcement—Payment Monitoring This increment delivers functionality within the enforcement subsystem that supports monitoring cases for compliance with ordered payment terms.

Increment: Enforcement-Wage Withholding This increment delivers functionality within the enforcement subsystem for setting up and managing wagewithholding orders with employers (who are responsible for paying 70% of all ordered Child Support nationwide).

Increment: Enforcement—Administrative This increment delivers functionality within the enforcement subsystem for invoking specific remedies, such as Financial Institution Data Match (FIDM), and IRS Tax Offsets.

Increment: Enforcement—Judicial This increment delivers functionality within the enforcement subsystem for invoking specific enforcement actions, such as a judicial Order to Show Cause.

Increment: Case Initiation—Intake This increment delivers functionality within the case initiation subsystem for accepting referrals from IV-A, and processing client applications.

Increment: Establishment-Assessment and Order Entry This increment delivers functionality within the case initiation subsystem for assessing referrals and applications, and for entering Child Support enforcement orders.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 192

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Increment: Locate—Address/Employer Verifications This increment delivers functionality within the locate subsystem for initiating and receiving responses from employers verifying (or denying) employment status.

Increment: Locate-Research This increment delivers functionality within the locate subsystem for performing research using a variety of locate tools, such as skip-trace databases.

Increment: Review and Adjustment This increment delivers a federally-required review-and-adjustment subsystem that ensures each case is reviewed and considered for order modification on a regular, policy-driven schedule.

Increment: Establishment: Paternity This increment delivers functionality within the establishment subsystem that manages the process of proving or disproving the paternity of covered children.

Increment: Establishment: Stipulations This increment delivers functionality within the establishment subsystem that manages the process of documented stipulated paternity and/or responsibility for support.

Increment: Establishment: Court Preparation This increment delivers functionality within the establishment subsystem that manages the process of preparing documentation and information for use in court proceedings that establish paternity and/or responsibility for support.

Increment: Case Management: Case Assignments This increment delivers functionality within the case management subsystem for establishing and managing assignments of cases to Child Support workers, for managing workloads, and for adjusting to the realities of a dynamic workforce.

Increment: Case Management: Case Closure This increment delivers functionality within the case management subsystem for 1) ensuring cases that should be closed are recognized properly and case closure is performed in an orderly and consistent way; and 2) producing appropriate, defensible documentation of reasons for closure and actions taken during the case’s lifetime.

Increment: Customer Service: Customer Inquiries This increment delivers functionality within the customer service subsystem for handling customer (NCP or CP) inquiries regarding case status, payment status, financial statements, and other typical subjects of customer interaction.

Increment: Customer Service: Customer Self-Service This increment delivers functionality within the customer service subsystem that enables customers to directly perform routine case inquiries and submit information using some combination of Web technologies and IVR systems. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 193

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Increment: Customer Service: Employers This increment delivers functionality within the customer service subsystem for assisting employers in enforcing income withholding orders (IWOs) on their employees.

Increment: Interstate This increment delivers an interstate subsystem that manages the interactions with other state Child Support agencies as they enforce Nevada Child Support and/or as Nevada reciprocates by enforcing Child Support on behalf of the other states.

Increment Sequencing and Timeline If the 41 increments described above will, when they are all completed, produce a modernized Nevada IV-D System, there is still the question of where to start, and what order to proceed through the development. The order in which the increments were presented above was approximate (proceeding from risk-mitigating to foundational, then to functional, and finally to “clean up” and “optional”). This section will present a more detailed view of that ordering, as well as an overall timeline for the completion of the modernization project itself.

Sequencing and Resourcing Assumptions and Constraints There are many variables to any given work planning effort, particularly one as large and complex as the Nevada IV-D systems modernization effort. The assumptions and constraints that underlie the plan create an important set of inputs that must be understood. The following assumptions and constraints are specific to the sequencing and execution of the modernization effort:

33

Š

Start Date. It is assumed that the “in earnest” phase of modernization will begin no sooner than July 1, 2013 (coincident with a ramp-down of effort on the Maintenance Plan). Work on some “low burn” activities—in particular, work to begin developing the first round of RFPs for any work that will be contracted for; and work to line up DWSS resources and direct-hire a contractor—is assumed to begin on January 1, 2013, and will overlap with the Maintenance Plan activities.

Š

Time Span. The amount of time to plan for the modernization effort is constrained by available funding on the one hand (it can be done no faster than available funding33 will allow), and pragmatism on the other hand (while theoretically it could be planned to take 25 years to complete, that would obviously be self-defeating). PSI has chosen a target time span of nine (9) years, which, when added to the Maintenance Plan activities, would make the entire maintenance and modernization project take between 10 and 10.5 years to complete.

“Available funding” in this definition also includes any appropriation requests that DWSS succeeds with.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 194

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Use of Vendors. DWSS has limited bandwidth and a perennial challenge to recruit directhire staff; yet, the number of staff required to staff the modernization effort will be substantial. This staff will have to be acquired quickly for timelines to hold. In light of these basic truths, this plan assumes that some combination of vendors willing to do fixed-cost work, as well as contractors willing to work on time-and-materials, will be used to make up for the limited DWSS staff resources.

Š

Blended Rate. While it’s not known which percentage of staff will be vendors or contractors or DWSS staff, it is fairly certain that half or more will be from the vendor / contractor community with some or all of those not local to Carson City. To account for this, PSI has chosen a blended rate of $100 per resource hour. Obviously, if DWSS is able to hire more staff than is anticipated and thus rely less on vendor / contractor staff, this may change the rate assumption.

Š

Constant Progress. While theoretically it would be possible to ramp the modernization effort up and down over the years to consume as much as possible of the funding—and in so doing, try and get done as fast as possible—this plan does not assume this will be the approach. Notwithstanding some possibility of ramping up activity in some places through special one-time projects staffed with contractors or fixed-price vendors, the plan assumes that the activity level ramps up gradually, and then stays at approximately that same level for the duration of the modernization effort. (See the Alternate Approaches section for other possible configurations.

Increments and Grouping The increments described above, and their estimated effort, are summarized in the table below.34 Table 32: Increments Order and Hours Increment Name

Estimated Hours

Develop a Unified IV-D System Database

8,320

Develop a Data Access Layer

8,320

Implement a Business Process Hosting Layer

8,320

Develop a Presentation Layer

8,320

34 Note that PSI does not show CSP to EGL conversion in this list because it is scheduled to be completed during (or prior to) the Maintenance Plan phase.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 195

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Increment Name

Estimated Hours

Implement an Enterprise Service Bus (ESB)

8,320

Develop a Batch Processing Facility

10,400

Develop a Unified Security Layer

16,640

Customer Service: Customer Inquiries

13,520

Customer Service: Customer Self-Service

9,360

Customer Service: Employers

5,200

Prototype Web-Based Screen Conversion

6,240

Full Web-Based Screen Conversion

8,320

Implement Business Rules Engine (BRE)

16,640

IV-D Framework: Document Generation

23,920

IV-D Framework: Alerts Management

12,480

Financials: Billing and Collections

14,560

Financials: Distribution

66,560

Financials: Disbursements

37,440

Financials: Reconciliation

21,840

Financials: Adjustments

5,200

Implement a Workflow Engine

26,000

Case Initiation: Intake

75,920

Case Initiation: Assessment/Order Entry

50,960

Locate: Research

33,280

Interstate

46,800

Locate: Address/Employer Verifications

32,240

Case Management: Case Assignments

16,640

Enforcement: Payment Monitoring

10,400

Enforcement: Wage Withholding

11,440

Enforcement: Administrative

57,200

Enforcement: Judicial

26,000

Review and Adjustment

7,280

Establishment: Paternity

29,120

Establishment: Stipulations

11,440

Establishment: Court Preparation

36,400

Case Management: Case Closure

40,560

Implement a Data Mart / Data Warehouse

18,720

Implement True Portal Environment

8,320

Develop a Federated User Repository

2,080

Implement Master Data Management

8,320

Total

859,040

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 196

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

PSI arranged these increments into groups, based on similarity and in order to place prerequisite increments ahead of increments that are dependent upon them, and arrived at the following grouping scheme:

Modernization Prep Work This group is not built around any increments, but, rather, is focused on laying down the project infrastructure needed to execute on the Modernization Roadmap, hiring internal staff, writing, issuing, and evaluating RFPs for modernization increments that will be outsourced, and otherwise laying the groundwork for the modernization effort.

Group 1: Infrastructure (core SOA) The theme of this group is to build out the basic SOA framework of the Nevada IV-D System, and to develop some basic integration between the legacy system and the new architecture, in essence bringing up the basic “Transitional” architecture described in the Modernization Approach section. This group consists of the following increments: Table 33: Infrastructure Group Increment Name

Estimated Hours

Develop a Unified IV-D System Database

8,320

Develop a Data Access Layer

8,320

Implement a Business Process Hosting Layer

8,320

Develop a Presentation Layer

8,320

Total

33,280

Group 2: Customer Service and Infrastructure 2 The theme of this group is to continue to build out the framework for the new IV-D system while bringing on some useful functionality. Because the Customer Service increments have few dependencies (their largest dependency is on the database and a basic presentation layer), they can be brought up on even the minimal amount of framework that is available at this point in time. This group consists of the following increments: Table 34: Customer Service and Infrastructure II Group Increment Name

Estimated Hours

Implement an Enterprise Service Bus (ESB)

8,320

Develop a Batch Processing Facility

10,400

Develop a Unified Security Layer

16,640

Customer Service—Customer Inquiries

13,520

Customer Service—Customer Self-Service

9,360

Customer Service—Employers

5,200

Prototype Web-Based Screen Conversion

6,240

Full Web-Based Screen Conversion

8,320

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 197

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Implement Business Rules Engine (BRE)

16,640

IV-D Framework—Document Generation

23,920

IV-D Framework—Alerts Management

12,480

Total

131,040

Group 3: Financials and Workflow The theme of this group is to pivot from infrastructure development (only one major piece of the core left to complete) to more functional-focused delivery. The last remaining piece of infrastructure, workflow, is brought on in this group. The financial increments have little dependency on workflow, so they can be worked on at the same time the workflow increment is being developed. This group consists of the following increments: Table 35: Financials and Workflow Group Increment Name

Estimated Hours

Financials—Billing and Collections

14,560

Financials—Distribution

66,560

Financials—Disbursements

37,440

Financials—Reconciliation

21,840

Financials—Adjustments

5,200

Implement a Workflow Engine

26,000

Total

171,600

Group 4: Case Setup & Locate The theme of this group is to focus on the Case Initiation and Locate functional areas. At this point the Workflow Engine is online, so increments that depend on it can now be developed. This group consists of the following increments. Table 36: Case Set Up and Locate Groups Increment Name

Estimated Hours

Case Initiation—Intake

75,920

Case Initiation—Assessment/Order Entry

50,960

Locate—Research

33,280

Interstate

46,800

Locate—Address/Employer Verifications

32,240

Case Management—Case Assignments

16,640

Total

255,840

Group 5: Enforcement

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 198

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

The theme of this group is to focus on the Enforcement functional area. This group consists of the following increments: Table 37: Enforcement Group Increment Name

Estimated Hours

Enforcement—Payment Monitoring

10,400

Enforcement—Wage Withholding

11,440

Enforcement—Administrative

57,200

Enforcement—Judicial

26,000

Review and Adjustment

7,280

Establishment—Paternity

29,120

Establishment—Stipulations

11,440

Establishment—Court Preparation

36,400

Total

189,280

Group 6: Cleanup & Optional The theme of this group is to pick up the last remaining functional increments and to bring on some increments that are more “optional” in nature (e.g., Data Warehouse, Portal, Master Data). This group consists of the following increments:

Table 38: Clean-Up and Optional Group Increment Name

Estimated Hours

Case Management—Case Closure

40,560

Implement a Data Mart / Data Warehouse

18,720

Implement True Portal Environment

8,320

Develop a Federated User Repository

2,080

Implement Master Data Management

8,320

Total

78,000

Summary of Groups Hiding the detail of the increments themselves, the following is a summary of the groups that have been laid out: Table 39: Summary of Modernization Increments Groups Group Name

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Hours

Page 199

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Group 1: Infrastructure (core SOA)

33,280

Group 2: Customer Service & Infrastructure 2

131,040

Group 3: Financials & Workflow

171,600

Group 4: Case Setup & Locate

255,840

Group 5: Enforcement

189,280

Group 6: Cleanup & Optional

78,000

Total

859,040

Timeline The Funding Plan presented in the Modernization Funding Plan shows there is enough available funding in the years 2014-2022 to fund an appreciable amount of modernization development. The raw number of hours that have been estimated for the modernization work is 859,040. In theory, if every available dollar was applied to this backlog of work35 in the year the funding plan says it is available, the project could be completed as early as 2021 (est.). This is a theoretical maximum that assumes resources can be scaled up exactly to the desired level and then scaled back down again, which is not very realistic. But the picture only changes somewhat if PSI picks a sustainable resource size and keeps it constant (see assumption Constant Progress in the Assumptions and Constraints section above). At a resource level of 45, the entire modernization effort is complete in 2022 (state fiscal year 2023), as shown in the GANTT chart below: Table 40: Modernization Timeline

Below is a less graphical version of the same information:

35

At the assumed blended rate of $100 / resource hour.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 200

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

A resource level of 45 coincides with a run rate of approximately $9.3M per year, which PSI shows starting in state fiscal year 2014. This overlays the available funding for Maintenance and Modernization as follows:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 201

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Table 41: Modernization Funds and Spending Timeline State Fiscal Year

Available Funds for Maintenance & Modernization

Modernization Spend

2012

$5,414,734

0

2013

$4,285,688

$312,000

2014

$9,800,269

$9,360,000

2015

$10,991,529

$9,360,000

2016

$10,511,223

$9,360,000

2017

$10,157,533

$9,360,000

2018

$10,747,673

$9,360,000

2019

$11,288,585

$9,360,000

2020

$11,828,073

$9,360,000

2021

$12,415,758

$9,360,000

2022

$12,952,829

$9,360,000

2023

$13,488,504

$1,664,000

This shows that the proposed resource level of 45, representing a $9.3 M-per-year run rate, generally is supported by the amount of available funding. On an ongoing basis, each budget period’s spending plan will need to iron out the details to assure sufficient funding is available to support maintenance and modernization work in that year.

Alternate Approaches The sequencing laid out above is achievable, and the assumptions presented at the beginning of this section are reasonable, given the facts available at the time of this writing. However, variables such as these change, and it’s reasonable to consider how such changes might affect the modernization timeline.

Alternate Resource Plans The plan laid out above assumes a staffing level of 45, which gets the project done in early 2022. What happens if one adjusts this staffing level up or down? Obviously, in general terms, fewer staff will mean that modernization takes longer to complete; and more staff (up until the point where the work cannot be done any faster) means modernization will be completed faster. The following staffing levels have the effect shown:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 202

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Table 42: Timeline Impact of Alternative Staffing Levels Year

35 Resources

40 Resources

45 Resources

50 Resources

60 Resources

2014

786,240

775,840

765,440

755,040

734,240

2015

713,440

692,640

671,840

651,040

609,440

2016

640,640

609,440

578,240

547,040

484,640

2017

567,840

526,240

484,640

443,040

359,840

2018

495,040

443,040

391,040

339,040

235,040

2019

422,240

359,840

297,440

235,040

(completion)

2020

349,440

276,640

203,840

131,040

2021

276,640

193,440

110,240

(completion)

2022

203,840

110,240

(completion)

2023

131,040

(completion)

2024

(completion)

2025 2026

Removing Nonessential Increments While there is little in the way of “nice to haves” in the Modernization Roadmap, there are still some increments that are technically non-essential to a modernized Nevada IV-D system; and, therefore, DWSS may choose to omit or do one or more of them at some other time. This section identifies the “optional” increments in the roadmap that are not directly on the critical path to a modernized system. Converting Legacy Screens to Web-Based Presentation

The increments Prototype Web-Based Screen Conversion and Full Web-Based Screen Conversion exist strictly to ease the pain for users of having dual system interfaces (legacy mode and Web-based mode). Users live with this situation today, and have expressed frustration with it, which was the impetus for an incremental approach in the first place. However, while making the user experience more fruitful and positive is an important goal, it is one that could be delayed if needed, which would remove approximately 7 person-years from the project timeline. Implement a True Portal Environment

This is another user experience increment, and is not strictly necessary to a modernized IV-D System. Productivity gains are expected to come out of implementing the increment, but those gains are hard to estimate and even more difficult to guarantee, so of all the increments, this one has the lowest “bankable” return on investment (ROI). If this increment were omitted, it would remove approximately 4 person-years from the project timeline.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 203

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Implement Master Data Management

Master Data Management (MDM) is an important concept and solves several problems for DWSS, in particular where IV-A and IV-D must share information about clients, employers, and other similar-butdifferent database entities. A consequence of removing this from the architecture will be a less intuitive ability to share data involving these entities across system/agency lines. Another consequence will be a delay in updates from one side to the other in some cases, or too aggressive updates in other cases (e.g., read “unwanted updates”)—in short, the same situation users experience today. If this increment were omitted, it would remove 4 person-years from the project timeline. Develop a Federated User Repository

This increment is intended to make it easier for DWSS to share targeted portions of the IV-D System with other-state users or members of some external entities (e.g., contractor agencies, legal associations, etc.). The consequence of removing this increment will be that it will be somewhat harder to give outside agencies access to NOMADS; and, when access is given, there will be more of a burden on DWSS IT Staff to manage those user credentials. If this increment were omitted, it would remove approximately 1 person-year from the project timeline. Implement a Data Mart / Data Warehouse

The final “optional” increment is the data warehouse implementation. This increment is intended to deliver better ad-hoc query features, as well as improved management reporting capabilities. While it ultimately will be important for DWSS to have a data warehouse/data mart facility, this could be deferred indefinitely (at the cost of lower insight into the database, workloads, etc.). If this increment were omitted, it would remove approximately 9 person-years from the project timeline.

Modernization Roadmap Maintenance As with any plan—particularly those that cover multiple-year projects—events will happen during the execution of earlier steps in the plan that should be factored into the plan itself in order to keep the plan accurate. This section discusses the maintenance of the Modernization Roadmap, including the kinds of events that ought to trigger a review and possible update of the plan to keep it relevant and updated.

Review-Triggering Events The Modernization Roadmap should be reviewed and updated when the following events occur: Š

At the conclusion of a major increment / group. The completion of an increment provides a good milestone for reviewing the plan so that the new information that comes out of the increment can be factored into the plan.

Š

At the conclusion of an overlapping non-roadmap project. Non-roadmap projects (projects that did not come about directly because of the roadmap, but still affect or overlap the work planned in the roadmap (e.g., if IV-A were to independently implement a Document Generation tool) should prompt a review of the roadmap. If the non-roadmap project supplies some planned roadmap functionality, such reviews will presumably be to remove no-longer-needed work from the roadmap; but it is also possible that the nonroadmap project would have a negative effect on the roadmap (i.e., it adds work to the schedule).

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 204

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

During budgeting updates. When the biennial budget is approved, the funding assumptions and spending plan should be reviewed. Similarly, when Appropriation Requests are approved and additional funding secured, the funding assumptions and spending plan should be reviewed.

Š

When other significant and relevant information is developed. This is an admittedly amorphous category for a trigger, but it still bears mentioning. Events in this category might include 1) OCSE issues new alerts, bulletins, or other communications that have the potential to affect planned work (i.e., large requirements are added); 2) major technology initiatives that affect the roadmap are announced or put into effect (e.g., mainframes are put on an “end of life” status); or 3) IV-D policy changes in material ways. The IV-D System Owner should watch for such events and factor their effects into the roadmap.

Š

Annually. For the duration of the modernization effort, the IV-D System Owner should ensure the roadmap document is reviewed at least annually if no other events trigger a review in any given calendar year.

Roadmap Review The goal of any given review of the roadmap should be to ensure the plan is still accurate and, if not, adjust the plan to make it accurate again. This general statement will tend to break down into the following types of updates: Š

Adding, removing, and resizing increments

Š

Refactoring increments

Š

Resequencing increments and adjusting timelines

Each of these types of updates is described below.

Adding, Removing, and Resizing Increments This type of update will tend to be triggered by external events, such as the completion of an increment, the conclusion of an overlapping non-roadmap project, or IV-D Program policy changes or technology edicts. Events such as these will create new increments, remove planned increments, or affect existing planned increments.

Adding Increments When new requirements are encountered, they may be handled by adding new increments to the roadmap, describing and sizing the new increment(s), and adjusting the sequencing so the increment is accounted for in relation to the other increments. The key information to develop for new increments includes: Š

Description. New increments should be described as fully as possible, but voluminous descriptions may be better handled as attachments to the roadmap and/or external

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 205

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

documents, as opposed to placing long descriptions inline. Currently, increments are described in 4-5 pages, and this rule of thumb should be maintained to keep the roadmap readable. Š

Effort Estimate. Estimates should be provided as ROMs, or as more-refined estimates if available.

Š

Dependencies. Dependencies on other increments in particular should be noted, as they are relevant to the proper sequencing of the increments.

Removing Increments In some cases, a straightforward removal of an increment is required, as when an increment is determined to be no longer necessary, or has been provided outside of the roadmap (e.g., IV-A implemented Document Generation). Removing an increment primarily will consist of deleting the increment (or somehow indicating it is no longer needed, perhaps with a font change or using strikethrough), dropping the increment from the sequencing, and resequencing the remaining increments. Straightforward removal is rare; it is likely that some “removal” of increments will turn out to require refactoring of an increment instead (described below).

Resizing Increments This occurs when an increment’s scope and description has changed materially enough to affect its estimate. In this case, the main elements to update are the description (describe the adjusted scope) and the estimate. Following this update, the sequencing should be adjusted to show the increment’s new scope. Note that a special case of resizing estimates might come in the form of a “mass reestimating” process. This can happen when one notices a trend that all estimates are similarly incorrect and decides to apply a correction to all estimates to account for this trend. The basic process is still the same, however, except the description most likely will not need updating, since it has not changed. To see the effect of the resizing, for each affected increment, the time is adjusted followed by the entire roadmap being resequenced.

Refactoring Increments Refactoring increments can get intricate, and only general guidelines can be provided here. Refactoring is defined as taking an existing increment and materially rethinking it, usually coming up with a different set of increments as a result. For example, a single increment might be broken down into three more specific increments. Additionally, work that was planned for an increment is now being provided by the framework— thus it no longer needs to be performed and requires removal from the increment’s scope. Finally, an increment might need to be broken down into smaller increments so a specific piece can be “pulled forward” in the schedule and completed earlier. In all these examples, the general process should be the same: Š

Rewrite the affected descriptions, which might include adding new increments to hold functionality that is being removed (refactored) from another one.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 206

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Size / resize the affected increments according to the new descriptions.

Š

Adjust dependencies as needed within the affected increments.

Š

Resequence the roadmap, adding new increments in the appropriate place in the sequence.

It should be noted PSI is discussing the maintenance of increments in the context of maintaining the Modernization Roadmap; this is different than the planning and creation of a detailed WBS (Work Breakdown Structure), which occurs during the execution of an increment. This could be called refactoring because it involves making smaller things (tasks) out of a larger thing, as PSI is describing. But from the standpoint of the roadmap, such details belong in the execution of an increment, and have no place in the roadmap itself. None of the advice in this section should be read as calling for the roadmap to be updated with the detailed WBS of any given increment—that would be overkill and would provide little value.

Resequencing Increments and Adjusting Timelines Resequencing increments and adjusting timelines should be done when estimates change, increments are added or removed, or when funding is (or more specifically, resources are) adjusted. PSI provided a simple tool for performing what-if analysis on sequence changes. The tool, Nevada IV-D Modernization Sequencing & Timeline Tool.xls, is described below.

Estimates Change and Increments are Added & Removed This is a straightforward calculation of the new project timeline and end-date based on adjustments that have been made to one or more increments. This primarily involves inputting the updated increment figures and/or adding and removing increments from the list, then recalculating the project timeline using the sequencing tool.

Funding (Resourcing) Changes The initial roadmap made certain resourcing and funding assumptions, as identified in the Increment Sequencing and Timeline section. Primary among these was a resource-level assumption that defines both a) how much work can get done in any given period of time; and b) how much money the project is spending in that same amount of time. The initial timeline was laid out as being the fastest, most practical timeline achievable given the funding currently projected to be available. When resourcing is adjusted, either because the resources are not available (i.e., the money is there but the resources cannot be hired / contracted), or the funding availability proves to be different than the projections, the timeline will necessarily be affected. The new resource levels should be identified and a new timeline calculated based on the adjusted resource levels.

Sequencing What-If Tool PSI has provided a simple tool for performing what-if analysis on the timeline and sequence of increment groups. The tool is in a file named Nevada IV-D Modernization Sequencing & Timeline Tool.xls, and is provided as a project artifact. The tool can be used when evaluating the effects of modifications to the sequencing, increment sizes, and resourcing assumptions. The following recommendations should guide users of the tool: Š

IMPORTANT: The tool requires the “Analysis Toolpak” add-in. There is a free, standard add-in to Microsoft Excel, the “Analysis Toolpak,” that provides the workday-

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 207

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

based date calculations the spreadsheet relies upon. This add-in should be enabled in a system before the tool is used. This can be done by following the steps below: ƒ

The Analysis Toolpak (ATP) is provided free with Excel, and it should already be on the computer in question.

ƒ

Go to the Tools menu, and select the Add-Ins item.

ƒ

This will display a dialog box which lists all of the Add In modules that Excel found in the standard Add-Ins folder (typically located here: C:\Program Files\Microsoft Office\Office\Library).

ƒ

Find Analysis ToolPak in the list, and place a check mark next to it.

ƒ

If one tries to use the worksheet without first installing the add-in , a #NAME? error will show up in the “End” date columns (column L) and the “(rough) Project End Date” cell. If that occurs, follow the steps above to install the ATP before reattempting to use the worksheet.

Š

Start with a clean copy of the “Sequencing” worksheet. PSI recommends that, when performing any given what-if analysis, one begins by creating a copy of the “Sequencing” worksheet and renaming it appropriately (e.g., “2014-revision-1-RBW”), allowing the worksheet to be practiced with safely. If the spreadsheet should become corrupted, an “as delivered” clean copy can be located in the project folders.

Š

Modify “Team Bandwidth” to reflect aggregate team size. The field “Team Bandwidth” in the assumptions section allows you the aggregate size of the team to be modified (i.e., the number of full-time-equivalent resources working on the modernization project directly, including vendor staff). Increasing this number reflects hiring more resources and accelerates the project timeline. Decreasing this number reflects hiring fewer resources and extends the overall project timeline.

Š

Modify “cost per resource-hour” to calculate run-rate. Run-rate is the amount of money that is projected (spent) on the resources dedicated to the project. PSI has performed its initial calculations using a $100 / resource-hour blended rate, which is intended to reflect the

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 208

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

average rate that will be spent on DWSS staff, contractor staff, and project-oriented vendors36. Š

Modify “Project begin date” to start the modernization project earlier or later: Modifying the project begin date will cause all increment begin and end dates (columns K and L, in green) to be moved out or in, as appropriate, based on the new begin date.

Š

Modify increments to resize / refactor increments:

Š

Š

ƒ

The Section in yellow is the “what-if playground.” Here, increments can be added, deleted, resized (change their estimated hours), or refactored.

ƒ

PSI recommends one not modify the group “header” lines, which are in bold font. These rows hold the formulas for calculating the beginning and end dates for the individual increment groups, and should not be modified (except by one who is trained in how to do this).

Zero-out finished increments to perform point-forward calculations. If a tool is being used to cast the remainder of the modernization project (after, say, two increment-groups are already complete), the following steps should be followed: ƒ

Create a copy of the sequencing worksheet for the what-if.

ƒ

Zero-out the hours for any increments that are considered to be complete (or refactor and move forward any remaining hours that are to be completed).

ƒ

Enter the new point-forward date as the new “Project Begin Date” (blue “Assumptions” section at top of worksheet).

Dependencies are between increment-groups only. The tool assumes that each increment-group will be done serially (one after the other), and that work within an increment-group will be done in parallel (as fast as the assumed “team bandwidth” allows). Sequencing (in particular the milestone start and end dates for the individual increments) is a factor that can be used to determine how wide the team is and how many hours are contained within a group.

36 Fixed-price vendors obviously do not charge by the resource-hour. The blended rate is still a good guideline since, if DWSS gets reasonable value for its fixed-price dollar, the net calculation of dollars-paid-vendor / hours-of-project-work-performed-by-vendor ought to come close to $100.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 209

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Š

Calculations are approximations only. The sequencing and milestone dates calculated by the tool should be regarded as approximations only. For example, the tool assumes relatively “perfect” load-balancing of the team within any given group, and does not take into account state-specific holidays. It is designed to be simple to use and understand, and to provide good-but-rough answers to questions, such as “If we have an effective team-size of 39, when will this increment be complete?”

Planning Results: Spending Plan for Maintenance and Modernization  

Introduction The objective of the spending plan is to align available resources with maintenance and modernization needs. To achieve this objective, PSI summarized the sources and amounts of costs identified in the Maintenance Plan and Modernization Roadmap by state fiscal year. Costs were then overlaid on the available funding for maintenance and modernization activities. Finally, adjustments were made to move available resources to state fiscal years, where they are needed, and thereby determine any additional need for General Fund appropriations. This section of the system maintenance and modernization spending plans includes: Š

A summary of costs from the Maintenance Plan and Modernization Roadmap

Š

A yearly comparison of available funding to resource needs

Š

A spending plan summary

Š

A discussion regarding maintenance of the funding and spending plans

For a more detailed understanding of the spending plan’s basis and accounting, please see Appendix H.

Summary of Costs for Maintenance and Modernization Funding for the maintenance phase is required from January 2012 through June 2013 to address all of the work items in the Maintenance Plan. During this phase, the Maintenance Plan calls for the following expenditures: Š

$100,000 per year for the System Owner position covering the second half of state fiscal year 2012 and all of state fiscal year 2013

Š

Two (2) positions for baseline maintenance with estimated costs of $104,000 in the last six months of state fiscal year 2012 and $208,000 in state fiscal year 2013

Š

Up to nine (9) positions for Maintenance Plan activities with estimated costs of $728,000 in state fiscal year 2012, and $1,560,000 in state fiscal year 2013 through state fiscal year 2023

Š

$1,386,457 of incentive funds for program-wide enhancements

See Appendix H for details regarding how staff position costs were estimated for the maintenance phase.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 210

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

Funding for the modernization phase is required from July 2013 through August 2023 to complete all of the modernization increments. During this phase, the Modernization Roadmap calls for the following expenditures: Š

$100,000 per year for the System Owner position covering state fiscal year 2014 through state fiscal year 2023

Š

Up to four (4) positions for preparatory work for the modernization phase with estimated costs of $312,000 in state fiscal year 2013 (see Appendix H for details regarding how staff position costs were estimated)

Š

Forty-five (45) state and contracted positions to work on modernization increments with estimated costs of $9,360,000 per year through state fiscal year 2022, and $1,664,000 in state fiscal year 2023 at the close of this effort

Š

$800,000 for a batch processing tool in state fiscal year 2014

Š

$1,000,000 for a document generation tool in state fiscal year 2015

The following table summarizes the costs for the maintenance and modernization phases. It shows the maximum annual resource need is $10,668,000 in state fiscal year 2015. It also shows the total cost of the Maintenance Plan and Modernization Roadmap to be $95,232,457. Of this amount, a portion will be funded by State resources with the balance funded by federal financial participation (FFP). The Maintenance Plan resource need of $2,114,457 in state fiscal year 2012 includes the $728,000 for the nine (9) maintenance staff and $1,386,457 for program-wide enhancements. Table 43: Maintenance and modernization Costs SFY 2012-23 SFY 2012 SFY 2013 SFY 2014 SFY 2015 SFY 2016 SFY 2017 SFY 2018 System Owner $50,000 $100,000 $100,000 $100,000 $100,000 $100,000 $100,000 Baseline Maintenance Staffing Resource Need $104,000 $208,000 $208,000 $208,000 $208,000 $208,000 $208,000 Maintenance Plan Resource Need $2,114,457 $1,560,000 $0 $0 $0 $0 $0 Modernization Roadmap Staffing Resource Need $0 $312,000 $9,360,000 $9,360,000 $9,360,000 $9,360,000 $9,360,000 Non-staffing Resource Need $0 $0 $800,000 $1,000,000 $0 $0 $0 Total Resource Need $2,268,457 $2,180,000 $10,468,000 $10,668,000 $9,668,000 $9,668,000 $9,668,000 SFY 2019

SFY 2020

System Owner $100,000 $100,000 Baseline Maintenance Staffing Resource Need $208,000 $208,000 Maintenance Plan Resource Need $0 $0 Modernization Roadmap Staffing Resource Need $9,360,000 $9,360,000 Non-staffing Resource Need $0 $0 Total Resource Need

$9,668,000 $9,668,000

SFY 2021

SFY 2022

SFY 2023

TOTAL

$100,000

$100,000

$100,000

$1,150,000

$208,000

$208,000

$208,000

$2,392,000

$0

$0

$0

$3,674,457

$9,360,000 $0 $9,668,000

NOMADS CSE System Maintenance Plan & Modernization Roadmap

$9,360,000 $1,664,000 $86,216,000 $0

$0

$1,800,000

$9,668,000 $1,972,000 $95,232,457

Page 211

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

With both the available funding and resource needs now identified, PSI compared annual available resources to the annual resource needs. PSI then adjusted the timing of resources to align available funding with system resource needs.

Comparison of Available Funding to Resource Needs The following table shows the available state and federal funding by state fiscal year from the funding plan. It also shows the annual resource needs from the maintenance and modernization phases. Table 44: Comparison of Available Funding to Resource Needs SFY 2012-23 State Fiscal Year

Total Available State and Federal Funding

Total Resource Need

SFY 2012

$5,414,734

$2,268,457

SFY 2013

$4,285,688

$2,180,000

SFY 2014

$9,800,269

$10,468,000

SFY 2015

$10,991,529

$10,668,000

SFY 2016

$10,511,223

$9,668,000

SFY 2017

$10,157,533

$9,668,000

SFY 2018

$10,747,673

$9,668,000

SFY 2019

$11,288,585

$9,668,000

SFY 2020

$11,828,073

$9,668,000

SFY 2021

$12,415,758

$9,668,000

SFY 2022

$12,952,829

$9,668,000

SFY 2023

$13,488,504

$1,972,000

Total

$123,882,398

$95,232,457

The table above shows that available funding exceeds the total resources needed in every year except state fiscal year 2014. Given the projected shortfall in state fiscal year 2014, PSI pushed excess resources from state fiscal years 2012 and 2013 into state fiscal year 2014. For the biennium covering state fiscal years 2012 and 2013, PSI staff has followed DWSS and CSEP’s existing resource allocations. Of the $5,414,734 of combined state and federal resources available in state fiscal year 2012, $4,366,159 is incentives. Of this $4,366,159 of incentives, CSEP has committed $1,386,457 to use for program-wide enhancements. Therefore, the balance of incentives in state fiscal year 2012 may be pushed forward to state fiscal year 2014 to cover the aforementioned shortfall. The remaining resource needs in state fiscal year 2012 would be fully covered by the state share of collections and General Fund support from DWSS. The next section summarizes PSI’s spending plan for the Maintenance Plan and Modernization Roadmap.

Summary of Spending Plan The spending plan shows that the costs for maintenance and modernization activities can be covered with existing resources if Nevada follows PSI’s recommendations and the underlying assumptions bear out. The existing funding can even support accelerating the Modernization Roadmap. NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 212

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

However, if Nevada does not follow PSI’s recommendations to leverage incentives and/or the State share of collections, the resource requirements of the Modernization Roadmap are not likely to be met by available resources. Rather than decelerating the Modernization Roadmap if such a funding gap occurs within a biennium, PSI recommends an increase in General Fund resources, either in the form of support from DWSS or appropriations, to meet this funding gap. Furthermore, should PSI’s funding recommendations be fully implemented and leveraged resources prove sufficient to support the modernization schedule as forecasted, Nevada may still wish to consider supplementing these resources with General Fund resources in order to accelerate the system’s modernization schedule and associated benefits.

Funding Plan and Spending Plan Maintenance As discussed, PSI’s forecast of available funding is dependent on DWSS and CSEP executing PSI’s funding recommendations and the associated funding assumptions bearing out. In the event a recommendation is not accepted or an assumption does not bear out, actual available resources in a given year may fall short of need. Therefore, ongoing maintenance and modernization planning and execution will require DWSS and CSEP to maintain and update the funding plan and spending plan, keeping them current with actual resource amounts and/or revised assumptions. As the System Owner updates the Maintenance Plan and Modernization Roadmap, the funding plan should likewise be updated. Triggers for funding plan updates may include adding, removing, resizing and resequencing work items and/or modernization increments. Funding events alone may trigger funding plan updates that in turn may require updates to the Maintenance Plan and/or Modernization Roadmap. At minimum, the following items should be updated on an annual basis: Š

General Fund support from DWSS. CSEP must update the funding plan with the amount of any additional General Fund support. The updated amount should include both state resources and applicable FFP.

Š

Additional incentives earned. CSEP must update the estimates of additional incentives earned in upcoming years based on the most recent performance trends. The updated amount should include the amount of incentives (and applicable FFP if FFP is available for incentive expenditures in the future).

Š

Additional state share of collections. CSEP must update the estimates of additional state share of collections in the upcoming years based on the most recent trend in collections. The updated amount should include the state share of collections and applicable FFP.

Š

Baseline funding resets. Although the funding plan assumes that certain sources will provide a constant baseline level of funding, future fiscal circumstances may require CSEP to reset these baseline amounts. CSEP should then update the baseline amounts as appropriate.

Š

Resource needs by year. As CSEP makes changes to the Maintenance Plan and Modernization Roadmap, CSEP must make any corresponding changes in the level of resources needed for a given year. The spending plan takes the level of resources needed as a given determined by maintaining the Maintenance Plan and Modernization Roadmap.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 213

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

See Appendix I for the spreadsheet tool that DWSS and CSEP should use to update and maintain the funding and spending plans.

Planning Results: Issues  In this section PSI identifies significant issues that need to be addressed that will impact the success and/or direction of system maintenance and modernization. IV-D System Governance. While the primary purpose of this assessment is to develop a plan to stabilize and upgrade the Nevada IV-D system, PSI has also addressed and made significant recommendations to change how the IV-D system is currently governed. PSI is of the opinion that the prognosis for the Maintenance Plan and Modernization Roadmap is directly dependent on Nevada acting to transform its system governance process. Establishing and hiring a qualified IV-D System Owner within CSEP is viewed as the essential first step. Unless / until the Nevada IV-D System Owner position is filled, PSI considers this to be a critical issue that threatens CSEP’s ability to achieve its objectives. OCSE. As a federally subsidized program, Child Support—and particularly Child Support systems—are subject to regulation and oversight by OCSE. As DWSS implements the Maintenance Plan and Modernization Roadmap, it will need to apprise OCSE of its plans via its APDUs. As modernization proceeds, particularly in the event that DWSS chooses to seek funding to accelerate the development, there is the potential for increased OCSE attention. This could entail a request for more formal federal planning (including the requirement that DWSS perform a feasibility study) and/or a request that DWSS engage an Independent Validation and Verification (IV&V) vendor. Should these events occur, they will add cost and time to the implementation of the Modernization Roadmap and, in extreme circumstances, could alter the technical direction proposed.

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 214

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

VI. CONCLUSION An objective, comprehensive needs assessment confirmed Nevada’s technology support for the Child Support program is in urgent need of attention. Stakeholders echoed serious concerns about the limitations and deficiencies of the current IV-D system. Nearly every element of the current system was found to be in need of some form of remediation. It was also clear from the technical needs assessment that DWSS should aggressively execute the actionable Maintenance Plan represented in this report in order to reduce risk and stabilize the current system. A TCSA was designed for a future Nevada IV-D system that is more scalable, robust, and easier to modify than the current system. A realistic Modernization Roadmap was constructed that provides a rational, incremental approach to achieving a modern, efficient IV-D system, one that will support and manage effective and efficient Child Support business processes. PSI worked closely with DWSS to understand CSEP’s current funding streams, expenditures, and budget processes, enabling PSI to develop a strategy to fully leverage existing funding sources for the IV-D NOMADS Maintenance Plan and Modernization Roadmap. The results of PSI’s analysis and planning concluded that existing funding sources can be sufficiently leveraged not only to execute the Maintenance Plan in the near term, but also to successfully execute the Modernization Roadmap through completion in 2023. To support the execution of these Plans, PSI is making recommendations to transform the IV-D System’s governance structure and establish a well-designed, repeatable process for implementing both maintenance and modernization. Because needs and available resources will likely change over time, guidelines and tools were developed to assist CSEP in updating the system improvement plans. By leveraging available resources, taking steps to strengthen system governance, and executing technical and functional system projects in a rational order, Nevada can realize a fully modernized IV-D system within the next 10-11 years. The State may opt to accelerate modernization with additional funding. In the near term, Nevada’s IV-D system will be stabilized by addressing urgent viability issues. In the longer term, Nevada’s Child Support Enforcement Program will be empowered to achieve its objectives and improve the lives of the state’s children and families.

NOMADS STEERING COMMITTEE RESPONSE Below, in its entirety, we have inserted the State’s response to this document:

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 215

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 216

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 217

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 218

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 219

State of Nevada Department of Health and Human Services Division of Welfare and Supportive Services

NOMADS CSE System Maintenance Plan & Modernization Roadmap

Page 220

Loading...

NOMADS CSE System Maintenance Plan - DWSS - State of Nevada

Nevada Operations of Multi-Automated Data Systems (NOMADS) – Child Support Enforcement Application Assessment Project NOMADS CSE System Maintenance P...

2MB Sizes 3 Downloads 16 Views

Recommend Documents

NOMADS CSE System Maintenance Plan - Nevada Legislature
Assessment Project. NOMADS CSE System. Maintenance Plan &. Modernization Roadmap. October 6, 2011. Revision 4.2. EXHIBIT

Division of Purchasing - Nevada State Purchasing - State of Nevada
Sep 17, 2015 - cost of the Seed to Sale Inventory Tracking and Management System and use of that system by. MMEs. The pr

1862-MSC-Contract - Nevada State Purchasing - State of Nevada
costs, arising out of any alleged negligent or willful acts or omissions of Contractor, its officers, employees and agen

association list1 - Nevada Division of Insurance - State of Nevada
Apr 1, 2013 - 5/1/1999. M & R CONSTRUCTION CORP. 6/1/1999. CARSON HOME IMPROVEMENTS INC. 8/1/1999 ..... INC. 8/1/2008. K

water words - Nevada Division of Water Resources - State of Nevada
Safe Yield — (1) The rate at which water can be withdrawn from supply, source, or an aquifer over a period of years ..

THE CONSTITUTION OF THE STATE OF NEVADA - Nevada Legislature
[Effective through November 26, 2018, and after that date unless the provisions of Senate Joint Resolution No. ...... Th

Circular - Nevada Division of Insurance - State of Nevada
Nov 18, 2009 - As a result of Item B-1399A, effective 7/1/2006, the loss cost for class code 7425 was updated by the ave

Nevada Practitioners' Journal of Labor and - State Bar of Nevada
1 Associate Professor, William F. Harrah College of Hotel Administration, University of Nevada, Las Vegas. 2 See, e.g. .

Contact Us - Nevada Department of Taxation - State of Nevada
Call Center. Contact our Call Center for questions regarding general tax inquiries, Sales Tax, Use Tax, Modified Busines

state of nevada nevada medical fee schedule maximum allowable
NEVADA MEDICAL FEE SCHEDULE. MAXIMUM ALLOWABLE PROVIDER PAYMENT. February 1, 2016 through January 31, 2017. Pursuant to