Es geht genauer! Aufwandsschätzung in Software-Entwicklungsprojekten

Wie werden Aufwände für Software-Entwicklungen in der Praxis geschätzt? Wie zuverlässig sind diese Schätzungen? Wie könnten sie genauer werden? Eine Befragung von erfahrenen Projektmanagern zum Thema Aufwandsschätzung lieferte erstaunliche Resultate: Unter anderem waren die Befragten mit den Schätzwerten zufrieden, obwohl die tatsächlichen Kosten beträchtlich davon abwichen. Dr. Dirk Basten stellt die Ergebnisse dieser Studie vor und analysiert, warum Schätzungen die Ist-Werte nur selten richtig prognostizieren. Er leitet daraus konkrete Handlungsempfehlungen ab, wie sich die Genauigkeit von Aufwandsschätzungen erheblich steigern lässt.

Es geht genauer! Aufwandsschätzung in Software-Entwicklungsprojekten

Wie werden Aufwände für Software-Entwicklungen in der Praxis geschätzt? Wie zuverlässig sind diese Schätzungen? Wie könnten sie genauer werden? Eine Befragung von erfahrenen Projektmanagern zum Thema Aufwandsschätzung lieferte erstaunliche Resultate: Unter anderem waren die Befragten mit den Schätzwerten zufrieden, obwohl die tatsächlichen Kosten beträchtlich davon abwichen. Dr. Dirk Basten stellt die Ergebnisse dieser Studie vor und analysiert, warum Schätzungen die Ist-Werte nur selten richtig prognostizieren. Er leitet daraus konkrete Handlungsempfehlungen ab, wie sich die Genauigkeit von Aufwandsschätzungen erheblich steigern lässt.

Die Prognose des Arbeitsaufwands, der für die Entwicklung einer Software benötigt wird, ist häufig mit einer hohen Unsicherheit behaftet. Überschreitungen des geplanten Projektbudgets und/oder des Zeitplans sind die weit verbreiteten Folgen. Obwohl viele Faktoren bekannt sind, welche die Genauigkeit von Aufwandsschätzungen unabhängig von der eingesetzten Methode verbessern können (Basten und Sunyaev, 2011), wird dieses Wissen offensichtlich in der Praxis nicht ausreichend effektiv genutzt.

Um die Gründe für dieses Defizit herauszufinden, befragte eine Arbeitsgruppe der Wirtschafts- und Sozialwissenschaftlichen Fakultät der Universität zu Köln (Basten und Mellis, 2011) insgesamt 52 Projektmanager zu ihren Methoden und Erfahrungen hinsichtlich der Aufwandsschätzung von Software-Entwicklungsprojekten. Abgefragt wurden dabei die Systematik der Schätzungen, die eingesetzten Schätzverfahren sowie der von den Experten wahrgenommene Erfolg dieser Schätzungen.

Die nun vorliegenden Ergebnisse der Anfang 2011 durchgeführten Befragung zeigen eine ambivalente Einstellung der Projektverantwortlichen gegenüber dem Thema Aufwandsschätzung. Einerseits wird sie häufig als unnötige und Aufwand verursachende Aktivität angesehen, so dass in hohem Maß Daumenregeln angewendet werden. Andererseits zeigt diese Untersuchung, dass den Experten die Bedeutung und die Notwendigkeit von genauen Aufwandsschätzungen bewusst sind, dieses Bewusstsein jedoch in den Unternehmen noch stärker verankert werden muss.

Umfrageteilnehmer: Experten mit breitem Erfahrungshintergrund

An der Befragung nahmen insgesamt 52 Projektmanager (48 Männer, 4 Frauen) teil. Die Teilnehmer verfügen über durchschnittlich 16 Jahre Erfahrung in der Software-Entwicklung (Bild 1) und waren im Durchschnitt an 50 Projekten beteiligt gewesen. Voraussetzung für die Teilnahme an der Umfrage war, dass sie über ein abgeschlossenes Projekt berichten konnten, bei dem sie selbst die Aufwandsschätzung durchgeführt hatten.

Bild 1: Verteilung der Teilnehmer entsprechend der Anzahl der Projekte, an denen sie mitgewirkt haben.

Die meisten Teilnehmer (69%) verfügen über einen technischen Hintergrund, während 31% sich als betriebswirtschaftlich ausgerichtet sehen. Mehrheitlich (73%) haben sie ein Diplom oder einen Doktorgrad in Informatik, Wirtschaftsinformatik oder einem verwandten Studiengang.

Die analysierten Projekte hatten hauptsächlich in den Branchen Informations- und Kommunikationstechnologie (50%), Logistik (12%) und Beratung (12%) stattgefunden. Die übrigen Projekte (26%) verteilen sich zu fast gleichen Anteilen auf eine Vielzahl weiterer Branchen. 58% der Projekte waren in einem externen Auftraggeber/Auftragnehmer-Verhältnis durchgeführt worden, alle anderen sind interne Projekte. Die Projekte waren entweder zum Festpreis (66%) oder nach Aufwand (34%) abgerechnet worden, andere Vertragsformen scheinen in der Praxis keine Anwendung zu finden. Da die Umfrageteilnehmer zunächst nur im deutschsprachigen Raum angeworben wurden, waren drei Viertel der Projekte in Deutschland durchgeführt worden, dennoch ist ein Viertel der Projekte international (z.B. Singapur, Polen).

Auch die Größe der Unternehmen, bei denen die Projekte ausgeführt worden waren, deckt ein breites Spektrum vom mittelständischen Software-Entwicklungshaus bis zum internationalen Großkonzern ab. Die durchschnittliche Mitarbeiterzahl beträgt dementsprechend rund 40 Tausend, der durchschnittliche Jahresumsatz rund acht Milliarden Euro.

Schätzverfahren werden meistens kombiniert

Die in der Umfrage von den Teilnehmern angegebenen Schätzverfahren wurden zur Auswertung in vier Gruppen eingeteilt: Analogieverfahren, Work Breakdown Structure, Function Points und Expertenschätzung.

Analogieverfahren

Analogiebasierte Verfahren verwenden Erfahrungswerte aus bereits durchgeführten Projekten zur Aufwandsschätzung eines Softwareprojekts. Daher sind vor allem Erfahrungsdatenbanken mit dokumentierten Schätzungen von früheren Projekten (z.B. Ziele, eingesetzte Entwicklungsmethode, geschätzter und tatsächlicher Aufwand) für diese Verfahren entscheidend. Anhand bestimmter Attribute und Einflussfaktoren (z.B. Entwicklungstyp, Anwendungsgebiet, Programmiersprache und Entwicklungsplattform) werden die bereits abgeschlossenen Software-Entwicklungsprojekte ermittelt, die dem neuen am ähnlichsten sind. Die Aufwandsschätzung erfolgt dann anhand des tatsächlichen Aufwands der identifizierten Analogieprojekte. Die konkreten Schätzwerte werden ermittelt, indem diese Erfahrungswerte an die Daten des neuen Projekts angepasst werden. Eine andere Möglichkeit besteht darin, mit Hilfe von sog. "Voting Rules" (Koch und Mitlöhner, 2009) eine Rangliste der abgeschlossenen Projekte zu erstellen, wobei die beiden, dem zu schätzenden Projekt benachbarten Projekte, die obere und untere Grenze der Aufwandsschätzung liefern.

Work Breakdown Structure

Der Einsatz einer Work Breakdown Structure (WBS, dt.: Projektstrukturplan) dient dazu, ein Projekt in Teilprojekte, (Teil-)Aufgaben, Arbeitspakete und Ähnliches zu gliedern (Tausworthe, 1980). WBS stellt somit generell ein wichtiges Instrument zur Planung von Projekten dar. Obwohl dieses Verfahren häufig als Ergänzung zu anderen Schätzverfahren eingesetzt wird, kann es auch als eigenständiger Ansatz betrachtet werden. Durch die Aufteilung eines Projekts in Arbeitspakete, von denen angenommen wird, dass sie den gleichen Aufwand benötigen (z.B. einen Personentag), kann der Gesamtaufwand des Projekts geschätzt werden.

Function-Point-Analyse

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 14
Kommentare 5

Alle Kommentare

Guest
In vielen, vor allem innovativen Projekten, treten Probleme (oder Herausforderungen, wie man will) auf, die nicht planbar waren und mit keiner Methode planbar gewesen wären. Wie oft hört man in Reviews den Satz "Wenn folgendes nicht eingetreten wäre, hätte der Plan gestimmt". (Irgendwie beschuldigt man so die Realität als Ursache der Probleme ?!) Weiterhin liegt es in der Natur des Menschen, dass man vergleichend sehr viel besser schätzen kann als absolut und dass man gut nur dann gut schätzen kann , wenn die Grössenverhältnisse nicht mehr als 1 zu 10 sind. Die meisten Schätzungen von technischen Experten über ihre Arbeit sind zu niedrig, weil sie nur die technischen Schwierigkeiten aber nicht die organisatorischen berücksichtigen. Ein Schätzverfahren sollte diese Punkte berücksichtigen und: 1. vergleichend schätzen 2. Auf eine Granularität von nicht mehr als 1: 10 gehen 3. Die wahre Kapazität aus vergangenen Projekten extrapolieren - das beinhaltet automatische die "organisatorische Bremse" Gemeinhin nennt man das dann agile Schätzverfahren. (points, planning poker - velocity etc.) Agile hat also sehr viel damit zu tun, so zu arbeiten wie Menschen nun mal einfach "ticken" und man passt die Verfahren der Natur des Menschen (auch Projektleiter sind Menschen !)und der Natur von Innovation (Arbeiten mit Unvorsehbarem) an statt umgekehrt.
Dorian
Gloski
Guter Artikel. Er beschreibt die einzelnen Schätzmethoden kurz und knapp und liefert interessante Zahlen. Bzgl. der Schätzgenauigkeit habe ich die Erfahrung gemacht, dass viele Budgetverantwortliche bereits insgeheim eine Überschreitung von 30% einkalkulieren. Eine genauere, also höhere, Schätzung könnte hier u. U. kontraproduktiv sein und das Budget erhöhen, da die Projektbeteiligten davon ausgehen, dass eine gewisse Budgetüberschreitung kein Problem darstellt. Agile Schätzmethoden stellen, meiner Meinung nach, eine Art von Expertenschätzung dar. Sie sind besser als die Schätzung eines einzelnen Experten, da sie als Konsens innerhalb des Teams entstehen. Sie sind allerdings ebenso wenig reproduzierbar und hängen stark vom Team und der Formulierung der User Stories ab. Dadurch sind sie gut für die Planung einzelner Iterationen geeignet. Für die Schätzung des gesamten Projektes sind sie allerdings, ähnlich wie die Expertenschätzung, nur bedingt geeignet.
Guest
Wenn ich das richtig verstehe, wurde 52 Personen bzw. Projekte berücksichtigt? Das ist ein bisschen wenig, um allgemeine Erkenntnisse abzuleiten. Besonders interessant ist die Argumentation, daß eine möglichst genaue Schätzung die Lösung "aller" Probleme ist. Nun, die Entwicklung agiler Vorgehensweisen scheint die bessere Alternative zu sein ;-).
Karsten
Hoffmann
Dr.
Zum Verständnis der Schätzproblematik wäre es in Ergänzung zum Artikel vielleicht hilfreich, den Begriff Schätzklausur einzuführen. Diese "best practise" in einigen Unternehmen (die ich als PM-Trainer sowohl selbst praktiziere als auch "lehre") basiert auf einem ausgearbeiteten PSP (ProjektStrukturPlan) bzw. WBS, ohne den eine Aufwandsschätzung kaum möglich ist. Den PSP aufstellen bedeutet, die zu leistende Arbeit zu strukturieren und deshalb zwangsläufig zu analysieren: Was muss geleistet werden? Welchen Skill braucht man dazu jeweils? In welchen Abschnitten/Phasen? So erzwingt die Zerlegung der zu leistenden Projektarbeiten in Arbeitspakete (AP) das genaue Nachfragen und "sich kümmern um Details". Grundsatz der Schätzklausur: Erst dann können wir schätzen, wenn wir diese Strukturarbeit so weit gemacht haben, dass wir uns ein "Schätzen" überhaupt zutrauen. Kombiniert man dieses Vorgehen mit einem Grundsatz wie: Arbeitspakete > 100 Stunden sind noch mal zu teilen, dann erhält man zügig und mit hoher Effizienz ein Grundgerippe von Arbeitspaketen, an denen sich die "Knackpunkte" eines Projektes leicht identifizieren lassen. Bei vorliegendem Lastenheft gewisser Qualität (oder vergleichbaren Beschreibungen) kann auf diese Weise ein Projekt in der Größenordnung von z.B. 1-3 Personenjahren in kurzer Zeit (1-2 Tagen) recht gut abgeschätzt werden. Dies gelingt umso leichter, je mehr solches Vorgehen Schätzklausuren üblicherweise praktiziert werden und Schätzungen damit einen guten Alltagsbezug haben. Die Schätzung selbst besteht je Arbeitspaket aus Mindeststundenzahl sowie einem Sicherheitsfaktor (10%, 30% oder 50%, je nach dem, wie klar man den Umfang des Paketes sieht; genügen 50% nicht, so gibt man keine Schätzung ab und zu diesem Paket noch Klärungsbedarf). Klausur bedeutet, das Ganze macht man mindestens zu zweit, in abgeschlossener Form. Beide schätzen unabhängig voneinander. APe mit großer Differenz fordern zum Nachgespräch auf. Das ganze ergänzt um %-Aufschläge für Projektmanagement und QS-Massnahmen, Risikozuschläge etc. ergibt ein sehr solides Verfahren. Frage an den Artikelautor: Sehen Sie o.g. Vorgehen als "Expertenschätzung" oder "auf Basis WBS"? Die Projektrealität in vielen Unternehmen zeigt, dass die PM-Praxis gerade in dieser Hinsicht noch teilweise stark unterentwickelt ist. Ohne klare Projekt-Planung mit geplanten Aufwänden erscheint ein systematisches Controlling kaum möglich.
Janko
Böhm
Herr Dr. basten, vielen Dank für den interessanten Artikel. Mir hat gut gefallen wie Sie die Notwendigkeit einer Schätzung herausarbeiten und die verschiedenen Sichten aus einem sehr starken Praxisbezug heraus darlegen. Mit der Überschrift hatte ich einen eher technischen Artikel erwartet der eine oder mehrere Verfahren inhaltlich darstellen. Ich bin selbst auch ein großer Anhänger vom Einsatz guter Schätzverfahren treffe aber in der Praxis auch immer auf Ressentiment in den Unternehmen die den Aufwand scheuen und den Nutzen in Frage stellen. Mit der Erstellung eines Projekt Struktur Plans habe ich auch gute Erfahrungen gemacht weil so auch das gemeinschaftliche Nachdenken und Kennelernen des Scops bzw. den Projektgegenstandes unterstützt wird. Wie von Hr. Müller angesprochen erweist sich eine relative Schätzung meist als sehr hilfreich und praktikabel. Wenn man die Schätzung mit StoryPoints statt Personentagen erstellt ist man als Projektleiter immer daran gebunden diese in Zeit umzurechnen - und so hat man die Team-performance (Velocity) incl. der organisatorischen Bremse als auch den wiederholen Charakter zwangsläufig im Blick. Wie ich es aus Ihrem Artikel, Herr Dr. Basten herausgelesen habe sollte es am Ende nicht um das noch ausgefeiltere und noch genauere Schätzverfahren gehen - sondern um die Akzeptanz von Aufwands-Schätzungen mit einen angemessenen Methode. Also der Überzeugung der Key Stakeholder des Projekts zu einem strukturiertem und methodischem Vorgehen. Das kann ich absolut mittragen und ich denke da haben wir alle noch genug zu tun :-)
Alle anzeigen