Warum Digitalprojekte ohne Lastenheft scheitern
Die meisten gescheiterten Digitalprojekte im Mittelstand scheitern nicht an der Technik. Sie scheitern daran, dass am Anfang niemand sauber aufgeschrieben hat, was eigentlich gebaut werden soll. Stattdessen gibt es ein zweiseitiges Briefing, ein paar E-Mails, drei Telefonate — und auf dieser Grundlage werden Angebote in fünfstelliger Höhe verglichen. Sechs Monate später streiten sich Auftraggeber und Agentur darüber, ob die Schnittstelle zur Warenwirtschaft „selbstverständlich enthalten" war oder als Nachtrag berechnet wird. Beide Seiten haben recht, weil keine Seite damals klar war.
Ein Lastenheft löst genau dieses Problem. Es ist kein Bürokratie-Akt, sondern das Dokument, das eine Investition in Software, Website, Shop, ERP oder CRM überhaupt erst kalkulierbar macht. Wer ein gutes Lastenheft hat, bekommt vergleichbare Angebote, kann Anbieter sauber bewerten und hat in der Umsetzung eine belastbare Grundlage für Abnahme und Streitfälle. Wer keines hat, kauft eine Black Box.
Dieser Pillar-Leitfaden ist die vollständige Anleitung — geschrieben aus über sechs Jahren Mandaten im B2B-Mittelstand, in denen wir bei Lastenheft-Beratung Geschäftsführer und IT-Leiter durch genau diese Phase begleitet haben. Inkl. der Stellen, an denen Lastenhefte in der Praxis regelmäßig scheitern.
Was ist ein Lastenheft? Definition nach DIN 69905
Ein Lastenheft ist das vom Auftraggeber erstellte Dokument, das alle Anforderungen an ein Projekt — funktional, nichtfunktional und organisatorisch — strukturiert beschreibt. Es beantwortet die Fragen WAS soll erreicht werden, WARUM, in welchem Rahmen, mit welchen Schnittstellen und bis wann.
Die zentrale Norm ist DIN 69905 (Projektabwicklung — Begriffe). Sie definiert das Lastenheft seit 1997 und ist nicht nur für Bauprojekte oder klassische Software relevant, sondern auch für Webprojekte, B2B-Shops, ERP-Einführungen und CRM-Migrationen. Ergänzend wirken VDI 2519 (Vorgehensweise) und ISO/IEC/IEEE 29148 (Requirements Engineering in Software-Projekten). In der Praxis genügt es, sich an DIN 69905 zu orientieren.
Lastenheft vs. Pflichtenheft — die kurze Abgrenzung
Lastenheft und Pflichtenheft sind keine Synonyme. Das Lastenheft beschreibt aus Auftraggeber-Sicht das WAS — die Anforderungen. Das Pflichtenheft beschreibt aus Auftragnehmer-Sicht das WIE — die technische Umsetzung. Reihenfolge: Lastenheft zuerst, dann Anbieter-Auswahl, dann Pflichtenheft. Ein Pflichtenheft ohne vorheriges Lastenheft ist methodisch nicht möglich — denn worauf soll es antworten?
Die vollständige Abgrenzung mit Code-Beispielen und vier Use-Cases (Webprojekt, B2B-Shop, ERP, CRM) findest du im vertiefenden Cluster-Artikel Lastenheft vs. Pflichtenheft — Unterschied erklärt.
Warum sich der Aufwand lohnt — 5 Hebel
- Vergleichbare Angebote. Ohne Lastenheft kalkuliert jeder Anbieter auf Basis seiner eigenen Interpretation. Angebote sind dadurch nicht vergleichbar — du vergleichst Äpfel mit Birnen. Mit Lastenheft bekommst du Festpreis-Angebote auf gleicher Grundlage.
- Nachträge sinken um 60 bis 80 Prozent. Was im Lastenheft steht, ist Teil des Auftrags. Was nicht drinsteht, wird teuer. Allein dieser Effekt rechtfertigt die Investition in ein sauberes Lastenheft praktisch immer.
- Interne Klarheit vor Auftragsvergabe. Der größte Mehrwert entsteht oft schon beim Schreiben — weil widersprüchliche Erwartungen aus Geschäftsführung, IT und Fachabteilung sichtbar werden, bevor sie 80.000 Euro kosten.
- Saubere Abnahme. Jede Anforderung im Lastenheft bekommt ein Akzeptanzkriterium. Beim Projektabschluss wird damit objektiv prüfbar, ob die Leistung erbracht wurde — keine endlosen Streitgespräche.
- Vertragliche Grundlage. Lastenheft und das daraus abgeleitete Pflichtenheft werden Vertragsbestandteil. Im Streitfall steht damit fest, was geschuldet war.
Die 9 Pflicht-Kapitel eines Lastenhefts
Nach DIN 69905 und gelebter Beratungspraxis besteht ein vollständiges Lastenheft aus neun Standardkapiteln. Die Reihenfolge ist nicht zufällig — sie folgt der Logik vom Allgemeinen zum Spezifischen.
- Ausgangssituation und Ist-Zustand. Welche Systeme, Prozesse und Pain Points existieren heute? Wer wirklich nur was sich ändern soll beschreibt, ohne den Ist-Zustand zu klären, bekommt Angebote, die an der Realität vorbeigehen.
- Projektziele und Erfolgskriterien. Messbar, terminiert, priorisiert. „Wir wollen einen modernen Webauftritt" ist kein Ziel. „Bis Q1/2027 eine B2B-Shop-Plattform mit 1.200 Produkten, ERP-Schnittstelle und 30 Prozent geringerer Bearbeitungszeit pro Bestellung" ist ein Ziel.
- Funktionale Anforderungen. Was muss das System können? Jede Anforderung mit eindeutiger ID (z.B. F-001), Beschreibung, Priorität (MUSS, SOLL, KANN) und Akzeptanzkriterium. Diese Struktur ist die wichtigste Disziplin im ganzen Dokument.
- Nichtfunktionale Anforderungen. Performance (Antwortzeiten, Ladezeiten), Sicherheit (DSGVO, Verschlüsselung, Auditierbarkeit), Skalierung, Verfügbarkeit, Barrierefreiheit (BFSG ab 2025). Diese Kapitel werden gern vergessen — und führen später zu den teuersten Nachträgen.
- Mengengerüst und Datenvolumen. Wie viele Nutzer, wie viele Produkte, wie viele Transaktionen pro Tag, wie viel Datenvolumen? Ein Shop für 50 Produkte und einer für 50.000 sind völlig unterschiedliche Projekte — auch wenn beide „B2B-Shop" heißen.
- Schnittstellen zu Bestandssystemen. ERP, Warenwirtschaft, CRM, PIM, Buchhaltung, Versanddienstleister, Zahlungsanbieter — mit konkreten Systemen, Versionen und Datenformaten. Schnittstellen sind in 7 von 10 B2B-Projekten der größte Kosten- und Risikoblock.
- Lieferumfang und Abgrenzung. Was ist enthalten, was explizit nicht? Schulung, Migration von Bestandsdaten, Hosting, Wartung — alles, was unklar bleibt, wird zum Streitthema.
- Termin- und Meilenstein-Plan. Realistische Meilensteine, harte Deadlines (Messe-Launch, Geschäftsjahres-Wechsel, Auslaufen einer Bestandslizenz). Pufferzeiten explizit ausweisen — Wunschtermine produzieren Nachverhandlungen.
- Akzeptanz- und Abnahmekriterien. Pro Anforderung: Wann gilt sie als erfüllt? Diese Kapitel sind die Versicherung gegen „Das war so nicht gemeint"-Diskussionen am Projektende.
Ergänzend — nicht zwingend, aber empfehlenswert — gehören in den Anhang: Glossar (Begriffsdefinitionen), Risikoeinschätzung, Vergabeprozess und Bewertungsmatrix für Anbieter sowie ein Verweis auf Vertragsmuster.
Lege die funktionalen Anforderungen als nummerierte Tabelle an, nicht als Fließtext. Spalten: ID, Anforderung, Priorität (MUSS/SOLL/KANN), Akzeptanzkriterium, Bezug zu Geschäftsprozess. Diese eine Disziplin trennt brauchbare Lastenhefte von unbrauchbaren — und macht das spätere Pflichtenheft praktisch von allein schreibbar.
Lastenheft erstellen — Schritt für Schritt
Ein gutes Lastenheft entsteht nicht am Schreibtisch in zwei Tagen. Realistisch sind 3 bis 8 Wochen, je nach Komplexität. Der Hauptaufwand liegt nicht im Schreiben, sondern in den Fach-Interviews und der internen Abstimmung. Diese sechs Schritte haben sich in unserer Beratungspraxis bewährt.
Schritt 1: Ist-Zustand dokumentieren
Bevor du beschreibst, was sich ändern soll, beschreibe, was heute ist. Mit welchen Systemen wird heute gearbeitet? Wo entstehen Medienbrüche? Welche Daten werden manuell übertragen? Diese Bestandsaufnahme ist kein Selbstzweck — sie sorgt dafür, dass das neue System in die bestehende Landschaft passt. Interview-Format: 60 bis 90 Minuten pro Fachabteilung, dokumentiert mit Screenshot-Annotationen und Prozess-Skizzen. Aus dieser Phase entsteht typischerweise auch die Liste der Schnittstellen, die später Kapitel 6 füllt.
Schritt 2: Ziele formulieren und priorisieren
Ziele sind keine Wunschliste. Sie sind eine priorisierte Hierarchie: Was ist das Hauptziel, was sind Nebenziele, was wäre nice-to-have? In der Praxis nutze ich gerne ein Verfahren namens „MoSCoW-Priorisierung" — Must-have, Should-have, Could-have, Won't-have-this-time. Damit wird der Diskussionsstoff in der Geschäftsführung sortiert, bevor er ins Lastenheft wandert.
Schritt 3: Anforderungen strukturieren
Funktionale und nichtfunktionale Anforderungen trennen. Jede Anforderung bekommt eine eindeutige ID, eine klare Beschreibung in einem Satz, eine Priorität und ein messbares Akzeptanzkriterium. Vermeiden: Anforderungen, die mit „benutzerfreundlich", „performant" oder „modern" formuliert sind. Diese Begriffe sind nicht messbar — und damit nicht abnehmefähig. Stattdessen: „Die Suche liefert Ergebnisse innerhalb von 800 Millisekunden bei einem Index von 50.000 Produkten."
Schritt 4: Mengengerüst und Schnittstellen
Dieser Schritt ist der unterschätzteste — und der teuerste, wenn er übersprungen wird. Mengengerüst: Wie viele Nutzer parallel? Wie viele Datensätze? Welche Wachstumserwartung in den nächsten 3 Jahren? Schnittstellen: Welche Drittsysteme müssen angebunden werden? Mit welchen Datenformaten, in welchen Zyklen (Echtzeit, stündlich, täglich), mit welcher Fehlerbehandlung? Hier braucht es oft ein Gespräch mit dem ERP- oder Warenwirtschafts-Anbieter, bevor das Lastenheft fertig wird.
Schritt 5: Termine und Lieferumfang festlegen
Termine sind keine Verhandlungsbasis, sondern Realität. Wenn das System zur Hausmesse im März stehen muss, ist das ein harter Termin — und der Rückwärts-Plan ergibt, wann das Lastenheft fertig sein muss, wann die Auftragsvergabe steht, wann die Entwicklung startet. Lieferumfang explizit: Was ist enthalten? Schulung? Migration? Hosting? Wartung im ersten Jahr? Die größten Streitthemen am Projektende stammen aus diesem Kapitel.
Schritt 6: Internes Review und Abnahme
Bevor das Lastenheft an Anbieter geht: einen internen Review-Workshop. Geschäftsführung, IT, Fachabteilung, gegebenenfalls Datenschutzbeauftragter und Betriebsrat. Jede Anforderung wird kurz geprüft: Stimmt sie noch? Ist sie vollständig? Aus dieser Runde entstehen typischerweise 5 bis 15 Anpassungen — und genau diese Anpassungen sind später entscheidend.
Die häufigsten Fehler im Lastenheft
Aus über 30 begleiteten Lastenheft-Projekten kommen immer dieselben Fehler. Wer sie kennt, vermeidet die meisten Schmerzen.
- Wunschliste statt Anforderungen. 80 Anforderungen, alle Priorität MUSS — und kein Budget, das das tragen würde. Ein Lastenheft muss priorisieren, sonst priorisiert es der Anbieter (und zwar nach seinen Margen).
- Keine Akzeptanzkriterien. Anforderungen ohne messbare Abnahme-Logik sind im Streitfall wertlos. „Schnelle Suche" ist keine Anforderung — „Suchergebnis in unter 800 ms bei 50.000 Produkten" schon.
- Schnittstellen oberflächlich. „Wir haben ein ERP, das soll angebunden werden" reicht nicht. Hersteller, Version, Datenformat, Schnittstellen-Typ (REST, SOAP, CSV-Export), Frequenz — alles muss rein.
- Nichtfunktionale Anforderungen vergessen. DSGVO, Barrierefreiheit (BFSG ab 2025!), Performance, Skalierung, Browser-Kompatibilität. Diese Kapitel werden gern überflogen — und sind später die teuersten Nachträge.
- Keine Glossar-Pflege. „Kunde", „Mitarbeiter", „Bestellung" bedeuten in unterschiedlichen Fachabteilungen oft verschiedene Dinge. Ohne Glossar entstehen Missverständnisse, die erst im Test auffliegen.
- Vom Anbieter schreiben lassen. Wenn der Anbieter das Lastenheft schreibt, optimiert er es auf seine Lösung. Damit verlierst du den Wettbewerb zwischen Anbietern und die Verhandlungsposition. Das Lastenheft muss vom Auftraggeber kommen — gerne mit externer Beratung, aber nicht vom späteren Umsetzer.
- Zu spät beginnen. Lastenheft erst nach der Anbieter-Auswahl zu schreiben ist methodisch falsch. Reihenfolge: Lastenheft → Ausschreibung → Anbieter-Auswahl → Pflichtenheft → Vertrag → Umsetzung.
Lastenheft-Vorlage und Tools
Eine gute Vorlage spart in der Erstellung 30 bis 50 Prozent Zeit. Wir stellen unsere Vorlage als Lead-Magnet kostenlos zur Verfügung — Word zum direkten Ausfüllen plus PDF als Preview, mit den 9 Standardkapiteln, vorformulierten Beispiel-Anforderungen für Webprojekt, B2B-Shop, ERP- und CRM-Einführung sowie einer leeren MoSCoW-Bewertungsmatrix. Details, Download-Button und Aufbau-Übersicht im Cluster-Artikel Lastenheft-Vorlage kostenlos zum Download.
An Tools für die Erstellung haben sich in der Praxis bewährt:
- Confluence oder Notion für kollaboratives Schreiben mit mehreren Fachabteilungen — inkl. Versionierung und Kommentaren.
- Word mit Formatvorlagen für das finale, versendbare Dokument. PDF-Export für die Ausschreibung.
- Excel oder Airtable für die Anforderungstabelle. Eine Anforderung pro Zeile, Spalten wie oben beschrieben. Diese Liste wird später zum Backbone des Pflichtenhefts.
- draw.io oder Lucidchart für Prozess-Diagramme im Ist-Zustand-Kapitel und für Schnittstellen-Skizzen.
Wer KI-Tools einsetzen will: ChatGPT, Claude und Copilot sind gute Sparrings-Partner, um Anforderungen umzuformulieren oder Lücken aufzudecken. Sie können aber ein Lastenheft nicht ersetzen — weil sie weder den Ist-Zustand noch die internen Konflikte kennen. Als Lektor und Strukturierer sind sie nützlich, als Autor untauglich.
Wann macht externe Lastenheft-Beratung Sinn?
Nicht jedes Projekt braucht einen externen Berater. Wer ein 20.000-Euro-Webprojekt mit klarer interner Vorstellung umsetzt, kann das Lastenheft in der Regel selbst schreiben — gegebenenfalls mit einem Review-Termin am Ende. Bei größeren Vorhaben kippt die Rechnung.
Externe Beratung lohnt sich konkret, wenn mindestens eines dieser Kriterien zutrifft:
- Projektbudget über 50.000 Euro
- Mehrere Fachabteilungen mit unterschiedlichen Interessen beteiligt
- Erstes Digitalprojekt dieser Größenordnung im Betrieb
- Schnittstellen zu mehr als zwei Bestandssystemen
- Harte Termin-Restriktion (Messe, Lizenzauslauf, Geschäftsjahr)
- Vorhandener Entwurf, der von neutraler Stelle geprüft werden soll
In der Praxis bieten wir bei ecommaze drei Pakete an: Review eines bestehenden Entwurfs (800–1.500 €), Co-Creation mit Berater und Fachabteilung (2.500–4.500 €) und Full-Service mit Fach-Interviews und vollständiger Erstellung (4.500–8.000 € für Webprojekte, 8.000–15.000 € für ERP/Shop). Details und genauer Leistungsumfang auf unserer Leistungsseite Lastenheft-Beratung.
Häufige Fragen zum Lastenheft
Was gehört in ein Lastenheft?
Neun Standardkapitel nach DIN 69905: Ausgangssituation und Ist-Zustand, Projektziele, funktionale Anforderungen, nichtfunktionale Anforderungen, Mengengerüst, Schnittstellen, Lieferumfang, Termin-Plan, Akzeptanzkriterien. Ergänzt durch Glossar, Risiken und Vergabeprozess im Anhang.
Wie lange dauert es, ein Lastenheft zu erstellen?
Realistisch zwischen 3 und 8 Wochen. Ein Webprojekt-Lastenheft ist in 3 bis 4 Wochen machbar, eine ERP-Einführung braucht 6 bis 10 Wochen. Der Hauptaufwand liegt in den Fach-Interviews und in der internen Abstimmung — nicht im Schreiben.
Was kostet ein professionell erstelltes Lastenheft?
Webprojekt: 2.500 bis 4.500 € (Co-Creation) bzw. 4.500 bis 8.000 € (Full-Service). ERP-/Shop-Vorhaben: 8.000 bis 15.000 €. Review-Paket bereits vorhandener Entwürfe: 800 bis 1.500 €. Ein gutes Lastenheft spart in der Umsetzung typischerweise 15 bis 30 Prozent der Gesamtkosten.
Wer schreibt das Lastenheft — wir selbst oder ein Berater?
Die Verantwortung liegt beim Auftraggeber. In der Praxis funktioniert hybrid am besten: Fachabteilung liefert Inhalte und Ist-Zustand, externer Berater strukturiert und hinterfragt blinde Flecken. Nie vom späteren Umsetzer schreiben lassen — das verzerrt den Wettbewerb.
Brauche ich für ein kleines Webprojekt wirklich ein Lastenheft?
Ab etwa 15.000 € Projektbudget klar ja. Darunter genügt ein strukturiertes Briefing mit 5 bis 10 Seiten. Entscheidend ist nicht die Größe, sondern: mehrere Anbieter im Vergleich, mehrere Stakeholder intern, wirtschaftliche Tragweite.
Lastenheft oder agile User Stories — was ist besser?
Beides hat Berechtigung und wird oft kombiniert. Lastenheft gibt den Rahmen vor (Was, mit welchen Schnittstellen, in welchem Termin, mit welchem Budget). User Stories steuern die Umsetzung innerhalb dieses Rahmens. Reine Agilität ohne Lastenheft funktioniert nur bei kleinen internen Vorhaben.
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Lastenheft = Was (Auftraggeber-Sicht). Pflichtenheft = Wie (Auftragnehmer-Sicht). Reihenfolge: Lastenheft → Anbieter-Auswahl → Pflichtenheft. Die ausführliche Abgrenzung steht in unserem Cluster-Artikel Lastenheft vs. Pflichtenheft.
Welche Norm definiert ein Lastenheft?
DIN 69905 (Projektabwicklung — Begriffe), ergänzend VDI 2519 und ISO/IEC/IEEE 29148 für Software-Projekte. In der Praxis genügt es, sich an DIN 69905 zu orientieren — die Norm ist auch für Webprojekte, Shop-Einführungen und CRM-Vorhaben anwendbar.
Weitere Cluster-Artikel zum Thema Lastenheft
Dieser Pillar-Leitfaden ist der Einstieg. Wer einzelne Aspekte vertiefen will:
- Lastenheft vs. Pflichtenheft — Der Unterschied einfach erklärt
- Lastenheft-Vorlage kostenlos zum Download (Word + PDF)
- Lastenheft für Website-Relaunch (folgt)
- Lastenheft für ERP- und CRM-Einführung (folgt)
Wer lieber direkt sprechen möchte, statt sich durch weitere Artikel zu lesen: ein 30-Minuten-Erstgespräch ist kostenlos und unverbindlich. Wir schauen gemeinsam auf das Vorhaben, klären, ob Review, Co-Creation oder Full-Service passt — und sagen ehrlich, falls dein Projekt unsere Beratung gar nicht braucht.