Softwareentwicklung für öffentliche Auftraggeber. Agile Entwicklung und Preiskalkulation

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Theoretische Grundlagen
2.1 Phasenorientierte Methoden der Softwareentwicklung
2.2 Agile Methoden der Softwareentwicklung
2.3 Projektvergabe öffentlicher Auftraggeber

3 Möglichkeiten der Preisgestaltung agiler Entwicklungsprojekte
3.1 Schätzmethoden agiler Entwicklungsprojekte
3.2 Vertragstypologische Einordnung
3.3 Mögliche Vergütungsarten agiler Entwicklungsprojekte

4 Deckung der Anforderungen öffentlicher Auftraggeber
4.1 Analyse aus Sicht des Haushaltsrechtes
4.2 Analyse aus Sicht des Vergaberechtes
4.3 Analyse aus Sicht des Preisrechtes
4.4 Fazit

5 Zusammenfassung und Ausblick

Literaturverzeichnis

Gesetzes- und Urteilsverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Vergabearten öffentlicher Aufträge

Abbildung 2: Preistreppe VO PR 30/53

Abbildung 3: Merkmale von Werk- und Dienstverträgen

Abbildung 4: Aufwands- und Preisschätzung eines agilen Projektes

1 Einleitung

Mit dem ambitionierten Ziel einer Vereinheitlichung der IT-Systeme zur Steuerverwaltung und der Integration historisch gewachsener Software aller Bundesländer, hat die öffentliche Hand in Deutschland das Projekt FISCUS ins Leben gerufen. Dieses Softwareentwicklungsprojekt wurde 2006 nach 13 Jahren Laufzeit und einem Schaden von 500 Mio. € abgebrochen – und das ohne ein nutzbares Ergebnis erzielt zu haben.^[1] Es gibt viele weitere Beispiele für von der öffentlichen Hand vergebene Projekte mit dem Ziel einer funktionierenden Software, die durch hohe Komplexität in diesem Bereich gescheitert sind.^[2]

Nicht nur Softwareentwicklungsprojekte der öffentlichen Hand sind dieser steigenden Komplexität erlegen. Auch privatwirtschaftliche Unternehmen haben damit zu kämpfen. Daher ist vor etwa 15 Jahren ein neuer Trend gestartet, die bis dato starren Vorgehensmodelle in der Abwicklung solcher Projekte aufzubrechen und stattdessen agiler zu gestalten.^[3] Studien belegen die weitaus höheren Erfolgswahrscheinlichkeiten und geringeren Abbruchrisiken von agilen Softwareentwicklungsprojekten im Vergleich zu solchen, die nach den herkömmlichen, phasenorientierten Vorgehensmodellen entwickelt wurden.^[4]

Doch agile Entwicklungsmethoden stoßen an ihre Grenzen, wenn ihnen die vertragliche Gestaltung und somit auch das Vergütungsmodell zuwider laufen.^[5] Inzwischen gibt es diverse Ansätze, wie eine mit agilen Vorgehensmodellen einhergehende und harmonisierende Preisgestaltung aussehen kann. Jedoch sind viele dieser Ansätze mit dem Vergabeverfahren öffentlicher Auftraggeber augenscheinlich nicht vereinbar. Aufgrund der enormen volkswirtschaftlichen Bedeutung der öffentlichen Auftragsvergabe drängen sich zwangsläufig folgende Fragen auf: Welche Arten der Preisgestaltung bei Entwicklungsprojekten individueller Software sind grundsätzlich möglich und welche Einflüsse haben sie auf das Vorgehensmodell der agilen Entwicklung? Sind diese mit den besonderen Bedürfnissen von öffentlichen Auftraggebern vereinbar?

Im Rahmen dieser Ausarbeitung wird daher in Kapitel 2 sowohl ein grundlegendes Verständnis für agile Entwicklungsmethoden und deren Vorteile für den Auftraggeber und -nehmer, als auch für die Besonderheiten bei der Vergabe von Aufträgen der öffentlichen Hand geschaffen. Es folgt eine Betrachtung der Möglichkeiten der Preisgestaltung agiler Entwicklungsprojekte und der Besonderheiten bei der Kalkulation in Kapitel 3. Darauf aufbauend erfolgt eine Analyse der Erkenntnisse vor dem Hintergrund der besonderen Anforderungen öffentlicher Auftraggeber in Kapitel 4 und der in Frage stehenden Vereinbarung mit dem öffentlichen Vergabeverfahren. Das Kapitel 5 schließt mit einer Zusammenfassung der Erkenntnisse und einem Ausblick ab.

2 Theoretische Grundlagen

Zur theoretischen Fundierung wird zunächst ein kurzer Blick auf phasenorientierte Methoden der Softwareentwicklung, welche bis vor etwa 15 Jahren gängige Praxis waren, geworfen. Dies ist nötig um in Abgrenzung dazu ein Verständnis für die wesentlichen Vorteile agiler Methoden schaffen zu können.

2.1 Phasenorientierte Methoden der Softwareentwicklung

Phasenorientierte Methoden wie das Wasserfallmodell sind im Gegensatz zu den agilen Methoden planorientiert. Der Funktionsumfang des Projektes stellt den Fixpunkt dar. Auf dieser Basis werden Kosten und Termine des Projektes geschätzt.^[6] Dieses Vorgehen war in der Softwareentwicklung bis zur Entstehung des Trends zum agilen Vorgehen Anfang der 2000er Jahre Usus. Es äußert sich durch eine detaillierte Planung und Dokumentation im Pflichtenheft des Projektes. Alle Anforderungen werden also nach Möglichkeit zu Beginn definiert und fixiert. Änderungen an diesem Plan sollen vermieden werden da sie mit hohem Aufwand verbunden sind. An die Planung schließt sich als nächste Phase die Umsetzung dieser an. Mit Abschluss des Projektes soll das vollständige Produkt abgenommen werden, welches im Idealfall dem entspricht, was im Pflichtenheft festgehalten wurde.^[7]

2.2 Agile Methoden der Softwareentwicklung

Ende der 1990er wurden von verschiedenen Vertretern der Softwareentwicklungsbranche und der Wissenschaft neue Vorgehensmodelle entwickelt, in denen sie Prozesse und Prinzipien vorstellten, mit denen sie den Gedanken der Agilität in das Blickfeld rückten. 2001 trafen sich die einflussreichsten Vertreter ebendieser Vorgehensmodelle, um gemeinsam das agile Manifest zu definieren. Die dort verabschiedeten Prinzipien führten in den Folgejahren einen Paradigmenwechsel in dieser Branche herbei.^[8]

Im Folgenden soll ein Verständnis dafür entstehen, welche Vorteile sowohl für privatwirtschaftliche Unternehmen als auch für die öffentliche Hand, sowohl für Auftraggeber einer Entwicklung als auch für deren Auftragnehmer, entstehen. Um dies deutlich zu machen, empfiehlt es sich zunächst allgemein auf die Prinzipien des agilen Manifestes einzugehen, ehe ein explizites Modell beschrieben wird.

2.2.1 Prinzipien agiler Entwicklungsmethoden

In dem agilen Manifest fassen die Autoren ihre Vorstellungen in zwölf Prinzipien zusammen, welche alle agilen Vorgehensmodelle der Softwareentwicklung in sich vereinen. Diese Prinzipien stellen eine hohe Kundenorientierung in den Vordergrund und sollen den Kunden durch frühe und kontinuierliche Lieferungen von Softwareinkrementen zufriedenstellen.^[9] Inkremente sind kleine, funktionierende Anteile der zu entwickelnden Software, beispielsweise Features oder Teile der Produktfunktionalitäten.^[10] Diese Inkremente, aufgrund der einfachen textuellen Beschreibung im Planungsprozess auch Storys genannt, werden im iterativen Vorgehen erstellt. Eine Iteration beschreibt einen Entwicklungsschritt von maximal vier Wochen mit Präferenz zu kürzeren Zeiträumen. Agile Methoden geben nicht vor, das Produkt von Beginn der Entwicklung an bereits vollkommen spezifiziert zu haben, es werden lediglich die wesentlichen Funktionalitäten festgelegt, welche in jeder Iteration weiterentwickelt werden. Welche Funktionen die zu entwickelnde Software also haben soll wird erst im Laufe des Projektes festgelegt. Innerhalb der Iteration liegt ein besonderer Fokus auf dem Teamgedanken. Die kleinen, selbstorganisierten Entwicklungsteams treffen gemeinsam Entscheidungen, reflektieren ihre Arbeit und binden auch den Kunden intensiv ein. Das ist gemäßden Prinzipien des agilen Manifestes die Grundlage für die besten Architekturen, Anforderungen und Designs. Auch eine ausreichende Motivation der Mitarbeiter, die durch geeignete Maßnahmen positiv beeinflusst werden sollte, ist Bestandteil ebendieser Prinzipien. Agile Methoden stellen die Individuen und deren Interaktion über die Prozesse und Werkzeuge. Die effektivste und effizienteste Methode Informationen innerhalb des Teams zu transportieren ist im persönlichen Dialog.^[11]

Der Kunde muss in jeder Iteration involviert werden, sein Feedback zu den bisher gelieferten Storys verarbeitet und auch seine Präferenzen und Wünsche der in der kommenden Iteration zu entwickelnden Funktionalitäten berücksichtigt werden. Die Prinzipien des agilen Manifestes geben vor, dass jede Änderung der Anforderungen begrüßt werden soll, auch in der späteren Entwicklungsphase, da diese den Wettbewerbsvorteil des Kunden stärken. Der Fortschritt des Projektes nach jeder Iteration soll schließlich primär in bis zu diesem Zeitpunkt funktionierender Software gemessen werden.^[12]

2.2.2 Ausgestaltung agiler Entwicklungsmethoden

Agile Methoden sind sich zwar in ihren Prinzipien einig, im Folgenden soll jedoch nur Scrum als das am meisten verbreitete und erfolgreichste Vorgehensmodell, oft auch als das Standard-Vorgehensmodell betitelt, detaillierter beschrieben werden.^[13] Die im Hauptteil erarbeiteten Erkenntnisse können ebenso gut auf andere agile Methoden angewandt werden. Dieser Abschnitt soll lediglich ein Verständnis für die Wirkungsweisen hinter solchen Modellen schaffen.

Scrum arbeitet nicht wie herkömmliche, phasenorientierte Entwicklungsmethoden mit einem detaillierten technischen Feinkonzept (Pflichtenheft), sondern mit drei Artefakten. Diese drei Artefakte sind das Inkrement beziehungsweise die Story, das Sprint Backlog und das Product Backlog.^[14] Eine Story ist ein funktionierender Anteil der zu entwickelnden Software, ein Teil der Produktfunktionalität. Die Story wird nach ihrem Aufwand in Story Points gemessen. Eine in der Umsetzung als aufwendig eingeschätzte Story wird mit einer höheren Anzahl an Story Points bemessen, als eine in der Umsetzung voraussichtlich simplere Story. Das Sprint Backlog wird vor jeder Iteration von den Entwicklungsteams definiert. Es umfasst so viele Storys, wie die Teammitglieder schätzen in der jeweiligen Iteration umsetzen zu können. Es wird lediglich für die anstehende Iteration definiert, da agile Methoden akzeptieren, dass eine Planung welche tiefer in die Zukunft blickt, mit zu hoher Unsicherheit belastet ist und eine geringere Aussagekraft hat. Das Product Backlog enthält die Summe aller Storys, die von den Entwicklungsteams für das zu entwickelnde Produkt umgesetzt werden sollen. Die Abhängigkeit kann demnach folgendermaßen dargestellt werden:

Dabei soll das Product Backlog jedoch nicht zu sehr spezifiziert werden, die Anforderungen sollen lediglich ausreichend gut in Storys formuliert und in Story Points bemessen sein. Eine detailliertere Spezifikation soll erst mit dem Sprint Backlog durch Kommunikation innerhalb der Entwicklungsteams geschehen. Dies soll verhindern, dass zu viel Arbeit in die Ausgestaltung der zu entwickelnden Storys investiert wird, welche mit zunehmendem Projektverlauf und dadurch besserem Kenntnisstand sowohl bei dem Kunden, als auch bei den Entwicklungsteams ohnehin geändert werden oder entfallen.^[15]

Der Fokus auf die Zusammenarbeit der Entwicklungsteams lässt bestimmte Ereignisse nötig werden. Dazu gehört das Entwicklungsvorgehen über Iterationen. Diese sollen, wie in Kapital 2.2.1 beschrieben, maximal vier Wochen mit Präferenz zu kürzeren Zeiträumen einnehmen. Dadurch soll ein zu großer Planungshorizont verhindert und ein für den Menschen gut überschaubarer Zeitraum geschaffen werden, in welchem er eine verlässliche Detailplanung generieren kann. Zu Beginn der Iteration findet das Sprint Planning statt. In diesem Termin soll durch die Beantwortung der Fragen, was das Ziel der Iteration ist und wie dieses erreicht werden soll, das Sprint Backlog erstellt werden. Im täglichen Rhythmus findet der Daily Scrum statt. In einem 15-minütigen Termin findet sich jedes Entwicklungsteam zusammen und die Teammitglieder beraten darüber, was sie am gestrigen Tag zur Erreichung des Iterationsziels getan haben, was sie am heutigen Tag dafür tun werden und welche Hindernisse sie sehen. Am Ende jeder Iteration werden das Sprint Review und die Sprint Retrospektive durchgeführt. Das Sprint Review soll mit Kundenbeteiligung und Fokus auf das Produkt die Frage beantworten, ob die entwickelten Storys den Zweck des Produktes erfüllen und ob es für die späteren Anwender nutzbar sein wird. Im Rahmen der Sprint Retrospektive hingegen sollen konkrete Verbesserungsmaßnahmen in der Zusammenarbeit der Teams erarbeitet werden. Diese widerkehrenden Ereignisse zeigen auf, wie der Fokus auf Produkt und Kunde durch agile Entwicklungsmethoden erreicht werden kann.^[16]

An einem Produkt können ein oder mehrere Teams arbeiten. Jedes Team hat drei bis neun Mitglieder, Scrum kennt dabei nur drei Rollen: Den Product Owner, den Scrum Master und das Entwicklungsteam. Der Product Owner trägt die Verantwortung für den Kundennutzen der Software, indem er die Produkteigenschaften, also Storys im Product Backlog, entsprechend priorisiert und mit Story Points bemisst. Er definiert die Produkteigenschaften im Product Backlog und konkretisiert und verfeinert deren Anforderungen im Rahmen der Iterationen. Er soll hierdurch die Effizienz der Entwicklungsteams maximieren. Für die richtige und erfolgreiche Anwendung von Scrum sorgt der Scrum Master. Zu seinen Aufgaben gehören neben der Moderation der Meetings auch der Schutz des Teams vor externen Einflüssen, das Schaffen von Verständnis für Scrum im Unternehmen, das Coaching des Teams in Selbstorganisation und weitere Aufgaben die zeigen, dass er sich ganz in den Dienst des Teams stellt. Das Entwicklungsteam selbst ist cross-funktional aufgebaut; ihm gehören neben Entwicklern auch Experten wie Tester oder Designer an. Dieser Aufbau ist einer autarken Arbeitsweise des Entwicklungsteams dienlich.^[17]

2.2.3 Intentionen agiler Entwicklungsmethoden

Die Ausgestaltung agiler Methoden wie Scrum hat viele Vorteile gegenüber den herkömmlichen phasenorientierten Methoden. Ein Wesentlicher ist die weitaus kürzere Vorlaufzeit, bis das Produkt erstmals am Markt platziert wird. Durch die iterativ-inkrementelle Vorgehensweise, also dem Anspruch nach jeder Iteration neue funktions- und verkaufsfähige Funktionalitäten bereitstellen zu können, liefert jedes Entwicklungsteam mindestens im Monatsrhythmus ein verkaufsfähiges Produkt, welches auch durch den Kunden eingesetzt werden kann. Im Rahmen von phasenorientierten Entwicklungsmethoden passiert dies erst am Ende der Projektlaufzeit, was Monate oder sogar Jahre in Anspruch nehmen kann.^[18] Der Product Owner stellt dabei in Kommunikation mit dem Kunden sicher, dass nur die wirklich wertvollen Funktionalitäten in diesem Rhythmus geliefert werden.^[19]

Die ständige Begleitung von Qualitätstestern innerhalb der Teams, gepaart mit der Tatsache, dass Fehler aufgrund des Anspruchs durchgehend funktionsfähige Software zu liefern schneller gefunden werden als bei phasenorientierten Methoden, führt zu einer höheren Qualität des Produktes. Einen weiteren Teil zu der Qualitätssteigerung tragen die Einbindung des Kunden und sein laufendes Feedback bei. Durch die Diversität in der Teamzusammenstellung bei Methoden wie Scrum wird außerdem ein höherer Innovationsgrad erreicht als bei klassisch zusammengestellten Abteilungen.^[20]

Die Zufriedenheit der Mitarbeiter kann durch eine höhere intrinsische Motivation wesentlich gesteigert werden. Die intrinsische Motivation im Rahmen agiler Entwicklungsmethoden wiederum ist höher als bei herkömmlichen Methoden, da der Mitarbeiter den Zweck seiner Arbeit eher versteht und für sinnvoll hält, von seinen Aufgaben nicht überfordert wird und die Art der Umsetzung seiner Aufgaben selbst bestimmen kann. Der Mitarbeiter entwickelt Funktionalitäten, deren Kundennutzen er durch die Kommunikation mit ebendiesem kennt. Den Zweck seiner Arbeit sollte er demnach verstehen. Sein Einfluss auf die Art der Umsetzung seiner Aufgaben ist durch die Selbstorganisation der Teams gegeben. Dies bietet außerdem die Chance, dass jedes Teammitglied selbst dafür sorgen kann, dass es sich Aufgaben annimmt, an denen es wächst.^[21]

Der enorm kurze Planungsrhythmus in agilen Projekten sorgt für eine höhere Effizienz. Es wird nicht wie bei herkömmlichen phasenorientierten Entwicklungsprojekten jedes Detail von vornherein durchgeplant, bemessen und in einem Pflichtenheft festgehalten, welches im Projektverlauf durch die sich ändernde Umwelt ohnehin wieder umgeschrieben werden muss. Methoden wie Scrum nehmen hin, dass nur kurze Zeithorizonte gut überschaubar sind und sparen sich die vergeblichen Mühen einer zu hohen Spezifikation.^[22]

2.3 Projektvergabe öffentlicher Auftraggeber

Auch für Softwareentwicklungsprojekte öffentlicher Auftraggeber, wie dem in Kapitel 1 genannten Beispiel der einheitlichen Steuerverwaltungssoftware FISCUS, kann ein agiles Vorgehensmodell einen hohen Mehrwert generieren. Als öffentliche Auftraggeber werden in Deutschland der Bund, die Länder, Gemeinden und Gemeindeverbände, sowie sonstige juristische Personen des öffentlichen Rechts gesehen.^[23] Jedoch sind agile Vorgehensmodelle für die öffentliche Hand neu, ein Thema mit welchem sie sich noch wenig beschäftigt hat^[24] und auch im Rechtswesen ist dieses Thema hierzulande zwar bekannt, wurde bisher jedoch kaum behandelt.^[25]

Die Bundesanstalt für IT-Dienstleistungen hat mit dem V-Modell XT ein eigenes Vorgehensmodell geschaffen, welches agile Elemente aufgreift. Hierbei handelt es sich um ein Modell, welches bei der Abwicklung von Softwareentwicklungsprojekten in der öffentlichen Verwaltung zur Anwendung kommen soll. Somit ist es nur bei der Vergabe an Unternehmen der öffentlichen Hand, also der sogenannten In-House Vergabe, relevant. Da es zusammenfassend jedoch ein phasenorientiertes Modell ist, welches nur wenige agile Ideen aufgreift, bleibt es auch nur ein Versuch diesem Paradigmenwechsel zu folgen.^[26] Die Implementierung agiler Methoden in der öffentlichen Verwaltung stellt für sich genommen ein komplexes Thema dar; die In-House Vergabe wird im Rahmen dieser Arbeit daher nicht eingehender behandelt.

Eine gute Übersicht über die Anforderungen öffentlicher Auftraggeber bei der Vergabe an privatwirtschaftliche Unternehmen sollte ein Blick auf die Gesetzeslage geben. Diese manifestiert die Anforderungen, an die sich bei jeder Vergabe gehalten werden muss. Im Folgenden werden sie anhand der deutschen Rechtslage untersucht. Grundsätzlich haben in Deutschland drei Rechtsvorschriften Einfluss auf die Vergabe öffentlicher Aufträge: Das Haushaltsrecht, das Vergaberecht und die preisrechtlichen Vorschriften.^[27]

2.3.1 Einflüsse des Haushaltsrechtes auf die Preisbildung

Die Ausschreibungspflicht für öffentliche Aufträge, sowie die Grundsätze der wirtschaftlichen und der sparsamen Verwendung von Haushaltsmitteln, gehen aus dem Haushaltsrecht hervor.^[28] Diese stellen Prämissen dar, welche bei der Durchführung des Beschaffungsprozesses durchgehend zu berücksichtigen sind.^[29] Das Wirtschaftlichkeitsprinzip schreibt allgemein das günstigste Verhältnis zwischen einem verfolgten Zweck einer Maßnahme und den für ebendiese Maßnahme eingesetzten Mitteln vor. Es beinhaltet demnach zum einen das Minimalprinzip, welches die Erreichung eines bestimmten Zieles mit möglichst geringen Mitteln vorschreibt. Zum anderen schließt es das Maximalprinzip ein, welches mit den zur Verfügung stehenden Mitteln das möglichst beste Ergebnis vorschreibt. Die Wahl des jeweiligen Prinzips richtet sich danach, ob Ziel oder Mittel gegeben sind.^[30]

Konkretere Anhaltspunkte gibt die Bundeshaushaltsordnung. So darf im Bundeshaushaltsplan nur der Finanzbedarf eingestellt werden, der zur Erfüllung der Aufgaben des Bundes im Bewilligungszeitraum notwendig ist. Des Weiteren schreibt sie eine Prüfung vor, ob unter Berücksichtigung des Wirtschaftlichkeits- und Sparsamkeitsprinzips die Aufgaben nicht mit geringerem Personal- oder Sachaufwand erfüllt werden können.^[31] Diese Vorschriften und viele weitere der Bundeshaushaltsordnung legen nahe, dass es bei der Erfüllung des Wirtschaftlichkeitsprinzips zum einen um die Erfüllung von Aufgaben, zum anderen um die erforderlichen und notwendigen Geldmittel zur Erfüllung ebendieser Aufgaben geht. Dabei müssen die eingesetzten Mittel geeignet sein, um den angestrebten Zweck abzudecken. Es muss des Weiteren erforderlich sein, diesen Zweck abzudecken und es darf keine sparsamere Alternative existieren. Mittel und Zweck müssen zudem in einem angemessenen Verhältnis stehen.^[32]

2.3.2 Einflüsse des Vergaberechtes auf die Preisbildung

Die Art des Vergabeverfahrens wurde bis zu einer kürzlichen Reform des Vergaberechts durch die Vergabe- und Vertragsordnung für Liefer- und Dienstleistungen VOL/A geregelt. Diese teilte sich in zwei Abschnitte auf. Der erste Abschnitt enthielt die Basisparagraphen für die Durchführung nationaler Vergabeverfahren. Der zweite Abschnitt die EG-Paragraphen für die Durchführung eines europaweit einheitlichen Vergabeverfahrens.^[33] Erreicht der zu vergebene Auftrag den von der EU festgelegten Schwellenwert in Höhe von 135.000 € für Aufträge, welche von zentralen Regierungsbehörden vergeben werden beziehungsweise 209.000 € für Aufträge von subzentralen öffentlichen Auftraggebern, so findet das europaweit einheitliche Vergabeverfahren Anwendung.^[34]

Um die Richtlinie 2014/24/EU der Europäischen Union einer neuen europaweit einheitlichen Vergaberichtlinie fristgerecht in deutsches Recht umzusetzen, wurde das deutsche Vergaberecht oberschwellige Vergabe betreffend im April 2016 modernisiert. Die Vergabeverordnung (VgV) wurde grundlegend überarbeitet und die europäischen Vorschriften wurden im Rahmen dieser Überarbeitung berücksichtigt; der EG Abschnitt der VOL/A wurde obsolet.^[35] Für Aufträge unterhalb der Schwellenwerte greift seit einer Reform des unterschwelligen Vergaberechtes im Jahr 2017 die Unterschwellenvergabeordnung.^[36] Es ergeben sich die in Abbildung 1 dargestellten Möglichkeiten unterschiedlicher Vergabeverfahren für den öffentlichen Auftraggeber.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Vergabearten öffentlicher Aufträge^[37]

Aufgrund der hohen Personalkosten der mit interdisziplinären Spezialisten besetzten Teams wird angenommen, dass bereits bei wenigen Teams und Iterationen kaum ein agiles Entwicklungsprojekt preislich im unterschwelligen Bereich liegt. Im Rahmen dieser Arbeit wird daher vereinfachend ausschließlich der oberschwellige, europaweite Bereich der öffentlichen Auftragsvergabe betrachtet. Im oberschwelligen Bereich soll der öffentliche Auftraggeber grundsätzlich zwischen dem offenem- und dem nicht-offenem Verfahren wählen,^[38] es sei denn Absatz 3 oder 4 des §14 VgV bieten ihm andere Möglichkeiten. Im Rahmen des offenen Verfahrens fordert der öffentliche Auftraggeber eine unbeschränkte Anzahl von Unternehmen zur Abgabe von Angeboten auf. Im nicht-offenen Verfahren wählt der öffentliche Auftraggeber vorher nach objektiven, transparenten und nicht-diskriminierenden Kriterien eine beschränkte Anzahl von Unternehmen zur Angebotsabgabe auf.^[39] Bis zu der Reform im Jahr 2016 sollte vorrangig das offene Verfahren gewählt werden. Inzwischen darf vorbehaltlich des Grundsatzes der Wirtschaftlichkeit frei zwischen diesen Verfahren abgewogen werden.^[40] Diese Wahlfreiheit wird europaweit durchgesetzt.^[41] Der öffentliche Auftraggeber muss somit eine Wirtschaftlichkeits- und Wettbewerbsprüfung durchführen, er ist demnach an dem besten Preis-Leistungsverhältnis interessiert. Weiterhin soll der Fokus auf einen möglichst ausgeprägten Wettbewerb und ein hohes Maßan Transparenz ein weiteres Interesse der öffentlichen Hand abdecken: die Verhütung von Korruption.^[42]

Das Verhandlungsverfahren, bei dem sich der öffentliche Auftraggeber zum Zweck der Auftragsverhandlung direkt an ausgewählte Unternehmen wendet, und der 2005 eingeführte wettbewerbliche Dialog, sind bei der Beauftragung agiler Entwicklungsprojekte ebenfalls von Interesse.^[43] Im wettbewerblichen Dialog kann der öffentliche Auftraggeber die Mittel zur Befriedigung seines Bedarfs anhand der angebotenen technischen, finanziellen und rechtlichen Lösungen definieren, sollte dies ohne entsprechende Angebote nicht möglich sein.^[44] Er bietet somit noch mehr Freiheiten als das Verhandlungsverfahren.

Weiterhin zeigt sich in der Gesetzgebung der nahen Vergangenheit, dass sich Prinzipien wie Wirtschaftlichkeit, Qualität und Innovation als Argumente bei der öffentlichen Vergabe in Deutschland gegenüber dem Preis als zentrales Kriterium haben durchsetzen können.^[45] Vor allem die Innovation als Kriterium für öffentliche Vergabe sollte auch die Methoden der Produktion der zu beschaffenden Güter einschließen. Im Fall der Softwareentwicklung möglicherweise auch Scrum als innovatives Vorgehensmodell der Produktion von Software. Spätestens seit der deutschen Oberschwellen-Vergaberechtsreform im Jahr 2016, deren Inhalt in ähnlicher Form durch die EU Richtlinie 2014/24/EU europaweit umgesetzt wird, ist dies durch die Wahl der Innovationspartnerschaft im Rahmen der Auftragserteilung kein vergabefremder Aspekt mehr.^[46] Diese Partnerschaft soll dem öffentlichen Auftraggeber bei Beauftragung von konzeptionellen oder innovativen Lösungen offen stehen.^[47] Öffentlichen Auftraggebern soll hierdurch erleichtert werden Innovationen zu fördern. Innovation ist eine treibende Kraft des Wirtschaftswachstums, welchen der Staat durch die Vergabe öffentlicher Auftraggeber zu fördern hat.^[48] Man kann die Förderung von Innovationen zur Begünstigung des Wirtschaftswachstums demnach als ein Ziel des öffentlichen Auftraggebers betrachten. Eigens dafür wurde die Innovationspartnerschaft als Vergabeverfahren in der durch die EU angestoßenen Vergaberechtsreform im Jahr 2016 als neue Möglichkeit der öffentlichen Auftragsvergabe hinzugefügt.

2.3.3 Einflüsse des Preisrechtes auf die Preisbildung

Das Preisrecht gilt als Ergänzung zum Vergaberecht. Zwar haben sich das Anwendungsfeld und das betriebswirtschaftliche Instrumentarium seit Inkrafttreten der Verordnung PR Nr. 30/53 über die Preise bei öffentlichen Aufträgen vor über 60 Jahren gravierend gewandelt, es kam bisher jedoch zu keiner wesentlichen Überarbeitung ebendieser.^[49] Sie ist auch ohne vertragliche Würdigung auf alle öffentlichen Aufträge anzuwenden.^[50]

Die Anwendung der Preisverordnung gebietet dem öffentlichen Auftraggeber vorwiegend den Vorzug von Marktpreisen, bevor auf Selbstkostenpreise zurückgegriffen wird. Selbstkostenpreise müssen anhand detaillierter Kalkulationsvorschriften ermittelt werden. Weiterhin soll festen Preisen Vorrang vor der Bildung veränderlicher Preise gegeben werden. Der dritte wesentliche Grundsatz der Verordnung ist das Höchstpreisprinzip. Es stellt sicher, dass die gemäßder Verordnung festgelegten Preise von keiner Partei überschritten, jedoch unterschritten werden dürfen.^[51] Es ergibt sich die in Abbildung 2 dargestellte Preistreppe.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Preistreppe VO PR 30/53^[52]

Staatlich festgesetzte Preise sind besondere Preisvorschriften, welche gemäßPreisgesetz zur Preisbildung und Preisüberwachung erlassen wurden. Heute fallen darunter nur noch wenige Ausnahmen wie im Bereich der Gebührenordnungen für Ärzte oder Notare; bei öffentlichen Aufträgen kommt ihnen kaum Bedeutung zu.^[53] Staatlich festgesetzte Preise sind im Kontext dieser Arbeit daher nicht relevant. Marktpreise, also Preise für marktgängige Leistungen, werden in der Preisverordnung nicht hinreichend definiert. Anwender in der Praxis und Experten bemängeln die Unklarheit über die Voraussetzung von Marktpreisen.^[54] Für die Marktgängigkeit eines Preises sprechen jedoch die Herstellung und der Handel der zugrundeliegenden Leistung allgemein im wirtschaftlichen Verkehr und die Verkehrsüblichkeit des Preises.^[55]

In Verbindung mit dem Vergaberecht wurde in einem Runderlass zur Preisverordnung darauf hingewiesen, dass durch eine Ausschreibung zustande gekommene Preise als Marktpreis gelten, sofern „[…] der Wettbewerb der Anbieter alle ausreichenden Garantien für ein ordnungsgemäßes Zustandekommen der Preise geboten hat.“^[56] Durch den Ermessensspielraum bezüglich der genannten Garantien ergibt sich jedoch keine automatische Zuordnung von Marktpreisen zu bestimmten Vergabearten.^[57]

[...]

---

^[1] Vgl. Mertens 2009, S. 44. Der Schaden erhöht sich auf 5 Mrd. € wenn entgangene Steuereinnahmen berücksichtigt werden.

^[2] Vgl. Mertens 2012, S. 433ff.

^[3] Vgl. Maximini 2013, S. IX.

^[4] Vgl. Orłowski et al. 2017, S. 525f; Ahimbisibwe et al. 2017, S. 420f; o.V. 2017, S. 9.

^[5] Vgl. Auer-Reinsdorff 2010, S. 93.

^[6] Vgl. Opelt et al. 2012, S. 43.

^[7] Vgl. Müller und Hüsselmann 2017, S. 49ff.

^[8] Vgl. Roock und Wolf 2016, S. 5f; Beck et al. 2001a.

^[9] Vgl. Beck et al. 2001b.

^[10] Vgl. Wintersteiger 2014, S. 18f.

^[11] Vgl. Gloger 2014, S. 12f; Roock und Wolf 2016, S. 5ff, Beck et al. 2001a.

^[12] Vgl. Beck et al. 2001b; Wintersteiger 2014, S. 21f, Gloger 2014, S. 12.

^[13] Vgl. Wintersteiger 2014, S. 1; Roock und Wolf 2016, S. 5; Gloger 2014, S. 11; Pieper und Roock 2017, S. 1; Opelt et al. 2012, S. 1.

^[14] Vgl. Pieper und Roock 2017, S. 11.

^[15] Vgl. Wintersteiger 2014, S. 107f; Gloger 2014, S. 16f; Petrini und Muniz JR 2014, S. 437ff.

^[16] Vgl. Roock und Wolf 2016, S. 22ff; Maximini 2013, S. 182f.

^[17] Vgl. Wintersteiger 2014, S. 47ff; Roock und Wolf 2016, S. 19ff.

^[18] Vgl. Opelt et al. 2012, S. 35.

^[19] Vgl. Roock und Wolf 2016, S. 8f.

^[20] Vgl. Pieper und Roock 2017, S. 21; Sandhaus et al. 2015, S. 308.

^[21] Vgl. Pieper und Roock 2017, S. 22f.

^[22] Vgl. Roock und Wolf 2016, S. 10.

^[23] Vgl. §2 Abs. 1 VO PR 30/53.

^[24] Vgl. Schmid und Hanisch 2015, S. 21; Heydenreich 2016, S. 13.

^[25] Vgl. Ernst 2017, S. 285f.

^[26] Vgl. Schill und Achtert 2015, S. 52f; Schmidt et al. 2014; Schmid und Hanisch 2015, S. 21.

^[27] Vgl. Georgi 2015, S. 9ff.

^[28] Vgl. §6, §30 HGrG.

^[29] Vgl. Fabry et al. 2013, S. 51.

^[30] Vgl. Pils 2012, S. 8; Engels 2015, S. 116f.

^[31] Vgl. § 2, § 90 BHO.

^[32] Vgl. Engels 2015, S. 117.

^[33] Vgl. Fabry et al. 2013, S. 9.

^[34] Vgl. Art. 4 2014/24/EU in Verbindung mit Art. 1 (EU) 2015/2170.

^[35] Vgl. Ley und Wankmüller 2016, S. 10ff.

^[36] Näheres hierzu in Ley und Wankmüller 2017.

^[37] Eigene Darstellung in Anlehnung an §14 Abs. 1 VgV; § 8 UVgO.

^[38] Vgl. §14 Abs. 2 VgV; Wietersheim 2016.

^[39] Vgl. §119 Abs. 3 & 4 GWB.

^[40] Vgl. o.V. 2015a, S. 3.

^[41] Vgl. Art. 26 Abs. 2 2014/24/EU.

^[42] Vgl. Ley und Wankmüller 2016, S. 291.

^[43] Vgl. §119 Abs. 5 & 6 GWB; Pils 2012, S. 39f.

^[44] Vgl. Ley und Wankmüller 2016, S. 293.

^[45] Vgl. Sack und Sarter 2015, S. 373.

^[46] Vgl. §14 Abs. 1 VgV; Ley und Wankmüller 2016, S. 18.

^[47] Vgl. §14 Abs. 3 Nr. 2 VgV.

^[48] Vgl. Erwägungsgrund 47 2014/24/EU.

^[49] Vgl. Hoffjan et al. 2013, S. 3ff; Georgi 2015, S. 1f.

^[50] Vgl. Dierkes et al. 2009, S. 192, davon ausgenommen sind Bauaufträge.

^[51] Vgl. §1 VO PR 30/53.

^[52] Eigene Darstellung in Anlehnung an Hoffjan et al. 2013; § 3 bis 7 VO PR 30/53.

^[53] Vgl. Müller 1991, S. 21.

^[54] Vgl. Dörr und Hoffjan 2015, S. 46; Dierkes et al. 2009, S. 196.

^[55] Vgl. Nr. 5 a Runderlass Verordnung PR Nr. 30/53 vom 22.12.1953; Georgi 2015, S. 27.

^[56] Nr. 5 b Runderlass Verordnung PR Nr. 30/53 vom 22.12.1953.

^[57] Vgl. Müller 2011, S. 724.