NEW YORK State Division of
Housing and Community
Renewal
Rent Regulation Transformation
REQUEST FOR PROPOSALS
RFP # RRT-090313
This RFP is posted on the Division of the Housing and Community Renewal website:
http://www.nyshcr.org/AboutUs/Procurement/
Issued: July 25, 2013
Submission Deadline: September 3, 2013, by 3:00 PM ET
Procurement Notice:
IMPORTANT NOTICE: A restricted period under the Procurement Lobbying Law is currently in effect for
this Procurement and it will remain in effect until State Comptroller approval of the Contract. Bidders are
prohibited from contact related to this procurement with any New York State employee other than the
designated contacts (refer to RFP A-7 Procurement Lobbying Form, and
https://www3.ogs.state.ny.us/legal/lobbyinglawfaq/default.asp).
Designated Contact(s) for this Procurement:
Kenneth J. Ford – Manager, Contracts and Procurement Unit
New York State Housing and Community Renewal
Hampton Plaza, 38-40 State St.
Albany, NY 12207
518-474-6434
kford@nyshcr.org
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Table of Contents
1
Calendar of Events and Milestones
5
2
Project Overview
2.1
Issuing Agency Overview
2.2
Overview of Rent Regulation
2.2.1 Office of Rent Administration
2.2.2 Tenant Protection Unit
2.3
Project Overview
6
6
6
6
13
14
3
Administrative Information
3.1
Contract Term
3.2
Pre-Proposal Conference
3.3
Post Conference Bidder Questions
3.4
Notice of Interest
3.5
Additional Information Related to This Procurement
3.6
Amendments and Addenda
3.7
Restriction of Communications
3.8
Primary Contractor and Subcontractor(s) Team
3.9
Participation by Minority Group Members and Women
3.10
Worker’s Compensation and Disability Benefits Certifications
3.11
Vendor Responsibility
3.11.1 General Responsibility
3.11.2 Suspension of Work (for Non-Responsibility)
3.11.3 Termination (for Non-Responsibility)
3.12
Ownership/Title To Project Deliverables
3.12.1 Definitions
3.12.2 Title to Project Deliverables
3.12.3 Contractor’s Obligation with Regard to ISV (Third Party) Product
3.12.4 Title and Ownership Warranty
3.13
Reservation of Rights
17
17
17
17
17
18
18
18
19
19
19
20
20
20
20
21
21
21
23
23
23
4
Mandatory Qualifications to Propose
4.1
Project(s) Meeting the Proposer Minimum Qualifications
4.2
Project Manager Minimum Qualifications
4.3
Technical Lead Minimum Qualifications
25
25
25
25
5
Scope of Services
5.1
Program Vision
5.1.1 Business Goals
5.1.2 Rent Regulation Transformation
5.2
Project Scope
5.2.1 Functional Scope
5.2.2 Technical Scope
5.3
Technical Environments
5.4
Technical Architecture
26
26
26
28
29
30
51
59
60
2
DHCR RFP for Rent Regulation Transformation
DRAFT V2
5.5
Software
5.6
Application Development Tools
5.7
Project Management-Related Required Services
5.7.1 Project Management
5.7.2 Relationship
5.7.3 Proposer Responsibility for Detailed Requirements Definition
5.7.4 Multiple Products, Services, Methodologies
5.7.5 Project Management and Control Methodology
5.7.6 System Development Life Cycle
5.7.7 Project Work Plan
5.8
Contractor Requirements
5.8.1 Work Location
60
61
61
61
62
62
62
64
64
65
65
70
6
Proposal Requirements
6.1
Technical Proposal
6.1.1 Table of Contents
6.1.2 Executive Summary
6.1.3 Verification of Mandatory Qualifications
6.1.4 Functional and Technical Requirements
6.1.5 Company Experience and Staff Qualifications
6.1.6 Staff Qualifications
6.1.7 Project Approach
6.2
Cost Proposal
6.3
Administrative Proposal
6.3.1 Title Page
6.3.2 Table of Contents
6.3.3 M/WBE Requirements
6.3.4 Procurement Lobbying Provisions and Forms
6.3.5 Vendor Responsibility Questionnaire
6.3.6 Assurances of No Conflict of Interest or Detrimental Effect
6.3.7 Workforce Employment Utilization
6.3.8 Iran Divestment Act of 2012
6.4
Submission of a Complete Three-Part Proposal
71
71
71
71
72
72
73
74
75
77
78
78
78
78
78
78
78
79
79
79
7
Evaluation Process
7.1
General Information
7.2
Submission Review
7.3
Technical Evaluation
7.3.1 Technical Proposal
7.3.2 Oral Presentations
7.4
Cost Evaluation
81
81
81
81
81
81
82
8
Award of Contract/Debriefing
8.1
Contract Award
8.2
Debriefings
83
83
83
9
Contractual Requirements
9.1
Contract
84
84
3
DHCR RFP for Rent Regulation Transformation
9.2
10
Appendices
Appendices
DRAFT V2
84
85
4
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Calendar of Events and Milestones
1
The purpose of this procurement is to identify a vendor that will assist New York State Division of Housing
and Community Renewal (DHCR) with the transformation of its Rent Regulation operation. It is
anticipated that a contract will be awarded in response to this Request for Proposals (RFP) based on the
following schedule:
Table 1, Key Dates in the Procurement Schedule
Date
Event
7/25/13
Issuance of Request for Proposals
7/31/13
Registration and Bidders’ Questions Due for Pre-Proposal
Conference
7/31/13
Expression of Interest Due
8/5/13
Pre-Proposal Conference
8/9/13
Closing Date for Bidder’s Post-Conference Questions
8/19/13
Response to Bidder’s Post-Conference Questions
9/3/13
Proposal Submission Deadline
9/19/13
Bidder Presentations
9/16/13
Notification of Selection
11/25/13
Approximate Start Date
Unless otherwise noted, the due time is 3:00 pm on the designated date.
Please note: the State reserves the right to change any of the dates stated in this RFP. If such
change occurs, the State will notify all Firms who received the RFP directly from the State and post
the change(s) on the Division of Housing and Community Renewal (Division/DHCR) website where
this RFP is posted.
5
DHCR RFP for Rent Regulation Transformation
DRAFT V2
2 Project Overview
2.1
Issuing Agency Overview
DHCR’s mission is to make New York State a better place to live by supporting community efforts to
preserve and expand affordable housing, home ownership and economic opportunities, and by
providing equal access to safe, decent and affordable housing. DHCR is responsible for the
supervision, maintenance and development of affordable low and moderate income housing in New
York State. The Division performs a number of activities in fulfillment of this mission through its offices
of Community Development, Housing Operations and Rent Administration.
The Office of Community Development administers housing development and community
preservation programs, including State and Federal grants and loans to housing developers to
partially finance construction or renovation of affordable housing. The Office of Housing Operations
has oversight and supervision of the State’s public and publicly assisted rental housing. Lastly, the
Office of Rent Administration is responsible for the rent regulation process for more than one million
rent-regulated apartments in both New York City, and those localities in the counties of Albany, Erie,
Nassau, Rockland, Schenectady, Rensselaer and Westchester subject to rent laws.
On June 24th, 2011 under the leadership of Governor Andrew Cuomo, New York State passed the
greatest expansion of the rent regulation process in 40 years. The objective of these changes was to
ensure that New York State’s rent regulated apartment units will properly remain in the rent regulation
system as required by these laws. Passing these new statutory provisions to extend and strengthen
the system was a critical first step. New York State DHCR also needed to implement significant
improvements to the State’s oversight structure through the creation of a strong strategic plan for the
new Tenant Protection Unit (TPU). With the new TPU in place, and a more efficiently operating ORA,
the State will be able to strive for organizational excellence while working towards the goal of meeting
the needs of the rent regulation community of New York.
Over the past year, DHCR has completed initial planning work for the transformation of the Rent
Regulation operations. The Tenant Protection Unit has been created. Opportunities for improving
operations have been identified and prioritized. Specific decisions have been made about how to
move forward in developing the systems that will support a transformed Rent Regulation operation.
These elements are elaborated in the sections that follow.
2.2
Overview of Rent Regulation
2.2.1 Office of Rent Administration
ORA is responsible for administering rent regulations covering regulated buildings on a day-to-day
basis. These regulations limit rent increases, require lease renewals, provide for the maintenance of
services/repairs, allow for rent increases for apartment and building improvements and prevent
harassment and unwarranted evictions.
The following are ORA’s mandates and objectives:


ORA preserves and maintains this adequate supply of regulated housing for approximately
2.5 million New Yorkers.
ORA administers the rent control and rent stabilization laws and regulations which includes
DHCR’s function as a custodian for all rental records required by law to be filed or maintained
by it. The rent stabilization laws and regulations are designed to provide owners with an
adequate return on investment while providing tenants with protection from burdensome rent
increases in a market with a persistent shortage of suitable rental housing.
6
DHCR RFP for Rent Regulation Transformation
DRAFT V2

ORA is responsible for protecting tenants from unlawful rent increases, harassment and the
threat of illegal evictions while ensuring their rights to well-maintained housing.

ORA safeguards the integrity of this regulated housing stock by providing mechanisms for a
reasonable return on investment for owners who maintain their buildings.

ORA considers and responds to the applications and legitimate inquiries of the tenants and
owners of the more than one million rent regulated apartments.
Rent Regulation involves the operation of four different rent regulatory schemes: Two within New York
City and two outside of New York City.
However, the New York City Rent Stabilization Law is the statute under which rent regulation primarily
operates. It covers approximately 850,000 units. It is administered by DHCR’s Office of Rent
Administration.
As a general framework, the Rent Stabilization System works as follows:
Rent Increases
Every tenant is entitled to a one or two year lease with increases set city-wide by the NYC Rent
Guidelines Board. These leases are served directly by owners to tenants without automatic government
review of the increases. Owners may also apply to DHCR (with the right of tenant challenge) for
additional increases based on a building-wide major capital improvement (MCI). In addition owners may
charge, without prior DHCR approval, for increases where there has been an improvement within an
apartment (Individual Apartment Improvement) (IAI). Where IAI’s are installed when the apartment is
vacant, there is no need to obtain tenant consent or DHCR review. The statute also provides for an
approximately 20% increase on vacancy with greater increases depending on the period of time the prior
tenant lived there (vacancy and longevity increases).
Rent Decreases
Tenants are entitled to have all services maintained. If they are not maintained, DHCR upon tenant
complaint may inspect the apartment and order (after owner notice and opportunity to contest the
procedures) the rent decreased by the last guideline increase and frozen at that level until DHCR issues
an order confirming restoration of the services. ORA has been following up on rent reduction
determinations to assure restoration or fines for violating DHCR determinations by its new “AI” and “code
red” procedures.
Rent Overcharges
If a tenant believes the owner has increased the rent by more than the owner is entitled, the tenant may
file an overcharge complaint with DHCR to get the proper rent calculated and get a refund with interest.
DHCR then asks the owner for all the necessary rent records and IAI information over the four year
period preceding the complaint filing, in order to calculate the rent. DHCR can only obtain more
information than the preceding four years, if there is a “fraudulent scheme to deregulate the apartment”.
DHCR will award three times the overcharge amount (“treble damages”) when an owner fails to establish
the overcharge wasn’t willful.
Deregulation
An apartment is deregulated upon vacancy when an owner can legally charge in excess of $2,500 per
month. The rent increases resulting in deregulation are usually a combination of IAI’s and vacancy and
longevity increases after the present tenant vacates but before the new tenant moves in. An apartment
can also be deregulated by application to DHCR when there is a tenant in occupancy whose income
7
DHCR RFP for Rent Regulation Transformation
DRAFT V2
exceeds $200,000 per year for two years (confirmed by NYS TAX) and the rent exceeds $2,500 per
month.
Registration
Owners are required to annually register each building and apartment subject to the Rent Stabilization
Law with DHCR. Tenants have the right to challenge each annual registration for accuracy by filing a
complaint with DHCR.
Public Information
DHCR operates an ambitious phone information function, has a robust record access system (but with
statutory requirements to keep certain information confidential) and an extensive community
outreach/public meeting componant.
Enforcement
DHCR divides responsibility between two separate program areas: the Office of Rent Administration and
the Tenant Protection Unit.
Structure
DHCR’s Office of Rent Administration (ORA) is responsible for administering rent regulations covering
privately owned buildings in NYC, Westchester, Nassau and Rockland counties. ORA considers and
responds to the applications and legitimate inquiries of the tenants and owners of over 900,000 rent
regulated apartments (which includes the 850,000 rent stabilized units previously referred to). It is
organized into four bureaus: Overcharge and Luxury Decontrol Bureau, Property Management Bureau,
Rent Control/Emergency Tenant Protection Act (ETPA) Bureau and the Rent Information Bureau.
ORA operates within the New York State Division of Housing and Community Renewal (DHCR). It is
organized into four bureaus: Overcharge and Luxury Decontrol Bureau, Property Management Bureau,
Rent Control/Emergency Tenant Protection Act (ETPA) Bureau and Rent Information Bureau. With the
exception of the Rent Information Bureau, the other three bureaus are major case processing bureaus.
The following section will cover the organization structure and major roles and responsibilities performed
by each bureau.
8
DHCR RFP for Rent Regulation Transformation
DRAFT V2
2.2.1.1 Overcharge and Luxury Decontrol Bureau
The Overcharge and Luxury Decontrol Bureau oversees cases related to overcharge and high
rent/high income decontrol. There are 72 full time employees (“FTE’s”) in this Bureau and it is
organized into four units: Overcharge Unit, “Luxury Decontrol” Unit, Operations/Eviction Unit and
Petition for Administrative Review (PAR) unit. This bureau processes cases related to overcharge,
luxury decontrol and eviction. The PAR unit processes all appeals of decisions which the bureau
issues. The following is an outline of the major tasks completed by each unit within the Overcharge
and Luxury Decontrol Bureau:
Overcharge Unit
This unit processes overcharges, lease renewals and fair market rent appeal complaints from tenants
residing in rent stabilized apartments. The unit processes substantial rehabilitation applications from
owners alleging that the building was substantially rehabilitated as residential units on or after
January 1, 1974 which would exempt the building from the Rent Stabilization Law. The unit also
processes an owner’s application to refuse to renew leases on the grounds that may include that the
building will be demolished.
Luxury Decontrol Unit
This unit processes all high rent/high income decontrol cases which provides for deregulation of
apartments dependent on the subject apartment’s legal rent, and the tenant’s federally adjusted gross
income.
Operations/Eviction
The Operations Unit screens new Overcharge/Luxury Decontrol applications. The unit prepares case
folders for the applications, and creates docket numbers and labels for the cases. The unit also
provides ongoing support to the Overcharge and Luxury Decontrol Unit by distributing incoming and
outgoing mail, and updating the status field in HUTS to reflect the location of the cases. The Eviction
Unit manages owner eviction and demolition cases. They handle eviction applications by owners
seeking not to renew a tenant’s lease based on withdrawal of the unit from the rental market or
demolition of the structure.
Petition for Administrative Review Unit (PAR)
Every processing bureau has its own PAR unit. That unit is responsible for determining if the Rent
Administrator’s orders are: correct and should be affirmed; incorrect and should be modified or
revoked; or remanded to the Rent Administrator for further investigation. The orders issued at this
level are Deputy Commissioner’s Orders and are generally considered final unless one of the parties
requests and is granted a Request of Reconsideration of the PAR order or proceeds with an Article 78
proceeding in court.
2.2.1.2 Property Management Bureau
The Property Management Bureau provides services to owners in the area of building-wide owner
applications related to Major Capital Improvements (MCl), hardship rent increases, tax abatements
and modification of building-wide services. There are 116 FTEs in this bureau. It also provides
services to tenants in the area of tenant applications related to the maintenance of individual
apartment and building-wide services. It also manages the Inspection Unit and
Enforcement/Compliance/Mediation Unit. The following is an outline of the major tasks completed by
each unit within the Property Management Bureau:
MCI Processing Unit
This unit processes building – wide owner applications for rent increases based on MCI, hardship rent
increases, tax abatements and owner applications for modification of building-wide services.
9
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Operations & Maintenance Unit (MCI)
This unit screens incoming applications. They prepare case folders for the applications, create docket
number and labels for the case. They also provide ongoing support to the MCI Processing Unit by
distributing incoming and outgoing mail, and updating the status field on HUTS to reflect the location
of cases.
Services Unit
This unit processes tenant applications related to the maintenance of individual apartments and
building-wide services, tenant complaints of harassment and tenant complaints of non-compliance
with DHCR orders.
Multi-Service Unit
This unit has multiple case types including MCI cases and Services cases from outside of NYC. They
also process Administrative Determinations where the status of an apartment is at issue or the rent is
unknown.
Operations & Screening Unit (Services)
This unit screens incoming applications for the Bureau. They prepare case folders for the
applications, create docket number and labels for the case. They also provide ongoing support to the
Services Unit by distributing incoming and outgoing mail, and updating the status field on HUTS to
reflect the location of cases.
Inspection Unit
This unit provides support to all case processing bureaus. Upon receipt of a request from a bureau,
an inspection may be scheduled and conducted. Inspectors are stationed in various offices located in
Queens, Brooklyn and Manhattan however they provide coverage for buildings located throughout the
five NYC boroughs and Nassau, Westchester and Rockland Counties.
Enforcement/Compliance/Mediation Unit
The Compliance Unit conducts mediation and if necessary, because mediation fails or is
inappropriate, may recommend that a formal administrative hearing be commenced resulting in the
imposition of Civil Penalties for violation of DHCR orders. The Enforcement Unit investigates and if
necessary, prosecutes harassment cases where the tenants claims that an owner is engaging in a
course of conduct designed to make the tenant vacate or surrender their rights under the rent laws.
PAR Unit
As already noted, every processing bureau has a PAR unit. The PAR unit for this bureau has 9 FTEs.
The unit is responsible for determining if the Rent Administrator’s orders are correct and should be
affirmed; incorrect and should be modified or revoked; or remanded to the Rent Administrator for
further investigation. The orders issued at this level are Commissioner’s Orders and are generally
considered final unless one of the parties requests and is granted, a Request of Reconsideration of
the PAR order or proceeds with an Article 78 proceeding in court.
2.2.1.3 Rent Control/ETPA Bureau
Rent Control/ETPA Bureau provides the administrative processing for rent controlled apartments and
produces rent control history reports for use in other cases where necessary. There are 40 FTEs in
this Bureau and it is organized into five units: Cyclical Cases Unit (MBR and Fuel), Owner Individual
Unit, Research and Analysis Unit, Request for Reconsideration Unit and PAR Unit.
Cyclical Cases – MBR and Fuel Unit
This unit processes Maximum Base Rent (MBR) and Fuel Cost cases (which are cyclical increases to
cover increased expenses) in NYC rent controlled apartments as well as challenges to both case
types.
10
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Owner Individual Unit
This unit processes rent control overcharge complaints, as well as owner individual filings or rent
increases and decontrol cases.
Research and Analysis Unit
This unit provides data to Nassau, Rockland and Westchester Rent Guidelines Boards. This unit also
updates the Standard Adjustment Factor, Operation & Maintenance Certification, Fuel Cost
Adjustment Factor and Labor Cost Adjustment Factor for use in cyclical cases. This unit is
responsible for updating the operational bulletins such as, “Surcharges for Tenant-installed Washing
Machines, Dryers and Dishwashers”, “Conversion from Master to Individual Metering of Electricity
with Direct Payment by Tenant” and the annual update for air conditioners surcharges.
Request for Reconsideration Unit
The Rent Control Bureau is charged with determining if a Request for Reconsideration on a PAR
issued by any processing bureau in the Office of Rent Administration (ORA) should be granted. One
attorney is assigned to this task.
11
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Petition for Administrative Review
As previously noted, every processing bureau has a PAR unit. The unit is responsible for determining
if the Rent Administrator’s orders are correct and should be affirmed; incorrect and should be
modified or revoked; or remanded to the Rent Administrator for further investigation. The orders
issued at this level are Commissioner’s Orders and are generally considered final unless one of the
parties requests and is granted, a Request of Reconsideration of the PAR order or proceeds with an
Article 78 proceeding in court.
Rent Guideline Boards
Each year, the rent guidelines boards of Westchester, Rockland and Nassau counties establish rent
guidelines for leases for apartments subject to the Emergency Tenant Protection Act of 1974, as
amended. The ETPA requires that Division staff assist the boards in their work. The Deputy Counsel
and two associate attorneys assist the boards by scheduling meetings; drafting for the boards’
approval minutes of their meetings; providing them with legal advice on the ETPA and the state’s
Open Meetings Law; and editing for legal issues the written rent guidelines. Other Division staff may
also assist the boards by finding meeting sites; answering case-processing questions and processing
the board members’ statutory stipends.
2.2.1.4 Rent Information Bureau
The Rent Information Bureau provides direct services to the public through a number of units. It has a
centralized telephone, Rent Info Line, an information email box, five New York City based Borough
Rent Offices and one Westchester County District Rent Office. There are 86 FTEs in this Bureau and
it is organized into five units: Records Access-FOIL/Subpoena Unit, Forms Unit, Staffing
Management/Administrative Service Unit, Borough Rent Office and Central Records Information
Service Unit. The following is an outline of the major tasks completed by each unit within the Rent
Information Bureau:
Records Access-FOIL/Subpoena Unit
This unit provides access to case files, orders and rent registration information.
Forms Unit
This unit is responsible for the creation and modification of all forms used by ORA as well as printed
material and its placement on the website.
Staffing Management/Administrative Services Unit
This unit works with DHCR staff in Albancy to coordinate personnel matters within ORA. The
Administrative Services Unit works with Albany staff and DHCR Street staff in Manhattan, distributing
supplies, managing building repair issues and related financial reporting systems.
Burough and District Rent Offices
The Burough and District Rent Offices provides localized public information assistance to tenants and
owners. The offices provide apartment registered rent histories as well as information about cases
that may affect the requesting tenant’s rent. In addition, the office provides owners with building and
case information. Owners and tenants can also receive technical assistance in completing DHCR
forms.
Central Records Unit
The Central Records Unit manages the filing, delivery, scanning and disposal of all case files.
12
DHCR RFP for Rent Regulation Transformation
DRAFT V2
2.2.1.5 Other Relevant Units
Processing Services Unit
The Processing Services Unit is located in Albany and there are 4 FTEs in the unit. The unit is
charged with making sure all of the initial, annual, amendment and vacancy decontrol registrations
that are received by DHCR are entered into “HUTS” ORA computerized database (whether such
submissions are paper, ARRO and RSA submissions). They also work with helping users of the
online system that owners use to enter annual registrations for submission to DHCR. They resolve
data integrity issues with the registration data, duplication of submissions for a building or apartment,
adding new building addresses into HUTS.
2.2.2 Tenant Protection Unit
The Tenant Protection Unit (TPU) is the centerpiece of a historic and unique approach by Governor
Andrew M. Cuomo, toward proactive enforcement of the various rent laws administered by DHCR.
In 2012 TPU launched two major audit initiatives to assure owner compliance with the rent laws: a
Rent Registration Initiative to assure that apartments were filing their annual registration as required
by law and an IAI (individual apartment improvement) audit. There are 22 FTEs in this unit.
Rent Registration Initiative
In examining DHCR data, TPU determined that since 2009, there were thousands of units which had
previously been registering with DHCR that had disappeared from the rent registration logs without
notice or explanation. This initiative is based on proactive outreach: notifying owners who have failed
to register their units since 2009; requiring them to either re-register their units or to provide an
explanation for their failure.
Individual Apartment Improvements Audits
Upon the vacancy of an apartment, owners are entitled to an increase of approximately 20% and the
cost of improvements made to the apartment such as new appliances and renovations (“IAI’s”). Some
owners have used false or incomplete claims of IAI renovations to illegally raise rents. TPU has been
conducting audits of many owners who through a combination of IAI and vacancy increases have
claimed significant increases in rent. “Proffer” letters were issued to owners who had provided less
than adequate responses to TPU’s initial request for information. TPU has also issued subpoenas to
a variety of owners who have failed to respond to either the first requests or proffer letters.
Status
In the decades of DHCR’s administration of this program, this is the most aggressive enforcement
initiative by any Governor or Commissioner to assure the legitimacy of increases. Further, due to the
registration outreach, the State experienced its first large-scale recapturing of rent-regulated units
with over 19,000 rent-regulated apartments re-registered. Owner groups have acknowledged that this
heightened level of scrutiny has already resulted in many owners more seriously undertaking their
obligations to maintain proof and evidence of appropriate business practices for review. These
actions, combined with Governor Andrew M. Cuomo’s June 2011 signing of the State’s strongest rent
laws since 1974, has not only brought greater stability to the rental housing stock, but has reduced
the loss of rent-regulated apartments. Having a proactive Tenant Protection Unit is a measured step
that informs the tenant and ownership communities that the Governor and DHCR are committed to
stabilizing the rent-regulated market through fair and balanced enforcement.
13
DHCR RFP for Rent Regulation Transformation
DRAFT V2
2.2.2.1 Audit/Investigatory Unit
The Audit/Investigatory Unit determines through research, constituent outreach, and risk
assessments, various entities to audit and investigate in order to assure compliance with rent laws
and regulations. The unit will then conduct these audits, investigations and inspections to
detect/determine potential landlord non-compliance, misrepresentations and/or fraud.
2.2.2.2 Legal Unit
In conjunction with TPU’s Investigatory Unit, the Legal Unit works to proactively prevent violations of
housing laws and root out fraud that impairs the rights of rent regulated tenants and may
inappropriately diminish New York’s rent regulated housing stock. TPU’s attorneys: 1) analyze this
investigatory data for fraud and other illegality; 2) commence litigation for injunctive relief and 3)
negotiate settlement agreements.
2.2.2.3 Forensic Analysis Unit
The Forensic Analysis Unit provides the necessary information to support new and ongoing audits
and investigations through analyses, reports, and dashboards. Information is sourced both from
internal agency data as well as various external sources. The unit also maintains the unit’s data
collection and monitors current and future performance measures for TPU.
2.2.2.4 Intergovernmental Affairs Unit
The Intergovernmental Affairs Unit is responsible for outreach to the community with a focus on
communications with landlord and tenant advocacy groups. The Unit conducts meetings with relevant
stakeholders to hear their input on the TPU’s actions and report back on the TPU’s progress. The
Unit responds to public officials and their staff when questions arise about the TPU. The Unit
monitors various related budget and legislative issues of concern to TPU.
2.3
Project Overview
The objective for this project is to facilitate a Business Transformation for the Tenant Protection Unit
(TPU) and Office of Rent Administration (ORA) divisions within DHCR (“The Rent Regulations
Solution”). This transformation will implement business process, policy and organizational changes,
in combination with new supporting technology, in order to enable both divisions to operate more
effectively in terms of current/ongoing service delivery.
DHCR is soliciting proposals from firms
having recent experience in the implementation of integrated Cloud-based IT solutions of similar
scope and complexity in the public sector. DHCR desires to contract with the Proposer for the
products and services described and characterized below (this is a summary list only; it is not meant
to be all inclusive):
 Provision of any and all necessary software based on one of, and not a combination of the
following technologies: IBM WebSphere/Lombardi, Microsoft Dynamics, Siebel and
Salesforce.com to meet business and functionality requirements; Proposer may bid up to four
solution options each based on one of these technologies;
 A solution that is based on mature, proven technologies (but not those that are at or near the
end of their life cycle). The solution proposed to DHCR must generally reflect the capabilities
available to the most technologically enabled state-wide rent regulation systems. DHCR
desires proposals for modern solutions, i.e., open solutions, modern database management
capabilities, and user-friendly interfaces;
 A complete solution for all its core business functions including case management and case
processing that permit DHCR to perform all of its operations as outlined in Section 5.2.1
Functional Scope and Appendix P – NYS DHCR Rent Regulation System Functional and
Technical Requirements Matrix and replace its existing History, Update and Tracking System
(HUTS);
14
DHCR RFP for Rent Regulation Transformation



















DRAFT V2
Assessments of the operational impact of the transformation opportunities identified herein,
plan for addressing changes in business processes and operations and Business Process
Reengineering (BPR) of DHCR current business processes, as necessary, to increase
processing efficiency and to drive the technology solution;
Business process services that are orchestrated using business rules and a defined
vocabulary;
Provision of project management services for the business transformation and implementation
effort as provided herein;
Support for the execution of all processes and transactions required in accordance with
applicable legislation, regulations, policies, etc., that are in effect on the date of contract
execution;
Browser-based access to these solutions for all appropriate stakeholders;
Role-based security and access within each solution;
Internet-based, self-service functionality to enable and improve access to DHCR data and
information by its stakeholders who will be provided with secure access to the solution (with
appropriate levels of security authorizations). The interface will be informative and also will
enable customers to intuitively process their own transactions and view relevant status
information;
Enterprise Content Management (ECM) System based on continued use of DHCR‘s existing
Content Server (formerly known as LiveLink) repository to capture and manage all paper and
electronic based content. Incoming paper documents must be scanned and the subsequent
distribution and management of all work that results from such documents (as well as
requests made by phone, the Internet, etc.) must be managed by a tightly embedded
workflow engine;
Ad hoc querying and reporting capabilities to provide executive, management and operational
reports including case reports and registration reports;
Ad hoc querying and reporting capabilities based on Data Warehouse, Data Analytics and
Business Intelligence;
Integration with Interactive Voice Response (IVR) technology to permit simple interactive
operations;
A suitable joint (DHCR Information Technology Services (ITS) and successful Proposer) onsite analysis of the current environment, resulting in the specification of a complete Cloudbased hardware and software environment that is consistent with New York State’s current
technical direction and that meets the requirements (including multiple physical and logical
environments) presented in this RFP;
Provision of any and all necessary Cloud-based development, test, training, User Acceptance
Test (UAT), staging/quality assurance and production environment as well as disaster
recovery site hardware, software and hosting services. Production environment and related
disaster recovery/business continuity services will start with the rollout of the first functional
capability and conclude 3 years after the rollout of the final capability anticipated at the end of
the 18 month duration of the implementation project;
Conversion and migration of DHCR current HUTS data to the solution and bridging of data as
necessary based on a phased implementation;
Appropriately protected data within the solution as prescribed by NYS IT standards;
Capability to analyze and audit workload performance and productivity metrics to support
operational business decisions and trend analysis;
Complete testing of all aspects of the solution, including unit, system, integration, and
regression testing as well as vulnerability testing as prescribed within this RFP;
Provision of change management and training for appropriate stakeholders – not only in
application navigation and the use of screens and windows, but also in the use of the new
solution to perform all of their various job functions, processes, and sub-processes in the new
environment;
Provision of Organizational Design and Performance Management Framework;
15
DHCR RFP for Rent Regulation Transformation













DRAFT V2
Provision of Quality Assurance to establish quality assurance procedures and processes, risk
identification, assessment, impact analysis and mitigation strategies, quality reviews, project
monitoring and reporting as well as subject matter advice, where applicable;
Provision of full implementation of the solution (including as-built documentation of system
code, configurations and customizations);
Provision of software support for the new solution during the implementation and continuing
through the warranty period as provided herein;
Provision of Knowledge Transfer to DHCR ITS staff during requirements analysis, design,
test, implementation and the warranty period so that DHCR ITS staff may be fully trained in
the solution, which it will ultimately service, maintain and enhance without Proposer
assistance;
Alignment of the proposed solution with the DHCR‘s Objectives as described in the RFP;
Enablement of all required system interfaces with external stakeholders, including those listed
in Section 5.2.1 Functional Scope;
Business rules management capabilities for business and technical staff;
Integrated and context sensitive help functionality features available to assist stakeholders
through business process tasks and workflows;
Audit capabilities such that a member‘s account can be identified as to whether it has been
audited, through what date and by whom;
A full security management suite that integrates with New York State Identity Management
Solution;
A warranty on all software, hardware and services that starts with the rollout of the first
functional capability and concludes 12 months after the rollout of the final capability.
Provision of DHCR-specific manuals and documentation for solution users administrators, and
developers; in addition to all baseline functionality, all such documentation must reflect the
customized, as-built status of the solution; standard documentation reflecting only the
Proposer‘s un-customized base solution will not be accepted; and
Provision of experience-based expertise and consultation to DHCR management on topics
such as suggested changes in staffing levels, communications, reorganization, and non-audit
services.
16
DHCR RFP for Rent Regulation Transformation
3
Administrative Information
3.1
Contract Term
DRAFT V2
The term of the contract will be for a period of 4 ½ years from contract signing with an option to extend
two additional one-year terms. This includes 18 months from contract signing for the implementation of
the new Rent Regulation System and 3 years of production operation of the system in a Cloud-based
environment provided and supported by the winning proposer.
3.2
Pre-Proposal Conference
Pre-Proposal Conference Registration
A pre-proposal conference will be held. To register, Bidders are directed to send an email to
kford@nyshcr.org with the following information:

The name, title, and contact information of the designated representatives that will be attending;

The email address of a contact person to whom DHCR can send a notification to the Bidder of the
Conference location;

Questions that Bidders would like discussed at the Pre-Proposal Conference.
Bidders are asked to notify the Division of their interest in attending and provide any questions for the
Conference by the time identified in the Calendar of Events.
Bidders bear any and all costs related to their attendance at the Conference (such as travel and
expenses). Electronic devices, such as recording devices, video cameras, etc. are prohibited during the
Conference.
Verbal responses provided by representatives of the State during the Conference are not formal and are
not binding. Formal written responses to the questions received during the registration period will be
published on the Division’s procurement web page:
http://www.nyshcr.org/AboutUs/Procurement/
3.3
Post Conference Bidder Questions
After the Conference, any questions or requests for clarification regarding the RFP should be submitted
via email, citing the RFP page and section, no later than the date identified in the Calendar of Events.
Questions will not be accepted orally and any question received after the deadline may not be
answered. The list of questions/requests for clarifications and the official responses will be posted to the
Division’s website at http://www.nyshcr.org/AboutUs/Procurement/ and notice of such posting will be sent
to all Firms who have been furnished the RFP by the Division.
Firms that receive this RFP or access it from a source other than the Division should contact the Division
at kford@nyshcr.org to confirm that their correct contact information is listed. This will ensure that every
Vendor will receive updates, amendments and/or addenda to this RFP.
3.4
Notice of Interest
Firms are asked to return an optional Notice of Interest Form (Appendix B) by the date identified in the
Calendar of Events. The form will be used as the basis of communications during the procurement period.
17
DHCR RFP for Rent Regulation Transformation
3.5
DRAFT V2
Additional Information Related to This Procurement
Additional information is available about relevant elements of the overall transformation initiative to those
vendors who submit an Expression of interest by the date due noted in the Calendar of Events and who
sign a Non-Disclosure Agreement included in the Appendices of this RFP.
Please note that this additional information is for background information purposes only. The information
is not to be relied on for any purpose. The scope and related requirements of this RFP are included in
this RFP.
To receive this information and as part of its bid submission, the Bidder is required to sign and submit to
DHCR a copy of the Non-Disclosure Agreement included in Appendix C.
3.6
Amendments and Addenda
DHCR reserves the right to modify any part of this RFP, including, but not limited to, the date and time by
which proposals must be submitted and received by DHCR, at any time prior to the Deadline for
Submission of Proposals listed in Calendar of Events. Modifications to this RFP shall be made by
issuance of amendments and/or addenda.
Prior to the Deadline for Submissions of Proposals, any such clarifications or modifications as deemed
necessary will be posted to the DHCR website and subsequent email notification will be provided to all
vendors known to DHCR that have received access to this RFP. DHCR also reserves the right to cancel
this RFP, in whole or in part, and to reject any and all proposals.
If the Proposer discovers any ambiguity, conflict, discrepancy, omission, or other error in this RFP, the
Proposer shall immediately notify DHCR of such error in writing and request clarification or modification of
the document.
3.7
Restriction of Communications
Firms that receive this RFP or access it from a source other than the Division should contact the Division
at kford@nyshcr.org to confirm that their correct contact information is listed. This will ensure that the
Vendor receives all updates, amendments and/or addenda to this RFP. All inquiries concerning this
procurement must be addressed to the following designated contact for this Procurement:
Kenneth J. Ford – Manager, Contracts and Procurement Unit
New York State Housing and Community Renewal
Hampton Plaza, 38-40 State St.
Albany, NY 12207
518-474-6434
kford@nyshcr.org
Bidders are prohibited from contact related to this procurement with any New York State employee or
representative other than designated personnel from the date this RFP is issued until the contract(s) have
been approved by the State Comptroller’s Office. Violation of this provision would be grounds for
immediate disqualification.
Further information about this restriction may be found at:
https://www3.ogs.state.ny.us/legal/lobbyinglawfaq/default.asp
18
DHCR RFP for Rent Regulation Transformation
3.8
DRAFT V2
Primary Contractor and Subcontractor(s) Team
The State seeks a total solution and vendors may partner to provide the required services and meet the
procurement’s M/WBE participation goals. Proposers must name a lead vendor as the Primary Contractor
that will serve as the legal contracting entity for the Project Period. If the proposal includes products or
services from any other participating vendors, it is understood that those vendors will serve as
subcontractors to the Primary Contractor.
For the purpose of evaluating proposals and developing the resulting agreement between the State and
the Primary Contractor, all contributions to the project from both the Primary Contractor and
subcontractor(s), including skills, attributes, and products, will be considered as a total solution put forth
by the single Proposer.
In the event that a “team approach” is proposed by a Bidder, a lead entity must be identified as the
Primary Contractor. All necessary communications will be directed to the Primary Contractor. In the event
that a contract award is made as a result of a proposal which has taken a “team approach”, the resulting
Agreement will be between the Primary Contractor and the State.
3.9
Participation by Minority Group Members and Women
DHCR values affording minority- and women-owned business enterprises (M/WBEs) the opportunity to
participate in the performance of the contract to be awarded for this project.
Accordingly, by submitting a proposal in response to this RFP, Proposers assert that they have made and
will continue to make good-faith efforts to promote and assist the participation of certified M/WBEs that
maintain and/or enhance the value of their proposals as subcontractors and suppliers on this project, in
an amount equal to ten percent (10%) MBE and ten percent (10%) WBE of the total dollar value of this
project. These participation goals shall be applicable to the contract as a whole and will be monitored by
DHCR.
DHCR policies in this regard are noted in Appendix D, M/WBE Reporting of this RFP. Proposers shall
respond to the participation goals established for MBE and WBE participation by completing and
submitting a M/WBE Utilization Plan) and Notice of Intent to Participate, contained in Appendix D M/WBE
Reporting of this RFP.
Proposers may apply for a partial or total waiver of these participation goals by submitting the Request for
Waiver, also contained in Appendix D. Waivers will be granted only where it appears that the Proposer
cannot, after a good faith effort, comply with the goals as stated above.
3.10 Worker’s Compensation and Disability Benefits Certifications
The successful Proposer must submit the following documentation within 48 hours of notification of
selection for award:
For Workers’ Compensation Documentation.
Upon notification of award, the successful Proposer will be requested to submit one of the following forms
as Workers‘ Compensation documentation:
CE-200 – Certificate of Attestation for New York Entities with No Employees and Certain Out-of-State
Entities, that New York State Workers‘ Compensation And/Or Disability Benefits Insurance Coverage is
Not Required
OR
19
DHCR RFP for Rent Regulation Transformation
DRAFT V2
C-105.2 – Certificate of Workers‘ Compensation Insurance (or U-26.3 if insured through the State
Insurance Fund);
OR
SI-12 – Certificate of Workers‘ Compensation Self-Insurance (or GSI-105.2 Certificate of Participation in
Workers‘ Compensation Group Self-Insurance);
For Disability Documentation
Upon notification of award, the successful Proposer will be requested to submit one of the following forms
as Disability documentation:
CE-200 – Certificate of Attestation for New York Entities with No Employees and Certain Out-of-State
Entities, that New York State Workers‘ Compensation And/Or Disability Benefits Insurance Coverage is
Not Required;
OR
DB-120.1 – Certificate of Disability Benefits Insurance;
OR
DB-155 – Certificate of Disability Benefits Self-Insurance.
ACORD forms are not acceptable proof of insurance. Further information is available at the Workers‘
Compensation Board‘s website, which can be accessed through this link: http://www.wcb.state.ny.us.
Please note that these forms are not required as part of the proposal submissions.
3.11 Vendor Responsibility
3.11.1 General Responsibility
The proposer shall at all times during the Contract term and during the bid evaluation process remain
responsible. The proposer agrees, if requested by the Commissioner of DHCR or his or her designee, to
present evidence of its continuing legal authority to do business in New York State, integrity, experience,
ability, prior performance, and organizational and financial capacity.
3.11.2 Suspension of Work (for Non-Responsibility)
The Commissioner of DHCR or his or her designee, in his or her sole discretion, reserves the right to
suspend any or all activities under this Contract, at any time, when he or she discovers information that
calls into question the responsibility of the successful proposer. In the event of such suspension, the
contractor will be given written notice outlining the particulars of such suspension. Upon issuance of such
notice, it must comply with the terms of the suspension order. Contract activity may resume at such time
as the commissioner or his or her designee issues a written notice authorizing a resumption of
performance under the Contract.
3.11.3 Termination (for Non-Responsibility)
Upon written notice to the contractor, and a reasonable opportunity to be heard with appropriate HCR
officials or staff, the contract may be terminated by the Commissioner of DHCR or his or her designee at
the contractor’s expense where the contractor is determined by the Commissioner of DHCR or his or her
designee to be non-responsible. In such event, the commissioner of DHCR or his or her designee may
20
DHCR RFP for Rent Regulation Transformation
DRAFT V2
complete the contractual requirements in any manner he or she may deem advisable and pursue
available legal or equitable remedies for breach.
3.12 Ownership/Title To Project Deliverables
3.12.1 Definitions
(i)
For purposes of this paragraph, “Products.” A deliverable furnished under this Contract by or
through Respondent, including existing and custom Products, including, but not limited to: a)
components of the hardware environment, b) printed materials (included but not limited to
training manuals, system and user documentation, reports, drawings), whether printed in
hard copy or maintained on diskette, CD, DVD or other electronic media (c) third party
software, d) modifications, customizations, custom programs, program listings, programming
tools, data, modules, components, and e) any properties embodied therein, whether in
tangible or intangible form (including but not limited to utilities, interfaces, templates,
subroutines, algorithms, formulas, source code, object code).
(ii)
For purposes of this paragraph, “Existing Products.” Tangible Products and intangible
licensed Products that exist prior to the commencement of work under the Contract.
Respondent bears the burden of proving that a particular product was in existence prior to the
commencement of the Project.
(iii)
For purposes of this paragraph, “Custom Products.” Products, preliminary, final or otherwise,
which are created or developed by Respondent, its Subcontractors, partners, employees or
agents for Authorized User under the Contract. This includes but is not limited to all writings,
inventions, improvements, processes, procedures, techniques, information and other
materials that may be furnished to Respondent or that Respondent may create, conceive,
discover or develop, either solely or jointly with any other person or persons, in connection
with the services that developed or created by Respondent or its personnel during the course
of performing the Services and/or creating the Deliverables. To the extent that any such
Custom Products, under applicable law, may not be considered to be owned by the Division,
the Respondent hereby assigns to the Division the ownership of all rights in such Custom
Product under patent, copyright and other applicable laws. Contractor will make full
disclosure to the Division of all such Custom Products, and will do everything necessary or
desirable to vest absolute title thereto with the State and the Division.
3.12.2 Title to Project Deliverables
Contractor acknowledges that it is seeking to be commissioned by the Division to perform the services
detailed in the RFP. Unless otherwise specified in writing in the Bid or contract, the Division shall have
ownership and license rights as follows:
21
DHCR RFP for Rent Regulation Transformation
DRAFT V2
3.12.2.1 Existing Products
1.
Hardware – Title and ownership of Existing Hardware Product shall pass to Division
upon Acceptance.
2.
Software – Title and ownership to Existing Software Product(s) delivered by Contractor
under the Contract that is normally commercially distributed on a license basis by the Contractor or other
independent software vendor proprietary owner (“Existing Licensed Product”), whether or not embedded
in, delivered or operating in conjunction with hardware or Custom Products, shall remain with Contractor
or the proprietary owner of other independent software vendor(s) (ISV). Effective upon acceptance, such
Product shall be licensed to the Division in accordance with the Contractor or ISV owner’s standard
license agreement, provided, however, that such standard license, must, at a minimum: (a) grant the
Division non-exclusive, perpetual license to use, execute, reproduce, display, perform, adapt (unless
Contractor advises Division as part of Contractor’s proposal that adaptation will violate existing
agreements or statutes and Contractor demonstrates such to the Division’s satisfaction) and distribute
Existing Licensed Product to the Division up to the license capacity stated in the Contract with all license
rights necessary to fully effect the general business purpose(s) stated in the (Bid) or Contract, including
the financing assignment rights set forth in paragraph (c) below; and (b) recognize the State of New York
as the licensee in addition to the Division. Where these rights are not otherwise covered by the ISV’s
owner’s standard license agreement, the Contractor shall be responsible for obtaining these rights at its
sole cost and expense. The Authorized User shall reproduce all copyright notices and any other legend
of ownership on any copies authorized under this paragraph.
3.12.2.2 Custom Products
Effective upon creation of Custom Products, Contractor hereby conveys, assigns and transfers to Division
the sole and exclusive rights, title and interest in Custom Product(s), whether preliminary, final or
otherwise, including all trademark and copyrights. Contractor hereby agrees to take all necessary and
appropriate steps to ensure that the Custom Products are protected against unauthorized copying,
reproduction and marketing by or though Contractor, its agents, employees, or Subcontractors. Nothing
herein shall preclude the Contractor from otherwise using the related or underlying general knowledge,
skills, ideas, concepts, techniques and experience developed under this Contract in the course of
Contractor’s business. The Division may, by providing written notice thereof to the Contractor, elect in the
alternative to take a non-exclusive perpetual license to Custom Products in lieu of the Division taking
exclusive ownership and title to such Products. In such case, Licensee on behalf of the Division and the
State of New York shall be granted a non-exclusive perpetual license to use, execute, reproduce, display,
perform, adapt and distribute Custom Product as necessary to fully effect the general business
purpose(s) as stated in paragraph (b)(i)(2), above.
22
DHCR RFP for Rent Regulation Transformation
DRAFT V2
3.12.3 Contractor’s Obligation with Regard to ISV (Third Party) Product
Where Contractor furnishes Existing Licensed Product(s) as a Project Deliverable, and sufficient rights
necessary to effect the purposes of this section are not otherwise provided in the Contractor or ISV’s
standard license agreement, Contractor shall be responsible for obtaining from the ISV third party
proprietary owner/developer the rights set forth herein to the benefit of the Authorized User at
Contractor’s sole cost and expense.
3.12.4 Title and Ownership Warranty
Contractor warrants, represents and conveys (i) full ownership, clear title free of all liens, or (ii) the right to
transfer or deliver perpetual license rights to any Products transferred to Authorized User under this
Contract. Contractor shall be solely liable for any costs of acquisition associated therewith. Contractor
fully indemnifies the Authorized User for any loss, damages or actions arising from a breach of said
warranty without limitation.
3.13 Reservation of Rights
DHCR reserves the right to:

Reject any or all proposals received in response to the RFP

Withdraw the RFP at any time, at the agency’s sole discretion

Make an award under the RFP in whole or in part

Disqualify any bidder whose conduct and/or proposal fails to conform to the requirements of the
RFP

Seek clarification of proposals

Use proposal information obtained through site visits, management interviews and the state’s
investigation of a bidder’s qualifications, experience, ability or financial standing, and any material
or information submitted by the bidder in response to the agency’s request for clarifying
information in the course of evaluation and/or selection under the RFP

Prior to the bid opening, amend the RFP specifications to correct errors or oversights, or to
supply additional information, as it becomes available and provide bidders with that information

Prior to the bid opening, direct bidders to submit proposal modifications addressing subsequent
RFP amendments

Change any of the scheduled dates

Eliminate any mandatory, non-material specifications that cannot be complied with by all of the
prospective bidders

Waive any requirements that are not material

Negotiate with the successful bidder within the scope of the RFP in the best interests of the state

Conduct contract negotiations with the next responsible bidder, should the agency be
unsuccessful in negotiating with the selected bidder

Utilize any and all ideas submitted in the proposals received

Unless otherwise specified in the solicitation, every offer is firm and not revocable for a period of
180 days from the bid opening, and
23
DHCR RFP for Rent Regulation Transformation

DRAFT V2
Require clarification at any time during the procurement process and/or require correction of
arithmetic or other apparent errors for the purpose of assuring a full and complete understanding
of an offerer’s proposal and/or to determine an offerer’s compliance with the requirements of the
solicitation.
Appendix A, Standard Clauses for State of New York Contracts, will apply to this contract. Depending on
the nature of the procurement, there may be additional state reserved rights beyond those presented
here.
24
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Mandatory Qualifications to Propose
4
A Proposer must meet all of the qualifications outlined below in this section. Failure to do so will result in
the rejection of the proposal.
All references in this RFP to the Proposer shall be construed to encompass both the prime contractor and
all subcontractors. However, the single source of responsibility shall rest with the prime contractor.
4.1
Project(s) Meeting the Proposer Minimum Qualifications
The Proposer must be able to cite at least three (3) previous public sector projects, from within the past
five years, which must be fully complete (i.e., in the warranty period or later), where the Proposer
successfully implemented a new information system for a Federal, State and/or Local government that
included the following:

Process transformation

Case management system

Provision of Cloud Solution and Services

Migration of a legacy system to an n-Tier system,

External agency system interfaces, and

Use of one or more of the following technologies that the Proposer is using in this proposal:
SalesForce.com case management
Microsoft Dynamics
Siebel
Websphere develop platform.
These requirements may be met by multiple projects. The Proposer is encouraged to cite at least one
New York City or a New York State public sector project that meets the qualifications.
4.2
Project Manager Minimum Qualifications
The Proposer’s Project Manager must have a minimum of five (5) years of experience in project
management and a total of ten (10) years of relevant professional experience. That experience must
include work similar in scope to that outlined in Section 5 Scope of Services.
4.3
Technical Lead Minimum Qualifications
The Proposer’s Technical Lead must have a minimum of five (5) years of experience in a technical lead
role using the technologies comprising the Proposer’s solution and a total of 10 years of relevant
professional experience. The experience must include work similar in scope to that outlined in Section 5
Scope of Services.
25
DHCR RFP for Rent Regulation Transformation
5
Scope of Services
5.1
Program Vision
DRAFT V2
5.1.1 Business Goals
New York State released a Tier II Assignment entitled the Rent Regulation Initiative that called for
DHCR’s Business Transformation and Technology Transformation.
As a result of the transformation
work that has been completed, a number of improvement themes and opportunities were developed. The
opportunities have been summarized along ten key themes which support ORA in meeting its mandate
and in enabling TPU to carry out its’ strategic objectives. The expected benefits of these themes are the
essence of the business transformation DHCR seeks. The improvement themes and opportunities are
summarized in the table below.
#
Theme
1
Improve
internal
Processes
Opportunities
•
•
•
2
Implement
internal ORA
Operational
Improvements
•
•
•
•
3
Enhance Data
Accuracy and
Integrity
•
•
4
5
6
Take steps to
reduce ORA
caseload
•
Information
Collection and
Sharing
•
Utilize
data
analytics
to
support
•
•
•
•
ORA/
TPU
Automate forms online with comprehensive error checks,
and links to databases
Decrease ORA processing times through improved
processes such as check lists, process flows,
standardization,
training,
automation,
standardized
templates
Implement new philosophy of case process times by
shifting time and effort away from case processing and
administrative processes to adjudication and decision
making
ORA
Develop and implement organizational wide performance
management methodology
Address technology challenges such as real-time reports,
thin client, etc.
Develop and implement staff training and cross training
Develop operational level agreements with HIS
ORA
Capture all missing building and apartment rent
registrations for relevant enforcement periods of review as
much as possible
Minimize the use of preferential rents being used to create
vacancy turnover or artificially raise legal rents (4-year rule)
ORA/
TPU
Reduce ORA case processing through improved triage of
cases, and improvement in data input and accuracy
Identify opportunities for changing delivery model for
certain services or move toward self service
ORA
Improve ORA technology to include case processing work
flows and reporting
Leverage existing data sources and integrate data where
appropriate (ORA TPU, HPD, housing court etc.)
ORA/
TPU
Investigate “standard data analytics” results (IAI, fraud etc.)
Improve ability to enforce rent regulations and related
controls
TPU
26
DHCR RFP for Rent Regulation Transformation
DRAFT V2
investigative
activities
Proactive
action against
problem
owners
•
8
Incentives
,
rent reduction
9
10
7
Proactively prevent non-compliance trends by identifying
problem owners associated with multiple buildings
Seek opportunities to improve tenant protection when
trends in non-compliance arise
TPU
•
Proactively grant rent reduction orders for building wide
service complaints etc.
TPU/
ORA
Increase
Access
to
Information
and
Transparency
of Data
•
Allow clients to lookup the detailed status of their open /
pending case(s) online
ORA/TPU
Build
awareness of
rights
and
obligations
•
Work with tenant groups, legislators etc. to increase
awareness of fraud and non-compliance
TPU/ORA
•
The DHCR Rent Regulation System will enable DHCR to accurately, efficiently and effectively administer
and oversee the rent regulation programs within the State of New York and foster a system of compliance
and self-regulation. As such, the objectives of the system are:
 Provide a more user-friendly web-based application to manage all rent regulation activities
including registrations of units, case management and case processing
 Implement business process improvements and automate paper-based processes to reduce
workload through automation
 Enable data analysis to monitor and respond to fraud and non-compliance matters
 Enable organization-wide performance management
 Provide management reports and response to queries
 Streamline internal communication through workflows and enhance data sharing with other
Agencies
 Provide a platform for future requirements of the organization
The key benefits and outcomes to be derived from the system include:
 Replacement of the existing HUTS system and related databases
 Improved Client Service and customer satisfaction for both landlords and tenants
 Reduced case processing times and faster response times that enable ORA and TPU to continue
to meet their objectives with limited resources through increased productivity and efficiencies
 Multiple channels of communications and consistent user experience across channels
 Provide a more robust mechanism for accurately tracking, analyzing and reporting on data
associated with rent regulation
27
DHCR RFP for Rent Regulation Transformation
DRAFT V2
5.1.2 Rent Regulation Transformation
The objective for this project is to facilitate a Business Transformation for the Tenant Protection Unit
(TPU) and Office of Rent Administration (ORA) divisions within DHCR that will implement business
process, policy and organizational changes, in combination with new supporting technology, thus
enabling both divisions to operate more effectively in terms of current/ongoing service delivery.
This rent regulation business transformation will be achieved through creation of improved, re-engineered
and new business processes with supporting policies, organizational structure and documentation of
related detailed business requirements. The project will leverage existing documentation and interviews
with TPU and ORA subject-matter-experts (SMEs), to create detailed business requirements and detailed
functional design including, but not limited to, Use Cases, screen mock-ups and navigation which will be
derived, documented and provided as input to the technical development activity described below.
Based on the Business Transformation activities, the objective of technical activities is to create a solution
that incorporates the functionality of the legacy HUTS case processing application and properly integrates
the case management, enterprise content management, document management, reporting, as well as
data warehouse and data analytics functionality.
Leveraging the detailed business requirements and detailed functional design as input, the Technical
Solution Architecture (also known as Detailed Technical Design) will be created. Based upon DHCR
approval of the Technical Solution Architecture, solution software development, testing and
implementation activities will follow.
The new solution will carry over existing HUTS functionality from the old system that is validated as still
relevant for the TPU and ORA. It will also embody the requisite functionality to implement the process
and policy changes/improvements captured through the Business Transformation activity.
28
DHCR RFP for Rent Regulation Transformation
5.2
DRAFT V2
Project Scope
Sections 5.2.1 Functional Scope and 5.2.2 Technical Scope provide summary information on the
business functional and technical requirements to be satisfied by the proposed solution. Additionally,
Appendix P provides a detailed listing (“Requirements Matrix”) of all business functional and technical
requirements to be satisfied by the proposed solution.
The consultant must respond to every requirement. The consultant must also respond to any
“specific instructions to respondents” by providing the page number in their proposal where the fulfillment
of the requirement is provided. Not providing the page number where the requirement is addressed in the
proposal will result in a lower score. Failure to respond to each and every requirement may lead to
proposal dismissal on non-responsive grounds.
Definitions of requirements in the Requirements Matrix are:
 Mandatory – The project requirements defined in this RFP, denoted as ‘Mandatory’, represent
the Mandatory requirements that must be met by each consultant’s proposal in order to be initially
deemed technically responsive to the RFP during the pre-screening evaluation phase. The
consultant must meet this requirement. Mandatory requirements are evaluated as either pass or
fail and are not included in the proposal score. If the requirement is not met, NYS DHCR may
deem this proposal to be non-responsive. Any proposal deemed to be non-responsive shall
eliminate the consultant and its proposal from further consideration.
 Desired – the requirement describes goods or services that the agency prefers, but that the
consultant is not obligated to propose. NYS DHCR will evaluate and document the degree of
responsiveness and numerically score responses to requirements denoted as ‘Desired’.
 OB – out of the box. Assumed to mean that the system meets the requirements without any of
the following being applicable. (COTS is acceptable)
 CNF – special configuration. Special configuration is the scenario where the product does not
include standard features built specifically to address the requirement in question, but the desired
results can be achieved by configuring the system in a specific way. A typical example of a
special configuration is the use of a workflow engine that supports business processes. The
workflow typically requires configuration to implement business rules that are unique to the
process. The application has a framework to alter the look or function of the application based on
data stored in supporting database table.
 CST – customization. This is the scenario where the standard product does not include features
built specifically to address the requirement in question, and where custom development effort is
needed to achieve the desired results.
 NAV – not available. The required functionality is not available and cannot be provided. This is
the scenario where the standard product does not have features built specifically to address the
requirement in question, and where the respondent does not recommend additional
customization to the software to meet the requirement.
The Proposer should provide a comprehensive proposal and apply its knowledge, understanding and
experience with technology enablers and align them with the functional business requirements.
The comprehensive proposal should take the following characteristics into consideration:
 Alignment with DHCR’s Business Goals;
 Improved functionality for all applications or transactions;
 A high degree of automation, interoperability, and integration with consideration for all the various
roles of internal and external stakeholders;
 A high degree of measurability;
 Ease of management and administration;
 A high degree of electronic capability including data exchange and collaboration using multiple
electronic communications channels;
 Streamlined and efficient business processes and workflow;
 Improved self-service capabilities for all stakeholders;
 A high degree of data accuracy and availability with appropriate data security where it is required;
29
DHCR RFP for Rent Regulation Transformation



DRAFT V2
A positive, intuitive, informative and navigable experience conducive to timely learning and
development with a high degree of user and customer satisfaction;
A high degree of flexibility and agility to adapt to ongoing and future replacements, updates and
innovations; and
Levels of risk that are acceptable to DHCR.
5.2.1 Functional Scope
The business functions constitute the primary services that enable DHCR, ORA, TPU and OLA to serve,
and interact with, its core customers - Owners, Tenants, Housing Preservation and Development (HPD),
New York State Unified Court System (OCA), and New York State Department of Taxation and Finance,
Office of Real Property Tax Services (TAX). They also represent the primary services that enable data
sharing with external agencies and systems: HPD, New York City Rent Guideline Board (RGB), New York
City Independent Budget Office (IBO), New York City Department of Finance (DOF), TAX, Owner Rent
Regulation Applications (ORRA) and Code Red.
30
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Registration
Receiving submissions of initial, annual, vacancy decontrol, and amendment registrations for buildings
and apartments is a primary function related to the administration of Rent Regulation in New York State.
The envisioned system would be required to accept registration submissions through all channels of
system interaction (online application, mobile app, email, fax, Interactive Voice Response (IVR), call in,
hand delivery, mail and scan). The system should:

Include functions to process Registration submissions beginning notification, tasks and workflow.

Log receipt of initial, annual, vacancy decontrol, amendment registrations for buildings and
apartments.

Provide ability to enter initial, annual, vacancy decontrol, amendment registrations for buildings
and apartments as registered entities within the system.

Provide the ability to handle multiple building registrations for a single registration year for
different owners and to attach the respective apartment registrations to the correct owner’s
building registration.

Provide ability to modify the registration information that is collected for a new year without
impacting the registration information collected for previous years.

Provide ability for authorized staff to add new building address information using a pre-assigned
building identification number or have the system generate a new building identification number.

Provide ability for authorized staff to delete building and apartment registrations that were entered
in error or amend such registrations while maintaining information as originally entered.
Case Processing
The core function of the Office of Rent Administration is to process cases related to the administration of
Rent Regulation in New York State. The envisioned system would be required to manage and process
cases related to Rent Administration and Tenant Protection. This would include docketing, workflow
management, automation of activities/calculations (where possible), closing and archiving of cases.
Specifically, the system should provide the following functionality:
1) Master File –The system should:

Provide a master file (apartment base) of the history of all regulated apartment units.

Create a master file of all known apartment units from the existing registration data.

Provide the ability to add/modify records.

Collect information specific to the apartment including but not limited to the Rent Control
Effective Date, Rent Stabilized Effective Date, Exempt Date, Exempt status, Apartment
Street Address and AKA apartment designations, unit rehab/consolidations.

Tie the master file creation process into the annual rent registration process to update the
information accordingly.

Support the annual NYC Finance billing.
31
DHCR RFP for Rent Regulation Transformation
DRAFT V2
2) Docketing – The system should:

Provide standardized functions to support the docketing of 60 case types including, but
not limited to, Senior Citizen Rent Increase Exemption (SCRIE) and Disability Rent
Increase Exemption (DRIE).

Create a unique docket number for each case entered.

Identify buildings and apartments associated with the case.

Collect the owner name and address.

Collect the owner and/or tenant representative name and address.

Collect sub-classifications based on case type.

Ability to relate newly docketed case to existing cases based on case type.

Include generation of an acknowledgement notice to the party that filed the case and
possible notifications to tenants, owners, managing agents, tenant/owner representatives
depending on the case type.

Provide means to collect additional information depending on the case type. This
information includes but is not limited to: items replaced in a major capital improvement
case along with cost of the items replaced.

Provide means to collect additional information depending on the case type. This
information includes but is not limited to: items not being maintained by the owner in an
individual apartment or in the building.

Provide means to collect additional information depending on the case type. This
information includes but is not limited to: the tenant name/address used on the annual
income tax form.

Provide means to collect additional information depending on the case type. This
information includes but is not limited to: fee payment received for maximum base rent
increase cases.

Provide means to collect additional information depending on the case type. This
information includes but is not limited to: types of fuel used and quantity consumed for
buildings with rent controlled units.

Provide means to collect additional information depending on the case type. This
information includes but is not limited to: data used to create a rent calculation chart to
determine if an owner is charging a tenant a rent that is higher than what should legally
be charged.

Provide ability to modify any case information after the initial entry of the data.

Provide ability for authorized staff to modify an apartment number/tenant name for an
open case. Store event at the case level noting the change.

Automatically assign cases based on case type to a specified bureau/unit, then staff
based on current workload.
32
DHCR RFP for Rent Regulation Transformation
DRAFT V2
3) Case Events – The system should:

Have standardized process to track entry of actions (events) taken against a case.

Allow events to be entered manually or be system generated. Event type, date, time,
comments and user/process that created the event needs to be collected.

Support multiple event types, including, but not limited to:
i. Docketed
ii. Assigned
iii. Transferred
iv. Closed (Grant, Grant in part, Denied, etc.)
v. Informational
4) Case Inspections – The system should:

Provide standardized process for requesting and tracking inspections that need to be
performed on buildings/apartments as necessitated by the case.

Generate correspondence to the owner/tenant regarding the scheduling, rescheduling,
cancellation of the inspection.

Generate an email to the Inspections Unit when the case processor requests an
inspection for the case.

Automatically schedule inspections based on staff workloads and location of building/unit
5) Special Judicial Review (SJR) Cases – The system should:

Provide ability for the Office of Legal Affairs (OLA) to log, assign and track SJR cases
that are filed against underlying ORA docketed cases.

Provide ability to log, assign and track appeals cases that are filed against an underlying
SJR case.

Provide inquiry screens for all users of the system (ORA and OLA) to look at the SJR and
appeals cases.
6) Non-rent Cases – The system should:

Provide ability to log, assign and track non-rent cases.
7) Freedom of Information Law (FOIL)/Subpoena Requests – The system should:

Provide the ability to log, assign, track and close FOIL/Subpoena requests from the
public. Information collected includes but is not limited to: the requester name, address,
phone number; who the requester is (owner, prospective owner, tenant, subtenant, etc.);
date request is received; the building that the request is related to (if applicable to the
request); what is being requested; court information for subpoena requests.

Generate correspondence to requesters.

Track money received for photocopies of records.
33
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Generate reports listing number, type of FOIL requests received, processed, charges,
KPIs.

The system should be designed prevent sharing of documents that are exempt from
public disclosure.
8) Mediation Cases – The system should:

Provide the ability to log, assign, track and close mediation cases. These are complaints
from tenants or owners where the participants have agreed to try to resolve the issue via
mediation

Provide ability to generate correspondence to the parties involved.

Track the phone calls made or received for the mediation case.

Generate management reports related to mediation cases.
9) Public Information – The system should:

Provide means to track the calls, walk-ins, correspondence received by staff by day and
the type of request.

Provide the ability to track the number of clients that were seen by staff by location.

Generate management reports related to public information.
10) Central Records – The system should:

Provide ability for staff to request information from the Central Records Unit. Information
requested includes but is not limited to: case files; copies of initial registration forms;
copies of registration cards.

Log the request, assign the request to a Central Records staff member and track the
progress of the request.

Allow the Central Records staff to create the next available box number for a specified
case type. This box number will be used to denote where the paper documents for a
case reside within Central Records with the paper documents are transferred from the
processing unit to Central Records unit.

Provide management reports related to Central Records.
11) Inquiry Functions – The system should:

Provide inquiry access for all building and apartment registration data, case data, OLA
data, FOIL/Subpoena data, Central Records request data, mediation case data.

Allow data being accessed by different search criteria – e.g., building id, owner name,
tenant name, case docket number, etc.

Allow supervisors to be able to inquire on cases assigned to subordinates.

Allow staff to be able to inquire on cases assigned to them.

Allow supervisors and staff to be able to inquire on their case workloads.

Limit inquiry access via the Web for non-DHCR staff.
34
DHCR RFP for Rent Regulation Transformation
DRAFT V2
12) Changes and Corrections – The system should:

Allow changes/corrections to existing case and registration data with a requirement for a
higher access level.

Provide ability for authorized staff to modify building identification numbers by changing
all records in the system that have the old building identification number value to the new
value. If registration records already exist under the new building identification number,
need to prevent the change if buildings are registered under the same year for the two
different building identification numbers. Store events noting the change of building id at
the building level and at the case level

Provide ability for authorized staff to modify the building identification number for a
specific docketed case. Allow the linking of apartments attached to the case to the
correct address occurrence under the new building identification number. Store event
noting the change of building id at the case level.

Provide ability for authorized staff to modify apartment numbers for a selected building
identification number. Should allow for a single registration year or for all registration
years. Store event noting the change of apartment number at the apartment level and at
the case level.

Provide ability for authorized staff to add/change the relation of existing cases to one
another.

Provide ability for authorized staff to change all cases assigned to a specific staff person
to a different staff person. Ability to further limit the cases transferred for the specific staff
person to a selected bureau, case type and/or case classification. The new staff person
must have the proper security levels to process the cases being transferred. Store event
at the case level noting the transfer.

For a specified case, provide the ability for authorized staff to enter a missing filing date,
modify the apartment status, modify the case type and/or classification, and modify the
bureau the case is assigned to. Store event at the case level noting the change.

Provide the ability for authorized staff to enter building information events for a specified
building or an apartment within a specified building. These may include but are not
limited to: building owner change, registration non-compliance, apartment status change,
building id change, apartment history change.
13) End User Functionality – The system should:

Allow users to effectively interact with the program's core data assets on a unified
platform.

Provided user access to of all key ORA and TPU datasets into one database repository.

Allow user to access the web based reporting server remotely.

Allow user to hyperlinks to various case related documents.

Automate all rent regulation process calculations.

Calculate all business formulas that are currently performed in HUTS.

Calculate all business formulas that are currently performed in ETPA.
35
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Conduct automated geocode address cleansing as users enter or update address
information.

Automate system decision support functionality including triage for escalated email alerts
for certain case types e.g., Code Reds.
14) Final Order – The system should:

Provide customized templates for each automated case type and determination.
Authorized ORA staff will have the ability to create and modify the templates.

Provide all orders in a standard format.

Support orders having digitized signature of the rent administrator in charge of the case
type.

Provide templates that allow the entry of additional data by rent examiners.

Provide templates that automatically merge case data from the system.

Provide a notification and approval function ability that allows the examiner to notify their
supervisor that the case is ready for review, the ability for the supervisor to notify the
examiner that changes need to be made, the ability for the supervisor to notify the rent
administrator of the unit that the case is ready to be reviewed, the ability for the rent
administrator to notify the supervisor that changes need to be made, the ability for the
rent administrator to approve the generation of the order.

Automatically generate orders for all recipients of the case determination: owners,
managing agents, tenants, tenant representatives.

Make copies of orders available in the Electronic Content Management system.

Provide order generation status reports.

Provide order generation process that has the necessary controls to provide proof of
mailing.

Have the ability to resend/reprint automated orders.
15) Index Values – The system should:

Automatically set index values when cases are closed.

Allow manually entry of case index values.

Provide online case index reports to the public.

Provide authorized ORA staff the ability to set index values by case type.
16) Batch Processing – The system should:

Process information entered by Rent Examiners: Generate Orders.

Process information entered by Rent Examiners: Generate Notices.

Process information entered by Rent Examiners: Update Case Status and Case
Information.

Process information entered by Rent Examiners: Transfer Cases.
36
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Process information entered by Rent Examiners: Index Cases.

Process information entered by Rent Examiners: Produce Reports.

Process information entered by Rent Examiners: Populate Data warehouse.

Implement Registration processes: Load large annual registration submissions.

Implement Registration processes: Produce Reports.

Implement Registration processes: Populate Data warehouse.
Core Case Management
More complex case types would require enhanced case management functionality that would enable the
organization to adequately and appropriately manage these case types. This would include the ability to
assign cases, actions, activities etc. Specifically, the system should provide the following functionality:
1) Organizational Structure – The system should:

Maintain an Organizational Structure for all users of the system.

Maintain an unlimited number of levels for the organization structure to manage staff,
supervisors, manager and executive staff.

Have the ability to assign roles, responsibilities and positions to users.

Integrate with NYS ID Management to limit the views/screens and data that the user can
access based on their roles, responsibilities and positions.
2) Dashboard – The system should have the ability to configure and display process/performance
dashboards.
3) Home Page – The system should:

Allow users to view their Home Page after logging in.

Display information on the Home Page based on the organization, role and responsibility
of the user.

Allow the user to customize their Home Page.

Have the ability to display dashboards on the Home Page.
4) Reference Tables – The system should:

Allow administrators to add and update records in reference tables.

Allow deletion of items from reference tables that are referenced.
5) Print – The system should have web browser printing available to users to print an image of the
current screen and include identifying information such as system date, system time and person
logged in.
6) Case Management – The system should:

Provide staff the ability to review the history of tenant/owner’s prior case submissions,
complaints, requests and results/determinations.
37
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Maintain an audit trail of activities performed by users.

Provide staff the ability to review the history of case activities.

Be able to print all case management forms at any given point (e.g., when a court request
is made, when a case manager needs to review documents, etc.).
7) Profile – The system should:

Have
the
ability
to
capture
tenant/owner/building/apartment.

Have the ability to associate tenants/owners/buildings/apartments and identify the type of
relationship in the association.

Have the ability to attach a start and end date to each relationship established in the
system for tenants/owners.

Utilize the user-defined case contact for all correspondence and communication.

Have the ability to track updates to profile information via a historical audit trail.

Track changes of relationships between tenants and owners via a historical audit trail.
key
identifying
information
for
a
8) Resources Management – The system should provide the ability to manage all resources within
the system.
9) System Search – The system should:

Have the ability to search for all resources in the system by various criteria.

Have comprehensive search capability for all defined fields in all case management
records.

Have the ability to perform a sound-ex and/or sounds-like search.
10) Time Specifications – The system should allow for the entry of time assuming a 24 hour clock
format (i.e. military time - hh:mm:ss.tt).
11) Data Entry Specification – The system should:

Support spell checking of any free-form text entered.

Require users to enter free-form text when "other" is selected in picklists.

Have the ability to ensure that all required fields are populated and checked for
appropriate values.
12) Address Specifications – The system should:

Normalize all addresses.

Support the ability to automatically geo-code addresses by interfacing with New York
City's existing GIS system.

Prompt users to confirm the address is correct if it was updated after geo-coding and
normalization.
38
DHCR RFP for Rent Regulation Transformation
DRAFT V2
13) Document Search – The system should allow users to locate documents via a text-based search.
14) Policy Document – The system should contain a link to access DHCR policy documentation.
15) Archiving and Purging – The system should:

Provide staff the ability to archive case information. This historical information should be
moved from the production environment to an archived environment and remain
accessible for historical analysis and reporting.

Allow purging of data and documents based on policy and business rules.

Present a listing of records to be purged for review prior to physically purging any
information.

Have configurable purge data specifications.
16) Forms/Questionnaires – The system should:

Pre-populate questionnaires and forms with available data.

Determine questions on questionnaires / forms based on previous answers.

Store complete forms, questionnaires, letters and other documents.

Allow authorized users to retrieve, view and print the documents in their original form as
they were created and stored.
17) System Specifications – The system should:

Maintain an audit trail of activities performed by users.

Designate access rights to view the audit trail based on user role.

Allow system administrators to view all audit trails.

Not allow users to modify the audit trail records.
18) Appointment – The system should be able to schedule/re-schedule appointments with a
tenant/owner.
19) Workflows and Notifications – The system should:

Support work queues for all organizational departments, individual roles and pre-defined
functions.

Have the ability to use defined workflows to route work items to appropriate queue based
on the work item type.
As the work item progresses, the case would be
enhanced/adjusted appropriately.

Allow management to view the work list/queue for their units/users; understand the
volume of that work and the rate of productivity in terms of processing the work.

Expedite communications and standardize correspondence between workers through the
automation of workflow.

Automate, provide an improved service delivery process and increase operational
efficiency through: Electronic processing tools that help staff complete tasks in a timely
manner, such as immediate access to case records.
39
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Provide the ability to generate tasks required for staff to coordinate standard case related
activities including but not limited to notifications, scheduling/re-scheduling appointments,
document checklists.

Support workflow through tasks for specified functions within the system. DHCR
management and staff will be automatically notified of critical and non-critical events
which will serve to facilitate the monitoring of all tenants/owners within active cases.
DHCR users must be able to reserve and/or assign tasks to themselves or other
authorized staff.

Allow authorized users to sort and filter their work lists/queues.

Allow management to view the work list/queue for their units/users.

Display basic data/descriptive information for each queue.

Have the ability to allow designated staff to modify the rules that determine how a work
queue operates.

Support time-sensitive task assignment, including the
supervisors/managers for timely assignment or execution of tasks.

Have the ability to prioritize tasks for critical incidents, time-sensitive events and actions.

Provide supervisors and staff with the ability to categorize a task as a higher priority for
immediate response.

Have the ability to store historical tasks timeliness of completion statistics for trend and
performance metric reporting.

Allow the system administrator to be able to enable/disable notifications for users.

Allow user defined tasks and workflow, directed to a specific user or group.

Have the ability to identify and escalate overdue tasks.
ability
to
notify
Court Orders
The system should be able to capture and manage court orders within the system and associate them
with the appropriate tenant/owner cases and allow the agency's systems administrator to maintain the
standard picklist of court order directives / activities through an administrative component. Specifically,
the system should provide the following functionality:
1) Case Outcome – The system should:

Have the ability to capture sentence or disposition type for a case outcome.

Have the ability to capture final case outcomes.

Associate final case outcomes to the applicable dockets.

Have the ability to capture sentence or disposition date for a case outcome.
2) Security – The system should integrate with NYS ID Management to provide the ability to restrict
access to Court Order information based on user roles.
40
DHCR RFP for Rent Regulation Transformation
DRAFT V2
3) Scheduling – The system should:

Trigger a task to designated staff to review and resolve possible conflicts when multiple
court appearances are scheduled on the same day.

Support notifications to staff of upcoming court appointments.
4) Document Management – The system should:

Support the association of electronically captured or generated documents with a specific
court order.

Support the scanning and association of scanned court documents with a docket number.
5) Workflow and Notifications – The system should:

Have the ability to generate tasks and workflow to designated staff based on the
directives / activities required by a court order.

Have the ability to track court order progress through tasks originating from the receipt of
an order. This will enable multiple units to complete and provide details necessary to
facilitate completion of a court order.
Incident Reporting
The system should provide the ability for an authorized user to create a new incident in the system and
associate it with an existing case or create a new case entirely, thus beginning notification, tasks and
workflow. Specifically, the system should provide the following functionality:
1) Incident Reporting – The system should:

Generate and assign a unique incident number to the incident.

Provide the ability to look-up and associate an incident to tenants, owners, buildings and
apartments. The process should minimize duplication of already registered entities within
the system.

Provide the ability to look up incident histories of owners, tenants, buildings and
apartments.

Ability to record required information to establish an incident report and begin workflow or
notification activities.

Automatically capture the date and time that the incident is created.

Require entry of the date and time the incident occurred.

Require the facility/location to be recorded when recording minimal incident information
for an initial incident report.

Support a standard picklist for use in incident reporting.

Allow the agency's systems administrator to maintain the picklist used in incident
reporting.

Support the identification and association of multiple events to a single incident.

Display the events and descriptions under an incident on the same screen, so that the
user can view them at one once.
41
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Distinguish between critical and non-critical incidents based on the event type(s) and
attributes associated with an incident.

Require a free-form description of the incident.

Require entry of an Incident narrative, which is a chronological description of the incident.

Have an audit trail of updates made to an incident.

Only allow users to make updates to finalized incidents by adding notes.

Have an administrative component to allow the agency's systems administrator to
maintain a picklist of incident and event types.

Have the ability to display a definition of each incident event type.

Have an event type of ""Manager's Requested Incident"" for incident reporting to allow
entry of non-standard events.

Associate a status and stage with each incident.

Have the ability to search for incidents by status.

Have the ability to associate photographs, whether scanned or digitally captured, with a
specific incident.

Provide the ability for an authorized user to upload and associate videos with a specific
incident.
2) Workflow and Notifications – The system should:

Provide notifications and tasks to staff related to the incident based on established
business rules. These will be used by staff to initiate or perform a follow-up action
associated to an Incident.

Send an electronic notification to designated parties when an incident is entered, based
on the type of incident.

Have the ability to associate the workflow task to the incident in which it originated.

Allow staff to notify other staff members based on their discretion during any phase of the
Incident.

Provide the ability to automatically or manually trigger escalations of tasks requiring
actions or follow-up.

Allow an incident to be closed or completed prior to closure of all tasks associated with
the incident.

Assign incident-related tasks a priority based on the incident and event type.

Have the ability to auto generate tasks based on a specific incident type and event type.

Have the ability to view workflow tasks initiated as a result of incidents by status, staff
assigned, or specific incident.

Have the ability to track the status of an incident and necessary actions through tasks,
including all actions and events initiated during and after an incident.
42
DHCR RFP for Rent Regulation Transformation
DRAFT V2
3) Reporting – The system should allow each user to create pre-defined queries for a specific
"report" which is more of a saved search related to incident reporting, and run that "report" daily.
4) QA Review – The system should:

Produce a monthly list of incidents for QA reviews, including: incident reporter, person
reported to, incident number, date, facility, event type, and incomplete incident
information by facility.

Record the date, time, and name of the reviewer for QA reviews of all incidents.

Support entry of free form text for QA comments resulting from QA reviews of all
incidents.
5) Security Access – The system should integrate with NYS ID Management to allow viewing of
incidents to be restricted to specific user roles.
6) Document Management – The system should support the association of electronically captured
or generated documents with a specific Incident.
Enterprise Content Management
Many cases handled by the ORA and TPU will involve the management of documents and
correspondence. This could include a variety of formats such as email, letters, pictures, diagrams, court
orders etc. These documents could relate to a single case or multiple cases. The system would require
the functionality to manage and store these documents to support the management and processing of
cases. As such, the system should have the ability to provide a web-based Electronic Content
Management process and provide the ability to associate documents, whether electronically generated or
scanned, to a case file. Specifically, the system should provide the following functionality:
1) Document Scanning – The system should:

Have the ability to allow staff to categorize documents identified for scanning.

Have the ability to allow authorized users to scan documents.

Have the ability for designated staff to approve documents that have been scanned into
the system.

Capture the following details for scanned documents:
i. Scanner location (configurable)
ii. User ID (who scanned)
iii. Date/Time

Allow a scanned document to be re-assigned to other cases within the system in the
event of being assigned to an incorrect case.

Initiate tasks to designated staff for review upon the re-assignment of a scanned
document.

Have the ability to associate a task with the scanned document that originated the
creation of the task.

Have the ability to allow batch scanning of multiple documents.
43
DHCR RFP for Rent Regulation Transformation
DRAFT V2
2) Document Indexing – The system should:

Have the ability to allow staff to record the key elements/attributes of the scanned
document to help index the documents.

Maintain Document Categories and Document Types.

Have the ability to allow the authorized user to update the Document Categories and
Types as necessary.

Provide the ability to utilize Optical Character Recognition when indexing documentation.

Provide the ability to Bar-Code documents.

Have the ability to record a reference value, which relates to the actual location of the
original document.

Allow a process to assess non-indexed documents.

Allow authorized users to select, view and index documents in the queue.

Allow authorized users to select, view and delete documents in the queue.
3) Workflow – The system should:

Have the ability to route a scanned document to a queue.

Have the ability to allow the system administrator to define and maintain standardized
multi-step workflows for incoming documents that are scanned into the system. This will
support processes to review, associate and handle the documents.

Have the ability to use defined workflows to route documents to appropriate queue based
on the document type or other parameters.

Have the ability to allow the operator of the scanner to select a workflow for a document
from a picklist of standard workflows.

Have the ability to create steps in standardized workflows that allow users to route
documents to additional queues when required.

Have the ability to allow users to attach documents to tasks generated within the system.

Integrate with NYS ID Management to provide administrators the ability to grant users
permission to override the assigned workflow, and send documents to other users, in an
ad-hoc fashion.

Allow users with appropriate security roles to override specific information during the
workflow and Electronic Content Management process.

Allow notifications to designated staff to be sent based on the document type scanned
into the system.
4) Document Upload – The system should:

Provide the ability to import soft copy of documents received via email and fax.

Have the ability to import soft copies of documents received in at least the following
formats: Microsoft suite, JPEG, TIFF, PDF, and email (.TXT or .MSG).
44
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Provide the ability for an authorized user to upload and associate pictures and videos
with a case file.

Provide the ability for authorized users to upload documents from a computer or network
drive.
5) Security Access – The system should:

Integrate with NYS ID Management to provide the ability to allow users as well as groups
of user’s access to queues based on security roles.

Integrate with NYS ID Management to provide restricted access to the documents based
on the document type and security role of the user.

Integrate with NYS ID Management to allow limited access to the documents within the
case to defined users based on case status and other criteria.

Integrate with NYS ID Management to allow authorized users to manage access
privileges to documents based on type, category, and other parameters.

Integrate with NYS ID Management to provide the ability to control access to view
document types based on user role.
6) Document Repository – The system should have the ability to maintain and add documents to a
centralized State document repository that is controlled through secured role-based access.
7) Document Search – The system should provide the ability to search and filter documents using
document metadata.
8) Document Status – The system should:

Have the ability to save "work in progress" documents that can be edited multiple times
until final.

Have the ability to associate a status (final, draft, etc.) with documents scanned into the
system.

Have the ability to allow notes to be classified by a pick list of standard types.
9) Document and Correspondence Creation and Generation – The system should:

Have the ability to generate documents used for mailed correspondence.

Have the ability to generate forms and letters based on predefined templates and fill
those forms with the data stored from within the system.

Have the ability to allow user to select a form/letter for generation.

Have the ability to allow user to generate a form/letter based on a workflow rule for the
user to review and submit.

Have the ability to pre-populate much of the data in the templates during the time of
generation.

Have the ability to allow users to fill in sections of the document during the time of
generation.

Have the ability to allow users to print documents that were previously generated.
45
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Have the ability to allow users to save documents during the process of generation.

Have the ability to retrieve a previously system-generated document and use it to create
a new document.

Not allow previously saved final documents to be modified.

Have the ability to select notes for placement on forms based on note type.

Have the ability to record details of the document generation such as the user creating
and/or modifying and date/time of creation/modification.

Have the ability to save data used to produce a document, so as to enable users to
reproduce the original copy of the document at a later time.

Provide option to send correspondence via email, paper or both.

Provide a standardized process for examiners to create notices/requests for additional
information to a particular party involved with the case.

Allow Examiners to be able to select boiler plate text and/or enter free form text and
should be able to assign a due date for the party’s response.

Automatically resend the notice if a response is not received by the due date.

Provide ability to manually resend the notice if a response is not received by the due date

Allow Authorized ORA and TPU staff to create boilerplate notices, set initial and late
response periods and determine which case types will use the boilerplates.

Make copies of notices available in the Document management system.

Provide Tickler activity reports. When the examiners need more information for a case
they create a tickler notice to the appropriate party of the case requesting the information.
For each item requested on the tickler notice there is a due date for the response for that
particular item and an indicator of whether a second notice will be sent if the party does
not respond by the due date. Tickler activity reports list the tickler notices generated for
a case, the number of tickler notices created by week and by type (first notice, final
notice, acknowledgement notice, extension approved/denied), the cases where the
tickler notice processing has been completed and case processing can resume.

Allow ability to resend/reprint automated correspondence.
10) Document Control – The system should:

Have the ability to support versioning of the documents/templates to enable the
reproduction of the original document even after a template version changed.

Allow documentation to be checked-in and checked-out of the system.
11) Audit – The system should have the ability to associate a time/date and user with a document
when it is interacted (e.g. viewed, edited, etc.) with by a user.
12) Support Paperless Process – The system should:

Position ORA to move to a paperless process, eliminating paper case files.

Implement processes and procedures for scanning all incoming correspondence.
46
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Implement image-destroy policy.

Implement retention periods for all stored documents.

Implement policy for accessing electronic documents.

Support handling electronic correspondence to/from owners, tenants, owner/tenant
representatives.

Provide proof of receipt of electronic correspondence.
13) Workflow for Case Triage – The system should:

Utilize automated web based workflows for TPU and ORA case processing.

Provide for full integration with DHCR's existing Electronic Content Management system.
Content Server (formerly known as LiveLink).

Provide optional batch workflow processing for cases

Allow for workflow configuration at the unique task level.

Provide a workflow simulation module that will used for future workflow modifications and
developments

Provide an optional production mirror data set for workflow simulation

Allow for role based testing and integrated test module reporting that will integrate with
SSRS in a separate data cube.

Allow for end user batch based simulation and testing.

Integrate with HIS SQL Server existing reporting tools and Electronic Content
Management system (Content Server formerly known as LiveLink) metadata elements.
Reporting
As with any mature government organization, the management of performance, outcomes, and resources
requires regular and ad-hoc reporting. The system will be required to provide standard, customizable, and
ad-hoc reporting as well as querying on a regular basis across various levels of the organization relating
to a number of key metrics. These reports should be provided on a timely basis and be adaptable to
future requirements of the organization. The new system’s reporting capability will duplicate the existing
Report Distribution System (RDS) system capabilities. RDS will continue to operate and serve other
systems once the new system commences production operations. Specifically, the system should
provide the following reporting functionality:
1) General – The system should:

Have the ability to generate standard executive, management, operational reports
including case reports and registration reports.

Have the ability to create ad hoc reports and respond to queries.

Have a management reporting dashboard that reflects key operational metrics from the
real-time operational database.

Have the ability to trigger reports for specific users through tasks and notifications.

Support generation of reports from the real-time operational database.
47
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Have the ability to run standard reports.

Have the ability to create ad hoc reports.

Provide the ability to create new reports.

Provide users the ability to select field-level criteria for the creation of a report.

Provide users the ability to enter, save, select, and modify computational formulas in the
creation of reports.

Provide the ability to view drill down reports.

Have the ability to output reports for online review and in printer-friendly hardcopy
versions.

Have the ability to create reports with user-defined date ranges as selection criteria.

Have the ability to limit access to generate reports based on defined user roles.

Have the ability to limit access to create new reports based on defined user roles.

Have the ability to limit access to save new reports based on defined user roles.

Have the ability to limit access to delete reports based on defined user roles.

Have the ability to limit access to modify reports based on define user roles.

Have the ability to limit access to run / view reports based on user roles.

Allow authorized users to generate reports based on the alerts sent by the system.

Support the generation of reports from data marts that are extracts, aggregations, and
summarizations of data from the real-time operational database.

Support limits on ad hoc reporting from the real-time operational database to minimize
the performance impact.

Be able to export reported data to PDF, CSV, and XLS formats.

Have the ability to generate reports based on a variety of selection criteria already
defined in the system.

Have the ability to create system-generated reports that are generated at a predefined
timeframe.

Ability to create system-generated reports and automatically issue to identify users via
email.

Create a solution that encompasses all HUTS, ETPA, and reporting capabilities. The
functionality will duplicate the existing RDS functionality. Note: RDS will continue to
serve other systems once the new system is operational.

Include dashboards / scorecard tools and analytical reports that will be accessible via
SharePoint. Reports will include functionality for dynamic public facing reports
48
DHCR RFP for Rent Regulation Transformation
DRAFT V2
2) Rent Regulation Transparency – The system should:

Enable increased Rent Regulation transparency by consolidating data that is needed for
Freedom of Information Law (FOIL) requests.

Facilitate the utilization of dynamic portals for report access and application access for
internal and external audiences.

Report on Counts of rent regulated apartments, registrations, cases (active and inactive)

Report on % of rent regulated apartments by, county, zip code, community area, etc.

Report on rent violations.

Report on case statuses.

Report on rent case processing times.

Report on trends in Affordable Housing.

Report on Rent Registration Compliance by county, zip code, community area, etc.

Provide mailing list functionality for automatic case updates and DHCR Rent Regulations
updates.

Generate reports for filtered data: volume, occupancy, speed of case processing, etc.

Integrate with the existing DHCR Rent Inquiry phone system: Rent Info Line.
3) Enterprise Level Overview – The system should:

Provide daily staff activity logs.

Provide Program Area level reports (ORA, TPU).

Provide Bureau level reports (by Bureau).

Provide Unit level reports (by Unit).

Provide Team level reports (by Supervisor).

Provide Location level reports (by DHCR site).

Provide Employee level reports (by case or function).

Provide Current Status Report of overall ORA and TPU productivity vs. predetermined
KPI standards.

Provide reports on KPI at the same levels as listed in Program Area level reports (ORA,
TPU), Bureau level reports (by Bureau), Unit level reports (by Unit), Team level reports
(by Supervisor), and Location level reports (by DHCR site).

Provide Inspector daily activity status reports.

Provide End-of-Day Report for various rent case processing types.

Provide Chronological and Daily Log of any system or module Failures.
49
DHCR RFP for Rent Regulation Transformation
DRAFT V2
4) Types of reports – The system should include, but not be limited to, reports in the following
subject areas:

Case

Registration

Management

Correspondence

Building

User
Data Warehousing and Data Analytics
The system will be required to store aggregated data relating to cases. This data will be used in the
processing of cases, the review and quality assurance of cases and their outcomes, as well as to provide
data for analytics. The system should be capable of enabling the analytics of datasets in existing and
common formats. The system will specifically provide the following functionality:
1) General – The system should:

Create a functional data warehouse that contains legacy HUTS, ETPA data, new
system’s data including rent registration data and external data sources and is refreshed
periodically to keep the data current.

Leverage the existing DHCR relational database management systems infrastructure that
is currently in its initial usage stage.

Provide data cube(s) along with specific data marts for ORA and TPU.

Utilize XML interfaces, as much as possible, and support other technologies like APIs
and Flat Files to link to other external databases.

Validate all data submitted to the data warehouse.

Provide an automated data cleansing tool for rent data and addresses.
2) Fraud Detection and Predictive Analysis – The system should:

Provide a role based customizable predictive analytics module.

Provide real-time XML import functionality, as much as possible, and support other
techniques like APIs and Flat Flies to import data from designated shared external data
sources

Use SharePoint to provide a link to dashboards for TPU, ORA and the Executive Office
generated using the data warehouse data.
3) Security and Access Control – The system will use the NYS ID Management System to provide
security, single sign-on and role-based access control to data warehouse functionality.
4) Data warehouse interfaces – The system should interface with:

Rent Control for Fuel Information to support the calculations performed by the Research
and Analysis group.

Water and Sewage as well as Department of Finance for Maximum Base Rent.
50
DHCR RFP for Rent Regulation Transformation

DRAFT V2
Tax and Finance for Luxury Deregulation Data.
5.2.2 Technical Scope
The system will operate on a Cloud-based server infrastructure owned and operated by the successful
Proposer.
DHCR requires a system with the following overall architectural characteristics:
1) An enterprise approach to data that supports flexibility in future systems and process
development, including:
2) A common data model as opposed to separate data models for each distinct business
application,

A common, program-independent, identification of key reference data, and

A single version of truth with respect to current data, history and calculations for all
analysis purposes.
3) A tiered architecture, including:

A common infrastructure with common services to enable business processes across
lines of business with minimum redundancy, and

Extensibility and scalability to the greatest extent possible. This will help avoid manual
processes from being established or separate, non-integrated systems.
4) Minimized diversity of technology solutions and user interface styles required to support the
architecture.
5) Metadata, both technical and business, to specify the application architecture contents and rules
to facilitate the research associated with the location of specific business rules in question, the reuse of system components for new requirements, and other technical and business oriented
research associated with a complex system.
6) Persistent data storage using a commercially available DBMS such as SQL Server or Oracle or
DB2.
7) A highly modular and flexible software environment leveraging software architectures such as ntiered Service Oriented Architecture.
8) An architecture that supports industry standards such as web services that adhere to key
standards such as SOAP, XML, UDDI, SAML 2.0 and WSDL.
9) System custom components that are built using .NET.
10) System components that fit the State's architectural framework defined by the IT standards.
11) High levels of modularity and an industry standard framework in the software architecture.
12) Business rules that are separate and external from the application logic and that operate on the
data to achieve higher levels of flexibility and maintainability. The business rules must be visible
so that modification may be assigned to user roles that are not necessarily technical.
13) Solution that is integrated with the State's Identify Management infrastructure and provides
security, single-signon, role-based access controls, and system-to-system encryption consistent
with the State’s security standards.
51
DHCR RFP for Rent Regulation Transformation
DRAFT V2
14) Provide clean factoring or layering for re-use in other applications.
15) Use batch processing to automatically schedule and run periodic, recurring or one-time
processing.
16) Incorporate business process management and workflow technologies.
17) Ensure modules are available for re-use for other application components.
The system is expected to provide access to the following high-level user groups and counts:
1) ORA – 300 users
2) TPU – 30 users
3) OLA – 50 users
4) Owners – 40,000 users
5) Tenants –150,000 users
6) HPD – 45 users
7) OCA – 116 users
8) DOF – 32 users
9) TAX – 2 users
ORA, TPU and OLA users will be located at approximately 7 sites across Albany, New York City and
Westchester. HPD users will be located at 1 site in New York City. OCA users will be located at 5 sites in
New York City. DOF users will be located at 1 site in New York City. TAX users will be located at 1 site
in New York City. Owners and Tenants will be accessing the system over the Internet.
The system will provide the following channels of interaction with its users:
1) Online Application
2) Smart Phone or Mobile App
3) Paper-based Mail
4) Paper-based Hand Delivery through Walk Ins
5) Email
6) Fax
7) Scan
8) IVR
9) Call in
52
DHCR RFP for Rent Regulation Transformation
DRAFT V2
General
The system should be highly configurable, thus allowing changes in how it handles case creation, the
introduction of new documents, workflows and outputs based upon business needs. The successful
proposer will migrate HUTS legacy data into the new system. The system should:

Allow for programmatic customizations where necessary.

Be capable of interfacing with related systems and applications built upon Microsoft SQL
Server, Oracle, .Net, SharePoint, Content Server (formerly known as LiveLink) and Model
204.

Be developed using one of the following technologies: SalesForce, Microsoft Dynamics,
Siebel, IBM WebSphere/Lombardi.

Be developed using one of the following databases: SQL Server, Oracle or DB2.

Allow for its data to be accessed by SQL Server Reporting Services (SSRS), SQL Server
Integration Services (SSIS), and SQL Server Analysis Services (SSAS) for the purpose of
performing various data analytic activities.

Support the use of SAS, Crystal Report and other ODBC-compliant data analysis and
reporting tools.

Support custom software development using .NET and provide the ability to integrate with
custom software components developed using .NET.

Provide functionality similar to IBM WebSphere Process Server and IBM Business Process
Monitor for process management and process monitoring. Alternately, integrate with the
State’s process management services based on IBM WebSphere Process Server and
process monitoring services that is based on IBM Process Monitor.

Result in the migration of the legacy DHCR Model 204 HUTS database to a modern relational
database management system.

Use an open architecture that is compliant with NYS IT Standards, provides Service Oriented
Architecture and support Interoperability with other State systems.
Performance Tracking
The system will enable performance tracking by consolidating information required for internal
reporting and processes, including but not limited to: Registration, Case resolution, Complaint
Resolution, Investigative Triage, Investigations, Tenant Outreach, Compliance Enforcement, Internal
and External Collaboration Activities.
Common Meta-Data
The solution will provide for the use of common data elements that will be utilized for integration with
existing DHCR systems that will not be replaced by this project. The system should:

Include a common data dictionary and map for integrated reporting between DHCR systems
and the vendor proposed solution(s).

Provide templates for data integration and data sharing with external data sources. The
integration will include both the import and export of DHCR data to various stakeholders.

Provide edit checks to preserve data integrity.
53
DHCR RFP for Rent Regulation Transformation
DRAFT V2
GIS Mapping
The system should:

Provide interactive maps and schematics implemented using ESRI GIS technology by
integrating with the State's GIS system.

Leverage the State's Geographic Information System (GIS) tools for addressing standards,
analysis, and dataset integration, including data from the NYS GIS Clearinghouse.

Integrate with the State's GIS system to provide interactive maps that will include a current,
high quality base map equivalent to the industry standards from Google, Bing or ESRI.

Integrate with the State GIS system to provide Automatic mapping of GPS equipped mobile
devices (show location on interactive desktop map).

Integrate with the State's GIS system to provide interactive maps depicting the geographic
locations of rent regulated buildings and their registration status.

Integrate with the State's GIS system to provide user defined pre-set views (e.g. statewide,
region, default) in the interactive map and schematic views.

Provide map layers related to Rent.

Provide unique symbology for each apartment type (e.g. rent control, rent stabilization,
exempt).

Provide labels (up to 20 characters in length) for any device depicted on the interactive map
and schematic views.

Provide authorized users the ability to configure the content and font of the labels.

Provide user pre-defined information on “mouse-over” providing more information about a
building / address attributes.

Provide a map legend that depicts all layers included in the interactive map and schematic
views.

Able to toggle the visibility of the map legend.

Provide the user to Pan, Zoom, and Select on the interactive map or schematic.

Provide the user ability to turn map layers on and off in the interactive map and schematic
view.

Allow authorized users to edit and modify the schematic map.
System Accessibility
The system should:

Be web based and accessible through standard web browsers including IE, Chrome, Firefox

Provide a Mobile Application for ORA inspectors

Provide intelligent batching capability when a signal is lost due to poor wireless connectivity.

Provide a Mobile application for Tenants interaction including filing applications using mobile
devices.
54
DHCR RFP for Rent Regulation Transformation
DRAFT V2

Provide a Mobile application for Owners interaction including filing applications using mobile
devices.

Provide functionality for Electronic Signatures for Tenants and Owners.

Be ADA and Section 508 compliant based on Federal Standards.
NYS IT Standards
The system should comply with State Information Security Policy P03 002; as well as the CIO
Council’s Identity and Access Management principles and Trust Model as defined in the security
section below. The vendor will collaborate with ITS to define additional IT standards that apply to any
new components selected for the new system.
The system should:

Follow the NYS IT Technology Standards and interface based on NYS IT Standards with
existing NYS Enterprise Systems wherever existing compatible base functionality exists.

Adhere to open architecture technology standards based on Service Oriented Architecture
(SOA) and be interoperable.
Additionally, the system's Electronic Content Management will be developed using NYS IT Standards,
Service Oriented Architecture and Web Services to provide an open architecture that facilitates
migration to ECM products other than Content Server such as FileNet, IBM Content Manager or
CMOD, and Documentum.
System Performance
The system should:

Support 75% of the user base as concurrent user requests

Complete 95% of transactions within 5 seconds, with no single transaction exceeding 10
seconds

Be available 24x7 and no less than 99% of the time during scheduled hours of operation
High Availability and Fault Tolerance
The system should:

Provide High Availability and Fault Tolerance system features and functions.

Provide Local and remote (over a Wide Area Network - WAN) redundant servers with
automatic, semi-automatic, and manual failover options:

Provide Failover - Cold Start Up.

Provide Failover - Warm Start Up.

Provide Failover – Hot Standby.

Provide Failover - Full time load balanced.

Provide Power Fail Restart.

Provide Mirrored Server Systems.
55
DHCR RFP for Rent Regulation Transformation

DRAFT V2
Provide System Monitoring, Alerts and associated Reports.
System Management
System management tools and procedures must be delivered for the ongoing support and
maintenance, including customization, of the COTS system components. The State’s enterprisesupported technologies based on IT standards should be used where possible. Any proposed
technology component that is not currently supported by the State would be researched by the State
and agreement from all involved State agencies would occur. The tools and procedures shall include
descriptions and technical specifications for an overall network and systems management framework,
including:

Application management and monitoring

Systems management and monitoring

Web services management

Event management

Identity and access management through integration with the State’s identity management
infrastructure
Specifically, the system should:

Tie into the NYS ID Management System for DHCR employees and use their NYS userids
and passwords.

Integrate with NYS ID Management to provide the ability to administer user access for nonDHCR employees– e.g. establish and edit user profiles, inactivate users, reset passwords.

Provide the ability to enforce NYS ID Management password standards for non-DHCR user
password changes on a scheduled or on-demand basis.

Provide the ability to enforce DHCR username conventions.

Provide the ability to enforce NYS ID Management username conventions.

Provide the ability to enforce NYS ID Management password complexity requirements.

Integrate with NYS ID Management to provide the ability to set user access levels based on
function, including approval authority based on case type and ORA bureau, access to specific
data to the column level, inquiry and update access.

Provide the ability to track and log all system users.

Provide ability for selected staff to enter/modify necessary table/code records that are needed
for case processing. (e.g., yearly fuel price data, yearly rent guideline board data, overcharge
calculation chart standard footnote text, case index records by case type, and case types for
assigning box numbers).

Audit all inserts, updates, deletions to all data - log userid, type, date and time of change, the
data changed, function used to make the change.

The system will provide the ability to partition the system by permission level, e.g. super user,
administrator, read only, read-write, view device status or output, control device.

Include a context-sensitive online help function.
56
DHCR RFP for Rent Regulation Transformation

DRAFT V2
Use current supported version of Oracle or MS SQL or DB2 Database for data storage.
Audit
The system should maintain an audit trail of activities performed by users.
Live Help
The system should provide Live Help capabilities that leverage instant messaging and video chats.
Data Conversion
The system should contain data converted from the legacy HUTS and related systems.
External Interfaces
The system should interface with:

New York City Department of Housing Preservation and Development (HPD).

New York City Rent Guideline Board (RGB).

New York City Independent Budget Office (IBO).

New York City Department of Finance (DOF).

New York State Department of Taxation and Finance (TAX).

Owner Rent Registration Application (ORRA).

DHCR's Code Red Application.
The system should provide system-to-system encryption that is consistent with the State's security
standards.
Security
The State currently provides authentication services and robust security through its enterprise identity
management infrastructure. It is required that the contractor use this infrastructure to implement
general security features at the access level, while providing “fine grained” security through each
discrete application. The system should integrate with NYS ID Management to provide security
consistent with NYS Security Standards along with single sign-on and role-based access control
throughout the system and must support the following requirements:
Robust Authentication

Support for Lightweight Directory Access Protocol (LDAP)

Support for challenge response mechanisms

Support for the State’s Internet authentication mechanism
Access Control

Granular data and function access based on a user’s role

Access control audit mechanisms. The ability to see what was accessed, by whom and when.
57
DHCR RFP for Rent Regulation Transformation

DRAFT V2
Adequate technical security to prevent unauthorized access to the system, and its data files
and databases.
Integrity

Support secure communications utilizing SSL over HTTPS for Internet based transactions

Data encryption for client/server transactions and external data feeds
Security Monitoring

Ability to log and track all security related activity

Tracking and notification of any security-related exposures.

Ability to search and analyze logs to assist in security detection, suppression and prevention

Ability to search and analyze logs to ensure compliance with privacy policies.
Additionally, the system will follow SAML 2.0 Standard for cross-domain security federation and leverage
NYS ID Management for system-to-system interfaces.
In addition, the system must comply with State Information Security Policy P03-002; as well as the CIO
Council’s Identity and Access Management principles and Trust Model. Information regarding these
policies and standards is available at:

New
York
State
Information
Security
Policy
P03-002:
http://www.dhses.ny.gov/ocs/resources/documents/Cyber-Security-Policy-P03-002-V3.4.pdf;

New York State Entity Identity Management Governance Authority:

http://www.cio.ny.gov/policy/NYS-P10-005.pdf; and

New York State Identity Trust Model: http://www.cio.ny.gov/policy/NYS-P10-006.pdf.
The State will, along with the selected Contractor, define the security requirements for agency data as it
relates to a Cloud environment.
58
DHCR RFP for Rent Regulation Transformation
5.3
DRAFT V2
Technical Environments
Production Environment
The proposer must provide specifications for a secure fault-tolerant Cloud-based environment that
provides access to all users and user groups and integrates with the external systems and NYS
infrastructure specified herein. Production server components must not impact or be impacted by
workloads external to the environment. The environment should be designed to minimize outages due to
upgrades or outages of systems/components that are not part of the production solution. Redundant
components must be located at two physically separate data centers to ensure system
availability/disaster recovery/business continuity in the case of the loss of either data center, or solution
failure due to any single component failure (i.e., failover capability), or to perform migration activities.
Staging Area or Quality Assurance (QA) Environment
The proposer must provide specifications for a second Cloud-based environment, which must scale to
match the production environment and accessible to all users and user groups and integrates with the
external systems and NYS infrastructure specified herein. This environment will be used for load testing
of major releases of the Rent Regulation solution and for implementation of emergency production fixes
(which will subsequently be migrated into production and then merged with the other environments). One
aspect of the staging environment that does not have to match the production environment is the
currency of the data. The databases should be sized and otherwise the same as those in production. The
solution must provide the capability to refresh the staging data with production or other data as
necessary, on demand.
59
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Training Environment
The proposer must provide specifications for a Cloud-based environment that will be used to train
appropriate stakeholders (external and internal to DHCR) and users and user groups of the Rent
Regulation solution. This must also be similar to production in regard to access, security and
configuration to facilitate all aspects of training. DHCR desires the flexibility to manage the migration of all
approved production modifications to the Rent Regulation solution into the training environment. For
example, routine updates to the solution can be migrated to both the training and production
environments concurrently, while major releases or modifications may be migrated to the training
environment prior to production migration in order to provide the opportunity for appropriate training.
Appropriate DHCR staff and stakeholders must be able to refresh/reset data for training sessions.
Test Environment
The proposer must provide specifications for a Cloud-based environment that will be used by appropriate
staff to test the Rent Regulation solution changes/implementations, upgrades to system software or
hardware and any/all system or application configuration changes. This environment will be used for all
testing such as System, Integration, Performance, Regression, and User Acceptance Testing.
Additionally, appropriate staff and stakeholders should be able to refresh/reset data for User Testing
purposes.
Development Environment
The proposer must provide specifications for a Cloud-based environment that will be used for software
development, changes/implementations, upgrades to system software or hardware and any/all system or
application configuration changes.
Disaster Recovery and Business Continuity Environment
The proposer must provide specifications for a secure Cloud-based disaster recovery/business continuity
environment that provides access to all users and user groups and integrates with the external systems
and NYS infrastructure specified herein. Components redundant with the production environment must
be located at two physically separate data centers to ensure system availability/disaster
recovery/business continuity in the case of the loss of either data center, or solution failure due to any
single component failure (i.e., failover capability), or to perform migration activities.
5.4
Technical Architecture
The proposer must respond with a high level technical architecture diagram for the Rent Regulation
solution supported with diagrams depicting the interactions among the various system components. The
purpose of these diagrams is to ensure that DHCR understands the essential design of the proposed
solution, and can determine that the design is generally consistent with the scope and capabilities
represented in this RFP. Diagrams should include architectural views that reflect the application
architecture, information architecture, security architecture and corresponding software and hardware
architectures. The proposed architecture can be further refined by the successful proposer during the
project.
5.5
Software
The proposer must respond with a description of all software that will comprise the Rent Regulation
solution. This will include, but not be limited to, Commercial Off The Shelf (COTS) software, custom
software, third-party packages, and open source.
The proposer‘s proposed solution should include NO software or hardware locks, traps, dongle keys, or
similar security measures that would in any way deny DHCR full and complete access.
60
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Logging capability for all platforms should be provided. DHCR should be able to configure the system to
monitor, and record system logging events, including changes to security parameters and the activity of
users with elevated privileges, at various degrees of granularity (e.g., verbose, warn, etc.). The degree of
granularity should be able to be raised or lowered as necessary. In addition, the system should have
appropriate reporting capabilities.
5.6
Application Development Tools
The proposer should include a full suite of development and maintenance tools that will enhance ITS
programmer productivity in terms of maintaining and updating proposer-supplied applications and in
developing new applications. These tools should at a minimum include all tools used by the proposer in
the development, enhancement, and maintenance of its software, including but not limited to:
1) Application development studio;
2) Test script/test case generator;
3) Test drivers;
4) Middleware;
5) Software configuration management software;
6) Version control software;
7) Problem incident reporting, tracking, and management tools;
8) Data or process modeling software;
9) “HELP” generation software;
10) Windows and/or browser application development software tools;
11) All compilers for software development (and associated tools);
12) All memory and allocation analysis software used in system development;
13) A tool or tools that provide the ability to selectively purge (and save) to tape or other appropriate
media database records that meet data-driven selection parameters. A corresponding restore
capability is also required. The integrity of the data and the database should be automatically
maintained during both processes;
14) Programmer and user productivity tools; and
15) Software distribution agents.
5.7
Project Management-Related Required Services
In addition to the business and technology requirements specified, DHCR has identified several project
management-related areas that are of importance in selecting the Contractor. The intent of this section is
to inform the proposer of the responsibilities and the expectations for conduct over the duration of its
relationship with DHCR in the following areas:
1) Project management
2) Assisting DHCR staff and users,
3) Standard project management deliverables, and
4) Process and organizational change recommendations and transition management.
5.7.1 Project Management
DHCR expects the proposer to be competent in project management skills. The proposer‘s approach to
project management must ensure that:
1) Project planning and project management are part of normal daily activities;
2) Resource planning occurs in conjunction with DHCR management;
3) There is an established path and process for escalation of project issues;
4) Risk management is included as part of the normal process;
5) The proposer is able to provide reports to DHCR business units and DHCR management on the
progress against project objectives, to ensure continued project support; and
61
DHCR RFP for Rent Regulation Transformation
DRAFT V2
6) The project plan is organized in a phased approach that provides achievable and demonstrable
milestones and deliverables. The engagement should be managed to meet specific milestones
with an established method of reporting project status.
In the sections that follow, DHCR provides more detail with respect to the following topics:
1) Relationship,
2) Proposer Responsibility for Detailed Requirements Definition,
3) Multiple Products, Services and Methodologies,
4) Project Management and Control Methodology,
5) System Development Life Cycle, and
6) Project Work Plan
5.7.2 Relationship
The nature of the long-term relationship between DHCR and the successful Proposer will be key to the
success of the project. As such, the Proposer must ensure that:
 It has a demonstrated ability to understand and deliver realistic mission-critical systems;
 It can provide technical leadership and has the courage to suggest innovative solutions and take
advantage of opportunities as they present themselves, without putting DHCR at risk in meeting
its business objectives;
 It understands the aggressive nature of the schedule and will take ownership of tasks in a
proactive manner; and
 It understands the vision for DHCR and is able to align the Proposer‘s capabilities with DHCR’s
needs.
5.7.3 Proposer Responsibility for Detailed Requirements Definition
DHCR‘s environment is governed by myriad laws, rules, regulations, ―standard operating procedures,
and long-standing practices (formal and informal, documented and undocumented). The proposed Rent
Regulation solution must provide support for the execution of all processes and transactions required in
accordance with applicable legislation, regulations, policies, etc., that are in effect on the date of contract
execution.
In addition, the successful Proposer must take appropriate steps to elicit, capture and deploy all manner
of detailed requirement definition (be it functional or technical) from the appropriate DHCR party (be it
functional, technical or external to DHCR).
5.7.4 Multiple Products, Services, Methodologies
It is essential that the Proposer understand that DHCR is seeking more than just a “software
development” company. Mature software product development skills and experience are a necessary,
but far from sufficient, qualification. DHCR understands that each Proposer has (or should have) a
methodology for developing and deploying its particular Rent Regulation solution, but DHCR is seeking a
solution comprised of more than just those tasks and items identified in the Proposer‘s development
methodology. In order to deliver the broad, integrated solution that DHCR seeks, the Proposer must have
experience with, and methodologies to address, numerous other disciplines such as Business Process
Reengineering, procedure document development, organizational change management, training, and
workflow analysis. Proposer proposals must provide evidence of a mature, proven methodology in each
of these other critical areas of the project.
Therefore, the Proposer‘s proposal must address not only the standard system development
methodology referenced; it must also provide a detailed discussion of the methodology that will be
employed in each of the following areas:
 Project management – Proposer‘s project management structure, procedures, roles and
responsibilities, client reporting, meetings, and provisions for replacement of personnel.
62
DHCR RFP for Rent Regulation Transformation















DRAFT V2
Project scheduling – Scheduling tools and procedures, schedule updating, reporting against the
project schedule, and responding to change orders.
Process change (Business Process Reengineering) – Analysis, alternatives, proposed
improvements, change implementation, and integration with the new technical solution.
Organizational change (Organizational Restructuring) – DHCR understands that it wields the
most influence with its staff in terms of ensuring the success of any organizational changes
required by or resulting from implementation of a new Rent Regulation solution. However, DHCR
will look to the Proposer for analysis, generic role descriptions, recommended realignment
alternatives, proposed improvements, training considerations, and the identification of new roles
as needed to successfully execute and support the Rent Regulation solution.
Data conversion/bridging – Conversion planning, data mapping from the existing to the new
environment, identification of data errors, alignment of data conversion with project phases,
identification of data fields that need to be cleansed and/or within acceptable tolerances as
agreed to with DHCR, and reporting on reconciliation and cleansing of converted data. Data
bridging should be considered, where appropriate and necessary.
Data cleansing – Corrections of errors in the data in legacy systems (including, but not limited to
inconsistencies, errors, and missing data) that have been identified, approved, and signed off on
by the DHCR Project Director for migration to the Rent Regulation solution.
Configuration management – Ensuring a quality, timely product through application of discipline in
keeping an evolving solution under control. This includes topics such as repository control and
management, version control, etc., not just of software code, but also of design documents.
Enterprise Content Management (ECM) (imaging, print archiving, workflow and correspondence
management) – Development of appropriate ECM capabilities and their full integration with the
new solution.
Risk management – Identification and mitigation strategies related to all facets of risks associated
with the project, including a discussion of the methodology for designing and implementing
information and infrastructure security.
Project communication – Experience-based identification of all the project stakeholders and their
specific communication needs, including any innovative approaches to communications that the
Proposer has encountered or employed on previous projects.
Project change control – Defining new/changed requirements, developing an estimate, evaluating
schedule effects, obtaining DCHR approval, integrating requested changes into the project, and
testing.
Problem incident reporting – How to report a problem, how the problem is assigned for resolution,
integrating the “fix” into the project, regression testing, gaining DCHR acceptance, and analysis
and trend tracking.
System operation – Configuration control, job scheduling, equipment maintenance, written
documentation and procedures, personnel scheduling, and problem resolution.
Infrastructure and information security – Defining security requirements for enterprise information
and applications and developing a security plan to address the requirements.
Organizational Change Management and Training – Determining organizational change
management and training needs, developing training materials, scheduling training appropriately
within the overall project, assigning trainers, providing training facilities as necessary, and
gauging the effectiveness of training; training methodology must address training not only in
navigation, screens, data entry, and the like, but also in the use of the new solution to perform
various job functions, processes, and sub-processes.
Testing – Preparing test plans, test schedules, test variants, test scenarios, test cases, test data,
expected results; executing tests; reporting test results; referring problems identified in testing for
resolution; integration with problem incident report methodology, and re-testing after the problem
has been resolved.
During the course of the project, the Proposer will be expected to deliver and support all products and
services described in the RFP – not just those steps described in its standard system development
and deployment process.
63
DHCR RFP for Rent Regulation Transformation
DRAFT V2
5.7.5 Project Management and Control Methodology
Microsoft Project must be used to assist in the automated project management of this project. The
Proposer will deliver to DCHR the Microsoft Project files at various points in the project.
The Proposer is expected to use the tool to automatically reflect the effect on the overall project of
approved changes in various parameters, e.g., changes in:
 Project scope/requirements,
 Project schedule, and
 Resource availability.
The Proposer must be prepared to automatically generate various reports as requested by the DHCR
Project Director to reflect the project's status at any point in time, e.g.:
 Gantt charts depicting start date, end date, and duration of individual tasks;
 Graphical display of the project's critical path;
 Percent complete status of individual tasks;
 Calendar driven, manpower loading charts, by individual task, for both Proposer and DHCR staff
including variable man-hours per work day; and
 Calendar driven manpower loading charts, by month/week, for both Proposer and DHCR staff
including variable man-hours per work day.
The project management tools and methodology must be an integrated part of the Proposer‘s system
development life cycle approach and project management methodology.
5.7.6 System Development Life Cycle
Proposers should state their commitment to utilize a single system development life cycle methodology
and terminology for all portions of the project. For example, if the Proposer proposes to procure,
customize, and integrate a third party component into the overall solution, then all activities relating to the
third party component integration should observe the same system life cycle methodology that will be
utilized in developing the rest of the Rent Regulation solution. DHCR staff members are to be educated
in and expected to utilize only one life cycle methodology and terminology set for the duration of the
project.
DHCR prefers methodologies that allow DHCR staff multiple opportunities to validate requirements and
design. For this reason, an iterative development methodology is favored for use in the development of
the Rent Regulation solution. Ideally, this includes an opportunity to view rapid prototypes of requirements
and design concepts, screens, content, and application flow. (Such prototypes do not necessarily need to
become operational or be reused during development.) Simulation of workflow and performance
measurement within the design effort is also desirable. Proposals that include in the development period
a Conference Room Pilot (CRP) – wherein users see the full solution life cycle – would be viewed
favorably by DHCR.
The project will be divided into multiple functional rollout phases, as appropriate, each including
numerous activities/tasks that will be implemented sequentially or on an overlapping basis. Each rollout
phase will involve numerous deliverables (documents and software), that will be submitted to various
DHCR staff members for review and revision over multiple iterations.
DHCR‘s objective is to be assured that an appropriate control scheme is put in place and rigorously
applied to all project activities such that all project participants understand what they are working on, what
is expected of them, and how it fits into the overall project. Specifically, DHCR wants to ensure that,
without exception, all project participants – the Proposer's staff, DHCR staff, and all concerned third
parties – when approaching a task (whether it is developing software, drafting/updating written
documents, or reviewing a deliverable), clearly understand:
 The phase of the project to which the task relates;
64
DHCR RFP for Rent Regulation Transformation









DRAFT V2
Which revision/release they are working on (and that it is the current revision/release);
The date of the revision/release;
How many previous versions were developed and reviewed;
What has been changed, added, or deleted relative to the previous release;
What functions or features the delivery should contain and what it should not contain;
How many pages it should contain;
The emailed documents or the CD-ROMs that accompany the delivery (if applicable) and
precisely what those emails or CD-ROMs contain;
When a response is required; and
When the next release can be expected.
Unless otherwise agreed between DHCR and the successful Proposer, it will be the Proposer‘s
responsibility to notify all reviewers via email of the presence in the deliverables repository of the
delivered documents.
5.7.7 Project Work Plan
The Proposer assumes full responsibility for planning, scheduling, and completing all project tasks. The
Initial Project Work Plan will be delivered as part of the proposal and contain a high-level plan of the
entire project.
At the beginning of the contract, the successful Proposer shall provide to DHCR a complete detailed work
plan for all portions of the project. This plan will be included as part of the Project Management Plan
deliverable.
At the end of the analysis phase and beginning of the design phase of the project, the successful
Proposer shall provide to DHCR a complete detailed work plan for all remaining portions of the project.
The plan will contain, at a minimum: narratives, task definitions, schedules, Gantt charts, dependencies,
as well as DHCR and Proposer labor loading. It shall include all project deliverables, all detailed tasks
with start dates, completion dates, hours to complete, dependencies, Proposer and DHCR resources
assigned and project milestones. The work plan must reflect the phasing of the project, as appropriate
and necessary. The complete detailed work plan shall be based on the Initial Project Work Plan included
in the Proposer's proposal, including any modifications made during contract negotiations. It will include
all mandatory project elements and any desired options that have been authorized to date at that time.
The DHCR Project Director will approve or reject the plan noting any deficiencies to the successful
Proposer. Rejected plans must be revised until they meet the satisfaction of the DHCR Project Director.
The Detailed Work Plan for the Project will be subject to on-going modification and will be updated on a
mutually agreed schedule, at a minimum, whenever major new phases are undertaken, whenever change
orders are initiated, and no less frequently than every three (3) months.
5.8
Contractor Requirements
The Contractor will provide the Deliverables and meet the requirements specified in the RFP and its
referenced appendices, attachments, and exhibits. The Contractor shall perform all of the activities and
tasks required to achieve the objectives, functions, outputs, and performance criteria stated therein, in a
manner that meets the project’s and resulting Contract’s objectives. All services provided by the selected
Contractor shall be appropriate and acceptable to the DHCR Rent Regulation System project team and
be consistent with State and Federal laws and regulations. The Contractor shall provide all of the staff
necessary to perform the required services.
During the life of the project, the State will review Deliverables and evaluate them for completeness,
clarity, adherence to generally recognized standards, and compliance with the State’s intent as conveyed
in this RFP, and the resulting contract. A Deliverable, phase, or milestone will not be considered complete
until written approval has been given by the State. For each deliverable, the Contractor shall provide a
65
DHCR RFP for Rent Regulation Transformation
DRAFT V2
deliverable outline and a sample deliverable. State will undertake best efforts to perform timely review of
the deliverables for the project and complete the first round of review within a duration that is no more
than 15 business days.
The State will contract with a single Bidder to implement the Rent Regulation System that will provide the
required functionality as detailed in this RFP. The System will run in Cloud computing facilities maintained
and operated by the winning proposer. The State requires that the Contractor follow a systematic
approach to the design, development, and implementation of the System to ensure that a comprehensive
and expandable system is implemented for the Participating Agencies. The State requires the project to
be completed within 18 months for all the life-cycle phases described below and 3 years of production
operation. The bidder is requested to provide a justification in the event that an alternate timeline is
proposed. Specific deadlines for deliverables will be agreed upon by the parties after the engagement of
the Contractor. The exact approach and methodologies proposed by the Bidder to fulfill the Deliverables
and requirements of all life-cycle phases as described below should be provided in the Approach portion
of the Bidder’s Technical Proposal. The Bidder should address all the Deliverables for the life-cycle
phases in their project plan but can organize and plan for the accomplishment of the work based on their
experience with projects of similar scale and scope. The Bidder should recommend an implementation
approach for the System based on their best practices and experience, and should fully describe that
approach within the Approach section of the Technical Proposal. By responding to this RFP, the Bidder
confirms their commitment to meet all requirements defined in this RFP regardless of the approach
proposed.
The Contractor shall provide project Deliverables for the Rent Regulation System in the form and format
agreed to by the State using deliverable specification sheets approved by the State. The deliverable
specification sheets will include, but not be limited to the following information for each project deliverable:
deliverable title, frequency, draft and final due dates, approval requirements, outline and description of
contents, and delivery of media.
Project deliverables will include, but is not limited to, the following:
1) Project Management Plan – The Contractor shall develop a comprehensive project management
plan (the “Systems Integration Services Project Management Plan”) that includes a detailed
project plan and addresses key areas of the project, including but not limited to: Scope
Management, Human Resource Management, Quality Management, Communication
Management, Risk Management, Development Methodology Overview, defect reporting and
resolution methodology and Change Control Methodology. The Contractor shall manage and
carry-out the Systems Integration Services in accordance with the Project Management Plan. The
Project Management Plan will include a process by which all Deliverables will be reviewed and
accepted.
2) Business Requirements Document Deliverable – For each of the transformation opportunities
pursued by DHCR, the impact on operations needs to be assessed and a plan for addressing
changes in business processes and operations needs to be developed by working with individual
units. This deliverable will contain design and documentation of new processes that stem from a
cycle of assessing operations, identifying potential/needed changes, and working with operational
managers and leadership to define and design new processes. The Contractor shall include, as
applicable, the Policy, Operations and Technology Transformation Vision, Mission, Goals,
Principles, Context Models, Capability Models, Target Operating Model, Service Model, Service
Output Model, Future State Business Processes and Updated Requirements Traceability Matrix
based on Business Process Reengineering exercises to increase processing efficiency and to
drive the technology solution.
3) System Architecture Requirements Deliverable – In collaboration with DHCR and IT stakeholders,
the Contractor shall define and document the specific System Architecture Requirements for this
project to articulate the requirements of the IT system that accomplishes the business activities
and business requirements that require automation. The document will include a description of
the expected behavior of the system from the perspective of the end-user and document system
requirements that are traceable to the business requirements and future state business
processes. These requirements will comprehensively cover system functional requirements, non-
66
DHCR RFP for Rent Regulation Transformation
4)
5)
6)
7)
8)
DRAFT V2
functional requirements, policy requirements, interface requirements and data requirements.
Preliminary Use Cases and system workflows shall be included, as appropriate. The deliverable
shall include the Updated Requirements Traceability Matrix. Any new IT standards that the
Contractor collaboratively develops with ITS will be included.
Updated Project Plan (Design Phase) – The Contractor shall periodically update the baseline
Project Plan to show the estimate to complete the rest of the project. This update will be
delivered at the end of the Analysis Phase and focus on incorporating any additional details
pertaining to Design Phase while confirming the plan for the rest of the project.
Detailed Functional Design Deliverable – The Contractor shall develop the functional design that
includes, but is not limited to, detailed Use Cases, screen mock-ups and navigation, configuration
and customization specifications for screens, business processes, rules, batch, workflow,
notifications, alerts, integration, functional system interfaces, business objects and components,
data objects as well as reports. The deliverable shall include Application Style Guide, data
entities list, organizational, system-level, function-level and data-level security, updated
Requirements Traceability Matrix and updated Future State Business Process. The deliverable
shall also include results of a fit/gap analysis between stated functional requirements and any
packaged software that is part of the Contractor’s proposed solution. The deliverable shall
provide a description of each outstanding gap and stipulation of the Contractor’s approach to
resolving the gap. Gaps may be resolved through an approach that includes one or more of the
following, but not limited to: additional product configuration changes, upgrading to new software
release, or custom enhancement. The deliverable shall also articulate the design for policy and
data requirements.
Technical Solution Architecture Deliverable – The Contractor shall develop the detailed Technical
Solution Architecture as it relates to technical configuration, customization and implementation for
each layer of software, including but not limited to: client, presentation, business, persistence and
data. The deliverable shall include, but not be limited to: the logical data model, physical data
model, infrastructure, system interfaces technical architecture, as well as security and audit.
Detailed specifications for performance optimization, data migration and conversion, availability
and data protection, audit as well as technical architecture for disaster recovery and business
continuity shall be included. Documentation of compliance of the architecture with NYS IT
Standards as well as any new IT standards that the Contractor collaboratively developed with ITS
and documented as part of the System Architecture Requirements deliverable shall be included.
The deliverable shall also include results of a fit/gap analysis between stated technical
requirements and any packaged software that is part of the Contractor’s proposed solution. The
deliverable shall provide a description of each outstanding gap and stipulation of the Contractor’s
approach to resolving the gap. Gaps may be resolved through an approach that includes one or
more of the following, but not limited to: additional product configuration changes, upgrading to
new software release, or custom enhancement.
System Capacity Plan (Development, Test, Training and UAT) – The Contractor shall develop a
plan to itemize the capacity needs of the system throughout the software development process
(development, test, training and UAT). The plan will include detailed specifications for all Cloudbased hardware, software and related services for these environments to be fully operational for
use on the project.
Business Improvement Deliverable – The Contractor shall develop the Business Improvement
Deliverable that consists of a Change Management and Training Plan, Revised Organizational
Design and Performance Management Framework. Consistent and frequent communication and
engagement of stakeholders required in order to ensure the new system is accepted and
adopted. The implementation of a new strategy or operating model may necessitate additional
skills and experience beyond that contained within ORA and the TPU today. Moreover, existing
roles may be impacted by a new organizational structure or role expectations. In addition to
training related to the new Rent Regulation System, the Change Management and Training Plan
will include, but not be limited to, general information about New York State Home and
Community, Division of Housing and Community Renewal, the ORA and TPU overall strategy; an
overview of Rent Stabilization and Rent Control Law which includes history, important milestones
of Rent Regulations, and its current highlights and challenges; and training new employees with
new processes and procedures. An alignment of strategic mission, vision, and organizational
67
DHCR RFP for Rent Regulation Transformation
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
22)
DRAFT V2
structure is required to achieve the fundamental shift envisioned by the new system. Developing
an organizational structure that aligns with these key strategic components is a critical success
factor in achieving the goals established for the stakeholder organizations. The Contractor shall
develop an Organizational Design that has a number of key components including, but not limited
to, reporting relationships, process maps and a preliminary risk assessment. Additionally, the
deliverable shall include a Performance Management Framework to help the transformed
organizations track progress against a set of benchmarks and make informed decisions. The
Framework will provide guideline, structure and process for how performance goals are defined,
implemented and measured.
Plan for Testing Activities – The Contractor shall develop a plan for all testing activities including,
but not limited to, unit testing, system testing (including security), integration testing (including
security), performance testing, regression testing and smoke testing.
Implementation Plan – The Contractor shall develop an Implementation Plan to show the
schedule, approach, phases, releases, resources and risks as well as mitigation steps associated
with Implementing the System. The plan will include a statement of scope, and iteration plan for
software development.
Updated Project Plan (Build Phase) – The Contractor shall periodically update the baseline
Project Plan to show the estimate to complete the rest of the project. This update will be
delivered at the end of the Design Phase and focus on incorporating any additional details
pertaining to Build Phase while confirming the plan for the rest of the project.
Development, Training, Test and UAT Environments Installation and Configuration – The
Contractor shall provide fully installed and configured Cloud-based environments for
development, training, test and UAT including disaster recovery and business continuity
environments as specified in the System Capacity Plan (Development, Test, Training and UAT)
and approved by DHCR. The deliverable shall include a report itemizing all software and
hardware components constituting these environments and validation that these components and
the environment as a whole are operational.
Software Application Development Plan – The Contractor shall develop a plan to complete the
software application development activities within the timeframe laid out in the project plan. The
plan shall include details for managing each software release including releases associated with
any software/hardware upgrades.
Configuration Management Plan – The Contractor shall develop a plan to manage the
configuration of the system and maintain the integrity of that configuration.
Change Management Plan – The Contractor shall develop a change management plan to
manage organizational changes resulting from this project.
Knowledge Transfer Plan – The Contractor shall develop a Knowledge Transfer Plan to keep
DHCR and ITS staff up to date on knowledge related to system development activities starting
from the analysis phase of the project through design, development, testing and implementation
as well as post-implementation activities.
Coding Standards – The Contractor shall develop coding standards that the entire system needs
to adhere to.
Quality Assurance Plan – The Contractor shall develop a plan that includes a description of the
role of the Contractor’s Quality Assurance function; establishes quality assurance procedures and
processes, risk identification, assessment, impact analysis and mitigation strategies; formulates
quality review activities and related reporting; provides project monitoring and related reporting;
and defines any necessary QA staff including subject matter advice, where applicable.
Disaster Recovery and Business Continuity Plan – The Contractor shall develop a plan to provide
reliable disaster recovery for the system and business continuity.
System Capacity Plan (Staging/QA and Production) – The Contractor shall develop a plan to
itemize the capacity needs of the system throughout the software deployment and operation
process (Staging/QA and Production).
Training Plan – The Contractor shall develop a training plan to schedule and complete training
activities.
Data Conversion and Conversion Testing Plan – The Contractor shall develop a plan to complete
data conversion and conversion testing activities. Include data bridging, as appropriate and
necessary.
68
DHCR RFP for Rent Regulation Transformation
DRAFT V2
23) Staging/QA and Production Environments Installation and Configuration – The Contractor shall
provide fully installed and configured Cloud-based environments for staging/QA and production
including disaster recovery and business continuity environments as specified in the System
Capacity Plan (Staging/QA and Production) and approved by DHCR. The deliverable shall
include a report itemizing all software and hardware components constituting these environments
and validation that these components and the environment as a whole are operational.
24) Software and Source Code – The Contractor shall turn in all software and source code pertaining
to the Rent Regulation System that DHCR will own at project conclusion and is needed for DHCR
to continue maintenance and support of the system. DHCR will have unrestricted rights to make
modifications and/or customizations to all source code. The deliverable will include, but not be
limited to, a listing of all software and source code configuration items along with detailed
descriptions accompanying an electronic medium containing all the software and source code.
The Contractor shall certify that all source code is compliant with the coding standards approved
by DHCR.
25) Execution and Completion of Data Conversion and Bridging, as appropriate – The Contractor
shall execute and complete all data conversion activities and implement any bridging necessary
to provide a fully functional system release. The deliverable will include a report describing the
successful conversion of all data and successful implementation of appropriate bridging.
26) Completion of all Testing including User Acceptance Testing – The Contractor shall complete all
testing activities, including but not limed to, unit testing, system testing (including security),
integration testing (including security), performance testing, regression testing and smoke testing
and as specified in the Plan for Testing Activities approved by DHCR. The Contractor shall also
complete providing necessary support for successful completion of UAT activities. The
deliverable shall include a report documenting successful completion of all testing including UAT.
27) Test Results – The Contractor shall periodically report on the results of the planned testing
activities.
28) Rollout plan – The Contractor shall develop a plan for rolling out the system in phases and
include a schedule, staffing, approach, checklists and risks as well as mitigation steps.
29) Operations Support and Maintenance Plan – The Contractor shall develop a plan to provide
operations support and maintenance and include the schedule, structure, staffing and risks as
well as mitigation steps.
30) User Acceptance Test Plan – The Contractor shall develop a plan to coordinate and complete
user acceptance test activities.
31) Pilot Plan – The Contractor shall develop a plan to Pilot the system prior to statewide rollout.
32) Completion of Organizational Change Management, Knowledge Transfer and Training Activities –
The Contractor shall complete all Organizational Change Management, Knowledge Transfer and
Training Activities specified in the Change Management Plan Knowledge Transfer Plan and
Training Plan and approved by DHCR. The deliverable shall include a report documenting
successful completion of these activities.
33) Resolution of all critical and major defects – The Contractor shall complete resolution of all critical
and major defects identified prior to Go Live. The deliverable shall include a detailed report
documenting successful resolution of all critical and major defects identified prior to Go Live.
34) Plan for resolution of all defects other than critical and major defects – The Contractor shall
provide a plan to complete resolving all defects other than critical and major defects identified
prior to Go Live. The plan will include, but not be limited to, scope, schedule, resources, and
approach to resolving these defects.
35) Updated Project Plan (Deploy Phase) – The Contractor shall periodically update the baseline
Project Plan to show the estimate to complete the rest of the project. This update will be
delivered at the end of the Build Phase and focus on incorporating any additional details
pertaining to Deploy Phase while confirming the plan for the rest of the project.
36) Completion of Pilot – The Contractor shall complete implementing a Pilot system in accordance
with the Pilot Plan approved by DHCR. The deliverable will include a report documenting the
successful completion.
37) Cutover of New System – The Contractor shall complete cutover to the new system and
commence full production operation. The deliverable shall include a report documenting
69
DHCR RFP for Rent Regulation Transformation
38)
39)
40)
41)
42)
43)
DRAFT V2
completion of all planned rollout activities documented in the Rollout Plan and approved by
DHCR.
Resolution of all defects identified prior to Go Live and 45 days after Go Live – The Contractor
shall complete resolution of all defects identified prior to Go Live and 45 days after Go Live. The
deliverable shall include a detailed report documenting successful resolution of all these defects.
Plan for resolving defects identified after 45 days of Go Live – The Contractor shall provide a plan
to complete resolving all defects identified after 45 days of Go Live. The plan will include, but not
be limited to, scope, schedule, resources, and approach to resolving these defects.
Operations Support and Maintenance Manual – The Contractor shall develop a manual that
provides detailed instructions and includes procedures and processes for operations support and
maintenance.
User Manual – The Contractor shall develop a User Manual for reference by users of the system.
Updated Project Plan (Operate Phase) – The Contractor shall periodically update the baseline
Project Plan to show the estimate to complete the rest of the project. This update will be
delivered at the end of the Deploy Phase and focus on incorporating any additional details
pertaining to Operate Phase while confirming the plan for the rest of the project.
Bi-Weekly Status Reports – The Contractor shall provide bi-weekly status reports that accurately
depict completed activities, planned activities, staffing levels, issues, risk areas and mitigation
steps and information pertinent to stakeholders to enable decisions to be made to keep the
project on track.
5.8.1 Work Location
The Bidder must deploy its team members on-site at DHCR’s Gertz Plaza location in Jamaica, Queens
for business analysis and project management activities, at DHCR’s Hampton Plaza location in Albany for
software development, testing and implementation activities and the individual agency user locations for
user acceptance testing. The successful proposer’s team is expected to plan for travel amongst project
sites, as the need arises.
70
DHCR RFP for Rent Regulation Transformation
6
DRAFT V2
Proposal Requirements
The Bidder should submit a proposal that clearly and concisely provides all of the information required,
upon which the State will base its evaluation. Emphasis should be concentrated on conformance to the
RFP instructions, responsiveness to the RFP requirements, and clarity of content. The Bidder is advised
to thoroughly read and follow all instructions contained in this RFP. Proposals that do not comply with
these instructions, or do not meet the full intent of all the requirements of this RFP may be subject to
scoring reductions during the evaluation process or may be deemed non-responsive.
The State does not require, nor desire, any promotional material that does not specifically address the
response requirements of this RFP.
A complete proposal for this RFP is comprised of three (3) separate sealed proposals: technical, cost,
and administrative. The Proposer may bid up to four solution options based on one of the following
technologies: IBM WebSphere/Lombardi, Microsoft Dynamics, Siebel and Salesforce.com. The Proposer
must submit a complete and separate proposal for this RFP that is comprised on three (3) separate
sealed proposals: technical, cost, and administrative for each solution option. Please see below for
content and submission details.
6.1
Technical Proposal
This section of the RFP provides instructions to Bidders regarding information that is to be included in a
Technical Proposal. The State reminds Bidders that responses shall be complete, factual, and as detailed
as necessary to allow the State to perform a comprehensive review and evaluation of proposed services,
capabilities, and experience.
The purpose of the Technical Proposal is to provide a Bidder with the opportunity to demonstrate its
qualifications, competence and capacity to undertake the engagement described herein, in a manner
which complies with applicable laws and regulations, and the requirements of the RFP; it should
specifically detail the Bidder’s qualifications and experience in providing services sought by the State
(including the experience of its subcontractors where applicable). There should be no dollar unit or
costs included in the Technical Proposal document.
To expedite the review of the submissions, the Division requests that all proposals be submitted in a
binder and organized with tabs numbered to match the specific information requested for each
sub-section below, including Appendices. Responses to each Proposal Requirement should be numbered
and in sequential order in the Technical Proposal.
Technical proposals should be limited to no more than 100 pages, not including Appendices. The
Appendices may include Firm Qualification Forms, Staff Resumes and other material supporting the
Bidder’s proposal.
6.1.1 Table of Contents
The Table of Contents should clearly identify the location of all material within the proposal by section and
page number.
6.1.2 Executive Summary
An Executive Summary highlighting significant features of the Bidder’s proposal should be included in the
Technical Proposal. Firms are reminded that cost should not be included in this section.
71
DHCR RFP for Rent Regulation Transformation
DRAFT V2
6.1.3 Verification of Mandatory Qualifications
Bidders must demonstrate how they meet the mandatory qualifications described in Section 4. The
Division reserves the right to seek clarification from Bidders to ensure that these minimums have been
met. If a Bidder cannot demonstrate that the minimum requirements have been met, they will be deemed
non-responsive and their proposal will be rejected.
6.1.4 Functional and Technical Requirements
By submitting a proposal, the Bidder warrants that it has carefully reviewed the needs of the State (as
described in this RFP, its attachments and other communications related to this RFP), has familiarized
itself with the specifications and requirements of this RFP and warrants that it can provide such products
and services as represented in its proposal.
6.1.4.1 Ability to Meet the Functional and Technical Requirements
Using Appendix P – Functional and Technical Requirements and the following guidelines, the Bidder
should provide an indication as to how the proposed solution will meet the State’s requirements with
respect to features, functions and system requirements using one of the following responses in the
“Compliance” column:

OBX – Out of the Box. Out of the Box is the Approach Code that should be indicated when the
solution will address the requirement “out of the box,” without being conditional on any Special
Configuration, System Workaround, Process Workaround, Customization, or Integration with
Third Party Applications.

CNF – Special Configuration. Special configuration is the scenario where the solution does not
include standard features built specifically to address the requirement in question, but the desired
results can be achieved by configuring the System in a specific way. For example, with respect to
reporting, Special Configuration would be the Approach Code where no single standard report
satisfies the requirement in question, but where an existing standard report can be modified
solely by means of configuration, such as modifying existing, or adding new fields to the report.

CST – Customization. Customization is the Approach Code to apply when the solution does not
include features built specifically to address the requirement in question, and a custom
development effort is needed to achieve the desired result. With respect to reporting,
customization is the scenario where no single standard report satisfies the requirement in
question, but where an existing standard report can be recoded or a new report can be created
through additional development effort requiring coding changes.

NAV – Not Available. The requirement cannot be met with the proposed solution.
Bidder Comments
If the Bidder’s response to the “Compliance” column requires explanation or clarification, it should be
provided in this column. Bidders are also asked to use the Bidder Comments column to list the specific
module of the proposed system or third-party software that meets the requirement.
Please note that Functional and Technical Requirements listed in Appendix P include mandatory
and desired requirements. An Approach Code must be entered for each requirement, and a
Proposer’s failure to indicate their ability to meet one or more of the requirements listed will
impact the technical score.
72
DHCR RFP for Rent Regulation Transformation
DRAFT V2
6.1.4.2 Approach to Meeting the Functional and Technical Requirements
Supplement the completed requirements table with additional details describing how the solution will meet
the requirements. Use the same order of headings and requirements used in Appendix P – Functional
and Technical Requirements. Where appropriate include schematics and diagrams that provide both
conceptual and technical explanations of the proposed solution. Specifically, the proposed technical
architecture should be identified.
6.1.5 Company Experience and Staff Qualifications
6.1.5.1 Description of Company Experience
Direct, prior experience in transformation work described in Section 5 is essential. Describe company
background, history, and directly relevant experience and related services.
6.1.5.2 Firm Project Qualifications and References
Provide three project references for the Firm(s) that will perform the proposed work. References should
detail projects currently in progress or completed within the past five years that are comparable in size,
scope and complexity to this effort, and that are for services/products comparable to the Contractor
requirements described in this RFP.
The references provided must support the Bidder’s claim to meet the mandatory qualifications identified in
Section 4.1, Project(s) Meeting the Proposer Minimum Qualifications.
For each reference, provide all information specified in Appendix E, Firm Qualification Form. The State
reserves the right to request information from other sources at its discretion.
6.1.5.3 Additional Qualifications
The Bidder may, at its discretion, provide a description of other relevant qualifications.
73
DHCR RFP for Rent Regulation Transformation
DRAFT V2
6.1.6 Staff Qualifications
6.1.6.1 Staff Qualifications and Key Staff
In this section of the Technical Proposal, Bidders should demonstrate that proposed staff has the
necessary knowledge and demonstrated ability to provide the services required by this RFP. The State
reserves the right to reject any proposed staff member’s participation in the engagement. The State will
review and approve substitutions in staff from those proposed. Any staff substitutions will require that new
staff have qualifications meeting or exceeding the qualifications of the staff included in the Bidder’s
proposal.
Key staff for the proposed work includes the following:

Project Manager

Technical Lead

Technical Architect

Security Lead

Business Analyst

Data Architect

Data Conversion Lead

Database Administrator

Lead Application Developer

Quality Assurance Analyst

Testing Lead

Implementation Lead

Technical Writer

Knowledge Transfer Lead

Trainer

Operations, Support and Maintenance Lead
The project manager and the technical lead must be dedicated full-time to the project for duration of the
project. Other key staff does not need to be full-time. Moreover, the State is not prescribing the number
of staff members required on the team. It is the responsibility of the Bidder to propose and resource a
team that can complete the required scope of work effectively.
Bidders may propose multiple roles for a key person, but overlapping responsibilities and transition
between roles must be explained. Responses that do not identify the persons proposed for the positions
by name will be rejected as non‐responsive.
The sections that follow identify the information that the Bidder should provide.
74
DHCR RFP for Rent Regulation Transformation
DRAFT V2
6.1.6.2 Project Team Organization
Provide an overview of the project team organization, an organization chart and a table summarizing the
individuals proposed, their title on the project, a description of the role they will fill in the project and their
key qualifications.
6.1.6.3 Project Team Resumes and References
Provide resumes for each key team member proposed.
Provide three references for each key team member. The reference should include the reference name,
organization, title/role, contact information (e-mail and phone), and description of the project relationship
to the proposed team member.
The resumes and references may be included in an Appendix to the proposal.
6.1.7 Project Approach
Address the Bidder’s approach to completing the requirements identified in Section 5.3 – Technical
Environments, Section 5.4 – Technical Architecture, Section 5.5 – Software, Section 5.6 Application
Development Tools, Section 5.7 – Project Management-Related Required Services, and Section 5.8 –
Contractor Requirements. Describe the following:

Overarching approach – how the bidder will meet the requirements outlined in Section 5.3
through Section 5.8; provide sufficient detail to demonstrate the ability of the Bidder to meet the
requirements

Project schedule – provide a statement of the key milestones and the expected timing of their
delivery, and

Level of effort – include a table summarizing the level of effort per key role (and additional roles, if
any) by deliverable.
The description should provide convincing evidence that the Bidder understands the objectives that the
contract is expected to meet, the nature of the required work and the level of effort necessary to
successfully complete the contract.
The State also plans to enter into a separate contract with a Project Monitoring/Quality Assurance
(PM/QA) and Independent Validation and Verification (IV&V) contractor. The selected vendor is expected
to cooperate fully with State staff and their contractors representing the State, including for PM/QA and
IV&V services, throughout all project activities.
6.1.7.1 Overarching Approach
The Bidder must provide an overview of how it will approach the project and meet the requirements. The
overview should describe the broad approach, methodology, tools and expected inputs and outputs.
In addition, the Bidder must describe in detail how it will complete each of the deliverables identified in
Section 5.8, Contractor Requirements while providing a detailed description of the approach for meeting
requirements stated in Sections 5.3 through 5.7. The detailed description of the deliverables approach
should include the objectives, scope, approach and deliverables/outputs for each deliverable.
75
DHCR RFP for Rent Regulation Transformation
DRAFT V2
6.1.7.2 Project Schedule
The Bidder should provide a high level project schedule which identifies the key milestones and the
expected timing of their delivery. A narrative explaining the flow of the project should be provided to
support the schedule.
6.1.7.3 Level of Effort
The Bidder should provide a table summarizing the level of effort per key role (and additional roles, if any)
by deliverable. The Bidder should use the table in Appendix F, Team Level of Effort.
76
DHCR RFP for Rent Regulation Transformation
6.2
DRAFT V2
Cost Proposal
Among the selection criteria is the fee the Bidder will charge the State for the services and products
described in this RFP. The Bidder must propose fees and costs in its bid that covers all services and
products proposed to meet the requirements of this RFP. The total estimated contract value for the
engagement will be derived from the successful Bidder’s Cost Proposal.
Bidders must present their pricing information by completing Appendix G: Cost Forms. Proposals with fee
formats different than the format indicated in this section and in Appendix G: Cost Forms will not be
considered for evaluation. The rates included in the proposal should be the Firm’s lowest discounted
governmental rates.
Appendix G, Cost Forms, includes the following elements:
1) Costs Forms for Mandatory Requirements

Fixed Fee Cost by Deliverable – fixed fee cost for each of the deliverables identified in
Section 5.8 associated with delivery of a solution for mandatory requirements identified in
Appendix P – Functional and Technical Requirements;

Monthly Fixed Fee Cost for Cloud-based Services related to Development, Test, Training,
UAT, QA and Production Environments for a duration of 4 ½ years (18 months project
duration and 3 years of production operation);

Total Fixed Fee Cost - a summary table with the total cost of the fixed fee deliverables and
Cloud-based Services;

Invoicing, Payments, Retainage and Tracking Thereof;

Software costs – a table specifying the software needed to meet the mandatory requirements
of this proposal based on the Bidder’s approach;

Hardware costs – a table specifying the hardware needed to meet the mandatory
requirements of this proposal based on the Bidder’s approach;
2) Costs Forms for Desirable Requirements

Fixed Fee Cost by Functionality – fixed fee cost for the implementation of each of the desired
requirements identified in Appendix P – Functional and Technical Requirements;

Monthly Fixed Fee Cost for any additional Cloud-based Services for delivering the Desirable
requirements as it relates to Development, Test, Training, UAT, QA and Production
Environments for a duration of 4 ½ years (18 months project duration and 3 years of
production operation);

Total Fixed Fee Cost - a summary table with the total cost of the fixed fee functionality and
Cloud-based Services;

Invoicing, Payments, Retainage and Tracking Thereof;

Software costs – a table specifying the software needed to meet the desirable requirements
of this proposal based on the Bidder’s approach;

Hardware costs – a table specifying the hardware needed to meet the desirable requirements
of this proposal based on the Bidder’s approach;
3) Hourly Rates for Potential Change Orders – a table of rates that may be used if the Division
decides to initiate a change in scope of the project.
77
DHCR RFP for Rent Regulation Transformation
6.3
DRAFT V2
Administrative Proposal
The Administrative Proposal should contain all the requirements listed below. An Administrative Proposal
that is incomplete in any material respect and does not follow the prescribed format may be eliminated
from consideration. The information requested should be provided in the prescribed format. All responses
to the RFP will be subject to verification for accuracy.
Please provide the forms in the same order in which they are requested below. The proposal must
contain sufficient `information to assure DHCR of its accuracy.
The Administrative Proposal must be submitted in a separate sealed envelope, not included with the
Technical Proposal or Cost Proposal.
Cost information must not be included in the Administrative Proposal documents.
6.3.1 Title Page
Submit a Title Page providing the RFP subject and number; the Proposer's name and address, the name,
title, address, telephone and fax numbers, and email address of the Proposer‘s contact person; and the
date of the Administrative Proposal.
6.3.2 Table of Contents
Following the Title Page, the Proposer must submit a Table of Contents that should clearly identify all
material (by section and page number) included in the Administrative Proposal. Each page of the
Administrative Proposal must be numbered (with the possible exception of pre-printed material included
in attachment references), and each section heading must appear in the proposal Table of Contents.
6.3.3 M/WBE Requirements
Proposers are required to comply with Minority and Women-owned Business Enterprises (M/WBE)
requirements as stated in Appendix D M/WBE Requirements of the RFP. Appendix D M/WBE
Requirements delineates the DCHR policy regarding opportunities for M/WBE firms, including the
expected percentage of participation by such firms. As part of your proposal, complete and return the
appropriate attachments to Appendix D M/WBE Requirements in accordance with Section 3.9 Participation by Minority Group Members and Women.
6.3.4 Procurement Lobbying Provisions and Forms
Proposers are required to review Appendix H, Procurement Lobbying Provisions and Forms, and submit
the completed Affirmation of Understanding of an Agreement Pursuant to State Finance Law S139-j (3)
and S139-j (6) (b) and Certification of Compliance With State Finance Law S139-k (5) that are included in
Appendix H.
6.3.5 Vendor Responsibility Questionnaire
Prime contractors are required to complete, certify, and submit a Vendor Responsibility Questionnaire
(Appendix I) as part of their Administrative Proposal documents.
6.3.6 Assurances of No Conflict of Interest or Detrimental Effect
Bidders are required to complete, certify, and submit an Assurances of No Conflict of Interest or
Detrimental Effect Form (Appendix J) as part of their Administrative Proposal documents.
78
DHCR RFP for Rent Regulation Transformation
DRAFT V2
6.3.7 Workforce Employment Utilization
Bidders are required to complete and submit a Workforce Employment Utilization Form (Appendix K) as
part of their Administrative Proposal documents.
6.3.8 Iran Divestment Act of 2012
Bidders are required to complete and submit an Iran Divestment Act Form (Appendix L) as part of their
Administrative Proposal documents.
Failure to submit any of these requirements as described in this RFP may result in disqualification
of a Firm’s proposal.
6.4
Submission of a Complete Three-Part Proposal
Firms submitting a proposal are indicating their acceptance of the conditions in this RFP. Submission of
proposals in a manner other than as described in these instructions (e.g., facsimile, electronic
transmission) will not be accepted.
All amendments, clarifications, Bidder questions with State responses and any announcements related to
this procurement will be posted to the Division’s web site. It is the Bidder’s responsibility to check the web
site periodically for any updates. All applicable amendment information must be incorporated into the
Bidder’s proposal. Failure to include this information in the proposal may result in disqualification or a
reduced technical score.
When submitting each proposal (Technical, Cost, and Administrative), Firms will comply with the
following:

Technical Proposals, Cost Proposals, and Administrative Proposals must be submitted in
separately sealed packages;

“Original” documents must have an original signature; copied or electronic signatures will not be
accepted;

“Original” proposals (Technical, Cost, and Administrative) should clearly be marked “Original” on
the cover page;

Clearly mark the outside packaging for each set of sealed proposals (Technical, Cost, and
Administrative). The originals and each copy should be individually marked as follows:




Rent Regulation Transformation RFP
[Technical/Cost/Administrative] Proposal
Submitted by [Bidder’s name]
Each Bidder must submit:
Two (2) original and six (6) copies of the Technical Proposal.
Two (2) original and two (2) copies of the Cost Proposal.
Two (2) original and two (2) copies of the Administrative Proposal(s),
One electronic copy each (on CD) of the Technical Proposal, Cost Proposal and
Administrative Proposal. The preferred format of the electronic documents is Microsoft
Word, Excel and Project and/or PDF as appropriate.
Note: The sealed, separate proposal packages may be submitted within one complete package for
mailing.
79
DHCR RFP for Rent Regulation Transformation
DRAFT V2
A complete package (Technical, Cost, and Administrative Proposals) must be received before the time
noted in the Calendar of Events. Proposal should be sent to the following address:
Kenneth J. Ford – Manager, Contracts and Procurement Unit
New York State Housing and Community Renewal
Hampton Plaza, 38-40 State St.
Albany, NY 12207
Late proposals will not be considered for award.
The State of New York is not liable for any costs incurred by a Bidder in the preparation and/or production
of any proposal, or for any work performed prior to the execution of a formal contract(s).
80
DHCR RFP for Rent Regulation Transformation
7
Evaluation Process
7.1
General Information
DRAFT V2
The Division will evaluate each proposal based on the “Best Value” concept. This means that the
proposal that “optimizes quality, cost, and efficiency among responsive and responsible Offerers” shall be
selected for award (State Finance Law, Article 11, § 163).
The Division will determine which proposal best satisfies its requirements. The Division reserves all rights
with respect to the award. All proposals deemed to be responsive to the requirements of this procurement
will be evaluated and scored for technical qualities and cost. Proposals failing to meet the requirements of
this document may be eliminated from consideration. Qualified staff/individuals will evaluate all submitted
proposals. The Division may request clarification of a proposal. The evaluation process will be comprised
of a technical evaluation, including Demonstration and Presentation components, a cost evaluation. The
evaluation will be conducted as set forth herein.
Upon review of proposals submitted by Offerers, the Division may, at its discretion, submit to Proposers
written questions and requests for clarification relating to their Technical, Administrative, and/or Cost
Proposals. Offerers will be provided the period of time in which the written responses to the Division’s
requests for clarification must be completed.
Other than to provide clarifying information as may be requested by the Division, no Proposer will be
allowed to alter its proposal or add information.
7.2
Submission Review
The Division’s Contracts Office will examine all proposals that are received in a proper and timely manner
to determine if they meet the proposal submission requirements, as described in Section 6 of this RFP.
This review will include a review of the Administrative Proposal to confirm that it is complete and
responsive. Proposals that are materially deficient in meeting the submission requirements or have
omitted material documents, in the sole opinion of the Division, may be rejected. Proposals failing to pass
the Submission Review will be considered non-responsive and will not be evaluated any further.
7.3
Technical Evaluation
70 percent of Total Score
The technical evaluation is 70 percent of the final score. Evaluations will be based on the responses
provided to the Proposer Requirements detailed in Section 4, Section 5 and Section 6 and on the Bidder’s
performance in the Oral Presentation components.
7.3.1 Technical Proposal
An Evaluation Committee will independently score each Technical Proposal that meets the submission
requirements of this RFP. Evaluation Committee members will score the Technical Proposal for each
Proposer to identify Bidders with the highest probability of satisfactorily providing the specific services
described by this RFP.
7.3.2 Oral Presentations
The purpose of the presentation is to impart to the Selection Committee an understanding of how specific
services will be provided, to substantiate the information contained in a Bidder’s proposal, and for the
Bidder’s to further explain its proposed solution, experience and capabilities. During the presentation, the
Selection Committee may ask questions to gain a better understanding of the proposed solution.
81
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Information presented by a Proposer in the Presentation may impact their technical score.
7.4
Cost Evaluation
30 percent of Total Score
The Division Contracts Office will examine the Cost Proposal documents and review them for
responsiveness to cost requirements. If a Cost Proposal is found to be non-responsive, that proposal will
not receive a cost score and will be eliminated from consideration.
The cost scores are based on a maximum score (30 Points) being allocated to the proposal with the
lowest cost. All other proposals will receive a proportionate score based on the relation of their Cost
Proposal to the proposal offered at the lowest cost according to the following formula:
Cost points awarded = (30 potential points) X (Low Bid/Proposer’s Bid)
82
DHCR RFP for Rent Regulation Transformation
8
Award of Contract/Debriefing
8.1
Contract Award
DRAFT V2
The State expects to award one contract as a result of this RFP; however, the State reserves the right to
not award a contract, at its sole discretion reserves the right to split.
A. The State anticipates making a final decision on the selection of Contractor(s) at the time noted in the
Calendar of Events. Notification of selection/non-selection will be provided to Bidders.
B. The Request for Proposals (including all attachments and appendices) and all
amendments/clarifications thereto, and the proposal submitted by the successful Firm and any
clarifications thereto, will serve as the basis for, and will be included as appendices to, the contract(s)
with the Division. Contract(s) defining all Deliverables and the specific responsibilities of the
Contractor(s) will be drafted by the Division.
C. As stated in Section 3.11 in this RFP, in the event an agreement cannot be made with the highest
rated qualified Bidder, the Division has the right to negotiate with the next highest rated qualified
Bidder.
D. The delivery of services based on an approved contract is expected to commence on or about the
time indicated in the Calendar of Events.
E. Contract award is subject to approval of the Office of the Attorney General and the Office of the State
Comptroller.
F. Upon contract award, public announcements or news releases pertaining to the contract shall not be
made without the prior written consent of the Division.
8.2
Debriefings
Unsuccessful Bidders shall be notified upon the Division’s selection of Contractor(s). Consistent with the
New York State Procurement Guidelines, Proposers not selected for award may request a debriefing to
discuss the evaluation of their proposal within five days of receiving notification.
83
DHCR RFP for Rent Regulation Transformation
9
Contractual Requirements
9.1
Contract
DRAFT V2
The written contract with the awarded Firm shall be a standard State contract including “Standard
Clauses for New York State Contracts” included in Appendix A and the additional terms identified in
Appendix A-1. This information affecting Bidders should be carefully examined.
The entire Agreement or any agreement resulting from this procurement shall consist of the documents
and appendices listed below. Conflicts between these documents shall be resolved in the following order
of precedence:
1. Appendix A: Standard Clauses for New York State Contracts;
2. The Contract, including the terms identified in Appendix A-1, all exhibits, attachments, and
appendices;
3. The RFP, including all appendices and attachments, and any and all modifications and clarifications
thereto; and
4. The Contractor’s Proposal and any clarifications thereto.
The selected Contractor shall be responsible for successful performance of all Subcontractors.
Furthermore, the State will consider the Contractor to be the sole point of contact with regard to
contractual matters as well as payment of any and all charges resulting from the resulting Contract. The
Contractor will coordinate services with other entities when necessary to perform the services described
in this RFP and in the Contractor’s proposal. The Contractor will be responsible for compliance with
requirements under the Contract, even if requirements are delegated to subcontractors. All State policies,
guidelines and requirements that apply to the Contractor also apply to subcontractors. The Contractor
and subcontractors shall not in any way represent themselves in the name of the State without prior
written approval.
Any changes to the contract will be initiated by the Division and will be valid upon signature of the
Contract Change Signature Page, Appendix X.
9.2
Appendices
Important information is contained in the Appendices and should be carefully examined. Please note the
following:

The Bidder must complete and submit Appendix M, State Consultant Employment Form

A Sales Tax Certification (Appendix N) should be submitted upon notification of selection by the
Division, as it is required for review and approval of the contract by the Comptroller’s Office

Proof of Workers’ Compensation and Disability Insurance as required by Section 57 and 220 of
the New York State Workers’ Compensation Law should be submitted by the Insurer upon
notification of selection. See Appendix O.
84
DHCR RFP for Rent Regulation Transformation
DRAFT V2
Appendices
10
This RFP contains the following appendices:

Appendix A - “Standard Clauses for New York State Contracts” must be included in the contract
with the awarded Firm.

Appendix A-1 - Additional contractual terms

Appendix B – Notice of Interest Form

Appendix C – Non-Disclosure Agreement

Appendix D – Participation By Minority Group Members And Women Requirements And
Procedures For Contracts With Housing Trust Fund Corporation

Appendix E – Firm Qualification Form

Appendix F – Team Level of Effort

Appendix G – Cost Forms

Appendix H – Procurement Lobbying Provisions and Forms

Appendix I – Vendor Responsibility Questionnaire

Appendix J – Assurances of No Conflict of Interest

Appendix K – Workforce Employment Utilization

Appendix L – Iran Divestment Act

Appendix M – State Consultant Services – Contractor’s Planned Employment

Appendix N – Contractor Certification to Covered Agency – ST-220-CA

Appendix O – Workers’ Compensation Requirements Under Workers’ Compensation Law

Appendix P – Functional and Technical Requirements

Appendix X – Contract Change Signature Page
85