Softwareentwicklung für öffentliche Auftraggeber – eine Buchzusammenfassung

Theoretische Grundlagen von Software­entwicklungs­methoden und Vergaberecht

Im ersten Abschnitt des Buches werden phasenorientierte Methoden wie zum Beispiel das Wasserfallmodell sowie agile Methoden wie Scrum dargestellt. Der Schwerpunkt liegt dabei auf den agilen Methoden und Prinzipien.

Neben den Softwareentwicklungsmethoden werden auch die Grundlagen der Projektvergabe öffentlicher Auftraggeber dargestellt. Öffentliche Auftraggeber sind verpflichtet, das Vergaberecht zu beachten, das grundsätzlich eine öffentliche oder zumindest wettbewerbliche Ausschreibung von Aufträgen vorschreibt. Sie müssen Haushaltsmittel zudem wirtschaftlich und sparsam verwenden. Für die Vergabe gibt der Gesetzgeber in der Verordnung über die Vergabe öffentlicher Aufträge VgV (§14 Abs. 1) sowie in der Unterschwellenvergabeordnung UVgO (§9) verschiedene Verfahren vor. Diese unterscheiden sich im Bezug auf den Teilnehmerkreis sowie auf die Möglichkeit, während des Vergabeverfahrens beziehungsweise während der Projektlaufzeit über die konkrete Ausgestaltung der Auftragsinhalte zu verhandeln.

Ob die VgV oder die UVgO zu beachten sind, hängt vom Auftragswert ab. Überschreitet dieser einen Schwellenwert von 140.000 € bei obersten und oberen Bundesbehörden oder 215.000 € bei sonstigen öffentlichen Auftraggebern, sind die Aufträge gemäß VgV und damit EU-weit auszuschreiben (die Werte sind die 2022/2023 gültigen; im Buch sind noch alte Werte genannt). Der Auftragswert ist dabei ohne Umsatzsteuer, aber inklusive aller Folgeaufträge und Erweiterungen zu berechnen (UfAB S. 61). Viele agile Softwareprojekte werden über ihre Laufzeit gesehen im oberschwelligen Bereich liegen, weshalb das Buch den unterschwelligen Bereich ausklammert.

Generell sind öffentliche Auftraggeber gehalten, zwischen dem offenen und dem nicht-offenen Verfahren zu wählen, es sei denn, es stehen aufgrund der in §14 Abs. 3 oder 4 VgV genannten Gründe andere Verfahren wie das Verhandlungsverfahren, der wettbewerbliche Dialog oder die Innovationspartnerschaft offen.

Im letzten Abschnitt des Grundlagenteils werden die Rechtsvorschriften zur Preisgestaltung, insbesondere die Verordnung PR Nr. 30/53, dargestellt. Gemäß dieser Verordnung muss der Auftraggeber Marktpreisen den Vorzug vor Selbstkostenpreisen geben, feste Preise genießen Vorrang vor veränderlichen Preisen und es gilt das Höchstpreisprinzip: Die gemäß der Verordnung festgelegten Preise dürfen von keiner Partei überschritten, wohl aber unterschritten werden.

Möglichkeiten der Preisgestaltung agiler Entwicklungsprojekte

Im nächsten Kapitel werden Story Points als verbreitete Schätzmethode für agile Entwicklungsprojekte kurz umrissen. Es folgt eine vertragstypologische Einordnung von Softwareprojekten und eine Gegenüberstellung wesentlicher Eigenschaften von Werkvertrag und Dienstvertrag. Der Autor weist aber darauf hin, dass sich agile Softwareaufträge häufig nicht eindeutig zu einem der beiden Vertragstypen zuordnen lassen.

In den folgenden Abschnitten werden verschiedene mögliche Vergütungsarten für agile Entwicklungsprojekte ausführlich beschrieben.

• Der reguläre Festpreis ist das klassische Preismodell, lässt sich aber schwer mit agiler Entwicklung vereinbaren, da er strikte Planeinhaltung fordert. Auftraggeber, die ein Festpreisprojekt vergeben wollen, sollten die Kosten für Change Requests von vorne herein mit berücksichtigen.

• Der Aufwandspreis vermeidet die Probleme des Festpreises, verlagert aber das Risiko stark in Richtung Auftraggeber. Ein Aufwandspreis mit Obergrenze wiederum erlegt dem Auftragnehmer das Risiko bezüglich der Überschreitung des geplanten Aufwands auf, ohne ihn für eine Unterschreitung des Aufwands zu belohnen. Aufwandspreise setzen zudem keinen wirtschaftlichen Anreiz für möglichst gute Ergebnisse, sondern eher zur Produktion möglichst vieler Stunden.

• Eine nutzenabhängige Abrechnung ("Pay per use") setzt Anreize für die Entwicklung erfolgreicher Lösungen, aber der Auftragnehmer übernimmt ein erhebliches Risiko, da er bei geringem Nutzen eventuell keine kostendeckende Vergütung erhält. Allerdings sind auch Mischformen möglich wie zum Beispiel eine kostendeckende Basisvergütung und eine nutzenabhängige Erfolgskomponente.

• Schließlich wird der agile Festpreis dargestellt. In diesem Modell ist der Gesamtpreis fest und wird für einen bestimmten, in Story Points bemessenen Auftragsumfang vereinbart. Welche Funktionalität am Ende tatsächlich entwickelt wird, ist nicht von vorne herein festgelegt sondern kann im Projektverlauf verändert werden. Als Variante des agilen Festpreises wird ein Festpreis pro Iteration beschrieben.

Nach den Preismodellen geht der Autor auf weitere Möglichkeiten der agilen Vertragsgestaltung ein: die Option des Projektabbruchs und den Risk-Share-Ansatz.

Wenn beiden Vertragspartnern die Möglichkeit offensteht, das Projekt abzubrechen, ist dies ein starker Anreiz für eine gute Kooperation, sowohl für den öffentlichen Auftraggeber als auch für den Auftragnehmer.

Der Risk-Share-Ansatz sieht vor, dass Kostenüberschreitungen vom Auftragnehmer und Auftraggeber gemeinsam getragen werden. Der Auftragnehmer erhält somit auch für den erhöhten Aufwand eine Vergütung, aber da diese nur anteilig erfolgt (in Höhe des vom Auftraggeber übernommenen Risikoanteils) hat er keinen Anreiz, möglichst viele Stunden zu produzieren.

Abschließend werden die verschiedenen Ansätze vergleichend gewürdigt. Der agile Festpreis wird als das am besten zur agilen Softwareentwicklung passende Modell bezeichnet, wobei in Einzelfällen auch andere Preistypen oder eine Kombination davon sinnvoll sein können.

Deckung der Anforderungen öffentlicher Auftraggeber

In diesem Kapitel werden die zuvor beschriebenen Preis- und Vertragsmodelle mit den Anforderungen an die öffentliche Vergabe abgeglichen.

Zunächst erfolgt eine Analyse aus Sicht des Haushaltsrechts: Das Haushaltsrecht schreibt dem öffentlichen Auftraggeber die Beachtung des Wirtschaftlichkeitsprinzips vor. Ein gegebenes Ziel soll demnach mit möglichst geringem Mitteleinsatz erreicht werden (Minimalprinzip), umgekehrt soll mit den zur Verfügung gestellten Mitteln das bestmögliche Ergebnis erreicht werden (Maximalprinzip).

Es folgt eine aus meiner Sicht spannende Argumentation: Agile Methoden haben in den vergangenen Jahren ihre Vorteilhaftigkeit gegenüber herkömmlichen plangetriebenen Methoden unter Beweis gestellt (Orłowski et al. 2017, S. 525 f.), es würde dem Wirtschaftlichkeitsprinzip also widersprechen, ein anderes als das agile Vorgehen zu wählen. Allerdings ist einer der Grundsätze aus dem agilen Manifest, dass es Reaktion auf Veränderung für wichtiger hält als das Befolgen eines Plans. Ein starrer, vor Projektbeginn festgelegter Plan widerspricht also dem agilen Vorgehen. Damit kann das Minimalprinzip, das ein starres Ziel voraussetzt, nicht zur Anwendung kommen.

Besser passend ist das Maximalprinzip, das für einen gegebenen Mitteileinsatz den größtmöglichen Erfolg anstrebt. Allerdings gibt es keine Garantie dafür, dass die gegebenen Mittel zur Erreichung der Minimalanforderungen an die Software reichen werden; es kann vielmehr sein, dass mehr Mittel als ursprünglich geplant benötigt werden. Damit scheidet auch das Maximalprinzip aus, da es einen konstanten Mitteleinsatz vorsieht.

Der agile Festpreis scheint ein guter und dem allgemeinen Gebot der Wirtschaftlichkeit entsprechender Kompromiss zu sein. Das Buch verweist hier auf die Unterlage für die Ausschreibung und Bewertung von IT-Leistungen UfAB des Bundes, die zum Zeitpunkt der Erscheinung des Buches einen festen Preis mit variablem Leistungsumfang noch nicht vorsah. Inzwischen wurde die UfAB aber überarbeitet und beschreibt den agilen Festpreis verbunden mit einem Risk-Sharing-Ansatz ausdrücklich als in Betracht kommende Option (S. 88 UfAB 2018).

Abschließend weist der Autor noch darauf hin, dass nutzenbasierte Abrechnungen weder mit dem Maximal- noch mit dem Minimalprinzip vereinbar sind.

Es folgt eine Analyse aus Sicht des Vergaberechts. Sowohl das offene als auch das nicht-offene Verfahren, die beide eine vollständige Spezifikation vor der Vergabe vorsehen, sind mit einem agilen Vorgehen nur sehr begrenzt vereinbar. Insbesondere würde auf den wesentlichen Vorteil der agilen Vorgehensweisen, die intensive Kommunikation zwischen Auftraggeber und Auftragnehmer bei der Erarbeitung der konkreten Lösung, verzichtet.

Für agile Projekte geeignet sind hingegen das Verhandlungsverfahren sowie der wettbewerbliche Dialog. Der wesentliche Unterschied zwischen diesen beiden Verfahren liegt darin, dass im Verhandlungsverfahren der Auftraggeber in der Lage sein muss, die technischen Mittel anzugeben, mit denen die Projektziele erfüllt werden können. Im wettbewerblichen Dialog hingegen ist nur das Ziel vorgegeben, die technischen Mittel werden von den potenziellen Auftragnehmern (Bietern) vorgeschlagen. Mit diesen Verfahren sind auch sämtliche agilen Vergütungsmodelle vereinbar und können noch im Laufe des Vergabeverfahrens während der Verhandlungen zwischen Auftraggeber und Bieter festgelegt werden.

Auch die oben bereits erwähnte UfAB befasst sich inzwischen mit agilen Methoden und betont: "Als Vergabeverfahrensart wird das Verhandlungsverfahren / die Verhandlungsvergabe mit Teilnahmewettbewerb bei agilen Vorgehensmodellen regelmäßig zulässig, aber tatsächlich geboten sein, um vor Vertragsschluss mit den Bietern insbesondere über die Einzelheiten des Vorgehensmodells und die vertragliche Ausgestaltung verhandeln zu können" (S. 87 UfAB 2018). An anderer Stelle in der UfAB (S. 121 ff.) wird auch der wettbewerbliche Dialog als adäquates Verfahren beschreiben, wenn die Mittel zur Zielerreichung nicht vorab spezifiziert werden können.

Die Innovationspartnerschaft wiederum passt zwar vom Namen her sehr gut zur Natur von Softwareprojekten, sieht aber die Trennung in Forschung-/Entwicklungsphase und anschließende Produktionsphase eines innovativen Produkts vor. Da es in der Softwareentwicklung keine von der Entwicklung getrennte Produktionsphase gibt, hat die Innovationspartnerschaft keinen Mehrwert gegenüber dem wettbewerblichen Dialog (und ist ihm im Übrigen sehr ähnlich).

Schließlich erfolgt eine Analyse aus Sicht des Preisrechts. Grundsätzlich ist dem Marktpreis wie im Grundlagenkapitel beschrieben der Vorzug gegenüber Selbstkostenpreisen zu geben. Bei Sofwareentwicklungsprojekten, in denen kundenindividuelle Software entsteht, ist es aber schwierig, einen solchen Marktpreis zu bestimmen – zumal wenn diese Software nicht im Vorfeld abschließend spezifiziert werden kann und damit nicht verschiedene vergleichbare Angebote eingeholt werden können. Eine Lösung kann der Ansatz eines marktüblichen Tagessatzes für Entwickler als Marktpreis sein. Wenn aber die Anzahl benötiger Tage variabel ist, widerspricht das dem Grundsatz, dass festen Preisen der Vorzug vor veränderlichen Preisen gegeben werden sollte. Die ebenfalls denkbare Definition eines Marktpreises pro Story Point hingegen hat das Problem, dass Story Points ein sehr subjektives Maß für den Aufwand sind. Ein Preis pro Team und Iteration wiederum wäre ebenfalls ein flexibler Preis. Preisprüfer fordern, dass die Vergleichbarkeit der Marktpreise sich auf den gesamten Auftrag beziehen muss und es nicht ausreicht, dass Einzelpreise marktüblich sind (Preise und Preisprüfungen bei öffentlichen Aufträgen).

Sind Marktpreise nicht ermittelbar, müssen Selbstkostenpreise herangezogen werden, für die es in den Leitsätzen für die Preisermittlung auf Grund von Selbstkosten (PreisLS) detaillierte Vorschriften gibt. Allerdings sieht der Autor in der Heranziehung der Preisverordnung und der PreisLS keinen wesentlichen Mehrwert für den öffentlichen Auftraggeber gegenüber der Ermittlung und ggf. Nachverhandlung von Marktpreisen über einen Vergleich verschiedener Anbieter.

Insgesamt wird auch in der abschließenden Betrachtung der agile Festpreis als (vorkalkulatorischer) Selbstkostenfestpreis als die beste Option gesehen. Hinsichtlich des Vergabeverfahrens wird der wettbewerbliche Dialog als das gängigste Verfahren für Softwareentwicklungsprojekte dargestellt.

Bibliographische Angaben

Softwareentwicklung für öffentliche Auftraggeber. Agile Entwicklung und Preiskalkulation / Felix Hinkelmann, 1. Auflage 2018, Studylab München, 62 Seiten. Magisterarbeit der FernUniversität Hagen, erhältlich über https://www.grin.com/document/413391.

Weitere Literatur

Folgende Quellen stellen aus meiner Sicht eine gute Ergänzung zum hier besprochenen Buch dar:

• Unterlage für Ausschreibung und Bewertung von IT-Leistungen (UfAB): Die offizielle Handreichung des CIOs des Bundes für die mit der Ausschreibung von Software-/IT-Projekten befassten Beschaffer. Enthält umfassende Erläuterungen zur Planung und Durchführung von IT-Ausschreibungen der öffentlichen Hand.

• Der agile Festpreis : Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge (Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr, Carl Hanser Verlag München): Die detaillierte Beschreibung des im oben besprochenen Buch wie auch in der UfAB favorisierten Preismodells

• Software Estimation without Guessing (George Dinwiddie, O'Reilly 2019): Eine sehr gute Darstellung der Möglichkeiten und Grenzen von Aufwandsschätzungen in Softwareprojekten.