1. Orientation
3a. Assessment phase
In this phase, you will publicize and promote the RFP, circulating it broadly using both novel and conventional channels. Vendor awareness increases your likelihood of finding a great partner. As vendors express interest, you can answer questions, and provide context by describing the broader goals of the department, or values of the city council. The key to countering (valid) concerns around interacting with vendors is a fair, unbiased and transparent process—any questions answered or context provided should be made publicly available, so all potential bidders have the same info.
When bids have been submitted, an evaluation committee will read bids and rank vendors based on the
criteria you developed in Phase 2. It is important to view bids from both qualitative and quantitative
perspectives. The committee should be empowered to consider not only the cost, but also alignment with
public values, technical quality and long term viability, the vendor’s collaborative dynamic, and
issues like data ownership and privacy.
Now the tables are turned—it’s your opportunity to ask questions of the vendors! Get to know what
they are offering and how they will work with you as a client. The city’s technical staff and end
users should help provide input to the evaluation committee. Host workshops where vendors can demo
their solutions to end users, giving them direct experience.
Once the committee chooses a winning bid, make sure to follow up properly with other bidders and
provide feedback. If you’ve done a good job of writing an agile, modular budget, these vendors may be
subbed into future modules. Whatever happens, it’s valuable to maintain strong, positive
relationships.
At this point, the city’s legal staff will prepare a formal contract. Broadly speaking, the contract
reduces the city’s risk and liability, and ensures vendors are accountable for performance. Remember
the modular approach: umbrella contracts, with sub-contracts for specific software modules, help
reduce risk and align your project with the agile development process.
Though some contract elements are standard and non-negotiable, a surprising number can be changed.
Assume anything can be changed, and read through it carefully—pay attention to alignment with your
goals for the project, and where the contract might impair an agile development process or limit open
sourcing.
This phase concludes with a contract that the vendor, legal staff, and project team agree on. With
that agreement in hand, you are ready to start collaborating on software development.