Assessment phase

This phase is relevant to:

• Buying off the shelf software
• Contracting a custom instance of existing open source software
• Contracting custom software

If you’re building software in-house, skip ahead to the Implementation phase.

The third phase applies only to projects that include an RFP. In this phase, you will publicize and actively promote the RFP, using conventional and unconventional channels to circulate it broadly. The more vendors are aware of it, the better your likelihood of finding a great partner.

As vendors become interested in responding to the RFP, you have an opportunity to engage with them. You can answer questions and provide context for the project by describing the broader goals of the department or the values of the city council. Contrary to what many public officials assume, interacting with vendors is a good thing – as long as it is fair, unbiased and non-preferential. Any questions you answer or context you provide should be made publicly available, so that all potential bidders have the same information.

When bids have been submitted, an evaluation committee will read bids and rank vendors based on the evaluation criteria you developed in phase 2. It is important to view bids from both a qualitative and quantitative perspective. The committee should be empowered to consider not only the cost, but also the alignment with public values, the technical quality and long term viability, the vendor’s collaborative dynamic, and issues like data ownership and privacy. The city’s technical staff and the end users should also be involved with evaluation, providing input to the evaluation committee. Now the tables are turned – it’s your opportunity to ask questions to the vendors! Get to know what they are offering and how they will work with you as a client.

The committee will choose one bid as the winner, but make sure to follow up properly with non-winners and provide feedback. If you’ve done a good job of writing an agile, modular budget, these vendors may be subbed in or out for future modules. Whatever happens, it’s important to maintain strong, positive relationships. At this point, the city’s legal staff will prepare a formal contract. Broadly speaking, the contract functions to reduce the city’s risk and liability, and ensure that the vendor is accountable for performance. Consider writing an umbrella contract, with sub-contracts for specific software modules – that will help reduce risk and will align with the agile development process.

Some elements will be standard and non-negotiable, but a surprising amount of contract templates can be changed. Start from the assumption that anything can be changed, and read through it carefully, paying attention to if the contract aligns with your goals for the project, and where it might impair the agile development process.

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.

Read on