Ein Online-Antragsportal, eine Schnittstelle zwischen zwei Fachverfahren, ein internes Ticketsystem. Wenn Standardsoftware nicht mehr passt, entwickeln wir eine Individuallösung. Für öffentliche Auftraggeber ist der Weg dorthin rechtlich vorgezeichnet. Für Entwicklerteams, die solche Aufträge annehmen, lohnt sich aber auch ein Blick in dieselben Regeln. Ob ein Softwareprojekt gut gelingt, entscheidet sich nämlich ganz oft lange vor der ersten Codezeile.
Planung: Ohne belastbaren Bedarf keine saubere Vergabe
Am Anfang steht die Frage, was die Software leisten soll und was sie kosten darf. Die Anforderungen werden in einem Lastenheft gebündelt, getrennt nach funktionalen und nicht funktionalen Kriterien. Zu Letzteren gehören Antwortzeiten, Barrierefreiheit, Schnittstellenstandards wie REST und JSON sowie Vorgaben zur Informationssicherheit.
Parallel braucht es eine Kostenschätzung, denn der geschätzte Auftragswert bestimmt das Verfahren. Nach § 3 der Vergabeverordnung zählt der Gesamtwert ohne Umsatzsteuer, einschließlich Optionen und Vertragsverlängerungen. Seit dem 1. Januar 2026 liegt der EU-Schwellenwert für Liefer- und Dienstleistungen bei 216.000 Euro für subzentrale Auftraggeber und bei 140.000 Euro für zentrale Regierungsdienststellen. Wer darüber liegt, muss europaweit ausschreiben.
Ob sich Eigenentwicklung, angepasste Standardsoftware oder eine Open-Source-Lösung rechnet, lässt sich mit einer Wirtschaftlichkeitsbetrachtung nach dem WiBe-Standard des Bundes vergleichen. Viele Verwaltungen ziehen für diese Phase einen herstellerneutralen Fachplaner IT hinzu, der Anforderungen, Lösungsvarianten und Kostenrahmen zusammenführt, bevor die Vergabeunterlagen entstehen. Der Vorteil liegt in der Kontinuität. Wer den Bedarf erhoben hat, kann später prüfen, ob er tatsächlich erfüllt wurde.
Vergabe: Leistungsbeschreibung, Wertung und Vertrag
Die Leistungsbeschreibung muss nach § 31 VgV eindeutig und produktneutral formuliert sein. Verweise auf bestimmte Hersteller oder Produkte sind nur zulässig, wenn der Auftragsgegenstand dies rechtfertigt.
Für die Angebotswertung hat sich die UfAB 2018 etabliert, ein Praxisleitfaden des Beschaffungsamts des Bundesinnenministeriums. Sie beschreibt mathematische Methoden, mit denen Preis und Leistungspunkte zu einer vergleichbaren Kennzahl verrechnet werden. Den Zuschlag erhält nach § 127 GWB das wirtschaftlichste Angebot, also das beste Preis-Leistungs-Verhältnis und nicht zwingend das günstigste.
Vertragsgrundlage ist in der Regel der EVB-IT Erstellungsvertrag. Er deckt die Erstellung von Individualsoftware und die Anpassung von Software auf Quellcode-Ebene ab. Standardmäßig erhält der Auftraggeber ein nicht ausschließliches Nutzungsrecht. Wer mehr braucht, etwa exklusive Rechte oder die Befugnis zur Weiterentwicklung durch Dritte, muss das ausdrücklich vereinbaren. Gleiches gilt für Quellcode-Übergabe, Dokumentation und Pflege nach der Abnahme.
Projektüberwachung: Vom Kick-off bis zur Abnahme
Mit dem Zuschlag beginnt die eigentliche Steuerungsarbeit. Ein Meilensteinplan, regelmäßige Statusberichte und ein geregeltes Änderungsverfahren verhindern, dass Zusatzwünsche unkontrolliert zu Nachträgen werden. Bei agiler Entwicklung sollten Sprint-Ziele und eine Definition of Done vertraglich verankert sein.
Die Abnahme ist der rechtlich entscheidende Moment. Bei werkvertraglichen Leistungen nach § 640 BGB wird mit ihr die Vergütung fällig, und die Verjährung der Mängelansprüche beginnt. Getestet wird gegen die Kriterien des Lastenhefts. Die EVB-IT unterscheiden dabei Mängelklassen, von betriebsverhindernden Fehlern bis zu leichten Mängeln, die eine Abnahme nicht blockieren.
Was Auftraggeber und Entwickler daraus mitnehmen können
Auftraggeber sollten Abnahmekriterien bereits ins Lastenheft schreiben und den Auftragswert früh realistisch schätzen. Planung, Vergabe und Überwachung funktionieren am besten, wenn dieselben Fachleute alle drei Phasen begleiten.
Entwicklerteams auf Bieterseite profitieren davon, die EVB-IT Erstellungs-AGB vor der Angebotsabgabe gründlich zu lesen. Nutzungsrechte an vorbestehenden Komponenten und eingesetzten Open-Source-Bibliotheken gehören offengelegt. Dokumentation ist kein Nebenprodukt, sondern Leistungsbestandteil und sollte entsprechend kalkuliert werden.
