Skip to content

Writing ToRs for projects with Open Source

We recommend those unfamiliar with open source software procurement to seek expert guidance on formulating tenders, as they differ significantly from standard international development tenders (technical advice and infrastructure). As general best practice, consider involving partners and future users early in the conception of the ToR, to ensure alignment with their needs and expectations. In line with this, clearly agree with them their expected level of involvement during the project and transparently communicate this in the ToR. Similarly, be transparent in the reasoning on the technical requirements and have resources available to answer technical questions during the tendering process.

Checklist

5. Background

  1. Provide a clear description of the problem and user group, addressing the dimensions of 1.
  2. Provide a detailed description of the status quo, including 2., 3. and 4.
  3. Clearly describe the vision and highlight which parts are not predetermined
  4. Transparently share the reasoning for the open source preference.

6. Define clear technical requirements for the project

  1. Make the requirements as flexible as possible to meet with different technological solutions. Consider only sharing the needs analysis, leaving the choice of technology to the contractor. When listing technological options, be mindful of omissions.
  2. Be specific on interoperability requirements and standards to follow
  3. Describe the service requirements across the entire software life-cycle (Software-Lebenszyklus – Wikipedia), in particular those aspects that concern roll-out, maintenance and later adaptations that may be needed
  4. Differentiate nice to have and must have criteria. Avoid long wish-lists focus on criteria that are relevant for the core problem only.
  5. Be aware of potentially exclusive criteria that may seem small side-aspects, but can be prohibitively expensive for (small) suppliers (e.g. specific hosting requirements, certain cybersecurity standards, …)

7. Work packages

  1. Clearly describe and differentiate the required development stages (discovery, pilot, implementation/roll-out, maintenance)
  2. Describe the involvement of user groups
  3. Describe desired implementation approach - consider prioritising agile modes of work where possible
  4. Plan the project timeline accordingly. Take into account that design and user engagement can take significant amounts of time.

8. Budget preparation

  1. Carefully match the project requirements to the budget. Adapting, rather simply adopting, a piece of software can imply significant increases in effortConsider at minimum the following aspects for human capacity: analysis/requirements engineering, design, programming, user engagement and testing, domain expertise
  2. Consider costs for training and change management
  3. The less clear the choice of technology, the more flexibility is also required in the budget. If no solution has been identified, budget for decision making process. If instead the choice is clear, draw on a standard framework for software budgets.
  4. User engagement is key but costly. At minimum, budget explicitly for design workshops and user testing.
  5. Calculate costs for maintenance and hosting both for the project period and for afterwards
  6. Consider agile-compatible remuneration and project steering strategies