Interview mit Avision-CEOs Nadine Riederer und Jürgen Bernert Ist die Aufwandsschätzung für IT-Projekte (un)nötige Mühe?

Anbieter zum Thema

Avision GmbH

netfiles GmbH

Aufwandsschätzungen für IT-Projekte sind ein zweischneidiges Schwert: den einen vermitteln sie ein Gefühl der Sicherheit, anderen ist die Schhätzung schlicht zu ungenau. Beim IT-Dienstleister Avision kennt man dies Problem – und die beiden CEOs Nadine Riederer und Jürgen Bernert haben völlig unterschiedliche Meinungen dazu.

Die Aufwandsschätzung von Projekten aus dem Bereich der Software-Entwicklung ist ein vieldiskutiertes Thema. Neben zahlreichen Ansätzen und Methoden gibt es aber auch Meinungen, die das Konzept als solches in Frage stellen. Wie stehen Sie dazu, Herr Bernert?

Jürgen Bernert: Ich möchte gleich zu Beginn die These in den Raum stellen, dass viele Unternehmen sehr viel Mühe in die Aufwandsschätzung von IT-Projekten stecken, deren Ergebnisse sich am Ende des Tages nicht drastisch von den Einschätzungen und dem Bauchgefühl der Experten und Projektmanager unterscheidet. Es stellt sich mir daher die Frage, ob diese detaillierten Schätzverfahren wichtig sind oder doch nur vergebene Liebesmüh – denn sie versprechen keine Sicherheit oder Garantien.

Auch mit ausgearbeiteten Projektplänen können sich Dienstleister bei der Kalkulation verzetteln, denn nicht immer liegen alle Informationen vorab auf dem Tisch. Und auch die Anforderungen können sich ändern, es gibt keine Gewissheiten dabei. Deswegen sollten wir darüber sprechen, ob sich Unternehmen den oft mit hohem Aufwand verbundenen Schritt der Aufwandsschätzung sparen und sich lieber auf ihre Erfahrung für eine grobe Kostenangabe verlassen sollten.

Nadine Riederer: Ich glaube, wir dürfen das Thema nicht zu sehr verallgemeinern. Auf Kostenschätzungen an sich würde ich nicht per se verzichten wollen, auch wenn dabei nicht jedes Detail aufgeführt und abgeschätzt werden muss.

Die Methode ist aus meiner Sicht unverzichtbar, weil sie uns als Dienstleister eine erste Struktur für das Projekt gibt. Ich sehe darin die Möglichkeit, mit einer Expertenrunde die grundlegenden Schritte zu besprechen, Risiken aufzudecken und unsere Einschätzungen an den Kunden weiterzugeben. Das ist aus meiner Sicht die bessere Variante als zu sagen: „Wir fangen jetzt mal an und schauen später, wie teuer es wird“.

Bernert: Dagegen möchte ich gerne mit der Praxis argumentieren. Es liegt nun mal in der Natur der Sache, dass auf dem Markt eine gewisse Vorliebe für harte Zahlen herrscht – besonders, wenn es um die Frage des Budgets beziehungsweise der endgültigen Kosten geht. Ausschlaggebend für viele Kunden ist vor allem die Zahl, die am Ende steht.

Die aufwändig erstellten Planungsdokumente und Einschätzungen spielen dabei eher eine untergeordnete Rolle und kommen in manchen Fällen auch nicht beim Adressaten an. Wenn die genannte Summe in das vorhandene Budget passt, reicht das oftmals schon aus. Hinzu kommt, dass die Ausarbeitung einer Aufwandsschätzung auch Zeit kostet. Fahren IT-Dienstleister daher nicht besser damit, auf ihre Erfahrungswerte zu vertrauen und eine zeitnahe erste Einschätzung abzugeben?

Riederer: Es gibt zahllose Beispiele von IT-Projekten, bei denen die Diskrepanz zwischen Bauchgefühl und Aufwandsschätzung enorm ist. Wir sprechen hier von Millionen. Wenn der Projektleiter von einer Million Euro ausgeht, die detaillierte Schätzung aber von drei, dann sollten die Alarmglocken läuten.

Dev-Insider: Wäre an diesem Punkt auch zu überlegen, IT-Projekte überhaupt nicht mehr zu einem Festpreis anzubieten?

Riederer: Diese Überlegungen gibt es natürlich auch. In der Praxis würden dann aber Dienstleister den Zuschlag für viele Projekte gar nicht mehr erhalten, weil zumindest die ungefähre budgetäre Richtung fehlt. Damit können die meisten Unternehmen nicht planen.

Bernert: Das stimmt natürlich. Es gibt allerdings viele Projekte und Kunden, die für IT-Dienstleister nicht nur finanziell, sondern auch strategisch wichtig sind. Da ist von Anfang an klar, wieviel Budget zur Verfügung steht und dass der eigene Aufwand darüber liegt. Ich möchte aber noch einmal auf die einzelnen Schritte einer Aufwandsschätzung zurückkommen, die eventuell bis auf die Ebene der Arbeitspakete heruntergebrochen werden.

Das hat den bereits genannten Vorteil, dass beispielsweise bei agilen Projekten die Informationen schon im Backlog vorhanden sind und die Mitarbeiter die Storypoints geschätzt haben. Die Entscheidung liegt aber beim Kunden. Wenn die interne Planung des Unternehmens einen Preis von beispielsweise 500.000 Euro vorsieht und deswegen Projektkosten von kalkulierten 700.000 Euro schlicht nicht zulässt, dann war die ganze Arbeit um sonst.

Riederer: Aber der Anbieter weiß jetzt, dass er 200.000 Euro drauflegen müsste und kann sich entscheiden, ob es das wert ist. Wenn es ein Thema ist, das keine Aussicht auf Weiterführung hat, dann lässt man es. Wenn es zukunftsträchtig ist, kann es trotzdem als strategisches Projekt realisiert werden. Neue Kunden, neue Erfahrungen, neue Technologien – das alles sind Gründe, die für eine solche Entscheidung sprechen können.

Was wären aus Ihrer Sicht sinnvolle Alternativen zur klassischen Aufwandsschätzung?

Bernert: Besonders im agilen Umfeld gibt es Methodiken, die sich bereits bewährt haben. Wenn das Entwickler-Team von einem bestimmten Betrag ausgeht, mit einem Design-to-Budget-Ansatz arbeitet und der Product Owner dafür sorgt, dass die Software konsistent und deployable ist, entsteht damit meiner Meinung nach ein größerer Mehrwert als bei der klassischen Aufwandsschätzung.

Riederer: Ich sehe dabei besonders bei großen Konzernen die Schwierigkeit der Organisation, weil sie mit internen Budgetfreigaben arbeiten. Die müssen vertreten werden und ein klares Ziel verfolgen. Unsere Kunden brauchen deswegen zumindest eine grobe Aufwandsschätzung, mit der sie das Projekt intern vorantreiben und die Freigabe für das Budget begründen können.

Optimal wäre ein Umfeld, in dem das Management bewusst einen Budgetrahmen vorgibt und schaut, was damit erreicht werden kann. In der Realität dominiert aber eher das klassische Vorgehen: Die Software soll bestimmte Funktionen besitzen und spezifische Business-Cases umsetzen – und jetzt brauchen wir vom Dienstleister eine Zahl, was das kostet.

Stellt sich dabei nicht die Frage, wie akkurat so eine Schätzung sein kann, gerade bei Projekten, die sich über mehrere Jahre ziehen?

Riederer: Eine grobe Richtung muss es immer geben, denn es ist ein Unterschied, ob ein Unternehmen eine Million oder fünf Millionen veranschlagt.

Bernert: Das stimmt, aber wenn wir uns die vielen Großprojekte unserer Zeit anschauen – etwa die Elbphilharmonie oder den Berliner Flughafen –, da lagen die Schätzungen meilenweit daneben. Am Ende lagen die Kosten in völlig anderen Größenordnungen.

Riederer: Ein möglicher Mittelweg wäre es, Projekte in einer Runde von Experten vorzustellen und zu diskutieren, ein Grundgerüst herauszuarbeiten und danach Einschätzungen zu den Kosten abzugeben – aus diesen ergibt sich ja sowohl eine Tendenz als auch ein Mittelwert. Notwendig wäre dafür eine Mischung aus Optimisten und Pessimisten, die den Best Case, den Worst Case und alles dazwischen abdecken. Auf das Bauchgefühl einer Person zu hören, gleicht für mich eher einem Glücksspiel. Am Ende muss eine Zahl stehen und die Zusammenarbeit mit dem Kunden muss fair und transparent sein.

Bernert: Das auf jeden Fall. Zu diesem Thema gibt es sehr viele unterschiedliche Ansätze, komplexe mathematische Modelle und sogar Tools zur Risikoberechnung. Das ist viel Aufwand und aus meiner Sicht auch eine gewisse Pseudo-Genauigkeit. Auch Expertenschätzungen sind letztlich nicht wissenschaftlich exakt, aber sie benötigen weniger Aufwand. Am Ende ist es eine Schätzung, keine Berechnung – darüber sollten wir uns alle klar sein.

Welche anderen Methodiken gibt es noch für die möglichst genaue Kostenabschätzung?

Bernert: Eine Zeit lang gab es einen großen Hype um die Function-Point-Analyse. Dabei vergibt das Unternehmen Punkte für Schnittstellen, Masken, Features etc. Das Motto war also „zählen statt schätzen“. Aus dem Erfahrungswert ließen sich danach die Kosten für den jeweiligen Function Point ableiten und am Ende stand ein Endbetrag fest. Die Methode war aber alles in allem zu aufwändig und konnte sich nicht durchsetzen.

Riederer: Hinzu kommt, dass Unternehmen die Methode erst nach einiger Zeit anwenden können, denn am Anfang gibt es keine Erfahrungswerte. Mir fehlt einfach das Vertrauen in dieses Vorgehen. Sobald neue Technologien hinzukommen, ändert sich das gesamte System und der Wert einzelner Function Points – unter dem Strich ist der Ansatz zu unflexibel und zu aufwändig.

Bernert: Dagegen hat sich auf dem Markt eher durchgesetzt, mit einem etwas niedrigeren Preis zu starten und das Projekt später mit Change Requests anzupassen. Für eine langfristige und gesunde Kundenbeziehung sollten diese Aspekte aber von Anfang an transparent besprochen werden – wer niedrig stapelt und am Ende die Hand für mehr Geld aufhält, vergrault seine Kunden.

Riederer: Change Requests sind Teil des Geschäftes, die Welt verändert sich nun mal auch im Laufe eines Projektes. Daran ist per se nichts auszusetzen. Es kommt dabei viel mehr und das große Ganze an, die Art und Weise, wie sich Dienstleister und Kunden begegnen und auf welcher Basis die Zusammenarbeit abläuft. Mit Verständnis, Transparenz und guter Kommunikation lässt sich jedes IT-Projekt umsetzen. Egal, ob mit Chance Requests, ausgearbeiteten Kostenabschätzungen oder Preisangaben, die auf Erfahrungen beruhen.

(ID:49975343)