Warum das LV über den Projekterfolg entscheidet
Das Leistungsverzeichnis ist das zentrale Dokument jeder IT-Ausschreibung. Es ist gleichzeitig die rechtlich bindende Grundlage des späteren Vertrags, die Basis für alle Angebote der Bieter und der Maßstab für die spätere Leistungsabnahme. Was im LV fehlt, undeutlich formuliert oder rechtlich angreifbar ist, wirkt sich in jeder dieser drei Dimensionen aus.
- Angebote nicht vergleichbar, Wertung angreifbar
- Bieter kalkulieren Risikopuffer ein, Preise steigen
- Nachträge und Streit über den Leistungsumfang
- Rügen und Nachprüfungsverfahren durch Bieter
- Aufhebung des Verfahrens im schlimmsten Fall
- Vergleichbare, vollständige Angebote
- Realistischere Preise durch Planungssicherheit für Bieter
- Klare Abnahmekriterien, weniger Nachtragsstreit
- Nachvollziehbares Verfahren, weniger Angriffsfläche
- IT-Projekt läuft wie geplant, weil der Scope klar war
Viele Probleme in IT-Projekten der öffentlichen Hand haben ihren Ursprung vor der Umsetzung: in einem Leistungsverzeichnis, das zu vage formuliert, zu produktorientiert aufgebaut oder in entscheidenden Punkten lückenhaft ist. Sorgfalt beim LV zahlt sich deshalb aus.
Kernbestandteile eines Leistungsverzeichnisses
Leistungsbeschreibung und Leistungsverzeichnis sind nicht dasselbe: Die Leistungsbeschreibung (LB) ist das übergeordnete Dokument, das den Auftragsgegenstand beschreibt (§ 121 GWB, § 31 VgV). Das Leistungsverzeichnis (LV) ist eine positionsbasierte Form der Leistungsbeschreibung mit Mengen, Einheiten und Einzelpositionen. Das LV ist also eine konkrete Ausprägung der LB, nicht deren Bestandteil. Für IT-Ausschreibungen sollte ein vollständiges LV folgende Kernpositionen umfassen:
Einzelne, klar abgrenzbare Leistungseinheiten mit Bezeichnung, Menge und Einheit. Jede Position muss so beschrieben sein, dass Bieter sie eindeutig kalkulieren können.
Anzahl Nutzer, Standorte, Geräte, Transaktionen, Lizenzen. Ohne Mengengerüst können Bieter keine realistische Preiskalkulation erstellen, und kalkulieren dann auf Risiko.
Kompatibilitätsanforderungen zur bestehenden IT-Infrastruktur, Betriebssysteme, Datenbankversionen, Browserkompatibilität, Barrierefreiheit (BITV 2.0).
Welche bestehenden Systeme muss die neue Lösung anbinden? Format, Protokoll, Übergabepunkt und Verantwortlichkeit je Schnittstelle klar benennen.
Verfügbarkeitsanforderungen, Reaktionszeiten, Wartungsfenster, Support-Zeiten. Je präziser hier formuliert wird, desto klarer sind Vertragsgrundlage und Abnahmekriterien.
Wann gilt die Leistung als erbracht? Welche Tests und Abnahmekriterien gelten? Ein fehlender Abnahmerahmen führt leicht zu späterem Streit über Nachträge.
Das Mengengerüst wird in Leistungsverzeichnissen leicht vernachlässigt. Bieter, die nicht wissen, wie viele Nutzer, Standorte oder welches Datenmigrations-Volumen gemeint ist, kalkulieren entweder zu hoch (Sicherheitspuffer) oder zu niedrig (Nachträge). Beides schadet dem Auftraggeber. Lieber ungenaue Schätzwerte angeben als gar keine.
Herstellerneutralität nach § 31 VgV
§ 31 Abs. 6 VgV verbietet Verweise auf eine bestimmte Produktion oder Herkunft, ein besonderes Verfahren, gewerbliche Schutzrechte, Typen oder einen bestimmten Ursprung, wenn dadurch bestimmte Unternehmen oder Produkte begünstigt oder ausgeschlossen werden, es sei denn, der Auftragsgegenstand rechtfertigt den Verweis. Dahinter steht der Wettbewerbsgrundsatz (§ 97 Abs. 1 GWB): Jeder Marktteilnehmer soll eine faire Chance haben, ein passendes Angebot abzugeben.
- „Microsoft SharePoint als Dokumentenmanagementsystem“
- „SAP-kompatible Schnittstelle“ ohne funktionale Alternative
- Anforderungen, die faktisch nur ein Produkt erfüllen kann
- Neutral formuliert, aber Kombination von Parametern schließt alle außer einem Hersteller aus
- Funktionale Beschreibung: „webbasiertes DMS mit Versionierung und Rollenkonzept“
- Angabe von Industriestandards: „REST-API, OAuth 2.0“
- Produktnennung nur ausnahmsweise, mit dem Zusatz „oder gleichwertig“ und dokumentierter Begründung
Eine Produktnennung ist ausnahmsweise zulässig, wenn der Auftragsgegenstand anders nicht hinreichend genau und allgemein verständlich beschrieben werden kann. Dann ist der Zusatz „oder gleichwertig“ Pflicht (§ 31 Abs. 6 Satz 2 VgV). Die Gründe gehören in die Dokumentation des Verfahrens (§ 8 VgV).
Achtung: Maßgeblich ist nicht nur der Wortlaut, sondern die Wirkung. Auch ein formal neutral formuliertes LV verengt den Wettbewerb, wenn die Kombination der Anforderungen faktisch nur ein Produkt zulässt (verdeckte Produktvorgabe). Die sachlichen Gründe für solche Anforderungen sollte der Auftraggeber dokumentieren.
Für IT-Ausschreibungen empfiehlt sich in der Praxis der Wechsel von produktorientierten Formulierungen hin zu offenen Standards und Protokollen. Wer statt „SAP-Schnittstelle“ eine „RFC- oder REST-basierte Anbindung an ein ERP-System“ ausschreibt, öffnet den Wettbewerb ohne Qualitätsverlust.
6 typische Fehler im IT-Leistungsverzeichnis
Die folgenden Fehler kommen in Leistungsverzeichnissen öffentlicher Auftraggeber immer wieder vor. Sie entstehen selten aus Absicht, meist aus Zeit- oder Ressourcenmangel.
Formulierungen wie „moderne IT-Lösung“, „aktueller Sicherheitsstandard“ oder „intuitive Bedienbarkeit“ sind nicht prüfbar. Bieter interpretieren sie unterschiedlich, Angebote werden unvergleichbar, die Wertung ist angreifbar.
Besser: Konkrete, messbare Anforderungen nennen: „Reaktionszeit unter 2 Sekunden bei 500 gleichzeitigen Nutzern“, „ISO 27001-zertifizierter Betrieb“.
Kein Hinweis auf Nutzerzahl, Standorte, Datenmenge oder Transaktionsvolumen. Bieter können nicht realistisch kalkulieren. Ergebnis: Entweder Risikoaufschläge oder spätere Nachträge, wenn der tatsächliche Umfang abweicht.
Besser: Auch Schätzwerte helfen. „Ca. 150 Nutzer an 3 Standorten, ca. 50.000 Datensätze zur Migration“ ermöglicht eine Kalkulation, auf die der Auftraggeber später zurückgreifen kann.
IT-Systeme funktionieren selten isoliert. Wenn unklar bleibt, welche Drittsysteme angebunden werden müssen, wer für die Schnittstelle verantwortlich ist und welches Format erwartet wird, entstehen nach Zuschlag sofort Nachfragen und Nachträge.
Besser: Für jede Schnittstelle: System, Format/Protokoll, Richtung (eingehend/ausgehend), Frequenz und Verantwortung (AN, AG oder Drittanbieter) angeben.
Wenn das LV nicht definiert, wann die Leistung als vertragsgemäß erbracht gilt, hat der Auftraggeber im Abnahmestreit keine starke Position. Abnahmen können verzögert, verweigert oder vom AN erzwungen werden.
Besser: Abnahmetest-Prozedur, Testszenarien und Abnahmekriterien bereits im LV festlegen: „Abnahme gilt als erteilt, wenn alle definierten Testszenarien ohne kritische Fehler bestanden sind.“
LVs aus früheren Vergaben werden ohne Anpassung übernommen. Veraltete technische Anforderungen, falsche Mengenangaben und nicht mehr gültige Normenreferenzen gefährden das neue Verfahren und verzerren den Wettbewerb.
Besser: Vorhandene LVs als Strukturvorlage nutzen, aber jeden inhaltlichen Abschnitt auf Aktualität prüfen. Normen, Schwellenwerte und Technologiereferenzen immer neu recherchieren.
Das LV nennt keinen Hersteller, aber die Kombination der Anforderungen (bestimmte proprietäre Dateiformate, ein konkretes Lizenzmodell, eine herstellerspezifische API) schließt faktisch alle außer einem Anbieter aus.
Besser: Anforderungen auf Interoperabilität und offene Standards prüfen. Ist ein bestimmtes Produkt sachlich erforderlich: die Gründe aus dem Auftragsgegenstand dokumentieren (§ 8 VgV) und, wo § 31 Abs. 6 VgV es verlangt, „oder gleichwertig“ ergänzen.
Positionsbasiertes LV oder funktionale Leistungsbeschreibung?
Das Leistungsverzeichnis ist eine positionsbasierte, konstruktive Form der Leistungsbeschreibung. Für viele IT-Beschaffungen ist das genau richtig: Hardware, Lizenzen, Wartungsverträge lassen sich gut in Positionen mit Mengen und Einheiten abbilden. Für komplexe Projekte mit offenem Lösungsraum (individuelle Softwareentwicklung, Digitalisierungsvorhaben, Cloud-Migrationen) kann stattdessen eine funktionale Leistungsbeschreibung geeigneter sein.
Beschreibt die Leistung in Einzelpositionen mit Menge, Einheit und konkreten technischen Anforderungen. Der Auftraggeber gibt vor, was zu liefern ist. Bieter kalkulieren Einheitspreise.
Grenze: Erfordert klaren Leistungsumfang. Schließt alternative Lösungsansätze aus.
Beschreibt Ziel und Leistungsparameter, nicht den Weg. Der Bieter entwickelt das Lösungskonzept. Zulässig nach § 31 Abs. 2 Nr. 1 VgV. Typisch bei Vorhaben mit offenem technischen Lösungsraum.
Grenze: Angebote schwerer vergleichbar, Wertung aufwändiger.
Oft bietet sich eine Kombination beider Ansätze an: Mindestanforderungen, Schnittstellen und SLA im LV konstruktiv und messbar festschreiben, die technische Umsetzung und das Lösungsdesign dem Bieter überlassen. Pflichtanforderungen (Must) klar von optionalen Anforderungen (Should/Nice-to-have) trennen und im LV kennzeichnen.
| Anforderungstyp | Beschreibungsform | Beispiel IT |
|---|---|---|
| Pflicht (Must) | Konstruktiv + messbar | „System muss LDAP/Active Directory-Anbindung unterstützen“ |
| Optional (Should) | Funktional beschrieben | „Mobile Nutzbarkeit über browserbasierte Oberfläche“ |
| Lösungsdesign | Dem Bieter überlassen | Datenbankarchitektur, Skalierungsstrategie, Deployment-Modell |
| Schnittstellen | Konstruktiv (Standard angeben) | „REST-API-Anbindung an SAP IS-U, Datenaustausch im JSON-Format“ |
Muster-LVs und Vergabe-Archiv als Ausgangsbasis
Ein IT-Leistungsverzeichnis von Grund auf neu zu erstellen kostet Zeit und setzt Fachwissen voraus, das in Vergabestellen nicht immer vorhanden ist. Zwei Produkte helfen beim Einstieg. Einen eigenen technischen Entwurf mit Excel-Preisblatt erstellt außerdem der Leistungsverzeichnis-Generator; Gewichtung und rechtliche Festlegungen bleiben darin Ihrer Vergabestelle überlassen.
LV-Vorlagen für konkrete IT-Beschaffungen: technische Mindestanforderungen und messbare Bewertungsmerkmale, Platzhalter für das Mengengerüst, herstellerneutral formuliert und an BSI IT-Grundschutz orientiert. Die Gewichtung legt Ihre Vergabestelle fest. Verfügbar zum Beispiel für Tablets, EDR/XDR, SIEM und Microsoft 365.
Muster-LVs ansehen →Wie haben vergleichbare Behörden und Kommunen ähnliche IT-Beschaffungen ausgeschrieben? Das Vergabe-Archiv enthält reale Vergabeunterlagen öffentlicher Auftraggeber. Formulierungen, Strukturen und Anforderungsprofile aus der Praxis als Orientierung für das eigene LV.
Vergabe-Archiv entdecken →Blick in eine Vorlage: die Blanko-Vorlage
Wenn noch kein passendes Themen-Muster vorliegt, liefert unsere branchenoffene Blanko-Vorlage ein Grundgerüst. Blättern Sie durch die ersten Seiten:
Vorlagen und Archiv-Dokumente sind Ausgangspunkt, kein Ersatz für die inhaltliche Auseinandersetzung mit dem eigenen Bedarf. Jede Vorlage muss auf die konkrete Beschaffung angepasst werden: Mengengerüst, Schnittstellen und Abnahmekriterien sind immer projektspezifisch. Ein ungeprüft übernommenes LV bleibt ein Fehler, auch wenn die Vorlage selbst gut ist.
Quellen
- Bundesministerium der Justiz: "§ 31 VgV: Leistungsbeschreibung", gesetze-im-internet.de, Stand 2026.
- Vergabeblog: "In der IT-Beschaffung ist ein Euro keine 50 Cent wert, 20 Fehler, Teil 1", vergabeblog.de, 2023.
- comp/lex: "Die fünf größten Fehler in IT-Leistungsbeschreibungen", comp-lex.de, 2024.
- Behörden Spiegel: "Verdeckt produktspezifische Ausschreibung unzulässig", behoerden-spiegel.de, 2025.
