Modern RE Keynote: Pflichtenheft oder Projektgrab? Lehren aus der Sicht eines IT-Sachverständigen

Noch schnell anmelden: Heute um 16:00, kostenloses Webinar mit Michael zu Interfaces mit SysML und Rhapsody.
Aus Scheitern können wir viel lernen. Sachverständige sind diejenigen, die sich den Scherbenhaufen anschauen und analysieren, warum Projekte aus dem Ruder laufen. Wenige wird überraschen, dass die Probleme fast immer am Anfang entstehen, bevor die eigentliche Arbeit beginnt.
Die Keynote „Pflichtenheft oder Projektgrab?“ auf der Modern RE wurde von Prof. Dr.-Ing. Stefan Wagenpfeil gehalten. Als IT-Sachverständiger analysiert er regelmäßig gescheiterte Projekte und zeigt auf, wie man schon früh erkennt, ob ein Projekt tragfähig ist oder nicht. Ein perfektes Thema für eine Keynote auf einer Konferenz zum Anforderungsmanagement.
Als IT-Sachverständige kümmern wir uns darum, bei Gerichtsverfahren, bei Streitigkeiten zur Qualitätsbegutachtung von Softwareprodukten, schlicht und ergreifend eine neutrale Instanz einzunehmen.“
Prof. Dr.-Ing. Stefan Wagenpfeil
Modern RE 2025
Die diesjährige Modern RE fand vom 17.–18. September 2025 in Leibzig statt. Die Konferenz war mit ca. 130 Teilnehmern gut besucht und deckte ein breites Spektrum an Inhalten in unterschiedlichen Formaten, von Vortrag bis Workshop, ab. Ich selbst durfte am Folgetag die zweite Keynote zu Product Velocity halten.
Warum Planung so schwer ist
Die Theorie klingt einfach: Klare Anforderungen schreiben, dann umsetzen. Doch die Praxis ist kompliziert. Anforderungen sind oft unklar, widersprüchlich und unvollständig. Dazu kommt, dass sie sich häufig im Laufe des Projekts ändern. Doch selbst sorgfältig geschriebene Anforderungen sind selten so klar, wie der Auftragsgeber es erwartet hätte. Dazu ein Beispiel aus der Keynote, das verdeutlicht, wie schwierig Planung sein kann.
Ein Unternehmen schrieb ein SAP-Projekt aus, mit über 1000 Seiten detaillierter Anforderungen. Die Angebote der Bieter lagen zwischen 13 und 43 Millionen Euro – eine Abweichung von 300 Prozent. Trotz des großen Aufwands in der Vorbereitung war die Vergleichbarkeit nicht gegeben.
Ohne Verträge geht es nicht
Verträge sind die Grundlage der Zusammenarbeit. Eigentlich sollten Verträge eine gute Zusammenarbeit ermöglichen, doch häufig sind sie die Ursache für Probleme. Wagenpfeil schildert Fälle, in denen IT-Verträge faktisch sittenwidrig waren. Viele Verträge enthalten auch bewusst Lücken oder unfaire Klauseln. Ein Problem ist, dass technische Menschen und Juristen völlig anders ticken.
Dort hat der Dienstleister den Auftraggeber, für den er programmieren sollte, dazu verpflichtet, dass bei Verzögerungen in der Entwicklung für das verlängerte Bereitstellen von Ressourcen ein Aufschlag bezahlt wird. Also ich als Dienstleister brauche zu lang und kriege dann noch mehr Geld.
Prof. Dr.-Ing. Stefan Wagenpfeil
Verträge können unterschiedlich gestaltet werden. Die wichtigsten Arten von IT-Verträgen sind:
- Werkvertrag: Lieferung eines klar beschriebenen Ergebnisses. Vorteil: klare Abnahme. Nachteil: erfordert extrem präzise Anforderungen.
- Dienstvertrag: Abrechnung nach Zeit. Vorteil: flexibel. Nachteil: kein klarer Anspruch auf Ergebnis.
- Agiler Vertrag: Jeder Sprint gilt als kleines Werk. Vorteil: passt zu agilen Methoden. Nachteil: hoher Dokumentationsaufwand, oft unklare Abnahmekriterien.
- Servicevertrag: Wartung oder Betrieb. Vorteil: klar im Support. Nachteil: Weiterentwicklungen verschwimmen schnell mit Wartung.
Beispiel: Dokumentation gegen Quellcode
Ein zweiter Fall zeigt, wie absurd die Konflikte sein können: Ein Auftraggeber verweigerte die Abnahme einer korrekt funktionierenden Software. Warum? Weil die Ursprüngliche Spezifikation von der Implementierung abwich. Konkret definierte die Spec 14 Zustände. Die Analyse des Quellcode zweigte, dass nur 8 umgesetzt wurden, weil für die Funktionalität die restlichen Zustände nicht notwendig waren.
Formell hatte der Auftraggeber recht: Das System wurde nicht wie spezifiziert implementiert. Doch das Ergebnis war absurd, insbesondere, weil der Auftraggeber auch nicht recht erklären konnte, wer genau diese 14 Zustände definiert hatte, oder aus welchem Grund.
5 Punkte, um vertragliche Konflikte frühzeitig zu vermeiden
Die folgenden Punkte sind zwar kein Allheilmittel, können aber helfen, frühzeitig vertragliche Probleme zu entschärfen. Als Nebeneffekt tragen sie grundsätzlich zu der Qualität des Ergebnisses bei. Die Punkte sind:
- Passender Vertrag: Die Vertragsart muss zum Projekt passen. Oft wird die Vertragsart ausgewählt, „weil wir es schon immer so ausgeschrieben haben“.
- Quality Gates: Regelmäßige, unabhängige Überprüfungen, um Abweichungen frühzeitig zu erkennen.
- Abnahmekriterien: Von Beginn an klare Kriterien definieren, die dokumentiert und verbindlich sind.
- Verbindlichkeit bei Deliverables: Alles ist ein Deliverable – auch Projektpläne, Tests und Verträge – und sollte entsprechend behandelt werden.
- Zeit und Geld realistisch bewerten: Fast nie gibt es beides. Entsprechend müssen Prioritäten gesetzt und Erwartungen gemanagt werden.
Qualität beginnt am Anfang. Auch wenn wir wissen, dass schnell nicht unbedingt günstig ist, bleibt die Regel: Mist rein, Mist raus.
Prof. Dr.-Ing. Stefan Wagenpfeil
Fazit
Projekte scheitern nicht am Ende, sondern am Anfang. Die Kombination aus unklaren Anforderungen, schlechten Verträgen und fehlender Qualitätssicherung führt zwangsläufig zum Streit. Zeit oder Geld sind fast immer knapp, beides gleichzeitig ist selten.
Und auch das ist eine wichtige Lehre: Wir sind keine Juristen. Verträge gehören zur Realität von Projekten, aber sie folgen einer anderen Logik. Wer das akzeptiert und trotzdem für Klarheit sorgt, hat die besten Chancen, das Projekt nicht im Pflichtenheft zu begraben, sondern erfolgreich abzuschließen.





