7 Faktoren für garantiertes Scheitern

Mitarbeiter nicht wertschätzen, Komplexität unterschätzen oder sich auf Mythen verlassen. Wenn diese und weitere Faktoren berücksichtigt werden, wird Ihr Projekt garantiert scheitern.

Weißt du, dass? Wochen- und monatelang berichtet der Projektleiter über sein Projekt. Natürlich dürfen auch die klassischen Statuslampen nicht fehlen. Und dieser steht ständig auf dem Grün: alles ok. Doch eines Tages schaltet die Ampel plötzlich auf Rot! Folglich beginnt für die Verantwortlichen ein sehr unangenehmer Bearbeitungsprozess. Meistens gilt die erste Frage dem Schuldigen, die zweite den Ursachen und dann widmet man sich nur noch den Lösungsmöglichkeiten.

Nachfolgend sind 7 typische Faktoren aufgeführt, die einen Ausfall fast garantieren.

Faktor 1: Missachten Sie den menschlichen Faktor

In vielen Jahren als Entwickler, Projektleiter, Coach und Krisenmanager habe ich festgestellt, dass zwischenmenschliche Spannungen das größte Hindernis bei der Umsetzung von IT-Projekten sind. Umgekehrt stimmt die Chemie zwischen den Mitarbeitern und es herrscht ein offenes, fehlertolerantes Klima, für alle Schwierigkeiten lassen sich Lösungen finden – auch in kritischen Situationen.

Es liegt in der Natur des Menschen, Konflikte zu vermeiden. Und so ist es nur natürlich, wenn Leute (zB der Projektleiter) komplett ignorieren oder zu lange wegschauen. Aber Konflikte lösen sich meist nicht von alleine auf. Recherche ist gefragt, ebenso Moderation und zumindest der Blick auf Veränderung oder Lösung.

Manchmal sind es die kleinen Dinge, die eine große Wirkung haben, wie zum Beispiel ein neuer Job für einen Mitarbeiter. Oftmals sind jedoch größere Aufwände nötig, wie etwa die Neuorganisation von Teams, um wieder Ruhe ins Projekt zu bringen. Die schlechteste Alternative ist jedoch, den menschlichen Faktor außer Acht zu lassen.

Faktor 2: Zu groß denken oder zu klein machen

Manche Unternehmen übernehmen ein Projekt. Sie unterschätzen die Komplexität, die Risiken und den immensen Personal- und Sachaufwand. Ist meine Organisation – unabhängig von den Kosten – überhaupt in der Lage, ein Projekt mit 100 Mitarbeitern zu bewältigen? Haben wir genügend Jobs, Besprechungsräume, Netzwerkkapazität, Entwicklungsserver etc.?

Ist das Unternehmen in der Lage, die Anforderungen eines großen agilen Entwicklungsteams an einen Entwicklungs- und Testpfad einschließlich Continuous Integration/Delivery zu erfüllen? Bei solchen Fragen hätte der Business Case realistisch kalkuliert werden müssen. Ich habe mehrfach erlebt, dass erst kurz vor dem Start eines gigantischen Projekts klar wurde, dass das entstandene System eigentlich nicht gebraucht wird, weil es nicht in das Geschäftsmodell des Unternehmens passt. Leider war das vorher niemandem aufgefallen.

Ein weiteres erkennbares Muster: Ein Protagonist will unbedingt eine SW realisieren, zB aus Prestigegründen oder um Mitarbeiter einzusetzen, und kalkuliert die Kosten als vernachlässigbar ein. Ist der spätere Projektleiter nicht stark genug, die Diskrepanz im Rahmen von Entscheidungsgremien darzustellen, entsteht hohes Krisenpotential.

Faktor 3: Verlassen Sie sich zu 100 % auf Schätzungen und Planung

Ein weit verbreiteter Mythos ist die Verlässlichkeit von Schätzungen und Planungen. Das Konzept des Projekts zeichnet sich durch seine Einzigartigkeit aus. Vielleicht gab es schon ähnliche Projekte, aber im Prinzip betritt ein Unternehmen mit jedem Projekt Neuland. Das bedeutet, dass Schätzungen nur so gut sein können wie die Erfahrungen und Anpassungsfähigkeiten der Macher in Bezug auf das aktuelle Projekt.

Pläne können jedoch niemals spontane Ereignisse, Änderungen in Bezug auf Anforderungen, Technologien oder das Eintreten unerwarteter Risiken beinhalten. Letztlich sind Schätzungen und die darauf basierenden Planungen nichts anderes als eine Wette auf die Zukunft! Diese Tatsache zu akzeptieren, ist ein erster Schritt nach vorn. Disziplin, Mut und System helfen, mögliche Krisen zu verhindern oder zu lindern.

Faktor 4: Das magische PM-Dreieck wird konsequent missachtet

Studium der Informatik, erstes Semester, erste Vorlesung Projektmanagement: „Das magische PM-Dreieck“ . Der an Führungsaufgaben Interessierte wird schon früh an die Gesetzmäßigkeiten dieses Dreiecks herangeführt. Diese besagen, dass die Änderung eines der drei Parameter zwangsläufig zu den Folgen mindestens eines der anderen Parameter führt.

In der Praxis werden diese Gesetze jedoch nur allzu gerne ignoriert. Wie bereits im Zusammenhang mit Kalkulation und Planung erwähnt, ist ein Projekt etwas Einzigartiges und die Wahrscheinlichkeit ungeplanter Einflüsse außerordentlich hoch. Deshalb ist es bei fast jedem Projekt früher oder später erforderlich, dass die Verantwortlichen auf diese Einflüsse reagieren. Stehen jedoch alle Parameter fest, dh der Kunde fordert weiterhin die Einhaltung von Zeit, Budget und Inhalt, ist das Scheitern nur noch eine Frage der Zeit.

Faktor 5: Dokumentation von allem

Frei nach Franz Beckenbauer: „Wir nennen es einen Klassiker!“ Obwohl immer mehr Unternehmen auf agiles Vorgehen (meist Scrum) setzen, finden sich immer noch Organisationen und Projekte, die einer umfangreichen Dokumentation eine größere Bedeutung beimessen als der zu erstellenden Software. Gerade bei großen Projekten ist dies ein hohes Risiko. Oft ist eine Jagd von Beratern und Fachbereichsexperten auf tausende Seiten oft über Monate oder sogar Jahre hinweg gearbeitet worden, die später von einem anderen Team in SW übersetzt werden.

Je umfangreicher die Dokumentation, desto länger die Realisierungszeit und desto unwahrscheinlicher ist es, dass die SW den tatsächlichen Anforderungen der Anwender entspricht. Reaktionen auf Marktveränderungen sind nicht oder nur mit großem Aufwand und zeitlichen Zugeständnissen möglich. Ein Dokument bietet eine Grundlage, gegen die das Produkt entfernt werden kann. Leider ist das Geschriebene nicht unbedingt eindeutig und das Ergebnis anders gedacht als ursprünglich gedacht. Wie oft habe ich von Abteilungsmitarbeitern und Endanwendern den Satz gehört: „Oh, das habe ich mir ganz anders vorgestellt!“ .

Faktor 6: Eben keine ausgewogene Projektorganisation

Ein Team von 20 Entwicklern und 1 technischen Ansprechpartner? Um zu erkennen, dass dieses Konstrukt früher oder später scheitern wird, braucht es kein Expertenwissen. Zu Beginn eines Projekts, egal ob Wasserfall oder agil, funktioniert es vielleicht noch, weil die Entwickler mit Frameworks oder dem Aufsetzen der Umgebungen beschäftigt sind. Doch schon bald stellen die Mitarbeiter Fragen – brauchen intensive fachliche Unterstützung.

Ein einzelner Fachexperte kann diesem zeitlichen und emotionalen Druck niemals standhalten und benötigt Unterstützung, sowohl personell als auch durch den Umsetzungsprozess. Allerdings ist es eine ganz schlechte Idee, dem personellen Engpass mit der Einschränkung der Kommunikation zu begegnen.

Ebenfalls eine beliebte Idee und ganz vorne in der Größenordnung der typischen Managementfehler: Ein Mitarbeiter sammelt die Fragen der Entwickler, bespricht sie mit dem technischen Ansprechpartner und gibt die Antworten zurück. Damit schaffen Sie einen Engpass par excellence, lösen eine extrem hohe Fehlerquote aus und verzögern die Entwicklung erheblich.

Faktor 7: Erhitzen Sie den Frosch langsam

Kennst du diese Geschichte? Wenn Sie einen Frosch in einen Topf mit Wasser geben und ihn kontinuierlich zum Kochen erhitzen, versucht der Frosch nicht zu entkommen. Werfen Sie ihn direkt in heißes Wasser, springt er sofort heraus.

Eine meiner wichtigsten Erkenntnisse der letzten Jahre ist, dass Mitarbeiter von IT-Projekten mit zunehmender Dauer an zunehmender Erblindung erlöschen. Einmal etablierte Prozesse werden vielleicht im Nachhinein hinterfragt, aber selten wirklich drastisch. Die Fähigkeit der Menschen, auf Veränderungen zu reagieren, schwindet proportional zur Dauer eines Projekts.

Daher empfiehlt sich bei (großen) Projekten eine sporadische Beleuchtung (Health Checks) durch einen externen, bisher nicht beteiligten Gutachter, um die auslaufenden, möglicherweise nicht zielführenden Pfade aufzudecken. Spätestens nach dem Erkennen einer ausgewachsenen Krise ist es fast unmöglich, den Turnaround allein mit der vorhandenen Belegschaft zu schaffen.

Es kann also möglich sein

Die beschriebenen typischen Managementfehler sind nur eine kleine Auswahl meiner persönlichen Hitliste von Verhaltensmustern, die den erfolgreichen Abschluss von SW-Entwicklungsprojekten verhindern oder sogar verhindern. Aus der Ferne könnte der Eindruck entstehen, dass es einfach ist, die Probleme in den frühen Stadien der Projekte zu erkennen und zu beheben. Doch vermeintlich unverrückbare Rahmenbedingungen und die erwähnte Blindheit erschweren es oft, die richtigen Entscheidungen zu treffen. Die eingangs erwähnten Statistiken der Standish Group belegen dies Jahr für Jahr.

Wenn ein Projekt in Schieflage gerät, wird dringend empfohlen, dass ein externer Krisenmanager objektiv, frei von Befindlichkeiten und ohne den Ballast der Projekthistorie analysieren und handeln kann. Die einzige Teilnahme eines Experten, der den Menschen im Projekt zuhört, kann bereits positive Effekte bewirken. Auch durch die Auswahl geeigneter Maßnahmen gelingt die Transformation und schließlich der Turnaround.