Attachment A - Scope of Services.pdf

Attachment A - Scope of Services

Application Migration

Legislative Appropriations System / Planning and Budgeting Subsystem

Executive Office of the Governor State of Florida

Systems Design and Development

1.0 Introduction

The Legislative Appropriation System/Planning and Budgeting Subsystem (LAS/PBS) is a custom written application used by the State of Florida for the development and implementation of the annual State budget. The application has approximately 500 authorized users throughout the State. These users include:

• State Agency Budget Officers and Analysts

• Executive Office of the Governor (EOG)

• Budget Analysts from the Executive Office of the Governor, Office of Planning and Budget (OPB)

• Budget Analysts from the House Appropriations Committee (House)

• Budget Analysts from the Senate Appropriations Committee (Senate)

The Contractor will comply with section 508 of the Rehabilitation Act of 1973, as amended and 29 U.S.C.

s. 794(d), including the regulations set forth under 36 C.F.R. part 1194. Section 282.601(1), F.S., states that “state government shall, when developing, competitively procuring, maintaining, or using electronic information or information technology acquired on or after July 1, 2006, ensure that State employees with disabilities have access to and are provided with information and data comparable to the access and use by State employees who are not individuals with disabilities.

The application was designed to adhere to applicable Florida Statues detailing how the State of Florida develops, implements and maintains the annual budget. These Statues include (but are not limited to) section 215, Florida Statutes and section 216, Florida Statutes. Any changes in the functionality of the application must be approved by the Florida Legislature prior to changes being implemented.

LAS/PBS is a legacy application that resides on the Department of Financial Services (DFS) IBM mainframe. The application is developed and maintained by the Systems Design and Development policy unit (SDD) located within the Executive Office of the Governor, Office of Planning and Budget (also known as Office of Policy and Budget). The application code is written utilizing traditional mainframe programming languages and databases. In recent years SDD has begun the process of creating a web-based user interface for the application moving away from the traditional “green screen” appearance of mainframe applications. The web user interface is created with the newer development technologies and a small relational database that controls user’s preferences on the web.

SDD is interested in finding a vendor that will work with existing staff to convert the existing legacy application to modern technologies and have the production application reside on the cloud. There will be no changes to application functionality or business processes. The vendor selected will have access to all source code, databases and requirements written for the LAS/PBS application. SDD requires the application be developed using the Microsoft’s C# language with an Oracle database for data storage.

Pursuant to 60GG-4, F.A.C., The state agency will ensure that contracts reflect the restriction on the geographic location of data to the continental United States unless approved in writing by the agency head or designee. Remote access to data, other than open data, from outside the continental United States is prohibited unless approved in writing by the agency head or designee.

The resultant application database shall replicate with the existing ADABAS database to ensure a failover method should the cloud application not perform once moved to production.

Application Database

Business Layer

Mainframe Programming

Language

Screen Maps

Programming

Language

Communication Layer

Web Interface

User Preferences

User Community

Business Layer/ User Interface Application

Data

Application Data

Business Layer

Programming

Language

Screen Maps

Communication Layer

Web Interface

User Preferences

Existing Legacy Application to be used for first year disaster recovery.

2.0 Current Production Implementation

The LAS/PBS application currently exists in two environments. These environments are commonly referred to as LAS/PBS Mainframe and LAS/PBS Web.

LAS/PBS Mainframe

LAS/PBS Mainframe is a transactional application using separate programs to perform create, read, update and delete functions. There are also a series of programs that are built around the reporting needs of the application. In recent years, programs have been developed allowing the application to integrate with a web-based user interface. These programs accept input data from the web application, perform the data processing and stream the resultant data to the web for display.

Approximately 70% of the transactions have both a traditional mainframe user interface as well as a corresponding web interface. There are approximately 90 transactions that are only available on the mainframe. Approximately 30 transactions are only available on the web. For a complete list of transactions refer to Exhibit B.

LAS/PBS Web

LAS/PBS Web is a customized web-based user interface allowing users to interact with the LAS/PBS mainframe from a web browser. The traditional mainframe input screens have been modernized to create an experience that is more robust and user friendly.

The application is menu driven with links for each transaction on the mainframe. The web pages are used for navigation throughout the application and data input.

Data entered on the web pages is streamed to the mainframe application for processing. The application then streams the data back to the web pages for display.

Reporting/Downloads

Reporting in the LAS/PBS application is accomplished by entering report criteria on the Mainframe or Web interface. The mainframe generates a dataset and transmits the dataset to the web servers. Third party software on the web server then utilizes the dataset to generate a PDF which can be accessed from the “Preview” tab or emailed to the user. Note that some reports are statutorily required to appear in a particular fashion. At no time will any report layouts be modified from what is currently produced.

Data downloads in the LAS/PBS application are accomplished by entering download criteria on the Mainframe or Web interface. The mainframe generates a dataset and transmits the dataset to the web servers. Third party software on the web server then utilizes the dataset to generate an .xlsx or .docx file which can be accessed from the “Preview” tab, emailed, or opened within the browser.

3.0 Proposals

The proposed solution provided by the vendor shall:

• reside in the Amazon cloud environment

• use modern programming technologies

• use modern database for data storage

• easily add/remove hardware resources allowing SDD to increase resources during peak usage and remove resources when they are not needed

• perform bi-directional replication between the converted database and the existing mainframe database

• provide increased security with two factor authentication (2FA)

• meet or exceed the current web application performance measures

• maintain the look and feel of the current LAS/PBS Web environment (user interface)

• cause no change in functionality between current transactions and converted transactions

• convert transactions without web interface to reside within the web application

The selected vendor will be given access to all LAS/PBS source code and requirements. The converted application is to have NO changes in functionality. If functionality differences exist between the converted application, the LAS/PBS requirements and the current production application, the current LAS/PBS Mainframe and LAS/PBS Web application functionality will supersede the requirements and the converted application. Upon project completion, SDD will be given all source code and documentation created by the vendor for ongoing application maintenance and enhancements. The selected vendor will also provide code walkthroughs with SDD developers to ensure that migrated code adheres to LAS/PBS standards. Code walkthroughs will also provide knowledge transfer between the selected vendor and the SDD development team.

Approximately 90 LAS/PBS Mainframe transactions do not have a corresponding web interface. These transactions will need to be converted to reside in the resultant web application. Vendors shall provide two plans for converting these transactions.

1. Convert the transaction “as is”. The interface will appear exactly as it does on the mainframe while residing in the web framework.

2. Convert the transaction using a SDD provided page layout. The screen layout will be redesigned to match current LAS/PBS Web pages.

At no time during the conversion of these transactions will any functionality change.

4.0 Timeline

LAS/PBS operates year-round with peak usage based on the State budget cycle. Peak usage cycles would include:

• the 30 days of the fiscal year Startup

• the 14 days prior to the release of the State Agency Legislative Budget Requests

• the 28 days prior to the release of the Governor’s Recommendations

• the 60 days of the Florida Legislative Session

Due to these constraints, implementation of the converted application must occur after the completion of the Startup process and before agencies Legislative Budget Requests are due. Note that any selected date may need to be altered if the Annual State Budget is not implemented in a timely manner.

5.0 Additional Information

SDD has provided two documents to assist interested vendors in determining the amount of work required to convert the LAS/PBS application for its current state to the proposed state.

Exhibit A is the Business Requirements. In this exhibit SDD has explained the functional aspects of the application and how it adheres to State law.

Exhibit B is the Technical Overview. In this exhibit SDD has explained the technical aspects of the current application. Included is a listing of the LAS/PBS transactions, name and description of the transaction as well as columns indicating the language of the business layer and language of the user interface. The document also contains SDD concerns related to how aspects of the current system are to be converted to the new application.

Upon request SDD will also provide the following information. Please note that some of this information is considered sensitive and will require the vendor to sign a non-disclosure form.

• All technical requirements related to the LAS/PBS application

• Source code

• Database

6.0 Deliverables

The following sections identify the deliverables by each phase of this project. The deliverables listed shall be required under this proposal. The vendor’s proposed deliverables shall include the LAS/PBS deliverables listed herein.

6.1 Project Initiation

LAS/PBS Responsibilities

The application is currently maintained by SDD. SDD will provide the awarded vendor with the following:

• Access to its technical resources, as needed, to explain code and answer technical questions.

• Requirements documentation.

• All data contained in the system.

• All source code currently utilized by the application.

• LAS/PBS Web current coding conventions and standards.

• Database design documentation detailing the structure of the database.

• Complete set of test data to allow development of conversion strategies.

• A listing of third-party software utilized by the LAS/PBS application.

• Access to conduct the LAS/PBS application assessment and a baseline performance assessment.

• Set up and maintain the non-production environments (Development and

Test) as recommended by the vendor.

Vendor’s Responsibilities The awarded vendor shall provide a project kickoff presentation within 30 days of the issuance of the contract. The presentation shall include the following elements:

• Introduction – Vendor explanation of the project purpose, scope, assumptions, constraints, schedule, resources, and risks to insure they align with the Scope of Work, Business Requirements (Exhibit A) and Technical Overview (Exhibit B).

• Proposed Timeline – Start dates, end dates, tasks, dependencies and critical path.

• Project Delivery Methodology – Such as design-build, fast track, scrum or agile.

• Project Management Tool Access – Vendor’s proposed tools and access for reporting, documentation, and collaboration. Vendor will be responsible for providing SDD project staff with access to the tools and documentation.

a) The vendor shall conduct and present the LAS/PBS application assessment and baseline performance assessment.

b) The vendor shall provide a certified Project Management Professional (PMP) to lead the project.

c) The vendor shall provide proof of insurance and process for virus and ransomware prevention and protection.

6.2 Project Planning Phase

The following items within the Project Planning Phase section shall be delivered by the vendor and approved by LAS/PBS contract manager during the planning phase of the project.

a) Project Management Plan

• Scope of Work – What is in-scope and what is out-of-scope.

• Assumptions and Constraints – Detail assumptions and limitations.

• Approved Schedule and Timeline - The approved timeline will include scope of work, tasks, effort, resources, begin and end dates, dependencies and critical path. Any proposed changes to the approved timeline must be authorized by the LAS/PBS contract manager.

• Work Breakdown Structure (WBS) – Identify the hierarchical and incremental decomposition of the tasks to deliver each milestone of the project. The LAS/PBS milestones listed in the Milestones section, shall be included in the vendor’s Work Breakdown Structure.

• Project Performance Measures – Measures to be monitored and reported throughout the project and will be used to determine if the project objectives have been met.

• List of Project Deliverables – Includes both project management and application specific deliverables.

• Communications – Documenting the responsibility, frequency, type and audience for ongoing project communications. This will include a repository for all project documents, approvals and communications throughout the life of the project.

• Project Status Report – Details the structure, information, format, frequency and location for all status reports.

• Project Meetings – Details the types, frequency, facilitator, participants, responsibilities, documentation/minutes and follow up action items.

• Change Management – How change requests between approved vendor and LAS/PBS contract manager will be initiated, documented, assessed, escalated, approved, tracked and executed.

• Quality Management – How quality will be managed, deliverables produced and what elements define quality in the deliverables and project execution.

• Risk and Issues Management – How risks and issues will be reported to the LAS/PBS contract manager and subsequently monitored, maintained and acted upon throughout the project.

b) Solution Design

• The solution design document shall reflect the conversion of the LAS/PBS application from the current environment to the desired newer technologies making no changes to functionality or screen design.

• The solution design document shall include the following:

o System overview including a description and diagram;

o Oracle Database design (includes structure, schema, data dictionary and map);

o Migration strategy details for moving mainframe database data to a modern relation database;

o Replacement software list with version and proof of commercial availability and licensing;

o Replacement hardware list with version and proof of commercial availability and licensing;

o Detailed code conversion process and methodology (manual rewrite, augmentation, automated refactoring utilities).

o Requirements traceability matrix which maps the (provided) SDD requirements to the transaction code conversion tasks.

o Solution and strategy for remediating changed LAS/PBS application code occurring throughout the project timeline into the new converted LAS/PBS application;

o Solution and design for the converted LAS/PBS application and database scalability to accommodate the high and low demands of the annual budget cycle;

o Solution and design for required infrastructure security;

o Include in the Solution Design plan the disclosure and commitment by the vendor that all materials and intellectual property utilized and created by the vendor to convert the LAS/PBS application and infrastructure will remain the sole and exclusive property of the State of Florida.

o Include in the Solution Design plan the disclosure and commitment by the vendor that the final LAS/PBS product inclusive of all materials and services as the result of this conversion will remain the sole and exclusive property of the State of Florida.

o Solution and strategy for disposition of all LAS/PBS data, programs, scripts and other items developed by the vendor for this project after transition to SDD;

o System integration plan;

o Assumptions; and o Constraints.

c) Disaster Recovery and Failover Plan

• The disaster recovery and failover plan shall include the infrastructure solution for restoring the system to operation and shall be reviewed and approved by the LAS/PBS contract manager.

• The disaster recovery and failover plan shall include the steps required to restore the system to operation and shall be reviewed and approved by the LAS/PBS contract manager.

• The disaster recovery and failover plan shall describe data loss prevention and data recovery methods used to meet current capabilities (recover database, individual files and individual columns) and shall be reviewed and approved by the LAS/PBS contract manager.

• The disaster recovery and failover plan shall include the comprehensive test plan and procedures that will be used and validated on an annual basis.

d) Test and Validation Plan

• The project test plan document shall include the plans and timelines for the following tests and shall be reviewed and approved by the LAS/PBS contract manager:

o Data Verification and Validation;

o Unit and System Testing (vendor shall test and correct all converted data and code prior to releasing to SDD for testing);

o Functional Testing (includes requirements traceability matrix);

o Integration Testing;

o System Testing;

o Security Testing;

o Business Cycle (end to end) Testing;

o User Acceptance Testing;

o Load and Performance Testing;

o Defect Management (Tracking and Resolution of issues found); and o Disaster Recovery and Failover Testing.

• The project test plans must outline vendor and SDD staff who are responsible for testing the application.

• The project test plan shall include a process used to report errors discovered during SDD system testing and vendor’s resolution response.

• Final testing shall include the confirmation that requirements have been fulfilled using the requirements traceability matrix.

• The final cloud solution shall be established by SDD per vendor recommendations.

• Final acceptance testing shall be performed by SDD in the cloud environment.

e) Code Review and Training Plan

• Shall include that requirements have been fulfilled utilizing the requirements traceability matrix.

• Shall provide an Operations and Maintenance Plan that documents the

Development Operations (DevOps) process for the operation and continued maintenance of the LAS/PBS application and services.

• Shall provide a plan for the training and knowledge transfer of the new technology that includes guide and training documentation for SDD staff.

• Shall include the details for handing over the new application and infrastructure to SDD along with the approval process.

• Shall include the timelines and resources.

f) Go Live and Rollback Plan

• Shall include the detailed implementation plan with schedule, tasks, resources, predecessors and dependencies for both go live and rollback plans.

• Shall include the process and criteria for evaluating the “Go or No-Go” decision.

• Shall include the production readiness process for go live.

• Shall provide a plan that includes a valid rollback and mitigation if go live implementation fails.

• Shall provide a plan that includes a valid rollback and mitigation in the case that the solution has been implemented and in place for a period of time such as weeks or months.

• Shall include a Service Level Agreement (SLA) which identifies how issues and tasks will be managed including the quality, response time and resolution. The SLA must identify service provider and state agency responsibilities for privacy and security, protection of government data, personnel background screening, and security deliverables with associated frequencies.

g) Non-Production Environment for Development and Testing Plan

• Shall include that SDD will set up and maintain the non-production environments (Development and Test) as recommended by the vendor.

• Shall provide a plan for SDD to set up and maintain the non-production environments (Development and Test) to be hosted on-site in SDD’s current environment.

• Shall provide a plan that outlines establishing and maintaining a development and test environment that mimics a true projection of the production environment.

• Shall provide the strategy for a development and test environment populated with the LAS/PBS application framework and converted Oracle database.

• Shall provide a plan that outlines the use of on premises Azure DevOps for the requirements repository.

• Shall provide a plan that outlines the use of on premises Azure DevOps for the test scripts repository.

• Shall provide a plan that outlines the use of on premises Azure DevOps for the code repository for development and test environments.

h) LAS/PBS Mainframe database to relational database conversion plan

• Shall provide a database conversion plan that includes the current LAS/PBS

Web database design using the existing Column approach.

• Shall provide a plan that bases the new LAS/PBS relational database table structure on the mainframe database structure and concepts.

• Shall provide a plan that involves all LAS/PBS mainframe data being converted and migrated to the new relational database.

• Shall provide a plan that includes all data converted and migrated to the new relational database to be validated and verified against the current LAS/PBS mainframe data.

• Shall provide a plan that includes the converted database in development and test environments to be a true projection of the production environment.

• Shall provide a plan that outlines SDD’s ability to administer converted databases in the production, test and development environments.

• Shall provide a plan that details the approach to confirm that the converted database has been tuned for performance meet or exceed documented measures.

i) Bi-Directional Mainframe to Relational Database Replication

• Shall provide a plan that outlines how the two way replication between mainframe and relational databases will be provided.

6.3 Project Execution and Control Phase

The following items within the Project Execution and Control Phase section shall be delivered by the vendor and approved by the LAS/PBS contract manager during the execution phase of the project.

The remainder of this page is intentionally left blank

a) Shall conduct and deliver project meetings, minutes, status reports as agreed in the Project Management Plan.

b) Shall implement all project deliverables as per the Project Management Plan (Scope, WBS, Performance, Communications, Change Management, Schedule, Quality, Resource, Procurement, Risks and Issues).

c) Shall Implement all project deliverables based on the Project Schedule and Timeline Plan.

d) Shall implement all project deliverables following the requirements in the Non-Production environment for the Development and Testing Plan.

e) Shall deliver replacement software as defined by the Solution Design document.

f) Shall deliver replacement hardware as defined by the Solution Design document.

g) Shall deliver converted database as defined by the Solution Design document and the Mainframe to Relational Database Conversion Plan.

h) Shall deliver code/software solution to implement the database replication plan provided in the Mainframe/Relational Replication Plan.

i) Shall deliver converted code, application and services as defined by the Solution Design document and the Code Review and Approval Plan.

j) Shall deliver converted code, application functionality and services as outlined in this Scope of Services, Exhibit A (Business Requirements) and Exhibit B (Technical Overview).

k) Shall deliver converted code, application and services in the order and approach as agreed in the Approved Schedule and Timeline Plan.

l) Shall deliver converted code, application and services integration as defined in the Solution Design Document.

m) Shall deliver converted code, application and services for SDD testing and acceptance as per the agreed Test and Validation Plan.

n) Shall deliver a tested and proven Disaster Recovery and Failover process as defined by the Disaster Recovery and Failover Plan.

o) Shall demonstrate proof of a successful Rollback of the converted application as defined by the Rollback Plan.

p) Shall implement a successful Go Live of the converted LAS/PBS application and services in a cloud infrastructure as defined by the Solution Design document.

q) Shall monitor, manage and update Azure DevOps repository as converted code, application and services are delivered by the vendor and acceptance tested by SDD.

r) Shall monitor, support and resolve all defects and issues found during all testing phases and cycles as outlined in the Test and Validation Plan.

s) Shall monitor, support and provide updates to the Project Management Plan and Schedule and Timeline Plans status changes throughout the project. Shall communicate the updates based on the Communications agreement of the Project Management Plan.

t) Shall execute the Code Review and Training Plan including documentation for transition and turnover of the converted components of the LAS/PBS application.

u) Shall execute the Code Review and Training Plan including the training of SDD staff with DevOps guide and training documentation.

6.4 Project Closure

a) All documentation and plans created and approved during the Project Planning Phase (and outlined in this contract) shall be reviewed and signed off as complete by LAS/PBS contract manager.

b) All requirements in Scope of Work Project Management Plan shall be met and shall be approved by the LAS/PBS contract manager.

c) The vendor shall provide post implementation support with the agreed timeframe and SLA as defined in the Go Live and Rollback Plan.

d) Shall confirm disposition (or destruction) of this project’s data, programs, scripts and all other items developed by the vendor and in their possession.

e) Shall confirm that all materials created and the final LAS/PBS product remains the sole and exclusive property of the State of Florida and cannot be sold or transferred to any other entity.

6.5 One Year Post Implementation Support and Maintenance

a) Shall provide a plan for one year of post implementation support by the vendor and shall be reviewed and approved by the LAS/PBS contract manager. This plan shall include but not be limited to a 24/7 Contact Process, Issue Definition and Escalation Process (SLA), Network and Integration Support and Resolution, Application and Database Support and Resolution and Post-Mortem documentation.

b) Shall provide a plan and the ability to scale down vendor staff/support in the case that Go Live is delayed based on budget cycle and timeline constraints.

c) Shall include in the post implementation plan the requirement and outline of a hypercare support strategy during the first Legislative Session timeframe after successful Go Live.

7.0 Location of Work

Conversion and migration work may be performed at the vendor’s site but cannot be performed offshore. The vendor will have access to the LAS/PBS environments either on-site or via secured connection. The final product will reside in a cloud infrastructure.

8.0 Reports and Meetings

At a minimum, weekly meetings between the vendor and SDD shall be conducted in person or via teleconference as dictated by the LAS/PBS contract manager. All meetings must include an agenda and final minutes provided by the vendor. Remote meeting software can be used. If proprietary software is used for meetings, the vendor must supply licenses for SDD.

At a minimum, a weekly status report shall be submitted at the end of each week by the vendor project manager to the LAS/PBS contract manager. This report must include the following:

• Project – Includes date, project name and description, project managers, team members, stakeholders/contract manager and the location for project status reports.

• Project Overall Summary – This can be a dashboard or list of project’s goals and progress.

Includes the scope, budget, timeline and percentage complete. This is the project’s health status.

• Project Milestones and Deliverables – Includes the detailed work for current deliverables per the timeline. The detailed work should be documented as completed, in progress and pending (next up) for the deliverable.

• Project Issues, Risks and Change Management – Includes status on new and open issues and risks. Also includes change requests and status.

• Project Meetings – Includes all project meetings held for the week and action items from them. Also includes the location of the meeting agenda and minutes documentation.

9.0 Acceptance Criteria

The project shall be considered complete when the new LAS/PBS application runs in a cloud based Windows Server/Oracle environment without errors and meets or exceeds the performance measures agreed upon. The functionality of the new application shall match the current LAS/PBS application. This section is in regards to completion of the project closure deliverable.

10.0 Constraints

• The go live date of the project is constrained by the annual state budget cycle.

• Florida Legislature requires the General Appropriations Act (GAA) output to appear in a specific format and not to be changed in any way.

11.0 Nondisclosure Agreement

Vendors will be required to sign a Nondisclosure Agreement (NDA) for Exhibit B, Technical Overview and any SDD software or code requested during the term of the RFP solicitation. The vendors who signed an NDA and are not awarded, must destroy all data received by the EOG.

12.0 Milestones

1. Approval by the LAS/PBS contract manager of all plans as outlined in section Project

Planning Phase

2. Approval by the LAS/PBS contract manager of the conversion and validation of the Adabas database to the Oracle database

3. Approval by the LAS/PBS contract manager of the bi-directional data replication between the Adabas and Oracle databases

4. Approval by the LAS/PBS contract manager of the conversion and validation of application

Security (Logon and 2FA)

5. Approval by the LAS/PBS contract manager of the conversion and validation of Codes and

Titles maintenance

6. Approval by the LAS/PBS contract manager of conversion and validation of the Budget

Development components

7. Approval by the LAS/PBS contract manager of conversion and validation of the Budget

Allocation components

8. Approval by the LAS/PBS contract manager of conversion and validation of the Special

Functions, Audit/Update, Other Functions and Other Processes

9. Approval by the LAS/PBS contract manager of conversion and validation of data integration with all external systems

10. Approval by the LAS/PBS contract manager of end to end and performance testing of the

LAS/PBS application

11. Approval by the LAS/PBS contract manager of successful working Production and Disaster

Recovery environments

12. Approval by the LAS/PBS contract manager of Disaster Recovery and Failover test of the

LAS/PBS application and infrastructure

13. Approval by the LAS/PBS contract manager of delivery and acceptance of all source code

14. Approval by the LAS/PBS contract manager the execution of training and knowledge transfer of SDD staff by vendor along with appropriate operations guide

15. Approval by the LAS/PBS contract manager of Go Live (Migration of production data and launch of new system)

16. One Year Post Implementation Support and Maintenance

13.0 Milestones, Performance Standards, and Financial Consequences The Contractor should provide the Milestones, meet the performance standards, and be liable for the financial consequences described in the table below. All Milestones must be provided or performed and tested and accepted to the satisfaction of the LAS/PBS Contract Manager.

Deliverable and Performance Standard

Due date or Time Periods

Financial Consequences

Milestone 1 – (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 1 by the mutually agreed upon date.

Failure to submit Milestone 1 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 2 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 2 by the mutually agreed upon date.

Failure to submit Milestone 2 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 3 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 3 by the mutually agreed upon date.

Failure to submit Milestone 3 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 4 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 4 by the mutually agreed upon date.

Failure to submit Milestone 4 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 5 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 5 by the mutually agreed upon date.

Failure to submit Milestone 5 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 6 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 6 by the mutually agreed upon date.

Failure to submit Milestone 6 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 7 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 7 by the mutually agreed upon date.

Failure to submit Milestone 7 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 8 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 8 by the mutually agreed upon date.

Failure to submit Milestone 8 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 9 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 9 by the mutually agreed upon date.

Failure to submit Milestone 9 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 10 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 10 by the mutually agreed upon date.

Failure to submit Milestone 10 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 11 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 11 by the mutually agreed upon date.

Failure to submit Milestone 11 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 12 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 12 by the mutually agreed upon date.

Failure to submit Milestone 12 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 13 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 13 by the mutually agreed upon date.

Failure to submit Milestone 13 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 14 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 14 by the mutually agreed upon date.

Failure to submit Milestone 14 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

Milestone 15 (Section 11 Attachment A, Scope of Services)

The Contractor shall provide Milestone 15 by the mutually agreed upon date.

Failure to submit Milestone 15 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

SUPPORT SERVICES

Milestone 16 – One Year Post Implementation of Support + Maintenance - Includes labor, material, tools, equipment and software and consultation for system support after Milestones 1 through 15 have been completed.

The Contractor shall provide Milestone 16 by the mutually agreed upon date.

Failure to submit Milestone 16 and/or meet the specified time criteria will result in the Contractor being assessed one hundred dollars ($100) for each business day the milestone remains incomplete.

REPORTS AND MEETINGS

Meetings (Section 8 of Attachment A, Scope of Services)

The Contractor shall meet weekly with the Agency and should provide an agenda and meeting minutes to the Agency.

Failure to meet during the specified time or not include the meeting criteria will result in the Contractor being assessed one hundred ($100) dollars for each business day beyond the agreed upon meeting date that the Contractor and Agency do not meet or provide the specified criteria.

Reports (Section 8 of Attachment A, Scope of Services)

The Contractor shall submit a weekly status report at the end of each week by the Contractor’s Project Manager and include the specified criteria.

Failure to submit a weekly status report and/or include the specified report criteria will result in the Contractor being assessed one hundred ($100) dollars for each business day beyond agreed upon report due date.

CORRECTIVE ACTION PLAN

Corrective Action Plan (as listed in Attachment F, Draft Contract)

The Contractor shall submit a Corrective Action Plan to the EOG within the timeframe and in the format requested in writing by the EOG.

Failure to submit the Milestone or meet the specified time criteria will result in Contractor being assessed one hundred dollars ($100) for each business day, until the Corrective Action Plan is submitted.

Corrective Action Plan Implementation (as listed in Attachment F, Draft Contract)

The Contractor shall ensure the Corrective Action Plan implementation within three

(3) business days of the EOG’s written approval, unless a mutually agreeable alternative timeline is established.

Failure to submit the Milestone and meet the specified time criteria will result in Contractor being assessed one hundred dollars ($100) for each business day, until the Corrective Action Plan is completed.