Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Stolpersteine im Projektmanagement

Warum IT-Projekte aus dem Ruder laufen

04.06.2013
Größere komplexe Projekte - nicht nur in der IT Branche - haben die Tendenz sowohl terminlich, als auch vom Budget her aus dem Ruder zu laufen. Woran das liegt, und wie Unternehmen und IT-Dienstleister diese Schieflagen vermeiden können, erklärt Thomas Wittbecker, Geschäftsführer der Adacor Hosting GmbH.
Thomas Wittbecker, Geschäftsführender Gesellschafter der Adacor Hosting GmbH
Thomas Wittbecker, Geschäftsführender Gesellschafter der Adacor Hosting GmbH
Foto: Adacor

Größere komplexe Projekte - nicht nur in der IT Branche - haben die Tendenz sowohl terminlich, als auch vom Budget her aus dem Ruder zu laufen. Oft nimmt die Katastrophe schon bei der Ausschreibung ihren Lauf und setzt sich im Projektmanagement fort. Dabei könnten sich die größten Stolpersteine schon im Ansatz umgehen lassen.
von Thomas Wittbecker (Geschäftsführer der Adacor Hosting GmbH)
Je nachdem, welche aktuelle Studie man zugrunde legt sind bei größeren IT Projekten 70 bis 80 Prozent der Projekte "Out of Time” oder "Out of Budget”. Da drängt sich natürlich die Frage auf, ob da nur Laien am Werk sind, oder ob es andere Gründe für die Probleme gibt.

Die Beleuchtung der drei projektbestimmenden Eckpunkte Budget, Deadline und Fachlichkeit bringen dabei Licht ins Dunkel.

Aus der eigenen Erfahrung kann ich das nur für komplexe Hosting-Projekte beurteilen, allerdings dürften die Probleme eher grundsätzlicher Natur sein und in allen Branchen auftreten.

Schauen wir uns die Rahmenbedingungen von etwas größeren Projekten an: alle Projekte haben ein Budget, einen Zeitrahmen mit Deadlines und eine definierte Fachlichkeit, meist über ein Pflichten- oder Lastenheft beschrieben. Das sind die drei Eckpunkte, die ein Projekt festnageln.

Bei kleinen, einfach gelagerten Projekten funktioniert das auch hervorragend. Solange man sich ein wenig Mühe gibt, die Fachlichkeit genau definiert, das benötigte Budget zusammenrechnet und sich genau überlegt, wie lange man braucht.

Bei Projekten, die man immer wieder umsetzt, und bei denen man sich genau auskennt, funktioniert das: Auspuff reparieren, Wohnzimmer anstreichen, Standard Webserver aufsetzen und zur Verfügung stellen.

Die Grenzen des Schätzens in der Praxis

Problematischer wird es bei Projekten, die komplexer sind und bei denen die Projektverantwortlichen Neuland betreten. Hier fangen wir an Annahmen zu treffen und zu schätzen - und zwar viele Male.
Leider sind wir Menschen extrem schlecht im Schätzen.
Die Adacor betreibt im Kerngeschäft Individualprojekte. Software wird individuell entwickelt und dann von uns betrieben - und das teilweise mit Hunderten bis Millionen Nutzern, je nach Art des Projektes. Zu dem Zeitpunkt an dem der Betrieb der Infrastruktur ausgeschrieben wird, ist in der Regel die Software noch nicht einmal fertig entwickelt, man weiß nicht genau wie viele Leute zugreifen werden und wie diese die Software nutzen.
Aber es gibt schon eine klare Anforderung an die Infrastruktur und man möchte feste SLAs eine feste Architektur und eine definierte Verfügbarkeit zum Festpreis.

Die Katastrophe beginnt bei der Ausschreibung: Ein Beispiel

Eine typische Situation aus der Praxis. Wir bekommen eine Ausschreibung auf den Tisch, ca. 100 Seiten, Infrastruktur für ein neues Projekt, Software wird noch entwickelt und alles genau spezifiziert. Für die Erstellung der Ausschreibung wurde sogar eine Consulting Firma beauftragt.

  • Nach Lektüre der Ausschreibung und ein wenig Analyse antworten wir: Leider können wir nicht an der Ausschreibung teilnehmen, weil die Spezifikationen technisch gesehen nicht funktionieren werden. Natürlich mit Begründung.

  • Antwort: Bitte nehmen Sie trotzdem teil und bieten etwas an, was nicht funktioniert, damit die Vergleichbarkeit gewahrt bleibt.

  • Da denke ich mir: "Na super. Wie wird das Projekt wohl laufen?" Das bedeutet im Klartext: Man weiß eigentlich noch nicht sicher, was man im Detail benötigt, aber man schreibt es schon fest. Man weiß auch nicht wie viel man benötigt, dafür schreibt man das auch schon fest, mit einem festen Preis. Dann wird auch noch der Termin für das "going live” gefixt und fertig ist die Katastrophe.

Bei solchen Projekten gibt es auch noch immer mehrere Parteien (mindestens Kunde, Software-Dienstleister und uns), die alle drei ihre Aufgaben erfüllen und Deadlines einhalten müssen.

Wenn jetzt alle drei Säulen - Fachkonzept, Budget und Deadline - fixiert werden und sich dann herausstellt, dass irgendwelche Annahmen und Schätzungen falsch waren, explodiert das Projekt.

Und mal ehrlich, wie wahrscheinlich ist es bei einem Projekt, in dem es um etwas Neues geht und man keinerlei Erfahrungswerte hat, dass man treffgenaue Schätzungen abgibt? Gleich Null!

Demgemäß ist auch die Wahrscheinlichkeit nicht sehr hoch, dass ein Projekt genauso läuft wie geplant und alle drei Eckpunkte eingehalten werden. Nur sind dann alle überrascht und entsetzt, dass die böse Realität sich einen Weg gebahnt hat.

Halten wir also fest

  1. Bei komplexen Projekten ist es unglaublich schwierig, die genauen fachlichen Anforderungen schon vor Beginn des Projektes zu definieren, da die Erfahrung fehlt. Deshalb werden Annahmen getroffen.

  2. Wir Menschen sind schlecht im Schätzen, vor allem wenn wir wenig Erfahrungswerte haben. Das wirkt sich besonders negativ auf die Frage der Dauer aus.

  3. Also können wir nicht davon ausgehen, dass wir ein Projekt exakt im Voraus planen können, ohne eine Menge Fehler zu begehen.