Wenn man sich diesen Podcast so anhört, dann entsteht gleich der Eindruck, dass es eigentlich unglaublich viel coole Tech zu integrieren gäbe und unglaublich viel Potenzial für auch gerade mittelständische Unternehmen mit eigenen Projekten im Bereich Software wirklich sich Innovationsvorsprünge zu verschaffen. Und auf der anderen Seite weiß man aber auch aus der Erfahrung, dass das sehr, sehr oft nicht gemacht wird. Da stellt sich natürlich die Frage, warum ist das so? Und ich glaube, diese Gründe sind eigentlich seit Jahrzehnten die gleichen. Ein Softwareprojekt anzugehen, ist einfach mit wahnsinnig viel Angst verbunden, weil wahrscheinlich jeder, der ausreichend alt ist, sag ich es mal so, schon ein Projekt hat Scheitern oder zumindest wahnsinnig stolpern sehen. Man sagt ja immer so 75% der Softwareprojekte scheitern, was letzten Endes bedeutet, 75% überziehen entweder das Budget oder bringen nicht das Ergebnis, was man ursprünglich haben wollte. Und das ist natürlich eine phänomenal hohe Zahl. Das ist drei Viertel der Projekte, die ursprünglich gestartet wurden, liefern nicht, was sie hätten liefern sollen. Und egal, ob man jetzt mit kleinen Unternehmen arbeitet oder mit Bittlständlern oder mit großen Konzernen, überall gibt es so den Mythos des planbaren Großprojekts. Als gäbe es tatsächlich ein Weg, absolut verlässlich und risikofrei, so ein Projekt durchzuplanen und dann auch genau auf diesem Plan entlang auszuführen. Und in dem Moment, wo das dann nicht so ist, wo die Realität uns einholt und der Projektplan nicht mehr ganz den Gegebenheiten entspricht, errscht dann die Angst und viele von den Projekten werden dann auch in diesem Zeitpunkt schon abgebrochen. Je größer das Projekt, desto wahrscheinlicher wird es nicht das liefern, was man ursprünglich gedacht hat oder nicht in dem Budget oder in dem zeitlichen Rahmen, den man sich ursprünglich gedacht hat. Das ist eigentlich logisch, je länger der Projektzeitraum, desto weiter sind natürlich auch die Abweichungen. Aber die Frage ist, warum scheitern denn diese Projekte eigentlich? Gibt es da irgendwelche magischen Hebel, die man eigentlich bewegen könnte, um vielleicht zu verhindern, dass sie scheitern? Magische Hebel gibt es sicher nicht, aber was man definitiv sagen kann, ist, es liegt selten an der Technik oder es liegt selten nur an der Technik. Manche Projekte sind wirklich technisch komplex. Dann gibt es wirklich komplizierte Integrationen oder auch komplizierte Algorithmen, die vielleicht noch gar nicht final bekannt sind, die man integrieren will. Gerade wenn man etwas wirklich Innovatives schaffen will, muss man natürlich sich ein bisschen an die Kante des Abgrunds, an die Bleeding Edge trauen. Aber aus meiner Sicht, und ich habe wirklich schon in sehr, sehr vielen Projekten mitgewirkt, sind die Stolpesteine eigentlich primär nicht täglich. Primär sind die Stolpesteine in der Organisationsstruktur oder in der Art, wie zusammengearbeitet bzw. kommuniziert wird angelegt. Das meine ich jetzt nicht im Punkt der Soft Skills, da gibt es auch viel dazu zu sagen. Also viele Organisationen kommunizieren einfach sehr ineffektiv oder sogar zum Schaden des Projekts manchmal. Aber das ist nicht, was ich meine. Was ich meine ist wirklich die Strukturen in einer Organisation und wie bestimmte Leute an bestimmten Punkten zusammenarbeiten, das ist eigentlich fast immer das, was ein Projekt scheitern lässt oder stolpern lässt. Es muss ja nicht unbedingt schief gehen, aber es geht über das Budget, geht über den Zeitrahmen oder der Scope wird reduziert. Ich wollte heute mal auf drei Beispiele eingehen, drei große Fehler, die Großprojekte killen können oder die Projekte zum Scheitern bringen können. Einfach weil wir die so oft sehen, dass wir überzeugt sein können, das ist ein wesentlicher Aspekt. Wir haben über die Jahrzehnte jetzt schon unzählige Projekte gemacht. Ich habe tatsächlich keine genaue Zahl im Kopf, aber von drei, vier Monate bis drei, vier Jahre Budget von 10.000 bis 10 Millionen war alles dabei. Aber interessanterweise sind diese Probleme, die ich ansprechen möchte, sind eigentlich unabhängig von der Projektgröße gerne zu mal zu beobachten. Das Erste ist, was ich gnadenbasierte Zuarbeit nenne. Das ist vielleicht nicht das Wichtigste, aber es ist ein sehr, sehr weit verbreitetes Problem. Vielleicht kennt ihr die Situation, das Kernprojektteam ist definiert. Es sind Leute zusammengekommen, die kennen sich wirklich gut mit der Sachlage aus, die haben technisch die Skills, das umzusetzen. Es sind Projektmanager vielleicht sogar dabei oder ein Scrum Master, wenn es ein agiles Projekt ist, der sich um die Hindernisse kümmert und sicherstellt, dass die Informationen an die richtigen Leute kommt. Es gibt eine Zielvorstellung, es gibt ein Budget, alles ist wunderbar, es ist definiert, was gemacht werden soll, aber die Organisation ist so aufgebaut, dass dieses Projektteam jetzt ganz viele Zulieferungen aus anderen Teilen der Organisation braucht. Nehmen wir mal an, es ist ein Team, das bestimmt eine App umsetzen soll. Endlich soll die Firma mobil digital vertreten sein, aber dazu brauchen sie natürlich Zulieferungen aus dem IT-Bereich, weil da müssen sie sich mit Backend-APIs integrieren. Brauchen sie Zulieferungen aus der Rechtsabteilung, weil natürlich geklärt werden muss, was muss man da für Einwilligungen unterschreiben oder wie muss das aufgesetzt sein mit dem Tracking und so weiter. braucht Zulieferungen vielleicht auch aus der Datenhaltung, weil man auch Daten schreiben will, also Dinge über den Nutzer lernen will. Das heißt, dieses Team hat einerseits einen eigenen Projektplan und der kann agil sein, der kann ganz klassisch sein mit Gantt-Chart und so weiter, aber es hat auch immer wieder Punkte, an denen Zulieferungen aus anderen Teams kommen müssen. Und total oft ist es so, dass diese anderen Teams vielleicht von der Geschäftsführung oder von irgendeinem Sponsor eingeschworen wurden, dass sie quasi unser Projekt supporten sollen. Also die anderen Bereiche wissen, es gibt unser App-Projekt und die anderen Bereiche wissen, sie müssen dazu arbeiten. Aber wann sie das machen, in welche Qualität und in welche Geschwindigkeit, darüber hat eigentlich niemand gesprochen und da ist auch niemand entscheidungsbefugt. Weil ich mit meinem App-Team bin eigentlich auf Augenhöhe mit dem Typen vom API-Team, mit dem ich integrieren muss. Und der weiß zwar, hey, du musst diesem Team zuliefern und du musst dieser App-Projekt zuliefern, aber es hat ihm halt keiner gesagt, es muss aber zum 14.8. zur Verfügung stehen oder es muss innerhalb von zwei Wochen zur Verfügung stehen, wenn die dir Bescheid sagen. Das heißt, der ist jetzt eigentlich gnadenbasiert unterwegs. Der sagt sich, okay, wenn ich die Zeit habe, dann plane ich das ein. Dann kann man auch eskalieren und sagen, hey, plan es früher ein. Und dann macht das halt widerwillig, aber es gibt keinen Zusammenhang zwischen meinem Team, meinem App-Team und diesem Team, der uns erlauben würde, zu formalisieren, wann die zuliefern. Diese ganzen Inhouse-Teams, die ganzen Silos, die gerade in einer großen Organisation existieren, die haben alle eigene Roadmaps, die haben alle eigene Projekte, haben Migrationsprojekte, eigene Implementierungsprojekte, andere Lighthouse-Projekte, vielleicht die an ihnen zerren, dann kommt noch von der Geschäftsführung irgendwas, was ganz dringend ist, aber eigentlich völlig unwichtig. Alle diese Interessen laufen dann zusammen bei meinem zuliefernden Team und dann stelle ich mich da hinten an. Und jetzt kann ich natürlich eskalieren, also kann über die Geschäftsführung gehen oder über den Projektsponsor oder was, oft genug ist das ja leider quasi das Gleiche, also die niedrigste gemeinsame Management-Schicht zwischen diesen Teams in den Silos ist oft erst die Geschäftsführung. Es ist schockierend, wie viele Organisationen wirklich so strukturiert sind. Und dann kann der der Druck machen und dann kommt es aber trotzdem zur Verzögerung, es kommt zu Fingerpointing, Schuldzuweisung, weil auf diese Art will eigentlich keiner arbeiten. Das ist so oft der Fall, dass es fast schon der Standard ist. Wenn man in so ein Projekt guckt, das Einzige, was man machen kann, um das zu verhindern, ist natürlich, dass man ein Kernprojektteam hat, in dem wirklich alle Funktionen drin sind, die jemand braucht. Also wenn ich aus dem anderen Silo nichts brauche, sondern wenn ich mir einfach aus dem anderen Orga-Teil jemand in mein Projektteam hole, der für mich dann das macht, dann habe ich diese Effekte natürlich nicht. Aber das geht in den wenigsten Organisationsstrukturen so. Das ist dieser agile Traum vom cross-funktionalen Team, mit dem ein agiles Projekt meiner Meinung nach steht und fällt. Wenn man das nicht hat, sollte man es lassen. Also ein cross-funktionales Team muss eigentlich da sein, wenn man agil arbeiten will. Und manchmal kriegt man das hin, aber in den meisten Organisationen eben nicht. Damit ist das Projekt dann automatisch nicht agil und man muss, oder zumindest nicht vollständig agil und man muss andere Lösungen für dieses Problem suchen. Zum Beispiel, indem man sagt, okay, mein Hauptrisiko sind Zulieferungen. Das heißt, ich muss unabhängig davon, wie ich sonst meine Requirements-Analyse mache, muss ich Zulieferungen aus anderen Organisationsteilen total früh identifizieren und auch total früh anfragen und mit Deadline mir entsprechenden Commitment der zuliefernden Teams holen, damit klar ist, wann muss das dastehen. Und dann muss ich trotzdem noch einen Puffer draufschlagen, weil das natürlich trotzdem zu Verzögerungen führt. Und das muss auch verschriftlicht werden natürlich. Nicht, dass man jetzt einen Vertrag machen muss mit anderen Organisationsbestandteilen, wobei ich auch das schon gesehen habe, aber irgendwo muss stehen, auch für die Geschäftsführung einsehbar, das API-Team liefert meinem Mobile-App-Projekt spätestens am 14.8. folgende Lieferungen zu. und da muss ich halt auch diese total nicht agile Spezifikation schreiben, in der ich genau definiere, was ich haben will. Wie gesagt, in agilen Teams, in agilen Projekten würde man versuchen, das über cross-funktionale Teams zu lösen. Das heißt, ich hole mir vom Geschäftsführer oder vom Sponsor irgendwie die Zusage, dass ich aus dem zuliefernden Team jemand in mein Team integrieren kann für die Projektdauer, der mir dann diese Zulieferungen sicherstellt, wenn das eine einzelne Person kann. Manchmal brauchen wir wirklich eine große Ziellieferung, dann braucht man das ganze Team am Start. Hybride-Modelle, wo ich sage, ich bin so ein bisschen agil und die Zulieferungen sind so ein bisschen Wasserfall, aber ich lege nicht vorher fest, wann die kommen und ich weiß auch nicht ganz genau, was ich brauche, die sind eigentlich schon tot. So ein hybrides Modell ohne klare Verantwortlichkeit ist eigentlich ein Showstopper. Da geht die Planbarkeit sofort gegen null. Das wird noch verschärft durch Matrix-Organisationen und ähnliche Strukturen, die ja momentan sehr in sind und auch viele Vorteile haben. Aber da gibt es halt auch wenig Eskalationspfade. Fachliche und disziplinarische Führungen verlaufen dann quasi so ein bisschen orthogonal zueinander. Durch diese Matrix-Organisationsstruktur ist es dann oft noch schwieriger, echte Commitments zu kriegen und nicht auf Gnadenakte der anderen Teams angewiesen zu sein. Also gnadenbasierte Zuarbeit, wie gesagt, super häufig. Aus meiner Sicht ein absolutes Risiko für jedes Projekt. Ein bisschen was davon ist immer dabei. Irgendwas vergisst man immer und dann muss man doch bei irgendeiner Abteilung betteln gehen und sagen, hey, könnt ihr mir das nicht noch liefern? Aber je mehr man das minimiert, desto planbarer wird das Projekt. Ich habe jetzt gerade schon über Agilität geredet. In Neomo machen wir eigentlich fast alle Projekte agil. Das heißt, wir folgen eigentlich dem Prinzip, dass erst fertige Code wirklich die sinnvollste Produktspezifikation ist und versuchen eben das Produkt in Inkrementen abzuliefern, die dem Kunden erlauben, früh zu bewerten, ob das das ist, was er wirklich wollte. Aber in vielen Großprojekten, gerade Großprojekten, wird dieses agile Emblem so ein bisschen draufgeklebt als Entschuldigung dafür, dass man eigentlich keinen klaren Prozess hat oder noch nicht mal klare Strukturen. Das ist so dieses Stichwort agiles Chaos. Und das ist eigentlich ein Widerspruch. Ein agiler Prozess, ein agil geführtes Projekt ist eben gerade nicht chaotisch. Das sind sehr, sehr klar definierte Prozesse, klare Schritte, wie man zu einem Ergebnis kommt. Und wenn man das hinkriegt, wie vorhin gesagt, wenn man zum Beispiel ein cross-funktionales Team hat, dann kann man damit ein sehr, sehr berechenbares Projekt führen. Insbesondere dann, wenn man eben auch bereit ist, am Scope des Projekts ein bisschen zu optimieren, wenn es zu Schwierigkeiten mit der Timeline kommt. Leider ist aber oft das Gegenteil der Fall. Keiner hat wirklich Ahnung, wie Agilität funktioniert, weil man hat früher das eh nicht so gemacht und dann wurde einer mal als Scrum Master geschult. Das hat aber nicht viel damit zu tun, ob man wirklich in der Lage ist, eine agile Organisation zu sein. Und dann wird halt irgendwie das Buzzword Scrum, was ja schon kein Buzzword mehr ist, oder das Buzzword Kanban draufgepappt, ohne dass das Fundament da ist, ohne dass jemandem wirklich klar ist, was das bedeutet, wenn ein Projekt agil geführt wird. Typischerweise wird das dann gemacht, wenn zum Beispiel die Requirements noch nicht klar sind. Das kann man machen, ja, es ist manchmal wertvoll, die Requirements, also die Anforderungen erst im Laufe des Projekts wirklich entdecken zu können, weil die dann viel näher an der Realität sind. Vielleicht kann man sogar einen frühen Projektstand schon mal echten Nutzern zeigen oder mit echten Nutzern testen, sodass man viel, viel bessere Requirements kriegt. Aber dann braucht man auf der anderen Seite einen unglaublich guten Product Owner, also jemand, der eine klare Produktvision hat, der Entscheidungsbefugnisse hat, diese Anforderungen tatsächlich dann letzten Endes festzuzunnen und der das Projekt wirklich führt im besten Sinne des Wortes. Also der dieses Projekt repräsentiert und voranbringen will, weil der ersetzt uns nämlich die Requirements. Viele agile Projekte, auch Großprojekte in großen Firmen, haben weder das eine noch das andere. Die starten ohne Requirements, es gibt keine Spezifikation, ist ja ein agiles Projekt, aber es gibt auch keinen Product Owner, sondern mehr so einen glorifizierten Project Manager, der gar nicht weiß, was er managen soll, weil ja keine Requirements da sind. Und dann gibt es so eine ganz vage Produktvision, die vielleicht von der Geschäftsführung kommt, macht mal was mit AI im Umfeld von unseren Prozessen. Auf der Basis kann man kein sinnvolles agiles Projekt führen. Das heißt, es gibt maximale Dynamik, maximale Variabilität, aber minimale Orientierung und auch minimale Outcomes natürlich. Das sollte man sich bewusst sein. Agilität ist wirklich das Gegenteil von Chaos. Das heißt, nicht jeder macht mal irgendwas, alle haben viele Hüte auf, sondern da gibt es klare Rollen, Fokus und kurze Feedbackzyklen. Und ein gutes, agiles Setup braucht ja keine fertige Spezifikation, braucht aber eine klare Produktversion, braucht klare Ziele, messbare Ziele, die das Produkt erreichen soll, braucht einen sehr guten Product Owner, der die Requirements dann im Laufe des Projekts definiert statt upfront und der dann auch eben dafür da ist, quasi Input zu machen. zu holen von verschiedenen Stakeholdern und ein agiles, cross-funktionales Team, das wirklich in der Lage ist, dann auch diese Requirements umzusetzen. Das heißt, das Team muss auf jedes System Zugriff haben, das notwendig ist, um das Projekt zu erreichen. Ansonsten sollte man lieber klassisch planen. Klassisch im Sinne von, wir machen erst eine Spezifikation, validieren die mit allen beteiligten Abteilungen, klären die Zulieferungen, wie ich es vorhin gesagt habe und wir machen wirklich ein Gentschart mit Wasserfallmodell. Nicht ein Gentschart für die Tasks, aber ein Gentschart für die groben Zulieferungen, die dran sind, damit man sie zeitlich einladen kann. Alles dazwischen ist eigentlich suboptimal und halt sehr, sehr unplanbar. Ein kleiner Zusatzbonus in diesem Kontext ist oft, dass Stakeholder nicht genau wissen, was ihre Rolle ist in agilen Projekten, also die, die es wirklich am Ende bezahlen. Das heißt, die tauchen dann immer mal auf und geben eine neue Richtung vor und nehmen Einfluss, dann verschwinden sie aber wieder, sind nicht mehr für Rückfragen verfügbar oder sind auch nicht verfügbar, um irgendwelche Dinge durchzusetzen, die notwendig wären. Und das ist dann auch sehr, sehr ungünstig. Also Stakeholder haben in agilen Projekten eine bestimmte Rolle, haben bestimmte Punkte, an denen sie mit dem Team interagieren und daran sollte man sich dann eben auch halten. Es ist aber tatsächlich nicht immer nur das Projekt Setup, also in der Organisationsstruktur, das zu so Problemen führt. Manchmal ist es tatsächlich auch das Entwicklungsteam. Das habe ich tatsächlich auch mehrfach gesehen. Ich bin in eine Firma mal gekommen als CTO, da habe ich tatsächlich selber diesen Fehler gemacht. Es gab ein Produkt, das hat auch funktioniert. Das war ein relativ komplexes Produkt, das auf Windows lokal gelaufen ist. Sehr klassisch, individuell installiert auf Servern. Ist auch schon eine Weile her. Macht man heute ja nicht mehr so. Das war ein System, das hätte man eigentlich nur mit neuer Funktionalität erweitern müssen. Man hätte da Sachen, bestimmte Funktionalitäten reinbauen müssen, um neue Märkte zu erschließen. Absolut sinnvoll aus meiner Sicht, aber natürlich kam dann der Impulse aus dem Entwicklungsteam, hey, jetzt ist doch die Gelegenheit, mal alles neu zu machen, weil eigentlich wollen wir doch auf Docker, was damals eben gerade, ja, ich will nicht sagen aufkam, aber wirklich krasse Traktionen gewonnen hat. Wir wollen doch cloudfähig werden. Wir wollen doch eigentlich auch die Architektur mal aufräumen, wollen das skalierbarer machen. Und jetzt müssen wir eh in dem Projekt so viel ändern, dann lass es uns doch gleich neu auf die grüne Wiese bauen. Das geht dann auch viel schneller, weil eigentlich brauchen wir vieles aus dem Altprodukt nicht mehr. Die Argumente sind immer die gleichen. Man hat irgendwelche veraltete Technologie, die vielleicht auch das Entwicklungsteam gar nicht mag und ursprünglich nicht erschaffen hat. Also ganz oft ist die Situation, dass aus dem ursprünglichen Implementierungsteam dann schon keiner mehr übrig ist und das neue Team, das auf den ganzen Legacy-Problemen sitzt, hat halt keinen Spaß an der alten Code-Basis. Ja, und vielleicht häufen sich auch die Bug-Tickets und man sagt sich, hey, wenn ich alles neu schreibe, dann bin ich das quasi alles los. Aber Greenfield-Projekte haben halt ganz andere Probleme. Meistens unterschätzt man enorm den Aufwand, den es bedeutet, mit einem alten Produkt gleichzuziehen, was Features betrifft. Und meistens schätzt man falsch ein, ob man die alten Features noch braucht. Die Antwort ist fast immer ja. Es gibt fast immer irgendeinen Kunden, der irgendein obskures Feature benutzt, der davon abhängt, der davon abhängt, dass diese und jene API genauso funktionieren. Und all das ist in einem Greenfield-Projekt, wo wir versuchen, das neu zu erschaffen, ein extremes Problem. Also ich habe normalerweise immer vermieden, solche Tiger-Teams zu machen, die quasi ein neues Produkt schaffen, wenn das alte nur noch gewartet wird und stattdessen versucht, inkrementell zu transformieren, was an alten Software da war, einfach weil Greenfield immer unterschätzt wird. Der Scope wächst stetig, die Komplexität steigt stetig, die Zeit reicht nie, der ROI verschiebt sich ins Ungewisse, weil wir schreiben ja alles neu, nur um ein paar neue Features zu haben. Das ist im Prinzip fast immer der falsche Weg, wenn es irgendeine Technologie gibt, die eigentlich schon einen Großteil dessen, was wir brauchen, macht. Eine Migration und eine Neuentwicklung sollte man in dem Sinne auch sehr, sehr häufig trennen. Eine Migration, die in eine Neuentwicklung eingebaut wird, ja, das ist fast immer risikoreicher als die Alternativen. Es ist auch ein Fakt, dass Greenfield-Projekte oft beschlossen werden, ohne dass das Altsystem wirklich vollständig verstanden wurde. Weder von der Kundennutzung des Altsystems her, noch von der technischen Komplexität her. Und die Migrationsstrategien, was es bedeutet, Kunden dann auf das neue System zu heben oder Daten, die es schon gibt, in das neue System zu überführen, werden auch viel zu spät geplant. Wir bauen erstmal alles neu, umziehen können wir später. De facto muss man die Migrationsstrategie eigentlich zuerst machen, damit man das neue System darauf optimieren kann, dass sie auch unterstützt wird. Long story short, wenn man kein Greenfield-Projekt machen muss, sollte man es nicht machen, sondern sollte eher auf inkrementelle Migration setzen und dann entweder erst migrieren, dann die Features bauen oder die Features am Altsystem anbauen oder die neuen Features sind dann vielleicht im ersten neuen Microservice, der schon mal die neue Architektur einläutet oder wie auch immer. Aber Greenfield ist fast immer das Risikoreichste, was man machen kann, weil man eben alles Wissen wegschmeißt. Das sicherste Wissen über Anforderungen ist, was im Code ist, ist was in der Software ist. Das ist die beste Dokumentation darüber, wie die Kunden die Software verwenden, ist die Software selbst. Und ja, manche Features werden nicht verwendet, aber man ist immer wieder schockiert davon, dass eben doch jeder obskure Button in der Realität von irgendeinem Kunden schon mal geklickt worden ist. Und allein dann diesen Button wegzunehmen, bedeutet auch für die Überzeugungsarbeit, Marketingarbeit mit keinem Wert, der dem Ganzen gegenübersteht. Also auch das, dass man sich vom Entwicklungsteam quasi Richtung Greenfield treiben lässt, obwohl eigentlich existierende Software da ist, die nur verändert werden müsste, fast immer eine schlechte Idee. In meinem persönlichen Fall war es dann tatsächlich so, dass wir das Greenfield-Projekt sowieso in das ursprüngliche System integrieren mussten, weil natürlich doch alle Altanforderungen weiterhin vorhanden waren. Und dann hatten wir zwei eigentlich inkompatible Architekturen, die parallel gelaufen sind für sehr, sehr lange Zeit und einen viel, viel höheren Aufwand für die Implementierung dieser Features, als wir ursprünglich angesetzt hatten. Also wirklich auch auf der ganzen Linie nicht gescheitert, aber ein stark ins Stolpeln geratendes Projekt, was natürlich viel länger gedauert hat, als man denkt. Weil man geht ja oft rein, gerade als ein bisschen technologieorientierter Mensch und sagt sich, ach, mit Framework XYZ geht es ja so viel leichter alles da. Bevor ich das Altsystem anfange, habe ich das in Kurzem neu geschrieben. Meistens stimmt das halt nicht und meistens ist das Framework selber dann auch nochmal ein Problem, weil man es halt doch entweder überschätzt hat oder auch falsch eingeschätzt, was es wirklich an Funktionalitäten liefert, die man an der Stelle braucht. Long story short, das waren meine drei wesentlichsten Punkte, die Projekt ins Stolpern bringen und ich hoffe, dass das nicht für alle quasi ein alter Hut war, weil was ich in unserer Umgebung sehe, in Firmen, ist, dass immer wieder in diese drei Fallen getappt wird. Was sie gemeinsam haben, ist wie gesagt, das Scheitern beginnt nicht im Code, sondern in der Kultur. Es scheidet nicht an den Technologien oder an der Software, die vorhanden ist, sondern an unrealistischen Erwartungen, fehlende Verantwortung, mangelnde Kommunikation. Das heißt, wer Großprojekte wirklich meistern will, braucht erstmal keine besseren Tools, sondern bessere Entscheidungen und bessere Strukturen. Und bevor man ein Großprojekt startet, also besonders ein Großprojekt, eigentlich bevor man jedes Projekt startet, sollte man eigentlich über diese Dinge nachdenken. Nicht, was ist mein Toolset, nämlich Jira oder Trello oder Zettel, sondern wo bette ich mich ein, was ist meine Kultur, meine Firmenstruktur, was für ein Prozess kann ich wirklich dieser Firmenstruktur zumuten, was funktioniert da wirklich. Und ein großes Problem, das ich auch sehe, ist, viele dieser Projekte werden von vornherein risikoavers geplant und dann auch risikoavers geführt. Was meine ich damit? Sie werden risikoavers geplant in dem Sinne, dass man versucht, das Projekt so aufzusetzen, dass es möglichst gar kein Risiko gibt, dass es irgendwie beeinträchtigen kann. Das stimmt aber meistens nicht. Man stellt dann fest, oh, es gibt doch ganz viele Risiken und dann hat man ein hochkomplexes Risiko-Tracking-Sheet mit Impact und Probability und Importance und all den Sachen, die man so machen kann. Aber keiner traut sich, die wirklichen Risiken einzutragen. Ich weiß nicht, vielleicht ist das meine spezifische Erfahrung, das habe ich aber auch schon mindestens ein Dutzend Mal erlebt, dass das komplexeste Risiko-Tracking-Mechanismus vorhanden war, aber jedes Mal, wenn man ein Risiko beim Namen benannt hat, gingen Diskussionen los, ob man das jetzt wirklich eintragen soll, weil dann sieht es ja auch der Sponsor und dann sieht es ja auch die Geschäftsführung oder ob man das lieber unter den Tisch fallen lässt, damit das Projekt nach außen total smooth und on track aussieht. Und das ist vielleicht auch ein Faden, der sich durch viele solche Projekte durchzieht, dass man versucht, so ein Happy Face auf die Ugly Truth zu setzen. Also ein Projekt muss nach außen immer total erfolgreich aussehen, während innen die Probleme immer größer werden, sich immer mehr vervielfältigen, bis es dann halt wirklich zum völligen Knall kommt. wohingegen man mit einem echt risikogetriebenen Projekt, wo man von vornherein Riesen benennt und adressiert, diesen Misserfolg auch hätte abwenden können. Vielleicht liegt das, diese Risiko-Aversität aber auch daran, dass die meisten Projekte gar keine superklaren Ziele haben und keinen so super messbaren Erfolg, sodass sie einfach nur daran gemessen werden, ob sie von außen halbwegs glatt und friktionslos aussehen. Letzten Endes Risikobetrachtung, das Kontinuiersträcken von Risiken ist eigentlich eines der wesentlichen Themen in Projektmanagement. Das ist nicht, dass man Tasks auf einem Board von A nach B schiebt, sondern dass man sich permanent bewusst macht, was bedroht mein Projekt, was sind Hindernisse, was sind organisationelle Risiken und diese auch ehrlich benennt und mitigiert. Und dann vielleicht auch, wenn so ein Risiko wirklich mal zu einem mega unlösbaren Problem wird, den Mut hat, ein Projekt abzubrechen und zu sagen, okay, an dieser Stelle kommen wir nicht weiter. Weil für die meisten Firmen ist es besser, anderthalb Millionen auszugeben statt zehn und dann am Ende trotzdem kein Ergebnis zu haben. Und das ist eigentlich nur mit einer sehr risikogetriebenen Betrachtung von so einem Projekt möglich. Das, worüber ich heute geredet habe, passt da sehr gut dazu, weil das sind eigentlich Risiken, die kann man von vornherein direkt in das Tracking-Sheet schreiben. Organisationsstruktur passt nicht zur Projektstruktur, Kommunikation zwischen Abteilungen scheitert an Schuldzuweisung oder scheitert an unklaren Reporting-Lines und so weiter und so fort. Das sind Risiken, die kann man schon ins Template schreiben, weil die für jedes Projekt gleichermaßen gelten und eigentlich als allererstes adressiert werden müssen. Oder eben das Risiko, dass die Organisationsstruktur keine agile Projektstruktur aushält, im Sinne von tragen kann. Also, lange Rede, kurzer Sinn, risikogetriebenes Vorgehen immer gut, aber es gibt ein paar Risiken, die sind für jedes Projekt wahr, die sollte man also in jedem Fall adressieren und das waren mal drei davon.