Jede Firma, jeder Entwickler und auch jeder Auftraggeber, der etwas mit Software zu tun hat, wird diese Situation kennen:

Könnten Sie noch das oder das oder das einbauen? Könnten Sie hier noch 1 Pixel nach oben schieben? Könnten Sie die Funktion bitte so machen, dass…

Diese Dialoge entstehen meist zum Ende des Projekts, nicht zu Beginn, wo sie zur korrekten Aufwandskalkulation richtig platziert wären, und sorgen für Unmut bei den Entwicklern. Das Grundproblem ist, dass der Auftraggeber oftmals unzureichend Verständnis von Art und Funktionsweise der Software hat und vermeintliche kleine Änderungen mitunter große Auswirkungen auf die Gesamtarchitektur haben. Grundsätzlich gilt für jedes Projekt das Paretoprinzip:

Pareto-Prinzip:
80% der Funktion können in 20% der Zeit erledigt werden. Die restlichen 20% beanspruchen allerdings noch mal 80% Zeit.
Pareto-Prinzip

In den ersten 20% der Arbeitszeit entsteht ein funktionierender Prototyp, die Aufgabe ist formal erfüllt, die Software funktionstüchtig. Die restliche Zeit kann man unter „Feinschliff“ zusammenfassen, welcher aber einen erheblichen Aufwand darstellt. Denn das Interesse des Entwicklers ist oftmals die Lösung des Problems, nicht das zentrieren irgendwelcher Buttons oder das Dokumentieren. Somit sinkt die Produktivität für die restlichen Aufgaben. Kommt dann noch die anfangs beschriebene Situation hinzu, dass der Auftraggeber „eigentlich etwas anderes meinte“ und noch mal hart etwas geändert werden muss, ist das ärgerlich.

Die Idee, was die Software/Funktion/Produkt können soll, wird oft auch erst vollständig durchdacht, wenn 80% erledigt sind und der funktionierende Prototyp „zum Anfassen“ da steht.

Wie also diese Herausforderung zur beidseitigen Zufriedenheit zwischen Auftraggeber & Auftragnehmer lösen?

Kumulative Aufwandskalkulation

Maik Pfingsten schlägt in seinem Zukunftsarchitekten Blog die kumulative Aufwandskalkulation vor, in welcher diese oben beschriebenen Faktoren etwas abgedämpft werden, indem man zur bilateralen Transparenz gleich im Angebot „darauf hinweist“, dass es die oben beschriebenen Phänomene gibt.

“Perfekt

Wie viel Aufwand wird benötigt, wenn alles ideal läuft?

Wenn kein Server kaputt geht, kein Kunde anruft, wenn alles perfekt ist?

“Realistisch

Was glaubst du – ohne mal zwei durch zwei – wird der Aufwand sein (wichtig: Aufwand nicht Dauer!)?

Aus Sicht des Entwicklers ist die Wahrscheinlichkeit, relativ gesehen, „eins“, das Problem zu lösen.

“Expertise“

Wie viel Berufserfahrung hast du? Wie gut kennst du dich mit der Materie aus?

1=Man kann nachts die Lösung runterbeten, wenn man geweckt wird.

10=Man hat einen fragenden Blick. Mit diesem wird der Aufwand multipliziert.

Mit diesen 3 Kennwerten kann man folgende Kurve darstellen:

Beispielhafte Aufwandskalkulation mit idealem Aufwand von 240h, geschätztem Aufwand von 960h und einer Unsicherheit von 6.

Beispielhafte Aufwandskalkulation mit idealem Aufwand von 240h, geschätztem Aufwand von 960h und einer Unsicherheit von 6.

Diese Aufwandskalkulation kann man nun integrieren und normieren, sodass folgende kumulative Aufwandskalkulation dabei entsteht.

Integrierte und normierte Aufwandskalkulation

Integrierte und normierte Aufwandskalkulation

Diese Darstellung zeigt nun auf eindrucksvolle Art und Weise, wie man sich tatsächlich den Aufwand vorstellen muss. Sowohl seitens des Auftraggebers als auch seitens des Auftragnehmers. Oftmals ist es nämlich so, dass die Motivation der beteiligten Entwickler zum Ende des Projets sinkt und erhöhte Incentives notwendig sind, um auf Top-Niveau weiter zu arbeiten.

Mittel zur Kommunikation

Die oben beschriebene Darstellung könnte man nun als Mittel zur Kommunikation direkt auch in Angeboten verwenden. Statt einer ausführlichen, in festen Zahlen definierten Angebotsvorlage, ergibt sich ein äußerst effektiver Gegenpart zu folgendem Phänomen: Man kann Softwareumfänge nicht absolut exakt in Worte fassen. Es gibt immer einen Spielraum, was mit dem Satz im Angebot nun gemeint ist. Bis zuletzt dahin, ob die Variable nun als int16 oder double geführt wird oder ob die Überschrift zentriert oder linksbündig zu erstellen ist.

Somit steht der relativ ungenauen Definition der Anforderungen auch ein relatives Angebot gegenüber. Nehmen wir einen Stundenlohn hinzu und beziehen wir die Pareto-Regel (die letzten 20% sind noch mal sehr intensiv!) mit ein, so ergibt sich folgende Darstellung.

Kalkuliertes Projektbudget mit kumulativer Aufwandsschätzung und Pareto-Regel

Kalkuliertes Projektbudget mit kumulativer Aufwandsschätzung und Pareto-Regel

Geht man also davon aus, dass bei 80% Projektfortschritt die Funktion tatsächlich so wie gefordert funktioniert, der Auftrag also formal erfüllt ist, dann sind die letzten 20% Zusatz, die der Auftraggeber natürlich umgesetzt haben kann, aber schon im Angebot eine entsprechende monetäre Bewertung der ganzen „kleinen Änderungen“ sieht.

Das ist fair und absolut offene Kommunikation!

Probleme

Leider gibt es bei dieser Art der Angebotslegung ein paar Probleme, welche natürlich bedacht werden müssen.

  • Wenn der Auftraggeber noch nie etwas vom Pareto-Prinzip, der 80/20-Regel, gehört hat, dann wird es schwer sein zu verstehen, was das ganze Spektakel überhaupt soll. Weiterhin ist auf den 1. Blick ja völlig unklar, weshalb jemand für 80% Fertigstellung überhaupt einen Auftrag auslösen sollte, schließlich soll es immer 100% funktionieren.
  • Weiterhin problematisch ist das sich hohe Projektbudget, was sich durch diese ehrliche Art der Kalkulation mit Unsicherheitsfaktor ergibt. Man läuft Gefahr viele Aufträge überhaupt nicht zu bekommen, schlicht weil die Summe so hoch erscheint.
  • Was trotz der etwas weicher gespülten Kalkulation der Kern bleibt: Der geschätzte Aufwand (siehe Punkt „Realistisch“). Liegt man hier daneben, kann man mit der kumulierten Aufwandskalkulation den Fehler zwar etwas abfedern, aber nicht aufheben.

Wie ist Ihre Meinung zu dieser Art der Angebotsabgabe? Ist das frech, ehrlich, zu idealistisch, offensiv, unpraktikabel? Welche Stolpersteine würden Sie bei dieser Vorgehensweise aus machen? Wir freuen uns über Feedback.

Download

Excel Template: Projektkalkulation

Mit der Vorlage können Sie ihre eigene kumulative Aufwandskalkulation berechnen. Die Datei steht unter CC BY-SA 3.0 DE Lizenz, d.h. Sie dürfen:

  • das Werk bzw. den Inhalt vervielfältigen, verbreiten und öffentlich zugänglich machen
  • Abwandlungen und Bearbeitungen des Werkes bzw. Inhaltes anfertigen
  • das Werk kommerziell nutzen

Allerdings unter folgenden Bedingungen:

  • Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. ('MechLab Engineering auf Grundlage von Maik Pfingsten')
  • Wenn Sie das lizenzierte Werk bzw. den lizenzierten Inhalt bearbeiten oder in anderer Weise erkennbar als Grundlage für eigenes Schaffen verwenden, dürfen Sie die daraufhin neu entstandenen Werke bzw. Inhalte nur unter Verwendung von Lizenzbedingungen weitergeben, die mit denen dieses Lizenzvertrages identisch oder vergleichbar sind.

Download