Schlagwörter: Annahmen, Projektmanagement, regelmäßig überprüfen, falsche Annahmen, Probleme, Projektversagen, klare Annahmen, Missverständnisse, bekannte Annahmen, kontrollieren, hinterfragen, Kritik, Risikomanagement, potenzielle Probleme, frühzeitig erkennen, Risiken

In dieser Podcast-Folge sprechen wir über Annahmen im Projektmanagement. Es ist wichtig, Annahmen regelmäßig zu überprüfen und anzupassen. Falsche Annahmen können zu Problemen und Projektversagen führen. Wir betonen die Bedeutung von klaren und expliziten Annahmen, um Missverständnisse zu vermeiden. Auch bekannte Annahmen sollten kontrolliert und hinterfragt werden. Kritik und Risikomanagement sind entscheidend, um potenzielle Probleme frühzeitig zu erkennen. Es ist wichtig, sich bewusst zu sein, dass Annahmen immer Risiken darstellen können.

Transcript

Mel:
[0:00] Moin Fabian! 

Einführung: Das Management von Projekten

Fabian:
[0:01] Salut Melvin! 

Mel:
[0:02] Management by Project, Ausgabe Nummer 29, wir melden uns nach längerer arbeitsbedingter Pause zurück und steigen direkt in das neue Thema ein. 
Wenn man Projekte aufsetzt, dann ist es in der Regel so, dass man ein ungefähres Bild davon hat, was man da eigentlich machen soll und was auf einen zukommt. 
Und relativ früh in Projektphasen hat man dann auch eigentlich eine erste Lösungsskizze vorliegen und die steht natürlich so ein bisschen im luftleeren Raum, weil man alle notwendigen Abklärungen noch nicht gemacht hat. 
Man hat sich da noch nicht tiefer in die Themen reingearbeitet. 
Und was dann aber relativ oft gemacht wird und was eine, glaube ich, auch völlig zulässige, gainige Praxis ist, ist, man stellt zu Projektanfang Prämissen auf. 
Man nimmt bestimmte Annahmen und sagt, hey, das ist das, wovon wir ausgehen, wie irgendwie das Gesamtsystem funktioniert, welche Interaktionen wir mit anderen Bereichen haben etc. 

Der Rahmen und die Bedeutung von Prämissen

[0:55] Und diese Prämissen helfen einem dann dabei so ein bisschen den Rahmen abzustecken, in dem man sich da bewegt. 
Und eine spannende Situation, die sich daraus dann ergeben kann im Laufe des Projektes, ist, wenn sich Prämissen, wenn sich Annahmen erstmal als falsch erweisen, wie man damit rumgeht. 
Oder auch wenn man sagt, so auf bestimmte Prämissen, die brauchen wir gar nicht mehr. Da dachten wir ursprünglich mal, das sieht so und so aus. 
Aber in Wahrheit ist das gar nicht so dramatisch, wie wir ursprünglich mal gedacht haben. 
Und vielleicht, Fabian, kannst du mir gleich zum Anfang mal noch so ein paar Beispiele über den Tisch werfen, was so typische Prämissen sind oder was dir in deiner Praxis mal so begegnet ist. 

Fabian:
[1:34] Wie soll ich sagen, ich kann mich sehr mit dem identifizieren, insbesondere auch im breiteren Sinn. 
Es gibt ja, habe ich letztes Jahr gelernt, da war ich mal im Anforderungsmanagement-Schulung, die Worte explizit und implizit. 
Und jetzt in dem Kontext, im professionellen Kontext vom Anforderungsmanagement oder Requirement Engineering geht es ja darum, so wenig wie möglich implizit zu haben. Implizit heisst, wir alle denken so, das haben wir einen Konsens oder das ist die Anforderung. 
Aber eigentlich habe ich es ganz anders gedacht wie du und wir haben es nie aufgeschrieben, nie geklärt. 
Und explizit heisst eben, ich habe es versucht, so eindeutig wie möglich und nach allen Regeln der Kunst zu formulieren. 
Und ich glaube, das ist mal die erste Frage, die sehr mit mir resoniert. 

Die Bedeutung von expliziten Prämissen

[2:22] Ich habe ja gerade in dem Umfeld, in dem ich mich in den letzten Jahren bewege, gelernt, das Explizite zu lieben. 
Manchmal ist auch das Implizite gut. Ich glaube, das ist auch noch eine Kunst für sich. 
Aber je expliziter du es gemacht hast, das ist natürlich Arbeit, das geht nicht schnell, desto klarer ist dir auch, was diese Prämisse gewesen ist oder diese Annahme, die du getroffen hast. 
Und ich für mich selber habe mehr investiert in letzter Zeit, um das explizit zu machen. 

Beispiel: Die Notwendigkeit einer stabilen Unternehmensstrategie

[2:59] Beispiel hast du gefragt, Dinge die du sowieso tun musst, du gehst mal davon aus, dass dein Umfeld eine gewisse Stabilität hat. 
Sei das die Unternehmensstrategie, sei das die Organisationen, die Bedürfnisse und so weiter. Und das kann sich immer relativ schnell als falsch herausstellen, da gibt es dann auch noch den Markt und andere Marktteilnehmer. 

Auswirkungen von Veränderungen auf Projekte

[3:23] Und ich würde sagen, je nachdem, ich glaube, was sicher unterscheidenswert ist, wie gewohnt ist man selber und das eigene Umfeld, dass diese Dinge passieren. 
Ich glaube, das prägt schon, wie man dann damit umgeht, wenn zum Beispiel die Unternehmensstrategie, ändert. Ich denke, tendenziell, habe ich oft erlebt, wird immer unterschätzt, wie viel Auswirkungen das hat. 
Oder manchmal ist es ein neuer Chef, manchmal ist es andere Änderungen, die in meinem Erlebnis immer starke Einwirkungen haben auf ein Projekt. 
Ja, ich glaube, es ist dann recht simpel. 
Meine Haltung ist, da interessiert mich auch deine, je besser du verstehst, dass sich verändert hast. 
Je früher du reagierst, oft auch je konsequenter du reagierst, desto besser für den Projekterfolg in meinem Erlebnis. 
Also wenn ich zurückdenke, wenn ich mal nicht die Konsequenz der Veränderung antizipiert habe, das hat sich immer relativ negativ ausgewirkt auf ein Projekt. 
Und wenn ich es geschafft habe, es zu tun. Ja, also ich nehme jetzt weiter ein bisschen mehr Bezug auf strategische Geschichten. Man könnte es genauso auf den Markt beziehen, auf Partner. 

Konsequenzen von Schlüsselannahmen und strategischen Entscheidungen

[4:42] Ja, ich glaube da, ich glaube das, was dem gemeinsam ist, dass es, es gibt so die Schlüsselannahmen, die du getroffen hast. Und wenn die ändern, das, das hat in jedem Fall Konsequenzen. 

Mel:
[4:55] Das ist eigentlich so das, was ich aus meiner Praxis auch beobachten kann, dass wenn du da Pech hast, dann legst du am Anfang aus einer vielleicht sogar relativ naiven Annahme oder aus einer einfachen Überschlagsrechnung heraus Dinge fest, die dir hinten raus um die Ohren fliegen und zwar bis hin zum Projektabbruch. 
Also vielleicht so ein Beispiel, was mir mal begegnet ist, dafür gibt es ein Standard-Tool. 
Also wir gehen davon aus, wir haben irgendeine Lösung oder irgendein Problem und wir gehen jetzt davon aus, wir kaufen uns dafür ein Tool ein. 
Und ja, okay, weil irgendwie vielleicht der Anwendungsfall eigentlich was ist, wo du sagst, naja, Probleme haben auch noch andere, da gibt es irgendeinen Lieferanten geben. 
Und dann evaluierst du und dann machst du und tust und hast vielleicht sogar noch eine Ausschreibung und auf einmal stehst du halt da und stellst dir dann fest, okay, es gibt zwar Anbieter, aber die haben jetzt irgendwie doch nicht genau das, was ich haben will. 
Oder die customizing Aufwände sind irgendwie so hoch, dass ich eigentlich das ganze Ding auch selbst bauen könnte. Oder ich habe dann nachher Probleme mit dem System Versioning, also SAP lässt grüßen. 
Ich habe so viel gecustomized, dass ich auf die nächste Version nicht upgraden kann. 
Also solche Themen, die dir dann richtig um die Ohren fliegen, weil, ja, warum eigentlich? 
Weil man das nicht regelmäßig überprüft hat? Weil man zu naiv mit diesen Annahmen umgegangen ist? Was wäre deine Einschätzung? Warum eigentlich? 

Bedeutung eines Geschäftsmodells für ein Projekt

Fabian:
[6:16] Also ich habe analytisch, der Geneigte hat es vielleicht schon gemerkt, ich abstrahiere gern. 
Was mir da immer hilft, ist eigentlich zu denken, auch mit dem Projekt. 
Hast du eigentlich ein Geschäftsmodell? 

Die Essenz eines Geschäftsmodells: Problem, Lösung, Geld verdienen

[6:31] Die Essenz eines Geschäftsmodells ist ja, es gibt ein Problem und ich erarbeite eine Lösung dafür und im besten Fall kann ich dafür dann Geld verlangen und so weiter. 
Mir hilft immer, du kannst auf beiden Seiten falsche Annahmen haben. 
Und wenn du explizit in der Geschäftsmodellentwicklung bist, bist du dir auch dem sehr sehr bewusst, weil wenn du neue Geschäftsmodelle machst, die scheitern ganz ganz oft oder neun von zehn Fällen und ich glaube ein Projekt ist nichts anderes auch wie ein Gefäß, das versucht ein Geschäftsmodell zu erfüllen oder und da kann es auf der Problemseite kann etwas passieren oder eben auf der Solution Seite. 
Du hast irgendwelche Annahmen bezüglich deiner Lösung, die du jetzt erarbeitest in dem Projekt, die sich auf einmal auf falsch herausstellen und du hast irgendwelche Annahmen dazu, was wirklich eigentlich effektiv das Problem ist, was du lösen musst oder und ich Ich finde das Modell sehr, sehr passend. 
Egal, ob du jetzt im Marketingumfeld bist, wo du effektiv an den Markt gehst, dort kommt die Methode eher her. 
Aber du hast ja immer eigentlich einen Auftraggeber, einen Problemträger sozusagen und du hast Lösungshypothesen, denen du folgst. Wenn da in den beiden Räumen sich was ändert, dann musst du reagieren. 

[7:49] Es gibt sicher auch Gegenbeispiele, wo weiterhin Lösungen erarbeitet wurden, die keine Lösungen sind oder Probleme gelöst wurden, die keine Probleme sind. 
Aber langfristig ist es in der Regel, holt einem das schon ein. 

Mel:
[8:03] Also meine Beobachtung ist tatsächlich, dass der zweite Fall, den du geschildert hast, sogar häufiger vorkommt als der erste. 
Was ja so eine gängige Praxis ist und von der ich ehrlich gesagt überhaupt kein Fan bin, ist, wenn man mit Prämissen arbeitet, dass man dann irgendwie ganz am Anfang seines Projekts mal irgendwie in sein Lenkungsgremium geht und sagt so hier das sind unsere Prämissen und nehmt die mal bitte ab. 
So cover your ass im Sinne von wenn dann eins von den Dingern dir um die Ohren fliegt, dann bin ich ja nicht schuld gewesen, weil Management hat ja gesagt, das passt schon irgendwie. 
Und was mich daran so stört, ist jetzt viel weniger dieses Vorgehen, also ich glaube, es gehört zum Stakeholder-Management dazu, zu sagen, hier wir bewegen uns halt in einem unsicheren Raum und da haben wir gewisse Anforderungen für getroffen, die uns auf diesem Weg begleiten. 
Aber dann kein aktives Risikomanagement zu führen und zu sagen, okay, was kann ich denn tun, damit diese Annahmen tatsächlich auch eintreten oder damit ich zumindest früh erkenne, wenn sie nicht eintritt. 

Risikomanagement und Sunk Cost Fallacy in Projekten

[8:58] Das ist was, was ich sehr selten sehe und das führt in meinen Augen halt dazu, dass du dann am Ende tatsächlich in so eine Sunk Cost Fallacy reinläufst, weil du einfach sagst, ich habe schon zu viel investiert. 
Wenn ich jetzt hier rausgehe, dann produziere ich die Abschreiber, dann produziere ich die Sunk Cost, dann gehen die Themen irgendwie nicht voran. 
Ich muss vielleicht sogar komplett neu anfangen. Das will ich dann ja auch nicht und deshalb mache ich lieber weiter mit irgendwas, was eigentlich total sinnfrei ist. 

[9:25] Hast du in deinen Themen, deinen Projekten da einen Mechanismus, wo du sagst, das sind meine Prämissen und die überprüfe ich auch zyklisch. 

Fabian:
[9:35] Ich glaube, einerseits habe ich persönlich einen Fluch. Es ist Fluch und Segen. 
Ich bin jemand, der dauernd darüber nachdenkt, was passieren könnte. 
Dann ist die Kunst, zu spüren, wie gross die Konsequenzen sind, wenn du falsche Annahmen hast, oder wie gross die Veränderung im Umfeld ist. 
Es ist genau, wie du es sagst. Wenn du sagst, das unternehmerische Denken, dort ist das Gang und Gäbe. 
Wenn du wirklich sozusagen an der Spitze des Bootes stehst als Unternehmer, dann spürst du jede Welle, jede Windrichtungsänderung usw. 
Du musst es auch, deshalb wird ja auch immer gesagt, ja, Unternehmertum ist nicht akademisierbar, weil das ist ja dann ein intuitives Reagieren auf Veränderungen. 
Und ich glaube, dass Projekte, egal wie klein, schlussendlich sich da nicht unterscheiden. 
Deshalb ist es so eine reizvolle Aufgabe, weil du eine Art eben doch die Captain-Funktion dann hast als Projektleiter und sicherstellen musst, dass du die Veränderungen auf beiden Seiten, also beim Problemraum wie auch beim Lösungsraum, dass du die frühzeitig spürst. 

[10:47] Und dann gibt es nichts anderes wie so konsequent wie möglich reagieren. 
Und ich persönlich glaube, nicht reagieren ist praktisch immer falsch, langfristig gesehen, auch wenn das Umfeld träge ist. Wir haben ja auch schon über Agilität geredet. 
Agilität ist eben eine manifestierte Eigenschaft. Es ist nicht eine Methode. 
Und wenn du in einem Unternehmensumfeld bist, das relativ träge ist, dann kann man ja verzweifeln an dem, dass alle das tun, was du gerade beschrieben hast, dass man einfach Dinge mit viel Momentum weiterlaufen lässt. 
Für mich ist das, das sind Ursache und Wirkung, für mich ist es logisch, dass dich das früher oder später einholt. Also nicht zwingend ich als Projektleiter, als Organisation sowieso. Also du gibst für das Falsche das Geld auf, und das hat Konsequenzen. 

Sinnhaftes Arbeiten und langfristige Arbeitsstrategie

[11:44] Und ja, für meine, für sinnhaftes Arbeiten ist Für mich persönlich ist es sehr wichtig, an sinnhaften Dingen arbeiten zu können, die der Organisation etwas bringen, die sie vorwärts bringen. 
Ich glaube auch daran, auch wenn es manchmal kurzfristig nicht so ist, dass das langfristig auch die beste Arbeitsstrategie ist, Also sowohl auf dem persönlichen wie auch für ein Projekt, weil… 

[12:11] Eben, früher oder später holt es dich ein und ich habe tatsächlich gesagt, auch schon oft, wie lange arbeite ich jetzt? 
Zu lange. Zu lange. Aber ich habe mich ja einen guten Teil dieser Arbeitszeit in grossen Organisationen bewegt und da erlebst du zum Beispiel zig Reorganisationen, oder? 
Und wenn du Projekte machst, die strategisch exponiert sind, ich habe immer erlebt, dass unterschätzt wird, was die Konsequenzen sind von Reorganisationen zum Beispiel. 
Da musst du darauf reagieren, du musst dich positionieren. Das heisst nicht überhastet. 
Es geht eigentlich darum zu erkennen, wie gross die Konsequenzen der Veränderung sind und adäquat darauf zu reagieren. 
Deshalb im Generellen. Im Konkreten, also in der Geschäftsmodellentwicklung benutzt man das Wort pivotieren. 

Pivotieren: Konsequent in eine andere Richtung gehen

[13:06] Und was man damit meint ist, dass man wirklich konsequent auch mal in die andere Richtung geht, oder? 
Also zuerst bin ich nach links gerannt, da habe ich gemerkt, da komme ich nicht weiter und dann gehe ich ganz konsequent mal nach rechts im Wissen drum, dass das genauso falsch sein kann, aber wenn ich es nicht tue… 
Weiss ich eben nicht, ob es falsch war. Ich glaube ein bisschen an das, aber es ist sehr kontextabhängig, wie groß diese Ausschläge dann sein müssen. 

Mel:
[13:39] Ein Punkt, den du eben genannt hast und den ich auch schon beobachtet habe, ist natürlich so die Frage, man hat als Projekt ja irgendeinen Auftrag und möchte irgendwas der Organisation Gutes tun, zumindest im Regelfall. 
Und die Frage ist ja, oder was ich dann quasi als Fallstrick schon mehrfach beobachtet habe, ist das Verwechseln von Wunsch und Chance. 
Also dass man hingeht und sagt quasi, es wäre total super, wenn, bleiben wir bei dem Beispiel von eben, wenn durch irgendwie ein Standard-Tool wir unsere Prozesse irgendwie für quasi geschenkt super vereinfacht bekommen und dann irgendwie viel besser produzieren können als vorher. 

[14:20] Und das ist ja erstmal eine Wunschvorstellung. Also das ist ja erstmal, das hätte ich gerne, das hätte jeder, jedes Unternehmen gerne. 
Und was dann aber manchmal passiert, und das ist halt einfach das Gefährliche beim Arbeiten mit Annahmen, ist, dass ich dann hingehe und sage, okay, ich mache diesen Wunsch zu einer Annahme. 
Und dann sage ich halt auch immer, wir treffen jetzt hier mal die Annahme, dass, wenn ich ein Standard-Tool kaufe, ich irgendwie signifikante Einsparungen damit erzielen kann. 
Und auf einmal habe ich quasi einen Denkfehler gemacht, weil ich habe nämlich, wie gesagt, Wunsch und Chance verwechselt und manövriere mich dann in so eine Legendenbildung rein. 
Also was ich einfach da schon beobachtet habe ist, kommt es dann in so Konstellationen und so, auch da bleiben wir bei dem Beispiel, wo du dann so sagst so, ja, vielleicht ist es jetzt irgendwie doch nicht die beste Idee, das auszuschreiben, weil wir haben vielleicht eine RFI gemacht, also wir sind mal in den Markt gegangen und haben gefragt, hey Anbieter, was habt ihr denn so, was kostet das so ungefähr und dann haben wir vielleicht schon eine erste Indikation bekommen und dann sagst du so, hm, vielleicht sollten wir unsere Prämisse mal hinterfragen und dann kriegst du aber so gehört, nein, nein, wir haben einfach nur nicht die richtigen Unternehmen gefunden. 
Da gibt es noch irgendwelche versteckten Anbieter und wenn wir dann die Ausschreibung machen, dann kommen die schon alle. 

[15:35] Und eigentlich wächst so nach und nach in der Organisation die Überzeugung so, naja, vielleicht gibt es die doch nicht. 
Also, oder warum melden die sich nicht oder was ist da los? Aber weil du halt einfach mal gesagt hast, so nee, wir wollen irgendwie niedrigere Preise durch höhere Anbieter, fliegt dir das Thema dann irgendwie, also das wird dann nicht mehr kontrollierbar und du hast dann so eine self-fulfilling prophecy geschaffen, ja und dann machst du die Ausschreibung und dann kommst du genau zu der Situation und dann hast du halt nachher da irgendwie nur einen Anbieter und den willst du eigentlich gar nicht, weil der hat gar kein Produkt. 

Fabian:
[16:07] Ich kann es auch noch mit einem Beispiel ergänzen, ganz konkret, dass es verwandt ist. 
Und gerade das Legendenbildung habe ich da angesprochen, weil das ist, glaube ich, ziemlich korrekt bezüglich Annahmen. 
Vielleicht doch zuerst. Ich meine, das beste Gegenmittel gegen Annahmen ist mehr zu wissen, oder? Es ist banal. 
Und das bewahrheitet sich aus meiner Sicht immer deshalb. 
Es wird eben schwieriger, wenn du laufende, grössere Projekte hast, hast du noch die Muße zu verstehen, ob du am richtigen Arbeiten bist. Aber du musst es tun. 
Ich habe zwei konkrete Beispiele. Als ich in einer grossen Organisation angefangen habe, war mein erstes Projekt, eine Software-Konzern weit einzuführen. 
Die Auftraggeber waren überzeugt, dass das eine sinnvolle Idee ist. 

Anfängliche Unsicherheit beim Beurteilen der Situation

[17:05] Ich konnte das natürlich am Anfang nicht beurteilen, ich bin einfach rein, ja cool, ich versuche das mal hinzubekommen. 
Mit der Zeit habe ich gemerkt, so wirklich ist gar kein Bedürfnis da für die Produkte, die so eine moderne Software bieten. 
Also die Resultate, diese Software, es war ein Management-Informationssystem, das bessere Reporting zu gewissen KPIs ermöglicht hat, aber eigentlich gab es gar keine Nachfrage nach diesen besseren KP oder nicht in dem Ausmass, wie die Geschichte manchmal erzählt wird. Das war auch genau so eine Legendenbildung. 

Selbstläufe von Prophecies und Annahmen bei Projekten

[17:40] Ich glaube, das sind auch so Selbstläufe eben von vielen Prophecies, weil du musst ja auch etwas verkaufen. Also das ist ja auch Overselling oft dann, oder? Also du bist ein Verkaufer, musst du es ja haben, um überhaupt so ein Projekt machen zu können. 
Und dann gehst du eben von Annahmen aus. Und ich muss sagen das. 
Das Projekt war extrem aufwendig jetzt für das Thema, was es betroffen hat. 
Und vier, fünf Jahre später wurde dann die Software nicht mehr benutzt, weil es war einfach Overkill. 
Und man hat ja gar nicht die Spezialisten, um das zu verwenden. 
Das ist ein Beispiel, ja. Und das andere bezüglich Annahmen, da war es wirklich ein Produkt, das ich an den Markt gebracht habe. 
Da war eine Schlüsselannahme, wir können unter unserem Brand, also Unternehmen, dieses neue Produkt verkaufen. 
Also es war eine Wunschannahme, weil schlussendlich war es banal. 
Die Brandingverantwortlichen hatten einfach keine Lust, eine neue Brandingstrategie zu machen. Ich habe dann am Anfang gedacht, Challenge accepted, kann ja sein, dass das geht. 
Und nachher haben wir mit Evidenz, also zig Markstudien und so mit der Zeit herausgekommen, es geht nicht. Du kannst nicht unter dem Wasserbrand Feuer verkaufen, oder? 

Mel:
[18:58] Ja, oder das klassische Marketingthema. Du kannst als Premium-Marker kein Budget-Projekt machen. 

Fabian:
[19:04] Und da war meine Konsequenz am Schluss. Ich habe dann die Projektleitung, nachdem ich realisiert habe, dass ich das nicht bewegen kann, dass die Umstände es nicht zulassen, dass man eine neue Brandstrategie macht, das Interesse nicht mehr da war. 
Klar, das ist so grundsätzlich da. 
Dann halt nicht. Dann halt nicht, oder? Aber was in Ordnung ist. 
Da sind ja dann zum Teil doch auch rationelle Entscheide dahinter. 
Das andere, was ich oft erlebt, man bewertet natürlich als Projektleiter seine Pflicht. 
Der Job als Projektleiter ist ja die Dinge, die der Auftrag geben möchte, zu machen. 
Das heisst aber noch lange nicht, dass man sie dann wirklich tun muss. 
Im Idealfall schon, weil es dann Sankt kostet. Aber man muss auch akzeptieren, dass es größere strategische Umstände gibt, die das nicht mehr als lohnend sich herausstellen lassen. Auch wenn man dann herbeigeführt hat. 
Als Projektleiter hat man eine andere Sicht dann auf das. 

Mel:
[20:10] Also was ich immer krass finde, ist dieses, was ich vorhin schon mal angedeutet habe, dass man hingeht und sagt irgendwie, ich treffe bestimmte Annahmen und hinterfrage die dann nie wieder, also die gelten dann quasi als gesetzt und vielleicht auch, um so ein bisschen in die konstruktive Schiene einzubiegen, eine Thematik, die sich bei mir in der Vergangenheit bewährt hat, ist einfach, dass man gesagt hat, okay, wenn wir uns diese Annahmen jetzt noch mal vor Augen führen, welche von denen führen eigentlich zu welcher Auswirkung? 
Also ein klassischer Risikomanagement Einsatz, Eintrittswahrscheinlichkeit und Auswirkungen. 
Eintrittswahrscheinlichkeit kann ich wahrscheinlich in den meisten Fällen nicht vernünftig angeben, aber bei Auswirkungen habe ich eigentlich ein relativ gutes Gefühl dafür. Ist das jetzt was, was ein kompletter Showstopper ist, wo ich sage, Wenn das nicht eintritt, fliegt mir das Ding um die Ohren. 
Oder ist das was wo ja wenn das nicht? 

[21:00] Eintritt, dann kann ich damit irgendwie umgehen. Und ein Ansatz, der da aus meiner Sicht extrem erfolgsversprechend ist, ist bei der Abklärung, also, dass man Ressourcen zur Verfügung stellen muss, die die Annahmen abklopfen, das ist, glaube ich, jedem klar. 
Aber bei der Frage, in welcher Reihenfolge mache ich das und auch mit welcher Priorität im Vergleich zu den ganzen anderen Projektaufgaben, die ich habe, mit denen anzufangen, wo ich sage, da liegt ein potenzieller Showstopper drin. 
Einfach weil, wenn mir das Ding um die Ohren fliegt, dann ist wenigstens nicht so viel Geld weg. 
Also das kann ja passieren, dass aus welchen Gründen auch immer sich dann eine Prämisse eben nicht bewahrheitet. Und man gesagt hat, okay, ist halt so. 
Aber mal hinzugehen und diese Prämissen in Reihenfolge zu bringen und wirklich zu sagen, welchen bricht mir das Genick? 
Und mit denen dann mal anzufangen und zu erhärten, läuft das oder läuft das nicht? Ich meine, so macht man es in der wissenschaftlichen Arbeit ja auch. 
Am Anfang die Forschungshypothese, dann machst du irgendwie ganz viele Späße drumherum und am Ende sagst du, hat jetzt meine Forschungshypothese gehalten oder nicht. 

Fabian:
[22:00] Also ich glaube, das ist genau korrekt, weil das ja heißt, du musst die Prämissen besser verstehen und was steht wirklich dahinter. Ich glaube, ich habe einfach schon oft erlebt, dass genau, also ich glaube, das ist auch die Challenge als Projektleiter. 
Du müsstest ja eigentlich alles verstehen, was dein Projekt betrifft, aber kannst du eigentlich nie. Also ist zu viel, oder? 
Und ich habe so den Eindruck, dass das eine Haltung, die du dann haben kannst, ist, okay, dann ignoriere ich einfach alles, was ausserhalb von meinem Projektsystemgrenze ist, oder? 
Und das kann man machen, weil aus einer Verantwortungsperspektive, aus einer Governance Perspektive ist es genau so und das hat gar nichts mit der Methode oder wenn du ein agiles Projekt hast, hast du einen Leuchtturm. 
Es kann aber sein, dass der Leuchtturm wirklich am falschen Ort steht, oder? 
Aber das ist aus meiner Sicht zulässig als Projektleiter zu sagen, es war nicht meine Aufgabe, kann ich nicht stemmen, oder? 
Gleichzeitig, was du aber tun kannst, ist… 
Das Setting der Ghosts auswählen und trotzdem versuchen zu verstehen, wie sinnvoll und stabil dieses Setting, das du entweder mitgeschaffen hast oder gegeben bekommen hast, sein kann. 

Schwierigkeiten bei der Einschätzung des Projektausgangs

[23:25] Ich glaube, es ist sicher einer der schwierigsten Vorgänge, wenn du sagen musst, das wird wohl nichts. 

Mel:
[23:32] Ich glaube, es ist massiv abhängig von der Time-to-Market, die du hast, um es mal so zu nennen. 
Also von der Laufzeit deines Projektes und der Frage, wie viel Zeit geht eigentlich ins Land, bis du geklärt haben kannst, ob deine Prämisse hält oder nicht. 
Also wenn ich mir ein Projekt vorstelle, das ein halbes Jahr geht oder wegen mir ein Jahr, da würde ich behaupten, da kann gar nicht so viel schief gehen, weil da habe ich eigentlich relativ guten Überblick über diese ganzen externen Faktoren, die du auch angesprochen hast. 
Je länger mein Projekt läuft, umso mehr Platten-Tektonik habe ich einfach in der Zeit und umso mehr Themen können einfach auftreten, die ich nicht kontrollieren oder händeln kann. 
Und ich glaube, das muss man sich einfach auch nochmal vor Augen führen, dass je länger so ein Projekt läuft, umso wichtiger ist es, zyklisch über die Prämissen drüber zu gehen und zu gucken, mit welchen Annahmen bin ich hier unterwegs. 
Unterwegs. Die sind ja auch nicht statisch. Also ist ja jetzt auch nicht so, dass ich am Anfang von meinem Projekt sage, die fünf sind es und die bleiben dann, sondern irgendeine ist dann mal nicht mehr relevant und dafür kommt aber irgendwas Neues dazu, was ich vorher nicht gesehen habe. 
Und so komme ich ja dann vom einen zum anderen. 

Fabian:
[24:33] Ja, und das ist wirklich übertragbar. Ich meine, wenn du ein Projekt hast, was wirklich eher ein klares Produkt mit klaren Kunden hast, dann kennen wir alle die Methoden. Du sagst, ich mache minimal viable products. 
Ich gehe so früh. Ich gehe mit was zusammengebastelt früh wie möglich zu einem Kunden. 
Aber das ist aus meiner Erfahrung auch in anderen Kontexten genauso möglich. 
Das heisst, du gehst eben so früh wie möglich zu den Stakeholdern mit ersten Ideen, mit ersten Entwürfen und suchst eben die Diskussion. 

Die Kunst des Dialogs im Projektmanagement

[25:06] Da gibt es ja wirklich gegen Reflex. Es gibt Leute, die möchten etwas fertig machen und dann erst zeigen, dass es möglich gut aussieht. 
Da bin ich in meiner Erfahrung ganz stark davon überzeugt, dass es viel besser ist, dauernd den Dialog zu suchen. 
Das ist dann die Kunst, wie viel Energie investierst du da, aber ich glaube, du kannst fast nicht zu viel investieren als Projektleiter. 
Es kann auch nur schon heissen, wie du mit deinen Gremien, mit deinen Lenkungsausschüssen oder was auch immer du hast in deinem PI-Review oder wenn wir jetzt im Agilumfeld sind, wie du mit den Leuten sprichst und auch schaust. 
Ja, ich habe so einen Credo, ich denke, ein Projektleiter, das ist auch wieder mit ganz simplen Worten, der muss schauen, dass er mit denen Leuten sprechen kann, die eben denken und entscheiden. 
Oft kannst du in Organisationen sein, wo es dann noch zig Ansprechpartner haben, die weder wirklich bereit sind zu denken oder den Auftrag zuzuhaben oder entscheiden können und du Du musst halt schon schauen, dass du mit den Leuten, die im Denken und Entscheiden im Dialog sein kannst und möglichst früh Entwicklungen im Projekt testen kannst im Prinzip. 

Frühzeitige Entwicklungstests und die Möglichkeit zum Pivotieren

[26:26] Und dann kannst du pivotieren. 

Umstände, die Prämissen irrelevant machen

[26:31] Wenn es dann noch fundamentellere Veränderungen gibt, dann muss man dann irgendwann anerkennen, sind es einfach auch Umstände, die dann da zuführen, dass deine Prämissen ganz nichtig werden. 
Muss man halt auch analytisch einen On-Stop rechnen, das kann immer passieren. 
Es gibt kein Geschäft auf der Welt, das hundertprozentig stabil ist. 

Mel:
[26:54] Ja, aber ich glaube, du kannst dich wirklich auf die meisten Sachen relativ gut vorbereiten. 
Was, glaube ich, eine sinnvolle Übung ist, ist, wenn man jetzt in diese Prämotem-Methoden zum Beispiel reingeht und einfach sagt, spulen wir die Zeit gedanklich mal vor, das Projekt ist gescheitert, woran hattet ihr Lehen, dass ich dann einfach überlege, was sind denn für Themen gekommen oder dass ich mir auch im Team einfach mal Gedanken mache, lasst doch mal vom vom absoluten Worst Case ausgehen. 
Und bei all meinen Annahmen tritt das genaue Gegenteil ein von dem, was ich mal angenommen habe. Was wäre jetzt eigentlich ein Thema und was wäre kein Thema? 
Und dann weiß ich eigentlich relativ schnell und ohne jetzt riesige Aufwände und ohne große Abklärung, wo ich jetzt noch mal reininvestieren muss und und Mitigationsmaßnahmen finde und wo ich einfach sagen so. 
Ja, okay, ist jetzt toll, dass wir diese diese Annahme getroffen haben. 
Und ich glaube, das ist wirklich etwas, was man zyklisch machen sollte. 

Fabian:
[27:44] Was auch noch eine Hands-on-Methode ist, wenn man als Projektleiter, das versteht man je nachdem technisch nicht alles und so weiter, Wirklich die Kritiker. 
Von mir aus auch, sie dürfen sogar etwas Persönliches und Negatives sein, denen wirklich zuhören. Das ist banal, aber du musst dann das abstrahieren, oder? 
Es kann auch sein, dass da irgendeine Absicht dahinter ist und so weiter. 
Ich sage das zum Teil den Kritikern des Projekts auch direkt und sage, du bist mein bester Risikomanager. 
Vor allem, wenn sie noch, sagen wir mal… 

Mel:
[28:25] Irgendwo kommt es ja her. 

Fabian:
[28:26] Ja, genau, es kommt eben irgendwo her und vor allem, wenn sie auch nicht eine Interessensbindung haben an dich, ist es am besten, weil sie dann einfach sagen, was sie sonst hören oder was sie analytisch wirklich denken. 
Ich glaube, gerade bei den Annahmen, das hast du vorhin schon gesagt, oder diese Legende oder so, da muss man mega aufpassen, dass man nicht eine Bubble kreiert, wo dann analytisch korrekte, aber kritische Punkte nicht mehr so stattfinden. 
Ich glaube, dem kann man fast nicht aus- Der Mensch funktioniert so, oder? 
Man möchte, dass das, was wo ich jetzt dran bin, das ist sicher richtig und sicher wichtig und korrekt, oder? 
Aber es kann einfach so sein, dass man, ja dass das falsch ist und da sind die Kritiker doch eben die besten Risikomanager, oder? Am dummsten ist es eigentlich, wenn es einem egal ist, was man macht. 

Mel:
[29:15] Dann hast du andere Probleme. 

Fabian:
[29:17] Ja, genau. 

Mel:
[29:17] Also vielleicht noch ein Gedanke. Ich glaube, wichtig ist an der Stelle auch, dass man den Prämissen vor allen Dingen bewusst ist, also die auch aufschreiben. 
Wir hatten in der letzten Folge ja zum Beispiel mal über das Projekthandbuch geschrieben. 
Ich glaube, das ist ein guter Ort, um einfach zyklisch mal drauf zu gucken, weil wir müssen bei Prämissen natürlich auch davon ausgehen, eine ganze Reihe können wir, du hast es das Ganze am Anfang gesagt, können wir explizit machen. Da können wir einfach sagen, wir gehen von dem und dem aus und das wissen wir. 
Und wir haben aber auch einfach implizite Annahmen und Prämissen getroffen, denen wir uns einfach an der Stelle so nicht bewusst sind. 
Und die alleine stellen ja schon ein Risiko dar, dass ich irgendwelche Annahmen habe, von denen ich gar nicht weiss, dass ich sie habe und die fliegen mir um die Ohren, dann sollte ich zumindest versuchen, bei denen, die ich kenne und denen ich mir bewusst bin, die so zu steuern, dass mir da nichts passiert. 

Fabian:
[30:04] Das ist doch ein guter Schlusssatz, da kann ich voll dahinter stehen. 
Vielleicht muss man dann das Wort Prämisse noch ändern, weil die sind ja prä, vielleicht sind es dann nur noch missen. 

Mel:
[30:19] Gibt es sowas wie Postmissen? 

Fabian:
[30:22] Postmissen sind auf jeden Fall schöne Wortkreationen, die wir im Angebot haben. 
Annahmen ist weniger Prä, du hast immer Annahmen. 

Mel:
[30:31] Okay, wir hoffen ihr hattet Spass, konntet was mitnehmen, überprüft bis zur nächsten Folge eure Prämissen. Wie immer freuen wir uns auf Feedback, managementbyprojects.com slash community, hinterlasst da gerne einen Kommentar. 
Und ansonsten wünschen wir euch alles Gute, bis demnächst, ciao! 

Fabian:
[30:46] Macht’s gut!