Attachment B Statement of Work ITN1314-08 - Florida OF FLORIDA OFFICE OF FINANCIAL REGULATION ATTACHMENT - B Statement of Work Check Cashing Database IT System Implementation

STATE OF FLORIDA OFFICE OF FINANCIAL REGULATION

ATTACHMENT - B

Statement of Work

Check Cashing Database IT System Implementation

Florida Office of Financial Regulation Check Cashing Database Implementation

CCDB Implementation SOW DFS (OFR) ITN 13/14-08

Page 2 of 45

Table of Contents

1 Overview ..................................................................................................................................... 3 1.1 Background .......................................................................................................................... 3 1.2 Overview of Current Environment ....................................................................................... 4

1.2.1 Current State Environment ........................................................................................... 4 1.3 Overview of Future Environment ......................................................................................... 7

1.3.1 Service Delivery Model ................................................................................................ 7 1.3.2 CCDB Architecture ...................................................................................................... 7 1.3.3 CCDB Deployment Options ......................................................................................... 9

2 Definitions and Acronyms ......................................................................................................... 12 3 Scope of Work ........................................................................................................................... 15

3.1 In Scope .............................................................................................................................. 15 3.1.1 Project Phases: System Development Life Cycle ...................................................... 17

3.2 Out of Scope ....................................................................................................................... 33 3.3 Requirements ...................................................................................................................... 33

3.3.1 Regulatory Requirements ........................................................................................... 33 3.3.2 Functional Requirements ............................................................................................ 34 3.3.3 Technical Requirements ............................................................................................. 34

3.4 Special Office Requirements or Constraints ...................................................................... 34 3.5 Standards and Specifications .............................................................................................. 34

4 Deliverables and Schedule ......................................................................................................... 35 4.1 Deliverables ........................................................................................................................ 35 4.2 Deliverables Format ........................................................................................................... 42 4.3 Project Schedule ................................................................................................................. 42 4.4 Inspection and Acceptance ................................................................................................. 43

5 Responsibilities and Staffing ..................................................................................................... 43 5.1 Contractor Responsibilities ................................................................................................ 43 5.2 DIS Responsibilities ........................................................................................................... 43 5.3 OFR Responsibilities .......................................................................................................... 43 5.4 Location of Work ............................................................................................................... 44 5.5 Project Staffing ................................................................................................................... 44

5.5.1 Contractor Project Staffing ......................................................................................... 44 5.5.2 Office Project Staffing ................................................................................................ 44



Page 3 of 45

1 Overview

The Florida Office of Financial Regulation (OFR or Office) is issuing this Statement of Work (SOW) to define the scope and requirements to procure implementation services for a new real time, on-line Check Cashing Database (CCDB). This SOW will enable the Office to comply with legislation which requires the issuance of a competitive solicitation to secure technology services related to the development and maintenance of a Check Cashing Database. This Scope of Work is to be read in conjunction with the proposed Contract (see Attachment A) and the Invitation to Negotiate, and not to the exclusion of any terms articulated in the proposed Contract, Invitation to Negotiate, and not within this Scope of Work.

1.1 Background The Florida Legislature passed House Bill 217 during the 2013 Session which amended Section 560.310, F.S. to include additional requirements for money services business licensees concerning use of a centralized database in which pertinent information regarding check cashing transactions will be captured. The database would be used by regulators (e.g., Department of Financial Services, Division of Workers Compensation) and law enforcement agencies (e.g., Department of Financial Services, Division of Insurance Fraud) to target and identify persons involved in workers’ compensation insurance premium fraud and other illicit activities. House Bill 217 also mandated the Office to issue a competitive solicitation as provided in s. 287.057 for a statewide, real time, on-line check cashing database to combat fraudulent check cashing activity. The expected outcome for this database is to improve the flow of information regarding commercial/third-party checks between check cashers, Office of Financial Regulations, Division of Workers Compensation, and Division of Insurance Fraud.

In order to comply with the above law, the Office initiated a project titled “Check Cashing Database” project. The CCDB project has been divided into two phases.

• Phase I – Requirements Definition and Procurement Support: The Office initiated a “Requirements Definition and Procurement Support” phase to define the requirements for the on-line CCDB system and to issue a competitive solicitation to secure the services of an implementation vendor to implement the on-line CCDB solution. This effort was needed to support the Office in complying with legislation which requires the issuance of a competitive solicitation to secure technology services related to the development and maintenance of a check cashing database.

The following two reference documents will provide additional context to the purpose of this proposed project: 1. Chapter 2013-139 – HB No. 217: http://laws.flrules.org/2013/139 2. Money Service Business Workers’ Comp Fraud Work Group:

http://www.myfloridacfo.com/sitepages/agency/sections/moneyservicebusiness.aspx



Page 4 of 45

• Phase II – Implementation: The implementation phase of the project will begin after awarding a contract to the implementing vendor. Upon a determination of the cost of implementing and maintaining the CCDB, it may be necessary for the Office to request additional appropriation from the Legislature before proceeding with the development of the CCDB system.

Phase II - Implementation is the focus of this SOW. Phase I has already been completed.

1.2 Overview of Current Environment The Office’s current environment primarily consists of a fully integrated Regulatory Enforcement and Licensing System (REAL). The Office deployed REAL in 2008 and utilizes the REAL System to manage licensing and enforcement activities for entities under Chapter 560, F.S. The proposed project may create a new application (i.e., CCDB) that may possibly be integrated into the Office’s REAL architecture. For Contractors that are proposing the option of hosting the CCDB within / as an extension of REAL, the Office is providing the following information on the REAL System and its architecture.

1.2.1 Current State Environment

1.2.1.1 REAL System Overview The REAL system consists of the following major components:

• Versa Regulation: Versa Regulation is commercial off-the-shelf software owned by Iron

Data Solution, LLC. The Office is currently under a software maintenance and support agreement with this vendor. It performs license and enforcement tracking for the enterprise and is the main system of record. It is a Java based application running on the Jboss platform with Oracle 10g as its data store. Its User Interface is 508 compliant and completely browser based. In addition to interactive processing there are two major components of the product:

DataMart – This Business Intelligence tool provides adhoc reporting capabilities from

the Versa Regulation application on a near real time basis. It is a separate database that is populated through triggers and updates from the main Versa Regulation application.

Batch Scheduler – This component of Versa Regulation provides scheduled event

handling. The primary functions of the Versa Regulation Batch Scheduler are letter processing, scheduled license batch processing, scheduled report generation and interface batch processing. It is a powerful batch scheduler that can be used beyond Versa Regulation for any scheduled functions.

• Online Portal: The REAL System online portal is a custom developed component which

provides self service processing to the general public and licensees. It was developed in C# using a .NET architecture framework. The portal uses an Oracle 10g database strictly



Page 5 of 45

for user and application management. Its primary business functions are handled through web services calls to an application programming interface (API) are exposed by the Versa Regulation system. The Office owns all custom code associated with the portal. Web Services are owned by Iron Data and covered under the software maintenance and support agreement.

• FileNet: The FileNet application provides scanning, imaging, document management and

record retention capabilities to the enterprise. Documents related to license application or license enforcement are managed by the FileNet component. Electronic documents are scanned and indexed in the FileNet database and referenced to their related license records. Versa Regulation and the Online Portal utilize symbolic links to these physical documents to provide access to them through their respective interfaces.

• Payment Authorization Vendor: This vendor provides online payment functions for the

self service channel. The Online Portal uses the vendor’s common gateway to request credit card validation and processing.

• Active Directory: The Active Directory structure is utilized to provide single sign on

functionality for the Versa Regulation package. Versa Regulation utilizes custom built APIs to access the users Active Directory information and map it to Versa Regulation security structure.

The REAL System provides the following functionality to the Office: • On-Line application filing • On-Line complaint filing • On-Line compliance filings (renewals, quarterly reports, amendments) • On-Line Public Searches for legal orders, licensed entities, etc • Case Management for Examinations, Complaints, Investigations, Legal, and Public

Records Requests • License processing for applications, renewals, amendments • Tracking and accounting for fees received related to licenses, fines and examinations • Workflow functionality, i.e. assignment of work based on pre-defined business rules and

advancement of work based on case or license processing activities • Imaging and electronic storage of related documents • Ad-Hoc Reports • Interfacing with Department of Financial Services systems, Payment Authorization

Vendor, Florida Department of Law Enforcement, and Veritec (Deferred Presentment Provider)

• Integration with the Nationwide Mortgage Licensing System (NMLS)

The REAL system hardware infrastructure is currently housed in the Fletcher Building Data Center in Tallahassee, Florida and is operated under the management of the DFS-DIS. Application support for the REAL system is provided under an operations and maintenance



Page 6 of 45

contract with an external support provider located in Tallahassee, Florida. The Office oversees all activities and functions of the external support provider.

1.2.1.2 REAL System Architecture This section provides a high level overview of the system architecture, application architecture, physical infrastructure and hardware specifications of the Regulatory Enforcement and Licensing (REAL) System. The REAL architecture is shown in Figure 1, below.

Figure 1: Overview of the system components comprising REAL System.



Page 7 of 45

The REAL Architecture describes the applications and technology architecture of the REAL System. It also describes surrounding architecture components that support business operations, including task management and reporting. The end state REAL solution has the following technology characteristics: • Self-service and State Portals implemented using C# and .NET framework technology and

Oracle databases. • The core Versa Regulation application, where the functionality, business rules and data

associated with client applications is located. • A reporting architecture provided using SQL Reporting Services and Versa Regulation

DataMart. • A batch architecture provided using the existing Versa Regulation batch architecture. • A scanning and electronic document management system utilizing shared storage for imaged

documentation.

1.3 Overview of Future Environment

1.3.1 Service Delivery Model The Office’s service delivery model as applicable to the CCDB is as follows:

Figure 2 – Service Delivery Model

1.3.2 CCDB Architecture The following diagram (see Figure 3 – CCDB Functionality) depicts the functionality of the CCDB system for the Licensees and the OFR.

Florida Legislature Office of Financial Regulation

CCDB Check Cashers

LawsFundingMonitoring

RulesMonitoringLicensingExaminationsInvestigationsAssistance

Transaction ProcessingValidationAlertsReportsLogging

Transaction ReportingRecords ManagementCompliance

Transactions

Consumers



Page 8 of 45

Figure 3 – CCDB Functionality

The core functionality of the CCDB system from an OFR user perspective is:

• The ability to view transaction history for transactions and aggregate transactions. • The ability to perform advanced data searches and retrieve transaction information (e.g.

across licensees or payees, or timeline). • The ability to generate and view pre-configured (i.e. canned) reports for viewing

transactions and for compliance reporting. • The ability to generate and view a dashboard with synthesized data. • The ability to perform OFR related user administration activities. • The ability to execute advanced data analytics and provide system generated alerts based

on user configured parameters (e.g. unusual transaction volume for a check cashing location, such as, 200% increase in volume in a month, or unusual amount in a single transaction, such as over $200,000).

• An interface with the Florida Office of Financial Regulation REAL system to validate if the Licensee has an active license and to update and keep current the status of a license.

• An interface with the Florida Department of Financial Services, Division of Workers Compensation, to compare the running total of dollar amounts paid to each corporation to the total amount of payroll reported on the Workers Compensation insurance application.



Page 9 of 45

• An interface with the Florida Department of Financial Services, Division of Workers Compensation to validate if the Payee has a current workers compensation insurance policy or an exemption certificate (as applicable).

• An interface with the Florida Department of State to validate if the Payee is registered as a business with the Department of State and if the Articles of Incorporation are filed.

• The ability to meet record retention requirements of the Office.

The core functionality of the CCDB system from a Licensee user perspective is: • The ability to submit, amend, and void transactions and aggregate transactions through a

web portal. • The ability to perform data searches and retrieve transaction information. • The ability to generate and view pre-configured (i.e. canned) reports for viewing

transactions. • The ability to perform Licensee related user administration activities. • The ability to submit, amend, and void transactions and aggregate transactions through a

web service (i.e. a system interface between the Licensee Point of Sale device and the CCDB system).

1.3.3 CCDB Deployment Options The Office identified three deployment (i.e. hosting) options to be considered by prospective bidders for the CCDB. Contractors may present proposals for one of the three options, or for more than one option. The Office will evaluate each proposed hosting option as a part of the procurement process.

Option 1: Host CCDB within OFR (outside REAL) Option 2: Host CCDB within / as an extension of REAL Option 3: Host CCDB outside OFR (and REAL)

The Office provides the following information to aid the vendor in appropriately scoping the solution; however, please note that the OFR makes no guarantee to the transaction volume estimates below and these may be subject to change:

• There are approximately 1,000 active Licensees in the State of Florida that operate at approximately 2,000 physical locations.

• Some Licensees have more than 1 location and in some cases the number of locations exceeds 100.

• Approximately 2 million transactions exceeding the $1,000 occur which equates to: An estimated average of 160,000 transactions per month. An estimated average of 5,500 per day. Please note that the averages may be concentrated on pay date(s) and pay time(s).



Page 10 of 45

Option 1 - Host CCDB within OFR (outside REAL)

Figure 4 – Host CCDB within OFR (outside REAL)

Option 2 - Host CCDB within/ as an extension of REAL

Figure 5 – Host CCDB within / as an extension of REAL



Page 11 of 45

OFR Users include employees from the Office, the Division of Workers Compensation (DWC), the Division of Insurance Fraud (DIF), and the Bureau of Financial Investigations (BFI) and others as may be deemed necessary.

Option 3 - Host CCDB Outside OFR (and REAL)

Figure 6 – Host CCDB Outside OFR (and REAL)

Contractors proposing Option 3 must: 1. Provide a SSAE-16 report to the OFR within 90 days of implementation and on an annual basis for the

duration of the contract. 2. Propose an “Exit Strategy” in the proposal. 3. Comply with all State and Federal Laws related to Personally Identifiable Information (PII) including

but not limited to: protection; breach notification, and remediation.



Page 12 of 45

2 Definitions and Acronyms

The following terms used in this document are defined herein.

Term Definition

Project Management Terms Acceptance criteria Pre-defined performance requirements and essential

conditions that project deliverables are measured against before they are considered complete and acceptable. The criteria must be relevant, measurable and specific.

Change A change in the scope of the project. See also: Scope.

Contract The contract that will be awarded to the successful proposer under this competitive solicitation.

Contract Manager Person designated as the main Office point of contact for all issues related to the Services performed under this SOW. This person is the single point of contact for the Contractor and is the only person authorized to make or approve any changes in the requirements of the SOW.

Contractor Vendor that is selected for the project.

Deliverable A product or service that satisfies one or more objectives of the project. Deliverables must be tangible, measurable and verifiable outcomes of work that meet pre-determined standards for acceptance that must be accepted in writing before payment. Examples of deliverables include project documentation, systems, system prototypes, facilities, training and customer support.

DIS or Division or Division of Information Systems

A division within the Department of Financial Services that provides technological support for operations.

Milestone A key event during the project management process selected for its importance in the judging of a project. Examples are the completion of a phase, completion of a major deliverable, or completion of an activity (such as a group of tasks or processes).

Objectives Define the end results to be achieved by the project. Describe them in terms that are observable, measurable, that indicate a timeline for attaining them, and the acceptable level of performance for each goal.

Office or OFR Refers to the Office of Financial Regulation, i.e. the Customer.



Page 13 of 45

Term Definition

Project Management Office A unit within the Division of Information Systems that provides support for agency technology projects; Also known as PMO.

Requirements Conditions or capabilities to which a system or service must conform. Requirements can be derived from documented user needs or from a contract, standards, or specifications.

Scope Describes at a high level what will and will not be included as part of the project. Scope defines the project’s overall boundaries and provides a common understanding of the project for the stakeholders and the project team. It is further defined by the requirements, deliverables, schedule and supporting information contained in this SOW.

Standards Documents that stipulate minimum levels of performance and quality for goods and services, and optimal conditions and procedures for operation.

Specifications Concise statements of requirements for materials, products or services that are to be used by industry or a government agency.

Task A cohesive, individual unit of work that is part of the total work needed to accomplish a project.

Vendor The entity that submits materials to the Office in accordance with the solicitation instructions, or other entity responding to the solicitation associated with this SOW. This may also be referred to as Respondent, Bidder, and Proposer. The solicitation response may be referred to as Reply, Bid or Response.

Business Terms

Aggregated Transaction A transaction that is comprised of multiple payment instruments.

BFI The OFR Bureau of Financial Investigations.

Business Day(s) Monday through Friday, excluding State-observed holidays.

Calendar Day(s) Monday through Sunday, except that if the last day counted falls on a weekend or State-observed holiday, the due date shall be the next Business Day thereafter.

Cashing Providing currency for payment instruments except for traveler’s checks. See F.S. 560.103 (5).

CCDB The Check Cashing Database system which the Office is



Page 14 of 45

Term Definition procuring.

Check Casher A person who sells currency in exchange for payment instruments received, except travelers checks. See F.S.560.103 (6)

Check Cashing Location A branch office or mobile location of a check casher. See F.S.560.103 (20)

Check Cashing Teller A person responsible for accepting and exchanging currency for payment instruments.

Conductor A natural person who presents himself or herself to a licensee for purposes of cashing a payment instrument. See F.S.560.103 (9)

DIF The DFS Division of Insurance Fraud.

DFS The State of Florida Department of Financial Services.

DOS The State of Florida Department of State.

DWC The DFS Division of Workers Compensation.

Fiscal Year The State of Florida Fiscal Year period beginning July 1 and ending June 30.

F.S. The 2013 Florida Statutes.

Licensee A person licensed under Chapter 560.

Mobile Location The VIN number of the automobile from which a Check Casher operates a mobile location.

Performance Measures The required minimum acceptable level of service to be performed by the Contractor and the criteria the Office will use to evaluate the successful completion of each deliverable and/or service.

Payee The person the check is made payable to. The Payee can be an individual or a business.

Payment Instrument A check, draft, warrant, money order, travelers check, electronic instrument, or other instrument, payment of money, or monetary value whether or not negotiable. The term does not include an instrument that is redeemable by the issuer in merchandise or service, a credit card voucher,



Page 15 of 45

Term Definition or a letter of credit. See F.S. 560.103 (25)

Payor The person that wrote the check.

SLA A Service-level Agreement and is a part of a service contract where a service is formally defined.

Transaction A check cashing transaction that is comprised of a single payment instrument.

Technical Terms

POS system A Point of Sale system used by check cashers to process and store check cashing transactions. This is an internal system owned and maintained by a check casher.

REAL The OFR’s Regulatory Enforcement and Licensing System.

RPO The Recovery Point Objective and is the point to which information used by an activity must be restored to enable the activity to operate on resumption.

RTO The Recovery Time Objective and is the target time set for resumption of product, service or activity delivery after an incident.

Uptime The time during which the CCDB is in operation.

3 Scope of Work

3.1 In Scope The scope of work for this project may generally be described as providing a technical solution and supporting services that will enable the Office to meet the stated program objectives. This Statement of Work (“SOW”) describes the functionality and features to be provided by the CCDB. It also describes the services to be provided by the Contractor to support the CCDB throughout the project lifecycle including implementation services, project management services, and operation and support requirements. The requirements stated herein are intended to inform proposers of the minimum expectations of the Office, but proposers may clarify and expand on the requirements. In addition, the Project Schedule submitted by the proposer will present the proposed project timeline for approval. The Office is presenting three deployment/hosting options for the CCDB as outlined in Section 1.3.3 CCDB Deployment Options. Contractors may propose on one option or more than one option. The resulting contract will reflect the contractual terms and conditions agreed upon between the Office and the Contractor, including the project timeline and scope of services.



Page 16 of 45

The Office of Financial Regulation has planned a phased implementation approach for the Check Cashing Database solution per the Project’s System Development Life Cycle (SDLC). The Office is aware that if a Contractor is proposing hosting a solution using Option 3 (i.e. outside OFR and REAL), a fully implemented SDLC may not be necessary. The table below summarizes each phase of the SDLC.

Phase Summary Phase One: Initiate and Plan The objective of this phase is for the Contractor and the

Office to create the overarching planning documentation for the Project. The Contractor shall submit the core planning deliverables.

Phase Two: Define The objective of this phase is for the Contractor to validate and elaborate the requirements provided in the Requirements Specification Report (RSR) with key project stakeholders in order to generate specific, detailed functional and technical requirements.

Phase Three: Design The objective of this phase is to create a visual representation of the system to be built. This phase transforms the detailed, defined requirements into complete, detailed functional specifications. Technical specifications are also created to illustrate the necessary infrastructure to support the system architecture.

Phase Four: Develop The objective of this phase is to convert the deliverables of the Design phase into a complete information system as specified in the Requirements Traceability Matrix.

Phase Five: System Test The objective of this phase is to prove that the new system satisfies the detailed requirements as specified in the Define phase.

Phase Six: Implement and Train The objective of this phase is to deploy the system to all users and to ensure that they are trained on all functional and technical areas of the CCDB solution.

Phase Seven: Maintain The objective of this phase is to ensure that the system continues to work as specified and to maintain the system.

The scope is further defined within the remainder of this section as well as Section 4 Deliverables and Schedule and Section 5 Responsibilities and Staffing.



Page 17 of 45

3.1.1 Project Phases: System Development Life Cycle The Contractor’s System Development Life Cycle shall conform to the high-level project schedule and the specific SDLC phases as outlined below. Associated Phase Gate deliverables for each SDLC phase are also outlined and must be satisfied prior to entering the subsequent phase gate.

3.1.1.1 Phase One: Initiate and Plan The objective of this phase is for the Contractor and the Office to create the overarching documentation for the Project. The Contractor shall submit the core planning deliverables as defined in Section 4 Deliverables and Schedule.

The Contractor shall develop a Project Management Plan as part of the methodology and approach to the Project. The Contractor shall follow project management methodologies consistent with the Project Management Institute (PMI) project management methodologies stated in the Project Management Body of Knowledge (PMBOK). In this task the Contractor shall detail the SDLC approach and methodology for initiating, planning, defining, designing, developing, testing, training, implementing and maintaining the CCDB solution. The Office and the Contractor shall work together during Project Initiation and Planning Phase to develop and refine the Project Management Plan (PMP) based on the project approach and schedule.

The Project Management Plan shall include the following sections:

1. Work Breakdown Structure (WBS) 2. Project Roles and Responsibilities 3. Project Schedule 4. Communication Management 5. Document Management 6. Schedule Management 7. Quality Management 8. Issue Management 9. Scope Management 10. Risk Management 11. Resource Management and Staffing 12. Configuration Management 13. Knowledge Management 14. Phase Gate Review and Acceptance Process 15. Phase Gate Approval Criteria 16. Project Change Control Management 17. Information Security 18. Conflict Resolution

OFR expects that the level of detail within the deliverables will be commensurate with the project size and complexity.



Page 18 of 45

All sections, identified above, will be delivered during the Planning Phase in an initial overall Project Management Plan as a baseline document. The PMP will be clarified, revised, expanded, and maintained throughout the project and submitted to the Office for review during phase gate reviews and other contractually specified review points. The Project Schedule is a key component that will be leveraged throughout the project. The following shall be included in the Project Schedule: • A Microsoft Project 2007 schedule that details tasks and activities that will be performed

during the engagement to at least Work Breakdown Structure (WBS) level 4. • The project schedule shall be maintained on at least a weekly basis. • The project schedule shall reflect non-working time of project team members (i.e.,

weekends, holidays). • At a minimum, the schedule shall include firm task durations (estimated durations should be

limited), task start and finish dates, baseline start and finish dates, task predecessors and successors, and resources.

The Contractor shall conduct a Project Initiation meeting at a location selected by the Office and at a date and time mutually agreed upon by the Office and the Contractor. The Project Initiation meeting shall be attended by the Office Project Team and the Contractor Project Team. The purpose of the meeting shall be to review the PMP and all the deliverables associated with the Project SDLC. The Contractor shall conduct one or more additional Project Initiation meetings as deemed necessary by the Office. The Project Initiation meeting activities shall include: • Understanding of the project objectives and scope. • Review the DIS ISDM Phases and Deliverables, including Standards and Procedures. • Identification of the roles and responsibilities of the project stakeholders, including the

Office Project Team, Contractor Project Team, DIS staff (e.g., Change Management, Environment Support Teams, Help Desk, Maintenance Support Manager, Technical Support staff), and any other key project team members.

• Review the PMP. • Review of the project schedule, phases and associated deliverables. • Understanding of the project performance measurements and critical success factors. • Identification of key stakeholders that will serve as the point of contact to review and

validate information at all agreed upon project phases. • Overview of the process to manage all phases of the project, including the elements of the

PMP, such as communications management, risk management, issue management, etc. • Any other topic as deemed appropriate by the Office.

Any decisions or agreements from the Project Initiation meeting(s) shall be documented by the Contractor and submitted to the Office project team for review and acceptance. The following sections define the responsibilities of the Contractor and the Office. The Contractor’s responsibilities during the Initiate and Plan phase shall include:



Page 19 of 45

1) Facilitating the Project Initiation meeting. 2) Designating staff members to serve as part of the planning process. 3) Working with Office staff to establish the necessary technical environments. 4) Preparing the planning deliverables. 5) Revising deliverables as a result of the review and approval process. 6) Conducting weekly Status Meetings. 7) Creating and updating the Project Schedule.

The OFR’s responsibilities during the Initiate and Plan phase shall include:

1) Participating in project planning activities and identify responsibilities of Office staff. 2) Participating in plan development by providing technical information and guidance. 3) Reviewing and approving all planning deliverables. 4) Supplying hardware, software, and infrastructure for which the Office is responsible. 5) Coordinate participation of DFS-DIS in planned activities, as needed.

The DFS-DIS responsibilities during the Initiate and Plan phase shall include:

1) Participating in project planning activities and identify responsibilities of Office staff. 2) Provide Security Awareness Training for the Contractor’s personnel who will be

assigned to this project.

3.1.1.2 Phase Two: Define The objective of this phase is for the Contractor to validate and elaborate the requirements provided in the Requirements Response Matrix (RRM) with key project stakeholders in order to generate specific, detailed functional and technical requirements.

The Contractor shall validate and refine the requirements identified in this SOW and in Attachment D - Requirements Response Matrix to generate specific, low level requirements (i.e., Functional, Technical, and Regulatory) to produce a Requirements Traceability Matrix (RTM). The Contractor shall propose a methodology that generates lower level requirements through working sessions with the Office. The working sessions shall be Joint Application Development (JAD) or other Office approved requirements generation methodology proposed by the Contractor. The Contractor shall propose a methodology that enables the participation of key external stakeholders such as the Department of State, Department of Financial Services, and selected check cashing businesses.

The Contractor shall also update the Requirements Specification Report (RSR) provided in Attachment E - Requirements Specification Report to reflect the hosting option chosen, changes to the proposed system architecture and any other amendments deemed necessary by the Office and the Contractor. The RSR shall reflect all updates to the RTM based on outcomes from the JAD sessions.

Initiate and Plan Phase Gate. The following deliverables are tied to this Phase Gate:

• Project Management Plan • Project Initiation and Status Meeting(s) • Project Status Report



Page 20 of 45

The Contractor’s requirements validation responsibilities shall include:

1) Providing a defined methodology to validate and maintain requirements including process that will be utilized in conducting requirements validation sessions (e.g., JAD sessions).

2) Providing a proposed schedule of requirements sessions that will be conducted and the expected knowledge base of the Office and other stakeholder participants.

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

4) Providing an agenda for each requirements validation sessions. 5) Conducting and documenting requirements validation sessions. 6) Preparing the requirements validation deliverable as stated in Section 4 Deliverables and

Schedule.

The Contractor shall propose a Deployment Strategy for delivering the CCDB solution through one of the hosting options as identified in Section 1.3.3 CCDB Deployment Options. The Deployment Strategy shall also include the interface definitions to external systems (i.e., Department of State, Division of Workers’ Compensation, and check cashing Point of Sale devices).

The Contractor’s interface definition responsibilities shall include:

1) Providing documentation on interfaces specifying purpose, format, content, frequency and processing for each interface transaction.

2) Providing meeting minutes of each interface session, including issues addressed and decisions made, to the Office’s Project Manager within three (3) business days of conclusion of the interface meeting.

3) Providing the deliverables as identified in Section 4 Deliverables and Schedule. 4) Revising deliverables as a result of the review and approval process.

The OFR’s responsibilities during the Define phase shall include: 1) Participating in planned activities (i.e., JAD sessions) as necessary. 2) Providing information as requested from the Contractor. 3) Reviewing and approving Phase Gate deliverables per the agreed schedule and PMP. 4) Coordinating the participation of key external stakeholders, as needed. 5) Coordinate participation of DFS-DIS in planned activities, as needed.

The DFS-DIS responsibilities during the Define phase shall include:

1) Participating in planned activities (i.e., JAD sessions) as necessary. 2) Providing information as requested from the Contractor. 3) Review Phase Gate deliverables as per the approved schedule.

Define Phase Gate. The following deliverables are tied to this Phase Gate: • Updated Requirements Specification Report • Requirements Traceability Matrix



Page 21 of 45

3.1.1.3 Phase Three: Design The objective of the Design phase is to create a visual representation of the system to be built. This phase transforms the detailed, defined requirements into complete, detailed functional specifications that document each form, screen, and report in the system. Technical specifications are also created to illustrate the necessary infrastructure to support the system architecture.

The Contractor shall generate a conceptual system design (i.e., Functional Design Document) describing how the CCDB solution will enable the functional requirements specified in the RTM. The Functional Design Document (FDD) shall include, but not be limited to, data models and process models and must include both graphic and narrative representation for each form, report, interface and enhancement. All business rules and workflows shall be documented in detail. The Contractor shall specify User Interface standards and provide a prototype illustrating the functionality of the CCDB solution. Components of the FDD include:

1. User Interface Standards - Defines usability standards for the CCDB user interface. Browser based standards should be browser agnostic and the CCDB user interface should run on current browser releases.

a. Application Development Standards: The purpose of this document is to define standards and best practices for developing web-based application software in order to present a consistent “look and feel” to the applications, and to ensure the supportability of applications developed throughout the Department.

b. DFS Web Services: Applies to all DFS Web Services projects including those assigned to contracted vendors, the Offices of Insurance Regulation and Financial Regulation in cases where the Web Services require support from DFS infrastructure, (i.e., software, hardware, network, applications or similar).

c. Web Accessibility and Content: This document provides accessibility standards and best practices for the Department of Financial Services web based application and content pages.

2. Prototype - Illustrates the navigation of the forms and demonstrates the UI standards that are incorporated into the solution.

3. Reporting templates - Layouts and definitions of pre-defined reports.

The Contractor shall generate a Technical Design Document (TDD) reflecting the final requirements for system architecture, configuration, and operation. The Technical Design Document shall be developed based on outputs from technical design sessions conducted with the Contractor, DFS-DIS, and key Office stakeholders. The Contractor shall conduct development reviews, apply software development standards, perform code and unit tests, and maintain TDD for each object being developed. At the completion of CCDB solution development, the Contractor shall ensure that the Technical Design Document is updated to represent the complete “as built” CCDB solution. Components of the TDD include:

1. System Architecture - Visual representation of the technical components (i.e., tiered

architecture model) necessary to support the CCDB solution. 2. Database Design - Documents the supporting data structures through tools and techniques

such as entity relationship models, data dictionaries, etc.



Page 22 of 45

3. Web Services Interface Design - Illustrate the multiple interface requirements necessary to support the CCDB solution.

The Contractor may propose alternatives to any of the components noted above, but any alternative must be clearly justified and have the prior approval of the Office.

The Contractor’s responsibilities during the Design phase include:

1) Supporting the Office with developing the User Interface standards. 2) Supporting the Office with developing performance criteria. 3) Preparing the technical system design deliverables. 4) Creating and refining the database design. 5) Documenting technical system design issues and decisions in deliverables. 6) Conducting a walk-through of the deliverables. 7) Revising deliverables as a result of the review and approval process.

The OFR’s responsibilities during the Design phase shall include: 1) Participating in planned activities (e.g., Design sessions) as necessary. 2) Providing information as requested from the Contractor. 3) Reviewing and approving Phase Gate deliverables per the agreed schedule and PMP. 4) Coordinating participation of DFS-DIS in planned activities, as necessary.

The DFS-DIS responsibilities during the Design phase shall include:

1) Participating in planned activities (i.e., Design sessions) as necessary. 2) Providing information as requested from the Contractor. 3) Review Phase Gate deliverables as per the approved schedule.

3.1.1.4 Phase Four: Develop The objective of this phase is to convert the deliverables of the Design phase into a complete information system as specified. The Contractor’s installation and configuration efforts will be guided by the outputs of the Initiate and Plan, Define, and Design phases.

The Contractor shall create and maintain an Infrastructure Plan that will include hardware, software, and network requirements list of all new hardware, software, and network components that are necessary to support the CCDB solution. The following environments shall be included in the Infrastructure Plan:

• Development Environment • Testing Environment • Training Environment (i.e., Sandbox) • Production Environment

Design Phase Gate. The following deliverables are tied to this Phase Gate: • Functional Design Document • Technical Design Document



Page 23 of 45

The Contractor shall develop or configure and extend the base code per the functional design and perform unit testing. The Contractor shall conduct code review and unit testing results for quality assurance reviews by the Office. The Contractor shall develop a Unit Test Plan that documents the approach and methodology. Test results shall be included for base code that is already tested. Unit test results shall be documented and provided to the Office. Unit testing shall be performed on each unit of code or configuration to ensure that it functions as specified.

The Contractor shall document development and testing guidelines. These guidelines must be approved by the Office before any coding or development can begin. If non-COTS software is provided by the Contractor as part of the CCDB, the Contractor shall provide a tested release of the application consisting of software code and release notes as planned in the project schedule. The Contractor shall update and resubmit the software code or configuration whenever changes to the operational software are implemented.

The Contractor shall develop and maintain a Configuration Management Plan documenting the configurations of all hardware and software necessary to support CCDB. The Configuration Management Plan shall be used as a tool to establish the overall approach for the Configuration Management activities of the CCDB. The purpose of the plan is to identify the overall policies and methods for the Configuration Management activities to be used during the system life cycle of the CCDB solution and will be updated iteratively as necessary. The Contractor shall provide copies of source code to the OFR for all applications developed and installed. The Contractor must agree that the Office will own the source code of custom software and will have access to escrowed source code of pre-existing licensed software. The OFR retains the right to maintain and support its own applications or to contract for these services. The Contractor must agree that all changes will be documented and be consistent with the Contractor’s documented Change Control Plan. Source code must be clearly written and understandable comments, with date and name included. (See Application Development Guidelines Using DFS System Architecture for .Net.doc, DFS System Architecture for .Net.doc, VS.Net Coding Standards.doc, Adding .NET solutions to SourceSafe.doc, DFS Team Development Guidelines.doc, Setting up Local DFS. Common Solution for .NET.doc, and if applicable, Windows Based Application Standards for Windows Forms Smart Client.doc.)

The Contractor’s responsibilities during the Develop phase shall include:

1) Supporting the Office with developing the physical/logical security plan. 2) Supporting the Office with setting up the test environments. 3) Supporting the Office with disaster recovery setup and testing. 4) Developing an infrastructure plan based on a validated server sizing study. 5) Revising deliverables as a result of the review and approval process. 6) Working with the Office’s resources for planning and coordination for installation of all

hardware and software supporting the CCDB. 7) Deploying, in collaboration with Office staff, the CCDB as required by the infrastructure

design.



Page 24 of 45

8) Configuring the system to the most current production version of all underlying software, tools, and databases, unless the Office agrees to an exception.

9) Creating new or modified objects. 10) Creating new or modified programs. 11) Creating unit test cases and test data. 12) Designing and performing unit testing. 13) Reporting unit test results. 14) Preparing code and unit test deliverables. 15) Revising deliverables as a result of the review and approval process. 16) Providing all source code developed and/or modified by the Contractor for use in this project

to the OFR on a regular basis, not less than weekly. In the event the Contractor ceases to do business or discontinues support to the OFR in the future, the OFR will then have possession of all source code for their business solution.

17) Following the guidelines for storage of all source and compiled code. Use of Microsoft Visual SourceSafe for .Net as a source code version/change management tool required.

18) Providing copies of source code to the OFR for all applications developed and installed. 19) Including appropriate error trapping and handling procedures in all codes. Appropriate errors

must be logged into either a database or log file with the following information: Session ID, User ID, IP Address, Date/Time, and Object(s) where error occurred (i.e. ASP page, PL/SQL procedure/package, Visual Basic Function, database object). (See Error Handling Guidelines.doc).

The OFR’s responsibilities during the Develop phase shall include:

1) Participate in planned activities (i.e., review Unit Test Results) as necessary. 2) Provide information as requested from the Contractor. 3) Review and approve Phase Gate deliverables per the agreed schedule and PMP 4) Coordinate participation of DFS-DIS in planned activities, as needed.

The DFS-DIS responsibilities during the Develop shall include:

1) Participating in planned activities (i.e., review Unit Test Results) as necessary. 2) Providing information as requested from the Contractor. 3) Review Phase Gate deliverables as per the approved schedule.

3.1.1.5 Phase Five: System Test The objective of this phase is to prove that the new system satisfies the detailed requirements as specified in the Define phase.

Develop Phase Gate. The following deliverables are tied to this Phase Gate: • Source Code • Unit Test Plan • Unit Test Results • Infrastructure Plan • Configuration Management Plan



Page 25 of 45

The Contractor shall test the proposed CCDB in accordance with established software development practices to include:

• System Testing to evaluate the assembled system and confirm that the CCDB operates as expected including all system security and user profiles;

• End-to-End Testing to confirm the CCDB units, modules, and COTS application modules operate effectively together and to ensure that functional objectives are being achieved;

• Interface Testing to evaluate every interface and confirm that each interface operates according to the interface requirements as specified in the Requirements Specification Report;

• Performance Testing/Stress Testing to simulate the system to the limits of its requirements and beyond those limits to confirm graceful failure including COTS packages and to confirm satisfaction of performance requirements in a simulated test environment;

• User Acceptance Testing to evaluate the overall functionality of the CCDB system components against the Requirements Specification Report and the Requirements Traceability Matrix; and

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

The Contractor shall support all system, user acceptance, and end-to-end testing planned, and executed, by the Office with actual data provided by the Office. The Contractor shall conduct all Performance/Stress and Interface testing with actual data provided by the Office. The Contractor shall generate all required test documentation (e.g., Performance/Stress Test Plans and Cases; and, Interface Test Plans and Cases). During test planning, the Contractor shall update the Requirements Traceability Matrix to reflect the relationship between requirements and planned acceptance tests. The Contractor shall record, track, and manage all problems and issues identified during testing workstreams (i.e., System, End-to-End, Interface, Performance/Stress, User Acceptance, and Regression). 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 CCDB solution. Following any software change or test script change made during the acceptance 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. The Contractor shall lead the Office in executing User Acceptance Testing (UAT) to demonstrate that all requirements are met, and shall provide the Office documentation to report the outcomes of the User Acceptance Testing. The Contractor and Office will collaborate to ensure that the UAT process supports the Office’s ability to identify additional tests cases during the UAT workstream to ensure that the acceptance test cases are thorough and complete. The Contractor shall work with the Office to develop test cases, test scripts, test data and test files for all test cases including any added by the Office. The Contractor shall confirm that User



Page 26 of 45

Acceptance Tests have been planned for all requirements by tracing the requirements to the planned acceptance test cases and scripts.

The Contractor’s responsibilities during the System Test phase shall include:

1) Implementing a defect tracking and reporting method. 2) Documenting, analyzing and classifying all reported problems. 3) Updating the Requirements Traceability Matrix to reflect the relationship between

requirements and planned tests. 4) Working with Office staff to establish the test environments. 5) Configuring the CCDB to the most current production version of all underlying software,

tools, and databases, unless the Office agrees to an exception. 6) Creating test data and test files needed for initial testing as well as for re-testing, if applicable. 7) Supporting system and end-to-end 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) Correcting problems, repeating integration, system, stress and performance testing until expected results are obtained.

9) Providing documentation for all test results for each set of tests performed. 10) Supporting the development of all User Acceptance Test deliverables. 11) Establishing the application in the Acceptance Test environment. 12) Supplying training needed for testing. 13) Generating acceptance test plan, test scenarios, and test result logs. 14) Conducting Performance/Stress Testing as a part of overall testing in an environment that

simulates the production environment. 15) Shall conduct testing in accordance with the ISDM requirements of DIS provided by the

Contract Manager.

The OFR’s responsibilities during the System Test phase shall include: 1) Participating in planned activities (e.g., Review Test Cases, Execute Scripts, Provide

Feedback) as necessary. 2) Providing information as requested from the Contractor. 3) Reviewing and approving Phase Gate deliverables per the agreed schedule and PMP. 4) Coordinating DFS-DIS participation, as needed.

The DFS-DIS responsibilities during the System Test phase shall include:

1) Participating in planned activities (e.g., Review Test Cases, Execute Scripts, Provide Feedback) as necessary.

2) Providing information as requested from the Contractor. 3) Review Phase Gate deliverables as per the approved schedule.

System Test Phase Gate. The following deliverables are tied to this Phase Gate: • Test Plan • Test Cases • Test Results • Updated Requirements Traceability Matrix



Page 27 of 45

3.1.1.6 Phase Six: Implement and Train The main objective of this phase is to deploy the system to all users. Activities in this phase will include training of all end users on the system as appropriate (e.g. functional or end user, technical, system administration, help desk). The objective is also to ensure that all appropriate user documentation is prepared to guide users on how to navigate the installed CCDB solution.

3.1.1.6.1 Implement The Contractor shall provide a hardware and software purchase list of all new hardware and software that shall be purchased to implement the proposed CCDB solution. The hardware list shall include all hardware necessary to fully implement the proposed CCDB solution. The software list shall include all software necessary to fully implement the proposed CCDB solution including operating systems, relational database management systems, data warehouse software, and other supporting software. The Contractor shall clearly identify all the proposed proprietary software and hardware. The Contractor shall provide an explanation of the associated benefits and risks for all proprietary software and hardware being used.

The Office reserves the right to purchase any of the items on the purchase list from another source instead of acquiring them from the Contractor if it is in the best interest of the Office. The Contractor shall be responsible for the installation of all hardware specifically needed for the proposed CCDB solution, regardless of whether it is purchased by the Contractor or purchased by the Office. The Contractor shall install all software on servers and clients.

The Contractor shall initialize the entire system including setup of initial internal user accounts and privileges. The Contractor shall install and implement the proposed CCDB solution at the OFR offices in Tallahassee. The Contractor shall provide local technical and functional support.

The Contractor shall develop an Implementation Plan that, at a minimum, addresses database administrator procedures, installation procedures, identification of the steps leading up to the rollout, promotion of the software to the production environment, system availability to users, a strategy to rollback in case of major issues encountered during the rollout, and a final acceptance report for each planned release in the approved project schedule. If the plan includes equipment or services provided by a subcontractor, the Contractor shall be fully responsible (as prime contractor) for the delivery of the entire system. The Contractor shall develop/update the Disaster Recovery Manual which shall outline the procedures to successfully recover the CCDB. The Contractor’s staff shall be present at the implementation site during the go-live of the system. The Contractor’s responsibilities during the Implement phase shall include:

1) Supporting the Office with developing the Operational Readiness Plan. 2) Working with Office resources for planning and coordination for installation of all hardware

and software supporting the proposed CCDB solution. 3) Deploying the proposed CCDB solution (i.e. hardware and software installations).



Page 28 of 45

4) Providing on-site support during the implementation. 5) Performing roll-back procedures, if required. 6) Developing/updating the Disaster Recovery Manual. 7) Ensuring all system components have been incorporated into routine system backups for all

platforms hosted at DFS (mainframe, UNIX, Windows). 8) Including in the project schedule a post-implementation Recovery test to recovery all

components of the production application, using backup protocols as determined by the DIS. 9) Performing a successful Recovery Test and preparing an updated Disaster Recovery Manual,

which are required for final acceptance of the system. For applications hosted by the Contractor, the recovery test will be performed by Contractor and monitored by DFS personnel.

The Office’s responsibilities during the Implement phase shall include: 1) Review and approve the installation and implementation deliverables. 2) Assist the Contractor in planning, coordination and execution of hardware and software

installations. 3) Provide a physical location where the servers will be installed. 4) Coordinate participation of DFS-DIS in planned activities, as needed.

The DFS-DIS responsibilities during the Implement phase shall include:

1) Participating in planned activities as necessary. 2) Providing information as requested from the Contractor. 3) Review Phase Gate deliverables as per the approved schedule. 4) Performing the Recovery Test which will be monitored by Contractor personnel for

applications hosted by DFS. 5) DIS personnel in DFS will determine if the Disaster Recovery test is successful or needs to be

corrected and repeated prior to final acceptance.

3.1.1.6.2 Train The Contractor shall present a method to train the user population defined below that balances effectiveness with expense. The Contractor shall provide a Customized Training Plan that will ensure that all the CCDB end users have access to the knowledge and skills necessary to effectively employ the CCDB solution and supporting technology. The Contractor shall provide the Office with Customized Training Material for the operation and support of the CCDB solution. The Contractor’s training material shall be in electronic form, i.e. in the form of an online user help, and the Contractor shall continually update the training material where changes to the solution’s method of operation have occurred. The training material shall be provided in a format that allows the Office to conduct train-the-trainer sessions after the Contractor’s training responsibilities have expired, which shall include training modules (e.g. videos) and



Page 29 of 45

associated procedure documents for all end users of the CCDB solution. The training material shall be used to train each category of CCDB user. In collaboration with the Office, the Contractor shall train, or provide a mechanism to train, all the CCDB users including, but not limited to OFR internal users, Check Cashers, etc. The Contractor shall provide at a minimum five (5) training sessions with OFR internal users using the train-the-trainer methodology. The training shall be conducted at the OFR offices in Tallahassee. The Contractor shall provide at a minimum five (5) training sessions with Check Cashers utilizing webinars and computer-based training (CBT). The Contractor’s responsibilities during the Train phase shall include:

1) Providing a detailed Training Plan that is submitted to the Office for review and approval. 2) Developing a Training Schedule provided to the Office by the Contractor. The trainers

provided by the Contractor must track attendance and class completion and provide status information to the Office. If any classes must be rescheduled, the Contractor shall attempt to reschedule staff as agreed upon with the Office, and provide reports to the Office.

3) Provides for knowledge transfer to DIS staff to maintain the system. 4) Provide for knowledge transfer to DIS Tier 1 staff. 5) Developing training with a plan for continuing education and software application updates,

including a train-the-trainer activity for on-boarding new hires. 6) Conducting training in Tallahassee for all CCDB internal end users (about 250 users). 7) Conducting training across the industry to include all Check Casher end users (about 4000

users). The Contractor shall provide train the trainer materials and a course so that the Office will be able to continue training for new users of the system, or for refresher courses for existing users. Training shall be in the form of CBTs and webinars.

8) Providing both structured and on-the-job training for system administrators, system operators, support resources so they are prepared to transition into these roles when the warranty period ends.

9) Ensuring training is aimed at skill acquisition and helping end users become self-sufficient in the use of the CCDB solution.

10) Providing the training in a training environment and a database for training that contains a sufficient amount of diverse data and allows exploration of all parts of the CCDB solution through hands-on exercises.

11) Delivering training in time to meet the user acceptance testing and implementation project schedule.

12) Providing training that is based on a variety of stages in the business process life cycle to provide realism and must not include actual data to protect confidentiality.

13) Targeting training to the business or support process for the appropriate level of staff. The training will include functionality in sufficient detail so that OFR staff will know how to perform their assigned duties within the CCDB environment.

14) Delivering training using step-by-step user and system instructions that include data field options and status updates.

15) Delivering training in a simulated production-like training environment that permits practicing new skills.



Page 30 of 45

16) Delivering the training with user and technical documentation 17) Updating the Requirements Traceability Matrix to reflect that the user manual has completely

addressed all the CCDB solution functionality, as recorded in the requirements. 18) Delivering a customized electronic training document available online for all functionality in

the CCDB solution. The manuals shall be available to users online. 19) Evaluating training for effectiveness and continuous improvement with testing of Office

employees and Check Cashers (on a pass/fail basis) to confirm that all training topics are mastered.

20) Providing course-related information that will be maintained in the employee’s CCDB training record.

21) Refreshing 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.

The OFR’s responsibilities during the Train phase shall include:

1) Working with the Contractor regarding planning, monitoring, and delivery of training. 2) Assigning a training team leader from the OFR’s project team. 3) Acting as the liaison between the Contractor and Check Cashers to schedule training sessions. 4) Monitoring all training provided by the Contractor. 5) Reviewing evaluation forms and providing feedback on training design and delivery

throughout the implementation training period. 6) Providing training facilities in Tallahassee. 7) Scheduling the training class dates, reserving classrooms, providing in-class liaison staff,

scheduling attendees, and providing logistical support. 8) Providing at a minimum five (5) training sessions with Check Cashers via webinars and CBTs.

The DFS-DIS responsibilities during the Train phase shall include:

1) Participating in planned training activities, as necessary. 2) Review Phase Gate deliverables as per the approved schedule.

After successful training of all system users the Contractor shall roll out the fully operational CCDB solution.

Implement and Train Phase Gate. The following deliverables are tied to this Phase Gate: • Implementation Plan • Disaster Recovery Manual • Fully Deployed CCDB Solution • Customized Training Plan • Training Schedule • Customized Training Material • Training Execution



Page 31 of 45

3.1.1.7 Phase Seven: Maintain. The objective of this phase is to ensure that the system continues to work as specified and to maintain the system.

Prior to moving into the Warranty Period Support, the Contractor shall obtain written authorization from the Office that all performance measures have been met and that the CCDB solution is operating in production without any material deficiency with all required functionality.

3.1.1.7.1 Warranty Support The Contractor shall provide a warranty period of 12 months from the date of go-live for software developed and implemented specifically for the CCDB solution, and for integration of all software in the CCDB solution after full operational capability is declared by the Office and the system is fully accepted by the Office. The Contractor’s Warranty Period Support responsibilities shall include:

1) Monitoring of the CCDB solution production environment. 2) Developing appropriate procedures for the Office to report and track issues identified. 3) Correcting defects or problems in a timely fashion (per Service Level Agreements defined

below). 4) Conducting full integrated testing of any warranty repair to ensure that it is complete and

appropriate, and conducting regression testing to avoid other problems created by the warranty repair.

5) Correcting defects related specifically to implementation. Any errors in the installation, configuration or customization of the software solution as documented in the relevant deliverables will be corrected by the Contractor in most expedient and effective method.

The Contractor shall coordinate installation and testing of repaired software with the Office and update all documentation affected by the change. For critical problems that prevent complete operation of the CCDB solution, the Contractor shall provide a workaround for the problem. The Contractor shall provide to the Office the full standard warranty available and any additional COTS software required for the CCDB solution. For all problems identified in acquired COTS packages, the Contractor shall coordinate warranty repair with the COTS packages Contractor, provide the Contractor all needed information, monitor the Contractor’s status on resolving the warranty issue, test the updated package with the CCDB solution, and install the replacement or update.

The Contractor shall generate a Warranty Completion Report at the completion of the warranty period.

NOTE: Final acceptance of each custom software Deliverable shall be considered to occur when each Deliverable has been approved by OFR/DFS and has been operating in production without any material deficiency for 10 days of full production with all functionality.



Page 32 of 45

3.1.1.7.2 Operations and Maintenance Transition In collaboration with the Office, the Contractor shall develop and maintain a system user guide and an Operation and Technical Manual that describe how to use, operate and maintain the system respectively. The Contractor shall maintain the user guide and the manual through the warranty period. The Contractor shall provide day-to-day support and maintenance to the CCDB solution at time of go-live and for a duration of 2 years and for three 1 year contract renewal periods. During optional operational periods, if exercised by the Office, the Contractor shall transition the day-to-day support and maintenance of the CCDB solution to the Office’s own staff or their designated agent. The Contractor shall transition the operations and first line support of the CCDB solution as directed and according to the Office-approved operations and maintenance transition plan. As part of the transition, the Contractor shall provide current electronic and paper copies of all Contractor-related deliverables. The Contractor shall ensure that the material to be transitioned is complete and correct at the time of transition.

3.1.1.7.3 Maintenance The Contractor shall be subject to a Service Level Agreement (SLA) after the go-live, which includes support of all problems beyond Level 1 support and enhancements to the CCDB solution. The negotiated SLA shall, at a minimum, outline the responsibilities of both the Contractor and the Office (including acceptable performance parameters with applicable metrics and measurement methodology), document the expected duration of the SLA, describe the applications and services covered by the SLA (identification, remediation and communication), document the procedures for monitoring the service levels, and provide a schedule for remediation of outages and associated penalties and problem-resolution procedures. As part of ongoing maintenance, the Contractor shall provide the Office with a Software Upgrade Schedule and Approach document for the CCDB solution that stipulates software upgrade/release frequency and performance measures. The Contractor’s Software Upgrade Schedule and Approach shall outline the Office’s options to upgrade the CCDB solution in order to maintain Contractor support. As a component of this deliverable, the Contractor shall include guaranteed software assurance which covers compatibilities of new installs to the existing software version and assures modifications of sensitive or critical system resources. Accurate and timely logging of events shall be logged to establish what events occurred, when the events occurred, the source of the events, and the outcome of the events. Finally, the Contractor shall certify that the Office’s CCDB solution system will be upgraded to support all applicable latest versions of the COTS products (e.g., database, operating systems, browsers, etc) in these planned maintenance activities within a reasonable timeframe. The Contractor shall also provide a Software Escrow Agreement to give the Office access/ownership of the source code based on defined situations. The Contractor’s responsibilities during the Maintain phase shall include:

1) Integrating CCDB procedures into the Office’s Disaster Recovery Manual.



Page 33 of 45

2) Preparing monthly status reports, in a format agreed upon by the Office. 3) Conducting monthly status meetings.

The OFR’s responsibilities during the Maintain phase shall include: 1) Developing the SLA with input from the Contractor 2) Participating in planned activities (e.g., Status Meetings) as necessary. 3) Providing information as requested from the Contractor. 4) Reviewing and approving Monthly Status Reports.

The DFS-DIS responsibilities during the Maintain phase shall include:

1) Participating in planned activities (e.g., Status Meetings) as necessary. 2) Providing information as requested from the Contractor. 3) Review Phase Gate deliverables as per the approved schedule.

The deliverables and performance standards associated with each Phase Gate identified in this scope of work are further defined in Section 5 Deliverables and Acceptance Criteria.

3.2 Out of Scope • Maintenance services related to the Regulatory Enforcement and Licensing (REAL) System and

any changes required to be made to the REAL System to accommodate required interfaces. • Changes to any Department of Financial Services managed systems where an interface with the

CCDB is required. • Changes to the Division of Workers’ Compensation system. • Changes to the Department of State System. • Changes to the check cashers point of sale (POS) systems.

3.3 Requirements This section contains the requirements defining the capabilities, functionality, performance, and other characteristics required of the CCDB. Attachment D - Requirements Response Matrix contains the requirements resulting from JAD sessions with the Office staff and key external stakeholders.

3.3.1 Regulatory Requirements Reference: Attachment E - Requirements Specification Report of the ITN

Maintain Phase Gate. The following deliverables are tied to this Phase Gate: • Warranty Completion Report • Operation and Technical Manual • Operations and Maintenance Transition Plan • Upgrade Schedule and Approach document • Software Escrow Agreement



Page 34 of 45

3.3.2 Functional Requirements Reference: Attachment E - Requirements Specification Report of the ITN

3.3.3 Technical Requirements Reference: Attachment E - Requirements Specification Report of the ITN. DFS-DIS technical oversight of the solution and its implementation is required for hosting options where the DIS infrastructure is impacted. The Vendor is responsible for ensuring appropriate DIS involvement and for requesting and obtaining appropriate DIS approval throughout the project, in accordance with all Technical Requirements and Project Management Requirements.

3.4 Special Office Requirements or Constraints

3.5 Standards and Specifications The Department of Financial Services (DFS) has adopted an Information Systems Development Methodology (ISDM). The primary purpose of the DFS ISDM is to target new development and technology upgrade activities to produce applications that are easier to maintain, perform well under load, provide security controls and facilitate repeatable processes. All deliverables (Work) developed and work conducted by the Contractor pursuant to this SOW shall be performed in accordance with the Division of Information Systems (DIS) standards and specifications. These standards will be strictly adhered to and are available at the following website: http://www.myfloridacfo.com/dis/isdm/ New application development activities are defined as “activities that result in the creation of new source code with the expected outcome of satisfying a business need for the first time in the chosen development language.” New application development and technology upgrade activities are required to follow the DFS ISDM and DFS Application Development Standards unless prior written exemption is approved by DIS. The DFS ISDM Life Cycle Checklist is a roadmap to ensure critical checkpoints and deliverables are met. The Checklist has various required steps and associated documents that must be completed both during the development process and prior to production deployment. New development activities and technology upgrade activities should use the most recent .Net templates provided by the DIS, Bureau of Enterprise Applications. Application maintenance and enhancement activities that are not technology upgrades or new development should also follow the DFS ISDM Checklist. However, these activities should continue to enhance and maintain existing applications in the same style, framework and architecture that already exist in the application. Exceptions to the ISDM process, templates, standards and checklist must be requested in advance of work being performed by contacting the Division of Information Systems.



Page 35 of 45

4 Deliverables and Schedule

4.1 Deliverables

The Contractor shall prepare and deliver the following deliverables to the OFR. The OFR will use the Performance Measures to determine when each deliverable will be considered acceptable. (Prices and rates will be stated in the Pricing Proposal submitted by the Contractor.)

No. Deliverable Deliverable Description Performance Measures Phase One: Initiate and Plan 1.1 Project Management

Plan This deliverable is built on the PMBOK framework and includes key information about the planning, execution, and continued monitoring and controlling throughout the life of the project.

At a minimum, the deliverable shall: • Be based on an industry standard project

management model such as PMBOK. • Include sections specified in the Scope

of Work, Section 3.1.1.1 Phase One: Initiate and Plan.

• Maintained throughout the life of the project.

• Include templates for Weekly Status Report and Risk/Issue Tracking.

1.2 Project Initiation Meeting(s)

This meeting is designed as a collaborative review of the PMP and all the deliverables associated with the Project SDLC.

At a minimum, the deliverable shall: • Include an agenda for the meeting. • Include minutes of the meeting. • Result in updated deliverables (i.e.,

PMP) if applicable. 1.3 Project Status Report Project Status Reporting

communicating the overall health of the project will be provided at each Weekly Status Meeting throughout the life of the project.

At a minimum, the deliverable shall: • Include sections on milestone tracking,

key activities completed, forecasted work for upcoming reporting periods, issues log, and a risks log.

Phase Two: Define 2.1 Updated Requirements A document explaining the At a minimum, the deliverable shall:

OFR expects that the level of detail within the deliverables will be commensurate with the project size and complexity. For Non-Performance: Failure to complete the required duties as outlined may result in an Office initiated corrective action plan. The Contractor will have an opportunity to respond to the corrective action plan and provide a cure to the deficiencies identified in the corrective action plan. The Office may accept or reject the Contractor’s recommended cure. Invoices will not be processed until the Contractor successfully exits the cure period.



Page 36 of 45

No. Deliverable Deliverable Description Performance Measures Specifications Report CCDB system architecture

and associated requirements (i.e., functional, technical, regulatory).

• Update the RSR based on the selected hosting option, the vendor’s proposed solution, and the results of the requirements validation sessions.

• Ensure that the RSR is aligned with the updated RTM.

2.2 Requirements Traceability Matrix

Link of all the functional, technical, and regulatory requirements back to future software development, testing, and implementation activities.

At a minimum, the deliverable shall: • Identify requirements at the lowest level

required to perform design activities; values are identified at the field level and consistency edits are defined.

• Be based on an industry standard Requirements Management tool, as agreed to by the Office, which can import data from tools such as Microsoft Excel.

• Maintained through the project lifecycle (i.e., Define, Design, Develop, System Test, Implementation, and Maintenance phases).

Phase Three: Design 3.1 Functional Design

Document Provides a conceptual perspective of the CCDB solution including data models, process models, and both graphical and narrative representation for each form, report, interface, and enhancement.

At a minimum, the deliverable shall: • Be supported by appropriate models

(i.e., data models, process models, data dictionary).

• Include visual presentation with appropriate narrative context.

• Include the User Interface Standards that shall be built upon documented industry standards.

• Include a Prototype that demonstrates key functionality that is being met by the CCDB solution.

• Include Report templates for any predefined reports.

• Documentation complies with the DIS policies, procedures and technical standards provided by the Contract Manager.

3.2 Technical Design Document

The TDD shall demonstrate the overall infrastructure necessary to support the CCDB system architecture.

At a minimum, the deliverable shall: • Include a graphical and narrative

explanation of the underlying infrastructure necessary to support the



Page 37 of 45

No. Deliverable Deliverable Description Performance Measures CCDB architecture.

• Include the System Architecture that illustrates a tiered representation of the CCDB solution (e.g. client, server-side components, network layer, data layer, security layer, etc.).

• Include a Database Design that represents the data structures, an entity relationship model and a database schema that defines tables, fields, relationships, views, indexes, packages, procedures, functions, triggers, types, sequences, XML schemas, and other elements.

• Include the Web Services Interfaces Design that defines each interface and technology necessary to support each interface (e.g., SOAP, XML, etc).

Phase Four: Develop 4.1 Source Code A copy of the source code

libraries shall be provided to the Office in a usable medium.

At a minimum, the deliverable shall: • The code libraries shall be loaded into a

standard source code repository. • Source code shall be documented to

reflect updates and extensions of functionality where appropriate.

• System needs all requirements enumerated in this SOW, including requirements for system performance.

• Document business and technical requirements for approval by the Office.

4.2 Unit Test Plan The plan shall communicate the methodology and approach used to ensure that requirements are fully tested during the Develop Phase of the Project Life Cycle.

At a minimum, the deliverable shall: • Include a narrative of the Unit Testing

methodology applied in the Develop Phase of the Project Life Cycle.

• Include an explanation of the approach used to apply the Unit Test methodology and document the Unit Testing policies and procedures that will be followed during the life of the project and the future maintenance of the CCDB solution.

• Document the development and testing guidelines applied during the Project



Page 38 of 45

No. Deliverable Deliverable Description Performance Measures Life Cycle.

4.3 Unit Test Results Unit Test Results shall be documented in a standard report layout and include the result of each case executed.

At a minimum, the deliverable shall: • Provide a report showing each unit test

case executed with the corresponding result (e.g., pass/fail).

4.4 Infrastructure Plan The plan shall document the necessary hardware, software, and network components to support the CCDB environments (i.e., Development, Testing, Production).

At a minimum, the deliverable shall: • Provide detailed information about each

component within the system architecture.

• Include information based on a validated server sizing study.

4.5 Configuration Management Plan

The plan shall document the configurations of all hardware and software necessary to support the CCDB solution.

At a minimum, the deliverable shall: • Provide sufficient information so that

the plan may be used as a tool to establish the overall approach for the Configuration Management activities of the CCDB.

• Identify the overall policies and methods for the Configuration Management activities to be used during the system life cycle of the CCDB solution.

Phase Five: System Test 5.1 Test Plan The Test Plan shall cover

multi testing components including System, End-to-End, Interface, Performance/Stress, User Acceptance, and Regression.

At a minimum, the deliverable shall: • Include templates to document the

results of each testing component. • Include process maps illustrating the

steps of each test.

5.2 Test Cases Documented test cases that are linked back to the requirements will be utilized in the execution of test cases.

At a minimum, the deliverable shall: • Include an inventory of test cases by

functional area. • Provide a link between test case and

requirement. • Be maintainable as changes are made to

the system. • Develop tests to ensure the system

meets requirements. • Testing has been conducted and

completed.



Page 39 of 45

No. Deliverable Deliverable Description Performance Measures 5.3 Test Results A tool to track the

execution of test cases with the corresponding result (e.g., pass/fail).

At a minimum, the deliverable shall: • Provide a report showing each unit test

case executed with the corresponding result (e.g., pass/fail, remediation action).

5.4 Updated Requirements Traceability Matrix

The Requirements Traceability Matrix is a living document which should be documented through the life cycle. The Matrix is used as a tool in the testing process.

At a minimum, the deliverable shall: • Be maintained as appropriate during the

Testing cycles.

Phase Six: Implement and Train 6.1 Implementation Plan The plan shall address the

methodology and approach necessary to launch and maintain the CCDB platform.

At a minimum, the deliverable shall: • Include database administration

procedures. • Include installation procedures. • Identify the steps leading up to rollout. • Clearly document the procedures for

promoting software to the production environment.

• Define a rollback process in the event major issues surface of a software release.

6.2 Disaster Recovery (DR) Manual

The plan shall address the strategy for business continuity to minimize the effects of a disaster to enable the Office to maintain or quickly resume critical functions.

At a minimum, the deliverable shall: • Require a successful Recovery Test of

the entire application has occurred. • Include a final, updated copy of this

Deliverable to be issued to the Office in electronic, hardcopy and CD format.

6.3 Fully Deployed CCDB Solution

All agreed to User Acceptance Test cases have been deemed “Passed” and any remaining issues are being tracked and prioritized within the defect remediation process.

At a minimum, the deliverable shall: • Include a closeout report of closed UAT

scripts and open defects to be resolved in remediation process.

6.4 Customized Training Plan

A plan to ensure that all the CCDB end users have access to the knowledge and skills necessary to effectively employ the

At a minimum, the deliverable shall: • Provide an approach with plan and

mechanism to achieve the necessary knowledge transfer to the CCDB end users.



Page 40 of 45

No. Deliverable Deliverable Description Performance Measures CCDB solution.

6.5 Training Schedule A supporting timeline with allocated resources to achieve the Training Plan.

At a minimum, the deliverable shall: • Include a detailed schedule of tasks and

activities to achieve the objective of the Customized Training Plan.

6.6 Customized Training

Material The Contractor shall provide the necessary training aides and materials to facilitate the CCDB training to end users.

At a minimum, the deliverable shall: • Include original copies of the training

material in an agreed upon media (e.g., web-based, digital, etc.).

6.7 Training Execution

Report The Contractor shall provide a minimum of five training sessions with OFR internal users.

At a minimum, the deliverable shall: • Include a closeout report (e.g., training

results such as satisfaction percentage, percent of employee completion, percent pass vs. failed, etc.) documenting the training sessions and the participants that were trained.

Phase Seven: Maintenance 7.1 Warranty Completion

Report The warranty support period will last 12 months from the date of the CCDB solution going live.

At a minimum, the deliverable shall: • Monthly Operational Reports

documenting overall status, key activities, and open issues.

• A final closeout report at the end of the 12 month warranty period.

7.2 Operation and

Technical Manual The manual shall explain how to use, operate and maintain the CCDB system.

At a minimum, the deliverable shall: • Include current inventory of hardware

and software versions. • Include documented processes to

support the system. • Include checklists and templates to

ensure operational tasks are completed timely.

• Include a disaster recovery component for the CCDB solution.

7.3 Operations and Maintenance Transition Plan

The plan shall document the Contractor’s approach to transition the operations and first line support of the CCDB solution to the Office.

At a minimum, the deliverable shall: • Include a detailed approach with

activities and tasks to be accomplished. • Include an inventory of business

processes, knowledge, and skills necessary to execute the operational components of the CCDB system.



Page 41 of 45

No. Deliverable Deliverable Description Performance Measures • Transfer to the Office data and records

and at a minimum provide to the Office: data definitions, table structure, the Office’s data under its control, and any custom code required to allow the Office a smooth transition to in-house or substitute vendor implementation of similar functionality to that provided by the Contractor.

• Three months prior to termination, the Contractor shall provide the Office an explanation of the functional equivalent of the technical requirements of any services or proprietary products used to carry out the contract and all documentation supporting a description of the technical and service requirements.

7.4 Software Update Schedule and Approach Document

The Contractor shall maintain a release schedule of all patches and upgrades for all licensed software within the CCDB architecture.

At a minimum, the deliverable shall: • Include a current list of CCDB licensed

components with version number and date installed/upgraded.

• Include a frequency of expected software releases for planning purposes.

• Include a performance standard to measure the performance of each licensed CCDB component.

• Include Upgrades, upgrade notifications and remote diagnostics.

• Include Guaranteed right to new versions.

• Include a completed record of work, including workflow authorization signatures, when implementing patches and updates for system software.

7.5 Software Escrow Agreement

Documented agreement that gives OFR access/ownership of the source code based on defined situations.

At a minimum, the deliverable shall: • Include completed and signed Software

Escrow Agreement. • Detail how/where CCDB software code

is escrowed, who holds it and the conditions for code handover.



Page 42 of 45

4.2 Deliverables Format The deliverables described in this section are to be provided in electronic format, and shall be in a format that can be updated by the OFR, using the following DIS project software standards (or lower convertible versions):

File Content Application Version Word Processing Microsoft Word 2003 Spreadsheets Microsoft Excel 2003 Entity Relationship Diagrams and Physical Diagrams

Sybase Power Designer Erwin Visio

10 (or version that can be opened in 10 and 12) In version and format that can be opened in DIS version of PowerDesigner 2003

Process Flow Diagrams Visio Sybase PowerDesigner

2003 12

Project Management MS Project Professional Project Server

2003 2003

Database DB2 Oracle SQL Server Microsoft Access

8 8.1.7 and 10g 2005 2003

Programming Source Code MS Visual SourceSafe (or .NET equivalent)

6.0 C

Presentations MS PowerPoint 2003 Email and Calendar/Scheduling MS Outlook 2003 Security/Authentication Active Directory

4.3 Project Schedule

The following schedule reflects the deadlines for completion of the services detailed in this SOW. In addition to this list, the final Contract may identify other deliverables not yet listed, which must be segregated into logical phases and milestones with a work schedule and completion date for each one. In this instance the Office will work with the Contractor to establish the work plan and related deliverable date. The Vendor shall provide projected dates for completion in their response.

Milestones Due Date Initiate and Plan Acceptance Define Acceptance Design Acceptance Develop Acceptance System Test Acceptance



Page 43 of 45

Milestones Due Date Implement and Train Acceptance Maintain Acceptance

4.4 Inspection and Acceptance All deliverables shall be submitted to the Contract Manager for review and approval. The Contractor shall provide the Office with a Deliverable Review Schedule to notify project participants in advance of when they are expected to be available for review and acceptance of deliverables. The Office will accept each deliverable in writing when it has been reviewed and signed off that it meets the applicable criteria specified in this SOW, including the standards and guidelines referenced herein. The Office may provide additional acceptance criteria during the contract period to be used for the deliverables. Failure to accept a deliverable within 20 days means automatic non-acceptance by the Office unless stated otherwise by the Contract Manager in writing.

5 Responsibilities and Staffing

5.1 Contractor Responsibilities

The Contractor responsibilities have been outlined in Section 3.1.1 of this SOW under each SDLC Phase.

5.2 DIS Responsibilities 1) Internet connectivity 2) Access to telephones and printers, as needed 3) Work stations, as needed 4) Access to the DFS network as appropriate while adhering to the DIS ISDM standards 5) Access to the DFS/OFR platforms and interfacing systems as appropriate 6) Access to applicable policies and standards

5.3 OFR Responsibilities

1) Oversight: • The OFR shall require its staff to review Contractor reports and reconcile them to

supporting documents. • The OFR shall provide a dedicated Project Manager to liaise with the Contractor’s

dedicated Project Manager and will be the day-to-day point of contact for the Contractor. • The OFR shall provide documentation as requested by the Contractor and within a

specified timeframe. • The OFR shall provide staff as required to complete all phases of the engagement.

2) Facilities and Equipment: • The OFR shall provide work space as needed.



Page 44 of 45

5.4 Location of Work

It is expected that the work outlined in this SOW will be conducted on-site in OFR’s Tallahassee offices at 200 East Gaines Street, Tallahassee, Florida 32399. If the Contractor uses their own computer laptop, the equipment will be subjected to a security review by the Office in order to ensure it is free of software viruses and does not otherwise pose a security threat prior to connection to the Office’s network.

5.5 Project Staffing

5.5.1 Contractor Project Staffing The Contractor must organize their staff so that individuals fulfill specific roles in a well-defined organization. The Contractor must define its proposed key staffing organization. The specific roles, responsibilities and the education, knowledge, and experience required to perform the role shall be identified. Contractor staff members fulfilling key roles are considered to be key staff. The Contractor’s proposed organization should identify any specific roles required by its methodologies or solution. The Office reserves the right to designate additional roles as key staff. Organizationally, the Contractor is free to structure its organization to perform specific roles. The Office provides the following key staff recommendations:

1. There shall be one staff member fulfilling the Project Manager role. 2. There shall be one staff member fulfilling the Technical Lead role.

Staff members acting in key roles of the project shall be identified by name in the proposal and shall be available for the project. Please refer to Attachment A - Standard Contract for specific clauses pertaining to reassignment of key personnel.

5.5.2 Office Project Staffing Role Responsibilities

Executive Sponsor Decision-maker who provides high-level direction and final approval of legislative or financial agency impacts.

Project Sponsor

Represents the executive sponsor on a day-to-day basis; Makes most decisions except those impacting the Office legislatively or financially; Works with Contractor’s Project Manager and OFR’s Contract Manager to develop deliverable acceptance criteria; Approves major deliverables.

Steering Committee Group of high-level stakeholders who provide guidance on overall strategic direction; Facilitate resolution of significant issues in the project.



Page 45 of 45

Role Responsibilities

Business Analysts

Participate in defining business requirements, functional requirements and validation Participate in testing activities; Respond as necessary to business related issues/questions.

Business Coordinator

Provide support to the Contractor’s Project Manager. Manage OFR’s involvement in the planning, development, review and acceptance of all project deliverables; Ensures OFR meets agreed upon project schedule; Ensure adequate business resources are available; Coordinate project status communications; Resolve minor issues, but major issues are escalated to the Project Sponsor; Coordinate activities and communications with external stakeholders; participate in the daily management of project scope, risk, quality; Ensure compliance with project proposal and with all established standards. Coordinate activities with the business / Office community including testing and training; Define business rules; Authorize access and serve as the primary application contact for troubleshooting after the application is installed.

DFS IT Coordinator

From the technical side; Provide support to the Project Manager; Coordinate and manage DIS resources; Develop the associated tasks and estimated effort hours for DIS resources; Ensure compliance with DIS policies, procedures and technical standards.

Technical Experts

From the technical side; Participate in required technical related discussions and activities, especially those related to infrastructure issues and back-end systems.

Disaster Recovery Coordinator

From the technical side; Coordinate Recovery Test and inclusion of Project Disaster Recovery plans into overall Office Disaster Recovery Plans, as appropriate.

DFS DIS PMO Representative

From the PMO; Monitor and review projects to ensure compliance with PMO policies, procedures and standards; Review project management processes for adherence to sound PM practices; Review project deliverables and processes used to create them for quality assurance purposes; Develop and manage metrics to measure the quality of project deliverables and services.

Contract Manager

Main Office point of contact for all issues related to the SOW; Serves as the Office’s Contracting Officer for purposes of an applicable STC; Review, verify and approve invoices from the Contractor; Receives all deliverables from the Contractor; Ensure the timely review by the Office of all planning documents and deliverables.