Mitarbeiter nicht würdigen, Komplexität unterschätzen oder auf Mythen setzen. Bei Berücksichtigung dieser und weiterer Faktoren wird Ihr Projekt garantiert scheitern. [...]
Kennen Sie das? Wochen und Monate berichtet der Projektleiter im Leitungskreis zu seinem Projekt. Selbstverständlich darf dabei die klassische Statusampel nicht fehlen. Und diese steht beständig auf Grün: alles ok. Doch eines Tages wechselt die Ampel unvermittelt auf Rot! Konsequenterweise beginnt nun für die Verantwortlichen ein sehr unerfreulicher Aufarbeitungsprozess. Meist gilt die erste Frage dem Schuldigen, die zweite den Ursachen und dann erst widmet man sich den Lösungsmöglichkeiten.
Zieht man die Statistiken der Standish Group aus dem Jahre 2015 zu Rate, trägt sich genau dieses Szenario täglich in den Konferenzräumen der IT-Betriebe auf der ganzen Welt zu. Denn gerade einmal 29% aller SW-Entwicklungsprojekte sind erfolgreich, der Rest scheitert völlig (19%) oder ist nur mit Einschränkungen (52%) live gegangen. Mehr als 2/3 aller Projekte erreichen also nicht ihr geplantes Ziel: Mannigfaltige Optimierungsmöglichkeiten!
Nachfolgend 7 typische Faktoren, die den Misserfolg fast schon garantieren.
Faktor 1: Missachten Sie den Faktor Mensch
In vielen Jahren als Entwickler, Projektleiter, Coach und Krisenmanager habe ich festgestellt, dass zwischenmenschliche Spannungen das größte Hindernis in der Umsetzung von IT-Projekten darstellen. Stimmt umgekehrt die Chemie zwischen den Mitarbeitern und es herrscht ein offenes, fehlertolerantes Klima, lassen sich für alle Schwierigkeiten Lösungen finden – auch in kritischen Situationen.
Es liegt in der Natur des Menschen, Konflikten aus dem Weg zu gehen. Und somit ist es nur natürlich, wenn implizit oder explizit mit Personalführung beauftragte Personen (z.B. der Projektleiter) schlechte Stimmungen komplett ignorieren oder zu lange wegsehen. Doch Konflikte lösen sich meist nicht von alleine. Es bedarf der Ursachenforschung, der Moderation und mindestens die Perspektive auf Veränderung oder Lösung.
Manchmal sind es die kleinen Dinge, die eine große Wirkung erzielen, wie z.B. ein neuer Arbeitsplatz für einen Mitarbeiter. Oft sind jedoch größere Aufwände notwendig, wie z.B. die Neuorganisation von Teams, um wieder Ruhe in das Projekt zu bringen. Die schlechteste Alternative ist jedoch die Missachtung des Faktors Mensch. Platz 1.
Faktor 2: Zu groß denken oder zu klein machen
Manche Firmen übernehmen sich mit einem Projekt. Sie unterschätzen die Komplexität, die Risiken und den immensen personellen wie materiellen Aufwand. Ist – unabhängig von den Kosten – meine Organisation überhaupt in der Lage, ein Projekt mit 100 Mitarbeitern zu stemmen? Haben wir genügend Arbeitsplätze, Besprechungsräume, Netzkapazität, Entwicklungsserver etc.?
Ist der Betrieb imstande, die Anforderungen eines großen agilen Entwicklungsteams an eine Entwicklungs- und Teststrecke inkl. Continuous Integration/Delivery zu erfüllen? Solchen Fragen vorangestellt, sollte der Business Case realistisch gerechnet worden sein. Ich habe es mehrfach erlebt, dass erst kurz vor dem Start eines gigantischen Projektes klar wurde, dass man das resultierende System eigentlich gar nicht benötigte, weil es nicht in das Geschäftsmodell des Unternehmens passte. Leider war das zuvor niemandem aufgefallen.
Ein weiteres, erkennbares Muster: Ein Protagonist möchte die Realisierung einer SW unbedingt, z.B. aus Prestigegründen oder um Mitarbeiter auszulasten, und rechnet die Kosten klein. Ist der spätere Projektleiter nicht stark genug, die Diskrepanz im Rahmen von Entscheidungsgremien darzustellen, entstehen hieraus hohe Krisenpotenziale. Platz 2.
Faktor 3: Sich auf Schätzungen und Planungen 100% verlassen
Ein weit verbreiteter Mythos ist die Verlässlichkeit von Schätzungen und Planungen. Der Begriff des Projektes ist definiert durch seine Einmaligkeit. Vielleicht gab es bereits ähnlich gelagerte Vorhaben, doch grundsätzlich betritt ein Unternehmen mit jedem Projekt Neuland. Das bedeutet, dass Schätzungen immer nur so gut sein können, wie die Erfahrungen der Ersteller und deren Adaptionsfähigkeiten bzgl. des aktuellen Projekts.
Pläne können allerdings niemals spontane Ereignisse, Veränderungen hinsichtlich der Anforderungen, der Technologien oder den Eintritt nicht erwarteter Risiken mit einschließen. Letztlich sind Schätzungen und die darauf aufbauenden Pläne nichts weiter als eine Wette auf die Zukunft! Diese Tatsache zu akzeptieren, ist ein erster Schritt nach vorn. Disziplin, Mut und Systematik helfen, mögliche Krisen zu verhindern oder zu lindern. Platz 3.
Faktor 4: Das magische PM-Dreieck konsequent missachten
Studium der Informatik, erstes Semester, erste Vorlesung Projektmanagement: „Das magische PM-Dreieck“. Schon sehr früh wird der an Managementaufgaben Interessierte an die Gesetze dieses Dreiecks herangeführt. Diese besagen, dass die Veränderung eines der drei Parameter Zeit, Budget oder Inhalt (Qualität) unweigerlich zu Konsequenzen bei mindestens einem der weiteren Parameter führen.
Doch werden diese Gesetze in der Praxis nur zu gerne ignoriert. Wie schon im Kontext von Schätzung und Planung erwähnt, ist ein Projekt etwas Einmaliges und die Wahrscheinlichkeit von nicht geplanten Einflüssen extrem hoch. Deshalb ist es früher oder später in quasi jedem Projekt erforderlich, dass die Verantwortlichen auf diese Einflüsse reagieren. Sind dann jedoch alle Parameter fixiert, d.h. der Kunde fordert weiterhin die Einhaltung von Zeit, Budget und Inhalt, ist das Scheitern nur noch eine Frage der Zeit. Platz 4.
Faktor 5: Dokumentation über alles
Frei nach Franz Beckenbauer: „We call it a Klassiker!“ Obwohl immer mehr Unternehmen auf agile Vorgehensweisen (meist Scrum) setzen, findet man weiterhin Organisationen und Projekte, welche einer umfangreichen Dokumentation den größeren Stellenwert einräumen, als der zu erstellenden Software. Gerade in großen Projekten ist dies ein hohes Risiko. Oftmals arbeitet über Monate oder gar Jahre eine Heerschar von Beratern und Fachbereichsexperten an tausenden Seiten Beschreibungen, welche später von einem anderen Team in SW übersetzt werden.
Je umfangreicher die Dokumentation, desto länger die Realisierungszeit und umso unwahrscheinlicher ist es, dass die SW den tatsächlichen Erfordernissen der Anwender entspricht. Reaktionen auf Veränderungen des Marktes sind nicht oder nur mit großem Aufwand und zeitlichen Zugeständnissen möglich. Zwar bietet ein Dokument eine Basis, gegen die das Produkt abgenommen werden kann. Doch leider ist das Geschriebene nicht unbedingt eindeutig und das Ergebnis anders als ursprünglich gedacht. Wie oft habe ich von Fachbereichsmitarbeitern und Endanwendern den Satz gehört: „Oh, das habe ich mir aber ganz anders vorgestellt!“. Platz 5.
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 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.
*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.
Be the first to comment