9. Contracting
This step is for organizations:
- buying off the shelf software
- hiring a vendor to customize existing open source software
- buying custom software
If you are building software in-house, read 6. Agile development planning and resourcing or skip ahead to the Implementation phase.
Goals
- To cover the city’s liability and ensure that vendors are accountable for performance.
- To ensure the integrity of a working relationship during the development process.
- To establish an effective development process and working relationship.
Actions
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 process or objectives (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 points are important.
- Review standard terms of contract provided by the legal department. Identify specific points that conflict with your intended process or objectives.
- 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.
Working with technical requirements
Include technical expectations and standards in the contract.
- 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, tend toward releasing 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)
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 miscommunications, speed up the development process, and improve the final outcome. It will also build alignment between the municipal staff and agencies who will be responsible for using and maintaining the software.
- Identify a primary contact (product owner) and key stakeholders. It may be useful to name additional stakeholders involved using the following tags:
- 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 have 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.
Common challenges
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.
Checklist
- Contract with the winning vendor
- Purchase order with the winning vendor
- Internal alignment on the project plan and internal working group as needed
References
Boston Procurement Reform Resources
Open Software Licenses 101
https://fossa.com/blog/open-source-licenses-101-mit-license/
FairMarkit: Procurement Contract Management Best Practices
https://www.fairmarkit.com/blog/procurement-contract-management-best-practices
McKinsey: Taking supplier collaboration to the next level