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

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.

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, …)

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.

Personnel Concept

Common measures of qualification such as years of experience and level of formal education have strong limitations within software project1. We therefore put together a few recommendations for the personnel concept:

Matching Maturity

Different project phases require distinct skill sets, which are often challenging to find in a single CV. During early discovery phases, when the tech stack or product vision is still undefined, comprehensive expertise in the domain and general IT architecture is crucial. As the project matures and requirements solidify, more specialized technical skills become key.

  1. Prioritize skills and experiences that match the maturity stage of your project

  2. Where possible, include mixed seniority through expert pools and tandems, to allow teams to flexibly distribute work and enable capacity building

  3. Consider other measures of experience, such as number of reference projects in field X, especially for less senior roles.
  4. When requiring specific skills and technologies, be sure to limit it to a set of core competencies to avoid unicorn personas

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

  1. The inventor of a famous python package called FastAPI, for example, posted job offers to which he could not apply because it required 3 years of experience while he had only invented FastAPI 1 year before. As for the University degree, some famous examples of University dropouts include Steve Jobs (founder of Apple), Bill Gates (founder of Microsoft), and Mark Zuckerberg (founder of Facebook). All of them would fail to meet the formal education requirements of many job offers. ↩