attachment b statement of work - myflorida.com€¦ · attachment b statement of work . ... 5.7 ddi...

Attachment B Statement of Work

Statement of Work 1

Section 1 Overview ................................................................................................................................. 4

1.1 Definitions .................................................................................................................... 4

1.2 Contract Objectives .................................................................................................... 4

1.3 System Overview......................................................................................................... 4

Section 2 Project Governance Structure and Staffing Requirements .............................................. 6

2.1 Cooperation with the Department and Other Entities .............................................. 7

2.2 Cooperation in the Event of a Subsequent Contractor ........................................... 7

2.3 Contractor Staffing Requirements ............................................................................. 8

Section 3 Project Administration .......................................................................................................... 9

3.1 Project Management ................................................................................................... 9

3.2 Phase Gate Reviews ................................................................................................. 10

3.3 Knowledge Transfer .................................................................................................. 11

3.4 Disaster Preparedness / Disaster Recovery ........................................................... 12

Section 4 Project Execution Performance Periods ........................................................................... 13

4.1 DDI Performance Period ........................................................................................... 13

4.2 ST Performance Period ............................................................................................. 13

4.3 OS Performance Period ............................................................................................ 14

Section 5 Design, Development and Implementation (DDI) Performance Period ......................... 15

5.1 DDI Performance Period Phase One: Initiation and Planning ............................... 15

5.2 DDI Performance Period Phase Two: Requirements Elaboration ........................ 17

5.3 DDI Performance Period Phase Three: System Design ......................................... 19

5.4 DDI Performance Phase Four: System Development and Test ............................ 25

5.5 DDI Performance Phase Five: Data Conversion .................................................... 27

5.6 DDI Performance Phase Six: Testing ...................................................................... 28

5.7 DDI Performance Phase Seven: Implementation ................................................... 32

Section 6 Services Transition (ST) Performance Period .................................................................. 35

Statement of Work 2

6.1 ST Performance Period Phase A – Warranty Phase .............................................. 35

6.2 ST Performance Phase B – Services Transition Phase ......................................... 37

Section 7 Operational Support (OS) Performance Period ................................................................ 37

Section 8 Project Deliverables for All Phases ................................................................................... 39

8.1 Project Governance and Oversight Deliverables ................................................... 40

8.2 DDI Performance Period Phase One: Project Initiation Deliverables ................... 40

8.3 DDI Performance Period Phase Two: Requirements Elaboration ........................ 42

8.4 DDI Performance Period Phase Three: System Design Deliverables .................. 43

8.5 DDI Performance Period Phase Four: System Development and Test Deliverables ........................................................................................................................... 45

8.6 DDI Performance Period Phase Five: Data Conversion Deliverables .................. 46

8.7 DDI Performance Period Phase Six: Testing Deliverables .................................... 47

8.8 DDI Performance Period Phase Seven: Implementation Deliverables ................. 48

8.9 ST Performance Period Phase A: Warranty Phase Deliverables .......................... 50

8.10 ST Performance Period Phase B: Services Transition Phase Deliverables ........ 51

8.11 Additional Considerations – Operational Support Performance Period Deliverables ........................................................................................................................... 51

Statement of Work 3

Section 1 Overview

1.1 Definitions In this document, in addition to the definitions in the PUR 1000 and PUR 1001, capitalized terms shall have the meanings stated in the solicitation Attachment K, incorporated as Exhibit 3 of the Contract. Defined terms in the singular shall include the plural and vice versa, and the masculine, feminine, or neuter gender shall include all genders.

1.2 Contract Objectives

The Department of Financial Services’ (“DFS,” or the “Department”) expectation for the RMIS replacement is that it will meet the Division of Risk Management’s (“DRM” or the “Division”) business objectives, including:

Improved Efficiency and Reduced Errors: The new system must collect and manage claim information, administer claims, provide workflow and other tools to support the ability of users to communicate with each other, accept and route information, work files and set reminders for key actions. Improved efficiency will enable adjusters to work on high priority items such as investigations and legal issues in a timelier manner.

Improved Collaboration and System Integration: The new system should greatly increase the seamless technical integration of the Division with its partners, including third party administrators, other Divisions within the Department and other State and Federal Agencies. This integration should reduce or eliminate the extensive manual effort currently required to export and import data.

Enable Self-Service Internally and Externally: The new system should support self-service by Division employees (for example, requesting standard reports), Vendors (for example, submitting invoices electronically) and State Agencies (for example, submitting a property update or claim notification electronically).

Performance Measurement: The new system should support tracking and reporting of metrics and improve data access for performance management.

1.3 System Overview

To support the Division’s objectives, the new system is expected to include, but is not limited to:

1) Business Rules Engine

2) Web Based architecture

3) Document imaging and management, including tight integration with FileNet P8

4) Advanced search capabilities

5) Workflow management

6) Communication administration, including e-mail system integration

Statement of Work 4

7) Customer relationship management, or tight integration with an external customer relationship management (CRM) system

8) Automated system interfaces

9) Data import / export, including batch processing

10) Reporting and dashboard tools

11) Enhanced security (role-based)

12) Auditing tools

13) System administration tools

14) Agency self-service portal

The new system (“System”) is expected to support the following high-level business functions:

1) Policy administration, including Rating / Binding, issuing Certificates of Insurance with detailed property schedules, calculating premiums and processing no-cost endorsements. Note that the Department has unique Policy administration requirements related to potential annual changes in the organizational structure of various state agencies / policyholders (e.g. Legislatively mandated mergers or reorganizations that necessitate moving properties, claims or history).

2) Claims management, including first notice of loss / injury, validation of coverage, investigation, loss and loss adjustment expenses, reserving, subrogation, salvage and deductible recovery, vendor management, litigation management, claims payment, claims history, third party administrator (TPA) data integration and image and document management.

3) Finance and accounting, including premium and deductible billing, premiums and receivables collection, general ledger interface and payment processing. Note that the Department has unique Finance and Accounting (F&A) requirements related to interfacing with existing financial management systems and calculating deductibles.

4) Reporting, including statistical reporting to the Division of Worker’s Compensation (DWC) and other entities, claims data reporting to DWC and Centers for Medicare and Medicare Services (CMS), management reporting, work tracking, auditing, claims monitoring and actuarial data reporting.

Statement of Work 5

Section 2 Project Governance Structure and Staffing Requirements

This project will be administered by the Department’s Division of Information Systems (DIS) and Division of Risk Management. The expected organizational chart of the project team follows. The Contractor is expected to fully cooperate and participate with the Department and any of its partners or Vendors.

Project Sponsor

Department Project Manager

Contractor Project Coordinator

Contractor Project Team

Key Resources Include: Requirements Lead, Development Lead, Testing Lead, Training Lead, Implementation Lead and Transition Resource

Department Project Team

Department Contract Manager

Third‐Party Business App

Owners

Executive Steering Committee

The Department’s governance structure and stakeholders include: Role Responsibility Project Sponsor • Responsible for funding and project resources.

• Responsible for strategic project direction. • Escalation point for Project Director.

Executive Steering Committee

• Consists of members from DIS, DRM and other stakeholders. • Monitors ongoing project progress. • Responsible for supporting project with Division resources as necessary. • Responsible for decision making regarding scope, budget and schedule of the

project. Department Contract Manager

• Day-to-day point of contact for the Department in interfacing with the Contractor post implementation.

• Has authority to make or obtain contractual decisions on behalf of the Department. • Responsible for dispute resolution. • Escalation point for the Department Project Manager. • Reviews, verifies and approves invoices from the Contractor.

Department Project Manager

• Manages day-to-day execution of the project during implementation. • Coordinates activities and communication between project team members. • Interfaces with Contract Manager to review and approve Contractor deliverables. • Acts as liaison between the project team, project support, the steering committee and

project sponsor. Contractor Project Coordinator

• The Contractor Project Coordinator is required to be a Project Management Institute (PMI) certified Project Management Professional (PMP).

• A member of Key Resources (see Section 2.3).

Statement of Work 6

Role Responsibility

• Single day-to-day point of contact for the Department in interfacing with the Contractor.

• Responsible for the successful execution of the contract scope of work and deliverables.

• Responsible for tracking and reporting status of project execution to the Project Manager.

• Acts as liaison between the Contractor and the Project Manager and DRM Contract Manager.

Contractor Project Team

• Responsible for successful technical, business and management activities for design, development and implementation of the project.

• Key resources on the Project Team include: o Requirements Lead o Development Lead o Testing Lead o Training Lead o Implementation Lead o Transition Resource

Contractor Transition Resource (see 3.3)

• A member of the Key Resources (see Section 2.3). • A technical member of the design, development and implementation team that stays

on after Go-Live to provide onsite operational maintenance and support for two years during the Services Transition Performance Period.

Department Project Team

• Employees or contractors of the Divisions of Risk Management or Information Systems assigned by the Department to support the system design, implementation and operation associated with this Contract.

Departmental Project Support

• Department Legal, Human Resources, Procurement, Finance and Accounting and Budget staff that provide additional project support as necessary.

Functional Leads and Business Process Owners

• DRM resources that act as subject matter experts in verifying and refining requirements, reviewing designs and interfaces, confirming data accuracy and performing user acceptance testing.

Technical Leads, DBA, Application Development Leads

• DIS resources that act as subject matter experts on the expected architecture of the new system as well as interfacing with existing business systems.

• Provide data extracts and work with the Contractor Project Team to implement APIs and interfaces to achieve the expected level of integration with external business applications.

Third-Party Business Application Owners

• Responsible for providing necessary documentation and information on the function of third party applications that the new system will attach to.

• Assists in understanding the data structures needed to move data seamlessly between applications.

• Provides necessary access and permissions to the third party system to enable integration or interfacing.

• Third-party business application owners can be employee of the Department, other state or Federal agencies or third-party Vendors under contract with the Department.

2.1 Cooperation with the Department and Other Entities

As required by Attachment A – Standard Contract, section 7.8; the Contractor and its subcontractor(s) agree to cooperate fully with the Department, Partners, oversight authorities and other contractors retained by the Department.

2.2 Cooperation in the Event of a Subsequent Contractor

If the Contract, or any portion thereof, is terminated for any reason prior to its completion, the Contractor agrees to comply with the terms of Attachment A – Standard Contract section 12,

Statement of Work 7

including cooperating fully with the subsequent contractor. Such requirement shall exist notwithstanding the reasons for the retention of the subsequent contractor, including but not limited to cancellation, termination or expiration of the Contract with the Contractor.

2.3 Contractor Staffing Requirements

The Contractor shall maintain staffing levels sufficient to complete the services and meeting the requirements specified in the Contract and statement of work. Proposed individuals’ skill levels should be consistent with the proposed System and services. The Contractor must provide resumes demonstrating appropriate experience for all proposed staff. The Department reserves the right to reject any proposed team members throughout the Contract period.

The Contractor will identify key personnel in their reply. Key personnel (“Key Resources”) are those that the Department or Contractor deem essential to the successful execution of the Project. Key personnel includes, but is not limited to: Project Coordinator, Requirements Lead, Development Lead, Testing Lead, Training Lead, Implementation Lead and Transition Resource(s).

The Contractor may not reassign any key project personnel except as provided for and in the manner described by section 7 of Attachment A – Standard Contract. The Contractor may not knowingly employ or contract with any former employee of the Department in violation of section 112.3185, Florida Statutes (F.S.).

Statement of Work 8

Section 3 Project Administration

The following sections describe the responsibilities of the Contractor and the Department with regards to general project execution tasks. Later sections describe responsibilities related to Design, Development and Implementation tasks.

3.1 Project Management

Project management is the responsibility of the Department and the Contractor. The Contractor will designate a Project Management Institute (PMI) certified Project Management Professional (PMP©) to oversee Contractor activities on this project. This person may not be replaced without the prior consent of the Department. The Contractor Project Manager is responsible for the successful delivery of the Contractor’s services in accordance with the Contract and statement of work. The Contractor will manage all Contractor and subcontractor (if any) activities as specified in the Project Management Plan (PMP).

The Department will develop the PMP with appropriate input from the Contractor. All activities described in the PMP will be consistent with the Project Management Body of Knowledge (PMBOK) standards for project management.

The Contractor will be responsible for maintaining consistent communications with the Department Project Manager and other members of the project team.

The Department will establish a SharePoint site for maintaining project documentation and deliverables. The Contractor will use this library to store, access and reference documents and deliverables related to this contract.

3.1.1 Contractor Project Management Responsibilities 1) Provide input into the PMP.

2) Manage and direct Contractor and subcontractor staff.

3) Create and maintain a fully resource-loaded project schedule for all Design, Development and Implementation (DDI) activities.

4) Manage the project according to the agreed project schedule.

5) Prepare and submit weekly project status reports.

6) Participate in weekly project status meetings.

7) Prepare and distribute minutes from project status meetings within three business days of meeting.

8) Identify risks, issues and opportunities and submit to Project Manager.

9) Identify and notify Department Project Manager of scope, budget, schedule or resource issues.

10) Require compliance with project management, development, security and other standards of the Department from all Contractor and subcontractor resources.

Statement of Work 9

11) Prepare formal reports and presentations.

12) Participate and cooperate with audits, reviews and quality activities.

13) Provide documents to the Project team for review in the formats and on the timeframes specified in the project schedule and Deliverable Expectation Documents (DEDs) and maintain project documentation in SharePoint site.

14) Maintain records in accordance with the Florida Sunshine laws as appropriate.

3.1.2 Department Project Management Responsibilities 1) Develop and maintain the PMP.

2) Work with the Contractor to develop or approve applicable project management templates.

3) Define reporting structures and expectations between project participants.

4) Facilitate the resolution of issues.

5) Facilitate the availability of Department staff.

6) Facilitate timely review and acceptance of project deliverables.

7) Review and approve schedules changes.

8) Review and approve risk or issue mitigation plans or activities.

9) Review and approve all Contractor project staff.

10) Review and approve project status reports.

11) Negotiate changes in scope as appropriate and necessary.

12) Coordinate with stakeholders to prepare for implementation.

13) Support the Contractor by providing required information timely.

14) Provide a SharePoint library for all project documentation.

15) Provide the Contractor with workspace at the Department’s facilities in Tallahassee, Florida.

16) Provide the Contractor access to the Department’s infrastructure, including server and operating system, network connectivity, database software and tools, and data storage as needed for the Project. The Contractor will use these resources in accordance with the Department’s published usage and security guidelines. Any Contractor resources connected to the Department’s infrastructure will be subject to inspection and approval. See: http://www.myfloridacfo.com/Division/DIS/ISDM/

3.2 Phase Gate Reviews

The Department will manage the progress of the Project according to phases as described in the Design, Development and Implementation section. Each phase concludes with a formal gate review of Project deliverables, risks, opportunities and accomplishments. These reviews give the Department and the Contractor an opportunity to determine whether the Project is making sufficient progress to continue. Successful completion of the gate review at the end of a

Statement of Work 10

http://www.myfloridacfo.com/Division/DIS/ISDM/

phase is the trigger that allows the Contractor to invoice the Department for Deliverables completed within that phase, per the process defined in Attachment A – Standard Contract sections 8 (Acceptance of Deliverables) and 9 (Payment and Financial).

3.3 Knowledge Transfer

The Department requires the Contractor to develop and execute a robust knowledge transfer plan. It is the intent of the Department to develop the internal capabilities to maintain the System after implementation. The Contractor must include in its proposal staffing for a two-year transition period after implementation. The resource(s) identified by the Contractor responsible for the Transition Period must be member(s) of the implementation team during the initial System implementation (“Transition Resource”). During this transition period, responsibility for maintaining the System will gradually transition from the Contractor to Department staff. During Design, Development and Implementation the Contractor is responsible for developing a transition plan that covers this two-year period. The Transition Plan should detail the knowledge that the Department must gain proficiency in and provide a schedule with testable milestones for the Department’s resources to achieve.

In addition, knowledge transfer will be an integral component of each phase gate, with functional and technical knowledge transfer expected to be a component of each major deliverable signoff.

3.3.1 Contractor Knowledge Transfer Responsibilities 1) Develop and maintain a Knowledge Transfer Plan for pre- and post- implementation.

Plan must include phased hand-off, identify key knowledge, skills and abilities (KSAs) that Department staff must obtain and identify any foundational skill sets required to support the System (e.g. third-party tool use, programming language, etc.).

2) Conduct formal deliverable reviews / trainings for Department as appropriate.

3) Provide minutes of formal deliverable reviews.

4) Pre-implementation, assess and report to Department Project Manager on level of proficiency achieved by Department staff after each phase gate.

5) Post-implementation, assess and report monthly to Project Manager on level of Department proficiency and readiness to assume maintenance activities.

3.3.2 Department Knowledge Transfer Responsibilities 1) Identify key staff for knowledge transfer.

2) Ensure key staff is available to participate in reviews and trainings.

3) Obtain, at Departmental expense, any third-party tool training deemed required for assuming maintenance responsibilities for the new System (e.g. DB training, programming language training, etc.)


3.4 Disaster Preparedness / Disaster Recovery

The Contractor shall work with the Department to become familiar with the Department’s Disaster Recovery (“DR”) infrastructure. The Contractor shall then, within thirty (30) days of execution of the Contract, submit to the Department’s Project Manager input to the Department’s Disaster Preparedness Plan, including provisions for pre-disaster records protection and an alternative Recovery Plan that allows the Contractor to continue functioning in compliance with the Contract in the event of an actual emergency. The input to the Disaster Preparedness Plan shall also include Recovery Plans specific to the new System that details actions to be taken in the event of a natural disaster or disaster resulting from negligence, sabotage, mob action, etc. The Contractor should also be aware of the requirements of Attachment A – Standard Contract, section 10.8 (Excusable Failure).

3.4.1 Contractor Disaster Preparedness / Recovery Responsibilities 1) Work with the Department to understand the existing DR infrastructure.

2) Prepare input to the Disaster Preparedness Plan.

3) Execute the project-specific Disaster Recovery Plan as required during the Contract term in collaboration with the Department.

3.4.2 Department Disaster Preparedness / Recovery Responsibilities 1) Review, edit or approve the Contractor’s input to the Disaster Preparedness Plan.

2) Provide the Contractor with the existing Disaster Recovery Plan for the Department’s assets.

3) Execute the Disaster Recovery Plan after the Contract term.


Section 4 Project Execution Performance Periods

The Project shall consist of three performance periods – the Design, Development and Implementation (DDI) Performance Period, the Services Transition (ST) Performance Period and the optional Operations Support (OS) Performance Period. The DDI Performance Period includes all activities from the time of contract execution to System Go-Live. The Services Transition Performance Period begins at System Go-Live and continues for a period of two (2) years post Go-Live. The optional Operations Support Performance Period begins at the conclusion of the Services Transition period and continues for two (2) years. The Operations Support Performance Period tasks may be renewed for a period of five (5) years after completion of the initial contract term.

4.1 DDI Performance Period

The DDI Performance Period includes all of the activities necessary to implement the new System, including data migration, report development, installation, configuration, customization and training. The DDI Performance Period is broken into Phases. The following Phases and approach may be updated to be consistent with the Contractor’s SDLC as agreed to by the Department during negotiations.

Phase One: Project Initiation and Planning

Phase Two: Requirements Elaboration.

Phase Three: System Design. Create functional, business process, technical, interface and data conversion designs.

Phase Four: System Development and Test. Install, Configure, Code and Unit Test application.

Phase Five: Data Conversion. Populate new System with legacy data from multiple sources.

Phase Six: Testing.

Phase Seven: Go-Live and Training. Move into production environment with required training and documentation.

4.2 ST Performance Period

This Performance Period includes the warranty period and oversees the transition of maintenance capabilities from the Contractor to the Department post-implementation over a two-year timeframe after Go-Live.

Phase A: Warranty and Documentation

Phase B: Services Transition


4.3 OS Performance Period

If the Department determines it is in the best interest of the Department and the State to engage the Contractor to provide ongoing Operational Support, the optional OS Performance Period would begin at the end of the two-year Services Transition Performance Period. If the Department selects this option, the Department and the Contractor must negotiate to refine the statement of work and document a detailed service level agreement (SLA). The agreed statement of work and SLA will be incorporated into the Contract by Amendment.


Section 5 Design, Development and Implementation (DDI) Performance Period

5.1 DDI Performance Period Phase One: Initiation and Planning

During Project Initiation and Planning, the project will kick off and the Department and the Contractor will work together to define how the project and all tasks will be managed, including the definition of the System Development Life Cycle (SDLC). The Department will create a Project Management Plan (PMP). The Contractor will provide input and updates to the PMP. The plan will follow industry standard practices for project management and will include at a minimum, the methodology and approach for the project.

Within thirty (30) days of contract initiation, the Contractor will conduct a kick-off meeting in coordination with the Department. All of the Contractor’s key staff will attend the kick off meeting. The purpose of the meeting will be to review the project plan (including scope management, schedule management, risk management, change management, quality management, communication management and resource management) and the various deliverables associated with the complete SDLC of the project, as well as establishing general project understanding among the Stakeholders. Such understanding should include, but is not limited to, the identification, roles and responsibilities of stakeholders, the SDLC methodology the Contractor will employ, the processes that will be used to review and provide input into processes and deliverables, critical success factors and the performance measures that will be used to evaluate the Project. The Contractor shall conduct one or more additional project initiation meetings if deemed necessary by the Department to meet the goals and objectives of this phase.

The Contractor and the Department will implement the workspace and development environment requirements agreed to during negotiations. This Contractor is expected to perform the work under this Contract at the Department’s facilities in Tallahassee, Florida. The Contractor and the Department’s Project Manager will work together to prepare the work site, including obtaining necessary background checks on Contractor staff, setting up work spaces, establishing necessary credentials and accounts and establishing the necessary technical environment. The Department expects that all workspace and technical environments will be operational within 30 days of the Contract execution.

The Department’s project team and the Department Project Manager will work together to develop and refine the PMP according to the project approach and schedule. The PMP will include various subcomponents, some of which are the responsibility of the Contractor to provide. Subcomponents shall be due either prior to the kick-off meeting or at the end of the phase gate, according to the following matrix:

Subcomponent Responsibility Of Due Prior To Project Charter Department Kickoff Project Schedule Contractor Kickoff SDLC Methodology Contractor, with input from

Department Kickoff

Budget Management Plan Department Kickoff Schedule Management Plan Department, with input from

Contractor Kickoff

Project Change Control Management Department Kickoff


Subcomponent Responsibility Of Due Prior To Plan (includes scope and schedule) Deliverable Expectation Document (DED) and Deliverable Checklists

Department, with input from Contractor

Kickoff

Phase Gate Approval Criteria Department Kickoff Phase Gate / Deliverable Review and Acceptance Process

Department Kickoff

Disaster Preparedness Plan Contractor Kickoff (within 30 days of contract execution)

Communication Management Plan Department, with input from Contractor

Phase Gate

Document Management Plan Department, with input from Contractor

Phase Gate

Quality Management Plan Contractor Phase Gate Risk / Issue Management Plan Contractor Phase Gate Knowledge Transfer Plan Contractor Phase Gate Human Resource Management and Staffing Plan

Contractor Phase Gate

Configuration Management Plan Contractor, with input from Department

Phase Gate

Information Security Plan Department, with input from Contractor

Phase Gate

5.1.1 Contractor Initiate and Plan Responsibilities 1) Onboard Contractor staff, including required background checks.

2) Prepare PMP subcomponents according to the above schedule.

3) Provide input into planning deliverables that are the responsibility of the Department as needed.

4) Facilitate the Project kickoff meeting.

5) Capture minutes from the kickoff meeting and note any decisions or agreements. Minutes will be delivered for Department review and approval within three (3) business days of the kickoff.

6) Work with Department staff to establish workspace per the Contract.

7) Work with Department staff to establish the technical environment per the Contract.

8) Implement tool or database for tracking and reporting issues per the issue management plan.

5.1.2 Department Initiate and Plan Responsibilities 1) Obtain a MFMP Purchase Order to authorize Contractor work initiation.

2) Review, approve or reject all proposed Contractor staff.

3) Obtain results from Contractor and track successful completion of required background checks.

4) Prepare PMP subcomponents according to the above schedule.

5) Provide input into planning deliverables that are the responsibility of the Contractor as needed.


6) Supply workspace and configure required accounts and permissions as necessary for Contractor Project Team per the Contract.

7) Supply hardware, software and infrastructure for which the Department is responsible per the Contract.

8) Establish the SharePoint document repository for the Project.

9) Participate in the kickoff meeting.

10) Communicate with the Steering Committee and all key stakeholders regarding Project Initiation.

5.2 DDI Performance Period Phase Two: Requirements Elaboration

The Contractor shall elaborate and refine the requirements provided in this ITN to generate specific, detailed requirements. The Contractor shall verify requirements with the Department and other stakeholders to ensure requirements are correct, understandable and testable. Additionally, the Contractor shall specifically evaluate the completeness of the requirements to ensure that all requirements have been captured and develop any additional requirements necessary to address the entire System.

The Contractor shall generate detailed requirements by Joint Application Development (JAD) sessions or other Department-approved methodology proposed by the Contractor. The methodology must be consistent with the Contractor’s approved SDLC. The Contractor’s approach must acknowledge the time limitations of business users and facilitate and encourage the participation of all stakeholders (e.g., DRM, DIS, State Agencies) with efficient processes. The Contractor’s methodology shall clearly indicate the process that will be followed during the requirements sessions. The Contractor will work with the Department’s Project Manager to run requirements sessions and the Contractor shall prepare a clearly defined agenda at least three (3) business days prior to any meeting. The Contractor shall maintain minutes of the session and submit those to the Department for review and approval within three (3) business days of the meeting. In addition, the Contractor shall capture any modifications to the requirements according to the traceability requirements detailed below.

The Contractor shall generate a Requirements Definition Document (RDD) to document the requirements. The RDD must include, but is not limited to, use cases, descriptions of System and user interfaces, communication interfaces, product functions, user characteristics, constraints and assumptions, external interface requirements, design constraints, and logical database requirements. Note that particular care must be applied to documenting requirements related to external system interfaces. External business applications such as FLAIR (the State’s accounting system), FileNet (for Division document and image management) and CODA (the Department’s cash receipts system) among others perform essential functions for the Division and must be supported. A listing of known external interfaces can be found in Attachment I. The Contractor shall document all interface requirements, including plans to migrate and deprecate business applications that will no longer be needed with the new System.

The Contractor must maintain system requirements in a Requirements Management Tool. The Contractor shall provide this tool, subject to Department approval. The tool can be custom developed or industry standard, but must provide import/integration of standard tools such as Microsoft Excel, be web enabled and provide export/reporting features. The provided tool shall


include the ability to output a robust Requirements Traceability Matrix (RTM) to track the relationship between requirements and the developed System. The Contractor shall provide the Department with five (5) perpetual licenses for the tool for Department users if so requested.

After completion of the Requirements Elaboration phase, requirements will be Baselined. Should additional requirements come to light during later phases of the DDI, the Contractor will utilize the same elaboration methodology employed in this phase. Additional requirements will be recorded in the requirements management tool and evaluated for inclusion through the Project’s change management process.

5.2.1 Contractor Requirements Elaboration Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Provide a defined methodology to validate and maintain requirements including the process of how requirements validation sessions will be conducted.

3) Provide a proposed schedule of requirements validation sessions.

4) Ensure that the Contractor’s functional and technical experts are on-site during the requirements validation sessions to address and answer any questions.

5) Provide an agenda for each requirements validation session a minimum of three (3) days prior to the meeting.

6) Conduct and document requirements validation sessions.

7) Manage time efficiently during the requirements session to ensure efficient use of the participants’ time.

8) Provide a report of each requirements validation session, including but not limited to: issues addressed, decisions made, and business rules linked to the requirements, workflows, forms, etc. to the Department’s Project Manager within three (3) business days of the session.

9) Work with the Department to describe the business processes that will exist as a result of the proposed System implementation.

10) Validate needs through prototyping of functionality, navigation, and workflow.

11) Prepare the Requirements Definition Document, including interface descriptions.

12) Install and prepare the requirements management tool, as needed.

13) Provide training to Department staff in use of requirements management tool, as needed.

14) Enter requirements into the requirements management tool.

5.2.2 Department Requirements Elaboration Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Review and approve requirements elaboration schedule.


3) Participate in JAD or requirements elaboration meetings, with appropriate staff members to clearly describe required functionality and clarify needs to the Contractor.

4) Resolve any issues raised during requirements elaboration related to conflicting or unclear requirements.

5) Provide leadership in coordinating efforts with Department and partners for requirements elaboration.

6) Provide interpretation of legislative statutes and existing policies and procedures.

7) Identify business process owners with authority to provide input into requirements elaboration and process definition.

8) Work with the Contractor to describe new business processes that will result from use of the new System.

9) Review and approve all requirements deliverables, including meeting reports.

5.3 DDI Performance Period Phase Three: System Design

5.3.1 Design Phase – Functional Design

The Contractor shall generate a conceptual system design and provide a Functional Design Document (FDD) for the proposed System. The FDD shall include, but not be limited to, data models and process models and must include both graphic and narrative component for each form, report, interface, conversion and enhancement. All business rules and workflows must be documented in detail. The Contractor shall develop prototypes to depict System functionality including user interface screens that will be available in the final System. The Contractor shall update the requirements management tool to reflect the relationship between requirements and design elements. At the completion of the System development, the Contractor shall ensure that the FDD is updated to represent the complete “as-built” new System.

After acceptance of the Design phase by the Department, the functional design will be Baselined. The Contractor shall report all issues after this point through the accepted issue management process. The Contractor will record the issues in the accepted issue-tracking tool. Any modifications to the Functional Design Document after Baselining will be evaluated through the Project’s change management process agreed to in the PMP.

5.3.1.1 Contractor Functional Design Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Prepare the Functional Design Document.

3) Prototype forms and screens, menu navigation and business functions.

4) Facilitate walk-throughs of the System design with business process owners.

5) Capture results or modifications from walk-throughs and update documentation as needed. Summary meeting minutes must be produced within three (3) business days of meeting.


6) Update the Requirements Management Tool as needed to reflect the relationship between requirements and the design.

5.3.1.2 Department Functional Design Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Provide input into the functional design.

3) Participate in reviews and walk-throughs of the proposed System design and provide direction and feedback.

4) Review and approve all Design deliverables, including meeting reports.

5.3.2 Design Phase – Business Process Re-engineering

The Contractor shall work with stakeholders to create re-engineered, future state Department business processes to reflect the approved System design and shall document the new business processes. The future state business processes should enable stakeholders to effectively realize the full benefits of System implementation. All in-scope business processes shall be documented in a final To-Be Process Models document and provided to the Department for approval.

5.3.2.1 Contractor Business Process Re-engineering Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Create future state Department and Partner business processes to reflect the System as designed.

3) Create business process deliverables.

4) Prepare an Organizational Change Management Plan to prepare for the implementation of the new System, including the activities necessary for the Department and Partners to successfully adopt the new System while minimizing the impact to staff productivity and business performance. This Plan shall include staff roles and responsibilities.

5) Prepare a Staffing and Productivity Impact Analysis Report based on the model for the new System.

6) Facilitate walk-throughs of business process designs with business process owners.


5.3.2.2 Department Business Process Re-engineering Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Participate in process design sessions.


3) Provide interpretation of applicable statutes, rules, Department and Partner policies and guidance documents.

4) Develop any internal policy changes required to support new business processes.

5) Participate in reviews and walk-throughs of proposed business processes and provide direction and feedback.


5.3.3 Design Phase – Technical Design

The Department will work closely with the Contractor during the Technical Design. The Department reserves the right to directly participate in and contribute to tasks required during the Technical Design, in consultation with the Contractor.

The Contractor will specify software languages and tools that are widely available in the market. The Contractor shall generate a Technical Design Document (TDD) with the final requirements for the System, including a configuration plan, infrastructure plan and physical and logical security plan. The Contractor shall update the Requirements Management Tool to reflect the relationship between requirements and design elements. The Contractor shall conduct informal reviews of the design as it is developed and provide the Department with access to informal review information and documentation.

The Contractor shall develop its configuration management plan to include descriptions of the software configuration and customizations necessary to meet functional and non-functional requirements and interfaces.

The Contractor’s infrastructure plan must include a list of the hardware, software and network elements necessary to support the new System through implementation, production and ongoing support and maintenance. The infrastructure list shall include applicable Commercial-Off-The-Shelf (COTS) software, operating systems, relational database management systems, and other supporting software. The Contractor shall clearly identify all the proposed custom developed software. The Contractor shall provide an explanation of the associated benefits and risks for all recommended custom developed software. The Contractor will then work with DRM and DIS staff to evaluate existing resources to determine what hardware or software can be reused for the new System and evaluate alternatives for the System architecture.

The Department’s physical and logical Security Plan template must be included in the TDD. The Contractor will work with the DIS Information Security Office to complete the plan according to the Department’s Information Systems Development Methodology (ISDM). The plan shall include, but is not limited to: resource access enforcement, separation of duties, session management, remote or mobile access policies, logging and monitoring, authentication and data risk assessment.

The Department reserves the right to purchase any of the items specified in the TDD from another source instead of acquiring them from the Contractor if it is in the best interest of the Department.


After acceptance of the System Design phase by the Department, the Technical Design will be Baselined. This must occur prior to development beginning. The Contractor shall report all issues after this point through the accepted issue management process. The Contractor will record the issues in the accepted issue-tracking tool. Any modifications to the Technical Design Document after baselining will be evaluated through the Project’s change management process. The FDD and the TDD, once Baselined, will comprise the agreement between the Department and the Contractor regarding the functionality and operation of the System.

5.3.3.1 Contractor Technical Design Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Collaborate with Department staff to finalize the technical design, including the database structure, load management, and storage and hardware requirements.

3) Work with Department staff to evaluate existing assets to determine what can be used to support the new System.

4) Assist the Department in completing the physical / logical Security Plan template.

5) Prepare the Technical Design Document.

6) Facilitate walk-throughs of the System design with technical Subject Matter Experts (SMEs).



5.3.3.2 Department Technical Design Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Collaborate with the Contractor on the technical design, particularly with regards to existing environments, Department standards, security requirements, storage, DR and network capabilities, etc.



5) Procure necessary hardware or software.

5.3.4 Design Phase – Interface Design

A critical Division requirement is the seamless integration or interface of the proposed System with various external systems. A list of existing interfaces can be found in Attachment I. Some of these systems will be retired after implementation of the new System, as their functions will now be handled by the new System (for example, the Division currently uses a Microsoft Access application to issue and track invoices). Other systems will have to be modified to support an


electronic data interchange (EDI) with the new System (for example, the Department’s cash receipts system, CODA, will likely need to be modified to support a live feed of data from the new system), or will remain as they are, but the new system must automate the now-manual data exchange and apply appropriate business logic to responses provided by the external system. Finally, some external business applications will need to be integrated with the new System for seamless user interaction (for example, FileNet or the Medical Case Manager’s (MCM’s) management system).

The Department will work closely with the Contractor during the Interface Design. The Department reserves the right to directly participate in and contribute to tasks required during the Interface Design, in consultation with the Contractor.

The Contractor shall collaborate with the Department to define and document all interfaces with external business applications. The Contractor shall generate Interface Definitions for each of the external business applications that will be supported, describing each interface in detail, specifying purpose, format, content, frequency, and transaction processing. Each EDI-based interface must include a data map for incoming transactions that describes how incoming data is transformed, how appropriate business rules are applied and how data is mapped to the new System’s database. Each EDI-based interface must also include an export file definition, where needed, for outgoing data feeds. The export file definition must describe the field names, data type, length, allowable value limits, delimiter and any other data required by the target external business application.

The Contractor shall manage and facilitate all meetings on interfaces, prepare meeting minutes, and track interface coordination status in the status meetings. The Contractor shall update the requirements management tool to reflect the relationship between requirements and design elements.

After acceptance of the System Design Phase by the Department, the Interface Design will be Baselined. The Contractor shall report all issues after this point through the accepted issue management process. The Contractor will record the issues in the accepted issue-tracking tool. Any modifications to the Interface Definitions or design after Baselining will be evaluated through the Project’s change management process, agreed to in the PMP.

5.3.4.1 Contractor Interface Design Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Work with external business system owners / developers to define the functional and technical design for interfacing with the new System. The Contractor will propose innovative Systems where appropriate to achieve the Department’s objectives of eliminating manual effort to the degree possible and increasing data accuracy and timeliness.

3) Facilitate design meetings, prepare agendas and capture minutes of each interface session. Minutes, including issues addressed and decisions made, shall be submitted to the Department’s Project Manager within three (3) business days of meeting.

4) Prepare the Interface Definitions.


5) Update the TDD as needed for additional hardware or software necessary to support integration or EDI.

6) Facilitate walk-throughs of the interface designs with functional and technical SMEs.



5.3.4.2 Department Interface Design Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Identify application owners for each external business application.

3) Facilitate and coordinate with application owners to be available for Contractor meetings.

4) Obtain access / cooperation of any external (non Departmental) entity required for interface design (e.g. MCM Vendor).

5) Participate as needed in design meetings.

6) Work with Contractor to understand business rules or transformations that will have to be applied to external business system responses.



5.3.5 Design Phase – Data Conversion Design

STARS contains approximately 40 years of historical policy and claims data. In addition to STARS, DRM data exists in spreadsheets and databases where the existing system lacked the ability to store or process the data. The Department has a separate project underway to extract historical data from STARS, scrub and define it. The Department has not yet decided how much of the historical data will be brought into the new System.

The Department will work closely with the Contractor during the Data Conversion Design. The Department, in consultation with the Contractor, reserves the right to directly participate in and contribute to tasks required during the Data Conversion Design.

The Department will provide the Contractor with a data definition file. The Contractor will map that data to the new System’s data model. The Contractor shall create a Data Conversion Plan that defines how the data will be imported, transformed and tested for accuracy post-conversion. The Data Conversion Plan will be incorporated into the Contractor’s Go-Live Plan. The Data Conversion Plan should also address how historical data can be archived and retrieved according to the System’s established record management features.


5.3.5.1 Contractor Data Conversion Design Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Map data definitions into new System data model.

3) Develop the Data Conversion Plan.

4) Provide feedback to the Department’s data extract team on needed adjustments to the planned extract process.


5.3.5.2 Department Data Conversion Design Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Provide a data definition document to the Contractor that describes fields and definitions for data extracted from STARS and other systems.

3) Work with the Contractor to understand any requested adjustments to the planned extract routines.

4) Review and approve Data Mapping and Data Conversion Plan.

5.4 DDI Performance Phase Four: System Development and Test

In consultation with DIS, the Contractor shall install, configure and customize the software and perform unit testing. The Contractor shall maintain code review and unit testing results for Quality Assurance (QA) reviews by the Department. Unit testing shall be done on each unit of code to ensure that it functions as specified. The change management process as part of the PMP shall be used to address requested changes in design and implementation. Design, development, and testing staff may initiate change requests when encountering inconsistencies or opportunities for refinement in the application.

The Contractor shall provide the Package Data Model for the new System and will collaborate with the Department to install all hardware and software in order to facilitate knowledge transfer of the installation process. The Contractor shall install all software specifically associated with the System, regardless of whether it is purchased by the Contractor or purchased by the Department.

The Contractor shall develop and document development and testing guidelines. These guidelines must be approved by the Department before coding or development can begin. Following these guidelines, the Contractor will develop or extend all code packages necessary to implement the functional and non-functional requirements.

The Contractor shall develop and code all interfaces and integrations in collaboration with the Department’s technical staff who will liaise with external business system owners as necessary to develop and test interfaces and integrations. The Contractor shall also develop all reports identified in the Requirements Definition Document and work with the Department to validate their accuracy.


For non Commercial-Off-The-Shelf (COTS) code provided by the Contractor as part of the new System, the Contractor shall provide a tested release of the code and release notes as planned in the Project schedule. The Contractor shall update and resubmit the software code whenever changes to the operational software are implemented.

The Contractor shall provide a tracking and reporting system for System defects and testing results. The Department shall have direct access to the defect tracking system at all times, and the Contractor will report the resolution of all defects in the System. Once implemented the defect tracking and reporting system will be used and maintained throughout the duration of the Contract.

The Department will work closely with the Contractor during the Technical Design phase. The Department reserves the right, in consultation with the Contractor, to directly participate in and contribute to tasks required during the System development, configuration and testing.

5.4.1 Contractor System Development and Test Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Assist the Department in setting up development, test and production environments, inclusive of all required hardware and software.

3) Assist the Department in setting up disaster recovery and testing the disaster recovery configuration.

4) Collaborating with DIS resources, install and configure the proposed System per the Functional and Technical Design documents to the most current production version of all underlying software, tools, and databases, unless the Department agrees to an exception.

5) Work with Department technical staff during package installation and configuration to provide knowledge transfer.

6) Create new or modified objects, programs or scripts.

7) Create unit test cases, test data and load into test environment.

8) Design and perform unit testing.

9) Report unit test results.

10) Prepare code / configuration packages and unit test deliverables.

11) Design and document reports as described in the Requirements Definition Document, including purpose, format, content and frequency.

12) Design, develop and test reports.

13) Update the Requirements Management Tool to reflect the linkage between requirements and the as-built System.

14) Submit deliverables to the Department for review.

5.4.2 Department System Development and Test Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.


2) Work with the Contractor to create development, test and production environments.

3) Work with the Contractor to create and test the DR environment.

4) Participate in the coding and construction of the final System.

5) Provide test environments of external business applications as needed for development and testing of interfaces.

6) Participate with the Contractor during package installation and configuration for knowledge transfer.

7) Review System objects for conformance with software development and documentation standards.

8) Provide clarification of requirements and design option decisions.

9) Coordinate with external parties as needed to support the Contractor in activities related to interface development and testing.

10) Work with the Contractor and external parties to validate the appropriate exchange of data with external business applications.

11) Work with Contractor to validate the appropriate business rule handling of received data from external business applications.

12) Validate the user interface integration between the System and external business applications.

13) Review and approve the code and unit test deliverables.

14) Work with the Contractor to validate the reports described in the Requirements Definition Document.

15) Provide subject matter experts to clarify and provide existing reports as needed for clarification.

16) Review and approve reporting deliverables.

5.5 DDI Performance Phase Five: Data Conversion

The Contractor shall develop and test conversion software, coordinate all conversion activities, develop the control process to manage any manual conversion efforts and support the Department’s manual conversion as necessary.

The Contractor shall work closely with the Department to create data conversion routines and update the Data Conversion Plan to reflect the as-built System and final routines. The Department shall provide data extracts and the Contractor’s routines will perform the transformation and loading. The Contractor shall verify, in collaboration with the Department, the successful transformation and load of the data.

The Contractor shall make converted data available for unit tests, integration tests, System tests, performance tests and user acceptance tests. The Contractor shall design data conversion software and procedures to be used during implementation before any location or user group “goes live” in the new System.


5.5.1 Contractor Data Conversion Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Support the Department with performing data quality analysis and cleansing.

3) Update the data conversion plan and data mapping to reflect the as-built System.

4) Collaborate with the Department to code and test data conversion routines.

5) Conduct mock data conversion with full data sets.

6) Produce reports of record exceptions, including missing data and likely duplicate entities or records.

7) Recommend mitigation strategies for combining duplicate entities or records or for handling missing data and data exceptions.

8) Run clean data conversions to create clean data sets for each major testing phase, including unit testing, System, integration, performance and user acceptance testing.

9) Run clean data conversions in accordance with the SDLC implementation and Go-Live strategy.

10) Update data conversion documentation to reflect as-built conversion.

5.5.2 Department Data Conversion Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Review and approve updates to the data conversion plan.

3) Extract data from all legacy systems, ancillary databases and Excel spreadsheets and provide it to the Contractor in a defined, reproducible format.

4) Provide the Contractor with a description of all data elements and relationships.

5) Perform data cleansing activities, including systematic data cleansing and identifying manual record adjustments that should be made by the Department.

6) Work with the Contractor as the Contractor develops data transformation and load routines.

7) Make data modifications necessary to respond to conversion load error reports provided by the Contractor.

8) Assist the Contractor in validating converted data.

9) Review conversion routines for conformance with software development and documentation standards.

5.6 DDI Performance Phase Six: Testing

The Contractor shall test the System in accordance with the accepted SDLC. The Contractor shall involve the appropriate Department technical staff in all aspects of testing and will actively perform knowledge transfer during this Phase. Prior to beginning the test phase, the Contractor shall create a Master test plan that describes the overall approach and process for System,


performance, end-to-end, user acceptance, interface, usability and regression testing objectives. The Master Plan shall include the tools to be used for testing, process for populating test databases, users and resources that will be involved in testing, testing schedule and approach to capturing and tracking testing results.

The Contractor will perform all testing on actual data provided by the Department.

The Contractor shall generate all required test documentation (e.g., test plans, test cases, result reporting templates, etc). During test planning, the Contractor shall update the Requirements Management Tool to reflect the relationship between requirements and planned acceptance tests.

The Contractor shall not consider any test case complete until the designated Department staff provide approval(s). The Contractor shall record and track all problems identified during acceptance. The Contractor shall troubleshoot all test result anomalies to determine the source of the problem. If necessary, the Contractor shall update test plan, test cases, and test scripts, and shall modify and re-test the System. Following any software change or test script change made during the testing period, the Contractor shall perform a regression analysis of tests already executed to determine which test results may have been affected by the change and need to be re-executed.

5.6.1 Test Phase – Application Testing

The Contractor shall test the new System in accordance with the SDLC for:

• System Testing to exercise the assembled System and confirm that it operates as expected including System security and user profiles.

• End-to-End testing to confirm that assembled units, modules and COTS application modules operate effectively together and meet all functional objectives as described in the Requirements Definition Document.

• Interface Testing to exercise every interface and confirm that each interface operates according to the Interface Definitions in the Requirements Definition Document, including interfaces to COTS packages.

• Performance / Stress Testing to simulate the System to the limits of its requirements and beyond those limits to confirm graceful failure, including but not limited to, COTS packages, and to confirm satisfaction of performance requirements in a simulated test environment.

• Usability Testing to evaluate the user interface.

• Regression Testing as needed after code modifications to verify core application functionality for all software builds and defect remediation.


5.6.1.1 Contractor Application Testing Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Create all required System integration testing deliverables.

3) Update the requirements management tool to reflect the relationship between requirements and planned tests.

4) Establish the test environments.

5) Install and configure clean instances of the new System, in the most current production version of all underlying software, tools, and databases for testing, unless the Department agrees to an exception.

6) Create test data and test files needed for initial testing as well as for re-testing (if any).

7) Conduct integration and System tests. Each module must be tested when it is completed. The compatibility of all modules for the entire System must be tested when all modules have been completed.

8) Conduct interface testing.

9) Conduct stress and performance testing.

10) Conduct usability testing.

11) Assist Department in data conversion testing to confirm that all legacy and support data is correctly migrated and available in the System.

12) Correct problems, repeating integration, System, stress and performance testing until expected results are obtained.

13) For each set of tests performed, provide documentation for all test results.

5.6.1.2 Department Application Testing Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Provide staff to participate in all System integration testing activities, especially when testing interfaces with existing systems that are not provided by the Contractor.

3) Coordinate with external business system owners to test accuracy and functionality of EDIs and System integration interfaces.

4) Provide appropriate review and approval all testing deliverables.

5.6.2 Test Phase – User Acceptance Testing

The Contractor shall assist the Department with conducting user acceptance testing (UAT) to demonstrate that all requirements are met, and shall provide to the Department documentation to report the outcomes of the user acceptance testing. The Department may identify additional tests during review of acceptance test planning and testing to ensure that the acceptance tests are thorough and complete.


The Contractor, with Department guidance and validation, shall develop test cases, test scripts, test data and test files for all test cases including any added by the Department. The Contractor shall confirm that user acceptance tests have been planned for all requirements by tracing the requirements to the planned acceptance tests and their associated test cases and test scripts.

User acceptance testing shall be conducted in the user acceptance test environment that duplicates the operational environment to the greatest extent possible. An acceptance test team composed of appropriate Department stakeholders will perform the acceptance test together with help, participation and support of the Contractor.

Acceptance Testing shall verify the following:

• Adherence to all requirements and design documentation;

• Documentation of any defects existing in the software;

• Full installation of the application software and functional objectives;

• Conversion of legacy data;

• Completeness and accuracy of System documentation;

• As applicable, resolution of STARS system deficiencies.

• Response time and overall System performance;

• System, data, and application security; and

• Accuracy/performance of System interfaces.

5.6.2.1 Contractor User Acceptance Testing Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Develop all UAT deliverables.

3) Establish the application in the UAT environment.

4) Supply training needed for UAT.

5) Create UAT data and files needed for initial testing as well as for re-testing (if any). UAT must be conducted with fully converted production data.

6) Generate UAT plan, test scenarios, and test result logs.

7) Update requirements management tool to reflect the relationship between requirements and planned user acceptance tests.

8) Provide support during UAT.

9) Document and correct issues.

10) Develop UAT analysis reports.


5.6.2.2 Department User Acceptance Testing Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Review and approve UAT plan.

3) Arrange for appropriate UAT staff availability.

4) Execute user test cases as defined by the UAT Plan.

5) Provide support during UAT.

6) Review and approve documentation and correction of issues.

7) Review and approve UAT analysis reports.

8) Review and approve UAT deliverables.

5.7 DDI Performance Phase Seven: Implementation

This Phase consists of System Go-Live and Training.

5.7.1 Implementation Phase – System Go-Live

In collaboration with the Department, the Contractor shall develop a production Go-Live plan that includes at a minimum, promotion of the software to the production environment, data conversion and population of the production system, system availability to users, training, documentation, identification of the steps leading up to the Go-Live, and a strategy to rollback in case of major issues encountered during the Go-Live. If the Go-Live plan utilizes a phased approach, the plan must also show how the remaining functionality will be implemented. The plan must include: Database Administrator (DBA) procedures, installation procedures, a rollback plan and Go-Live schedule, application installation scripts and a final acceptance report for each planned release in the approved project schedule.

The Department’s staff will participate in all Go-Live activities.

5.7.1.1 Contractor Go-Live Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Develop the Go-Live plan.

3) Work with Department staff for planning and coordination of hardware and software supporting the new System.

4) Deploy the new System into the production environment.

5) Test the System in the production environment to confirm successful installation and deployment.

6) Provide on-site support during the implementation.


5.7.1.2 Department Go-Live Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Review and approve the Go-Live plan and schedule.

3) Assist the Contractor in planning, coordinating and executing hardware and software installations.

4) Confirm successful installation

5.7.2 Implementation Phase – Training

The Contractor shall present a method to train the user population defined below that balances effectiveness with expense. The Contractor shall provide a Training Plan that will ensure all System users have the knowledge and skills necessary to effectively employ the System and supporting technology. The plan should address how the Contractor will train Department and other Eligible Users prior to deployment, as well as conduct refresher training and new hire training for Department staff for the duration of the Contract.

The Contractor shall implement the Training Plan and work with the Department to train, or provide a mechanism to train, all users including Department staff, other State Agencies and other identified users or stakeholders. The Contractor’s training materials shall be tailored to the Department’s System. The Contractor shall provide the Department with all training material for the operation and support of the System. The Contractor’s training tool and materials shall be provided in an electronic format that allows the Department to update or edit the materials and conduct train-the-trainer sessions after the Contractor’s training responsibilities have been completed.

The Training Plan must include:

• In-person training conducted in Tallahassee for end-users, super users and limited users.

• A combination of structured and on-the-job training for Technical Support / customer service / help desk / user support resources so they are prepared to transition into these roles when the warranty period ends.

• Train the Trainer courses and materials so that the Department can train new staff, provide refresher courses for existing users or provide continuing education for future System modifications.

• Outreach training for Eligible Users to access and learn the System functions available to Eligible Users and other public entities.

• Focus all training on skill acquisition and helping end users become self-sufficient in the use of the new System. Materials should include step-by-step user and System instructions.

• Training targeted to the business or support process appropriate to the audience being trained.

• A training environment that accurately replicates the functionality and actual data of the production System.


• A training schedule that permits training for UAT testers to be complete prior to user acceptance testing.

• Appropriate coordination and agreement between training materials and the content of online help within the System.

• Evaluating training for effectiveness and continuous improvement with testing of Department employees (on a pass/fail basis) to confirm that all training topics are mastered.

5.7.2.1 Contractor Training Responsibilities 1) Work with the Department to develop the DED for Phase Deliverables.

2) Develop all training deliverables, including the Training Plan and all training materials and courses. Deliver training materials in electronic, editable formats that allow the Department to update and maintain the materials. Training materials must include at a minimum a step-by-step training guide and an electronic, searchable user manual. All training materials must accurately reflect the as-built System.

3) Develop training materials and programs and deliver training for the following user groups:

o End-users (approximately 113 users): The Contractor must develop and deliver all core module training, appropriate refresher training, and relevant updates on the new System’s application software.

o Super users (approximately 10 users): This target audience includes functional and technical analysts, trainers, key Department and Partner staff, and other staff as identified by the Department and Partners.

o Limited users (approximately 300 users): This group consists of users from other State Agencies and staff from other areas of the Department who require a basic knowledge of the use of the System in order to perform their job functions, but who do not require the in-depth training that functional end-users require.

o Technical Support / customer service / help desk / user support resources (approximately 15 users): The Contractor must ensure that designated staff members are capable of providing effective help desk and user support services. The training for help desk/user support staff members must cover all core module training plus the following knowledge and skill areas:

Customer Service / user support / help desk management

Face-to-face and remote diagnosis and troubleshooting techniques

Knowledge of the new System’s application architecture

The new System’s web services

Firewall and network infrastructure support

Application security and access controls

Software maintenance


Reporting, ad hoc querying, and data warehousing

Printing

4) Facilitate knowledge transfer to Department and Partner stakeholders and all other Project team members concerning all aspects of the functionality, use, and reporting capability of the new System

5) Refresh the training to match the needs of the training schedule. If the schedule cannot suit all classes, the Contractor shall set up multiple copies of the training database and an easy method to access the proper copy or an easy method for allowing trainers to conduct a refresh of training data without requiring technical assistance.

5.7.2.2 Department Training Responsibilities 1) Work with the Contractor to develop the DED for Phase Deliverables.

2) Develop and deliver training related to operational procedures and policy changes as a result of the new System implementation.

3) Support the Contractor’s tasks to plan, monitor and deliver training.

4) Assign a training team leader from the Department’s Project team.

5) Monitor all training provided by the Contractor.

6) Review evaluation forms and provide feedback on training design and delivery throughout the implementation training period.

7) Scheduling the training class dates, reserving classrooms, providing in-class liaison staff, scheduling attendees, and providing logistical support.

Section 6 Services Transition (ST) Performance Period

The Services Transition performance period begins with the Go-Live of the new System and ends two years post Go-Live. The purpose of the services transition period is to enable an orderly transition from the Contractor to the Department operating the System in a self-sufficient manner.

The ST Performance Period contains two phases – a Warranty Phase and a Services Transition Phase. The Warranty Phase and the Services Transition Phase will begin simultaneously when the System is accepted by the Department.

Prior to moving into the Warranty Phase, the Contractor shall obtain written notice from the Department that all acceptance criteria have been met and that the System is operating in production without any material deficiency and with all required functionality.

6.1 ST Performance Period Phase A – Warranty Phase

The Contractor shall provide a warranty for software developed and implemented specifically for the System, and for integration of all software in the System, according to the Warranty


requirements of Attachment A: Standard Contract, section 15, after full operational capability is declared by the Department and System Final Acceptance by the Department.

The Warranty Phase must provide all break-fix services, in addition to the services detailed below. The Services Transition Resource available during the Services Transition Phase will perform only maintenance and enhancement during the warranty period. After the warranty period ends, the Services Transition Resource will additionally provide break-fix services under the fixed monthly fee for that resource.

During the Warranty Phase and the Services Transition Phase, Service Level Agreements (SLAs) shall govern the Contractor’s actions. The purpose of the SLAs will be to establish a common commitment to roles, responsibilities and communication processes.

The Contractor shall pass-through to the Department the full standard warranty available from any COTS software provided by the Contractor.

6.1.1 Contractor Warranty Responsibilities 1) Monitor the System production environment performance.

2) Develop appropriate procedures for Department to report and track issues or defects using the established defect tracking system.

3) Correct all reported or identified defects in a timely fashion (per Service Level Agreements).

4) Test any warranty repair according to the accepted SDLC to ensure that it is complete and appropriate. Conduct regression testing to avoid other problems created by the warranty repair. Prepare testing reports as described in Section 5.5.1: Application Testing.

5) Coordinate installation and testing of repaired software with the Department and update all documentation affected by the change. For critical defects that prevent complete operation of the System, the Contractor shall provide a workaround for the problem.

6) Coordinate any warranty repair defects identified in any COTS software provided, including providing the COTS Vendor with any required information, monitoring completion and installation of repairs and testing the System after conclusion of repairs.

7) Generate a Warranty Completion Report at the conclusion of the Warranty Phase as defined in Section 8: Summary of Project Deliverables for All Phases.

6.1.2 Department Warranty Responsibilities 1) Provide written notice of acceptance of the production system and initiation of the

Warranty Phase.

2) Review and approve warranty support deliverables.

3) Report defects according to the accepted defect reporting process.


6.2 ST Performance Phase B – Services Transition Phase

The Department intends to develop the in-house capacity to maintain the System, but recognizes that DRM and DIS staff have limited availability to train and assume System responsibilities. The Department shall engage the Contractor to assist in building this in-house capacity. The Contractor shall commit a key member of its implementation team to continue in a staff augmentation capacity onsite with the Department for a period of two years (24 months) to provide support to DRM and DIS. During this time, the Contractor’s Services Transition Resource will maintain the System, correct defects after expiration of the Warranty Phase and implement requested enhancements to the System according to the direction of the Department. The Department will assign the duties of the Services Transition Resource and prioritize service requests within available time.

During the Transition Phase, Department staff (availability permitting) will work closely with the Services Transition Resource to learn the System. Over time, and as proficiency permits, Department staff will assume the duties of the Services Transition Resource and perform them under the Contractor’s supervision. If the Department is not able to allocate sufficient staff resources to build this proficiency in-house, the Department reserves the right to amend the Contract for ongoing support after the two-year Services Transition Phase (see “Operational Support” Performance Phase).

The onsite representative shall be a member of the implementation team with direct knowledge of the requirements, configuration and development of the System. The Contractor must identify the Services Transition Resource as a Key Personnel of the proposed project team.

During the Services Transition Phase, the Services Transition Resource shall develop a Services Transition Plan, update appropriate DDI documentation to reflect the as-built System, including the Requirements Management Tool, Functional Design Document, Technical Design Document, security plan, training materials and user manual as well as provide day-to-day support and maintenance to meet SLAs. Day-to-day support may include, but is not limited to, help desk support, user training, report development, System request assessment, defect resolution, enhancement configuration or coding, testing and upgrade installation.

The Services Transition Plan shall include a schedule, description of required knowledge, skills and abilities (KSAs) that Department staff must demonstrate prior to assuming Contractor duties, method(s) for assessing Department staff proficiencies in the KSAs and a maintenance manual that describes the activities necessary to maintain the System.

Section 7 Operational Support (OS) Performance Period

In the last six months of the ST Performance Period, the Department shall conduct an evaluation of its internal capacity to support and maintain the System.

If the Department determines, in its sole judgment, that it is in the State’s best interest to retain the Contractor to provide ongoing Operational Support, the Department will notify the Contractor in writing. If so noticed, the Contractor shall provide Operational Support services for two years, beginning at the completion of the ST Performance Period and ending with the expiration of the original contract term. If the Department chooses, the Department can renew the Contract for


Operational Services for an additional five years. When the Department notifies the Contractor that Operational Support services are needed, the Department and the Contractor will negotiate to refine the following Statement of Work and the Department will document an SLA, which will enumerate the Department’s expectations of the Contractor’s responsibilities, timeframes, responsiveness and other details. As directed in the ITN, the Contractor shall identify the fees for Operational Support services in the Hourly Service Rate Card section of Attachment C: Price Response. The refined Statement of Work and the SLA will be incorporated into the Contract by executing an Amendment.

The Statement will include, at a high level:

1. Error or defect tracking and correction and troubleshooting EDI and scripting errors

2. Report writing

3. Data Cleansing / Correction

4. Installation of upgrades and patches

5. Staff training and desktop support related to the System

6. Troubleshooting of interfaces, scripts and EDI



Section 8 Project Deliverables for All Phases

The Contractor shall be responsible for the completion of the project deliverables described in this Statement of Work and any additions or deletions agreed upon during Contract negotiations. The Contractor will submit Deliverables according to the requirements of Attachment A – Standard Contract section 8 (Acceptance of Deliverables).

The Department’s designated Contract Manager and Project Manager will monitor the Contractor’s performance in accordance with the requirements of the Contract. Deficiencies may be subject to a financial consequence as defined in Attachment A – Standard Contract section 10 (Consequences for non-Performance).

The Contractor shall follow the accepted PMP and SDLC procedures for deliverable development and submissions. The Deliverables specified in this Statement of Work follow this section.

8.1 Project Governance and Oversight Deliverables Ref Deliverable Major

Deliverable? Description Deliverable SOW

Reference Minimum Performance Standards

1 Weekly Status Reports Weekly Status Meetings

No Weekly status updates and meetings that follow the agreed format and structure.

Project Management • Status reports are submitted on the agreed template and show completed activities, projected activities, issues, risks, percent complete of tasks, percent complete of budget.

• Status meetings are attended in person by the Contractor’s project manager.

2 Knowledge Transfer Plan

Yes Early description for how the Contractor will train the Department in the System throughout the engagement, rather than just at the end.

Knowledge Transfer • Knowledge transfer plan is delivered to the Department 30 days after contract execution.

• Knowledge transfer plan describes knowledge transfer points at each phase gate and in each phase of the project.

• Knowledge transfer plan describes how it will morph into the Transition Plan required in ST Performance Period Phase B: Transition Phase.

3 Meeting Minutes

No Minutes from meetings hosted by the Contractor

Multiple References • Minutes identify the participants, time, location and purpose of each meeting.

• Minutes describe the decisions, next steps and outcomes of the meeting.

• Minutes describe any major discussions or points of debate.

• Minutes are submitted to the Department for review within three (3) days of the meeting.

8.2 DDI Performance Period Phase One: Project Initiation Deliverables Ref Deliverable Major



P1-1 Kick Off Meeting and Materials

No Kick off for the project and review of project management approach.

Project Initiation and Planning

• The kickoff meeting is held within 30 days of Contract execution.

• All key Contractor staff are present at the meeting. • Minutes are captured and submitted to the

department within three (3) days of the meeting. • All expected elements of the PMP are prepared.


Ref Deliverable Major

Deliverable? Description Deliverable SOW Min mum Performance Standards

Reference i

P1-2 Project Management Plan Components

Yes The project management plan governing all aspects of the Project execution, including SDLC. The Department is responsible for completing the PMP with input from the Contractor.

Project Initiation and Planning Disaster Preparedness

• All expected elements of the PMP are submitted to the Department by the due date agreed with the Department Project Manager.

• Project schedule is created in Microsoft Project and includes all tasks, durations, resources and dependencies necessary to execute the Project.

• Project schedule is resource loaded. • SDLC methodology describes the control processes

for design, development and testing. • SDLC addresses promotion of the software to the

various instances/environments (e.g., System test, user-acceptance test, production environment).

• SDLC describes the methodology for requirements elaboration.

• Disaster Response plan addresses key project risks (such as the loss of a key staff person or hardware failure) in addition to standard DR threats (addresses project continuity).

• Quality Management plan describes the governance model for code reviews, peer reviews and development standard enforcement.

• Risk and Issue Management Plan describes an issue tracking tool provided by the Contractor.

• Risk and Issue Management Plan describes the processes for identifying, submitting, documenting, assigning, tracking, mitigating and resolving risks and issues.

• Human Resource Management and Staffing Plan identifies key Contractor personnel and their KSAs and experience.

• Human Resource Management and Staffing Plan describes contractor onboarding process.

• Human Resource Management and Staffing Plan describes minimum required staffing levels and how the Contractor will staff the DDI and ST periods, emphasizing the continuity of resources between the DDI and ST periods.


8.3 DDI Performance Period Phase Two: Requirements Elaboration Ref Deliverable Major



P2-1 Requirements Definition Document

Yes Captures the functional and non-functional requirements of the System.

Requirements Elaboration

• The RDD includes descriptions of System and user interface requirements, communication interface requirements, product functions, user characteristics, constraints and assumptions, external interface requirements, design constraints, and logical database requirements.

• The RDD includes documentation of all interface requirements, including plans to migrate and deprecate business applications that will no longer be needed with the new System.

• The RDD includes supporting materials, including minutes from JAD sessions that were attended by appropriate technical and functional Contractor SMEs. The minutes were submitted to the Department within 3 days of the meeting and final approved versions are included as an appendix to the RDD.

• The JAD sessions / requirements validation activities were executed according to the agreed upon Requirements Validation Methodology.

• The RDD makes an affirmative statement that the Contractor has validated the completeness of the requirements.

P2-2 Requirements Management Tool / Requirements Traceability Matrix

Yes Record of all of the functional and non-functional requirements to be traced to later software implementation or development activities.

Requirements Elaboration

• The Requirements Management Tool (RMT) is a custom-developed or industry-standard tool that can import and export data from tools such as Microsoft Excel.

• The RMT includes all functional and non-functional requirements for the System.

• The RMT identifies requirements at the lowest level required to perform design activities; values are identified at the field level and consistency edits are defined.

• The RMT references the decision owner and decision made to determine how the requirement is met (or not met) by the System or DRM business process.

• The RMT has the ability to output a Requirements





Traceability Matrix that clearly shows the relationship between requirements and their implementation in functional or technical design.

• The RMT is updated throughout the engagement to continue to show the relationship between requirements and as-built System and test results to demonstrate that requirements have been delivered.

8.4 DDI Performance Period Phase Three: System Design Deliverables Ref Deliverable Major



P3-1 Functional Design Document

Yes Detailed Functional design showing how the System will meet the functional requirements.

Design Phase – Functional Design

• The FDD includes data models and process models. • The FDD includes graphic and narrative descriptions

for each form, report, interface, conversion and enhancement.

• The FDD documents all business rules and workflows in detail.

• The FDD includes prototypes that depict System functionality including user interface screens that will be available in the final System.

• The FDD includes use cases for each major Actor / function.

• The FDD describes all required reports in detail, including layout and structure, scheduling, delivery and any other pertinent details. Where reports can be delivered via standard built-in reports, this is noted.

• The FDD is updated throughout the engagement to represent the final as-built System.

P3-2 Future State Documentation

Yes Future business process description, including organizational change management plan and staffing and productivity impact analysis

Business Process Re-Engineering

• The future state document describes the business processes that will be in place after the System is implemented for all in-scope functions.

• The document includes process flows and narratives.

• The document includes an organizational change management plan that addresses training, communication and implementation phasing.

• The document includes a staffing and productivity





impact analysis that describes the expected day-to-day impact of new processes and system tools.

P3-3 Technical Design Document

Yes Detailed Technical design showing how the System will operate. Includes infrastructure plan, security plan and configuration plan.

Technical Design • The TDD includes a configuration management plan that includes descriptions of the software configuration and customizations necessary to meet functional and non-functional requirements and interfaces.

• The Configuration Management Plan includes processes for functional and physical configuration audits to ensure that configurations are consistent with requirements and that functional and performance attributes are achieved.

• The TDD includes an infrastructure plan that lists all hardware, software and network elements necessary to support the new System through all SDLC phases.

• The infrastructure plan describes all COTS, operating systems, database management systems or other software needed to operate the System.

• The infrastructure plan shall identify and explain use of all custom developed software.

• The infrastructure plan shall include an assessment of existing Department assets and a determination as to what can be reused for the new System.

• The TDD includes the Department’s Security Plan template, which the Contractor completed in collaboration with the Department’s Information Security Office.

• The TDD includes an affirmative statement that the Contractor has evaluated the completeness of the technical requirements.

• The TDD is updated throughout the engagement to capture the as-built System.

P3-4 Interface Definitions

Yes Design interfaces and integrations for the new System

Interface Design • An Interface Definition exists for every interface and integration that will exist with the new System.

• The Interface Definitions identify in detail the purpose, format, content, owner, data transmission frequency, detailed data map, completeness and accuracy controls, exception handling and





processing for each interface transaction.

P3-5 Data Conversion Plan

Yes Defines how legacy data will be imported, transformed and tested for accuracy post-conversion.

Data Conversion Design

• The Data Conversion Plan identifies source systems, and any additional electronic or hardcopy sources of data that are required and the goals and issues for each source system.

• The Data Conversion Plan includes a Data Map showing how the legacy data aligns to the new data model.

• The Plan includes roles and responsibilities of the Contractor and Department.

• The Plan addresses how historical data can be archived and retrieved according to the System’s established record management features.

• The Plan describes the processes for loading, transforming and testing the data for accuracy.

8.5 DDI Performance Period Phase Four: System Development and Test Deliverables Ref Deliverable Major



P4-1 Package Data Model

Yes Provide the data layout of the package System.

System Development and Test

• The Package Data Model includes the complete data model to illustrate the data needed and created by business processes for the System.

• The Package Data Model describes the process for keeping the System current and the approach for upgrading to new versions of hardware or software.

P4-2 Package and Configuration Training for Team

No Provide training material and teach the DIS team how to install and configure the package.


• Training includes training material for core technology and System administrators on the approach and process to install the hardware, package data, and other required software tools.

• Training teaches the core technology and System administrators the approach and process to configure the software package and configure other required software tools.

P4-3 Objects and Packages

Yes Configure and extend the package per the functional design.


• Software is installed and configured according to the TDD.

• Code is developed per the approved development




Reference Minimum Perf ro mance Standards

guidelines. • All application standards are correctly implemented. • Code is peer reviewed and unit tested prior to

delivery to the Department for review. • Unit testing is demonstrated through documented

test cases, test data and test results (output or screenshots) that demonstrate successful test.

• Code is developed according to the FDD, TDD and the requirements management tool is updated to reflect the link between requirements and code or configuration.

• All interfaces and integrations are developed in collaboration with the Department’s technical staff and according to the Interface Definitions. All interfaces and integrations are thoroughly tested to verify accurate EDI and business processing.

• All reports defined in the Requirements Definition Document are developed and scheduled as needed and output is provided to the Department for review.

• All code is provided to the Department for review. • A defect tracking system is set up and available for

the Department to access at all times during this and later phases.

P4-4 Unit Test Results

No Output from unit testing


8.6 DDI Performance Period Phase Five: Data Conversion Deliverables Ref Deliverable Major



p5-1 Data Conversion Routines

Yes Routines coded and tested to transform and load the Department’s relevant risk management data utilizing extracts provided by the Department.

Data Conversion

• Code and test data conversion routines according to the Data Conversion Plan and the agreed data map.

• Routines are tested through mock data conversions with full data sets and the Department is provided results to evaluate for accuracy.

• Conversion routines are run to create clean data sets for each major testing phase, including unit testing, System, integration, performance and user





acceptance testing. • Conversion routines are run as required by the

SDLC implementation and Go-Live strategy. P5-2 Data

Conversion Exception Reports

No Reports provided to the Department to facilitate data cleanup and issue resolution.

Data Conversion • Reports include record exceptions, including missing data and likely duplicate entities or records.

• Report analysis includes recommended mitigation strategies for combining duplicate entities or records or for handling missing data and data exceptions.

8.7 DDI Performance Period Phase Six: Testing Deliverables Ref Deliverable Major



P6-1 Master Test Plan

Yes Overall plan for conducting testing on the deployment ready System.

Testing • Master Test Plan includes testing approaches for System, end-to-end, interface, performance / stress, usability, regression and User Acceptance Testing objectives.

• Master Test Plan describes the processes, tools, success criteria, assumptions and parameters for each testing objective.

• Master Test Plan includes test cases for all major actors and functions.

• Master Test Plan describes the process for populating test databases.

• Master Test Plan identifies the testers and assigns them to roles/actors and test cases as necessary.

• Master Test plan describes the process for reporting identified defects, tracking their assignment, analysis, resolution and re-testing (including regression testing where appropriate).

• Master Test Plan describes the testing schedule. • Master Test Plan includes reporting templates that

capture test results from testing participants. P6-2 Tester Training No Training provided by

the Contractor to Department resources to enable them to effectively participate in testing.

Testing • Department resources are trained in the use of the system.

• Testing resources are trained in the use of the defect tracking system and the testing process, schedule and responsibilities.




Reference i

• Testing resources are trained in documentation standards and requirements for capturing test results.

• Testing resources are assigned to their respective testing objectives and the use of appropriate results templates.

P6-3 Testing Results No Results of execution of various testing objectives as described in the Master Test Plan.

Testing • Results include a narrative summary of testing results, including metrics (e.g. number of defects reported by module) for each test objective.

• Results include raw output from testing templates as supporting documentation.

• Results include reports from defect tracking system showing defects by type and resolution.

8.8 DDI Performance Period Phase Seven: Implementation Deliverables Ref Deliverable Major



P7-1 Go-Live Plan Yes Plan for implementing System into a production environment.

System Go-Live • Go-Live Plan includes: • Promotion of the software to the production

environment; • Data conversion and population of the production

system, • System availability to users, • Training, • Documentation, • Identification of the steps leading up to the Go-Live, • A strategy to rollback in case of major issues

encountered during the Go-Live. • A plan for how multiple phases will be implemented

if phased, • Database Administrator (DBA) procedures, • Installation procedures, • A Go-Live schedule, • Application installation scripts, and • A final acceptance report for each planned release in

the approved project schedule.




Reference i

P7-2 Deployment Yes Deployment of System into a production environment

System Go-Live • The System is live in the production environment and functioning as expected.

P7-3 Training Plan No Plan for providing all required training to all audiences included in the Statement of Work.

Training

• The Training Plan describes the training approach (class room, computer based, train the trainer, etc) and specific resource time and resource commitments for training four distinct training audiences.

• The plan provides for Train-the-Trainer courses and materials.

• The plan provides a training schedule. • The plan addresses how the Contractor will train

users prior to deployment, as well as conduct refresher training and new hire training for the duration of the Contract.

• The plan describes a training approach that is tailored to the specific needs of each training audience.

• The plan describes the requirements for a training environment that accurately replicates the functionality and actual data of the production System.

• The plan describes the method(s) that will be used to evaluate effectiveness of training and confirm that training topics are mastered.

P7-4 Training Materials

No Training material modified for the customizations and processes used at DRM.

Training

• Training material covers all System functionality and all stages in the business process lifecycle, and includes enhanced functionality as required by the Department.

• Training material includes step-by-step user and System instructions that include data field options and status updates.

• Training material includes training materials and training/job aids for on-going end user reference and support, and use the Train-the-Trainer methodology.

• Training materials are accessible to external users to learn the new IMS functions available to State Agencies and other public entities.

• Training materials are provided in electronic, editable formats that allow the Department to update





and maintain the materials. • All training materials accurately reflect the as-built

System.

P7-5 User Manual Yes

Training • Training materials include an online, searchable user manual.

• User manual addresses all the System functionality, as recorded in the requirements.

• User Manual is integrated with context-sensitive on-line help functionality in the new System to ensure online access by users.

P7-6 Training Execution

Yes Training rolled out to all user groups.

Training

• In-person training is conducted in Tallahassee for end-users, super users and limited users.

• Training includes a combination of structured and on-the-job training for Technical Support / customer service / help desk / user support resources so they are prepared to transition into these roles when the warranty period ends.

• Training includes outreach training for external users to access and learn the System functions available to State Agencies and other public entities.

• The training environment that accurately replicates the functionality and actual data of the production System.

• Training is evaluated for effectiveness per the training plan.

• Training is aligned to the training schedule. • Training provides a mechanism for trainee input on

clarity and value of the training material and delivery to be captured and assessed.

8.9 ST Performance Period Phase A: Warranty Phase Deliverables Ref Deliverable Major



A-1 Warranty Completion Report

Yes Document that summarizes the state of the production

Warranty Phase • Report validates that the hardware, customized IMS, and supporting software are performing in a stable manner.




Reference i

environment at the end of the Warranty Support period.

• Report summarizes the current state of production

including open issues, transition status and production environment performance statistics.

8.10 ST Performance Period Phase B: Services Transition Phase Deliverables Ref Deliverable Major



B-1 Transition Plan Yes Plan for smooth transition to the Department operating and maintaining the System.

Services Transition Phase

• The Services Transition Plan includes a schedule for transitioning tasks.

• The plan describes the activities necessary to maintain the System (that aligns with the SLAs).

• The plan describes the required knowledge, skills and abilities (KSAs) that Department staff must demonstrate prior to assuming Contractor duties

• The plan describes the method(s) for assessing Department staff proficiencies in the KSAs

B-2 Final Documentation Updates

Yes Final updates of design and project management documents to reflect final as-built System and serve as final System documentation.

Services Transition Phase

• The Requirements Management Tool, Functional Design Document, Technical Design Document, security plan, training materials and user manual are updated to reflect the final as-built System.

8.11 Additional Considerations – Operational Support Performance Period Deliverables Ref Deliverable Participants Description Deliverable SOW


A Upgrade Schedule and Approach

DRM DIS

Schedule of point (minor) and major releases of package software and support for new supporting software and hardware versions.

Operational Support Performance Period

• The approach specifies frequency of releases and performance measures for the new release.

• The approach defines the Department's options for accepting upgrades (to maintain support).

• The approach certifies that the Department’s System will be upgraded to support all applicable latest versions of the base software packages (e.g.,



Ref Deliverable Participants Description Deliverable SOW Reference

Minimum Performance Standards

database, operating Systems, browsers, etc) during planned maintenance activities within a reasonable timeframe.

B Software Escrow Agreement

DRM DIS

Agreement to give DFS code access/ownership in light of certain situations.

Operational Support Performance Period

• The agreement details how/where the System software code is escrowed, who holds it and the conditions for code handover.

• The agreement certifies that System code will be in a usable format if handed over (i.e. documented and executable).