overview - procure.ohio.gov · web viewthese offerors will be invited to participate in a team...

Table of Contents

1. OVERVIEW.......................................................................................................................................................2

1.1 RFP Scope.................................................................................................................21.2 The RFP Methodology.............................................................................................21.3 This RFP.....................................................................................................................3System and Project Management Requirements (Table A)..........................................4

2. DEVELOPMENT AND SUPPORT................................................................................................................4

3. HARDWARE AND SOFTWARE....................................................................................................................4

4. ARCHITECTURE.............................................................................................................................................4

5. PERSONNEL....................................................................................................................................................4

5.1 Location.....................................................................................................................45.2 Final Say...................................................................................................................45.3 Non-Disclosure..........................................................................................................45.4 Management..............................................................................................................5

6. OTHER.............................................................................................................................................................5

6.1 State-Owned Data....................................................................................................56.2 State-Owned Capabilities........................................................................................56.3 Automated Conversion Methods:...........................................................................56.4 Responsibilities.........................................................................................................56.4.1 Offeror Responsibilities............................................................................................56.4.2 State Conversion Responsibilities:.........................................................................6

7. EXIT STRATEGY............................................................................................................................................6

8. COST PROPOSAL.........................................................................................................................................6

8.1 General Provisions...................................................................................................68.2 Cost Proposal Requirements..................................................................................68.3 Software and Hardware Costs................................................................................78.4 Total Cost of Project.................................................................................................7

9. TABLE A: SYSTEM AND PROJECT MANAGEMENT REQUIREMENTS.............................................7

10. SERVICE LEVEL AGREEMENTS – ED STEPS PROJECT SOFTWARE DEVELOPMENT...........16

10.1 Parties and Timeline...............................................................................................1610.2 Methodology – the Project Schedule...................................................................1610.3 Service Catalogue...................................................................................................1610.4 Deductions...............................................................................................................1810.5 Meetings...................................................................................................................1810.6 Reporting..................................................................................................................1810.7 Sprint Failure..............................................................................................................1910.8 Application Testing Availability................................................................................2110.9 Application Testing Responsiveness Service Load Testing..............................2210.10 Dispute Resolution..................................................................................................22

ODE ED STEPS Project RFP p

Supplement One – ODE ED STEPSSystem Project Requirements

1. OverviewThe requirements for the ED STEPS System are found in Supplement 3 Additional Documentation. These include the following: Supplement 3 (B) the ED STEPS Vision Document: This vision document was developed by a set of four (4) user subcommittees comprised of subject matter

experts representing all operational groups of the Department who will be using the system. Basically, this document was created by the users of the system. Supplement 3 (A) the Combined Use Cases as Functional Requirements: This document details the Vision document at a more granular level showing

processes, screens and data components. Supplements 3 (E)(1)-(4) PowerPoint presentations: These are graphical depictions of the requirements that were created as the subcommittees developed

the requirements and should prove invaluable in responding to this RFP. Please note these serve as examples and represent requirements but are not prescriptive of actual screens.

Supplements 3 (D) CCIP Application Assessment & Supplement 3 (C) To-Be Execution Model Deliverable: These are historical project documents included to provide a full project perspective.

1.1 RFP Scope

ODE is asking for a dedicated team of experienced and skilled manpower resources and a proposed detailed cost from the Offeror to build this system using the architecture set forth in the architecture documents in Supplement 2 (State Architecture) and Supplements 3 (F) & (G) (ODE EAS Architecture). ODE understands that the vision document provided as Supplement 3 (B) is at such a high level that it will need to be converted to an architectural system design document describing the system in detailed technical terms showing components/services/modules/data configurations. ODE also believes that while using an Agile scrum methodology that many of the finer details of the project will be better defined during the development sprints. This architecture design document will be the first deliverable the Offeror must provide. Time and the proper manpower resources should be built into the project estimate and timelines to complete this task.

1.2 The RFP Methodology

Kick Off Meeting. The Contractor, in conjunction with State staff, must plan and conduct a Project kickoff meeting.

The Contractor in collaboration with the State will initiate the project with a mobilization effort for the first 15 days of the project, followed by the project kick-off event. This effort will focus on planning, processes, and project methodology. The goal will be to discuss and evaluate the Contractor’s proposed practices, methodologies and recommendations and ensure Contractor’s understanding of their commitment to deliver the proposed solution for the project. The Contractor must also work with the State on establishing acceptance criteria prior to submitting a deliverable.

The Contractor in conjunction with the State must develop and deliver a presentation to the sponsors, key stakeholders and core project team after the mobilization effort. At a minimum, the presentation must include a high level overview of the following:

Project scope and schedule; Goals of the Project; Methodology, approach, and tools to achieve the goals;

ODE EDSTEPS Project RFP p 2

Roles, responsibilities, and team expectations; Tasks, Deliverables, Milestones and significant work products; and Contract content review.

Project Review Check Point. Upon completion of the baselined Project Plan and on a quarterly basis throughout the Project, the Contractor, in conjunction with State Project team staff, must deliver a presentation to the State. At a minimum, the presentation must address any known State or Contractor issues or concerns, including but not limited to the following:

Project scope, budget and schedule; Any changes to Key named resources assigned to the Project; Project readiness including key issues and risk from their current status; Project Status including variance from baseline for key milestones, tasks, deliverables (Significant work products) and project closure; Methodology, approach, and tools to achieve the Project goals (inventory and status of completeness and agreement for documented project management

and implementation approaches. I.e., Project management plan, communication plan, requirements traceability, implementation approach and methodology); and

Roles, responsibilities, and team expectations.

Upon completion of the presentation, the State will immediately assess the health of the project and determine next steps for moving forward with the Project, within one week of the meeting, which may include the following:

Continue the Project; Terminate the Contract; or Suspend the Contract.

See Suspension and Termination language in Attachment Four for remedies for failure to deliver the proposed solution.

Please Note: There may be additional Project Reviews conducted by the State on an as needed basis throughout the term of the Contract to assess Project health and ensure the Project is progressing successfully.

As part of the technical evaluation phase, ODE will be selecting the three highest scoring Offerors for a final selection process. These Offerors will be invited to participate in a team interview and problem-solving session at ODE. The Offeror must bring their top technical team members for an interview and problem-solving session based on individual interviews and group performance on a set of technical challenges.

1.3 This RFP

These initial requirements focus on the Offerors’ experience and the experience and capability of the manpower resources proposed to do this project. All requirements will be evaluated and rolled up into one score for the entire requirements table. Not all requirements are weighted equally.


System and Project Management Requirements (Table A)

Offerors must describe their past experiences, their proposed manpower resources, and their understanding of this project to demonstrate their ability to do this project. These requirements are found in Section 9 - Table A: System and Project Management Requirements to this RFP. Offerors must respond to all requirements.

2. Development and SupportThis RFP is for development of the system and includes first year maintenance and support. The RFP includes the requirement that the Offeror conduct education and training of ODE employees at a sufficient level to allow ODE to handle ongoing maintenance and support. ODE hereby commits to making the proper ODE resources available for sufficient time for training and source code hand-off to allow for ODE to assume maintenance and support responsibilities.

3. Hardware and SoftwareODE will accept hardware or software proposals made by the Offeror. Any hardware or software must be compatible with ODE’s environment as outlined in this document as well as in Supplements 3 (F) & (G) ODE EAS Architecture. ODE will be responsible for the impact of implementing ED STEPS on this infrastructure and making changes to it.

4. ArchitectureThe Offeror or subcontractor must understand the ODE architecture and be able to develop the ED STEPS application within those architectural requirements and constraints. The Offeror must review the architecture as given in Supplement 2 (State Architecture) and Supplements 3 (F) & (G) (ODE EAS Architecture) when responding to this RFP to recommend the manpower resources, the cost estimates, and the timelines.

5. PersonnelThe most important component of this RFP is the manpower resources dedicated to work on the project.

5.1 Location ODE may require specific members of the project team to reside at the ODE facility for specific lengths of time. The Offeror should be mindful of this when identifying and committing manpower resources. The Offeror must understand that the proposed rate for each manpower resource will be the only compensation for this resource and needs to be quoted to encompass any travel or any other factor in their manpower cost proposal.

5.2 Final Say

The Offeror must supply a manpower plan in the project organization (A.5.1) for this RFP. The manpower plan will contain specific individuals. ODE reserves the right to interview and accept or reject each proposed individual resource before they begin work on this project. ODE also reserves the right to require replacement of any given resource at any time during the course of the project.


5.3 Non-Disclosure

The Offeror must verify that all Offerors and any subcontractor staff have signed ODE non-disclosure agreements prior to commencing work on the project. Depending on the role of the individual, there may be several forms to be signed to ensure data is held safe.

5.4 Management

The Offeror must manage the relationship among its staff and any subcontractors. The Offeror must jointly manage the project with the ODE project management team including a lead from both IT and one representing cross-functional departments.

6. Other Prior to the conclusion of the Contract, the Offeror agrees to the following:

6.1 State-Owned DataAll data within the System will be the property of ODE and will be housed in the ODE computing environment. This data must stay securely in the ODE environment.

6.2 State-Owned CapabilitiesAll capabilities created within the System will be the property of ODE and must stay securely within the ODE environment. ODE will solely own all software created as a result of this project.

6.3 Automated Conversion Methods: Whenever possible, if necessary, automated methods will be used to consolidate, validate, and transfer in the approach to converting data: Conversion of any external system data Automated client data consolidation methods Automated data validation and editing methods Data that contains missing files Data that contains missing field values Data that did not pass automated editing routines Data which requires some manual validation of the values assigned to certain fields.

6.4 Responsibilities6.4.1 Offeror ResponsibilitiesThe Offeror will be responsible for developing all new functionality for the ED STEPS system and any changes to the remaining CCIP system (Project Cash Request and Final Expenditure Report Functionalities).


6.4.2 State Conversion Responsibilities: The ODE staff will be responsible for all changes required to other existing systems (EAS, GLC and Compliance) to enable ED STEPS to function properly. Existing systems are defined as the systems that are currently running and in a productions status with ODE.

7. Exit StrategyBefore the award of the Contract, the Offeror and ODE will document an exit strategy. This strategy may be used at the discretion of ODE for numerous reasons. There may be a time when the project is no longer the correct solution for ODE. ODE may determine during the project that they are not satisfied with the project progress or project results. In any case, this exit strategy will outline the process, timeline intervals, and ongoing commitments for each side for agreements on termination.

8. Cost ProposalThe Offeror is expected to conform to the following guidelines in addition to those provided in the RFP:

8.1 General ProvisionsODE believes the most important factor for success for this project is the experience and capability of the manpower resources and the ability to keep those dedicated resources applied to this project.

The Contract resulting from this proposal will be a time and materials contract. There will be a combination of fixed and variable costs.

The costs will be fixed in the form of hourly rates for the manpower resources proposed to fulfill this contract. For example, the quoted rate for a project manager will be fixed for the duration of the project despite the specific project manager used. The Offeror needs to be cognizant of this provision while quoting hourly costs. Hourly costs need to be inclusive of all costs which may include travel to and from ODE sites or any other cost that Offeror may incur for their manpower resources. The Offeror also needs to fully identify all resources needed at contract time since adding additional resources will require contract changes. For example, the Offeror may propose the use of three .NET developers as opposed to two so long as the developers work for the same fixed hourly rate. Should the Offeror want to add a Tester that was not specified in the contract, that would require a contract change.

The costs will be variable based on the number of hours the specific resources will need to work to fulfill this contract. That means for any given time period that the costs will vary depending on the number of hours each resource works. The Offeror must provide total project hour estimates for each identified manpower resource for this cost proposal. ODE understands that these are estimates, but ODE has conducted a similar cost estimation exercise and will use Offeror’s estimates to evaluate the Offeror’s understanding of the requirements and the resonability of their estimates. At contract time, ODE and the Offeror will establish maximum and minimum hours for each resource for the duration of the contract. These “ranges” should allow both ODE and the Offeror to establish reasonable expectations for project costs. Should the project costs exceed or fall below these ranges, ODE and the Offeror will need to re-negotiate.

8.2 Cost Proposal RequirementsCost Proposals will be executed on a total project basis. ODE requires the following of the Cost Proposal: The Cost Proposal must be free from mathematical error (minor rounding errors are not considered mathematical errors); The Cost Proposal must include all costs; and


The Cost Proposal must be accompanied by a copy of the Supplement 4 (A) & (B).

Supplement 4 Document details:

Supplement 4 Cost Proposal tab contains Position Title, Rate, Number of Hours and Total Cost. The Offeror needs to complete this Cost Proposal. Supplement 4 Resource Plan tab contains Position Title, Hourly Rate, Hours Per Month for each Resource and Yearly Resource Totals. The Offeror needs

to complete this Resource Plan. Supplement 4 Estimated Resource Plan tab shows the estimated Timeline of all the Resources. It also shows the estimated months the specific resources

will be needed for this project. This document has been provided for information purposes only. The Offeror does not need to complete this document. The purpose of this information is to show ODE’s resource estimates.

Supplement 4 Proposed Project Timeline tab has been provided for information purposes only. The Offeror does not need to complete this document. The purpose of this information is to show ODE’s proposed ED STEPS project timeline.

8.3 Software and Hardware CostsODE does not expect the Offeror to submit hardware or software costs

8.4 Total Cost of ProjectThe cost proposal will be arrived at by filling out and then summarizing Supplement 4 Resource Plan tab. Offeror must use the following information to fill out Supplement 4 Resource Plan tab:• Title/role of each resource;• Hourly rate of that resource;• Cost of that resource for every month they will be dedicated to the project (Calculated by the number of hours for each month that resource will be

dedicated times the hourly rate giving a dollar amount and entered into the cell for that month in the spreadsheet);• Total cost for the project for that resource (calculated from summing the cells across); and• Total of all rates for all resources (calculated from total of all resource costs for the project) (i.e. proposed project cost).

The Offeror must summarize the data from Supplement 4 Resource Plan tab to complete Supplement 4 Cost Proposal tab.

9. Table A: System and Project Management RequirementsResponses should be provided in the Response block below the requirement. Appendices are permitted should the space in the response block be inadequate. Offeror must label appendices per the Requirement Number.

Number Requirement Weight

A.1 Cloud experience, especially Azure cloud PaaS (Platform as a Service) experience, is critical for this project. We want to know about the Offeror’s Azure cloud PaaS experience. The Offeror must indicate whether projects were done by the Offeror or by a subcontractor.

A.1.1 The Offeror must list and give a brief summary description of two (2) projects successfully completed by the Offeror’s organization or subcontractors within a Microsoft Azure cloud PaaS environment. For the projects listed, Offeror must

5


provide project duration, project technical architecture, project size, project participants, project success, lessons learned, and anything ODE might find relevant about the experience. The Offeror must provide references and contact information for these projects with the assumption that ODE may contact them for their experiences with Offeror. The Offeror must identify which, if any, of these projects were done for a government agency and identify the agency.

ODE has already selected the Azure tools/resources that will be used for this project. The technical architecture for the Azure projects executed by the Offeror should be similar to the technical architecture used by ODE.

Response:

A.2 Agile project management experience with a scrum approach is also critical for this project. We want to know about Offeror’s Agile project management experience. Since ODE has used cross-functional teams to develop the vision document, ODE wishes to continue for the development phase and use an Agile scrum methodology. The Offeror must indicate whether projects were done by the Offeror or by a sub-contractor.

A.2.1 The Offeror must list and give a brief summary description of three (3) projects successfully completed by the Offeror’s organization or subcontractors using the Agile scrum project management methodology. These may be the same or different projects than given in A.1.1. For the projects listed, Offeror must provide project duration, size, participants, success criteria met, lessons learned, and anything ODE might find relevant about the experience. The Offeror must provide references and contact information for these projects with the assumption that ODE may contact them for their experiences with Offeror. The Offeror must identify which, if any, of these projects were done for a government agency and identify the agency.

Response:

A.3 State of Ohio and other Governments Projects: The Offeror’s experience with the state or government organization is important for this project. Offeror must indicate whether projects were done by Offeror or subcontractor.

A.3.1 The Offeror must provide a list of no less than three (3) and no more than five (5) projects of similar size/scope (not given above) successfully completed or in-flight (active) projects for the State of Ohio by Offeror’s organization or subcontractors completed or still active within the past five (5) years. The Offeror must include the results of those projects and whether they were completed on time, within budget, and with the requisite functionality. The Offeror must include any active projects. The Offeror must include any disputed projects or projects residing in a legal status. ODE is concerned about past and present performance for the State of Ohio.

The Offeror must provide a list of no less than three (3) and no more than five (5) projects (not given above) successfully completed or in-flight (active) projects specifically for a government organization by Offeror’s organization or subcontractors completed or still active within the past five (5) years. The Offeror must include the results of those projects and whether they were completed on time, within budget, and with the requisite functionality. The Offeror must include any active projects. The Offeror must include any disputed projects or projects residing in a legal status. ODE is concerned about past and present performance for government organizations.


Response:

A.4 Organization and Subcontractors(): The Offeror’s organization is important to this project. Offeror must provide the same information for the Offeror and any designated subcontractors.

A.4.1 The Offeror must provide a brief description of its organizational entity and any proposed subcontractors entity (including business locations, size, areas of specialization and expertise, client base and any other pertinent information that would aid an evaluator in formulating a determination about the stability and strength of the entity), including the Offeror’s organization’s and any subcontractor’s experience and history developing systems of similar size and scope to the ED STEPS Project.

Response:

A.5 Project Organization Overview: The proposed project team members (manpower resources) with their experience and capabilities are the most critical component of this RFP.

A.5.1 The Offeror must provide a Project Organization overview that describes the Project Team structure and the title, roles and responsibilities of project team members. Please note that ODE has identified the resources they would use were they doing the project internally given as part of Supplement 4 Resource Plan tab. Offeror must attempt to match their resource titles where applicable to Supplement 4 Resource Plan tab to allow ODE to make comparisons between project organizations. Offeror must supply this information including:

Identification of each individual proposed to fill a key role for this engagement including the following information, at a minimum, for each person identified:

o Description of education and trainingo Description of previous experience fulfilling their assigned roleo Description of previous direct experience with substantially similar projects.

The Offeror may include any other experience deemed relevant by the Offeror to adequately convey an individual's experience and qualifications (resume encouraged); and

Offeror must use the format in Attachment 8 to provide a summary of this information – Personnel Profile Summary.

The Offeror must certify its intent to commit the proposed key staff for the project team to the engagement of this project through implementation. Proposed staff may be from Offeror or subcontractors.

The Offeror must also include Supplement 4 Resource Plan tab and Attachments 8.

Response:

A.6 Staff Resources

A.6.1 Solutions Architect: The Solutions Architect proposed has the following education, training, experience, and experience with substantially similar projects.

Minimum Qualifications:Minimum of 3 years of experience using Microsoft Azure.


Minimum of 2 years of experience in developing cloud architecture and adoption strategy for Azure.Minimum of 2 years of experience in developing/maintaining IT systems in a hybrid mode (Azure cloud and on-premise system).Minimum of 2 years of experience in developing/maintaining Azure cloud native IT systems OR in migrating existing .NET application to Azure.Minimum of 2 years of experience in Continuous Integration / Continuous Delivery in Azure.Minimum of 2 years of experience in Azure Technologies (e.g. Azure function, Azure Batch/Web Jobs, Service Fabric, Service Bus, Key Vault). Minimum of 1 year of experience with VSTS Online.Minimum of 10 years of experience in developing/maintaining IT systems using Microsoft .NET 2.0 and above (C# preferred).Minimum of 8 years of experience in Relational database technologies (MS SQL (preferred) or Oracle).Minimum of 8 years of experience in architecting IT systems using Microsoft .NET 2.0 and above (C# preferred).Minimum of 5 years of experience in leading teams through multiple stages of software development (from system analysis to deployment).Minimum 5 years of experience in Microservice Architecture.Minimum of 5 years of experience in Test Driven Development and test automation.Minimum of 5 years of experience in Agile Development Methodologies using TFS.Minimum of 2 years of experience using Angular 2.0 or above with TypeScript, Bootstrap, Jasmine, Karma (or other Angular testing framework).Minimum of 5 years of experience with other web UI development tools/languages (JavaScript, jQuery, Ajax, MVC).Minimum of 1 year of experience with .NET CORE 1.0/2.0 using C#.Minimum of 5 years of experience using Mocking framework (MoQ or equivalent).Minimum of 5 years of experience in Dependency injection (Autofac or equivalent).Minimum of 3 years of experience using ORM Tools (Entity Framework (preferred) or equivalent).

Preferred Qualifications:Minimum of 2 years of experience reporting using Power BI / MS Report.Minimum of 2 years of experience in ETL using SSIS (or equivalent).Minimum of 2 years of experience with MS Azure Data Factory.Minimum of 2 years of experience using other database technology (noSQL/Cosmos DB/MongoDB).

ODE has already selected the Azure tools/resources that will be used for this project. The solution architect for this project should have experience in the Azure tools/resource used by ODE.

Offeror will provide Attachment 8 labeled Solutions Architect and any other documentation (e.g. resume) as the response to this requirement and ODE will use Attachment 8 to score this requirement.

Response:

A.6.2 UI Architect / Sr. Developer: The UI Architect / Sr. Developer proposed has the following education, training, experience, and experience with substantially similar projects.


Minimum Qualifications:Minimum of 5 years of experience in architecting UI/Front End using scripting languages/frameworks (e.g. Angular 2.0, Angular 1.0, React). Having experience with multiple technology set preferred. Minimum of 8 years of experience in developing UI/Front end using various scripting languages (e.g. JavaScript, TypeScript). Having experience with multiple scripting languages preferred. Minimum of 10 years of experience in IT System Architecture.Minimum of 5 years of experience in mentoring and code/design review.Minimum of a total of 15 years of IT experience.Minimum of 2 years of Cloud experience (Azure and/or AWS).

ODE is using Angular 4.0/5.0 for the UI development. Experience with Angular 4.0 and above and Node.Js are preferred.

Response: Offeror will provide Attachment 8 labeled UI Architect / Sr. Developer and any other documentation (e.g. resume) as the response to this requirement and ODE will use Attachment 8 to score this requirement.

A.6.3 Database Designer: The Database Designer proposed has the following education, training, experience, and experience with substantially similar projects.

Minimum Qualifications:Minimum of 3 years of experience working with Business office on requirements gathering and needs assessment with the ability to translate need into Logical/Physical data model.

Minimum of 4 production projects (not classroom, research or pilot projects) involving data base modeling for online applications.

Minimum of 5 years of experience working with MS SQLServer. Minimum of 3 year of experience working with 2014 version or later and a minimum of 1 year with SQLServer Azure preferred.

Minimum of 5 years of experience data modeling Erwin. Minimum of 3 years with R9 versions or later preferred.

Response: Offeror will provide Attachment 8 labeled Database Designer and any other documentation (e.g. resume) as the response to this requirement and ODE will use Attachment 8 to score this requirement.

User Interface Designer (UI): The UIwill be provided by ODE and will not be sourced or scored in this RFP.

Response: N/A

A.6.4 The (SM) Scrum Master or (PM) Project Manager: The SM or PM proposed has the following education, training, experience, and experience with substantially similar projects.


Minimum Qualifications:Minimum of 10 years of experience in the IT field.Minimum of 10 years of experience as a Certified Scrum Master overseeing Agile development projects. Minimum of 10 years of experience organizing and facilitating planning and coordination ceremonies including release / PI planning, iteration planning, daily stand-ups, iteration review/demos and retrospectives.Minimum of 10 years of experience working creatively and analytically in a problem-solving environment. Minimum of 10 years of experience with all facets of software development lifecycle (requirements definition, system design, development, testing, deployment, support).Minimum of 10 years of experience mentoring and motivating development teams to perform well and achieve the best outcomes for the project. Excellent verbal and written communication skills with the ability to communicate at all organizational levels in a highly collaborative fashion.Good technical knowledge to understand the various technical touchpoints to understand dependencies.Ability to excel in a highly dynamic environment and flexible to change direction as needed.Proactive and ability to think downstream and plan and recommend improvements and assist in changes to best practices where appropriate.Proficient in Microsoft Office tools (PowerPoint, Excel, Word, Project and Visio)

Preferred Qualifications:IT Project Management experience managing Agile development projects.

Response: Offeror will provide Attachment 8 labeled (SM) Scrum Master or (PM) Project Manager and any other documentation (e.g. resume) as the response to this requirement and ODE will use Attachment 8 to score this requirement.

Business Analyst (BA) / Documentation (D): The Business Analyst / Documentation will be provided by ODE and will not be sourced or scored in this RFP.

Response: N/A

A.6.5 Tester (T) / Quality Assurance (QA): The Tester / Quality Assurance proposed has the following education, training, experience, and experience with substantially similar projects.

Minimum Qualifications:Experience as a .NET Tester.Minimum of 7 years professional experience in developing and/or testing software applications in complex end user environments. Minimum of 5 years of experience performing all aspects of software test management (test plan, test case creation, test cases execution, defect tracking, capture testing metrics). Minimum of 5 years of experience with manual testing (functional, regression and performance).Minimum of 3 years of experience with automated testing (functional, regression and performance). Minimum of 2 years of experience in developing/testing web applications on the Microsoft ASP.Net Framework.Minimum of 2 years of experience with Visual Studio 2008/2010 for Software Testers (Test manager) and Team


Foundation Server (TFS).

Preferred Qualifications: Minimum of 2 years of experience in writing SQL queries and relational database (Oracle is preferred).Knowledge and professional experience of XML, nUnit, Web Service, and ASP.NET 4.0 is preferred. Experience in leading, developing and growing QA team is preferred.Minimum of 1 year of experience using SCRUM Agile development methodologies (or SCRUM Master certification as equivalent).Goals-oriented proactive team player with the ability to multi-task and prioritize technical tasks in a fast-paced, professional environment.Bachelor’s degree or higher in Computer Science or related field. Partial credit will be awarded for Bachelor degree or higher in any field.

Response: Offeror will provide Attachment 8 labeled (T) Tester / (QA) Quality Assurance and any other documentation (e.g. resume) as the response to this requirement and ODE will use Attachment 8 to score this requirement.

A.6.6 Cloud .NET Developer 1: The Cloud .NET Developer proposed has the following education, training, experience, and experience with substantially similar projects.

Minimum Qualifications:Minimum of 10 years of experience developing/maintaining IT systems using Microsoft .NET 2.0 and above (C# preferred).Minimum of 10 years of experience using Relational database technologies (MS SQL (preferred) or Oracle).Minimum of 3 years of experience using Test Driven Development and test automation.Minimum of 5 years of experience in Agile Development Methodologies using TFS.Minimum of 1 year of experience using Angular 2.0 or above with TypeScript, Bootstrap, Jasmine, Karma (or other Angular testing framework).Minimum of 1 year of experience using other web UI development tools/languages (JavaScript, jQuery, Ajax, MVC).Minimum of 1 year of experience with .NET CORE 1.0/2.0 using C#.Minimum of 2 years of experience using Mocking framework (MoQ or equivalent).Minimum of 2 years of experience using Dependency injection (Autofac or equivalent).Minimum of 2 years of experience using ORM Tools (Entity Framework (preferred) or equivalent).

Preferred Qualifications: Minimum of 2 years of experience using Microsoft Azure. (cloud native IT systems, hybrid solution or migration of existing system to Azure)Minimum of 2 years of experience in Angular 4.0 or aboveMinimum of 2 years of experience in Continuous Integration / Continuous Delivery in Azure.Minimum of 1 year of Azure Technologies (e.g. Azure function, Azure Batch/Web Jobs, service Fabric, Service Bus, Key Vault).


Minimum of 1 year of experience with VSTS Online.Minimum of 2 years of experience using other database technology (noSQL/Cosmos DB/MongoDB).

Response: Offeror will provide Attachment 8 labeled Cloud .Net Developer 1 and any other documentation (e.g. resume) as the response to this requirement and ODE will use Attachment 8 to score this requirement.

A.6.7 Cloud .NET Developer 2: The Cloud .NET Developer proposed has the following education, training, experience, and experience with substantially similar projects.

Minimum Qualifications:Minimum of 10 years of experience developing/maintaining IT systems using Microsoft .NET 2.0 and above (C# preferred).Minimum of 10 years of experience using Relational database technologies (MS SQL (preferred) or Oracle).Minimum of 3 years of experience using Test Driven Development and test automation.Minimum of 5 years of experience in Agile Development Methodologies using TFS.Minimum of 1 year of experience using Angular 2.0 or above with TypeScript, Bootstrap, Jasmine, Karma (or other Angular testing framework).Minimum of 1 year of experience using other web UI development tools/languages (JavaScript, jQuery, Ajax, MVC).Minimum of 1 year of experience with .NET CORE 1.0/2.0 using C#.Minimum of 2 years of experience using Mocking framework (MoQ or equivalent).Minimum of 2 years of experience using Dependency injection (Autofac or equivalent).Minimum of 2 years of experience using ORM Tools (Entity Framework (preferred) or equivalent).

Preferred Qualifications: Minimum of 2 years of experience using Microsoft Azure (cloud native IT systems, hybrid solution or migration of existing system to Azure)Minimum of 2 years of experience in Angular 4.0 or aboveMinimum of 2 years of experience in Continuous Integration / Continuous Delivery in Azure.Minimum of 1 year of Azure Technologies (e.g. Azure function, Azure Batch/Web Jobs, Service Fabric, Service Bus, Key Vault). Minimum of 1 year of experience with VSTS Online.Minimum of 2 years of experience using other database technology (noSQL/Cosmos DB/MongoDB).

Response: Offeror will provide Attachment 8 labeled Cloud .Net Developer 2 and any other documentation (e.g. resume) as the response to this requirement and ODE will use Attachment 8 to score this requirement.

A.6.8 Should the Offeror propose other resources not given above, the Offeror must enter those here and label as A.6.8, A.6.9 and so on.

Response: Offeror will provide Attachment 8 labeled with the proposed resource and any other documentation (e.g. resume) as the response to this requirement and ODE will use Attachment 8 to score this requirement.


A7 Project Plan: Since some components of the cost proposal are variable, the Offeror’s ability to develop precise project plans and schedules is important.

A7.1 The Offeror must submit a Project Plan for the ED STEPS system development governed by Supplement 2 (State Architecture) and Supplement (3) (F) & (G) ODE EAS Architecture). The Project Plan must take the manpower resources identified in A.5.1 – Project Organization and assign the hourly cost of that resource and the number of hours that resource is required for the length of the project. ODE estimates the project to be 24 months in duration as outlined in Supplement 4 Proposed Project Timeline tab but Offeror must provide their own estimates of duration. Contracts cannot be written to exceed 2 years so ODE insists that the Offeror not exceed that duration for their estimates. The Offeror must map this information to a calendar showing the duration of the project and deployment of those identified manpower resources against the calendar. The resulting project plan must show a month by month deployment of the manpower resources. Offeror must use Supplement 4 Resource Plan tab as the format for Offeror’s Project Plan submission.

Response: Must also include updated Supplement 4 Resource Plan tab.

A8 Project Schedule: Since some components of the cost proposal are variable, the Offeror’s ability to develop precise project plans and schedules is important.

A8.1 The Offeror must exhibit a full understanding of the project requirements and work with ODE to establish a detailed Project Schedule. Here are the major project steps:

Architecture system design Decision Framework One-Plan Consolidated Competitive Application Dashboard Project Wrap-up

The Offeror must use the ODE vision document and the Project Plan from A.7.1 to show development deliverables in the form of a proposed Project Schedule for each major project step. The Offeror must map each deliverable to a series of 4-week sprints (Agile scrum sprint methodology). While only estimates at this point, this document will be used later to develop a project schedule with project milestones and deliverables. Offeror must develop the initial Project Plan for a response to this requirement and, should the Offeror be chosen for this project, for the System updating throughout the project showing dependencies, milestones, and deliverables required to achieve the work described in the RFP.

Response:


10. Service Level Agreements – ED STEPS Project Software Development

10.1 Parties and TimelineThis Service Level Agreement is between the service provider (Offeror) and ODE from award of this contract and is expected to be approved with the overall contract. This service level agreement is effective as of the date of award of this work. ODE and the service provider must review at least quarterly to determine if any modifications or amendments are needed to reflect the ODE requirements and service provider’s services.

10.2 Methodology – the Project ScheduleService provider is developing the ED STEPS project using an Agile scrum methodology with project deliverables required every 4th Wednesday of the month (unless specified in writing) presented to the cross-functional subcommittee for review and approval. Each set of project deliverables comprises what is known as a sprint. The content of the deliverables in the sprint will be negotiated between the Offeror and ODE. Failure to come to an agreement will require intervention by senior management on both sides of the project.

While the architectural design document is being completed, at the beginning of the project, Offeror and ODE will convene a meeting and develop a project schedule breaking down each of the major development components into sub-components with specific deliverables of functionality. These functionality deliverables will be divided among sprints and used to develop the overall project schedule. Both parties must agree to the schedule.

Any deviation from this schedule must come from a project review meeting between the Offeror and ODE. The resulting project schedule must be reviewed and confirmed at least monthly so long as the sprints are successful and the indicated functionality is delivered, more often if not.

Periodically, the schedule will be challenged by the cross-functional subcommittee where some additional functionality will be identified and desired which, if provided, will threaten the project schedule. Offeror will provide the impact on the schedule and ODE will determine whether the identified and desired functionality warrants a change in the project schedule or whether it should be added to a list of deliverables to be provided later, possibly in a Phase II schedule.

10.3 Service CatalogueOfferor will provide the following services to ODE per the ED STEPS project contract:

Service General Description Specifics of service

Development Develop the software for the ED STEPS System in the Microsoft Azure PaaS cloud environment using a .Net framework and adhering to the Project Plan.

Deliver the architecture document Develop the Decision Framework Develop the One-Plan Develop the Consolidated Application for

Competitive and Formula based grants Update existing CCIP financial functionalities Develop the District Dashboard Wrap up the project

Deliverables for Planning and Scheduling

Tangible deliverables required for a successful software development project and a deliverable acceptance process.

Project plan Development plan Manpower plan Project schedule Architecture document Decision Framework functioning software One-Plan functioning software Consolidated Application for Competitive and

Formula based grants functioning software Updating exiting CCIP system Distract Dashboard functioning software Full system implementation Training

ODE ED STEPS Project RFP p 16

Documentation Change control process Final system acceptance process Knowledge transfer process

Quality Control Internal quality management function. Quality control function Quality control process Quality control checklists Quality control inspection process Quality control reports

Risk Management Risk Management Plan for the project.

Risk management methodology/process Risk management tools Risk management reviews Risk management documentation Risk management monitoring Risk management control Risk management contingency plans

Tools Tools used to conduct the project. Project planning tools Project reporting tools Project scheduling tools Project document and artifact storing tools Project testing tools Project training tools Project knowledge transfer tools

Testing Test Plans and testing the system. Test plan description Test plan process Testing for component, integration, system,

functional, performance, regression, security and user acceptance

Test certifications Test for documentation

System Implementation

Implementing the system once completely coded and tested.

System implementation approach System implementation process System implementation strategy System implementation scheduling System implementation communications System implementation acceptance criteria System implementation resources System implementation timing

First Year Maintenance

Maintain the system collaboratively with ODE resources.

New Enhancements Bug Fixes

Knowledge Transfer

Transfer of knowledge about usage of the system to users and maintenance/support of the system to technical support team

Users Navigation Features Functionality Documentation Help features Support optionsSupport Team: Content management System design and schema System usage System testing techniques (manual and

automated) System procedures Application and tools development


Report generation Data and database administration Utilities Application diagnostic tools System administration and maintenance

Documentation Document the system for the users of the system, the application administrator, and the ODE maintenance/support team

Reference manuals Data Architecture Dependency documentation Design documentation User Interface documentation Technical Interface documentation Quality management activities Test plans User manual Online Help System manual System administration manual Help desk manual Documentation (i.e., changes to

requirements, use cases, business rules) Training manuals and materials

Training Provide training materials and guidance for training users, application administrator, and the ODE team.

Online training for users loaded into ODEs current LMS system or the State’s Taleo system to the SCORM standard

Hands on train 1 on 1 for application administrator.

Hands on and classroom train ODE maintenance and support team.

10.4 DeductionsA 5% deduction will be taken from Offeror’s monthly invoice for the month in which one or more of the SLA levels were not met. Logistics of such a payment will be mutually agreed upon between Offeror and ODE.

10.5 MeetingsThe following meetings between Offeror and ODE must take place unless otherwise agreed upon:

Initial meeting to develop the project schedule; Monthly sprint definition and review of previous sprint; Monthly progress review meeting; Quarterly progress review meeting; and Schedule challenge meeting (as needed).

10.6 ReportingThe following reports provided by the service offeror will be used to manage the ED STEPS system development agreement. Agenda, schedules and expected content will be discussed and agreed upon at the kick-off meeting for the project.

Weekly Status ReportOfferor to provide ODE with a weekly status report that gives an overall summary of the following:

Project health; On-going activities; Sprint summary including completed tasks and sprint failures; Upcoming milestones and releases; Personnel/staffing issues; Project slippage; Risk identification and mitigation plan; and Action items.


Monthly Status ReportMetrics will be tracked by Offeror, summarized in a dashboard format, and discussed in a monthly meeting. This activity includes the following:

Project costs; Project progress; Project deliverables; and Project milestones.

Quarterly Status ReportA quarterly review meeting will include the following:

The SLA will be reviewed with the managers involved and an amendment addendum will be created if required;

Review process will be through teleconference or face-to-face meeting session which will be booked in advance;

Review document prepared by service provider that will include overall project status, sprint failures, metrics reporting, supporting reasons for metrics deviation, and items that need adjustment within SLA (e.g. scope, metrics, etc.); and

SLA changes will be tracked by version number and date.

Reporting Service Levels

Type MeasurementWeekly Status Report Delivered at not less than 7 calendar day intervals

Monthly Status Report Delivered at monthly calendar intervals and not less than 2state work days before scheduled review meeting

Quarterly Status Report Delivered at quarterly calendar intervals and not less than 5 state work days before scheduled review meeting

10.7 Sprint FailureDuring the course of the system development process, functionality per the Agile scrum approach will be delivered every month and reviewed with ODE subject matter experts (SMEs) in the form of sub-committees for each of the system components (e.g. One-Plan, Decision Framework). The following procedures will be used to respond to missing or non-functional requirement deliverables (Sprint failures) committed to in the sprint that are reported by the SMEs and received by the service provider. A missing or non-functional requirement deliverable is defined as deliverables identified in the sprint that were to be delivered and were not which adversely affects the application development schedule of deliverables.

The measurement period for Sprint failure correction SLAs is a calendar month. For example, if an SLA is not met during the month of April one 5% deduction (as outlined in the SLA associated with that particular service) will be applied to the invoice for the month of April, and if it is not met for the month of May, an additional 5% deduction will be applied to the invoice for the month of May. Sprint failures negatively affect the project schedule and may result in missing milestones and deadlines. Sprint failures become top priority for progress reporting and project status. These may jeopardize the overall project as well.

Prioritization Approach

Sprint failures received by Offeror will be given a features/requirement priorities from 1 – 4 based on how important responding to the problem is to the component schedule and the software development schedule as a whole. The Severity Code will be the basis for assessing the impact on the development schedule and for dictating the response that the service Offeror must provide. Critical, urgent, and routine application functions are defined in the section below on the Sprint Failure Type.


Severity Code Definition1 Severity Level One – there is a complete or severe lack of functionality that is scheduled to be

delivered in the sprint. System testing is halted or severely restricted. Repetitive problems at Level One may be grounds for Contract termination.

2 Severity Level Two – there is a minor lack of functionality but system testing can continue. The impact is an inconvenience but business critical areas can still function and be tested.

3 Severity Level Three – there is a deviation from any normal standard but that causes no delay or loss of testing. This may be a minor error, incorrect behavior, or a documentation error that does not impede the operation and testing of the system.

4 Severity Level Four - performing functionality that has not diminished routine application functionality or performance.

Sprint Failure Type

The table below provides examples of critical, urgent, and routine Sprint Failure types. Further conversation with the Offeror will help to ensure all services are mapped to the correct category.

Sprint Failure Type Description Examples

Critical

The core elements of the sprint were not developed or were developed so poorly that they would not function at all. These functions are large enough to impact the component schedule and the overall project schedule. These are generally large functions or deliverables that take multiple days of work.

SME/LEA cannot create a One-PlanSME/LEA cannot create a Decision FrameworkSME/LEA cannot access the Consolidated Competitive Application

Urgent

Some components of the sprint were not developed or were developed so poorly that they would not function at all. These functions are large enough to impact the component schedule. These are usually medium sized functions in nature that require a day or more of work.

SME/LEA cannot add a goalSME/LEA cannot add a strategySME/LEA cannot add an implementation

Routine

One or more small components of the sprint were not developed or were developed so poorly that they would not function. These functions are not large enough to impact the component schedule. These are usually small functions in nature that require less than a day’s work.

SME/LEA cannot crate a reportSME/LEA cannot sign in to ED STEPSSME/LEA cannot execute a workflowSME/LEA cannot navigate the system

Response and Resolution Times

Severity codes are used to determine appropriate response and resolution times. Response and resolution times are measured from when the Sprint failure is reported by the SME to Offeror. If the Sprint failure is not resolved within the defined timeframe, continuous effort will be applied until the problem is resolved.

Severity Code

InitialResponse

Estimation Response

Subsequent Responses Resolution

1Immediately during sprint demo

1 day Daily 1 state work day

2 Immediately during sprint

2 days Daily 2 state work days


demo3 2-4 hours 3-5 days Weekly 5 state work days

4 4-8 hours 5 state work days Weekly 10 state work days

Initial Response is when a development problem is reported by the ODE SME and acknowledged by the service provider. This problem will be conveyed back to the originator with proposed severity level noted. Initial severity level will be set by the service provider; escalation process will be available however.

Estimation Response is when the SME that reported the problem is informed of an estimated resolution time.

Subsequent Responses is the frequency with which the SME that reported the problem is updated on the resolution status.

Resolution is the point at which the problem is resolved and the application function is returned to a usable and available state.

Response and Resolution Service Levels

If Offeror fails to meet any of the following Response and Resolution Service levels in a given calendar month, the response and resolution service will be reported as unacceptable and a meeting between ODE and Offeror must take place. If Offeror fails to meet any of the following Response and Resolution Service levels in a given calendar month, the response and resolution service will be reported as unacceptable and a 5% deduction will be assessed.

Type Measurement

Problem ResolutionLess than 95% of problems are resolved in the prescribed resolution interval.

Response/Estimate Less than 95% of Initial Response, Estimation Response, and Subsequent Response times are met.

Maximum Problem Aging No problem is older than 14 days.

10.8 Application Testing AvailabilityTesting Availability is defined as the ability of an end user (ODE SME or designated tester) to access and test any of the included application functions from a functioning workstation and live network connection. For an application to be available, all of its supporting systems must be operational. “Unavailable” or “Unavailability” means the users are unable to access the Service or test all the Service’s features and functions effectively and efficiently.

System testing availability will be measured weekly during normal business hours. Application testing availability metrics will be measured/reported Monthly beginning with initial delivered functionality. Weekly measurement begins the first full week of functionality. Excludes scheduled maintenance.

Application Testing

State Work Day Hour Availability

Off-Hour Availability when scheduled Scheduled Down-Time

DefinitionMonday-Friday 8 am – 5 pm Eastern Time

Monday-Friday 5:01pm-7:59 am Eastern Time; Sat. and Sun.

Monday-Friday 10 pm – 6 am Eastern Time

Critical 99.5% 99.5% To Be mutually agreed upon

Urgent 99% 98% To Be mutually agreed upon

Routine 98% 98% To Be mutually agreed upon

Any additional outages must be scheduled and approved by ODE at least two weeks in advance, unless there is an emergency.

Application Testing Availability Service Levels


If the system fails to meet any of the following Testing availability service levels in a given calendar month, the availability will be reported as unacceptable and a meeting between ODE and Offeror must take place. If the system fails to meet any of the following Testing Availability Service levels in a given calendar month, the availability will be reported as unacceptable and a 5% deduction will be assessed.

Type MeasurementCritical Application

AvailabilityAvailability falls below 99.5% for more than 2 days of the month during regular state work hours.

Urgent Application Availability

Availability falls below 99% for more than 2 days of the month during regular state work hours.

Routine Application Availability

Availability falls below 98% for more than 2 days of the month during regular state work hours.

10.9 Application Testing Responsiveness Service Load TestingThis service load testing speaks to online response time for this application during testing. Response times are only applicable to the Application, within the control of the Offeror, as identified in this Contract. This service load testing is included since the Offeror is responsible for developing the Architectural system design document and can be held responsible for application responsiveness. Should the Offeror feel the lack of responsiveness is due to something in control of ODE, Offeror and ODE must meet and resolve the issue.

Online response time is measured as the elapsed time from when a request enters the UI Application gateway until the request has been satisfied and leaves the UI Application gateway. This includes processing times of all components covered under this Amendment which participate in fulfilling the request, including but not limited to Firewalls, Load Balancers, WAN/LAN Telecommunications Lines, Web Servers, and Application and Database Servers. The definition of a transaction is any system action that requires a screen to paint, refresh and/or system update to complete during normal operations. Mutually agreed to exception functions will be excluded from measurement.

The Measurement interval is Monday through Friday during state work days 8 am – 5 pm EST. Metrics will be collected monthly beginning with delivery of initial functionality, Weekly, thereafter; Measurements are to be reported monthly.

If the system fails to meet any of the following Application Testing Responsiveness Service levels in a given calendar month, the availability will be reported as unacceptable and a meeting between ODE and Offeror must take place. If the system fails to meet any of the following Application Testing Responsiveness Service levels in a given calendar month, the availability will be reported as unacceptable and a 5% deduction will be assessed.

Type MeasurementApplication

Testing Responsiveness

More than 5% of transactions complete (via State network) > 4.0 seconds

Application Testing

Responsiveness

More than 1% of transactions complete in > 10.0 seconds

10.10 Dispute ResolutionCreation of a Dispute Resolution Capability. The Parties will make efforts to first resolve internally any dispute, by escalating it to higher levels of management. If the disputed matter has not been resolved by the identified responsible Party (or organization) as defined in Supplement 1, the disputed matter will be reviewed by the ____________________________________________ within a commercially reasonable period of the delivery of a written notice by one Party to another.


Informal Dispute Resolution. Prior to the initiation of formal dispute resolution procedures as to any dispute (other than those arising out of the breach of a Party’s obligations), the Parties will first attempt to resolve each dispute informally, as follows:

If the Parties are unable to resolve a dispute in an amount of time that either Party deems required under the circumstances, such Party may refer the dispute to the State CIO or designee by delivering a written notice of such referral to the other Party.

Within five (5) Business Days of the delivery of a notice referring a dispute to the State CIO or designee, each Party will prepare and submit to the Steering Committee a detailed summary of the dispute, the underlying facts, supporting information and documentation and their respective positions, together with any supporting documentation.

The State CIO or designee will address the dispute at its next regularly scheduled meeting or, at the request of either Party, will conduct a special meeting within ten (10) Business Days to address such dispute. The State CIO or designee will address the dispute in an effort to resolve such dispute without the necessity of any formal proceeding.

The State CIO or designee will address the dispute at the next regularly scheduled meeting between the Contractor and the State or, at the request of either Party, will conduct a special meeting within twenty (20) Business Days to address such dispute. The State CIO or designee will address the dispute in an effort to resolve such dispute without the necessity of any formal proceeding.

If the State CIO or designee is unable to resolve a dispute within thirty (30) days of the first regular meeting between the State and Contractor addressing such dispute (or such longer period of time as the Parties may agree upon), either Party may refer the dispute to internal escalation by delivering written notice of such referral to the other Party.

Internal Escalation. If for whatever reason the Contractor and the State cannot resolve a dispute via the above escalation processes and procedures, the Contractor and the State agree to choose a mutually agreeable neutral third party who will mediate the dispute between the parties. The mediator chosen must be an experienced mediator and must not be: a current or former employee of either party or associated with any aspect of the Government of the State of Ohio; associated with any equipment or software supplier; or associated with the Contractor or the State. As to each prohibition this means either directly or indirectly or by virtue of any material financial interests, directly or indirectly, or by virtue of any family members, close friendships or in any way that would have the reasonable appearance of either conflict or potential for bias. If the parties are unable to agree on a qualified person, the mediator will be appointed by the American Arbitration Association.

The mediation must be non-binding and must be confidential to the extent permitted by law. Each party must be represented in the mediation by a person with authority to settle the dispute. The parties must participate in good faith in accordance with the recommendations of the mediator and must follow procedures for mediation as suggested by the mediator. All mediation expenses, except expenses of the individual parties, must be shared equally by the parties. The parties must refrain from court proceedings during the mediation process insofar as they can do so without prejudicing their legal rights.

If the disputed matter has not been resolved within thirty (30) days thereafter, or such longer period as agreed to in writing by the Parties, each Party will have the right to commence any legal proceeding as permitted by law.

Escalation for Repetitive Service Level Failures. Although it is the State’s intent to escalate service level failures to the Contractor Account Representative, the State may decide to escalate to other levels within the Contractor’s corporate structure deemed appropriate to resolve repetitive service failures.


overview - procure.ohio.gov · web viewthese offerors will be invited to participate in a team...

Documents