Cover the city’s liability and ensure that vendors are accountable for performance
3d. Contracting
This section will help you:
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
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)
Guidelines
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.
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
Guidelines
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.
Takeaways
Create or complete the following outputs before moving on to the next step.
Contract with the winning vendor
Internal alignment on the project plan and internal working group as needed
Further reading
