Der leidige Risikoaufschlag

Published by Tobias Hofmann on

5 min read

Einmal kam eine Projektanfrage in meine Inbox. Es ging um die Aufwandsschätzung für ein neues Projekt. Frühes Stadium. Der Kunde hatte gerade erst seinen Schmerz als Bitte formuliert. Er hatte sich von einem doch recht großen Softwarehaus eine eigene Lösung für die Bearbeitung von Meldungen erstellen lassen. Diese Lösung sollte aus verschiedenen Gründen abgelöst werden, am besten komplett mit SAP-Technologie, etwas Cloud, UI5 für das Frontend.

Der Start

Was war die Motivation? Die bestehende Lösung war vom anderen Softwarehaus / Beraterhaus komplett eigen entwickelt worden, mit DB, Middleware und Frontend und ein wahres Monstrum an verwendeten Technologien. Egal ob Angular, React, vanilla JavaScript HTML, Node.js, Java, C#, unterschiedliche Datenbanken, es war alles dabei. Dabei war ursprünglich angedacht gewesen alles in SAP zu integrieren und so viel SAP-Technologie zu verwenden wie möglich. Irgendwo war das Projekt aber falsch abgebogen. Auf jeden Fall war der Kunde nicht mehr glücklich damit und wollte weg davon. Allein der Aufwand für die Wartung und Weiterentwicklung überstieg die initiale Planung bei weitem. Da der Vertrag mit dem Verursacher dem Ende entgegen ging und man nicht eine Verlängerung vereinbaren wollte, wurde eine Alternative gesucht.

In den initialen Gesprächen waren die Rahmenbedingungen schnell geklärt. Die ungewünschte Supportverlängerung stand in einigen Monate an. Bis dahin musste die finale Entscheidung ob eine neue Lösung live geht stehen. Also nicht nur, ob diese in Auftrag gegeben wird, sondern ob diese auch eingesetzt werden kann. Damit war der maximale zeitliche Rahmen für die Entwicklung, Test und Abnahme gesetzt: etwa 9 Monate. Vom Funktionsumfang her ergab eine genauere Analyse das etwa 50+% mit SAP Standard gelöst werden können. Zusammen mit dem Kunden und weiteren Experten kamen wir zu dem Ergebnis, das der gesamte Aufwand für die Apps sich im Rahmen halten sollte: etwa 800 PT. Bei der Analyse war der Kunde auch erleichtert als der Aufwand besprochen wurde. Denn: Budget war genügend da, aber für die Rechtfertigung Pro-Neuentwicklung gab es die Vorgabe nicht mehr als 1.500 PT zu veranschlagen (fixer Tagessatz). Bei mehr würde die Entscheidung für die Wartungsverlängerung ausfallen.

Diese Zahl gaben wir weiter an die interne Projektplanung. 800 PT veranschlagt, der Kunde hatte als absolute Schmerzgrenze 1.500 PT, selbst mit zusätzlichem Puffer sollte das klappen. Mit einem weiteren Risikoaufschlag oder weiteren Leuten sollte es kein Problem sein ein ganzes Team für 9 Monate mit Arbeit zu versorgen. Wir dachten das es kein Problem sein sollte. 100% Aufschlag? Unmöglich.

Wir lagen falsch.

Die Planung

Die Projektplanung setzte sich in Kontakt mit unseren Managern. Und ja, die, die bei der Planung dabei waren, waren erst mal raus aus der Planung. Die Manager übernahmen. Und leider wussten auch die Manager von der magischen Zahl 1.500, hatten diese aber komplett falsch interpretiert und ließen sich davon auch nicht mehr belehren. Die 1.500 wurde als ein Richtwert für die reine Entwicklung gesehen, d.h. 1.500 PT in 9 Monaten nur für die Entwicklung. Die Manager sahen hier die Gelegenheit ein ganzes Team zu parken. Am besten noch Leute kurzfristig für eventuell 5 PT im Monat auf das Projekt buchen zu lassen, um die Forecast- und Buchungsquote zu erfüllen. Hier kollidierten nun zwei Welten. Die Analyse wurde auf Basis der Anforderung erstellt und kam auf 800 PT, unabhängig vom Wissen über die Schmerzgrenze. Die Analyse des Managements ging von der Fehlinterpretation der Schmerzgrenze aus und war rein auf Buchungsquote basiert. Also: wie viele Leute kann ich unterbringen um bei etwa (!) 1.500 PT zu sein? Der mehrmals angebrachte Hinweis das man ein Projekt auf die Kundenanforderungen ausrichten muss und nicht auf die eigenen Ziele wurde ebenso mehrfach ignoriert. Ebenso die Richtigstellung der Zahl 1.500. Wie der Untergang der Titanic wurde der Projektuntergang dadurch noch beschleunigt das die Manager davon überzeugt waren zu wissen was sie tun. Sie sind ja Manager, Projektabwicklung ist ihre tägliche Aufgabe. Und so wurde dann der reine Entwicklungsaufwand mit 1.500 PT an die nächste Stelle eingereicht. Diese fügte dann noch den Projektaufschlag dazu (also mehr als ein Projektleiter, Outsourcing, Koordinierung, Testen, Dokumentation, etc.). Und dann ging das ganze noch zur Risikobewertung wo nochmals 40+% draufgeschlagen wurden. Die Antwort auf die Frage warum über 40% Risikoaufschlag wurde mit „mach ich in dem Land immer so“ beantwortet.

Der Untergang

Der Kunde lachte höflich als der Aufwand und die Kosten präsentiert wurden. Der Zeitrahmen von 9 Monaten war natürlich komplett überzogen, die PT und Kosten ausreichend, um die bestehende Lösung doch noch für etliche Jahre zu pflegen. Die Reaktion der Verantwortlichen beim Kunden war auch klar: warum laden wir euch ein die Lösung zu analysieren, sind ehrlich und ihr verschwendet unsere Zeit? Und ja, diese Tür wurde auf lange, lange Zeit geschlossen. Und die Manager? Tja, die verstanden die Welt nicht und fragten noch Wochen danach nach warum denn der Vertrag nicht unterschrieben ist. Und als dann wirklich jeder verstanden hatte das da nichts kommt und ein so schönes Projekt für die Buchungsquote und Leute zu parken nicht stattfindet, ratet mal wer schuld war? Keiner! Der Risikoaufschlag? Natürlich nicht! Die Manager! Natürlich nicht? Verkauf? Die 30. Person auf der warum-auch-immer-stetig angewachsenen Mailingliste? Nein!

Was kann man hier lernen?

Gier frisst Hirn. Anstatt froh zu sein ein doch recht entspanntes Projekt zu haben das einige Leute für etliche Monate auslastet, nein, es musste mehr sein. Es mussten mehr Leute sein, mehr PT, mehr Aufwand.

Egoismus vernichtet Projekte. Jeder Manager wollte seine Leute auf dem Projekt haben, seinen Forecast optimieren, seine Team-Buchungsquote bei 100% haben.

Arroganz und Ignoranz vergrault Kunden. Wer auch die einfachsten Dinge, die der Kunde einem sagt, ignoriert und den Leuten vor den Kopf stößt, da man es ja besser weiß: irgendwann haben die Leute auf Kundenseite keine Lust mehr. Und dann wird man nicht mehr gerufen, nicht mehr gefragt und eingeladen.

Let the world know
Categories: Technology

Tobias Hofmann

Doing stuff with SAP since 1998. Open, web, UX, cloud. I am not a Basis guy, but very knowledgeable about Basis stuff, as it's the foundation of everything I do (DevOps). Performance is king, and unit tests is something I actually do. Developing HTML5 apps when HTML5 wasn't around. HCP/SCP user since 2012, NetWeaver since 2002, ABAP since 1998.

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.