Claus Kolb

IT Projektmanagement


Auf meinem Blog berichte ich regelmäßig von meinen Erfahrungen aus Kundenprojekten. Folgen Sie mir auf Twitter, um über neue Artikel informiert zu werden.

Budgetierung agiler Projekte

August 4, 2014Claus Kolb0 Kommentare

In Unternehmen, die eine agile Methode einführen, stellt sich oft die Frage, wie ein Projektbudget bestimmt werden kann, ohne über eine detaillierte Spezifikation zu verfügen. Während dies in sequentiellen Vorgehensweisen i.d.R. auf Basis eines detaillierten Fachkonzepts erfolgt, fehlt dieses in agilen Projekten. Nachfolgend stelle ich zwei Möglichkeiten vor, im Voraus den Aufwand und damit das Budget eines Projektes grob zu bestimmen.

Projekttyp

Die hier beschriebenen Methoden sind nicht für Forschungsprojekte geeignet, bei denen völlig unklar ist, wie die Anforderungen überhaupt aussehen. In solchen Projekten ist es zielführender, ein festes Projektbudget vorzugeben und dafür den maximalen Wert zu implementieren, der dafür zu haben ist. Reine Forschungsprojekte sind in der Praxis aber eher selten. Ein Beispiel für ein solches Projekt wäre es, eine Mobile App zu entwickeln, die auf Basis von freiwillig erfassten Gesundheitsdaten dem Nutzer gesundheitsbezogene Ratschläge erteilt.

Ich beziehe mich hier auf Projekte, deren Lösungsraum und damit Schwankung des Gesamtaufwands im Zeitablauf immer kleiner werden (siehe Abbildung 1). Ein Beispiel für diesen Projekttyp ist die Erfüllung von gesetzlichen Erfordernissen im Bereich Altersverifikation an eine Online-Plattform mit Hilfe des Postident-Verfahrens.

Abbildung 1: Genauigkeit der Aufwandschätzung im Zeitablauf

Abbildung 1: Genauigkeit der Aufwandschätzung im Zeitablauf

Methode 1: Hochrechnung

Am Anfang eines solchen Projektes muss zumindest ein (mehr oder minder ausformuliertes) Grobkonzept stehen. Dieses Grobkonzept kann „klassisch“ als Dokument erstellt und abgestimmt werden, aber auch z.B. mit der Methode des Story Mappings „agil“ ermittelt werden. Die folgenden Schritte sind durchzuführen, um ein Projektbudget zu ermitteln.

  1. Auf Basis des Dokuments bzw. direkt aus der Story Map wird eine (möglichst) vollständige Liste von Epics erstellt.
  2. Die User Stories mindestens eines Epics werden detailliert ausgearbeitet.
  3. Die User Stories des Epics werden mit Story Points geschätzt und auf das Epic summiert.
  4. Die User Stories des Epics werden zusätzlich in Personentagen geschätzt. Dies ist eine sehr grobe Schätzung (notfalls) durch evtl. gar nicht am Projekt beteiligt Personen für den Zweck, ein sehr grobes Projektbudget zu ermitteln. Zu einem späteren Zeitpunkt muss diese Schätzung durch das eigentliche Projektteam wiederholt werden. In meiner Praxiserfahrung haben sich hierfür Schätzungen durch eine Gruppe von Experten bewährt.
  5. Die anderen Epics werden relativ zum geschätzten Epic gesetzt und ihr Aufwand auf dieser Basis abgeleitet. Um hier keine umfassenden kleinteiligen Diskussionen aufkommen zu lassen, kann die relative Schätzung anhand eines in der folgenden Abbildung zu sehenden grafischen Schemas in Gruppenarbeit erfolgen. Dazu wird am Anfang das detailliert geschätzte Epic 1 als Referenz-Epic auf der 0%-Linie platziert (siehe Abbildung 2). Alle anderen Epics werden relativ zu diesem positioniert.
  6. Durch die Berücksichtigung eines zusätzlichen, prozentualen Puffers für Features, an die man nicht gedacht hat, kommt man zu einem Gesamtbudget für das Projekt.
Abbildung 2: Relative Schätzung von Epics

Abbildung 2: Relative Schätzung von Epics

Methode 2: Projektvergleich

Auch für die Methode des Projektvergleichs sollte eine möglichst vollständige Liste von Epics erstellt werden, um zumindest einen groben Überblick über die zu realisierenden Funktionen zu bekommen. Analog zur relativen Schätzung von User Stories (mit Story Points) wird dieses Projekt mit anderen Projekten ins Verhältnis gesetzt. Ist dieses Projekt zweimal, dreimal, fünfmal oder achtmal so komplex wie bereits beendete Projekte, deren Inhalt man kennt. Dafür ist natürlich Voraussetzung, dass die schätzenden Personen bereits einige Projekte in diesem Umfeld gemacht haben, um sie mit dem neuen Projekt zu vergleichen. Auch für Projekte lässt sich die o.g. grafische Möglichkeit nutzen und damit Projekte anstatt von Epics vergleichen.

Beide Methoden können selbstverständlich kombiniert werden, um einerseits eine grobe Vorstellung für das Gesamtbudget des Projektes zu bekommen und anschließend diese Schätzung mit einer Hochrechnung zu verifizieren. Auf Basis der geschätzten Personentage können die Personalkosten des Projekts abgeleitet werden. Diese Schätzung muss um zusätzliche Kosten für Hardware, Software und Lizenzen sowie Personalaufwand in nicht-agilen Bereichen ergänzt werden, um zum finalen Projektbudget zu kommen.


Eine Antwort eingeben