Stolpersteine im Projektmanagement
Warum IT-Projekte aus dem Ruder laufen
Foto: Adacor
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.
- Wann läuft ein Projekt schief
Die Reißleine ziehen - wann und woran lässt sich erkennen, dass ein Projekt aus dem Ruder läuft? - Ist für das Projekt eine Zeitdauer von mehr als eineinhalb Jahren vorgesehen?
Dann ist es besser, das Projekt in kleinere Teilschritte zu gliedern und Geschäftsprozesse nacheinander umsetzen. Der Grund: Ein Unternehmen entwickelt sich in zwei Jahren weiter, Geschäftsprozesse verändern sich und die ursprünglich geplanten Projektumfänge sind nicht mehr dieselben. Selbst ein sauber aufgesetztes Change-Management greift immer in die laufende und noch nicht vollständige Implementierung ein. - Werden Meilensteintermine überschritten?
Spätestens wenn der erste Termin überschritten wird, muss die Projektleitung dem sofort Rechnung tragen und gemeinsam mit dem Lenkungsausschuss die geplanten Maßnahmen kritisch prüfen. - Gibt es viele Änderungen während des Projektes?
Tauchen während der Projektlaufzeit permanent Änderungen auf, war die Planung schlecht oder die Realität überholt die Einführung. In diesen Fällen sollten alle Beteiligten offen über die absehbaren Risiken sprechen und realistische Gegenmaßnahmen entwickeln, die den Projekterfolg sicherstellen. Oder gemeinsam entscheiden, Termin- und Budgetanpassungen vorzunehmen. - Stimmen die zwischenmenschlichen Beziehungen noch?
Kommt es zwischen Beratern, Projektleitung und Key Usern vermehrt zu Spannungen, funktioniert die Kommunikation nicht (mehr) richtig. Motivationsprobleme treten auf und es werden oft Schuldige gesucht statt Lösungen. In solchen Fällen sollte umgehend gehandelt werden - dies ist eine der Hauptursachen für scheiternde Projekte! - Ist die vereinbarte Dokumentation ...
... im Projekt aktuell und sind Änderungen sauber dokumentiert? Wenn nicht, ist dies ein sicherer Indikator dafür, dass das Projekt aus dem Ruder zu laufen droht. - Stimmt die Qualität ...
... der Implementierungspartner und wie lässt sich mangelndes Wissen der Consultants erkennen? Implementierungsziele, die gerissen werden und Teilschritte, die qualitativ nicht der Planung entsprechen, sind eindeutige Anzeichen der Schwäche. Prüft man Teilschritte in regelmäßigen Abnahmen per Testkatalog, sind Abweichungen leicht festzustellen. - Ein Implementierungspartner ...
... und Verantwortlicher ist immer einfacher zu steuern als mehrere. Vor allem dann, wenn diese in einer Wettbewerbssituation zueinander stehen.