Learn more about the solution the City and County of San Francisco seeks to procure
Learn more about the solution the City and County of San Francisco seeks to procure
2.1. General information
The Scope of Work is to be used as a general guide and is not intended to be a complete list of all work necessary to complete the Project.
Each Proposer should demonstrate its capabilities in RFP Proposal Templates A-K. CCSF will negotiate the specific scope of services, budget, deliverables, and timeline with the highest-scoring Proposer selected for contract negotiations. There is no guarantee of a minimum amount of work or compensation for any Proposer selected for contract negotiations.
Please refer to the full RFP for a complete scope of work.
2.2. Overview of services
Overview of the hiring process broken down into modules:
.png)
Per this diagram, this RFP focuses on the following hiring process modules:
-
Getting the word out
-
Assessing skills
-
Creating a ranked list of eligible candidates (unique to government and CCSF)
-
Matching positions with eligible candidates (unique to government and CCSF)
-
Determining fit
-
Data
-
Communication
-
User experience
Below we have included the purpose of each module, but the product requirements for each module can be found in the full downloadable RFP.
The list of product requirements is based on research and discovery work the Hiring Modernization Project team has led and indicates the types of functionality CCSF is looking for. Note that each product requirement involves many details that CCSF expects the selected Proposer to research, define, and adjust (if necessary) for the best implementation plan moving forward. These are objective-based goals rather than specific functional requirements. They should provide Proposers with a sense of the goal CCSF is trying to achieve, not specifically how it should be achieved. CCSF has distinguished between the requirements that CCSF believes are essential to building a strong foundation versus those that CCSF defines as enhancements that would allow CCSF to further modernize its practices.
2.2.1. Getting the word out
The purpose of this module is to ensure that CCSF puts open positions and upcoming exams in front of prospective candidates and that enough qualified people apply/take the exam.
Please refer to the full RFP for a complete scope of work.
2.2.2. Assessing skills
The purpose of this module is to ensure that CCSF is objectively and effectively determining which candidates have the appropriate skills and qualifications for a given position through the evaluation of minimum qualifications and an examination process. Refer to Section 11.1. for more details on this unique government hiring process.
Please refer to the full RFP for a complete scope of work.
2.2.3. Creating a ranked list of eligible candidates
The purpose of this module is to ensure that CCSF is objectively and effectively ranking qualified candidates based on their examination scores and other relevant criteria. Refer to Section 11.2 for more details on this unique government hiring process.
Please refer to the full RFP for a complete scope of work.
2.2.4. Matching positions with eligible candidates
For permanent civil service positions, the total number of hires needed (City-wide), and rules negotiated with unions determine how many qualified candidates can be shared with (or “referred” to) a hiring manager. Refer to Section 11.3 for more details on this unique government hiring process.
Please refer to the full RFP for a complete scope of work.
2.2.5. Determining fit
The purpose of this module is for hiring managers to establish a process for determining and selecting the best eligible candidate for the position and their department/team through:
-
A selection process (e.g., interviews, job-specific questionnaires, etc.)
-
Capturing the results of any additional screening tied to the duties of the positions (e.g.,
background checks, medical examinations, etc.)
Please refer to the full RFP for a complete scope of work.
2.2.6. Data
Data is a critical piece of any applicant tracking system. The system should provide visibility into essential recruiting trends, answers to high-level recruiting questions, and insight into more nuanced parts of the hiring process.
Please refer to the full RFP for a complete scope of work.
2.2.7. Communication
Communication plays a key role in ensuring all users are on the same page throughout the hiring process. Communication also has the potential to support candidates and ensure candidates are being offered the best possible user experience.
Please refer to the full RFP for a complete scope of work.
2.2.8. User experience
In addition to the modules described in Sections 2.2.1 through 2.2.7, there will be elements in an applicant tracking system that will need to be explored and added in order to constantly offer the best possible user experience to candidates, hiring managers, and HR professionals. CCSF expects the selected Proposer to consistently value, complete, and prioritize research to ensure CCSF is meeting users’ needs as they evolve.
Please refer to the full RFP for a complete scope of work.
At this time, CCSF is not looking for Proposals for the following modules (grayed out in the diagram at the beginning of RFP Section 2.2): Define Roles, Number of Hires Needed by Role, and Onboarding. PeopleSoft currently supports the basic functionality behind these modules. However, as noted in Section 2.4, it is critical that the ATS solution integrates with PeopleSoft HCM 9.2 (and future releases) to ensure that data such as job classification information, approved positions, and new hires flow between the different systems.
2.3. Implementation design
As mentioned previously, CCSF is looking to implement a modular and extensible solution that easily allows products to speak to one another. Therefore, any implemented solution (whether an individual module or a broader platform implementation) must present an Ecosystem-friendly approach with:
-
2.3.1. Heavy use of standards-compliant exchange formats (such as JSON)
-
2.3.2.The majority of core functionality is expected to have appropriate API endpoints to allow for automation and extension
-
2.3.3. Event-based hooks or triggers that allow integrating
-
2.3.4. Pre-built connectors or data-exchange formats for direct connection with other modules and services (without requiring custom coding)
-
2.3.5. Responsive design assuming usage on different devices (desktop, mobile, tablet)
-
2.3.6. Configurable capabilities that allow the application to be easily modified by non-technical staff when laws or policies change
-
2.3.7. Complies with the Americans with Disability Act, including but not limited to Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. Sec. 794d), and WCAG 2.0 and 2.1 guidelines as amended or updated from time to time. The selected vendor may be asked to complete a Voluntary Product Accessibility Template (VPAT)
2.4. PeopleSoft integration
CCSF utilizes Oracle PeopleSoft HCM 9.2 (on-prem) as a primary data-source, data-connection, and data- integration point. Therefore, solutions must support data exchange with PeopleSoft PeopleTools. For detailed information about PeopleSoft PeopleTools Integration Tools, please review the following PeopleBook online here.
Proposers who are concerned about the on-prem nature of CCSF’s system are encouraged to ask questions before the questions deadline. CCSF believes that some of the options proposed in terms of how to interface with PeopleSoft (i.e., through an API layer, through a third-party integration partner) could address such concerns when integrating with a cloud-based ATS solution.
The preferred connection methodology for all integration points moving forward is the PeopleTools Integration Broker. Specific planning and execution of the Integration Broker development (or an alternative equivalent approach) will be necessary.
Based on the responses provided to the RFI published in 2018, CCSF foresees a few different approaches to help ensure integration between the cloud-based ATS solution and the current human capital management system (PeopleSoft 9.2):
-
Building an API layer facilitating the integration--this could be in the form a hub (the role of the hub architecture would be to provide a common exchange and data broker through which various vendors, projects, and products can pass relevant events and data)--the hub would expose those PeopleSoft data, objects, and services through a RESTful, GraphQL, or similar modern API-based service architecture
-
Working with a third-party integration partner
-
Addressing the different integration needs on a one-off basis
There are five pre-built integrations between the current ATS and PeopleSoft. At a minimum, CCSF will need to continue to integrate at these points in the process. However, CCSF recognizes that there could be many other processes that could be optimized with further integration (e.g., pulling in employee information including employee type, seniority date, and information allowing the system to calculate eligibility for promotional points).
Please refer to the full RFP for a list of current pre-built integrations between the current ATS and PeopleSoft.
Any procured service (Software as a Service, or “SaaS”) or custom-implemented solution must meet a desired level of security, reliability, and performance. The data involved and transferred related to CCSF hiring is sensitive and often legally protected. In addition to a minimum industry-standard level of data protection, preference is given to those solutions that present a comprehensive approach to keeping all data and flows secure and available.
The envisioned system and modules must secure applicant, employee, and all types of personally identifiable information data stored and accessed by the application(s). The system (including processes, interfaces, databases, and connections) must be secured against intrusion, injections, or other means intended to gain access to the application(s), data, or CCSF infrastructure.
Please refer to the full RFP for a complete list of security requirements.
2.5.3. Legacy data migration
The Proposer will work with CCSF to identify, transform, and migrate legacy data. CCSF anticipates this process will involve significant planning efforts and will include many interrelated data models. Please note that while CCSF would ideally like to migrate as much legacy data as possible, the selected Proposer is expected to work with CCSF to identify the data that can be reasonably migrated.
2.5. Platform and security requirements
As discussed in Section 1.9, sprint meetings will take place every two to four weeks to go over items to be prioritized and to plan the upcoming sprint. Sprints end with a sprint review (demonstrate work done, and accept or reject that work) and a sprint retrospective (to review performance).
The Proposer will implement a working product feature or module at the end of each sprint. CCSF and the Proposer will use the results of these sprints to decide together the goals of subsequent sprints. CCSF anticipates that work will continue until all critical product features are released and successfully implemented.