An Alphabetical Listing of Contractors Pre-Qualified to Participate in This Opportunity Follows

An Alphabetical Listing of Contractors Pre-Qualified to Participate in This Opportunity Follows

NOTICE

This opportunity is being released to ODJFS – Professional Technical Services pre-qualified contractors as a result of Open Market RFP #0A1183. The terms and conditions of the #0A1183 contract apply to this task order solicitation.

ONLY Contractors pre-qualified in the 2.0 OWCMS Ecosystem Technology 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:

CGI Technology Inc.
CMA Consulting
Conduent State & Local Solutions
Strategic Systems Inc.
Symbiosys Solutions Inc.

Pre-qualified offerors are expected to respond to a majority of the Solicitations received during the course of a fiscal year. A no-bid response should provide an explanation to why they are not responding to the Solicitation.

Task OrderPTJFS-18-02-007

WIET (REISSUE)

DATEISSUED:March 26, 2018

TheOhioDepartmentofJob and Family Servicesisrequesting proposalsfor work leveraging Contract 0A1183Professional Technical Services: System Operations and Maintenance for Employment Services Systems:

PROJECTS:

Workforce Inventory of Education and Training (WIET) Add Appeal Process & WIET Enhancements

POST DATE: March 26, 2018

INQUIRY PERIOD BEGINS:March 26, 2018

INQUIRY PERIOD ENDS:April 7, 2018 at 8:00 a.m. (Columbus, Ohio time)

PROPOSAL DUE DATE:April 16, 2018at 1:00 p.m. (Columbus, Ohio time)

OPENINGLOCATION:DepartmentofJob and Family Services

Office of Contracts and Acquisitions

30 East Broad Street, 31st Floor

Columbus,Ohio43215

Purpose.The purpose of this Task Ordersolicitation is to provide The Ohio Department of Job and Family Services with a prequalified Contractor, herein after referred to as the “Contractor”, to provide services from the OWCMS Ecosystem Technology Categoryin the Professional Technical Services Contract. The Contractormust 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 1, Scope of Work.

ORGANIZATION:ThisTask Order solicitationconsistsofsix (6) parts, two (2) attachments and two (2) supplements. Pleaseverifythatyouhaveacompletecopy.

Parts:

Part OneScope of Work

Part TwoStaffing Plan and Time Commitment

Part ThreeODJFS Vendor Support

Part FourTask Order Evaluation Criteria

Part FiveRequirements for Proposals

Attachments:

Attachment AOWCMS Development Task Order Standards

Attachment BSystem Test Standards for Task Orders

Supplements:

Supplement1WIET Appeal Requirements

Supplement 2WIET Enhancements Requirements

Table of Contents

1.Scope of Work

1.1.WIET Add Appeal Process & WIET Enhancements

1.2Standards

1.2.1.Transition applications to work with supported WebSphere version

1.3.Deliverables

1.3.1.Project Planning and Commencement of Work

1.3.2.Sprints

1.3.2.1.Required Artifacts

1.3.2.2.Other Artifacts

1.3.3.Sprint 0

1.4.Required Phase Gates

1.4.1.User Acceptance Testing (UAT)

1.4.2.Design Review and Approval

1.4.3.Standards Compliance Review

1.4.4.Project Value Review

1.5.Code Merge

1.6.Deployments

2.Staffing Plan and Time Commitment

3.ODJFS Vendor Support

3.1ODJFS Program Area Support

3.2Project Management Support

3.3Development Support

3.4Testing Support

3.5Colocation, Remote Access, PC and Development Tool Support

3.6Document Review and Approval

4.Task Order Evaluation Criteria

5.RequirementsforProposals

5.1 Inquiry Process

5.2ProposalInstructions

5.3ProposalFormat

5.3.1 Tab A - Cover Letter

5.3.2 Tab B - SubcontractorLetters

5.3.3 Tab C – Proposed Solution

5.3.4 Tab E - ODJFS SupportExpectations

5.3.6 Tab F - Assumptions

5.3.7 Cost Proposal - Sealed separately

1.Scope of Work

The scope of work to be completed under this Task Order includes completion of work on the Workforce Inventory of Education and Training (WIET) Add Appeal Process and Enhancements Project. This must be completed no later than December 31, 2018.

The approach to the completion of work will be to develop final requirements and implement new and revised software using agile processes to meet the business objectives for each project. The project’s requirements, as shown in the supplements, provide more details on the overall scope of work within the Task Order. The proposed cost and number of sprints must cover the work effort required to meet the requirements contained within Supplements One and Two.

Software Development Life Cycle (SDLC)

The desire is that the work in this Task Order will be accomplished using agile processes. The Offeror must propose an agile methodology that addresses the full life cycle from scope management to user acceptance testing and implement the projects described in this document.

A short description of each project with the primary objectives of the project follows in this section.

1.1.WIET Add Appeal Process & WIET Enhancements

The Workforce Inventory of Education and Training (WIET) is an online list of approved state and local training Providers. Training Providers on this list are eligible to receive Workforce Innovation and Opportunity Act (WIOA) and Temporary Assistance for Needy Families (TANF) funds to instruct program participants.

The goal of this project is to provide enhancements to the WIET system.

Objectives

If an institution or training provider has been denied as an eligible training provider, has lost eligibility, or has been terminated from WIET, the institution or training provider may appeal the denial or termination. The Ohio Department of Job and Family Services (ODJFS) needs to comply with policy requirements regarding notifying Providers of their right to appeal, pursuant to the WIOA PL 16-02 (Eligible Training Providers). For efficiency of staff time, the system would allow WIET state administrators users to track appeals based on the Provider or program being appealed. This assists with resolution and supports metrics for appeal processing and auditing.

The WIET application must be amended so that error messages match data conditions. The application must also be amended to reduce manual intervention in approving providers, programs, and their renewals. Finally, the application must also be amended to remove other assorted conditions that have caused users frustration, including aspects that may be enhancements or defect resolution.

The final detailed requirements will be developed and implemented during the project using agile processes. The project’s current written requirements, as shown in requirements supplements, provide more details on the overall scope of the project.

1.2Standards

During the life of the Task Order, in addition to the standards defined in DAS RFP 0A1183, the standards as shown in the following attachmentsmust be followed when specific activities covered by the standards have been scheduled into sprints via the sprint planning process. During the project the Contractor may propose alternative approaches to completion of work. Any changes to these standards will be documented and approved through project change control.

  1. Attachment A: Development Task Order Standards
  2. Attachment B:System Test Standards for Task Orders

1.2.1.Transition applications to work with supported WebSphere version

During the life of the Task Order, the application’s technology platform will be upgraded to WebSphere version 8.5.5/Java 1.7 by the State. The Offerormust complete tasks required to ensurethe application(s) works onthe new platform. The cut-over to the new platform will be scheduled to occur within one of the sprint releases, to be determined by mutual agreement after the start of the project. This must be completed no later than December 31, 2018. The proposed plan must include the tasks and timeline required to complete work to transition the application to Java version 7 and WebSphere version 8.5.5. The work plan proposed by the Offerorshould include following activities and other activities the Offerordeems required to complete the coding and testing of this scope of work.

  1. Configure the Developer environment, convert the 9 OWCMS Applications from WAS 7.0.0.41 to WAS 8.5.5, and ensure the applications work in the new environment and support TLS v1.2. The Developer environment includeslocal RAD Workspace and local WebSphere Application Server (v8.5.5). The transition includes, but not limited to,following:
  2. User interface components/frameworks e.g.: JSP, JSF
  3. Business logic and data access code e.g.:EJBs, Hibernate and JPAs
  4. Optimize Log Management using ODJFS standard log Framework, remove log statements that write PI / sensitive data to eliminate security and audit concerns
  5. To ensure the applications work in the upgraded WAS environment, the vendor must:
  6. Rectify any code compatibility issues.
  7. Perform complete system test planning (including the creation of test cases) for functional, regression and performance tests as outlined in the System Testing Standards.
  8. Perform Test execution as outlined in the System Testing standards and using automatic build tools as outlined below.
  9. Develop automatic builds using agency’s Continuous Integration tool -Jenkins.
  10. Provide documentation regarding the new build process.
  11. Provide knowledge transfer regarding the new build process to designated ODJFS staff.
  12. Provide insight into policies and standards utilized in this process.
  13. Modify dependency management to utilize agency’s centralized Nexus Repository Manager with Apache Maven for 11 applications and batch interfaces.
  14. Provide documentation regarding utilizing the Nexus Repository Manager.
  15. Provide knowledge transfer regarding using the Nexus Repository Manager to designated ODJFS staff.
  16. Update Batch interfaces and route 11 Services calls spread across 11 applications and batch interfaces through ESB for better API Management.
  17. Provide documentation regarding using ESB for batch and service call interfaces.
  18. Provide knowledge transfer regarding using ESB for batch and service call interfaces to designated ODJFS staff.

1.3.Deliverables

1.3.1.Project Planning and Commencement of Work

The Contractor must start work on a comprehensive Project Management Plan no later than five(5)business days following the issuance of a purchase order with a kick-off between ODJFS and the Contractor’s representative(s). The Project Management Plan must contain at least: scope, schedule, communication, resource, risk and issue management.

The named key resources provided in the Contractor’s proposal must begin work on the Project within fifteen (15)business days of the issuance of a purchase order.

The Contractorwill develop and provide an overall Test Management Plan for the project that describes the approach to be followed for functional, regression and performance tests. The Test Management Plan is expected to be completed before the start of Sprint 1.

This work and related activities are expected to be completed within thirty (30)calendar days of the issuance of a purchase order.

1.3.2.Sprints

The project will be comprised of development iterations (sprints) that are equally divided across the duration of the project. Sprint work is to begin immediately upon submission of the Sprint 1 certification letter and end after implementation of the work identified in the Scope of Work Section of this Task Order.

1.3.2.1.Required Artifacts

Each sprint delivered must include at least the following artifacts:

  1. Updated groomed product backlog and sprint planning documents;
  2. Updated and approved requirement documentation;
  3. Updated status report in MS word including project risks, issues, and change orders;
  4. Updated burn charts representing metrics for work completed and estimated work remaining vs. time remaining;
  5. Sprint Show and Tell Presentation;
  6. Sprint Retrospective Report; and
  7. One or more deliverables from the “Other Artifacts” listed below as appropriate to the planned work.

1.3.2.2.Other Artifacts

The following artifacts are to be providedby the Contractor at the completion of each sprint when applicable. Sprint planning will determine the exact composition of work for each sprint.

Development Artifacts

  1. Approved detailed design and technical design documents;
  2. Approved wireframes/screen mockups/system documentation;
  3. Completed design andcode walkthrough templates;
  4. Tested application code checked into Dimensions;
  5. Approved database scripts (Data Definition Language (DDL), Data Manipulation Language (DML)) checked into dimensions;
  6. Scheduling Modification Request (SMR) for new and revised batch jobs; and
  7. Build Files (.EAR files, .JAR files, etc.)deployed to appropriate development and testing environments.

Testing Artifacts

  1. Approved project requirements are to be stored in HP Application Lifecycle Management (ALM);
  2. Approved test plan that meets system test standards;
  3. Created or updated automated test scripts in HP UFT (Unified Functional Testing);
  4. Presentation for system test knowledge walkthrough; and
  5. System test results documentation as defined in the Testing Standards.

1.3.3.Sprint 0

The Offeror’s proposal must include the activities and a schedule that it will execute during sprint 0 period to ensure successful start of the development work and completion of the project objectives described in this document. The Offeror’s proposal mustinclude specific details on the expectations the Offerorhas of ODJFS staff and resources during this period. Sprint 0 is expected to begin within twenty-one (21)calendar days of the issuance of a purchase order.

  1. The Contractorwill create the initial prioritized product backlog based on requirements documents provided with this document and additional Contractor-facilitated planning sessions completed during the sprint.
  2. The Contractorwill provide orientationto ODJFS agile team members and other key ODJFS project stakeholders on the agile processes to be used. The orientationmustinclude information on the process including roles and responsibilities.
  3. The Contractorwill provide a certification letter that all prerequisites to start Sprint 1 are complete. Prerequisites are:
  4. Development and Testing Environments must be prepared and ready for use;
  5. All system and tool access must be available to sprint team members
  6. Contractorand ODJFS agile team members must be available to start work.
  7. Approval of the Test Management Plan
  8. Approval of the Project Management Plan
  9. Other activities as defined by the Contractor in the proposed SDLC

1.4.Required Phase Gates

1.4.1.User Acceptance Testing (UAT)

The ODJFSProduct Owner is expected to accept the system changes at the conclusion of each sprint. Acceptance is required before the next sprint can start.

1.4.2.Design Review and Approval

Before coding new application components or making database changes, the Contractormust submit new or updated design documents using the supplied template, or approved alternative, for review and approval by the ODJFS Development Lead and/or Application Database Analyst (DBA). Modifications to existing functions are expected to conform to the system’s existing design constructs. ODJFS will review and approve the design documents or request changes within each sprint.

1.4.3.Standards Compliance Review

The Contractor is responsible for ensuring its staff comply with the published standards attached to this document. ODJFS will conduct a formal code review on a sampling of code delivered during selected sprints to ensure compliance with the standards identified in Attachment A. Sprint planning will identify the sprints in which the code reviews will occur. Code delivered in the current or a prior sprint will be selected for the review. For formal code reviews the Contractormustprovide a list of files changed/created for each piece of functionality using the code review template document.The Contractormust complete a walk through with the ODJFS Development Lead. The ODJFS Development Lead will review completed code to ensure compliance with coding guidelines, coding standards and naming standards. ODJFS may also conduct informal or Ad Hoc standards compliance reviews by review of checked in code.ODJFS may leverage automated tools for standards compliance reviews.

The Contractormust develop and maintain a test plan that complies with ODJFS System Test Standard(Attachment B). ODJFSSystem Test Lead will validate test scripts developed along with Ad Hoc standards reviews to ensure compliance with the standards. For example,

  1. Attaching test documents to the Customer Service Request (CSR)/Work Request (WR)/Incident Report (IR) in Dimensions
  2. Updating CSRs, WRs and IRs with test comments
  3. Generating test plan and execution documents from HP Application Lifecycle Management (ALM) Tool
  4. Daily documentation of defects related to the test set in HP ALM

At the conclusion of the review, the Contractorwill be provided with specific corrective action for items found to not be in compliance with standards. The Contractormust develop and present ODJFS with a corrective action plan to address the standards issues that do not impact the current and future planned sprints. On approval, the Contractorwill complete the corrective action plan.

1.4.4.Project Value Review

The Contractor’s representative must attend regular meetings, the schedule for which will be identified in the Project Management Plan, with the ODJFS project manager and key stakeholders. The Contractor’s representative must present project risks, issues, sprint retrospective reports and progress of delivered work against planed work (Burn charts). The periodic value review will assess the actual output of the team(s)vs. the planned output of the team(s). ODJFS and Contractor’srepresentative will work to resolve obstacles to value delivery and address project issues and risks as needed. The failure to consistently meet the objectives of the planned sprints may result in suspension of work until issues related to the value delivery can be resolved.

1.5.Code Merge

When the code from a sprint is scheduled for deployment to production,it is the responsibility of the Contractorto merge the project code back into the main production branch, as directed by ODJFS prior to final system testing and User Acceptance Testing (UAT) for the sprint. The Contractormust compare with the appropriate repository version before check-in and complete any code update and merge activities as necessary. Code overlap among simultaneous projects need to be coordinated before merge.

1.6.Deployments

The Contractormust deploy the code to system test and UAT Environments based on an agreed to schedule with the ODJFS and in accordance with deployment standards. Deployments that are required outside of the agreed to schedule must be approved by the ODJFS Product Owner and ODJFS designated Test Lead. ODJFS staff will coordinate deployments to production.

2.Staffing Plan and Time Commitment

The Offeror’s Staffing Plan and Time Commitment response must contain the following information: