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.
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 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 agileagile 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. Alles zu Agile auf CIO.de
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.