Software-Entwicklung: 7 Faktoren für garantiertes 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.Nachfolgend 7 typische Faktoren, die den Misserfolg fast schon garantieren.Faktor 1: Missachten Sie den Faktor MenschIn 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 machenManche 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% verlassenEin 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 missachtenStudium 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 allesFrei 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 ProjektorganisationEin 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 erhitzenKennen 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 gelingenDie 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.15 Probleme beim Projektmanagement1. Unklare ArbeitslastBryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen.2. Undefinierte ErwartungenAlle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia.3. Fehlende Management-UnterstützungDie Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv.4. Methodik nach Schema FIm Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt.5. Überlastete Mitarbeiter„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet.6. Ungeteiltes HerrschaftswissenProjekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann.7. Unklare EntscheidungsfindungIm Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht.8. Fehlende SoftwareExel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software.9. Gefahr des AusufernsChange Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist.10. Nicht “Nein” sagen könnenIm Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man “nein” sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat.11. Mangelnder ZusammenhaltProjektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3.12. Vergessener ArbeitsalltagHilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen.13. Zu häufige MeetingsMeetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren.14. Gut genug ist nicht immer gutSergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes.15. Nicht aus Fehlern lernenLiz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden.15 Fehler beim ProjektmanagementEs gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.