Problemstellungen der öffentlichen Hand bei der Ausschreibung von Internetprojekten

Warum öffentliche Ausschreibungen scheitern

Wenn Sie an erfolgreiche Projekte im öffentlichen Sektor denken, welche fallen Ihnen ein?

Ob Bauvorhaben wie Flughafen Berlin Brandenburg und Elbphilharmonie oder IT-Projekte wie die LKW-Maut, Hartz-IV-Software oder Polizeifunk - die öffentliche Hand scheitert oft bei der Projektbeschreibung, Ausschreibung und Umsetzung.

Eine erfolgreiche Projektierung, unter Einhaltung der drei Parameter Kosten, Zeit und Funktionen scheint unmöglich zu sein.

Dies trifft auch bei "kleineren" Projekten wie Webportalen zu.

Kein Wunder:
Wer ist in der Lage, ein ihm unbekanntes Projekt valide und seriös zu planen, wenn er dies zum ersten oder vielleicht zum zweiten Mal macht?
Die notwendige Expertise zur Projektbeschreibung kann gar nicht vorhanden sein.

Das Problem:
Bei der Erstellung der Ausschreibungsunterlagen haben viele Institutionen noch keinen Experten hinzugezogen, da die landläufige Meinung vorherrscht:
"Eine Leistungsbeschreibung zu erstellen kann ja nicht schwer sein. Das machen wir schon mal eben selbst."

Hier ist der Auftraggeber in einer Zwickmühle. Er muss eine valide Beschreibung vorlegen, um größtmögliche Chancengleichheit bei der Ausschreibung zu gewährleisten. Dies kann er jedoch eigenständig kaum leisten.
Ihm fehlen technische Grundlagen für die Ausgestaltung von einzelnen Funktionen oder auch Alternativansätze, die zum gleichen oder sogar besseren Ergebnis führen. Der Auftraggeber ist gezwungen, einzelne Softwaremodule oder Erweiterungen aufzuführen und sich mit diesen auseinanderzusetzen in der Hoffnung, diese würden zur bestmöglichen Zielerreichung führen.

Die Zwickmühle ist der Versuch einer technischen Leistungsbeschreibung obwohl nur eine fachliche Anforderungsbeschreibung Sinn macht.

Konsequenzen und Stilblüten dieses Dilemmas

Als Konsequenz aus diesem Dilemma werden in der Praxis häufig Ausschreibungen auch komplett zurückgezogen, da Anspruch und Wirklichkeit auseinanderklaffen oder ganz profan: gar keine Bewerbungen eingegangen sind.

Und was sind die Schlussfolgerungen, wenn öffentliche Gelder evtl. "verschwendet", Termine nicht gehalten und endlose Nachkalkulationen drohen?

Gibt es einen Ausweg aus dem Dilemma mit den unbekannten Größen "Projekt - und Facherfahrung", "Projektmanagementmethode" und gesetzlichen Vorgaben des Ausschreibungsverfahrens?

Professionalisierung

Die Professionalisierung muss bei der Ausschreibungsmethodik beginnen, sich über die richtige Wahl des Projektmanagementverfahrens hinziehen und darf bei der Dienstleisterauswahl nicht enden. Das in der Praxis häufig durchgeführte Verfahren führt aber nicht nur zu wirtschaftlichen Schäden im Sinne von zurückgezogenen Ausschreibungen.

Es führt mindestens zu einer weiteren Stilblüte, die ebenfalls wirtschaftlichen Schaden verursacht:
Nicht selten werden Rahmenbedingungen für Ausschreibungen derart speziell gestaltet, dass der Kreis möglicher Bewerber auf eine Weise selektiert wird, die nicht mit den tatsächlich notwendigen Fertigkeiten übereinstimmen.

Die Chancen für neue Anbieter, neue Ideen und neue Konzepte werden so von Beginn an reduziert oder sogar ausgeschlossen.

Scrum für Kommunen, Scrum für Städte, Scrum für Hochschulen. Ein klares JA!

Starre Projektierung ist Gift für den Projekterfolg

Seien wir ehrlich. Bei Projektbeginn ist für Dienstleister wie Auftraggeber das Wissen um das Projekt vage. Dennoch wird bereits verlangt, möglichst viele Entscheidungen zu treffen. Diese Entscheidungen werden im Lasten- und Pflichtenheft manifestiert und sind fortan Gesetz.

Mit fortschreitendem Projektverlauf nimmt das Wissen um das Projekt stetig zu. Es kommen neue Ideen auf, neue Anforderungen, es ergeben sich Änderungswünsche, ursprüngliche gestellte Anforderungen erweisen sich als überflüssig. In der Regel werden aber Projekte mit klassischer (starrer) Projektierung im Laufe des Projektes immer weniger Entscheidungen getroffen. Wie auch? Diese hat man ja an den Anfang des Projektes gestellt, in dem Glauben, diese Projektbeschreibung wird schon richtig sein. Sie wurden vertraglich manifestiert und sind unverrückbar.

Dieses starre Vorgehensmodell, welches am realen Bedarf vorbei agiert, ist der Grund dafür, dass viele Projekte der öffentlichen Hand scheitern.

Der reale Bedarf ist bei umfangreichen Projekten auf der Detailebene zu Projektbeginn nicht vollständig transparent.

Auswirkung von Entscheidungen (durchgezogene Linie = Wasserfall)  
Wissen über Projekt (gestrichelte Linie = agile Methodik)

Viele Studien legen hierzu immer wieder den Finger in die Wunde.

So hat schon Watts S. Humphrey im Jahr 2000 nachgewiesen, dass pro Phase in der ein Fehler später entdeckt wird, der Aufwand zur Behebung um 10% steigt.
Zudem kommen tagtäglich Veränderungen hinzu, die vorab kaum planbar sind, die neue Anforderungen an das Projekt stellen, seien es rechtliche, marktspezifische, personelle oder organisatorische.
Diese ganz natürliche Projektveränderung beträgt 3-5% im Monat. Bei einer nicht unüblichen Projektlaufzeit von 12 Monaten addiert sich dies schnell auf bis zu 60%!

Wasserfallprojekte, in dem erst eine vollständige Analyse und Planung darauf aufbauend der Entwurf und dann die Programmierung folgte, wurden spätestens bei der Integration und den Systemtests von der Wirklichkeit eingeholt. Doch 24 Stunden vor Livegang ist es oft zu spät, eine lange Liste an Änderungen umzusetzen. Die Projekteskalation führt zu einem unrühmlichen Ende.

Wasserfallprojekte folgen einem linearen Vorgehensmodell, das in Phasen durchgeführt wird. Jede Phase baut zwingend auf der vorausgehenden auf. Jede Phase hat klare Start- und Endpunkte und schließt mit einem Meilenstein und dessen Dokumentation ab. Die Bezeichnung "Wasserfall" ergibt sich aus der häufig gewählten Darstellung der Kaskade angeordneten Phasen.

Agile Webprojekte nach Scrum - Webrelaunch Ausschreibungen der öffentlichen Hand

Agile Methoden schaffen faire Projektbedingungen

Im Gegensatz dazu setzt ein agiles Management nach Scrum auf eine iterative Anforderungsbeschreibung, die im Projektverlauf stetig angepasst und erweitert wird.

Am Anfang der Entwicklung steht die sogenannte Produktvision des IT-Systems, in Form klar verständlicher Anforderungen, die jedoch noch nicht detailliert beschrieben sind. Diese Produktvision ist unveränderlich und Maßstab aller darauf aufbauender Inhaltsbeschreibungen.
Steht die Produktvision, werden die sogenannten Epics entwickelt. Darunter sind grobe Themenfelder und deren Hauptfunktionen zu verstehen.
Die Epics werden priorisiert und immer wieder um einzelne, in sich abgeschlossene Aufgabeneinheiten, den Userstories, ständig ergänzt. Dies geschieht zusammen mit dem Auftraggeber, der die Userstories immer wieder neu priorisiert und auch verändert.

Zudem werden die Userstories erst kurz vor Umsetzungsbeginn detaillierter ausgearbeitet. Dadurch fließen Erfahrungen der Anwender und Veränderungen der Anforderungen stetig in die Entwicklung. Die Umsetzung erfolgt in kleinen, in sich geschlossenen Zeitfenstern, den Sprints, die 1 bis 4 Wochen dauern. Eine initiale Analysephase ist relativ kurz. Mit dem ersten Sprint wird das Projekt produktiv und der Kunde erhält bereits nach dem Sprint ein auslieferbares Produkt anhand dessen auch sofort Funktionstests durchgeführt werden können.

Scrum ist ein Framework und stellt klare Regeln in der Zusammenarbeit auf. Dieses strikte Korsett gibt dem Teilnehmer jedoch die Freiheit, inhaltlich stets neu zu denken. Erfolgreich ist die Methode, wenn die Grundprinzipien einer erfolgreichen Entwicklung beachtet werden:
Das agile Manifest.

Agile Webprojekte bei öffentlichen Ausschreibungen

Agiles Arbeiten trotz starrem Vergaberecht

Will man die Vorteile einer agilen Entwicklung nutzen, wird weder ein Lastenheft noch ein Pflichtenheft erstellt. Und hier beginnen die Herausforderungen der öffentlichen Verwaltung, die sich an das jeweils gültige Vergabeverfahren halten muss.

Wie lässt sich demnach die Anforderung einer eindeutigen und erschöpfenden Leistungsbeschreibung mit agiler Vorgehensweise vereinbaren? Die Vergabe- und Vertragsordnung3 fordert ja eine genaue Beschreibung, da diese notwendig scheint, um allen Bewerbern die Beschreibung im gleichen Sinne vorlegen zu können, um vergleichbare Angebote zu erhalten. Und gleichzeitig wird geregelt, dass eine mögliche, wesentliche Vertragsänderung innerhalb der Vertragslaufzeit auch zu einer Neuausschreibungspflicht führen könnte. Was zeigt die Realität? Die meisten Preisangebote öffentlicher Ausschreibungen liegen in einer Bandbreite jenseits von Gut und Böse.

Das hehre Ziel der Vergleichbarkeit wird ad absurdum geführt, da unklare und ungenaue Spezifikationen, fehlende Unterlagen, das Wissen um Abweichungen und das Finden von Ausschreibungslücken zu gravierenden Preisunterschieden führen. Sie erinnern sich? Flughafen Berlin lässt grüßen!

Die Hürden, damit öffentliche Auftraggeber von agilen Methoden profitieren und dennoch das Vergaberecht einhalten sind hoch:

1. Genaue Beschreibung des Leistungsgegenstandes bei Vertragsbeginn und

2. Verpflichtung zur Nutzung des EVB-IT Vertrages. Doch es gibt Spielräume im Verfahren, die für die Ausschreibung eines agilen Softwareprojektes legitim genutzt werden können.

Grundregeln bei öffentlichen Ausschreibungen

Es liegt nicht allein am öffentlichen Auftraggeber, wenn Angebote erstellt werden, die sich nicht vergleichen lassen. Der Interessent hat eine aktive Mitwirkungspflicht, um die gewünschte Leistungsbeschreibung auch als Angebotsgrundlage zu erhalten.
Zwar sind Auftraggeber an das Vergaberecht gebunden, doch dies muss nicht bedeuten, dass ein komplexes Vergabeverfahren eine fachliche Auseinandersetzung während der Angebotsphase, ausschließt. Es gilt vielmehr, einige Grundregeln einzuhalten, um erfolgreich an einer öffentlichen Ausschreibung teilzunehmen.

Kommunikation ist gewünscht
Solange die Angebotsfrist nicht abgelaufen ist, sind Fragen nicht nur erlaubt, sondern auch erwünscht. Nach der Frist gibt es keine Chance mehr. Nur durch Nachfragen lassen sich Unklarheiten beseitigen und Anforderungen konkretisieren. Auftraggeber ändern nicht selten dann noch einmal Details der Ausschreibung. So lassen sich individuelle Aspekte einbringen, die dann auch als eigener Vorteil genutzt werden können.

Formalien sind obligatorisch
Genaues Lesen ist Pflicht. Wer Unterlagen nicht einreicht, die aber als Muss-Kriterien deklariert sind, scheidet aus! Wer Termine nicht einhält, scheidet aus! Wer Pflichtfelder nicht ausfüllt oder Unterschriften vergisst, scheidet aus! Ein Nachreichen oder Nachkorrigieren ist nicht zulässig. Die Vergabestelle alleine entscheidet, ob die Ausschreibungsunterlagen vollständig und rechtlich einwandfrei sind. Erst nach dieser Prüfung werden die akzeptierten Angebote an die jeweilige Fachabteilung weitergereicht.

Eigene Regeln führen zum Ausschluss
Die eigenen AGBs als möglichen Vertragsbestandteil einzufordern bedeutet den direkten K.O. Genauso erfolglos ist auch der Versuch, Vertragsbedingungen in Frage zu stellen oder gar abzuwandeln, sei es auch nur in einem marginalen Punkt. Ein Angebot ist immer verbindlich und bezieht sich auf die ausgeschriebenen Leistungen, inkl. aller Rahmenbedingungen. Hier helfen nur „Randbemerkungen“, die in einem späteren Vergabegespräch herangezogen werden können, die aber zum Zeitpunkt der Angebotsabgabe noch keine Rolle spielen dürfen.

Rüge als letztes Mittel
Und wenn dennoch der Wettbewerb den Zuschlag erhält? Im Dschungel der Einzelentscheidungen ist es fast unmöglich objektiv anfechtbare Tatbestände zu finden, die gegen eine Vergabe sprechen. Oder anders formuliert: Was nützt ein Widerspruch? Dies führt bestenfalls zu einer neuen Ausschreibung. Mehr Arbeit, die den Auftraggeber nicht unbedingt positiv Ihnen gegenüber stimmt. Dennoch kann es sich gerade bei EU-weiten Vergabeverfahren lohnen, Vergaberechtsverstöße innerhalb kürzester Frist als sogenannte Rüge anzumahnen. Dieser formale Weg ist Bedingung, um den vergabespezifischen Rechtsschutz in Anspruch zu nehmen, um sich gegen ungünstige Entscheidungen zu wehren.

Beratung öffentliche Hand bei Webrelaunch Ausschreibungen

Leistungsbeschreibung statt Produktbeschreibung

Am Anfang steht die Beratung und die Erarbeitung der Produktanforderung. Ein Auftraggeber kann hierfür als Dienstleistung Beratungskapazität einkaufen. Der Dienstleister schuldet hierbei keine definierte Funktionalität.
Bei diesen Beratungsleistungen ist agiles Vorgehen konform zum Vergaberecht. Der Auftraggeber kann die Anforderungen im Verlauf beliebig ändern.

Hierzu bedient er sich den Werkzeugen von Scrum und priorisiert als Product Owner (der ist für den fachlichen Erfolg des Projektes verantwortlich) alle Userstories. Es handelt sich hierbei allerdings im klassischen Sinne um einen Dienstvertrag. Der Auftraggeber ist somit allein für den Erfolg des Projektes verantwortlich.

Doch auch bei einem Werkvertrag sind Gestaltungsspielräume möglich. Zwar verlangt vor allem § 8 EG Absatz 1 VOL/A eine umfassende Leistungsbeschreibung, die alle Bewerber verstehen müssen, damit sie vergleichbare Offerten für das Werk anbieten können.

Jedoch verlangt das Gesetz lediglich eine genaue Beschreibung der Leistung und nicht die Beschreibung eines Produktes, das daraus zwingend hervorgeht. Somit geht die Legaldefinition nicht von einer abschließenden Leistungsbeschreibung aus. Vergaberechtlich reicht es aus, eine Softwareleistung funktional zu beschreiben, so dass Festpreisangebote abgegeben werden können. Zudem muss das agile Vorgehensmodell verbindlich festgeschrieben werden. Mit Hilfe eines Beraters erarbeitet der Auftraggeber seine Produktvision. Es werden Epics gebildet und Userstories formuliert um auch aufwendigere Funktionsbereiche ausreichend zu beschreiben. Diese Form der Leistungsbeschreibung tritt an die Stelle eines Lasten- und auch Pflichtenheftes. Es werden also nicht mehr detailliert technisch umzusetzende Funktionen beschrieben, sondern fachlich gewünschte Leistungsbestandteile. Die Art der Umsetzung spielt an dieser Stelle keine Rolle.

Diese Form der Beschreibung stellt somit die vergaberelevante Leistungsbeschreibung dar.

Scrum bietet auf dieser Datenbasis das Modell der Expertenschätzung. Diese Expertenschätzung ist letztendlich das agile Festpreisangebot mit dem der Dienstleister verspricht, die gewünschte Leistungsbeschreibung durch ein von ihm zu schaffendes Produkt umzusetzen.
Im Rahmen des Verhandlungsgespräches werden dann die scrumspezifischen Rahmenbedingungen wie Sprintlänge, Reviewmeetings, Risikovereinbarungen und Entscheidungswege bei Unklarheiten festgeschrieben.
Damit wird auch das Risiko einer vergaberechtlich relevanten Leistungsänderung mit der Gefahr einer Neuausschreibung minimiert. So ist sichergestellt, dass eine Detailfunktionsbeschreibung in die Entwicklungsphase verlagert werden kann.
Dies wird auch so vorab skizziert, dass an Stelle kostspieliger Change-Requests eine kontinuierliche Weiterentwicklung des Product Backlogs tritt. Veränderungen sind erwünscht und dieses Prinzip wird somit Vertragsbestandteil.
Die vertragliche Ausgestaltung kann ohne weiteres als Ergänzung zum EVB-IT Vertrag aufgenommen werden. Der sogenannte Agile Festpreisvertrag regelt dabei detailliert das gesamte agile Vorgehen.
In dem Buch von Andreas Opelt finden sich sehr gute Handlungsanleitungen, die auch für Auftraggeber der öffentlichen Hand genutzt werden können.

Fazit

Legitimiert der formal höhere Aufwand, im Sinne des Vergaberechts, dennoch agile Projekte? Eindeutig ja. Dem elementar höheren Nutzen erfolgreicher Scrumprojekte steht ein vergleichbar geringer Mehraufwand bei der Ausgestaltung der Ausschreibungsunterlagen gegenüber. Solange der Ausschreibungsprozess und die Projektumsetzung vergaberechtskonform erfolgt und die Projektsteuerung professionell begleitet wird, profitieren Auftraggeber von einem IT-Projekt das tatsächlich pünktlich und im Rahmen der vereinbarten Kosten funktionstüchtig abgeliefert wird

 

Internetagentur aus Leidenschaft

The People Who Do TPWD GmbH: die Internet- und Webdesign-Agentur mit Standorten in Berlin und Köln und wir sind in ganz Deutschland, Österreich und der Schweiz für Sie tätig. Mit dem entscheidenden Plus an Erfahrung, Leidenschaft und Professionalität – für Ihre Online-Projekte.