NOTICE - Web viewODOT Web Application ... perform further validation through Java Program and the java ... Proposed project manager and team members resume or curriculum vitae

NOTICE

This opportunity is being released to DBITS Contractors pre-qualified as a result of Open Market RFP #0A1147.

ONLY Contractors pre-qualified in the Application Development and Maintenance Transition Planning Category are eligible to submit proposal responses AND to submit inquiries. The State does not intend to respond to inquiries or to accept proposals submitted by organizations not pre-qualified in this Technology Category.

An alphabetical listing of Contractors pre-qualified to participate in this opportunity follows:

AccentureAdvocate Consulting GroupAdvocate Solutions LLCArdent TechnologiesCapTech VenturesCardinal Solutions GroupCareworks TechCDI CorpCentric Consulting LLCCGI Technologies and Solutions, Inc.CMA Consulting ServicesComputer Aid, Inc.Crowe Horwath LLPData Transfer SolutionsData-Core Systems, Inc.enfoTechHalcyonHMB, Inc.IBMIIT ContactsInfojiniInformation Control CompanyJMT Technology GroupKunz, Leigh & AssociatesLochbridgeMapsys Systems & SolutionsMAXIMUS Human Services, Inc.

McGladrey LLPMGT of America, Inc.Navigator Management Partners LLCPeerless TechnologiesPersistent SystemsPlanet TechnologiesPrelude SystemQuantrum LLCQuick SolutionsR. Dorsey & CompanySense CorpSogeti USA, LLCSondhi SolutionsSystem Soft TechnologiesSystems Technology Group, Inc.TCC Software SolutionsTeam Ray Technologies, LLCTEK SystemsTeranomicThe Greentree GroupTruven Health AnalyticsUnicon International. Inc.VertexWindsor SolutionsXLN Systems

E N T E R P R I S E I T C O N T R A C T I N G | D B I T S S O W S o l i c i t a t i o n D B D O T - 1 8 - 0 3 - 0 0 1 1

Statement of Work Solicitation

State of Ohio DAS on Behalf of the

Ohio Department of Transportation

Highway Information Management System

Project Statement of Work

DBITS Solicitation ID No.Solicitation Release Date

DBDOT-18-03-002 02-21-2018

Section 1: Purpose

The purpose of this Project Statement of Work (SOW) is to provide The Ohio Department of Transportation (ODOT) with information technology services in Technology Category Application Development. A qualified Contractor, herein after referred to as the “Contractor”, shall furnish the necessary personnel, equipment, material and/or services and otherwise do all things necessary for or incidental to the performance of work set forth in Section 3, Scope of Work.

Table of ContentsSection 1: PurposeSection 2: Background InformationSection 3: Scope of WorkSection 4: Deliverables ManagementSection 5: SOW Response Submission RequirementsSection 6: SOW Evaluation CriteriaSection 7: SOW Calendar of EventsSection 8: Inquiry ProcessSection 9: Submission Instructions & Location

TimelineSOW Solicitation Release to pre-qualified Contractor: 02/21/2018Inquiry Period Begins: 02/21/2018Inquiry Period Ends: 03/09/2018 @ 8:00 AMProposal Response Due Date: 03/14/2018 @ 1:00 PM

Section 2: Background Information

2.1 Agency Information

Agency Name Ohio Department of Transportation (ODOT) Office of Planning – Technical Services

Contact Names Allen Skaggs – DoIT Project Mgmt Office

Brian Schleppi – Office of Planning – Technical Services

Contacts Phone 614-387-5697

614-752-5745

Bill to Address Office of Planning – Technical Services Ohio Department of Transportation1980 West Broad StreetColumbus, OH 43223

2.2 Project Information

Project Name Highway Information Management Systems

2 D B D O T - 1 8 - 0 3 - 0 0 1H i g h w a y I n f o r m a t i o n M a n a g e m e n t S y s t e m s

Project Background & Objective

BACKGROUNDThere are two solutions being requested; Highway Infrastructure Management System and Skid Test Management System.

Highway Infrastructure Management OverviewThe Highway Infrastructure Management Section supports every facet of ODOT’s business processes related to highways including planning, design, construction, maintenance, forensics, research and overall management. Highway Infrastructure Management houses ODOT’s expertise on highway surface characteristics (ride quality, friction, rutting, splash/spray/surface drainage and tire/pavement noise) and supports transportation asset management (TAM).

Processes – The Highway Infrastructure Management Section has identified two distinct processes. These processes, which are discussed in detailed later in this document include:

Network Data Collection – This process involves the physical collection of data in the field using ODOT’s data collection van. Specific guidance regarding van equipment data collection preparation/training, data collection scheduling and a field data collection checklist is discussed.

Network Data Processing – This process involves the processing of data collected in the field. Discussion topics include the uploading and processing of raw field data as well as the publishing of data for use by GIS and Roadway Inventory staff and also in support of numerous business needs including TAM, friction, pavement management, planning and the Highway Performance Monitoring System (HPMS) reporting requirements.

The Highway Infrastructure Management (HIM) section in the Office of Technical Services is currently processing critical data/reports using inefficient processes. The HIM data elements (e.g. road roughness, pavement, distress, highway geometrics etc.) are used throughout the ODOT enterprise for the yearly Highway Performance Monitoring System (HPMS) submittal and MAP-21/FAST (Fixing America’s Transportation) Act performance measures. The processing of the HIM data elements requires months of time and uses outdated and unsupported programs to process the data.

For more information please see the attached documents – Project Scope Statement – HIM & Skid Test Ver 4.1 Infrastructure Management Document_Final v4.0 HIM High Level Process Profiler Sample Reports (with dummy data) HIM BRS v1.70 (Business Requirements Specifications) HIM Data Model ODOT Web Application Architecture

Skid Test Overview ODOT, Infrastructure Management staff operate two skid test units or skid trucks that measure the friction between rubber tires and pavement on wet roads. Skid test units consist of a one-ton crew


cab pickup pulling a specially designed two-wheel trailer. The truck travels down the road to be tested at a steady velocity, almost always 40 MPH. At the appropriate time the system is activated and the automatic skid cycle commences. Water is pumped out in front of the trailer test tire. In ODOT's case, this is the left tire. A very powerful braking system locks this wheel and sensitive instruments measure the horizontal and vertical forces acting on this tire.The current system does not have ability to track skid test requests if there are multiple tests by the same user. There is no mechanism to run standardized reports.

For more information please review the content at this URL –https://www.dot.state.oh.us/Divisions/Planning/TechServ/infrastructure/Pages/SkidTesting.aspx

For more information please see the attached documents – Project Scope Statement – HIM & Skid Test Ver 4.1 Mock up Skid Test Request Form HIM BRS v1.70 (Business Requirements Specifications)

OBJECTIVEThe objective of this SOW solicitation is to secure a Contractor who must:

Replace the outdated programs and automate the processing and validating of HIM data and preparation for annual HPMS submittal.

Publish HIMS Data to ODOT Enterprise Data Warehouse Create a new web based request form, workflow, tracker and reporting for Skid

Tests

Current Flow for processing HIM Data elements -There are five Data Categories defined within the HIM data gathered, reviewed and corrected and eventually submitted to HPMS, including: HIM Data elements:

International Roughness Index (IRI) - IRI is the roughness index most commonly used worldwide for evaluating and managing road systems. It is calculated using a quarter-car vehicle math model, whose response is accumulated to yield a roughness index with units of slope

Rutting - Rut is a depression or groove in wheel paths of lanes caused by vehicle tire loads

Faulting - Faulting is the difference in elevation across a joint or crack Cracking - Crack is a break in pavement caused by load and or environmental

factors

At a later date, in a minor release / enhancement, another data element will be added to the HIM system.

Highway Geometrics – E.g. Cross slope, Grade and Radius of horizontal and vertical curves.

There are multiple steps in processing HIM Data elements prior to HPMS submittal: Pre-work and Collect/Process data prior to HPMS submittal.


https://www.dot.state.oh.us/Divisions/Planning/TechServ/infrastructure/Pages/SkidTesting.aspx

https://www.dot.state.oh.us/Divisions/Planning/TechServ/infrastructure/Pages/SkidTesting.aspx

Pre-Work Set up the proprietary database (Pathrunner data Collection) Use previous years data for current year reporting If new NLFID’s are added, use road inventory information to get new NLFID’s in

database Use Collector App for Maps (Paper/Electronic) and Route of HPMS sample section

Collection and Processing of HIM Data elements Pathway van collects the data and data will be copied into system via tapes (Hard

drive) Use the pathway software and copy the data from tapes (Hard drive) into different

folders as per the locations Data will be processed through SAS programs. There are total 5 SAS programs are

used currently to process the data such as: To convert the data into 1/10th mile report file and also converts it to a 143 column

format for conversion to standardize ride number, add predict PSI from the half car IRI value to create final IRI file.

To check the sanity of data by using validation on all the 143 columns E.g.: Year should be 4 digits, Check Left IRI and Right IRI, Lat/Long, BLog, ELog etc. Compare the data from previous step to expected collection distance from road

inventory (Theoretical test distance). Create statistics of the week

Average miles per day Standard deviation High mileage day Low mileage day How many miles covered and How many days it took to cover

To generate a historical report from past 20 years. This report will have following details:

# of runs (segments for Pathrunner) Total # of records Test length Average left IRI Average right IRI Average half car ride Min ride # Max ride#

Create a report for Average between Blog and Elog and average between lat and long.

If any missing data is found then go back to step 2 and continue to find that missing data

Send the Data to GIS group to check for Geo spatial reconciliation for current year’s LRS with respect to Lat/Long. GIS team will delete duplications and null values.

Send the final output file to IT team after linear Vs spatial reconciliation. IT team


performs further validation such as Checks for duplication and delete duplicates Checks for null values and replace them with historical data (validation

involves up to 4 years of data) Checks for all county route section, if any missing data is found then a

log is created and send it to Business users, so that they can respond with missing data

After data scrubbing is done, perform further validation through Java Program and the java application loads the data into Oracle ORSP table.

Finally provide the refined data to HPMS team. HPMS team uses the final data provided by IT team and submits on the HPMS

website

There are a lot of manual steps in current process which are time consuming and susceptible for errors. These can be eliminated with automation and increased efficiency.

Business Objectives

The Contractor must automate the HIM data process that applies to HPMS files will reduce manual intervention, duplication and errors

The updated process will improve the HPMS process for HIM data elements and assist in meeting MAP21 performance measures

Replace unsupported technology (E.g. SAS etc.) with DoIT supported technology Centralized storage of authenticated HIM Data Specialized web-based data collection request form and request tracker Integration of HIM data elements to ensure data is available within the ODOT

Enterprise Data Warehouse Import historical data into new HIM Database

20 Years of data (approximately 30MB each - in ASCII text, pipe (|) delimited file format)

May require data conversion to align historical data to fields in HIM Database

The Contractor must implement a Skid Testing Request Function. Using this functionality, the user can request skid testing at all the locations needed. These new request forms will generate a unique request number which can be tracked in the new database.

Create reporting solution for new Skid and Profiler reports for the use of agency, so that Skid test reports are standardized and searchable in database.

Update existing Skid and Profiler reports Import of historical reports into Skid Test Management System

o May require data conversion to align historical data

2.3 Project Schedule

Expected Project Duration

The selected Contractor will be notified by ODOT when work may begin. The estimated start date for this project is late March 2018. This project is expected to be completed by September 28, 2018. Support and technology transfer activities will begin after formal deployment has been accepted by ODOT.


2.4 Project Milestones

Estimated Date Milestone

03-30-2018 Kickoff Meeting

04-18-2018 Completion of Discovery / Requirements

05-05-2018 Completion and delivery of Wire Frames / Designs

08-15-2018 Completion and delivery of Construction elements

08-30-2018 Completion of all Testing

09-14-2018 Signoff on Application Testing results

09-15-2018 Beta Deployment

09-28-2018 Final Deployment

2.5 Contractor’s Work Effort RequirementThe Contractor’s full-time regular employees must perform at least 30% of the effort required to complete the Work. The Contractor may use its personnel or subcontractor personnel to meet the remaining 70% of the effort.

Section 3: Scope of Work

Refer to attached scope document (Project Scope Statement - Highway Infrastructure Management Ver-4.1) for complete Scope. The Contractor must meet all requirements of the SOW.Product/Solution

Automated processes for HIM data elements Data collection and import into new Database Data validation using provided criteria and present outliers for review and disposition Data validation using geo spatial reconciliation against LRS Meet MAP-21/FAST Act reporting requirements for HIM data elements Import of 20 years of historical data into new HIM database Creation of a file (exported from HIM database) that contains subset of data to be imported into the

Enterprise Data Warehouse (EDW) or development of ODBC integration with EDW. New Skid Testing request web-based form/tracker and generate Skid test reports

Business Owner/Stakeholder will: Business Owners/Stakeholders will be available for questions and answers throughout the length of the project Business Owners/Stakeholders to attend a bi-weekly status meeting to assist in issue resolution, risk

identification/analysis, risk mitigation, change management and impact analysis User Acceptance Testing (UAT) will be performed in coordination with business owners/stakeholders in the

HIM system test environment to validate deliverables perform as expected Business Owners/Stakeholders to develop communications and training manuals as needed and lead,

coordinate, and deliver needed training

ODOT Project Management Office will: Support needed for change control DoIT PMO to provide project management oversight Project status and reporting Follow all DoIT PMO SDLC processes and procedures

HPMS Reporting – The Contractor must:Replace legacy SAS programs and, to the extent possible, automate processing of HIM data elements for HPMS submittal.


Section 3: Scope of Work

Provide the refined data to HPMS team, so that, ODOT could perform HPMS submittal Weekly - Generate reports for HIM data elements

Theoretical Test distance vs Profiler test distance (Weekly) NextCheck2 Report – It generate the historical reports from past 20 years Statistics of the week Average Report

Meet MAP-21/FAST Act reporting requirements for HIM data elements Ensure HIM data elements are registered for the reporting LRS

Skid Test Management – The Contractor must: Perform evaluation of existing software products and/or systems within ODOT to determine if any can be

adapted or extended to support the requirements listed below. If so, then leverage that investment as best as possible.

If no existing system can support the requirements then create a new Skid Testing request web-based form/tracker and workflow system The form/tracker/workflow will allow user to request new skid test (Creating with a unique ID)

NOTE: User in this instance is an ODOT Employee (ie – this is not for public use) Create a new Database for storing, retrieving and to track skid test requests with Unique ID and results of

the completed skid tests Ability to view status of requested skid test Ability to submit a recurring skid test (each skid test would have a unique ID and reference the other skid

test that are part of the recurring request) Generate skid test reports Generate administrative reports relative the status of completed and pending skid test

For the HIM Database, provide solution to store, retrieve and perform backup of data. Current size estimates are: Only datasets that are part of the HIM data elements / HPMS Reporting are in scope Perform data conversion of existing “gold versions” of IRI date (previously submitted and accepted by

HPMS)o 20 Years of historical data averages of 20MB per year (in ASCII Text, Pipe (|) delimited file format.

Current year and going forward estimated to be 1 GB per year (includes all five of the data categories)

Section 3.1 – Assumptions and Constraints

Assumptions Detailed list of Local and State collection route for HPMS will be provided to HIM Administrators prior to data collection.

Linear vs. spatial reconciliation is done for the most recent year’s LRS only

HPMS Assumptions: IRI data must be collected on all NHS routes and IRI Data (Value_Numeric): Acceptable range is 30-400 When using last year’s/down direction or any method to fill the gaps the year should be

changed accordingly

Constraints Implementation must not disrupt already in-place data collection and business processes.


Section 3.2 – Glossary

GlossaryTerm Description

ODOT Ohio Department of Transportation

NLFID Network Linear Feature Identifier

PSI Pounds per Square Inch

Blog Beginning Log point

Elog Ending Log point

MAP21 Moving Ahead for Progress in the 21st Century Act (Federal NHS regulations)

FAST Fixing America's Surface Transportation Act (Federal NHS regulations)

ODBC Open DataBase Connection

DoIT Department of Information Technology (within ODOT)

PMO Project Management Office (within ODOT DoIT)

SDLC Software Development Lifecycle

GIS Global Information System

NHS National Highway System

FHA Federal Highway Administration

HIM Highway Infrastructure Management

HPMS Highway Performance Monitoring System

IRI International Roughness Index

JMF Job Mix Formula

LRS Linear Referencing System

SN Skid Number

TRC Transportation Research Center Inc.

EDW Enterprise Data Warehouse

Section 3.3 – Deliverable Descriptions

Deliverable Name Deliverable Description

Detailed Project Plan & Schedule Provide a detailed project plan and schedule of activities to complete the applications

Weekly Status Reports Provide weekly status report of activities for the current week and plans for the next week

Detailed Requirements document Provide a detailed requirements document to ensure all functionality has been included

Detailed Wire Frames Provide detailed mock ups / designs of screens for the application

Software Architecture Diagram (SAD) Provide a diagram of the architecture of the application

Delivery of Construction elements via bi- Demonstrate developed working code during bi-weekly sprint reviews


Section 3.3 – Deliverable Descriptions

Deliverable Name Deliverable Description

weekly sprints

Completion of system testing / signoff Provide documented results of testing including bugs and resolutions

Completion of UAT testing / signoff Agency

Train-the-Trainer to ODOT teams Provide train-the-trainer sessions for ODOT project teams.

Beta Deployment plan Develop a detailed beta deployment plan

Beta Deployment Lead and supervise technical deployments to beta sites.

Production DeploymentProvide support (onsite and remote) during ODOT Department of Information Technology deployment to production environment and desktops

Product support plan / Maintenance Develop a detailed product support plan for the application post deployment and provide maintenance services as needed

Section 3.4 – Deliverables

Deliverable Name Due Date(If applicable)

Payment Eligible?Yes/No Acceptance Criteria

DISCOVERY PHASE:Detailed Project Plan & Schedule No Approval from ODOT project

managers and ODOT Sponsor

Throughout Project:Weekly Status Reports No Approval from ODOT project

managers and ODOT Sponsor

DISCOVERY PHASE:Detailed Requirements document No Approval from the ODOT BA, ODOT

Sponsor and ODOT Technical Lead

DISCOVERY PHASE:Detailed Wire Frames No Approval from the ODOT PM and

Sponsor

DISCOVERY PHASE: Software Architecture Diagram (SAD) No Approval of the ODOT Technical lead

DEVELOPMENT PHASE: Delivery of Development elements via bi-weekly sprints

No Approval from the ODOT PM and Sponsor

DEVELOPMENT PHASE: Completion of system testing / signoff

Yes – at end of development signoff

Approval from the ODOT PM and Sponsor

TESTING PHASE: Completion of UAT testing / signoff Yes Approval from the ODOT PM and

Sponsor

TRAINING PHASE: Train-the-Trainer to ODOT / ODPS teams No Approval from the ODOT PM and

Sponsor

DEPLOYMENT PHASE: Beta Deployment plan No Approval from the ODOT PM and

Sponsor

DEPLOYMENT PHASE: Beta Deployment Yes Approval from the ODOT PM and

Sponsor

DEPLOYMENT PHASE: Yes Approval from the ODOT PM and

1 0 D B D O T - 1 8 - 0 3 - 0 0 1H i g h w a y I n f o r m a t i o n M a n a g e m e n t S y s t e m s

Section 3.4 – Deliverables

Deliverable Name Due Date(If applicable)

Payment Eligible?Yes/No Acceptance Criteria

Production Deployment Sponsor

POST DEPLOYMENT SUPPORT / MAINTENANCE PHASE: Product support plan (Beta Production Release)

Yes Approval from the ODOT PM and Sponsor

3.5 Restrictions on Data Location and Work

The Contractor must perform all work specified in the SOW Solicitation and keep all State data within the United States, and the State may reject any SOW Response that proposes to do any work or make State data available outside the United States.

The Contractor will comply with all state and federal laws regarding equal employment opportunity and fair labor and employment practices, including Ohio Revised Code Section 125.111 and all related Executive Orders.

Section 4: Deliverables Management

4.1 Submission/Format

PM Artifact/Project Work Product Submission Format

Project Plan & Schedule Via email Microsoft Project compatible format

Status Reports Via email Microsoft Office compatible

All Project documents are to be delivered electronically

Via email, as required Microsoft Office compatible

4.2 Reports and Meetings

The Contractor is required to provide the Agency contract manager with weekly written progress reports of this project. These are due to the Agency contract manager by the close of business on Thursday of each week throughout the life of the project.

The progress reports must cover all work performed and completed during the week for which the progress report is provided and must present the work to be performed during the subsequent week.

The progress report must identify any problems encountered or still outstanding with an explanation of the cause and resolution of the problem or how the problem will be resolved.

The Contractor will be responsible for conducting weekly status meetings with the Agency contract manager. The meetings will be held on Thursday at a time and place so designated by the Agency contract manager – unless revised by the Agency contract manager. The meetings can be in person or over the phone at the discretion of the Agency contract manager.

The Contractor will be responsible for conducting Sprint Review meetings every two weeks on a day to be defined. During the Sprint Review, working coding developed in the previous two weeks will be shown for Agency feedback.

E N T E R P R I S E I T C O N T R A C T I N G | D B I T S S O W S o l i c i t a t i o n D B D O T - 1 8 - 0 3 - 0 0 1 1 1

4.3 Period of Performance

The project is to be completed by September 28th, 2018. Performance is based on delivery and acceptance of each deliverable.

A validation that the application is working correctly will be to utilize the data collected during 2018 and processing through the HIM System as well as the current manual processing. A comparison of the results will be performed to determine any issues that will need to be resolved to be considered ready for Production.

4.4 Performance ExpectationsThe Contractor will support the ODOT IT Department following deployment as follows:

Support: The process of resolving software conflicts and usability problems, day to day issues that come in the application, and in supplying updates and patches for bugs and security holes in the program, documenting any changes in the source code.

Maintenance: The process of supporting the application and/or component after delivery to correct defects, maintain performance and/or maintain compatibility with other elements in the technical environment to ultimately ensure the existing system and/or business functionality continues to operate as already designed. The maintenance of the application and/or component is not constrained by the time and/or size of the effort.

The Contractor must provide communication for all functions via telephone, email, and internet support.

This section sets forth the performance specifications for the Service Level Agreements (SLA) to be established between the Contractor and State. Most individual service levels are linked to “Fee at Risk” due to the State to incent Contractor performance. The Service Levels contained herein are Service Levels for this SOW Solicitation. Both the State and the Contractor recognize and agree that Service Levels and performance specifications may be added or adjusted by mutual agreement during the term of the Contract as business, organizational objectives and technological changes permit or require.

The Contractor agrees that 10% of the not to exceed fixed price for the SOW deliverables will be at risk (“Fee at Risk”). The Fee at Risk will be calculated as follows:

Total Not to Exceed Fixed Price (NTEFP) of the SOW Deliverables

x 10 % (.10) = Total Fee at Risk for the SOW

Furthermore, in order to apply the Fee at Risk, the following monthly calculation will be used:

Monthly Fee at Risk =Total Fee at Risk for the SOW

Term of the SOW in months

The Contractor will be assessed for each SLA failure and the “Performance Credit” will not exceed the monthly Fee at Risk for that period. The Performance Credit is the amount due to the State for the failure of SLAs. For SLAs measured on a quarterly basis, the monthly fee at risk applies and is cumulative.

On a quarterly basis, there will be a “true-up” at which time the total amount of the Performance Credit will be calculated


(the “Net Amount”), and such Net Amount may be off set against any fees owed by the State to the Contractor, unless the State requests a payment in the amount of the Performance Credit.

The Contractor will not be liable for any failed SLA caused by circumstances beyond its control, and that could not be avoided or mitigated through the exercise of prudence and ordinary care, provided that the Contractor promptly, notifies the State in writing and takes all steps necessary to minimize the effect of such circumstances and resumes its performance of the Services in accordance with the SLAs as soon as reasonably possible.

To further clarify, the Performance Credits available to the State will not constitute the State’s exclusive remedy to resolving issues related to the Contractor’s performance. In addition, if the Contractor fails multiple service levels during a reporting period or demonstrates a pattern of failing a specific service level throughout the SOW, then the Contractor may be required, at the State’s discretion, to implement a State-approved corrective action plan to address the failed performance.

SLAs will commence when the SOW is initiated.

Monthly Service Level Report. On a monthly basis, the Contractor must provide a written report (the “Monthly Service Level Report”) to the State which includes the following information:

Identification and description of each failed SLA caused by circumstances beyond the Contractor’s control and that could not be avoided or mitigated through the exercise of prudence and ordinary care during the applicable month;

The Contractor’s quantitative performance for each SLA; The amount of any monthly performance credit for each SLA; The year-to-date total performance credit balance for each SLA and all the SLAs; Upon state request, a “Root-Cause Analysis” and corrective action plan with respect to any SLA where the

Individual SLA was failed during the preceding month; and Trend or statistical analysis with respect to each SLA as requested by the State.

The Monthly Service Level Report will be due no later than the tenth (10th) day of the following month.

SLA Name Performance Evaluated

Delivery Date Service Level The Delivery Date Service Level will measure the percentage of SOW tasks, activities, deliverables, milestones and events assigned specific completion dates in the applicable SOW and/or SOW project plan that are achieved on time. The State and the Contractor will agree to a project plan at the commencement of the SOW and the Contractor will maintain the project plan as agreed to throughout the life of the SOW. The parties may agree to re-baseline the project plan throughout the life of the SOW. Due to the overlapping nature of tasks, activities, deliverables, milestones and events a measurement period of one calendar month will be established to serve as the basis for the measurement window. The Contractor will count all tasks, activities, deliverables, milestones and events to be completed during the measurement window and their corresponding delivery dates in the applicable SOW and/or SOW project plan. This service level will commence upon SOW initiation and will prevail until SOW completion.

Compliance with delivery date isexpected to be greater than 85%


This SLA is calculated as follows: “% Compliance with delivery dates” equals “(Total dates in period – Total dates missed)” divided by “Total dates in period”

Scheduled Reports Service Level

The Scheduled Reports Service Level will measure the receipt of Reports within SLA schedule or other established time frames.

This SLA is calculated as follows: “Scheduled Reporting Performance” equals “(Total Number of Reports Required – Total Reports Missed/Missing)” divided by “Total Number of Reports Required”

System Test Execution Exit Quality Rate

The System Test Execution Exit Quality Rate will, prior to UAT, be determined using the results of Contractor generated pre-test strategy, executed testing cases including functionality, performance, integration, interfaces, operational suitability and other test coverage items comprising a thorough Contractor executed system testing effort. Regression Testing must be performed as necessary. “System Test Execution Exit Quality Rate” means the inventory of all test cases performed in conjunction with Contractor system testing, or testing otherwise preceding the State’s User Acceptance Testing efforts, presentation of resultant test performance inclusive of identified errors or issues (by priority), impact areas and overall testing results to the State otherwise referred to as “Testing Results”.

This Service Level begins upon Contractor presentation of the aforementioned Testing Results to the State prior to the State conducting UAT. The initial service level shown for this SLA will be 90.0%, exclusive of Critical and High defects (which must be resolved prior to presentation to the State) and will be validated during an initial measurement period. The initial and subsequent measurement periods will be as mutually agreed by the Parties. Following the initial measurement period, and as a result of any production use the Service Level will be adjusted to 95%.

Compliance with the System Test ExecutionExit Quality Rate is expected to be greaterthan or equal to 90% prior to UAT and greater than or equal to 95% in production

This SLA is calculated as follows: “System Test Quality/Exit Rate” equals “Total Test Cases Passing Contractor System Test Efforts” divided by “Total Executed during System Testing Effort”

4.5 State Staffing Plan

Staff/Stakeholder Name Project Role Percent Allocated

Allen Skaggs ODOT Project Manager 20%

Rashmi Somani ODOT Business Analyst 10%

TBD ODOT Technical Lead 10%


Staff/Stakeholder Name Project Role Percent Allocated

Brain Schleppi ODOT Project Sponsor 10%

Section 5: SOW Response Submission Requirements

5.1 Response Format, Content Requirements

An identifiable tab sheet must precede each section of a Proposal, and each Proposal must follow the format outlined below. All pages, except pre-printed technical inserts, must be sequentially numbered. Each Proposal must contain the following:

1. Cover Letter2. Contractor Experience Requirements3. Subcontractors Documentation4. Project Team Qualifications5. Assumptions6. Payment Address7. Staffing plan, personnel resumes, time commitment, organizational chart8. Contingency Plan9. Project Plan10. Project Schedule (WBS using MS Project or compatible)11. Communication Plan12. Fee Structure including Estimated Work Effort for each Task/Deliverable13. Rate Card14. Supplement 1 (Security) Acceptance

Include the following:1. Cover Letter

A. Must be in the form of a standard business letter;B. Must be signed by an individual authorized to legally bind the Contractor;C. Must include a statement regarding the Contractor’s legal structure (e.g. an Ohio corporation), Federal tax identification number, and principal place of business; please list any Ohio locations or branches;D. Must include a list of the people who prepared the Proposal, including their titles; andE. Must include the name, address, e-mail, phone number, and fax number of a contact person who has the authority to answer questions regarding the Proposal.

2. Contractors Experience RequirementsA. Each proposal must include a brief executive summary of the services the Contractor proposes to

provide and one representative sample of previously completed projects as it relates to this proposal (e.g. detailed requirements documents, analysis). See the evaluation criteria for additional required information;

B. Each proposal must describe the Contractor’s experience, capability, and capacity to provide application development. Provide specific detailed information demonstrating experience similar in nature to the type of work described in this SOW for each of the resources identified in Section 5.2.


C. Mandatory Requirements:

The Contractor must have performed similar work for at least 2 projects within the past 5 years and must demonstrate they meet this requirement by including a list of at least three references from current or past customers. The list must contain current contact persons and contact information for work engagements. Contractors not meeting this requirement to the satisfaction of ODOT may be disqualified. The proposal must contain a brief summary of each of those work engagements, how they are similar in size, scope, and purpose, to the project described in this SOW solicitation document, and the level of success attained.

3. Subcontractor DocumentationFor each proposed subcontractor, the Contractor must attach a letter from the subcontractor, signed by someone authorized to legally bind the subcontractor, with the following included in the letter:

A. The subcontractor’s legal status, federal tax identification number, D-U-N-S number if applicable, and principal place of business address;

B. The name, phone number, fax number, email address, and mailing address of a person who is authorized to legally bind the subcontractor to contractual obligations;

C. A description of the work the subcontractor will do and one representative sample of previously completed projects as it relates to this SOW (e.g. detailed requirements document, analysis, statement of work. See the evaluation criteria for additional required information;

D. Must describe the subcontractor’s experience, capability, and capacity to provide application development. Provide specific detailed information demonstrating experience similar in nature to the type of work described in this SOW from each of the resources identified in Section 5.2;

E. A commitment to do the work if the Contractor is selected; andF. A statement that the subcontractor has read and understood the RFP and will comply with the

requirements of the RFP.

4. Project Team Qualifications Provide an outline of the project team and a brief description on the approach for the project. At a minimum, the proposal must contain:

A. Proposed project manager and team members resume or curriculum vitae demonstrating that the team has the necessary professional experience and background.

B. Three references where the proposed project manager has managed a similar project onsite or remotely.

C. Team members must have experience analyzing business processes that integrate data from multiple sources.

D. Minimum Project Manager Qualifications: i. Bachelor’s Degree in Information Technology or related field or equivalent work experience. ii. Five (5) years’ experience as a project manager developing project plans, defining schedules,

developing project approach, budgeting, monitoring and project change management processes. E. Minimum Programmer / Developer Qualifications:

i. Four-year college degree or equivalent technical study with advanced study preferred.ii. Five years relevant experience over the last 10 years:

a) ASP.NET MVC 4.0, C#b) Object Oriented Java Scriptc) CSS d) Log4Nete) Spring.NETf) Proficient in the standard SQL (Structured Query Language): syntax used by any one of

the following database vendors (Oracle and MS SQL Server)


5. Assumptions: The Contractor must list all assumptions the Contractor made in preparing the Proposal. If any assumption is unacceptable to the State, the State may at its sole discretion request that the Contractor remove the assumption or choose to reject the Proposal. No assumptions may be included regarding the outcomes of negotiation, terms and conditions, or requirements. Assumptions should be provided as part of the Contractor response as a stand-alone response section that is inclusive of all assumptions with reference(s) to the section(s) of the RFP that the assumption is applicable to. The Contractor should not include assumptions elsewhere in their response.

6. Payment Address: The Contractor must give the address to which the State should send payments under the Contract.

7. Staffing plan, personnel resumes, time commitment, organizational chartIdentify Contractor and subcontractor staff and time commitment. Identify hourly rates for personnel, as applicable. Include Contractor and subcontractor resumes for each resource identified and organizational chart for entire team.

Resource Name Role Contractor or Sub-contractor

Time commitment Hourly Rate

8. Contingency PlanDescribe contingency planning requirements, as applicable.

9. Project PlanIdentify and describe the plan to produce effective documents and complete the deliverable requirements. Describe the primary tasks, how long each task will take, and when each task will be completed in order to meet the final deadline.

10. Project Schedule (WBS using MS Project or compatible)Describe the Project Schedule including planning, planned vs. actuals for monitoring performance, including milestones, and time for writing, editing and revising. Using MS Project or compatible, create a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project with each descending level representing an increasingly detailed definition of the project work.

11. Communication Plan Strong listening skills, the ability to ask appropriate questions, and follow-up questions will be required to capture the information necessary to complete the deliverable requirements. Describe the methods to be used to gather and store various types of information and to disseminate the information, updates, and corrections to previously distributed material. Identify to whom the information will flow and what methods will be used for the distribution. Include format, content, level of detail, and conventions to be used. Provide methods for accessing information between scheduled communications.

12. Fee Structure including Estimated Work Effort for each Task/Deliverable


Deliverable NameTotal Estimated

Work Effort (Hours)

Not-to-Exceed Fixed Price for

Deliverable

DISCOVERY PHASE: Detailed Project Plan & Schedule n/a

Throughout Project: Weekly Status Reports n/a

DISCOVERY PHASE: Detailed Requirements document n/a

DISCOVERY PHASE: Detailed Wire Frames n/a

DISCOVERY PHASE: Software Architecture Diagram (SAD) n/a

DEVELOPMENT PHASE: Delivery of Development elements via bi-weekly sprints n/a

DEVELOPMENT PHASE: Completion of system testing / signoff

TESTING PHASE: Completion of UAT testing / signoff

TRAINING PHASE: Train-the-Trainer to ODOT / ODPS teams n/a

DEPLOYMENT PHASE: Beta Deployment plan n/a

DEPLOYMENT PHASE: Beta Deployment

DEPLOYMENT PHASE: Production Deployment

POST DEPLOYMENT SUPPORT / MAINT. PHASE: Product support plan (Beta Production Release)

Total Cost for all Deliverables

Post Deployment – Optional Year 1 Maintenance and Enhancements500 hours of Developer resource time/effort

+150 hours of Business Analyst resource time/effort

*Rates above cannot exceed those stated on Rate Card (discounts may be applied)Only actual hours used may be billed

Post Deployment – Optional Year 2 Maintenance and Enhancements500 hours of Developer resource time/effort

+150 hours of Business Analyst resource time/effort

*Rates above cannot exceed those stated on Rate Card (discounts may be applied)Only actual hours used may be billed

Total Costs (all Deliverables and Optional Post Deployment)


13. Rate CardThe primary purpose of obtaining a Rate Card is to establish baseline hourly rates in the event that change orders are necessary. The DBITS contract is not intended to be used for hourly based time and materials work. Contractors must submit a Rate Card that includes hourly rates for all services the Contractor offers, including but not limited to those listed in this Solicitation. Enter the Rate Card information in this section.

Position/Title Rate/Hr.

14. Supplement 1 (Security) AcceptanceThe Contractor must provide a statement agreeing to and accepting Supplement 1 (Security Supplement) in its entirety.

Section 6: SOW Evaluation Criteria

Mandatory Requirement: Accept/Reject

The Contractor must have performed similar work for at least 2 projects within the past 5 years and must demonstrate they meet this requirement by including a list of at least three references from current or past customers. The list must contain current contact persons and contact information for work engagements. Contractors not meeting this requirement to the satisfaction of ODOT may be disqualified. The proposal must contain a brief summary of each of those work engagements, how they are similar in size, scope, and purpose, to the project described in this SOW solicitation document, and the level of success attained.

Scored Requirements WeightDoes Not

MeetMeet Exceed

s

Contractor or subcontractor summary shows company experience in application development using ESRI/GIS with a multitude of data inputs 7 0 5 7

Contractor or subcontractor summary must describe the approach for developing the application/interface. 5 0 5 7

Contractor’s staffing plan 3 0 5 7Contractor or subcontractor summary shows evidence that the Project Team Qualifications are fully met 3 0 5 7

Contractor or subcontractor summary shows evidence that all items for subcontractor documentation are fully met 3 0 5 7

Contractor or subcontractor summary shows evidence that all items in the Contractors Experience Requirements have been fully met 3 0 5 7

Contractor’s project plan 3 0 5 7Contractor summary shows ability and availability to complete the project in the available timeline based on the proposed project plan 5 0 5 7

Price Performance Formula. The evaluation team will rate the Proposals that meet the Mandatory Requirements based on the following criteria and respective weights.


Criteria PercentageTechnical Proposal 70%

Cost Summary 30%

To ensure the scoring ratio is maintained, the State will use the following formulas to adjust the points awarded to each offeror. The offeror with the highest point total for the Technical Proposal will receive 700 points. The remaining offerors will receive a percentage of the maximum points available based upon the following formula:

Technical Proposal Points = (Offeror’s Technical Proposal Points/Highest Number of Technical Proposal Points Obtained) x 700

The offeror with the lowest proposed total cost for evaluation purposes will receive 300 points. The remaining offerors will receive a percentage of the maximum cost points available based upon the following formula:

Cost Summary Points = (Lowest Total Cost for Evaluation Purposes/Offeror’s Total Cost for Evaluation Purposes) x 300

Total Points Score: The total points score is calculated using the following formula:Total Points = Technical Proposal Points + Cost Summary Points

Section 7: SOW Solicitation Calendar of Events

Firm DatesSOW Solicitation Released to Contractors 02/21/2018Inquiry Period Begins 02/21/2018Inquiry Period Ends 03/09/2018 @ 8:00 AM ESTProposal Response Due Date 03/14/2018 @ 1:00 PM EST

Anticipated DatesEstimated Date for Selection of Awarded Contractor 03/07/2018Estimated Commencement Date of Work Late March 2018

SECTION 8: Inquiry Process

Contractors may make inquiries regarding this SOW Solicitation anytime during the inquiry period listed in the Calendar of Events. To make an inquiry, Contractors must use the following process:

Access the State’s Procurement Website at http://procure.ohio.gov/;

From the Navigation Bar on the right select “Bid Opportunities Search”;

Enter the ODX Solicitation ID number found on the first page of this SOW Solicitation in the “Document/Bid Number:” box;

Click the “Search” button;

Click on the Document/Bid Number to go to the document information page,

On the document information page, click the “Submit Inquiry” button;


On the document inquiry page, complete the required “Personal Information” section by providing:

o First and last name of the Contractor’s representative who is responsible for the inquiry,

o Name of the Contractor,

o Representative’s business phone number, and

o Representative’s email address;

Type the inquiry in the space provided including:

o A reference to the relevant part of this SOW Solicitation,

o The heading for the provision under question, and

o The page number of the SOW Solicitation where the provision can be found; and

Click the “Submit” button.

A Contractor submitting an inquiry will receive an acknowledgement that the State has received the inquiry as well as an email acknowledging receipt. The Contractor will not receive a personalized response to the question nor notification when the State has answered the question.

Contractors may view inquiries and responses on the State’s Procurement Website by using the same instructions described above and by clicking the “View Q & A” button on the document information page.

The State usually responds to all inquiries within three business days of receipt, excluding weekends and State holidays. But the State will not respond to any inquiries received after 8:00 a.m. on the inquiry end date.

Section 9: Submission Instructions & Location

Each Contractor must submit four (4) complete, sealed and signed copies of its Proposal Response and each submission must be clearly marked “ODOT - Highway Information Management System” on the outside of its package along with Contractor’s name.

A single electronic copy of the complete Proposal Response must also be submitted with the printed Proposal Responses. Electronic submissions should be on a CD, DVD or USB memory stick.

Each proposal must be organized in the same format as described in Section 5. Any material deviation from the format outlined in Section 5 may result in a rejection of the non-conforming proposal. Each proposal must contain an identifiable tab sheet preceding each section of the proposal. Proposal Response should be good for a minimum of 60 days.

The State will not be liable for any costs incurred by any Contractor in responding to this SOW Solicitation, even if the State does not award a contract through this process. The State may decide not to award a contract at the State’s discretion. The State may reject late submissions regardless of the cause for the delay. The State may also reject any submissions that it believes is not in its interest to accept and may decide not to do business with any of the Contractors responding to this SOW Solicitation.

Proposal Responses MUST be submitted to the State Agency’s Procurement Representative:Melissa AnverseOhio Department of TransportationDoIT PMO – 4th Floor1980 West Broad StreetColumbus, OH

Proprietary information


All Proposal Responses and other material submitted will become the property of the State and may be returned only at the State's option. Proprietary information should not be included in a Proposal Response or supporting materials because the State will have the right to use any materials or ideas submitted in any quotation without compensation to the Contractor. Additionally, all Proposal Response submissions will be open to the public after the contract has been awarded.The State may reject any Proposal if the Contractor takes exception to the terms and conditions of the Contract.

Waiver of DefectsThe State has the right to waive any defects in any quotation or in the submission process followed by a Contractor. But the State will only do so if it believes that is in the State's interest and will not cause any material unfairness to other Contractors.

Rejection of SubmissionsThe State may reject any submissions that is not in the required format, does not address all the requirements of this SOW Solicitation, or that the State believes is excessive in price or otherwise not in its interest to consider or to accept. The State will reject any responses from companies not pre-qualified in the Technology Category associated with this SOW Solicitation. In addition, the State may cancel this SOW Solicitation, reject all the submissions, and seek to do the work through a new SOW Solicitation or other means.

SOW Solicitation Attachments/Supplements

All of the following Attachments and Supplement are available for download on the State of Ohio Procurement Website on the details page for this solicitation.

Attachment/Supplement - Name/TitleProject Scope Statement – HIM & Skid Test Ver 4.1Infrastructure Management Document Final v4.0HIM High Level ProcessProfiler Sample Reports (with dummy data)HIM BRS v1.70 (Business Requirements Specifications)HIM Data ModelODOT Web Application ArchitectureMock up Skid Test Request FormSupplement 1 State Architecture Security Privacy and Data Handling


Documents

NOTICE - Web viewODOT Web Application ... perform further validation through Java Program and the java ... Proposed project manager and team members resume or curriculum vitae