Soliciting bidder information on compliance with the IIS Functional Standards

If you are seeking to migrate to a new IIS, you will want to know how prospective commercial off-the-shelf solutions or other IIS solutions meet the IIS Functional Standards. Avoid vague instructions such as “describe how you meet the Functional Standards” or, on the other extreme, requiring narrative descriptions for each of the standards, which can consume precious and limited pages in the proposals. Focus on what information you most need. Chances are some standards are more important to you than others (the CDC IISSB Operations Team can help with setting priorities), and unique jurisdictional requirements are likely ones about which you definitely want to learn (e.g., PAIS status, consent, ability to generate a vaccine validation and forecast based on the school immunization law requirements, inter-jurisdictional exchange, etc.). Options include:

• Include a table with the Functional Standards listed, with columns for “fully support,” “partially support” and “do not support,” with room for the bidder to comment.
• One way to structure comments for “partially support” responses is to ask bidders to list which operational guidance statements they do not currently meet, or, conversely, which they do fully meet.
• Ask for a narrative description of any Functional Standards not currently fully met, including plans and timeline for meeting them.

Rely on product demos, if allowed in your jurisdiction, to satisfy your most pressing interests in the Functional Standards, focusing the RFP on how the bidders will address your unique legal, policy, technical or other jurisdictional requirements.

Considerations

• While many solicitation documents include the history of the IIS, focusing on your needs and current priorities is much more helpful for the bidders.
• Know when to be specific and when to allow the bidders to propose solutions. Generally speaking, state your requirements but not how the bidder is to meet them. There is a good chance the bidder is more attuned to evolving IIS technologies or newer ways to meet IIS requirements than the IIS program or central IT.
• Consider carefully before specifying contractor support in terms of full-time equivalents (FTE). It might be more in your interest to state only what services and skill sets you need, allowing the bidders to assemble the expertise in the most cost-effective way. That approach might mean a bidder proposing to use a portion of a particular person and expertise (e.g., vaccine evaluation and forecasting, AFIX support) across supported projects that use the same IIS platform or module; in other words, you’d be acquiring a more knowledgeable and diverse team by enabling the bidder to assemble a team based on skills rather than FTEs.
• State technology standards should be included in an RFP, but current process flows are best left out in order to leave bidder flexibility in determining the best process. Insisting on a current process flow that doesn’t match how other IIS software works may discourage bidders from applying or could add customization costs.
• Avoid the phrase “including, but not limited to,” because it is unclear and may leave the bidder unsure whether to add functions to the software or to adjust the cost. It can also open the possibility of misunderstandings leading up to or in the delivery/implementation of the product.
• If central IT is involved in hosting or supporting your current IIS, including a RASCI chart (responsible-accountable-supports-consulted-informed) can help the bidder understand how they will need to fit into an organizational responsibility matrix and even to estimate how much time will be required for different levels of decisions. The RASCI chart should list the level of responsibility for key responsibility areas related to database management, change requests, security, etc., by program, central IT and vendor. (For a RASCI chart template, see the “assembling the acquisition team” section.)
• It may be that you do not want to signal that you are interested in migrating, perhaps because you want to stay with your current solution, because your jurisdiction’s procurement policies may prohibit any language that might reduce competitive bidding, or because you actually would like to migrate but don’t want your current vendor to know. Each of those circumstances may require somewhat different approaches and perhaps subtle differences in language. Speaking candidly with your procurement officer is likely your best route to deciding how to proceed.

Final checks

☑ Have you verified that there are no conflicts between boilerplate and IIS-specific language in the RFP?

☑ Have you verified that any links to reference documents work?

☑ Have you verified that the RFP provides sufficient information for the bidders to satisfy the evaluation/scoring criteria?

☑ Are you including a proposal document checklist to aid bidders in ensuring they are submitting a complete package? If so, has the checklist been validated by the procurement office?