avenues projects ow

Attachment D

Avenues Project

Statement of Work08/25/2011

Version 5.0

Contents

1.0 Introduction / Purpose.......................................................................................................10

1.1 Avenues Site Review..................................................................................................................10

2.0 Functional Scope.....................................................................................................................12

2.1 Concept of Operations...............................................................................................................13

3.0 Project Phases and Timeline....................................................................................................14

3.1 Project Phases............................................................................................................................15

3.1.1 Phase #2: SRS – Avenues Implementation........................................................................15

3.1.1.1 Project Management.....................................................................................................15

3.1.1.2 Business.........................................................................................................................15

3.1.1.3 Technical Architecture and Infrastructure.....................................................................16

3.1.1.4 Content Management....................................................................................................16

3.1.1.5 Document Conversion....................................................................................................16

3.1.1.6 Eligibility and Benefits Administration System...............................................................17

3.1.1.7 Business Intelligence Services and Reporting.................................................................17

3.1.2 Phase #3: LIEAP.................................................................................................................17

3.1.3 Ongoing Operations...........................................................................................................17

3.1.4 Phase #4: Virtual Contact Center......................................................................................17

4.0 Project Staffing.......................................................................................................................19

4.1 Accenture..................................................................................................................................20

4.2 State...........................................................................................................................................23

4.3 Organization Chart.....................................................................................................................25

4.4 Key Personnel............................................................................................................................26

4.5 Skill Sets for the SRS project......................................................................................................29

5.0 Deliverable Schedule...............................................................................................................32

6.0 Project Management and Project Administrative Services.......................................................36

6.1 KITO Requirements....................................................................................................................36

6.2 Internal Reporting Requirements..............................................................................................37

6.3 Project Time Reporting and Cost Allocation..............................................................................38

6.4 Project Execution Tools..............................................................................................................38

Version 5.0

6.5 Documentation of Meetings and Decisions...............................................................................39

6.6 Risk and Issues Management.....................................................................................................39

6.7 Deliverables...............................................................................................................................39

6.8 Governance, Change Control Process and Acceptance of Deliverables.....................................40

6.8.1 Governance........................................................................................................................40

6.8.2 Change Control Process.....................................................................................................41

7.0 Requirements Validation, Business Process Design, Software Configuration, Testing, and Enhancements & Modifications..........................................................................................................47

7.1 Responsibility Matrix.................................................................................................................49

7.2 Deliverables and Work Products................................................................................................49

8.0 Workflow Analysis and Development......................................................................................51

8.1 Scope Definition.........................................................................................................................51

8.2 Major Activities by Phase...........................................................................................................56

8.2.1 Analyze Phase....................................................................................................................56

8.2.1.1 Analyze Process Flows....................................................................................................56

8.2.2 Design Phase......................................................................................................................57

8.2.2.1 General Design Documents............................................................................................57

8.2.3 Build Phase........................................................................................................................58

8.2.3.1 Detailed Design Documents...........................................................................................58

8.2.3.2 Build and Component Test.............................................................................................58

8.2.4 Test Phase..........................................................................................................................58

8.2.5 Deploy Phase.....................................................................................................................58



9.0 Interfaces................................................................................................................................62


9.1.1 Interfaces In Scope.............................................................................................................63

9.1.2 Interfaces Not In Scope......................................................................................................65


9.2.1 Analyze Phase....................................................................................................................66

9.2.2 Design Phase......................................................................................................................67

9.2.3 Build Phase........................................................................................................................68

Version 5.0

9.2.4 Test Phase..........................................................................................................................69

9.2.5 Deploy Phase.....................................................................................................................69

9.3 Responsibilities..........................................................................................................................69

9.4 Other Interface Considerations..................................................................................................70

9.5 Deliverables...............................................................................................................................70

10.0 Data Conversion.....................................................................................................................71



10.2.1 Analyze Phase....................................................................................................................71

10.2.1.1 Conversion Analysis.......................................................................................................71

10.2.2 Design Phase......................................................................................................................73

10.2.3 Build Phase........................................................................................................................74

10.2.3.1 Build and Component Test:............................................................................................74

10.2.4 Test Phase..........................................................................................................................74

10.2.5 Deploy Phase.....................................................................................................................74

10.2.5.1 Mock Conversions:.........................................................................................................74

10.2.5.2 Cutover:.........................................................................................................................75


10.4 Deliverables...............................................................................................................................77

11.0 Business Intelligence Services and Reporting...........................................................................78


11.2 Major Activities by System Development Methodology Phase.................................................79

11.2.1 Analyze Phase....................................................................................................................79

11.2.1.1 Analyze Reports.............................................................................................................79

11.2.2 Design Phase......................................................................................................................80

11.2.2.1 General Design Documents:...........................................................................................80

11.2.2.2 Detailed Design Documents...........................................................................................80

11.2.3 Build Phase........................................................................................................................80


11.2.4 Test Phase..........................................................................................................................81

11.2.5 Deploy Phase.....................................................................................................................81


Version 5.0

11.4 Other Requirements..................................................................................................................82

11.4.1 Scope of the Business Intelligence Services.......................................................................82


12.0 Automated Forms and Notices................................................................................................83



12.2.1 Analyze Phase....................................................................................................................92

12.2.1.1 Analyze Forms and Notices............................................................................................92

12.2.2 Design Phase......................................................................................................................92

12.2.3 Build Phase........................................................................................................................93


12.2.4 Test Phase..........................................................................................................................94

12.2.5 Section 7 of the K-MED SOW Deploy Phase.......................................................................94



13.0 Imaging and Content Management.........................................................................................96


13.2 Deliverables and Work Products...............................................................................................96

14.0 Enterprise Readiness...............................................................................................................97


14.1.1 Analyze Phase....................................................................................................................97

14.1.1.1 Develop the Stakeholder Assessment and Stakeholder Management Plan...................97

14.1.1.2 Create Enterprise Readiness Plan..................................................................................98

14.1.1.3 Create Communication Plan..........................................................................................98

14.1.2 Design Phase......................................................................................................................99

14.1.2.1 Support Road Shows......................................................................................................99

14.1.2.2 Launch Change Agent Network and Regional Implementation Leads............................99

14.1.2.3 Document System, Process and Role Gaps..................................................................100

14.1.2.4 Design Change Discussion Guides/Readiness (Business Process) Workshops..............100

14.1.2.5 Provide Communications /Update Communication Plan.............................................101

14.1.3 Build Phase......................................................................................................................105

Version 5.0

14.1.3.1 Build Change Discussion Guides/ Readiness (Business Process) Workshops...............105

14.1.3.2 Create Role Descriptions..............................................................................................106

14.1.3.3 Provide Communications / Update Communication Plan............................................106

14.1.3.4 Assess and Report Readiness.......................................................................................106

14.1.4 Test Phase........................................................................................................................109

14.1.5 Deploy Phase...................................................................................................................109

14.1.5.1 Assess and Report Readiness.......................................................................................109

14.1.5.2 Provide Communications / Update Communication Plan............................................109

14.2 Responsibility Matrix...............................................................................................................110

14.3 Other Requirements................................................................................................................110

14.4 Deliverables.............................................................................................................................110

15.0 Training Services...................................................................................................................112

15.1 Major Activities by Phase.........................................................................................................112

15.1.1 Analyze Phase..................................................................................................................112

15.1.1.1 Analyze End User Training and Support Needs............................................................112

15.1.1.2 Training Curriculum......................................................................................................113

15.1.2 Design Phase....................................................................................................................115

15.1.2.1 Training Tools Training.................................................................................................115

15.1.2.2 Training Design............................................................................................................115

15.1.3 Build Phase......................................................................................................................116

15.1.3.1 Build.............................................................................................................................116

15.1.3.2 Test..............................................................................................................................118

15.1.4 Deploy Phase...................................................................................................................118

15.1.4.1 Pilot Training................................................................................................................118

15.1.4.2 Train-the-Trainer..........................................................................................................119

15.1.4.3 Training Facilities.........................................................................................................120

15.1.4.4 Training Delivery..........................................................................................................120

15.1.4.5 Training Administration...............................................................................................121

15.1.4.6 Training Transition.......................................................................................................122



15.4 Deliverables.............................................................................................................................123

Version 5.0

16.0 Knowledge Transfer Services.................................................................................................124

16.1 Scope Definition.......................................................................................................................124


16.2.1 Analyze Phase..................................................................................................................124

16.2.1.1 Identify Roles...............................................................................................................124

16.2.1.2 Knowledge Transfer Plan.............................................................................................125

16.2.2 Design Phase....................................................................................................................126

16.2.2.1 Personal Learning Plans...............................................................................................126

16.2.2.2 Assess Knowledge Transfer Progress...........................................................................127

16.2.2.3 Design Small Group Walkthrough sessions..................................................................127

16.2.3 Build Phase......................................................................................................................128

16.2.4 Test Phase........................................................................................................................128

16.2.5 Deploy Phase...................................................................................................................129

16.2.6 Post Systems Support Phase............................................................................................130

16.2.6.1 Assess Knowledge Transfer Progress – Post Systems Support.....................................130



16.5 Deliverables.............................................................................................................................131

17.0 Technical Infrastructure Build and Operations.......................................................................132

17.1 Major Activities........................................................................................................................132


17.3 Deliverables.............................................................................................................................135

18.0 SRS Quality Assurance...........................................................................................................137



18.3 Deliverables and Work Products..............................................................................................138

19.0 508 Compliance....................................................................................................................140

20.0 Help Desk..............................................................................................................................141

21.0 Continuity of Operations and Disaster Recovery....................................................................142

21.1 Scope Definition.......................................................................................................................142


Version 5.0


22.0 Ongoing Operations..............................................................................................................145


22.1.1 Knowledge Transfer.........................................................................................................145

22.1.2 Enhancements.................................................................................................................146


22.3 Deliverables.............................................................................................................................147

23.0 Print Mail..............................................................................................................................148


23.2 Deliverables.............................................................................................................................149

24.0 Post-Implementation Support...............................................................................................150


25.0 Archiving (KEEP)....................................................................................................................152

25.1 Analyze Phase..........................................................................................................................152

25.1.1 Analyze KEEP Requirements............................................................................................152


25.3 Other Considerations...............................................................................................................154


26.0 Virtual Contact Center...........................................................................................................155


26.1.1 Analysis............................................................................................................................159

26.1.1.1 Virtual Contact Center Analysis....................................................................................159

26.1.2 Design Phase....................................................................................................................161

26.1.3 Build Phase......................................................................................................................162

26.1.3.1 Detailed Design Documents.........................................................................................162

26.1.3.2 Build and Component Test...........................................................................................162

26.1.4 Test Phase........................................................................................................................163

26.1.4.1 VCC IVR Testing............................................................................................................163

26.1.4.2 Telephony / ACD Testing..............................................................................................164

26.1.5 Deploy Phase...................................................................................................................165

26.1.5.1 IVR deployment:..........................................................................................................165

Version 5.0

26.1.5.2 Telephony /ACD deployment.......................................................................................166


26.3 Deliverables.............................................................................................................................167

27.0 Business Process Reengineering (BPR) and Business Process Improvement (BPI) – Change Management....................................................................................................................................168

27.1 Business Process Reengineering and Business Process Improvement.....................................168

27.1.1 Perform Business Process Reengineering (BPR)/Business Process Improvement (BPI). . .168

27.1.1 Business Activities and Tasks...........................................................................................169

27.2 Deliverables/Work Products....................................................................................................172

Version 5.0

1.0 Introduction / Purpose

The purpose of this SRS Statement of Work (SOW) is to document and formalize the decisions made and agreements reached during K-MED/Avenues contract negotiations. The SOW supplements the contract by providing required clarity to specific areas of the Contractor’s proposal. It particularly documents any item that is different from the State’s RFP, State’s RRO or the Contractor’s proposals. The SOW does not substitute for, nor necessarily nullify, any commitments or approaches described in the Contractor’s proposal or other Contractor commitments made during the procurement process. If the SOW is silent on a given item or approach, then these other documents and Contractor commitments are in full force.

The SOW defines the Project phases and releases. The SOW defines requirements for project controls and project administration, including the change control process. It lists all deliverables and provides a brief description of each deliverable. The SOW identifies which party is responsible for specific Project activities. The SOW includes proposed Contractor and State staffing.

The SRS SOW is an incremental work effort to the K-MED SOW and should be viewed as the work necessary to be done that is in addition to the K-MED SOW. Any consideration of the SRS SOW must include the K-MED SOW for a complete picture of the project. In many instances the SRS SOW will refer to the K-MED SOW.

1.1 Avenues Site Review

The Contractor will provide a Demonstration and Training session of the K-MED/Avenues Vendor’s proposed system at the central development site located in San Antonio, Texas. The expectations of the session are:

See a demonstration of the proposed solution and all technical aspects that support it.

See a presentation and walk thru of the development center processes, procedures, standards, and guidelines for product maintenance and enhancement.

Receive training in the solution architecture and practices.

The scheduled time and agenda will be determined and agreed upon by both the State and Contractor during detailed project planning.

The Contractor shall be responsible for all the travel and lodging expenses, for up to 10 State agency staff to attend the session. The State will be represented by a team consisting of developer, software administration, analyst, and business staff. All travel and expense arrangements shall fully comply with the terms of K.S.A. 46-237 and travel arrangements are compliant with the State of Kansas Travel Policies, found at: http://da.state.ks.us/ar/employee/travel/.

The State team will arrive in San Antonio on the day before the session is to begin and depart from the location at the conclusion of the session. It is expected that the session will not exceed two days.

Version 5.0

The Contractor will provide the airfare and lodging arrangements for the State staff specified. The billing for these accommodations will go directly to the Contractor from the travel companies. Coverage of ground transportation will be arranged in the planning of the trip. It is expected that the State will cover the meal expenses for the staff attending.

Version 5.0

2.0 Functional Scope

The Avenues project will implement the next generation of integrated eligibility and benefits administration information management systems that will include an Integrated Service Delivery model to better serve Kansans. Integrated service delivery that is focused on the client will require improvements to the current SRS business processes and the underlying information technology that supports them.

The scope of the Avenues project is extensive and is summarized as follows.

Replacement of the following legacy systems:

– KAECSES-AE

– Kan-Pay

– KsCares

– EATSS

– TOP

– LIEAP systems

As part of the project, all functionality and data from these systems will be incorporated into the new system, per the functional and conversion design, and these will be decommissioned.

The following programs are in scope for Avenues:

– Temporary Assistance for Needy Families (TANF)

– SNAP (Food Assistance)

– Refugee Assistance

– General Assistance

– Funeral Assistance

– Work Programs (Includes both TANF and Food Assistance Employment & Training)

– Child Care Subsidy (Includes customer eligibility, benefits, and provider enrollment)

– Low Income Energy Assistance (LIEAP)

Version 5.0

The following Children and Family Services programs are for payment or emergency payments only.

– Adoption Support Subsidy

– Permanent Custodianship

– Independent Living (Chaffee)

– Generic Family Services

Implementation of the new Eligibility and Benefits Administration System (Avenues). This will include all aspects of implementing a new system, such as conversion, interfaces, new business processes, and users trained in the use of the system. SRS will have the ability to consolidate service delivery, perform integrated case management, and eliminate redundant and inefficient processes.

Establishment of the appropriate communication and change management methods and structure.

Establishment of the core technical infrastructure to support the solution.

Business Process Reengineering/Improvements. Staff business processes will be reengineered for more efficiency in meeting customer needs and use of the new solution.

Implementation of a Virtual Contact Center. This will implement a new unit and the necessary system functionality to provide statewide customer support using phone and internet service channels, regardless of the staff location.

Establishment of a Content Management solution that is integrated with the eligibility system. This will include the hardware, software, infrastructure, processes, rollout, and support for the establishment of a Records Management Center, in accordance with the SOW and Avenues requirements.

Implementation of a new organizational structure for programs supported by Avenues. Any new organizational structures will be implemented and staff assigned to new duties.

2.1 Concept of Operations

The SRS future vision model shares many concepts of the K-MED vision. The K-MED vision provides the base for SRS with incremental aspects pertaining to the SRS program service delivery. The SRS Concept of Operations document (see Appendix) provides a description of the SRS current environment and the future vision of operations.

Version 5.0

3.0 Project Phases and Timeline

Project Phase Deliverable/Scope Deployment DatePhase 1 Phase 1 involves K-MED scope only.

SRS work begins with Phase 2.NA

Phase 2 Project Management, Business Process Reengineering/Improvement, Technical Architecture and Infrastructure, Content Management (including Document Conversion), Eligibility and Benefits Administration System, and Business Intelligence Services

Month 21

Phase 3 LIEAP Month 28

Phase 4 Virtual Contact Center Month 31

The following chart represents the Avenues Timeline. The integrated Project Plan will contain the aligned workplan with K-MED, which will coordinate the implementation of phases.

Figure 1 - SRS Timeline

Version 5.0

3.1 Project Phases

3.1.1 Phase #2: SRS – Avenues Implementation

Listed below are the high-level work efforts that are In Scope for Phase 2. This phase includes the following: Project Management, Business Process Reengineering/Improvement, Technical Architecture and Infrastructure, Content Management (including Document Conversion), Eligibility and Benefits Administration System, and Business Intelligence Services. It should be noted that Phase 1, which is not scope within the SRS – Avenues Implementation, is K-MED scope associated with the Self Screening Portal and Presumptive Eligibility.

3.1.1.1 Project Management

Project Management will include planning, controlling, and reporting the work; identifying, tracking, and resolving problems and issues; and leading the project in cooperation with the State’s Project Director and staff. Other activities would include conducting project initiation, arranging and conducting status meetings, managing the quality reviews, and developing and implementing the issue and risk management programs. Accenture will work to maintain a cooperative working relationship with State staff and the State’s Independent Validation and Verification Vendor (IV&V) on an ongoing daily basis to design, develop, implement, maintain, and operate a system that meets the required specifications.

Our approach to performing the activities surrounding Project Management involves leveraging the PMO established by the K-MED project and adding additional focus on quality. Our Project Manager is supported by a PMO Lead focused on working with your PMO and IV&V to track quality metrics and overall team performance.

3.1.1.2 Business

Business activities and tasks are necessary to plan and prepare for SRS deployment of change management staff. We are using the broad term “Change Management” to include the activities of Business Process Reengineering, Business Process Improvement, as well as the plans, communications and activities necessary to get your staff ready for the new processes that accompany the integrated K-MED and Avenues System.

Perform Business Process Reengineering (BPR)/Business Process Improvement (BPI)

Using a six-step method to conducting business process improvements for the Avenues project, Accenture will provide the appropriate staff with Business Process Improvement expertise (during the initial window in the project) to research, evaluate, and identify new business processes.

Accenture will provide a staff person familiar with the proposed eligibility system to work with this team in:

helping to identify a plan of implementation of the new business processes.

Version 5.0

working with SRS to establish and maintain a model business process office.

aiding the state in the rollout of these new processes, training, education, and any other aspects of successfully transitioning the organization to the new business processes.

3.1.1.3 Technical Architecture and Infrastructure

The Technical Architecture and Infrastructure activities are intended to extend the K-MED architecture and scale it appropriately for the increased caseloads of Avenues. They will include the activities and tasks to deploy the infrastructure, equipment, and software for the integrated K-MED/ Avenues system. These tasks would follow a methodology that includes the processes necessary to analyze the equipment and software requirements, development of the software and equipment, development and implementation of the security, management of the procurement process for hardware and software, as well as the technical architecture support to design, build, test and deploy K-MED/Avenues.

Our approach to performing the activities surrounding the Technical Architecture and Infrastructure activities involves leveraging the technical teams and resources that already exist for the K-MED project. The Tech Arch resources assigned to Avenues will be focused on adapting the architecture and infrastructure to SRS needs rather than starting from scratch.

3.1.1.4 Content Management

Accenture’s Content Management solution will be to build on capabilities in the existing APSP to provide a more robust solution supporting cohesive integration with the APSP Portal application and enhanced workflow capabilities. The solution will allow the State to scan documents and process images electronically. It will give SRS users the ability to store and retrieve case related documents electronically, and view the stored images online from within the Avenues System.

Accenture’s approach to performing the activities surrounding Content Management involves leveraging the deep expertise of our teaming partner, Perceptive. Based in Kansas and experienced with public sector ECM implementations, Perceptive is well equipped to rapidly develop and deploy the standalone imaging solution. We will work with our Perceptive partners to integrate the interim solution into the Eligibility and Web Portal systems. At that point, all appropriate Avenues users will be able to benefit from ongoing ECM capabilities.

3.1.1.5 Document Conversion

Historically scanned and imaged documents (i.e., content) will be converted from the legacy system to the SRS – Avenues solution by an external contractor and is not part of the Accenture scope. Accenture will, however, provide the correct file format to the external vendor so the historical documents can easily be consumed/converted by the Image now, and put the “Client” on a server, a desktop, or both based on what works best for the document conversion work effort.

Version 5.0

3.1.1.6 Eligibility and Benefits Administration System

Eligibility and Benefits Administration includes the incremental modifications to the K-MED solution to meet the Avenues functional, technical, conversion and interface requirements.

Our approach to performing the activities surrounding Eligibility System and Web Portal involves leveraging the large development team that exists for the K-MED project while enhancing it with additional functional and technical resources. Accenture will add developers focused on development of the Eligibility System, Interfaces, Data Conversion as well as System Testing and Training so that the Avenues project is well represented in the combined team.

3.1.1.7 Business Intelligence Services and Reporting

Business Intelligence Services and Reporting involves the activities and tasks necessary to implement the K-MED Business Intelligence Services architecture for the Avenues Project for use by SRS decision makers. As we perform the Design for Avenues, we will confirm that adequate storage for the incremental case load increase for SRS cases has been defined in the plan. The modifications to the K-MED Business Intelligence Services design will primarily be driven by the programmatic changes for the SRS-specific programs.

Our approach to performing the activities surrounding Business Intelligence Services and Reporting involves leveraging the reporting capabilities of the K-MED team with additional resources from Accenture Analytics and our San Antonio Development Center. In this way, we will make use of existing skills and capabilities while bringing additional Business Intelligence Services and Reporting experience.

3.1.2 Phase #3: LIEAP

Phase 3 will include the implementation of the Low Income Energy Assistance Program (LIEAP). This implementation will help eligible households pay for a portion of their home energy costs by providing an annual benefit. The solution will consist of registering clients, determining a clients eligibility and benefit amount, processing a payment, as well as maintaining and updating information about vendors.

3.1.3 Ongoing Operations

Accenture will provide resources dedicated to Knowledge Transfer, Enhancements, and Help Desk for a period of 12 months after the Implementation of the SRS – Avenues application. At the conclusion of the Ongoing Operations phase SRS staff will have the knowledge and “hands on” expertise to manage and support future enhancement work without the guidance of Accenture resources.

3.1.4 Phase #4: Virtual Contact Center

The Virtual Contact Center (VCC) work effort will establish the tools, technologies, organizational structure, role definitions, and physical structure necessary to allow the SRS to improve customer service through a consolidated statewide Virtual Contact Center. Customers contacting the agency will

Version 5.0

be routed through this Virtual Contact Center in order to improve response times, customer satisfaction and improve workforce efficiency.

Version 5.0

4.0 Project Staffing

The Project Staffing SOW is intended to identify the Contractor and State resources needed to implement the SRS Avenues Solution. Accenture and SRS staff will work together to complete General and Detailed Design documentation, Build and Unit Test (i.e., pages, database updates, interface, reports, forms, batch, etc.), System Test, and Deployment of the required work products, Deliverables, and Application Components to successfully implement the benefits system. By the very nature of integrating SRS staff with Accenture resources SRS will learn how to maintain and enhance the system. Accenture will also be leveraging the Accenture resources assigned to the K-MED project in an effort to maximize the team productivity between the two projects.

Version 5.0

4.1 Accenture

Table 1 - Accenture Staffing TableTeam Role Resource Name Location Roll

On Mont

h

Roll Off Month

Total Months

Project Management Avenues Account Lead* Debora Morris Topeka M1 M21 4

Project Management Avenues Project Manager Keith Salas Topeka M1 M21 21

Project Management PMO Manager TBD Topeka M1 M21 21

Change Management Change Management Project Manager* Robin Murphy Topeka M4 M21 18

Change Management Business Process Reengineering Lead TBD Topeka M4 M16 13

Change Management Business Analyst Lead TBD Topeka M5 M5 1

Change Management Business Analyst TBD Topeka M4 M16 13

Change Management Training Developer TBD Topeka M6 M20 15



Technical Architecture Technical Architecture and Install Infrastructure Manager*

Mel Pieper Topeka M1 M21 21

Technical Architecture System Architect TBD Topeka M3 M17 15

Technical Architecture Database Administrator TBD Topeka M3 M21 19

Tech. Arch. - Content Management Content Management Manager* Kristen Parker Topeka M1 M20 10

Tech. Arch. - Content Management Imaging/Content Management Developer TBD Topeka M1 M20 5



Eligibility System Eligibility and Benefits Administration System Manager*

Jerry Nielson Topeka M1 M21 21

Eligibility System Business Functional Manager/Testing TBD Topeka M1 M18 15

Eligibility System Application Developers TBD Topeka M2 M21 20

Eligibility System Application Developers TBD SADC M6 M21 16

Eligibility System - Conversion Application Developer – Conversion TBD Topeka M4 M21 18

Eligibility System - Conversion Application Developer – Conversion TBD SADC M5 M21 17

Version 5.0

Team Role Resource Name Location Roll On

Month

Roll Off Month

Total Months

Eligibility System - Interfaces Application Developer – Interfaces TBD SADC M6 M18 13

Eligibility System - Interfaces Application Developer – Interfaces TBD Topeka M6 M11 6

Eligibility System - Interfaces Application Developer – Interfaces TBD Topeka M7 M20 14

Eligibility System Application Developer – Forms TBD Topeka M5 M21 20

Eligibility System Application Developer – Forms TBD Topeka M6 M20 22

Virtual Contact Center Virtual Contact Center Project Manager* David Corey Topeka M24 M31 8

Virtual Contact Center IVR/CRM Developer TBD Topeka M26 M31 6



Business Intelligence Services and Reporting

Business Intelligence Services and Reporting Project Manager*

Anthony Perez Topeka M13 M21 9


Reports Lead TBD SADC M13 M21 9


Application Developer – Reports TBD Topeka M4 M12 9















Version 5.0

Team Role Resource Name Location Roll On

Month

Roll Off Month

Total Months





NOTE: Accenture will leverage the K-MED Project Management team for SRS beyond month 21 . This team will support Project Management functions during LIEAP and Virtual Contact Center activities.

Version 5.0

4.2 State

The table below defines the SRS Staff required to support the SRS Project teams. It highlights the Team, Role, and Roll On and Roll Off Months for each resource. For a description of Roles please refer to section 4.5 Skill Sets for both SRS and K-MED projects, below. Resources marked with an asterisk are intended to highlight those resources that would be part of the 12 month Ongoing Operations team. These resources would support the management, build and test, training, and implementation of the ongoing support and approved enhancement requests during the 12 month Ongoing Operations phase of the project.

Table 2 - SRS Staffing TableTeam Role Roll On

MonthRoll Off Month

Total Months

Project Management Project Manager M1 M21 21

Project Management PMO Manager M1 M39 39

Project Management Project Manager M1 M39 39

Technical Architecture System Architect M1 M21 21

Eligibility System Business Functional Manager M1 M39 39

Eligibility System Business Functional Manager M1 M39 39

Eligibility System Business Analyst/SME M1 M39 39





Eligibility System Application Developer M2 M39 38






Eligibility System - Conversion Application Developer - Conversion M6 M21 16

Eligibility System - Content Management Imaging/Content Management Developer M1 M21 21

Business Intelligence Services and Reporting Application Developer – Reports M13 M21 9

Version 5.0

Team Role Roll On Month

Roll Off Month

Total Months

Eligibility System Tester M6 M18 13



Enterprise Readiness Business Process Reengineering Lead M4 M16 13

Enterprise Readiness Business Process Reengineering Lead M4 M16 13

Enterprise Readiness Training Developer M6 M21 16



Note: This table represents the minimum number of resources contractually obligated to complete the SRS Contract. Additional resources may be identified during the Analyze and Design phases of the project. There is an expectation that the State will provide business resources, technical resources and subject matter experts as needed to support the project.

Version 5.0

4.3 Organization Chart

The proposed Avenues implementation team is shown in the Avenues Project Organization Chart. This chart shows the resources specifically identified for SRS and its requirements across all phases of the project. Accenture will leverage Perceptive to fill the roles for the Content Management while Accenture while remaining overall responsible for the overall project.

Figure 2 - Avenues Project Organization Chart

Version 5.0

4.4 Key Personnel

Listed in the table below are the contractor resources that have been identified as key to the Avenues project. Proposed consultants should be available to staff the project, unless prevented from doing so by circumstances beyond the Proposer’s control.

Table 3 - Key SRS PersonnelRole Role Descriptions Relevant Experience

Keith Salas

Avenues Project Manager

Oversee and would provide day-to-day direction of the project. Is the single point of contact for the State regarding the Avenues implementation

Resolves escalated issues, creates plans to mitigate risk, and remove roadblocks

Management and technical support to project team members

Handles complex projects. Designs and implements project plans

Relies on experience and judgment to plan and accomplish goals

13 years experience in IT field delivering large, complex systems, on-time and on budget, and to the satisfaction of the customer

9 years of health and human services experience including 6 years eligibility determination and 2 years child support systems

7 years of project management experience

Robin Murphy

Sub-Project 1 Business Architecture and Change Management Project Manager

Defines future business processes for use with Avenues solution

Performs Organizational Assessment to support of the new business model and provide recommendations for organizational change

Develops a Stakeholder Assessment and Management Plan

Works directly with the project managers to provide communications on status of project and web updates

3 years experience in change management / implementation 2 years health and human services experience including Medicaid

eligibility determination systems 6 years experience in training development and delivery including

leading training teams 4 years experience business process development, testing and

implementation 1 year experience organizational design and implementation

Mel Pieper

Sub-Project 2: Update Technical Architecture and Install Infrastructure Project Manager

Designs expansion of K-MED technical architecture to support Avenues requirements

Defines system and application architecture and would provide vision, problem anticipation, and problem solving ability to organization

Assists in the definition of the architecture

25 years of experience in the IT industry delivering large, complex systems, on-time and on budget, and to the satisfaction of the customer

15 years experience managing technical support/architecture teams 10 years experience in managing system architecture at the

enterprise level 12 years of experience working with the proposed RDBMS-based

applications

Version 5.0

Role Role Descriptions Relevant Experienceand technology needs of the organization based on new and emerging technologies, and establishes priorities and strategies consistent with business goals and economic viability.

Serves as an advisor to senior IT leadership on advanced technologies and evaluates the business impact through cost/benefit analysis. Recommends and incorporates technology with long-term business plans

10 years of experience years of experience supporting object oriented web applications

10 years of health and human services experience including 10 years TANF, SNAP and other program eligibility determination systems

Kristen Parker

Sub-Project 3: Content Management Project Manager

Develop and design the overall ECM storage and retrieval strategy

Define a conversion strategy for existing paper case files

Leads the overall design, development and implementation of the ECM and integration with Avenues

9 years experience in designing, building and managing software projects

Led the design and implementation of document management solutions as a project manager for over 85 projects

Led the document management team for the California Statewide Automated Welfare System (SAWS) Consortium-IV (C-IV) project.

Experience marrying the unique needs of human services case management with the best practices of document management systems

Jerald Nielson

Sub-Project 4: Eligibility and Benefits Administration System Project Manager

Leads the technical team and oversees all technical aspects of Avenues application development including data conversion, portal and interfaces

Manages technical resource allocation for the team to manage project cost and schedule

Reviews all technical deliverables and would provide input to the Overall Project Manager regarding approval of technical deliverables

7 years of experience in managing application development at the enterprise level

Developed and maintained a major health and human services systems on J2EE platform

11 years of experience in IT field delivering large, complex systems, on-time and on budget, and to the satisfaction of the customer

9 years of health and human services experience including 9 years Welfare eligibility determination systems


Dave Corey

Sub-Project 5: Virtual Contact Center Project Manager

Leads detailed design meetings to build, configure, and implement the Virtual Contact Center

Defines integration of telephony systems with Avenues CRM functions

Analyzes field offices and provides recommendations for new model to support the Virtual Contact Center

33 years experience in the communications industry, including wire-line service (PSTN) and VoIP network configurations.

28 years experience in telecommunications infrastructure for Avaya and Cisco systems, including ancillary applications (IVR, Call Management Systems, CTI, Advanced Call Routing, Voice Messaging, Fax Server, Call Recording, Quality Monitoring, and Workforce Management applications)

Development, testing, installation and maintenance of two 500+

Version 5.0

Role Role Descriptions Relevant Experienceseat call centers for health and human services clients.

7 years experience in health and human services – 5 years in support of Medicaid eligibility systems, and 2 years at the Texas Welfare Modernization project.


Anthony Perez

Sub-Project 6: Business Intelligence Services and Reporting Project Manager

Leads the Business Intelligence Services & Reporting team, skilled in data analytics, reporting, and data mining tools & techniques

3 years experience in architecting and implementing eligibility system reporting components leveraging various tools and concepts; Oracle Database, SQL, PL/SQL, Oracle Reports Builder, Oracle Warehouse Builder, Extract Translate Load Design Concepts (ETL), Oracle Business Intelligence Enterprise Edition(OBIEE) and Data Warehousing Dimensional Design Concepts.

3 years experience in architecting and implementing eligibility system data conversion components leverage Oracle Database and Oracle Warehouse Builder.

2 years of development team leadership experience; leading teams of 2-3 developers to meet project milestones on time and on budget.

1 year experience in maintaining and enhancing a production Business Intelligence Services providing analytical reports from eligibility system data.

6 years experience in IT field maintaining and enhancing a large and complex eligibility system to meet customer needs

Version 5.0

4.5 Skill Sets for the SRS project

The listing below includes roles/skill sets for the SRS project. The focus is to provide a high level description with a focus on the tool and developments skills. A person can serve more than one role. It is expected that the Key Skills and Responsibilities that are highlighted in bold font are the needed skill sets that would most benefit the project.

Role Key Skills and Responsibilities1. Project Manager Provides day-to-day leadership of project team

Champions project vision and goals Bridges IT relationship with multiple agencies and outside organizations Builds the team Executes governance Monitors project plans and redirects team efforts as needed to adhere to project schedule and outcomes

2. PMO Manager Provides day-to-day leadership and management of the Project Management Office (PMO) team and resources.

Leads and manages the PMO team and resources including (but not limited to):1. Risk and Issue Management2. Change Control Management3. Deliverable Management4. Document Management5. Resource Management

Work plan management of the Avenues project

3. System Architect Understanding of Service Oriented Architecture principles and governance Reviews application for performance and standards Reviews log directories for growth and manages appropriately Reviews capacity planning and performance impact Serves as nexus between program/application needs and architecture

4. Technical Architect Manages/enhances Architecture Blueprint, Patterns and Reference Architectures

Skilled in the implementation of Enterprise Service Bus Assesses business needs and enhances the architecture appropriately Reviews and supports project teams with architectural guidelines Assists in enhancing SOA methods Conducts Technical / Architectural Quality Assurance Specific Skills in Oracle Service Oriented Architecture suite and the open standards within the APSP that

implement it.

5. Application Developer – (Focused on Java) Codes tests, and configures system components

Version 5.0

Role Key Skills and Responsibilities Translates functional requirements and designs into programmatic code Implements agency-specific configurations and customizations Performs testing on code until passes unit test conditions Database knowledge - ANSI SQL, Data Access Objects Specific programming language skills/knowledge - Java, Spring Framework, Java Server Pages, Oracle Portal,

XML, Rational Suite (Trained), Unified Modeling Language (UML), Services Oriented Development, Oracle Unified Business Process Management.

Knowledge of development environment

6. Application Developer – Reports Produces and tests new and existing reports

Designs/modifies report layouts Understands databases in order to access report data Translates business requirements into report design Creates report templates to include standard report objects, queries, and layouts View, interact with and analyze the result set, and share the results around information Drag-and-drop trusted content, filters and other content Add colors and text, add comments and personalize widgets Share and distribute objects and reports to be consumed by others and collaborate through integrations with

other software packages Specific tools Oracle Business Intelligence Enterprise for Business Intelligence Services reporting/Oracle BI Publisher for

reports

7. Application Developer – Conversion Codes and tests conversion programs to accurately convert data from legacy systems

Understand data translation Ability to translate requirements into specifications and aid in test planning Knowledge of data handling methodologies Ability to create reports Data analysis skills Use of Oracle Warehouse Builder in loading data

8. Business Functional Manager/Testing Lead Responsibilities of this position include functional aspects of SRS Avenues including requirements definition, design, and testing

Facilitates requirements sessions and oversee the writing and validation of detailed requirements. Works closely with the Implementation team to plan for business changes needed to accommodate the new

system Plans, executes, and documents testing processes involved in the implementation of the systems and services Coordinates the project work plan and schedule for the Testing Team Works closely with Application Development Team to verify timely completion of testing and testing status Verifies team deliverables

Version 5.0

Role Key Skills and Responsibilities Interfaces with other teams

9. Tester Provide expertise in the planning, constructing and execution of Avenues tests. Apply business and functional knowledge to meet the team’s overall test objectives.

Knowledge of SRS’s business requirements and processes Works closely with Application Developers to verify the application and any identified defects Assists in the development of test conditions and test scripts Assists in the execution of test scripts Logs the necessary defects for the Avenues application related to execution of test scripts

10. Imaging/Content Management Developer 2 to 3 years in imaging, document indexing, and scanning hardware deployment; skills in the ImageNow product

11. Business Process Reengineering Lead – SRS Leads team to redesign SRS business processes to take best advantage of system capabilities

Leads team to make organization and roles changes to align with new and revised business processes Develops in-depth knowledge of system functionality and processes Knowledge of SRS’s business requirements and processes Ability to evaluate options in light of operational, management, and policy considerations

12. Business Analyst/SME Provides subject matter expertise to developers, designers, training team and enterprise readiness team

Defines system requirements/configuration based on SRS business requirements Provides guidance, input and review for training and enterprise readiness materials Knowledge of SRS’s organizational culture and business requirements Understanding of specialty areas (e.g. intake) Ability to articulate SRS stakeholder and customer needs Ability to communicate complex issues to technical and non-technical audiences

13. Training Developer Contribute to the Training Team by assisting in designing and developing the training materials.

Ability to communicate issues with technical and non-technical audiences Familiarity with Avenues Training tools: Microsoft Work, Adobe Captivate and RoboHelp Knowledge of SRS’s business requirements and processes

Version 5.0

5.0 Deliverable Schedule

The following deliverable schedule provides the agreed upon pricing for specific deliverables and the associated expected month for completion. The Project Work Plan will establish specific due dates for each deliverable, which may vary from this table, and shall govern. The holdback of deliverables will be released following the Acceptance of the deliverable, and the Acceptance of the Avenues implementation in Phase ,2 and again for Phase 3 and Phase 4. Holdback of the deliverables for the implementation of the BPR changes (Pilot, and each subsequent set of offices in deliverable list), will be released upon Acceptance of the BPR deliverables and completion of the BPR work. Other payments due to the contractor are incorporated into the contract and are detailed in the recurring payment schedule below.

No.

SRS Deliverable Name Deliverable Month

Deliverable Price

1 Project Management Plan 1 $80,235

2 Cost Allocation/Time Reporting 1 $64,188

3 Detailed Project Plan (KITO Approved) 1 $128,376

4 Facility Management Plan 1 $112,329

5 Communications Plan 1 $112,329

6 Risk Management and Issues Management Plan 1 $96,282

7 Configuration Management Plan 1 $144,423

8 Knowledge Transfer Plan 9 $208,610

9 Interface Plan (P2) 2 $481,409

10 Reports Plan (P2) 2 $465,362

11 Interface Standards and Layouts (for Agencies and Business Partners) (P2)

2 $369,080

12 Requirements Validation (P2) 3 $561,643

13 Business Intelligence and Reporting Plan 3 $481,409

14 Enterprise Readiness Plan (P2) 10 $673,972

15 Conversion Plan (P2) 6 $914,676

16 Application Code and Unit Test (P2) 13 $962,817

17 Continuity of Operations Plan (P2) 15 $240,704

Version 5.0

No.


Deliverable Price

18 Training Plan (P2) 6 $497,456

19 Capacity and Performance Plan (P2) 6 $465,362

20 Training Materials (P2) 13 $497,456

21 Deployment/Rollout Plan (P2) 15 $353,033

22 User Acceptance Test Plan (P2) 15 $353,033

23 Online User Guide (P2) 14 $240,704

24 Operating Procedures Guide (P2) 14 $224,657

25 Tables and Rules User Guide (P2) 14 $320,939

26 Data Conversion Dry-Run (P2) 21 $401,174

27 Knowledge Transfer Scorecards (Completed Phase 2 Personnel Assessments)

20 $112,329

28 Performance Test (P2) 20 $176,516

29 Training Delivery Complete (P2) 20 $465,362

30 Detailed System Design (DSD) (P2) 10 $465,362

31 Application Deployment (P2) 21 $561,643

32 System Acceptance (P2) 21 $1,123,287

33 System Test Plan (P2) 11 $320,939

34 Continuity of Operations Exercise (P2) 15 $320,939

35 System Test Results(P2) 15 $320,939

36 LIEAP Detailed System Design 23 $288,845

37 LIEAP System Test Plan 24 $240,704

38 User Acceptance Testing Results and Resolutions Document (P3) 27 $192,563

39 LIEAP Application Deployment 27 $256,751

40 LIEAP System Acceptance 27 $465,362

41 LIEAP System Documentation and Knowledge Transfer 28 $144,423

42 Virtual Call Center Deployment 30 $160,470

Version 5.0

No.


Deliverable Price

43 Organization Design for Virtual Contact Center 24 $192,563

44 Virtual Call Center Detailed System Design 24 $240,704

45 Virtual Call Center System Test Plan 25 $160,470

46 Virtual Call Center System Acceptance 30 $240,704

47 Virtual Contact Center System Documentation and Knowledge Transfer

31 $144,423

48 BPR Assessment 3 $553,846

49 BPR Plan 5 $692,308

50 BPR Implementation Pilot 6 $553,846

51 BPR Office Implementation 2 thru 6 8 $346,154



Total Deliverables: $18,816,185

*Deliverables 12, 35, 36, 38 - 46 are unique to the SRS – Avenues project. All other deliverables are common to both K-MED and SRS; however, the price is only specific to SRS portions of the deliverable.

Listed below are recurring payments. Service delivery billings refer to 12 months of maintenance services, following implementation:

Fiscal Year: FY2012 FY2012 FY2012 FY2012 FY2012 FY2012 FY2012 FY2012Month: 1 2 3 4 5 6 7 8

Billing CategoryHoldback Eligible Total Category Price Aug-11 Sep-11 Oct-11 Nov-11 Dec-11 Jan-12 Feb-12 Mar-12

Monthly PMO Billings N $1,570,504 $90,575 $77,426 $80,370 $80,370 $80,370 $80,277 $75,645 $75,645Service Delivery Billings N $1,389,000 $0 $0 $0 $0 $0 $0 $0 $0

SRS Non-Deliverable Billings $2,959,504 $90,575 $77,426 $80,370 $80,370 $80,370 $80,277 $75,645 $75,645

FY2012 FY2012 FY2012 FY2013 FY2013 FY2013 FY2013 FY2013 FY2013 FY20139 10 11 12 13 14 15 16 17 18

Billing CategoryApr-12 May-12 Jun-12 Jul-12 Aug-12 Sep-12 Oct-12 Nov-12 Dec-12 Jan-13

Monthly PMO Billings $75,645 $65,675 $65,675 $65,675 $65,675 $66,392 $66,392 $66,392 $68,359 $68,345Service Delivery Billings $0 $0 $0 $0 $0 $0 $0 $0 $0 $0

SRS Non-Deliverable Billings $75,645 $65,675 $65,675 $65,675 $65,675 $66,392 $66,392 $66,392 $68,359 $68,345

Version 5.0


Billing CategoryFeb-13 Mar-13 Apr-13 May-13 Jun-13 Jul-13 Aug-13 Sep-13 Oct-13 Nov-13

Monthly PMO Billings $68,345 $68,345 $68,345 $10,042 $10,042 $10,042 $10,042 $10,401 $0 $0Service Delivery Billings $0 $0 $0 $112,745 $112,745 $112,745 $112,745 $117,299 $117,299 $117,299

SRS Non-Deliverable Billings $68,345 $68,345 $68,345 $122,787 $122,787 $122,787 $122,787 $127,700 $117,299 $117,299


Billing CategoryDec-13 Jan-14 Feb-14 Mar-14 Apr-14 May-14 Jun-14 Jul-14 Aug-14 Sep-14

Monthly PMO Billings $0 $0 $0 $0 $0 $0 $0 $0 $0 $0Service Delivery Billings $117,299 $117,317 $117,317 $117,317 $116,874 $0 $0 $0 $0 $0

SRS Non-Deliverable Billings $117,299 $117,317 $117,317 $117,317 $116,874 $0 $0 $0 $0 $0

No further service recurring payments after month 33.

SRS Deliverables $18,816,185SRS Non Deliverables $2,959,504

$21,775,689

Version 5.0

6.0 Project Management and Project Administrative Services

The Project Management Office (PMO) will be comprised of representatives from the K-MED/Avenues State and Contractor Project Teams. The PMO shall be responsible for providing project management services. The PMO will generate and provide project management analysis and information to K-MED/AVENUES Project leadership, the K-MED/AVENUES Project Steering Committee and K-MED/AVENUES Project Team members. The PMO will ensure that all applicable Kansas Information Technology Office (KITO) requirements, as specified in ITEC Policy 2400 Revision 1, are met.

The K-MED/AVENUES State Management Team shall include the State’s Project Director(s), State’s Project Manager, as well as the Contractor Project Manager.

6.1 KITO Requirements

The Project Management Plan shall meet all requirements of ITEC Policy 2400, Revision 1, and must be approved by the CITO prior to commencement of material project activities (January 1, April 1, July 1, and October 1). The K-MED/AVENUES Project Management Plan will reflect the four major project phases for the K-MED/AVENUES project.

The Detailed Project Plan, a detailed work breakdown structure completed in Microsoft Project, is one part of the overall K-MED/AVENUES Project Management Plan. For Project Phases 1 and 2, all individual tasks for the Plan and Analyze Phases of the project shall be equal to or more than eight hours and less than or equal to 80 hours of duration (unless there is a KITO exception). The tasks for later work may be greater than 80 hours but must be in sufficient detail to show all milestones, deliverables and the summary level dependent activities in sufficient detail to assess milestone and deliverable statuses. Near the completion of the preceding development phase, the Detailed Project Plan for the next development phase will be further refined. All tasks shall be resource loaded (both Contractor and State employees) and leveled. All deliverables shall be shown as milestones. Additional internal milestones/deliverables shall be established for management and reporting purposes. The project’s critical path(s) shall be identified.

Quarterly Reports shall be prepared in a timely manner by the Contractor so that they can be submitted by the Project Director to the KITO office on a quarterly basis. An updated version of the project plan shall be submitted by the Contractor on the 3rd business day after the end of the quarter. Quarterly reports shall show the project’s progress and estimate at completion. The table below identifies the elements of the Quarterly Report and responsibilities.

Version 5.0

If the Project encounters problems adversely affecting scope, schedule or cost, KITO reporting information and frequency may increase. Any additional reporting requirements arising during the course of the Project due to problems adversely affecting scope, schedule or cost shall be maintained and supported by the Contractor at no additional cost provided the additional reporting requirements pertain to activities the Contractor is responsible to perform or information the Contractor is responsible to manage.

6.2 Internal Reporting Requirements

The Contractor shall provide K-MED/AVENUES Project Monthly Status Reports that reflect the previous month’s activities. K-MED/AVENUES Project Monthly Status Reports are due by Tuesday, 10am, in the week following the end of each month. If a State holiday occurs during one of the report preparation days, a grace period of one day will be allowed for the submittal of the report. Accepted K-MED/AVENUES Project Monthly Status Reports shall constitute the Deliverable that permits payment for project management services. The QARP process shall be used for these monthly deliverables. The table below identifies the elements of the K-MED/AVENUES Project Monthly Status Reports and responsibilities. In addition, for select project WBS elements earned-value reporting may be beneficial. Where the State believes that this level of granularity will provide a valuable indicator of the status of a discrete critical project scope element, the State shall request and the Contractor shall provide earned-value reports for the duration of the specific scope element or until the State is satisfied with the progress of the specific scope element.

Monthly Reporting Contractor KDHE-HCF/SRS Team

Budget-to-Actual Lead Assist

Critical Path & Analysis Lead Assist

Milestone Status Lead Assist

Project “Health” Assessment Lead Assist

Look ahead (upcoming activities and issues) Lead Assist

Outreach Activities (training, risk issues and mitigation activities, communication, etc.)

Assist Lead

Progress in Knowledge Transfer Lead Assist

Change Request Log Assist Lead

Staff Changes (Contractor and State) Lead Assist

Version 5.0

KITO Quarterly Reporting Contractor KDHE-HCF/SRSCover Letter Lead

Transmittal Letter (including narrative) Lead

Checklist Lead

Updating Plan (WBS, Schedule, EAC) Lead Assist

WPI Assist Lead

The Contractor shall provide K-MED/AVENUES Project Weekly Status Reports that reflect information for the Monday through Friday time period. K-MED/AVENUES Project Weekly Status Reports are due by Tuesday, 10am, in the week following the reporting period. If a State holiday occurs during one of the report preparation days, a grace period of one day will be allowed for the submittal of the report. The table below identifies the elements of the K-MED/AVENUES Project Weekly Status Reports and responsibilities. A template for the K-MED/AVENUES Project Weekly Status Report is provided in Attachment A.

Weekly Reporting Contractor KDHE-HCF/SRS Team

Accomplishments Lead Assist

Activities for Next Reporting Period Lead Assist

Issues/Risk Elements Lead Assist

Status of Critical Path Lead Assist

Budget to Actual Lead Assist

6.3 Project Time Reporting and Cost Allocation

The Contractor shall maintain a record of hours worked per WBS element on the MS project plan. The Contractor shall provide the State access to MS Project to enable authorized personnel from the State to enter hours worked by WBS element for each employee or other updating as appropriate. Time reporting for State project personnel shall be performed on a weekly basis. The table below identifies the work elements for time reporting and responsibilities.

Time Reporting Contractor KDHE-HCF/SRS Team

Configure, Host, Administer MS Project Server or other time capture/allocation tool

Lead Assist

Train Appropriate Project Team Members on Time Reporting Lead Assist

Update Project Schedule/WBS with Actual Employee Time Lead Assist

Provide Monthly Reports on Budget vs. Actual Time per WBS Element Lead Assist

Capture and record Contractor time Lead

Capture and record State time Assist Lead

6.4 Project Execution Tools

The Contractor shall provide all necessary training in, and access to, the Rationale Toolset for requirements management, version control of documents, internal workflow processes for defect management and testing tools for unit, system and performance testing. Training shall be held for all members of the co-located Project Team deemed necessary by the State Project Director(s). The

Version 5.0

amount of training time provided by the Contractor shall be sufficient to adequately train project team members so that they may adequately perform their project responsibilities.

Project Execution Tools Contractor KDHE-HCF/SRS Team

Configure, Host, Administer Rationale Toolset Lead Assist

Train Appropriate Project Team Members on Tools Lead Assist

6.5 Documentation of Meetings and Decisions

The Contractor shall utilize the following procedures for conducting and documenting meetings:

Prepare agenda including meeting objectives.

Conduct the meeting.

Document action items, issues and decisions.

Preparing meeting agendas and documenting action items, issues and decisions may also be performed by the K-MED/AVENUES State Project Team members when deemed appropriate and mutually agreed to by Contractor and State.

6.6 Risk and Issues Management

The Contractor shall, in consultation with the K-MED/AVENUES State Management Team, develop and maintain a Risk and Issues Management Plan which shall include a Risk and Issues Tracking Document. The Plan shall identify key risk elements and rank these risks based on the product of the probability of occurrence and the impact (i.e. Qualitative Risk Analysis). The Plan shall also include mitigation measures to monitor identified risks. Using these measures, the Contractor shall update the Risk and Issues Tracking Document to report on the status of identified risks and any proposed or implemented risk mitigation activities. The updated Risk and Issues Tracking Document shall be included as a subsection of the K-MED/AVENUES Project Monthly Status Report, unless a risk element occurs, in which case that risk element shall be reflected as an issue. Issues which prevent work from being accomplished shall be reported as part of the K-MED/AVENUES Project Weekly Status Report. Risk and Issues Management Meetings will be scheduled monthly and will include members of the K-MED/AVENUES State and Contractor Management Teams.

6.7 Deliverables

Please refer to Section 5.0 Deliverables Schedule above.

Version 5.0

Change Request

Authority Cost Impact Scope Impact Schedule Impact Agency Impact Law, Reg, Policy Impact

Level 1 Executive SponsorsChanges over $250K

Would be associated with cost impact

Any change affecting the “Go-live” date

TBD Any changes affecting laws, regulations or other non-KDHE-HCF/SRS/KID policies

Level 2 Steering CommitteeChanges over $50K and under$250K

“Significant” impact on project scope (+/-)

TBD Recommends changes to Executive Sponsors

Level 3 K-MED Leadership Team (CCB)

Changes under $50K

“Moderate” impact on project scope (+/-)

Any change affecting KITO milestones or other key (internal management) milestones

Any decisions/ changes T to support specific

agencies or “adversely” affecting agencies

Any changes affecting KDHE-HCFSRS policies and procedures

Level 4 State LeadsPMOBusinessTechEnterprise Readiness

All changes affecting cost (+/-) must be approved by K-MED Leadership Team

“Minor” impact on project scope (+/-)

“Minor” impact on project activities that do not adversely impact a milestone

6.8 Governance, Change Control Process and Acceptance of Deliverables

6.8.1 Governance

Project Governance is defined in the K-MED/AVENUES Steering Committee Charter and in the K-MED/AVENUES Project Management Plan. Four levels of project governance are delineated below:

1) Level 4 –K-MED/AVENUES State Managers (Business, Technical, Enterprise Readiness) are authorized to approve minor changes in project scope.

2) Level 3 –K-MED/AVENUES State Management Team is authorized to approve moderate scope changes.

3) Level 2 – K-MED/AVENUES Steering Committee is authorized to approve significant scope changes and make recommendations to the Executive Sponsors on policies and issues affecting agencies.

4) Level 1 – Executive Sponsors approve recommendations from Level 2 and provide Statewide leadership and the mandate for the K-MED/AVENUES Project.

Version 5.0

6.8.2 Change Control Process

The following process shall be used for all scope, schedule or cost changes:

1. Change Requests (CR) are submitted by the K-MED/AVENUES State Management Team to the Change Control Board (CCB). The CCB shall be comprised of the State Project Director(s), the State Project Manager, and the Contractor’s Project Manager. A member of the State’s PMO shall serve as the Secretary of the CCB.

2. All CRs must be sponsored by a K-MED/AVENUES State Manager (i.e. Functional, Technical and Enterprise Readiness). To initiate a CR, the K-MED/AVENUES State Manager shall send an email request to the CCB. The request should include a priority designation.

a. Priority 1 – Urgent and Major Impact

b. Priority 2 – Urgent and Minor Impact

c. Priority 3 – Not Urgent and Major Impact

d. Priority 4 – Not Urgent and Minor Impact

1. The K-MED/AVENUES Project Team Manager must receive authorization from the CCB to proceed with the CR.

2. CRs shall be developed using the attached template. Analysis will include impacts to business requirements, cost, schedule and State and Contractor resources. CRs will be presented to the CCB and the merits of each CR shall be discussed collaboratively among the CCB, the sponsor, the Contractor and affected stakeholders.

3. The Contractor shall not bill the State for developing CRs. Within five days the CCB shall either:

a. Approve the CR

b. Disapprove the CR

c. Request additional information

d. Present the CR to the Steering Committee (as appropriate)

1. All CRs and their disposition shall be documented in the Change Control Log.

1. Approved CRs shall become Change Orders (CO) to the SOW. The CCB shall determine if the approved CO shall be designated as:

a. a fixed-price CO,

Version 5.0

b. a trade-off of hours from scope reduction,

c. a “time and materials” CO,

d. a reduction in scope CO, or

e. a schedule impact CO (e.g. a time extension for a deliverable).

1. The CCB shall designate the funding source for the approved CO. In most cases CO requiring funding will come from the designated pools of hours reserved for modifications and enhancements, interfaces, conversions, workflows and reports. The Requirements Traceability Matrix shall be updated to reflect the changes in scope to the applicable requirements.

1. After the change has been implemented and accepted, the CR shall be closed and documented in the closed page of the Change Control Log.

Version 5.0

Change Request (CR)

Change Request #: ______

Date Requested: _______________________

Requested by: _______________________

Assigned to: _______________________

Priority: ______________

Priority 1 – Urgent and Major ImpactPriority 2 – Urgent and Minor ImpactPriority 3 – Not Urgent and Major ImpactPriority 4 – Not Urgent and Minor Impact

Description of Change and High-level Requirements:

Reason for Change:

Implications of Not Making Change:

Analysis of Change

Analyst: ________________________ Time to Complete Analysis: ______ hrs

Est. Cost Impact: _________________ Date Completed: _________________

Est. Schedule Impact: _____________

Milestones/Deliverables Impacted: __________________________________________________

Teams Impacted: Functional

Enterprise Readiness

Technical/Infrastructure

Business Intelligence Services

Systems Impacted: _______________________________________________________________

Deliverables Impacted: ____________________________________________________________

Version 5.0

Change Request (CR)

Preferred Resolution and Assumptions:(Describe the best solution for the project while addressing functional, technical, usability and customer/stakeholder impacts)

Alternate Solutions (if applicable):(Describe alternative solutions while addressing functional, technical, usability and customer/stakeholder impacts)

Level of Effort

Team Design Hours

Development Hours

Testing Hours

Documentation Hours

Training Hours

Contractor

State

Resource Estimate

Team Member Name Hours Rate Start Date End DateContractorContractorContractorContractor

State N/AState N/AState N/AState N/A

Schedule Impact

Design Expected Complete Development Expected Complete

System Test Expected Complete

MM/DD/YY MM/DD/YY MM/DD/YY

Fixed-Price Change Order

Total Fixed Price: $

Detailed Fixed-Price Cost Breakdown by Phase (includes labor, travel, etc.)

Version 5.0

Design Phase Development Phase System Test Phase Training Material & Documentation

Time and Materials Change Order

Price Not to Exceed: $

Actual expenses shall be reimbursed at the agreed to labor rate and shall include travel, etc

Detailed Cost Estimate by Phase

Design Phase Development Phase System Test Phase Training Material & Documentation

Deliverable(s)

Risks and Issues(Identify impact to existing project risks and issues)

Supporting Documentation(Provide information relative to any documentation supporting this change request such as documents/files names, links, screen shots of applicable delivered pages, mock-ups, process flow diagrams, etc.)

Version 5.0

Version 5.0

ApproveK-MED LeadSend e-mail CR Request

(w/ Priority) to CCB; Secretary to Initiate CR

K-MED Lead AssignsProject Personnel to

Develop the CR

K-MED Leadership Team

Approve/DisapproveRequest to Initiate CR;

Leadership Teamto respond w/i

3 days

Disapprove

Project PersonnelDevelop CR

K-MED Leadership

Team Reviews CR andResponds w/i

5 days

Stop

Approve

DisapproveStop

Execute CR• define deliverable (DED)• update project plan (as req’d)• update RTM (as req’d)• notify impacted team membersand stakeholders

Request Additional Information/ Analysis

State LeadSubmits/Presents

CR to CCB

CR is Entered into Change Log

Defer

Brief Steering Committee

EscalateIf > $50K

Perform Additional Analysis or Provide

Additional Information

Steering Committee Decision on

CR

Approve

DisapproveStop

7.0 Requirements Validation, Business Process Design, Software Configuration, Testing, and Enhancements & Modifications

The project team will be responsible for analysis, design, configuration, and system testing of the SRS - Avenues application, including requirements validation, business process design, software configuration, testing, and enhancements and modifications. In scope are the requirements provided in SRS Human Services Eligibility Modernization RFP. The specific requirements in scope include:

1. Business Requirements

2. Technical Requirements

3. Interface Requirements

4. Conversion Requirements

The Avenues scope is an incremental addition to the K-MED scope. The K-MED SOW in Section 7 describes the phases of the System Development Lifecycle which trace RFP Requirements through the K-MED implementation. The Avenues scope follows the same process as described in Section 7 of the K-MED SOW. Additional sections of the Avenues SOW have been added to supplement special scope areas (e.g. Workflows, Interfaces, etc) to the base description for the Avenues system build.

Key additions not detailed in the Avenues requirements but are part of the project scope include:

Report Development – Described in the Business Intelligence Services and Reporting Statement of Work (SOW)

Forms and Notice Development – Described in the Automated Forms and Notices SOW

Conversion of LIEAP – Described in the Data Conversion SOW

NOTE: Although Accenture will not convert from the EATSS or TOP systems, Accenture will test the ability to decommission these systems during Operational Readiness Testing, and confirm the necessary functionality is working in Avenues.

Version 5.0

7.1 Test Phase

The SRS Test Phase will reference the K-MED Test Phase as the Avenues solution will leverage the methodologies, processes, conditions, and scripts that are defined in the K-MED Test Phase. As part of the SRS testing effort and to adequately test the Avenues scope, Accenture will supply a subset of Business Analysts and Application Development resources as an increment to the overall K-MED Test team. The result will be one integrated K-MED/Avenues Test Team.

The K-MED/Avenues Testing Team, consisting of both Contractor and State staff, will design, create and execute the necessary scripts based on the defined test conditions and cycles. Test phases will build upon each other in functionality and complexity. During test execution, System Investigation Requests (SIRs) will be identified, assigned a priority, and tracked through to completion. The goal will be that critical and high priority SIRs are corrected prior to the next test cycle.

Version 5.0

7.2 Responsibility Matrix

Scope Element Contractor SRS Analyze Phase

Conduct Conference Room Pilot Lead Assist

Perform Fit/Gap of APSP to K-MED Requirements Lead Assist

Define Reports, Interfaces, Conversion, Enhancement, Forms and Workflows (RICEFW) Inventories

Lead Assist

Design Phase

Design Modifications Lead Assist

Design Security Lead Assist

Build Phase

Build Configuration Lead Assist

Build and Unit Test Application Components Lead Assist

Develop Test Conditions and Scripts Lead Assist

Test Phase

Plan Integration Test Lead Assist

Plan System Test Lead Assist

Plan UAT Lead Assist

Execute Integration Test Lead Assist

Execute System Test Lead Assist

Execute User Acceptance Test Assist Lead

7.3 Deliverables and Work Products

Ref. No. Phase Deliverable/Work Product Name

Description

29 Design Detailed System Design The General and Detailed Design documents the technical requirements for developing, testing, and implementing the K-MED System.

NA Design Development Standards Guide

(work product - not a paid deliverable)

This deliverable describes the standards and process for making modifications to the APSP application.

15 Build Application Code and Unit Test

This deliverable represents the developed and unit tested enhancements and modifications that are ready for system test. Exception and error handling processing will be validated against signed-off program design specifications. Enhancements and modifications will be tested as standalone modules.

32 Test System Test Plan System Test Plan describes the test strategy for K-MED including the sequence and methodology of testing. The plan addresses at a high level the test environment, the tests to be performed, and the schedule for test activities. It also includes a list of business processes per module.

The System Test Plan will include objectives, entry and exit

Version 5.0


Description

criteria, approach, schedule, script documentation, data management, assumptions, constraints, risks, and requirements traceability.

21 Test User Acceptance Test Plan We will include the following in the User Acceptance Test Plan: objectives, entry and exit criteria, approach, schedule, script documentation, data management, assumptions, constraints, risks, and requirements traceability.

34 Test System Test Results This deliverable documents the system test results of the system test conditions and scripts and the fixes or SIRs identified due to system test. It details of the test scripts executed and the number, type and status of identified SIRs during the system testing process.

37 Test User Acceptance Testing Results and Resolutions Document

This deliverable provides documentation of the issue tracking and resolution during UAT. UAT testing results are reported in this deliverable.

Version 5.0

8.0 Workflow Analysis and Development

The Avenues Project team, including the business analyst, will be responsible for design, configuration, and testing of the system BPM-based workflows within the Business Process Management (BPM) tool. This team will also be responsible for configuring and/or changing workflows internal to the system. Their tasks will include requirements validation, functional design, technical design, build and unit test, and system testing.

8.1 Scope Definition

APSP provides 12 BPM workflows that are shipped “out of the box”. These processes will be configured according to SRS need. Business processes will describe workflows for both human and system users. Business Process designs can include input data, process flows, tasks, routing (including escalation), forms, output data, invocation of external systems like rules engines, and business activity monitoring events. BPM-based workflows will be designed, built and deployed in the Oracle BPM Suite environment. Non-BPM workflows will consist of Java code for page-to-page workflows, tasks and reminders, and Java Server Pages-based portlets for forms and page elements.

The following definitions were used when estimating the effort for workflows. These definitions will be used to determine complexity both during the configuration of included workflows and when implementing any contingency workflows:

Process Step: A discrete, unique human task (i.e., Complete and Forward Form) or discrete, unique system operation (i.e., Get Normalized Address) that is performed during the course of the business process. The following BPM constructs are not process steps are not counted as such:

Decision points (i.e., Is Address Normalized?)

Routing rules (i.e., if program=”Medicaid” then forward to role X)

Escalations (i.e., If application has been idle at this step for 24 hours, then escalate to role X)

Business processes often include sub-processes. The building of these sub processes will follow the same sizing approach as any other process. Sub-processes included in master processes will be counted as 1 process step.

Role: The human or system actor performing the process step. These are identified by the role headings in a typical “swim lane” flow design diagram.

For example, the following simple process is comprised of 4 Process Steps and 2 Roles:

Version 5.0

The following, more complex process flow has 12 process steps and 4 roles:

This count includes the following 8 Human Task Process Steps:

1. Answer Non-Financial Questions

2. Answer Financial Questions

Version 5.0

3. Submit Application

4. Provide Information (unique step called in two different contexts)

5. Request Information (unique step called in two different contexts)

6. Run Eligibility

7. Review Results

8. Complete Application

This count includes the following 4 System Tasks Process Steps:

1. Assign Caseworker (calls the existing Assign a Caseworker sub process)

2. Check Business Rules

3. Mail Notices and Correspondence

4. Post Results to Self Service Portal

The following scale will be used when building a new business process or configuring an existing business process.

Workflow Complexity Process Steps (Human and

System)

Roles(Human and

System)Simple Up to 5 1 to 2

Average 6-11 3 to 4

Complex 12+ 5 +

After general design, the number of steps and roles in the business process will be counted. The number of steps and roles will then be compared to the above scale. If both numbers fall in the same complexity range, then that complexity will be applied to the business process effort. If one of the measures falls in a higher complexity range, then the higher complexity will be assigned to the business process. The following sample workflow inventory demonstrates sizing examples:

Workflow Process Steps (Human and

System)

Roles(Human and

System)

Complexity

Sample Workflow 1 5 3 Average

Sample Workflow 2 5 2 Simple

Sample Workflow 3 13 4 Complex

Version 5.0

The following BPM-based workflows are included in the APSP solution. Process configurations to the following processes are in-scope for the Avenues solution. Configurations include modifications of business process flow, role, reminder, alert, and data changes to the base process flow that is included with the solution. Configuration also includes configuring Business Activity Monitoring events for tasks in the workflow.

Configuration does not include major changes or re-purposing of the base process flow, such as extensive branching of an existing flow. Using personal learning plans (PLPs), BPM skills will be transferred to State employees for the purpose of extending and repurposing the existing workflows.

Public Assistance Portal BPM Workflows

Workflow Steps ComplexityRegistration Application Received

File Clearance Worker/Clearinghouse Assignment Intake Verifications Received Application Assigned to Worker

Average

Determine Eligibility Verify/Complete Intake Eligibility Determination Supervisor Authorization Documents Generated Active Program Re-assigned (if needed)

Complex

Case Maintenance Receive Update/Re-application Process Update/Re-application Eligibility Determination (if needed) Documents Generated (if needed)

Average

Quality Assurance Random Sample Case Identified Worker Assignment Process Review Decision/Outcome

Average

Cost Avoidance and Recovery

Potential Case Identified Worker Assignment Research Cost Avoidance/Recovery Action Documents Generated (if needed)

Simple

Hearings and Appeals Request Filed Worker Assignment Review Decision/Outcome

Simple

Overpayment/

Underpayment

Identification Worker Assignment Process Decision/Outcome

Simple

Version 5.0

Self Service Portal BPM Workflows

Workflow Steps ComplexityAutomatic Application Application Received

File Clearance Worker/Clearinghouse Assignment Intake Verifications Received Application Assigned to Clearinghouse Status Reported to Customer

Complex

Screening Questionnaire Received Possible Eligibility Determined Status Reported to Customer

Simple

Report a Change Demographics or Income Change Received Verifications Received Worker/Clearinghouse Assignment Status Reported to Customer

Simple

The following non-BPM workflows are included in the APSP solution. Reminder, alert, and data changes to the following processes are in-scope for the Avenues solution.

Public Assistance Portal Non-BPM Workflows

Workflow Steps ComplexityFraud Identification

Worker Assignment Process Decision/Outcome

Simple

Worker Reassignment Redistribute Person’s Workload Future Date an Assignment Automatically Reassign Programs Based on Program State

Average

Resource Databank and Collaborator Access

Captures Third Party Organization Information Manages Recruitment of New Organizations Third Party Organization Self Service

Simple

Employment Services and Child Care Self-Sufficiency Planning

Allows workers to create Action Plans to document customer concerns and issues

Documented Family Plans capture customer strengths (e.g., degrees, skills) and desired outcomes and strategies (e.g., employment goals)

Monitors attendance, performance, and progress of customer training activities

Average

Customer Activities and Progress Tracking

Allows customers to enroll in training activities Training providers manage attendance for each session,

minimizing training data that worker must enter.

Simple

Skills Assessment and Job Matching

Provides job matching functionality based on customer skills documented by employment services workers and job opportunities listed in the Resource Databank.

Simple

Needs Assessment, Supportive Services and Payment Requests

Captures information regarding customer needs and barriers (e.g., lack of transportation)

Creates Service Arrangements and authorizes Supportive Services

Average

Version 5.0

Workflow Steps Complexityor Referrals to Service Providers.

Generates Payment Requests to repay Service Providers for their services.

Child Care Determines eligibility for Child Care based on person and case data

Generates Notices of Action for Child Care automatically Payments to Child Care Providers are calculated within the system

based on information from the Child Care certificate Displays Child Care waiting list functionality for jurisdictions that

require waiting lists.

Average

Foster Care Verify/complete intake (including Foster Care specific data collection pages)

Determines eligibility for Foster Care based on person and case data

Generates Notices of Action for Foster Care automatically Payments to Foster Care Payees are calculated within the system

based on the results of the eligibility determination and benefit calculation

Average

Adoption Verify/complete intake Determine eligibility for Adoption based on person and case data Payments for Adoption are issued

Simple

8.2 Major Activities by Phase

8.2.1 Analyze Phase

8.2.1.1 Analyze Process Flows

The Avenues Project team, including the business analyst, will work closely with the SRS business analysts to inventory and define Avenues workflow requirements. This serves to identify the nature and degree of the workflow development work. This step includes defining strategy for use of the workflows delivered with the APSP solution, the workflow capabilities of Oracle BPM Suite, and defining any additional business processes not delivered with the APSP solution.

Contractor Responsibilities:

Attend meetings with Business Analysts, Case Workers, and State Functional SMEs to identify BPM and non-BPM workflow requirements.

Confirm an inventory of BPM processes and sub-processes to be developed including the process name, description, and type.

Document high-level requirements for each BPM business process. Requirements should include system users, human users, decision points, and desired outcomes for each process.

Identify and document the security roles for each BPM and non-BPM workflow.

Version 5.0

Develop high level test conditions and expected results for each BPM and non-BPM workflow.

Confirm and adjust Project Plan based on the outcomes of the Analyze Phase.

State Responsibilities:

Provide Subject Matter Experts (SMEs) for each functional area that can efficiently and accurately document/describe required workflow requirements.

Review and approve the process inventory – this is important, as it defines the list of processes that will be built in subsequent activities.

Rationalize workflow requirements and determine if “as-is” processes already exist that could be used as starting points in the Design Phase.

Assist in the documentation of high-level business process requirements for each functional area.

Assist in the development of high-level test conditions and expected results for each workflow.

Make design decisions in a timely manner.


8.2.2 Design Phase

The design phase begins with specifications from the Analyze phase, and ends with a list of tasks that, once performed in Build, will deliver the future state solution.

8.2.2.1 General Design Documents

General designs will be created for each business process that was approved at the end of the Analyze Workflows activity.


Produce Business Process General Design Documents for each business process defined in the Analyze Phase.

Plan Assembly Test of the approved processes.


Contribute to Business Process General Design Documents.

Review and approve the Business Process General Design Documents.

Version 5.0

8.2.3 Build Phase

8.2.3.1 Detailed Design Documents

Produce Detailed Design documents for the business processes approved during the Analyze Phase.


Produce Detailed Design documents for business processes. Unlike General (functional) Designs, these detailed (technical) designs are intended as technical specifications that can be executed by business process developers and service interface developers.


Contribute to Detailed Design documents for State assigned business processes.

Review and approve each of the business process Detailed Design Documents.

8.2.3.2 Build and Component Test

The Avenues Project Team shall code and unit test business processes approved in the Analyze Phase.


Create Assembly and System Test Scripts.

Code and unit test business processes.

Conduct and document unit testing as part of the development documentation.


Review and approve the code, unit test-scripts and unit test results developed by Contractor.

Code and unit test business processes.

8.2.4 Test Phase

See Section 7 of the K-MED SOW.

8.2.5 Deploy Phase

The Avenues Project Team shall deploy the business processes approved in the Analyze Phase.


Deploy business processes documented through analyze/design and build activities

Version 5.0

Monitor the Deployment Readiness Checklist to prepare for business process deployment


Review Readiness Checklist and attend go/no-go decision meetings.

Version 5.0


The table below summarizes the responsibilities.

Workflow Contractor SRS TeamAnalyze Phase

Analyze Business Process Requirements Lead Assist

Coordinate Interaction with Business Process SMEs Assist Lead

Define Business Process Strategy Lead Assist

Confirm Business Process Inventories Lead Assist


Design Phase

Design Business Processes Lead Assist

Plan Assembly Test Lead Assist

Complete detailed design documents Lead Assist

Build Phase

Build and Unit Test Processes Lead Assist


Test Phase

Execute Assembly Test Lead Assist

Execute Product Test Lead Assist

Version 5.0


The table below summarizes the Business Process and workflow work products to be created during each phase:

Ref. No.

Phase

Deliverable Name

Work Product

Description

NA Workflow Processing Scope

The inventory of in-scope, confirmed Avenues requirements for workflow processing will be included in the Workflow Processing Scope.

29 Detailed System Design

The BPM and workflow designs for Avenues. These designs will include data inputs, system and human actors, service level agreements (if applicable), skeleton process flow diagrams, alerts and notifications, data outputs, and other desired outcomes for each workflow.

The Detailed System Design documents will provide technical detail to solve the workflow- and business process-related requirements.

NA Application Code and Unit Test

Test scripts that test every aspect of the discrete unit, in this case each business process or workflow. Coverage is focused on the individual process behaving in a technically desirable manner. This includes human actors having the correct access and ability to interact with the process and the process behaving as designed in the Detailed Design documents.

NA Integration Test Results

Test scripts that test integration with related systems. Coverage is focused on testing every system interface for the specific business process to validate that the assembly passes data as intended in the Detailed Design documents.

NA System Test Results

Test scripts that test each assembled business process as part of the system as a whole. Coverage will focus on the business process and its integrated system actors delivering the business outcomes outlined in the Detailed Design documents, and, in turn, the Requirements Matrix for traceability.

Version 5.0

9.0 Interfaces

The Accenture team shall be responsible for design, configuration, testing and deployment of all (inbound and outbound) system interfaces identified in section 6.1 below. These responsibilities are inclusive of requirements validation, functional design, technical design, build and unit test, and system test.

The State shall provide an interface Lead to assist the Accenture team with interface activities. The state interface Lead shall be responsible for establishing Interface Partner Agreement (IPA) and coordinating interfacing activities with all state and federal agencies. State agencies receiving data via interfaces from SRS shall be responsible for: 1) mapping data elements from SRS interface layout(s) to their systems, 2) developing programs to receive and insert SRS data into their agency system(s), 3) testing interface(s) and 4) participating in deployment. State agencies will be provided specified timeframes to perform activities identified above.


Section 1.1 defines the interfaces that are in scope for the SRS – Avenues projects. Section 1.2 identifies the interfaces that have been reviewed by both SRS and Accenture and have determined are not in scope for the SRS – Avenues projects. During the negotiating period Accenture compared the list of Interfaces that we removed and added, delta was used to cover the contingency of interfaces that may not have been identified at the time of the SOW writing. A total of 6 interfaces, which have been mutually agreed to by both SRS and Accenture, can be added to the Interface Team scope. Any additional interfaces (i.e., more than 6) will need to be approved through the projects Change Control Process.

Table 4 - Contingency of InterfacesComplexit

yComplexity Level Description Number of

InterfacesHours

Simple Simple Mapping with Simple Adapter 2 Less than 60 hours/each

Average Average Mapping with Average Adapter 1 60 - 100 hours/each

Complex Complex Mapping with a Complex Adapter 2 Greater than 100 hours

Total 5

Version 5.0

9.1.1 Interfaces In Scope

The following 17 interfaces are included in the K-MED solution and will be extended or reused to meet the SRS Avenues requirements:

Table 5- Interfaces in Scope that are Included in K-MEDInterfaces

Referrals to Child Support Enforcement

Child Support Alerts – Including Non-Cooperation

Child Support Income Information

Person & Program Involvement

Base Wage and Unemployment Benefit Information

Treasury Offset program

High Level Client Index

SDX – Supplemental Security Income State Data Exchange

BENDEX – Beneficiary Earnings Data Exchange

SVES – State Verification Exchange

Death Records

Inmate Information

BC/BS Premium Information

Interstate Match

Veterans Administration (VA) Match

Federal Match

Electronic Access to Social Security (EATSS) ** The following Interfaces are In-Scope for K-MED. These interfaces will need to be shared/extended with SRS:

Daily SDX – SSI State Data Exchange Interface with: EATSS & KAECSES-AE, SSA system

Monthly BENDEX – Beneficiary Earnings Data Exchange Interface with: EATSS & KAECSES-AE, SSA system

Daily BENDEX – Beneficiary Earnings Data Exchange Interface with: EATSS & KAECSES-AE, SSA system

Daily SVES – State Verification Exchange (Wire Third Party Query) Interface with: EATSS & KAECSES-AE, SSA system

Daily SVES – State Verification Exchange (Wire Third Party Query) Interface with: EATSS & KAECSES-AE, SSA system

Daily Qualifying Work Quarters (Sent to SSA through SVES) Interface with: EATSS & KAECSES-AE, SSA system

Daily Qualifying Work Quarters (Sent to SSA through SVES) Interface with: EATSS & KAECSES-AE, SSA system

Daily CHIPRA (CHIP Citizenship) SVES Requests – Not Active at this time Interface with: EATSS & KAECSES-AE, SSA system

The following 8 interfaces are similar to existing interfaces in the APSP Benefits System. These similar interfaces will be configured or modified to meet the SRS Avenues requirements:

Table 6- Interfaces that exists with the APSP solutionInterfaces

Child Care Provider Information

Version 5.0

Interfaces

EBT Issuance

Client Benefit Information & Warrant Numbers

Overpayment and Kansas Revenue Tax Data

Client Status Changes

Wage Information (BEERS)

TANF High Performance

Free and Reduced School Lunch

Version 5.0

The following 17 interfaces are new and will be created to meet the SRS Avenues requirements:

Table 7- New InterfacesInterfaces

Kansas Job Link – Public Assistance Recipient, Rehabilitation Services Recipient, and Child Care Payment Information

Foster Care Issuance

Low Income Energy Assistance Program (LIEAP) Interface

Juvenile Justice Authority (JJA) Reports

Sedgwick County Sheriff’s Department – Fugitive Felon Information

Shawnee County Sheriff’s Department – Fugitive Felon Information

Lifeline Auto Enrollment

Adoption Subsidy

SCRIPTS

Background Checks

ACF800 (CCDF Child Care Report)

KHPOP

DIFSLA Match

KPERS

The Work Number

SAVE

ACF801 (Child Care Monthly Report)

9.1.2 Interfaces Not In Scope

The following 21 interfaces were either (1) desired but not required by SRS staff or (2) are no longer active SRS interfaces. These interfaces are not in scope for the Interface work effort:

Table 8- Interfaces that are Not In ScopeInterfaces Notes

Client Address Changes – Although an active exchange, all alerts from this information are currently suppressed.

Defense Enrollment Eligibility Reporting System (DEERS) Currently not an active match.

This is a K-MED Interface; however, it is NOT identified as an Interface that is In-Scope.

Kansas Department of Health and Environment – Client Identification Number Exchange

This is a K-MED Interface; however, it is NOT identified as an Interface that is In-Scope.

EVES – SSN Verification with Social Security Administration. At this time, EVES is not used and this information is exchanged through SVES.

VRV Online

Wage, Employer, & Unemployment Benefit Information

Driver’s License & Vehicle Registration

Level of Care Information This is a K-MED Interface; however, it is NOT identified as an Interface that is In-Scope. It is identified as a K-MED Report

Version 5.0

Interfaces Notes

(MR-36 - LIVING ARRANGEMENT/LEVEL OF CARE OF NON INDEPENDENT LIVING MEMBERS BY PROGRAM AND AGE GROUP)

Missouri Client and Benefit Information

Food Stamp Fraud Disqualification Data

EBT- PC Admin. Terminal

EBT – Web Portal

Automated Standard Application for Payments (ASAP)

Account Management Agent (AMA)

KDHE – WebIZ This is a K-MED Interface; however, it is NOT identified as an Interface that is In-Scope.

Enterprise Access System (EAS)

Case Management System This is a K-MED Interface; however, it is NOT identified as an Interface that is In-Scope.

On-Line application

KHPA Website This is a K-MED Interface; however, it is NOT identified as an Interface that is In-Scope.

KDHE - CLARIS This is a CAPP Interface; however, it is NOT identified as an Interface that is In-Scope.

Food Programs Reporting System (FPRS)


9.2.1 Analyze Phase

At the completion of the Analysis Phase, designated State staff will sign off on the Interfaces that will be included in Avenues. Every interface identified will be documented and defined. During the Design Phase, developers will create detailed requirements and technical specifications explaining how they will build the functionality documented in the Interfaces General Design.


Conduct meetings with agency system SMEs to identify interface requirements.

For the interfaces that are listed above, document the high-level requirements for each inbound and outbound interface as input into an Interfaces Design document. This work product shall define: 1) the purpose of the interface, 2) source and target systems, 3) real-time or batch processing and 4) volume and frequency and 5) method for validating successful transmission.

Support SRS agency interface resources in documenting the coordination efforts related to the high-level requirements for each Interface Partner. Requirements should include direction (to/from SRS),

Version 5.0

frequency, volume of transactions, and user roles affected. The result will be Interface Partner Agreements with all State agencies sending or receiving data via interfaces with SRS

Determine transaction volumes and interface frequency and processing mode and architecture.

Leads in the development of high-level test conditions and expected results for each interface.

Define error handling procedures.

Define interface security protocols and standards and how these will be implemented.


Define/verify the schedule for interface activities and adjust the project plan accordingly.


Approve the in-scope interface inventory and all changes to the interface inventory.

Provide interface Lead and access to agency business and technical resources.

Assist in the development of high-level test conditions and expected results for each interface.

Review and approve the deliverable(s) from this phase.

9.2.2 Design Phase

The Design phase shall build upon the requirements and specifications from the Analyze phase. It shall result in a list of tasks that, once performed in the construction (or build) phase, will deliver the functioning, unit tested interfaces.

Detailed designs will be created for each interface. The designs include data elements and data mapping for each interface into and out of SRS.


Produce detailed technical design documents for exchange of SRS data; These detailed (technical) designs are technical specifications that can be executed by interface configuration SMEs and developers.

Define the testing approach for each interface.

For interfaces that will be used to populate data into the SRS application, a data map document shall be created. The data map document will include the identification of the source system and each field, the target system and each field and the rules to convert or transform the data.

Version 5.0

Determine how the system will be configured to create/send and receive/process interface files/messages to and from other systems.

Develop interface layouts and transmission modes for each interface.

Further define error handling procedures for each interface.

Participate in regular meetings with state agencies to discuss interface activities, responsibilities and timelines.

Participate in conference calls (related to interfaces) with federal partners.


Assist Accenture with interface design activities by providing business owner input.

Lead monthly meetings with state agencies to discuss interface activities, responsibilities and timelines.

Lead conference calls with federal partners.

Review and approve design documents.

Present detailed design information to agencies.

9.2.3 Build Phase

The Interface Development Team will use the detailed technical design documents (created in the Design Phase) to code the Interface identified in the Interfaces General Design. The detailed technical design documents will be input into the Application Development phase, defining the scope of the efforts for that phase.


Build and unit test delivered interfaces.

Build and unit test new interfaces.

Create unit test procedures and scripts.

Conduct and document unit testing and report test results.

Compile appropriate technical documentation for each interface.


Review and approve the code, unit test-scripts and unit test results developed by Accenture.

Version 5.0

9.2.4 Test Phase

See Section 7 of the K-MED SOW.

9.2.5 Deploy Phase

The Deploy phase shall deploy the necessary interfaces as defined in the requirements and specifications from the Analyze phase.


Deploy interfaces as documented through design and build activities

Monitor the Deployment Readiness Checklist to prepare for SRS Deployment



9.3 Responsibilities

The table below summarizes the responsibilities for the Accenture, SRS and state agencies.

Interfaces Accenture SRS AgencyAgency Interfaces

Identify required interfaces Lead Assist Assist

Develop interfaces, documentation and security Lead Assist Assist

Identify interface requirements type of interface/frequency/data elements

Lead Assist Assist

Create data mapping Lead Review Lead (for agency)

Hold “workshops” for agencies Assist Lead Attend

Build interface testing environment Lead

Provide technical assistance for agencies developing interfaces Lead Assist

Develop interface validation procedures for source/receiving systems

Assist/Lead Assist Lead (for agency)

Develop interface testing plans Lead Assist Lead (for agency)

Code and test interfaces Lead Lead

Develop reports/queries for validation Lead Assist Assist

Develop and maintain master list of all interfaces Lead Assist

Determine interface schedule requirements and document Lead Assist

Performance test all interfaces Lead

Develop technical documentation for each interface Lead Assist

Version 5.0

9.4 Other Interface Considerations

Addition or subtraction of interfaces shall follow the agreed-upon change control process. For a listing of interfaces defined as Not In Scope please see section 1.2.

9.5 Deliverables

The table below summarizes the interface deliverables to be created during each phase. Payment for deliverables shall be as agreed to on the Deliverable Payment Schedule.

Ref. No. Phase Deliverable Name Description9 Phase 2 Interface Plan The Interface Plan deliverable will define the contractors approach

to the Design and Build of the Interfaces that are identified as In-Scope for the SRS Avenues project.

29 Phase 2 Detailed System Design (DSD)

Interface detailed (technical) designs are technical specifications that can be executed by interface configuration SMEs and developers.

11 Phase 2 Interface Standards and Layouts (for Agencies and Business Partners)

Interface Standards and Layouts document will serve as the accepted file formats that SRS Agencies and Business Partners will need to agree to in order to send and receive files after the implementation of the SRS – Avenues solution.

Version 5.0

10.0 Data Conversion

The SRS Avenues Data Conversion Team will be responsible for the extraction, mapping, data cleansing, transformation, mock conversions, data validation and acceptance, and loading of data from the source systems into Avenues.

The SRS Avenues Data Conversion Team will be comprised of representatives from the Contractor and SRS and its legacy system teams.


The following conversion source systems are in scope. A conversion is defined as a file or database tables that needs to be converted from one source to another

Conversion Source Conversion*

KAECSES-AE TANF: 14,380 Cases – 36,972 Total People

General Assistance: 2,371 Cases – 2,394 People

Food Assistance: 117,752 Cases – 259,609 People

Refugee Assistance: 47 Cases – 52 People

CFS Payments are approximately 16,000 Cases

KsCares Child Care – 10,741 Cases - 20,319 Children

TANF Employment Services: 12,510 People

Food Assistance E&T: 157 People

LIEAP** TBD during Analyze Phase of SRS – Avenues project

Grand Total

* Case and Persons counts have been taking from the RFP and only represent estimates.** The LIEAP system will be implemented in Phase 3 of the SRS – Avenues project.


10.2.1 Analyze Phase

10.2.1.1 Conversion Analysis

The purpose of the analysis effort is to identify and analyze the sources of data to be converted. The conversion team develops an inventory of existing data formats, data mapping, and data conversion requirements of the legacy systems to define the scope of the SRS - Avenues Project conversion effort. The analysis effort primarily focuses on analyzing the following:

1. SRS Data Sources’ Technical environments

2. Physical characteristics of the data processed and maintained

3. Commonality and relationships among the case management data elements

Version 5.0

4. Overall stability, accessibility and the process for maintaining the data

5. Level of data quality

6. Potential extraction point in time and or business processes for each system


Conduct meetings with central and SRS SMEs to identify conversion requirements.

Lead Data Quality Assessment supported by SRS SMEs.

Perform Gap Analysis to identify gaps between the data available in the legacy systems in comparison with the data requirements of the Avenues System.

Perform analysis of the data from the various legacy systems to determine which data should be converted from which system.

Development of Conversion Plan..

Develop high level test conditions and expected results.



Provide Subject Matter Experts (SMEs) for each system that requires conversion.

Provide SME support in the Data Quality Assessment. SMEs play a critical role in confirming how the source data supports the current business process.

Assist in the development of high-level test conditions and expected results for each central and agency system that requires data conversion. SRS will take responsibility for the portions of these tests that deal with the legacy systems.

Review and approve the Gap Analysis. This is an important activity since it serves as input in how SRS will extract data in the standard conversion templates. The SRS will take responsibility for all modifications to existing SRS systems.



Version 5.0

10.2.2 Design Phase

The defined requirements and the analysis performed to-date drives the conversion design specifications of the data cleansing, extract, transformation, and load modules. The conversion Detailed Design Documents will:

1. Confirm that the data elements (automated or manual) are included in the Conversion Data Dictionary.

2. Refine the initial Gap Analysis and document processes to address each data gap.

3. Define Detailed Source to Target Data Maps and translation rules.

4. Confirm that the historical data elements are accounted for in the new system.

5. Confirm modules are reused where possible.

6. Confirm validation of data relationships from disparate data sources.

7. Baseline the control totals in order to measure the completeness of the conversion modules.

8. Confirm data cleansing processes.


Provide Conversion Data Dictionary and lead mapping of legacy data elements to Avenues source element.

Collect transaction and balance volumes to be used in planning the Mock Conversion Test.

Lead design of automatic conversion routines. Existing conversion routines are configured for loading of data into Avenues.

Design Manual Data acquisition processes with support from SRS SMEs.

Produce Detailed Design Documents for data upload work units.

Review State developed Detailed Design Documents for legacy conversion work units.


Evaluate the source data for conversion. Document its structure and schedule availability for conversion activities. Ensure that it has been cleansed in time for the conversion process.

Assist the Contractor with the development of the Design Documents.

Version 5.0

Develop the extract specifications and file specifications for the legacy system from which data will be extracted to load into APSP standard conversion templates.

Approve the data-maps including default logic in the data mapping documents, and may approve the rules to convert or transform the data.

Review and approve each of the Detailed Design Documents.

Develop Detailed Design Documents for legacy extracts.

10.2.3 Build Phase

10.2.3.1 Build and Component Test:

The SRS – Avenues Data Conversion Team shall code and unit test modifications.


Develop/modify data upload routines.

Develop/modify test conversion reports.

Configure APSP delivered data upload and extract routines.

Create unit test-scripts.



Code and component test the extract and reconciliation files and reports from the legacy systems.

Review and approve the unit test-scripts and unit test results developed by Contractor.

10.2.4 Test Phase

See Section 7 of the K-MED SOW

10.2.5 Deploy Phase

10.2.5.1 Mock Conversions:

The SRS Avenues Data Conversion Team will execute a minimum of three Mock Conversions. The goal of the mock conversions will be to verify that the delivered conversion templates can be used to load information for the integration testing and subsequent go live. If additional conversion modifications are identified during the Analyze Phase, these conversion routines will also be included in the Mock Conversion Testing.

Version 5.0


Coordinate, advise and support the State in their data cleansing activities.

Prepare a schedule of mock conversion activities that outlines the tasks and timeframes for the mock conversions.

Execute mock conversions. A mock conversion is an iterative process of executing conversions, performing validation and verification and correcting conversion programs that are built by the project team until the data is sufficiently usable for Integration Testing.

Support SRS as it executes data cleaning by identifying data to be “cleansed” and providing recommendations on data clean-up approaches. Validation and reconciliation report(s) will be created as part of each scheduled mock conversion that documents data discrepancies. The reports shall also include summary count information that SRS can use to help measure its progress related to data cleansing.

Prepare a mock conversion results document after each mock conversion, which summarizes the results of that conversion execution and the action items for both Contractor and the SRS in light of those results.

Provide overall input into the Go-Live cutover plan for Conversion.


Correct all System Investigation Requests (“SIRs”) for extract programs that arise from mock conversions.

Complete the data cleansing and purification of data contained in the legacy systems as required to support the data conversions, including if necessary manually or programmatically correcting the data.

Produce the source data files required to support each mock conversion. Such files will comply with the extract and file specifications.

Verify and validate the results of the mock conversions.

Review and approve the mock conversion results document including delineation of responsibilities for actions resulting from the mock conversions.

Decommission in scope Legacy Systems.

10.2.5.2 Cutover:

The SRS – Avenues Conversion team will execute all of the cutover activities defined in the Cutover Plan. This Cutover Plan will define the dependency and successor activities necessary to successfully convert data from the KAECSES-AE, KsCares, and LIEAP legacy sources into the SRS – Avenues solution.

Version 5.0


Execute the Go-Live cutover plan for Conversion activities.


Produce the source data files required to support Phase 2 Go-Live. Such files will comply with the extract and file specifications.



Scope Element Contractor SRS TeamCreate conversion plans and procedures Lead Assist

Create data conversion and migration maps and specifications Lead Assist

Create conversion extract programs Lead

Create data cleansing plan Assist Lead

Perform legacy data cleansing Lead

Create data loading scripts (including table load sequencing) Lead Assist

Develop data load validation reports/queries Lead Assist

Load agency cleansed data Lead

Run reports/queries in APSP/Avenues to validate data conversion Lead Assist

Build crosswalk tables as required Lead Assist

Populate crosswalk tables Lead

Conversion Cutover Testing Lead Assist

Develop cutover plan Lead Assist

Run two successful test conversions for all data to be loaded Lead Assist

Version 5.0

10.4 Deliverables

The table below summarizes the data conversion deliverables/work products to be created during each phase:

Ref. No.

Phase Deliverable/Work Product Name

Description

14

Analyze Conversion Plan The Eligibility Data Conversion Plan documents the requirements, manual and automatic procedures, and programs needed to extract data from the current applications. Existing data is formatted and cleansed prior to loading it into the new application. The plan will include itemized tasks, required resources, conversion strategy and required certification.

NA Design Conversion Data Dictionary

(work product – not a paid deliverable)

The Conversion Data Dictionary (CDD) identifies and documents (in one repository) the SRS target data elements from the base APSP software. It is updated with mappings from the source data.

NA Design Data Conversion Design


The Data Conversion Design defines the manual and automatic procedures and programs needed to extract data from the current applications, cleanse it, and load it into the new application. Coordination with all involved parties, conversion timeline and possible issues and risks will be specified. Conversion tools and infrastructure requirements will be also be included.

NA Build Data Conversion Build/Unit Test


This deliverable is the conversion of data in a test environment. Data will be processed via the conversion process to format it to the standards of the new system. Conversion loads and manual updates are executed prior to data validation.

32

Test System Test Plan The System Test Plan will include a Conversion Test Plan that documents the requirements needed to test Avenues requirements with converted data in an effort to deliver the required business functionality to the SRS users.

25

Deploy Data Conversion Dry Run Working in collaboration with SRS personnel, this deliverable will document the results of the final mock conversion. Each mock conversion will be executed in a production-size environment to simulate the actual cutover event, including schedule, resources and production data, and timings to best predict the length of time the conversion cutover will take.

Version 5.0

11.0 Business Intelligence Services and Reporting

The SRS Business Intelligence Services and Reporting team will be responsible for the design, configuration, testing, and deployment of reports as defined in the SRS scope. These tasks will include requirements validation, functional design, technical design, build and unit test, and system testing of the reports counts described in Section 11.1 Scope Definition. In addition, the team will leverage the Business Intelligence Services implemented for K-MED to support more advanced reporting features not achievable from the transactional application database like dashboards, drillable reports, and longitudinal analysis.


The reports scope includes development of the 58 (fifty eight) undefined report complexities listed below in the reporting tool library. During the Analyze phase of the Avenues project SRS staff will have the opportunity to review reports that come with the system and determine which, if any, could (1) be modified as part of the reports scope/development effort., or (2) configured in an effort to make the report titles and headings specific to Kansas (i.e., SRS). Reports that require modifications would count against the 58 undefined reports; whereas, reports that are configured would not.

The following reports complexities are in scope. During the Analysis Phase, the report inventory will be defined and confirmed.

Complexity Examples Report CountSimple A report containing one detailed list with

no summary section. Totals may be included after the section.

17

Medium A report containing a summary and detail listing on the same report layout. The details may be broken into sections on a single grouping (example by Worker or by Program). Totals are included after each section, with the possibility of a grand total at the end.

34

Complex The same criteria as medium, except there could be many groupings/sections included on the report. An example of this is a report which breaks down by Recovery Account Type, and further subdivides by status, aid code, benefit month, etc.

7

Version 5.0

Major Activities by Project Phases

11.2 Major Activities by System Development Methodology Phase


11.2.1.1 Analyze Reports

The SRS Business Intelligence Services and Reporting team will work closely with the SRS Business Analysis team to define, validate, and confirm SRS reporting requirements. This serves to refine the requirements of the reports in scope. This step also includes defining strategy for use of the different reporting capabilities of SRS, and will describe the strategy for using the reporting database or Business Intelligence Services for reporting purposes. The reporting database is a copy of the Online Transactional Processing (OLTP) database which is used for canned reports and ad-hoc queries. The Business Intelligence Services provides a flattened data model to expand reporting capabilities which cannot be addressed in the OLTP data structure.


Attend meetings with State Functional SMEs to validate and elaborate reporting requirements.

Define the types of reports and the purpose for the reporting and online analytical tools.

Document high-level requirements for each report. Requirements should include intended use, frequency, and volume of transactions.

Identify and document the roles for each report.




Provide Subject Matter Experts (SMEs) for each functional area that can efficiently and accurately define/describe required reporting requirements.

Review and approve the report inventory.

Review and approve documentation of high-level reporting requirements for each functional area.

Review and approve high-level test conditions and expected results for each report.


Version 5.0


11.2.2 Design Phase

The Design Phase begins with specifications from the Analyze Phase, and ends with a list of tasks that, once performed in Build, will deliver the future state solution.

11.2.2.1 General Design Documents:

General designs will be created for each reporting work unit that was approved at the end of the Analyze Reports activity.


Produce General Design Documents for work units identified in the State-approved Reports inventory. General designs will be documented in a format which can be used in user manuals, system documentation and training materials.

Plan Assembly Test of the approved reports.


Review and approve the General Designs.


Produce Detailed Design documents for the reporting work units approved during the Analyze Phase.


Produce Detailed Design documents for Reporting work units. Unlike General (functional) Designs, these detailed (technical) designs are intended as technical specifications that can be executed by report developers.


Review and approve each of the Detailed Design Documents.

11.2.3 Build Phase


The Reporting Team shall code and unit test reports approved in the Analyze Phase.


Leads in the coding of reports assigned to the Contractor.

Version 5.0

Leads in the creation of unit test scripts.

Leads in the documentation of unit testing as part of the development documentation.


Assists in the coding of reports assigned to the Contractor.

Assists in the creation of unit test scripts.

Review and approve unit test-scripts and unit test results developed by Contractor.

Assists in the documentation of unit testing as part of the development documentation.

11.2.4 Test Phase

Section 7 of the K-MED SOW

11.2.5 Deploy Phase

The Deploy phase shall deploy the necessary reports as defined in the requirements and specifications from the Analyze phase.


Deploy reports as documented through design and build activities




Version 5.0



Business Intelligence Services and Reporting Contractor SRS TeamAnalyze Phase

Analyze Reporting Requirements Lead Assist

Define Reporting Strategy Lead Assist

Define Report Inventories Lead Assist and Approve


Design Phase

Design Reports Lead Assist and Approve


Build Phase

Build and Unit Test Reporting Components Lead Assist and Approve


Test Phase

Execute Assembly Test Lead Assist

Execute Product Test Lead Assist

11.4 Other Requirements

11.4.1 Scope of the Business Intelligence Services

The SRS Business Intelligence Services will leverage the Warehouse Architecture and Warehouse Report Development scope from the K-MED implementation.

The Incremental SRS Business Intelligence Services requirements include adding 17 (seventeen) extracts that are added as an Extract, Transform, and Load (ETL) to the Business Intelligence Services.


The table below summarizes the Business Intelligence Services and Reporting work products and deliverables to be created during each phase:

Ref. No. Phase Deliverable Name Description10 Analyze Reports Plan The Reports Plan is the primary deliverable resulting from the Analyze Phase. The

Reports Plan consists of the report inventory and high level requirements defining data source, intended use, frequency.

29 Design Detailed System Design

For each report a General and Detailed Design is completed. The designs for each report include the following: report layout, parameters, data access logic.

Version 5.0

12.0 Automated Forms and Notices

The Avenues Automated Forms and Notices team is a sub-team of the development team. They work closely with the business analysts and will primarily be responsible for the conference room pilot, configuration, and testing of automated forms and notices as defined in the SRS Avenues scope. Their tasks will include requirements validation, mapping current APSP Notice of Action (NOA) snippets, forms, and notices to SRS Avenues forms and notices during conference room pilot. Then they configure and build forms and notices, execute unit test, and provide system testing support. This team includes resources from the SRS and the Contractor who work collaboratively to develop the forms and notices. The Contractor provides technical support in using the Adobe LiveCycle tool and the development of the forms and notices. This includes use of the Adobe LiveCycle tool, identifying database mapping to dynamically populate the forms and notices in accordance with requirements, and integration with other elements of the SRS Avenues application, such as the rules engine to populate Notice of Actions (if required). SRS will provide forms analysts/developers to assist in the development and testing of the forms and notices. This includes the provision of static content and text snippets that are dynamically pulled together through Adobe LiveCycle to create forms and notices. SRS staff are also responsible for the translation of text on forms in Non-English languages.

The SRS Automated Forms and Notices Statement of Work (SOW) will reference the K-MED Automated Forms and Notices SOW as the SRS Avenues solution will be designed, built, tested, and implemented leveraging the technical infrastructure, methodologies, business processes, designs, and development phase activities that are defined in the K-MED Automated Forms and Notices SOW. There are, however, two differences between the K-MED and SRS Automated Forms and Notices solutions:

The Forms and Notices listed in section 12.1 Scope Definition are specific to the SRS programs and business processes and not other agencies.

Not only will dedicated SRS staff, assigned to the Forms and Notices team, be expected to provide (1) the static content and text snippets, and (2) the translation of text on forms in Non-English languages, they will also be responsible for the development of approx. 25% of the Forms and Notices listed in the section X.1 Scope Definition

Version 5.0


The scope for automated forms and notices include the forms and notices listed in the table below. The following are assumed related to the scoping of Automated Forms and Notices.

Table 9 - Estimating AssumptionsComplexity Definition % Hours Estimated per Form/NoticeSimple A static form that requires no data populations and is

static. This is a form that is available via the K-MED application and is mailed out

40% Between 8 and 20 hours each

Medium Form with 1- 5 fields populated with no complex calculations or interaction/content generated by the rules engine or a complex static form


Complex A complex form is one that includes either one or more complex calculation, interaction with the rules engine, or more than 5 fields populated. It also would include multiple snippets.


Table 10 - List of Forms and NoticesProgram Form Type Form # Form Title

KsCares

KsCares Child Care Client C102 Reporting Requirements - Child Care

KsCares Child Care Client C103 Enrollment Fee Request Form

KsCares Child Care Client C104 Enrollment Fee Approval - Denial

KsCares Child Care Client C105 Change in SRS Service Center

KsCares Child Care Client C106 CC Approval Existing Card

KsCares Child Care Client C107 Vision Card - Important Notice (CC)

KsCares Child Care Client C108 EBT CC Training

KsCares Child Care Client C109 Provider Information Request

KsCares Child Care Client C110 Child Care Benefits Balance

KsCares Child Care Client C112 Claim Balance Change - Paid with EBT Benefits

KsCares Child Care Client C120 CC Approval - Remote PIN

KsCares Child Care Client C201 Incomplete Application Notice

KsCares Child Care Client C202 Eligibility Notice

KsCares Child Care Client C204 Ineligibility Notice

KsCares Child Care Client C205 General Verification Request

KsCares Child Care Client C302 Incomplete Review Notice

KsCares Child Care Client C303 Overdue Case Review Notice

KsCares Child Care Client C304 Review Eligibility Notice

KsCares Child Care Client C305 Review Ineligibility Notice

KsCares Child Care Client C306 CC Plan - Case Review Notice

KsCares Child Care Client C401 Change Notice

KsCares Child Care Client C402 Information Received Notice

KsCares Child Care Client C403 Case Transfer Notice

Version 5.0

Program Form Type Form # Form TitleKsCares Child Care Client C404 Mass Case Transfer

KsCares Child Care Client C502 Termination Notice

KsCares Child Care Client C806 Child Care - Additional Benefits

KsCares Child Care Client C807 Child Care - Restoration of Benefits

KsCares Child Care Client C810 Child Care Service Plan

KsCares Child Care Client C811 Direct Pay Review Eligibility Notice

KsCares Child Care Client C888 EBT Child Care Parents

KsCares Child Care Client C899 Printer Family Plan - Remail

KsCares Child Care Client C911 Overpayment Claim Initiation - Repayment Agreement

KsCares Child Care Client C912 Overpayment Claim Change - Reduction

KsCares Child Care Client C913 Overpayment Claim Deletion

KsCares Child Care Client C914 Overpayment Claim Addition

KsCares Child Care Client C915 Overpayment Repayment Plan

KsCares Work Programs W001 1st Orientation Letter

KsCares Work Programs W002 2nd Orientation

KsCares Work Programs W006 Appointment Letter

KsCares Work Programs W007 2nd Appointment Letter

KsCares Work Programs W101 Education Activity Letter

KsCares Work Programs W102 Training/Vocational Education Activity Letter

KsCares Work Programs W103 Training/Vocational Education Approval - Denial

KsCares Work Programs W104 Participation Review Request

KsCares Work Programs W106 Non-attendance Notice

KsCares Work Programs W107 General Correspondence

KsCares Work Programs W108 Notice Of Taf Months/Schedule Review

KsCares Work Programs W201 Work Experience Appointment Letter

KsCares Work Programs W202 Work Experience 2nd Appointment

KsCares Work Programs W205 Work Experience Assignment Letter

KsCares Work Programs W206 Work Experience Evaluation

KsCares Work Programs W207 Orientation to the World of Work Letter

KsCares Work Programs W251 Life Skills Letter

KsCares Work Programs W351 Job Search Letter

KsCares Work Programs W353 Job Search Verification

KsCares Work Programs W354 Job Contact Disallowance

KsCares Work Programs W355 Job Club Letter

KsCares Work Programs W402 Employment Letter

KsCares Work Programs W404 Transitional Service Expiration

KsCares Work Programs W405 Employment Follow-up

KsCares Work Programs W407 Transitional Service Offer

KsCares Work Programs W451 Self-sufficiency Plan Review 1st Letter

KsCares Work Programs W452 Self-sufficiency Plan Review 2nd Letter

KsCares Work Programs W454 Kansas Competency Assessment Letter

KsCares Work Programs W455 Referral Letter

Version 5.0

Program Form Type Form # Form TitleKsCares Work Programs W501 Notice of Change

KsCares Work Programs W502 Notice of Closure

KsCares Work Programs W503 1st Request for Information

KsCares Work Programs W504 2nd Request for Information

KsCares Work Programs W506 Repayment - 1st Letter

KsCares Work Programs W507 Repayment - 2nd Letter

KsCares Work Programs W802 Check Enclosed

KsCares Work Programs W806 Work Program Payment

KsCares Work Programs W808 Work Experience Reimbursement Allowance

KsCares Work Programs W888 EBT Mass Notice

KsCares Work Programs W901 Returned Payment

KsCares Work Programs W911 Repayment Agreement

KsCares Work Programs W912 Overpayment Claim Reduction

KsCares Work Programs W913 Overpayment Claim Deletion

KsCares Child Care Provider P101 General Notice

KsCares Child Care Provider P102 Rate Modification Request - CCC

KsCares Child Care Provider P103 Rate Modification Request - Lic - Reg

KsCares Child Care Provider P104 Rate Change Completed - CCC

KsCares Child Care Provider P105 Rate Change Completed - Lic - Reg

KsCares Child Care Provider P201 Denial or Termination Notice

KsCares Child Care Provider P202 Eligibility Notice

KsCares Child Care Provider P304 Review Eligibility Notice

KsCares Child Care Provider P400 Child Care Time Sheet - Local Issue

KsCares Child Care Provider P502 Provider Notice - Case Closed

KsCares Child Care Provider P888 EBT Child Care Notice - Provider

KsCares Child Care Provider P901 Returned Warrant

KsCares Child Care Provider P911 Overpayment Claim Initiation - Repayment Agreement

KsCares Child Care Provider P912 Overpayment Claim Change - Reduction

KsCares Child Care Provider P913 Overpayment Claim Deletion

KsCares Child Care Provider P914 Overpayment Claim Addition

GA Notices

GA Notices Approval Notice G101 GA - APPROVAL FOR ONE MONTH ONLY

GA Notices Approval Notice G104 DENIAL 1ST MONTH APPROVAL FOR 2ND MONTH

GA Notices Approval Notice G105 DENIAL OF 1ST MO, APPROVAL OF 2ND & 3RD

GA Notices Approval Notice G106 GA REVIEW COMPLETE

GA Notices Approval Notice G107 GARN APPROVAL

GA Notices Approval Notice G113 GA HARDSHIP APPROVAL FOR AGE OR GARN

GA Notices Approval Notice G114 GA-TIER I HARDSHIP APPROVAL

GA Notices Approval Notice G115 GA HARDSHIP APPROVAL - VR

GA Notices Approval Notice G191 GA & FS APPROVAL FOR ONE MONTH ONLY

GA Notices Approval Notice G192 GA AND FS APPROVAL FOR 1ST AND 2ND MONTH

GA Notices Approval Notice G193 GA/FS APPROVAL 1ST, 2ND, & 3RD MONTHS

Version 5.0

Program Form Type Form # Form TitleGA Notices Approval Notice G196 GA & FS REVIEWS COMPLETE

GA Notices Denial Notice G200 GA - FAILURE TO PROVIDE INFORMATION

GA Notices Denial Notice G201 GA - FAILURE TO COOPERATE

GA Notices Denial Notice G202 RESIDENCY REQUIREMENT NOT MET

GA Notices Denial Notice G203 GA - LOSS OF CONTACT

GA Notices Denial Notice G204 TO THE FAMILY OF THE DECEASED

GA Notices Denial Notice G205 GA - INCOME EXCEEDS MAXIMUM

GA Notices Denial Notice G207 GA - RESOURCES EXCEED MAXIMUM

GA Notices Denial Notice G208 GA DENIAL - OTHER REASONS

GA Notices Denial Notice G209 GA - APPLICATION WITHDRAWN

GA Notices Denial Notice G210 GA - INELIGIBLE ASSISTANCE UNIT

GA Notices Denial Notice G211 GA - CITIZENSHIP/ALIEN STATUS

GA Notices Denial Notice G212 GA DENIAL - 24 MONTH TIME LIMIT

GA Notices Denial Notice G214 FAILURE TO MEET VULNERABILITY CRITERIA

GA Notices Denial Notice G220 GA DENIAL - NON COOP WITH PMDT

GA Notices Denial Notice G221 G221 GA DENIAL NON-COOP POST 45 DAYS

GA Notices Denial Notice G240 GA - FAILURE TO APPLY FOR POTENTIAL BEN.

GA Notices Denial Notice G290 GA & FS DENIAL\FAILURE TO PROVIDE INFO.

GA Notices Denial Notice G291 GA AND FS DENIAL/FAILURE TO COOPERATE

GA Notices Denial Notice G292 GA/FS DENIAL/RESIDENCY REQUIRMNT NOT MET

GA Notices Denial Notice G293 GA & FS DENIAL LOSS OF CONTACT

GA Notices Denial Notice G294 TO THE FAMILY OF THE DECEASED

GA Notices Denial Notice G295 GA & FS DENIAL/INCOME EXCEEDS MAXIMUM

GA Notices Denial Notice G296 GA & FS DENIAL/EXCESS NET INCOME

GA Notices Denial Notice G297 GA AND FS DENIAL/RESOURCES EXCEED MAX.

GA Notices Denial Notice G298 GA AND FS DENIAL/OTHER REASONS

GA Notices Denial Notice G299 GA & FS DENIAL/APPLICATIONS WITHDRAWN

GA Notices Closure Notice G400 GA FAILED TO PROVIDE/VERIFY INFORMATION

GA Notices Closure Notice G401 GA FAILURE TO COOPERATE

GA Notices Closure Notice G402 RESIDENCY REQUIRMENT NOT MET

GA Notices Closure Notice G403 GA-LOSS OF CONTACT

GA Notices Closure Notice G404 TO THE FAMILY OF THE DECEASED

GA Notices Closure Notice G406 CLOSURE EXCESS NET INCOME

GA Notices Closure Notice G407 CLOSURE RESOURCES EXCEED MAXIMUM

GA Notices Closure Notice G408 GA CLOSURE - OTHER REASONS

GA Notices Closure Notice G409 GA - CLOSURE AT CLIENT'S REQUEST

GA Notices Closure Notice G410 GA-INELIGIBLE ASSISTANCE UNIT

GA Notices Closure Notice G411 CLOSURE/NO LONGER GA VULNERABLE

GA Notices Closure Notice G412 GA CLOSURE - 24 MONTH TIME LIMIT

GA Notices Closure Notice G413 GA HARDSHIP CLOSURE

GA Notices Closure Notice G414 GA/MEDIKAN CLOSURE 18 MTH LIMIT -TIER II

GA Notices Closure Notice G417 GA CLOSURE - SSI APPROVAL

Version 5.0

Program Form Type Form # Form TitleGA Notices Closure Notice G420 GA CLOSURE -NON COOP W/PMDT

GA Notices Closure Notice G440 FAILURE TO APPLY FOR POTENTIAL BENEFITS

GA Notices Closure Notice G450 FAILURE TO COMPLETE REVIEW

GA Notices Closure Notice G452 TIME LIMITED PROGRAM - GARN

GA Notices Closure Notice G490 GA & FS CLOSURE-FAILURE TO PROVIDE INFO

GA Notices Closure Notice G492 CLOSURE/RESIDENCY REQUIREMENT NOT MET

GA Notices Closure Notice G493 GA AND FS CLOSURE/LOSS OF CONTACT

GA Notices Closure Notice G494 TO THE FAMILY OF THE DECEASED

GA Notices Closure Notice G496 GA AND FS CLOSURE/EXCESS NET INCOME

GA Notices Closure Notice G497 GA AND FS CLOSURE/EXCESS RESOURCES

GA Notices Closure Notice G498 GA AND FS CLOSURE/OTHER REASONS

GA Notices Closure Notice G499 GA AND FS CLOSURE/CLIENT REQUEST

GA Notices Reinstatement Notice

G600 GA-REINSTATE AFTER SUSPENSION


G601 ERRONEOUS DISCONTINUANCE


G602 BENEFITS PAID PENDING HEARING DECISION

GA Notices Change Notice G701 CHANGE IN BENEFITS - OTHER REASONS

GA Notices Change Notice G702 SUPPLEMENTAL BENEFITS

GA Notices Change Notice G703 CHANGE IN HOUSEHOLD MEMBERS

GA Notices Change Notice G704 GA - CHANGE IN BENEFITS/INCOME CHANGE

GA Notices Change Notice G706 CHANGE IN BENEFITS/LIVING ARRANGEMENTS

GA Notices Change Notice G713 GA CHANGE IN BENEFITS-RECOUPMENT

GA Notices Change Notice G751 GA/FS CHANGE IN HOUSEHOLD MEMBERS

GA Notices Change Notice G753 GA/FS CHANGE IN BENEFITS-RECOUPMENT

GA Notices Misc. Notice G801 CASELOAD TRANSFER

GA Notices Misc. Notice G827 GA FRAUD DISQUALIFICATION - NONRECIPIENT

GA Notices Misc. Notice G828 GA FRAUD DISQUALIFICATION - PERMANENT

GA Notices Misc. Notice G830 GA FRAUD DISQUALIFICATION--RECIPIENT

GA Notices Misc. Notice G831 GA REPAY AGREEMENT - FRAUD - RECIPIENT

GA Notices Misc. Notice G832 GA REPAY AGREE.-AGENCY/CLIENT RECIPIENT

GA Notices Misc. Notice G834 GA-REPAYMENT AGREEMENT-NON RECIPIENT

GA Notices Misc. Notice G850 GA-SOCIAL SECURITY APP NEEDED

GA Notices Misc. Notice G851 GA-SOCIAL SECURITY APP NEEDED

GA Notices Misc. Notice G852 GA-SSA APP NEEDED-NEW CLIENT

GA Notices Misc. Notice G853 GA-SOCIAL SECURITY APP PENDING

GA Notices Misc. Notice G854 GA - TIME LIMIT INFORMATION

FS NOTICES

FS NOTICES Approval Notices F101 FS - APRVL FOR ONE MONTH ONLY

FS NOTICES Approval Notices F102 FS APRVL FOR 1ST & 2ND MONTHS

FS NOTICES Approval Notices 102F APROB. DE FS PARA EL 1ER Y 2DO MES

FS NOTICES Approval Notices F103 FS APPRVL 1ST, 2ND AND 3RD MOS.

Version 5.0

Program Form Type Form # Form TitleFS NOTICES Approval Notices 103F APROB. DE FS PARA EL 1ER, 2DO Y 3ER MES

FS NOTICES Approval Notices F104 FS DENY 1ST MONTH/APPR. 2ND MO.

FS NOTICES Approval Notices F105 FS DENIAL 1ST MO., APPRVL 2/3 MOS

FS NOTICES Approval Notices F106 FS REVIEW COMPLETE

FS NOTICES Approval Notices 106F REVISIÓN DE FS COMPLETA

FS NOTICES Approval Notices F107 FS REVIEW COMPLETE - IR REQUIRED

FS NOTICES Approval Notices 107F FS REVISIÓN COMPLETA - SR REQUISITOS

FS NOTICES Approval Notices F111 FS APRVL FOR ONE MONTH ONLY + IR REQ

FS NOTICES Approval Notices F112 FS APRVL FOR 1ST/2ND MOS + IR REQ

FS NOTICES Approval Notices F113 FS APPRVL 1ST/2ND/3RD MOS. + SR REQ.

FS NOTICES Approval Notices F114 FS DENY 1ST MO./APPR. 2ND MO. + IR. REQ.

FS NOTICES Approval Notices F115 FS DENY 1ST MO./APPR 2/3 MOS + IR REQ.

FS NOTICES Approval Notices F120 FS APPROVAL FOR 1ST/2ND MOS.- REMOTE PIN

FS NOTICES Approval Notices F121 EXPEDITED FS - POSTPONED VERIFICATION

FS NOTICES Approval Notices F130 FS DISASTER ASSISTANCE APPROVED

FS NOTICES Approval Notices F131 FS APRVL FOR ONE MONTH ONLY - NO IR REQ

FS NOTICES Approval Notices F132 FS APRVL FOR 1ST/2ND MOS - NO IR REQ

FS NOTICES Approval Notices F133 FS APPRVL 1ST/2ND/3RD MOS. - NO IR REQ

FS NOTICES Approval Notices F134 FS DENY 1ST MO./APPR. 2ND MO.- NO IR REQ

FS NOTICES Approval Notices F135 FS DENY 1ST MO. APPR 2/3 MOS.- NO IR REQ

FS NOTICES Approval Notices F137 FS REVIEW COMPLETE - NO IR REQUIRED

FS NOTICES Approval Notices F138 FS APPR. 1/2 MOS SI/24 MO REV PER

FS NOTICES Approval Notices F139 FS APPROVAL FOR 1/2 MOS - NO REPORTING REQUIREMENT

FS NOTICES Denial Notices F200 FAILURE TO PROVIDE INFO./REACTIVATE APP.

FS NOTICES Denial Notices F201 FS - FAILURE TO COOPERATE

FS NOTICES Denial Notices F202 RESIDENCY REQUIREMENT NOT MET

FS NOTICES Denial Notices F203 FS - LOSS OF CONTACT

FS NOTICES Denial Notices F205 FS DENIAL-INCOME EXCEEDS STANDARDS

FS NOTICES Denial Notices F207 FS - RESOURCES EXCEED MAXIMUM

FS NOTICES Denial Notices F208 FS DENIAL - OTHER REASONS

FS NOTICES Denial Notices F209 FS - APPLICATION WITHDRAWN

FS NOTICES Denial Notices F210 FS - DOES NOT MEET HOUSEHOLD REQUIREMENT

FS NOTICES Denial Notices F211 FS DENIAL - CITIZENSHIP/ALIEN STATUS

FS NOTICES Denial Notices F216 FS DENIAL - ABAWD REQUIREMENTS NOT MET

FS NOTICES Denial Notices F221 FS STUDENT ELIGIBILITY CRITERIA NOT MET

FS NOTICES Denial Notices F230 FS DISASTER PROGRAM DENIAL

FS NOTICES Closure Notices F400 FAILURE TO PROVIDE OR VERIFY INFORMATION

FS NOTICES Closure Notices F401 FS CLOSURE - FAILURE TO COOPERATE

FS NOTICES Closure Notices F402 FS - RESIDENCY REQUIREMENT NOT MET

FS NOTICES Closure Notices F403 LOSS OF CONTACT

FS NOTICES Closure Notices F404 TO THE FAMILY OF THE DECEASED

Version 5.0

Program Form Type Form # Form TitleFS NOTICES Closure Notices F405 INCOME EXCEEDS STANDARDS

FS NOTICES Closure Notices F407 FS - RESOURCES EXCEED MAXIMUM

FS NOTICES Closure Notices F408 FS CLOSURE - OTHER REASONS

FS NOTICES Closure Notices F409 FS - CLOSURE AT CLIENT REQUEST

FS NOTICES Closure Notices F410 NO LONGER MEETS HOUSEHOLD REQUIREMENT

FS NOTICES Closure Notices F412 FS CLOSURE - WORK PENALTY

FS NOTICES Closure Notices F416 FS CLOSURE - ABAWD REQUIREMENTS NOT MET

FS NOTICES Closure Notices F421 FS STUDENT ELIGIBILITY CRITERIA NOT MET

FS NOTICES Closure Notices F422 FS - RESIDING IN AN INSTITUTION

FS NOTICES Closure Notices F424 FS - 1 PERSON HH DISQUALIFIED FOR FRAUD

FS NOTICES Closure Notices F426 FS - ADDED TO ANOTHER ACTIVE CASE

FS NOTICES Closure Notices F448 FS - IR NON-RECEIPT NOTICE

FS NOTICES Closure Notices 448F FS - IR AVISO DE NO RECIBO

FS NOTICES Reinstatement Notices

F600 FS - REINSTATE AFTER SUSPENSION


F601 FS - ERRONEOUS DISCONTINUANCE


F602 BENEFITS PAID PENDING HEARING DECISION


F604 FS IR REINSTATEMENT NOTICE


604F FS IR AVISO DE REINCORPORACIÓN

FS NOTICES Change Notices F701 FS - CHANGE IN BENEFITS/OTHER REASONS

FS NOTICES Change Notices F702 FS - SUPPLEMENTAL BENEFITS

FS NOTICES Change Notices F703 FS - CHANGE IN HOUSEHOLD MEMBERS

FS NOTICES Change Notices F704 FS - CHANGE IN BENEFITS/INCOME CHANGE

FS NOTICES Change Notices 704F CAMBIOS EN INGRESOS/BENEFICIOS DE FS

FS NOTICES Change Notices F705 CHG IN BENEFITS/INC CHG NO DEP CARE VERI

FS NOTICES Change Notices F706 FS INTERIM REPORT REVIEW COMPLETE

FS NOTICES Change Notices F707 FS-SSI 12 MONTH REPORT REVIEW COMPLETE

FS NOTICES Change Notices F708 CHANGE IN BENEFITS/CHANGE IN HH DEDUCTS.

FS NOTICES Change Notices F709 FS CHANGE - WORK PENALTY

FS NOTICES Change Notices F711 FS CHANGE - CITIZENSHIP/ALIEN STATUS

FS NOTICES Change Notices F712 FS-CHANGE TO ZERO BEN./INFO. PENDING

FS NOTICES Change Notices F713 FS CHANGE IN BENEFITS-RECOUPMENT

FS NOTICES Change Notices F716 FS CHG IN BENEFITS - ABAWD REQUIREMENTS

FS NOTICES Change Notices F744 CHANGE DUE TO COOPERATION/WORK PROGRAMS

FS NOTICES Change Notices F745 FS - MASS CHANGE/BENEFIT CHANGE

FS NOTICES Change Notices 745F MODIFICACIÓN EN LOS BENEFICIOS

FS NOTICES Change Notices F746 FS - CHANGE IN BENEFITS - 2 MONTHS

FS NOTICES Misc. Notice F801 CASELOAD TRANSFER

FS NOTICES Misc. Notice F827 FRAUD DISQUAL.-NONPARTICIPATING INDIVID.

Version 5.0

Program Form Type Form # Form TitleFS NOTICES Misc. Notice F828 FRAUD DISQUALIFICATION - PERMANENT

FS NOTICES Misc. Notice F830 FRAUD DISQUAL.-PARTICIPATING INDIVIDUAL

FS NOTICES Misc. Notice F831 REPAY AGREEMENT - FRAUD - PARTICIP. HH

FS NOTICES Misc. Notice 831F ACUERDO DE REPAGO - FRAUDE - PARTICI. HH

FS NOTICES Misc. Notice F832 REPAY AGREE. - AGENCY/CLIENT PART. HH

FS NOTICES Misc. Notice 832F ACUERDO DE REPAGO - AGENCIA/CLIENTE PART

FS NOTICES Misc. Notice F833 REPAY AGREE. AGENCY/CLIENT NONPART HH

FS NOTICES Misc. Notice 833F ACUERDO DE REPAGO - AGENCIA/CLIENTE NO P

FS NOTICES Misc. Notice F834 REPAY AGREEMENT -FRAUD - NONPARTICIP. HH

FS NOTICES Misc. Notice 834F ACUERDO DE REPAGO - FRAUDE - NOPART. HH

FS NOTICES Misc. Notice F835 REPAYMENT AGREEMENT

FS NOTICES Misc. Notice 835F ACUERDO DE REPAGO

FS NOTICES Misc. Notice F839 FS - NOTICE OF LOST BENEFITS

FS NOTICES Misc. Notice F841 NOTICE OF LOST BENEFITS WITH OFFSETTING

FS NOTICES Misc. Notice F842 ELIGIBILITY FOR FREE SCHOOL MEALS

FS NOTICES Misc. Notice F843 FS INTERIM REPORT FORM

FS NOTICES Misc. Notice 843F FS FORMULARIO DE INFORME PROVISIONAL

FS NOTICES Misc. Notice F844 FS - NOTICE OF RESTORED BENEFITS

FS NOTICES Misc. Notice F845 FS-IMPORTANT INFORMATION (ABAWD)

FS NOTICES Misc. Notice F846 CHANGE REPORT FORM

FS NOTICES Misc. Notice F847 INTERIM REPORT INCOMPLETE NOTICE

FS NOTICES Misc. Notice 847F AVISO DE INFORME PROVISIONAL INCOMPLETO

FS NOTICES Misc. Notice F849 FS-IMPORTANT INFORMATION - ABAWD/ICT

FS NOTICES Misc. Notice F850 FOOD STAMP ADJUSTMENT NOTICE

Collateral Contact Notices

Collateral Contact Notices I001 EMPLOYER LETTER

Collateral Contact Notices I002 LANDLORD LETTER

Collateral Contact Notices I003 BANK LETTER

Collateral Contact Notices I004 LIFE INSURANCE LETTER

Collateral Contact Notices I005 GENERAL CORRESPONDENCE TO COLLATERALS

Collateral Contact Notices I010 REPAY LETTER TO TREATMENT CENTER

Collateral Contact Notices I011 FIELD NOTICE-EXPUNGED FS/CASH CLAIM CHG

Collateral Contact Notices I012 FUNERAL AGREEMENT REFERRAL

Collateral Contact Notices I013 ANNUITY REFERRAL

NOTE: This list of forms represents the current forms used by SRS, and a scope of 299 forms to be developed as part of the Avenues Solution. During the analyze and design phase, these forms may change, or different forms/notices may be used to accomplish the same thing. These changes will be captured in the design documents. Once Detailed Design is complete, the forms will be ‘locked’ and any future changes must follow the Project Change Management procedures .

Version 5.0



12.2.1.1 Analyze Forms and Notices

The Automated Forms and Notices Team will work closely with the SRS - AVENUES Business Analysts to validate and confirm SRS - AVENUES forms and notices requirements. This serves to refine the requirements of the forms in scope. This step also includes reviewing the forms available in the APSP application to map, where appropriate, to the existing SRS - AVENUES forms and notices.


Attend meetings with SRS Functional SMEs to validate forms and notices.

Setup and configure the Adobe LiveCycle and provide on the job training support.

Document existing in scope SRS - AVENUES forms and notices.

Lead review and mapping of in scope SRS - AVENUES forms and notices to existing templates in APSP.



Provide copies of all existing forms and notices that are currently in scope.

Attend and participate in forms and notices review.

Provide Subject Matter Experts (SMEs) for each functional area that can efficiently and accurately document/describe required forms and notices requirements and population.

Review and approve the forms and notices inventory.



12.2.2 Design Phase

The Design Phase begins with specifications from the Analyze Phase, and ends with a list of tasks that, once performed in Build, will deliver the future state solution.

Forms and notices designs will be created for each form or notice that identifies the static content, the definition of the dynamically populated fields if required for the form or notice, and the identification of corresponding APSP template where applicable.

Version 5.0


Produce General Design Documents for Contractor assigned forms identified in the State-approved RICEFW inventory.

Plan Integration Test of the approved forms and notices.


Produce General Design Documents for Contractor assigned forms identified in the State-approved RICEFW inventory.

Plan Integration Test of the approved forms and notices.

Review and approve the General Designs.

12.2.3 Build Phase


The Forms Team shall configure, modify and unit test forms approved in the Analyze Phase.


Configure, modify and/or develop, and unit test forms assigned to the Contractor.


Provide technical support on Adobe LiveCycle for team.


Configure, modify and/or develop, and unit test forms assigned to the Contractor.


Provide technical support on Adobe LiveCycle for team.

Review and approve the forms and notices, unit test-scripts and unit test results developed by Contractor.

12.2.4 Test Phase

12.2.5 Section 7 of the K-MED SOW Deploy Phase

The SRS Project Team shall deploy the forms approved in the Analyze Phase.

Version 5.0


Deploy the forms documented through design and build activities






Automated Forms and Notices Contractor SRS TeamAnalyze Phase

Analyze Forms Requirements Lead Assist

Define Forms Inventories Lead Assist


Design Phase

Design Forms Lead Assist


Build Phase

Build and Unit Test Forms Components Lead Assist


Test Phase

Execute Integration Test Lead Assist

Execute System Test Lead Assist


The table below summarizes the Forms and Notices work products and deliverables to be created during each phase:

Ref. No.

Phase Work Product Deliverable Description

NA Analyze Forms and Notices Inventory

A listing of forms and notices in scope with a mapping to templates if any in APSP.

NA Design Forms Design The General Design lists the forms static content, the definition of the dynamically populated form fields if required for the form, and the identification of corresponding APSP form/template where applicable.

15 Build Application Code and Unit Test

Delivery of the forms and notices source code, unit test scripts and execution results.

NOTE: Work products do not have a dependency on deliverables.

Version 5.0

Version 5.0

13.0 Imaging and Content Management

The SRS Imaging and Content Management Statement of Work (SOW) will reference the K-MED Imaging and Content Management SOW as the SRS solution will be designed, built, tested, and implemented leveraging the technical infrastructure, methodologies, business processes, designs, and development phase activities that are defined in the K-MED Imaging and Content Management SOW. There is, however, one difference between the K-MED and SRS Imaging and Content Management solutions and that is the document types that are scanned by eligibility workers. These document will be identified during the analysis and design phases of the SRS project.

In addition to the scope defined in the Imaging and Content Management sections below, Accenture will also support SRS staff in the establishment of Central Records Center. Support will include planning discussions during the Analyze and Design as well as guidance during the Build and Deployment phases of the Central Records Center. Both SRS and Accenture agree that SRS will take the lead in the operations of the Central Records Center.


The necessary document types (i.e., documents that will be scanned, categorized, and accessed through the Avenues system) will be identified during the analyze and design phases of the SRS project.


The table below summarizes the Imaging and Content Management work products and deliverables to be created during each phase:

Ref. No.

Phase Deliverable Name Work Products Description

29 Detailed System Design The Functional and Detailed Design Document details the functional and technical requirements for developing, testing, and implementing the Content Management solution for SRS.

NA ECM Interim Solution The ECM Interim Solution involves rapidly developing and deploying the standalone imaging solution.

NA ECM Eligibility Integration The ECM Eligibility Integration occurs after Document Conversion has competed (or reached an acceptable level). This deliverables marks the integration of the interim solution into the Eligibility and Web Portal systems.

Version 5.0

14.0 Enterprise Readiness

The Enterprise Readiness Team prepares SRS users for the transition to the new integrated K-MED/Avenues system and business processes. Because the K-MED implementation affects SRS workers, the K-MED Scope of Work includes enterprise readiness and communication initiatives aimed at supporting SRS personnel through the transition.

The readiness activities in the K-MED Scope of Work, such as identifying process and role gaps, producing Change Discussion Guides to explain new processes, and conducting Readiness Workshops with Change Agents are targeted toward SRS users who use K-MED for medical eligibility. Activities in the SRS Scope of Work are an incremental add to the K-MED SOW to address the Avenues-specific processes.

The Enterprise Readiness team will be comprised of representatives from the State project team and Contractor.



During the Analyze Phase, the team produces the Stakeholder Assessment and Stakeholder Management Plan, Enterprise Readiness Plan and Communication Plan that define the scope and contents of the Enterprise Readiness activities for the project.

14.1.1.1 Develop the Stakeholder Assessment and Stakeholder Management Plan

An input into the Enterprise Readiness Plan is the Stakeholder Assessment and Stakeholder Management Plan. The Stakeholder Assessment document identifies internal and external (e.g. customer) stakeholders and assesses the type and extent of impacts they will experience from the Avenues implementation. The Stakeholder Management Plan outlines how the project will develop support among the key stakeholders by involving them in project activities. The results of the assessment will feed into the Communication Plan.


Work with the State to identify key internal/external stakeholders and the key impacts for each group

Define initiatives to keep key stakeholders involved throughout the project

Develop the Stakeholder Management Plan

Version 5.0

State Responsibilities

Provide information to the Contractor regarding key internal/external stakeholders and impacts, including organization charts

Coordinate meetings with any groups necessary to complete the assessment and plan

Provide input into the Stakeholder Management Plan

Review and approve the Stakeholder Management Plan content that will become a part of the overall Enterprise Readiness Plan deliverable

14.1.1.2 Create Enterprise Readiness Plan

The Enterprise Readiness Plan describes the overall approach to conducting readiness activities for SRS. It describes the Enterprise Readiness tools and processes and provides a high-level schedule. The Enterprise Readiness Plan also describes how the SRS Enterprise Readiness initiatives build on and integrate with K-MED change activities.


Using input from the State, develop the Enterprise Readiness Plan


Coordinate meetings with any groups necessary to complete the plan

Provide input into Enterprise Readiness Plan

Review and approve the Enterprise Readiness Plan deliverable

14.1.1.3 Create Communication Plan

The Enterprise Readiness Team will create the Communication Plan. The plan will identify stakeholders, information needs, key messages, methods, senders, and schedule. It will also describe methods for collecting feedback on the effectiveness of the communication initiatives. Because there is a great deal of overlap between the K-MED Communication Plan and the Avenues Communication Plan, the document will address how to coordinate communication methods and timing to provide the most effective communication for SRS employees.


Create the Avenues Communication Plan and define the messages and delivery methods

Version 5.0


Assist the Contractor in the development of the Communication Plan. Assistance would include identification and input regarding stakeholders, messages, and delivery methods.

Review and approve Communication Plan deliverable

Review and approve communication materials

14.1.2 Design Phase

During the Design phase, the Enterprise Readiness Team designs the readiness tools, methods and materials to facilitate readiness and transition for stakeholders, as identified in the Enterprise Readiness Plan. They also support Road Shows to kick off Phase 1 and 2 for system users.

14.1.2.1 Support Road Shows

The Enterprise Readiness team supports the Road Show effort by providing communication materials such as a PowerPoint presentation to be used during the meetings.


Work with the State to plan the agenda for the Road Shows

Create Road Show materials


Provide input and review for Road Show materials

Determine Road Show locations

Conduct Road Shows

14.1.2.2 Launch Change Agent Network and Regional Implementation Leads

During this phase, Accenture will support the State in identifying KDHE-HCF and SRS personnel who will serve as Change Agents and Regional Implementation Leads. Change Agents are staff who help their local offices adapt to changing business processes and prepare for implementation, and who support their peers in the days and months following implementation. Change agents can represent any area of the business affected by the upcoming process changes. Each local office will identify one or more Change Agents who will assist their offices with K-MED and Avenues changes.

Also during this phase, State Enterprise Readiness team members identify Regional Implementation Leads who will monitor readiness at a regional level. The Regional Implementation Lead is the person responsible for supporting, monitoring and reporting on production transition readiness for all locations

Version 5.0

in the region. The ER team works with the Regional Implementation Leads to conduct readiness reviews at 90, 60, and 30 days prior to go-live, and weekly during the month prior to deployment. The effort to organize and manage the Change Agent program and work with the Regional Implementation Leads is included in the K-MED Scope of Work. Please refer to the K-MED Scope of Work for details and responsibilities.

14.1.2.3 Document System, Process and Role Gaps

Accenture and State Enterprise Readiness team members document the major functional differences between the current systems and the integrated K-MED and Avenues system. In addition, the team facilitates business process reviews (“as-is” versus “to-be”) to define the differences between the current environment and the future environment. The project will define up to four “to-be” business process models that align with the different types of local offices. The SRS SOW includes the incremental work to analyze the gaps for Avenues-related functionality and business processes.


Use information from fit gap activities and other project documentation to document functional differences

Conduct business process reviews (work with business analysts, state personnel, etc. to receive the appropriate input)

Document the future business processes

Document gaps between the current and future processes


Provide existing “as-is” analysis

Participate in documenting functional differences

Participate in process reviews

Participate in documenting revised business processes and gaps

Review and approve the process and role gap documentation

14.1.2.4 Design Change Discussion Guides/Readiness (Business Process) Workshops

Enterprise Readiness Team members develop Change Discussion Guides that describe the changes that affect job functions and roles. They then conduct Readiness Workshops with the Change Agents to explain the information in the guides and prepare the Change Agents to deliver the material back in

Version 5.0

their own areas. The workshops provide an overview of the new business processes and provide tools and aides to facilitate the local offices in identifying impacts and specific actions to prepare for implementation. Change Agents use the guides to generate discussion among managers, supervisors and staff in their locations about how business processes and job roles would change with the new system.


Design the Change Discussion Guides and other workshop content and material using baseline materials as input. Other workshop materials include PowerPoint presentations to present the new enterprise business processes, as well as checklists or “desk aides” to provide assistance, tools, and templates to help offices assess impacts and document actions.

(NOTE: The Enterprise Readiness team creates “desk aids” that refer specifically to the tools and procedures that would help local offices plan for the upcoming business process changes and prepare for implementation – these documents will not be needed after post implementation support. The training team, however, creates “job aids” that relate to tasks users perform in the system – these documents persist over time)


Participate in the design of the materials. This would include providing content and/or development of specific portions of assigned workshops.

Review and approve Change Discussion Guides and workshop materials

14.1.2.5 Provide Communications /Update Communication Plan

The Enterprise Readiness team creates and delivers specific communication messages, materials and events as outlined in the updated Communication Plan. The team reviews and updates the Communication Plan quarterly to include specific stakeholder information and specific communications messages, timing, and events. This task is repeated for each phase.


Work with SRS to update the Communication Plan on a quarterly basis to address stakeholder feedback and to reflect new information regarding specific stakeholders and specific communications messages, timing, and events

Implement communication initiatives specified in the Communication Plan


Produce/deliver communications with help and guidance from the Contractor

Version 5.0

Provide input and review for communication materials and initiatives

14.1.2.6 Office of the Future

Scope Description to Develop an Office of the Future Demonstration

Accenture will develop a demonstration for state staff to show them the types of business process and functional changes that they will implement with Avenues. This demonstration will be a prototype of the Office of the Future. This is a description of the scope for the development of the Office of the Future prototype.

Purpose of the Office of the Future Demonstration

The purpose of the Office of the Future demonstration is to:

• Visually demonstrate to state staff the changes to work processes that they will experience with the implementation of Avenues.

• Allow staff time to view the prototype from their workstations, at their convenience, and to generate ideas and questions for discussion with their supervisors and teams

• Demonstrate the interaction of business processes with new functionality, including self-service portals, document imaging, interactive voice response, Call Center, and data interfaces

• Replace the use of Change Discussion Guides (included in our original proposal) with this visual, self-paced, hands-on change management tool.

Approach to Creating the Office of the Future Demonstration

During the Analysis and Design Phases of the Project, Accenture’s change management staff will facilitate sixteen sessions with users to develop the To-Be business processes.

The purpose of these sessions is to identify the transitions required to move from the As-Is business processes to the To-Be business processes.

Using the To-Be processes, we will develop a Avenues demonstration that will replace the need for creation and deployment of Change Discussion Guides. We will show the prototype during a Conference Room Pilot (CRP). The state team will verify the Avenues system implements state processes correctly and meets requirements, as they see those processes. By actually seeing the business process changes and the relation to the Avenues system, state users will get a clear demonstration of how the changes will work.

The Office of the Future demonstration will be used by each group of staff, at their workstations, prior to Pilot and prior to each Phase, to prepare them for the business process changes that will occur. The

Version 5.0

Office of the Future will be flexible, in that individuals can view it as many times as they like, then teams could watch portions of it and discuss how they see it working in their office locations. The use of the prototype should reduce the demand on line staff’s time to attend meetings.

We will develop the Office of the Future Demonstration using portions of the Avenues prototype and a variety of other multi-media sources. We will develop the Demonstration using Adobe Captivate software (which is already included in our proposal as the training development tool). We will develop video presentations of new process flows in an office-like environment, by setting up a “model office” which will be recorded at the Project site. Members of the Project team will walk through the new business processes, showing integration of new system features into the business flows. A voice-over will unify the presentation, as workers move from viewing the video, to looking at Avenues pages (screens), and learning about the changes from As-Is to the To-Be processes that are relevant to their roles.

The end product will be a richly layered web-based module that Avenues system users can launch at their workstations. Workers will be able to select and view clips of the demonstration directly relevant to their worker roles. It will include information about To-Be processes that was formerly to be included in the Change Discussions Guides, but with the added features of visual and graphic demonstrations.

The Office of the Future will address the following change management and readiness needs:

• Creating a shared language (new Avenues system terminology) and vision among leaders and staff from different agencies, programs and locations

• Introducing business process changes and new functionality in a visual and engaging manner

• Supporting users as they transition to a new way of working which may include unfamiliar technology (such as Interactive Voice Response, Imaging, and call centers)

• Building support for changing job roles and skill needs among staff from KDHE, SRS, and other organizations

• Meeting the complex logistical and project management requirements of a phased Enterprise Readiness implementation the size and scope of Avenues

Readiness team members will work with state subject matter experts and members of the Accenture functional/business teams to document how new business processes and the Avenues system will affect the various Avenues user groups. Information from this analysis helps inform several activities, including skills and gap analysis, as well as role mapping. As a part of the role mapping process, the team will complete following tasks, as they would have done to create Change Discussion Guides:

• Identify current roles within the organizations affected by the Avenues implementation (SRS locations, provider locations, etc.)

Version 5.0

• Map existing roles to current (As-Is) business processes and events

• Identify future (To-Be) business processes

• Identify the changes in roles that are required to support the new business processes

• Analyze relationships between roles and how those relationships will be affected by the Avenues implementation

• Revise roles which support new business processes as required

• The Enterprise Readiness team will integrate information about revised roles into the Office of the Future demonstration.

Additional Option for Business Process Improvement – Change and Innovation Agency

As we develop the Office of the Future demonstration, we also offer an added feature of Business Process Improvement (BPI). We have successfully delivered BPI with state agencies across the nation and other government institutions around the globe, working with our clients to fit their business to the capabilities of solutions. We would tailor our approach to the specific needs of the Avenues project by leveraging our team’s experience in implementing human services solutions in 37 states in the U.S. The tailored methodology also leverages our experience implementing integrated human services solutions to provide a more focused methodology for the K-MED Project.

Business Process Improvement is a key focus of our successful record in Accenture’s Public Service Operating Group. With our BPI approach, we have helped numerous public service clients to streamline and re-engineer business processes. We also team with the Change and Innovation Agency, which is a company based in Kansas City, and a leader in bringing process improvements to state agencies.

Change and Innovation Agency (CIA) provides leadership consulting and practical process guidance to help teams be more productive. They have worked in agencies in all 50 states to change behaviors, preconceptions, and to drive innovative changes to process. They help teams re-imagine the work that they do and the outcomes they generate and eliminate the ‘kinks in the pipe’ that limit productivity. As an added feature of the Office of the Future, we propose that we leverage CIA in the Analysis Phase of the Avenues project to conduct several workshops. The purpose of these workshops would be to help set project mindset in the direction of positive process changes and to engage leadership in the possibilities. Systems automate processes; and Kansas has the opportunity to automate the most efficient and supportive processes. CIA can help achieve that outcome.

We will incorporate the outcomes of these workshops into the Design Phase for developing the To-Be processes for the Office of the Future demonstration.

Impact on Project Timelines

Version 5.0

The development of the Office of the Future demonstration and prototype can be accomplished within the existing Project timeframes, to keep all Phases on schedule as planned. This can be done by modifying the timing for some of the previously planned cultural change management work and inserting a prototype development effort. The additional effort for this work is estimated to be 6 person months of Accenture staff (2 people for 3 months). This work will be scheduled to begin during the Design phase and complete during the Build phase of the Project.

The prototype will then be ready for use in the field by Avenues system users, supervisors, SRS offices, providers, and Central office staff in time to prepare for implementations.

Impact on Project Cost: The Office of the Future would cost $199,397.

This includes the addition of two Accenture resources for 3 months to develop the Office of the Future demonstration during the Analysis and Design Phases, and 3 workshops conducted for state leadership and management during the Analysis Phase of the Project.

However, this cost is potentially offset by a savings in the need for as many state staff for change readiness activities as was originally anticipated. Because the Office of the Future could replace the need for change agents in each location to train staff on Change Discussion Guides, the amount of time needed for each of the State’s local change agents could be reduced by potentially as much as 50%.

14.1.3 Build Phase

During the Build phase, the Enterprise Readiness team continues to interact with users and change agents in support of the readiness activities outlined in the Enterprise Readiness Plan. The team defines roles and conducts role mapping, defines the tools and metrics to measure readiness, conducts the first readiness assessments, develops workshop content and continues developing and delivering detailed communication messages.

14.1.3.1 Build Change Discussion Guides/ Readiness (Business Process) Workshops

The Enterprise Readiness Team will develop the Change Discussion Guides and workshop materials.


Develop the Change Discussion Guides and other workshop content and material. Other workshop materials include PowerPoint presentations to present the new enterprise business processes, as well as checklists or job aides to provide assistance, tools, and templates to help offices assess impacts and document actions.

Version 5.0


Support the Contractor in the development of the materials. This could include providing content and/or development of specific portions of assigned workshops.

Help local offices identify the appropriate representatives to attend sessions

Review and approve Change Discussion Guides and workshop materials

14.1.3.2 Create Role Descriptions

The Enterprise Readiness team documents detailed descriptions of new and/or revised roles. Role descriptions include a role definition, description of responsibilities, skill/knowledge requirements, relationships to other roles, and a summary of change impacts associated with the role. Once role descriptions are complete, the team uses the role mapping process defined during Design phase to implement the role mapping activities.


Define and document descriptions for each role

Provide the tools, templates and processes defined in the Role Mapping approach

Support the State in role mapping activities by helping to troubleshoot the process and/or answer role-related questions

Coordinate the receipt of the role mapping information with the Security team


Use the Role Definitions and Role Mapping processes and tools to map end-users to appropriate roles within the timeframe suggested

Designate functional SMEs to review the role descriptions for accuracy and alignment to the new business processes

14.1.3.3 Provide Communications / Update Communication Plan

The Enterprise Readiness team continues to create and deliver specific communication messages, materials and events as outlined in the updated Communications Plan (see above for responsibilities).

14.1.3.4 Assess and Report Readiness

During the Build phase, the K-MED Enterprise Readiness team creates the tools and templates to use for readiness assessment and tracking. The Assess and Report Readiness effort is included in the K-MED Scope of Work.

Version 5.0

The following templates are samples for a Personal Learning Plan and Scorecard. As mentioned above, the actual templates used for Avenues will be developed by the K-MED Enterprise Readiness team.

Version 5.0

Personal Learning Plan (PLP)

Personal Learning Plan For: Ben CampPrimary Role: Rules Developer Learner:

Primary Learning Coach: Matt Berry Learning Coach:

Learning Objective (Knowledge/Skill to Be Acquired) Learning Approach(es) Coach Start Date End Date Status Knowledge Transfer Completed (Initials of Learner & Coach)

Next Steps

Describe key features and functions of Oracle Policy Automation (OPA)

Small Group Walkthrough Matt Berry 5/23 5/24 CompleteN/A

Ben to ask follow-up questions as needed

Understand OPA Components and Architecture Small Group Walkthrough Matt Berry 5/23 5/24 CompleteN/A


Describe Policy Automation Terms and Concepts Small Group Walkthrough Matt Berry 5/23 5/24 CompleteN/A


Author Rules in OPA Using Word and Excel On-the-Job Practice & Knowledge Transfer

Scott Parker TBD TBD Not Started______ / _______

Test Rules On-the-Job Practice & Knowledge Transfer


Create Visualizations within Oracle Policy Modeling On-the-Job Practice & Knowledge Transfer


Understand OPM Integration Points and Version Control Knowledge Transfer Scott Parker TBD TBD Not Started ______ / _______Understand Packaging and Deployment Options Knowledge Transfer Scott Parker TBD TBD Not Started ______ / _______Deploy a rule using Oracle Web Determinations Server On-the-Job Practice & Knowledge

TransferScott Parker TBD TBD Not Started

______ / _______Use the APSP Rules architecture component to implement a rule (Reference: APSP Workbench, "How to APSP Rules Service")

On-the-Job Practice & Knowledge Transfer

Scott Parker TBD TBD Not Started

______ / _______Understand OPA resources installed locally with software:(1) Oracle Policy Modeling Help(2) Oracle Policy Automation Help(3) Oracle Policy Automation Connector for Siebel Help

Self-Study Scott Parker TBD TBD Not Started

N/AUnderstand OPA product support resources available via Oracle.com:(1) OPA Knowledge Supporthttp://www.oracle.com/partners/en/knowledge-zone/applications/policy-automation-042908.htm

(2) OPA Forumhttp://forums.oracle.com/forums/forum.jspa?forumID=828

(3) OPA on OTNhttp://www.oracle.com/technetwork/apps-tech/policy-automation/overview/index.html

Self-Study Scott Parker TBD TBD Not Started

N/AUnderstand resources available in the APSP Workbench installed locally with software

Self-Study(Browse APSP Workbench help content in Eclipse)

Matt Berry TBD TBD Not Started

N/AGain deeper experience with OPA tools and concepts Oracle University -

Oracle Policy Modeling: Essentials Part I Course

N/A TBD TBD Not Started

N/A

Required Knowledge Transfer Completed(To be initialled upon completion of all Knowledge Transfer tasks)

Version 5.0

Scorecard

During this phase, the ER Team will orient the Regional Implementation Leads who will monitor readiness at a regional level. The team will work with the Regional Leads to conduct a readiness review at 90, 60, and 30 days prior to go-live, and weekly during the month prior to deployment. The team will track readiness in an overall tracking tool that contains each location and the readiness status. Readiness results are used as input into deployment go/no-go decisions. Go/no-go meetings will review these regional readiness assessments, along with application readiness, environment readiness and support readiness.


Create and distribute readiness checklist

Conduct readiness assessments

Analyze, summarize and report on readiness assessment results


Participate in reviews

Version 5.0

Review and approve readiness checklist

Assist contractor in the review of assessment results and the preparation of the summary report

14.1.4 Test Phase

During the Test phase, the Enterprise Readiness team delivers specific communication messages as defined in the updated communication plan and will continue to support readiness tasks, assess and report readiness, and provide outreach and support to users as they prepare for implementation.

14.1.5 Deploy Phase

14.1.5.1 Assess and Report Readiness

During the Deploy phase, the Enterprise Readiness team conducts the readiness assessments, analyzes the results and prepares a report of the assessment findings. The team will conduct a readiness review at 90, 60, and 30 days prior to go-live, and weekly during the month prior to deployment.


Create and distribute the applicable readiness checklists for this phase

Conduct readiness assessments

Analyze, summarize, and report on the readiness assessment results


Review and approve the readiness checklists for this phase

Participate in readiness reviews

Assist the Contractor in the review of the assessment results and the preparation of the summary report

14.1.5.2 Provide Communications / Update Communication Plan

The Enterprise Readiness team continues to create and deliver specific communication messages, materials and events as outlined in the updated Communications Plan (see above for responsibilities).

Version 5.0


The table below summarizes the responsibilities associated with Enterprise Readiness and Communication:

Scope Element Contractor StateCreate Stakeholder Assessment and Stakeholder Management Plan

Lead Assist

Develop Communication Plan & Delivery Methods Lead Assist

Create communication tools and delivery Lead Assist

Create Enterprise Readiness Plan Lead Assist

Meeting Logistics Lead

Identify System, Process and Role Gaps Lead Assist

Develop Change Discussion Guides Lead Assist

Readiness Workshop Development (who, when, how, how many)

Lead Assist

Readiness Workshop Presentation Assist Lead

Role Definition Lead Assist

Role Mapping using above definitions Lead Assist

Create readiness assessments Lead Assist


None identified.

14.4 Deliverables

The table below summarizes the Enterprise Readiness deliverables to be created during each phase:

Ref. No. Phase Deliverable Name DescriptionNA Analyze Stakeholder Assessment and

Stakeholder Management Plan (work product – not a paid deliverable)

The Stakeholder Assessment document identifies internal and external stakeholders and assesses the type and extent of impacts they will experience from the Avenues implementation. The Stakeholder Management Plan outlines how the project will develop support among the key stakeholders by involving them in project activities.

5 Analyze Communication Plan The Communication Plan describes the communication approach, structure, and methods that will be used on the project. The Plan includes such information as:

Communication Goals and Objectives Stakeholders Communication methods Anticipated messages and timeline Feedback mechanisms Suggested communication process, tools and templates;

including process for quarterly updates

13 Analyze Enterprise Readiness Plan The Enterprise Readiness Plan details the approach for preparing

Version 5.0

Ref. No. Phase Deliverable Name Descriptionthe State for implementation and the associated changes. The Plan will include such information as:

Enterprise readiness goals, objectives, and overall approach

Initial impacts, initiatives to address, and timeline Change Agent Network description and associated roles

and responsibilities Approach for assessing readiness

NA Build Change Discussion Guides (work product – not a paid deliverable)

Change Discussion Guides that describe the process changes that affect job functions and roles. They also include key decisions the local offices need to make in order to prepare for implementation of the new processes.

Version 5.0

15.0 Training Services

The Training team will be responsible for End User Training for the SRS users identified in Appendix 8 of the K-MED RFP. This includes analyzing the training needs, confirming the training curriculum, designing and building the training materials, coordinating the training environment with the technical team, testing training materials, conducting train-the-trainer, and supporting training administration. SRS may identify additional staff (approximately 500 to 600) to be trained during the course of the Avenues project. SRS will lead the effort, with assistance from Accenture, and in conjuction with K-MED training delivery, to make sure the appropriate staff receive the necessary training within the constraints of the Accenture staff. The training services for Avenues discussed in this Statement of Work is an increment of work added to the K-MED training.

The Training team will be comprised of representatives from the State SRS project team and the Contractor. The Statement of Work reflects that Accenture will coordinate closely with SRS on the training program. Five SRS personnel and a State Training Lead from SRS will serve on the Training Team and will be involved in day-to-day training analysis, design, development, and testing activities. Accenture will be responsible for Train-the-Trainer, and Training Delivery, while SRS will provide the staff to assist in Training Delivery.

ITS Training will be accomplished through side-by-side knowledge transfer and other knowledge transfer methods as outlined in the Knowledge Transfer section of the SOW.



15.1.1.1 Analyze End User Training and Support Needs

Within the Analyze phase, the Training team confirms training needs for each audience affected by the new business processes. When conducting a needs analysis, the team identifies roles and their corresponding tasks/responsibilities, which then drive the required skills, training needs and training schedule for that role. At the end of the Analyze Phase, the Training team develops the Training Plan that describes the key elements of the training program, and includes course outlines for each Web-based Training (WBT) and Instructor-Led Training (ILT) course. The SRS Training Plan will be a separate deliverable from the K-MED Training Plan.


Review the Enterprise Readiness Assessment Report

Define the skills required for new and revised roles. Contractor will leverage the impact analysis that has already been conducted on the project.

Version 5.0

Create the Training Plan which will document the overall scope and strategy for the SRS training program

Refine the preliminary curriculum using results from the audience analysis data


Review the Enterprise Readiness Assessment Report

Provide State context and content and assist in the preparation and development of the Training Plan

Review, provide revisions and corrections, and approve the Training Plan

Review, provide revisions and corrections, and give final approval for all course outlines

15.1.1.2 Training Curriculum

Using the results from the audience analysis, the Training team will refine the preliminary training curriculum for the End User Training Program. The preliminary training curriculum listed below includes courses already in scope for the K-MED project, as well as the courses that cover the additional functionality for Avenues.

Anticipated Course Type Length Baseline Course or New*

Avenues and K-MED Phase 1

Customer Self Assessment On line Demo < 15 min Baseline

Online Intake Application for Customers and Community Partners

On line Demo < 15 min Baseline

Online Intake Application for K-MED/Avenues users

Web-based Training 3 hours Baseline

System Navigation Web-based Training 2 hours Baseline

Presumptive Eligibility Instructor-led Training ½ day New

Avenues and SRS Phase 2

Eligibility Instructor-led Training 4 days for medical only; 5 days with additional program content integrated throughout course

Baseline

Clerical Roles Web-based Training 4 hours Baseline

Hearings and Appeals Web-based Training 4 hours Baseline

Office Administration Web-based Training 4 hours Baseline

Security Rights Administration Web-based Training 3 hours Baseline

Cost Avoidance and Recovery Web-based Training 3 hours Baseline

Calendaring Web-based Training 1 hour Baseline

Administrative Tools Web-based Training 2 hours Baseline

Data Synchronization Web-based Training 2.5 hours Baseline

Version 5.0

Anticipated Course Type Length Baseline Course or New*

Workload Reassignment Web-based Training 1.5 hours Baseline

Quality Assurance Web-based Training 4 hours Baseline

Avenues-Only

Employment Services Web-based Training 6 hours Baseline

Child Care Web-based Training 6 hours Baseline

Resource Databank Web-based Training 4 hours Baseline

Overpayments Web-based Training 3 hours Baseline

Issuances Small Group Walkthrough

1 day Baseline

Collections Small Group Walkthrough

1 day Baseline

Additional Training

Imaging/Content Management (development of course plus training for ITS Staff and Train-the-Trainer)

Instructor-Led Training 1 day Baseline

LIEAP Training Material and Delivery: Accenture will extending training materials (previously developed) to cover the additional LIEAP scope. Accenture will also provide joint responsibility to roll the delivery LIEAP of the Training Materials to the appropriate LIEAP staff.

Instructor-Led Training 1 day New

Virtual Contact Center (Development of course detailed design plus mentoring of Staff to complete the course)

Instructor-Led Training 1 day New

*Note: Baseline courses reflect existing APSP system functionality and will be modified by the Training team to reflect Kansas-specific changes. New courses will be designed and developed “from scratch” as no baseline course materials exist.

Small group walkthroughs are expert-led sessions with a flexible format. When appropriate, walkthroughs occur using the sandbox or a test version of the software, instead of the more structured training database, to provide the participants more flexibility to practice scenarios. For Issuances and Collections, the smaller training audience supports using this approach. Walkthroughs would be conducted in a central location such as the Central Training Lab.

Additional information about small group walkthroughs and knowledge transfer activities for ITS and project roles (network administrator, business rules personnel, developer, business analyst, etc.) can be found in the Knowledge Transfer section of the Scope of Work.

Version 5.0


Confirm the training curriculum, which lists the training courses, anticipated delivery method, and length for each course

Produce a high-level outline for each course for each SRS-specific course


Assist the Contractor in defining the curriculum, which includes providing State context and content, providing input regarding methods, and assisting in the development of the course outlines

Review and approve all inputs, standards, and templates used by the Contractor

15.1.2 Design Phase

Using the Training Plan and course outlines as input, the Training team creates detailed specifications for the end user training courses and support tools that will be developed during the Build phase.

The team builds on the outlines for each course identified in the Training Plan, identifying specific exercises that illuminate and reinforce the course objectives.

15.1.2.1 Training Tools Training

The Accenture Training team members will conduct informal knowledge transfer for the State Training team members on the tools and methodology that will be used to design and build the end user training.. Web-based Training will be developed in Adobe Captivate; Online Help will be developed in Adobe RoboHelp.


Teach the State training team members the use of the tools and methods used for designing and building the end user training


Ensure State training team members attend and participate in the informal meetings

15.1.2.2 Training Design

Training designs will contain information regarding learning objectives, suggested content, and estimated duration, and validate the suggested deployment method. Training designs consider the to-be business processes, as well as SRS-specific configurations and customizations to the system. During Design, the team will also identify changes required to the inventory of standard, delivered online help procedures that support Avenues functionality. The Avenues Scope of Work includes the effort to evaluate online help for Avenues functionality.

Version 5.0


Produce design documents for each instructor-led course, web-based course or online demonstration

Produce an inventory of online help procedures

Provide methods, tools, and guidance in the training design process


Produce training and online help design documentation, using the same inputs, standards and templates as the Accenture team members

Provide the necessary State content and context to the training materials

Review and approve all inputs, standards, and templates used by the Contractor

Review and provide confirmation of each training design to minimize rework during the Build phase

Confirm the inventory of online help procedures

Evaluate the look and feel of the baseline instructor-led products and implement design changes

Identify additional classroom and online help custom job aids

Provide revisions, corrections, and give final approval for all training materials

15.1.3 Build Phase

15.1.3.1 Build

The Build Phase includes developing training material. During this phase, the Training team develops SRS-specific training materials, online help procedures, WBTs, and training exercises based on the approved designs. They coordinate with the project technical staff to create a training environment and a training sandbox. The team will use baseline materials plus project deliverables (standards, templates, etc.) as a starting point for SRS training materials and online procedures. Once developed, SMEs review the materials and provide feedback. Once the feedback has been addressed, the materials are tested and revised prior to Training Deployment.


Work with the K-MED/Avenues training development team to develop a combined Eligibility course that reflects both K-MED and Avenues functionality. The K-MED scope of work includes developing the equivalent of 4 days of training. The SRS scope of work includes developing the equivalent of 1 day of additional training content. This content will be integrated into the full course so that SRS users see relevant scenarios and data throughout.

Version 5.0

Work with SRS to create the paper-based and online components of the Eligibility course. Paper materials consist of a slim user guide that contains course objectives, background information, information on how to utilize user support tools after training and after implementation (online help, help desk, etc.), guidelines and suggestions for using the sandbox to reinforce their skills after training, and a place for taking notes.

Develop written training materials in accordance with 508 compliance regulations.

Build new web-based training courses. WBT courses consist of text pages, simulated system pages with user interactivity, and skills assessments. The WBTs will be JAWS compliant.

Modify existing baseline courses to reflect SRS-specific system configurations and customizations, as well as agency-specific items such as logo, terminology, etc.

Identify scenarios and training data needed to support the instructor-led course objectives

Establish the training database environment and set up training data. Training for K-MED and Avenues will use the same training environment, with data specific to each.

Establish the training sandbox environment and define processes and procedures for the sandbox environment. K-MED and Avenues will use the same sandbox environment.

Develop course evaluations

Modify existing online help content and job aids to reflect SRS-specific configurations and customizations, as well as create new procedures where necessary

Contractor shall designate functional SMEs to review the training materials for system accuracy

Address the SME-reviewer feedback and update the training materials accordingly


Develop training materials using the same tools and templates as the Accenture team

Provide input to the training materials and support tools. The input will include State content and context to the materials

Review and approve all tools and templates used by Accenture

Assist in defining exercise scenarios and data used in the training database

Designate SMEs to review the training materials for State context, content and process accuracy

Address the SME-reviewer feedback and update the training materials accordingly

Create any SRS-specific training content required to supplement the training program

Version 5.0

Provide revisions, corrections, and give final approval for all training materials as well as support tools

15.1.3.2 Test

The Test Phase includes testing training materials prior to deployment. During this phase, the Training team tests SRS-specific training materials, online help procedures, WBTs, and training exercises.


Test instructor-led training exercises

Test new and modified web-based training courses

Work with the technical team to confirm sandbox readiness for deployment

Test online help


Conduct testing on training exercises, web-based training, and online help using the same tools and methods as the Accenture team

Designate SMEs to review the training materials for State context, content and process accuracy

Provide revisions, corrections, and give final approval for all training materials as well as support tools

15.1.4 Deploy Phase

During the Deploy Phase, the Training team conducts a training pilot, delivers Train-the-Trainer, and deploys web-based training and online help. Accenture will be responsible for Train-the-Trainer and Training Delivery, while SRS will provide the staff to assist in Training Delivery.

15.1.4.1 Pilot Training

The Training team conducts a mock delivery of each training course, to confirm the course duration and to validate that the objectives of the course are met as designed. Each pilot (a.k.a mock training delivery) will include the respective training developer conducting one practice session of each course to the trainers who are being prepared for training delivery and/or to other selected participants such as State subject matter experts. Observers from the Training team will validate course duration and identify any issues. Comments and observations will be captured throughout the delivery. Results will be summarized, analyzed, and prioritized. Recommended changes will then be made to correct issues where training did not perform as designed or where content was incorrect. Other changes mutually agreed upon by the State and the Contractor will be made prior to the training deployment to end users.

Version 5.0


Create the pilot schedule

Prepare the Central Training Lab for pilot courses

Conduct pilot courses

Review the pilot training results and prioritize changes

Apply approved changes


Provide input to the development of the Pilot Training Plan and schedule

Review and approve the Pilot Training Plan as well as all training courses associated with it

Identify pilot training participants

Participate in the review of the pilot training results and work together with Contractor to prioritize changes

Review, provide revisions and corrections, and give final approval for the post-pilot version of the training materials

15.1.4.2 Train-the-Trainer

The Train-the-Trainer program will prepare the SRS trainers for training delivery to the end users. The Accenture team will conduct the train-the-trainer program which includes four sessions – a project overview, a mock session of the trainer’s assigned course, at least one training practice run, and a supported session where the trainer conducts a session or portion of an actual training session with support from a project team member. Trainers who complete train-the-trainer receive certification to deliver training. These trainers will conduct any additional train-the-trainer sessions needed to train other personnel with training responsibilities.

Accenture will conduct 8 Train-the-Trainer sessions. This represents two full conducts of the Train-the-Trainer program.


Develop and conduct the train-the-trainer program, which shall be used to prepare the State’s trainers

Prepare constructive feedback for each trainer in the train-the-trainer program and provide that information to the State

Version 5.0


Recruit the State trainers who will conduct the end user training

Assist the Contractor in the development and delivery of the train-the-trainer program, which includes providing State content and context input to the materials

Review, provide revisions and corrections, and give final approval for the train-the-trainer material and courses

Ensure availability and attendance of the State trainers

15.1.4.3 Training Facilities

Training facilities consist of one Central Training Lab, located at the main project site, and temporary training facilities. Eligibility training will take place in the Central Lab and regional facilities identified, secured and managed by the State.


Configure and test Central Training Lab per required specifications

Provide guidance to the state on the requirements for regional training facilities to aid in identifying and establishing the sites

Work with the State to confirm site readiness


Provide final approval of Accenture’s plans for the Central Training Lab

Identify and coordinate setup of regional training facilities considering requirements guidance provided by Accenture

Test training sites to confirm preparedness for training delivery

15.1.4.4 Training Delivery

Training delivery includes conducting instructor-led courses and deploying web-based training courses and online help for the State end users identified in Appendix 8 of the RFP. The Accenture team will deploy WBT and online help, as well as compile results from training evaluations. Accenture will lead Instructor-Led Training, while the State will provide the staff to support the delivery of instructor-led training. This includes the following:

1. The SRS-specific content for the integrated Eligibility course. Because the SRS-specific information is integrated throughout the Eligibility course, training delivery will be accomplished

Version 5.0

by team teaching the Eligibility course with a K-MED/Avenues instructor. This helps confirm users gain an integrated view of the system, provides support from both agencies when users have questions, and also provides extra help in the classroom for assisting users as they complete their online exercises.

2. Imaging/Content Management training

3. Virtual Contact Center training


Deploy web-based training courses and online help

Compile and report on training evaluation results weekly

Provide Lead Instructor during teaching of Eligibility course


Ensure user availability to attend the required training

Provide support Instructor for instructor-led training courses

Administer evaluations in the classroom

15.1.4.5 Training Administration

Training administration will involve the activities associated with managing and administering the end user training program. It includes for example, training registration, reproduction of materials, collecting training evaluation results, scheduling courses and scheduling trainers. It also includes administering, collecting, analyzing and reporting the training evaluations. The Project Training Lead would manage the coordination of training facilities, as well as training administration tasks including training scheduling and rescheduling, course completion/attendance tracking, and administering course evaluations. SRS will help confirm successful delivery of training by assisting with administration and analyzing training evaluation results. In addition, Accenture will execute a one-time data extract from Moodle to Pathlore.


Run training reports

Assist in the analysis of the training evaluation results and recommendations for remediation

Schedule training facilities

Perform scheduling and rescheduling of training participants

Track course/completing and attendance

Version 5.0

Administer course evaluations

Coordinate the scheduling of instructors

Complete a one-time data extract from Moodle to Pathlore.


Assist in scheduling training facilities

Assist in performing scheduling and rescheduling of training participants

Assist in tracking course/completing and attendance

Assist in administering course evaluations

Assist in coordinating the scheduling of instructors

Ensure appropriate and timely completion of training registration for their users (local offices)

Review training evaluations and work with Accenture to make adjustments to training presentations and/or materials for future instructor-led training sessions; provide final approval on all changes and adjustments

15.1.4.6 Training Transition

Accenture would develop and implement the Training Delivery Transition Plan that would address the approach and implementation for transitioning training roles, training responsibilities, and training materials to SRS Training staff.


Work with the State Training Lead to perform knowledge transfer activities

Provide electronic versions and any appropriate paper-based training materials to SRS

Hold work session with SRS trainers and training developers to answer questions that they may have about the training materials and/or their development process


Participate in knowledge transfer and transition activities


The table below summarizes the responsibilities associated with training:

Version 5.0

Scope Element Accenture State Analyze End User Training and Support Needs Lead Assist

Approve Training Curriculum Assist Lead

Design Training Materials Lead Assist

Build and Test Training Lead Assist

Create online Help Lead Assist

Create any policy-related materials Lead

Recruit State Trainers Lead

Conduct Train-the-Trainer Lead

Training Administration Lead Assist

Provide training facilities Lead

Prepare and test training facilities Assist Lead

Deliver Training Lead Assist


None

15.4 Deliverables

The table below summarizes the training deliverables to be created during each phase:


Description

17 Analyze Training Plan The Training Plan describes the end user training approach and high-level curriculum. The training plan will provide training course recommendations, estimated duration, training methods and tools, and the training development and delivery approach and schedule.

NA Design Training Designs (work product – not a paid deliverable)

Training Designs contain information regarding learning objectives, suggested content, and estimated duration, and validate the suggested deployment method.

19 Build Training Materials The Training Materials consist of the instructor-led and web based content developer for end user training, as well as online help procedures and job aids as defined by the Training Designs.

NA Deploy Training Delivery Transition Plan (work product – not a paid deliverable)

Describes the approach for transitioning training roles, training responsibilities, and training materials to SRS Training staff.

Version 5.0

16.0 Knowledge Transfer Services


Project Management Leadership is ultimately responsible for confirming effective knowledge transfer takes place on the project. Other responsibilities will be divided as follows:

Enterprise Readiness Team (also referred to as the Change Management Team):

The Enterprise Readiness team will be responsible for facilitating the activities that occur between the Accenture team and SRS personnel that prepare SRS to support the system long term. The ER team will create the templates used for knowledge transfer activities, track overall knowledge transfer progress and report to the State.

Individual Team Leads:

The individual Accenture team leads are responsible for documenting and monitoring knowledge transfer activities on their teams to confirm that it is taking place to the expected level and within the expected timeframes. Teams use Personal Learning Plans to document and track knowledge transfer for each SRS individual who needs to maintain and operate the system after implementation.

The Knowledge Transfer services activities described in this section will be completed in the described phases, with a target completion of post-implementation of Phase 4. Activities will begin per the project plan



During the Analyze Phase, the Accenture team works with the SRS to confirm the list of roles targeted for knowledge transfer and the knowledge transfer tools and templates to be used for the project .

16.2.1.1 Identify Roles

The final list of roles will be confirmed by the SRS Project Manager. Examples of specialized roles that will participate in knowledge transfer include the following:

Configuration Team Member

Configuration Manager

Security Analyst

Infrastructure Lead

Version 5.0

Network Administrator

System Administrator

Developer

Business Analyst

Tester

Policy Analyst

Help Desk/support personnel

The Enterprise Readiness team works with the specific team leads and the State to determine the right mix of formal training, small group walkthroughs, and informal knowledge transfer for each role. In some cases, side-by-side informal knowledge transfer alone is appropriate for the role. In others, the team leads will need to conduct small group walkthrough sessions. The approach will depend on the complexity of the material and on the number of people who need to receive knowledge transfer for the particular topic. The ER team will seek input and review from ITS when completing the analysis.


Work with the State to document final list of roles

Determine the appropriate knowledge transfer techniques for the roles

Coordinate input with ITS


Provide input into the roles analysis

Review and approve the Knowledge Transfer Plan

16.2.1.2 Knowledge Transfer Plan

The Enterprise Readiness team develops the Knowledge Transfer Plan. The Knowledge Transfer Plan includes information regarding the ongoing support organization, roles, and skills and capabilities needed by each role. The Plan will also include knowledge transfer methods, key milestones, the preliminary Personal Learning Plan template, and the preliminary knowledge transfer scorecard template. The Plan will also include the processes and tools used to conduct and assess the knowledge transfer activities.

Version 5.0


Document the Knowledge Transfer Plan, including the methods to be used for knowledge transfer, such as peer programming, shadowing, role sharing, and small group walkthrough training. Include preliminary knowledge transfer templates.

Assist in defining the post-go live organization structure


Define the Post Go-Live organizational structure (technical and functional)

Identify the State resources targeted to fill roles in the Post Go-Live organization

Address all personnel-related communications and interactions with candidates and their transition to the Post Go-Live organization

Review and approve the Knowledge Transfer Plan

16.2.2 Design Phase

During the Design Phase, the Enterprise Readiness team refines the templates and confirms their final format with SRS stakeholders. They also orient the Project Team to the Knowledge Transfer and PLP processes. If the functional and technical leads require support in creating outlines or planning for their small group walkthroughs, the ER Team will coordinate with the Training team or other resources.

16.2.2.1 Personal Learning Plans

Each individual working on the Avenues project creates a Personal Learning Plan (PLP). A Personal Learning Plan is a document that lists the activities, skills, or knowledge that a person needs in order to complete their post-implementation job tasks. These plans document the individual’s current skill level for a certain topic, the desired skill level, the Accenture mentor assigned to the PLP, the reference materials, the time frame, the percentage completion, the signoff, and any next steps for the transferor/mentor or transferee. During the Design Phase, the Enterprise Readiness team will confirm the PLP template with the State and orient the project team on how to use the PLPs.


Identify mentors for each of the personnel targeted for knowledge transfer

Develop the templates and processes to support the knowledge transfer program and confirm with the State. This consists of the Personal Learning Plan template, the Knowledge Transfer scorecard and the small group training walkthrough template

Orient the team on how to use the template to create PLPs for their team members

Version 5.0


Review and approve the knowledge transfer templates

16.2.2.2 Assess Knowledge Transfer Progress

The Enterprise Readiness team will initiate and facilitate assessment of the knowledge transfer progress, as outlined in the Knowledge Transfer Plan. The team will compile the results and summarize the information in the Knowledge Transfer Scorecard.


Support the State in its assessment of knowledge transfer progress

Compile the results and prepare the Knowledge Transfer Scorecard


Assess the progress of the knowledge transfer activities and progress as defined in the Knowledge Transfer Plan

Ensure State candidates participating in knowledge transfer are available, actively participate, and update their PLPs accurately and in a timely manner

Provide input to creation of the Knowledge Transfer Scorecard

16.2.2.3 Design Small Group Walkthrough sessions

Using the small group walkthrough template as input, the Accenture team leads will work with the State to create the design documents for any small group walkthrough sessions needed for their areas. An example is a Rules Maintenance walkthrough. The template consists of a simple outline listing the learning objectives, topics to be covered, length, hands-on exercises, etc.


Develop design documents, including exercise scenarios, for small group walkthroughs


Provide input into the walkthrough designs

Review and approve the walkthrough designs

Begin knowledge transfer/track on PLPs

Version 5.0

16.2.3 Build Phase

During the Build Phase, the Enterprise Readiness team will continue to facilitate assessment of the knowledge transfer progress, as outlined in the Knowledge Transfer Plan. The team will compile the results and summarize the information in the Knowledge Transfer Scorecard. The functional and technical teams will prepare to deliver walkthrough sessions.




Organize the necessary materials and data needed to facilitate the small group walkthrough sessions

Continue knowledge transfer/track on PLPs



Ensure State candidates participating in knowledge transfer are available, actively participate, and update their Personal Learning Plans (PLPs) accurately and in a timely manner


16.2.4 Test Phase

During the Test Phase, the Enterprise Readiness team will continue to facilitate assessment of the knowledge transfer progress, as outlined in the Knowledge Transfer Plan. The team will compile the results and summarize the information in the Knowledge Transfer Scorecard. Individual team leads will confirm the environments and data are in place to conduct their walkthroughs or other knowledge transfer sessions.




Confirm the technical environments and data needed to facilitate the small group walkthrough sessions


Version 5.0

Lead the knowledge transfer of testing tools (e.g. logging a defect) and procedures (e.g. steps to take to resolve a defect) through mentoring and shadowing activities with State staff



Ensure State candidates participating in knowledge transfer are available, actively participate, and update their Personal Learning Plans (PLPs) accurately and in a timely manner


Participate in mentoring and shadowing activities with Accenture staff

16.2.5 Deploy Phase

The Enterprise Readiness team will initiate and facilitate assessment of the knowledge transfer progress, as outlined in the Knowledge Transfer Plan. The team will compile the results and summarize the information in the Knowledge Transfer Scorecard. Individual team leads will conduct small group walkthroughs or other knowledge transfer sessions.


Monitor knowledge transfer progress





Monitor and maintain knowledge transfer tools such as blogs and chat rooms


Review the knowledge transfer scorecard

Version 5.0

16.2.6 Post Systems Support Phase

16.2.6.1 Assess Knowledge Transfer Progress – Post Systems Support

The team will facilitate assessment of the knowledge transfer progress, as outlined in the Knowledge Transfer Plan. The team will compile the results and summarize the information in the Knowledge Transfer Scorecard.







Monitor and maintain knowledge transfer tools such as blogs and chat rooms




The table below summarizes the responsibilities associated with Knowledge Transfer services:

Scope Element Contractor SRS State TeamDefine Post Go-Live organizational structure (functional & technical)

Assist Lead

Develop Knowledge Transfer Plan Lead Assist

Develop Personal Learning Plans for Post Go-Live Team Member (quarterly then monthly)

Lead Assist

Develop Knowledge Transfer scorecards Lead Assist

Assess Personal Learning Plans Assist Lead


None identified.

Version 5.0

16.5 Deliverables

The table below summarizes the Knowledge Transfer deliverables to be created during each phase:

Ref. No.

Phase Deliverable Name Description

8 Analyze Knowledge Transfer Plan The Knowledge Transfer Plan deliverable will define the approach used to prepare the designated Project Team resources for roles in the Post Go-Live Organization. The Plan will include:

Overall project approach to knowledge transfer and milestones etc

Methods, tools, and processes used to facilitate knowledge transfer

Description of the Post Go-Live Support Organization structure, roles and capabilities needed

Personal Learning Plan template Knowledge transfer scorecard template and processes

used to conduct and assess the knowledge transfer activities

26 Phase 2 Eligibility

Knowledge Transfer Scorecard

This deliverable summarizes the results of the knowledge transfer progress to date, against the plan. Results are summarized in a scorecard format as defined in the Knowledge Transfer Plan.

26 LIEAP Knowledge Transfer Scorecard



26 VCC Knowledge Transfer Scorecard



Version 5.0

17.0 Technical Infrastructure Build and Operations

The SRS Technical Infrastructure Statement of Work (SOW) will reference the K-MED Technical Infrastructure Build and Operations SOW as the SRS solution will be managed and executed to leverage the same technologies, methodologies, and activities that are defined in the K-MED Technical Infrastructure Build and Operations SOW.

17.1 Major Activities

The Contractor shall provide technical leadership and mentoring in planning, designing and building the technical infrastructure for the project. The Contractor will work with State personnel and synthesize the information to estimate the hardware required to support the required number of environments used during implementation. During implementation, the Development Environment will be built and maintained by the Contractor. The other 8 environments will be built and maintained by the Contractor with technical input from the State. In addition, the Contractor, with input from State personnel, shall be responsible for estimating the hardware requirements for the production system. It is envisioned that the equipment originally used for the User Acceptance Test (UAT) Environment will be used for the Disaster Recovery (DR) system. The Contractor shall assist the State in the planning and building of the off-site DR infrastructure. The Contractor shall lead the effort in developing a Disaster Recovery Plan. The Contractor will assist the Hosting Provider who will be responsible for overseeing a DR exercise 1-2 months prior to “go-live.”

The Contractor shall provide maintenance and operational support of the Project’s K-MED/Avenues technical infrastructure. This will include, but will not be limited to: keeping the operating system current, performing periodic backups and restores, creating and maintaining new instances of K-MED/Avenues, as required, and applying patches and fixes to all instances of K-MED/Avenues.

To expedite the Conference Room Pilots and Fit/Gap sessions, the Contractor shall furnish a Reference Environment. The Reference Environment is an off-site, hosted instance of the Worker Portal and the Self-Service Portal, with all commercial products from Oracle installed and configured. The State must provide the commercial product license keys prior to the installation of these products on the Contractor’s hosted servers. This instance shall be available 24/7 except for routine environment maintenance activities. The Contractor will communicate the planned down-time schedule to the State in advance.

Prior to production cutover, the Contractor shall apply all available service packs and updates such that the Worker Portal, the Self-Service Portal, commercial products, applications, databases, OS, and virtualization technologies shall be in their most current status unless both parties mutually agree that the risk and potential impact to “go-live” activities is greater than the impact of refraining from applying the latest service pack updates.

Version 5.0


Roles and responsibilities for managing the technical infrastructure and related activities are delineated in the table below. It is assumed that all applicable scope elements listed below apply to all instances of the hardware, databases and applications without specifying each.

Scope Element Contractor SRS - Avenues Team

Hosting Provider

Build & Design

Install Oracle Database Lead Assist

Setup Oracle Database Lead Assist

Implement Load Balancer Assist Assist Lead

Establish firewalls Assist Assist Lead

Apply fixes, patches and bundles as needed (when provided & available from APSP, Oracle, etc. and in consultation w/ team)

Lead Assist

Install commercial middleware software Lead Assist

Configure commercial middleware software Lead Assist

Install Master Data Management software Lead Assist

Configure Master Data Management software Lead Assist

Install APSP architecture and portal software Lead Assist

Install Business Intelligence Services/BI software Lead Assist

Setup Business Intelligence Services/BI software Lead Assist

Install Conversion software Lead Assist

Setup Conversion software Lead Assist

Install Batch scheduler software Lead Assist

Setup Batch scheduler software Lead Assist

Apply security to the DB level Lead Assist

Document strategy for building and maintaining environments Lead Assist Assist

Create production system database administration procedures Lead Assist Assist

Create technical readiness document Lead Assist Assist

Evaluate WAN capacity as it relates to the K-MED implementation Lead Assist Assist

Create the standard technical infrastructure configuration Lead Assist Assist

Create database instances:

Production Lead Assist Assist

Reference Lead Assist Assist

Integration Lead Assist Assist

Development Lead Assist

Interface Testing Lead Assist Assist

Conversion Testing Lead Assist Assist

UAT Lead Assist Assist

System Testing Lead Assist Assist

Training Lead Assist Assist

Emergency Fix Lead Assist Assist

Version 5.0


Hosting Provider

Performance tuning:

Databases Lead Assist Assist

Application servers Lead Assist Assist

Web servers Lead Assist Assist

Batch processes Lead Assist Assist

Online processes Lead Assist Assist

Develop software patches and fixes methodology Lead Assist

Create backup and recovery plan Lead Assist

Test and validate backup and recovery procedures in all environments (instances)

Lead Assist Assist

Develop Database change policies Lead Assist

Harden the web infrastructure components; install security patches, turn off unused services, etc

Assist Assist Lead

Establish remote access to Kansas development environment in accordance to DISC policies

Assist Assist Lead

Develop hardware installation strategy & plan Lead Assist Assist

Install & configure hardware (Development) Lead Assist

Install & configure operating system software (Development) Lead Assist

Install & configure hardware (Non-Development) Assist Assist Lead

Install & configure operating system software (Non-Development) Assist Assist Lead

Setup SAN drives Lead Assist

Install SAN drivers Lead Assist

Install backup system Lead Assist

Develop configuration migration procedures Lead Assist

Develop Standard technical infrastructure configuration and change management methodologies

Lead Assist

Document technical architecture Lead Assist

Document infrastructure design Lead Assist

Develop and document standard technical infrastructure configuration Lead Assist

Create the business continuity plan (Disaster Recovery) Lead Assist Assist

Develop DR procedures, providing detail steps necessary to bring DR site to Production Status

Assist Assist Lead

Conduct DR development meetings Assist Assist Lead

Create DR Execution Plan for the DR test exercise Assist Assist Lead

Architect, implement and test a disaster recovery process Assist Lead

Identify technical requirements Lead Assist

Define application architecture Lead Assist

Define technical architecture Lead Assist

Assess technical architecture gaps Lead Assist

Confirm technical architecture analysis and deliverables Lead Assist

Version 5.0


Hosting Provider

Transition technical architecture analysis deliverables Lead Assist

Design batch processing Lead Assist

Plan & conduct component test Lead Assist

Build and test application components Lead Assist

Size hardware for implementation Lead Assist

Size hardware for production Lead Assist

Operations

Define long term production support strategy Lead Assist

Create a production system operational model Lead Assist

Create production System Administration procedures Lead Assist

Create production system operation procedures Lead Assist

Establish criteria and plan for applying software upgrades from APSP, Oracle and other commercial vendors.

Lead Assist

Service Packs Lead Assist Assist

Application Bundles Lead Assist Assist

Patches & Fixes Lead Assist Assist

Apply software upgrades Lead Assist Assist

Updates & Fixes Lead Assist Assist

Establish plan for applying database upgrades from Oracle Lead Assist Assist

Perform Nightly Operations Assist Assist Lead

Operating System backups Assist Assist Lead

Database backups Assist Assist Lead

Web backups Assist Assist Lead

Other server backups Assist Assist Lead

Performance tuning (continuously): Lead Assist Assist

Databases Lead Assist Assist

Application servers Lead Assist Assist

Web servers Lead Assist Assist

Batch processes Lead Assist Assist

Online processes Lead Assist Assist

Cutover

Create production cutover plan Lead Assist Assist

Create detailed task lists and work plans for Cutover Lead Assist Assist

Create production cutover staffing schedule Lead Assist Assist

Create production cutover roles and responsibilities Lead Assist Assist

17.3 Deliverables

Ref. No. Phase Work Products DescriptionNA Analyze Technical Architecture Plan

Version 5.0

Ref. No. Phase Work Products DescriptionNA Build Web Portal Functional and

Technical Designs

NA Deploy Technical Architecture Installation and Knowledge Transfer

Version 5.0

18.0 SRS Quality Assurance

The Contractor’s Quality Assurance (QA) approach shall include the following:

1. Contractor QA representatives will meet periodically with K-MED/AVENUES Project Leadership to assess and review progress, recommend courses of action and help verify that quality is a focus for the outcome of the Project. The QA Review provides objectivity, independence, broad subject matter experience and a careful assessment of all viewpoints. The external QA Review also includes inspection of deliverables to assess technical quality, an evaluation of QA program metrics and interviews with managers from the K-MED/AVENUES Project.

2. Contractor will prepare a work product (Client Satisfaction Survey), the summary of which when completed, will be included in the QA Review. The findings of the QA Review will be documented.

3. Use of standard quality methodologies and performance metrics, e.g. rates of defect identification and fixes.

4. Layers of quality review.

5. Compliance with CMMI Maturity Level 4.

6. Adherence to quality guidelines and standards.

7. Work with an IV&V contractor that will be on-site to provide an independent assessment of project “health”. The Contractor shall provide the selected IV&V contractor all Project information they request and access to Project personnel for interviews.


The Quality Assurance approach includes the following major activities:

1. Develop quality guidelines for development and testing.

2. Conduct quarterly Quality Assurance (QA) Reviews that include the establishment and evaluation of stakeholder expectations.

3. Conduct annual Client Satisfaction Surveys.

4. Work with involved agencies and business partners to ensure adoption of and adherence to Project QA standards.

5. Review and adopt recommendations of an IV&V Contractor.

Version 5.0


1. Development of a Quality Assurance Plan.

2. Provide QA awareness and training to the Project Team.

3. Conduct Quality Assurance Reviews per the Project Plan.


1. Ensure Project activities are executed in adherence to quality standards.

2. Make the appropriate client stakeholders available for periodic meetings.

3. Respond to the annual Client Satisfaction Survey.

4. Assist involved agencies and business partners in meeting Project QA standards.



Quality Assurance Contractor KDHE-HCF-SRS Team

IV&V

K-MED/AVENUES Quality Plan Lead Assist Assist

QA Training for Project Team (what, who, how, when) Lead Assist Assist

Quality Guidelines (See Contractor’s proposal Section 7.1.3.16, pages 7-284 through 7-289)

Lead Assist Assist

Quarterly Quality Assurance Reviews Lead Assist Assist

Annual Client Satisfaction Surveys Lead Assist Assist

Present Project QA Standards to involved Agencies and Business Partners

Assist Lead Attend

Monitor Agencies and Business Partners to Ensure Adherence to Project QA Standards

Assist Lead n/a


There are no paid deliverables related to Quality Assurance.

Ref. No. Phase Deliverable Name DescriptionNA All Quality Assurance

Plan


The Quality Assurance Plan will outline processes, activities, roles, and monitoring practices fundamental for the implementation of a sound and robust Quality Assurance approach.

NA All QA Training

(work product – not

Two 2-hour training classes for the Project Team on quality control guidelines and processes.

Version 5.0

Ref. No. Phase Deliverable Name Descriptiona paid deliverable)

NA All Quarterly Quality Assurance Review Findings


Accenture requires that every project conduct formal, quarterly reviews, known as Quality Assurance Reviews. An Accenture Senior Executive, external to the K-MED/AVENUES engagement, conducts the review. The program’s foundation and success begins with an objective, quality Executive Sponsor for the State of Kansas. This executive meets quarterly with K-MED/AVENUES Project Leadership to assess and review progress, recommend courses of action, and help verify that quality is a focus for the outcome of the project. The QA review provides objectivity, independence, broad subject matter experience and a careful assessment of all viewpoints. The external QA review would also include inspections of deliverables to assess technical quality, an evaluation of QA program metrics, and interviews with managers from the K-MED/AVENUES project. The findings and recommendations are documented.

NA All Client Satisfaction Survey


Annual Client Satisfaction Survey provided to key Project Management and stakeholders.

Version 5.0

19.0 508 Compliance

The system delivered by the Contractor shall comply with State of Kansas Accessibility requirements. For additional details regarding the scope of work for 508 Compliance, please see Section 24 - Web Accessibility Compliance of the K-MED SOW.

Version 5.0

20.0 Help Desk

The Avenues Help Desk is the single point of contact for support and online services to manage and resolve incidents and problems. For the purposes of this section, any reference to Help Desk refers to the Business Help Desk unless stated otherwise.

Scope Definition

The SRS Avenues Help Desk will be an increment to the K-MED Help Desk. As per the SRS Ongoing Operations contract with the Contractor, the Contractor will provide the Help Desk support for the SRS increment along with the K-MED portion. The K-MED SOW will be the basis for the SRS increment. At the conclusion of the Ongoing Operations contract and as part of the implementation of the Virtual Contact Center, it is expected that the Contractor will assist the State in transitioning this functionality into the Virtual Contact Center solution.


1. Assist in the transition of the Help Desk functionality into the Virtual Contact Center solution.


1. Lead the transition of the Help Desk functionality into the Virtual Contact Center solution.

Responsibility MatrixThe table below summarizes the responsibilities.

Help Desk Contractor SRS

Develop the Help Desk Transition Plan Assist Lead

Deliverables and Work ProductsRef. No. Phase Work Product Description

NA Help Desk Transition Plan

Document the transition steps of the Help Desk functionality to be incorporated into the Virtual Contact center solution from the support by the Contractor.

Version 5.0

21.0 Continuity of Operations and Disaster Recovery


The Contractor shall develop and test Business Continuity of Operations and Disaster Recovery (DR) Plans as defined in RFP Sections A6.3.2.2.6.1 and A6.3.2.2.6.2, the RRO request, and in the Contractor’s proposal. The Contractor will coordinate plan development with the State (KDHE and SRS) and the hosting vendor. Each plan will be developed and tested prior to Phase 1, Phase 2, Phase 3, and Phase 4 releases. For each subsequent release, the plans and the tests will be built on earlier versions.

The Disaster Recovery Plan and periodic DR simulations must be executed to the satisfaction of the State to constitute “acceptance.” Test results must be available for review by State or Federal officials upon request.

After a release to production, the Disaster Recovery Plan must be tested every 12 months, and a written report of the outcome, corrective action plan, and revisions, if any, must be available within 90 calendar days of the completion of the test. This report, including test results, must be filed with the State Project Directors and any other agency authorized by the State or the Federal government.


1. Review applicable State requirements for Business Continuity, i.e. ITEC Policy 5300R1 - Business Contingency Planning and ITEC Policy 5310R1 - Business Contingency Planning Implementation. http://www.da.ks.gov/kito/itec/Policies/ITECITPolicy7310.htm

2. Develop Business Continuity of Operations and Disaster Recovery Plans for the scope of the technical architecture and Contractor operations of the Avenues System.

3. Conduct Disaster Recovery simulation exercises in cooperation with the State, the hosting vendor (if different), and State business partners as applicable. Draft corrective actions and provide debrief to the State and applicable business partners.


1. Review draft and final Plans.

2. Assist with Disaster Recovery simulation exercises.

3. Coordinate activities involving State agencies and State business partners.

4. Review results of simulation and participate in debrief.

Version 5.0



Continuity of Operations/Disaster Recovery

Contractor Hosting Vendor

KDHE-HCF/SRS Agency/Business Partner

Develop Business Continuity of Operations Plan

Lead Assist Assist Assist

Review Business Continuity of Operations Plan and Update Accordingly Prior to Each Release


Develop Disaster Recovery Plan for Phase 1 Lead Assist Assist Assist

Test Disaster Recovery Plan for Phase 1 Release by Performing Disaster Recovery Simulation








Revise Disaster Recovery Plan for Steady-state Operations


Test Disaster Recovery Plan for Steady-state Operations by Performing Disaster Recovery Simulation at 1 year intervals beginning 1 year after the Successful Phase 3 Disaster Recovery Simulation



The following deliverables are part of the Continuity of Operations scope.

Version 5.0

Ref No # Phase Deliverable Name Description

16 Design Continuity of Operations Plan The Business Continuity of Operations Plan details the Contractor core business processes and contingency plan in case of an emergency. The plan will identify triggers for activating plans and an establishment of a Business Resumption Team.

Additionally the Disaster Recovery section details the retention and storage of back-up files, hardware and networks. It also includes a staff chart and back-up procedures and support to accommodate the loss of online communications.

33 Test Continuity of Operations Exercise

A simulated test of a disaster is completed with a switchover to the DR environment. The test is focused on procedures for the switchover, restart of the application, and verification of critical application functions.

Version 5.0

22.0 Ongoing Operations

The Ongoing Operations statement of work includes the tasks associated with the design/build/test/release of enhancements for SRS. The state is responsible for managing the enhancement process, and Accenture will provide six resources to assist/support this process. The operations team will follow the Change and Release Management process as defined by the state. In addition, Accenture will continue to provide knowledge transfer to SRS staff throughout the duration of ongoing operations, and support Help Desk operations.

The Ongoing Operations effort begins with the implementation/go-live of SRS and continues for 12 months.

(NOTE: Production Support is handled through K-MED. This entails ongoing operation of a computer application allowing effective system maintenance. This includes monitoring performance and uptime, security issues, utilization of the system, transaction volumes, and related activities to monitor the production application.)


The Ongoing Operations effort is led by SRS and supported by six Accenture staff. During Ongoing Operations, Accenture is responsible for managing knowledge transfer activities, and supporting the enhancement process (as described below).

22.1.1 Knowledge Transfer

Knowledge Transfer is a two-way effort starting from project initiation through the duration of the contract. During Ongoing Operations our team will build on the knowledge transfer activities that have occurred throughout the project. These activities are made possible by creating a work environment where SRS and Accenture staff can work side-by-side to complete their tasks. By co-locating, and coordinating efforts, we create an environment where ‘shadowing’ becomes inherent. This will remain true for the SRS Operations Team.

During the course of the SRS project, the Enterprise Readiness (ER) team will be responsible for facilitating the activities that occur between the Accenture team and SRS personnel that prepare SRS to support the system long term. The ER team will create the templates used for knowledge transfer activities, track overall knowledge transfer progress and report to the State. We will continue to use these templates, processes and status reporting during the Ongoing Operations phase. Knowledge transfer activities will focus on the following areas:

Documentation of enhancement designs

Identifying system-wide impact assessments

Version 5.0

Build activities

Test activities

Release Management

General Configuration of APSP

(See Section 16.0-Knowledge Transfer Services of this document for more information on Accenture’s approach to knowledge transfer.)

22.1.2 Enhancements

Enhancements entail modifying existing applications in response to new or changing business requirements. Enhancements will be submitted through the change management process and approved by SRS.

Beginning with the implementation/go-live of SRS, the State managed operations team will perform enhancements. The capacity for Accenture resources is set at six resources for 12 months. The six Accenture roles will provide technical and functional support for the SRS enhancement effort, and will provide expertise across functional areas (such as forms/reports, online, rules, BPM, etc).

SRS will be responsible for managing and executing the enhancements. It is suggested that the SRS team consist of at least the following thirteen resources:

Team Role Resource Name Location Roll On Month

Roll Off Month

Total Months

Proj Mgmt Project Manager* State Deputy Mgr 1 State M1 M39 39

App Dev App Dev Team* State Developer 1 State M2 M39 38






Functional SNAP/TANF BA* Business Analyst 4 State M1 M39 39

Functional SNAP/TANF BA* Business Analyst 5 State M1 M39 39

Functional Subject Matter Expert*

State SME 4 State M1 M39 39

Functional Tester* State Tester 2 State M6 M18 13

Functional Tester* State Tester 3 State M6 M39 34

Implementation Bus Intel Dev* State Bus Intel Dev State M13 M21 9

Version 5.0

The capacity for SRS resources can grow at the discretion of SRS, according to the quantity/complexity of enhancements desired. Unless a change order is requested to provide additional support of the enhancement process, the Accenture capacity will remain at six.


The table below summarizes the responsibilities associated with Ongoing Operations services:

Scope Element Contractor SRS State TeamDefine Post Go-Live organizational structure (functional & technical)

Assist Lead

Identify, document, prioritize and implement desired SRS enhancements

Assist Lead

Perform knowledge transfer activities Lead Assist

Obtain stakeholder agreement Assist LeadUpdate use cases Assist LeadDefine/Update RICEFW inventories Assist LeadAnalyze integration solution Assist Lead

Design/Update Application & Database Assist Lead

22.3 Deliverables

The work product for the Operations team will provide SRS with a status report of results of the team activities.

Ref. No. Phase Work Product DescriptionNA On-going

OperationsOperations Status Report The monthly operations status report includes status for each

area of responsibility of the Ongoing Operations team. This includes enhancement support and knowledge transfer. This report is submitted monthly and is tied to the monthly maintenance e-billing.

Version 5.0

23.0 Print Mail

SRS will be handling print mail on their own. This document is intended to present how the solution will deliver the appropriate information (i.e., documents) to the SRS preferred print mail vendor.

The SRS Avenues printing solution is designed to effortlessly handle the maximum load of bulk printing. The central print architecture is split into a series of specific tasks, each task being executed by a batch module. The modules run in the proper sequence resulting in the print documents being sent to the Department’s bulk printing facility using their preferred mode of transfer, e.g. FTP.

The central print process involves taking document files from the document storage repository that are marked for central printing, organizing them into envelopes based on their destination, and generating PDF files known as print bundles that are sent to the central printing facility to be printed, folded, stuffed into envelopes, and mailed out to the customers.

The central print batch jobs are organized by the mailing priority of the documents to be printed; priority 0 means top priority, 1 means same day, 2 means next day, and 3 means seven day. This way all documents that will be mailed with the same priority are put in the same bundle and it is easier for the printing facility to identify the bundles and organize their print schedules accordingly, thus reducing printing and mailing errors.

The United States Post Office (USPS) handles envelopes without a zip code suffix differently than those with a zip code suffix. For this reason, our central print architecture has separate modules for handling addresses with and without the zip code suffix.

The bundler modules sort the documents with the same priority code first by zip code, then by zip code suffix, address and finally customer name. This ensures that two customers living at the same address do not receive their documents in the same envelope. The combination of an address and a customer name creates a unique destination and the central print batch jobs process one destination at a time rather than one record at a time.

The SRS Avenues solution incorporates smart cost saving features in the way it generates the print bundles. All printed documents addressed to the same destination are placed into one or more envelopes. Documents that require return envelopes are placed in the same envelope if they fit. So, if a destination is supposed to receive two separate documents, and each of the documents is required to come with a prepaid return envelope, only one return envelope is sent, thus reducing mailing costs. There exists a hierarchy to the return envelope type, and since only one return envelope can be placed in an envelope, the organization of print documents into envelopes includes logic to consolidate the documents

A final step in the print bundle generation is the barcoding of documents. A special vertical barcode is added to the top left corner of each page of the document. This barcode is used by the folding and stuffing machines to sort the documents and stuff them into the right envelopes. The simple barcode

Version 5.0

identifies the envelope number, page number, last page and a new zip code indicator. Since the documents sent to the central print facility are already sorted by zip code, the USPS gives a discount on the postage.


The table below summarizes the responsibilities associated with Print Mail:

Scope Element Contractor SRS State TeamDeliver the appropriate information (i.e., documents) to the SRS preferred print mail vendor

Lead

Perform Print Mail functions Lead

23.2 Deliverables

There are no deliverables or work products for the Avenues Print Mail solution.

Version 5.0

24.0 Post-Implementation Support

Post-implementation needs for the SRS-Avenues project will be addressed through implementation of the planned K-MED support approach. The K-MED approach includes support for users during deployment of the system and for a period of six months after Phase 2 implementation. Post-implementation support includes both onsite support and centralized support functions. Field staff can access multiple types of help easily and quickly, which helps minimize disruption to business functions and keep error rates and processing times low. Post-Implementation support includes:

Central Support Team – The Central Support team coordinates onsite support during deployment and for six months after deployment. They will be located in the Topeka project site, and will perform the following activities:

– Monitor deployment issues and coordinate support and communications as the issues are resolved

– Answer direct questions from Regional Support teams/provide answers for questions not resolved onsite

– Coordinate data clean-up efforts

– Forward issues and questions to the Help Desk as needed

– Identify trends and report to project management about consistent areas of concern

– Inform Training and Enterprise Readiness resources of areas that may need additional or different training or online help content to address user support needs

Regional Support Teams – Regional Support Teams, comprised of enterprise readiness, conversion, business analyst, and developer project team members, will travel across the state during deployment and in the 30 days after deployment to support users. They will provide direct support to users by answering questions, conducting system demonstrations, delivering ad hoc target topic training sessions, and helping users obtain support from other sources when needed. They will maintain regular contact with the Central Support Team to report status and receive the latest information on trends, project communication, and issue resolutions.

Change Agent support – Change Agents will support their assigned users by answering questions, assisting users in obtaining additional help, working with Regional Support Teams and the Central Support Team to report and resolve user issues, and keeping their local leadership aware of deployment and post-implementation support schedules and plans.

Help Desk – The Help Desk will take direct calls from users, record incidents, and track them to completion. Information about the Help Desk facet of post-implementation support can be found in the

Version 5.0

Help Desk section of the Statement of Work. Accenture will work to develop a strategy to incorporate the Help Desk into the Post-Implementation Support activities.


Please refer to the K-MED Statement of Work for details on the Post-Implementation Activities by Phase.

Version 5.0

25.0 Archiving (KEEP)

25.1 Analyze Phase

25.1.1 Analyze KEEP Requirements

The Contractor will determine how to accomplish the results defined in the KEEP interface requirements and the feasibility of implementing the KEEP interface functions during Phase 2 or 3 of the K-MED/AVENUES implementation. The results of the analysis may include the recommendation of specific functions to be implemented in separate phases if needed. The Contractor will lead an analysis of this change, and document the necessary plan to make implementation a success.


1. Confirm stakeholders and adhere to project governance and communication strategies.

2. Meet with State resources and obtain necessary knowledge and assistance from these resources to identify KEEP requirements and confirm business processes.

3. Document requirements and applicable use cases and business processes resulting from KEEP analysis meetings.

4. Define the conceptual data model required to support the solution plan.

5. Confirm Solution Scope required for successful data exchange between K-MED/AVENUES and the KEEP and the feasibility of implementing during one of the four phases of the K-MED/AVENUES implementation.

6. Confirm and adjust the Project Plan based on the outcomes of the Analyze Phase and the defined Solution Plan.

7. Develop the analysis document describing how to accomplish the results defined in the MMIS Member Beneficiary Subsystem requirements.


1. Provide technical assistance and expert knowledge to Contractor.

2. Make State Archives, Kansas State Historical Society and K-MED/AVENUES staff available for analysis and work sessions and meetings related to K-MED/AVENUES records analysis, K-MED/AVENUES-to-KEEP ingest plans, and K-MED/AVENUES to KEEP interface development.

3. Provide Accenture with the technical specifications and KEEP System architecture.

Version 5.0

4. Provide technical and business Subject Matter Experts (SMEs) for KEEP that can efficiently and accurately document/describe K-MED/AVENUES to KEEP requirements.

5. Assist in defining the requirements and applicable use cases and business processes resulting from KEEP analysis meetings.

6. Assist in defining the Solution Scope required for successful data exchange between K-MED/AVENUES and KEEP.

7. Assist in identifying adjustments to the Project Plan based on the outcomes of the Analyze Phase and the defined Solution Plan.

8. Make decisions in a timely manner.

9. Review and approve the analysis document describing how to accomplish the results defined in the KEEP requirements.

Joint State and Contractor Responsibilities:

1. Comply with the state’s Government Records Preservation Act (K.S.A. 45-401 through 45-414) and Public Records Act (K.S.A. 75-3501 through K.S.A. 75-3520) http://www.kshs.org/government/records/stategovt/recordslaw.htm

2. Contractor will comply with legal, regulatory or operational requirements to providing public access to the records.



K-MED/AVENUES to KEEP Analysis Contractor SRSAnalyze Phase

Document KEEP Interface requirements Lead Assist

Document record series to be impacted by K-MED/AVENUES and retained in KEEP

Lead Assist

Develop KEEP ingest Plan Lead Assist

Develop Applicable Use Cases Lead Assist

Develop KEEP Interface Analysis Lead Assist

Version 5.0

25.3 Other Considerations

Depending on the results of the analysis and design choices, additional scope may be required as a result of this analysis.

Specific performance expectations, deliverables, and other applicable items required to implement the solution will be determined following the analysis to support an appropriate contract Change Order. An initial estimate of implementation costs for the interfaces to KEEP are itemized below:

Deliverable NameTotal Work

UnitsCost per

Work UnitPayment Amount

Complex Mapping with a Complex Adapter 1 $81,912 $81,912

Complex Mapping with a Custom Adapter 1 $163,824 $163,824


Ref. No. Phase Deliverable Name DescriptionNA Analyze KEEP Analysis


Consolidation of analysis artifacts including requirements, use cases and solution plan.

Version 5.0

26.0 Virtual Contact Center

The SRS – Avenues Virtual Contact Center (VCC) team will be responsible for the design, development and deployment of a virtual contact center using Avenues workers in SRS identified locations statewide. The VCC will use SRS provided telephony and Interactive Voice Response (IVR) platforms built to deliver intelligent call routing, IVR customer self-service functionality, and K-MED CRM reporting resulting from Customer Service Representative (CSR) use of the APSP Communications Tab, and Voice over IP (VoIP) call handling with Quality of Service (QoS) tagging.

The SRS – Avenues Virtual Contact Center team will be comprised of representatives from the Contractor, SRS, and SRS- IT teams. The following high level responsibilities are defined for the Contractor and SRS and are further defined in the remainder of the virtual contact center section.

Component Provided By

Function Component Integrates With Integration Responsibility

Dependencies

IVR SRS, IVR Vendor

The IVR provides Avenues customer/program centric information to inbound callers. It collects caller provided information like SSN, Case Number, Language preference, etc. for further call processing

Telephony Platform. Integration enables passing of caller provided information from the IVR to the Telephony Platform.

Accenture / IVR and Telephony Vendors

Both IVR and Telephony Platform must support this integration

Telephony Platform

SRS, Telephony Vendor

The Telephony Platform receives caller provided information collected by the IVR, and uses it to route calls using Automatic Call Distribution (ACD) software.

The Telephony Platform

Siebel CRM. Integration enables retrieval of caller demographics or other data elements associated with caller provided information. The integration is also has the capability to enable screen pop functionality.

Oracle / Telephony Vendor

The Telephony Platform integrates with Siebel CRM through a Vendor provided Computer Telephony Integration (CTI) Application Server or Application Interface (API). This integration is essential for CSR screen pop functionality

Version 5.0

also passes selected caller provided information to Siebel CRM. This information is used to retrieve caller demographics, case information or other data used for CSR screen pop

Once ACD routing is determined by the Telephony Platform, the information gathered is sent to Siebel CRM which in turn sends caller data to the computer screen of the CSR receiving the ACD call. The computer / telephone association is made through the Siebel Desktop User Interface, described below.

Siebel CRM SRS, Oracle

Siebel CRM uses the caller provided information (passed from the Telephony Platform) to extract caller data from Avenues. This data is coordinated with ACD call routing and appears in the Siebel Desktop User Interface when the call is delivered to the CSR.

APSP. Integration provides retrieval of caller demographics, case information or other data to be used for CSR screen pop functionality.

Oracle/ SRS/ Accenture

Siebel CRM/ APSP integration required for caller demographics and case information retrieval

Siebel Desktop User Interface (UI)

Oracle Establishes link between phone and computer on CSR desktop through CSR login in the Desktop User Interface

Siebel CRM. The integration allows Siebel to determine the associated desktop for data delivery once an ACD destination has been provided by the Telephony Platform through the CTI link

Oracle ACD identification (CSR ID) must be a passed between the Telephony Platform and the Siebel CRM for the CSR phone/computer association to be made

Version 5.0


Facilitate all VCC detailed design meetings for the build, configuration and implementation of the VCC

Develop, test, and deploy call routing strategies aligned with SRS business process decisions

Integrate the IVR with back-end database systems to support customer self-service capabilities

Modifications to the APSP Communications Tab, reflecting the collection and reporting of SRS-Avenues required CRM data, if different from K-MED

Development and execution of test plans for call routing, IVR self-service functions, and Communications tab data collection and reporting

Develop the organization structure, transition plans and training plans for VCC staff, including the creation of CSR and VCC Supervisor/Manager Role descriptions.

Analysis of Toll Free voice network facilities to accommodate consolidated VCC call load

Mentor SRS testing staff on the development of test plans for future functionality.

Document all VCC detailed designs for review with SRS-IT staff

Assist with Data Network Analysis/Sizing for VoIP test and deployment

Assist SRS staff with recommendations for office reconfiguration to accommodate VCC


Providing direction for the development of call routing strategies. This includes determination of functional CSR groupings that include; program type, call type, and customer language selection

Providing base IVR and telephony systems

Providing the Contractor with administrative access to VCC base systems, IVR, Telephony, and associated databases or other SRS systems, as required

Staff the VCC team with State personnel that are qualified in their area of participation (IVR, VoIP Telephony, Voice and Data Networks, Automatic Call Distribution (ACD)).

Acquisition of necessary hardware, software, and network facilities required for the build out of the VCC. This includes change orders with suppliers and vendors of existing VCC infrastructure

Provide training staff for instruction of VCC Customer Service Representatives

Version 5.0

The following VCC implementation steps are in scope. An implementation step is defined as a functional component required for the deployment of the Avenues Virtual Contact Center.

VCC Platform Implementation Steps

IVR 10 Simple Call Routing Patterns1 5 Moderate Complexity Call Routing Patterns2

Database integration with APSP Telephony platform integration3

Develop and execute IVR test plans Create detailed design document of Avenues IVR end state build out IVR knowledge transfer to SRS staff

Telephony System / Automatic Call Distribution (ACD)

Assist SRS-IT staff with analysis of SRS data network for required VoIP capacity VoIP Telephony design, test and deployment to SRS offices or other Avenues

workers Conduct call capacity analysis for consolidated toll free service for statewide

calling Assist SRS-IT staff with resizing of voice network circuits, if necessary Establish skills based routing through the ACD Identify individual offices in ACD routing patterns for effective closure

procedures Standard ACD reporting Assist SRS trainers with the development of VCC CSR curriculum for

Telephone/ACD use Create detailed design document of Avenues Telephony / ACD end state build

out Telephony / ACD knowledge transfer to SRS staff

K-MED CRM Functionality Modify APSP Communications Tab to capture SRS-Avenues required data, if different than K-MED

Create detailed design document of Avenues Communication Tab K-MED CRM functionality knowledge transfer to SRS staff

1 Simple Call Routing Patterns employ no database calls, providing callers static information, e.g., program descriptions, hours of operation, addresses of local offices, etc.2 Call Routing Patterns with Moderate Complexity have 1-3 database calls, using integration with back end database systems to provide secure, caller specific information, e.g., application status or program eligibility.3 May not be attainable if systems referenced are incompatible or do not have this capability

For clarity, the following steps are out of scope for SRS –Avenues:Related VCC Platform Out of Scope for SRS – Avenues

IVR Professional recording of IVR voice files Complex Call Routing patterns4

IVR outbound calling campaigns – broadcast IVR outbound calling campaigns – predictive or preview dialing Load testing of the IVR

Telephony System / Automatic Call Distribution (ACD)

Call Recording / Screen Capture CRM integration with APSP or any other CRM application (providing screen

pop, or other integrated functions) Extension of VoIP capabilities to Avenues workers using cell phones as their

primary method of voice communications Development of ad hoc or customized ACD reports Load testing of the VoIP telephony deployment

Version 5.0

Related VCC Platform Out of Scope for SRS – Avenues

Video calls

VCC – General Duplicate system implementation for Disaster Recovery / Business Continuity CSR unified desktop providing links to Avenues ECM, APSP, or other external

systems4 Complex call routing patterns employ 4 or more database calls or collect caller supplied data for compilation and reporting.

Customer surveys are one example of an IVR complex routing pattern.


26.1.1 Analysis

26.1.1.1 Virtual Contact Center Analysis

The purpose of the analysis effort is to identify SRS requirements related to VCC customer contacts. The VCC team analyzes customer contact criteria provided by SRS and develops call routing strategies that work within the SRS Avenues IVR/Telephony framework. These strategies employ the dissemination of public information (e.g., program descriptions, eligibility requirements) or caller specific information (e.g., customer application or eligibility status), and the statewide routing of calls to properly trained CSR resources. The VCC analysis phase focuses on:

1. Gap analysis of current IVR capabilities and those required under SRS – Avenues.

2. The impact of call consolidation on existing toll free circuits – determination of anticipated call volumes

3. Call consolidation impact on IVR port size and licensing

4. VoIP hardware/software/licensing for existing telephony platform

5. Analysis of data network capacities required for the deployment of a statewide VoIP solution

6. Verify IVR / Telephony integration required for passing call routing variables

7. Verify ACD capabilities required for intelligent call routing

8. Selection of web portal service calls to be used for customer specific inquiries (database dips that provide the same secure information available through the Customer Portal)

9. Identification of customer contact resources by program knowledge (skill) and language capability (if bilingual support is required).

Version 5.0


Conduct meetings with SRS and SRS-IT to identify IVR self-service requirements and define call routing through the VCC

Assist SRS-IT with technical assessments of existing voice and data networks, and the processing of change orders with network providers, as required

Perform Gap Analysis to identify gaps between legacy IVR and telephony systems compared with Avenues VCC requirements

Work with SRS-IT, and IVR and telephony vendors to determine the level of integration permitted between systems

Work with SRS-IT and APSP personnel to determine SRS-Avenues changes required in K-MED Communications Tab

Report integration issues and impacts to SRS.




Provide Subject Matter Experts (SMEs) for each VCC system and related network.

Process network change orders to provide VCC required voice and data capacities

Process change orders on existing IVR / Telephony platforms to meet Avenues VCC requirements

Assist in the development of high-level test conditions and expected results. If legacy IVR /telephony functionality is reused in the delivery of Avenues, SRS will take responsibility for testing those portions of the legacy systems.

Review and approve the Gap Analysis. This is an important activity since the integration of multiple systems is key to the attainment of VCC objectives.



Version 5.0

26.1.2 Design Phase

Based on the requirement definitions and analysis done to this point, the Virtual Contact Center design phase specifies the IVR, Telephony and K-MED CRM components that will be required for VCC. The design specifications will:

1. Refine the initial Gap Analysis and document processes needed to address each gap

2. Confirm the level of IVR/Telephony integration

3. Confirm the IVR use of APSP web services for data retrieval

4. Confirm the K-MED Communications Tab changes in APSP

5. Confirm reuse of existing IVR/Telephony programming, if required.

6. Confirm the web services to be used in the IVR

7. Confirm network capacities for VCC voice and data networks

8. Detail the statewide VCC organization structure and floor space reorganization, by office, if required


Provide SMEs for IVR and Telephony design

Provide SRS-IT with voice and data network analysis indicating the need for circuit change orders

Lead design of intelligent call routing strategies base on Avenues requirements

Work with SRS equipment vendors to verify systems integration design

Work with APSP SMEs to incorporate APSP web service calls into the IVR design

Work with APSP SMEs to modify APSP Communications Tab, if needed

Escalate system integration issues to SRS

Create VCC systems design documentation

Create VCC Organizational diagrams including Management/Supervisory structure and CSR groupings by skill/program/language

Create revised floor plan documents for VCC offices requiring change

Initiate mentoring with SRS team members for project design.

Version 5.0


Evaluate call routing strategies to ensure compliance with Avenues customer contact directives.

Assist the Contractor with the development of the Design Documents.

Confirm selected web services will provide the specific information required

Confirm APSP Communications Tab changes

Assist with equipment vendor meetings for integration design

Assist Contractor with documentation of VCC staffing by office, skill, program, and language

Provide Contractor with floor plans of all new or existing VCC offices

Actively participate in design mentoring activities

26.1.3 Build Phase


Produce Detailed Design documents for the VCC systems functionality approved during the Analyze Phase.


Produce Detailed Design documents for IVR call routing and self-service functions

Produce Detailed Design documents for the Telephony System / ACD call routing functions directed to VoIP endpoints, by skill

Produce Detailed Design documents for VCC voice and data networks

SRS Responsibilities:

Assist the Contractor with the development of the Detailed Design document for the VCC IVR, Telephony system, and end-state voice and data network design.

Review and approve each of the Detailed Design Documents


The Virtual Contact Center Team will code and unit test each VCC system.


Code the IVR and Telephony systems with VCC designed call routing patterns

Version 5.0

Program IVR/Telephony integration

Program IVR/ Database integration using APSP web portal web services

Work with APSP SMEs to modify APSP Communications Tab functionality, as required

Create platform specific test-scripts

Conduct and document VCC systems testing as part of the development documentation

Work with SRS training staff on the development of VCC training modules

Create mentoring opportunities for State teammates during VCC platform builds


Review and approve the system test-scripts and system test results developed by Contractor

SRS training staff begins development of CSR training modules

Actively participate in build out of each VCC platform / application

26.1.4 Test Phase

26.1.4.1 VCC IVR Testing

The Virtual Contact Center Team will conduct end-to-end testing on call routing patterns in the Avenues IVR. This includes testing of simple and moderately complex route patterns and their associated voice files and database lookups.


Develop, plan, and execute detailed test plans for all VCC IVR call routing patterns and functions, including informational messages and database integrations

Execution of test plans related to call routing for dissemination of general information, including SRS office locations, hours of operation, program descriptions, and other required messages. Testing to include accurate routing and messaging for bilingual callers, if required

Execution of test plans related to all call routing patterns requiring retrieval of database information for callers seeking specific information related to their application or case status (web services testing)

Mentor State team members in the development and execution of IVR test scripts

Version 5.0


Assist with verification of call routing patterns and the accuracy of information provided in each

Assist with the development and execution of IVR test plans

Provide client test case information for database retrieval, including multiple test clients with data for each testable parameter (application status, program eligibility information, etc.)

Actively participate in the development and execution of IVR test scripts

Review and approve IVR test results

26.1.4.2 Telephony / ACD Testing

The Virtual Contact Center Team will conduct testing of VoIP telephony for each Avenues office location during normal production hours to ensure proper Quality of Service (QoS) tagging and adequate data bandwidth for all CSR required applications, including VoIP. This testing will be done in conjunction with ACD skills-based routing tests that will verify call routing to appropriate CSR agent groups across the state.


Execution of test plans related to all CSR identified skills, including program related and language related CSR call queues

Develop, plan, and execute detailed test plans related to all VCC Telephony and ACD functions, including VoIP testing for IP telephony in each VCC location, and ACD routing and reporting

VoIP quality check to ensure near toll quality voice transmission to each IP connected telephony location

Test ACD office closure procedures for each Avenues VCC location

ACD information storage and retrieval using standard ACD reports (platform dependent)

Verify statewide access to the consolidated toll free number used for IVR/Telephony access

Verification of IVR / Telephony integration through caller qualified identification being collected in the IVR and passed to the telephone system.

Verification of APSP Communications Tab functionality, including customer data retrieval from APSP

Verification of APSP Communications Tab reporting, including contact type, contact duration, CSR identification, reporting by location, and other specified parameters

Version 5.0

Mentor State teammates in the development and execution of all telephony / ACD test scripts

Support SRS training staff for VCC CSR training sessions

SRS responsibilities:

Assist with Telephony / ACD testing for statewide access, skills based routing, office closure procedures and systems integration.

Active participation in the development and execution of ACD / Telephony systems test scripts

Review and approve Telephony / ACD test results

Initiate VCC CSR training sessions

26.1.5 Deploy Phase

26.1.5.1 IVR deployment:

The Virtual Contact Center Team will execute a “flash cut” installation of the VCC IVR. Following the successful completion of the IVR testing and at an SRS approved time, the new VCC IVR code will be promoted into the Avenues production environment.


Promotion of the VCC IVR code from the Avenues test to production environment

Monitor toll free line access(voice network) to the IVR system

Monitor IVR port capacities to ensure customer access

Monitor IVR performance with regard to system integration and web service functionality.

Mentor State team members for functional monitoring and ongoing support of the IVR


Assist with IVR performance monitoring following IVR go-live

Actively participate in post-deployment IVR mentoring

Review and approve successful IVR deployment

26.1.5.2 Telephony /ACD deployment

The Virtual Contact Center Team will execute a phased installation of the VCC Telephony / ACD platform. Once VoIP testing on the telephony platform has been completed, a staged approach will be used to roll

Version 5.0

out VCC functionality to Avenues locations across the state. This staged deployment will use the VCC programmed capability of closing individual offices. In this way the VCC team will be available to each office for “day-one” support as VCC functionality rolls out.


Promotion of the VCC Telephony / ACD code from the Avenues test to production environment

Monitor skills based routing, including CSR availability, queue times, and abandon calls

Monitor CSR use of APSP Communications Tab

Assist SRS-IT with data network performance monitoring for VoIP active location

Mentor State team members for functional monitoring and ongoing support of Telephony / ACD systems


Assist with go-live monitoring of VCC Telephony / ACD functions during staged call center roll out

Provide vendor liaison support with voice and data network providers, as necessary

Actively participate in post-deployment Telephony / ACD mentoring

Review and approve successful VCC Telephony / ACD

The table below summarizes team responsibilities for the Virtual Contact Center implementation.

Scope Element Contractor SRS TeamCreate call routing patterns (IVR) Lead Assist

Gap Analysis of existing IVR/ Telephony systems Lead Assist

Order hardware/software for IVR/Telephony systems Lead

Voice network analysis (toll free call consolidation) Lead Assist

Data network analysis (VoIP capacity) Assist Lead

Voice / Data network change orders Lead

IVR / Telephony Integration Lead Assist

APSP Communications Tab modifications Lead Assist

IVR/ Database Integration (web services) Lead Assist

VCC Training Curriculum development Assist Lead

ACD reporting Lead Assist

VCC knowledge transfer Lead Assist

Develop cutover plan Lead Assist

VCC testing Lead Assist

Version 5.0


None identified.

26.3 Deliverables

The table below summarizes the virtual contact center deliverables/work products to be created during each phase:


Description

41 Deploy Virtual Contact Center Deployment

The Virtual Contact Center Team will execute a phased installation of the VCC Telephony / ACD platform.

42

Design Organization Design for Virtual Contact Center

The Organization Design for the SRS-Avenues Virtual Contact Center documents the infrastructure and staffing required to deploy a statewide call center. This design incorporates intelligent call routing through the VCC IVR, skills based routing to CSR resources across the state, and program efficiency gains using IVR self-service.

43 Design Virtual Contact Center Detailed System Design

Based on the requirement definitions and analysis, the Virtual Contact Center detailed design document specifies the IVR, Telephony and K-MED CRM components that will be required for VCC.

44 Test Virtual Contact Center System Test Plan

45 Test Virtual Contact Center System Acceptance

46

Design - Deploy

Virtual Contact Center System Documentation and Knowledge Transfer

Working in collaboration with SRS personnel, this deliverable will document the design, build and testing of each Virtual Contact Center component. A resource that is available to SRS staff who may be new to VCC, it is also a living document that details the continuing change that will occur as the VCC adapts to changes in program, policy and technology.

Version 5.0

27.0 Business Process Reengineering (BPR) and Business Process Improvement (BPI) – Change Management

During the Business Process Reengineering and Business Process Improvement phase, we conduct an assessment of which business processes will impact SRS such that they need to be included in the Design Phase. The BPR work effort is expected to be completed by Change and Innovation (CIA), in conjuction with Accenture. Any Business Process changes that are not included in the Design Phase could be deferred to a post-implementation work effort.

27.1 Business Process Reengineering and Business Process Improvement

Business activities and tasks are necessary to plan and prepare for SRS deployment of enterprise readiness staff. Business Process Reengineering and Business Process Improvement will include the plans, communications and activities necessary to get SRS staff ready for the new processes that accompany the integrated K-MEDS and Avenues System.

27.1.1 Perform Business Process Reengineering (BPR)/Business Process Improvement (BPI)

Accenture will provide the appropriate staff with Business Process Improvement expertise during the initial window in the project to research, evaluate, and identify new business processes. This will include, but not be limited to the establishment of a Concept of Operations document. SRS will have staff to work with these experts and an initial draft Concept of Operations for consideration.

Accenture will provide a staff person familiar with the proposed eligibility system to work with this team to:

• Help identify a plan of implementation of the new business processes.• Work with SRS to establish and maintain a model business process office.• Aid the state in the rollout of these new processes, training, education, and any other aspects of

successfully transitioning the organization to the new business processes.

The Accenture team will use a six-step method to conduct business process improvement for the Avenues project:

Assess the Organization Confirm the As-Is Business Processes / Conduct Leadership Strategy Session Use an internal team of Eligibility, Policy, Operations, Clerical Staff to Define/Enhance the To-Be

Business Processes Identify the Gaps Document the Actions Required to Close the Gaps Verify the To-Be Business Processes are efficient and effective once implemented

Version 5.0

27.1.1 Business Activities and Tasks

Listed in the table below are Business Activities and Task that Accenture will lead and SRS staff will assist.

Business Activities and Tasks Business Activity and Task Descriptions

Organizational Assessment Time spent in local offices reviewing operational data, observing customer interaction with the system, interviewing staff and clients, and meeting with mangers. This assessment prepares us to meet with management and teams.

Define/Enhance the To-Be Business Process Team work to redesign non-system related business processes– example: whether you process verifications on the spot or batch it, the technology won’t be different – but timeliness will be.

Note: The decision about caseloads will be made in the team redesign phase.

Identify Gaps and Document Actions to Close Gaps Gaps identified such as poor verification practices / policies; scheduled appointments; batching of registrations, etc.

Skills Needs and Gap Assessment Will identify local management gaps and address with training for the new process.

Human Resource Capacity Will identify recovered resource capacity opportunity with new processes – typically 20% - 30% per office.

Leadership training and strategy session Will conduct following the Process Assessment. Half day of training combined with a strategy session for setting up Process Team

Process Redesign Team Leadership and facilitation of this team to map and assess current processes, as well as redesign the new business process for the State of Kansas. Deliverables include: Process Recommendations, standardized interview scripts, Standardized documentation prototype, Policy change recommendations, Procedural Manual, Process Measures; Implementation Plan

Implementation Blitz Teams Leadership of 1-2 day sessions where staff are finalizing the deliverables once approved by Agency Leadership

Facility Readiness Working with local leaders on a weekly basis going through implementation plans, informing SRS of any roadblocks, providing management training.

Process Management Go-Live Support Provide a team of 3-5 over a very structured 4-day implementation of the new process.

Version 5.0

Business Activities and Tasks Business Activity and Task Descriptions

Core Team Capacity Building Develop a group of internal experts to carry on with roll-outs (usually after 10-15 offices).

Review of Performance As offices go-live, we will initially facilitate a weekly phone call between office managers and the SRS operations leader to discuss performance, find consistent fixes, etc. The results of these calls will be documented and distributed to the appropriate individuals.

Process Planning for the next 14 offices Conduct shorter planning sessions with three facilities per session to build their Process Management Plans

Facility Readiness and Go-Live Support for next 14 offices Review implementation plan progress, provide management training. - Provide a team of 3-5 over a very structured 4-day implementation of the new process.


Create the SRS Business Process Reengineering approach and teach the approach to State partners to assist in carrying out the activities.

Research, evaluate and identify new business practices.

Identify a plan of implementation of the new business processes, work with SRS to establish and maintain a model business process office, and aid the state in the rollout of these new processes, training, education, and any other aspects of successfully transitioning the organization to the new business processes.

Measure the benefits of the changes by collecting business process metrics via detailed performance reporting during the Model Business Office.

Conduct the assessment activities and communicate the results iteratively with key stakeholders to refine the approach as needed along the way.

Work with SRS to understand the factors that influence appropriate organizational design decisions such as:

o The agency’s mission and how the new technology strengthens ito Shared values, the beliefs that guide actions and behaviors within the organizationo Core competencies, what the agency does really well and wants to continue doing

wello Key Performance Indicators, what and how SRS measures success.

Analyze your organization charts, position descriptions, and the work you have already done to document your as-is processes.

Version 5.0

Participate in BPR/BPI activities and project fit gap analysis sessions to gain an understanding of the to-be business processes.

Conduct a SWOT analysis to identify and document the strengths, weaknesses, opportunities and threats that influence SRS’s ability to achieve the project’s objectives.

Facilitate working sessions with SRS personnel to identify the impacts of the new processes on the organization and job roles. We foresee multiple sessions so that we can spend adequate time with the various business units, ITS, and SRS leadership.

Document information about the current organizational model and behaviors. Develop initial suggestions for the future organizational model and how team policy should

occur. Once we present the initial recommendations to SRS leadership and other personnel SRS

identifies, we refine the Organizational Assessment to reflect the feedback. Upon acceptance of the initial recommendations, we work with you to identify specific SRS staff to participate on the Organizational Change Team. We see this team as a natural part of the overall Change Management team who is already in place on the project to support the change management efforts.

Designated SRS and Accenture change management team members work together with HR to create more detailed recommendations and perform the analysis required to modify organization charts, job roles, skills requirements, capacity planning, and transition activities.

Conduct the ITS Organizational Assessment effort. Evaluate the ITS organization and produce the deliverables associated with the state’s requirements, including resource needs (both the SRS and third party models), training needs, skills sets, a knowledge transfer/mentoring plan and a recommended IT governance strategy.


Provide detailed and comprehensive list of the As-Is Business processes and and indication of the variations in these As-Is processes among local offices, where available.

Assist the Contractor in the research, identification, and evaluation of new business practices.

Assist in the development of the Concept of Operations document. Provide input regarding stakeholders and levels of involvement.

Assist the Contractor in identifying a plan of implementation of the new business processes.

Establish and maintain a model business process office, and participate in the rollout of these new processes, training, education, and any other aspects of successfully transitioning the organization to the new business processes.

Provide staff to attend and participate in the Model Business Office to test new processes.

Version 5.0

Provide a select pool of SRS Staff (e.g. Change Agents and BAs where available) in the BPI effort. We recommend selecting participating users from various offices across the state that the K-MED/Avenues solution must support.

The State will review the Organizational Assessment work products and participate in refining them prior to finalizing them.

Assist the Contractor in gaining access to the documents, plans, staff, and governance forums needed in order to conduct the organizational assessment.

Assist the Contractor in the development of the IT Organizational Assessment. Assistance includes identification and input regarding organizational charts, staff, access to interview and work with staff, and access to planning documents and governance forums.

The State would review the ITS Organization Assessment work product that will be included in the Organization Assessment deliverable.

27.2 Deliverables/Work Products

The table below summarizes the deliverables to be created during each phase:

Ref. No.

Phase Deliverables Description

2 BPR Assessment To-Be business model, business processes and workflow swim lane diagrams

Gap analysis of business processes and requirements

Detailed business requirements document including an established requirements traceability matrix

Federal Waiver and State Policy Impacts

2 BPR Plan Conversion Plan

2 BPR Office Implementation Pilot

2 BPR Office Implementation 2 - 15

Version 5.0

Version 5.0

APPENDIX

Version 5.0

SRS

Concept of Operations

Version 5.0

Initial Purpose of the SRS Concept of Operations (SRS Con Ops)

As the State of Kansas prepares to select a trusted business partner to jointly execute the K-MED and Avenues projects, it is important to ensure the partners share a common vision. Accenture and the State have been mildly introduced during the K-MED evaluation process, and the state has been able to further communicate its vision.

SRS has joined in the evaluation and procurement process of the K-MED project by including the scope of the Avenues project as an optional bid of the RRO. The Avenues project scope includes the eligibility, benefits administration, and case management for the means tested programs within the Department of Social and Rehabilitation Services (SRS) for the state of Kansas. These programs primarily reside in the Economic and Employment Support (EES) unit within the Integrated Service Delivery division of SRS.

To ensure alignment of expectations, this document describes the State of Kansas vision for the K-MED/Avenues system and what the state intends to achieve by successful project execution. The scope of this document applies mainly to the means tested programs administered by SRS.

Version 5.0

Current State Versus The Future State

SRS conducted a current state evaluation of their organization, processes and technology by conducting site visits and staff interviews which revealed a setting in which linear work and labor intensive processes are the rule, rather than the exception. The Information systems supporting the current environment provide little relief from the paper-based business processes, and in some situations, they contribute to the creation of additional paperwork. The following lists some of the major inefficiencies that are prevalent within the current environment and how we envision correcting these in the future:

Processes:

Current: The current processes are full of manual steps, rework, and handoffs. There is a certain level of rework that is inherent in handoffs of work; the person on the receiving end of the hand-off must review the work previously completed in order to complete his or her task. Hand-offs often leads to bottlenecks in the workflow. For example, when an application for EES benefits is received, in most of the offices visited, the application passes through at least four different staff members before it is processed. The application is handled by the receptionist, screener, a clerk who registers the application and the Case Worker. At any step of the process, the application can become bottlenecked or be returned to the previous worker.

Future: With the use of automation, an integrated work-flow engine, integrated business rules, content management, and the customer providing the majority of our data entry; rework and excessive handoffs will be eliminated or drastically reduced. The initial steps that are currently completed by SRS staff members to register an application can be automated and only exceptions will be processed by SRS staff. SRS understands there will be instances when human intervention is required as it is not feasible to try to put every situation into the business rules when trying to resolve people identification and household composition issues.

Current: The current processes are full of workarounds and manual steps. Case workers currently have paper case files for each of their assigned case located at or around their desk. There are no electronic case files. This limitation makes it necessary for customers who call in to make changes or request information to speak directly to their case worker rather than a more generalist staff member. If a customer moves or wants to relocate to a different office, staff has to copy the case file and mail it to the other office which delays the customer’s ability to work with that new office for a few days.

Future: Content will be captured electronically and the content management solution will be fully integrated into the new Avenues system. To the end user, the content management system is simply a part of their new benefits administration and eligibility system. Staff and customers will see all content related to a case on their user interface of the Avenues system and will be allowed to add additional content, view content, and delete content (with the proper security). Content will be viewable by staff and customers at a customer and/or case level. Customers and staff will have the ability to scan documents at an SRS office or at a community partner as well

Version 5.0

as sending in electronic documentation. The system will have the ability to index and automatically attach documents to a customer/case record given the proper information is supplied by that customer/staff. QA processes will reside in both the offices and the Records Management Center.

As a part of this effort, SRS will convert existing case file content for cases that are currently open. SRS will analyze which documents are necessary to convert and attempt to clean out the current case files in advance. Because the case files are needed in instances where a customer contacts their case worker, the case files will have to be converted at their physical location. SRS is open to doing this conversion prior to the implementation of the Avenues system. The hardware and software necessary to convert these documents could be implemented at a location at a time and we could convert location by location, moving the larger scanning equipment to the next location. We understand this will require training of our staff and the utilization of a stand-alone content management system prior to the implementation of Avenues.

Current: With some exceptions, limited knowledge of programs within and outside of SRS leads to limited referrals for customers to other SRS and community-based services. Some of the smaller offices in the Southeast Region have employed generalists who screened for all programs and worked closely with outside agencies to become aware of services available in the community. This model worked well for customer service but given current economic conditions, these workers have been moved back to caseload management. However, this was not widespread among all of the offices. In addition, each of the Regions have staff members that are responsible for working with the community to ensure access points are staffed with information about SRS benefits and application forms. However, there is no central repository of information about services outside of SRS for the staff to access to pass this information on to the customer. The current SRS Website only provides the customer with information about services SRS provides, not what is provided in their community.

Future: SRS will provide access to a service locator on their Customer Portal in order to assist customers with information about services provided in their area. The customer will be able to put in the kind of services they need (such as assistance with food) and the service locator would provide them a list of places that may be able to assist (such as a local food bank or WIC). This “service locator” could be built as a part of K-MED/Avenues or we could provide a link to the current 211 system in Kansas. SRS will continue to work with community partners to ensure they have updated information regarding SRS programs, how to assist the customer with the application process, and how to easily interact with SRS to develop more partnerships.

Current: New or expanded programs and responsibilities have been added with little or no system, and financial, or additional staff support. The regions are expected to determine the best way for their region to implement these changes, thus resulting in 6 (or more) different ways to implement. This means that 6 times the necessary resources are used to come up with the implementation plans, ongoing support, and possible creation of ancillary systems. The more efficient way to implement these changes would be to have a responsible entity develop

Version 5.0

the best implementation plan, systems required to support this change, provide the costs for the implementation and ongoing support and maintenance.

Future: Prior to adding new programs or expanding existing programs, individuals within Policy and Program Management will be knowledgeable in the areas of policy, rules, systems, procedures, and contracts. These staff will be involved with several related and integrated business activities that start with continuous monitoring and research of proposed legislative changes and the economic impact to SRS customers. The staff in this role must have the capability to respond quickly to prioritize programmatic needs that are driven by legislative and budget concerns and constraints. Data will be available to this team to allow for proactive cost-effective decision making for policy development and implementation. The Policy and Program Management staff will have the capability to utilize the automated system to forecast policy/program changes for a group of selected cases and once the system-generated results are available, shall analyze the effects of the changes and the impact to the corresponding program(s). Such analysis may include, but is not be limited to, dollar savings or increased costs, the number of cases impacted, and eligibility impacts such as the number of cases closed, additional cases that would be eligible, amount of benefit changes, etc. Once changes have been approved and prioritized with the other requests, the Program and Performance Management staff will work with ITS and training staff to determine the process, training and system changes required to properly implement the changes in the field. Training staff will update or develop the training materials and conduct the training necessary to properly train field staff prior to the implementation of the change. SRS will have the ability to provide training in multiple methods, some of which might be: in person, via recorded session, online tutorials, etc.

Current: There is no way for SRS to monitor and measure business processes. The current business processes are manual and typically sit outside of the systems, making them impossible to measure or compare them. This information would be very helpful when trying to ensure that all customers are going through the same process, or determining which of the regional processes are most efficient and trying to implement them in the other offices. In the current environment, policy staff do not have ownership over the processes yet are oftentimes accountable for correcting process issues.

Future: In the future business model, the new technology will allow staff access to the duration each task in a business process takes, down to a person level. This information will assist management in determining where possible bottlenecks are present and allow them to see if staff are deviating from that process. This role will be responsible for instructing field staff on the correct performance of tasks and how to implement policy procedures. These staff members will ensure consistency and standardization of processes across all regions. These staff will work closely with the Policy and Program Management, Training and ITS staff when changes are required to the business processes and the system.

Current: The interaction between SRS and KHPA appears convoluted and cumbersome. There is a blurry demarcation of duties between KHPA and SRS related to the Medical Assistance programs. Some types of applications are only processed by SRS (Elderly and Disabled); others are processed by either agency; while other applications are only processed by KHPA. In some

Version 5.0

situations, such as the receipt of an EES Family/Children application for benefits, the application is initially submitted to SRS where the Case Worker processes the eligibility. However, once the initial eligibility is determined, the SRS Case Worker copies and transfers the Medical Assistance portion of the case to KHPA, but retains the TANF portion of the case. At that point, any changes to a customer’s circumstances require action both on the part of the SRS and KHPA Case Workers. (Please keep in mind, this is for current state only and does not reflect changes that will be done in the future as a result of the K-MED project.)

Future: KHPA/KDHE and SRS will have an integrated system in the future which will store the customer information, documents, and case information. Customers will no longer have to notify both agencies when they need to report a change to their demographics or provide documentation. SRS staff will no longer have to photocopy paper documents to send to the Clearinghouse, the necessary documentation will be electronic and available to KHPA. When a customer requests services from both agencies, an electronic notification will alert KHPA they have a medical case if there is processing to complete on that case. The Elderly and Disabled cases will continue to be processed by SRS, this includes the case management. The integrated system will allow KHPA and SRS to easily share historical and demographic documentation to make the process more customer friendly. For instance: if a customer has had a medical case with KHPA but no services with SRS, if they apply for SRS services most of their information will already be in the system as well as documentation necessary to meet federal guidelines.

Organization:

Current: Roles and responsibilities of field staff varied from location to location. Even when staff performed the same process, they may do it differently than the other location. This can cause inconsistencies in your results and makes it difficult for staff to transfer to another location. Training appeared to be light once the initial training was completed. Shortcuts that are learned from staff are not often shared with others to gain those efficiencies.

Future: Standard processes and roles will be implemented with this project. Management will ensure processes are executed in a standard manner across the state; this includes standardization of roles performing the tasks. There will be standard training documentation for new staff, the implementation of new functionality, and ongoing training. With the ability to monitor the business processes down to the task level, they will have the tools necessary to determine if retraining is necessary for some staff.

Current: Although, there is a customer service office today, their function is to take complaints and then distribute them for resolution through the regional customer service staff and central office. There is no single entity responsible for customer service in the agency, yet that is one of the strategic goals. When there is not a single point of contact responsible for something as large as customer service, there is really no one to hold accountable. Customer services are not measured in SRS today.

Future: A primary change with the implementation of Avenues is the development and implementation of the Virtual Contact Center which will provide the initial single point of contact for customers

Version 5.0

when accessing services in person, by telephone, or other electronic means. The Virtual Contact Center will consist of:

Customer Service Representatives (CSRs) who will be located at local offices to assist customers who walk-in to the office seeking information or to apply for services

Customer Service Representatives will answer routine inquiries when customers call for assistance, or contact SRS with other electronic means such as email, chat, etc.

Customer Service Representatives will be responsible for manually entering any paper applications that are received at a local office

Help Desk personnel will assist with computer-related problem resolution

The purpose of the Virtual Contact Center is to serve the customer by handling all routine inquiries whether made in person, via phone or by email. This unit will consist of the various CSRs, staff members that are generalists with a generalized knowledge of all EES program areas and a broad knowledge of services available within the community. Regardless of whether located in the Virtual Contact Center or in the Local Offices, the CSRs will be responsible for handling all routine inquiries, performing triage, gathering information, assisting with referrals to community agencies and performing pre-screening activities as well as assisting the customer in completion of their online application.

The new solution will provide the capability for the CSRs to enter and track all customer inquiries and complaints. If the inquiry/complaint can be handled by the CSR, they will log that transaction and close it. If the inquiry/complaint can’t be handled by the CSR, the transaction will be assigned (or forwarded) to the proper staff. All inquiries/complaints will be logged and monitored to determine the agencies challenges and allow SRS to measure our customer service. SRS will utilize workflow to route the inquiry/complaint to the proper person or queue. Management will monitor the queues to ensure these transactions are being managed in an acceptable timeframe.

Technology:

Current: Customers are currently limited in their choice of service channels. The systems do not provide sufficient web accessibility for the customers or staff. SRS currently provides the customer with an online screening tool and online application. With the implementation of CAPP, the screening tool and online application will be updated to be more user friendly and there will be some integration with the legacy systems. The online application allows the customer to apply for TANF, Food Assistance, and Child Care Subsidy. This portal has very limited access and does not allow the customer to apply for other benefits, view their case information, update information, or request other services.

Future: The customer portal will be significantly expanded with Avenues. The screening and online application will be expanded to include all programs within the scope of Avenues and K-MED and will be fully integrated with the K-MED/Avenues system – this includes the eligibility and benefits administration system, MDM, telephony, and content management system. The

Version 5.0

customer will have the ability to apply for new services, view their information, add documentation to their case, and change information. If a customer has questions or concerns when using the portal, they will have the options of an online chat with a CSR, contacting a CSR via phone, or sending an email to the CSR mail queue. The online chat and phone options will be available during normal business hours. If the customer calls on the phone, the Interactive Voice Response (IVR) system will pass the identifying information (customer ID of some type) into the case management system of the CSR answering that call to pull up the case information for that customer. SRS would like the ability for the CSR to view exactly what the customer is seeing on their screen. When a customer makes a change to their information, the proper workflow will be activated to take proper actions based on the type of change. An example is a change of income source; the workflow would generate an employer letter or automated interface.

Current: SRS staff members are required to rely on numerous cheat sheets in order to enter a correct code in the legacy system or understand the information that already exists in the system. Each system has its own set of required codes that are entered so the workers have to look up codes in two or more separate guidebooks. New employees require lengthy training to understand use of the system and Social Workers and staff at outside agencies, such as the hospitals, report that it is easier to email or call SRS staff as opposed to trying to decipher the codes that exist in the legacy system. Any external contractors that have access to the system also are reliant on SRS staff to understand the data that exists in the systems.

Future: The new system will not utilize cryptic codes, meaningful words will be used and drop-down lists and/or radio buttons will be utilized whenever possible. The system will utilize workflow and screen flow to traverse the customers, staff, and partners down the necessary path. Smart scripting will be utilized so the end user will not have to answer unnecessary questions or go down a path that is not necessary for their particular need. Training needs will still be necessary, but there will no longer be a need for staff to memorize codes and policy information as it will be accessible and understandable from the system. Online tutorials and help will be available for all types of users.

Current: The systems lack checks and balances or editing within the systems to ensure that cases are not established incorrectly. There is no automated check to show if a customer is a part of another family on another case or if a customer is receiving benefits in another program area; all of these checks are completed manually. Changing of demographic information is not automated and requires staff to manually search systems to determine where the change should be applied.

Future: The new Master Data Management (MDM) will be utilized as the Master Client Index (MCI) for KHPA and SRS. The MCI will house the common information for all customers known to the system. One common client index will be utilized regardless of the agency. The system will have the ability to show all relationships of that customer to any case information, making it much easier to determine what services that customer may currently have or has had in the past. Household composition will be easily determined within the new system to ensure staff has the overall view of the customer and household. When a customer or partner enters

Version 5.0

information into the portal, the system will automatically do a customer and case search for everyone on that application to ensure we are not duplicating benefits or adding duplicate customers to the system. The business rules engine will provide the rules for determining customer and case matches. If all rules pass, the system will automatically register the case and determine eligibility. If all rules do not pass, that application or change will go into a queue for CSR processing. The system will allow the CSR to look at the rule(s) that failed and resolve any issues, and then the case can move forward in the registration and eligibility process.

Current: The systems that are utilized to support these services have been built independently by program area and are old and antiquated. Most of the systems were transferred in from other states and were built using business models that were not in alignment with Kansas which caused them to be heavily modified and difficult to maintain. Most systems were built using different programming languages and technology making it difficult to utilize programming resources across the different systems. These technologies are older and not easily modularized or extendable like current technology options. The business rules are coded into the system and not easily identified and can reside in multiple locations. The systems were not meant to support the number of programs and services that we have today, so the programmers often times have to “fake” the system into doing something different. With the older technology, it is increasingly difficult to find staff to support these systems when state staff retire. SRS has had to contract for support in many instances which increases the cost of ownership for these systems. These legacy systems run on the mainframe and as other state agencies modernize their systems, SRS costs continue to rise as our agency share of usage continues to rise.

Future: The future system will be service oriented architecture (SOA) compliant. SOA takes common business applications and breaks them down into individual business functions, called services. SOA allows you to build, deploy and integrate these services, independent of the applications and computing platforms on which they run. Rather than building separate stand-alone systems to meet each programmatic requirement, the framework will be a collection of software products or modules that fulfill functional business needs across all programs within Avenues/K-MED, integrated through service oriented architecture. These new technologies have inherent functionality that can meet a broad spectrum of business requirements and can be configured, rather than requiring custom software development, to meet specific program needs. Business services created with these new solutions are reusable within the system which will decrease development time and cost and provide the flexibility to respond to the constantly changing business environment. This comprehensive approach will enable flexibility when adding new programs or modifying existing programs. The business rules, business process management, IVR, workflow management, content management, business intelligence, and MDM will be components that are not embedded in the system, making them more easily modifiable and traceable. All system components will be integrated, making it appear to the end user as one comprehensive system. An example of this is the integration of the case management system with the content management system. The end user will have a listing of all content for a customer or case on their screen and have the ability to click on a link of that content and it will be brought up in a new window for that end user to view.

Version 5.0

Configuration Specialists, Application Administrators, and Integration Specialists are new roles to the agency. Support and maintenance right after implementation will be completed internally with the assistance from a vendor for training and mentoring, with the goal to become more self-sufficient over time. The vendor could be utilized for quick ramp-up for future enhancements or emergency cases.

Current: Information gathering requires both paper documentation and data entry into the systems. The systems oftentimes do not interact with each other and do not populate the appropriate fields with data that is entered in another SRS system, thereby requiring the staff to enter the same data in two or more separate systems. For example, if an applicant is applying for both TANF and Child Care benefits, the information that is on the application form has to be entered in both KAECSES-AE and in KSCares. This duplication of effort is very inefficient and error prone as keying errors can be made.

Future: All programs within the scope of Avenues and K-MED will be included in the new comprehensive and integrated system and data will be shared between the programs, thus reducing the amount of data entry for the customer and staff. Documents can be captured once and shared between programs. Documents can be viewed at a customer level or a case level but will only be stored in the system once. If a customer is already registered in the Customer Portal, information can be pre-populated for them to reduce the data entry necessary for them to reapply or expand their benefits.

Current: The database technology used in most of the systems does not easily lend itself to user access, making it difficult to create ad hoc reports. This has also limited the amount of integration that can be accomplished among the systems. The current systems are more like data repositories and do not contain many of the automation features of newer technology.

Future: The new system will be built on more modern relational database technology. There will be a separate data repository for reporting and business intelligence. The end user will have more robust capabilities with expanded data elements for producing ad hoc reports based on their security. Their access to information will be on a more real-time basis than what they have today. The business intelligence repository will be utilized for performance management, as-if scenarios when changes are suggested, and other agency reporting. Our expectation is the data repository utilized for business intelligence and reporting will be refreshed nightly.

Current: Currently, there is no capability to record conversations with customers within our current legacy systems, forcing staff to create manual logs of interactions with customers. Case workers keep a Word file on each of their customers and have to open that file and record conversations with customers into that file. These manual logs are kept on a shared drive at that regional or local office as opposed to having this ability integrated into the system and visible state wide.

Future: Staff will have the ability to record notes and conversations they have with their customers as a part of the case management. Emails sent by the customer can be attached to the case and an entry automatically added to allow staff to add narrative based on that email. If a customer

Version 5.0

calls, the telephony system will automatically enter a log entry of that phone call and date and time of the call, staff will have the ability to add to that entry to provide more details. The system should be flexible enough to allow SRS to record conversations between a CSR and a customer which can also be stored within the system.

The success of this project depends on each area (people, process, and technology) working together in a integrated, cohesive manner and the support of the SRS Management Team.

In order to transform the department to a truly customer centered business model will require changes to processes and organization as well as the technology. Prior attempts made by the department have not been successful because the technical supports needed for integrated service delivery were not available. Likewise, in the process of moving forward implementing new technical systems will, by themselves, be insufficient. It is critical that the agency move forward on all three axis and restructure processes and organizational structures as well to produce the business model required to service SRS customers in the future.

Technology services in SRS have, admittedly, not been able to adequately keep pace with the programmatic needs of the organization with the current resources, but with the support of the agency, this modernization project will put SRS/EES systems at the forefront of Social Services delivery.

SRS recognizes that each of the three operational areas wants to become more efficient, and has attempted at some level to become so. Executive management at SRS are committed to providing the leadership, organization, and resources that allow people, processes, and technology to work together to provide effective services to all Kansans, in the same way, every time they are needed.

Scenarios for the Future SRS Model:

Scenario 1: Sally Smith loses her job and is not eligible to receive unemployment insurance. With the loss of her job, she loses medical insurance coverage for her and her family and it is getting increasingly difficult for her to feed her children.

1. Sally goes to her public library to look for some type of assistance on one of their local computers.

2. A staff member from the library asks Sally if she needs any assistance.3. Sally asks the library staff member if they know who she might contact for some assistance

with getting her children medical coverage as well as assistance to get her children food.4. The library staff member had been updated previously from SRS communications about the

ability to screen for eligibility as well as look for other types of assistance on the SRS website and provides that address to the customer.

5. The customer goes into the SRS Customer Portal and follows the online instructions on how to fill out the screening information to see if she might qualify for any benefits. This can all

Version 5.0

be completed anonymously, or the customer can choose to create a unique signon to the SRS Customer Portal.

6. The customer goes through the very simple screening process and finds out that she and her children might be eligible for Medical coverage, TANF, and Food Assistance so she has decided she would like to go ahead and apply for these benefits. The customer is also provided a list of services within her area that might also be of assistance, such as: the local food bank, the department of Commerce to assist her with finding a new job, WIC, as well as others.

7. The customer now creates her unique user ID, password, and completes the four questions asked as a part of the authentication process to be used if she forgets her password.

8. The customer fills out the application and utilizes the online assistance provided by some of the fields on the screen by clicking on the link beside that field to get a better idea of what she is to fill out in that specific field.

9. The customer comes to a question she is still not clear how to answer, so she starts an online chat (this customer is filling out her application during normal business hours) with one of the SRS CSRs to get better clarification. She is able to resolve her issue and go right back to filling out her application.

Option 2: The customers calls the SRS office and talks with a CSR who is able to see exactly where she is in her application and that CSR walks the customer through the part of the application that customer is having difficulties with.

10. The customer completes her application and sends it for processing. She indicated on her application that she would like to be notified via text message if she needs to check the SRS Customer Portal for any updated information, with her second preference as a phone call. She acknowledges that all the information she entered is valid and true and types in her name for our electronic signature requirements.

11. The system provides her with information about her application number, what documentation the agency will need and when they will need it before they are able to determine if she is qualified to receive benefits, provides her with information about the closest place she can go to send her documents electronically to SRS for faster processing, and then provides her with an approximate date and time of when she can expect to hear back from us.

12. Since this customer is applying for TANF, she is required to complete an interview. The system asks her for her availability and automatically schedules her interview by cross referencing her schedule with the SRS staff schedule.

13. The system starts processing the application. Since she and her children are not known to the system, the system automatically adds her and her children to the client index and assigns them a unique customer ID number.

14. If desired, the system assigns a case worker to that case – this must be flexible, we may not want to assign a certain case worker to all cases.

Version 5.0

15. The system automatically registers the case and starts the eligibility process. The system realizes that all necessary documentation has not been received and puts that case on hold for 10 days before a message is sent to the customer notifying them we have not received their information and cannot process their application until that is received.

16. Sally mails her documentation to the central address provided as a part of the information she received after filling out her application.

17. The central records management center opens Sally’s mail which contains Sally’s unique application number. The staff scan and index Sally’s documents into the system – which is attaching them to both the person and the case. This means the birth certificate for the children are attached to the correct child, etc.

18. As soon as all necessary documents are attached to the case, the eligibility process begins again. If any issues occur in the eligibility process, that case goes into a queue for a CSR to work. The CSR is able to look at the business rules that failed to determine what issues might have occurred with the case to resolve these issues.

19. The CSR works with the customer to resolve all issues and the eligibility process is kicked off again.

20. The customer and her children are eligible for food assistance, TANF, and Medical coverage.21. The system generates an email and text message to Sally to let her know she is eligible, how

much she will receive, and when her EBT and medical card will be sent to her. The text message alerts Sally to check her email.

22. The system automatically generates a file (or request) to the EBT contractor who sends the card to Sally.

23. The system automatically notifies the proper SRS Case Coordinator to determine how we can successfully get Sally back to work. This will include providing benefits for child care, travel and training expenses.

24. When Sally attends a community college for training, the community college provides updates via the Provider Portal to be applied directly to Sally’s case file information.

25. Since Sally continues her education, she is now due for her annual review. 26. The system generates her annual review packet, texts Sally and then emails the information

to Sally to fill out electronically and send back to SRS.27. Because the documents are electronic and bar-coded, they are automatically attached to

Sally’s case and an alert is sent to her Case Coordinator for review.

Visually Impaired:

Sam Smith is visually impaired and it is difficult for him to get to an SRS office. Sam has a computer and assistive devices at his home and has been instructed to complete an online application to apply for food assistance due to a loss of income.

Version 5.0

1. Sam’s scenario is much like Sally’s scenario above, but Sam is utilizing the JAWS reader to read each of the fields on each screen of the online application. Sam is able to navigate the complete application and utilize the help text when necessary.

2. Sam is not required to complete a face to face interview and can do a phone interview. The system automatically schedules a time to do a phone interview with a CSR.

Help Desk:

Steve is a CSR at the Virtual Contact Center. His duties rotate between assisting customers face-to-face, via the phone, via the fax, or via email. Depending on the volumes, Steve can be reassigned throughout the day to assist in areas that have higher traffic than others.

1. This morning Steve is assigned to assist customer that are calling in for assistance.2. Steve signs into his computer and sets his status to available; he does not speak Spanish so

he is assigned to the English queue.3. The telephony system automatically routes incoming calls based on the CSR that has been

idle the longest period of time. If all CSRs are on the phone, the customer is put on hold and provided with a message to let them know approximately how long they will be waiting for the next available CSR, provides them with the opportunity to leave a message, and lets them know they can receive information online.

4. Steve’s phone rings and his screen pops over to information about a customer named David Dirt, providing him just a few seconds to read over his information.

5. David indicates to Steve that he is unable to complete his online application and isn’t sure why.

6. Steve is able to see exactly where David is in his application process and determines David has not clicked on the “I agree” button at the bottom of the application, which is a required field.

7. The conversation between Steve and David is automatically entered into the system. Steve is able to enter the resolution of the call and mark the status as closed.

8. Once that call is complete, Steve is on to the next call.9. The system tracks the time spend on the customer resolution.

Managers:

Doris is the Virtual Contact Center manager for the North East Region. She has a staff of 30 Customer Service Representatives and is responsible for making sure the workload is evenly distributed

Version 5.0

between all service channels. Doris must do quarterly feedback sessions and annual review for all of her staff.

1. Doris has a dashboard on her monitor that lets her know how many the volumes of each of her service channels: phone, email, online chat, in person, fax, mail, etc.

2. Doris has a regular schedule for each of her staff, they understand which service channel they are working on any given day.

3. If Doris sees the wait times on the phones are getting higher than normal, she looks at the volume in her other areas and determines she can take 2 CSRs out of online chat and have them help out with the phone calls.

4. Doris instant messages the 2 CSRs and tells them they will be working the phones for the remainder of the day, or until she lets them know they can change to a different service channel.

5. The 2 CSRs log into the telephony system and quickly the wait times are back to an acceptable level.

6. Doris receives daily, weekly, and monthly reports to assist her with staffing plans and performance appraisals. She utilizes these reports to determine if someone has a strength or weakness in certain areas. She utilizes these reports to set measurable outcomes for CSRs to effectively communicate expectations.

Objectives

Key objectives (i.e. business, strategy/policy, project execution, technology knowledge transfer) are presented below.

SRS is the safety net provider for services which can’t be effectively or cost efficiently provided by public/private partners. SRS is obligated to provide certain services, however the agency will refer customers to other state agencies and to community partners for provision of services to the maximum extent possible.

Version 5.0

SRS will facilitate and enable service delivery through public/private partnerships. The agency will make concerted outreach efforts to not only educate the community on services offered by SRS but also to obtain knowledge of services offered by the community.

The agency will provide universal access and a single point of entry for customers to obtain services, both those external and internal to the agency.

SRS will transform from a program-centric model to a client-centric model which places the customer at the center of its planning, policy, program and practice efforts. This will require the agency to integrate with other state services outside of SRS.

The agency approach will change from that of a programmatic eligibility determination to an approach where the client is viewed holistically across multiple programs.

SRS wants a single view of service providers which links providers to multiple programs. Currently multiple provider registries exist depending on the program and the provider type.

Service delivery needs to be outcome and accountability-based instead of output-based by focusing on results.

The agency will need to provide and share information across SRS programs, other state agencies, contract service providers, and community based organizations. Data access must be subject to a legitimate “need to know”, the minimum needed for the business function, and in compliance with HIPAA and other privacy standards.

Customers should have access to their case information if they are the source of the data and it does not involve sensitive or otherwise confidential information. Parents and guardians would have access to relevant information with appropriate restrictions and authority.

SRS will define the common business processes (e.g., intake) that exist for programs administered by SRS based on Core Business Functions; these should be primarily defined by the Regions collectively in collaboration with the central office.

Future business model must be flexible enough to accommodate Program-specific business processes (function) without sacrificing the overall goals and objectives related to common functions and standardization.

Work should be done by the appropriate level of staff. Work flow should start with generalists and be assigned to specialists only when needed. For example the initial intake and triage for financial programs could be performed by generalists.

Emergency contacts such as child and adult abuse and neglect calls should always be assigned to a specialist right away.

The future business model will result in work efficiencies but the current SRS workforce should be preserved when possible. However, specific job descriptions will evolve and take on new characteristics. There must exist the flexibility to assign staff to new roles if necessary, e.g., reassigning current case worker/clerical staff to Contact Center duties.

Version 5.0

The existing service locations will be required at the same level in the near term although the physical appearance, atmosphere and functions performed at the location may change in the future.

The future business model may require greater co-location of SRS staff with Community Based Organizations (CBOs) and other partners.

The development of common terminology, taxonomy and other metadata across programs is desirable except those linked to a legitimate Program-specific business requirement. For example, the agency would need to establish a common definition of case management, case maintenance, etc.

Customers may initially be unfamiliar with or lack access to technology such as the Internet. Overcoming the digital divide for customers should be accomplished through partners.

The goal is to minimize the use of paper transactions and paper documentation and maximize reliance on electronic methods.

The future vision requires the maximization of cross channel service integration across business functions, e.g., the capability to start a process, such as filing an application on the web and finish it on the phone.

To the extent possible clients should be encouraged to start with self-service (low touch) through the web and involve SRS and other support (high touch) as needed.

SRS will assist customers in achieving self-sufficiency by holding them accountable to comply with applicable rules, regulations, and laws; and by promoting customer learning of applicable life skills.

Version 5.0

avenues projects ow

Documents

project management

srs project

project phases

project staffing

project time reporting

project execution tools

issues management

content management