Der Pflichtenheft-Fehler, der dein Projekt 30% teurer macht

Ein Pflichtenheft mit 40 Seiten wirkt vollständig - und ist es trotzdem oft nicht. Der teuerste Fehler ist selten eine fehlende Funktion, sondern eine unpräzise Formulierung einer vorhandenen. Genau diese Lücken werden später zu kostenpflichtigen Nachträgen, weil sie im Angebot nicht eingepreist waren. Was ein Pflichtenheft überhaupt von einem Lastenheft unterscheidet, erklären wir in diesem Artikel - hier geht es tiefer: um die konkreten Fehlermuster, die speziell im Pflichtenheft selbst teuer werden.

Warum unpräzise Formulierungen so teuer werden

Ein Festpreisangebot basiert auf dem, was im Dokument steht - nicht auf dem, was du dir dabei gedacht hast. Steht "Nutzer können Dateien hochladen" im Pflichtenheft, aber nicht, welche Dateiformate, welche maximale Größe oder was bei einem fehlerhaften Upload passiert, kalkuliert der Anbieter die einfachste Variante. Jede Abweichung davon wird zum Nachtrag - mit Aufpreis. Und dieser Aufpreis ist selten günstig: Ein Nachtrag mitten im laufenden Projekt kostet in der Regel mehr pro Stunde als dieselbe Arbeit, die von Anfang an eingeplant war, weil bereits gebaute Teile angepasst, erneut getestet und oft auch neu abgestimmt werden müssen.

Beispiel 1: Fehlende Fehlerfälle

"Der Nutzer meldet sich mit E-Mail und Passwort an" klingt vollständig. Was passiert bei falschem Passwort, bei einem gesperrten Account, bei vergessenem Passwort? Jeder dieser Fälle, der nicht explizit beschrieben ist, wird entweder gar nicht gebaut oder erst nachträglich beauftragt. In der Praxis bedeutet das: Eine simple Login-Maske ohne beschriebene Fehlerfälle wird oft im ersten Aufwasch mit der einfachsten Fehlermeldung ("Login fehlgeschlagen") ausgeliefert. Ein "Passwort vergessen"-Flow mit E-Mail-Versand, Token-Ablauf und erneuter Verifizierung ist dann kein kleiner Zusatz, sondern ein eigenständiges Feature mit eigenem Entwicklungs- und Testaufwand - nicht selten im Bereich von drei bis fünf zusätzlichen Personentagen, die im ursprünglichen Angebot schlicht nicht vorkamen.

Beispiel 2: Unklare Mengenangaben

"Das System soll performant sein" ist keine Anforderung, sondern eine Absichtserklärung. Ohne konkrete Angabe (z. B. "Ladezeit unter 2 Sekunden bei 500 gleichzeitigen Nutzern") lässt sich weder ein Angebot seriös kalkulieren noch später abnehmen, ob das Kriterium erfüllt ist. Das Problem zeigt sich meist erst spät: Die Software läuft im Test mit fünf Nutzern einwandfrei, und erst beim Rollout mit der echten Belegschaft wird sichtbar, dass die Architektur für die tatsächliche Last nicht ausgelegt war. Eine nachträgliche Skalierung - zusätzliche Serverkapazität, Caching, Optimierung von Datenbankabfragen - ist ungleich teurer als eine Architektur, die von Anfang an auf die richtige Nutzerzahl ausgelegt wurde.

Beispiel 3: Widersprüchliche Anforderungen an verschiedenen Stellen

In umfangreichen Dokumenten widersprechen sich Anforderungen häufig, weil sie von unterschiedlichen Personen zu unterschiedlichen Zeitpunkten geschrieben wurden. Steht an einer Stelle "jeder Nutzer sieht nur eigene Daten" und an anderer Stelle "Teamleiter sehen alle Projekte ihres Teams", ist das kein Fehler an sich - aber es muss präzisiert werden, sonst interpretiert der Anbieter es auf die für ihn einfachste Weise. In der Praxis heißt "einfachste Weise" fast immer: die restriktivere Variante, weil sie weniger Aufwand für Berechtigungslogik bedeutet. Wenn dann im laufenden Projekt klar wird, dass Teamleiter doch mehr sehen sollen als ursprünglich umgesetzt, ist das ein nachträglicher Eingriff in ein bereits bestehendes Berechtigungssystem - strukturell aufwendiger, als es von Anfang an mitzudenken.

Beispiel 4: Fehlende Abgrenzung zum Nicht-Umfang

Ein oft übersehener Punkt: Was explizit nicht Teil des Projekts ist, sollte genauso dokumentiert sein wie das, was dazugehört. Ohne diese Abgrenzung entstehen Erwartungen, die der Anbieter nie zugesagt hat - und die trotzdem als "natürlich inbegriffen" empfunden werden. Ein typisches Beispiel: Ein Pflichtenheft beschreibt einen Datenimport aus einer bestehenden Excel-Liste, ohne zu erwähnen, dass die neuen Daten auch wieder exportierbar sein müssen. Für den Auftraggeber ist ein Export "selbstverständlich dabei" - für den Anbieter ist es eine zusätzliche Anforderung, die nicht kalkuliert wurde. Solche Konflikte enden regelmäßig in Diskussionen darüber, wer im Recht ist, statt in produktiver Entwicklungsarbeit.

Beispiel 5: Fehlende Schnittstellenspezifikation

"Das System bindet die bestehende Warenwirtschaft an" sagt nichts darüber aus, über welches Protokoll (REST, SOAP, Datei-Export), in welchem Format und mit welcher Aktualisierungsfrequenz die Anbindung erfolgen soll. Schnittstellen zu Drittsystemen zählen zu den teuersten Nachträgen überhaupt, weil sie oft von der Mitwirkung eines weiteren Anbieters abhängen - und eine nachträglich verhandelte Schnittstellenspezifikation bedeutet in der Regel Wartezeit für beide Seiten, zusätzlich zum reinen Entwicklungsaufwand.

Beispiel 6: Fehlende Abnahmekriterien

Selbst ein technisch präzises Pflichtenheft hilft wenig, wenn am Ende unklar ist, wann eine Anforderung als "fertig" gilt. Ohne definierte Abnahmekriterien - etwa konkrete Testfälle oder messbare Erfolgskriterien pro Anforderung - verschiebt sich die Diskussion über Qualität vom Projektstart auf die Abnahme, den denkbar ungünstigsten Zeitpunkt dafür. Nacharbeit, die zur Abnahme "einfach noch gemacht" werden muss, wird faktisch zum unbezahlten Nachtrag für den Anbieter oder zum teuren Streitpunkt für den Auftraggeber - keine gute Ausgangslage für beide Seiten.

Checkliste: Das Pflichtenheft vor der Abgabe prüfen

Bevor ein Pflichtenheft final geht, lohnt sich ein Durchgang mit genau diesen Fragen:

Ist zu jeder Kernfunktion beschrieben, was bei einer fehlerhaften Eingabe oder einem abgebrochenen Vorgang passiert?
Enthält jede Anforderung mit Performance-, Kapazitäts- oder Mengenbezug eine konkrete Zahl statt eines Adjektivs wie "schnell" oder "performant"?
Wurden alle Anforderungen gegen alle anderen auf Widersprüche geprüft, nicht nur gegen die direkt benachbarten?
Ist explizit dokumentiert, was nicht Teil des Projekts ist?
Ist zu jeder externen Schnittstelle Protokoll, Format und Frequenz spezifiziert?
Gibt es zu jeder Anforderung ein nachvollziehbares Abnahmekriterium?

Wie du diese Fehler vor der Angebotseinholung findest

Diese Art von Lücken fällt beim eigenen Durchlesen selten auf, weil man das Dokument mit dem eigenen, impliziten Wissen liest - der Anbieter aber nicht. Eine systematische Prüfung auf fehlende Fehlerfälle, unklare Mengenangaben und Widersprüche, bevor das Dokument rausgeht, verschiebt genau diese Kosten dorthin, wo sie am billigsten zu beheben sind: aufs Papier. Das Prinzip dahinter ist dasselbe wie bei der KI-gestützten Analyse eines Lastenhefts: Vollständigkeit, Widerspruchsfreiheit und Eindeutigkeit lassen sich systematisch prüfen, statt auf ein aufmerksames Durchlesen zu hoffen.

Fazit

Die 30 % Mehrkosten entstehen selten durch eine komplett vergessene Funktion, sondern durch viele kleine Unschärfen, die sich über ein Projekt summieren. Wer sein Pflichtenheft vor der Angebotseinholung auf genau diese Muster prüft, bekommt Angebote, die tatsächlich zum späteren Ergebnis passen.

Häufig gestellte Fragen

Warum werden unpräzise Formulierungen im Pflichtenheft so teuer?

Ein Festpreisangebot basiert auf dem, was tatsächlich im Dokument steht. Fehlt eine Präzisierung, kalkuliert der Anbieter die einfachste Variante. Jede spätere Abweichung davon wird zum kostenpflichtigen Nachtrag - und Nachträge sind pro Stunde in der Regel teurer als von Anfang an eingeplante Arbeit, weil bereits gebaute Teile angepasst und erneut getestet werden müssen.

Was sind typische Lücken in einem Pflichtenheft?

Häufig sind es fehlende Fehlerfälle (z. B. was bei falscher Anmeldung passiert), unklare Mengenangaben ("performant" statt konkreter Zahlen), Widersprüche zwischen verschiedenen Abschnitten, eine fehlende Abgrenzung dessen, was nicht Teil des Projekts ist, unspezifizierte Schnittstellen zu Drittsystemen sowie fehlende Abnahmekriterien pro Anforderung.

Wie finde ich diese Fehler, bevor ich Angebote einhole?

Solche Lücken fallen beim eigenen Durchlesen oft nicht auf, weil man das Dokument mit dem eigenen impliziten Wissen liest. Eine systematische, idealerweise KI-gestützte Prüfung auf fehlende Fehlerfälle und Widersprüche deckt sie vorab auf, bevor sie zu teuren Nachträgen werden.

Wie viel teurer kann ein Projekt durch ein lückenhaftes Pflichtenheft werden?

Das lässt sich nicht pauschal beziffern, aber Erfahrungswerte aus gescheiterten oder nachverhandelten Projekten zeigen häufig Mehrkosten im Bereich von 20-30 % gegenüber dem ursprünglichen Festpreisangebot - meist durch die Summe vieler kleiner Nachträge statt durch einen einzelnen großen Fehler.