Zusammenarbeit mit dem Kunden ist wichtiger als Verträge!
Das ist einer der vier Leitsätze des Agilen Manifests. Aber ein Projekt mit externer Beteiligung ohne Verträge zu starten ist wohl keine Lösung. Beim Abschluss von Verträgen können schon die Weichen für das Scheitern eines Projektes gestellt werden. Oft sind es gerade perfekt erscheinende Verträge, die für nachfolgende Probleme verantwortlich sind.
In einem großartigen Buch über Industrielle Megaprojekte nennt der Autor 7 typische Ursachen für das Scheitern solcher Projekte, davon haben 3 direkt mit den Verträgen zu tun.
Grund Nr. 1: Vereinbarungen, die nicht fair gegenüber allen Stakeholdern sind
Ich habe ein Großprojekt im öffentlichen Sektor in der Vergabephase begleitet und musste mit ansehen, wie die Vertragsbedingungen immer mehr den Charakter eines Knebelvertrages annahmen. Der siegreiche Anbieter wusste beim Zuschlag nicht, ob er Grund zum Feiern habe. Das Projekt endete auch in einem Fiasko, schließlich wurde es mit einem anderen Anbieter auf Basis einer Aufwandsverrechnung (getarnt durch wirkungslose und mehrfach korrigierte Preisdeckelungen) neu aufgesetzt und fertiggestellt. Das hätte man für alle Beteiligten billiger und schneller haben können, wenn man den Juristen rechtzeitig in den Arm gefallen wäre.
Grund Nr. 2: Das Budget wird willkürlich gekürzt
Wenn Einkaufsabteilungen ins Spiel kommen, so muss ein „Einkaufserfolg“ dargestellt werden und das ist am sichtbarsten und am einfachsten eine Kürzung des ursprünglichen Preises. Ein unrealistisches Budget rächt sich unweigerlich und am Ende wird es teurer als es gewesen wäre, wenn man die seriös geschätzten Zahlen belassen hätte. Das ist leicht gesagt, aber schwer durchgesetzt. Man läuft in größeren Unternehmen mit offenen Augen in das immer gleiche Problem und nur ein starkes, sachverständiges Top-Management kann das verhindern. Andernfalls grüßt täglich das Murmeltier und es werden zuerst aggressiv die Kosten reduziert um diese dann mit Change Requests wieder in die Höhe zu treiben.
Grund Nr. 3: Überwälzung des Risikos auf den Lieferanten
Es klingt ja so logisch, dass der das Risiko tragen soll, der den Hauptteil der Arbeiten ausführt. Merrow zeigt ausführlich, dass dies allein schon wirtschaftlich unmöglich ist. Ein Dienstleistungsunternehmen (das sind Berater und Softwareunternehmen) hat keine großen Vermögenswerte, um Risiken zu verkraften, die z.B. eine Bank, eine Versicherung oder ein Ministerium mit einem Projekt eingeht. Wenn der Lieferant eine Gewinnmarge von z.B. 10 % des Umsatzes hat, ist offensichtlich, dass er nicht Aufwandsüberschreitungen von z.B. 50 % tragen kann. Es ist auch nicht gerechtfertigt, denn die Ursache für solche Aufwandsüberschreitungen liegen so gut wie immer vor allem beim Auftraggeber (siehe Grund Nr. 1 und Nr. 2).
Das Buch von Merrow bietet noch einige weitere interessante und wichtige Einsichten, ich habe eine Kurzfassung davon in diesem Blogpost gegeben, dort ist auch der Link zum Buch für alle, die sich näher damit beschäftigen wollen.
Soweit der analytische Teil zu den Ursachen des Scheiterns. Das hilft zwar, aber ist nur die halbe Miete. Wie macht man es besser?
Bei klassischen Werkverträgen einfach, indem man die von Merrow genannten Probleme vermeidet. Wenn man aber ein Softwareentwicklungsprojekt agil abwickelt, kommen noch einige spezifische Punkte dazu. Das habe ich in meinem Blogpost „Die Vertragsphilosophie agiler Projekte“ zusammengefasst.
Ich möchte hier nur einen zentralen Punkt hervorheben, den ich in allen Diskussionen zu diesem Thema vermisse. Entscheidend ist, ob man die Aufwände des Vertragspartners als angemessen empfindet. Das heißt, dass ich ihm weder Unehrlichkeit unterstelle (es werden Aufwände verrechnet, die gar nicht entstanden sind) noch Ineffizienz (er braucht einfach zu lange, weil die Skills fehlen oder er schlecht organisiert ist). Wenn diese beiden Bedenken nicht bestehen, ist eine Verrechnung nach Aufwand (Time&Material) die einfachste und sparsamste Lösung. Nun ist grenzenloses Vertrauen kein Zugang, den eine Rechtsabteilung unterstützen kann. Daher braucht es Sicherheitsmechanismen, um im Falle des Falles eingreifen zu können. Auch dafür gibt es Lösungen in Form von im Voraus vereinbarten Schlichtungsmechanismen. Und wenn es hier trotzdem zu unüberbrückbaren Differenzen kommt, gibt es nur zwei Möglichkeiten für den Auftraggeber: den Auftragnehmer wechseln oder, wenn das nicht geht, die überhöhten Aufwände in Kauf nehmen und den Auftragnehmer bei der nächsten sich bietenden Gelegenheit loswerden. Ein Wundermittel weiß ich leider nicht und ich glaube auch, dass es keines gibt.
Etwas mehr zu Verträgen in agilen Projekten habe ich in meinem Blogpost „Agil ist erfolgreicher als Wasserfall! Mag sein, aber was sagt die Rechtsabteilung dazu?“ dargestellt. Dort gibt es auch Literaturempfehlungen und Links zu den relevanten agilen Ansätzen, denn es gibt mehr als nur Scrum. Dort gibt es auch einen Link zum Chaos-Report der Standish Group, die explizit feststellt, dass agile Projekte eine 4-mal höhere Erfolgsrate haben als solche nach dem Wasserfallmodell. Agil ist keineswegs eine Erfolgsgarantie, die gibt es einfach nicht, aber ein Erfolgsfaktor, den man intelligent nutzen sollte. Das ist vor allem eine Sache für die Auftraggeber von Projekten. „Kein Projektmanager kann in vielen langen Arbeitstagen soviel falsch oder richtig machen wie es Projektauftraggeber innerhalb von Minuten ganz nebenbei schaffen“, das ist der zentrale Satz in meinem kurzen Blogpost zum Thema „Projekte und ihre Auftraggeber“.
Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).
Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.