Maryland Higher Education Commission MDSIS RFP BPM042413.pdf

STATE OF MARYLAND

MARYLAND HIGHER EDUCATION COMMISSION (MHEC)

REQUEST FOR PROPOSALS (RFP)

MARYLAND STUDENT INFORMATION SYSTEM (MDSIS)

RFP NUMBER: BPM042413

ISSUE DATE: 03/01/2024

NOTICE

A Prospective Offeror that has received this document from a source other than eMarylandMarketplace

(eMMA) https://procurement.maryland.gov should register on eMMA. See Section 4.2.

MINORITY BUSINESS ENTERPRISES ARE ENCOURAGED TO

RESPOND TO THIS SOLICITATION.

Maryland Student Information System Solicitation #: BPM042413 RFP Document

RFP for Maryland Higher Education Commission Page ii of 126

VENDOR FEEDBACK FORM

To help us improve the quality of State solicitations, and to make our procurement process more responsive and business friendly, please provide comments and suggestions regarding this solicitation.

Please return your comments with your response. If you have chosen not to respond to this solicitation, please email or fax this completed form to the attention of the Procurement Officer (see Key Information Summary Sheet below for contact information).

Title: Maryland Student Information System (MDSIS) Solicitation No: BPM042413

1. If you have chosen not to respond to this solicitation, please indicate the reason(s) below:

� Other commitments preclude our participation at this time

� The subject of the solicitation is not something we ordinarily provide

� We are inexperienced in the work/commodities required

� Specifications are unclear, too restrictive, etc. (Explain in REMARKS section)

� The scope of work is beyond our present capacity

� Doing business with the State is simply too complicated. (Explain in REMARKS section)

� We cannot be competitive. (Explain in REMARKS section)

� Time allotted for completion of the Proposal is insufficient

� Start-up time is insufficient

� Bonding/Insurance requirements are restrictive (Explain in REMARKS section)

� Proposal requirements (other than specifications) are unreasonable or too risky (Explain in REMARKS section)

� MBE or VSBE requirements (Explain in REMARKS section)

� Prior State of Maryland contract experience was unprofitable or otherwise unsatisfactory.

(Explain in REMARKS section)

� Payment schedule too slow

� Other: __________________________________________________________________

2. If you have submitted a response to this solicitation, but wish to offer suggestions or express concerns, please use the REMARKS section below. (Attach additional pages as needed.)

REMARKS:

Vendor Name: ________________________________ Date: _______________________

Contact Person: _________________________________ Phone (____) _____ - _________________

Address: ______________________________________________________________________

E-mail Address: ________________________________________________________________

RFP for Maryland Higher Education Commission Page iii of 126

STATE OF MARYLAND

HIGHER EDUCCATION COMMISSION (MHEC)

KEY INFORMATION SUMMARY SHEET

Request for Proposals Maryland Student Information System (MDSIS)

Solicitation Number: BPM042413

RFP Issue Date: 03/01/2024

RFP Issuing Office: Maryland Higher Education Commission

Procurement Officer:

e-mail:

Office Phone:

Shirlita Lee 6 North Liberty Street, Ground Suite Baltimore, MD 21201 Shirlita.lee1@maryland.gov 410-767-3090

Proposals are to be sent to: Submit via eMMA

Pre-Proposal Conference: Thursday March 21, 2024 (03/21/2024) at 1pm Local Time Maryland Higher Education Commission 6 North Liberty Street, 8th Floor RM1 Baltimore, Maryland 21201

Questions Due Date and Time Tuesday April 2, 2024 at 4pm Local Time

Proposal Due (Closing) Date and Time:

Tuesday April 30, 2024 (04/30/2024) at 4pm Local Time

MBE Subcontracting Goal: 29%, with no sub-goals.

VSBE Subcontracting Goal: 1%

Contract Type: Firm Fixed Price

Contract Duration: 5 years with five (5) one year renewal option periods.

Primary Place of Performance:

Maryland Higher Education Commission 6 North Liberty Street, Ground Suite

Baltimore, Maryland 21201

SBR Designation: No

Federal Funding: No mailto:Shirlita.lee1@maryland.gov

RFP for Maryland Higher Education Commission Page iv of 126

TABLE OF CONTENTS – RFP

1 Minimum Qualifications

1.1 Offeror Minimum Qualifications

2 Contractor Requirements: Scope of Work

2.1 Summary Statement

2.2 Background, Purpose and Goals

2.3 Responsibilities and Tasks

2.4 Deliverables

2.5 Service Level Agreement (SLA)

3 Contractor Requirements: General

3.1 Contract Initiation Requirements

3.2 End of Contract Transition

3.3 Invoicing

3.4 Liquidated Damages

3.5 Disaster Recovery and Data

3.6 Insurance Requirements

3.7 Security Requirements

3.8 Problem Escalation Procedure

3.9 SOC 2 Type 2 Audit Report

3.10 Experience and Personnel

3.11 Substitution of Personnel

3.12 Minority Business Enterprise (MBE) Reports

3.13 Veteran Small Business Enterprise (VSBE) Reports

3.14 Additional Clauses

4 Procurement Instructions

4.1 Pre-Proposal Conference

4.2 eMaryland Marketplace Advantage (eMMA)

4.3 Questions

4.4 Procurement Method

4.5 Proposal Due (Closing) Date and Time

4.6 Multiple or Alternate Proposals

4.7 Economy of Preparation

RFP for Maryland Higher Education Commission Page v of 126

4.8 Public Information Act Notice

4.9 Award Basis

4.10 Oral Presentation

4.11 Duration of Proposal

4.12 Revisions to the RFP

4.13 Cancellations

4.14 Incurred Expenses

4.15 Protest/Disputes

4.16 Offeror Responsibilities

4.17 Acceptance of Terms and Conditions

4.18 Proposal Affidavit

4.19 Contract Affidavit

4.20 Compliance with Laws/Arrearages

4.21 Verification of Registration and Tax Payment

4.22 False Statements

4.23 Payments by Electronic Funds Transfer

4.24 Prompt Payment Policy

4.25 Electronic Procurements Authorized

4.26 MBE Participation Goal

4.27 VSBE Goal

4.28 Living Wage Requirements

4.29 Conflict of Interest Affidavit and Disclosure

4.30 Non-Disclosure Agreement

4.31 Nonvisual Access

4.32 Location of the Performance of Services Disclosure

4.33 Small Business Reserve (SBR) Procurement

4.34 Maryland Healthy Working Families Act Requirements

5 Proposal Format

5.1 Two Part Submission

5.2 Proposal Delivery and Packaging

5.3 Volume I - Technical Proposal

5.4 Volume II – Financial Proposal

6 Evaluation and Selection Process

6.1 Evaluation Committee

RFP for Maryland Higher Education Commission Page vi of 126

6.2 Technical Proposal Evaluation Criteria

6.3 Financial Proposal Evaluation Criteria

6.4 Reciprocal Preference

6.5 Selection Procedures

6.6 Documents Required upon Notice of Recommendation for Contract Award

7 RFP ATTACHMENTS AND APPENDICES

Attachment A. Pre-Proposal Conference Response Form

Attachment B. Financial Proposal Instructions & Form

Attachment C. Proposal Affidavit

Attachment D. Minority Business Enterprise (MBE) Forms

Attachment E. Veteran-Owned Small Business Enterprise (VSBE) Forms

Attachment F. Maryland Living Wage Affidavit of Agreement for Service Contracts

Attachment G. Federal Funds Attachments

Attachment H. Conflict of Interest Affidavit and Disclosure

Attachment I. Non-Disclosure Agreement (Contractor)

Attachment J. HIPAA Business Associate Agreement

Attachment K. Mercury Affidavit

Attachment L. Location of the Performance of Services Disclosure

Attachment M. Contract

Attachment N. Contract Affidavit

Attachment O. DHS Hiring Agreement

Attachment P. Payment vs. Milestones and SDLC Deliverables

Appendix 1. – Abbreviations and Definitions

Appendix 2. – Offeror Information Sheet

Additional Submission #1 – Evidence of Insurance Requirements

Additional Submission #2 – PEP

Additional Submission #3 – Fully Executed Escrow Agreement

RFP for Maryland Higher Education Commission Page vii of 126

Additional Submission #4 – Deliverable Product Acceptance Form (DPAF)

RFP for Maryland Higher Education Commission Page 1 of 126

1 Minimum Qualifications

1.1 Offeror Minimum Qualifications

There are no Offeror Minimum Qualifications for this procurement.

THE REMAINDER OF THIS PAGE IS INTENTIONALLY LEFT BLANK.

RFP for Maryland Higher Education Commission Page 2 of 126

2 Contractor Requirements: Scope of Work

2.1 Summary Statement

2.1.1 The Maryland Higher Education Commission (MHEC or Agency)), Office of Student Financial

Assistance (OSFA) is issuing this Request for Proposals (RFP) to award a contract to build a cloud-based unified student information system for the administration of state financial aid programs. MHEC is soliciting proposals to obtain (1) system development and implementation for internal OSFA staff and external users as authorized, (2) data conversion, (3) system coordination, (4) training, and (5) maintenance and support for five years after implementation.

2.1.2 It is the State’s intention to obtain goods and services, as specified in this RFP, from a Contract between the selected Offeror and the State.

2.1.3 The Agency intends to make a single award to the RFP. See RFP Section 4.9 Award Basis for more Contract award information.

2.1.4 An Offeror, either directly or through its subcontractor(s), must be able to provide all goods and services and meet all of the requirements requested in this solicitation and the successful Offeror (the Contractor) shall remain responsible for Contract performance regardless of subcontractor participation in the work.

2.1.5 The purpose of this solicitation is to procure a state-of-the-art available Commercial Off The Shelf (COTS) cloud-based solution to provide OSFA with a comprehensive financial aid system to effectively administer state education needs, student data and financial aid for Maryland constituents. While a COTS product may not exist, it is anticipated that the prospective Contractor will be able to use prior developed systems on a COTS basis to reduce development time, cost, and risk by building upon tested product components.

2.1.6 The State does not wish to procure a software application still under development. The COTS software utilized in the solution shall be operational (i.e., not under development) and generally available by the due date of the Proposal.

2.2 Background, Purpose and Goals

A. Background

The Office of Student Financial Assistance (OSFA) at the Maryland Higher Education Commission (MHEC) is responsible for the administration of 27 State student financial aid programs that process approximately 250,000 applications from Maryland students. Note that some additional scholarship programs are a subset of others which will increase the count of programs. Over 55,000 students receive awards in these programs each year providing over $125 million dollars in aid to Maryland students. The majority of State financial aid programs managed by OSFA are administered through the use of a database application that allows collecting and tracking of student data to deliver the processing services that support program requirements and State goals through strategic operational technology management.

The infrastructure of the current database application is no longer adaptable to new technologies, which justifies this project. The system has reached its design capacity for advanced technology features. A unified student information system is needed that is flexible, extensible, scalable, accessible, and secure to deliver a modern user experience internally and where students and other customers can self-serve. This investment will result in improved management of student data and administration of financial aid in a much more efficient, timely, and effective manner. Without it, MHEC would be forced to continue to https://mhec.maryland.gov/preparing/Pages/FinancialAid/descriptions.aspx

RFP for Maryland Higher Education Commission Page 3 of 126 attempt to build new technologies on an old infrastructure, increasing technical debt which ultimately results in diminishing returns and undesirable user experience.

The newly proposed cloud-based Maryland Student Information System (MDSIS) solution is planned for system modernization to ensure availability, scalability, continuity, and data integrity of financial aid services for State constituents using current technologies for a positive user experience.

The high-level mandated functions to achieve the goals of the newly proposed MDSIS system include:

(1) Available in Multiple Languages

(2) Mobile Technology

(3) Student Portal Document Tracking

(4) Capability for Electronic Signatures

(5) Integration of External Systems

(6) Multi-Level Communications

(7) Built-in User Help Assistance

B. Purpose

The purpose of this solicitation is to procure a state-of-the-art available COTS cloud-based solution to provide OSFA internal staff with a comprehensive unified student information system to effectively administer State education needs, student data and financial aid for Maryland constituents. While a COTS product may not exist for MHEC’s unique aid programs, it is anticipated that the prospective Offeror will be able to use prior developed systems on a COTS basis (7to reduce development time, cost, and risk by building upon tested product components. In addition to functionality for internal OSFA staff, the purpose of this solicitation is to enable MHEC to serve its customers through specialized portals, (1) students, (2) legislators, (3) institutions, (4) MHEC researchers, (5) MHEC Accounting Users, (6) High Schools, (7) Non-Profits, with a separate web portal for OSFA’s management of state financial aid and data extracts.

Each State financial aid program has its own set of criteria for eligibility and the system must perform automated processing to accommodate the rules for each program. There are six categories of student aid types from which OSFA awards funds to students, including: 1) five loan assistance repayment programs,

(2) eight need-based grants/scholarship programs; 3) two legislative scholarships; 4) eight career and occupational grants and scholarship programs; 5) three unique population programs, and one stipend type program. See Figure 1 below. The ways these financial aid types are awarded vary. Each year, the system requires updates, modifications, and enhancements to address federal and State program updates and requirements. The data-driven and rules-based architecture system is a key component to ensuring that all State financial aid programs run effectively and efficiently as well as provide a simple, accessible and positive user experience.

https://mhec.maryland.gov/preparing/Pages/FinancialAid/descriptions.aspx

RFP for Maryland Higher Education Commission Page 4 of 126

Figure 1: Categories of Student Aid

State financial aid programs administered by OSFA differ in size. See Figure 2 below. The Need-based Guaranteed Access Grants, Educational Assistance Grants, and Promise Scholarships are the largest funded programs administered by OSFA. These programs also represent the most straightforward awarding processes and administrative functions for system implementation. The other State aid programs, while smaller, have more uniqueness, complexities, and, in some cases, manual processes associated with awarding, tracking procedures, and program administration.

Figure 2: Percentage and Distribution of Award Recipients

In addition to administering state aid programs, OSFA must track service obligations and repayments for applicable aid programs. An individual who received a scholarship that requires a service requirement must begin employment in Maryland one year after degree completion, as outlined in the recipient’s service obligation agreement and signed promissory note.

RFP for Maryland Higher Education Commission Page 5 of 126

There is also a post-denial appeals submission process when a student experiences special circumstances that may cause them to fail to meet certain requirements for an award. The system must have functionality to process appeals.

Given the system and administrative processes associated with each State financial aid program, and even decentralized programs where institutions administer funding, there are common system overall functions required to manage programs. The diagram in Figure 3 below includes, but is not limited to, common State Financial Aid management functions and users.

Figure 3: Financial Aid Management Functions

To successfully administer State financial aid programs, external interfaces to the following are required:

1. The Federal Financial Aid Systems Gateway to acquire Free Application for Federal Student Assistance (FAFSA)s for Maryland residents

2. The Maryland Comptroller’s Office

3. The MD Motor Vehicle Administration (MVA) for address Information

4. The MD Central Collection Agency (CCU)

5. The State Board of Elections (SBE) for legislative districts

6. The Department of Budget and Management (DBM) for budget and program information

RFP for Maryland Higher Education Commission Page 6 of 126

As discussed, user portals are needed for MHEC, OSFA, and constituents with authorized access to student information as needed. The following diagram in Figure 4 shows a sample of basic needs for certain specialized users and portals. To note, the Agency user is comprised of the MHEC OSFA, accounting and research users who would all access the internal MHEC portal with specific permissions.

Figure 4: Sample of Basic Needs for Some Specialized Users and Portals

C. Goals

1. The Goals for this Project Include:

a. Cloud-based solutions are preferred so that private and financial data are properly secured and managed.

b. Build a system that conforms to Maryland’s State Development Life Cycle (SDLC) processes and security and privacy requirement guidelines with additional sensitivity to personal student identifiers and financial data. Particular consideration will be given to the requirements of the Family Educational Rights and Privacy Act (FERPA) with respect to privacy and identity theft.

c. A secure system that offers the flexibility and scalability to function according to program demands and can interface with external entities as needed.

RFP for Maryland Higher Education Commission Page 7 of 126

d. Ensure OSFA and Maryland constituents have access to a comprehensive, high-quality, and efficiently run student aid system.

e. Provide services for Maryland students, institutions, legislators, counselors, and researchers, etc. that meet the demands of access and requirements of reporting.

f. Improve and streamline internal processing functions that will reduce costs and improve overall financial aid delivery.

g. Consolidate and integrate existing independent systems and manual processes.

2. High Level Functions Required to Achieve the Goals Include:

a. Available in Multiple Languages

b. Device independence (desktop, laptop, mobile device)

c. Student Portal Document Tracking

d. Capability for Electronic Signatures

e. Integration of External Systems

f. Multi-Level Communications

g. Built-in User Help Assistance

h. Automated Application Processing

i. Verification Functionality

j. Award Processing Functionality

k. New Maryland Program Additions

l. Billing and Payments Processing

m. Research User Module

n. Document Tracking

o. Student and Data Reporting

p. Internal and External Web Portals

q. Security/Specialized access

r. Cloud Storage

s. Environments

t. Accessibility

u. Data Migration

D. Success Criteria Features Critical Success Factors

Available in Multiple Languages

The Maryland Student Information System (MDSIS) shall be available in multiple languages when accessed by the end user. The language list must be agreed upon and specified before the start of implementation.

Device Dependence (Desktop, Laptop, mobile device)

A mobile application must be built in an extensible manner with human centered design in mind. Users should be able to open the application and see functions which allows them to:

1. Upload documents

2. Review the status of their application

3. Receive alerts on where they are in the process

4. See tasks that are completed, pending or past due

RFP for Maryland Higher Education Commission Page 8 of 126

This application must be compatible with all IOS and Android devices. It should also work with all browsers (Google Chrome, Safari, FireFox, Opera, Microsoft Edge.

Student Portal Document Tracking

Students must be able to view documents sent from OSFA, and documents that are completed, pending, or past due. In addition, students must be able to upload and track their own documents.

Capability for Electronic Signatures

Students and other external users must have the capability to electronically sign documents as needed and required.

Integration of External Applications

The application must have extensive APIs built in to allow integration with 3rd party systems and external systems that the State of Maryland sends or receives files from. This includes the integration of student tax information from the Maryland Comptroller.

Multi-Level Communications Integrated User Interface (UI) tied to all user levels with notification functionality. Users should be able to receive alerts on pending documentation, open tasks, past due tasks, and granted awards.

Built-in User Help Assistance The system must have built-in guidance that describes the application processes using videos, pop-ups, chat-bots, etc.

Automated Application Processing

Application platform that combines adaptive matching and automated communications related to internal award opportunities, creating a fatigue-free experience for all applicants. It must have a good User Interface and be intuitive to the end user

Verification functionality Streamlined automated process with digital workflows that simplifies the process for applicants and provides access to virtual document upload tools as well as corrective action opportunities.

Awarding Process Functionality Automated process which uses calculation settings and equitable formulas designed to provide award packages based on policies and in-built eligibility guidelines. Ability to award, adjust awards, and cancel awards using population selections through batch processes.

New Maryland Program additions

Internal agency users must have functionality available to add/update variables for new legislatively mandated financial aid program(s) using a template or other means to make a new scholarship program effective.

Billing and Payments Allow the State to manage the billing environment - from invoicing and online bill payments to financial reporting and record keeping.

Billing & Payment Features:

1. Batch Entry: Streamline record keeping for payments, etc.

RFP for Maryland Higher Education Commission Page 9 of 126

2. Payments: Design customized payment plans. Apply the appropriate billing plan to all recipients and pre-create their invoices for the entire year. The program emails each appropriate invoice only as it becomes current.

3. Reports: Create invoices, letters, forms, notices, statistical and financial reports, and other documents with the built-in report writer.

4. Future Projections: Project anticipated revenue and expenditure for the year.

5. On-Demand Receipts: Produce daily receipt reports, aging reports, applicant summary statements, and combined invoices.

Research User Module The system must provide the ability for a researcher to have limited sign-on access. There is a requirement for MHEC to share the data with the Maryland Longitudinal Data System Center (MLDSC) for research purposes.

There is a mandate for a MLDSC researcher to produce a report for the General Assembly each year on high school students and their completion of FAFSAs.

1. MDSIS must have a query building tool that allows the extraction of raw data from the system at the student level in a .CSV format.

2. The system must provide the ability to capture variables at the financial aid transaction level associated with decisions made in the administration of aid including:

a. the determination of the eligibility

b. the decision of the student to decline the aid

c. the decision of the student that is ineligible for the aid

d. the characteristics of the student making the award decision.

e. the reason for not collecting aid

f. The student history

3. The system must provide the ability to extract the data (unit data per student) once a year on Maryland High School Students who submit incomplete FAFSAs, completed FAFSAs and the date of the transaction.

4. The system must provide the ability to maintain a change log/audit history table with a date stamp of separate entries for values that are changed for identified fields.

5. The system must provide the ability to accommodate multiple dates for different aid processing stages.

Document Tracking 1. Create a tool to be used to create, process, and track incoming and outgoing communications between the Agency and a variety of constituents. The tool must be designed to capture and store all communication efforts

RFP for Maryland Higher Education Commission Page 10 of 126 from or to an individual or organization occupying the roles such as:

a. Applicant

b. Donor

c. Vendor

d. Delegate

e. Non-profit Organizations

f. High School

2. Requirements

a. Automate outgoing items in a predefined sequence – track required documents to complete the verification process.

b. Create the ability to monitor requested and received incoming items noting when a file is completed. (i.e.

notify students if they are at risk of losing their financial aid for reasons such as poor academic performance).

c. Link related incoming and outgoing communications.

d. Process mailings on an ad-hoc or scheduled basis.

e. Utilize hierarchies to determine the best mail or e-mail address depending on business area or process.

3. MHEC must be able to Import Institutional Student

Information Records (ISIRs) from Federal Student Aid (FSA) using Edconnect Federal software.

4. MHEC must have the ability to Upload multiple ISIRs and select active record

5. MDSIS must have a Document repository

6. MDSIS must offer the ability for the Agency to create document workflows

7. MDSIS must provide the Agency the ability to identify student verification status

8. MDSIS must have a self-service document upload process

– a self-service solution that features several tabs and web forms that guide applicants, step-by-step, through the process for applying for and accepting the financial assistance awards

a. Staff see the same information applicants see—so they can provide relevant, timely support.

b. Displays a financial aid checklist that specifies all the steps and their proper sequence that students need to pursue financial aid in a particular year, including:

i. Receipt of the FAFSA

ii. Any outstanding documents required

iii. Actions the applicant needs to take to proceed through the awarding process

iv. The review status of the application

Student and Data Reporting Provide detailed reporting that provides Agency with clearer insights and analysis of current user data. Simplifies and

RFP for Maryland Higher Education Commission Page 11 of 126 streamlines the process of drawing important insights from disparate data sources.

1. No programming experience required from the End Users.

2. No need to wait for lengthy data draws from technical staff.

3. No precious time wasted on inefficient data aggregation and reporting.

Internal and External Web Portals

An interactive robust web application that enables internal OSFA users as well as external users (students, institutions, legislators, researchers, etc.) to view and interact with their individual information in the databases. Provides visual tools that enable users to complete tasks, such as awarding applicants, updating information, advising applicants, applying for financial assistance programs or submitting documents. Flexible deployment models— managed upgrades and fast access to new functionality to respond to new changes and challenges.

Security/Specialized Access Application shall support Multi-Factor authentication (MFA) for sign-on security and Web Access Firewall to protect the application by monitoring and filtering traffic. The application will be able to grant access based on User Group type and should come with built-in User groups with the option to add more. There will be an Administrative user with user permission features that can preset User types or groups within the application. When looking at an individual user profile, an administrator can change the user’s groups, change the account status, and update basic information about the user. The system will notify users of any changes to their basic information. The application will also provide automated controls for the deactivation of user accounts after a configurable period of inactivity.

Cloud Storage The application should come with Cloud based storage, security, regular backups and a Disaster recovery program. This functionality must be coordinated with the Maryland Department of Information Technology (DoIT).

Environments There should be multiple environments (test, modeling, production) setup as part of the implementation of the application. This gives the team the flexibility to modify, change and promote code for enhancements or modifications to existing features.

Accessibility Enabling access for people with disabilities through the use of assistive technology that supports non-visual Access standards.

Data Migration Migrating data from existing system to new MDSIS application. In addition, system shall have user ability to perform a full or partial import/export of State data on each module of the MDSIS in various formats including CVS and XLS on demand.

RFP for Maryland Higher Education Commission Page 12 of 126

2.2.1 State Staff and Roles

In addition to the Procurement Officer and Contract Monitor, the State will provide the resources below to help support the RFP process:

A. State Project Manager

The State will provide a State Project manager who is responsible for monitoring the daily activities for the development of the project and contract and provides technical guidance to the Contractor.

B. State Business Analyst

The State will provide a State Business Analyst who be responsible for writing and delivering the project requirements and traceability matrix utilized to clarify project deliverables and objectives.

C. State Product Owner

The State will provide a Product Owner who be responsible for maximizing the product’s value and oversees the implementation of the MDSIS application and functionality.

D. Chief Information Officer

The State CIO will oversee the entire Agency project team and assigned Vendor team to ensure that the implementation is going according to plan and allocated budget.

2.2.2 Other State Responsibilities

A. The State will provide normal office working facilities and equipment reasonably necessary for Contractor performance under the Contract.

B. The State is responsible for providing required information, data, documentation, and test data to facilitate the Contractor’s performance of the work.

2.3 Responsibilities and Tasks

2.3.1 Project Development Strategy Requirements

2.3.1.1 The Contractor shall use best practices, including a user interface prototype to better define requirements, daily build and smoke tests, frequent and early user involvement, staged delivery to better access project progress.

2.3.1.2 The MDSIS presents a serious risk to MHEC. If the system is not implemented properly, it will negatively impact all stakeholders and customers. To minimize risks, multiple approaches will be required of the Contractor, such as:

(1) Keeping MHEC Executive Staff abreast of system progress.

(2) Baselining with prior developed systems for a U.S. state higher education agency or a similar COTS basis for MDSIS, to reduce development cost and risk by building upon a tested product.

(3) Using the Maryland SDLC to ensure disciplined development.

RFP for Maryland Higher Education Commission Page 13 of 126

(4) Holding Technical reviews for requirements, design, and code for both development and testing software.

(5) Using testers who are separate from the development team as well as User Acceptance testing.

(6) Staging delivery to drive the system product to a releasable state periodically, to better understand quality and progress of the development process.

(7) Appropriate planning, development of well written requirements specifications and creation of a prototype user interface to better define requirements

(8) Involving users and Q&A early to test user interface prototypes before final release

(9) Testing using live data test sets during development, in parallel to the existing system with Contractor staff on site during testing, if possible.

(10) Scheduling MDSIS to cut-over during the summer months after most awards have been made and accepted or declined for the year. Staff will then need to work on the new test system and perform additional tests to ensure functions are working properly prior to the disbursement cycle.

(11) Training users on MDSIS and providing online manuals prior to each set of User Acceptance Testing (UAT).

(12) Supporting MHEC in conversions as necessary for parallel testing and risk mitigation, (13) and MHEC expects the Contractor to extract data from the existing system to have MDSIS fully functional.

2.3.2 Proposed Project Schedule

The high-level proposed project schedule is shown below:

ACTION ESTIMATED DATE

Estimated Award contract NTP Start work NTP

High-level Steps for Development (Work Plans)

• Requirements Review

• Test Environment

• Delivery of Prototypes

• Documentation

• Training

• User Acceptance Testing (UAT)

• Production Environment Created

• Data Integration

• Testing in Parallel

• Cutover, Compatibility, & Acceptance

NTP+12 Months

System Deployed 07/01/2025

RFP for Maryland Higher Education Commission Page 14 of 126

The proposed schedule for this project is aggressive to ensure the mandated timeline to deploy is met.

2.3.3 Development, Operations and Maintenance Timeline

Once development and implementation is complete and the MDSIS moves to maintenance and operations, the goal is a fixed price method where, the Agency will receive a standard monthly invoice which pays for any maintenance and operations that occur during that period. There will be no Time and Materials associated with this contract. See Figure 5 below for the Contract timeline.

Figure 5: Operations and Maintenance Timeline

Project Section

Development Time

Operations & Maintenance/Optional Renewal Years

1 2 3 4 5

Dates NTP 7/01/25-6/30/26 7/1/26-6/30/27 7/1/27-6/30/28 7/1/28-6/30/29, 7/1/29-6/30/30 Contract/ Payments

During this Time

Fixed Price Fixed Price on Operations

Maintenance

Fixed Price on Operations

Maintenance

Fixed Price on Operations

Maintenance

Fixed Price on Operations

Maintenance

Fixed Price on Operations

Maintenance

2.3.4 Assumptions

2.3.4.1 Assumptions made about task duration, resource availability, milestones, constraints, and optimization criteria are important to note. Current program assumptions include:

(1) The current contractor in place will continue to support the existing financial aid system.

(2) MHEC may use a Contractor with domain expertise to save time, cost and reduce risk.

(3) Total number of scholarships and aid programs stays relatively the same.

(4) Requirements creep is minimal.

(5) Testing and documentation start with the user interface prototype.

(6) RFP cycle is completed and the Contractor starts work at NTP.

(7) Project takes 12 months to complete.

(8) Data will be compatible between the existing financial aid system and

MDSIS.

2.3.5 Implementation Requirements

The Agency is using this RFP process to obtain a Contractor, preferably with domain experience, in 2024 to develop the MDSIS. The Contractor will be responsible for complete development of the system from requirements analysis through implementation in accordance with Maryland’s SDLC. This project is associated with a legislative mandate to include high level functions of the system (see Section 2.2.C.2).

The first operation and maintenance year includes a system warranty. The contract includes an additional four (4) years of renewal options for operations and maintenance support exercisable at the State’s discretion.

RFP for Maryland Higher Education Commission Page 15 of 126

The plan for system functionality can be delivered iteratively in stages based on an agreed upon approach between the Agency and the Contractor. The mandated timeline for completion is 07/01/2025. MHEC’s Project Manager will work directly with the Contractor’s Project Manager and other Contractor personnel to ensure timelines are met.

2.3.6 Contractor-Supplied Hardware, Software, and Materials

A. By responding to this RFP and accepting a Contract award, the Offeror specifically agrees that for any software, hardware or hosting service that it proposes or recommends, the State will have the right to use hosting services provided by the Department of Information Technology (DoIT) or purchase such item(s) from another source, instead of from the selected Offeror. Hardware and software related to MDSIS must be:

1. Consistent with applicable laws, regulations, and Agency and State policy and guidance.

2. Directly support MHEC missions and programs.

3. Unique, not redundant or duplicative in efforts.

B. The MDSIS shall be a cloud-based solution accessible from various client devices through a thin client interface such as a Web browser (e.g., Web-based email) or a program interface.

See also RFP Section 2.2D

C. The Contractor is responsible for coordination of the acquisition and operation of all hardware, software and network support with DoIT related to the services being provided, and shall keep all software current.

D. All Upgrades and regulatory updates shall be provided at no additional cost.

E. The Offeror shall provide all documentation, including but not limited to operational and user manuals for each portal user, for the software furnished under the Contract.

F. The warranty period of one (1) year for goods and services will not commence until acceptance of the MDSIS by the Agency. Notwithstanding anything to the contrary, all defective items must be replaced at no additional cost to the State.

2.3.7 Required Project Policies, Guidelines and Methodologies

The Contractor shall comply with all applicable laws, regulations, policies, standards and guidelines affecting Information Technology projects, which may be created or changed periodically. Offeror is required to review all applicable links provided below and state compliance in its response.

It is the responsibility of the Contractor to ensure adherence and to remain abreast of new or revised laws, regulations, policies, standards and guidelines affecting project execution. These include, but are not limited to:

A. The State of Maryland System Development Life Cycle (SDLC) methodology at:

http://doit.maryland.gov/SDLC/Pages/agile-sdlc.aspx ;;

B. The State of Maryland Information Technology Security Policy and Standards at:

http://www.DoIT.maryland.gov- keyword: Security Policy;

http://www.doit.maryland.gov/

RFP for Maryland Higher Education Commission Page 16 of 126

C. The State of Maryland Information Technology Non-Visual Standards at:

http://doit.maryland.gov/policies/Pages/ContractPolicies.aspx;

D. The State of Maryland Information Technology Project Oversight at:

http://doit.maryland.gov/epmo/Pages/ProjectOversight.aspx;

E. The Contractor shall follow project management methodologies consistent with the most recent edition of the Project Management Institute’s Project Management Body of Knowledge Guide.

2.3.8 Product Requirements

A. Offerors may propose open source software; however, the Offeror must include operational support for the proposed software as part of its Proposal.

B. Offeror shall be authorized to furnish the proposed goods and services. Offerors proposing to resell services of another entity must be authorized by such other entity (See RFP Section 5.3.2.)

C. No international processing for State Data: As described in Section 3.7 Security Requirements, Offerors are advised that any processing or storage of data outside of the continental U.S. is prohibited.

D. Offeror consistent expiration dates: A PO for a service already being delivered to the Agency under the Contract shall terminate on the same calendar day as the prior product/service. As appropriate, charges shall be pro-rated.

E. Any Contract award is contingent on the State’s agreement, during the Proposal evaluation process, to any applicable terms of use and any other agreement submitted under Section 5.3.2. Such agreed upon terms of use shall apply consistently across services ordered under the Contract.

F. The Contractor shall not establish any auto-renewal of services beyond the period identified in Contract documents.

G. In addition to any notices of renewal sent to the Agency, Contractors shall email notices of renewal to the e-mail address designated by the Contract Monitor.

2.3.9 Maintenance and Support

Maintenance and support, and Contractor’s ongoing maintenance and support obligations, are defined as follows:

A. Maintenance commences following the State’s acceptance and Go-Live of the

MDSIS.

B. Software maintenance includes all future software updates and system enhancements applicable to system modules licensed without further charge to all licensed users maintaining a renewable software support contract.

C. Support shall be provided for superseded releases and back releases still in use by the State.

D. For the first year and all subsequent Contract years, the following services shall be provided for the current version and one previous version of any Software provided with the Deliverables, commencing upon NTP date.

RFP for Maryland Higher Education Commission Page 17 of 126

1) Error Correction. Upon notice by State of a problem with the Software (which problem can be verified), reasonable efforts to correct or provide a working solution for the problem.

2) Material Defects. Contractor shall notify the State of any material errors or defects in the Deliverables known, or made known to Contractor from any source during the life of the Contract that could cause the production of inaccurate or otherwise materially incorrect results. The Contractor shall initiate actions as may be commercially necessary or proper to effect corrections of any such errors or defects.

3) Updates. Contractor will provide to the State at no additional charge all new releases and bug fixes (collectively referred to as “Updates”) for any software Deliverable developed or published by the Contractor and made available to its other customers.

4) Maintenance and Enhancements. Contractor will be responsible for maintenance of the software as specified and required by the State.

E. Operations tasks to include all state-utilized cybersecurity measures provided by the DoIT Office of Security Management.

F. Activity reporting.

G. User support (Help Desk)

1. Contractor shall furnish Help Desk services for the Agency with a goal to integrate with the DoIT ServiceNow instance.

2. Help Desk services are available during Normal State Business Hours.

Help Desk services shall be furnished using resources familiar with the State’s account.

3. Contractor shall utilize a help desk ticketing system to record and track all help desk calls. The ticketing system shall record with a date and timestamp when the ticket was opened and when the ticket was closed.

2.3.9.1 Technical Support

A. “Technical Support” means Contractor-provided assistance for the services or Solution furnished under the Contract, after initial end-user support confirms a technical issue that requires additional troubleshooting capabilities; sometimes referenced as Tier II – IV support.

B. Technical Support shall be available during Normal State Business Hours.

C. The State shall be able to contact a Technical Support team member 24 hours per day, 7 days per week, 365 days per year.

D. Contractor Personnel providing technical support shall be familiar with the State’s account (i.e., calls shall not be sent to a general queue).

E. Contractor shall return calls for service of emergency system issues (see Section 0 Service Level Agreement) within one (1) hour.

F. Calls for non-emergency IT service requests will be returned within three (3) hours or immediately the following day if after Normal State Business Hours.

RFP for Maryland Higher Education Commission Page 18 of 126

G. The State shall be provided with information on software problems encountered at other locations, along with the solution to those problems, when relevant to State software.

2.3.9.2 Backup

A. The Department of Information Technology (DoIT) will be hosting MDSIS and will therefore handle backup activity.

B. The Contractor must work in coordination with DoIT for backup activity as needed.

2.4 Deliverables

A. Project Implementation Plan and Schedule: The Contractor shall develop and deliver a

Project Implementation Plan and Schedule to the Contract Manager to cover the student information system implementation period. This plan will be reviewed on a weekly basis.

B. Requirements: The Contractor shall gather and document detailed technical system requirements and provide to the Contract Manager a Requirements Validation Report. The Report must address: A. Technical design documents B. Functional design documents C.

Installation and configuration D. Security requirements and approach for applications, data, and user access E. Performance capacity – includes number of users, concurrent users, number of transactions to be handled.

C. Software Configuration and/or Customization: The Contractor shall develop and manage all configuration/customization and installation activities against a detailed specification and requirements document. The detailed specification and design plan will address all the data, functional, interface, and technical requirements included in this RFP at a detailed level.

D. Change Management: Detailed document that describes the stakeholder engagement approach for the implementation of the MDSIS solution. This should have the list of stakeholders, stakeholder engagement plan and this should address any variance to the agreed on project scope, budget or assigned resources.

E. Testing: The Contractor shall complete system testing activities in accordance with the Requirements documentation. The Contractor shall provide an updated Business Needs Analysis, design documentation and test report at the conclusion of testing. The overarching responsibility for testing resides with the Contractor. Testing activities will include, but not be limited to: production problem research and resolution; development testing; application vulnerability analysis and testing; validation of software patches and fixes before promoting in production; testing the validation of edits and updates; support for System and user acceptance testing; business continuity testing. The testing must include unit, System integration, regression, parallel and user acceptance testing as appropriate.

F. Implementation: The Contractor shall complete System implementation in accordance with the DoIT SDLC process: https://doit.maryland.gov/SDLC/Pages/templates-phases.aspx

System implementation includes:

1) System installation and production readiness testing

2) User acceptance testing

3) Quality assurance testing

4) Training (end use and trainer)

5) Go-live implementation https://doit.maryland.gov/SDLC/Pages/templates-phases.aspx

RFP for Maryland Higher Education Commission Page 19 of 126

6) System stabilization

7) Final implementation documents

8) Anticipated Timing (see below)

At the conclusion of MDSIS implementation, the Contractor shall deliver all remaining components outlined in the System Testing Report and any updates to MDSIS components delivered after user acceptance testing (UAT).

G. Training: The Contractor shall provide training for the users of the MDSIS. The Contractor shall provide a training program that addresses the training requirements of all defined user type/roles.

2.4.1 Deliverable Submission

A. For every deliverable, the Contractor shall request the Contract Monitor confirm receipt of that deliverable by sending an e-mail identifying the deliverable name and date of receipt.

B. For every deliverable, the Contractor shall submit to the Contract Monitor, by e-mail, an Agency Deliverable Product Acceptance Form (DPAF), an example of which is provided on the DoIT web page here:

http://doit.maryland.gov/contracts/Documents/_procurementForms/DeliverableProd uctAcceptanceForm-DPAFsample.pdf.

C. Unless specified otherwise, written deliverables shall be compatible with Microsoft Office, Microsoft Project or Microsoft Visio within two (2) versions of the current version. At the Contract Monitor’s discretion, the Contract Monitor may request one hard copy of a written deliverable.

D. A standard deliverable review cycle will be elaborated and agreed-upon between the State and the Contractor. This review process is entered into when the Contractor completes a deliverable.

E. For any written deliverable, the Contract Monitor may request a draft version of the deliverable, to comply with the minimum deliverable quality criteria listed in Section 2.4.3 Minimum Deliverable Quality. Drafts of each final deliverable, except status reports, are required at least two weeks in advance of when the final deliverables are due (with the exception of deliverables due at the beginning of the project where this lead time is not possible, or where draft delivery date is explicitly specified). Draft versions of a deliverable shall comply with the minimum deliverable quality criteria listed in Section 2.4.3 Minimum Deliverable Quality.

2.4.2 Deliverable Acceptance

A. A final deliverable shall satisfy the scope and requirements of this RFP for that deliverable, including the quality and acceptance criteria for a final deliverable as defined in Section 2.4.4 Deliverable Descriptions/Acceptance Criteria.

B. The Contract Monitor shall review a final deliverable to determine compliance with the acceptance criteria as defined for that deliverable. The Contract

RFP for Maryland Higher Education Commission Page 20 of 126

Monitor is responsible for coordinating comments and input from various team members and stakeholders. The Contract Monitor is responsible for providing clear guidance and direction to the Contractor in the event of divergent feedback from various team members.

C. The Contract Monitor will issue to the Contractor a notice of acceptance or rejection of the deliverable in the DPAF (see online sample).