Summary of findings and publishing a request for information (RFI)

The hiring modernization project has just wrapped up a large research phase and is gearing up to transition into a modular implementation phase. To recap, here is a timeline outlining the sequence of events we’ve completed to date:

We are currently around the “Phase 3” mark with a few conversations still in progress that will impact the work in March.

Wrapping up everything we learned and collected to date

In an effort to remain open and provide various ways for folks to engage, learn, stay up to date and provide feedback we’ve been very diligent about documenting all of our research. This is something we’ve been working on putting together over the past month. The end product is a long, but concise living document outlining research pertaining to each one of the seven hiring modules.

We hope this structure will be beneficial for:

• Onboarding new members to the project
• A reference document that grounds us (and anyone working on this) in user needs
• Going deep on certain parts of the hiring process, while easily referencing the larger ecosystem
• Easily add details to existing sections as we continue moving forward

The document outlines the seven hiring modules:

And we picked a few key topics to describe each module in more detail:

We believe that it will be critical to have this document as a reference tool moving forward and wanted to share one example of what a module (the second hiring module: define roles) looks like.

You can view the entire document here.

With this document created, we can now move forward with making these changes a reality. The main way in which we do this is through the procurement process. Instead of releasing one large monolithic RFP, we’ve decided to break this project up into smaller components, but before even starting to do that we’ve decided to release a request for information (RFI).

Why are we releasing a request for information (RFI)?

Throughout this project, we’ve aimed to be as open as possible. An RFI is the natural next step because it allows us to:

• Inform potential vendors of the project objectives, challenges and process
• Allow potential vendors to have a strong understanding of the project so they can thoroughly think through their capabilities and determine whether this project is the right fit for them or not

We believe this open process gives the City and County of San Francisco the best chance to find the right partners moving forward. 18F led a similar process in Alaska, and they wrote a great piece about it here.

We’ve experienced the challenges that arise when a solicitation we’ve released or a contract we’ve signed goes awry. This can lead to trying to get everything perfect before releasing anything to the public — working in a vacuum that is actually counterproductive to our aim of collaboratively partnering with vendors. Without that valuable feedback from the vendor community, it can be difficult to construct a solicitation that is as good as it needs to be, instead relying on the misplaced hope that vendors will understand it. Often, this approach forces vendors to make assumptions to fill in the gaps because they lack a clear-enough picture of the project to respond adequately. When the product team and vendor start from a place of fundamental misunderstanding, it can be difficult to recover [emphasis added]. — How Alaska is using transparency to attract modern software vendors

What’s next?

In parallel we’re continuing to run small prototypes with different departments to (1) show what is possible when implementing smaller modular improvements, (2) better understand all possible use-cases, and (3) document these findings into our summary described above.

We are also in the process of collecting technical requirements from key internal stakeholders. This is critical as it will inform the technical requirements section of the RFI and RFPs moving forward. We’re in the process of having conversations with:

• CCSF’s Department of Technology to understand SaaS (software as a service) minimum requirements
• CCSF’s Controller’s Office to (1) continue documenting the data flows/dependencies between PeopleSoft (CCSF’s human capital management system) and the applicant tracking system, (2) to understand requirements of third-party solutions interfacing with PeopleSoft and (3) preferred approaches
• CCSF’s Committee on Information Technology to ensure we’ve appropriately scoped the project. Important dimensions include: strategic value (goals, impact), project benefits (users, measures), financial benefits (savings, fund match), regulatory compliance & risk management (policy, security), architecture and development plan (development methods, sharing), department capacity (planning, staffing)

We’re excited to continue sharing more in a couple weeks. As always, if you have questions or concerns, feel free to reach out at: monique.baena-tan@sfgov.org

-David and Monique

Monique Baena-Tan is Researcher and Service Designer for the Hiring Modernization Project. Most recently Monique led design research on Code for America’s talent initiative which included a job board to help technologists find opportunities in public interest tech, and documented best practices across the country in government hiring.

David Huebner is Project Manager and Strategy Advisor for the Hiring Modernization Project. He most recently worked at Code for America where he led a talent initiative focused on helping governments improve their people practices to ensure they can hire and retain technologists to deliver services most effectively. Previously, David worked at Google as a Manager on a strategy, analytics and effectiveness team focusing on hiring and people services.