in Agilität, Aufwandsschätzung, Planung

Die Heisenberg’sche Unschärferelation gilt auch für Aufwandsschätzungen in IT-Projekten

Was hat Physik mit Aufwandsschätzungen in IT-Projekten zu tun? Wieder so ein absurder Vergleich, um Leser anzulocken? Ja, natürlich soll der Titel Neugier wecken, aber es gibt wirklich eine starke Analogie, die für die Praxis nützlich ist.

Zunächst die Unschärferelation im Original: Zwei komplementäre Eigenschaften eines Teilchens sind nicht gleichzeitig beliebig genau bestimmbar. Die Unschärferelation ist nicht die Folge technisch unzulänglicher Messverfahren und damit tendenziell behebbar, sondern sie ist prinzipieller Natur. Anders formuliert: die Messung des Impulses eines Teilchens ist zwangsläufig mit einer Störung seines Ortes verbunden, und umgekehrt. Andere Eigenschaften, die hier betroffen sein können, sind z.B. Energie und Zeit.

Ein IT-Projekt ist – wie jedes Projekt – durch Ergebnis, Budget und Termin definiert. Manchmal wird dieses „magische Dreieck“ noch durch andere Parameter ergänzt, so z.B. Qualität. Meiner Meinung nach bringen solche Erweiterungen keinen Zusatznutzen, die angeführte Qualität ist z.B. ein Aspekt des Ergebnisses. Auch die Standish Group definiert den Erfolg eines Projektes durch die drei Parameter OnTime, OnBudget und OnTarget. Seit 2015 wurde OnTarget durch “with a satisfactory result“ ersetzt. Damit sollte der Kundennutzen in den Vordergrund gestellt werden; immer häufiger kann dieser nur durch Änderungen der ursprünglichen Ergebnisdefinition während des Projektes gesteigert werden. Die Standish Group zeigt überzeugend auf, dass agile Vorgehensmodelle deutlich erfolgreicher sind als traditionelle, starre Vorgangsweisen. Dazu habe ich schon vor einiger Zeit einen Blogbeitrag verfasst, daher müssen wir hier nicht näher darauf eingehen.

Die funktionalen Anforderungen bestimmen nur einen kleinen Teil des Projektaufwandes

Alle gängigen Methoden der Aufwandsschätzung stellen den Software-Entwicklungsaufwand in den Mittelpunkt und leiten diesen aus den funktionalen Anforderungen ab. Das gilt für klassische Methoden wie Function Point oder COCOMO ebenso wie für agile Ansätze mit Story Points. Die funktionalen Anforderungen bestimmen allerdings nur einen relativ kleinen Teil des Aufwandes.

Tom DeMarco, auch zu diesem Thema eine hervorragende Quelle für sinnvolle Vorgehensweisen, fordert ein Kostenmodell, das man Aufwandsschätzungen zugrunde legt. Dieses Kostenmodell ist ständig weiterzuentwickeln. Ihm liegt eine Struktur zugrunde, welche Faktoren wie und mit welcher Gewichtung in die Ermittlung des voraussichtlichen Aufwandes einfließen. Was sind solche Faktoren? Hier eine Liste aus meiner praktischen Erfahrung, trotz ihres Umfanges ohne Anspruch auf Vollständigkeit:

  • Die funktionalen Anforderungen der Anwender
  • Der Funktionsumfang verfügbarer Standard‑Software
  • Der Mix von Standardsoftware, Re-Use vorhandener Software und Individualentwicklung
  • Die Architektur der eingesetzten Standard‑Software oder die Architektur der eigenentwickelten Lösung
  • Die Produktivität der eingesetzten Entwicklungsplattform inkl. der dort verfügbaren Re-Use-Möglichkeiten externer und interner Software-Komponenten
  • Die nicht‑funktionalen Anforderungen, wie zum Beispiel Safety, Security, Performance und Usability
  • Die Qualität der Projektabwicklung (zum Beispiel angemessene Granularität der Planung, Projektleitung und Projektcontrolling)
  • Die Verfügbarkeit (Zeitpunkt, Ausmaß und Konstanz) geeigneter Personen für die zu besetzenden Projektfunktionen
  • Die Qualifikation der tatsächlich an der Projektarbeit beteiligten Personen (insbesondere Auftraggeber, Projektleiter, Geschäftsprozessanalytiker, Softwareentwickler, Tester)
  • Die Effizienz der Zusammenarbeit im Projekt, die Projektkultur insgesamt
  • Die Mikroorganisation der Projektarbeit (zum Beispiel Priorisierung, Vermeiden von Multitasking, Termindisziplin, Urlaubsplanung)
  • Nicht vorhersehbare Einflüsse aus dem Bereich der Produktlieferanten und externen Dienstleister
  • Die Vielfalt und Komplexität der Voraussetzungen für den Rollout, zum Beispiel in verschiedenen Unternehmen eines weltweit agierenden Konzerns oder auch nur in verschiedenen Abteilungen eines Unternehmens
  • Die Motivation und der Skill-Level der Anwender hinsichtlich ihrer Mitwirkung in allen Projektphasen (von der Erstellung des Business-Case über die Anforderungsanalyse bis zum Rollout).

Wie in der Quantenphysik gilt auch hier, dass es unmöglich ist, alle Parameter exakt zu bestimmen. Sie beeinflussen einander in einer nicht im Voraus bestimmbaren Weise. Wie bei der Unschärferelation handelt es sich auch hier nicht um einen Mangel der Schätz- und Messverfahren, sondern um eine prinzipielle Unmöglichkeit.

Die Lösung: Den Aufwand nicht schätzen, sondern managen

Der Abschied von klassischen Vorgehensmodellen ist nicht mehr aufzuhalten. Die negativen Erfahrungen mit Versuchen, alle drei Zielgrößen eines IT-Projektes im Voraus immer genauer zu bestimmen, zwingen zu einer völligen Abkehr von diesem Ansatz. Mit Paul Watzlawick: „Mehr desselben“ ist nicht die Lösung, damit vergrößert man das Problem.

Allerdings braucht man beim Start eines Projektes eine Größenordnung des erforderlichen Aufwandes, anders wäre der Business Case nicht berechenbar. Ebenso muss man das Staffing des Projektes am voraussichtlichen Aufwand ausrichten, wenn man mit zu kleinen Teams startet, kann in späteren Phasen eines Projektes nur noch mit Terminverschiebungen und Scope-Reduktion reagiert werden. Oft reduzieren solche Abweichungen aber den Wert des Projektergebnisses in einem nicht akzeptablen Ausmaß.

Ganz ohne Aufwandschätzung geht es also nicht. Aber analytische Methoden der Aufwandschätzung führen zu keinem brauchbaren Ergebnis. Man muss sich mit Expertenschätzungen und Benchmarks von vergleichbaren Projekten begnügen. Diese Schätzungen müssen mit ausreichenden Risikozuschlägen versehen werden und der Business Case muss auch diese Worst Case Szenarien vertragen. Das sind unerfreuliche Botschaften für die Projektauftraggeber, aber leider steht jedes andere Versprechen auf tönernen Füßen.

Das Vorgehensmodell macht den Unterschied

Der wirksamste Hebel für die Minimierung des Aufwandes in Relation zum erzielten Ergebnis ist die Art der Projektabwicklung. Dazu ein Fallbeispiel der Standish Group. Es wurden zwei gleichartige Projekte, die mit dem gleichen Budget gestartet wurden, miteinander verglichen. Das eine Projekt wurde „agil“ abgewickelt, das andere „klassisch“. Das agile Projekt endete mit einem Budget von 12,5 Mio, das klassische Projekt verbrauchte 45 Mio. Welche Aufwandsarten waren für diesen dramatischen Unterschied verantwortlich?

Der Aufwand für Projektmanagement unterschied sich in absoluten Zahlen um den Faktor 12 (13 % von 45 Mio sind 5,9 Mio, 4 % von 12,5 Mio sind 0,5 Mio). Der absolute Aufwand für die Software-Entwicklung unterscheidet sich hingegen nur um den Faktor 2 (15 % von 45 Mio sind 6,6 Mio, 25 % von 12,5 Mio sind 3,1 Mio). Man sieht also, dass vor allem die Overhead-Kosten in einem „klassischen“ Projekt dramatisch höher sind als in einem agilen Projekt.

Mit einer agilen Projektabwicklung muss allerdings auch eine Abkehr von klassischen Budgetierungsmethoden verbunden sein. Das Herunterbrechen des Scope auf Arbeitspakete wird nicht treffsicherer, wenn die Arbeitspakete nun Epics, Features und User Stories heißen. Es sind nach wie vor die funktionalen Anforderungen, eventuell auch nicht-funktionale Anforderungen, die dort abgebildet sind. Das ist, wie oben gezeigt, nur ein kleiner Teil der bestimmenden Faktoren für den Aufwand. Jeder Versuch, dieser Begrenztheit des Wissens auszuweichen, ist zum Scheitern verurteilt; wir verweisen wieder auf Heisenberg.

Daher braucht man ein grundsätzlich anderes Vorgehen. Ich kenne derzeit kein besseres Modell als „Beyond Budgeting“. In meinem Buch „12 Halbwahrheiten über IT-Projekte“ habe ich das ausführlich beschrieben.

Bei amazon gibt es das Buch als Kindle, Paperback (Softcover, schwarz-weiß) und als Premium-Ausgabe (Hardcover, durchgängig 4-Farbendruck).  Die Premium-Ausgabe gibt es auch im Buchhandel.

 

 

 

 

Schreibe einen Kommentar

Kommentar