Festpreisprojekte scheitern an ihrer DNA

Softwareprojekte auf Festpreisbasis misslingen nicht wegen der Technik, sondern wegen der Projektorganisation. Sie können nichts dafür. Sie scheitern an ihrem eigenen Wesen.

Gerne wird argumentiert, dass misslungene Projekte nicht scheitern, wenn alle Beteiligten einen Standard XYZ beachten oder ein ordentliches Projektmanagement-Tooling konsequent einsetzen.

Doch das ist größtenteils Quatsch.

Natürlich sind richtige Tools im Projekt enorm hilfreich. Standards erweisen sich als sinnvoll. Alles zusammen ist schön und gut, und es hilft auch – vorausgesetzt, das Projekt hat die richtige DNA. Doch das ist bei Festpreisprojekten selten der Fall. Der typische Ansatz ist nämlich der folgende:

1. Der Kunde stellt fest, dass er neue Software braucht, die er auf dem Markt nicht bekommt und somit entwickeln lassen muss.
2. Da im eigenen Hause die notwendige IT-Kompetenz fehlt, wird ein externer Lieferant gefunden.
3. Es wird mit dem Lieferanten ein Festpreis ausgemacht.
4. Das Projekt läuft gut an.
5. Das Projekt scheitert vollends in einer späteren Phase.

Woran liegt das? Die Projektveranlagung besteht aus widersprüchlichen Genen. Etwas überspitzt formuliert gestaltet sich das so:

• Der Kunde denkt, dass er einen Dummen gefunden habe, der billiger als andere das Richtige liefert.
• Der Lieferant denkt, dass er eine ahnungslose Melkkuh gefunden habe.

Natürlich predigen alle Fairness und Zufriedenheit unter den Beteiligten, aber das ist oft lediglich Teil des üblichen Projektrituals. Projekt-Outsourcing (noch schöner: -Offshoring) ist nämlich theoretisch eine tolle Sache, doch bei Großprojekten ist Ehrlichkeit Mangelware, und somit entfällt die elementare Grundlage für ein erfolgreich extern umgesetztes Festpreisprojekt.

Es geht schief, was schiefgehen muss

Die erste Projektphase gestaltet sich ja noch optimal, der Lieferant tut praktisch alles, worum er gebeten wird. Man will ja die Abhängigkeit weitgehend festigen, und der Kunde ist oft naiv genug zu glauben, dass das so weitergehen werde.

Doch später gewöhnt sich der Lieferant an seine fette Wurst und beginnt, sein Verhalten zu verändern. Auch der Kunde merkt allmählich, was er WIRKLICH braucht, und stellt weitere Forderungen. Gespräche laufen dann nach dem folgenden Prinzip:

• Kunde: „Wir brauchen Feature XYZ.“ (Übersetzung: „Warum hat der Lieferant das nicht selbst gesehen?“)
• Lieferant: „Das ist ein sinnloses Feature.“ (Übersetzung: „Das steht nicht im Lastenheft.“)
• Kunde: „Wir benötigen das aber.“ (Übersetzung: „Das ist doch offensichtlich!“)
• Lieferant: „Das ist technisch nicht machbar.“ (Übersetzung: „Das wollen wir nicht machen, es sei denn, es wird uns dafür ein Vermögen gezahlt.“)

Festpreisprojekte haben dieses Problem ab einer gewissen Größe, und es gibt wenig Hoffnung, dass sich das ändert. Weder agile Ansätze (die der Festpreisnatur eines Projekts widersprechen) noch strenge Standards (die die Kosten in die Höhe treiben) konnten bisher entschieden helfen.

Kunden folgen bei Festpreisprojekten der folgenden Argumentation:

„Wir liefern doch auch Produkte XYZ (Betondecken, Einbauküchen, Fenster etc.) nach Leistungsbeschreibung X, und es klappt ja hervorragend. Bei Software muss es auch so gehen. Das kann doch nicht soooo schwer sein!“

Es ist aber so schwer. Software ist vielleicht das komplizierteste, unüberschaubarste, schwierigste Produkt, das man auf Bestellung kaufen kann. Software ist dermaßen absurd komplex, dass dies einem Außenstehenden nicht näherzubringen ist.

Festpreisprojekte können funktionieren (ernsthaft)

Es geht auch anders. Dabei meine ich nicht den „agilen Festpreis“ oder ähnliche Versuche, die Natur auszutricksen. Wichtig ist nicht die Welche-auch-immer-Methodik, sondern die Qualität der Lieferanten-Kunden-Beziehung. Speziell in der Automobilindustrie funktionieren Festpreisprojekte nach einem bestimmten Muster. Da werden Zulieferer, die nicht selten extrem komplexe Systeme mit Software, Elektronik und Mechanik entwickeln, an die sehr kurze Leine genommen. Für die Laufzeit ihres Projektes werden die beteiligten Lieferantenmitarbeiter praktisch zur internen Abteilung des Automobilherstellers. Nichts passiert ohne Kundenzustimmung, weder Designanpassungen noch Änderungen im Team, und schon gar nicht Anpassungen am Projekt-Scope. Zugleich werden Zulieferer mit einer irrsinnigen Menge an Anforderungen konfrontiert, denn neben dem Lastenheft müssen sie abertausende Seiten Konzern- und Industriestandards befolgen.

Unter solchen Umständen geht es oft gut mit dem Festpreis-Entwicklungsprojekt. Es ist natürlich zu beachten, dass der Zulieferer nur teilweise seine Entwicklungskosten direkt erstattet bekommt. Er wird nämlich am Umsatz beteiligt (seine Teile werden in Fahrzeugen explizit mitverkauft), es besteht also ein Eigeninteresse an der Qualität der zu liefernden Komponenten.

Was aber tun, wenn man seine Lieferanten nicht in der Tasche hat?

Was sich große Automobilhersteller leisten können, das geht bei vielen anderen nicht. Erstens fehlt da die Eigenkompetenz im Softwarebau, und zweitens sind insbesondere im Mittelstand die Lieferanten schnell größer als ihre Kunden, oder zumindest können sie die für Festpreisprojekte charakteristische Abhängigkeit in (Nach-)Verhandlungen zu ihren Gunsten besser nutzen.

Wie beim Hausbau heißt es: Wenn man von der Materie keine Ahnung hat, dann sollte man jemanden anheuern, der das kann, und das Projekt NICHT per Festpreis, sondern nach Aufwand durchführen. Das ist speziell bei unternehmenskritischen Kernanwendungen sinnvoll. Dabei darf es sich bei dem Experten nicht um eine einzelne externe Organisation handeln, die alle erforderlichen Projektmanager, Entwickler, Tester etc. zur Verfügung stellt. Damit würde sich der Kunde in eine folgenschwere Abhängigkeit begeben. Es muss stattdessen eine unabhängige Person sein, die noch am besten am Projekterfolg direkt oder indirekt beteiligt ist. Dann gilt es, weitere Experten einzeln „nach dem Nasenprinzip“ einzukaufen, ins Team zu integrieren und das Projekt nach allen Regeln der Kunst durchzumanagen.

Oft schrecken Kunden vor diesem Ansatz zurück, denn er bedeutet, dass man einer Einzelperson vertrauen muss, und außerdem fürchten sie, dass das Projekt „ein Fass ohne Boden“ werden könnte. Doch die Praxis zeigt, dass man sich in die Tasche lügt, wenn man bei einem externen Dienstleister eine andere Erwartungshaltung entwickelt.

Illusionen darf man sich keine machen: Ein Softwareprojekt stellt immer eine enorme Anstrengung dar. Wer frei nach dem Spruch „Das kann doch nicht so schwer sein“ handelt, der lebt auf einem fernen Planeten. Entwicklungsprojekte sind immer mit einem hohen Risiko behaftet – auch deshalb machen sie ja so viel Spaß! Vorausgesetzt, am Ende wird das Projekt von Erfolg gekrönt. Und es wird erfolgreich, wenn es dazu von Geburt an richtig veranlagt ist.