Lastenheft für Softwareprojekte: Was wirklich hineingehört — und was Zeitverschwendung ist

Wer zum ersten Mal Software vergibt, stößt schnell auf den Rat, ein Lastenheft zu schreiben. Was dann oft entsteht, ist ein Dokument von achtzig Seiten, das Monate gekostet hat, jede Bildschirmmaske vorwegnimmt — und zu Angeboten führt, die um den Faktor drei auseinanderliegen.

Wir lesen solche Dokumente regelmäßig und schreiben Angebote darauf. Dieser Artikel beschreibt aus dieser Perspektive, was ein Lastenheft leisten muss, was hineingehört, was getrost weggelassen werden kann — und woran man merkt, dass man gerade das falsche Dokument schreibt.

Lastenheft und Pflichtenheft — der Unterschied in einem Satz

Die beiden Begriffe werden ständig verwechselt, dabei ist die Trennung einfach:

	Lastenheft	Pflichtenheft
Schreibt	Der Auftraggeber	Der Auftragnehmer
Beantwortet	Was soll erreicht werden?	Wie wird es umgesetzt?
Sprache	Fachlich, ohne Technik	Technisch, konkret
Zeitpunkt	Vor der Vergabe	Nach der Beauftragung
Zweck	Vergleichbare Angebote bekommen	Verbindlich festhalten, was gebaut wird

Kurz: Das Lastenheft beschreibt das Problem, das Pflichtenheft die Lösung. Wenn in eurem Lastenheft steht, welche Datenbank verwendet werden soll, habt ihr die Grenze überschritten — und damit einen der wenigen Bereiche vorweggenommen, in dem der Dienstleister tatsächlich Wert beisteuern könnte.

Was eine Agentur wirklich braucht

Um seriös kalkulieren zu können, brauchen wir Antworten auf sechs Fragen. Alles andere ist angenehm zu haben, aber nicht entscheidend.

Frage 4 ist die, an der Kalkulationen am häufigsten scheitern. „Anbindung an unser ERP“ kann zwei Tage bedeuten oder zwei Monate — je nachdem, ob es eine dokumentierte Schnittstelle gibt, ob jemand im Haus sie kennt und ob der ERP-Anbieter kooperiert. Wer diese Frage im Lastenheft offen lässt, bekommt entweder einen dicken Risikoaufschlag oder einen Streit im Projekt.

Frage 5 ist die, die am häufigsten fehlt und am meisten bringt. Ein Ziel wie „die Angebotserstellung dauert statt drei Tagen einen halben“ verändert die gesamte Diskussion. Ohne so einen Satz wird über Funktionen gestritten statt über Wirkung.

Eine Gliederung, die man in zwei Tagen füllen kann

Kein Wasserfall-Ungetüm, sondern das Minimum, das ein gutes Angebot ermöglicht:

1. Ausgangslage
   1.1 Was machen wir heute, womit, und was daran stört
   1.2 Wer ist betroffen (Rollen, Anzahl)
   1.3 Warum jetzt

2. Ziel
   2.1 Was soll in einem Jahr anders sein
   2.2 Woran messen wir das (2-3 Kennzahlen)
   2.3 Was ist ausdrücklich NICHT Ziel

3. Fachliche Anforderungen
   3.1 Die 5-10 wichtigsten Abläufe, je als Erzählung
       ("Eine Sachbearbeiterin bekommt eine Anfrage per Mail und ...")
   3.2 Was passiert im Fehlerfall / bei Ausnahmen
   3.3 Nice-to-have, klar als solches markiert

4. Daten und Systeme
   4.1 Welche Daten, Größenordnung, Herkunft, Qualität
   4.2 Bestehende Systeme und deren Schnittstellen
   4.3 Was migriert werden muss

5. Rahmen
   5.1 Budgetrahmen (ja, wirklich)
   5.2 Termine und deren Begründung
   5.3 Rechtliches: DSGVO, Branchenvorgaben, Barrierefreiheit
   5.4 Betrieb: wer betreibt das später, mit welchen Kenntnissen

6. Zusammenarbeit
   6.1 Wer entscheidet auf eurer Seite
   6.2 Wer steht fachlich zur Verfügung, wie viel
   6.3 Wie stellt ihr euch die Abstimmung vor

Punkt 3.1 ist das Herzstück. Schreibt Abläufe als Erzählung, nicht als Anforderungsliste. „Das System muss Anfragen verwalten können“ ist unkalkulierbar. Eine halbe Seite darüber, was zwischen dem Eingang einer Anfrage und ihrer Erledigung passiert, wer beteiligt ist und was schiefgehen kann, ist Gold wert.

Was ihr weglassen könnt

Aus vielen gelesenen Lastenheften: Diese Abschnitte kosten euch Zeit und bringen selten etwas.

• Bildschirmentwürfe. Wenn ihr sie vorgebt, bekommt ihr sie gebaut — auch wenn sie nicht die beste Lösung sind. Beschreibt lieber die Aufgabe, die auf dem Bildschirm erledigt werden soll.
• Technologievorgaben ohne Grund. „Muss in Java entwickelt werden“ ist eine sinnvolle Vorgabe, wenn eure IT nur Java betreibt. Ohne diesen Grund verkleinert es nur euren Anbieterkreis.
• Vollständige Feldlisten. Dreißig Seiten Datenfelder werden im Projekt ohnehin überarbeitet. Die Struktur reicht, die Details entstehen unterwegs.
• Formalismen aus Vorlagen. Abschnitte wie „Abkürzungsverzeichnis“ oder „Referenzierte Dokumente“, die dann leer bleiben, machen das Dokument nur schwerer lesbar.

Ein gutes Lastenheft für ein mittleres Projekt hat zwischen zehn und dreißig Seiten. Wird es länger, beschreibt es meistens Lösungen statt Probleme — und schließt damit genau die Vorschläge aus, für die man einen Dienstleister eigentlich beauftragt.

Der Budgetrahmen gehört hinein

Der häufigste Einwand: „Wenn wir eine Zahl nennen, schöpfen sie sie aus.“ Verständlich, aber in der Praxis richtet das Verschweigen mehr Schaden an.

Ohne Rahmen bekommt ihr Angebote, die alles enthalten, was jemand sich vorstellen kann — und liegt dann dreifach über eurem Budget. Danach beginnt eine Kürzungsrunde, in der auf beiden Seiten Zeit verbrannt wird. Mit einem Rahmen bekommt ihr Vorschläge, die zu diesem Rahmen passen, und könnt vergleichen, wer daraus am meisten macht.

Ein Korridor genügt: „Wir haben für die erste Ausbaustufe 60.000 bis 90.000 Euro vorgesehen.“ Das ist keine Preisverhandlung, sondern eine Information darüber, welche Größenordnung von Lösung überhaupt zur Debatte steht.

Wann ein Lastenheft die falsche Antwort ist

Es gibt Situationen, in denen der ganze Aufwand nicht lohnt:

Situation	Besser als Lastenheft
Ihr wisst nicht genau, was ihr braucht	Bezahlte Analysephase mit einem Dienstleister, 1–3 Wochen
Das Vorhaben ist klein (< 25.000 €)	Zweiseitiges Briefing plus ein Gespräch
Das Produkt soll am Markt getestet werden	Zielbeschreibung plus MVP-Umfang, Rest offen lassen
Ihr habt bereits einen Dienstleister	Direkt gemeinsam ein Pflichtenheft erarbeiten
Öffentliche Ausschreibung	Lastenheft ist Pflicht — dann aber mit Fachjurist

Die erste Zeile beschreibt den mit Abstand häufigsten Fall. Wer ein Lastenheft schreibt, um herauszufinden, was er will, schreibt monatelang und produziert am Ende Vermutungen. Eine bezahlte Analysephase kostet ein bis drei Wochen, liefert ein belastbares Dokument — und ihr habt dabei gleich gesehen, wie es sich anfühlt, mit diesem Dienstleister zu arbeiten.

Wie ihr die Angebote vergleicht

Wenn die Angebote da sind, sagt der Preis am wenigsten. Achtet stattdessen auf:

• Rückfragen. Wer ohne eine einzige Rückfrage anbietet, hat entweder nicht gelesen oder kalkuliert Risiko in den Preis. Gute Anbieter fragen unbequeme Dinge.
• Widerspruch. Wenn jemand einen eurer Punkte begründet in Frage stellt, ist das ein sehr gutes Zeichen. Zustimmung zu allem ist ein sehr schlechtes.
• Umgang mit Unsicherheit. Benennt das Angebot offene Punkte und wie damit umgegangen wird? Oder tut es so, als wäre alles klar?
• Was nach dem Launch passiert. Betrieb, Wartung, Weiterentwicklung, Übergabe. Ein Angebot, das am Go-live endet, beschreibt nur die Hälfte der Kosten.

Fazit

Ein Lastenheft ist kein Selbstzweck und kein Formalismus. Sein einziger Zweck ist, vergleichbare und belastbare Angebote zu bekommen. Alles, was diesem Zweck dient, gehört hinein; alles andere kostet nur Zeit.

Die drei Dinge, die den größten Unterschied machen, sind unspektakulär: eine ehrliche Beschreibung des heutigen Zustands, fünf bis zehn Abläufe als Erzählung statt als Anforderungsliste, und ein genannter Budgetrahmen. Wer nur diese drei sauber liefert, bekommt bessere Angebote als mit achtzig Seiten Formalismus.

Und wenn sich beim Schreiben herausstellt, dass ihr die Fragen selbst nicht beantworten könnt: Das ist kein Scheitern, sondern das eigentliche Ergebnis. Dann ist eine gemeinsame Analysephase der schnellere Weg als ein weiterer Monat am Dokument.