Scheitern Projekte, weisen die Stakeholder die Schuld meist den im Projekt agierenden Personen zu: Externe Dienstleister hätten mehr versprochen als sie leisten könnten, der Projektauftraggeber hätte das Vorhaben überfrachtet, die Kunden hätten den Preis zu stark gedrückt. Im Zentrum der Kritik steht dabei oft die Projektleitung, der vorgeworfen wird, die erkennbaren Probleme nicht aus dem Weg geräumt zu haben.

Sofern aber der Projektleiter / die Projektleiterin über ausreichende Projektmanagementqualifikation sowie Führungserfahrung verfügt, sind Schwierigkeiten im Projekt oft im Projektumfeld bzw. in den Rahmenbedingungen begründet, die der Projektleiter / die Projektleiterin nicht beeinflussen kann. Die Verantwortung des Projektleiters / der Projektleiterin besteht allerdings darin, laufend zu überprüfen, ob ein Projekt noch Aussicht auf Erfolg hat und, falls dies nicht mehr der Fall ist, die Entscheidung zum Projektabbruch herbeizuführen.

Anhand eines realen Projekts aus meiner eigenen Erfahrung (im Folgenden "Beispielprojekt" genannt) möchte ich einerseits aufzeigen, welche Faktoren dazu beitragen, dass ein Projekt abgebrochen werden muss. Andererseits möchte ich Wege beschreiben, wie eine kompetente Projektleitung in diesem Fall vorgehen kann, so dass sie für sich selbst keine negative Konsequenzen befürchten muss und den Stakeholdern die Vorteile des Projektabbruchs vermitteln kann.

Beispielprojekt: Projektabbruch auf halbem Weg

Das Beispielprojekt begann nach einer Vorbereitungsphase im Oktober 2006 mit der Ausschreibung und Vergabe einer IT-Dienstleistung. Die Stadt Zürich beabsichtigte, die vier bestehenden Software-Tools für die Fallführung im Sozialwesen und alle dazugehörigen Finanzprozesse zu einer einzigen Lösung zusammenzufassen, dadurch die Geschäftsprozesse zu vereinfachen und somit wesentliche Kosten einzusparen. Für das Projekt "Fallmanagement Modell Zürich" (FAMOZ) wurde ein Budget von mehr als zehn Mio. Schweizer Franken (alle erwähnten Kosten beinhalten immer einen hohen Anteil an Eigenleistungen) bewilligt. Im April 2007 bewilligte der Stadtrat eine Erhöhung des Budgets um eine halbe Mio. Franken für die Realisierung einer Datawarehouse-Lösung, die statistische Auswertungen durchführen und Management-Informationen aufbereiten sollte.

Die neue Software wurde 2008 in zwei Etappen produktiv gesetzt. Allerdings stellte sich in der Praxis heraus, dass das IT-System die Geschäftsabwicklung der Fallführung unzureichend unterstützte und hohen Bearbeitungsaufwand erzeugte. Die erhoffte Personaleinsparung konnte nicht realisiert werden.

Der erste Turnaround: Engagiert aber nicht zielführend

Nachdem auch erhebliche Nacharbeiten nicht den gewünschten Erfolg zeigten, wurde 2009 versucht, mit einem Turnaround möglichst vieles in den Griff zu bekommen. Rückblickend hätte eine Analyse zu diesem Zeitpunkt bereits zeigen müssen: "Zu viele verschiedene externe Personen kümmern sich um die Projektaktivitäten, aber keine von ihnen übernimmt tatsächlich die Verantwortung." Zu diesem Zeitpunkt waren der Generalunternehmer, der Unterauftragnehmer, ein Berater für den technischen Review und ein Berater für die Begleitung des Turnarounds im Einsatz.

Es folgten weitere Monate engagierter, aber nicht immer zielführender Projektarbeit. Für den Zeitraum von Januar bis August 2010 wurde für ein Anschlussprojekt mit Namen "FAMOZ 2" ein weiteres Budget von mehreren Mio. Franken bewilligt. Im Januar 2010 schied der interne Projektleiter mit einem Burnout aus dem Projekt aus.

Plötzlich Projektleiterin: Klappt der zweite Turnaround?

Dies war der Zeitpunkt, an dem ich die Projektleitung von einem Tag auf den anderen übernehmen musste. Es ist sicherlich nachvollziehbar, dass ich dabei ein ambivalentes Gefühl hatte. Entweder war der Turnaround wirklich noch zu schaffen oder es bestand die Gefahr, schließlich als "Projekt-Looser" dazustehen. Es galt, einen schnellen Aktionsplan zurechtzulegen. Die Zeit und das zur Verfügung stehende Budget waren in Anbetracht der Aufgabe sehr knapp, ich konnte bereits zu diesem Zeitpunkt absehen, dass weitere Finanzmittel erforderlich werden würden. Die Analyse des Projektumfelds war schnell erstellt und nicht unbedingt hoch motivierend.

Im Juni 2010 führte ich zur Neuorientierung und gemeinsamen Zielfindung einen dreitägigen Workshop mit 42 Beteiligten durch. Dieser wurde nach der Methode der Syntegration© nach Stafford Beer durchgeführt und war erfolgreich, weil vornehmlich das gegenseitige Verständnis gestärkt und neues Vertrauen in die vorhandenen Kompetenzen des Projektteams aufgebaut werden konnte. Die Ziele wurden neu festgelegt und alle Beteiligten waren Teil dieser Definition, so dass die neue Richtung für alle geklärt und vereinbart war. Die weiterhin im Projekt Beteiligten konnten nun noch einmal mit neuem Schwung und geeinter Kraft die aktualisierten Ziele in Angriff nehmen. Die intensiven Diskussionen der drei gemeinsamen Tage erhöhten deutlich das Vertrauen in die Stärke des Teams. Die Beteiligten, auch die Externen, verpflichteten sich auf das Vorgehen und waren bereit, das Vorhaben durchzuziehen.

Neuer Name – neues Glück?

Im September 2010 starteten wir das neu definierte Projekt auch unter einem neuen Namen: "Elektronisch unterstützte Soziale Arbeit" (ELUSA) mit einem deutlich reduzierten Funktionsumfang.