Entwicklung outsourcen: Nervenkrieg vs. agiler Festpreis

Mann der bei Festpreisrechnung ins Schwitzen gerät

Eine neue Software ist für viele Unternehmen ein Kraftakt. Das fängt mit dem Beschluss an, ein neues Projekt zu starten und hört bei der Überführung in den Live-Betrieb nicht auf. Mit dem outsourcen der Entwicklung kommen einige Barrieren dazu: Preismodell, Kommunikation und Vorgehen bei der Programmierung. Wir zeigen heute, welches Modell sich für wen am besten eignet und welche Punkte besonders beachtet werden müssen.

 

Auftraggeber und Auftragnehmer haben oft unterschiedliche Interessen

Ziel des Auftraggebers ist es, ein hochwertiges Produkt in kürzester Zeit zu einem akzeptablen Preis zu bekommen. Aus oberflächlicher Sicht böte sich an, von externen Dienstleistern Festpreiskalkulationen für das eigene Vorhaben anfertigen zu lassen und sich für den günstigsten zu entscheiden. Das Ziel für den Auftragnehmer ist ein positives Ergebnis und seine Ressourcen so zu nutzen, dass er damit am Markt ein gutes bis sehr gutes Ergebnis erreicht.
Somit haben beide Vertragspartner ein gemeinsames Ziel: Ein positives Ergebnis. Doch die anderen Positionen unterscheiden sich, woraus regelmäßig Probleme entstehen, die im Projektverlauf zu Konflikten anwachsen.

 

Der Klassiker: Festpreis und Change Requests

Viele Dienstleister haben sich auf die Strategie: „der Billigste bekommt den Auftrag“ eingestellt und liefern einen überschaubaren Grundpreis für die angefragte Software. Wählt ein Auftraggeber dieses Modell, sind die Qualität und Vollständigkeit der Anforderungen (Requirements) entscheidend für das Ergebnis.
Daher sollte man sehr erfahren sein, oder einen guten Berater für Requirements Engineering, für die Projektplanung und die Abnahme engagieren. Je detaillierter und durchdachter die Vorgaben, desto geringer die Abweichungen. Eine regelmäßige Kontrolle und Einsicht in den Stand des Projektes sind dabei unabdingbar. Als Auftraggeber sollte man bedenken, dass sich auch die eigenen Anforderungen an die Applikation ändern können, sobald man beginnt sie zu testen oder zu benutzen.
Ohne umfangreiche Erfahrung im Requirements Engeneering sind böse Überraschungen hier fast garantiert, denn der reale Projektpreis liegt  meist um ein vielfaches höher als der erste Angebotspreis. Das Geheimnis des günstigen Angebotes liegt in den notwendigen change requests, mit denen die Dienstleister den eigentlichen Gewinn machen müssen. Logischerweise verzögern diese notwendigen Änderungen auch den Projektabschluss gewaltig. Doch ohne die Änderungen wird die angefragte Applikation nie einen produktiven Status erreichen. Der Auftraggeber hat das Gefühl, das Projekt sei immer „fast fertig“, ohne die Zielgerade zu überqueren. Er ist dem Auftragnehmer quasi ausgeliefert, wenn sein Projekt zum Abschluss kommen soll. Die Folge ist oft ein zerrüttetes Verhältnis zwischen beiden Vertragsparteien. Der Aufpreis an Zeit, Geld und Nerven ist bei dem preiswerten Festpreismodell also im Nachhinein häufig immens.

 

Der Gelddruckautomat: Time and Money

Egal ob der Dienstleister Arbeitskräfte abstellt oder man sich ein eigenes Team aus Freelancern zusammen stellt – die Bezahlung nach Stunden ist ein klares Prinzip: Auftragnehmer lieben es und Freelancer sind selten bereit zu anderen Konditionen zu arbeiten. Gleichzeitig bietet es wenig Planungssicherheit für den Auftraggeber. Bis das Produkt wirklich produktiv ist, fließt in jedem Fall Geld. Da die Mitarbeiter häufig inhouse arbeiten, hat man als Auftraggeber hat man dabei zwar gefühlt mehr Kontrolle, aber im Regelfall ist man auch an allen Verzögerungen selbst schuld.
Ein weiterer entscheidender Nachteil ist, dass die Projektsteuerung vom Auftraggeber selbst zu leisten ist. Dies beginnt mit der Auswahl der richtigen Mitarbeiter. Nicht immer ist die benötigte technische Kompetenz schon vor Ort vorhanden. Also müssen schnell neue Leute eingestellt werden, deren Fähigkeiten und Verhalten man nur schwer einschätzen kann. Bei secu-ring stellen wir beispielsweise keinen Programmierer ein, der nicht unseren Einstellungstest und eine umfangreiche Codereview mit Bravour bestanden hat: Davon reden bestimmte Dinge zu können und sie beweisen zu müssen, macht einen entscheidenden Unterschied.
Auch im Time and Money Modell arbeiten Auftraggeber und Auftragnehmer tendenziell eher gegeneinander. Es besteht ein grundlegender Fehlanreiz: Lange Arbeitszeit wird besser bezahlt, als Effizienz. Darüber hinaus haben die Projektmitarbeiter selten umfangreichen Zugriff auf andere Ressourcen. So fehlen häufig Kontakte zu erfahrene Entwicklerkollegen aus anderen Projekten, die mit kompetenter Hilfe und outside-of-the-box-Denken aushelfen könnten. Doch gerade der Austausch zwischen verschiedenen Projekten hilft nicht nur den Mitarbeitern, sondern kommt im Regelfall allen Kunden eines Dienstleisters zu Gute.
Grundsätzlich sollte man sich die Frage stellen, ob man die gesamte Verantwortung für Scheitern und Gelingen des Projektes alleine tragen möchte.

 

Die Problematik: Das QTK-Dreieck

Product Owner der sich zwischen Kosten, Termin und Qualität entscheiden muss

Das magische Dreieck: Jeder kennt es und fast jeder ist sich der grundsätzlichen Implikationen bewusst: Man kann sich nur für zwei Ecken des Dreiecks entscheiden, nie für alle drei.
Dennoch gibt es immer wieder die Hoffnung, dass es bei dem eigenen Projekt doch möglich wird. Der Vertrieb von Softwaredienstleistern wird auch im Jahr 2015 nicht müde zu behaupten, dass die eigene Firma genau dieses Kunststück zu vollbringen vermag. Aber Hand aufs Herz: Man muss sich für zwei Ecken entscheiden und akzeptieren, dass die andere dadurch nicht den gleichen Wert beigemessen bekommt. Wird diese Entscheidung nicht bewusst am Anfang getroffen, ist die Enttäuschung unvermeidbar.

 

Agiler Festpreis: Vertrauen und gemeinsame Ziele setzen

Ein sinnvoller Ansatz, die oben genannten Problematiken aufzulösen oder zu reduzieren, ist der sogenannte agile Festpreis. Ziel ist dabei, Planungssicherheit für beide Seiten zu erzeugen und dennoch die Flexibilität für Änderungen hoch zu halten. Dafür wird vor dem Start ein Gesamtpaket definiert und taxiert. Im Laufe des Projektes können, wenn es das Feedback notwendig macht, gleichwertige Features ohne Mehrkosten ausgetauscht werden. Üblicherweise wird bei diesem Modell auch mit agilen Methoden wie Scrum oder Kanban gearbeitet. Dank deren kurzer Feedbackzyklen entsteht eine beständige Übersicht über den Projektstand, wie auch neue Ideen und Änderungswünsche. Im Gegensatz zum klassischen Festpreis nach Lastenheft, lassen sich diese aber gut integrieren.
Das Einhalten des initialen Preises ist auch bei diesem Vorgehen nicht unbedingt garantiert: Erfahrungsgemäß ist auch hier der Umfang am Ende meist größer als der, der anfangs vereinbart wurde. Gleichzeitig behält der Auftraggeber aber eine hohe Flexibilität und der Dienstleister trägt das unternehmerische Risiko für das Gelingen und die Kosten der Umsetzung der jeweiligen Anforderung. Eine weiterer Vorteil ergibt sich aus der Taxierung von einzelnen Anforderungen, welche eine Kosten – Nutzen Rechnung für jede Anforderung und damit den Vergleich ermöglicht. So brauchen nur Anforderungen umgesetzt werden, deren Business Value höher ist als dessen Kosten.
Auch wenn der agile Festpreis vordergründig für den Auftraggeber Vorteile zu bieten scheint, verdient auch der Auftragnehmer Geld. Genauso wichtig wie die Bezahlung ist jedoch die Zufriedenheit für Dienstleister und Kunden. Sie ist eine grundlegende Voraussetzung für Vertrauen und damit eine langfristige Zusammenarbeit, die sich für beide Vertragspartner positiv auswirkt: Gerade mit dem nötigen Vertrauen ist es auch möglich, Projekte zu beginnen, bei denen noch nicht jede Anforderung im Detail spezifiziert ist. Getreu den Prinzipien des Lean Management erspart dies die Spezifikation von Dingen, die erst zu einem späteren Zeitpunkt und dann auch meist anders als geplant umgesetzt werden.

 

Fazit: Anforderungen müssen spezifiziert werden

Der agile Festpreis ist in den meisten Fällen der erfolgversprechende Weg für die Entwicklung einer langfristig erfolgreiche Software oder Webapplikation. Aber auch hier ist es wichtig, einen Dienstleister zu finden, der einen beim Requirements Engineering kompetent unterstützen kann. Denn wie auch in allen anderen Modellen ist Requirements Engineering nicht alles, aber ohne gutes Anforderungsmanagement ist eine erfolgreiche Entwicklung der gewünschten Software äußerst unwahrscheinlich.

Was sind Eure Erfahrungen für die Zusammenarbeit? Mit welchen Konzepten/ Vertragsarten arbeitet Ihr mit Euren Dienstleistern oder Kunden zusammen?

 

Urheber Coverbild: inueng / 123RF Lizenzfreie Bilder

About Olaf Stichtenoth

Olaf Stichtenoth ist Gründer und CEO der secu-ring GmbH. Er ist Experte für die erfolgreiche Realisierung digitaler Lösungen. Sein Hauptinteresse liegt in der Verbindung von Digitalisierung und Optimierung von Geschäftsprozessen. Dabei verfolgt er grundlegend den Gedanken der Reduktion und der Schnelligkeit. Dazu sagt er selbst: "Beschränkung und Erprobung wird auf Grund der besseren Kostenbilanz der Planung, Erstellung und dem Ausrollen auf lange Sicht den Rang ablaufen."

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.