Software-Entwicklung

7 Faktoren für garantiertes Scheitern



Matthias Rauber hat sich mit seinem Unternehmen resc-IT GmbH auf die Rettung von IT-Projekten spezialisiert. Er verfügt über mehr als 20 Jahre Erfahrung als Projektmanager in traditionellen (Wasserfall) und agilen Projekten.

Faktor 6: Bloß keine ausgewogene Projektorganisation

Ein Team von 20 Entwicklern und 1 fachlicher Ansprechpartner? Es bedarf keines Expertenwissens, um zu erkennen, dass dieses Konstrukt früher oder später scheitern wird. Zu Beginn eines Projektes, egal ob Wasserfall oder agil, mag es noch funktionieren, weil die Entwickler mit Frameworks oder der Einrichtung der Umgebungen beschäftigt sind. Doch sehr bald werden die Mitarbeiter Fragen stellen, intensive fachliche Betreuung benötigen.

Ein einzelner Fachexperte kann diesem zeitlichen und emotionalen Druck niemals standhalten und benötigt Unterstützung, sowohl personell als auch durch den Realisierungsprozess. Allerdings ist es eine sehr schlechte Idee, dem Personalengpass mit der Beschränkung der Kommunikation zu begegnen. Ebenfalls eine beliebte Idee und ganz weit vorne auf der Skala der typischen Managementfehler: Ein Mitarbeiter sammelt die Fragen der Entwickler, erörtert diese mit dem fachlichen Ansprechpartner und trägt die Antworten wieder zurück. Auf diese Weise erzeugt man einen Flaschenhals par excellence, löst eine extrem hohe Fehlerquote aus und verzögert die Entwicklung maßgeblich. Mein Platz 6 für sicheres Scheitern.

Faktor 7: Den Frosch unbedingt langsam erhitzen

Kennen Sie diese Geschichte? Setzt man einen Frosch in einen Topf mit Wasser und erhitzt dieses kontinuierlich bis zum Kochen, unternimmt der Frosch keinerlei Fluchtversuche. Wirft man ihn direkt in heißes Wasser, springt er sofort heraus.

Eine der für mich wichtigsten Erkenntnisse der letzten Jahre ist, dass Mitarbeiter von IT-Projekten mit fortschreitender Dauer einer zunehmenden Betriebsblindheit verfallen. Einmal etablierte Prozesse werden vielleicht in Retrospektiven hinterfragt, aber selten wirklich einschneidend angepasst. Die Fähigkeit der Menschen auf Veränderungen zu reagieren, schwindet umgekehrt proportional zur Dauer eines Projektes.

Daher ist die sporadische Beleuchtung (Health Checks) von (insbesondere großen) Projekten durch einen externen, bisher nicht involvierten Berater zu empfehlen, um ausgetretene, potenziell nicht zielführende Pfade zu entdecken. Spätestens nach Erkennen einer ausgewachsenen Krise, ist es nahezu unmöglich, alleine mit dem bestehenden Personal den Turnaround zu schaffen. Platz 7.

So kann es sicher gelingen

Die beschriebenen typischen Managementfehler stellen lediglich eine kleine Auswahl meiner persönlichen Hitliste von Verhaltensmustern dar, welche den erfolgreichen Abschluss von SW-Entwicklungsprojekten be- oder gar verhindern. Aus der Distanz betrachtet, könnte der Eindruck entstehen, es sei ein Leichtes, die Probleme zu erkennen und bereits in frühen Stadien der Projekte zu korrigieren. Doch vermeintlich unverrückbare Rahmenbedingungen und die angesprochene Betriebsblindheit erschweren es oftmals, die richtigen Entscheidungen zu treffen. Die eingangs erwähnten Statistiken der Standish Group beweisen dies Jahr für Jahr.

Ist ein Projekt tatsächlich in Schieflage geraten, empfiehlt sich dringend das Hinzuziehen eines externen Krisenmanagers, der objektiv, frei von Befindlichkeiten und ohne den Ballast einer Projekthistorie analysieren und agieren kann. Allein die Beteiligung eines Sachverständigen, der den Menschen im Projekt zuhört, kann bereits positive Effekte hervorrufen. Durch die Auswahl geeigneter Maßnahmen gelingen auch die Transformation und schließlich der Turnaround.

Zur Startseite