Warum durch das Bundesvergabegesetz schlechte Software-Projekte bewirkt werden?!

Das Bundesvergabegesetz wurde geschaffen, um die Qualität und Nachvollziehbarkeit bei Ausschreibungsverfahren zu verbessern. Leider führen die darin vorgegebenen Rahmenbedingungen dazu, dass in vielen Fällen solche Projektangebote den Zuschlag bekommen, die schlecht geplant und definiert sind. Teilweise wird die schlechte Planung und Durchführung sogar durch das Bundesvergabegesetz gefördert und bewirkt. Dieser Artikel stellt die Problematik aus Sicht von Software-Projekten dar.
Zitate aus dem Bundesvergabegesetz, die bei SW-Ausschreibungen praktisch immer verletzt werden:

§67 (3) Die  Ausschreibungsunterlagen sind so auszuarbeiten, dass die Vergleichbarkeit der Angebote sichergestellt ist und die Preise ohne Übernahme nicht kalkulierbarer Risiken und  – sofern nicht eine funktionale Leistungsbeschreibung gemäß § 81 Abs. 3 erfolgt – ohne umfangreiche Vorarbeiten von den Bietern ermittelt werden können.
§ 82. (1) Die Leistungen  sind bei einer konstruktiven Leistungsbeschreibung so eindeutig, vollständig und neutral zu beschreiben, dass die Vergleichbarkeit der Angebote gewährleistet ist.

Software-Projekte sind in den meisten Fällen von einer beträchtlichen Komplexität. Vielfach wissen die Auftraggeber nur grob, was sie wollen (Projektidee), sind jedoch manchmal nicht in der Lage, detaillierte Vorstellungen schriftlich zu dokumentieren und in vielen Fällen ist es dem Auftraggeber darüber hinaus nicht möglich, die Architektur und verschiedene für ein Projekt notwenige und wichtige technische Details zu definieren oder zu verstehen.

Viele SW-Entwicklungs- und Projekt-Verantwortliche begründen die gegenüber anderen Branchen doch meist recht „intuitive“ Vorgehensweise damit, dass Software eben anders sei. Das „Imaginäre“ der Software wird daher vielfach als Ausrede verwendet, um keine strukturierte Projektabwicklung betreiben zu müssen! In diesem Zusammenhang wird die (scheinbar) leichte und jederzeit mögliche Änderbarkeit der Software immer wieder betont. Dies führt dazu, dass sich die Verantwortlichen im Vorfeld weniger Gedanken über den Bedarf und die eigenen Wünsche machen („wenn wir draufkommen, dass es falsch war, ist es ja im Nachhinein leicht zu ändern“).

Dies steht jedoch meist im Widerspruch zu den bei Software-Ausschreibungen meist vom Auftraggeber geforderten Festpreisvereinbarungen und führt in Verbindung mit den meist unklar formulierten Spezifikationen des Auftraggebers dazu, dass in vielen Fällen der „schlechte“ oder unpassende Lieferant die Ausschreibung gewinnt.

Das Kernproblem erklärt nachfolgende Grafik (Unschärfe-Trichter von Böhm):

Es ist Faktum, dass der Preis bei einer ungenauen Spezifikation auch mit einer gewissen Unschärfe kalkuliert werden muss. Im Beispiel sei der erwartete Zielpreis 1Mio. EUR, der in der Anfangsphase auf Basis grober Requirements geschätzt wird und ev. beim Auftraggeber auch gleich als Projektbudget festgeschrieben wird.

Der „gute“ Lieferant wird im Falle einer Ausschreibung auf seinen kalkulierten Zielpreis einen Sicherheitsaufschlag dazugeben, da er ja damit rechnen muss, dass vom Auftraggeber entsprechend viele Change-Requests geltend gemacht werden, von denen der Auftraggeber behaupten wird, dass diese aus seiner Sicht natürlich im Preis enthalten sein müssen.
Der angebotene Preis dieses Lieferanten wird daher z.B. mit Sicherheitsaufschlag bei 1,5 Mio. Euro  liegen.

Der „schlechte“ Lieferant, wird überlegen, dass er mit einem Sicherheitsaufschlag den Auftrag auf keinen Fall bekommen wird, da er dann für den Auftraggeber zu teuer ist.
Er wird daher in diesem Fall jedenfalls einen niedrigeren Preis als den kalkulierten Zielpreis angeben und damit rechnen, dass vom Auftraggeber entsprechend viele Change-Requests geltend gemacht werden, die er dann gegen ein entsprechend hohes Zusatzentgelt verrechnen kann und sich damit dann den gewährten Preisnachlass vom Auftraggeber im Laufe des Projekts wieder zurückholt.
Der angebotene Preis dieses Lieferanten wird daher z.B. bei 700 T. Euro  liegen.

Welcher Lieferant gewinnt nun die Ausschreibung?

Natürlich der mit dem geringsten Preis, da ja beide Lieferanten den Preis auf Basis derselben (unklaren) Spezifikation abgegeben haben und damit scheinbar dieselbe Auftragsgrundlage besteht.
In der Praxis wird der Auftraggeber in diesem Fall bald merken, dass das Projekt preislich völlig aus dem Ruder läuft und im Endeffekt genau so viel oder mehr gekostet hat, wie beim guten Lieferanten, der den Zuschlag nicht bekommen hat.
Der Unterschied ist, dass der Auftraggeber nun als „Strafe“ für diese Fehlentscheidung zum erhöhten Preis auch noch mit Streitereien mit dem Lieferanten rechnen muss, unnötigen Projektstress wegen zeitlicher Fehleinschätzungen hat, sowie eventuell nachträgliche Budget-Erhöhungen gegenüber seinen Geldgebern und Entscheidungsträgern argumentieren muss. Im schlimmsten Fall kann es sogar zu einem Projektabbruch wegen dieser massiven Fehleinschätzungen kommen.

Ein weiteres Problem, das durch das Bundesvergabegesetz verursacht wird ist, dass gute und passende Bieter oft bei Ausschreibungen für Konzeptphasen oder Spezifikationserstellungen zur Vorbereitung einer Ausschreibung gar nicht mehr teilnehmen, weil sie dann bei der Umsetzung meist nicht berücksichtigt werden.
Die Bieter wollen viel lieber einen großen Umsetzungsauftrag erhalten als einen kleinen Spezifikationsauftrag. Dies führt dazu, dass die Spezifikationen ev. nicht in der erforderlichen Qualität erstellt werden oder dass die Umsetzer dann mit einem Konzept konfrontiert sind, das in der spezifizierten Form nicht sinnvoll ist und sie dann jedoch als Umsetzer für die Ergebnisse verantwortlich gemacht werden.

Es gäbe aus der neuen Erkenntnis der SW-Projekt-Methoden hier einige Möglichkeiten, um auch Software-Ausschreibungen vernünftig und qualitätsvoll abzuwickeln.
Leider wird dies jedoch durch die gegenwärtige Form des Bundesvergabegesetztes nicht ermöglicht!

http://www.software-quality-lab.com