Irgendwas läuft schief im Projekt. Aber was genau, kann Hans-Helmut Krause von der Unternehmensberatung Hyperskill nicht sagen. Der Projektleiter soll ein neues Online-Reporting-System in einem mittelständischen Unternehmen einführen, das misst, welcher Mitarbeiter wie viel Zeit an einem Teilschritt zugebracht hat. "Alle waren begeistert, das ganze Unternehmen stand dahinter", erzählt der IT-Berater. Trotzdem wird das System nicht angenommen: Nur schleppend tragen sich die Mitarbeiter ein. Woran es liegt, kann Krause nicht sagen. Das Projekt ist kurz davor zu scheitern. "Da war einfach der Knoten drin, egal, wie oft ich es analysiert habe", sagt Krause.

Dass IT-Projekte scheitern, ist keine Seltenheit: 24 Prozent aller IT-Projekte verlaufen im Sand oder fahren an die Wand, so eine Studie der Standish Group. Oft wissen die Projektleiter nicht, woran es liegt. "An der technischen Seite liegt es meistens nicht - diese Probleme können wir lösen", sagt Krause. Zeit- und Kostenexplosionen sieht er auch nicht als Kernursache, eher als Folge. Schließlich wisse man oft lange vorher, dass da was nicht stimme. "Es liegt an den Menschen, wenn das Projekt den Bach runtergeht", meint Krause.

Unbestritten ist, dass Projekte an Personen scheitern. Die Schuld kann der Projektleiter nicht seinen Mitarbeitern zuschieben - schließlich hat er die Mitarbeiter für das Projekt ausgewählt. Warum nimmt er einen Unwilligen und Unqualifizierten mit hinein? Die Führungskraft muss sich fragen, wie er dagegen hätte ansteuern können, etwa, indem er extern rekrutiert oder intern weiterbildet. Was brächte es, Schuld zuzuweisen? Lösungen müssen her. Die liegen nicht im Projekt selbst. "Man muss dem Projektleiter helfen, nicht dem Projekt", sagt Siegfried Stadler, Projekt-Coach bei Hyperskill.

Ab in die Notaufnahme

Stadler schickt Projektleiter in den "Emergency Room" und zwar immer dann, wenn sie im Verlauf des Projekts ein ungutes Gefühl haben. Dazu hat er seine ganz eigene Theorie entwickelt. Dieses schlechte Gefühl entsteht, wenn Menschen eine Situation nicht bewerten können, sagt er. Können sie das nicht, wissen sie nicht, was zu tun ist. Dann geht es ihnen meist schlecht: "Menschen wollen handlungsfähig bleiben", begründet Stadler seine Theorie. Steht ein Projekt kurz vor der Katastrophe, ist ein Projektleiter meist wie gelähmt.

Damit der Kurs eines Vorhabens geändert wird, braucht ein Projektleiter konkrete Vorschläge: "Wenn er immer nur mit seinem unguten Gefühl kommt, lachen ihn die Leute aus", sagt Stadler. "Da muss man schon mit konkreten Zahlen und Daten kommen." Also ab in die Notaufnahme mit dem Projektleiter. "Das kann schon am Anfang des Projekts stehen oder eben am Ende, wenn der Go-Live-Termin sehr nah rückt und etwas nicht rund läuft", erklärt er.

Probleme in Einzelteile zerlegen

Stadler geht mit einem systemischen Ansatz an die Rettung von Projekten heran und identifiziert, wo es genau hakt. Mit seiner "Hyperskill-Methode" zerlegt Stadler mit dem Projektleiter gemeinsam die Situation und analysiert, welcher Projektbeteiligter welche Rolle innehat. "Wir machen Projektleiter in großen Krisen sofort wieder handlungsfähig", verspricht Stadler vollmundig. Welcher Mitarbeiter arbeitet an welchem Teilbereich, wo gab es Stunk, welches Budget läuft Gefahr, zu explodieren? Das kommt alles auf Karten.

"Die Stichpunkte funktionieren wie Legobausteine", sagt Stadler. Bringt der Projektleiter die Bausteine in Beziehung zueinander, entstehe so der Kontext. "Wir zerlegen die Situation so lange, bis der Projektleiter das Gefühl hat, dass es wieder stimmt", sagt Stadler. Der Projektleiter kommt von selbst auf den Fehler. "Damit lösen wir das Problem nicht." Aber der Entscheider weiß, wo es hakt und kann sich so eine Lösung überlegen.

Das kann bedeuten, dass der Projektleiter selbst abtritt oder die Reißleine im Projekt zieht. "Natürlich kann auch der Projektleiter das Problem sein", sagt Stadler. Das ist zwar zunächst ein Schlag fürs Ego, aber selbst zu erkennen, dass man selber das Problem ist, hat den Vorteil: "Der Projektleiter trifft die Entscheidung selbst und zeigt, dass ihm das Unternehmen wichtig ist." Inwieweit das eine Karriere verkraftet, muss jeder Entscheider selbst wissen.

Einer will das Projekt zum Scheitern bringen

Stadler stellt eine steile These auf: "Scheitert ein Projekt, gibt es oft jemanden, der nicht will, dass das Projekt zum Erfolg führt." Zum Beispiel kann es daran liegen, dass Projekte Strukturen verändern - das mögen viele nicht. Dann bringen sie ganz unbewusst ein Vorhaben vom Kurs ab. Einige Freelancer bauen darauf, dass sie möglichst lang in einem Projekt angestellt sind - eine rasche Erledigung ist nicht unbedingt die höchste Priorität.

Oder es hakt an einer Person, die nicht liefert, was sie soll. "Dann hat derjenige etwas davon, dass das Projekt nicht läuft oder sich verzögert", sagt Stadler. Das klingt zunächst heftig. Aber dieser Ansatz lässt sich auf ein weiteres bekanntes und beliebtes Problem anwenden: Die Fachabteilung liefert die Daten auch nach mehrmaligem Nachfragen nicht. Das kann am Unwillen der Abteilung liegen - warum sollte sie etwas liefern, was ihr nichts bringt? Für die Abteilung bedeutet das Projekt Veränderung, die sie vielleicht nicht mag. Also bremst sie unbewusst.

Vielleicht hat die Fachabteilung aber auch keine Kapazitäten, weil die Mitarbeiter ohnehin ständig Überstunden machen? "Dann sollte der Projektleiter mit dem Chef sprechen und dafür sorgen, dass mehr Budget für eine weitere Kraft zur Verfügung gestellt wird", sagt Stadler. "Das Budget kann er auch nicht herzaubern."

Was tun, wenn der Chef bremst?

Die Probleme liegen beim Menschen, bewusst oder unbewusst. Projektboykott kann auch heißen, dass ein Freelancer seine Fähigkeiten über Wert verkauft hat und völlig überfordert ist. Das gibt er nur in den seltensten Fällen zu. "Er wird die Schuld anderen zuschieben", sagt Stadler. Ganz schwierig ist es, wenn die Chefetage bremst.

"Hat der CEO das Interesse am Projekt verloren, muss man mit ihm vorsichtig darüber reden", sagt Stadler. Auch daran kann ein Projekt zugrunde gehen, ohne dass der Projektleiter etwas dafür kann. Hat der Projektleiter eine Person identifiziert, die bremst, ist er wieder handlungsfähig, schließlich hat er nun Alternativen. Die sind nicht immer angenehm. Aber der Projektleiter muss nicht mehr passiv ausharren, bis es zum Knall kommt.

Um gegen die menschlichen Fehler im ProjektmanagementProjektmanagement anzugehen, muss der Projektleiter wissen, wo sie liegen. Er kann selbst in den "Emergency Room" gehen und seine Situation analysieren. Selbst wenn das Projekt wegen gravierender Fehler nicht mehr zu beheben ist: Der Projektmanager kann wieder handeln. Auch das ist oft schon ein Erfolg. Alles zu Projektmanagement auf CIO.de

Von Betriebsräten und zankenden Ehefrauen

Projektleiter Krause kann Stadlers These ein Stück weit bestätigen. Er ging ähnlich wie Stadler an die Problemlösung heran: Er beschloss, sich auf einen Teilaspekt der Softwareanalyse zu konzentrieren. "Ich sah mir exemplarisch die Kernressourcen an. Chef und Mitarbeiter standen dahinter und die Software war auch in Ordnung", erzählt Krause. Er hatte allen die Rollen auf dem Papier zugewiesen, am Schluss stand die gesamte Unternehmensorganisation auf dem Blatt. Irgendwann kam ihm die Erkenntnis: "Das spielt noch ein Externer hinein, der etwas gegen das Projekt hat." Eher durch Zufall gelangte Krause zu dem Schluss: "Der Betriebsrat bremst die Einführung des Projekts."

Er habe das nicht bewusst hintertrieben, sondern habe sich tatsächlich Sorgen gemacht, ob das nicht zu einer Überwachung der Mitarbeiter führen würde. Er erfüllte nur seine Rolle, die er im Unternehmen spielte. "Die Mitarbeiter waren hin- und hergerissen. Sie wollten das Programm nutzen, aber sich kontrollieren lassen wollten sie sich auch nicht", sagt Krause. Er setzte sich schließlich mit dem Betriebsrat zusammen - dann erst war das Projekt erfolgreich. "Meine Kernerfahrung, die ich daraus mitgenommen habe: Es sind oft die menschlichen Dinge, die das Projekt zum Scheitern bringen."

Welche absurden Blüten die menschliche Komponente treiben kann, hat Krause mehrfach erlebt. "Einmal wäre ein mehrjähriges IT-Projekt beinah gescheitert, weil sich die beiden Ehefrauen der Kerningenieure gestritten haben. Daraufhin haben auch die Experten nicht mehr miteinander geredet", erzählt Krause. Ein Millionen-schweres Projekt wäre beinah gegen die Wand gefahren, weil eine Ehefrau der anderen gesagt hatte, dass sie zugenommen hat.