Vendor Q and A FINAL~3.pdf

1. What specific measurable outcomes will IHDA use to determine whether the selected solution is successful at 6, 12, and 24 months post-implementation?

As outlined in the RFP, it is desirable for vendors to provide a projected timetable for software implementation with specific milestones including UAT and acceptance of production environment (F.3.92). Our school of thought is flexible for how implementation is approached, including timeline.

2. Which objectives take precedence if tradeoffs are required between functionality, schedule, and cost?

Functionalities that protect compliance and mission outcomes take precedence, followed by schedule, and then cost.

3. What operational problems must be fully resolved for IHDA to consider this procurement a success versus merely improvement?

Success will be measured based on a variety of factors as outlined in the RFP.

4. Which lifecycle phases are considered mission-critical versus enhancement-level capabilities at award?

Requirements are not defined by lifecycle stages. Multifamily application intake is required per F.2.7. Points are awarded for desirable requirements that address other lifecycle stages. Section D.3 outlines the total number of points available and number of points necessary to advance to evaluation.

5. How will IHDA evaluate alignment with its long-term systems roadmap during scoring?

Section D.3 outlines the total number of points available and number of points necessary to advance to evaluation.

6. What risks would IHDA consider unacceptable regardless of technical merit?

All mandatory requirements are listed in Sections F.1 and F.2 of the RFP.

7. How will success be judged for external user adoption and satisfaction?

External user adoption is not voluntary so is not applicable for this procurement.

External user satisfaction is not directly defined in the RFP but the Desirable Elements section "External User Access and Interface" awards points for various features that address external user experience (F.3.57-F.3.65). IHDA engages external users regularly to define system performance.

8. Is reduction of manual processes a scored objective or an implied expectation?

Reduction of manual processes are scored through multiple requirements in the "Task Automation" and "Workflow Management" sections of Desirable Elements (F.3.44-F.3.56).

9. What internal KPIs are currently underperforming and driving urgency for this procurement?

All current software complete functions that allow IHDA to do business.

10. How will IHDA distinguish between vendors that partially meet requirements versus those offering modular roadmaps?

As stated in Section A.1 in the RFP, IHDA recognizes that while this RFP outlines a broad set of desired features and capabilities, a single system may not meet every specification. The Authority's primary objective is to identify a vendor and platform that move us meaningfully closer to a fully integrated, efficient, and sustainable solution that strengthens our operational infrastructure and improves service delivery.

11. Which functions currently performed outside systems of record are explicitly in scope for replacement?

There are several functions currently performed outside IHDA’s systems of record that are explicitly in scope for replacement by the new Development Lifecycle Software (DLS) Solution. Under Areas of Concern/Challenges, the document highlights:

Funding Application Intake: Currently managed outside system environments, often in standalone Excel workbooks.

Property Risk Assessment: Conducted manually and outside core systems.

Owner Compliance Activities: Tracked outside the system of record, creating oversight and reporting challenges.

Escrow Account Withdrawals and Compliance Document Review Status: Managed through a third-party configurable workflow tool, which IHDA notes is not sustainable long-term.

12. Are vendors expected to replace all existing third-party tools or integrate with selected ones?

Vendor expectations will vary based on the functionality of the new software.

13. Which legacy systems will remain authoritative after implementation, if any?

This will be defined following vendor selection depending on selected vendor’s system capabilities.

14. Are there assumed services or deliverables that IHDA expects but did not explicitly list?

To the best of our knowledge, the RFP is comprehensive of all requirements.

15. What activities are explicitly out of scope for this contract?

To the best of our knowledge, the RFP is comprehensive of all requirements.

16. Does IHDA expect configuration-only delivery or custom development where gaps exist?

IHDA expects a configuration-first approach, with custom development allowed only where necessary and governed by a clear, documented process. Where gaps exist that cannot be addressed through configuration, custom development is acceptable, provided vendors:

Clearly outline the process for requesting and implementing customizations.

Include timelines, approval workflows, and governance for changes.

Ensure that customizations do not compromise system integrity, upgrade paths, or IHDA’s ability to manage configurations independently (F.3.68-F.3.71).

17. Are future program additions expected to be absorbed without contract modification?

Program additions will be reviewed on a case-by-case basis and our Legal team will draft a contract and define terms, such as program additions.

18. What assumptions has IHDA made regarding data quality and completeness in legacy systems?

B.3 describes areas of concern and challenges regarding current systems, including data fragmentation and manual processes that risk data inconsistencies and misalignment.

19. Will vendors be responsible for cleansing and normalizing historical data?

Yes and IHDA expects this to be a collaborative process and will work with the vendor to provide guidance and ensure a smooth transition of historical data.

20. Are workflow redesign and business process re-engineering considered part of the scope?

No, workflow redesign and business process re-engineering are not part of the RFP scope.

21. Which requirements in Section F are mandatory versus desirable if conflicts arise?

All of Section F.1 and Section F.2 of the RFP are mandatory requirements.

22. What integration standards or APIs are required for existing state systems?

Vendors are required to support commonly available integration methods including application programming interfaces (APIs), flat files, secure transfer protocols (STPs), Microsoft SQL Server (2016+), Azure cloud services, and online analytical processing (OLAP)/business intelligence (BI) tools (F.1.1). Specific integrations will depend on the selected vendor's system capabilities.

23. Are real-time integrations required, or are batch interfaces acceptable in certain cases?

Vendors are asked to describe their integrations/interfaces. F.3.42, does not state what integration pattern is expected but vendors are required to support commonly available integration methods including application programming interfaces (APIs), flat files, secure transfer protocols (STPs), Microsoft SQL Server (2016+), Azure cloud services, and online analytical processing (OLAP)/business intelligence (BI) tools (F.1.1).

24. What performance benchmarks are required for concurrent internal and external users?

There are not specific performance metrics for concurrent users in the RFP. Vendors must maintain "consistent performance" in concurrent user scenarios (F.1.19) and points are awarded for vendors to describe concurrent user capacity (F.3.75) but no specific benchmark is defined.

25. How will system scalability be tested and validated during evaluation or acceptance?

Scalability testing during acceptance is not defined in the RFP. Vendors are required to maintain consistent performance across all system functions and must demonstrate scalability (F.1.19) and points are awarded for vendors that describe concurrent user capacity (F.3.75) but how this is tested is not defined.

26. Are vendors expected to provide sandbox, test, and training environments?

Yes, section F.1.22 states the Vendor must provide permanent, independent, non-production environments during the contract term for new software release development, testing, and training prior to a new production version or software change request by IHDA being placed into production. The staging (pre-production) environment configuration will be an exact duplicate of the production environment.

27. What reporting tools are preferred or required by IHDA?

F.3.40 - Vendors are asked to describe reporting and business intelligence capabilities of the DLS Solution, including embedded dashboards, custom report builders, advanced visualizations, connectors to external BI tools (e.g., Tableau, Power BI), and automated report generation/scheduling; explain ease-of-use for non-technical end users.

28. How should the system handle changes to NIGP codes, programs, or compliance rules mid-contract?

NIGP Code changes will be posted to BidBuy before proposals are due. NIGP Codes may be reevaluated at the time of renewal. Program or compliance rule changes mid-contract may be addressed by a contract amendment depending on circumstances and changes to the original contract scope.

29. Are mobile or responsive interfaces required for external users?

Yes.

30. What constraints exist around configuration versus customization?

IHDA requests that vendors prioritize configuration wherever possible. The RFP specifically requires vendors to provide an interface for IHDA system administrators to configure user roles and data visibility rules without custom development, emphasizing self-service configuration as the preferred method. Where configuration cannot meet requirements, customization may be allowed and communicated with

IHDA.

31. Is cloud hosting permitted, required, or optional?

IHDA is seeking to procure a Software as a Service (SaaS), defined as a cloud-based model accessed via subscription rather than software that is purchased and installed on individual user computers (F.3.76).

32. If cloud-hosted, are there restrictions on geographic data residency?

Vendors are asked to describe what they have in place. Datafencing is preferred - at rest and in flight within the 48 contiguous states.

33. Is a state-hosted or vendor-hosted model preferred for evaluation purposes?

IHDA is seeking to procure a SaaS, defined as a cloud-based model accessed via subscription rather than software that is purchased and installed on individual user computers (F.3.76). It is not required to be state hosted.

34. Who owns and controls the production, test, and backup environments?

Section F.1.22 states the Vendor must provide permanent, independent, non-production environments. IHDA is seeking to procure a SaaS, defined as a cloud-based model accessed via subscription rather than software that is purchased and installed on individual user computers. The vendor owns and controls all environments, IHDA owns all data.

35. What uptime and disaster recovery expectations apply?

Vendor must provide current examples of executed Service Level Agreements (SLAs) from similar engagements, or a comprehensive SLA template if none exist. SLA examples/templates must include financial penalty structures and remedies for SLA non-compliance (service credits, fee reductions, or other monetary compensation for missed performance targets).

36. Are vendors required to support hybrid hosting models?

No, IHDA is seeking to procure a SaaS, defined as a cloud-based model accessed via subscription rather than software that is purchased and installed on individual user computers (F.3.76).

37. What responsibilities does IHDA retain for infrastructure management?

No, IHDA is seeking to procure a SaaS, defined as a cloud-based model accessed via subscription rather than software that is purchased and installed on individual user computers (F.3.76).

38. How will hosting costs be evaluated and compared across bidders?

Pricing is scored pursuant to Section D of the RFP.

39. Are vendors required to support future migration to state infrastructure?

IHDA is anticipating this engagement to limited to the implementation of the vendor's softwares. Vendors receive points for defining he method for exporting all IHDA data in the event of contract termination (F.3.74).

40. What exit requirements apply to hosted environments at contract termination?

Terms of vendor engagement will be defined in contract after vendor selection.

41. Who retains ownership of all data, metadata, and derived analytics?

F1.10: The Vendor will have no ownership of IHDA data. The client organization (IHDA) retains exclusive ownership of all data, metadata, and any derived analytics generated throughout the engagement. The vendor shall have no ownership rights over any client data and acknowledges that all such information constitutes the client’s intellectual property. The vendor is responsible for implementing robust security measures to safeguard hosted data and must promptly report any data breach or data loss incidents to the client in accordance with agreed timelines and applicable regulatory requirements. Additionally, the vendor will ensure secure access, export, and portability of all data without imposing licensing or technical restrictions. These ownership and security obligations will be explicitly documented in the contract under data governance, intellectual property, and compliance provisions.

42. What level of historical data must be migrated to meet acceptance?

While the RFP does not specify an exact time span (e.g., “last 10 years”), the language “comprehensive legacy data” and “all existing IHDA data” indicates that the new system must migrate comprehensive legacy data from existing systems, including:

Financial records, Compliance histories, Project documentation, Associated data across all program areas. The migration must maintain data integrity and audit trails throughout the process. Additionally, the vendor must provide a mechanism for importing all existing IHDA data into the DLS Solution, including SQL data and associated documents (PDFs, Word, Excel, images) from legacy applications such as Authority DMS.

43. How will IHDA validate migrated data accuracy and completeness?

Validation activities will include but are not limited to: Data mapping and reconciliation, record counts and completeness checks, field-level validation, and user acceptance testing.

44. Are vendors responsible for preserving legacy audit trails?

We require the transfer of all existing IHDA data into the DLS Solution, and that the vendor provide an audit report of the data being migrated. A desired element (F.1.2;

F.1.15; F.3.25) is a description of the features for supporting data lineage and tracking changes to data over time.

45. What data retention policies must the system support?

A copy of IHDA’s record retention policy has been attached to the Bid.

46. How will data corrections post-migration be handled contractually?

Terms of vendor engagement will be defined in contract after vendor selection.

47. Are vendors required to support bulk data exports on demand?

Vendors are required (F.2.10; F.3.36) to describe any technical or licensing limitations on access to IHDA's business data, including features requiring separate licenses to enable data export or integration; It is requested that vendors describe their data export capabilities, including limitations on export volume or frequency.

48. What format and frequency of data backups are required?

Vendor is asked to supply information regarding the frequency, manner, and retention of backups. (F.3.85)

49. How will conflicting data definitions across legacy systems be resolved?

To be defined in the implementation phase but vendor is expected to have the technical expertise to enable smooth data corrections.

50. Are vendors required to support future re-migration or system replacement?

Vendors are required (F.3.76) to describe any technical or licensing limitations on access to IHDA's business data, including features requiring separate licenses to enable data export or integration; It is requested that vendors describe their data export capabilities, including limitations on export volume or frequency.

51. Are vendors permitted to use fully remote resources for implementation and support?

All services shall be performed in the United States. Remote resources located within the United States are allowed.

52. Is onsite presence required at any phase of the project?

Yes, and frequency and scheduling will be determined once vendor selection is complete. All services shall be performed in the United States. Remote resources located within the United States are allowed.

53. Are there minimum requirements for Illinois-based or U.S.-based staff?

No.

54. Are offshore resources permitted for development, configuration, or support activities?

All services shall be performed in the United States.

55. If offshore resources are used, are there restrictions related to data access?

All services shall be performed in the United States.

56. Are key personnel subject to approval or replacement restrictions?

No, however, per F.3.1, IHDA expects that key staff are experienced, knowledgeable, and credible.

57. What staffing continuity expectations apply over the contract term?

Continuity is not required.

58. Is the prime contractor permitted to subcontract the majority of technical work?

This will be defined following vendor selection depending on selected vendor's system capabilities.

59. Are subcontractors subject to the same compliance and disclosure requirements as the prime?

Per section D.2.2 of the RFP Subcontractor Disclosure, If the Offer includes any subcontractors, then Offeror shall complete the Subcontractor Disclosure section of the Offer to the State of Illinois. Per the Offer to the State of Illinois document, all contracts with the subcontractors identified above must include the Standard Illinois Certifications completed by the subcontractor. If the annual value of any of the subcontracts is more than $100,000, then the Vendor must provide to the State the subcontractor's Financial Disclosure and Conflicts of interest form or IPG Active Registered Vendor Disclosure form.

60. How will staffing approach be evaluated relative to technical merit?

Staffing is primarily addressed through the 80 points allocated to "Vendor Experience and Project Team" in Section F.3. Commitment to diversity in staffing accounts for up to 340 points (F.3.4). Technical merits account for the remaining 1180 points.

61. Which security frameworks must the solution comply with at go-live?

IHDA requires vendors to maintain SOC 2 compliance and aligns with the NIST Cybersecurity Framework. For evaluation purposes, vendors should clearly identify all security and compliance frameworks they adhere to, as outlined in Section F.2.2.

62. Are State of Illinois IT security standards mandatory or advisory?

The Offer to the State of Illinois document does reference the Information and Technology Standard Terms and Conditions and states they will become a part of any resulting contract. Section 2.31 of the Information and Technology Standard Terms and Conditions does have the State of Illinois specific security requirements for information and systems and states that the vendor must ensure these requirements are fully understood and allocate sufficient project time and resources to address the security requirements. The State of Illinois IT security requirement standards may be negotiated with the awarded vendor at the sole discretion of IHDA.

63. What penetration testing or vulnerability assessment is required prior to acceptance?

Vendors are asked to describe their Penn Testing and Vulnerability Testing. (F.1.19;

F.3.75)

64. How will compliance with federal housing regulations be validated?

Vendor receives points for proactive monitoring of federal housing regulations (F.3.71) and will be evaluated on a case-by-case basis.

65. Are vendors required to support role-based segregation of duties?

Yes, the system must support Role-Based Access Control (RBAC) that enables the assignment of specific rights and privileges to user roles (e.g., admin, manager, employee) following the principle of least privilege. The Solution must allow for the configuration of access to both screens and data based on job function (F.1.16).

66. What incident response timelines are required for security events?

Vendors are asked to describe what they have in place. IHDA requires notice within 48 hours if there is any breach or unintended disclosure of IHDA's data.

67. How will compliance gaps discovered post-award be handled?

IHDA requires notice within 48 hours if there is any breach or unintended disclosure of IHDA's data.

68. Are vendors required to support third-party security audits?

Per F.2.2, the Vendor must certify that it maintains a current SOC 1 or SSAE 18 report and/or SOC 2 report for critical business processes relating to the protection of Confidential Information and the safeguards implemented within its organization.

SOC reports are not required as part of the proposal but must be provided within two

(2) weeks upon IHDA’s written request during the contract term.

69. What encryption standards apply to data at rest and in transit?

All systems must encrypt all IHDA data at rest and in-flight using algorithms and key lengths consistent with the most recent NIST guidelines (F.1.9).

70. Are background checks required for vendor personnel with system access?

The State of Illinois Information and Technology Standard Terms and Conditions will become a part of any resulting contract, including its provisions on background checks.

71. Is IHDA seeking a fixed-price implementation or milestone-based pricing?

See Section C.1 for instructions on how to submit pricing. Pricing must be submitted using the pricing document attached to the bid. Submitting pricing in any other format may result in disqualification of your offer.

72. How will recurring subscription, licensing, and hosting costs be evaluated?

Pricing is scored pursuant to Section D of the RFP.

73. Are pricing escalations permitted during renewal terms?

See Section C.1 for instructions on how to submit pricing. Pricing must be submitted using the pricing document attached to the bid. Submitting pricing in any other format may result in disqualification of your offer.

74. What assumptions should vendors make regarding user counts over time?

As mentioned in section B.3., a current challenge for IHDA is data fragmentation across multiple legacy systems so user count, including user count over time, will depend on the selected vendor’s system capabilities and what system(s) the vendor will replace.

75. How will change requests be priced and approved?

See Section C.1 for instructions on how to submit pricing. Pricing must be submitted using the pricing document attached to the bid. Submitting pricing in any other format may result in disqualification of your offer.

76. Are vendors required to include all third-party costs in their pricing?

See Section C.1 for instructions on how to submit pricing. Pricing must be submitted using the pricing document attached to the bid. Submitting pricing in any other format may result in disqualification of your offer.

77. Will cost realism be evaluated independently of lowest price?

Pricing is scored pursuant to Section D of the RFP.

78. Are there funding constraints that may delay implementation milestones?

No.

79. How will pricing inconsistencies across proposal sections be treated?

Pricing is scored pursuant to Section D of the RFP.

80. Is IHDA seeking cost predictability or flexibility as a higher priority?

Pricing is scored pursuant to Section D of the RFP.

81. Who will serve as the single decision authority for scope and design approvals?

IHDA has designated a formal review committee to define decision authority for scope and design approvals.

82. What responsibilities will IHDA retain for requirements validation and testing?

IHDA has designated a formal review committee to define what responsibilities IHDA will retain during validation and testing.

83. How frequently will governance and steering meetings occur?

To be determined after vendor selection, will be included in project plan.

84. What escalation path applies for unresolved issues?

IHDA has designated a formal review committee to define what escalation process will be applicable. Points are awarded for defining an escalation matrix for unresolved issues (F.3.89).

85. Will IHDA provide dedicated subject matter experts throughout implementation?

Yes, IHDA will provide subject matter experts throughout implementation.

86. How will cross-department conflicts be resolved?

IHDA has designated a formal review committee to define how cross-department conflicts will be resolved.

87. Are vendors expected to manage communications with external stakeholders?

No, vendors are not expected to manage communications with external stakeholders.

88. What documentation approvals are required prior to acceptance?

Per F.3.92 vendors are awarded points for providing a projected timetable for software implementation (assuming work shall begin as soon as possible after contract execution). Documentation approvals will depend on vendor capabilities.

89. How will schedule impacts caused by IHDA dependencies be handled?

IHDA will make every effort to keep the project on track, and when a schedule impact occurs from IHDA, schedule dependencies may shift out to accommodate the schedule impact.

90. What authority does IHDA reserve to reprioritize work mid-project?

We expect work prioritization to be a collaborative process with the selected vendor.

In cases where re-prioritization is required, we expect both IHDA and the vendor to remain flexible and solution oriented to ensure continued smooth implementation.

91. Which milestones are contractual versus indicative?

All technical contract requirements are stated in section F.1 and technical mandatory requirements with evidence are stated in section F.2.

92. What penalties or remedies apply for schedule slippage?

In the event of schedule slippage attributable to the Vendor, IHDA may exercise one or more of the following remedies, as permitted under the contract: corrective action plans, reduction of payment, assessment of liquidated damages or service credits, and contractual remedies. Vendors should describe (F.2.16; F.3.92; F.2.14) their project management approach, risk mitigation strategies, and mechanisms for proactively identifying and addressing schedule risks.

93. How will acceptance criteria be defined for each phase?

Acceptance criteria will be established and documented in phase-specific artifacts such as the project plan, requirements documentation, design specifications, testing plans, and user acceptance testing scripts. Each phase will include formal review and acceptance by IHDA prior to proceeding to subsequent phases or issuing milestone payments. IHDA reserves the right to withhold acceptance until all agreed-upon criteria are met or approved remediation plans are completed. Vendors should describe their approach to defining, managing, and validating acceptance criteria throughout the project lifecycle.

94. Is phased or incremental go-live acceptable?

A phased go-live approach may be proposed by vendors, provided it supports project objectives, minimizes operational risk, and ensures continuity of business operations.

95. What dependencies exist outside vendor control?

The RFP is comprehensive of known dependencies.

96. How will delays caused by data readiness be treated?

IHDA will make every effort to keep the project on track, and when a schedule impact occurs from IHDA, schedule dependencies may shift out to accommodate the schedule impact.

97. Are vendors required to support parallel operations during transition?

Yes, if parallel operations are requested, the vendor will be required to support during the transition (F.3.94).

98. What constitutes final system acceptance?

Upon vendor selection, our team will define terms that will constitute final system acceptance.

99. How long is the stabilization period post-go-live?

Upon vendor selection, the team will discuss terms that will constitute the stabilization period post go-live.

100. Are vendors expected to support post-implementation optimization?

Upon vendor selection, our team will discuss and determine the terms of vendor, the support needed for post-implementation optimization.

101. How will technical scores be normalized across evaluators?

See Section D.3 of the RFP for Evaluation Methodology.

102. What minimum technical threshold must be met to remain price-competitive?

See Section D.5 of the RFP.

103. How will demonstrations be scored relative to written proposals?

See Section D.3 of the RFP for Evaluation Methodology.

104. Are evaluators instructed to assess roadmap credibility?

Section A.1 states the agency "welcome proposals from vendors who meet IHDA’s key priorities and who can clearly demonstrate a strategic roadmap for achieving alignment with our long-term system goals." and section F.5 requests the "Methodology to be used in completing the Scope of Work and Desired Outcomes of the Project/Engagement in Section A".

105. How will Commitment to Diversity scoring be integrated into final rankings?

See Section D.5 of the RFP for Evaluation Methodology.

106. Will references be scored or used only for responsibility determination?

References are not scored.

107. How will ties be resolved?

Per Administrative Code 44 Section 1.2037 Tie Bids and Proposals

b) Tie bids, proposals, or quotes will be resolved as follows:

1) If the tied vendors include only one Illinois resident vendor, the Illinois resident vendor shall be given the award. "Illinois resident vendor" has the meaning ascribed in Section 1.4510 (Resident Vendor Preference).

2) In all other situations, the award shall be made by lot unless the SPO determines that:

A) awarding to one of the vendors is in the State's best interest because, for example, that vendor is likely to be more reliable or responsive to the State's needs, based on past performance; provides a better quality of the supply or service;

provides quicker delivery; or, in the case of proposals, because of a desire to take advantage of the lower price; or

B) splitting the award is in the State's best interest because of a need to ensure delivery of the supply or service, or is necessary or desirable to promote future competition, and provided the affected vendors agree to the split award.

108. Is IHDA reserving the right to negotiate scope or price post-selection?

IHDA reserves the right to issue Best and Final Offer Requests.

109. Will multiple awards be considered?

No.

110. What protest rights apply to unsuccessful offerors?

See Section E.9 of the RFP.

111. Who owns configuration, workflows, and customizations developed under the contract?

All configurations, workflows, and customizations developed under this contract shall be deemed work for hire and will be the exclusive property of the client organization (IHDA). Any vendor reuse of generic components must be segregated from client-specific customizations and exclude client data or intellectual property.

112. Are vendors required to indemnify IHDA for IP infringement?

See Section 2.10 of the Information and Technology Standard Terms and Conditions.

113. What limitations of liability apply to data loss or system failure?

See Section 2.10.3 of the Information and Technology Standard Terms and Conditions.

114. Are there termination for convenience provisions?

See Section 1.2 of the Information and Technology Standard Terms and Conditions.

115. What transition assistance is required upon termination?

The State of Illinois Information and Technology Standard Terms and Conditions will become a part of any resulting contract, including requirements upon termination.

116. Are insurance coverage limits negotiable?

The State Standard Terms and Conditions set forth minimum insurance requirements expected of the vendor.

117. How are subcontractor liabilities treated?

See the Information and Technology Standard Terms and Conditions.

118. What warranties are required for system performance?

See the Information and Technology Standard Terms and Conditions.

119. How are disputes resolved under the contract?

See the Information and Technology Standard Terms and Conditions.

120. Are vendors permitted to reuse generic components developed during the engagement?

Permitting the vendor to reuse generic components promotes their seamless integration into the overall solution and supports long-term adoption, future maintenance, and potential expansion of customizations. All updates and upgrades must incorporate these customizations to ensure continuity and functionality. Any vendor reuse of generic components must be segregated from client-specific customizations and exclude client data or intellectual property.

121. How should the system handle program rule changes mid-affordability period?

IHDA has designated a formal review committee to define how program rule changes mid-affordability period will be addressed. The vendor is awarded points for describing self-service customization capabilities (F.3.69) and for describing how they will proactively monitoring regulatory changes (F.3.71).

122. What happens if data migration reveals irreconcilable inconsistencies?

IHDA has designated a formal review committee to define what happens if data migration reveals irreconcilable inconsistencies.

123. How will system performance degradation be addressed?

Vendor must provide current examples of executed Service Level Agreements (SLAs) from similar engagements (F.3.82; F.3.83; F.3.85), or a comprehensive SLA template if none exist. SLA examples/templates must include financial penalty structures and remedies for SLA non-compliance (service credits, fee reductions, or other monetary compensation for missed performance targets).

124. What remedies apply if external user adoption is materially lower than expected?

External user adoption is not voluntary and is not an applicable success criteria for the DLC system.

125. How will partial implementations be handled if the project is terminated early?

The State of Illinois Information and Technology Standard Terms and Conditions will become a part of any resulting contract.

126. Are vendors required to support data extraction in a standard format at exit?

Yes, data export is required.

127. What knowledge transfer is required upon contract completion?

Upon contract completion, the vendor is required to ensure comprehensive knowledge transfer to support continuity and effective system utilization. This includes providing a complete and accurate data dictionary for all reporting and custom development components, detailing data structures, field definitions, and relationships. Additionally, the vendor must deliver structured training on all systems to designated client personnel. This training should encompass system functionality, configuration management, troubleshooting procedures, and best practices for ongoing maintenance and reporting. The goal is to equip the client team with the necessary skills and documentation to independently manage, operate, and optimize the solution post-contract.

128. How will unresolved defects at contract end be treated?

The State of Illinois Information and Technology Standard Terms and Conditions will become a part of any resulting contract.

129. What obligations survive contract termination?

The State of Illinois Information and Technology Standard Terms and Conditions will become a part of any resulting contract.

130. How will IHDA ensure continuity of operations during vendor transition?

There will be a project manager and implementation plan that will map out how operational continuity and implementation of new software will coexist. This will happen after vendor selector and the vendor will be central to this discussion.

131. How to fulfill the BEP requirement as a vendor?

The BEP goal can be met in one of three ways: 1) The prime vendor is BEP certified and will meet the goal 100% through self-performance; 2) subcontract to a BEP certified firm; or 3) demonstration of a good faith effort. Please refer to the instructions in the Utilization Plan.

132. Can IHDA confirm whether it is open to a platform-based solution delivered by a systems integrator that lives in an IHDA managed cloud tenant, rather than a proprietary COTS DLS product?

IHDA is awarding points to vendors who provide a SaaS, defined as a cloud-based model accessed via subscription rather than software that is purchased and installed on individual user computers (F.3.76). This is not a contract requirement and would consider vendors with different system structures provided they receive enough points addressing other desirable elements.

133. Is the intent to replace Benedict, integrate with it, or run in parallel? How does IHDA envision reconciliation with CAMRA and Oracle post-implementation?

Integration or replacement of existing systems, including Benedict, will be defined after vendor selection and depend on the selected vendor's system capabilities.

134. What integration patterns are expected with Oracle Financials (real-time APIs vs batch)?

F.3.42, which awards points for integration with Oracle Financials, does not state what integration pattern is expected but vendors are required to support commonly available integration methods including application programming interfaces (APIs), flat files, secure transfer protocols (STPs), Microsoft SQL Server (2016+), Azure cloud services, and online analytical processing (OLAP)/business intelligence (BI) tools (F.1.1). Batch processing using secure file exchanges or scheduled data transfers is acceptable and sufficient for our needs. It's important to ensure that batch integration does not hinder IHDA's ability to receive the necessary transaction details or supporting data elements required for accurate GL posting.

135. Does IHDA expect licensing for external users to be included in the vendor’s pricing, or handled separately?

No licensing is needed for external users at this time.

136. Would IHDA be open to considering an extension to allow adequate time for reviewing the Q&A once it has been posted?

See the Bid in BidBuy for any updates to the Bid Opening Date and Time.

137. Please list the systems IHDA is currently using and what type of data that resides in each system.

Functionalities of current systems are listed in section B.4 and specific current systems are referenced throughout the RFP including Authority DMS (F.1.2), InspectCheck (F.3.39), Oracle Financials (F.3.42) as well as other systems including CAMRA, Benedict, Monday.com, HDS, Yardi, Mitas, & Encompass

138. We understand that the project will start in May 2026. Does IHDA have an expected system go-live date?

The go-live date will depend on the selected vendor's system capabilities.

139. Loan Payment Application – Is this referencing accepting online payments?

Section B.4. does not describe requirements, but a description of the strengths of our current system and third-party tool functionalities. The Loan Payment Application refers to the broad functionality tracking loan payments received, not accepting online payment which is not a current functionality.

140. Subsidy payouts – Can IHDA provide additional clarification on this requirement? Do you mean payments to properties for subsidy?

Section B.4. does not describe requirements, but a description of the strengths of our current system and third-party tool functionality. IHDA serves as the contract administrator for some rental assistance programs, including Section 811, which includes processing subsidy payments to properties.

141. Automated Data Population – Can IHDA provide additional clarification on this requirement?

Scoring will be based on how vendors describe how the DLS Solution enhances the submission process for Preliminary Project Assessments (PPAs) and funding applications, emphasizing advanced features such as automated data validation, real-time status updates, and seamless integration with other system components (compliance tracking, document management). Provide a streamlined, user-friendly experience for external users, including options for document uploads, dynamic form customization, and integration with IHDA’s existing systems for a fully automated workflow.

142. Can IHDA provide additional details on the type of integrations are needed and which systems the vendor will need to integrate?

Vendors are required to support commonly available integration methods including application programming interfaces (APIs), flat files, secure transfer protocols (STPs), Microsoft SQL Server (2016+), Azure cloud services, and online analytical processing (OLAP)/business intelligence (BI) tools (F.1.1). Specific integrations will depend on the selected vendor's system capabilities.

143. Which specific system are HUD XML files needed for? Can IHDA provide an example file or details describing the file?

F.3.13 provides points for external supporting external data standards, including HUD XML. Details on specific requirements will be defined after vendor selection depending on vendor capacity.

144. Can IHDA provide an example of current underwriting standards?

IHDA's current underwriting standards are available on the IHDA website:

https://www.ihda.org/developers/developer-resource-center/#toggle-id-11

145. F.3.21 - Is this a one-time import or reoccurring?

F.3.21 pertains to reoccurring data imports, not one-time transition from legacy systems. It awards points to vendors who describe their bulk data validation capabilities.

146. F.3.40 - Does IHDA plan to handle all reporting in-house (i.e., self-serve) or will the scope of this RFP include the vendor performing reporting (e.g., building custom dashboards, etc.)?

The DLS Solution must provide a sample report to demonstrate comprehensive reporting capabilities, including: Built-in tools for creating standard and custom reports; connectivity to external reporting platforms with performance specifications for concurrent users and response times; automated report scheduling and distribution with multiple delivery methods, frequency settings, and conditional report generation.

147. F3.41 Can IHDA provide additional details for the integration requirement with Property Insurance? How is this currently tracked by IHDA?

Vendors are required to support commonly available integration methods including application programming interfaces (APIs), flat files, secure transfer protocols (STPs), Microsoft SQL Server (2016+), Azure cloud services, and online analytical processing (OLAP)/business intelligence (BI) tools (F.1.1). The property insurance integration listed in F.3.41 is a desirable element but specific integrations will depend on the selected vendor's system capabilities.

148. F.3.67 – Bullet 4 – How these data points are linked to other system records.

Please clarify the IHDA’s expectation regarding how data points are linked to other system records. Is the intent limited to internal linkages within the DLS Solution (e.g., associations between reviews, programs, cases, users, and decisions within the same system), or is IHDA expecting integration or data synchronization with external systems? If external linkages are expected, please specify whether this requires real-time integrations, batch interfaces, or reporting-only connections, and whether specific external systems should be assumed?

Vendors are required to support commonly available integration methods including application programming interfaces (APIs), flat files, secure transfer protocols (STPs), Microsoft SQL Server (2016+), Azure cloud services, and online analytical processing (OLAP)/business intelligence (BI) tools (F.1.1). Specific integrations or internal system linkage will depend on the selected vendor's system capabilities and will be defined after vendor selection.

149. Exhibit B – Can IHDA provide additional details on expectations for how the items below need to be tracked? Clarify what/how this this should be tracked and is there an application needed for developers to apply for LIHTC?

a. % Low Income Housing Tax Credit

b. 4% Low Income Housing Tax Credit

c. 9%/4% Twin Low Income Housing Tax Credit

The vendor must show with evidence that it has functionality to support Low-Income Housing Tax Credit (LIHTC) compliance monitoring (F.2.13) and is awarded points for enhancing the submission process for Preliminary Project Assessments (PPAs), which would include LIHTC applications for developers (F.3.57).

150. Please provide additional detail on the Mortgage Insurance Premium (MIP).

Specifically, why is the MIP paid from the interest portion of the payment, and does the stated interest rate incorporate the MIP amount?

Specifics on special loan structure set up, including MIP, will be defined following vendor selection depending on the selected vendor's system capability.

151. Integrations: Would IHDA provide a full list of all required and desired system integrations for the Development Lifecycle Software Solution, including for each integration the data elements to be exchanged, direction of data flow, and the preferred integration method (e.g., API, SFTP/file exchange)?

Vendors are required to support commonly available integration methods including application programming interfaces (APIs), flat files, secure transfer protocols (STPs), Microsoft SQL Server (2016+), Azure cloud services, and online analytical processing (OLAP)/business intelligence (BI) tools (F.1.1). Specific integrations will depend on the selected vendor's system capabilities.

152. BEP timing: Would IHDA consider issuing an addendum to allow prime self-performance to satisfy the BEP goal if BEP certification is obtained prior to contract execution, rather than requiring certification by bid opening?

See BidBuy for any Addendums that are posted.