2.2.1 Arbeits- und Budgetplanung / Schätztechniken

Schätztechniken (2.2.1.P1)

Es gibt mehrtägige Seminare über Schätzmethoden. Einige dieser Techniken basieren auf fortschrittlichen Statistikmethoden und wissenschaftlichen Formeln. Sie liegen außerhalb des Rahmens dieser Website. Die folgenden Techniken zur Aufwandsschätzung können sowohl auf Projektebene wie auch auf Arbeitspakete oder jeder dazwischenliegenden Stufe angewendet werden.

• Vergangenheitswerte: Dies ist bei weitem die beste Methode. Wenn in Ihrem Unternehmen bei früheren Projekten die tatsächlichen Aufwandsstunden im Nachhinein dokumentiert wurden haben Sie eine Basis für Ihr jetziges Projekt. Die Charakteristiken und Aufwendungen des vorherigen Projekts werden Sie in einem File gespeichert haben. Wenn bereits ähnliche Aufgaben in der Vergangenheit durchgeführt wurden, können Sie Ihr Projekt mit den gleichen Begriffen beschreiben und Sie bekommen ein gutes Gefühl für die Aufwände Ihres jetzigen Projekts.
  
  
• Analogie: Selbst wenn Sie nicht die Möglichkeit haben auf ein Projekt mit dokumentierten Ist-Stunden zurückzugreifen, können Sie ein früheres Projekt nutzen. Analogie bedeutet, dass Sie Ihre Aufgaben beschreiben und in Ihrem Unternehmen ein Projekt suchen, bei dem in der Vergangenheit bereits ähnliche Arbeiten ausgeführt wurden. Wenn das zutrifft können Sie versuchen, den Aufwand zu ermitteln und ihn in analoger Form für Ihre jetzige Schätzung zu verwenden.
  
  
  Wenn Sie ein passendes früheres Projekt finden, können Sie den damaligen Projektmanager befragen, wie hoch der Stundenaufwand des Projekts war, und diese Informationen für Ihre Schätzung verwenden. Selbst wenn das damalige Projektteam den tatsächlichen Stundenaufwand nicht mehr dokumentiert hat, kann dieses dennoch eine nützliche Hilfe bei der Schätzung sein. Dieser Projektmanager hat zumindest noch eine ursprüngliche Schätzung von Aufwand und Dauer des Projekts. Obwohl er nun den tatsächlichen Stundenaufwand nicht dokumentiert hat, sollte er die eigentliche Dauer noch im Kopf haben. Wenn die Ist-Dauer sich mit der geschätzten Dauer deckt, dürfen Sie davon ausgehen, dass auch die Arbeitsstunden in etwa stimmen. Wenn das Projekt hingegen den geplanten Endtermin um 20 % überzogen hat, dürfen Sie vermuten, dass auch die geplanten Arbeitsstunden um 20 % überschritten wurden. Als Beispiel gehen wir von einem früheren Projekt aus, das auf sechs Monate und 2000 Stunden zur Fertigstellung geschätzt wurde. Wenn das Projekt wirklich in sechs Monaten fertig gestellt wurde, kann man mit ziemlicher Wahrscheinlichkeit davon ausgehen, dass das Projekt annähernd 2000 Stunden an Aufwand gekostet hat. Ebenso wenn das Projekt gut mit Personal ausgestattet war und sieben Monate brauchte, kann man die Fertigstellung des Projekts auf etwa 2300 Stunden schätzen.
  
  
• Verhältnis: Diese Methode i st der Analogie ähnlich, außer dass Ihr Vergleichsobjekt einen größeren bzw. kleineren Umfang hat. Zum Beispiel sind für die Installation einer Software in der Niederlassung A 500 Stunden aufgewendet worden. Wenn nun die Niederlassung B doppelt so groß ist, können Sie annehmen, dass der Aufwand für die Niederlassung B 1.000 Stunden betragen wird.
  
  
• Expertenmeinungen: Vielfach kann es angebracht sein, für die Planung einen internen oder externen Experten hinzuzuziehen. Wenn Sie z.B. das erste Mal eine neue Technologie einsetzen wollen, werden Sie die Hilfe eines externen Experten mit Erfahrung auf diesem Gebiet benötigen. Dieser kann die Erfahrungen einbringen, die er in anderen Unternehmen bereits gemacht hat. Sie können aber auch einen internen Experten finden, der Ihnen hilft. Auch wenn Sie das erste Mal für eine bestimmte Aufgabe eine Schätzung abgeben müssen, wird es sicher jemanden geben, der bereits Erfahrung hat.
  
  
• Delphi- Methode : Diese Methode ist der Expertenmeinung ähnlich, außer dass sie mehrere Experten hinzuzieht und auf einen Konsens zwischen den einzelnen Schätzungen abzielt. Wählen Sie als erstes zwei (vorzugsweise drei) Experten aus und geben Sie jedem die notwendigen Informationen für eine Aufwandsschätzung. Wenn danach die abgegebenen Schätzungen nahe bei einander liegen, können Sie den Durchschnittswert in die Planung übernehmen. Falls jedoch die Schätzungen voneinander abweichen, schicken Sie diese alle zusammen mit allen Angaben noch einmal an jeden Experten zu einer zweiten Schätzung. Jetzt können Sie davon ausgehen, dass bei der zweiten Schätzung alle die gleiche Ausgangslage haben und diesmal die Schätzungen näher beisammen liegen. Sollte eine abgegebene Schätzung weiterhin ausreißen, dann können Sie diese bei der Durchschnittsberechnung weglassen.
  
  
• Arbeits-Strukturierung: Ein Projekt wird in ausreichend kleine Einheiten unterteilt, da der Stundenaufwand für überschaubare Größen leichter geschätzt werden kann. Nach den Einzelschätzungen können die Einzelaufwände zu einem Gesamtaufwand aufaddiert werden.
  
  
• PERT: Der Begriff PERT wird oft im Zusammenhang mit Netzdiagrammen verwendet. Er ist jedoch eher ein Name für eine Schätzmethode, die einen Durchschnitt aus drei Zahlen verwendet. Die Methode basiert auf drei Fällen: Fall O = most optimistic, Fall M = most likely und Fall P = most pessimistic. Die resultierende PERT-Schätzung ist (O + 4M + P) / 6. Beispiel: Eine Aufgabe wird wahrscheinlich 10 Stunden benötigen. Im besten Fall braucht sie 6 Stunden, im schlechtesten Fall 26 Stunden. Die PERT-Schätzung ist dann (6 + 40 + 26) / 6 = 12 Stunden.
  
  
• Modellierung: Bei dieser Technik haben Sie ein Modell einer auszuführenden Arbeit, mit dem Sie von der Schätzung einer Teileinheit auf den Gesamtaufwand schließen können. Wenn Sie z.B. beauftragt werden, 40 neue Reports zu entwerfen, dann werden Sie zuerst den Aufwand für einen durchschnittlichen Report schätzen. Danach können Sie den Durchschnittsaufwand mit 40 multiplizieren und Sie erhalten die Gesamtschätzung.
  
  
• Function Points. Manche Organisationen zur IT-Entwicklung verwenden Function Points, um aussagekräftige Schätzungen der zur Durchführung eines Systementwicklungsprojekts erforderlichen Arbeit vorzunehmen. Function Points sind ein Mechanismus, mit dem man die relative Komplexität einer Anwendung ermitteln kann. Die Komplexität kann als eine Summe von Function Points ausgedrückt werden. Dementsprechen ist eine Anwendung mit 1000 Function Points im Allgemeinen zehn Mal größer und komplexer als eine Anwendung mit 100 Function Points.
  
  
  Ohne allzu sehr ins Detail zu gehen sei gesagt, dass Function Points die Größe einer Anwendung aus der Perspektive der Anwender betrachten. Die Anwender sehen Berichte, Masken und vielleicht Dateien. Ferner sehen sie Funktionen, Schnittstellen zu anderen Anwedungen, Datenbanken, Tabellen, etc.. Eine Anwendung mit 80 Masken und 20 Berichten dürfte naheliegenderweise größer sein als eine Anwendung mit 20 Masken und 5 Berichten. Diese Sichtweise der Größe ist völlig unabhängig von der zugrunde liegenden Technologie und der Entwicklungssprache. Unter Umständen benötigt die Anwendung mit der kleineren Anzahl an Bildschirmen sogar mehr Quellcodezeilen, doch für die Größenberechnung ist dies nicht mehr relevant.
  Man kann Function-Point-Schätzungen nicht im Frühstadium des Planungsprozesses einsetzen. Erst wenn Sie die Anzahl der Masken, Berichte, Schnittstellen, Dateien, Transaktionen etc. kennen, können Sie eine grobe Schätzung von Gesamt-Function-Points abgeben. Wenn Sie erst einmal in ein paar Projekten Function Points gezählt haben, werden Sie allmählich erkennen, welchen Arbeitsaufwand die Fertigstellung eines Function Points durchschnittlich in Anspruch nimmt. Danach müssen Sie nur noch rechnen, um den insgesamt erforderlichen Arbeitsaufwand zu ermitteln, gefolgt von der Dauer und den Kosten.