Requests for proposals (RFPs) are a good way to start the product evaluation process as well as help clarify the project's scope and requirements. RFPs give you the ability to compare products and platforms more objectively and get you the best results for your project. That said, the process of documenting and clarifying your project requirements can be pretty painful and time-consuming.
As a senior solutions engineer for customer identity and access management (CIAM), I've seen hundreds of RFPs -- some great and some terrible. To help you get the answers you're looking for, and put some good karma into the world, I've compiled a few tips to create a good CIAM RFP that is mutually beneficial to you and the vendors you're considering.
Gathering your cross-functional team
With CIAM projects, IT teams will generally take the lead in gathering technical requirements from the development teams. This is certainly a good source of requirements, but it is not the only group that needs representation throughout the process. Brand management, privacy compliance team, marketing, and security all gain value through the deployment of the right CIAM platform. Extending the RFP with some of their specific requirements upfront can add value to the CIAM project and help build the internal business case for buying a top-shelf CIAM platform.
RFPs created in a vacuum for a specific team without the holistic view can have several challenges, including picking the right tech, getting executive buy-in for the project, and scaling deployment.
Choose your tools
When crafting an RFP, think like an elementary school teacher. When a teacher creates a test, they pose the question and how they want the answer responded to in a clear way to improve the quality of the students' answers. So if you have a requirement that is true or false, narrow the options to just that. If you want a short answer, constrain the space available, and if you want a larger, more detailed answer, require it as an attachment.
For basic questions that require short answers or selection from a limited list, use a spreadsheet. Within all of the spreadsheet platforms, you can add validation and constraints to keep the answers uniform. You can also do things like introduce a grading system with weighting for each requirement, which will speed up objective evaluation.
The only major drawback to using a spreadsheet: The actual text management in a spreadsheet cell can be cumbersome when complex questions are being asked. In this case, require responses in a writable/annotatable document format. This will give the company answering the RFP freedom to provide a complete answer using the level of detail that meets your expectations.
For architecture questions, include a proposed "To-Be" diagram outlining your expectations. This will give the company answering the RFP a jumping-off point when building a personalized response and will make comparison between the different companies easier. Otherwise, standard diagrams will tend to vary between companies and not be as ideally personalized to your requirements.
IAM vs. CIAM
Don't confuse enterprise identity and access management (IAM) requirements with customer identity and access management requirements.
A common challenge we run into with RFPs is when the customer blends their requirements between what they need to manage their employees' identities with their requirements for managing their customers' identities. Some common language and requirements are shared between the two different systems, but they diverge on some key requirements.
Be generous with yourself and your prospective vendors with regard to timeline. All RFPs should have a clear set of milestones and corresponding dates. RFPs that give reasonable timelines (2 to 3 weeks between initial distribution of the RFP and the actual response time) get the best results in terms of answer quality and personalization to the specific use cases requested. Every organization you deliver an RFP to will have a stock set of answers for the common content/questions asked during an RFP. To get more meaningful responses than the stock answers requires time.
On the other hand, timelines tend to slip on the customer's side, so give yourself room to handle those slips without impacting the overall project timeline. I've seen really detailed RFPs come out with very tight timelines when going through the evaluation process. This process can be surprisingly complicated, and if the project start date approaches, those evaluations can be reduced to who can get the job done in time versus which technology is the best for the requirements. After you've spent so much time putting a quality RFP together, it hurts to have to compromise at the eleventh hour.
With the right combination of team, technology, timeline, and requirements, an RFP can be a great way to make an objective partnering decision with a CIAM vendor. It takes work to make a good RFP, and it takes work to respond well to an RFP. I look forward to answering your CIAM RFPs in the near future!