Process code for software procurement

3d. Contracting

This section will help you:


Cover the city’s liability and ensure that vendors are accountable for performance


Ensure the integrity of a working relationship during the development process


Establish an effective development process and working relationship

Common challenges

You may encounter these frictions as you do the work of contracting. These are challenges the Recommended actions are designed to solve, or that may arise as you take those actions.


Legacy language or contract requirements

Outdated clauses can conflict with the project scope or impede an effective development process—particularly in the case of agile software development.

Insufficient technical specifications

If a contract does not clearly spell out the city’s expectations, there can be downstream issues with, for example, ownership, privacy, security, adaptation, and monetization. If the city does not have technical standards, use well-accepted national or international standards.

Insufficient resourcing

Software development should be a collaborative process—internally and with the vendor. Make sure that staff have sufficient time to contribute and understand expectations.

Recommended actions

1. Incorporating non-negotiable legal requirements

Contracts should lay a legal foundation for project development and delivery. Most cities have legal counsel and precedent contracts which include ‘terms of contract’—however, those terms may directly conflict with your objectives or process (for example, making agile development impossible).
You will need to determine which requirements are non-negotiable and which are flexible. For software procurement in particular, the following action and guidelines are important.

Review standard terms of contract provided by the legal department

Identify specific points that conflict with your intended process or objectives.

Favorable contract requirements
Include dispute resolution protocols. Specify that disputes will be resolved under the jurisdiction of local courts. In the event of a dispute, the agreed contract will take precedence over the vendor’s norms or standard license templates. If software is open source, the OSS license will hold.
Specify that suppliers must have ownership or legal right to use the software, equipment and tools they use in the course of the contract.
Specify that documents, software, data, and knowledge produced in the course of the contract are the sole property of the city.

2. Working with technical requirements

Your market research revealed industry technical standards, your RFP included technical requirements, and your evaluation included feedback from a technical committee. Together, these are a good starting point for the requirements you include in the contract.


Include technical expectations and standards in the contract

(see guidelines below)
Tend toward hosting private citizen information and public sector data on city servers.
Specify that data may not be accessed, sold, or shared without the written permission of the city.
Public money = public code. If it is a custom software development project, release the code under an open license. This promotes further use and development, reduces contract handcuffs, and prevents giving a competitive edge to the vendor with taxpayer money.
Promote interoperability with software already in use at the city, and other modules that are part of the project.

3. Fostering good working relationships

Contracts are not the end of a procurement process—the success of the project will depend on how well the city collaborates with the vendor. A good working dynamic will reduce errors based on miscommunication, speed up development, and improve outcomes. It will also build alignment between municipal staff and agencies who will be responsible for the software.

Union Group 194 Line 48

The development team depends on you for quick, clear decision-making

The more effective your internal process for reviewing progress and providing feedback is, the more effective the software development process will be.


Identify a primary contact (product owner) to liaise with the development team

That person will be responsible for aggregating feedback from all internal stakeholders who are involved. You may find it helpful to assign your colleagues responsibilities using the DARCI framework: Decision-maker, Accountable, Responsible, Consulted, Informed

The product owner (as well as other key stakeholders, as needed) should attend sprint planning and review meetings.
The product owner should work to answer questions within the municipality and secure buy-in to facilitate the long term implementation and maintenance of software.
Make sure that city staff has time to contribute to the process and are aware of the important role that they can fill: co-designing sprints, giving feedback, adding or subtracting features, and sharing insights about day-to-day usability.

Create or complete the following outputs before moving on to the next step.

gear 2 arrow 2

Contract with the winning vendor

gear 2 arrow 2

Internal alignment on the project plan and internal working group as needed