Vor einigen Jahren verließ ich meine Firma, die Projekte sehr strukturiert abwickelte, und trat eine neue Stelle als Projektleiter bei der IT-Abteilung eines ausländischen Unternehmens an. Die Reputation dieses Unternehmens war sehr gut, deshalb vermutete ich, dass es auch im Projektmanagement einen hohen Reifegrad hätte. Doch als ich ankam, schockte mich die Projektkultur, die diesen Namen gar nicht verdiente: Es herrschte eher eine Wild-West-Mentalität, ganz nach dem Motto: "Jeder macht was er will, keiner was er soll, aber alle machen mit!"

Willkommen im Wilden Westen

Sie müssen sich mein neues Arbeitsumfeld folgendermaßen vorstellen: Es gab zwar viele Projekte und entsprechend viele Projektleiter, aber in vielen Projekten weder Planung noch Risikomanagement oder andere Disziplinen. Die Zusammenarbeit zwischen den auftraggebenden Fachabteilungen (Kunden) und der IT-Abteilung wurde für jedes Projekt neu definiert. Das war wegen des hohen Aufwands teuer, vor allem aber riskant, da viele der Applikationen miteinander verbunden und vernetzt waren. Unterschiedliche Vorgehensweisen bei der Weiterentwicklung der verknüpften Anwendungen sorgten für Abstimmungsprobleme und gefährdeten die Zuverlässigkeit der Produkte.

Die Koordination der Entwicklung selbst lief gut, die Übergabe an die Produktion des lauffähigen Systems hingegen nicht. Beispielsweise wurden die Zeitpläne für die Inbetriebnahme und die Anwendertests nicht miteinander koordiniert. Als Folge davon wusste der Kunde nicht, wann er testen sollte, und welche Zuarbeit von ihm wann erwartet wurde. Viele der entwickelten Applikationen wurden schließlich ohne weitere Prüfung einfach in die Produktion gebracht, sobald der letzte Kunde seine Freigabe gegeben hatte. Manchmal dauerte dies auch zu lange und man verzichtete auf die Freigabe. Dieses spontane und unkoordinierte Vorgehen wurde beschönigend als "Agiles Projektmanagement" bezeichnet - aber Scrum als wichtigstes agiles Vorgehensmodell war ein Fremdwort.

Es war offensichtlich, dass die Qualität der Projekte verbesserungsbedürftig war. Deshalb gab es bei den obligatorischen Audits regelmäßig Probleme. Diese wurden einfach ignoriert, nicht korrekt behandelt und über Jahre hingezogen.

Die Kunden übten keinen Druck auf die IT-Abteilung aus, zum Beispiel um eine verlässliche Planung zu erhalten. Selbst beim Budgetieren forderten die Kunden keine Verbesserungen ein. Niemand wusste letztendlich, welche Kosten in den Projekten wirklich entstanden, da es keine projektbezogene Aufwandserfassung gab und die Kunden nur pauschalierte Angebote ohne detaillierte Aufwandsschätzung erhielten.

Weder in der IT-Abteilung noch in den Fachabteilungen verfügten die Mitarbeiter über ein Projektmanagement-Know-how, wie es beispielsweise für eine IPMA- oder PMP-Zertifizierung oder für CMMI-kompatible Projekte benötigt wird. Neue Projektleiter oder Junior-Projektleiter konnten sich deshalb an keinen Vorgaben oder Wissenssammlungen orientieren, sondern mussten das Rad immer wieder neu erfinden.

Initiative: Verbesserung des Projektmanagements

Erster Anlauf oder die Kaffeekränzchenfalle

Meine erste Reaktion war, ein Expertenteam für Projektmanagement ins Leben zu rufen. Da es schon ein Konsortium für Technologie gab, war es relativ einfach, meinen Chef und wiederum dessen Chef davon zu überzeugen, dieselbe Idee auf das Projektmanagement anzuwenden.

Ich wollte ein Expertenteam mit einigen wenigen erfahrenen Projektleitern installieren. Meine Vorstellung war, dass dieses Team sich monatlich ca. drei bis vier Stunden trifft, systematisch die Schwächen im Projektmanagement analysiert und nach und nach für jede Disziplin Lösungen erarbeitet, um das Projektmanagement schrittweise zu verbessern. Aber ich wurde von meinen Chefs überstimmt. Es entstand ein unverbindliches Gremium, an dem jeder Projektleiter teilnehmen konnte. Keiner wollte oder musste jedoch verbindliche Aufgaben übernehmen oder Zusagen einhalten. In den ersten Sitzungen diskutierten wir, was eine Projektdefinition sei, später wurde behauptet, dass jedwede Planung sinnlos sei, weil wir dumme Kunden hätten, die uns ungenaue Anforderungen gäben.

Schließlich kam heraus, dass es schon mehrere, aufwändige Versuche gegeben hatte, ein standardisiertes Projektvorgehen einzuführen. Diese waren aber alle an den Projektleitern gescheitert. Ein standardisiertes Vorgehen verbanden sie mit einem sehr hohen Verwaltungsaufwand mit vielen Formularen. Das wollten sie vermeiden. Außerdem befürchteten sie, ihre Projekte nicht mehr so machen zu können, wie sie es wollten.

Nun sahen sie ihre Situation wieder gefährdet und unterminierten das Gremium. Sie lenkten die Diskussionen immer wieder auf andere Themen oder torpedierten Lösungsvorschläge, indem sie behaupteten, dass diese bei ihren Kunden nicht durchsetzbar seien. Dadurch verhinderten sie jeden Konsens. Im Laufe der Zeit nahmen kaum noch Projektleiter an den Sitzungen teil. Sie merkten, dass das Gremium ein zahnloser Tiger und eine Debattiergruppe war und sicher nichts passieren würde, was sie gefährdete. Das Gremium verkam zum Kaffeekränzchen.