EOED OneStop Grant Management RFR Final.docx

REQUEST FOR RESPONSE

[EOED OneStop Grant Management System RFR] RFR #______ / COMMBUYS Bid# ______

ISSUE DATE: 7/24/2026

1. Description or Purpose of Procurement:

The Massachusetts Executive Office of Economic Development (EOED) is responsible for advancing economic growth, job creation, and equitable development across the Commonwealth. EOED works in partnership with state agencies, quasi-public entities, municipalities, regional organizations, and the private sector to strengthen the Commonwealth’s economy and support communities of all sizes.

EOED has two flagship grant initiatives include the Community One Stop for Growth (“One Stop”) and the Business Front Door (“BFD”). The EOED portfolio also includes various grant programs run through the Executive Office, agencies and quasi-public agencies.

The primary users of this new system will be the flagship initiatives of the One Stop and the BFD. These teams run coordinated, cross-agency efforts to streamline access to state economic development, business and community investment programs for municipalities, not for profits, businesses and other eligible applicants. The initiatives provide a unified application and review process across multiple state agencies and authorities, enabling applicants to submit a single application for consideration across a range of funding programs. EOED manages the overall processes, including application intake, interagency coordination, review, and award recommendations, while participating agencies retain responsibility for program-specific requirements and grant administration. These initiatives are currently supported by a legacy grants management systems (IGX and Salesforce, respectively) that have become increasingly constrained as the program has grown, highlighting the need for a more flexible, scalable solution with enhanced user experience, reporting, and integration capabilities.

In addition to the One Stop and the BFD, EOED administers a diverse portfolio of grant, incentive, and other support programs that advance a wide range of economic development activities, including business growth and workforce development. These programs serve a broad set of applicants and stakeholders, including municipalities, businesses, and nonprofit organizations, and are delivered through multiple divisions, partner agencies, and engagement channels. These engagement channels further underscore the need for systems that support coordinated intake, data sharing, and seamless user experiences across EOED programs.

Despite these coordinated entry points, programs across EOED’s portfolio vary in structure, scale, and statutory requirements, and often operate with distinct application processes, eligibility criteria, timelines, and reporting requirements. While these approaches reflect program-specific needs, they also create opportunities to improve consistency, efficiency, and coordination across EOED’s portfolio, particularly in how applicants and businesses access, navigate, and engage with available resources.

EOED seeks a solution to serve as a full-lifecycle grants management system for EOED, establishing a new platform for the One Stop and the BFD while also supporting other grant and investment programs across EOED’s portfolio. The solution is intended to reduce fragmentation across systems, improve data consistency, and enable enterprise-wide reporting, coordination, and strategic decision-making. It must support diverse program structures and user groups within a unified platform while enabling flexible, program-specific workflows, interfaces, and entry points as appropriate, and ensuring interoperability with existing and future EOED and Commonwealth systems.

a. Procurement Overview EOED is issuing this RFR to solicit proposals from qualified Bidders to provide and implement a commercial-off-the-shelf (COTS), cloud-based grants management system, including all required software licenses, maintenance and support, training, and documentation (collectively, the “Software”). For the purposes of this RFR, “COTS” refers to a vendor-supported, pre-configured software product that is purpose-built for grants management and delivered as a standardized solution across multiple customers.

The Software will serve as a full-lifecycle, enterprise grants management platform for EOED, supporting the One Stop, the BFD, as well as additional grant and investment programs across the agency’s broader portfolio. The selected solution must be capable of accommodating diverse program structures, statutory requirements, and user groups, while enabling program-specific configurations, workflows, and user experiences, including distinct portals or entry points where appropriate.

EOED seeks a solution that supports configurable workflows, advanced automation, robust data analytics, and a modern, intuitive interface for both applicants and staff. The system must enable seamless coordination across agencies and programs, reduce fragmentation across existing tools, and improve consistency in application intake, review, award management, and reporting. This procurement reflects EOED’s commitment to continuous improvement and to ensuring that the technology supporting the One Stop, BFD, and EOED’s broader portfolio aligns with current best practices and Commonwealth’s long-term digital strategy.

EOED strongly prefers solutions that are natively designed for grants management and require minimal custom development. EOED expects that the majority of required functionality is delivered through native, out-of-the-box product capabilities rather than custom-developed features. Solutions requiring substantial custom development, including implementations built on general-purpose platforms, will be considered less responsive to this RFR and may receive lower evaluation scores.

b. Functionality and Business Requirements The selected Software will support the end-to-end administration of grants and related program processes, including application intake, review and scoring, award decisions, contracting, grant administration, reporting, and closeout. EOED seeks a solution that improves the usability and accessibility of its programs for applicants while increasing efficiency, consistency, and transparency for EOED staff and participating agencies.

The Software must provide an intuitive applicant experience and configurable tools for staff to manage applications, reviews, awards, contracts, and grant data. EOED seeks a scalable, vendor-supported solution that reduces manual processes, drives efficiencies through artificial intelligence, and can adapt to evolving program needs.

Specifically, EOED seeks a solution that includes the following capabilities:

· Portal Interface

· Software must allow EOED staff to configure most, if not all, portal components, workflows, and user-facing content within a configuration-driven, not development-driven, environment.

· Software must comply with the Commonwealth’s Enterprise Digital Accessibility Policy.

· Software must use a custom domain that is compliant with the Commonwealth’s Website Domain Policy.

· Software must meet all applicable Commonwealth and EOED security standards.

· Software must adhere to the Commonwealth’s design standards.

· Software must have an intuitive, user-centered, and easy to navigate interface for both external applicants and internal staff.

· Software must support responsive design across modern browsers and devices.

· Application Configuration

· Software must allow EOED to configure the application content, workflows, and validation rules within a configuration-driven, not development-driven, environment, with support for advanced configurations when requested.

· Software must support complex conditional logic based on single or multiple prior responses.

· Software must support data-driven logic, including configurable data table lookups and rule-based triggers.

· Software must allow EOED staff to manage the custom data tables.

· Software must allow EOED staff to open and close application submission periods without additional support.

· Application User Experience

· Software must support automatic draft saving and collaborative drafting by multiple users within the same organization.

· Software must allow upload of multiple and large file attachments.

· Software must generate clean, formatted PDF or export versions of submitted applications.

· Application Review

· Software must allow program staff to create configurable review forms, scoring criteria, and weighting methodologies.

· Software must support assignment of applications to specific reviewers and/or reviewer groups.

· Software must support assignment of a single application to multiple programs.

· Should support automated routing and assignment to programs, with the ability for manual override.

· Software must allow program staff to assign applications to individual reviewers within their respective groups.

· Software must support the creation of sub-groups within review structures, as needed.

· Software must enable reviewers to view the application and associated review form side by side within a single interface.

· Software must automatically aggregate scores by program, maintaining separate scoring records where multiple programs review the same application.

· Application Approval

· Software must support configurable, multi-level approval workflows (e.g., Program Review → Agency Review → Secretariat Review → Governor Approval).

· Software must provide administrators with a comprehensive, real-time view of recommendations and approval status across all levels.

· Software must allow EOED to create and send automated award decision notifications with customizable, data-populated templates.

· Grant Award Management

· Software must allow programs to create grant agreement templates within the system that can then be populated with applicant information to send for execution.

· Software must allow EOED to create, manage, and track contract amendments.

· Software must include legally binding electronic signature capability for award letters, grant agreements, and other documents.

· Software must allow the grantee to upload reimbursement requests and other required documents directly through the system.

· Software must allow EOED to create workflows to manage disbursement requests.

· Software must allow for budget, payment, reimbursement, and disbursement tracking at both the grant and portfolio levels.

· Software must allow for direct connection between grant awards and outcomes reporting, allowing impact metrics to be associated with individual grants.

· Account Registration and Management

· Software must support applicant authentication through the Commonwealth’s MyMass.gov single sign-on (SSO) system.

· Software must support internal user authentication through the Commonwealth’s single sign-on (SSO) system.

· Software must support organizational account structures with configurable, role-based permissions and security controls.

· Software must allow organization profiles to be configured by organization type.

· Software should allow for organizations and user accounts from the legacy system to be prepopulated and later claimed by users.

· Software must support distinct user experiences for different external users and internal roles.

· Software must include a configurable account/organization registration process that is intuitive and easy to use for users.

· Software must include duplicate organization and user detection functionality.

· Software must have an intuitive process to allow applicant organization administrators to add new members to an organization.

· Software must include secure user account emulation capability for authorized administrators for troubleshooting purposes.

· CRM Capabilities

· Software must allow EOED to configure and manage comprehensive organization profiles within a configuration-driven, not development-driven, environment.

· Software must provide a consolidated, 360-degree view of each organization, including:

· Current and historical applications

· Awards and amendments

· Spending and reimbursement requests

· Reporting status and compliance history

· Communications history

· Software must allow staff to track total funding awarded to an organization across programs and fiscal years.

· Software must allow direct communication with organizations through the portal and keep a record of all correspondence.

· Software must allow authorized staff to create and maintain internal notes associated with organization records.

· Software must allow documents to be uploaded to organization profiles, including external email correspondence.

· Software should support the ability to import application data from the legacy system and tie that data to the respective organization profile.

· Software must support role-based access controls to manage visibility of organization data across programs and agencies, as appropriate.

· Interoperability and Data Standards The Software must support seamless, secure, and scalable integration with external systems, enabling real-time data exchange and coordinated user experiences across EOED platforms and partner systems. The solution should align with the Commonwealth’s enterprise architecture principles and support both current and future integration needs. Specifically, EOED seeks a solution with the following capabilities:

· Standards-Based Integration Architecture

· Software must provide robust, well-documented, and versioned RESTful APIs (and/or equivalent modern integration methods) to support secure, real-time data exchange.

· Software must support industry-standard data formats and integration protocols.

· Software must be designed with an extensible architecture that allows for integration with additional systems without significant custom development.

· System Integration Capabilities

· Software must support seamless workflow and data integration with existing EOED and Commonwealth systems, including but not limited to Salesforce, Submittable, AWS-based tools, and Microsoft platforms.

· Software must support data integration with Commonwealth data platforms and reporting tools (e.g., Snowflake, Power BI, ArcGIS, Tableau).

· Software must support user experience integrations with EOED-developed tools, including the One Stop Expression of Interest AI tool and the Business Front Door front-end and back end through salesforce.

· Identity and Access Interoperability

· Software must support secure exchange of authenticated user attributes with external systems, enabling trusted user identity to be recognized across platforms.

· Software should support industry-standard identity federation protocols.

· Cross-System Workflow Initiation

· Software must support the ability for external systems to initiate specific user workflows (e.g., application intake processes) through secure, parameterized links, API calls, or embedded components.

· Software must support the passing of contextual parameters (e.g., user, organization, or program identifiers) to enable continuity of user experience across systems.

· Software must maintain appropriate session continuity or re-authentication handling consistent with Commonwealth security standards.

· Data Exchange and Pre-Population

· Software must support the secure ingestion of data from external systems to pre-populate application forms and other records.

· Software must allow configurable field mapping between external data sources and system data fields.

· Software must include validation controls to ensure data integrity and allow user review and confirmation prior to submission.

· Outbound Data Sharing and Synchronization

· Software must support real-time or near real-time sharing of application data, status updates, and key record information with external systems.

· Software must support both event-driven (e.g., webhooks) and request-based (API) data exchange mechanisms.

· Software must allow EOED to configure which data elements are shared with external systems and under what conditions.

· External System Alignment

· Software must support bi-directional data exchange with external CRM platforms, including synchronization of organization records, application data, and status updates.

· Software should support standard CRM integration patterns and tools to minimize custom development and ensure maintainability.

· Data Management and Standards

· API capabilities must support the programmatic creation, retrieval, update, and deletion (CRUD) of core system entities, including organizations, users, applications, grants, and reports.

· Software must support consistent data structures and standards to enable reliable integration and reporting across systems.

· Software must support bulk data import and export capabilities.

· Security and Governance

· All integrations must comply with Commonwealth security standards, including encryption of data in transit and at rest.

· Software must enforce role-based access controls governing data access and system interactions.

· Software must maintain detailed audit logs of all integration activity, including inbound and outbound data exchanges.

· Software must maintain detailed, immutable audit trails capturing user actions, including system activities, record changes, workflow actions, approval history, and integration activity.

· Audit logs must support reporting, filtering, export, and retention consistent with Commonwealth recordkeeping and security requirements.

· Scalability and Future Integration

· Software must be capable of supporting additional integrations with future systems and platforms without requiring significant re-architecture.

· Software should support modular integration approaches to allow EOED to incrementally expand its technology ecosystem.

· Automation & AI Capabilities

· Software must support AI integration.

· Software must include AI capabilities to summarize application and other information.

· Software should support AI-assisted tagging of organization or grant records

· Software should support configurable AI tools to assist reviewers in comparing applications against scoring criteria.

· Software should allow tagging, categorization, and auto-classification of organizations and applications.

· Software must clearly identify AI-generated outputs and allow human review and override.

· Software must include configurable workflow automation tools.

· Software should support ongoing AI model updates and performance improvements without disrupting system operations.

· Communications

· Software must allow both mass communications as well as direct communications through the system.

· Software should allow for automated emails to be sent through Commonwealth (mass.gov) email addresses and domains.

· Software must have ability to save and reference communications at the organization level.

· Software must have ability to create automated notifications to alert users of upcoming due dates and other critical reminders.

Reporting & Dashboards

· Software must include built-in reporting tools and configurable dashboards.

· Software must allow for both simple and complex data reporting without external integration or complex programming.

· Software must allow data to be represented through a variety of graphs and charts.

· Software should support drill down functionality within graphs and charts.

· Software must allow Ad hoc reporting capabilities for authorized users.

· Software must allow dashboards to be configured for different roles.

· Software must allow for aggregate KPI/outcomes reporting across programs.

· Software must allow customized downloads of reports into multiple formats (i.e., PDF, XLSX, CSV, etc.).

As indicated above, the Software will be used by both internal, administrative users as well as external applicants and grantees. EOED estimates the following volumes of users:

Internal Admin Access

External Grantee Access

2. Applicable Procurement Law

Executive Branch Goods and Services

3. Acquisition Method:

4. Whether Single or Multiple Contractors are Required for Contract:

Check One (“X”):

a. Estimated Number of Awards The target maximum number of Contractors is one the Purchasing Department may award more or fewer contracts, if it is in the best interests of the Commonwealth to do so.

b. Adding Contractors after initial Contract Award If, over the life of the contract, the Purchasing Department determines that additional Contractors may be added, these may be drawn from qualified companies that responded to this Solicitation and not awarded Contracts. If necessary to meet the requirements of the Commonwealth, the Solicitation may be reopened to obtain additional Bids.

5. Entities Eligible to Use the Resulting Contract:

· Office of Consumer Affairs

6. Expected Duration of Contract (Initial Duration and any Options to Renew):

Initial Duration

One-year (1) and four (4) months with an initial expiration date of 6/30/2027

Total Maximum Contract Duration

June 30th, 2031

7. Contract Performance and Business Specifications:

a) Scope of Services: The scope of this procurement includes the initial implementation and ongoing maintenance, support, and enhancement of the Software, including all required software licenses, hosting, maintenance and support, training, and documentation. The selected Contractor will be expected not only to deploy the Software, but to provide sustained operational and development support to ensure the platform continues to evolve in alignment with EOED’s programmatic, technical, and regulatory needs.

This includes:

· Professional services associated with implementation, including installation, configuration, system design, development, quality assurance, testing, data conversion and migration, integration, and other related services necessary to achieve a fully operational production environment.

· Managed services associated with ongoing hosting, storage, security management, help desk operations, troubleshooting, system upgrades, and performance monitoring.

· Ongoing development and configuration support to accommodate complex enhancements, evolving business requirements, new program additions, cross-agency coordination needs, reporting modifications, automation improvements, and other iterative system refinements. EOED anticipates that the Software will require periodic reconfiguration and structured enhancement releases to support continuous improvement of program processes.

Additionally, EOED is seeking comprehensive training services and materials for both internal and external users, including the training of at least two internal staff members to deliver future training and support. Ongoing help desk services must provide timely technical assistance to applicants during application submission and to EOED and participating agencies in connection with review, reporting, compliance, and data extraction activities.

b) Project Timeline The project is expected to follow the timeline below:

c) Technical Requirements The Bidder's proposed Software should meet all the requirements specified in:

1. SaaS Terms: Attachment G-1 for Bidders on ITS60, or Attachment G-2 for Bidders on ITS75 or partnering with ITS75 Resellers

2. Enterprise Information Security Standards and Policies as referenced in Section V (A)

3. Accessibility for IT Solutions Contract Language as referenced in Section V (C) Additionally, Bidder Software should support:

1. Mobile Ready Design and Access Software should be mobile-ready and user-friendly via web browsers on phones, tablets, and other devices in addition to personal computers and laptops. The Software should be able to be accessed through today's leading web browsers, including, but not limited to Google Chrome, Safari, and Microsoft Edge.

2. Enterprise Services The Commonwealth is transitioning from siloed, application-centric, and agency-centric IT investments to an enterprise approach. The Software should implement an extensible, flexible, scalable, and secure architecture on a platform that uses industry standards and standardized integration points. To promote the reuse and sharing of services across the Commonwealth, the Software effort may leverage existing and emerging components and services.

Fiscal Terms:

BILLS MUST BE PAYABLE IN ACCORDANCE WITH CTR’S BILL PAYMENT POLICY);

COMMONWEALTH IS TAX EXEMPT, PROMPT PAYMENT DISCOUNTS AND/OR NET TERMS ARE REQUIRED)

8. Small Business Purchasing Program Program Background The Massachusetts Small Business Purchasing Program (SBPP) was established pursuant to Executive Order 599to increase state contracting opportunities with small businesses having their principal place of business within the Commonwealth of Massachusetts. Pursuant to the SBPP, it is the intention of the issuing department to award this Small Procurement to one or more SBPP participating business(es) as described below.

SBPP Award Preference While all businesses, no matter the size or principal place of business, may submit responses to this solicitation, should an SBPP participant respond and meet the best value criteria as described in this solicitation, the SBPP participant shall be awarded the contract. The Strategic Sourcing Services Team (SSST) will not evaluate submissions from non-SBPP participants unless no SBPP Bidder meets the SSST’s best value evaluation criteria.

SBPP Participation Eligibility To be eligible to participate in this procurement as an SBPP participant, an entity must meet the following criteria, and be marked as an SBPP-registered business in COMMBUYS:

1. Have its principal place of business in the Commonwealth of Massachusetts;

2. Been in business for at least one year;

3. Employ a combined total of 50 or fewer full-time equivalent employees in all locations, or employees work less than a combined total of 26,000 hours per quarter; and

4. Have gross revenues, as reported on appropriate tax forms, of $15 million or less, based on a three-year average.

Non-profit firms also must be registered as a non-profit or charitable organization with the MA Attorney General’s Office and be up to date with all filings required by that office and be tax exempt under Section 501(c) of the Internal Revenue Code.

SBPP Compliance Requirements It is the responsibility of the Bidder to ensure that their SBPP status is current at the time of submitting a response and throughout the life of any resulting contract. Misrepresentation of SBPP status will result in disqualification from consideration, and may result in debarment, contract termination, and other actions. To learn more about the SBPP, including how to apply, visit the SBPP Webpage.

Program Resources and Assistance Bidders and Contractors seeking assistance regarding SBPP may visit the SBPP webpage, http://www.mass.gov/sbpp, or contact the SBPP Help Desk at sbpp@mass.gov.

9. Supplier Diversity Plan (SDP) Plan Program Background Pursuant to Executive Order 599 the Commonwealth’s Supplier Diversity Program (SDP) promotes business-to-business relationships between awarded Contractors and diverse businesses and non-profit organizations (“SDP Partners”) certified or recognized (see below for more information) by the Supplier Diversity Office (SDO).

All Bidders and Contractors are strongly encouraged to create a profile on the SDO’s Supplier Diversity Hub to access the Commonwealth’s supplier diversity resources and tools.

Financial Commitment Requirements All Bidders responding to this solicitation are required to make a significant financial commitment (“SDP Commitment”) to partnering with one or more SDO-certified or recognized diverse business enterprise(s) or non-profit organization(s). This SDP Commitment must be expressed as a percentage of contract sales resulting from this solicitation that would be spent with the SDP Partner(s).

After contract award (if any), the Total SDP Commitment shall become a contractual requirement to be met annually on a Massachusetts fiscal year basis (July 1 – June 30) for the duration of the contract. The minimum acceptable Total SDP Commitment in response to this solicitation shall be 1%. Bidders shall be awarded additional evaluation points for higher SDP Commitments.

No contract shall be awarded to a Bidder without an SDP Commitment that meets the requirements stated herein. This requirement extends to all Bidders regardless of their own supplier diversity certification.

Eligible SDP Partner Certification Categories SDP Partners must be business enterprises and/or non-profit organizations certified or recognized by the SDO in one or more of the following certification categories:

· Minority-Owned Business Enterprise (MBE)

· Minority Non-Profit Organization (M/NPO)

· Women-Owned Business Enterprise (WBE)

· Women Non-Profit Organization (W/NPO)

· Veteran-Owned Business Enterprise (VBE)

· Service-Disabled Veteran-Owned Business Enterprise (SDVOBE)

· Disability-Owned Business Enterprise (DOBE)

· Lesbian, Gay, Bisexual, and Transgender Business Enterprise (LBGTBE) Eligible Types of Business-to-Business Relationships Bidders and Contractors may engage SDP Partners as follows:

· Subcontracting, defined as a partnership in which the SDP partner is involved in the provision of products and/or services to the Commonwealth.

· Ancillary Products and Services, defined as a business relationship in which the SDP partner provides products or services that are not directly related to the Contractor’s contract with the Commonwealth but may be related to the Contractor’s own operational needs. These may include but are not limited to the following examples: professional services (e.g., IT, legal, advertising, HR, accounting etc.), maintenance services (e.g., cleaning, landscaping, tradespersons services, etc.), office expenses (e.g., office supplies, furniture, IT supplies, etc.). Anything declared as a business expense in which a certified vendor is used would qualify.

Other types of business-to-business relationships are not acceptable under this contract. All provisions of this RFR applicable to subcontracting shall apply equally to the engagement of SDP Partners as subcontractors.

Program Flexibility The SDP encompasses the following provisions to support Bidders in establishing and maintaining sustainable business-to-business relationships meeting their needs:

· SDP Partners are not required to be subcontractors.

· SDP Partners are not required to be Massachusetts-based businesses.

· SDP Partners may be changed or added during the term of the contract, provided the Contractor continues to meet its SDP Commitment.

SDP Plan Form Requirements All Bidders must complete the SDP Plan Form included in this solicitation and attach it to their bid response. In addition to proposing an SDP Commitment, each Bidder must propose one or more SDP Partner(s) to utilize to meet its SDP Commitment. Certified diverse Bidders may not list their own companies, their subsidiaries, or affiliates, as SDP Partners and may not meet their SDP Commitment by spending funds internally or with their own subsidiaries or affiliates.

Bidders may propose SDP Partners that are:

· Certified or recognized by the SDO: Such partners appear in the SDO Directory of Certified Businesses or in the SBA Veteran Small Business Certification (VetCert) directory. After contract award (if any), spending with such partners will contribute to meeting the Contractor’s SDP Commitment.

· Certified by one of SDO’s recognized third-party certification bodies but not yet listed in the SDO Directory of Certified Businesses: Such partners must be certified in eligible categories by one of SDO’s recognized third-party certification bodies, which include the City of Boston, the Greater New England Minority Supplier Development Council (GNEMSDC), the Center for Women & Enterprise (CWE), Disability: IN, National LGBT Chamber of Commerce (NGLCC), or the National Veteran Owned Business Association (NaVOBA) but have not yet opted to be listed in the SDO Directory of Certified Businesses. In order to opt into SDO’s Directory of Certified Businesses, the SDP partner must follow the applicable expedited instructions on SDO’s Apply for Recognition as a Third-Party Certified Business webpage. Self-certification is not acceptable. While Bidders may list such proposed SDP Partners on their SDP Plans, spending with such partners will not contribute to meeting the Contractor’s SDP Commitment unless they apply for and are granted SDO supplier diversity certification or recognition. If proposed SDP Partners do not receive SDO supplier diversity certification or recognition, the Contractor must find alternative SDP Partners to meet the SDP Commitment.

· Not yet certified or recognized by the SDO or one of SDO’s recognized third-party certification bodies: Such partners must be certified in eligible categories by other third-party certification bodies that are not yet recognized by the SDO, such as another city or state supplier diversity certification office, the National Minority Supplier Development Council, or the Women Business Enterprise National Council, but are not listed in the above-mentioned directories. Self-certification is not acceptable. While Bidders may list such proposed SDP Partners on their SDP Plans, spending with such partners will not contribute to meeting the Contractor’s SDP Commitment unless they apply for and are granted SDO supplier diversity certification or recognition. If proposed SDP Partners do not receive SDO supplier diversity certification or recognition, the Contractor must find alternative SDP Partners to meet the SDP Commitment.

It is the responsibility of the Contractor to ensure that their proposed SDP Partners obtain such certification or recognition by the SDO after contract award (if any). The issuing department and the SDO will not conduct outreach to proposed SDP Partners to ensure their certification. Furthermore, no guarantee may be made that a proposed SDP Partner will be certified, or regarding the time it may take to process a proposed SDP Partner certification. Contractors may direct partners to the SDO’s homepage, www.mass.gov/sdo and the Certification Self-Assessment Tool for guidance on applying for certification.

It is desirable for Bidders to provide a description of supplier diversity businesses practices. Specifically, listing contact information for the individual or unit responsible for establishing and maintaining supplier diversity relationships, and including a written policy for establishing and maintaining supplier diversity relationships.

It also is desirable for Bidders to use the SDP Plan Form to describe additional creative initiatives (if any) related to engaging, buying from, and/or collaborating with diverse businesses. Such initiatives may include but not be limited to:

· Serving as a mentor in a mentor-protégé relationship.

· Technical and financial assistance provided to diverse businesses.

· Participation in joint ventures between nondiverse and diverse businesses.

· Voluntary assistance programs by which nondiverse business employees are loaned to diverse businesses or by which diverse business employees are taken into viable business ventures to acquire training and experience in managing business affairs.

Evaluation of SDP Forms To encourage Bidders to develop substantial supplier diversity initiatives and commitments as measures valuable to the Commonwealth, at least 25% of the total available evaluation points for this bid solicitation shall be allocated to the evaluation of the SDP Plan submissions. Because the purpose of the SDP is to promote business-to-business partnerships, the Bidders’ workforce diversity initiatives will not be considered in the evaluation.

SDP Spending Reports After contract award, Contractors must submit reports at least annually to demonstrate compliance with the agreed-upon SDP Commitment. To submit SDP spending reports using the Hub, Contractors must create a profile in the Hub. Once registered, awarded contractors must report information such as, but not limited to, SDO or SDO-recognized SDP partner(s), spend with SDO partner(s), and total contract sales. Contractors must follow report submission instructions from the issuing department and the SDO.

SDP Spending Compliance Only Spending with SDP Partners that appear in the SDO Directory of Certified Businesses or in the SBA Veteran Small Business Certification (VetCert) directory shall be counted toward a Contractor’s compliance with their SDP Commitment. Spending with SDP Partners that do not appear in the directories above shall not be counted toward meeting a Contractor’s SDP Commitment.

It is the responsibility of the Contractor to ensure they meet their SDP Commitment. The SDO and the issuing department assume no responsibility for any Contractor’s failure to meet its SDP Commitment.

SDP Spending Verification The SDO and the contracting department reserve the right to contact SDP Partners at any time to request that they attest to the amounts reported to have been paid to them by the Contractor.

Program Resources and Assistance Contractors seeking assistance in the development of their SDP Plans or identification of potential SDP Partners may visit the SDP webpage, www.mass.gov/sdp, or contact the SDP Help Desk at sdp@mass.gov.

10. Environmentally Preferable Products Products and services purchased by state agencies must be in compliance with Executive Order 515, issued October 27, 2009. Under this Executive Order, Executive Departments are required to reduce their impact on the environment and enhance public health by procuring environmentally preferable products and services (EPPs) whenever such products and services perform to satisfactory standards and represent best value, consistent with 801 CMR 21.00. In line with this directive, all Contracts, whether departmental or statewide, must comply with the specifications and guidelines established by OSD and the EPP Program. EPPs are products and services that help to conserve natural resources, reduce waste, protect public health and the environment, and promote the use of clean technologies, recycled materials, and less toxic products. Bid responses must identify how a contractor meets these goals.

11. Evaluation Criteria Contractors must submit responses that meet all the submission requirements of the RFR. Only responsive proposals that meet the submission requirements will be evaluated, scored, and ranked by the evaluation team according to the evaluation criteria. Additional information may be requested for evaluation purposes.

Performance Measures: As outlined in the Standard Contract Form, Terms and Conditions, and RFR, infractions may result in the following actions:

Corrective Action Plan:

· Termination

· Suspension

· Adding additional contractor

· Cover/Replacement Cost

· Liquidated Damages

12. Instructions for Submission of Responses:

Only electronic quotes submitted via COMMBUYS will be accepted in response to this RFR. Responses must be sent via the “Create Quote” functionality in COMMBUYS. For instructions concerning how to submit a Quote, please see Appendix B.

Any submission that fails to meet the submission requirements of the RFR will be found non-responsive without further evaluation unless the evaluation team, at its discretion, determines that the non-compliance is insubstantial and may be corrected. In these cases, the evaluation team may allow the vendor to make minor corrections to the submission.

Estimated Procurement Calendar

Bidders are required to monitor COMMBUYS for changes to the procurement calendar for this Bid.

a. Online Questions (Bid Q&A) Written Questions must be entered using the “Bid Q&A” tab for the Bid in COMMBUYS no later than the “Online Questions Due” date and time indicated in the Estimated Procurement Calendar (above). The issuing department reserves the right to not respond to questions submitted after this date. It is the Bidder’s responsibility to verify receipt of questions.

It is the responsibility of the prospective Bidder and awarded Contractor to maintain an active registration in COMMBUYS and to keep current the email address of the Bidder’s contact person and prospective contract manager, if awarded a contract, and to monitor that email inbox for communications from the Purchasing Department, including requests for clarification. The Purchasing Department and the Commonwealth assume no responsibility if a prospective Bidder’s/awarded Contractor’s designated email address is not current, or if technical problems, including those with the prospective Bidder’s/awarded Contractor’s computer, network, or internet service provider (ISP) cause email communications sent to/from the prospective Bidder/Awarded contractor and the Purchasing Department to be lost or rejected by any means including email or spam filtering.

Written Responses to Questions will be released on or about the “Responses to Questions Posted Online” date indicated in the Estimated Procurement Calendar (above).

(Written questions and responses will be posted on the Bid Q&A Tab for this Bid in COMMBUYS.)

b. Bid Amendment Deadline The Purchasing Department reserves the right to make amendments to the Bid after initial publication. It is each Bidder’s responsibility to check COMMBUYS for amendments, addenda, or modifications to this Bid, and any Bid Q&A records related to this Bid. The Purchasing Department and the Commonwealth accept no responsibility and will provide no accommodation to Bidders who submit a Quote based on an out-of-date Bid or on information received from a source other than COMMBUYS.

b. Quotes (Bid Responses) Deadline (Bid Opening Date/Time) See the Quotes (Bid Responses) Deadline (Bid Opening) Date and Time indicated in the Estimated Procurement Calendar (above).

d. Estimated Contract Start Date This is the approximate start date. The actual start date will be the Contract Effective Date which is the date the Contract is executed by the parties.

13. Required Forms Responses to this RFR must contain the following documents

The above attachments are available as part of the Bid record on COMMBUYS (WWW.COMMBUYS.COM).

14. Bidder Responses

A. Bidder Response Elements

The following must be provided in each Bidder’s response:

1. Response Checklist Bidders must provide a completed copy of Form I: Response Checklist to certify they have provided each requested document under this RFQ.

2. RFR Response Document The RFR Response document must include the information requested in Form 2: RFR Response Cover Letter. Additionally, the RFQ Response should include:

a. Functionality & Business Requirements Response (Limit 25 pages):

1) A narrative response of how the Bidder's proposed solution meets the business and technical requirements as described in RFQ Section II.B.: Functionality & Business Requirements.

b. Project Management, Training, and Implementation Plan (Limit 10 Pages)

1) Bidders must provide a high-level project plan and implementation roadmap for the successful launch of their Grants Management System, including the timeframe for Software go-live.

2) Bidders should describe the key project personnel they are proposing on this engagement, including, but not limited to their: Account Manager, Project Manager, and Technical Lead, as applicable.

c. Cost Response (Limit 5 pages)

1) A Cost Narrative document that explains the Bidder's cost model in detail, including the following, as applicable:

1. A clear description of cost of implementing the solution.

2. Detail of Bidder's proposed license structure, maintenance, and support costs, and other associated costs

3. Any applicable volume discount charts or enterprise licensing options

4. The process for adding or removing licensed users so that EOED's licensing will be routinely right-sized

5. Bidder's assumptions in connection with its cost proposal

6. Explanation of any additional costs associated with the Bidder's bid

7. A description of any optional costs associated with the Bidder's bid, for example, optional add-on software functionality and modules

8. Potential cost model alternatives. Bidders may propose multiple types of software licenses with different options and prices. Bidders must identify any interdependencies between any options proposed in this manner in the narrative response.

9. Any anticipated major upgrades in the next three years, and estimated costs based on the level of proposed configuration.

d. References and Descriptions of Past Implementations (Limit 5 Pages)

1) Bidder must describe three examples in which the proposed software has been deployed for a customer similar to EOED, and for each of these instances provide the name and contact information for an individual employed by the entity that has deployed the software that can be used as a reference.

3. Grants Management Cost Workbook Fully completed Microsoft Excel Form 3: Grants Management Cost Workbook.

4. Proposed Grants Management Use Cases

a. Using the last four (4) columns provided in Attachment E: Proposed Grants Management Use Cases, indicate the proposed software's ability to meet the needs of each use case as:

1) In Current Software – Meaning standard, out of the box functionality

2) Meets with Configuration – Meaning the core system can be configured to meet the requirements specified

3) Meets with Customization – Meaning requiring customization of the core product

4) On Roadmap (next 12 months) – Meaning it is planned to be enhanced in the core product in the next 12 months

5) Not Included – Meaning not possible or offered in the proposed software

5. API Specifications to Support Integrations Bidder must provide comprehensive documentation and description of all application programming interfaces (APIs) required to support system integrations. This will be attached as Form 5 – API Specifications to Support Integrations.

6. Authorized Reseller Certification Letter A reseller certificate in the form attached hereto as Form 5: Authorized Reseller Certification Letter, if applicable (only required if Bidder is submitting a bid under the authority of an ITS60, ITS75, ITS81, or ITS82 reseller).

7. Template Statement of Work Include a redline (track changes) version of the Statement of Work (Form 6).

8. Bidder Exceptions EOED recognizes that not every market solution will meet all of the RFQ requirements. Bidder must expressly identify any RFQ requirement, whether business, technical or otherwise, that it is unable to meet. Bidders can include this information within the narrative responses provided they are clearly labeled as exceptions, or the Bidder may use a separate document.

B. Evaluation Criteria

Responses to this RFR will be evaluated based on the criteria listed below. EOED reserves the right to remove from further consideration any non-responsive bids and any responses that attempt to modify or condition acceptance of the Commonwealth’s standard contractual terms.

All responses will first be evaluated for inclusion of the required elements identified in Section II of this RFQ. Remaining responsive proposals will be evaluated as follows:

1. Alignment with the Business and Functional Requirements set forth in Section II:

a. Portal Interface

b. User Management

c. Intuitive, Robust, and Manageable Application

d. Application Review and Approval

e. CRM Capabilities

f. System Integrations

g. Automation & AI Capabilities

h. Communications

i.