Es ist zwanzig Jahre her - doch wenn Dana B. Harris von seinem größten gescheiterten IT-Projekt erzählt, benutzt sie noch immer Worte wie "Depression" und "Schmerz". Soll sie auch, meint Michael Fitzgerald. Über Gefühle zu sprechen, ist Teil der Verarbeitung solcher Erfahrungen. Fitzgerald hat sich für unsere US-Schwesterpublikation Computerworld in der Branche umgehört.
Fazit: Es spielt kaum eine Rolle, ob ein Projekt durch eigene Fehler oder "höhere Gewalt" gefloppt ist. Das IT-Team wird sich so oder so demotiviert und schlecht fühlen. Ein CIO muss das auffangen, sowohl der Firmenleitung wie dem eigenen Team gegenüber.
Im Falle von Harris lag es nicht in ihrer Hand. Sie arbeitete damals bei einer Rüstungsfirma, der mit dem Ende des Kalten Krieges Märkte wegbrachen. Damit stoppte das Management ein Software-Projekt, von dem Harris und ihr Team überzeugt waren und an dem sie gern gearbeitet hatten. "Unsere Arbeit, unser Einsatz wurde einfach vom Tisch gewischt" sagt Harris, die heute für die Computer Science Corporation tätig ist. Sie verließ das Rüstungsunternehmen kurz nach dem Ende des Projektes.
Harris war nicht weniger demoralisiert als Sharon K. Gietl, die ihr Projekt selbst in den Sand gesetzt hat. Sie verantwortete die IT in einer großen Anwaltskanzlei und ließ sich durch ihren Netzwerk-Manager von einem LAN Upgrade überzeugen, obwohl die Technologie damals unerprobt war. Nach einem Monat Kampf mit ständigen Netzwerk-Problemen brach sie das Projekt ab. Und bekannte vor dem Management Farbe.
"Das hat sie genau richtig gemacht", kommentiert Ken Corless vom Berater Accenture. Klare Kommunikation sei in einer solchen Situation das Beste. Gietl sagt selbst, sie habe sich zwar noch eine Menge Witze über "computerlose Freitage" anhören müssen, aber die Lage habe sich durch ihre offenen Worte entspannt.
Das setzt allerdings erst einmal voraus, dass ITler ihre eigenen Gefühle zur Kenntnis nehmen, sagt Bill Hagerup vom Berater Ouellette & Associates. Seine These: Wenn Unternehmen "Star Trek" wären, wäre die IT Mr. Spock. Der Halbvulkanier mit den markanten Ohren scheint menschliche Gefühle nicht zu kennen und lässt sich maximal dazu hinreißen, eine Augenbraue hochzuziehen.
Hagerup hat vor seiner Zeit als Berater selbst in der IT-Abteilung einer Versicherung gearbeitet. Er scheiterte mit einem Projekt, für das das Management schlicht und einfach viel zu wenig Zeit einräumte. Innerhalb der gesetzten Frist konnte das Team nur etwa 60 Prozent der geforderten Leistung abliefern.
Wie IT-Teams trauern
Heute vergleicht er die Gefühle seines Teams mit dem sogenannten Trauer-Zyklus der Sterbeforscherin Elisabeth Kübler-Ross. Auf eine erste Verleugnung des Ereignisses folgen Wut und so etwas wie der Versuch, mit Gott zu verhandeln. Schließlich rutscht der Trauernde in eine Depression und kann, wenn diese überstanden ist, den Verlust akzeptieren. "Langsam kamen wir da wieder raus", erinnert sich Hagerup.
Eine große Hilfe sei dabei das Reden gewesen, so Hagerup. Er sei aber nach wie vor enttäuscht über die fehlende Unterstützung durch das Management - und durch seinen damaligen CIO. In dieses Horn stößt auch Michael Krigsman vom Berater Asuret. Nach seinen Worten läuft die Sache üblicherweise wie folgt:
- Team zum Projekt-Manager: "Hast Du die Deadline gesehen? Das wäre nicht einmal zu schaffen, wenn wir rund um die Uhr durcharbeiten!"
- Projekt-Manager zum CIO: "Das Projekt hat, na ja, so seine Tücken. Wir bräuchten mehr Zeit!" Darauf der CIO (scherzhaft mit dem Finger drohend): "Sie müssen es aber hinkriegen!"
- CIO zum Business: "Ich habe mit dem Projekt-Manager gesprochen. Den Leute ist klar, dass sie es schaffen müssen."
Krigsman bezeichnet so etwas als dysfunktional. Hintergründig schwinge die Drohung mit, dass irgendjemand gefeuert wird, wenn das Projekt schiefgeht. Infolgedessen steckten sämtliche Mitarbeiter den Kopf in den Sand und wurschtelten vor sich hin. Insgeheim hoffe jeder, dass irgendein anderer endlich den Mut habe, offen zu sagen: "Wir schaffen das nicht."
Schuldzuweisungen sind unprofessionell
Dabei seien Schuldzuweisungen in einer solchen Situation unangebracht, unprofessionell und unnötig, sagt Harris. John Fisher von Net Inc. gibt IT-Verantwortlichen folgende Tipps mit auf den Weg:
1. Von den Erfahrungen anderer lernen. Als Fisher selbst noch in der IT arbeitete und für die Continental Illinois Bank eine International-Banking-Plattform aufbauen sollte, hörte er von den schlechten Erfahrungen anderer Banken mit derselben Software, die auch er nutzen wollte. Bei so etwas sollte immer die Alarmglocke schrillen.
2. Früh und regelmäßig den Erfolg überprüfen.
Projekte nicht vorschnell schlechtreden
3. Keine schlechte Stimmung aufkommen lassen: berechtige Vorsicht oder Skepsis darf nicht dazu führen, dass ein Projekt zu schnell schlechtgeredet wird. Projekt-Manager sollten darauf, achten, ob jemand negative Stimmung verbreitet.
Michael Fitzgeralds Text ist unter dem Titel "When IT Projects founder, emotions run high" erschienen.