Brainfucks in Digitalprojekten sind auf den ersten Blick oft unlogisch wirkende Zusammenhänge, die nur selten verstanden werden wollen.
Mir geht es hier nicht primär um Wissensvermittlung, sondern um Konzepte, die wir als Führungskräfte, Manager und Projektverantwortliche nur schwer verstehen können oder die gar aktuell noch im verborgenen liegen. Mir geht es also um Nichtwissen. Ich möchte von den Unbekannten in Projekten sprechen. Unbekanntes Unwissen, das oft Schuld daran ist, dass viele Projekte scheitern oder den Rahmen vollkommen sprengen.
Am besten steigen wir etwas fundierter und weniger philosophisch ein. Der ein oder andere hat wahrscheinlich bereits etwas vom renommierten Chaos Report gehört. Dieser Report beschäftigt sich seit über 15 Jahren mit der Analyse von IT-Projekten.
Wie du siehst, sind die aktuellen Zahlen und Erfolgsquoten in IT-Projekten ziemlich erschreckend. 32% scheitern komplett, 56% sprengen das Budget (Kosten, Zeit, Funktionen) und NUR 12% sind erfolgreich.
Doch warum ist das so?
We live in a VUCA-World! Diesen Satz hast du bestimmt schon einmal gehört. Doch was bedeutet das? Die VUCA-World beschreibt die Herausforderungen, mit denen wir täglich zu kämpfen haben. Innerhalb einer kurzen Zeitspanne können sich Anforderungen ganzer Märkte verändern und die Komplexität eines Vorhaben multiplizieren. Der Nutzer soll jedoch auch dann immer noch im Mittelpunkt stehen und seine Anliegen von uns richtig interpretiert werden.
Digitalprojekte in einem chaotisch-komplexen Umfeld stellen uns also meist täglich vor die Schwierigkeit, dass wir im Vorfeld nicht wissen, was tatsächlich auf uns zukommt.
Da ist es wieder, unser Nichtwissen. Wenn wir zeitlich etwas zurückdenken, stolpern wir über den Experten dieses hochkomplexen Fachbereichs. Donald Rumsfeld war von 2001-2006 der Verteidigungsminister der USA und hat kontinuierlich Aussagen getroffen, die an Unkonkretheit bis heute unübertroffen sind.
„We do know of certain knowledge that Osama Bin Laden is either in Afghanistan, or in some other country, or dead. There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don't know we don't know.”
Alles ist offen, nicht ist bestätigt. Ich könnte jetzt über seine Aussagen schmunzeln. Denkt man aber auch nur kurz über diese Bemerkungen nach, so findet man schnell Parallelen zu diesen “unknown unknowns” in eigenen Projekten. Ich versuche seit Jahren, diesem unbekannten Unwissen auf den Grund zu gehen, denn ich denke, keiner möchte in so einem Umfeld ein hoch anspruchsvolles Projekt verantworten. Es gibt einige Konzepte und Werkzeuge, die helfen können, sich dieser Herausforderung zu stellen.
Wie können wir also mit den VUCA-Rahmenbedingungen erfolgreich agieren?
In der Regel versuchen wir Antworten auf so komplexe Fragen zu finden wie: “Wie lange würde eine Neuentwicklung unserer E-Commerce Plattform dauern?”
Wir erstellen Abschätzungen, Machbarkeitsstudien, schreiben Lastenhefte und erstellen eine saubere Zeitplanung. Irgendwann glauben wir, alle Funktionen zu kennen, wissen, wie das Design sein soll und wie der Zeitrahmen definiert ist. Nun ist also alles Nötige erarbeitet und es wird sich an den Dienstleister des Vertrauens gewendet: “Wie lange dauert es denn jetzt und was wird es kosten?” Wahrscheinlich wird er dir dennoch antworten: “Das können wir nicht sagen!”
Trotz feststehendem Zeitrahmen und festgelegtem Projektumfang gibt es also keine belastbare Einschätzung? In der Regel wissen die Dienstleister nicht einmal, warum sie keine genau Abschätzung abgeben können. Das Einzige, das man durch unzählige Studien beweisen kann, ist, wie hervorragend wir darin sind, falsche Schätzungen abzugeben.
Ein gutes Beispiel für unser Fähigkeit, miserabel zu schätzen, ist die Erfolgsquote bei IT-Modernisierungsprojekten.
Solche Software Rewrites sind in nur 4% der Fälle erfolgreich. Zu 47% sind sie gefährdet (out of scope/time/budget) und zu fast 50% scheitern sie. Sie scheitern oft, weil zu Projektstart der Rewrite des großen Ganzen angestrebt wird.
Wenn ich unsere Erfahrung mit Digitalprojekten mit denen von anderen IT Unternehmen zusammenführe und mich frage, warum wir diese nicht abschätzen können, stoße ich immer wieder auf ähnliche Punkte, die ein Projekt gefährden.
“Die Artikeldaten kommen doch nicht über die Schnittstelle rein, sondern müssen händisch importiert werden.”
“Der Kunde/Designer/Entwickler dachte, dass die interne Suche Auto-Suggestion und Fehlertoleranz mitbringt.“
“Die realen Kundendaten sind im Live-System vollkommen anders als die Testdaten während der Projektumsetzung.”
“Das ERP-System hat wohl einen Bug in der Schnittstelle.”
Was haben diese Punkte alle gemeinsam? Herr Rumsfeld würde etwas sagen wie: “There are unknown unknowns and the ones we don’t know we don’t know.” Das ist es also wieder, unser Unwissen. Zu Beginn der Projekte wissen wir meist nicht nur nicht, dass wir die Antwort auf die Fragen nicht kennen, wir wissen normalerweise nicht einmal, dass die Frage existiert, geschweige denn, dass wir eine Antwort brauchen.
Wir sollten anfangs also nicht zu viel Zeit mit Schätzen verbringen und die Energie, die wir sonst in detaillierte Planung stecken, lieber nutzen, um schnell ins Doing zu kommen. Denn Geschwindigkeit ist eine bewährte Waffe im Kampf gegen das Unwissen.
Rapid results build team morale which leads to more success.
Rapid results generate more interest.
Wie können wir in Projekten Geschwindigkeit aufnehmen?
Zunächst einmal ist es sinnvoll, seinen ganzen Workflow und die Infrastruktur zu überprüfen und zu optimieren. Wo sind meine Zeitfresser und welche Steps sind überflüssig?
Was agile Workflows schon lange verstanden haben, ist noch längst nicht überall angekommen. Wir müssen dynamisch und nutzerorientiert agieren. Eine zentrale Stellschraube sind unsere Teams, wie sie arbeiten und wie sie an Probleme herangehen. Ein gutes Stichwort für Beschleunigung durch optimale Zusammenarbeit ist das sogenannte Pair Programming. Ich setze also zwei Personen an die gleiche, meist komplexe Aufgabe. Aber wie verändert sich die Geschwindigkeit der Entwicklung, wenn nur einer programmiert und der andere zuschaut? Exorbitant möchte ich fast sagen.
Was sich hier zeigt, ist ein Benefit, der sich durch eine intensive Zusammenarbeit im Team ergibt. Cross-Functional-Teams sind ein weiterer Projektkatalysator, den man unbedingt nutzen sollte. Die meisten Aufgaben und Probleme in unserer heutigen Arbeitswelt sind komplexe Probleme für Wissensarbeiter. Diese lassen sich am besten in Rahmen einer entsprechenden interdisziplinären Zusammenarbeit von generalisierenden Spezialisten lösen. Aber genau das sind CFTs nicht. CFTs lassen sich am besten mit einem Überfall-Kommando vergleichen. Alle arbeiten zusammen auf das eine Ziel hin (Bank ausrauben, Museum leerräumen, Projekt live bringen). Jeder hat seine ganz spezielle Begabung. Der Safeknacker kann Auto fahren, aber nicht so gut wie der Fluchtwagenfahrer. Sollte der Fluchtwagenfahrer ausfallen, wird das Team aber nicht den Mastermind-Planer anrufen und sagen: „Tom, unser Fluchtwagenfahrer ist krank, deshalb bleiben wir im Museum, bis er wieder gesund ist.“ Jedes Teammitglied hat eine Spezialisierung und alle arbeiten gemeinsam an einem Ziel. Das Team vereint so alle Kompetenzen, die es braucht, um das Ziel zu erreichen, und alle lernen voneinander.
Mit solchen Teams können wir viel besser auf Änderungen reagieren. Änderungen, die unsere Projekte immer komplexer werden lassen. Was denkst du? Um wie viel % verändern sich die Anforderungen in Digitalprojekten jeden Monat? Die Antwort ist: Um 10%. Auf den ersten Blick sind 10% Veränderung ja gar nicht so schlimm. Doch große Projekte haben eine deutlich höhere Laufzeit als nur einen Monat. Sie dauern oft 10-20 Monate. In 10 Monaten verändern sich die Anforderungen in unserem Projekt also um rund 100%. Welche Anforderung sich ändert und welche hinzukommen, wissen wir bei Projektstart nicht. Wie können wir solche Projekte dann angehen? Wir müssen genauso flexibel und gerüstet für change requests sein. An dieser Stelle ist Agilität besonders wichtig. Wir planen nicht das große Ganze, sondern kleine Schritte, die wir genau definieren, schätzen und planen können. Im besten Fall bringen wir so ein MVP (Minimum Viable Product) in Rekordzeit auf den Markt und entwickeln es in enger Abstimmung mit dem Kunden weiter. So merken wir schnell, ob wir auf dem richtigen Weg sind und ob die Nutzer unser Produkt verstehen und annehmen. Ein weiterer Vorteil ist, dass einzelne Sprints sehr gut abschätzbar sind, und da ein Sprint rund 1-4 Wochen dauert, belaufen sich die Anforderungsänderungen auf max. 10%. Mit einem eingespieltem Cross-Functional-Team also eine machbare Aufgabe. Wird eine komplexe Aufgabenstellung in kleine, umsetzbare Pakete zerlegt, wird diese somit plötzlich lösbar.
Viele dieser agilen Konzepte funktionieren nur mit angepasster Unternehmenskultur. Es ist klar, dass wir nicht alle ab morgen nur noch Holacracy, Lean und Scrum machen. Oft reichen für den Anfang auch kleine Schritte. Ein gutes Werkzeug ist die Verbesserung der Feedback- und Lob-Kultur.
In unserer Agentur liegen z.B. kleine Danke-Postkarten, die die Mitarbeiter nutzen können, um sich bei Kollegen für kleine und große Dinge einmal dediziert zu bedanken.
All die genannten Faktoren wappnen uns für das unbekannte Unwissen, das wir in Zukunft nicht mehr fürchten müssen. Das beweist auch der Vergleich der Erfolgsraten von klassischen und agilen Methoden in IT-Projekten.
Ich kann aus eigener Erfahrung nur sagen: Es lohnt, Prozesse zu überdenken, Strukturen zu ändern um einen neuen Blickwinkel zu finden. Brainfuck in komplexen Digitalprojekten.
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen
