Kumulative Aufwandskalkulation als Mittel zur Kommunikation

Sie befinden sich hier: ://Kumulative Aufwandskalkulation als Mittel zur Kommunikation

Kumulative Aufwandskalkulation als Mittel zur Kommunikation

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.

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

Wenn kein Server kaputt geht, kein Kunde anruft, wenn alles perfekt ist?[/fusion_content_box]

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.[/fusion_content_box]

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.[/fusion_content_box]

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

5 Comments

  1. Suther 02.08.2013 at 11:57 - Reply

    Sehr interessanter Artikel. Vielen Dank dafür.

    Ich nutze LibreOffice. Das Dokument wird richtig dargestellt. Einzig, das oberste Diagramm wird nicht dargestellt, weil der Y-Datenbereich fehlt.
    Was müsste in diesem Feld eingetragen werden, um dort im ersten Diagramm eine Ausgabe zu erhalten?

  2. Paul Balzer 03.08.2013 at 07:20 - Reply

    Hallo Suther,
    dort muss einfach eine Linie zwischen Nano-Prozent Wert [240; 0], dem erwarteten Wert [960; 1] und erwarteter Wert*Unsicherheitsfaktor [960*6; 0] hin.
    Viel Erfolg

  3. Christoph 14.05.2014 at 20:25 - Reply

    Hallo,

    Vielen Dank für die nette Vorlage.
    Aus meiner Sicht ist die Methode von Maik Pfingsten jedoch nicht korrekt umgesetzt,
    da es bei Ihrer Umsetzung zu sehr hohen Aufwänden bei größeren Unsicherheitsfaktoren kommt.
    In der Beschreibung von Maik wird der Worst Case mittels Nano-Prozent-Wert x Unsicherheitsfaktor berechnet, was allerdings dazu führen kann, dass Worst und Best Case gleich sind.

    Aus meiner Sicht wäre eine Berechnung mit der folgenden Gleichung besser:
    Worst Case = Erwartungswert + Nano-Prozent-Wert x Unsicherheitsfaktor [1..10]

    Ich habe mir das Excel-Sheet entsprechend angepasst und werde mal die ersten Erfahrungen damit sammeln.

    Gruß,
    Christoph

    • Paul Balzer 15.05.2014 at 07:46 - Reply

      Hallo Christoph,
      vielen Dank für den Hinweis! Das scheint tatsächlich sinnvoller. Ich habe die Excel Tabelle ebenfalls geändert und entsprechend deines Hinweises angepasst. Ich würde mich über Rückmeldungen freuen, ob das Pi*Daumen hin gehauen hat. Wir hatten bisher immer so kleine Unsicherheitsfaktoren, dass es nicht aufgefallen war. 🙂
      Grüße!

      • Thomas 19.05.2017 at 11:28 - Reply

        Hallo,

        ich stimme Herrn Christoph nicht zu. Wenn der Risikofaktor eins ist, muss der Worst Case dem Best Case entsprechen. Dafür steht der Faktor 1. Nach der nun von Ihnen angepassten Formel kann der selber geschätzte Wert nie einen Eintrittswahrscheinlichkeit von 80% erreichen (was ja bei der eigenen Schätzung wenn man gut schätzt das Ziel wäre) und führt zu einer künstlichen Erhöhung des Risikos.

        Gruß,
        Thomas

Leave A Comment