snap and tanf eligibility systems, enterprise architecture

STATE OF MONTANAREQUEST FOR PROPOSAL (RFP)

RFP Number:RFP09-1694P

RFP Title:SNAP AND TANF ELIGIBILITY SYSTEMS, ENTERPRISE ARCHITECTURE, AND FISCAL SERVICES

RFP Response Due Date and Time:July 30, 2009

2:00 p.m., Local TimeNumber of Pages: Part 1 of 3, 83 pages

ISSUING AGENCY INFORMATIONProcurement Officer:Penny Moon

Issue Date:May 29, 2009

State Procurement BureauGeneral Services Division

Department of AdministrationRoom 165, Mitchell Building

125 North Roberts StreetP.O. Box 200135

Helena, MT 59620-0135

Phone: (406) 444-2575Fax: (406) 444-2529TTY Users, Dial 711

Website: http://vendor.mt.gov/

INSTRUCTIONS TO OFFERORS

Return Sealed Proposal to:

State Procurement BureauGeneral Services Division

Department of AdministrationRoom 165, Mitchell Building

125 North Roberts StreetP.O. Box 200135

Helena, MT 59620-0135

Mark Face of Envelope/Package:

RFP Number: RFP09-1694PRFP Response Due Date: July 30, 2009, 2:00 p.m.

Special Instructions:Mandatory Pre-Proposal Conference June 23, 2009 1:00 p.m., Local Time

IMPORTANT: SEE STANDARD TERMS AND CONDITIONS

OFFERORS MUST COMPLETE THE FOLLOWING

Offeror Name/Address: Authorized Offeror Signatory:

(Please print name and sign in ink)

Offeror Phone Number: Offeror FAX Number:

Offeror E-mail Address:

OFFERORS MUST RETURN THIS COVER SHEET WITH RFP RESPONSE

Revised 2/09

http://gsd.mt.gov/

TABLE OF CONTENTS

SCHEDULE OF EVENTS..........................................................................................................................4

SECTION 1. PROJECT OVERVIEW AND INSTRUCTIONS / ADMINISTRATIVE REQUIREMENTS..............................................................................................................5

1.0 OVERVIEW.............................................................................................................................................51.1 CONTRACT TERM..................................................................................................................................61.2 SINGLE POINT OF CONTACT...............................................................................................................71.3 REQUIRED REVIEW...............................................................................................................................71.4 PROCUREMENT LIBRARY....................................................................................................................81.5 PRE-PROPOSAL CONFERENCE..........................................................................................................81.6 GENERAL REQUIREMENTS..................................................................................................................81.7 SUBMITTING A PROPOSAL................................................................................................................101.8 COST OF PREPARING A PROPOSAL................................................................................................11

SECTION 2. RFP STANDARD INFORMATION............................................................................122.0 AUTHORITY..........................................................................................................................................122.1 OFFEROR COMPETITION...................................................................................................................122.2 RECEIPT OF PROPOSALS AND PUBLIC INSPECTION....................................................................122.3 CLASSIFICATION AND EVALUATION OF PROPOSALS...................................................................122.4 STATE’S RIGHTS RESERVED............................................................................................................142.5 DEPARTMENT OF ADMINISTRATION POWERS AND DUTIES........................................................152.6 COMPLIANCE WITH STATE OF MONTANA IT STANDARDS............................................................15

SECTION 3. RFP INTRODUCTION AND BACKGROUND......................................................163.0 GENERAL INFORMATION...................................................................................................................163.1 BACKGROUND INFORMATION...........................................................................................................183.2 RFP ORGANIZATION...........................................................................................................................24

SECTION 4. GENERAL REQUIREMENTS.....................................................................................254.0 INTRODUCTION...................................................................................................................................254.1 CONTRACTOR RELATIONSHIP WITH DEPARTMENT AND OTHER CONTRACTORS...................254.2 PROJECT MANAGEMENT AND REPORTING....................................................................................254.3 CONTRACTOR COMMITMENT TO QUALITY MANAGEMENT..........................................................274.4 CONTRACTOR TRANSPARENCY, ACCOUNTABILITY, AND RESPONSIBILITY.............................284.5 COMMUNICATION REQUIREMENTS.................................................................................................284.6 COMPLIANCE WITH FEDERAL REQUIREMENTS.............................................................................294.7 SECURITY, CONFIDENTIALITY, AND AUDITING...............................................................................294.8 TECHNICAL REQUIREMENTS............................................................................................................31

SECTION 5. PHASE-SPECIFIC REQUIREMENTS.....................................................................415.0 OVERVIEW...........................................................................................................................................415.1 START UP PHASE................................................................................................................................425.2 DETAILED REQUIREMENTS DEFINITION PHASE............................................................................445.3 DESIGN PHASE....................................................................................................................................465.4 CONSTRUCTION PHASE....................................................................................................................485.5 CONVERSION.......................................................................................................................................505.6 TESTING PHASE..................................................................................................................................525.7 PILOT PHASE.......................................................................................................................................575.8 IMPLEMENTATION PHASE.................................................................................................................60

RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services,

5.9 OPERATIONS AND MAINTENANCE PHASE......................................................................................625.10 TURNOVER PHASE.............................................................................................................................675.11 MAJOR MILESTONES SUMMARY......................................................................................................685.12 REQUIRED DELIVERABLES SUMMARY............................................................................................69

SECTION 6. ENTERPRISE ARCHITECTURE...............................................................................726.0 OVERVIEW...........................................................................................................................................726.1 SERVICE-ORIENTED ARCHITECTURE..............................................................................................736.2 ENTERPRISE SERVICE BUS..............................................................................................................736.3 WEB PORTAL.......................................................................................................................................746.4 SINGLE SIGN-ON.................................................................................................................................766.5 SHARED INFORMATION AND WEB SERVICES................................................................................776.6 INTERSYSTEM NAVIGATION..............................................................................................................796.7 ENHANCING CHIMES-MEDICAID.......................................................................................................81


SCHEDULE OF EVENTS

EVENT DATE

RFP Issue Date May 29, 2009

Deadline for Receipt of First Round of Written Questions June 19, 2009

Pre-Proposal Conference June 23, 2009

Deadline for Receipt of Second Round of Written Questions June 26, 2009

Deadline for Posting Written Responses to the State's Website July 9, 2009

RFP Responses Due Date July 30, 2009

Notification of Offeror Interviews/Product Demonstrations/Oral Presentations

September 4, 2009

Offeror Interviews September 8-11, 2009

Offeror Product Demonstrations/Oral Presentations September 8-11, 2009

Site Visits September 14-17, 2009

Intended Date for Contract Award October 2, 2009

Contract Finalized January 4, 2010


SECTION 1. PROJECT OVERVIEW AND INSTRUCTIONS/ADMINISTRATIVE REQUIREMENTS

1.0. OVERVIEW

The Department of Public Health and Human Services, hereinafter referred to as the Department or DPHHS, is soliciting competitive, responsive proposals from experienced and financially sound organizations to design, develop, support, and maintain for the State of Montana: A new Supplemental Nutrition Assistance Program (SNAP) eligibility system. (Note – SNAP was called the

Food Stamp Program until October 2008.)

A new Temporary Assistance for Needy Families (TANF) eligibility system.

Enterprise architecture for these two new systems and the existing Medicaid eligibility system.

A library of shared fiscal services to support the shared fiscal (accounts receivable and accounts payable) responsibilities associated with the issuance of eligibility and benefits for SNAP and TANF.

This is a unique development project because the TANF and SNAP eligibility systems will be developed as stand-alone systems in a highly coordinated environment. DPHHS is migrating from a legacy system supporting integrated eligibility determination for SNAP, TANF, and Medicaid to separate web-based systems that share common services and communicate through enterprise architecture.

The Department first replaced the Medicaid eligibility system with the Combined Healthcare Information and Montana Eligibility System (CHIMES). The new SNAP and TANF eligibility systems will leverage work completed in CHIMES-Medicaid because the three programs’ eligibility systems share a large number of functional commonalities. Leveraging development work completed in CHIMES will reduce the amount of time needed to develop the SNAP and TANF eligibility systems because much of the underlying structure is already in place.

Using CHIMES as a base for the TANF and SNAP eligibility systems will also help assure a common look and feel for system users, particularly Office of Public Assistance (OPA) eligibility workers, who will determine eligibility for SNAP, Medicaid, and TANF. The enterprise architecture and its service-oriented architecture will coordinate the three systems seamlessly, meaning end users will use the separate eligibility systems as if they were one integrated system determining eligibility for three programs.

The system name is an important component of its look and feel. In order to create consistency with the new Medicaid eligibility system, the SNAP eligibility system will be called the Combined Healthcare Information and Montana Eligibility System-SNAP (CHIMES-SNAP) and the TANF eligibility system will be called the Combined Healthcare Information and Montana Eligibility System-TANF (CHIMES-TANF). The original CHIMES system will now be called the Combined Healthcare Information and Montana Eligibility System-Medicaid (CHIMES-Medicaid). All three systems will jointly be called CHIMES.

DPHHS envisions the contractor’s enterprise architecture solution for these three systems becoming the architecture standard used by the Department going into the future. New systems being developed and implemented in the future will use the enterprise architecture solution developed by the successful offeror to this RFP.

Detailed functional requirements and contractor responsibilities for the systems, enterprise architecture, and the shared fiscal services layer (SFSL) are provided in Sections 6, 7, 8, 9, and 10 of this RFP. Offerors should carefully read and understand all RFP responsibilities, performance requirements, and terms and conditions before responding.


1.0.1. Procurement Objectives The objective of this procurement is to select a contractor or a contractor and its subcontractors to design, develop, and implement new SNAP and TANF eligibility systems, an enterprise architecture solution, and associated shared services, including a SFSL for DPHHS. CHIMES-TANF and CHIMES-SNAP will leverage work completed in CHIMES-Medicaid. These three systems and all their components must coordinate with the development of other systems in the Department and the State. The Department anticipates that these systems will have an expected useful life of 20 years or more.

In planning this procurement, DPHHS developed the following guiding principles to meet their objectives for the CHIMES-SNAP, CHIMES-TANF, enterprise architecture, and SFSL contract:

Maximize competition so the Department receives the best and most creative technical solutions for the enterprise architecture and the eligibility systems.

Develop a quality RFP that increases accountability and meets the needs of the State by: o Thoroughly documenting requirements to elicit the optimum pricing and minimize future

misunderstandings.o Clearly defining and documenting contractor and Department roles, responsibilities, and scope of

work to provide a clear, firm base for the development contracts to reduce risk to the Department.o Maintaining eligibility focus to determine scope and priorities.o Documenting reasonable performance measures and standards.o Clearly identifying Department expectations.o Allowing a thorough State review prior to release.

Develop an RFP to meet SNAP-specific and TANF-specific goals, including:o Creating flexible, reliable, easily updateable, accurate, and easily maintainable systems.o Ensuring single data entry capability for the three eligibility systems.o Developing user-friendly eligibility systems from the Department and client perspectives.o Incorporating efficient interfaces and interoperability to allow for future collaboration with other

states and other Montana programs.o Allowing for comprehensive, flexible, usable, ad-hoc and scheduled reports for case management

and program management.o Ensuring robust and controllable system access and security.o Coordinating common functions across TANF, SNAP, and Medicaid eligibility systems.o Incorporating sound fiscal processes.o Developing well-defined data fields and rules so the eligibility systems serve the right people with

the right services at the right time.

The purpose of guiding principles is to set priorities, establish boundaries, and allocate resources for the success of the CHIMES-TANF, CHIMES-SNAP, and enterprise architecture project. They will be used by the project to govern the decision-making phases and will be expanded as needed.

1.1. CONTRACT TERM

The contract term is for a period of five years beginning December 2009 and ending September 2014. The Department anticipates the design, development, and implementation portion of the contract will last two years. A one-year warranty period and a three-year maintenance period, with the first year running concurrently with the warranty period, will begin at the completion of the design, development and implementation (DDI) work after the successful offeror meets the Department’s system acceptance criteria.

Renewals of the maintenance contract, by mutual agreement of both parties, may be made at one-year intervals, or any interval that is advantageous to the State. This contract, including any renewals, may not exceed a total of ten years, at the option of the State.


The Department expects the DDI of the shared fiscal services layer to be completed on a more aggressive schedule, to last one year, with a one-year warranty for that component, followed by State takeover of that shared fiscal services function. The Department believes that this shared fiscal services functionality will be developed and designed as a standalone process, whereby the shared services may be utilized by the Department prior to the completion of the CHIMES-SNAP and CHIMES-TANF systems.

The following table provides a detailed breakdown of the anticipated components for the stated contract term:

CONTRACT DATES MAJOR CONTRACT ACTIVITY

January 2010 – September 2011Design and development of CHIMES-SNAP and CHIMES-TANF and enterprise architecture

January 2010 – September 2010 Design and development of SFSL

October 2010 – September 2011 One-year warranty for SFSL

October 2011 – September 2012One-year warranty for CHIMES-SNAP and CHIMES-TANF systems

October 2011 – September 2014Three-year maintenance period for CHIMES-SNAP and CHIMES-TANF systems (with enterprise architecture)

October 2014 – September 2019Potential one-year contract extensions for CHIMES-SNAP and CHIMES-TANF maintenance and operations

1.2. SINGLE POINT OF CONTACT

From the date this Request for Proposal (RFP) is issued until an offeror is selected and the selection is announced by the procurement officer, offerors are not allowed to communicate with any State staff or officials regarding this procurement, except at the direction of Penny Moon, the procurement officer in charge of the solicitation. Any unauthorized contact may disqualify the offeror from further consideration. Contact information for the single point of contact is as follows:

Procurement Officer: Penny MoonAddress: State Procurement Bureau

Room 165, Mitchell Building125 North Roberts

PO Box 200135Helena, MT 59620-0135

Telephone Number: (406) 444-3313Fax Number: (406) 444-2529

Email Address: [email protected]

1.3. REQUIRED REVIEW

1.3.1. Review RFP Offerors should carefully review the instructions, mandatory requirements, specifications, standard terms and conditions, and contract set out in this RFP and promptly notify the procurement officer identified above in writing or via email of any ambiguity, inconsistency, unduly restrictive specifications, or error which they discover upon examination of this RFP. This should include any terms or requirements within the RFP that


mailto:[email protected]

either preclude the offeror from responding to the RFP or add unnecessary cost. This notification must be accompanied by an explanation and suggested modification and be received by the deadline for receipt of written or emailed inquiries set forth below. The State will make any final determination of changes to the RFP.

1.3.2. Form of Questions Offerors with questions or requiring clarification or interpretation of any section within this RFP must address these questions in writing or via email to the procurement officer referenced above on or before June 26, 2009. Each question must provide clear reference to the section, page, and item in question. Questions received after the deadline may not be considered.

1.3.3. State’s Response The State will provide an official written response by July 9, 2009 to all questions received by June 26, 2009. The State's response will be by formal written addendum. Any other form of interpretation, correction, or change to this RFP will not be binding upon the State. Any formal written addendum will be posted on the State's website alongside the posting of the RFP at http://gsd.mt.gov/osbs by the close of business on the date listed. Offerors must sign and return with their RFP response an Acknowledgment of Addendum for any addendum issued.

1.4. PROCUREMENT LIBRARY

A procurement library has been established for this procurement. The procurement library contains a number of documents and reference materials that may be useful in preparing a proposal in response to this RFP. A detailed list of its contents is included in Appendix 13.0. All possible effort has been made to ensure that library material is complete and current. However, the Department does not warrant that the information is, indeed, complete or current at the time of viewing.

The procurement library, containing all CHIMES-Medicaid-related material, is available on the State of Montana, Department of Health and Human Services website at: http://www.dphhs.mt.gov/legalresources/rfp/procurementlibrary/\.

1.5. PRE-PROPOSAL CONFERENCE

The Department invites interested parties to submit general questions prior to the mandatory pre-proposal conference. These questions will help the Department in preparing for the conference to focus on the items/questions that most need to be addressed. Written questions should be emailed to Penny Moon at [email protected] by close of business on June 19, 2009. These questions will be added to those received after the pre-proposal conference and written answers will be provided by the date stated in subsection 1.3.3.

A mandatory pre-proposal conference will be conducted at the Department of Environmental Quality Building, 1100 N Last Chance Gulch, Helena, Room 112 on June 23, 2009 at 1:00 p.m. Offerors are encouraged to use this opportunity to ask clarifying questions, obtain a better understanding of the project, or to notify the State of any ambiguities, inconsistencies, or errors discovered upon examination of this RFP. All responses to questions at the pre-proposal conference will be oral and in no way binding on the State.

1.6. GENERAL REQUIREMENTS

1.6.1. Acceptance of Terms and Conditions/Contract By submitting a response to this RFP, offeror agrees to acceptance of the contract with all terms and conditions as set out in Attachment A of this RFP. The selected offeror will be expected to enter into an Agreement that is substantially the same as the contract in Attachment A. In no event is an offeror to submit its own standard contract terms and conditions as a response to this RFP. The offeror must submit any requests for additions or exceptions to the contract terms, including any necessary licenses or other added


mailto:[email protected]

http://www.dphhs.mt.gov/legalresources/rfp/procurementlibrary/

http://gsd.mt.gov/osbs/Default.asp

provisions, exceptions and exact contract deviations that its firm wishes to negotiate to the procurement officer referenced above by the date for receipt of written/emailed questions, which is June 26, 2009; however, many clauses are required by Montana state law and cannot be negotiated.

Any request must be accompanied by an explanation of why the exception is being sought and what specific effect it will have on the offeror's ability to respond to the RFP or perform the contract. Requests must be made in the format of the table included in Appendix 13.10 of this RFP.

Any material exceptions requested and granted to the standard terms and conditions and contract language will be addressed in any formal written addendum issued for this RFP and will apply to all offerors submitting a response to this RFP. The State reserves the right to address nonmaterial requests for exceptions with the highest scoring offeror during contract negotiation. The State will make any final determination of changes to the contract and its terms and conditions.

1.6.2. Resulting Contract This RFP and any addenda, the offeror's RFP response, including any amendments, a best and final offer, and any clarification question responses shall be included in any resulting contract. The State's contract, attached as Attachment A, contains the contract terms and conditions which will form the basis of any contract between the State and the highest scoring offeror. In the event of a dispute as to the duties and responsibilities of the parties under this contract, the contract, along with any attachments prepared by the State, will govern in the same order of precedence as listed in the contract.

1.6.3. Mandatory Requirements To be eligible for consideration, an offeror must meet the intent of all mandatory requirements as summarized in Appendix 13.2. The State will determine whether an offeror's RFP response complies with the intent of the requirements. RFP responses that do not meet the full intent of all requirements listed in this RFP may be deemed nonresponsive.

1.6.4. Understanding Specifications and Requirements By submitting a response to this RFP, offeror agrees to an understanding of and compliance with the specifications and requirements described in this RFP.

1.6.5. Prime Contractor/Subcontractors The highest scoring offeror will be the prime contractor if a contract is awarded and shall be responsible, in total, for all work of any subcontractors. Use of subcontractors, if any, must be clearly explained in the proposal and any subcontractor must be identified by name in the proposal. The State reserves the right to approve all subcontractors. The contractor shall be responsible to the State for the acts and omissions of all subcontractors or agents and of persons directly or indirectly employed by such subcontractors, and for the acts and omissions of persons employed directly by the Contractor. Further, nothing contained within this document or any contract documents created as a result of any contract awards derived from this RFP shall create any contractual relationships between any subcontractor and the State.

At a minimum, the subcontractor information shall include name, address, the general scope of work to be performed by each subcontractor, its willingness to perform such work, and certification that it does not discriminate in its employment practices. The prime contractor shall report to the State annually information on its use of subcontractors, certifying that the subcontractor meets the employment practices mandated by Federal and State statutes and regulations. The subcontractor shall be held to the same standards as the prime contractor, as stated in this RFP. The State reserves the right to approve or disapprove the subcontractor and staff assigned to this contract.


1.6.6. Offeror’s Signature The proposals must be signed in ink by an individual authorized to legally bind the business submitting the proposal. The offeror's signature on a proposal in response to this RFP guarantees that the offer has been established without collusion and without effort to preclude the State of Montana from obtaining the best possible supply or service. Proof of authority of the person signing the RFP response must be furnished upon request.

1.6.7. Offer in Effect for 180 Days A proposal may not be modified, withdrawn, or canceled by the offeror for a 180-day period following the deadline for proposal submission as defined in the schedule of events, or receipt of best and final offer, if required, and offeror so agrees in submitting the proposal.

1.7. SUBMITTING A PROPOSAL

1.7.1. Organization of a Proposal Offerors must organize their proposal into sections that follow the format of the Proposal Submission Requirements detailed in Section 11 of this RFP, with tabs separating each section, as indicated in the proposal submission instructions. Response pages must be consecutively numbered. Using the Mandatory Requirements Checklist in Appendix 13.2, offerors must acknowledge all RFP sections.

An offeror making the statement “Refer to our literature…” or “Please see www…….com” may be deemed nonresponsive or receive point deductions. If making reference to materials located in another section of the RFP response, specific page numbers and sections must be noted. The Evaluator/Evaluation Committee is not required to search through literature or another section of the proposal to find a response.

1.7.2. Failure to Comply with Instructions Offerors failing to comply with these instructions may be subject to point deductions. The State may also choose to not evaluate, may deem nonresponsive, and/or may disqualify from further consideration any proposals that do not follow this RFP format, are difficult to understand, are difficult to read, or are missing any requested information.

1.7.3. Multiple Proposals Offerors may, at their option, submit multiple proposals, in which case each proposal shall be evaluated as a separate document.

1.7.4. Separate Technical and Cost Proposals Offerors must submit proposals in two parts – 1) a technical proposal and 2) a cost proposal. The format and content of each are specified in Section 11 of the RFP. Cost information must not be included in the technical proposal.

1.7.5. Copies Required and Deadline for Receipt of Proposals Offerors must submit one original technical proposal, four copies, and seven electronic copies to the State Procurement Bureau. Electronic copies should be submitted as Microsoft Word 2003, Microsoft XP, or Adobe Portable Document Format (PDF) documents. Electronic copies should be on separate CDs, so each evaluation team member can have his or her own. CDs must be complete; any product samples or other information not able to be included on the CD must be provided in one original and 11 paper copies. All CDs should be tested to ensure they are readable. If any confidential materials are included, per the requirements of subsection 2.2.2, they must be submitted on a separate CD or memory stick.


Offerors must submit one original cost proposal and two paper copies to the State Procurement Bureau under separate, sealed cover. The State Procurement Bureau will hold all cost proposals for opening until after the evaluation committee has completed its evaluation of the technical proposals. The time of opening will be at the State Procurement Bureau's option. At such time as the cost proposals are opened and reviewed by the procurement officer, they will be provided to the evaluation committee and become available for public inspection.

PROPOSALS MUST BE SEALED AND LABELED ON THE OUTSIDE OF THE PACKAGE to clearly indicate that they are in response to RFP09-1694P. Proposals must be clearly marked as either technical or cost proposals. Proposals must be received at the receptionist's desk of the State Procurement Bureau prior to 2:00 p.m., local time, July 30, 2009.

1.7.6. Late Proposals Regardless of cause, late proposals will not be accepted and will automatically be disqualified from further consideration. It shall be the offeror's sole risk to assure delivery at the receptionist's desk at the designated office by the designated time. Late proposals will not be opened and may be returned to the offeror at the expense of the offeror or destroyed if requested.

1.8. COST OF PREPARING A PROPOSAL

1.8.1. State Not Responsible for Preparation Costs The costs for developing and delivering responses to this RFP and any subsequent presentations of the proposal as requested by the State are entirely the responsibility of the offeror. The State is not liable for any expense incurred by the offeror in the preparation and presentation of their proposal or any other costs incurred by the offeror prior to execution of a contract.

1.8.2. All Timely Submitted Materials Become State Property All materials submitted in response to this RFP become the property of the State and are to be appended to any formal documentation, which would further define or expand any contractual relationship between the State and offeror resulting from this RFP process.


SECTION 2. RFP STANDARD INFORMATION

2.0. AUTHORITY

This RFP is issued under the authority of section 18-4-304, MCA (Montana Code Annotated) and ARM 2.5.602 (Administrative Rules of Montana). The RFP process is a procurement option allowing the award to be based on stated evaluation criteria. The RFP states the relative importance of all evaluation criteria. Only the evaluation criteria outlined in this RFP will be used.

2.1. OFFEROR COMPETITION

The State encourages free and open competition among offerors. Whenever possible, the State will design specifications, proposal requests, and conditions to accomplish this objective, consistent with the necessity to satisfy the State's need to procure technically sound, cost-effective services and supplies.

2.2. RECEIPT OF PROPOSALS AND PUBLIC INSPECTION

2.2.1. Public Information All information received in response to this RFP, including copyrighted material, is deemed public information and will be made available for public viewing and copying shortly after the time for receipt of proposals has passed with the following three exceptions: (1) bona fide trade secrets meeting the requirements of the Uniform Trade Secrets Act, Title 30, chapter 14, part 4, MCA, that have been properly marked, separated, and documented; (2) matters involving individual safety as determined by the State; and (3) other constitutional protections. See section 18-4-304, MCA. The State will make a copier available for interested parties to use at $0.10 per page. The interested party is responsible for the cost of copies and to provide personnel to do the copying.

2.2.2. Procurement Officer Review of Proposals Upon opening the proposals received in response to this RFP, the procurement officer in charge of the solicitation will review the proposals and separate out any information that meets the referenced exceptions in subsection 2.2.1 above, providing the following conditions have been met: Confidential information is clearly marked and separated from the rest of the proposal.

The proposal does not contain confidential material in the cost or price section.

An affidavit from an offeror's legal counsel attesting to and explaining the validity of the trade secret claim as set out in Title 30, chapter 14, part 4, MCA, is attached to each proposal containing trade secrets. Counsel must use the State of Montana “Affidavit for Trade Secret Confidentiality” form in requesting the trade secret claim. This affidavit form is available on the General Services Division's website at: http://gsd.mt.gov/procurement/forms.asp or by calling (406) 444-2575.

Information separated out under this process will be available for review only by the procurement officer, the evaluator/evaluation committee members, and limited other designees. Offerors must be prepared to pay all legal costs and fees associated with defending a claim for confidentiality in the event of a “right to know” (open records) request from another party.

2.3. CLASSIFICATION AND EVALUATION OF PROPOSALS

2.3.1. Initial Classification of Proposals as Responsive or Nonresponsive All proposals will initially be classified as either “responsive” or “nonresponsive,” in accordance with ARM 2.5.602. Proposals may be found nonresponsive at any time during the procurement process if any of the


http://gsd.mt.gov/procurement/forms.asp

required information is not provided or the proposal is not within the plans and specifications described and required in the RFP. If a proposal is found to be nonresponsive, it will not be considered further, and the price proposal will not be opened.

2.3.2. Determination of Responsibility The procurement officer will determine whether an offeror has met the standards of responsibility in accordance with ARM 2.5.407. Such a determination may be made at any time during the procurement process if information surfaces that would result in a determination of nonresponsibility. If an offeror is found nonresponsible, the determination must be in writing, made a part of the procurement file, and mailed to the affected offeror.

2.3.3. Evaluation of Proposals An evaluation committee will evaluate the remaining proposals. The State Procurement Bureau will hold all cost proposals for opening until after the evaluation committee has completed its evaluation of the technical proposals. The time of opening will be at the State Procurement Bureau's option. At such time as the cost proposals are opened and reviewed by the procurement officer, they will be provided to the evaluation committee and become available for public inspection.

The committee will recommend whether to award the contract to the highest scoring offeror or, if necessary, to seek discussion/negotiation or a best and final offer in order to determine the highest scoring offeror. All responsive proposals will be evaluated based on stated evaluation criteria. In scoring against stated criteria, the State may consider such factors as accepted industry standards and a comparative evaluation of all other qualified RFP responses in terms of quality and contractual factors. Differing costs will be considered in cost proposal scoring. The combined technical and cost proposal scores will be used to determine the most advantageous offering to the State. If an evaluation committee meets to deliberate and evaluate the proposals, the public may attend and observe the evaluation committee deliberations. Section 12 of this RFP explains the evaluation approach and criteria for the technical and cost proposals in more detail.

2.3.4. Completeness of Proposals Selection and award will be based on the offeror's proposal and other items outlined in this RFP. Submitted responses may not include references to information located elsewhere, such as Internet websites or libraries, unless specifically requested. Information or materials presented by offerors outside the formal response or subsequent discussion/negotiation or best and final offer, if requested, will not be considered, will have no bearing on any award, and may result in the offeror being disqualified from further consideration.

2.3.5. Opportunity for Discussion/Negotiation and/or Oral Presentation/Product Demonstration

After receipt of all proposals and prior to the determination of the award, the State may initiate discussions with one or more offerors should clarification or negotiation be necessary. Offerors may also be required to make an oral presentation and/or product demonstration to clarify their RFP response or to further define their offer. In either case, offerors should be prepared to send qualified personnel to Helena, Montana, to discuss technical and contractual aspects of the proposal. Oral presentations and product demonstrations, if requested, shall be at the offeror's expense.

2.3.6. Best and Final Offer The Best and Final Offer (BAFO) is an option available to the State under the RFP process, which permits the State to request a best and final offer from one or more offerors if additional information is required to make a final decision. Offerors may be contacted asking that they submit their best and final offer, which must include any and all discussed and/or negotiated changes. The State reserves the right to request a best and final offer for this RFP, if any, based on price/cost alone.


2.3.7. Evaluator/Evaluation Committee Recommendation for Contract Award The evaluator/evaluation committee will provide a written recommendation for contract award to the procurement officer that contains the scores, justification, and rationale for the decision. The procurement officer will review the recommendation to ensure its compliance with the RFP process and criteria before concurring in the evaluator's/evaluation committee’s recommendation of the responsive and responsible offeror that achieves the highest score and is, therefore, the most advantageous to the State. The State reserves the right to reject any or all proposals or to award this contract in a manner deemed to be in the best interest of the State.

2.3.8. Request for Documents Notice Upon concurrence with the evaluator's/evaluation committee's recommendation, the procurement officer will issue a “Request for Documents Notice” to the highest scoring offeror to obtain the required documents/information, such as insurance documents, contract performance security, an electronic copy of any requested material, i.e., RFP response, response to clarification questions, and/or best and final offer, and any other necessary documents. Receipt of the “Request for Documents Notice” does not constitute a contract and no work may begin until a contract signed by all parties is in place. The procurement officer will notify all other offerors of the State's selection.

2.3.9. Contract Execution Upon receipt of all required materials requested in the “Request for Documents Notice," a formal contract utilizing the contract with terms and conditions attached as Attachment A, as well as the highest scoring offeror's response to the RFP, will be provided to the highest scoring offeror for signature. The highest scoring offeror will be expected to accept and agree to all material requirements contained in the contract and set out in Attachment A of this RFP. If the highest scoring offeror does not accept all material requirements, the State may move to the next highest scoring offeror, or cancel the RFP. Work under the contract may begin when the contract is fully executed, i.e., when the contract is signed by all parties.

2.3.10 Protest Procedure Bidders and offerors may protest a solicitation or award of a contract per section 18-4-242, MCA, and ARM 2.5.406. The protest must be in writing and state in detail all of the protestor's objections. The complete protest must be submitted to the Department no later than the close of business 14 calendar days after the execution of the contract in question. If the 14th day falls on a Saturday, Sunday, or legal holiday, the protest is due at the end of the next business day. The State is under no obligation to delay, halt, or modify the procurement process pending the result of a protest, contested case proceeding, or judicial review.

2.4. STATE’S RIGHTS RESERVED

While the State has every intention to award a contract as a result of this RFP, issuance of the RFP in no way constitutes a commitment by the State of Montana to award and execute a contract. Upon a determination such actions would be in its best interest, the State, in its sole discretion, reserves the right to do any of the following: Cancel or terminate this RFP (section 18-4-307, MCA). Reject any or all proposals received in response to this RFP (ARM 2.5.602). Waive any undesirable, inconsequential, or inconsistent provisions of this RFP, which would not have

significant impact on any proposal (ARM 2.5.505). Not award if it is in the best interest of the State not to proceed with contract execution (ARM 2.5.602). If awarded, terminate any contract if the State determines adequate State funds are not available (section

18-4-313, MCA).

2.5. DEPARTMENT OF ADMINISTRATION POWERS AND DUTIES


The Department of Administration is responsible for carrying out the planning and program responsibilities for information technology (IT) for State government. (Section 2-17-512, MCA) The Chief Information Officer is the person appointed to carry out the duties and responsibilities of the Department of Administration relating to information technology. The Department of Administration shall: Review the use of information technology resources for all State agencies. Review and approve State agency specifications and procurement methods for the acquisition of

information technology resources. Review, approve, and sign all State agency IT contracts and shall review and approve other formal

agreements for information technology resources provided by the private sector and other government entities.

2.6. COMPLIANCE WITH STATE OF MONTANA IT STANDARDS

The offeror is expected to be familiar with the State of Montana IT environment. All services and products provided as a result of this RFP must comply with all applicable State of Montana IT policies and standards in effect at the time the RFP is issued. The offeror must request exceptions to State IT policies and standards in accordance with subsection 1.5 of this RFP. It will be the responsibility of the State to deny the exception request or to seek a policy or standards exception through the Department of Administration, Information Technology Services Division (ITSD). Offerors are expected to provide proposals that conform to State IT policies and standards. It is the intent of ITSD to utilize the existing policies and standards and not to routinely grant exceptions. The State reserves the right to address nonmaterial requests for exceptions with the highest scoring offeror during contract negotiation.

The links below will provide information on State of Montana IT strategic plans, current environment, policies, and standards.

State of Montana Information Technology Strategic Planhttp://itsd.mt.gov/stratplan/statewideplan.asp

State of Montana Information Technology Environmenthttp://itsd.mt.gov/techmt/compenviron.asp

State of Montana IT Policieshttp://itsd.mt.gov/policy/itpolicy.asp

State of Montana Software Standardshttp://itsd.mt.gov/policy/software.asp


http://itsd.mt.gov/policy/software.asp

http://itsd.mt.gov/policy/itpolicy.asp

http://itsd.mt.gov/techmt/compenviron.asp

http://itsd.mt.gov/stratplan/statewideplan.asp

SECTION 3. RFP INTRODUCTION AND BACKGROUND

3.0. GENERAL INFORMATION

DPHHS seeks to replace its current mainframe TANF and SNAP (previously called the Food Stamp Program) eligibility system with web-based systems, and to procure an enterprise architecture solution to serve as the common infrastructure connecting the separate systems. Included in this scope is the development of a shared fiscal services layer (SFSL) to provide functionality that supports the common fiscal functions shared by the CHIMES-SNAP and CHIMES-TANF systems, by providing a library of shared fiscal services where the fiscal interfaces and processing required by both the CHIMES-SNAP and CHIMES-TANF systems can be performed. The current legacy system, TEAMS, is built in a monolithic architecture that is difficult and costly to maintain, and that will not easily facilitate the implementation of enterprise architecture. In addition, it will become increasingly difficult to find programmers experienced in the legacy technology and languages needed to support TEAMS. The current system typifies state legacy systems in its inflexibility and use of codes, commands, and functions that could take years for an eligibility worker to master. Montana’s economy and employment patterns, like the rest of the country’s, are changing. In today’s world, very few people will retain jobs as OPA eligibility workers for the majority of their careers. The flexible and transient nature of the new state employee requires a new type of system. New systems or applications will have to replace institutional, people-based knowledge with better, more flexible technology that is easy to learn and use.

3.0.1. Strategic Goals and Objectives SNAP and TANF strategic goals and objectives were developed in conjunction with procurement project guiding principles. The goals and objectives, like the guiding principles, will be the benchmark from which procurement and system success will be measured. Specific requirements based on these goals and objectives are articulated in RFP Sections 6 through 10.

The main purpose of the new system is to determine eligibility. In addition to this, the SNAP eligibility system must meet specific program needs, including requirements of the Federal quality assurance standards and the SNAP Employment and Training program, and the TANF eligibility system must meet TANF-specific program needs including Federal reporting and case management requirements. The following goals and objectives address how the new eligibility system should operate to best support Montana’s TANF and SNAP programs. All goals and objectives are applicable to both programs unless otherwise noted.

1. The new eligibility systems must be flexible, modular, reliable, easy to update, and easy to maintain.

a. The State must be able to easily make changes within the systems, including changes to reports, tables, and rules. The State must be able to maintain eligibility rules, if they choose to do so. This flexibility and updateability is required for the systems to be responsive to changing program business needs.

b. The systems must be easily maintained over the long-term. End users must be able to perform this long-term maintenance.

c. The systems must be scaleable and modular.

2. The systems must be user-friendly from the State and client perspectives. More specifically, they must be quick, responsive, easy to learn, easy to search, and incorporate features including training modules, single entry, online help, online applications, links to policy manuals, and client-friendly correspondence.

a. The new systems must be easy to learn for new and existing State employees. The onscreen text must be written in plain English, so a user can look at a screen and know why he or she is on that screen, and know what to do to successfully use the screen. State employees must not have to remember illogical codes or workarounds to use the eligibility systems. The systems must be intuitive.

b. The systems must incorporate a search functionality to make it more useable.


c. The systems must incorporate system training modules and/or a system help function.

d. The systems must incorporate policy training modules and/or links to the SNAP and TANF policy manuals. This will allow eligibility workers to answer questions quicker and more accurately, improving the workers’ and the applicants’ or clients’ experiences.

e. The systems must incorporate sound fiscal processes.

f. The systems must one day have the ability to produce documents in other languages.

g. The systems must have a common intake function so demographic, income, resource, and other shared information only needs to be entered once.

h. The systems must be as paperless as possible.

i. The systems must be accessible to all, including people with disabilities.

j. The systems should be able to accept online applications and contain an online screening tool.

k. The systems must include spell check for case notes and notices.

l. The systems must have flexible and easy to use correspondence, to which changes can easily be made. System-generated correspondence must have basic word processing functionality including word wrap, the ability to have different line spacing, a variety of fonts, and bold and italics.

m. At a minimum, online availability is required between 6:00 a.m. and 7:00 p.m. seven days a week. The system must be available for longer hours in special circumstances, including the migrant season. The systems must have a consistent look and feel.

3. The systems must be able to easily exchange data with other systems. The new systems must have efficient interfaces and a high level of interoperability, allowing for future collaboration with other states or Montana programs.

a. The systems must coordinate with and be compatible with other information systems. Data must be easily exchanged between systems.

b. Interfaces must be intelligent and real-time. The systems need to be able to interface with other Montana State systems, Federal systems, non-profit partners, and other non-State program partners. The TANF and SNAP systems must also be able to share allowable information with appropriate tribal entities.

c. The systems must effectively and efficiently interface with all federally required systems.

d. System users must be able to smoothly transition to other programs from the systems, including Word and Excel.

4. The systems must have the ability to create reliable, comprehensive, flexible, usable, ad-hoc and scheduled reports for case management and program management.

a. The reporting capabilities must demonstrate accountability to and compliance with State and Federal standards.

b. The systems must automatically produce managerial reports, including case load reports, and the system must give staff the ability to query data to generate any other reports needed (ad-hoc reports).

c. The systems must have the ability to create accurate Federal reports.

d. The TANF system must calculate participation rates using the Federal formula. This formula must be easy to update.

e. The TANF system must have the ability to implement and accurately measure legislative performance measures.

f. The systems must be able to produce consistent reporting statistics (longitudinally valid).

g. The systems must retain accurate records.

h. The systems must be built to seamlessly coordinate with the shared fiscal services layer.

i. Reports must be clear, flexible, accurate, and timely.

5. The systems must have robust security and controllable system access.


a. Data within the systems must be secure and accessible only to those with proper access.

b. The systems must have varying levels of access. Protected health information needs to be accessible only to people with a certain security level.

c. The systems must have theft and fraud prevention built in to them.

d. The systems must contain a history of each user ID and the dated actions taken by specific users.

6. System development processes must be efficiently and effectively coordinated with other systems. TANF, SNAP, and Medicaid eligibility system users must use only one process and one set of screens to perform their work.

a. The systems must be successfully completed under budget and on time.

b. There must be a positive working partnership between the system users and the developers.

c. The systems must capitalize on the investment and development work completed on CHIMES-Medicaid.

d. The development of the systems must be coordinated with the development of other new systems including Child and Adult Protective Services System (CAPS), System for the Enforcement and Recovery of Child Support (SEARCHS), and CHIMES-Medicaid.

e. The systems must have consolidated financial processes, including overpayment management.

f. The SNAP and TANF systems must be developed to work with the Electronic Benefits Transaction (EBT) system and the shared fiscal services layer.

g. The systems intake process must be coordinated with other eligibility systems (Medicaid, TANF, and SNAP).

7. The systems must have well-defined data fields and rules. The systems must serve the right people with the right services at the right time.

a. The systems must accurately determine eligibility.

b. Data must be accurate and reliable in the new systems.

c. The systems must contain strong controls to limit and correct errors. Certain errors must be able to be corrected without programmer involvement.

d. The systems must minimize agency-caused errors.

e. The systems must have flexible eligibility categories for emergencies, such as Hurricane Katrina.

8. The systems must support efficient case management and assessment.

a. The systems must contain an effective case management and assessment module.

b. The systems must retain a history of case action, which must be easily searchable.

c. The systems must help OPA eligibility workers manage their time efficiently.

d. The SNAP system must include the Employment and Training (E&T) Program.

3.1. BACKGROUND INFORMATION

3.1.1. Procurement Overview Montana needs both a new SNAP eligibility system and a new TANF eligibility system to meet the changing program and administrative needs of today and the future. Montana’s current integrated eligibility system is a typical legacy system; it is inflexible, less accurate than it should be, expensive and difficult to update or change, and does not allow for adequate reporting or case management.

The Department intends to procure the two new systems that will support the overall Department goal of providing accurate and timely assistance to eligible Montanans. In order to do that, the systems will need to be more accurate and complete. The new eligibility systems must be easier to change, and changes should be made quickly and at a lower cost. They must have flexible and accurate reporting functionality, to allow for efficient and accurate Federal and State reporting. The systems should improve program management in the


areas of quality control, program security, and EBT system benefit issuance. The new eligibility systems must use a variety of mechanisms to interface with Federal, State, and other stakeholder systems. The Department also intends to procure an enterprise architecture solution to allow these two systems, the Medicaid eligibility system, and other systems to efficiently communicate and share data, including a Shared Fiscal Services Layer.

The Department anticipates that the design, development, and implementation of CHIMES-TANF, CHIMES-SNAP, the Enterprise Architecture (EA), and the SFSL will be completed within an approximate budgeted cost of $20,000,000.

The contract period coincides with the State’s biennium, and appropriate funding has been requested in the Montana Department budget request for the five-year base contract period. It is the Department’s intent to extend the contract term annually dependent upon the biennium budget authorizations, with the option of five additional one-year extensions up through July 2019. Appropriate funding will be requested through the State’s budgetary process for securing the funding for years 2015 through 2019 of this contract.

This contract and any contract extensions are contingent upon approval by the Department, the State Procurement Bureau, and the Governor or his designee, and upon available and approved funding. No Federal funds may be used for lobbying, and the selected vendor must comply with the Clean Air Act and Clean Water Act. Offerors must certify their compliance in the transmittal letter.

3.1.2. Procurement History The Economic Assistance Management System (TEAMS) currently determines eligibility and benefit issuance for Medicaid, TANF, and SNAP. TEAMS was originally developed in 1990 and has become consistently less responsive to the needs of these programs. TEAMS was federally certified early in 1992 after reviews of the system by both the US Department of Health and Human Services (HHS), Health Care Financial Administration (HCFA), and the US Department of Agriculture (USDA), Food and Nutrition Services (FNS) Administration. TEAMS is implemented on an IBM z9 mainframe running under zOS. The system is built on Computer Associates' Integrated Database Management System (IDMS). It contains online dialogues written in ADS/O and batch modules written in MVS COBOL. The system contains approximately 1,275 online programs and batch programs. It consists of 355 screens, 900 reports and stores 15.5 gigabytes of data. Approximately 150,000 active clients are processed by the system each month. The system supports approximately 500 eligibility specialists and support staff located across the State of Montana in Offices of Public Assistance (OPAs), as well as Work Readiness Component (WoRC) Operators.

3.1.3. Department of Public Health and Human Services The State of Montana, DPHHS is responsible for the delivery of a wide range of public assistance services funded through a combination of State and Federal dollars.

DPHHS is comprised of 12 divisions: 1) Director’s Office; 2) Children and Family Services; 3) Child Support Enforcement; 4) Technology Services; 5) Public Health and Safety; 6) Quality Assurance; 7) Human and Community Services; 8) Addictive and Mental Disorders; 9) Health Resources; 10) Disability Services; 11) Business and Financial Services; and 12) Senior and Long Term Care.

The Technology Services Division, the Public Assistance Bureau within the Human and Community Services Division, and the Business and Financial Services Division are the three DPHHS divisions managing this procurement process, and the system design, development and implementation. The contractor must obtain deliverable acceptance from applicable divisions. Some will require acceptance from all three divisions, others will only need acceptance from two.

3.1.3.1. Technology Services Division The Technology Services Division (TSD) provides operational and technological support to DPHHS to ensure efficient and effective implementation of Department programs. Support services include:


Reengineering processes critical to the Department mission. Developing and operating internal and external computer systems. Designing and managing networks. Programming. Supporting databases and application servers. Providing help desk support. Conducting technical planning of electronic government applications. Supporting telecommunications.

TSD supports a Project Management Bureau (TSD-PMB), which is the project management office for all DPHHS technology-related projects. Other divisions within DPHHS are their customers and partners on technology projects.

TSD-PMB adheres to the standards described by the Project Management Institute (PMI) in the Project Management Body of Knowledge (PMBOK). The Department requires the contractor to adhere to the same standards, as outlined in Section 4.2.

3.1.3.2. Human Community Services Division, Public Assistance Bureau The Human and Community Services Division (HCSD) helps families and individuals meet basic needs and work their way toward self-sufficiency. HCSD does this by administering a variety of Federal and State programs that offer cash assistance, employment training, SNAP benefits, Medicaid, child care, meal reimbursement, nutrition training, energy assistance, weatherization, and other services to help families move out of poverty.

The Human and Community Services Division is comprised of four bureaus: 1) Public Assistance; 2) Early Childhood Services; 3) Intergovernmental Human Services; and 4) Fiscal Services. The CHIMES systems fall within the purview of the Public Assistance Bureau (PAB). PAB administers Montana’s SNAP and TANF programs, and determines Medicaid eligibility. Services are provided by approximately 400 full-time equivalent employees (FTEs) assigned to the Offices of Public Assistance throughout the state.

3.1.3.3. Business and Financial Services Division The Business and Financial Services Division (BFSD) provides a variety of professional fiscal services to DPHHS, including: Financial and accounting operation and oversight. Cash management. Preparation and filing of Federal financial reports. Supply and equipment purchasing. Payroll processing. Audit coordination. Lease management. Vital records and statistics management. Property management. Records management. Accounts payable. Institutional reimbursement.

BFSD also provides leadership and guidance in the development and implementation of accounting policies and procedures and best business practices.


3.1.3.4. Organization Chart

3.1.4. Information Technology Services Division The State’s Information Technology Services Division (ITSD) is also an important player in the CHIMES and enterprise architecture project. The ITSD, under the authority of the State CIO, provides State agencies and customers information technology services in a fair, timely and responsive manner. The services provided ensure that the State’s information technology infrastructure is reliable, secure, and cost effective, and that it meets the business requirements of State agencies and citizens.

For this project, ITSD will provide hosting services for the three CHIMES systems and the enterprise architecture. ITSD will also oversee the project from initial planning through contract completion to ensure the systems and architecture comply with the information technology (IT) standards it has developed for all State systems. ITSD will ensure that this IT investment aligns with DPHHS’ strategic plans and that the Department realizes maximum benefit from this IT investment. Additionally, ITSD will assist with developing continuity of government, continuity of operations, and disaster recovery plans.

3.1.4.1. Organization Chart

3.1.5. SNAP Program Overview The Supplemental Nutrition Assistance Program (SNAP), formerly known as the Food Stamp Program, provides nutrition benefits to low-income participating clients, supports work, and delivers economic benefits to communities. In Montana, the SNAP eligibility system will determine eligibility, determine benefits levels, and capture participant information for the 35,800 Montana SNAP households. Households eligible to receive SNAP benefits include people that are:

Working for low wages or working part-time. Unemployed. Receiving TANF or other public assistance payments. Elderly or disabled and are low-income. Homeless.

The program is Federally funded, and most program rules are mandated in Federal regulation. However, states administer the program and have some flexibility in eligibility rules and service delivery models. All state agencies are required to sufficiently automate their SNAP operations and computerize their systems for obtaining, maintaining, utilizing and transmitting information concerning SNAP. Also, all state agencies are required to issue the monthly benefit allotment electronically through EBT systems – eliminating paper “stamps” or coupons.

The FNS is the Federal agency responsible for administering SNAP. Since the late 1990s, FNS has led two major Federal initiatives that have increased the performance expectations for State agencies:

Increase SNAP participation by eligible households. Improve quality assurance and payment accuracy.

Both of these initiatives have increased pressure on states to process larger volumes of applications while maintaining or increasing the accuracy of the eligibility determination and benefit levels. The efficiency and effectiveness of Montana’s new SNAP system will have a direct impact on Montana’s performance in these two areas.

3.1.6. TANF Program Overview The Temporary Assistance for Needy Families (TANF) program assists low-income adults with dependent children by providing employment and training services, work supports, and monthly cash grants. The TANF program is primarily funded by the Federal government through block grants to states or tribal entities. At the Federal level, the program is administered by HHS’ Administration for Children and Families (ACF).

State governments and participating tribes, not the Federal government, decide on the design of their program, the type and amount of assistance payments, the range of services to be provided, and the rules for determining who is eligible for benefits. However, there are Federal rules and regulations that all state programs must comply with, including a 60-month lifetime limit on assistance for participating adults. Also, states are limited in the kinds of activities that can be funded by the TANF block grant. Funding must be used for one of the four purposes defined in Federal law, which include:

1. Providing assistance to needy families so that children may be cared for in their own homes or in the homes of relatives.

2. Ending the dependency of needy parents on government benefits by promoting job preparation, work, and marriage.

3. Preventing and reducing the incidence of out-of-wedlock pregnancies and establishing annual numerical goals for preventing and reducing the incidence of these pregnancies.

4. Encouraging the formation and maintenance of two-parent families.

In addition, all states must meet annual program performance expectations – the most significant of which is the annual work participation rate. State programs must meet the minimum participation rate requirements

each year. If they do not, the Federal government can penalize the state by sanctioning a percentage of their block grant funding.

In February 2006, President Bush signed the Deficit Reduction Act of 2005. The law reauthorized Federal funding and made changes in four areas that impact how Montana manages its program.

1. Recalibration of the base year for the caseload reduction credit, effectively increasing the work participation rate requirements for states.

2. More precise definitions of work activity categories, eliminating some state flexibility in defining their work programs.

3. Addition of some new categories of individuals into the work participation rate.

4. Establishing new work verification plan requirements.

The combined impact of the four major changes has been to increase the performance expectations of the TANF program and to increase the importance of the TANF system to efficiently gather work participation data using a method that meets the new Federal work verification requirements.

3.2. RFP ORGANIZATION

The remainder of this RFP is organized as follows: SECTION 4: General Requirements – Defines overarching requirements including contractor, project

management, and general technical requirements.

SECTION 5: Phase-Specific Requirements – Delineates specific contractor responsibilities, performance expectations, milestones, deliverables, and Department responsibilities for each of the 10 contract phases or components.

SECTION 6: Enterprise Architecture Requirements – Defines detailed functional system requirements for the enterprise architecture.

SECTION 7: Detailed Common Requirements – Describes system functional requirements common to both TANF and SNAP systems.

SECTION 8: Detailed SNAP Requirements – Describes detailed, functional system requirements for CHIMES-SNAP.

SECTION 9: Detailed TANF Requirements – Describes detailed, functional system requirements for CHIMES-TANF.

SECTION 10: Shared Fiscal Services Requirements – Describes detailed, functional system requirements for the shared fiscal services layer.

SECTION 11: Proposal Requirements – Defines the format and contents for the Technical and Cost Proposals to be submitted by offerors.

SECTION 12: Evaluation Methodology – Includes an overview of the proposal evaluation methodology and a summary of evaluation criteria.

SECTION 13: Appendices – Provided to support information presented in these sections, including detailed information on CHIMES-Medicaid.

SECTION 4. GENERAL REQUIREMENTS

4.0. INTRODUCTION

This section of the RFP provides general requirements for the contractor scope of work in this RFP, and includes overall technical requirements that must be met within the development processes, as well as within the systems and enterprise architecture themselves.

4.1. CONTRACTOR RELATIONSHIP WITH DEPARTMENT AND OTHER CONTRACTORS

As the CHIMES-TANF, CHIMES-SNAP, and enterprise architecture contractor, contractor staff will have an ongoing relationship with Department staff and other contractor staff that is based on trust, confidentiality, objectivity, and integrity throughout all phases of the contract. The contractor will be privy to internal policy discussions, contractual issues, price negotiations, State financial information, and advanced knowledge of legislation. The contractor must maintain complete confidentiality related to the CHIMES-SNAP, CHIMES-TANF, and enterprise architecture project.

As part of the tasks described in this subsection, the contractor is responsible for the following general contract requirements:

1. Work cooperatively with key State staff, other system stakeholders, and the staff of other contractors as required in the course of the contract period.

2. Identify efficiencies that could be garnered by altering requirements, changing functionality, adapting business processes, or making other changes to the enterprise architecture or CHIMES systems.

3. Work on the eligibility systems and enterprise architecture at all times according to Federal and State regulations.

4. Inform Department management staff of current trends and issues in the eligibility and related systems’ marketplace, and provide information on new technologies in use in other states.

5. Work cooperatively with State staff assigned to the enterprise architecture, CHIMES-TANF, and CHIMES-SNAP project to ensure the success of the project.

6. Maintain complete and detailed records of all project meetings, system development life cycle documents, presentations, transition and system change planning issues, infrastructure management documents, performance reporting, risk assessment, project planning schedules, and any other interactions related to the system development project described in this RFP, and make such records electronically available to the Department on a regular basis throughout the life of the contract.

7. Work through the Department to share intellectual property information needed for external contractor quality assurance or independent verification and validation work.

8. Work collaboratively with other vendors performing quality assurance or independent verification and validation work, fixing identified defects and sharing performance metrics outlined in Section 4.2.

In addition, contract requirements specific to each functional system area and phase are presented in later sections of this RFP.

4.2. PROJECT MANAGEMENT AND REPORTING

The Department requests that the contractor propose an approach to project management for system development as well as project control tools to be used during the contract. The contractor must provide project management on an ongoing basis throughout the contract. The multiple deliverables associated with

the project management function must be completed according to the contractor’s proposed work plan, as approved by Department staff. The contractor is required to adhere to the standards described by the Project Management Institute (PMI) in the Project Management Body of Knowledge (PMBOK). All projects and plans must conform to the industry best practices.

The Department will use the following criteria to determine acceptance of the services and/or deliverables included in this RFP:

1. Project plans to be executed according to a standard dictated by the Department.

2. Deliverables document the validity of the requested development process relative to current industry standards and rates.

3. Documentation and deliverables conform to the acceptance and adequacy standards dictated by the Department.

4. All required documentation, as specified by the Department, will be delivered within mutually agreed-upon time frames.

5. Each deliverable will be accompanied by a Deliverable Acceptance Request (DAR) that must be completed and returned to contractor within a mutually agreed upon time period. The TSD/PMB project manager/lead and the applicable customer project manager(s) must sign DARs.

The contractor will be required to submit status reports to the Department’s Project Manager for the duration of the contract. The contractor's status reporting must provide information on progress toward meeting milestone dates and a formal report on progress and compliance with entrance and exit criteria. The Department will monitor each project milestone completion date to ensure that the implementation date will be met. Failure to meet any project milestone or deliverable completion date will be considered a signal to the State of Montana that a key date has not or will not be met. Damages may be assessed for failure to meet a project milestone or the implementation start date, as specified in this RFP and the resulting contract.

The status report must also identify any problem or circumstance encountered by the contractor, or of which the contractor gained knowledge during the period since the last such status report, which may prevent the contractor from completing any of its obligations or may generate charges in excess of those previously agreed to by the parties. The contractor must identify the amount of excess charges, if any, and the cause of any identified problem or circumstance and the steps taken to remedy the same.

The contractor will be required to create and store documents on the State’s SharePoint site established for the project. This includes but is not limited to status reports, deliverables, project plans, project management documents, and other supporting project documentation.

Managing to schedule on large Design, Development, and Implementation projects is always a challenge. The Department believes strongly in the use of project performance metrics as a valuable management tool. At its discretion the Department may employ the services of a Quality Assurance and/or Independent Verification and Validation (IV&V) vendor to provide independent assessments of project performance. The Department requires the contractor to provide the following performance metrics data, preferably in a readily accessible electronic format:

1. Throughout the project, weekly updated estimates in person-hours of all work remaining.

2. Throughout the project, weekly reporting of actual work completed in person-hours.

3. During construction and unit test, weekly reporting of modules successfully coded and unit tested.

4. During integration/system test, weekly reporting of the number of test cases, scripts or scenarios executed, passed, and failed.

5. During integration/system test, weekly updated estimates of the number of test cases, scripts or scenarios remaining to be executed.

6. During integration/system test, weekly reporting of defects found, open and closed, and average hours to fix per defect to date.

7. During user acceptance test, weekly reporting of the number of test cases, scripts or scenarios executed, passed, and failed.

8. During user acceptance test, weekly updated estimates of the number of test cases, scripts or scenarios remaining to be executed.

9. During user acceptance test, weekly reporting of defects found, open and closed, and average hours to fix per defect to date.

10. During pilot and implementation, weekly reporting of defects found, open and closed, and average hours to fix per defect to date.

11. During operations (warranty) and maintenance, monthly reporting of staff hours by type of staff (e.g., management, administrative, database application programming, web application programming). Additional operational reporting performance metrics will be agreed to with the contractor upon entering that phase of the contract.

4.3. CONTRACTOR COMMITMENT TO QUALITY MANAGEMENT

The Department is making a significant investment in procuring the system development services described in this RFP. The contractor selected will perform an essential role in the State’s eligibility determination processes. To maintain continuous focus on the importance of delivering quality systems and services, the contractor must plan, implement, rigorously endorse, and constantly improve a quality assurance program.

The Department seeks contractor endorsement of the fundamental importance of quality embedded in a living plan to introduce, promote, reinforce, and acknowledge quality in all contractor activities including communications.

The contractor must develop a quality assurance/quality management (QA/QM) proposed structure as part of the proposal and refined early in the project to address the needs and specific opportunities for quality improvement throughout the contract period. The final plan will be developed and submitted to the State for review once the contract has been approved. The QA/QM plan should reflect the contractor's experience and resolve toward quality in systems design, testing, and implementation; process design and staff training; performance standards development and measurement; and customer satisfaction measurement and analysis.

As part of its approach to quality management, the contractor must develop, support, and report progress against system metrics or software measurement criteria to allow both the contractor and the State to assess the progress of the systems development. The contactor must perform a review of information technology or information systems, to verify that the systems under development meet the objectives of the Department, and to ensure that the systems are developed in accordance with generally accepted standards for systems development. The evaluation of obtained evidence determines if the information systems are safeguarding assets, maintaining data integrity, and operating effectively and efficiently to achieve the organization's goals and objectives.

The QA/QM process must also address contractor operations, and the plan should contain associated means to measure this. The QA/QM plan must provide adequate information on internal structures to determine if it is appropriate for the contractor to perform its own information system quality reviews and security audits, or whether the contractor must contract with an outside entity to perform these reviews and audits. The plan must also include a proposed process for deliverable submittal and State review. The QA/QM plan must be updated and submitted annually to the State for review.

4.4. CONTRACTOR TRANSPARENCY, ACCOUNTABILITY, AND RESPONSIBILITY

The Department desires a significant level of transparency and visibility into the awarded contractor’s development activities in relation to this project. The contractor will be a partner with the Department project staff and is expected to be proactive in identifying problems or areas for improvement and communicating any issues or recommendations to the Department in a timely manner.

The Department also desires maximum contractor accountability. The contractor will be responsible for acknowledging and assuming responsibility for their actions, products, decisions, and policies. Specific responsibilities include:

1. Providing the Department ongoing electronic access to documentation used to support the activities conducted by the contractor.

2. Working collaboratively with the Department to gain Department approval of deliverables related to system development requested by the Department. These deliverables include, but are not limited to, requirements documents, design documents, testing plans and results, implementation readiness documents, and post-implementation review documents. Collaboration includes conducting walk-throughs of draft and final deliverables, communication on how Department comments were incorporated in final draft, and other Department defined collaboration requirements.

3. Clearly communicating the contractor’s understanding of changes or modifications requested by the Department.

4. Providing justification for any estimates for changes or modifications. The Department may request independent review or validation of such estimates using function point counts or similar industry methodologies to verify budget and schedule information provided by the contractor.

5. Revising hour and cost estimates and communicating any changes to original estimates in the change or modification’s detailed requirements document.

4.5. COMMUNICATION REQUIREMENTS

The contractor will be responsible for developing a communications management plan for all project-related activities. This plan will be submitted to the Department for review and approval within the first 45 days after the contract start date. This plan should describe, at a minimum, how the contractor will communicate with the Department and other entities, frequency and quality of communication, and communication types.

The contractor must provide all necessary software to support all electronic communications involved in day-to-day activities associated with the contract:

1. The Department must provide the ability for the contractor to connect with the State’s email system.

2. The system must enable all assigned contractor personnel to easily exchange documents and electronic files with the Department in compatible formats. The contractor is to maintain software versions that are compatible with the Department including, but not limited to, the following:

a. Microsoft Word (State currently uses Office 2003. They plan to move to 2007 in the next year.)b. Microsoft Excelc. Microsoft Projectd. Microsoft Accesse. Microsoft PowerPointf. Microsoft Visiog. Adobe PDF files (version 8)

3. The contractor must maintain such office automation compatibility between the Department and contractor personnel throughout the life of this contract.

http://en.wikipedia.org/wiki/Products

4.6. COMPLIANCE WITH FEDERAL REQUIREMENTS

The contractor must assist the Department in meeting Federal requirements for the joint State and Federal programs that are administered by DPHHS. The contractor must follow operational compliance efforts with existing and ongoing legislation passed at the Federal or State level, including all requirements around Protected Health Information and the Health Insurance Portability and Accountability Act (HIPAA).

4.6.1. Federal and State Ownership of Copyright Licenses The State and FNS reserve royalty-free, nonexclusive and irrevocable license to reproduce, publish, or otherwise use and authorize others to use for Federal Government purposes, the copyright in any software and associated documentation developed under the resulting contract.

All documentation and other work products developed by the contractor for this project will be considered works made for hire and owned by the State. For more detailed information, please refer to the U.S. Copyright Law at http://www.copyright.gov/title17/circ92.pdf.

The U.S. Copyright Law states the following regarding documentation created for hire:

“Works Made for Hire: In the case of a work made for hire, the employer or other person for whom the work was prepared is considered the author for purposes of this title, and, unless the parties have expressly agreed otherwise in a written instrument signed by them, owns all of the rights comprised in the copyright.”

4.7. SECURITY, CONFIDENTIALITY, AND AUDITING

The contractor must comply with State and Federal regulations, guidelines, and standards related to security, confidentiality, and auditing.

4.7.1. Security All information systems owned and operated by the State of Montana have some level of sensitivity and require the appropriate level of protection. The contractor must comply with Federal and State guidelines related to securing eligibility-related information. The contractor must provide assurance that it has effective internal controls over the processing of transactions performed under the resulting contract. The contractor must also demonstrate that it has adequate controls and safeguards over data and transactions maintained and processed on behalf of the State. Refer to subsection 7.151 for detailed security requirements.

4.7.2. Confidentiality The contractor must abide by all of the HIPAA Privacy Regulations found at 45 CFR Part 160 and Part 164, including future revisions and additions to these regulations. This includes agreement to control the use or disclosure of Protected Health Information as permitted or required by this agreement or as required by law. The contractor must establish, maintain, and use appropriate safeguards to prevent use or disclosure of client and provider personal information used by the contractor. This information must be held confidential and must not be divulged without the written consent of the Department. Need for access must be demonstrable and an auditable record of approvals must be maintained.

All documents, data compilations, reports, computer programs, photographs, and any other work provided to or produced by the contractor in the performance of the contract must be kept confidential by the contractor until publicly released by the Department or until written permission is granted by the Department for its release.

http://www.copyright.gov/title17/circ92.pdf

Publicly available information that is owned by the Department and information that is developed or maintained as part of this contract should not be released by contractor unless specifically authorized by the Department.

The contractor will be responsible for adhering to the following guidelines:

1. Prior to release of protected health information (PHI) to any non-State entity, the contractor must verify with the Department that the requesting party has signed the State’s HIPAA Business Associate Addendum.

2. Before disclosing any privileged information, the contractor must verify with the Department that such information may be disclosed.

3. Contractor personnel must sign Department confidentiality agreements before commencing work under this contract.

4.7.3. Auditing There are five distinct areas of auditing that need to be supported by the contractor. No additional funding will be allocated to the contractor for the audits required under this RFP. Therefore, the contractor is responsible for the cost of all audits and should ensure that those costs are included in the price of the contract. Detailed requirements are described below.

The contractor must respond to requests for information or access in the Department-specified timeframe.

4.7.3.1. General Audits may be performed by a number of State and Federal Agencies or authorized agents. The contractor must fully cooperate with the audit process. An audit may include, but is not limited to, the following capabilities and applies to the applications and architecture:

1. Storing, retrieving, and executing programs, whether such programs are part of the contractor’s production system, or generated by contractor staff.

2. Sampling and reconciling subsystem files to ensure accurate and timely maintenance.

3. Demonstrating services and/or benefits were provided for eligible clients.

4. Reviewing the contractor’s organization, policies, procedures, practices, effectiveness of control, operating efficiency, facility and software security, and back-up procedures.

5. Reviewing the contractor’s compliance with contract terms, system specifications, State or Federal regulations, administrative directives, and program documentation.

6. Reviewing any phase or aspect of the project for any purpose related to the system.

7. Responding to requests for data or information.

8. Having access to files, documentation, and contractor personnel.

9. Assisting Department staff in responding to Federal inquiries. This level of support must also be provided to all other State audit agencies or their designees.

4.7.3.2. Performance Auditing The State may conduct an audit of the contractor’s and/or the system’s performance. Contractors will have an opportunity to respond to the audit. The performance audit may cover all phases of the contract and may include, but not be limited to, an examination of the program, function, operation, and/or the management of the system, security, and the procedures of the contractor. The purpose of this audit is to provide assurance to the State that the contractor is achieving economy, efficiency and effectiveness in the employment of available resources.

Completed assessments may be kept on record at the State, maintained by the Quality Assurance Division of DPHHS, and may serve as past performance data. Past performance data will be available to assist agencies in the selection of IT service providers for future projects and procurement efforts.

4.7.3.3. Financial-Compliance The State may conduct an audit of the contractor’s resources to ensure financial compliance with the contract. The contractor must maintain FTE records and other evidence related to resource utilization costs and expenses of this contract and in such detail as must properly reflect all revenues; all net costs, direct and apportioned; and other costs and expenses, of whatever nature, that relate to performance of contractual duties under the provisions of this contract.

4.7.3.4. Security Auditing The contractor is responsible for procuring an independent security audit of the system to satisfy the needs of State and Federal Agencies. The QA/QM plan must show the internal corporate structure that will ensure audit independence if the contractor wants to conduct an independent audit using internal resources.

4.7.3.5. Records Retention The contractor must agree to the following terms for access to records relating to the contract:

1. Unless the Department specifies a shorter period of time in writing, the contractor agrees to preserve and make available all of its pertinent books, documents, papers, and records involving transactions related to this contract for a period of three years from the date of expiration or termination of the contract. Records involving matters in litigation must be kept for one year following the termination of litigation, including all appeals if the litigation has not terminated within the three years.

2. The contractor must agree that authorized Federal and State representatives, including, but not limited to, personnel of the State, other State entities with statutory authority, independent auditors acting on behalf of the State and/or Federal agencies providing funds, and the Comptroller General of the United States must have access to and the right to examine the items listed above during the contract and during the three year post-contract period or until resolution. During each contract period, access to these items must be provided in Montana. During the three year post-contract period, delivery of, and access to, the listed items must be at no cost to the Department.

3. The contractor must agree that authorized Federal and State representatives, including, but not limited to, personnel of the State, other State entities with statutory authority, and independent auditors acting on behalf of the State and/or Federal agencies providing funds must have access to, and the right to inspect, any site in which the contractor performs any work related to this contract or maintains any records related to this contract.

4. Requirements for access to records are governed by 45 CFR Part 74. The contractor, in accordance with this statute, must maintain accounting books, accounting records, documents, and other evidence pertaining to the administrative costs and expenses of this contract to the extent and in such detail as must properly reflect all revenues; all net costs, direct and apportioned; and other costs and expenses, of whatever nature, that relate to performance of contractual duties under the provisions of this contract. The contractor's accounting procedures and practices must conform to generally accepted accounting principles, and the costs properly applicable to this contract must be readily ascertainable there from.

4.8. TECHNICAL REQUIREMENTS

4.8.1. Common Infrastructure The three CHIMES systems (Medicaid, SNAP, and TANF) must share a common infrastructure. This will ensure compatibility between systems and will make it easier for the State to eventually operate and host the systems. Having a common infrastructure means the systems must use the same hardware, software, and hosting environment. CHIMES-Medicaid defines the standards by which CHIMES-TANF and CHIMES-SNAP must be built and operated.

The enterprise architecture creates the common infrastructure or middleware, connecting the three separate systems. The enterprise service bus will serve as the communication channel through which CHIMES-SNAP, CHIMES-TANF, and CHIMES-Medicaid will exchange information. The service-oriented architecture, web

services, web portal, common client index, and single sign-on will allow system users to use the three applications as if they were one.

4.8.1.1. CHIMES-Medicaid Medicaid was the first program to be extracted from TEAMS. CHIMES-Medicaid was designed and developed as a stand-alone application, with the intent that a subset of its services would eventually be exposed to utilize the enterprise architecture and communicate with other DPHHS applications. CHIMES-TANF and CHIMES-SNAP must mirror CHIMES-Medicaid’s infrastructure and environment to create efficiencies over the life of the contract and the resulting applications. This section provides an overview of CHIMES-Medicaid’s architecture. More detailed CHIMES-Medicaid information is included in the procurement library and throughout Sections 7 through 9.

CHIMES-Medicaid uses a multi-tier Java-based architecture, with about 200 web pages and 7,000 business rules. CHIMES-Medicaid automates eligibility determination, utilizing a business rules engine (BRE). The technical architecture relies on the following components and technologies:

ORACLE 10G DATABASE AND JBOSS APPLICATION SERVERThe database used to store persistent data for CHIMES-Medicaid is the 10g version of the Oracle database. Oracle is recognized as one of the major leaders in the relational database arena. The middle tier of CHIMES-Medicaid is built on a JBoss Application Server.

J2EEJ2EE is the development and runtime environment because of its robustness for use in developing enterprise applications, its cross-platform (Windows, Unix, Linux) capabilities, and its extensive use and acceptance in the industry. J2EE is built on top of J2SE (Standard Edition) and provides web services, component model, management, and communications application programming interfaces (APIs) to implement an enterprise class service-oriented architecture (SOA).

JAVASERVER PAGESThe technology for implementing the User Interface for CHIMES-Medicaid is JavaServer Pages (JSP). JSP technology is an extension of Java Servlet technology that supports creation of HTML and XML web pages. JSP makes it easier to combine fixed or static content with dynamic content. Many JSP pages rely on reusable, cross-platform components, such as JavaBeans or Enterprise JavaBeans components (parts of J2EE), to perform the more complex processing required in a web application. Reusability allows developers the ability to share and exchange components that perform common operations. This component-based approach speeds overall development and lets organizations leverage their existing expertise and development efforts for optimal results.

APACHE STRUTSCHIMES-Medicaid uses Apache Struts as the underlying framework for development of its user interface (UI). Struts has been customized, adapted, and implemented for the CHIMES-Medicaid project. Modern object-oriented applications separate the presentation of information to the user from the business logic, and from the way the UI “screens” or pages interact with each other. This model became known as the Model-View-Controller (MVC) model. Originally designed for the Smalltalk development environment, the Apache Software Foundation adapted MVC for use in the Java development environment and named that open source adaptation Struts.

HIBERNATEThe technology for isolating the Java business logic and UI code from the underlying relational database (Oracle) is Red Hat Hibernate. Hibernate has been successfully used on the CHIMES-Medicaid project. The desire for such a tool is motivated by the fact that the object-oriented nature of Java, JSP, and J2EE often produces object models that don’t match the underlying relational database. Sometimes objects can relate to business processes, sometimes to web pages, and possibly any number of other objects defined by the UI or

the business logic. It is often quite desirable to represent UI or business process data in object structures different than that represented on the database. Hibernate helps with that task.

ILOG JRULESThe Business Rules Engine (BRE) for CHIMES-Medicaid is ILOG’s JRules Engine. This BRE has been used successfully on the CHIMES-Medicaid project for all eligibility determination. JRules provides a natural language interface so business rules can be easily and naturally defined and understood by business analysts and policy experts.

XML AND ADOBE ACROBATThe technologies for the generation of correspondence and reports in CHIMES-Medicaid are XML and Adobe Acrobat to produce documents in the Portable Document Format (PDF). CHIMES-Medicaid will generate XML, which will input into Adobe Acrobat to produce the PDF files.

The following diagram illustrates the architecture of CHIMES-Medicaid:

CHIMES-Medicaid is currently in user acceptance testing (UAT). The application will be operational as a stand-alone application in July 2009.

4.8.1.2. Enterprise Architecture Enterprise architecture has become prominent in information technology planning and policy at the Federal and State levels. The State of Montana has also embraced the importance of enterprise architecture. Under the Montana Information Technology Act (MITA), the State’s Chief Information Officer (CIO) is charged with creating an enterprise architecture. To this end, ITSD is planning to establish an enterprise architecture as an integrated framework and governance process for managing and evolving IT while meeting strategic and

information resource management goals. This has resulted in the publication of the Conceptual Architecture Principles (CAP) (http://itsd.mt.gov/policy/policies/MT_DOA_ITSD_Conceptual_Architecture_Principles.pdf) as a logically consistent set of principles that are derived from the business requirements and will be used to guide the engineering of the organization’s information systems and technology infrastructure. There are 12 architectural principles contained within the CAP that represent business and integrate technology direction, the rationale and implications of each principle are drivers and motivating factors for ITSD EA initiatives and priorities. DPHHS will be guided by these principles in its decision-making to maximize business benefit and the adaptability of the IT environment.

Enterprise architecture will integrate the three separate eligibility systems so they operate seamlessly in an integrated environment. The contractor will develop a library of services, allowing information to be shared between systems. The architecture will give the systems the flexibility to define data differently with unique program rules.

To support the interoperable requirement for the CHIMES eligibility systems and as part of this RFP, the Department wishes to implement the following capabilities:

Service-Oriented Architecture Enterprise Service Bus Web Portal Single Sign-On Shared Information and Web Services, including a Common Client Index Intersystem Navigation

The Department wants to give the contractor significant latitude to propose what it considers to be the best solution to meet the Department’s and the applications’ needs. High-level requirements for the enterprise architecture solution are included in Section 6.

4.8.2. Application Hardware/Software Offerors must propose hardware and software that promote DPHHS’ vision of an enterprise architecture, which supports the use of services that are loosely coupled and reusable by systems needing to share common functionality. An important aspect of this vision is the State’s ability to easily operate, host, and update the systems and architecture. To support this goal of Department efficiency, CHIMES-TANF and CHIMES-SNAP system hardware and software environments must be compatible with CHIMES-Medicaid’s hardware and software environment, as described in subsection 4.8.1.1. The enterprise architecture hardware and software must be compatible with the systems’ architectures.

The contractor must demonstrate a methodology for evaluating, testing, and applying application and operating system patches within 30 days of release by the application or operating system vendor, where applicable. In the event problems are identified during testing, the contractor must escalate the issue to the Department and the Department will determine the appropriate course of action. The contractor is required to apply maintenance patches in the next available application release. If there is a more urgent patch identified by the contractor or the State, the contractor must evaluate it and take the appropriate action. This includes third-party software that must be supported and remain current. The application and architecture will be subject to regular vulnerability assessments by the contractor and must allow for a third party to perform penetration/security testing on the application and architecture, and assist in mitigating any identified vulnerabilities. All risks and vulnerabilities identified in the software must be reported to the Department. Critical vulnerabilities, as determined by the Department, must be mitigated immediately after testing and pending the State's approval of the contractor’s mitigation strategy. All software used to support the application must be continually supported by the contractor.

http://itsd.mt.gov/policy/policies/MT_DOA_ITSD_Conceptual_Architecture_Principles.pdf

4.8.2.1. Hosting Environment The State will provide and support the hosting environment for the three CHIMES applications. The State will supply three hosting environments: testing, quality assurance (QA), and deployment.

The following diagram illustrates contractor versus State environments:

APPLICATION SERVICESITSD will support the Application Server layer using an n-tier environment that supports Linux and JBoss. Currently, the Department is working with ITSD to implement the architecture on the Z9 mainframe in the Integrated Facility for Linux (IFL). This Application Server layer will also support the ILOG JRULES software. All three of the CHIMES systems may not end up being hosted in the IFL platform, however, the n-tier environment supporting Linux and JBoss will remain the same. If multiple application servers are implemented, then user access will be provided through the CISCO Content Switching Module (CSM) with load balancing between the application servers. CHIMES systems will not be available to the public, but will have Secure Sockets Layer (SSL) implemented providing network encryption.

DATABASE SERVICESITSD will support the Oracle database service in a shared Oracle user environment consisting of two IBM P550 8-way servers and four P550 4-way servers using IBM AIX operating system and IBM LPAR technology. This environment supports Oracle Server Enterprise Edition software and has several versions of that software deployed to meet individual application requirements.

The following diagram illustrates the hosting environment:

DATA CENTER SERVICESITSD manages and maintains a raised floor environment with adequate cooling, power and network capacity. All systems are supported by both Uninterruptible Power Supply (UPS) and backup generator power. The ITSD data center implements physical security measures that include controlled access and system security in a control center environment with the addition of the newly implemented Network Operations Security Center (NOSC) providing 24/7 management and monitoring of all data center and network systems.

4.8.2.2. Licensing The contractor is responsible for licensing all operating system components necessary to develop and run applications in its development environment. Production, QA, test, and hosting environments will be supported by and licensed by the State. The contractor must disclose all proprietary tools that the State must purchase to successfully host all of the system elements.

The contractor must convert all licenses for commercial off-the-shelf (COTS) products utilized within the enterprise architecture to the State once the systems and architecture are implemented.

4.8.2.3. Client Workstation OPA workstations are Dell Optiplex class machines with 2 GB or more of memory and processors of 2 GHz or better. Workstations are installed with the Vista operating system and Internet Explorer 7.

4.8.3. System Back-Up The contractor will only be responsible for system back-up during development. ITSD will be accountable for system back-up during production, testing, and operations. The State will use the same back-up approach for the three CHIMES systems. The hosting solution contains multiple redundancies to minimize the time that the system may be down and reduce the impact to the system users. All of the servers contain redundant power supplies, disk drives and SAN interfaces. Additionally, whole servers, SANs and even data centers are redundant.

4.8.4. System Reliability and Performance Standards There are 379 Medicaid, SNAP, and TANF eligibility caseworkers and 17 supervisory staff located in 51 OPAs around the state. In addition, there are approximately 10 administrative staff that will have access to the CHIMES applications from the PAB office in Helena. OPA locations are specified in Appendix 13.7.

Caseworkers will typically use CHIMES systems between 6:30 a.m. and 5:30 p.m. Mountain Time on State business days. The Department would like CHIMES to be available for as long as possible each day. At a minimum, online availability is required between 6:00 a.m. and 7:00 p.m. seven days a week. The system must be available for longer hours in special circumstances, including the migrant season. Daily and monthly batch processing will also require availability of the database outside of these hours.

There are currently approximately 39,300 SNAP households and 3,300 State TANF cases in the State of Montana. Supplemental Nutrition Assistance Program utilization has increased about five percent in the last State fiscal year due to increased outreach related to the SNAP name change, policy simplification (categorical eligibility), and the worsening economy. TANF utilization has fluctuated over the past ten State fiscal years, increasing from SFY 2000 through SFY 2003, decreasing from SFY 2003 through SFY 2008, and increasing slightly in SFY 2009. The fluctuations through the fourth quarter of SFY 2008 were due to policy changes, including transitions from State TANF to Tribal TANF. The increase since then is probably attributable to the national recession. The tables below represent historical and projected TANF and SNAP caseload data.

Historical Average Monthly Caseloads:

ProgramSFY09

(Jul-Feb) SFY08 SFY07 SFY06 SFY05 SFY04 SFY03 SFY02 SFY01 SFY00

TANF3,222(1.65%)

3,170(-3.29%)

3,278(-16.76%)

3,938(-18.75%)

4,847(-10.69%)

5,427(-11.94%)

6,163(8.91%)

5,659(18.76%)

4,765(2.67%) 4,641

SNAP36,963(4.98%)

35,210(0.74%)

34,953(-0.52%)

35,137(2.47%)

34,290(5.37%)

32,544(11.87%)

29,092(6.94%)

27,205(4.35%)

26,070(3.20%) 25,262

Projected Average Monthly Caseloads:Program SFY09 SFY10 SFY11 SFY12 SFY13 SFY14 SFY15

TANF3,368(1.85%)

3,469(3.00%)

3,573(3.00%)

3,681(3.00%)

3,791(3.00%)

3,905(3.00%)

4,022(3.00%)

SNAP38,114(8.25%)

42,540(11.61%)

45,921(7.95%)

49,572(7.95%)

53,513(7.95%)

57,767(7.95%)

62,359(7.95%)

The Department assumes that there will not be a drastic jump in the SNAP or TANF rolls due to the recession. If a large increase occurs, these estimates will not be accurate.

CHIMES-SNAP usage is projected to generate approximately 1,300,000 transactions monthly, which equates to approximately 163 transactions or 11 cases per case worker, per day. CHIMES-TANF usage is projected to generate approximately 1,760,000 transactions monthly, which equates to approximately 210 transactions or 15 cases per case worker per day. The table below contains monthly transaction estimates projected out until 2015. These are based on the caseload data above.

Projected Average Monthly Transactions:Program SFY09 SFY10 SFY11 SFY12 SFY13 SFY14 SFY15

SNAP 1,384,028 1,544,749 1,667,522 1,800,090 1,943,198 2,097,682 2,264,447TANF 1,796,440 1,850,333 1,905,843 1963,018 2,021,909 2,082,566 2,145,043

The CHIMES-Medicaid contractor estimates the size of that system to initially be 3.3 Gigabytes (Gb) for the database and 2.6 Gb for document storage. The initial size represents the database after one month of production use. Many tables and data elements in CHIMES-Medicaid will not be populated by TEAMS conversion since CHIMES-Medicaid captures significantly more data than is available in TEAMS. Eligibility workers will populate the system with additional data as they work in the system. At the end of a year of production, CHIMES-Medicaid database is estimated to be 13.6 Gb and document storage is estimated to be 31 Gb.

From these figures, the Department estimated the CHIMES-TANF and CHIMES-SNAP database size and document storage requirements. The Department calculated the number by multiplying the caseload ratio of Medicaid to TANF and SNAP by the CHIMES-Medicaid sizing estimates. Medicaid’s unduplicated caseload is 49,000 clients. We used the average monthly caseload for July through February 2009 for TANF and SNAP. The results are presented in the table below:

CHIMES-TANF and CHIMES-SNAP Sizing Estimates:Metric Medicaid TANF SNAP

Total Initial Database Size (1 month of production) 3.3 Gb 0.22 Gb 2.49 GbTotal Initial Document Storage Requirements (1 month of production) 2.6 Gb 0.17 Gb 1.96 GbTotal Final Database Size (1 year of production) 13.6 Gb 0.89 Gb 10.26 GbTotal Final Database Size (1 year of production) 31 Gb 2.04 Gb 23.38 Gb

DPHHS expects that the systems will be able to process requests and return results for standard web pages so that performance within all tiers of the architecture is optimized to allow on average two second response time, understanding that the State network must be adequate to deliver the transactions in a timely way to the end user.

The Department is also very interested in accuracy and security. CHIMES-SNAP, CHIMES-TANF, SFSL, and the enterprise architecture must accurately, securely, and reliably send, capture, store, and display data. The systems must accurately determine eligibility and benefit amounts. The systems must contain strong controls to limit and correct errors.

4.8.5. Remote Access CHIMES users will access the systems through the State’s network. Remote users (those not on the capitol complex), will utilize the State’s wide area network, SummitNet. The supported protocol for this State network is TCP/IP. Remote locations are typically connected by T1/1024 CIR frame relay circuits and various bandwidths of DSL utilizing Cisco routers.

SummitNet uses Cisco’s EIGRP and OSPF routing protocols. The State uses a private address numbering plan for IP addressing requirements within the general government portion of SummitNet including local governments such as cities and counties that have SummitNet connectivity. Cisco’s Private Internet Exchange (PIX) hardware is used to provide IP address translation and firewall protection.

SummitNet is a statewide network that at minimum reaches out to remote locations in each of the 56 county seats around the State, as well as various other towns, and several Montana University System campuses. SummitNet currently has approximately 568 circuits installed throughout the network. Included are two K-12 school districts, approximately 14 Montana University System community college campuses and research locations, and approximately 47 local government connections.

For the local area networks, the State of Montana has implemented an Ethernet data networking topology. The State maintains a Campus Fiber Backbone (CFB) network connecting Local Area Networks (LANs) deployed throughout the State capitol complex in Helena. Each building has a collapsed backbone connecting multiple segments to the CFB through Fast Ethernet LAN environments.

The State of Montana also leases LAN Switching Services (LSS) from Qwest. There are approximately 12 LSS sites connected via 45Mbps or 100Mbps ATM LAN Switching Services. These LSS connections service off-campus sites in Helena and Missoula to extend CFB connectivity.

The State of Montana leases dark fiber from Bresnan to multiple off-campus sites in Helena. These locations all use single mode fiber. Most of these locations terminate back to the Mitchell Building on the capitol complex.

The majority of the State of Montana's remote offices are wired with CAT-5 UTP cable. These remote offices operate at speeds of 10Mb/100Mb/1000Mb. Remote LANs are typically connected to the backbone via T1/1024 CIR frame relay circuits and various bandwidths of DSL utilizing Cisco routers.

4.8.5.1. Network Diagram The following diagram illustrates Montana’s network:

4.8.6. Disaster Recovery In the event of a system (not including issues related to application code) or hardware failure, the system must be recovered and back online within one business day. In the event of a disaster, the system must be recovered and back online within five business days of the restoration of basic infrastructure. For the purpose of this RFP, a disaster is defined as an event in which basic infrastructure (telecommunications, buildings, power, roads) of the local or State community has been comprised to the extent it interrupts the delivery of the system to the end users.

ITSD will be responsible for disaster recovery for services under its hosting responsibilities. The State of Montana has a contract with SUNGARD Availability Services Corporation for disaster recovery services. SUNGARD systems engineers are under contract to provide recovery services for the State.

4.8.6.1. Contractor Responsibilities 1. Ensure the development environment has an adequate amount of redundancies. The Department expects

the contractor to complete milestones within specified timeframes. Failure of the development environment will not be an acceptable reason for missing milestone and/or deliverable dates.

2. Utilize the SUNGARD disaster recovery contract for the services under the contractor’s scope of responsibility.

3. Participate in the development of the CHIMES-SNAP, CHIMES-TANF, and enterprise architecture disaster recovery plan. This plan contains details/tasks that will be performed by ITSD and SUNGARD to move operations to the disaster recovery facility. The contractor will help identify details/tasks that are required within the plan. The contractor may be assigned action items from these meetings.

4. Participate in disaster recovery exercises. The exercise takes place over a Department-defined period and contractor will be required to perform tasks during this exercise. The contractor will be required to:

a. Identify scope of exercise.b. Identify exercise objectives including pass/fail criteria.c. Identify roles/responsibilities.d. Develop an exercise document that contains the above information.e. Participate in the exercise.f. Document exercise results/lessons learned.

4.8.6.2. ITSD Responsibilities 1. Jointly develop a disaster recovery plan for CHIMES-SNAP, CHIMES-TANF, and the enterprise

architecture with SUNGARD, DPHHS, and the contractor. The disaster recovery plan should include the following six main components:

a. Supporting information including an introduction and concept of operations (system description, roles/responsibilities, and lines of succession).

b. Notification/activation phase including notification procedures, damage assessment, and plan activation.

c. Recovery phase, including sequence of recovery activities and recovery procedures

d. Reconstitution phase including restore original site, test systems, and terminate operations.

e. Maintenance/testing including frequency of maintenance/testing and testing objectives with pass/fail criteria.

f. Plan appendices including contact information (personnel, vendors), system requirements (hardware/software lists including models, versions, specifications and quantities), contractor service level agreements (SLAs), standard operating procedures (SOPs), and vital records.

4.8.6.3. Department Responsibilities 1. Work with ITSD and the contractor to develop a disaster recovery plan for CHIMES-SNAP, CHIMES-TANF,

and the enterprise architecture.

2. Approve disaster recovery plan.

SECTION 5. PHASE-SPECIFIC REQUIREMENTS

5.0. OVERVIEW

The scope of work for this procurement is divided into 10 phases or components, which include the complete development and implementation of the enterprise architecture, the SFSL, and the CHIMES-TANF and CHIMES-SNAP systems. Unless otherwise noted, these phases are implied as referring to the CHIMES-SNAP and CHIMES-TANF systems, the enterprise architecture, and the SFSL. The phases and components are not strictly sequential and may overlap. The phases and components are separated out because they have discrete deliverables and milestones associated with them. Additionally, phases and components require different expertise from proposed vendor personnel. The following subsections provide detailed descriptions of the phases and components, contractor and Department responsibilities, performance expectations, milestones, and deliverables for each phase or component. Personnel requirements are included in subsection 11.1.6.1.

The 10 phases or components are:

Start Up – The start up phase encompasses the contractor’s initial project planning and set up activities. The contractor will create and obtain Department approval for planning documents in this phase.

Detailed Requirements Definition Phase – In this phase, the contractor will work with Department personnel to validate and further define the architecture and requirements for the eligibility systems and enterprise architecture included in this RFP, and reconcile them with contractor-proposed solutions. Many of the applications’ requirements are identical to CHIMES-Medicaid detailed requirements. This will allow the contractor to take advantage of efficiencies and time savings in defining the detailed eligibility system requirements during this phase.

Design Phase – This phase includes all activities related to the design of the enterprise architecture and the eligibility systems. The technical architecture of the eligibility systems will be identical to CHIMES-Medicaid, but the technical architecture of the enterprise architecture and the SFSL will need to be defined. The contractor will create database, technical, and website specifications in this phase.

Construction Phase – The contractor will build the systems and architecture in the construction phase. The contractor will refine system standards, create user and training materials, and produce technical documentation.

Conversion – The contractor will convert data contained in TEAMS to CHIMES-SNAP, CHIMES-TANF, and the SFSL. The contractor will migrate data from the legacy system according to conversion parameters that are defined in cooperation with the Department. The contractor will be responsible for the planning, testing, and management of the data conversion process, including the logical and physical data architecture, and use of the data loading tools.

Testing – The contractor will test the software and hardware of the architecture and application to evaluate eligibility determination accuracy and their compliance with defined requirements. The contractor will perform unit and system testing. The contractor will support the Department in conducting user acceptance testing.

Pilot Phase – The contractor will assist the Department in implementing a statewide pilot test. This phase will require eligibility workers to enter application information into TEAMS and the new systems, and eligibility results will be compared. The test will occur in the production environment and benefits will be issued by the CHIMES systems. This phase will end with the Department accepting the system.

Implementation Phase – The contractor will deploy the CHIMES systems and the enterprise architecture after successfully completing the testing and pilot phases.

Operations and Maintenance Phase – This phase includes all activities involved in the operations maintenance of the eligibility systems and enterprise architecture for a minimum of three years of operations. The first year of this phase will constitute a warranty period, in which the contractor is responsible for all fixes needed to ensure that the systems and architecture operate according to Department specifications. All system and architecture functions must be performed by the contractor as directed by the Department in compliance with Federal and State requirements, statutes, and regulations.

Turnover Phase – The contractor will transition operations of the eligibility systems, the enterprise architecture, and the SFSL to the State or a new contractor during the turnover phase. The major activities in this phase will be transition planning, ensuring State or new contractor readiness for operations including a period of knowledge transfer from the contractor to the State, completing a successful trial application and decision table release in a test environment, and turning over the CHIMES systems, the enterprise architecture, and the SFSL to State or new contractor operations.

5.1. START UP PHASE

5.1.1. Overview The start up phase encompasses the contractor’s initial project planning and set up activities. These activities will begin on the date of contract signing (by all parties) and represent activities that must be completed to ensure that the project starts on a firm foundation. The contractor will create and obtain Department approval for planning documents in this phase.

5.1.2. Contractor Responsibilities 1. Prepare an outline and obtain acceptance from the Department for the contents and format for each start

up phase deliverable before beginning work on the deliverable.

2. Conduct project initiation kick-off meeting with key stakeholders and Department project management team.

3. Create a project work plan and project schedule to include a detailed activity-level schedule indicating the various project tasks, the activities necessary to meet deliverable dates including their duration, estimated start and completion dates, actual start and completion dates, critical paths, resources, dependencies, completion percentages, and phase-level milestones.

4. Create a quality assurance/quality management (QA/QM) plan that addresses the contractor's quality approach and methodologies to be utilized in systems design, testing, and implementation; process design and staff training; performance standards development and measurement; and customer satisfaction measurement and analysis.

5. Create a contractor project staffing plan, including staffing levels and location of staff for duration of project; an overview of the various positions, skill sets, experience requirements, and percentage of time spent onsite versus offsite.

6. Create a communication plan detailing the contractor’s plan for keeping all project stakeholders informed about project progress, identifying the goals/objectives of project communication, and identifying the target audience. The plan must address the requirements of routine written status reports, per RFP subsection 4.2, and weekly status meetings with additional meetings scheduled as necessary.

7. Establish a project control and issue reporting system, including project control tools as referenced in subsection 4.2 of this RFP.

8. Submit for approval to the Department the contractor’s project status reporting format and project control tools.

9. Create a project management plan that defines project roles and responsibilities, reporting relationships, taking into consideration the availability of Department resources, approach to providing weekly project

reporting metrics as specified in subsection 4.2 of this RFP, risk and issue management processes and escalation procedures, and mitigation strategies.

10. Meet with ITSD regarding the development of the CHIMES-SNAP, CHIMES-TANF, and shared services disaster recovery plan per RFP subsection 4.8.6.1, and provide recommendations regarding the development of the disaster recovery plan.

11. Conduct onsite review of State hosting environments.

12. Work with the Department and other State contractors, as necessary, for establishing appropriate project office automation connectivity.

13. Conduct an impact assessment of the contractor’s connectivity requirements on the Department and State infrastructure (e.g. bandwidth requirements).

14. Revise deliverables, if required, using Department review findings to meet content and format requirements and comply with applicable specifications.

15. Obtain written acceptance from the Department on all final deliverables for the start-up phase.

5.1.3. Performance Expectations 1. Conduct project initiation kick-off meeting within 30 days of contract effective date.

2. Submit drafts of the following documents within 30 days of contract effective date:a. Project work plan and scheduleb. QA/QM Planc. Contractor project staffing plan

3. Submit drafts of the following documents within 45 days of contract effective date:a. Communication planb. Project management plan

4. Submit revised start-up phase deliverables, based on Department review comments, within 15 business days of receipt of Department comments. (Please note that the Department expects that the deliverables from this phase will be continually updated throughout the contract phases.)

5. All start up phase documents must be completed (e.g., final deliverables submitted for approval by the Department) within 60 days of the contract effective date.

6. Impacts to existing infrastructure should be evaluated within the start up phase, no later than 45 business days after contract effective date, to ensure appropriate lead-time for the Department responsibilities regarding infrastructure capacity at all locations.

5.1.4. Major Milestones 1. Delivery and Department approval of project initiation and detailed project work plan.

5.1.5. Required Deliverables 1. Detailed Project Work Plan including all project tasks with planned start and end dates, estimates to

complete, and assigned resources, including contractor and Department resources.

2. Quality Assurance/Quality Management Plan including quality assurance, quality management, and performance measurement processes, and contractor internal quality control structures

3. Contractor Project Staffing Plan including staffing levels and location of contractor staff for duration of project, an overview of the various positions, skill sets, experience requirements, and percentage of time spent onsite versus offsite.

4. Project Issue Reporting System including an issue monitoring, escalation, and resolution process, consistent with existing Department standards.

5. Project Communication Plan identifying who needs what information, frequency, and media for each instance of communication.

6. Project Management Plan including roles, responsibilities, reporting relationships, risk and issue management processes, and escalation procedures using the project issue reporting system.

7. Recommendations for the Disaster Recovery Plan identifying tasks to be performed by ITSD and SUNGARD to move operations to the disaster recovery facility.

8. Identification of Impacts to Department Infrastructure Capacity including the identification of potential bandwidth and system/architecture performance capacity issues related to the system connectivity/usage requirements for the Department user locations.

5.1.6. Department Responsibilities

1. Review and determine acceptance of the proposed format and content of all task deliverables prior to development.

2. Review start-up phase deliverables, determine whether the deliverable complies with applicable specifications, and provide written comments to the contractor within a mutually agreed upon number of business days after receipt, based on deliverable.

3. Monitor contractor progress to task milestones.

4. Work with the contractor to resolve issues during the start-up phase.

5. Initiate the planning and funding allocation steps for needed infrastructure improvements/changes to Department office locations, based on contractor identification of issues related to support for infrastructure needs.

5.2. DETAILED REQUIREMENTS DEFINITION PHASE

5.2.1. Overview In this phase, the contractor will work with Department personnel to validate and further define the architecture and requirements for the eligibility systems and enterprise architecture, including the fiscal service layer, and reconcile them with contractor-proposed solutions.

The primary deliverables produced during this phase are the requirements specification document (RSD) and an updated requirements traceability matrix (RTM). The purpose of the RSD is to identify proposal requirements, validate requirements with stakeholders, identify how and where the requirements will be met during design and to define system acceptance criteria. The contractor will utilize and update the Department’s existing RTM containing the RFP requirements to fulfill the RTM purpose of tracking requirements throughout the design, testing and operations phases, based on validated RFP requirements.

Another significant responsibility for the contractor during this phase, as well as all subsequent design and testing-related phases, will be to utilize appropriate change control processes to control the management and approval of system changes to the requirements of this RFP, as directed by the Department.

5.2.2. Contractor Responsibilities 1. Prepare an outline and obtain acceptance from the Department for the contents and format for each

requirements definition phase deliverable before beginning work on the deliverable.

2. Develop and submit a requirements definition and validation plan for approval by the Department to include a description of tools to be used, and approach to issue tracking from requirements sessions, including the capture of potential training considerations identified during the requirements sessions.

3. Develop and submit a requirements definition session schedule for review by the Department.

4. Develop and distribute requirements definition session agendas prior to each session.

5. Conduct requirements analysis sessions to validate RFP requirements with program users and other stakeholders.

6. Prepare and submit for review and approval the requirements session meeting notes, including decisions, justification for changes, outstanding issues requiring follow-up, and impacts to future requirements sessions and session participants.

7. Utilize project control tools to formally track requirements session results so that the Department can manage the requirements decisions by module or functional area to include requirements not yet completed as well as decisions from completed requirements sessions.

8. Develop detail requirements specifications documentation for specific modules and/or functional areas for submission to the Department on an incremental basis as they are developed, which includes, at a minimum, increments for the CHIMES-SNAP, CHIMES-TANF, enterprise architecture, and shared fiscal services components and various sub-components/modules.

9. Compile final requirements specification document based on Department review findings regarding content and format.

10. Update and maintain the RTM.

11. Obtain written acceptance from the Department on the final requirements specification deliverable for the requirements definition phase.

5.2.3. Performance Expectations 1. Prepare and distribute requirements session agendas to invited participants no later than two business

days prior to the scheduled session.

2. Prepare and distribute requirements session minutes/notes to session participants no later than two business days following the session.

3. Submit final, complete requirements specification document to the Department within 15 business days of Department approval of last incremental requirements documentation deliverable.

4. Provide an updated RTM to the Department monthly during the requirements definition phase.

5.2.4. Major Milestones 1. Completion of detailed requirements sessions.

2. Delivery and Department approval of complete detailed requirements specification document.

5.2.5. Required Deliverables 1. Requirements Definition and Validation Plan including a description of tools to be used, use and

scheduling of resources, and approach to issue and comment tracking.

2. Facilitated Requirements Work Sessions including contractor and Department subject matter experts, covering in detail all system requirements.

3. Requirements Session Meeting Minutes including weekly reports from the project control tracking tool.

4. Updated Requirements Traceability Matrix tracking detailed requirements to RFP requirements, using the Department’s existing matrix.

5. Detailed Requirements Specification Template, depicting in detail the format of the proposed detailed requirements specification deliverable. This should be included within the Requirements Definition and Validation Plan.

6. Detailed Requirements Specification Document (RSD) fully reflecting all requirements that need to be met by the system as defined in the facilitated requirements definition work sessions. Detailed requirements specifications shall be delivered incrementally, as they are developed for each functional area or module, with final approval when all are approved.

7. Business Rules recording all business rules for CHIMES-SNAP and CHIMES-TANF.

5.2.6. Department Responsibilities 1. Review and determine acceptance of the proposed format and content of all task deliverables prior to

development.

2. Provide appropriate staff to attend requirements work sessions.

3. Work with contractor to establish schedule and location for requirements work sessions.

4. Provide contractor with information and clarification regarding interfaces and system processes, as well as Department policy, regulations, and procedures.

5. Review and approve requirements definition documentation and requirements specification document, within a mutually agreed upon number of business days after receipt.

6. Review and respond to all requirements change documents within a specified number of business days after receipt, using the agreed-upon project change control process.

7. Track policy-related changes and training impacts identified during the requirements sessions.


9. Work with the contractor to resolve issues during the requirements definition phase.

5.3. DESIGN PHASE

5.3.1. Overview This phase includes all activities related to the detailed design of the enterprise architecture, its shared services, including the SFSL, and the eligibility systems. The technical architecture of the eligibility systems will be identical to CHIMES-Medicaid. Additionally, the unique new and modified CHIMES-TANF and CHIMES-SNAP functional system requirements will be addressed and design specifications for system screens, reports, data, interfaces, and business rules will need to be defined in conformance with the requirements that were validated during the requirements definition phase.

The technical design of the enterprise architecture will also need to be defined during this phase. This will require the contractor to have a solid working understanding of the Department’s enterprise architecture approach. The purpose of the enterprise architecture directive is to create and use enterprise architecture as a framework for decision making for business, technology, and information systems for the Department. Specific areas of interest for the enterprise architecture include the design and use of components supporting the appearance of a seamless single entry point for the system users, the use of common client identification (IDs) and the design and development of common eligibility and authorization interface components, where available.

The design activities related to the development of the SFSL are expected to be completed independently of the design for the CHIMES systems. However, the responsibilities, deliverables, milestones and performance expectations as detailed in this subsection apply to the SFSL just as they do for the CHIMES systems and enterprise architecture.

5.3.2. Contractor Responsibilities 1. Prepare an outline and obtain acceptance from the Department for the contents and format for each design

phase deliverable before beginning work on the deliverable.

2. Develop and submit a detailed system design plan for approval by the Department to include a description of tools to be used, and approach to issue tracking from detailed design sessions, including the capture of potential training considerations identified during the design sessions.

3. Develop and submit a detailed system design session schedule for review by the Department.

4. Develop and distribute detailed system design session agendas prior to each session.

5. In developing windows, screens, reports or other layouts, perform prototyping where appropriate to enable Department staff to review and accept designs.

6. Demonstrate web page/module functionality through models/prototypes as appropriate.

7. Conduct detailed system design sessions to validate requirements with program users and other stakeholders.

8. Prepare and submit for review and approval to the Department and session attendees the detailed design session meeting notes, including decisions, justification for changes (including new, modified, or deleted requirements), outstanding issues requiring follow-up, and impacts to future detailed design sessions.

9. Utilize project control tools to formally track detailed design session results so that the Department can manage the design decisions by module or functional area to include design components not yet completed as well as decisions from completed design sessions.

10. Develop detail system design documentation for specific modules and/or functional areas for submission to the Department on an incremental basis as they are developed which includes, at a minimum, increments for CHIMES-SNAP, CHIMES-TANF, enterprise architecture, and shared fiscal services components and various sub-components/modules.

11. Conduct technical reviews of the detail system design deliverable with the Department to verify the design, and identify and resolve any design issues or questions.

12. Revise the draft detail system design document, and incorporate any comments submitted by the Department.

13. Develop final detail system design document based on Department review findings regarding content and format.

14. Update and maintain the requirements traceability matrix.

15. Obtain written acceptance from the Department on the final detail system design deliverable for the design phase.

5.3.3. Performance Expectations 1. Prepare and distribute detailed system design session agendas to invited participants no later than two

business days prior to the scheduled session.

2. Prepare and distribute detailed system design session minutes/notes to session participants no later than two business days following the session.

3. Submit final, complete detailed system design specification document to the Department within 15 business days of Department approval of last incremental detailed system design documentation deliverable.

4. Provide an updated RTM to the Department monthly during the detailed design phase.

5.3.4. Major Milestones 1. Completion of detailed system design sessions.

2. Completion and Department approval of detailed system design specifications.

5.3.5. Required Deliverables 1. Detailed System Design Plan including a description of the design work sessions content and structure, a

description of tools to be used, use and scheduling of resources, and approach to issue and comment tracking.

2. Facilitated Design Work Sessions including contractor and Department subject matter experts, covering in detail the design of the web pages, reports, data, conversion, and all business rules to meet the previously defined detailed requirements.

3. Detailed System Design Session Meeting Minutes including weekly reports from the project control tracking tool.

4. Updated Requirements Traceability Matrix fully tracking detailed design to detailed requirements.

5. Updated Business Rules recording all business rules and any additions, modifications, and deletions made to them.

6. Detailed Design Specification Template depicting in detail the format of the proposed detailed design specification deliverable. This should be included within the Detailed System Design Plan.

7. Detailed Design Specification Document (DSD) fully reflecting the design as defined in the facilitated design work sessions. Detailed design specifications must be delivered incrementally, as they are developed for each functional area or module, with final approval when all are approved.

8. Systems Documentation Template depicting the outline for the proposed contents of the system documentation for the CHIMES and SFSL applications, which will include at a minimum system information for system administrators, and configuration and content management documentation for application developers and content managers. Types of information to be included in the system documentation include hardware and software, descriptions of the shared services and infrastructural components, and other necessary system information. The systems documentation template should be included in the DSD.

9. Operational Procedures Manual Template depicting the format for the proposed operations manual, which will provide guidelines for the operation and use of the CHIMES and SFSL applications. The operational procedures manual template should be included in the DSD.


development.

2. Provide appropriate staff to attend detailed design work sessions.

3. Provide staff to attend web page/module walkthroughs as necessary.

4. Work with contractor to establish schedule and location for detailed design work sessions.

5. Review and approve detailed system design documentation, within a mutually agreed upon number of business days after receipt.

6. Review and respond to all detailed system design requirements change documents within a specified number of business days after receipt, using the agreed-upon project change control process.

7. Track policy-related changes and training impacts identified during the detailed design sessions.


9. Work with the contractor to resolve issues during the design phase.

5.4. CONSTRUCTION PHASE

5.4.1. Overview During the construction phase, the contractor will build the systems and architecture for the CHIMES-TANF and CHIMES-SNAP systems. The contractor will utilize construction tools and established methodologies for maintaining control of the construction process and ensuring that the construction of the systems and architecture conforms to the requirements and design specifications documented in the prior phases.

Although testing is described as a separate phase for this project, the contractor should coordinate the establishment of testing strategies during the construction phase, to ensure the flow of testing from unit testing to acceptance testing is cohesive. The construction phase will include unit testing to verify that each basic component of the system architecture is constructed correctly in accordance with the design specifications.

The State will provide and support three hosting environments: testing, QA, and deployment. The contractor is responsible for the development environment.

The construction activities related to the development of the SFSL are expected to be completed independently of the construction and unit testing for the CHIMES systems. However, the responsibilities, deliverables, milestones and performance expectations as detailed in this subsection apply to the SFSL just as they do for the CHIMES systems and enterprise architecture.

5.4.2. Contractor Responsibilities 1. Utilize a configuration management process and tools to manage changes to the CHIMES-SNAP and

CHIMES-TANF systems components.

2. Code the CHIMES-SNAP and CHIMES-TANF systems per approved design specifications.

3. Conduct technical reviews and audits of completed system components throughout the construction task, and record problems using the project control and issue reporting system.

4. Develop and submit to the Department a unit test checklist template and unit test plan.

5. Conduct unit testing.

6. Submit results of unit testing to Department on an incremental basis as modules or functional system units are complete.

7. Resubmit unit test results as necessary.

8. Provide weekly updates and performance metrics on unit testing and construction progress to the Department.

9. Demonstrate a working model for the functionality of each module or functional system unit.

10. Perform code walkthroughs as appropriate to demonstrate to the Department that all system functions have been completely and accurately constructed and unit-tested.

5.4.3. Performance Expectations 1. Respond to Department unit test review comments/concerns within five business days of receipt of

Department comments on the incremental unit test results.

2. Report weekly performance metrics data during the construction phase.

5.4.4. Major Milestones 1. Completion of construction/unit test.

2. Unit test completion attestation and unit test checklists delivered and approved by the Department.

5.4.5. Required Deliverables 1. Unit Test Plan describing the contractor’s approach, methodology and schedule for unit testing of the

CHIMES-TANF and CHIMES-SNAP systems.

2. Unit Test Checklist Template depicting in detail the format of the proposed unit test checklists deliverable.

3. Unit Test Checklists for each module, signed by each developer, attesting that each module has been thoroughly unit-tested, meets the checklist criteria, and is therefore ready for integration/system test. Unit test checklists must be delivered incrementally, as they are completed for each module, which includes at a minimum, modules for the CHIMES-SNAP, CHIMES-TANF, enterprise architecture, and shared fiscal services components and various sub-components/modules with final approval when all are approved.


development.

2. Attend code walkthroughs as necessary.

3. Review and approve incremental unit test completion checklists, within a mutually agreed upon number of business days after receipt.


5. Work with the contractor to resolve issues during the construction phase.

5.5. CONVERSION

5.5.1. Overview During conversion, the contractor will convert data contained in TEAMS to CHIMES-SNAP, CHIMES-TANF, and the SFSL. The contractor will migrate data from the legacy system according to conversion parameters that are defined in cooperation with the Department. The contractor will be responsible for the planning,

development, testing, and management of the data conversion process, including the logical and physical data architecture, and use of the data loading tools, and changes to current data values. The Department expects the contractor to utilize automated conversion and minimize manual intervention to the extent possible.

Data conversion will also include development of conversion software and/or manual procedures, testing of conversion programs and procedures, and preliminary conversion of all data. The data conversion stage will demonstrate thorough comprehensive testing of conversion processes, that all data required to support CHIMES-TANF, CHIMES-SNAP, and SFSL processing will be available and accurate. The data conversion stage will have its own life cycle and be performed throughout the DDI phases of the contract. Conversion will occur in the State’s hosting environment.

The conversion activities related to the development of the SFSL are expected to be completed independently of the conversion of data for the CHIMES systems. However, the responsibilities, deliverables, milestones and performance expectations as detailed in this subsection apply to the SFSL just as they do for the CHIMES systems and enterprise architecture.

5.5.2. Contractor Responsibilities 1. Work collaboratively with the TEAMS contractor during the conversion phase.

2. Prepare an outline and obtain acceptance from the Department for the contents and format for each conversion deliverable before beginning work on the deliverable.

3. Develop and submit a conversion strategy and plan for approval by the Department to include, but not be limited to, a description of conversion software and tools to be used, use of automated tools, resources and assumptions, testing approach and progress tracking and reporting approach.

4. Develop and submit a conversion schedule for review and approval by the Department, including TANF File-specific schedule needs.

5. Develop detailed conversion requirements to convert all data from current sources/formats into the CHIMES-TANF and CHIMES-SNAP systems and shared fiscal services, as appropriate.

6. Conduct conversion requirements walkthrough(s) for Department staff to be scheduled in cooperation with the Department.

7. Conduct testing of conversion processes prior to full conversion, and submit results to the Department for review.

8. Provide Department access to conversion testing logs.

9. Correct deficiencies identified during conversion testing, preliminary conversion and final conversion.

10. Convert data from TEAMS according to approved conversion requirements detailing the type of data to convert, the amount of history to convert for each type of data, data transformation rules, including but not limited to financial, benefit, case note, person-level data.

11. Provide conversion results showing before and after data conversion files/formats.

12. Provide technical assistance to the Department to resolve and prepare “clean” data for the conversion process.

13. Obtain written acceptance from the Department on all final deliverables for conversion.

5.5.3. Performance Expectations 1. Respond to Department conversion deliverable review comments/concerns within five business days of

receipt of Department comments on conversion deliverables.

2. Notify the Department of conversion deficiencies weekly during conversion.

3. Report weekly performance metrics data during conversion.

5.5.4. Major Milestones 1. Completion and approval of conversion strategy and plan.

2. Completion and approval of coding of conversion programs.

3. Completion and approval of testing of conversion programs.

4. Completion and approval of conversion testing.

5.5.5. Required Deliverables 1. Conversion Strategy providing the overall description of how the contractor plans to conduct conversion

for the project. This includes, but is not limited to:

a. Scope of conversionb. Approach to conversion testing c. Issue tracking d. Communication e. Resourcesf. Comprehensive description of strategy for both automated and manual conversion of data g. Environments

2. Conversion Detailed Design Specification, which reflects the design and approach for the conversion phase, and addresses how the conversion requirements will be demonstrated successfully during the conversion.

3. Conversion Test Plan, which includes the detailed description for how the contractor will conduct conversion testing. The plan includes, but is not limited to:

a. Introduction – overview, purpose, objectivesb. Scope for conversion test – inclusions, exclusionsc. Approach for conversion testd. Test datae. Data validation, both manual and automatedf. Testing processg. Conversion test entrance/exit criteriah. Test phases and cyclesi. Conversion test schedulej. Resources

i. Peopleii. Hardwareiii. Software

k. Roles and responsibilitiesl. Issue tracking management

i. Communicationii. Prioritization activitiesiii. Severity levelsiv. Toolsv. Reporting

m. Issues/risks/assumptionsn. Signoff sheeto. Any appropriate appendices

4. Conversion Requirements identifying the data sources, data type, years of history for specified data, destination and data changes, at a minimum.

5. Conversion Test Defect Log/Reports, which may be either a commercial defect tracking tool to which the Department has access or a contractor-developed defect log and progress report including, but not limited to, the following:

a. Numberb. Issue namec. Severityd. Statuse. Build

f. Owner6. Conversion Test Results depicting data results of successful conversion test.

7. Preliminary Converted Data including before and after data images/records.

5.5.6. Department Responsibilities 1. Provide quality assurance function for data conversion.

2. Review conversion requirements and participate in conversion requirements discussions as needed.

3. Provide conversion timeframes for the TANF File.

4. Coordinate communication between contractor and the TEAMS contractor to resolve problems during the conversion process.

5. Provide access to TEAMS system content to contractor.

6. Review conversion test results and results of preliminary conversion.

7. Review documented conversion results.

8. Monitor contractor progress to milestones.

9. Work with the contractor to resolve issues during conversion.

5.6. TESTING PHASE

5.6.1. Overview During the testing phase, the contractor is responsible for the conduct of unit, system, integration, and user acceptance testing to ensure that all of the enterprise architecture, shared fiscal services, and CHIMES-TANF and CHIMES-SNAP requirements are satisfied. The contractor will test the software and hardware of the architecture and application to evaluate eligibility determination accuracy and the systems’ compliance with defined requirements. The contractor will perform unit and integrated system testing. The contractor will support the Department in conducting user acceptance testing. The contractor will use State’s testing environment for integration and UAT.

The scope of the system test includes the testing of all CHIMES-TANF and CHIMES-SNAP modules and processes at the unit level, which is primarily conducted overlapping with the construction phase, followed by integrated system testing to validate that individual programs are communicating with each other successfully. Additionally, a parallel test will be conducted in conjunction with the pilot phase, which is described in subsection 5.7.

The UAT stage is designed to demonstrate that the CHIMES-TANF and CHIMES-SNAP systems, as developed by the contractor, meet Department specifications, perform all processes according to the CHIMES business rules, pass acceptance criteria identified by the Department, and work in an integrated fashion with the shared service components, including the SFSL. The UAT is to be conducted primarily by Department users, and will allow the opportunity for users to test the proper application of business rules, the accuracy of benefit determination and eligibility, and the format and content of all CHIMES outputs, including the reporting functions. The UAT must be conducted in a controlled and stable environment, and may utilize all, or select parts of, the preliminary converted files.

The testing activities related to the development of the SFSL are expected to be completed independently of the testing for the CHIMES systems. However, the UAT for the CHIMES-SNAP and CHIMES-TANF systems will incorporate the integration of these systems with the shared fiscal services. The responsibilities, deliverables, milestones and performance expectations as detailed in this subsection apply to the SFSL just as they do for the CHIMES systems and enterprise architecture.

5.6.2. Contractor Responsibilities 1. Work collaboratively with the TEAMS contractor during the testing phase.

2. Prepare an outline and obtain acceptance from the Department for the contents and format for each testing phase deliverable before beginning work on the deliverable.

3. Establish the software and network environment, including connection to the Department network that will be used during testing.

4. Coordinate with the State to utilize the separate State test environment for all testing activities, including system, integration and user acceptance testing.

5. Establish and maintain a permanent test environment for State-only use with current testing information.

6. Develop and implement system and integrated system test progress measurement metrics for the purpose of monitoring testing status. Metrics must include, but are not limited to, the cumulative status of test scenarios as well as those identified with problems and requiring retesting, those that do not require a retest, and the total population of test scenarios remaining throughout the test period.

7. Perform system testing of all CHIMES-TANF and CHIMES-SNAP modules/web pages and submit documented results to the Department for review and approval.

8. Conduct an integration test of CHIMES-TANF and CHIMES-SNAP, along with the shared services components, including system interfaces, and submit documented results to the Department for review and approval.

9. Plan, develop, and test all incoming and outgoing interfaces defined for CHIMES-TANF and CHIMES-SNAP during integrated system testing.

10. Resolve all test scenarios associated with errors and retest system components as necessary.

11. Utilize project control tools to formally track testing results so that the Department can manage the testing progress, problems, and resolutions by module or functional area.

12. Provide training to the Department’s acceptance testing team on preparing input data, using the web screens, understanding the business rules engine and shared services infrastructure, and reviewing CHIMES outputs.

13. Assist the Department in implementation of the acceptance test with respect to generation of test transactions, data, and files as well as analysis of reasons for unanticipated processing results.

14. Provide operations staff to support acceptance test activities.

15. Initiate any batch processes requested by the Department to support user acceptance testing.

16. Make minor modifications to web pages, reports, interfaces, and processes, as directed by the Department, during the testing task.

17. Track the status of problems identified by the Department during the acceptance test.

18. Make available all user acceptance test documentation including files and reports necessary to validate test results.

5.6.3. Performance Expectations 1. Respond to Department test results review comments/concerns within three business days of receipt of

Department comments on the submitted test results and testing phase deliverables.

2. Update and maintain specified testing metrics on a weekly basis for submission to the Department throughout the test period or as otherwise specified by the Department.

3. Make user acceptance test results available to the Department no later than two working days following execution of test cases.

4. The System must have an uptime for User Acceptance Testing in accordance with production specifications - 99.9% uptime during normal business hours of [8:00 a.m. to 5:00 p.m.] Mountain Time.

5.6.4. Major Milestones 1. Delivery and approval of test strategy.

2. Delivery and approval of integration/system test plan and sample test case templates.

3. Delivery and approval of integration/system test cases.

4. Move to integration/system test environment.

5. Department validation of integration/system test results and requirements traceability matrix.

6. Delivery and approval of user UAT.

7. Delivery and approval of UAT training plan.

8. Integration/system test completion, including delivery of updated requirements matrix and system test results.

9. Delivery and approval of UAT test cases.

10. Move to UAT environment.

11. Start user acceptance testing.

12. User acceptance test completion, including delivery of updated requirements traceability matrix and UAT test results.

13. State validation of user acceptance test results and requirements traceability matrix.

5.6.5. Required Deliverables 1. Test Strategy providing the overall description of how the contractor plans to conduct testing for the

project. This includes, but is not limited to:

a. Scope of testb. Approach to unit, integration/system, and user acceptance testing c. Issue tracking d. Communication e. Resources f. Test model and test data g. Environmentsh. UAT training

2. Integration/System Test Plan, which will include the detailed description for how the contractor will conduct integration/system test. The plan includes but is not limited to:

a. Introduction – overview, purpose, objectivesb. Scope for system test – inclusions, exclusionsc. Approach for integration/system test

i. Functional testingii. Performance testingiii. Stress testingiv. Load testingv. Interface testingvi. Batch testingvii. Shared services

d. Testing processe. Integration/system test entrance/exit criteriaf. Test phases and cyclesg. System test scheduleh. Resources


i. Roles and responsibilitiesj. Issue tracking management

i. Communicationii. Prioritization activitiesiii. Severity levelsiv. Toolsv. Reporting

k. Issues/risks/assumptionsl. Signoff sheetm. Appendices

3. Sample Integration/System Test Case Templates, which the Department will review prior to the development of test cases to ensure:

a. The test cases contain all the needed information and only the needed information.b. Formatting provides a clear presentation of information and easy navigation through the

document.c. Test cases are designed according to industry standards.

This deliverable should be included within the System Test Plan.

4. Integration/System Test Cases which the Department will review prior to the development of test cases to ensure:

a. All requirements are being thoroughly tested. b. Tests are being run for different boundary values, invalid values as well as valid values (i.e. test

cases are not designed strictly to ensure that the system works).c. Test cases are completed according to industry standards.d. System test cases are delivered incrementally, as they are completed for each functional area

or module, with final approval when all are approved.

5. Updated Requirements Traceability Matrix, which updates requirements to system test cases, demonstrating that all requirements are tested.

6. System Test Defect Log/Reports, which may be either a commercial defect tracking tool to which the Department has access or a contractor-developed defect log and progress report including, but not limited to, the following:

a. Numberb. Issue namec. Severityd. Statuse. Buildf. Owner

7. System Test Results, which must be delivered incrementally, as they are completed for each functional area or module, with final approval when all are approved.

8. User Acceptance Test Plan, which must include the detailed description for how the contractor will conduct UAT. The plan includes but is not limited to:

a. Introduction – overview, purpose, objectivesb. Scope for UAT Test – inclusions, exclusionsc. Approach for UAT test

i. Stress testingii. Simulation testingiii. Usability testing (this may occur early on in the project, prior to UAT)iv. Requirements verificationv. Shared services

d. Testing processe. UAT test entrance/exit criteriaf. Test phases and cyclesg. UAT scheduleh. Resources


i. Roles and responsibilitiesj. Issue tracking management

i. Communication

ii. Prioritization activitiesiii. Severity levelsiv. Toolsv. Reporting

k. Issues/risks/assumptionsl. Signoff sheetm. Appendices

9. User Acceptance Test Training Plan, which includes how the contractor plans to train users on test case development, test execution, and a schedule for training prior to UAT execution.

10. User Acceptance Test Cases, which must be developed in partnership with Department subject matter experts, UAT test cases will test that the system meets the user requirements and business needs of the Department.

11. User Acceptance Test Defect Log/Reports, which may be either a commercial defect tracking tool to which the Department has access or a contractor-developed defect log and progress report including, but not limited to, the following:

a. Numberb. Issue namec. Severityd. Statuse. Buildf. Owner

12. User Acceptance Test Results and Updated Requirements Traceability Matrix, demonstrating that the CHIMES systems requirements have been tested at the user level during UAT.

5.6.6. Department Responsibilities 1. Provide quality assurance function for the testing phase.

2. Establish the hosting of the test environment (State).

3. Designate a test lead to answer questions, assist with prioritization activities and work with the contractor to resolve issues related to testing.

4. Involve and provide required information to Federal funders.

5. Provide contractor access to subject matter experts (SMEs) for development of user acceptance test cases.

6. Provide resources (acceptable percentage of work time) for development of UAT test cases and UAT test execution.

7. Coordinate resources needed for testing interfaces and web portals, including non-Department resources.

8. Provide resources to work with contractor during system and UAT test execution to prioritize and resolve issues.

9. Use the contractor’s issue tracking system to monitor the contractor’s test progress, or define necessary test reports and desired frequency of reports.

10. Review and approve contractor test deliverables including test strategy, test plans, test cases and test results.

11. Ensure requirements map to system and UAT test cases by reviewing the updated requirement traceability matrix.

12. Prepare acceptance test scenarios and data, and conduct user acceptance testing.

13. Document acceptance test results, and retest as necessary.

14. Attend test phase deliverable walkthroughs, as appropriate, to enhance Department understanding and facilitate the approval process.

15. Approve test results within the agreed upon time frame or provide written documentation to the contractor stating why the test results are not acceptable.


17. Work with the contractor to resolve issues during the testing phase.

18. Review and approve, if applicable, written recommendations for improvement by the contractor.

19. Direct the retesting activities after correction of any problems.

5.7. PILOT PHASE

5.7.1. Overview During the pilot phase, the contractor will assist the Department in implementing a statewide pilot test. This phase will require eligibility workers and WoRC contractors (for TANF only) to enter application information into TEAMS and the new production-ready CHIMES systems, and eligibility results will be compared. Eligibility workers will only test a subset of their total cases during the pilot period. The pilot must occur in the production environment with actual benefits issued.

The Department feels it is necessary to implement a statewide pilot of the CHIMES systems to perform a final test in parallel with the production system all of the functionality that will be delivered in CHIMES. A key objective of the pilot is to “certify” the system for production use and to “certify” each and every eligibility worker in the use of CHIMES. Pilot as a parallel testing environment will validate the eligibility determination and benefits calculation of CHIMES against live production cases being worked simultaneously in the legacy TEAMS system. Montana’s information technology infrastructure differs based on OPA office location. The existing system, TEAMS, will be in production use throughout the pilot until DPHHS finalizes its decision to implement CHIMES.

The contractor will be required to support all aspects of the operational use of the CHIMES systems, the enterprise architecture infrastructure, and the shared fiscal services during pilot, including providing a help desk to support pilot users. The help desk will be responsible for documenting user problems, providing assistance where possible, and referring outstanding problems to the enterprise architecture support team, or other resources required to resolve the user’s problem. The help desk will be responsible for monitoring the resolution of problems and escalating problems that are not being addressed in a timely manner.

The SFSL will be tested and implemented before the CHIMES pilots. The contractor must show how CHIMES-SNAP and CHIMES-TANF successfully use the SFSL to process benefits during the pilot.

This phase will also require the contractor to develop systems documentation, operating procedures, and to plan and schedule training. This phase will end with the Department accepting the operational readiness of the CHIMES-TANF and CHIMES-SNAP systems.

5.7.2. Contractor Responsibilities 1. Work collaboratively with the TEAMS contractor during the pilot phase.

2. Prepare an outline and obtain acceptance from the Department for the contents and format for each pilot phase deliverable before beginning work on the deliverable.

3. Work with Department to determine pilot schedule.

4. Work with Department to determine pilot strategy.

5. Develop pilot/parallel testing instructions for pilot participants/users.

6. Produce technical system documentation for CHIMES-TANF, CHIMES-SNAP, and the SFSL.

7. Develop operating procedures.

8. Develop online help features.

9. Create/modify an online user manual designed to guide end-users step-by-step.

10. Develop a training plan that includes training goals, timelines, and training delivery methods.

11. Develop training modules that can be delivered to all end users specified by the Department. All end users should be trained using a combination of computer-based training/online training and train-the-trainers.

12. Train up to 50 Department super users in person.

13. Define and document help desk processes and procedures.

14. Operate and manage help desk operations during pilot and transition.

15. Record and track identified user problems during pilot.

16. Provide an implementation ready pilot system environment.

17. Utilize converted data and provide for necessary temporary conversion of data that may be needed for pilot, using cross walks if applicable.

18. Provide a method to report the parallel results of processing the same cases through the current system and compare the results to the CHIMES systems during pilot.

19. Provide weekly reporting of response times, problems encountered, and solutions.

20. Identify, report and resolve problems encountered during the pilot test within predefined guidelines as defined by the Department.

21. In collaboration with the Department, define performance and problem resolution guidelines (based on problem severity) to be used during pilot testing.

22. Evaluate system reliability and performance.

23. Modify CHIMES-TANF, CHIMES-SNAP, and the SFSL, when appropriate, to address problems discovered during the pilot.

24. Obtain written acceptance from the Department on the final pilot deliverables.

5.7.3. Performance Expectations 1. User manuals and online help features must be comprehensive and easy to understand.

2. Training materials must be developed with the end user in mind and must be easily understood by both trainers and trainees.

3. Provide accessibility of contractor operations personnel to Department personnel, Monday through Friday from 8:00 a.m. to 5:00 p.m. Mountain Time. This includes all regularly scheduled Department employee business days.

4. Provide the availability of contractor personnel with reasonable prior notice after 5:00 p.m. Monday through Friday and on weekends.

5. The help desk must contact the reporting user before closing any problem report.

6. The contractor will provide and staff a help desk support service to be available to authorized users between 8 a.m. through 5 p.m. Monday through Friday.

7. The contractor will research and respond to user within four hours of the inquiry to the help desk.

8. All system problems/deficiencies identified during pilot must be resolved or a course of action for the problem must be identified to the satisfaction of the Department.

9. The contractor will demonstrate successful pilot operations by meeting the accuracy, response, and system performance standards from Sections 4.8.4 and 7.1.4 for the pilot transactions.

5.7.4. Major Milestones 1. Completion of scheduled pilot training sessions.

2. Completion and Department approval of pilot results where all deficiencies/problems are addressed based on performance expectation regarding the acceptable level of problems.

3. Approval attestation of CHIMES-TANF and CHIMES-SNAP by pilot participants/users.

5.7.5. Required Deliverables 1. Pilot Strategy, which provides the overall description of how the contractor plans to conduct and

coordinate the pilot activities. This includes, but is not limited to:

a. Scope of the pilotb. Approach to pilotc. Issue trackingd. Communication and help deske. Resourcesf. Pilot trainingg. Environments

2. Pilot Instruction Handbook, which must guide the pilot participants in the use of the system during the pilot including access to the help desk, and comparison with the existing system.

3. Operational Procedures Manual, which will include, but not be limited to the necessary operating procedures for the generation of reports and letters, case notes, and queries, and navigation through the web pages, according to the template developed during the design phase.

4. System Documentation, which will include system information for the CHIMES and SFSL applications describing the system processes, description of hardware, software, shared services, and infrastructural components and other necessary system information, according to the template developed during the design phase.

5. Online User Manuals to include, but not be limited to, navigation instructions, menu selections, error messages, and detailed instructions on how to perform system tasks.

6. Training Plan describing the commitment of contractor staff to provide initial training and ongoing training to Department staff and that incorporates detailed plans, documentation, procedures, and presentation materials for conducting training for CHIMES-TANF and CHIMES-SNAP users and TANF and SNAP program staff.

7. Training Sessions/Modules that are delivered as part of the pilot phase, according to the schedule set forth in the Training Plan.

8. Pilot Test Results and Updated Requirements Traceability Matrix, demonstrating that the CHIMES systems requirements have been tested at the user level during pilot.

5.7.6. Department Responsibilities 1. Provide quality assurance function for the pilot phase.

2. Involve and provide required information to Federal funders.

3. Work with contractor to define pilot schedule.

4. Identify and provide to the contractor a listing of pilot locations and users.

5. Coordinate pilot participation among Department and contracted users.

6. Complete pilot testing activities, including, but not limited to, using the CHIMES systems to process eligibility, conduct case management activities, and authorize benefits.

7. Provide resources to work with contractor during the pilot execution to prioritize and resolve issues.

8. Review and approve contractor pilot phase deliverables including updated system documentation, user manuals and training materials.

9. Work with the contractor to define problem resolution guidelines to be used during pilot.


5.8. IMPLEMENTATION PHASE

5.8.1. Overview The contractor will deploy the CHIMES systems in conjunction with the enterprise architecture after successfully completing the testing and pilot phases. As indicated earlier in this section, the Department

expects that the contractor will independently deploy the SFSL in cooperation with the Business and Financial Services Division. The SFSL implementation will occur before CHIMES implementation. The State will host the SFSL, CHIMES systems, and the enterprise architecture.

For the implementation phase, the contractor will perform the final data conversion of all files necessary for CHIME-TANF and CHIMES-SNAP to work in conjunction with the shared architecture framework. The final step is to officially accept and cutover to the new CHIMES functionality. This will include notification to users of the date from which all TANF and SNAP cases must be entered, provide new operating procedures, and officially accept and cutover to the new CHIMES functionality.

5.8.2. Contractor Responsibilities 1. Work collaboratively with the TEAMS contractor during the implementation phase.

2. Finalize the implementation schedule.

3. Obtain Department approval for the implementation of CHIMES-TANF, CHIMES-SNAP, the enterprise architecture, and the SFSL.

4. Update system documentation and operating procedures. Note clearly in documents for Department review where updates have been made.

5. Conduct orientation and training for Department personnel from the Technology Services Division, the Business and Financial Services Division (for the SFSL), and Human and Community Services Division on contractor organization, functional responsibilities for software maintenance, and operational procedures.

6. Perform final conversion and review conversion reports to demonstrate successful conversion.

7. Provide a final operational readiness certification based on an operational readiness assessment, including, but not limited to, results of the parallel test and an assessment of the final operational readiness of contractor staff to maintain the system software in conjunction with the shared services and enterprise architecture.

8. Monitor the initial operation of the CHIMES systems and the SFSL to ensure that there are no immediate or ongoing adverse effects on the ability of TANF and SNAP programs and contracted workers to enter and process benefit applications according to the performance standards included in Sections 4.8.4 and 7.1.4.

9. Report on post-implementation issues and success for CHIMES-TANF, CHIMES-SNAP, the enterprise architecture, and the SFSL.

10. Submit weekly written status reports on the progress of tasks against the work plan.

11. Conduct weekly status meetings with appropriate Department staff.

12. Identify and report any implementation issues to Department.

13. Work with other system vendors and the Department to establish and ensure appropriate system and business interfaces to successfully meet the implementation requirements.

5.8.3. Performance Expectations 1. Successfully implement the fully operational CHIMES-TANF, CHIMES-SNAP, enterprise architecture and

SFSL. Fully operational is defined as meeting the system performance and accuracy standards cited in Sections 4.8.4 and 7.1.4 for all SNAP and TANF transactions, for the enterprise architecture, and using the SFSL for shared fiscal services.

2. The contractor shall submit updated system documentation no later than 45 days following the date of official implementation/cutover.

3. The contractor shall provide weekly reports on post-implementation monitoring of key transition and cutover criteria for no less than six months following implementation/cutover.

5.8.4. Major Milestones 1. Completion of scheduled implementation training sessions.

2. Department approval of operational readiness assessment.

3. Cutover to CHIMES and the SFSL from TEAMS for full operations (e.g., implementation/cutover).

5.8.5. Required Deliverables 1. Updated System Documentation, including all hardware, software, shared services, and infrastructural

components and impacts.

2. Updated Operational Procedures Manual, including overviews of operational components, procedures for use, including, but not limited to the generation of reports, queries, letters and case notes.

3. Operational Readiness Assessment Report, including the contractor’s demonstrated assessment of the systems’ readiness for full production use.

4. Statement of Resources, which must include an estimate of the number, type, and salary of personnel required to perform the other functions of the CHIMES-TANF and CHIMES-SNAP systems. The statement shall be separated by type of activity of the personnel, including, but not limited to, the following categories:

a. Software developersb. Database developersc. Data processing staff (for modification support) d. Systems analysts e. Systems programmers f. Programmer analysts g. Administrative staff h. Other support staff

The statement shall include all facilities and any other resources required to operate the CHIMES-TANF and CHIMES-SNAP systems, including, but not limited to:

a. Telecommunications networks b. Office space

The statement of resource requirements shall be based on the contractor's experience in the operation of the CHIMES-TANF and CHIMES-SNAP systems and shall include actual contractor resources devoted to operations activities.

This deliverable should be contained within the Operational Readiness Report.

5. Post-Implementation Operational Monitoring Plan, including methods and schedules for the Department to conduct post-implementation monitoring of the system operations related to performance standards for operations.

5.8.6. Department Responsibilities 1. Review final conversion results and parallel test result reports as appropriate.

2. Make Department program and contracted staff available for final training/orientation.

3. Approve implementation of CHIMES-TANF and CHIMES-SNAP.

4. Review and approve updated system documentation, updated operational procedures, operational readiness assessment report, and operational monitoring plan.

5. Work with contractor to resolve problems during the implementation phase.

5.9. OPERATIONS AND MAINTENANCE PHASE

5.9.1. Overview This phase includes all activities involved in the operations maintenance of the eligibility systems and enterprise architecture for a minimum of three years of operations. All system and architecture functions must be performed by the contractor as directed by the Department in compliance with Federal and State requirements, statutes, and regulations.

The first year of the three-year period will constitute the warranty period, during which the contractor is responsible for all fixes needed to ensure that the systems and architecture operate according to Department

specifications. This warranty period will begin at the time that the Department has accepted the CHIMES-TANF and CHIMES-SNAP eligibility systems, and the results of the pilot phase have been approved and accepted by the Department. During the warranty period, the contractor will correct, at its expense, any defects reported by the Department, which do not meet the agreed-upon design specifications. No additional charges for computer resources needed to maintain or correct the system shall be authorized. Upon completion of the warranty period, the contractor will be responsible for the maintenance and support of the CHIMES-TANF and CHIMES-SNAP systems throughout the remaining contract operations and maintenance period. A service level agreement (SLA) will be part of the final contract to address the technical support expectations for the contractor.

A separate one-year warranty period will be in effect upon the successful implementation and Department approval of the shared fiscal services library of services.

The contractor will continue to maintain the eligibility systems and enterprise architecture for three years. The contractor will be responsible for maintaining and upgrading the software as part of the maintenance responsibilities, and providing operational support to be performed during the contract term. The contractor is responsible for ensuring that eligibility determination remains accurate throughout the maintenance period. The State will operate the hardware, but the contractor remains responsible for the software, which is the platform for eligibility determination. Operational support involves all processes necessary to meet the requirements outlined throughout this RFP. The contractor must perform all operations maintenance and support as a routine activity during this phase. Maintenance and support as a routine activity will be provided at no additional cost to the Department. The contractor will charge for approved modifications to CHIMES-TANF and CHIMES-SNAP based on a contractually agreed approach and amount.

The contractor will be responsible for modifying the CHIMES-TANF and CHIMES-SNAP systems throughout the term of the contract. All system modifications/improvements will be made using approaches included in industry best practices, such as the Software Development Life Cycle (SDLC), as approved by the Department. Examples of a modification include the following:

Functionality not specified in this RFP or agreed to during the design phase. A system modification to an established report, screen, or file format, new data fields, or new business

rules. Software enhancement resulting from the Department or the contractor determining that a mandatory

additional requirement results in a change to existing file structures, data sets, or current processing logic.

Such modifications are distinct from maintenance and support.

5.9.2. Contractor Responsibilities The following contractor responsibilities apply to the contractors’ operational support of the CHIMES-TANF and CHIMES-SNAP functional system infrastructure, to include, but not be limited to, the business rules engine, interface processes, web pages, navigation, and the enterprise architecture components.

1. Develop and submit an operational procedures plan, describing the roles and responsibilities of the contractor and Department.

2. Maintain operational functioning of the CHIMES-TANF and CHIMES-SNAP eligibility systems, which includes accurate eligibility determination, the seamless-appearing single entry point for the system users, the use of common client IDs and the common eligibility and authorization interface components, business rules engine components for CHIMES-TANF and CHIMES-SNAP, and correspondence generation.

3. Maintain operational functioning of the SFSL, which includes account coding, payment processing, journals, exception processing, reporting and querying, data storage and interface processing.

4. Perform these ongoing maintenance support activities:

a. Regularly refresh or update data files. b. Initiate routine production schedules.c. Refresh links and data on web browser-enabled reports.

d. Maintain business rules engine.e. Maintain tables/databases that are not automatically updated during scheduled data loads.f. Maintain security on a database, network, and individual user level, including maintenance of

user accounts. g. Maintain all database and application servers and related hardware, except for Department-

designated server/hardware updates.h. Support archiving requirements outlined in subsection 7.145.

5. Perform research immediately upon recognizing potential system problems.

6. Maintain operations of the CHIMES-TANF and CHIMES-SNAP eligibility systems on the State’s servers.

7. Maintain operations of the SFSL on the State’s servers.

8. Provide and install upgrades of software during operations of the CHIMES-TANF and CHIMES-SNAP systems. Proactively maintain all software.

9. Maintain a correspondence generation application on the State’s servers.

10. Provide software training sessions for Department staff, Department contractors, and other State agencies when requested by the Department.

11. Updates, patches and repairs to components of the production, test and all other accessible environments should include, but are not limited to:

a. Operating systemsb. Database systemsc. Application and other softwared. Utilities for systems, database, software, communications e. Voice, video, data communications linesf. Communications softwareg. Driversh. Configurations

12. Correct (including development, testing, training and implementation) the following:

a. Deficiencies or problems with the application functionality of the CHIMES-TANF and CHIMES-SNAP eligibility systems.

b. Deficiencies or problems with the functionality developed or implemented specifically during the design phase.

c. Deficiencies or problems with the functionality of subsequent system improvements.

13. Provide help desk functionality (originally provided during the pilot operations phase) that includes a toll-free help desk and end user support service.

14. Maintain a help desk log that is electronically accessible to Department personnel.

15. Monitor the daily operations performance of CHIMES-TANF, CHIMES-SNAP, the enterprise architecture, and the SFSL.

16. Submit operations problem/trouble reports to the Department when operational problems occur, describing the nature of the problem, the expected impact on ongoing functions, a corrective action plan, and the expected time of problem resolution.

17. Develop updated user and system documentation, wherever applicable.

18. Track operations and maintenance hours by categories of routine system maintenance/operation and specific TANF, SNAP, EA, and SFSL requirements as requested.

19. Develop warranty defect correction approach.

20. Correct defects identified by the Department and/or contractor.

21. Conduct unit and system testing of corrected defects, and report results to State.

22. In the event of software upgrades to the State servers, notify all authorized users via email of the anticipated upgrade installation date, and length of time the State servers will be unavailable to the authorized users.

23. Prepare agenda in conjunction with the Department for weekly status meetings with Department staff. Status meetings must include reporting on current operations, progress on system operational maintenance, and system modification activities separately, and review of any deliverables submitted.

24. Offer recommendations to the Department on any improvements or efficiencies related to the hosting environment and network configuration.

25. Obtain written acceptance from the Department on all final deliverables for the operations phase.

26. Conduct ongoing training for Department-defined system users during the operations phase.

27. Provide source code to the Department as requested, and according to software version release schedule.

28. Participate and provide data and support to Department and any QA contractors in the performance of code reviews.

29. Assure that all licensed products for the systems are upgraded to the current, stable version. These products should not be allowed to lapse into an unsupported version.

30. Publish a software version release schedule, and provide updates to the Department as necessary.

31. Conduct detailed requirements analysis for major changes, including recommendations, if any, for alternate approaches to meet the Department’s needs.

32. Provide to the Department an assessment of the effort (number of programmer and business analyst hours) required to complete any requested or needed system modification.

33. Prepare a formal design estimate and requirements analysis for each approved system modification.

34. Utilize change management software that can be accessed by the Department as well as contractor staff. This software must track all system modification requests with information on stage of development, priority, staff assigned, and dates associated with each stage of development. The software should also allow for automatic notification of test problem logs, allow for assignment of those problems for resolution, and project plan development.

35. Prepare and submit a test plan for approval when required.

36. Code programs/modifications.

37. Perform systems test.

38. Submit test results for review and approval.

39. Implement modifications following Department approval.

40. Verify the successful implementation of the modification, through post-implementation monitoring.

41. Verify that data integrity is maintained throughout as a result of any modifications.

42. Submit a monthly invoice and supporting documentation for administrative reimbursement of operations, as specified by the Department.

43. During the warranty period, provide monthly warranty period status report with description of defects identified, defects corrected, and other issues as needed.

44. Following the warranty period, provide monthly reports to the Department on all system operation and modification activities, including help desk activity, and for each outstanding system modification, its expected completion date; progress toward completion (including hours worked by individual during the period); and estimated staff hours to completion, sorted by status and priority.

45. The contractor shall also be responsible for reporting monthly to the Department, all systems changes that have been implemented in the month. This monthly report will also include a three-month projection of the system modification activity that will be implemented in each month. Major projects requiring more than three months to complete, will also be noted with a status update on project milestones.

5.9.3. Performance Expectations 1. Provide accessibility of contractor operations personnel to Department personnel, Monday through Friday

from 8:00 a.m. to 5:00 p.m. Mountain Time. This includes all regularly scheduled Department employee business days.

2. Provide the availability of contractor personnel with reasonable prior notice after 5:00 p.m. Monday through Friday and on weekends.

3. The help desk must contact the reporting user before closing any problem report.

4. Submit operations trouble reports no later than at the close of business on the day the problem is identified.

5. The contractor must ensure that the average software response time for a single inquiry to the database by authorized users will not exceed five seconds, understanding that the State network must be adequate to deliver the transactions in a timely way to the end user.

6. The average software processing time for transmissions through the application to receive and retrieve results from the database, and send back the results shall not exceed ten seconds, understanding that the State network must be adequate to deliver the transactions in a timely way to the end user.

7. Ensure that CHIMES-TANF, CHIMES-SNAP, the enterprise architecture, and the SFSL are operational and accessible to authorized users a minimum of 12 hours a day, five days a week, on State business days.

8. Following the completion of any software upgrades or application releases, the contractor must immediately notify authorized users via email when servers are available.

9. Provide and staff a help desk support service to be available to authorized users between 8 a.m. through 5 p.m. Monday through Friday.

10. Research and respond to user within four hours of the inquiry to the help desk.

11. Submit operations and maintenance phase status reports to the Department on a regular bi-monthly schedule and on request.

12. Provide routine maintenance of the system at no charge to the Department during the warranty period.

13. Provide a breakdown of personnel resources expended during the month on the monthly invoice, according to a Department-defined breakdown of management, administrative and development/programming personnel.

14. Respond in writing to notices of system problems and modification requests issued by the Department within five business days of receipt. Reasonable time frames for performance of system changes requests shall be established as part of the Department’s approval process, including mutual agreement on the start date for the approved work and the acceptance of the estimated hours to complete the request.

15. Respond, in writing, to requests for estimates of system modification efforts submitted by the Department within three business days of receipt, unless specified for large project planning (which may increase that time frame).

16. Develop and submit updated systems/operational procedures documentation related to a system modification within 20 business days of its successful implementation.

5.9.4. Major Milestones 1. Department acceptance and approval of the completion of the warranty period.

2. Completion of all warranty period system defects.

3. Department acceptance and approval of completed system changes, as demonstrated through testing and post-implementation monitoring.

5.9.5. Required Deliverables 1. Change Request Forms submitted with estimate of hours and anticipated timeframe for completion.

2. Requirements Specifications for major approved change requests.

3. Electronic Help Desk Log with a record of help desk inquiries and responses.

4. Training Session Materials and Agendas for all relevant training requested by the Department.

5. Monthly Reports on System Operation and Modification Activity including system modification change requests, help desk activity, and other statistics to be determined.

6. Monthly Warranty Period Status Reports including description of defects identified and corrected.

7. Formal Design Estimate for each approved system modification. This should define the problem to be addressed, propose a solution, and specify an estimated level of effort (number of hours) and anticipated schedule required to design, code, test, and implement the change, then approve or revise the request, assign a priority to it, and establish an expected completion date.

8. Source Code and Software Updates for each system modification once it is completed.

9. Updated Operational Procedures and System Documentation delivered when determined by the Department and/or contractor to be applicable.

10. Ongoing Support/Maintenance Plan describing the system modification methodology and approach, as well as operational procedures and maintenance schedules.

11. Change Management Software Tool for tracking system change activity.

5.9.6. Department Responsibilities 1. Serve as a liaison between the contractor and other agencies and/or Federal agency representatives.

Provide quality assurance and oversight of system functionality to ensure TANF and SNAP business needs are met and to ensure operational performance.

2. Review and approve operating procedures defining responsibilities of contractor and Department, and request revisions as necessary.

3. Allow for contractor access to State servers/hosting environment.

4. Prepare and submit to the contractor a written change request for Department-initiated modifications.

5. Determine priority of change requests and monitor system modification activities.

6. Assist the contractor in conducting a detailed requirements analysis on any major changes as required.

7. Monitor system modification activities.

8. Participate in acceptance testing of modifications in a partnership with the contractor.

9. Approve implementation of a modification prior to its installation in the production CHIMES-TANF or CHIMES-SNAP environment.

10. Initiate, or review and follow up on, operations problem reports.

11. Monitor the resolution of problems identified by the contractor or Department staff.

12. Notify the contractor of performance problems, providing written notification of failures to meet performance requirements.

13. Conduct routine hardware maintenance functions.

14. Conduct back-up processes.

15. Review written recommendations by contractor for improvement.

16. Review and approve modification requests.

17. Monitor the contractor’s systems work and systems performance for accuracy and timeliness.

18. Review and approve updates to system documentation.

19. Review and approve updates to user documentation and operations procedures (if required).

5.10. TURNOVER PHASE

5.10.1. Overview The contractor will transition operations of the eligibility systems to the State or a new contractor during the turnover phase. The major activities in this phase will be transition planning, ensuring State/new contractor readiness for operations including a period of knowledge transfer from the contractor to the State or a new contractor, completing a successful trial application and decision table release in a test environment, and turning over the CHIMES systems and enterprise architecture to State or new contractor operations.

The contractor will be required to develop and submit a turnover plan and procedures to be included in the last contract year scope of work. The turnover activities will be inclusive in the contractor’s final year contract fee. The Department will not incur any additional cost regarding the turnover activities.

The contractor will transition operational responsibility for the SFSL to the State at the end of the one-year warranty period. Therefore, the responsibilities, deliverables, milestones and performance expectations described in this subsection will apply to the SFSL turnover at that time.

5.10.2. Contractor Responsibilities 1. Develop and submit turnover plan, detailing the contractor’s schedule and plan to coordinate and prepare

for role transitions from contractor to Department or new contractor staff.

2. Develop and submit a statement of operational resources needed for Department/new contractor review.

3. Designate a member of the contractor’s staff as the turnover coordinator.

4. Create knowledge transfer strategy and plan detailing a plan for affecting a thorough knowledge transfer from contractor staff to State/new contractor staff.

5. Conduct formal knowledge transfer from contractor to State/new contractor staff, including scheduling training.

6. Conduct operational procedures walkthrough with Department/new contractor staff.

7. Perform an operational readiness test to compare Department/new contractor capacity and understanding of operational processes with contractor’s operations to determine that the system turnover is effective.

5.10.3. Performance Expectations 1. At least 12 months before the end of the base contract (or any extension thereof), the contractor must

provide, at no additional cost, a turnover plan to the State/new contractor for the turnover of the CHIMES systems.

2. At least four months before the end of the one-year warranty period for the SFSL, the contractor must provide, at no additional cost, a turnover plan to the State for the turnover of the SFSL.

3. At least 12 months prior to the end of the base contract period (or any extension thereof), the contractor must furnish, at no extra charge, a statement of the resources that would be required by the State or new contractor to fully take over the operations and maintenance of the CHIMES-TANF and CHIMES-SNAP systems.

4. As requested, but approximately six months prior to the end of the base contract period, or any extension thereof (four months for the SFSL), transfer to the State or its agent, as needed, the following:

a. System documentation, including, user manuals needed to maintain the system b. Initial training of State/new contractor staff in the maintenance activities for CHIMES-TANF and

CHIMES-SNAP, or the SFSL.

5. All training must be completed at least three months prior to the end of the contract.

6. At least six months prior to the end of the base contract (or any extension thereof), the contractor shall provide an updated CHIMES-TANF and CHIMES-SNAP turnover plan and resource statement.

5.10.4. Major Milestones 1. Department acceptance and approval of operational readiness assessment.

2. Department acceptance of turnover/transfer of operations role to State/new contractor.

3. Training complete for State/new contractor staff.

5.10.5. Required Deliverables 1. Turnover Project Plan; the plan shall specifically include:

a. Proposed approach to turnover b. Tasks and subtasks for turnover

c. Training plan d. Schedule for turnover e. Documentation update procedures during turnover

2. Updated Statement of Resources, described within the implementation phase.

3. Knowledge Transfer Strategy and Plan to describe contractor’s approach to knowledge transfer, including, but not limited to, training, documentation, and other communication techniques for the CHIMES systems and the SFSL.

4. Maintenance and Support Readiness Assessment of State/new contractor readiness to assume maintenance and support activities.

5.10.6. Department Responsibilities 1. Request turnover services be initiated by the contractor.

2. Review and approve a turnover plan to facilitate transfer of the contractor responsibilities to the Department or a new contractor.

3. Review and approve a statement of staffing and operations resources that would be required to take over operation.

4. Make Department staff available (if applicable) to be trained in the maintenance and support activities of CHIMES-TANF, CHIMES-SNAP, and the SFSL.

5. Coordinate communication, among the contractor and Department and State ITSD personnel during the turnover and operations readiness activities.

6. Purchase and maintain adequate user licenses, if applicable.


8. Work with the contractor to resolve issues during the turnover phase.

5.11. MAJOR MILESTONES SUMMARY

Start-Up Phase (5.1.4)1 Delivery and Department approval of project initiation and detailed project work plan.Detailed Requirements Definition (5.2.4)2 Completion of detailed requirements sessions.

3 Delivery and Department approval of complete detailed requirements specification document.Design Phase (5.3.4)4 Completion of detailed system design sessions.5 Completion and Department approval of detailed system design specifications.Construction Phase (5.4.4)6 Completion of construction/unit test7 Unit test completion attestation and unit test checklists delivered and approved by the DepartmentConversion (5.5.4)8 Completion and approval of conversion strategy and plan.

9 Completion and approval of coding of conversion programs.

10 Completion and approval of testing of conversion programs.11 Completion and approval of conversion testing.Testing (5.6.4)12 Delivery and approval of test strategy.

13 Delivery and approval of integration/system test plan and sample test case templates.14 Delivery and approval of integration/system test cases.15 Move to integration/system test environment.

16 Department validation of integration/system test results and requirements traceability matrix.

17 Delivery and approval of user UAT.

18 Delivery and approval of UAT training plan.

19Integration/system test completion, including delivery of updated requirements matrix and system test results.

20 Delivery and approval of UAT test cases.21 Move to UAT environment.

22 Start user acceptance testing.

23User acceptance test completion, including delivery of updated requirements traceability matrix and UAT test results.

24 State validation of user acceptance test results and requirements traceability matrix.Pilot Phase (5.7.4)25 Completion of scheduled pilot training sessions.

26Completion and Department approval of pilot results where all deficiencies/problems are addressed based on performance expectation regarding the acceptable level of problems.

27 Approval attestation of CHIMES-TANF and CHIMES-SNAP by pilot participants/users.Implementation Phase (5.8.4)28 Completion of scheduled implementation training sessions.29 Department approval of operational readiness assessment.30 Cutover to CHIMES from legacy system for full operations (e.g., implementation/cutover).Operations and Maintenance Phase (5.9.4)31 Department acceptance and approval of the completion of the warranty period.32 Completion of all warranty period system defects.

33Department acceptance and approval of completed system changes, as demonstrated through testing and post-implementation monitoring.

Turnover Phase (5.10.4)34 Department acceptance and approval of operational readiness assessment.35 Department acceptance of turnover/transfer of operations role to State/other contractor.36 Training complete for State/other contractor staff.

5.12. REQUIRED DELIVERABLES SUMMARY

Start-Up Phase (5.1.5)1 Detailed Project Work Plan 2 Quality Assurance/Quality Management Plan3 Contractor Project Staffing Plan4 Project Issue Reporting System5 Project Communication Plan6 Project Management Plan7 Recommendations for the Disaster Recovery Plan8 Identification of Impacts to Department Infrastructure CapacityDetailed Requirements Definition (5.2.5)9 Requirements Definition and Validation Plan10 Facilitated Requirements Work Sessions11 Requirements Session Meeting Minutes12 Updated Requirements Traceability Matrix13 Detailed Requirements Specification Template14 Detailed Requirements Specification Document15 Business RulesDesign Phase (5.3.5)16 Detailed System Design Plan17 Facilitated Design Work Sessions18 Detailed System Design Session Meeting Minutes19 Updated Requirements Traceability Matrix

20 Updated Business Rules21 Detailed Design Specification Template22 Detailed Design Specification Document23 System Documentation Template24 Operational Procedures Manual TemplateConstruction Phase (5.4.5)25 Unit Test Plan 26 Unit Test Checklist Template27 Unit Test Checklists Conversion (5.5.5)28 Conversion Strategy 29 Conversion Detailed Design Specification30 Conversion Test Plan 31 Conversion Requirements 32 Conversion Test Defect Log/Reports33 Conversion Test Results 34 Preliminary Converted Data Testing (5.6.5)35 Test Strategy 36 Integration/System Test Plan 37 Sample Integration/System Test Case Templates 38 Integration/System Test Cases 39 Updated Requirements Traceability Matrix 40 System Test Defect Log/Reports 41 System Test Results 42 User Acceptance Test Plan 43 User Acceptance Test Training Plan 44 User Acceptance Test Cases 45 User Acceptance Test Defect Log/Reports 46 User Acceptance Test Results and Updated Requirements Traceability Matrix Pilot Phase (5.7.5)47 Pilot Strategy48 Pilot Instruction Handbook49 Operational Procedures Manual50 System Documentation51 Online User Manuals 52 Training Plan 53 Training Sessions/Modules 54 Pilot Test Results and Updated Requirements Traceability MatrixImplementation Phase (5.8.5)55 Updated System Documentation 56 Updated Operational Procedures Manual57 Operational Readiness Assessment Report58 Statement of Resources59 Post-Implementation Operational Monitoring PlanOperations and Maintenance Phase (5.9.5)60 Change Request Forms61 Requirements Specifications62 Electronic Help Desk Log63 Training Session Materials and Agendas64 Monthly Reports on System Operation and Modification Activity65 Monthly Warranty Period Status Reports

66 Formal Design Estimate67 Source Code and Software Updates 68 Updated Operational Procedures and System Documentation69 Ongoing Support/Maintenance Plan70 Change Management Software Tool Turnover Phase (5.10.5)71 Turnover Project Plan72 Updated Statement of Resources73 Knowledge Transfer Strategy and Plan74 Maintenance and Support Readiness Assessment

SECTION 6. ENTERPRISE ARCHITECTURE

6.0. OVERVIEW

With this procurement, DPHHS is moving away from monolithic and outdated legacy systems and toward its vision of web-based, people-friendly, and interoperable systems meeting and exceeding program needs. Enterprise architecture is the centerpiece of this shift from the present to the future. The architecture will allow the separate, standalone systems to communicate using exposed, shared services through a common architecture. System users will be able to use the three systems seamlessly, and not have to enter the same information multiple times.

The architecture created for the CHIMES systems will reshape the way DPHHS serves Montanans and does business going into the future. The CHIMES enterprise architecture will become the DPHHS enterprise architecture as systems are replaced. The Department plans to replace its Medicaid Management Information System, Montana Automated Child Welfare Information System, and Child Support system within the next five years. These systems and other future systems will be expected to take advantage of, operate within, and potentially expand upon the enterprise architecture designed as a result of this procurement.

6.0.1. Guiding Principles The Department developed overarching guiding principles to serve as the basis for how the enterprise architecture will operate with the CHIMES eligibility systems.

1. DPHHS will have three separate eligibility systems – Medicaid, SNAP, and TANF.

2. OPA workers will not be required to enter information for one program already entered in another program.

3. The Department will have a library of services that allow information to be shared between the systems.

4. A navigation flow between screens in each system will guide a user to the information that is missing.

5. Services will be created for information that is governed by program rules and regulations, which will give programs the flexibility to define data differently.

6. Historical information will be accumulated and maintained by each program for a case or client from the application date. Historical information accumulated by one program will not be shared with another.

7. Data that is not program-specific (e.g., case notes) will be shared by all three eligibility systems. This data will be stored and maintained in a data structure that is shared by all three systems. Access to this data will be governed by security roles.

8. Components and features of the enterprise architecture must subscribe to open standards and be flexible and scalable to allow for the addition of future systems and the expansion of the user base.

These principles are the foundation for the enterprise architecture requirements included in this section of the RFP. The components of the architecture and associated requirements are listed in the following subsections. The architectural requirements are focused on the CHIMES eligibility systems, while knowing its use will expand beyond this scope in the future.

These requirements represent the Department’s conceptual vision. DPHHS hopes that offerors will propose technology and tools to successfully implement this vision. The Department does not want to constrain any offeror’s creativity. DPHHS will be excited to receive proposals with alternative approaches if an offeror believes there is a better way to tackle the enterprise architecture.

6.1. SERVICE-ORIENTED ARCHITECTURE

Service-oriented architecture (SOA) will have a prominent role in the implementation of the enterprise architecture required by the CHIMES systems. SOA is an architectural style that involves the use of services to accomplish a function and promotes the use of information technology to automate the consumption and provision of services. The Department expects to utilize SOA as an approach for the realization and maintenance of business processes that span the enterprise. The SOA developed for the CHIMES eligibility systems will be used to facilitate functional re-use and data sharing among loosely coupled services.

6.1.1. Functional System Requirements Req # Requirement Description

1 The architecture must utilize service-oriented architecture.

2Services must be self-contained pieces of business functionality deployed as discrete pieces of code and/or data structures that can be reused.

3Services must be loosely coupled to reduce system dependencies to minimize the effects of modifications.

6.1.2. Performance Standards 1. Services developed within the service-oriented architecture must adhere to the same performance

standards expected by program and system-specific code that will be developed for these systems.

6.1.3. Contractor Responsibilities 1. The services developed within the service-oriented architecture must be done using standard system

development life cycle methodologies.

2. Make written recommendations on any area in which the contractor or Department thinks improvement can be made to the service-oriented architecture design and operation.

6.1.4. Department Responsibilities 1. Work with contractor to determine which services need to be created.

2. Approve SOA design.

6.2. ENTERPRISE SERVICE BUS

An enterprise service bus (ESB) must be implemented to support service-oriented interactions among the three eligibility systems that make up CHIMES. An ESB intelligently routes data flowing through enterprise systems, adapting and transforming that data as required by various systems. The ESB facilitates and coordinates the program-to-program communications necessary to support service-oriented interactions and combines messaging, transformation, and content-based routing into a single off-the-shelf product. The ESB will create a framework for loosely coupled integration and provide the ability to model, define, and manage processes that direct the sequenced integration of services (service orchestration).


1 The ESB must be either an off-the-shelf or an open source product.

2

The ESB must provide service orchestration that supports process automation by invoking services in a particular order and following a set of rules. The orchestration features of the ESB must make it easy to change process definitions and adapt to new business requirements.

3 The ESB must be able to support a variety of standard messaging protocols.4 The ESB must manage messages so messages are intelligently routed between services.5 The ESB must support message transformation functionality to enable communication among

Req # Requirement Descriptionsystems. The ESB must transform data into a common data format that is understood by both the sending and receiving systems.

6The ESB must support content-based routing functionality that determines the destination of a given message based on its content.

7The ESB must provide real time message tracking and distributed flow control debugging. It also must allow for the diagnosis and management of problems in complex distributed systems.

8The ESB must support publishing and subscribing functionality that employ an event-driven model in which an event occurring in one application can trigger an action in another.

9The ESB must provide the capability to link services across the organization with both queuing and publish and subscribe behavior.

10The ESB must be fault tolerant and provide high availability within a reliable infrastructure even if a component and its distributed infrastructure should fail.

11The ESB must allow the ability to change orchestration, rules, data mapping, and relationships between systems with minimal effort and disruption.

12The ESB must provide logging and auditing of services as well as the monitoring of faults, service and process status, and detailed performance statistics.

13The ESB must securely route messages and enforce authorized use of services, information, and data.

14The ESB must be scalable and have the ability to accommodate additional systems and services in the future.

15The ESB must be based on open standards and allow for the State to leverage existing IT investments.

6.2.2. Performance Standards 1. The ESB must meet industry standards for performance.

2. Irrespective of the network, the ESB must not contribute significantly to the overall response time of the system(s).

6.2.3. Contractor Responsibilities 1. Provide the specifications for the hardware required to run the ESB.

2. Install and configure the ESB within the State environment.

6.2.4. State Responsibilities 1. Provide equipment necessary for the ESB.

2. Participate in the installation configuration.

6.3. WEB PORTAL

CHIMES will require a centralized web portal that provides access to the three eligibility systems. The CHIMES portal will provide a consistent look and feel with access control and procedures for the eligibility systems. Various users with different roles accessing the different applications will have a single access point to all three systems. The CHIMES web portal is expected to provide intelligent integration and access to the systems and processes, and unified, real-time access to information held in disparate systems. The Department is open to an offeror bidding a third party product.

The following diagram illustrates a possible screen flow supported by the portal for system users accessing multiple systems. The Department understands that screens and navigation will be designed during the detailed requirements definition and the design phases.

Figure 6.3.A: Envisioned Web Portal Screen Flow


1 The architecture must contain a centralized web portal.

2The architecture must allow users to select which program(s) they will work for a particular case or individual. The architecture must allow users to utilize one system or multiple systems at the same time.

3The web portal must allow internal and external access using secure authentication through single sign on.

4 The web portal must display systems and content based upon the role of the user.

5The web portal must be scalable and have the ability to accommodate additional systems and content in the future.

6The web portal must be based on open standards and allow for the State to leverage existing IT investments.

7The web portal must provide collaboration capability particularly for the broadcasting and sharing of messages for a specific team of users.

8 The architecture must support varying access levels to data based on security roles.

6.3.2. Performance Standards 1. Whether developed or implemented as a third-party product, the web portal must adhere to the same

performance standards expected by program and system-specific code that will be developed for these systems.

6.3.3. Contractor Responsibilities

1. Work with the Department to define the design of the web portal.

2. If a COTS product is bid, provide the specifications for the hardware required to run the web portal.

3. If a COTS product is bid, install and configure the web portal within the State environment.

4. Make written recommendations in any area in which the contractor or Department thinks improvement can be made regarding the design and operation of the web portal.

6.3.4. State Responsibilities 1. Work with the contractor to define the design of the web portal.

2. If a COTS product is bid, provide equipment necessary for the web portal.

3. If a COTS product is bid, participate in the installation configuration.

6.4. SINGLE SIGN-ON

User authentication, which takes place in the web portal, must utilize single sign-on (SSO). SSO automates the process of managing multiple authorizations by capturing user provided credentials upon initial entry. Therefore, a user need logon only once to systems running under SSO. As CHIMES eligibility systems are accessed, the SSO technology will automatically pass the proper credentials to the applications being requested by the user.


1The architecture must utilize SSO. The architecture must only require users to sign on once when using the three eligibility systems.

2The SSO must automatically pass a user’s credentials on to the program’s eligibility system being requested by the user.

3 The SSO must record, encrypt, and store credentials when a user logs on the system(s).4 The SSO must be compatible with Microsoft Active Directory, the State’s LDAP.5 The SSO must be scalable.

6The SSO must match an individual’s security role with his or her ability to view, enter, modify, and delete information in the systems.

6.4.2. Performance Standards 1. The SSO must meet industry standards for performance.

2. Irrespective of the network, the SSO must not contribute significantly to the overall response time of the system(s).

6.4.3. Contractor Responsibilities 1. Work with the Department to define the design of the SSO.

2. If a COTS product is bid, provide the specifications for the hardware required to run the SSO.

3. If a COTS product is bid, install and configure the SSO within the State environment.

4. Make written recommendations on any area in which the contractor or Department thinks improvement can be made in the design and operation of the SSO.

6.4.4. Department Responsibilities 1. Work with the contractor to define the design of the SSO.

2. If a COTS product is bid, provide equipment necessary for the SSO.

3. If a COTS product is bid, participate in the installation configuration.

6.5. SHARED INFORMATION AND WEB SERVICES

TANF, SNAP, and Medicaid eligibility determination processes share a large number of commonalities. This subsection discusses the flow of information in common to all three systems. It is this information that will be managed by the services contained within the enterprise architecture. The Department identified these shared business processes or information flows in the following diagram.

Figure 6.5.A: Shared Eligibility Business Processes

To facilitate the sharing of information within the common process flow depicted in Figure 6.5.A, a number of services will be created. Appendix 13.6 includes a table listing these services and delineating which programs share these services in common. This table includes demographic information shared between the programs. To enhance the sharing of this demographic information and make it extensible to future systems, the enterprise architecture system must contain a virtual index of persons and where they reside in various Department systems. The common client index will be realized as a “service” within a service-oriented architecture, not a separate repository of person demographic information. Each system will maintain its own set of person data and business processes. Data will be exchanged based on access level of the requestor and system functionality. The Department encourages vendors to develop as many services as possible.

Within the tiered application architecture of CHIMES, web services will be used to provide access to data and functionality that must be shared between all three eligibility systems. Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the web. Once a web service is deployed, other applications (and other web services) can discover and invoke the deployed service. CHIMES will rely on web services for the information exchange required between the three eligibility systems.

The following diagram illustrates how the systems may share information. The service flow on the left side represents business processes, which may or may not be common between the eligibility systems. Again, the Department understands that these flows will be designed with the contractor during the detailed requirements definition and design phases.

Figure 6.5.B: Envisioned Information Flow via Web Services


1The architecture must require that services be created for information sharing between the three systems.

2The architecture must strive to prevent duplicate entry by system users. For example, information entered on a TANF income screen would not need to be reentered for SNAP or Medicaid income screens.

3One or more services may be created for a particular business process. Refer to the shared services matrix for a list of the information that must be shared between the three eligibility systems.

4 A program’s data requirements will determine which data will be shared between systems.

5System users must be alerted when information that does not auto-populate is updated in one program’s system.

6 Data that is not program-specific will be shared by all three eligibility systems. This data will be stored and maintained in a data structure that is shared by all three systems. Therefore, the data for case notes, alerts, and correspondence will be centrally stored and maintained

Req # Requirement Descriptionand not require data sharing services. Access to this data will be governed by security roles.

7 The architecture must support a common client index that is facilitated by services.

8Each eligibility system must store and maintain its own set of case data and business processes.

9

All information stored in the TANF and SNAP databases (e.g., addresses) shall include standardized location-based data elements that can be populated and used by a geocoding solution. The Department wishes to create geocode-ready databases that leverage GIS tools as part of its enterprise architecture initiative.

6.5.2. Performance Standards 1. Services developed must adhere to the same performance standards expected by program and system-

specific code that will be developed for these systems.

6.5.3. Contractor Responsibilities 1. The services developed must be done using standard system development life cycle methodologies.2. Make written recommendations on any area in which the contractor or Department thinks improvement can

be made to the services design and operation.

6.5.4. Department Responsibilities 1. Work with contractor to determine which services need to be created.

2. Approve the design of the services.

6.6. INTERSYSTEM NAVIGATION

The common process flow, described in the previous section, allows OPA workers to consider each case as a single case, regardless of how many programs a household utilizes. Offices of Public Assistance business processes mirror the common processes outlined in Figure 6.5.A. The following diagram demonstrates the process flow for a new applicant at an OPA office.

Figure 6.6.A: OPA Process Flow for New Applicant

The architecture’s navigation flow must coordinate with this process flow, and consider individuals at the case level. The architecture must not force users accessing multiple systems to view cases on a program-by-program basis. Instead, each business process should be completed for all requested programs before a user is navigated to the next process. The following diagram, also used above, illustrates how a user will be navigated between screens within the three systems. The navigation flow on the right side of the diagram depicts how a user will be guided through the various data collection functions for each shared process. The

Department understands that the intersystem navigation flow will be designed with the contractor during the detailed requirements definition and design phases.

Figure 6.6.B: Envisioned Intersystem Navigation Flow


1

The system must have the ability to automatically navigate system users through a minimum number of screens. The system must not automatically navigate to screens if all the required information is populated in the screen through shared services. The system will navigate to a screen only when the screen requires new information to be entered. System users must be able to opt out of the automatic navigation flow.

2The architecture must require users accessing multiple systems to fill in information in a Department-defined hierarchy of programs. This hierarchy will differ depending on the data being collected for each business process (e.g., collecting income information).

3The architecture must allow for the hierarchy of programs to be configurable. It must not be hard-coded in the system.

4When a system user is simultaneously accessing multiple programs to determine eligibility the architecture must require system users to populate missing information from other programs after each module is complete.

5The architecture must alert users when a change has been made in one program that impacts the determination of benefits and/or eligibility in another program.

6.6.2. Performance Standards 1. The navigation functionality must adhere to the same performance standards expected by program and

system-specific code that will be developed for these systems.

6.6.3. Contractor Responsibilities 1. Work with the Department to define the design of the navigation functionality.

2. Make written recommendations in any area in which the contractor or Department thinks improvement can be made regarding the design and operation of the navigation functionality.

6.6.4. Department Responsibilities 1. Work with the contractor to define the design of the navigation functionality.

6.7. ENHANCING CHIMES-MEDICAID

CHIMES-TANF and CHIMES-SNAP cannot be implemented until CHIMES-Medicaid is enhanced or modified to utilize the enterprise architecture. CHIMES-Medicaid will be implemented in September 2009. Between CHIMES-Medicaid and CHIMES-TANF and CHIMES-SNAP implementation, system users will be required to enter information into both the CHIMES-Medicaid and TEAMS systems. This double entry requirement must stop once CHIMES-TANF and CHIMES-SNAP are implemented. All three CHIMES systems must communicate via the enterprise architecture.

In order for the enterprise architecture to achieve full interoperability through shared architecture for the CHIMES systems, CHIMES-Medicaid must be modified to provide communications and interoperability between its exposed services and the enterprise architecture. The scope of the requirements in this subsection, therefore, is limited to the necessary modifications that will support this enterprise interoperability for CHIMES. Appendix 13.6 lists information sharing requirements for Medicaid, TANF, and SNAP. This in conjunction with the CHIMES-Medicaid information in the procurement file, which includes source code and detail design documents, will allow offerors to estimate the scope of CHIMES-Medicaid modification requirements.

The new contractor will be responsible for building all enterprise architecture components. The CHIMES-Medicaid contractor will review the resulting detail design documents as an external stakeholder. The new contractor will be expected to collaborate with the CHIMES-Medicaid contractor to identify what enhancements CHIMES-Medicaid requires. The CHIMES-Medicaid contractor will be responsible for modifying and exposing CHIMES-Medicaid functionality that allows the system to participate in the enterprise architecture and become interoperable with CHIMES-SNAP and CHIMES-TANF. The SNAP/TANF contractor will be the lead contractor on the CHIMES-Medicaid enhancement project.

The Department welcomes offerors’ suggestions of alternative ways to approach CHIMES-Medicaid enhancement. Given our investment in CHIMES-Medicaid and that it will have been in use for at least two years prior to the implementation of CHIMES-SNAP and CHIMES-TANF, the Department wants the three systems to have the same look and feel as CHIMES-Medicaid, and to have the three work seamlessly together. The Department will make the full design and code of CHIMES-Medicaid available to the contractor to use at the contractor sees fit to integrate the three systems.


1CHIMES-Medicaid must utilize service-oriented architecture, conforming to requirements in subsection 6.1.

2 CHIMES-Medicaid must utilize the enterprise service bus described in subsection 6.2.

3The web portal described in subsection 6.3 must access CHIMES-Medicaid in addition to CHIMES-TANF and CHIMES-SNAP.

4Authorized system users must be able to access CHIMES-Medicaid, CHIMES-SNAP, and CHIMES-TANF when utilizing their single sign-ons, described in subsection 6.4.

5CHIMES-Medicaid must utilize shared information and web services, conforming to requirements in subsection 6.5.

6Intersystem navigation requirements in subsection 6.6 must incorporate CHIMES-Medicaid into navigation flows.

6.7.2. Contractor Responsibilities 1. Work as the lead vendor in a collaborative process with the CHIMES-Medicaid vendor to enhance or

modify CHIMES-Medicaid so it can utilize the enterprise architecture.

2. Involve the CHIMES-Medicaid vendor as a stakeholder in the project and collaborate in creating the detail design specifications for the CHIMES-Medicaid enhancements or modifications.

6.7.3. Department Responsibilities 1. Work with the contractors to define the services that must be exposed to communicate with the enterprise

architecture.

SECTION 7. DETAILED COMMON REQUIREMENTS

SECTION 8. SNAP DETAILED REQUIREMENTS

SECTION 9. TANF DETAILED REQUIREMENTS

SECTION 10. SHARED FISCAL SERVICES REQUIREMENTS

SECTION 11. PROPOSAL REQUIREMENTS

SECTION 12. EVALUATION METHODOLOGY

SECTION 13. APPENDICES

snap and tanf eligibility systems, enterprise architecture

Documents

rfp number

proposal rfp rfp title

rfp standard information

rfp introduction

offeror fax number

number of pages

proposal conference

ink offeror phone number