Anforderungsanalyse: Warum das Lastenheft über Erfolg oder Scheitern entscheidet

Ein Lastenheft für ein neues ERP-System liegt seit drei Wochen beim Projektleiter. Zwölf Seiten, sauber formatiert, mit Gliederung und Anhang. Trotzdem beginnt das Kick-off-Meeting mit derselben Frage wie jedes Mal: Was genau soll das System eigentlich können? Das Dokument ist fertig. Die Anforderungsanalyse, die eigentlich dahinterstehen sollte, ist es nicht. Das ist kein Einzelfall. In den meisten gescheiterten IT-Projekten liegt der Fehler nicht bei der gewählten Software oder dem Lieferanten. Er liegt am Anfang: bei einem Lastenheft, das Antworten dokumentiert, bevor die richtigen Fragen gestellt wurden.

Warum entscheidet das Lastenheft über Erfolg oder Scheitern eines IT-Projekts?

Das Lastenheft ist die Übersetzung zwischen dem, was ein Unternehmen wirklich braucht, und dem, was ein Anbieter am Ende baut oder liefert. Jede Lücke, jede Unschärfe, jede stillschweigende Annahme in diesem Dokument wandert direkt ins Projekt. Sie taucht dort nicht sofort auf. Sie taucht auf, wenn die erste Testversion nicht das tut, was eigentlich gemeint war und eine Änderung plötzlich Wochen statt Stunden kostet.

Genau deshalb ist die Anforderungsanalyse kein bürokratischer Zwischenschritt vor dem eigentlichen Projekt. Sie ist der Teil des Projekts, der am meisten kostet, wenn man ihn überspringt.

Warum führt eine zu detaillierte technische Spezifikation zu teureren Lösungen?

Der häufigste Fehler in einem Lastenheft ist nicht zu wenig, sondern zu viel Detail an der falschen Stelle. Statt «wir brauchen ein System, das Bestellungen automatisch mit dem Lager abgleicht» steht im Dokument «wir brauchen SAP mit Modul MM». Das klingt konkreter, ist aber das Gegenteil von hilfreich: Es schreibt die Lösung fest, bevor jemand geprüft hat, ob es nicht auch eine passendere, günstigere oder schnellere Variante gibt.

Eine funktionale Anforderung beschreibt das gewünschte Ergebnis. Eine technische Anforderung beschreibt den Weg dorthin. Beide haben ihren Platz, aber die Reihenfolge ist entscheidend. Wer zuerst die Lösung nennt und erst danach über das Ziel nachdenkt, hat sich selbst die Möglichkeit genommen, die bessere oder billigere Option überhaupt zu sehen.

Welche Fehler passieren am häufigsten bei der Anforderungsanalyse?

Drei Muster wiederholen sich in fast jedem Projekt, das später über den Zeit- oder Kostenrahmen läuft. Erstens: Nur eine Abteilung wird befragt, meistens die, die das Projekt angestossen hat. Was die anderen Teams tatsächlich brauchen, kommt erst während der Umsetzung ans Licht, wenn Änderungen bereits teuer sind. Zweitens: Muss- und Kann-Anforderungen werden nicht getrennt. Am Ende gilt jede Anforderung als kritisch und der Anbieter kann nicht mehr sinnvoll priorisieren oder kalkulieren. Drittens: Bestehende Abläufe werden eins zu eins ins neue System übertragen, statt zu fragen, ob dieser Ablauf überhaupt noch der richtige ist.

Keines dieser drei Muster ist böswillig. Sie entstehen aus Zeitdruck und aus dem verständlichen Wunsch, schnell ins nächste Kapitel des Projekts zu kommen. Genau das macht sie so hartnäckig.

Wer sollte die Anforderungsanalyse eigentlich durchführen?

Die Fachabteilung kennt das Tagesgeschäft am besten. Sie weiss selten, was technisch sinnvoll oder überhaupt möglich ist und das ist auch nicht ihre Aufgabe. Der Anbieter kennt die technischen Möglichkeiten. Er kennt aber nicht das Tagesgeschäft des Kunden und wird, wenn er allein am Lastenheft schreibt, zwangsläufig in Richtung seiner eigenen Lösung denken.

Die Anforderungsanalyse gehört deshalb weder ausschliesslich der Fachabteilung noch ausschliesslich dem Anbieter. Sie funktioniert am besten als Dialog: eine unabhängige Instanz moderiert, stellt die unbequemen Rückfragen und übersetzt zwischen Geschäftsbedürfnis und technischer Machbarkeit, bevor überhaupt ein Anbieter mit einer konkreten Lösung antritt.

Fazit

Ein gutes Lastenheft ist kein dickes Dokument. Es ist ein Dokument, das die richtigen Fragen schon beantwortet hat, bevor der erste Anbieter es liest: Was soll die Lösung können, was nicht und warum. Wer diese Arbeit vor dem Projekt investiert, zahlt sie nicht ein zweites Mal während der Umsetzung.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer funktionalen und einer technischen Anforderung?

Eine funktionale Anforderung beschreibt, was ein System leisten soll, zum Beispiel «Bestellungen automatisch mit dem Lagerbestand abgleichen». Eine technische Anforderung legt fest, wie das umgesetzt wird, zum Beispiel mit welcher Software oder Schnittstelle. Funktionale Anforderungen gehören ins Lastenheft, technische Festlegungen sollten so lange wie möglich offenbleiben.

Welche Fehler passieren am häufigsten bei der Anforderungsanalyse?

Am häufigsten: Nur eine Abteilung wird befragt, Muss- und Kann-Anforderungen werden nicht getrennt und bestehende Abläufe werden unreflektiert ins neue System übernommen.

Wie lange sollte eine Anforderungsanalyse dauern?

Das hängt vom Umfang des Projekts ab, nicht von einer festen Formel. Entscheidend ist nicht die Dauer, sondern ob alle relevanten Stakeholder tatsächlich einbezogen wurden, ein zu kurzer Prozess spart selten Zeit, er verschiebt sie nur ins laufende Projekt.

Wer sollte die Anforderungsanalyse leiten, die Fachabteilung oder der IT-Anbieter?

Am besten eine unabhängige Instanz, die zwischen beiden vermittelt. Die Fachabteilung kennt das Geschäft, der Anbieter die Technik, eine neutrale Moderation verhindert, dass die Anforderungen zu früh in Richtung einer bestimmten Lösung gebogen werden.