Softwareprojekt starten: Pflichtenheft oder Product Discovery?
Das 80-Seiten-Pflichtenheft fühlt sich sicher an und ist oft der teuerste Fehler. Wie ein Softwareprojekt richtig startet — mit der riskantesten Annahme zuerst, nicht der dicksten Spezifikation.
Der häufigste Projektstart im Mittelstand sieht so aus: Jemand schreibt monatelang ein Pflichtenheft, holt drei Angebote ein, vergibt an das günstigste — und merkt nach einem halben Jahr, dass das Dokument das falsche Problem exakt beschrieben hat.
Das Pflichtenheft fühlt sich sicher an, weil es dick ist. Aber Umfang ist nicht Sicherheit. Die eigentliche Frage am Projektstart ist nicht „haben wir alles aufgeschrieben", sondern „wissen wir, was wirklich riskant ist".
Warum das große Pflichtenheft scheitert
Ein 80-Seiten-Pflichtenheft setzt voraus, dass man am Anfang am meisten weiß — also genau dann, wenn man am wenigsten weiß. Es friert Annahmen ein, bevor irgendeine davon geprüft wurde. Jede spätere Erkenntnis wird zur „Change Request" statt zur normalen Verbesserung.
Der Accelerate State of DevOps Report 2024 von DORA zeigt das Muster: große, seltene, spät getestete Festlegungen sind instabiler und langsamer als kleine, häufige, früh geprüfte. Das gilt für Code — und für Anforderungen genauso.
Product Discovery ist kein Gegenteil von Planung
Discovery wird oft missverstanden als „wir planen nicht, wir probieren rum". Das Gegenteil stimmt: Discovery ist disziplinierte Planung, die zuerst die riskanteste Annahme angreift statt der bequemsten.
Eine Annahme ist riskant, wenn das Projekt scheitert, falls sie falsch ist — und wenn niemand sicher weiß, ob sie stimmt. Genau dort beginnt ein gutes Projekt, nicht beim Login-Formular.
Vier Fragen, die ein Projekt richtig starten
1. Was ist die riskanteste Annahme?
Nicht „was bauen wir zuerst", sondern „was muss wahr sein, damit das Ganze überhaupt Sinn ergibt". Diese Annahme zuerst prüfen — bevor Budget gebunden ist.
2. Was ist der kleinste nützliche erste Schnitt?
Nicht das gesamte System, sondern der eine Prozess, der früh echten Nutzen liefert und die riskante Annahme testet. Alles andere wird bewusst nach hinten gelegt — schriftlich.
3. Woran erkennen wir Erfolg — vorab?
Ein Projekt ohne vorab definierte, messbare Zielgröße ist ein teures Bauchgefühl. „Soll besser werden" ist kein Ziel. „Durchlaufzeit von 5 Tagen auf unter 1 Tag" ist eins.
4. Was ist bewusst nicht im ersten Schnitt?
Der wertvollste Satz im Projektstart lautet „das machen wir absichtlich noch nicht". Wer das nicht aufschreibt, baut implizit alles — und liefert nichts früh.
Pflichtenheft ist nicht tot — es ist nur nicht der Start
Es gibt Kontexte, in denen ein formales Lastenheft sinnvoll ist: regulierte Beschaffung, Ausschreibungen, Festpreis auf scharf abgegrenztem Umfang. Aber selbst dann gilt: Erst Discovery, dann Spezifikation. Ein Pflichtenheft, das nach einer kurzen Discovery entsteht, beschreibt das richtige Problem. Eines davor beschreibt eine Vermutung.
Schätzungen ehrlich lesen
Eine seriöse Schätzung am Projektstart ist eine Spanne mit benannten Unsicherheiten, kein Punkt. Wer eine exakte Zahl auf ein vages Pflichtenheft gibt, hat entweder Puffer versteckt oder das Risiko nicht verstanden (siehe Was kostet individuelle Softwareentwicklung?). Und ob ein Projekt überhaupt Eigenentwicklung braucht, gehört vor jeden Projektstart (siehe Custom oder Standard?).
Checkliste für den Projektstart
- Kennen wir die riskanteste Annahme — und prüfen wir sie zuerst?
- Gibt es einen kleinsten nützlichen Schnitt statt „das ganze System"?
- Ist die Zielgröße vorab und messbar definiert?
- Ist schriftlich, was bewusst nicht im ersten Schnitt ist?
- Entsteht eine etwaige Spezifikation nach, nicht vor Discovery?
- Ist die Schätzung eine Spanne mit Unsicherheiten, kein Punkt?
- Ist geklärt, ob es überhaupt Eigenentwicklung braucht?
Häufige Fragen
Brauchen wir gar kein Pflichtenheft mehr? Doch — oft. Aber als Ergebnis einer kurzen Discovery, nicht als deren Ersatz. Erst das Risiko verstehen, dann sauber spezifizieren.
Ist Discovery nicht nur verzögerter Projektstart? Nein. Eine Discovery dauert Tage bis wenige Wochen und verhindert Monate falscher Entwicklung. Sie ist der Projektstart.
Was, wenn der Auftraggeber ein fertiges Pflichtenheft verlangt? Dann ist die erste Leistung, es gemeinsam gegen die riskanteste Annahme zu prüfen. Ein guter Partner liefert nicht blind, was im Dokument steht.
Wie groß ist eine sinnvolle Discovery? Klein. Ziel, riskanteste Annahme, erster Schnitt, Erfolgskriterium — auf wenigen Seiten, in Tagen, nicht Quartalen.
Fazit
Ein Softwareprojekt startet nicht mit dem dicksten Dokument, sondern mit der ehrlichsten Frage: Was muss wahr sein, damit das hier funktioniert — und wissen wir das schon? Wer die riskanteste Annahme zuerst prüft, klein schneidet und Erfolg vorab definiert, startet sicher. Wer mit 80 Seiten startet, beschreibt oft das falsche Problem perfekt.
Weiterlesen
- Individuelle Softwareentwicklung: Custom oder Standard? — die Frage vor jedem Projektstart.
- KI & Automatisierung im Mittelstand: der 90-Tage-Pilot — Risiko zuerst prüfen, in der Praxis.
Nächster Schritt
Sie wollen ein Softwareprojekt starten, ohne Monate ins falsche Dokument zu investieren? Beginnen Sie mit einer kurzen Einschätzung Ihrer Anforderungen. Wir benennen die riskanteste Annahme und schneiden einen ersten, prüfbaren Schritt.
Quellen
- DORA, Accelerate State of DevOps Report 2024 — dora.dev
- Atlassian, Agiles Projektmanagement — atlassian.com
- Thoughtworks, Technology Radar — thoughtworks.com