Zwar hat sich die Aussicht auf den Erfolg von IT-Projekten über die letzten Jahre verbessert, die Erfolgsquote zeigt aber dennoch ein düsteres Bild. Wie aus dem aktuellen Chaos Report der Standish Group hervorgeht, betrug der Anteil erfolgreicher IT-Projekte im Jahr 2002 34 Prozent. Die gänzlich gescheiterten Projekte schlugen mit 15 Prozent zu Buche, und mehr als die Hälfte der IT-Vorhaben (51%) waren sowohl teurer als geplant als auch später fertiggestellt. Rund zwei Drittel der IT-Projekte wurden also nicht wunschgemäss abgeschlossen.
Der Chaos Report wird von der Standish Group seit 1994 alle zwei Jahre erhoben. Im Jahr 2002 wurden insgesamt 13'522 IT-Projekte untersucht.
Es gibt viele Gründe, warum IT-Projekte scheitern können. Mangelhaftes Projektmanagement oder technologische Probleme sind zwar möglich, sind aber oft nicht die einzigen Gründe für gravierende Probleme. Denn darauf richtet sich ja stets die ganze Aufmerksamkeit. Hier werden die Methoden und Verfahren laufend perfektioniert. Das Übel muss also auch noch andere Wurzeln haben.
In ein Projektteam werden vielleicht etwa zwanzig Menschen (infolge der immer grösser werdenden Spezialisierung werden auch die Teams grösser) beordert; Menschen aus verschiedenen Firmen und Abteilungen, mit unterschiedlichen Ausbildungen, Erfahrungen und Interessen. Die meisten kennen sich nicht. Es gilt, keine Zeit zu verlieren. Die Aufgaben sind gross, und die Zeit ist knapp. Zu Beginn ist der Auftrag vage. Viele Informationen fehlen noch. Trotzdem muss jetzt das Projekt geplant werden: Wie soll man vorgehen? Wer tut was bis wann? Aus gruppendynamischer Sicht ist ein solches Team sozusagen im «Embryostadium», in der sogenannten Forming-Phase: Es hat sich noch keine gemeinsame Kultur entwickeln können. Die gemeinsame Sprache fehlt. Die Beteiligten wissen noch nicht, wie man sich in dieser Gruppe verhalten soll. Es konnte noch kein Vertrauen entstehen. Eine Gruppe tut sich in dieser Phase schwer, Entscheidungen zu treffen. Doch nie mehr im Projekt wird es so viele und so folgenschwere Entscheidungen zu treffen geben, wie gerade jetzt.
Kein Projektleiter käme auf die Idee zu sagen: «Ich muss die Kosten nicht kontrollieren. Wir sind ja alle erwachsene Leute. Jeder weiss, wie viel Zeit er verbrauchen kann. Das wird sich dann schon so ergeben.» Wenn es aber um den Teamentwicklungsprozess geht, ist genau dies die vorherrschende Überzeugung: «Das ergibt sich automatisch.» Keine Frage, Menschen arrangieren sich immer innerhalb von Gruppen. Können wir es uns aber leisten, dies dem Zufall zu überlassen?
Zuerst sollten wir eine solide Basis für Zusammenarbeit schaffen, bevor wir wichtige Entscheide treffen und losstürmen. Was muss aus gruppendynamischer Sicht sichergestellt sein, bevor ein Projekt startet?
• Jeder kennt die beteiligten Personen, deren fachlichen und organisatorischen Hintergrund, deren Einstellungen und Ansichten der projektrelevanten Aspekte und des Umfelds. Damit werden die anderen berechenbar in ihrem Verhalten. Ihre Argumentation wird plausibel. Man kann sein Verhalten darauf ausrichten.
• Es besteht ein gemeinsames Verständnis der Ziele des Projektes. Das geht viel weiter, als nur den Inhalt des Auftrages zu kennen.
• Man erkennt, worüber man bereits heute Konsens im Projektteam hat und wo Zielkonflikte, unterschiedliche Bewertungen oder unterschiedliche Interessen vorhanden sind. Diese Reibungsflächen sollen transparent werden, damit man weiss, woran man arbeiten muss. Hier gilt also: «erst differenzieren – dann integrieren».
Um diesen Status effizient zu erlangen, gibt es professionelle Methoden und Verfahren.
Dass diese Methoden nicht Einzug in die Projekte finden, liegt einerseits am bereits überladenen Aufgabenkatalog des Projektleiters. Er soll die sich widersprechenden Ziele der Ergebnisqualität, der zur Verfügung stehenden Zeit und der möglichst tiefen Kosten unter einen Hut bringen. Funktional bedingt fehlt es ihm an Distanz: Er ist zentral in das soziale System «Projektteam» involviert. Das sind äusserst schwierige Voraussetzungen, um den Teamentwicklungsprozess sinnvoll zu gestalten. Darüber hinaus hat er in seiner Ausbildung kaum Methoden zur Gestaltung von Teamentwicklungsprozessen gelernt. Dort standen andere Themen im Vordergrund.
Auf der anderen Seite haben wir es hier mit kaum messbaren, sogenannt weichen Faktoren zu tun. Was kosten Missverständnisse, schwelende Konflikte, Misstrauen, Unsicherheit? Es ist zum Beispiel kaum möglich, Aussagen darüber zu machen, was die Auswechslung von Schlüsselpersonen während des Projekts kostet. Weil diese Teile der Wirklichkeit so schwer zu beziffern sind, werden sie am liebsten ausgeblendet. So geben die Nachkalkulationen leider oft ein verzerrtes Bild der Projektrealität wieder. Entsprechend verzerrt werden dann auch die Lehren sein, die sich für die folgenden Projekte aus den Erfahrungen ziehen lassen.
Wie finden nun aber diese professionellen Gestaltungsmethoden für Teamentwicklungsprozesse Einzug in IT-Projekte? Ganz pragmatisch: über die Praxis. Entsprechend ausgebildete Fachleute sollen nicht nur Ausbildungssequenzen für IT-Fachleute veranstalten, sondern direkt in die Projektorganisation eingebunden werden. Als Prozessbegleiter haben sie die notwendige Distanz und können die Verantwortung für diesen Teil im Projekt übernehmen. Solange solche Prozessbegleiter nicht Alltag im IT-Projektgeschäft sind, ist die genaue Rollendefinition und speziell die Abgrenzung zu den Aufgaben des Projektleiters vorgängig zwischen den Beteiligten klar zu definieren.
Auf der anderen Seite muss die Ausbildung praxisnäher werden. Es nützt nichts, wenn in Ausbildungslehrgängen Konzepte wie die Maslowsche Motivationstheorie, die Phasen der Gruppenentwicklung und Watzlawicks Kommunikations-Axiome vermittelt werden, solange die Lehrgangsteilnehmer nicht sehen, wie diese Erkenntnisse in Projekten praktisch umgesetzt werden können. Ein Projektleiter muss Probleme ganzheitlich lösen, und darauf muss ihn seine Ausbildung vorbereiten. Aus allgemeiner Systemtheorie muss vernetztes Denken für Projektmanager werden. Dazu müssen wir aber beginnen, bereits die Ausbildungsdisziplinen zu vernetzen und nicht, sie auseinander zu dividieren.
Erfolgsaussichten von IT-Projekten
Dani Rey, dipl. Psychologe FH und Informatik-Projektleiter mit Eidg. FA, ist als selbständiger Organisationsberater und Coach tätig. Er ist Lehrbeauftragter am Institut für Informatik der Uni Zürich sowie für die WISS Wirtschaftsinformatikerschule Schweiz und IFA The Knowledge Company als Referent tätig.
Kontakt: drey@danirey.ch
;
www.danirey.chh
