Die wahren Kosten schlechter Anforderungen

Wenn ein IT-Projekt scheitert, werden die Ursachen häufig bei der Technologie gesucht.

• Die Software war nicht ausgereift.
• Der Lieferant hat schlecht oder nicht geliefert.
• Die Architektur war für unser Problem ungeeignet.
• Die Entwickler waren überlastet.

In der Praxis sehen wir jedoch immer wieder ein anderes Muster. Die eigentlichen Probleme entstehen oft deutlich früher – lange bevor die erste Zeile Code geschrieben wird. Sie entstehen dann, wenn Projekte mit unklaren Zielen, widersprüchlichen Erwartungen und unzureichend definierten Anforderungen gestartet werden. Die Folgen sind meist erst Monate später sichtbar. Dann jedoch mit voller Wucht.

In vielen Projekten herrscht besonders am Beginn großer Zeitdruck. Endlich ist das Budget genehmigt. Das Projekt kann starten. Der Fachbereich wartet oft schon seit Monaten auf eine Lösung und drängt, verständlicherweise, auf eine schnelle Umsetzung. Dadurch ist die Versuchung groß, die Analysephase möglichst kurz zu halten. Da man schon lange über die Probleme und Wünsche an das System gesprochen hat. Genau hier entsteht häufig der erste Fehler. Ein Missverständnis in einem Anforderungsworkshop kostet wenige Minuten. Ein Missverständnis nach dem Go-Live kann Hunderttausende Euro kosten. Bereits die Software-Engineering-Pioniere Barry Boehm und Victor Basili konnten in den späten 70er Jahren nachweisen, dass Fehler, die erst in späteren Projektphasen erkannt werden, um ein Vielfaches teurer zu beheben sind als Fehler, die bereits während der Anforderungsanalyse erkannt werden. In vielen Fällen steigen die Korrekturkosten um das Zehn- bis Hundertfache. Sie bezeichneten diesen Effekt auch als „Cost Escalation Factor“. Wer an der Analyse spart, spart daher selten Geld. Er verschiebt lediglich die Kosten in eine spätere Projektphase.

Dass schlechte Anforderungen kein theoretisches Problem sind, zeigen zahlreiche Studien. Das Project Management Institute (PMI) nennt unzureichendes Requirements Management als eine der wesentlichen Ursachen dafür, dass Projekte ihre Ziele nicht erreichen. Die International Institute of Business Analysis (IIBA) und IAG Consulting kamen in ihren Untersuchungen zu dem Ergebnis, dass mangelhafte Anforderungen bei großen Projekten Mehrkosten in Millionenhöhe verursachen können. Eine Untersuchung von Bent Flyvbjerg und Alexander Budzier von der Universität Oxford auf Basis von 1.471 IT-Projekten zeigte, dass Projekte im Durchschnitt ihr Budget um 27 % überschreiten. Besonders kritisch: Rund jedes sechste Projekt entwickelte sich zu einem sogenannten „Black Swan“ und überschritt die geplanten Kosten im Mittel um 200 % bei gleichzeitigen massiven Terminverzögerungen. Die Ursachen lagen dabei selten in der Technologie selbst, sondern häufig in unklaren Zielen, unrealistischen Annahmen und mangelhafter Anforderungsdefinition.

Besonders häufig beobachten wir einen Fehler: Organisationen beschreiben sehr detailliert, welche Funktionen ein System besitzen soll. Sie beschreiben jedoch nicht, welchen Nutzen das System erzeugen soll. Dadurch entstehen Lastenhefte, die zwar gut aussehen, aber am eigentlichen Nutzungsziel vorbei gehen. Erst im Betrieb erkennen die Anwender, dass das System doch nicht für die tägliche Arbeit tauglich ist. Richtig wäre es, folgende Fragen zu stellen:

• Welches Problem wird gelöst?
• Welche Kennzahlen sollen verbessert werden?
• Woran erkennen wir den Erfolg?
• Welcher Nutzen rechtfertigt die Investition?

Werden diese Fragen nicht gestellt ist das Ergebnis häufig ein System, das alle Anforderungen erfüllt und trotzdem als Misserfolg wahrgenommen wird. Nicht weil die Software schlecht ist. Sondern weil der erwartete Nutzen nie klar definiert wurde.

Schlechte Anforderungen verursachen nicht primär deshalb hohe Kosten, weil jede Änderung später exponentiell teurer wird. Die eigentlichen Kosten entstehen durch Fehlentscheidungen, Nacharbeiten, Projektverzögerungen, falsche Beschaffungen, zusätzliche Abstimmungen und den Verlust des erwarteten Nutzens. Denn die wirklich großen Schäden entstehen selten durch die technische Fehlerbehebung, sondern durch:

• Beschaffung der falschen Lösung
• Projektverzögerungen
• Claim- und Changemanagement
• Budgetüberschreitungen
• Höhere Testaufwände
• geringe Benutzerakzeptanz und Produktivitätsverluste
• verfehlte Geschäftsziele
• zusätzliche Betriebs- und Integrationskosten
• Vertrauensverlust in Projekte und IT

Diese Kosten sind schwer messbar. Sie sind jedoch oft deutlich höher als die eigentlichen Entwicklungskosten und wirken häufig noch Jahre nach dem Go-Live nach.

Requirements Engineering wird häufig als operative Tätigkeit betrachtet. Tatsächlich handelt es sich um Risikomanagement im Sinne der getroffenen Investitionsentscheidung. Gute Anforderungen schaffen Transparenz über:

• Ziele
• Nutzen
• Umfang
• Risiken
• Prioritäten
• Qualität

Damit bilden sie die Grundlage für fundierte Entscheidungen. Je größer und komplexer ein Projekt wird, desto wichtiger wird diese Transparenz.

Die meisten IT-Projekte scheitern nicht an fehlenden Skills oder der Technologie. Sie scheitern daran, dass unterschiedliche Menschen unterschiedliche Vorstellungen davon haben, was eigentlich erreicht werden soll, oder das der Nutzen, den das zukünftige System stiften soll nicht ausreichend erhoben wurde. Genau deshalb sind Anforderungen weit mehr als Dokumentation. Sie sind die Grundlage für Investitionsentscheidungen, Ausschreibungen, Architektur, Entwicklung, Test und Betrieb. Wer auf professionelles Anforderungsmanagement verzichtet, spart nicht an Aufwand. Er geht eine Wette ein. Eine Wette darauf, dass alle Beteiligten dasselbe Verständnis vom Projekt und den Projektzielen haben. Unsere Erfahrung zeigt: Diese Wette wird erstaunlich oft verloren. Die Kosten schlechter Anforderungen entstehen dabei selten auf einen Schlag. Sie summieren sich aus Fehlentscheidungen, Nacharbeiten, Verzögerungen und verfehltem Nutzen – und übersteigen häufig die ursprünglichen Investitionen in eine professionelle Anforderungsanalyse um ein Vielfaches. Quellen und weiterführende Informationen

• Project Management Institute (PMI): Pulse of the Profession
  https://www.pmi.org/learning/thought-leadership/pulse
• Flyvbjerg, B.; Budzier, A. (2011): Why Your IT Project May Be Riskier Than You Think, Harvard Business Review
  https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think
• Boehm, B.; Basili, V. (2001): Software Defect Reduction Top 10 List, IEEE Computer
  https://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf
• Consortium for Information & Software Quality (CISQ): The Cost of Poor Software Quality in the US
  https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/
• IAG Consulting: Business Analysis Benchmark Report
  https://www.iag.biz/business-analysis-benchmark-2008/