Thought Leadership
Kostenschätzungen für IT-Projekte sind ein heikles Thema, denn meistens beruhen sie lediglich auf der Erfahrung und dem Bauchgefühl des jeweiligen Projektleiters, was in der Praxis regelmäßig dazu führt, dass das IT-Budget sehr ineffektiv eingesetzt wird.
Entweder ist es zu klein oder in den Projekten wird das Geld unnötig verbrannt. Wie lässt sich die Kostenschätzung für IT-Projekte also auf eine valide und nachvollziehbare Basis stellen?
Hinterher ist man immer schlauer – das ist in vielen Unternehmen die Quintessenz, wenn es um IT-Projektkosten und das dafür zur Verfügung stehende Budget geht. Vor der Umsetzung eines IT-Projekts werden die Kosten natürlich so gut es geht kalkuliert. In der Regel liegen sie am Projektende aber unter oder über der anfänglichen Kalkulation. Natürlich versucht jeder IT-Manager diese Differenz so gering wie möglich zu halten. Dass sie als Schätzdifferenz bezeichnet wird, kommt nicht von ungefähr: Meistens stützt sich die Kostenkalkulation lediglich auf die Erfahrung des Projektleiters oder anders gesagt auf sein Bauchgefühl. Das kann schwerwiegende Folgen auf die Realisierung wichtiger IT-Projekte haben – ganz gleich, ob die Schätzdifferenz positiv (weniger Kosten als zunächst kalkuliert) oder negativ (mehr Kosten als kalkuliert) ausfällt.
Projekte bleiben auf der Strecke
Angenommen ein Unternehmen plant in einem festgesetzten Zeitraum sechs IT-Projekte und unterteilt diese nach Prioritäten. Das IT-Budget von 500.000 Euro wird zunächst auf die vier wichtigsten Projekte aufgeteilt. Für das Projekt mit oberster Priorität werden Kosten von 100.000 Euro veranschlagt. Tatsächlich liegen die Ausgaben bei einer negativen Schätzdifferenz von 30 Prozent aber bei 130.000 Euro. Das Projekt mit der zweithöchsten Priorität und einer Kostenkalkulation von 200.000 Euro schlägt demnach letztendlich mit 260.000 Euro zu Buche. Die Folge: Da die tatsächlichen Kosten um 30 Prozent höher liegen als zunächst prognostiziert, wird bereits beim dritten Projekt, für das ebenfalls 100.000 Euro angesetzt wurden, das IT-Budget überschritten. Alle weiteren Projekte können nicht mehr realisiert werden, da eine Budgeterhöhung im Nachhinein nur sehr schwer durchzusetzen ist. Wird während der Projektumsetzung festgestellt, dass das IT-Budget überschritten wird, kommt es zum Stopp des jeweiligen Projekts. Das Management muss zunächst darüber entscheiden, das Budget aufzustocken oder Projekte zu verschieben bzw. gleich ganz zu streichen. In der Zwischenzeit werden externe und interne Mitarbeiter fürs Warten bezahlt.
Nicht viel besser ist die Situation bei einer positiven Schätzdifferenz, denn nur in den seltensten Fällen fließt einmal angesetztes Budget aus einem Projekt zurück. In dem genannten Beispiel können mit einer positiven Schätzdifferenz von 30 Prozent zwar die vier wichtigsten IT-Projekte umgesetzt werden, jedoch stünde für die Projekte mit Priorität 5 (kalkulierte Kosten: 50.000 Euro) und 6 (kalkulierte Kosten: 40.000 Euro) eigentlich noch genügend Budget zur Verfügung, um auch diese zu realisieren. Das wird jedoch im angesetzten Zeitraum nicht geschehen, da das IT-Budget laut Kostenkalkulation nur für vier Projekte ausreicht. Die Frage ist nun, wie es Unternehmen gelingt, die Schätzdifferenz so gering wie möglich zu halten. Das Problem: Es gibt nur wenige markterprobte Schätzmethoden und selbst die haben noch ihre Haken.
Function-Point-Analyse und Vergleichsdatenbanken
Die Function-Point-Analyse wurde ursprünglich entworfen, um die Größe einer Software zu ermitteln und mit anderen Projekten zu vergleichen. Mit einer breit genug definierten Vergleichsbasis lassen sich entsprechende Aussage treffen. Einer solche Aussage wäre beispielsweise eine Schätzung zu den Kosten, die eine Software in ihrer Entstehung verursacht. Für eine Function-Point-Analyse benötigt man jedoch speziell ausgebildete Berater, was den Einsatz dieser Schätzmethode erheblich verteuert. Das Ergebnis der Analyse kann zudem nur so gut sein, wie sich zum einen die eingesetzten Technologien vergleichen lassen und zum anderen wie groß der Erfahrungsschatz der Function-Point-Berater ist. Außerdem muss jede Änderung oder Neuentwicklung im Rahmen des Projekts in FP ausgedrückt werden – ein nicht zu unterschätzender Arbeitsaufwand. Heute wird die Function-Point-Analyse eher benutzt, um Kennzahlen im Bereich Effektivität zu ermitteln.
Deshalb setzen einige Unternehmen die Function-Point-Analyse mit Vergleichsdatenbanken (VDB) ein. Allerdings kritisieren viele Experten die Vertrauenswürdigkeit und das Qualitätsversprechen solcher Datenbanken. Wer sich mit VDB beschäftigt, beschäftigt sich zudem sehr viel mit historischen Daten, deren Aussagekraft für aktuelle Projekte eher gering ist. Beide Methoden bewegen sich darüber hinaus von den Ressourcen eines Unternehmens weg, mit dem es Projektkosten einschätzt: Den eigenen IT-Experten. Sie können im Rahmen eines IT-Projekts am besten den Aufwand für die kleinsten, atomaren Aufgaben abschätzen, wie etwa für die Erstellung eines Design-Dokuments, die Entscheidung zur Änderungen von Source Files oder die Durchführung eines Softwaretests. Jedoch sollte es bei einer rein menschlichen Schätzung nicht bleiben.
Exakte Kosten für Tests, Design und Entwicklung
Auf die Ressource IT-Experte baut Perspective Estimation von ProArchCon auf. Die Schätzmethodologie der Software basiert auf hunderten Expertenschätzungen zu atomaren Projektaufgaben. Hier wird also nicht abstrahiert, sondern anhand eigener Algorithmen, die sich dieser Expertenschätzungen bedienen, kalkuliert. Die ProArchCon-Anwendung ermittelt die Kosten und den Zeitaufwand für Testfälle sowie für die Bereiche Design und Entwicklung ermitteln. Für die fachlichen und nicht-funktionalen Anforderungen eines IT-Vorhabens wird ein Katalog exakter Funktionsversprechen, sogenannte Quality Statements, definiert.
Die IT-Experten fertigen eine Liste der atomaren Änderungen (Artefakte und Testfälle) und deren Schätzungen an. Damit sind Dokumente, Schnittstellen etc. gemeint, also sämtliche im Rahmen eines IT-Projekts erstellte Design-, Development- und Testliefergegenstände. Perspective Estimation schätzt den Aufwand für die Erstellung solcher Artefakte und Testfälle software-agnostisch ein. Die Quality Statements, die Artefakte und die Testfälle werden dann zueinander zugeordnet (in einer „many-to-many“-Beziehung). Im Anschluss erstellen die Projektleiter des Unternehmens ein Projekt und wählen die Quality Statements aus, die damit abgesichert werden sollen. Perspective Estimation zieht die Schätzungen der Artefakte und Testfälle an und normalisiert die Ergebnisse. Dadurch liefert Perspective Estimation Informationen über den Zeit- und Kostenaufwand für die Artefakte und Testfälle, die dem jeweiligen Quality Statement zugeordnet sind. Die Artefakte und Testfälle lassen sich auf bis zu 15 Minuten genau taxieren. Ebenso ermittelt Perspective Estimation auf der einzelne Artefakt- bzw. Testfallebene Informationen zu Risiko und Uplift. So wird vermieden, dass grobe Uplifts zum Beispiel mit einem 15-prozentigen Risiko auf das ganze Projekt gesetzt werden. Mehrere Testfälle lasen sich zudem in Szenarien zusammenfassen. Die Quality Statements können flexibel gewählt werden, um Alternativschätzungen zu erhalten.
Die Kostenabschätzung auf atomarer Ebene erlaubt exakte Aussagen über die zu erwartenden Kosten, denn Perspective Estimation verkleinert die Schätzdifferenz, ohne mit abstrahierten Werten zu arbeiten. So können Unternehmen ihr IT-Budget intelligenter und gewinnbringender einsetzen. Die Zahl der IT-Projekte, die ein Unternehmen umsetzen kann, erhöht sich durch den Umstand, dass kein Geld mehr in Projekten verbrannt wird. Letztendlich verbessert Perspective Estimation auch die Kommunikation zwischen IT-Abteilung und Stakeholdern, da nun gesicherte Daten über Kosten und Aufwand vorliegen, die nicht auf dem Bauchgefühl des IT-Projektleiters beruhen, für das er sich nur schwer rechtfertigen kann, wenn die Planungen (mal wieder) daneben liegen.
