Projekte scheitern immer am Menschen

Erste Hilfe für Projekte

20.11.2023 von Bettina Dobe
Wie Sie ein Projekt immer noch retten können: Der Leiter muss in den "Emergency Room" und herausfinden, wer absichtlich bremst. Einer ist immer schuld.

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.

Meistens liegt es an den Menschen, wenn ein Projekt scheitert.
Foto: auremar - Fotolia.com

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

Siegfried Stadler schickt Projektleiter in den "Emergency Room".
Foto: Siegfried Stadler

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.

Probleme frühzeitig wahrnehmen
Damit man ein Projekt gar nicht erst in die "Notaufnahme für Projekte" schicken muss, hat Projektberaterin Andrea Ramscheidt ein paar Tipps zusammengestellt. Je früher sich ein Entscheider dazu Gedanken macht, desto besser.
Viel Zeit am Anfang
Welche Ziele ein Projekt erreichen soll, dafür sollte man sich gerade am Anfang viel Zeit nehmen. Menschen neigen dazu, schnell etwas zu beginnen. Dass man am Ziel vorbeischießt, merkt man erst nach einer Weile. Da kann es schon zu spät sein. Am Beginn eines Projekts sollte daher eine Stakeholder-Analyse stehen, mit Inhalts- und Ablaufplanung.
Nicht unter Druck setzen lassen
"Sagen Sie nicht Termin, Budget und Teilziele zu, bevor Sie einen ganz genauen Überblick haben“, rät Ramscheidt. Eine valide Prüfung braucht Zeit, schließlich muss alles genau berechnet werden. Die Zeit muss man sich als Projektleiter nehmen. Hat man alles genau geprüft und hält Zeitplan und Budget für enigermaßen realistisch, kann man loslegen. So muss man später nicht „nein“ sagen.
An einen Kollegen wenden
Bewährt habe sich, so Ramscheidt, sich früh an einen Externen zu wenden oder – noch besser – an einen Kollegen, der die Firma kennt, aber nicht im Projekt mitarbeitet. „Das gibt eine zusätzliche Sichtweise und ist für jedes Projekt wertvoll.“ Eventuelle Probleme können besprochen werden, bevor sie akut werden.
Offene Kommunikation etablieren
Ein Projektleiter sollte darauf achten, wie die Kommunikation im Team funktioniert. „Tauschen sich die Beteiligten nur während der Meetings aus oder reden sie auch mal beim Mittagessen über mögliche Probleme?“, sagt Ramscheidt. Es sei Aufgabe des Projektleiters, eine offene Kommunikation zu etablieren.
Besser als nichts
„Ein Projektleiter muss sich die Frage stellen, ob das Vorhaben noch Sinn macht oder ob es man es aufgeben sollte“, sagt Ramscheidt. „Er sollte aber auf jeden Fall Ruhe bewahren.“ Hat sich der Projektleiter eingestanden, dass das Projekt im Argen ist, muss er sich vor Augen führen: „Wie ist die Situation jetzt und welche Handlungsalternativen habe ich? Kann ich vielleicht noch Teilziele erreichen oder etwa eine Software nur mit Teilfunktionen live gehen lassen“, sagt Ramscheidt. Das ist immerhin noch besser, als das Projekt ganz abzuschreiben.
Schuldzuweisungen bringen nichts
Eines muss klar sein: Schuldzuweisungen bringen keine Lösungen. Vielmehr sollte sich der Projektleiter darauf konzentrieren, welcher Mitarbeiter im Team welche Ressourcen braucht, um seinen Teil noch zu schaffen. Wenn es nicht zu retten ist, sagt Ramscheidt: „Den Mut aufzubringen, zuzugeben, dass es gescheitert ist: Das ist eine der Aufgaben des Projektleiters.“

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.

So manchem Projektleiter sind die Dimensionen des Projekts schon über den Kopf gewachsen.
Foto: Altitude Visual - shutterstock.com

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 Projektmanagement 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.

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."

Projektleiter Hans-Helmut Krause weiß, dass oft Menschliches Projekte scheitern lässt, nicht die Technik.
Foto: Hans-Helmut Krause

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.

So retten Sie ein Projekt frühzeitig

Damit es gar nicht erst so weit kommt, gibt die selbständige Projektberaterin Andrea Ramscheidt Tipps. Ganz wichtig: "Für die Klärung der Ziele muss man sich am Anfang viel Zeit nehmen. Menschen neigen dazu, schnell etwas zu beginnen", sagt sie. Dass man am Ziel vorbeischießt, merke man erst nach einer Weile.

Am Beginn eines Projekts sollte eine Stakeholder-Analyse stehen mit anschließender Inhalts- und Ablaufplanung. "Sagen Sie nicht Termin, Budget und Teilziele zu, bevor Sie einen ganz genauen Überblick haben", rät Ramscheidt. "Die Zeit muss man sich als Projektleiter nehmen, alles valide zu prüfen." Sie ist überzeugt: Hat man alles genau abgewogen und hält die Berechnungen für realistisch, muss man später nicht "nein" sagen.

Wer sich frühzeitig mit einem Sparringspartner austauscht, bemerkt schneller Fehler.
Foto: imagINC - Fotolia.com

Bewährt habe sich auch, so Ramscheidt, sich früh an einen externen Sparringspartner zu wenden oder - noch besser - an einen Kollegen, der die Firma kennt, aber nicht im Projekt mitarbeitet. "Das gibt eine zusätzliche Sichtweise und ist für jedes Projekt wertvoll." Eventuelle Probleme können besprochen werden, bevor sie akut werden.

Kommunikation ist alles

Ein Projektleiter sollte darauf achten, wie und ob die Kommunikation im Team funktioniert. "Tauschen sich die Beteiligten nur während der Meetings aus oder reden sie auch mal beim Mittagessen über mögliche Probleme?", fragt Ramscheidt. Es sei Aufgabe des Projektleiters, eine offene Kommunikation zu etablieren.

Hat der Führungsverantwortliche trotz allem ein Zeit- oder Budgetproblem, sagt die Projektberaterin ganz klar: "Ein Budget explodiert nicht so einfach." Das sei häufig die Folge mangelnder Planverfolgung. Ein möglicher Grund: Wechselnde Verantwortungen und wechselnde Projektmitarbeiter sind oft die Ursache, wenn das Vorhaben scheitert.

So kommen Sie groß raus ... oder?
Sie möchten, dass Ihre Projekte zäh verlaufen, weil Sie sich damit in der Firma profilieren können? Dann folgen Sie den Ratschlägen von Jürgen Rohr.
Tipp 1
Setzen Sie die Verantwortlichen unter Termindruck. Mit engen Terminen stellen Sie sicher, dass möglichst wenige Betroffene ins Boot geholt werden. Damit vermeiden Sie die sowieso unnötigen Diskussionen um Meinungs- sowie Wahrnehmungsunterschiede.
Tipp 2
Starten Sie mit einer problem-orientierten Ist-Analyse. Fragen Sie immer zuerst danach, was nicht gut läuft. Damit fokussieren Sie die Aufmerksamkeit aller Beteiligten auf die Schwächen der Organisation. Sie stellen sicher, dass niemand auf die Idee kommt, sich auf den Erfolgen der Vergangenheit auszuruhen.
Tipp 3
Geben Sie möglichst kein zusammenfassendes Feedback. Halten Sie die Betroffenen im Unklaren. Das fördert zwar die Gerüchteküche, hält aber den Änderungsaufwand für die Konzeptionierer gering. Sie erhalten schon mit dem ersten Wurf ein Konzept aus einem Guss - ohne lästige und zeitaufwändige Anpassung an unterschiedliche Wahrnehmungen der Beteiligten.
Tipp 4
Lassen Sie das Konzept ohne Beteiligung der Betroffenen ausarbeiten. Hier können Sie Aufwand und Budget einsparen. Jeder Betroffene wird mit seinen individuellen Ansichten sowieso nur das Konzept verwässern. Außerdem: Wenn ein Außenstehender den Sollzustand konzipiert, kommt endlich frischer Wind in die Organisation.
Tipp 5
Vermitteln Sie das Konzept frontal mit mindestens 100 PowerPoint Slides. Hier gilt: Je mehr Input, desto weniger lästige Rückfragen. Halten Sie das Präsentationstempo hoch. Planen Sie ja keine Zeit für die Diskussion ein. Das Konzept steht. Basta!
Tipp 6
Planen Sie keine Zeit für die Überarbeitung des Konzepts ein. Das wäre ja noch schöner: Sie planen knapp bei Budget und Terminen und wollen sich den Erfolg nicht durch unplanbare Überarbeitungsaufwände vermiesen lassen. Denn jede Überarbeitungsschleife würde den schönen Entwurf zerstören.
Tipp 7
Schränken Sie die Zugriffsrechte auf neue Tools möglichst stark ein. Ganz wichtig: Wenn Sie im Rahmen der Organisationsentwicklung neue Werkzeuge (zum Beispiel ein IT-System) einführen, achten Sie darauf, dass niemand außer den Konzeptionierern in der Lage ist, die Werkzeuge anzupassen.
Tipp 8
Lassen Sie die Betroffenen beim Umsetzen des Konzepts alleine. In diesem Punkt gilt das Motto: Die Leute werden sich schon umgewöhnen. Durch die Unterstützung während der Umsetzungsphase könnte wiederum das sorgfältig ausgearbeitete Konzept verwässert werden. Das ist unbedingt zu vermeiden.
Tipp 9
Vermeiden Sie persönlichen Kontakt zwischen den Beteiligten. Stellen Sie sich vor, was Sie hier an Reisekosten einsparen können. Diskussionen können auch per E-Mail geführt werden. Das spart richtig Geld.
Tipp 10
Betrachten Sie jegliches Feedback als persönliche Kritik. Wenn jemand mit einem Feedback zu Ihnen kommt, will er damit eigentlich sagen, dass Sie Ihre Arbeit nicht richtig gemacht haben. Das wirkt sich schlecht auf Ihr Selbstwertgefühl aus.

Nicht jedes Projekt kann gerettet werden. Je eher man sich das eingesteht, desto besser: "Ein Projektleiter muss sich die Frage stellen, ob das Vorhaben noch Sinn macht oder ob es man es in Teilen oder ganz aufgeben sollte", sagt Ramscheidt. "Er sollte aber auf jeden Fall Ruhe bewahren." Hat sich der Projektleiter eingestanden, dass das Projekt im Argen ist, muss er sich vor Augen führen: "Wie ist die Situation jetzt und welche Handlungsalternativen habe ich? Kann ich vielleicht noch Teilziele erreichen oder etwa eine Software nur mit einem Teil der geplanten Funktionen live gehen lassen?", sagt Ramscheidt. So hat sich die Investition wenigstens ein wenig gelohnt.

Eines muss klar sein: "Schuldzuweisungen führen zu keinen Lösungen." Vielmehr sollte sich der Projektleiter darauf konzentrieren, welcher Mitarbeiter im Team welche Ressourcen braucht, um seinen Teil noch zu schaffen. Wenn es doch nicht zu retten ist, rät Ramscheidt: "Rechtzeitig den Mut aufbringen zuzugeben, dass es gescheitert ist: Das ist eine der Aufgaben des Projektleiters."

Spielregeln für das Projekt-Team
Diese Spielregeln sorgen für eine offene Kommunikation und bieten auch im Konfliktfall eine Orientierung.
Tipp 2
Eine offene Kommunikation einhalten.
Tipp 3
Eine konstruktive Zusammenarbeit umsetzen.
Tipp 4
Zu Problemen grundsätzlich Lösungsvorschläge anbieten.
Tipp 6
Keine Arbeitspakete ohne Termin und Verantwortlichen definieren.
Tipp 7
Delegieren von Arbeitspaketen vermeiden.
Tipp 8
Lieber miteinander reden anstatt E-Mail-Ping-Pong zu spielen.
Tipp 9
Keine politischen Spielchen treiben.
Tipp 11
Dynamik entwickeln und auf das gesamte Projektteam sowie alle Anwender übertragen.