ESBD_356196_1713886852249_FNS Handbook 901 v.2.4 (pg 251-350).pdf

5.2 Needs Assessment 5.0 System Planning 249

Doctrine

Doctrine is different than policy. It includes strategic plans and objectives for an organization and official objectives for programs such as SNAP, WIC, and CNP. Mission statements are one example of doctrine. Doctrines are the fundamental principles that guide FNS and the State in coordinated action toward a common objective.

Though neither policy nor strategy, joint doctrine serves to make policy and strategy effective in achieving a common objective. Doctrine is authoritative guidance and will be followed except when, in the judgment of the federal agency, exceptional circumstances dictate otherwise.

Is there existing doctrine that addresses or relates to the business need? Is it federal? State? Local?

Are there operating procedures in place that are NOT being followed which contribute to the identified need?

If no doctrine is in place which pertains to the defined need, does new doctrine need to be developed and implemented that will provide a total or partial solution to the need?

Organization

The organization is a hierarchal arrangement of a department or division with varied functions enabled by a structure that may include joint departments or divisions. These organizational units are the basis through which individuals cooperate systematically to accomplish a common mission and directly provide, or support, capabilities. Subordinate organizations coordinate with other departments or divisions and, as a whole, enable the higher-level organization to accomplish its mission. This includes the State staffing required to plan, operate, sustain, and support SNAP and WIC program capabilities.

Where is the need or problem occurring? What organizations are the needs or problems occurring in?

What is the primary and secondary mission / management focus of those organizations?

What are the organizational values and priorities?

Is the organization properly staffed and funded to deal with the need or problem?

Is senior management aware of the need or problem?

Is the issue already on some type of organizational issue list?

If so, why isn't the issue being resolved?

Who exactly is aware of the need or problem, or who is being impacted by the need or problem?

Training

Training includes techniques and procedures to prepare State agency staff to respond to strategic, operational, or performance requirements considered necessary to execute policy and operate systems supporting SNAP and WIC programs.

5.2 Needs Assessment 5.0 System Planning 250

Is the need or problem caused, at least in part, by a complete lack of or inadequate training?

Does training exist which addresses the need or problem?

Is the training being delivered effectively?

How are training results being measured and monitored?

Is the need or problem caused by a lack of competency or proficiency on existing systems and equipment?

When was the need or problem discovered? During maintenance, operations, or training?

Do personnel affected by the need or problem have access to training?

Is the training effort supported by leadership?

Is training properly staffed and funded?

Materiel

This includes all items necessary to execute policy and operate systems supporting SNAP and WIC programs (e.g., information technology, information systems, telecommunications, hardware, and software; related spares, repair parts, and support equipment, but excluding real property, facilities, and utilities). FNS advocates the reuse and/or transfer of existing materiel when feasible more than the development or acquisition of new materiel.

FNS recognizes the age and capabilities of materiel may be a contributing factor in some cases.

Is the need or problem caused, at least in part, by inadequate systems or equipment?

What legacy systems exist where the problem is occurring?

What functionality would a new system provide that currently does not exist?

What increases in operational performance are needed to resolve the need or problem?

Is the need or problem caused by a lack of competency or proficiency on existing systems and equipment?

Can increases in performance be achieved without development of a new system?

Who would be the primary and secondary users of the proposed systems or equipment?

Is interoperability either a driver or barrier to the need, or a problem resolution?

Leadership and education

Professional development of all leadership is the product of a learning continuum that comprises training, experience, education, and self-improvement. The role of professional education is to provide the education needed to complement training, experience, and self-improvement to produce the most professionally competent individuals possible.

Is the need or problem caused, at least in part, by inability or decreased ability to cooperate, coordinate, or communicate with external organizations?

5.2 Needs Assessment 5.0 System Planning 251

Does leadership understand the scope of the need or problem?

Does leadership have resources at its disposal to correct the need or problem?

Has leadership been trained on effective change management principles?

Has leadership properly assessed the level of criticality, threat, urgency, risk, etc. of the operational impact(s) of the need or problem?

Is leadership aware of the drivers and barriers to resolving the need or problem within the organization?

Has leadership identified cultural drivers and barriers between the Federal, State, and local agencies which hinder need or problem resolution?

Personnel

The personnel component primarily ensures that qualified personnel exist to support executing policy and operating systems supporting SNAP and WIC program requirements. This is accomplished through synchronized efforts of State agencies to optimize personnel support at the State and local levels to ensure success of policy and systems supporting SNAP and WIC programs.

Is the need or problem caused, at least in part, by inability or decreased ability to place qualified and trained personnel in the correct occupational specialties?

If need or problem resolution is likely to involve new materiel, systems, or equipment, are different occupational specialty codes needed to properly staff new systems?

Do new personnel have support to onboard to their jobs?

Are the right personnel in the right positions (skill set match)?

Facilities

Defined as real property consisting of one or more of the following: buildings, structures, utility systems, associated roads and other pavements, and underlying land. Key facilities are defined as headquarters installations and facilities of primary importance to the support of SNAP and WIC programs.

Is the need or problem caused, at least in part, by inadequate infrastructure?

Is physical distance of equipment, etc. leading to other problems?

Are there proper environmental controls?

Is there a lack of operations and maintenance?

5.2 Needs Assessment 5.0 System Planning 252

Policy

Policy from any Federal or State agency related to certification, eligibility, benefits, administration, funding, auditing, accountability, security, technology implementation, contracting, acquisitions, or SNAP and WIC program management.

Is there existing policy that addresses or relates to the business need? Is it Federal? State? Local?

If no policy exists which pertains to the defined need, does new policy need be developed and implemented that will provide a total or partial solution to the need?

Can policy be developed and signed at the State agency level? Will policy require USDA-level sponsorship, coordination and / or signature?

- el, facilities, and policy -assessment, doctrine, organization, training, materiel, leadership, personnel, facilities, and policy are assessed for their impact on the new processes.

Business Capability Definition

The needs assessment begins with defining the needed business capability using business analysis methodologies.

(See Figure 43: Business Capability Definition and the Needs Assessment, next page) The capability may be necessary to resolve a business or technology problem, fill a gap in supporting SNAP or WIC, respond to policy changes, or take advantage of an opportunity. This means doing a simple root cause analysis. Defining the business needs assessment by evaluating doctrine§§§, organization, training, materiel, leadership, personnel, facilities, and policy. The State agency needs to assess how each of these constrains, supports or promotes the

- to- -level outcomes and how the outcomes will be measured for success.

§§§ Doctrine is different than policy. It includes strategic plans and objectives for an organization and official objectives for programs such as SNAP, WIC, CNP. Mission statements are one example of doctrine.

5.2 Needs Assessment 5.0 System Planning 253

achieve the desired outcomes in other ways. Determining this is based on business analysis. Business analysis should not only validate the high-level outcomes, but provide opportunities for BPR/I. These BPR/I opportunities may become their own courses of action, or be combined with other courses of action to include an IT solution.

Each course of action requires its own rough order of magnitude cost estimate. The BCD ends with a summary of the outcomes; in other words, a report commonly known as the business case. Once the BPA process has been be conducted.

Figure 43: Business Capability Definition and the Needs Assessment

5.2 Needs Assessment 5.0 System Planning 254

The appropriate State agency authority uses the business case as the basis for making the decision to proceed with the project, or not. If the decision is to proceed, the State agency compares the scope and cost of the proposed project to the FNS thresholds requiring approval, to determine if the APD process applies.

SNAP Program Waivers

Some SNAP IS projects may trigger the need for a program waiver. Where technology is used to supplant or supplement the duties of merit staff, or where communication with applicants or participants changes the way applications are processed, changes are reported, or notices to participants are delivered, States should notify their FNS regional offices to ensure that the new processes are in compliance with SNAP policy or identify what waiver requests might be necessary.

See the SNAP website for information on waivers of rules.**** State agencies should keep in mind that tasks involving client contact are restricted to State merit system personnel unless FNS approves use of non-merit or vendor staff to perform certain tasks. This guidance may be found on the SNAP website.

The Business Case

A well-developed business case provides most of the information needed for the PAPD. The business case is built on the information from the business capabilities definition. It is used by the State agency as the basis for deciding to proceed with the project. It summarizes the key elements for the needs assessment and is a tool for the decision maker to select a course of action based on credible and objective information derived from systematic analysis. The complexity of a business case is driven by the level of confidence the decision maker needs to choose a course of action that will most reliably, and cost effectively, produce the desired outcome. The contents of the business case describe the full range of resources and actions required to reach the stated objectives.

The business case development process should ensure:

The Business Case concerns the business capabilities and impact, rather than focusing on technical aspects An executive with the capability and authority to deliver the benefits, sponsors, and commits to the investment

**** http://www.fns.usda.gov/snap/rules/Waivers/default.htm http://www.fns.usda.gov/snap/rules/Memo/2010/012210.pdf

See chapter 1.0 Getting Started with the Advance Planning Document (APD) Process, section 1.5.1 Thresholds.

5.3 Feasibility Study 5.0 System Planning 255

Thorough consideration and documentation of the required issues Clarity of both the value and risks inherent in the proposed solution The delivery of the outcomes and benefits can be traced and measured Inclusion of all factors relevant to a complete evaluation Clearly relevant and logical contents which are simple to evaluate Direct justification of key elements in a transparent manner Clear accountability and commitment for the delivery of benefits and management of costs

Later, the business case will be used as a starting point to develop more detailed information for the feasibility study that supports the IAPD.

From Business Case to APD

The need for an APD relies on the needs assessment, based on the relationship to dollar thresholds established in law and regulations, types of action/approval sought, program funding source, or type of funding sought. The appropriate State agency decision maker will use the business case from the needs assessment to determine the need for an APD. If the decision is to proceed with the project and request Federal financial participation (FFP), the State agency begins preparing the APD, using information from the business case.

5.3 Feasibility Study

Given the complex nature of system development and the interdependence of technical, program, fiscal, and operational considerations, a team approach is recommended. The team may consist of a variety of individuals with different skills and backgrounds (e.g., accounting, budget, program, or IT). Managers, business analysts, system analysts, programmers, and program analysts may also play a role. If the proposed system is integrated with other programs, specialists from those programs may either be included formally or be used on a consultant basis for the team. The size and composition of the team may also depend on the type and complexity of the proposed project. The important factor in the formation of the team is that its size and composition is sufficient to allow a comprehensive, well-coordinated project.

The feasibility study is a tool to help the State agency analyze, compare, and make sound decisions. It is a preliminary study that determines whether the project being considered is technically, financially, and operationally viable. The feasibility study occurs after approval of the PAPD. It builds on the needs assessment, See chapter 3.0 The Advance Planning Document Process for details on preparing the

APD.

5.3 Feasibility Study 5.0 System Planning 256

the initial business case, and the PAPD. It is an integral part of building the IAPD. See Figure 42 (page 246) for a depiction of the relationship between the Needs Assessment and the Feasibility Study.

The feasibility study uses the current system as a baseline to begin the comparative analysis of alternatives. A feasibility study includes three major activities: requirements analysis, alternatives analysis, and cost benefit analysis. Before considering alternatives, the State agency must know what capabilities and functions it needs the alternatives to provide; in other words, the functional requirements of the ideal solution. Alternatives analysis identifies the most likely candidates that can satisfy the scope and requirements for the project. Once a list of alternatives has been established that meet the functional requirements, they must be evaluated for technical, remaining alternatives are compared based on cost to decide which alternatives provide the most benefits. Each of these activities needs to include risk analysis.

The feasibility study identifies the approaches that can be used to meet the program objectives of improved effectiveness and efficiency of operation and administration. The purpose of the feasibility study is not to circumstances such as budget and schedule.

The outcome of the feasibility study should identify what system(s) might be functionally, technically, and operationally feasible for the State based on current circumstances and needs. Based on the analysis, there may be more than one feasible system. It may also be possible that none of the options are feasible resulting in a go/no- Table 23 provides an overarching synopsis of feasibility study guidelines and related documentation requirements for the

IAPD.

For SNAP, the alternatives analysis should assist the State agency to identify any possible need to request a waiver of program requirements.

The Feasibility Study is a required component of the Implementation Advance Planning Document (IAPD) for SNAP and WIC projects.

5.3 Feasibility Study 5.0 System Planning 257

Table 23: Feasibility Study Guidelines

Content/Issues Information to be Addressed

General Information/

Provide a brief description of the present system:

o Is the present system integrated with another public assistance or health system?

o What is the age of the current system? Does it meet the functional requirements of the program(s)?

o What Federal, State, and local programs will the new system service?

o What are the roles of other offices that will be involved (e.g., IT finance, Management Summary

Objectives:

Compliance with regulations

Increased processing speed

Increased productivity and streamlined business processes

Improved IT services

Improved implementation of program policies and decision making Requirements:

Increased capacity (e.g. number of users that may be supported, number of offices, number of mobile sites)

New technical requirements (e.g., a statewide standard)

Improved privacy and security (e.g., must be HIPAA compliant or meet state-specific security standards)

Improvements in management controls Assumptions and Constraints:

Operational life of the proposed system

Availability of information and resources

Financial constraints (e.g., a specific program function was mandated to be completed within a given time frame)

Legislative and policy constraints

See section 3.3.2.3 for related IAPD Documentation Requirements.

5.3 Feasibility Study 5.0 System Planning 258

Content/Issues Information to be Addressed Technical constraints (e.g., changing hardware/software/operating environment, new equipment must be compatible with existing)

Operational constraints (e.g., constraints imposed by an outside agency if the proposed system will be integrated with other public assistance programs)

Alternatives Analysis

Methodology:

Identify how the analysis was accomplished and how the alternative system(s) were evaluated

Summarize the general method or strategy employed; such as surveying, weighing, modeling, benchmarking, or simulating

Evaluation Criteria:

Identify the criteria to be used to determine the viable system(s); including the relative technical, fiscal, and operational advantages and the ability to meet the system requirements specified in the functional requirements document

Alternatives:

Describe each alternative system in terms of methodology and the degree to which it meets the established objectives and evaluation criteria within the framework of the aforementioned constraints

Include alternative systems deemed to be infeasible and specify the reasons for this conclusion (include the alternative analysis elements described in section

5.3.2.1 Minimum Alternatives)

Proposed System(s)

Technical Maturity - Describe the level of technical maturity for the potential solution. The description may address questions such as:

Is the potential solution technically proven or a recent innovation?

Has the proposed technology solution fully matured?

Is it nearing obsolescence?

Are services and expertise required to support the potential technical solution readily available?

What is the estimated lifecycle and longevity of the solution?

Equipment Effects:

Describe how new equipment requirements and changes to currently available equipment will be met; for example, do current hardware, telecommunications, and/or network services have the capacity to meet new system requirements

5.3 Feasibility Study 5.0 System Planning 259

Software Effects:

Describe any required additions or modifications needed to existing applications and support software to adapt them to the proposed system(s) and explain how such needs will be met

Describe any data conversion activities that will be necessitated by adoption of the proposed system

Organizational Effects:

Describe any organizational, personnel, and skill requirements that will change and how the change will be handled

Program Effects

Describe any conflicts or need to request a waiver (SNAP only) from program requirements

Resource Effects

Management, programmatic, and technical resource requirements

Computer processing resources required to develop, convert, implement, and test the new system(s)

Continued support for current system operations Operational Impacts- How the development process will take into account the effects on operations:

User operating procedures

Operating center procedures

Operating center and user relationships

Telecommunications impacts on the operating center and user sites

Source data processing

Data retention requirements and information storage and retrieval procedures

Output reporting procedures, media, and schedules

System failure consequences and recovery procedures

Site/Facility Effects:

Describe building modification requirements and how they will be met

5.3 Feasibility Study 5.0 System Planning 260

Content/Issues Information to be Addressed Fiscal Impacts:

Describe cost factors that may influence the development, design, and continued operation of the proposed system(s)

Identify the estimated total developmental cost and estimated annual operating costs and who will pay for these expenses

Justification:

State the reasoning that supports the selection of the proposed system(s) based on the aforementioned evaluation criteria and elimination of other alternatives

Proposed Schedule

For any alternative still being considered after the alternatives analysis, outline a proposed schedule for all implementation activities; such as systems design, development, testing, quality assurance, data conversion, and deployment and address the following components:

o Specific activities to be performed by the user in support of development of the proposed system(s) o Major milestones and management decision points

Requirements Analysis

The feasibility study begins with requirements analysis; State agencies should carefully define their criteria for the new system prior to performing the alternatives analysis. Requirements establish the scope of the technical capabilities needed. High-level objectives identified during the needs assessment are further expanded to include primary requirement needs. The focus is to satisfy the defined business capabilities needed, not build an exhaustive list of every detail of performance and capability. Requirements analysis uses the Functional Requirements Document (FRD) as a baseline to assess the ability of various alternative approaches to meet defined requirements. Requirements need to be of sufficient detail to assess what alternatives are available and capable of meeting the business needs.

Policy Related System Requirements

During systems analysis, the State agency needs to consult applicable FNS policies related to system technical requirements.

SNAP Requirements in in 7 CFR 272.10(b)(1), (b)(2)(vii) through (xiii), and (b)(3).

SNAP System Integrity Review Tool

SNAP EBT 7 CFR 274.1

5.3 Feasibility Study 5.0 System Planning 261

WIC Functional Requirements Document (FReD) for a Model WIC Information System

WIC EBT 7 CFR 246.12

Requirements analysis involves business analysis, business needs assessment, and systems analysis.

5.3.1.1 Business Analysis

Business analysis is a key activity during requirements analysis. (For more information on business analysis see section 5.2.1). Inefficient processes should be improved, or reengineered, before requirements are defined. This is especially true if the State agency intends to automate business processes that have been manual prior to the proposed project. BPR/I at this stage will minimize the need for technology customizations in alternative solutions. Customization is expensive. While systems analysis is important during requirements analysis, business analysis should take priority.

5.3.1.2 Business Needs Assessment

Business needs are initially explored, in a more general way, during needs assessment as part of the business capability definition and related business analysis activities. (See section 5.2). During the requirements analysis phase of the feasibility study, business needs should be more thoroughly analyzed as part of business needs assessment. The analysis of business needs during the feasibility study is more detailed than during the needs assessment. This is so that the level of detail is sufficient for producing fully defined requirements. This effort will contribute significantly to fully defining what requires a technology solution versus what can be resolved with BPR/I prior to undertaking a technology solution.

http://origin.drupal.fns.usda.gov/sites/default/files/FReD%20v2.0%20Final.pdf

See chapter 9.0 Systems Security for additional technical requirements based on federal policy.

Business analysis includes Business Needs Assessment, Business Process Analysis (BPA) and Business Process Reengineering and/or Improvements (BPR/I).

5.3 Feasibility Study 5.0 System Planning 262

5.3.1.3 Systems Analysis

Systems analysis is more technically oriented than business analysis, and should be performed for the existing system. It is focused on breaking a system down into its component parts and functions; in this case an IT system or database system. The purpose is to establish how all of the component parts interact with each other. Systems analysis activities help define technical interfaces within the system as well as to external systems. Data structures for storing information and exchanging information are analyzed for interoperability. These are all important elements for requirements analysis. System analysis will lead to the generation of accurate technical requirements which ensures that the new system is compatible with the existing system and any additional systems that it must interface with. During systems analysis, State agencies need to refer to FNS requirements for SNAP, WIC, and EBT systems.

5.3.1.4 System Integrity Review Tool Analysis for SNAP

The objective of systems development is to design a system that meets the needs of the user, not just the system specifications. Confirming that the developed system meets all user requirements is the function of user acceptance testing.38 However, the system design requirements are the first step in development; understanding the criteria for testing begins during requirements analysis. If a requirement is not testable, or a required regulatory capability is not part of the design, testing will fail to accomplish its purpose. State agencies are required to develop sufficient automation and to adhere to multiple policies in order to receive federal funding for automation projects. Sufficient automation levels are those that result in effective programs or in cost-effective reductions in errors and improvements in management efficiency.39 FNS has developed a SNAP System Integrity Review Tool40 to be completed by State staff for review by FNS Regional Office staff, to ensure automation projects adhere to all policy requirements.

The SNAP APD process described at 7 CFR 277.1841 states that FNS may conduct reviews of the system either prior to pilot, once it is fully operational statewide, or both. The review may include regulatory and policy requirements, system controls and performance, and system security, amoung other topics, as its foundation. Although the System Integrity Review Tool is intended to be used prior to User Acceptance Testing, and again after statewide implementation to validate functionality, it is also useful during requirements analysis. State agencies should use this tool as part of their requirements analysis to understand what system capabilities must be considered in the design. FNS will use this same tool for UAT, pilot, and possibly post-implementation reviews.

5.3 Feasibility Study 5.0 System Planning 263

5.3.1.5 WIC Functional Requirements Document (FReD)

The WIC FReD for a Model WIC IS addresses systems that support a number of WIC program operations and management functions such as certifying applicants, monitoring food vendors, tracking participation and expenditures, and managing appointments. This document also incorporates basic functions for an EBT system. The document is intended to help State agencies prepare the FRD for the IAPD, as well as RFPs for IS services, and to serve as guidance to in-house

IT staff developing a WIC IS.

5.3.1.6 System Integrity Review Tool Analysis for WIC

The WIC program is subject to the same reviews of the system either prior to UAT, once it is fully operational statewide, or both.42 FNS has developed two tools for the WIC program for System Integrity Reviews: the WIC MIS System Integrity Review Tool43 and a Functional Area Spreadsheet.

The review tool is intended to be used by the State agency during their planning and design stages as a list of data elements and system functions desirable for a WIC MIS. As with SNAP, it is intended to conduct State agency pre- and post-implementation reviews.44

5.3.1.7 FNS Requirements for WIC EBT Systems

In the IAPD, the State agency must provide assurances that the WIC EBT system will comply with all FNS standards. Therefore, the State agency must include the following in developing EBT requirements:

National Universal Product Code (NUPC) Database. Each State agency will submit copies of their Authorized Product List (APL) to the NUPC database as items are added, updated, or removed. If the State agency intends to utilize the NUPC Database to maintain, create, or distribute its APL, the IAPD must include State agency assurances that the State agency will utilize the UPC Category/Subcategory coding scheme developed by FNS. This will permit the State agency to utilize UPC/PLU data downloaded from the NUPC without translating this into a State agency specific category and subcategory coding scheme.

Refer to the WIC Functional Requirements Document (FReD) for details.

Copies may be obtained from the FNS website: http://www.fns.usda.gov/apd/WIC-FReD.

5.3 Feasibility Study 5.0 System Planning 264

Technical Standards. The State agency must agree to use the ASC X9, Inc. standards for WIC EBT, commonly known as ANSI X9.93. These are formats for standard messages and batch files necessary for WIC EBT processing for online and offline WIC EBT systems. Formats must conform to the most current version, but capability to support prior versions (backward compatibility) is necessary until all industry players have updated. EBT cards must be consistent with industry card standards for magnetic stripe cards and smartcards used in financial payment systems.

WIC EBT Operating Rules and Technical Implementation Guide (TIG). The State agency must make a commitment to use the Operating Rules and TIG developed for WIC EBT (see the FNS WIC EBT Technical Documents on Partnerweb§§§§ for more information).

WIC Universal MIS to EBT Interface Guideline. The State agency must agree to use the Universal Interface document as a guide in development of an interface between the State agency IS and EBT systems whether on-line or off-line technology is used.

5.3.1.8 Functional Requirements Document

hat is required for the IAPD. Specifications must be based upon a clear and accurate description of the functional requirements for the project. The FRD identifies the requirements analysis and desired system functionality for all aspects of program operations. This is a primary document needed for the alternatives analysis, as well as later SDLC system design activities.

The FRD should include:

Mandatory absolute functionality encompassing Federal and State requirements. This list should not take short-cuts, but be realistic about what is mandatory.

-offs when it comes to selecting a best fit alternative. Or, they can become the enhancement list for future projects.

This document serves as a touchstone for the project when defining specifications, providing developers (whether contracted or in- It serves as guidance to program and IT staff in developing an IS. State agencies are urged to ensure this document is kept up to date as the project progresses, noting decisions or changes to requirements. The FRD is also a reference for testing. When the project is complete, the FRD provides a historical view of the requirements and how they were met with changes noted.

The FRD serves as a reference document during operations and maintenance as well.

§§§§ www.Partnerweb.usda.gov is a password protected system. Contact the relevant FNS Regional Office for access.

5.3 Feasibility Study 5.0 System Planning 265

Alternative Analysis

Unless the State agency is introducing new technology or architecture, the primary focus of the feasibility study for FNS systems is the alternatives analysis. A State agency must perform an analysis of representative alternatives for hardware, software, and program functionality to determine the type of system that best meets its needs. The alternatives analysis involves identifying viable candidates to meet the requirements identified in the high-level objectives and technical scope; in other words, the results of the requirements analysis activities. What are alternatives? They can be almost anything the State agency believes is practical for meeting their needs.

incorporating off-the-shelf solutions, or initiating custom development when more cost-effective and timely solutions do not exist.

5.3.2.1 Minimum Alternatives

Typically, States use the following four alternatives in their analysis:

Upgrading or enhancing the existing State system Transferring a system or components from another State Developing a new system from the ground up Cloud computing options ranging from a hosted environment to subscriptions for online products

FNS recommends including a minimum of three alternatives in the analysis, to be sure that the best solution is found. Below are some examples:

Table 24: Minimum Alternatives

Alternatives Considerations

System Upgrade or Enhancement State agencies should consider this alternative. If it is not an available option, an explanation of why it is not must be included with the alternative analysis.

In competitive procurements, the FRD must not lead to requirements that unduly restrict competition. The FRD assists State agencies in preparing an RFP for development contractors and associated implementation services.

5.3 Feasibility Study 5.0 System Planning 266

Table 24: Minimum Alternatives

Alternatives Considerations

Transfer of another State system

This may include the entire system, or only some components (best of breed).

It is usually appropriate to include systems from more than one other state in the analysis, as they represent different approaches to meeting similar requirements.

Some things to remember when considering a transfer system are:

State agencies need to analyze obstacles to the transfer and modification of an existing system.

Compare the costs of overcoming the problem(s) in transferring an operational system to the costs of developing a new system.

transfer system may be. State agencies sometimes start with a transfer when they really want a new build. In some cases, transfers can end up costing the same, if not more, than an original build or the original cost of the transfer system.

Is it possible or in the best interest of the program to change/update existing business processes? This may reduce the number of changes required to a transfer system.

Developing or Implementing a new system

Depending on the age of the legacy system, and the technology it is built upon, there may come a point where it cannot be upgraded or enhanced enough to meet new technical standards.

Building a new system, or implanting a COTS solution, allows the State agency to consider new innovations, and brings it up-to-date with technology that is sustainable into the future.

All potentially viable alternatives should be included in the analysis. FNS will not accept the results of an alternatives analysis which compares only a pre-selected favorite to clearly non-

Alternatives must also include the analysis of technical and programmatic merits of possible system transfers:

Will existing equipment be usable or will new PCs and/or servers need to be purchased? What about the communications infrastructure - will it support the alternative?

Are there trade-offs that can be made between technology and business processes? If the business process is changed, will it minimize the potential changes to a system?

Appendix A4 includes a System Type and Acquisition Selection Tool to assist State agencies in narrowing down their alternatives.

5.3 Feasibility Study 5.0 System Planning 267

In many cases, the most cost-effective alternative is a transfer with minimal changes. Modifying software code is where the biggest development costs occur. This is why complete new builds are rare. However, under-estimating the amount of work and/or the number of changes needed to make a transfer system fit the State agency , are some of the major reasons why system transfers have s important to resources.

FNS will assist State agencies that request assistance in identifying other States with systems that should be considered for possible transfer. State agencies should contact those States with systems in which they are interested, to arrange for the sharing of available software and system documentation within a reasonable timeframe. State agencies need to analyze obstacles to the transfer or modification of an existing system and compare the cumulative costs of overcoming the problem in transferring an operational system, to the costs of developing a new system.

5.3.2.2 Other Alternative Considerations

Platform (or architecture) alternatives range from stand-alone solutions to mainframes, distributed networks, or web-based systems. Requirements for capacity may affect platforms as well as other options.

WIC must consider a State Agency Model (SAM) system transfer with as little change in functionality as possible, among the alternatives under consideration. (See section 0 for more on SAMs).

5.3 Feasibility Study 5.0 System Planning 268

Table 25: Alternative Platforms/Capacity Enhancement

Architecture

Client/server LAN and micros

Distributed

Web-based

Mainframe

Capacity of current hardware, telecommunications, and network components

Outsourcing (contracting out)

Acquire services (other than equipment)

From other State agencies (central IT)

Commercially

Reconfigure existing resources

Use of non-automated alternatives

Reallocating or re-training personnel

Revising business processes and/or operational flow

Table 26: Labor Alternatives

Labor Source

Acquisition Type Using in-house services

Using contract services

Using combination

Using shared system

Using shared services

Transferring/Modifying

Modifying or Redesigning Current System

Custom Development

System Hosting by Another State

Services include teleprocessing, computer time, electronic mail, voice mail, cellular telephone, and web services.

Alternatives include both in-house and contractual solutions, as well as sharing and borrowing resources. Support services include source data entry, training, custom software development, business analysis, systems analysis

5.3 Feasibility Study 5.0 System Planning 269

and design, software conversion, facilities management, maintenance, equipment operation, network management, studies, and evaluation.

Table 27: Alternatives for Acquiring Services

Increase or utilize In-House Resources

In-House Development of Service Capability

Resource Sharing with Other State Agencies

Contractual Commercial Services

Temporary Commercial Services

Manpower-based

Project-based

Full Service, Per Call, On Call

Temporary Commercial Services

5.3.2.3 WIC State Agency Model Systems (SAM) Alternatives

or acquisition of a non-SAM WIC IS, approval of a WIC system is accomplished using the APD process. FNS initiated the SAM project to promote the development of model IS for WIC State agencies. Specifically, the SAM initiative supports multi-State consortium efforts to plan, design, and develop model systems and to deploy the models in multiple State agencies. The goals of the project are to increase efficiency and eliminate or significantly reduce cost and duplicative efforts across WIC State agency systems, as well as to ensure that systems meet WIC policy and regulatory requirements.

To optimize its investment, FNS requires SAM systems be considered in the Feasibility Study/Alternatives Analysis.

The benefits of transferring a SAM are the following:

Model system software is already developed SAMs are fully functional and EBT-ready State agencies may receive priority funding for model system transfer and implementation, as well as some ongoing support costs for SAM Users Groups.

5.3 Feasibility Study 5.0 System Planning 270

State agencies transferring a model system will maximize their Nutrition Services and Administration (NSA) funds.

This is because the cost of software maintenance will be incurred only once and distributed to all States within

Under some circumstances, a SAM model may not meet State agency needs. If, after initial evaluation, it is determined that a SAM system is not viable, the State agency may exclude that alternative from further detailed comparison in the Feasibility Study/Alternatives Analysis, as long as valid justification is provided. The justification must demonstrate a good effort on the part of the State agency to consider a SAM system and not dismiss a SAM merely for an unexamined preference.

Examples of acceptable justification include the following:

All SA

If a SAM is selected, the State agency must list and explain in the IAPD any planned or desired modifications to th transferring a SAM are required intentions must be made clear in the IAPD.

1. - ers Group; submitting its

2.

rity funding considerations.

The WIC program expects that SAM transfers can be done at a minimal or reduced cost. State agencies can implement the system themselves or prepare competitive procurements to hire implementation contractors.

Consult with FNS for details on each SAM system.

REMEMBER, especially for a WIC SAM transfer using SAM grant funding, FNS anticipates minimal changes to the functionality upon initial transfer.

5.3 Feasibility Study 5.0 System Planning 271

5.3.2.4 WIC EBT System Alternatives Analysis

An Alternatives Analysis is not an IAPD requirement for EBT systems. However, if a State agency chooses to develop one, the following components should be considered in determining the most

WIC Information System Capability Assess the readiness and practicality of adapting the WIC IS (or a transfer IS) to electronically issue and track benefits WIC Business Capacity Assess the skills, abilities, and organizational impact an EBT system will have on WIC Program and IS staff and services.

Retail Vendor Technical Capabilities Survey a sample of WIC-approved vendors for their readiness for EBT. Assess their ability, readiness, and desire to integrate EBT into their Electronic Cash Register (ECR) systems Retail Vendor Equipage Analyze and plan for retailer equipage strategies; single function and multifunction Financial Considerations Assess EBT effects on financial payments to vendors through the State agency, a bank, or via a future EBT contractor State versus Contractor Responsibilities Assess whether on-going EBT needs are best handled by State agency staff or an EBT processor or another contractor. Some needs may be a shared responsibility (e.g., 24/7 help desk support) Infrastructure Considerations Assess WIC clinic telecommunications capabilities to support card and benefit set-up, and any other operational issues for the chosen technology Recommend a Technical Solution Analyze one or more alternative implementation approaches and assess which one is the most viable and affordable solution. A State agency may choose to prepare an EBT IAPD based on one technology or may examine both online and offline alternatives Recommend a Plan Develop a recommended 2-5 year proposed EBT implementation plan in the State agency. The State agency may need to include some of this alternative analysis if they determine that they need to obtain an exception to the 2020 EBT mandate

5.3.2.5 Performing Alternatives Analysis

Gap analysis is the central activity of completing the comparison of alternatives. Each alternative needs to have

y. Viable alternatives should be those that best fit the scope and requirements of the project. Cost control is always a key objective. When considering COTS or a system transfer, minimizing the number of changes or customizations will reduce costs. This can dictate the best fit for the State, the budget, and the schedule. The gap analysis is extremely

5.3 Feasibility Study 5.0 System Planning 272

helpful to determine missing or weak functionality in any systems being considered. This also goes for technical requirements of the system. Gap analysis may reveal the need to return to requirements analysis.

The gap analysis answers two critical questions required when selecting the most appropriate system for the State

How big is the gap between the - and each of the available options?

How big is the gap between the - , available budget, and resources) and each of the available options?

The answers to these questions provide these constraints: how much can be spent to complete the system, and the maximum period of time the system must be completed in.

Once the gap analysis is performed for each alternative, then the alternatives may be measured against one another. The best fit solution should become clear. If not, then the alternatives selected and the mandatory and optional requirements may need to be revisited.

The FRD developed for the project during requirements analysis should be used to measure the alternatives. How If a system transfer is one alternative, get a working version if possible, and the documentation. Perform the analysis to make sure the system will meet the needs. Perform a gap analysis of program functional and technical requirements. It is important to be sure to apply the exact same analysis methodology for each alternative examined. When performing a gap analysis of functionality, include subject matter experts in the discussions and review. Based on the FRD, do all mandatory requirements exist in the alternative? Is the State willing to pay to have them added? Analyze how many changes would be needed for each alternative to meet the needs. Minimal changes are the goal.

The alternatives analysis is a comparison that focuses on the technical, operational, and functional differences between the alternatives and the requirements.

Table 28: Gap Analysis Functional Area Gap Analysis Considerations

System interfaces (Technical)

What impacts will the alternative have on any existing systems or interfaces needed to conduct business?

For WIC, does the system deliver benefits using EBT?

Information verification processes?

Data sharing/exchange capability?

Integration with other State Health Care or Human Services systems?

5.3 Feasibility Study 5.0 System Planning 273

Table 28: Gap Analysis Functional Area Gap Analysis Considerations

Personnel and Training (Operational)

What effect will the alternative have on existing personnel and the skills required?

Will there be an impact on the number of staff required?

Will there be a big learning curve for staff?

Will new staff need to be hired with different skill sets?

How much training will be required to bring current staff up to speed?

the business processes be adapted to this system?

Data Migration & Conversion (Functional)

Will data conversion activities add cost to the project?

What about data cleansing?

How much time will it take to reformat the data, add missing elements, etc., both before and after conversion?

How much staff time and cost will be required?

Has sufficient planning been done?

Conducting a thorough gap analysis of all alternatives is vital in assisting the State to determine which alternative alternatives analysis results are known, the State agency can compare the cost effectiveness and long-term benefits from upgrading its existing system, transferring an existing system from another State, or developing a new system.

Cost Benefit Analysis

Because more than one system may be functionally, technically, and operationally feasible, the State agency needs another tool to help it select the best system. The Cost Benefit Analysis (CBA) is used to estimate the costs for the existing system and each system alternative. It will estimate costs for the nonrecurring (design, development, and implementation) and recurring (operations and maintenance) components of each alternative. This decision-making tool helps to further narrow the possibilities and arrive at the best system for the St and circumstances.

The CBA determines which alternative will provide the greatest benefits relative to its costs. The analysis provides, by funding source, the estimated cost of developing and operating each alternative found to be viable through the feasibility study. The analysis identifies the tangible and intangible benefits related to each funding source.

The IAPD must show that a meaningful CBA was performed as a part of comparing alternatives. However, it does

5.3 Feasibility Study 5.0 System Planning 274

not require calculating a number of years to the break-even point or tracking and reporting the CBA beyond initial approval of the IAPD. It should:

Describe cost factors that may influence the development, design, and continued operation of the proposed system(s) Identify the estimated total developmental cost and estimated annual operating costs Identify funding sources for these expenses Determine which alternative will provide the greatest benefits relative to costs

A CBA is required for large-scale software development. It is not required for routine equipment replacement and upgrades.