Unsere Sammlung der Projektzitate wächst inzwischen sehr ansehnlich. Kürzlich bekamen wir von Heinrich Unger eine ganze Liste herrlicher Weisheiten.
Hier sind sie:
- Es gibt keine guten Projektmanager, nur solche, die Glück hatten.
- Die Projektdauer wird von der Anzahl der Änderungsanträge bestimmt.
- Es gibt keinen schleichenden Funktionszuwachs! Nur einen rasenden.
- Gerate so früh wie möglich in Verzug! Dann hast Du mehr Zeit, den Rückstand aufzuholen!
- Nach 90% der Projektlaufzeit und 90% des Budgets sind auch 90% der Arbeit erledigt. Die restlichen 10% Arbeit können in den verbleibenden 90% der Zeit und des Budgets bequem erledigt werden.
- Gutes Projektmanagement besteht nicht aus Planen, Überwachen und Steuern. Es geht nur darum, gute Entschuldigungen für die entstandenen Probleme zu finden.
- Projektmanager werden benötigt, weil es in allen Projekten Probleme gibt.
- Probleme gibt es, weil es Projekte gibt.
- Ohne Projektmanager gäbe es keine Projekte.
- Gute Projektmanager fangen erst gar kein Projekt an.
Ich bin immer wieder erstaunt, an welchen scheinbar nebensächlichen Dingen Projekte scheitern können. Das ist die Geschichte eines Projektes das eingestellt wurde. Das Projekt wurde abrupt beendet mit einer sogenannten „Management-Entscheidung“. Die Entscheidung fiel kurz vor Weihnachten. Die Frage, ob das nicht auch früher möglich gewesen wäre, führt zu einer anderen Geschichte (... darüber, wie schnell Manager Entscheidungen treffen oder eben nicht und wie dann mehr oder weniger klar kommuniziert wird…), die zu einem anderen Zeitpunkt erzählt werden soll.
Leider kam das Ende nicht ganz überraschend. Und das Projekt stellt sich natürlich die Frage, ob es soweit hat kommen müssen? Eigentlich lief doch alles ganz gut. Es gab zwar Offene Punkte, die im letzten Meeting mit dem Management Board als dringend zu bearbeiten angemahnt wurden, doch diese Punkte waren nicht unlösbar und auch inzwischen geklärt. Um es in den beliebten Projektstatus-Ampelfarben auszudrücken: das Projekt hatte den Weg von rot zu gelb locker geschafft und war auf dem Weg nach grün. Soweit es die Beurteilung der Fakten und der Projektergebnisse betraf. Die Beurteilung aus der Perspektive des Projektes wohlgemerkt.
Konkret ging die Geschichte so:
Da war einmal ein ambitionierter Projektleiter, der ein ganz schön großes Team von etwa 40 Personen zu managen hatte. Das Team war auch sehr kunterbunt zusammengesetzt. Unterschiedliche Typen von Menschen, unterschiedliche Arbeitsweisen, Erfahrungen und Kommunikationsstile. Nicht zuletzt eine Mischung aus internen Kollegen, externen freiberuflichen Beratern und einem Beratungsteam eines beauftragen Unternehmens. Eine bunte Mischung aus ganz verschiedenen Interessen. Die sollten nun zusammenarbeiten und sich von dem Projektleiter steuern lassen.
Im Team wusste jeder Bescheid, was er zu tun hatte. Was die anderen Kollegen so machten, war zum Teil unklar bis unbekannt. Das führte dazu, dass so manche fachliche Frage eine Weile durch das Projekt geisterte, bis sich jemand fand, der die Antwort wusste. Es ging nichts verloren, nur manche Dinge wurden dadurch etwas mühsam. Niemand wartet gerne lange auf Antworten zu Fragen, die ihm wichtig sind.
Da das Team so groß war, gab es viele verschiedene Themen, die mit Kollegen aus den betroffenen Fachbereichen geklärt und abgestimmt werden mussten. Also redete der eine Kollege aus dem einen Teilprojekt mal mit dem Fachbereich, dann wieder jemand aus einem anderen Teilprojekt. Blöd nur, wenn beide Kollegen nichts voneinander wussten und auch noch Informationen weitergaben, die für die Kollegen aus dem Fachbereich ganz und gar widersprüchlich klangen. Die Kollegen waren verwirrt und wussten nicht, woran sie waren mit dem Projekt. Vertraut man jemandem, der sich scheinbar dauernd widerspricht?
Das Thema des Projektes war recht anspruchsvoll. Um der alten IT-Weisheit entgegenzuwirken, die da sagt „wer testet ist feige“ wurden sehr umfangreiche Tests geplant. Die Leute, die sich fachlich damit gut auskannten, also diejenigen, die die Testfälle auch inhaltlich verstanden, waren mit beteiligt. Es sollte möglichst viel möglichst gründlich getestet werden. Natürlich mit den zukünftigen Nutzern des Projektes, den das waren genau die, die sich fachlich auskannten. Die verstanden nur nichts von den IT-technischen Hintergründen des Projektes. Woher auch. Doch manchmal kamen da Fragen, die die Unsicherheit über diese ganzen technischen Zusammenhänge ausdrückten. Ungeschickt, wenn nie Zeit war, genau zuzuhören und diese Fragen in Ruhe zu beantworten. „Dafür bin ich nicht beauftragt“, so die ganz klare Abgrenzung, die aus dem Team regelmäßig zu hören war.
So nach und nach bekamen die Kollegen „zukünftige Nutzer“ das Gefühl, dass dieses Projekt etwas merkwürdig arbeitete. Eigentlich zu Unrecht, aber der Eindruck war nun mal da. Leider hatte der Projektleiter viel zu wenig Zeit, um sich all diese Sorgen anzuhören. Sonst gab es auch viel zu wenig Mitarbeiter in dem Projekt, die sich mal Zeit nahmen, zuzuhören, wenn jemand aus dem Fachbereich etwas zu erzählen hatte - zu fachlichen Hintergründen oder „historischen Zusammenhängen“ oder Themen, die sowohl das Projekt als auch den Fachbereich betrafen. Geschichten darüber, warum die Dinge gerade so sind, wie sie sind. Meistens gibt es ja für die scheinbar unlogischsten Abläufe einen guten Grund. Wenn man den kennt, versteht man das große Ganze besser.
Das alles führte dazu, dass der Ruf des Projektes nicht der beste war. Technisch gesehen, völlig zu Unrecht, fand das Projekt. Und lag damit gar nicht falsch. Doch geholfen hat es nicht.
Denn eines Tages passierte folgendes: ein anderes Projekt, das weit hinter seinem ursprünglichen Zeitplan lag, verursachte ein paar ordentliche Engpässe bei verfügbaren Ressourcen, Menschen und Technik gleichermaßen. Eine Risikoanalyse wurde durchgeführt. Eine Bewertung aller Projekte im Umfeld dieses anderen Projektes erfolgte. Man verschaffte sich einen Überblick über die Risiken, all diese Projekte nun gleichzeitig durchzuführen. Nicht ganz unerwartet kamen die Mitglieder des Managementboards zu der Überzeugung, dass alle Risiken aller Projekte auf einmal für das Unternehmen gefährlich werden könnten. Und damit erfolgte eine klare Entscheidung. Das Projekt, von dem hier erzählt wurde, wurde zugunsten des anderen Projektes eingestellt.
Ende.
?
Schade für das Projekt. Und den Projektleiter. Nachvollziehbar für das Unternehmen.
Hätte es Alternativen gegeben? Sicher. Aber es fand sich für dieses Projekt kein Fürsprecher. Warum nicht? Technisch war das Projekt ganz in Ordnung. Aber niemand hat gerne mit dem Projekt zusammengearbeitet. „Die haben ja nie zugehört, wenn wir was Wichtiges hatten….“
Liebe Projektteams, achtet doch hin und wieder darauf, ob ihr genug Zuhörer in euren Projekten habt. Und dass jeder ab und zu mal über den eigenen Tellerrand hinausblickt, um zu sehen und zu hören, was sonst noch so läuft und wo er mit wenig Aufwand weiterhelfen kann (auch wenn er nicht „beauftragt“ ist).