Einfach Projekte

Warum eure Projekte nicht steuerbar sind

• Jörg Tausendfreund

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 46:09

Wenn Projekte rennen und doch nichts fertig wird, fehlt selten die nächste Methode – es fehlt das Betriebssystem. Wir zeigen, wie ein minimalistisches Project Operating System aus klaren Regeln, schlanken Artefakten und kurzen Routinen echte Steuerung erzeugt: Entscheidungen fließen, Arbeit wird sichtbar, Risiken werden getestet und Ergebnisse liefern Wirkung. Ohne Folklore, ohne Tool-Zirkus, mit Fokus auf Transparenz, Entscheidbarkeit und Flow.

Wir starten mit fünf First-Principles, die jedes erfolgreiche Projekt prägen: Wertlieferung unter Unsicherheit, messbarer Erfolg für echte Trade-offs, Entscheidungen als Engpass, Feedback vor Prognose und sichtbare Arbeit statt Parallel-Hektik. Daraus leiten wir ein Setup ab, das in mittelständischen Realitäten genauso trägt wie in großen Programmen: ein einseitiger Project Brief mit Zweck, Outcome, Constraints, Nichtzielen, Top-Annahmen und Definition of Done, ein One Board als Single Source of Truth von rechts nach links gesteuert, knappe Decision Rights plus hartes Decision Log, Annahmen und Risiken als Reduktionsmaschine der Unsicherheit sowie ein Fünfzahlen-Dashboard, dessen Ampeln Konsequenzen statt Farben haben.

Damit das keine Theorie bleibt, bekommst du drei Routinen, die Meetings von Zeitfressern zu Steuerungswerkzeugen machen: das Weekly Heartbeat für Blocker und Flow, ein Review mit echten Demos für schnelles Feedback, sowie ein monatliches Steering mit Sponsor für klare Entscheidungen und Ressourcenschutz. Zusätzlich liefern wir einen Zehn-Tage-Plan für den Start und eine präzise Sprache „nach oben“: kein Methoden-, sondern ein Steuerungsproblem; wir setzen Brief, Board, Decision Log, Fünfzahlen-Dashboard und drei Routinen auf; dafür brauchen wir Entscheidungsrechte und einen monatlichen Decision-Slot.

Du suchst weniger Status und mehr Steuerung, weniger Heldentum und mehr System? Starte hier, sichere Transparenz, Entscheidungen und Flow – und bringe Arbeit verlässlich ins Ziel. Wenn dir diese Folge hilft, abonniere den Podcast, teile ihn mit deinem Team und sag uns: Welche Entscheidung braucht dein Projekt diese Woche?

Die 5 Prinzipien im Podcast 

  1. Projekte sind Wertlieferung unter Unsicherheit.
  2. Erfolg ist definiert und messbar (Outcome + Constraints + DoD).
  3. Entscheidungen sind der Engpass.
  4. Feedback schlägt Prognose.
  5. Transparenz & Flow sind Steuerung (Fertigstellen vor Starten).


Die 12 First Principles (vollständig)

  1. Wertlieferung unter Unsicherheit
  2. Erfolg ist definiert und messbar
  3. Trade-offs sind unvermeidbar
  4. Entscheidungen sind der Engpass
  5. Feedback schlägt Prognose
  6. Transparenz ist Steuerung
  7. Engpässe bestimmen die Durchlaufzeit
  8. Qualität ist ein System
  9. Kommunikation ist die Arbeit
  10. Motivation folgt Sinn, Autonomie, Fortschritt
  11. Scope braucht ein Priorisierungssystem
  12. Risiken sind ungetestete Annahmen 

Mini‑Selbstcheck (2 Minuten)

  • 1 Seite Klarheit – oder Folien?
  • 1 Wahrheit – oder Tool‑Zoo?
  • Entscheidungen mit Frist – oder per Schweigen?
  • Tests/Signale für Annahmen – oder Hoffnung?
  • Flow – oder 100% Auslastung & nichts Done?

Hol dir doch einfach den Project OS v1 - One-Pager
https://stan.store/einfachprojekte/p/project-os-v1

Bist du interessiert an mehr Informationen zu erfolgreicher Projektarbeit? Hier findest Du mehr: https://www.einfachprojekte.de

Im Blog findest Du regelmäßig neue Beiträge, kompakt und auf den Punkt: 

https://www.1000freund.net/blog

Deine persönliche Projektleitungskompetenz ist das A und O. Teste Deine doch einfach mal hier:

Schick mir gerne Deine Nachricht...

SPEAKER_00:

Hey, ganz ernsthafte Frage. Wie oft habt ihr im Projekt alles? Plan, Tool, Geoffix, Status und trotzdem fühlt es sich an, wir laufen, aber wir liefern nicht. Dann fehlt euch sehr wahrscheinlich nicht die nächste Methode, dann fehlt euch das sogenannte Betriebssystem. Also die Mechanik, die Klarheit, Entscheidung, Feedback und Lieferfähigkeit zuverlässig macht. Heute bekommst du einen Diagnoseblick, der vielleicht wehtut, aber wirkt. Und du bekommst ein minimalistisches Setup, das du in 10 Tagen starten könntest, damit Projekte nicht nur laufen, sondern liefern. Sei dabei. Herzlich willkommen bei Einfach Projekte. Mein Name ist Jörg Tausendfreund und du kannst hier für deine Projektarbeit Strategien, Ansätze und Tipps bekommen. Vor allem immer im Klartext gesprochen. Und für dich, damit du direkt was damit anfangen kannst. Sei einfach dabei. Ja, hey, und wieder einmal herzlich willkommen bei Einfach Projekte. Und ich bin hier wieder im virtuellen Project Office. Und heute geht's um ein Wort, das erstmal irritieren kann, oder vielleicht mehrere Worte, die erstmal irritieren können, und zwar um das sogenannte Project Operating System. Project OS könnte man auch dazu sagen. Oder auf Deutsch das Betriebssystem für Projekte. Und jetzt nicht gleich abschalten, sondern jetzt direkt dranbleiben, weil das ist nicht Microsoft oder sonst irgendwas. Falls man da jetzt gleich dran denken würde. Nein, nein, nein, nein, nein. Und wir reden auch nicht über Windows oder sonst irgendwas, sondern wir reden über Regeln, Artefakte und Routinen, die ein Projekt steuerbar machen. Also was ganz Elementares im Prinzip. Und ich sag dir gleich, was diese Folge dir liefern kann, und zwar ganz konkret. Erstens, du kannst nach der Folge relativ schnell diagnostizieren, ob dein Projekt ein Betriebssystem hat oder eure Organisation ein Betriebssystem hat, oder eben nur Meetings und Hoffnungen. Zweitens, du bekommst Sprache, wie du Sponsor und Führung überzeugst. Aus der Perspektive, wir brauchen keine neue Methode, wir brauchen Entscheidbarkeit und Flow. Und drittens packe ich dir einen One-Pager und die Templates in die Shownotes, damit das direkt bei dir Wirkung entfalten kann. Und ja, Methodennamen dürfen natürlich auch weiterhin fallen. Also Scrum, Wasserfall und so weiter und so fort. Darum geht es gar nicht. Denn die These heute ist erstmal ganz simpel. Wenn die Mechanik fehlt, ist jede Methode nur Deko. Oder du könntest auch sagen, kann keine Methode richtig funktionieren. Dazu ein kurzer Satz, der sowas ähnliches wie eine Leitlinie für uns heute sein kann. Status ist Transparenz, Steuerung ist Transparenz plus Entscheidung plus Aktion. So, da so ähnlich wirst du das schon ganz, ganz häufig hier bei mir bei Einfach Projekte gehört haben und nichtsdestotrotz sind es eben einfach die Basics, die dazu führen, dass Projekte entweder laufen oder nicht. Der fancy Stuff, der fancy Scheiß unter uns, der ist es definitiv nicht. So, und ich nehme dich jetzt mit in das von mir so heiß geliebte Projekt Phönix. Das kennst du ja, das ist immer so dieses Beispielprojekt, damit ich keine Namen nennen muss. Und wieder mal, wie so oft, klassischer industrieller Mittelstand. Ein Projekt, das nicht Innovationstheater ist oder sonst irgendwas, sondern echte Lieferkette, echte Abhängigkeiten, echte Kundenwirkung. Und Montagmorgen ist Projektmeeting, der Projektplan ist da, das Tool ist da und der Status ist natürlich grün. Und trotzdem merkst du innerhalb von zehn Minuten, das Projekt ist nicht grün, es ist höchstens nicht offiziell rot. Und jetzt ist natürlich wieder wie immer die spannende Frage nach dem warum. Weil ganz typische Dinge passieren. Eine Entscheidung zur Schnittstelle hängt seit drei Wochen. Wer kennt das nicht? Dass Entscheidungen zur Schnittstelle bzw. eher zwischen den Schnittstellen hängen bleiben. Zwei Teams arbeiten parallel an wichtigen Themen. Keiner weiß, was zuerst fertig werden muss. Risiken stehen irgendwo in einem Dokument, aber niemand beschäftigt sich damit und testet sie möglicherweise aus. Und das meiste, was im Meeting gesagt wird, endet mit klären wir bilateral. Und bilateral ist Projekt Deutsch für das verschwindet in der Nebelmaschine. Und jetzt passiert das, was ich ständig sehe. Und du vielleicht auch. Die Projektleitung versucht, das System zu kompensieren. Sie telefoniert, sie erinnert, sie rettet, sie moderiert. Sie hält das Projekt grün mit persönlicher Energie. Und an der Stelle musst du dir einen Satz merken. Wenn dein Projekt nur läuft, weil die Projektleitung heldenhaft kompensiert, dann ist das kein Projektmanagement, dann ist das Schadensbegrenzung mit Kalenderfunktion. Und genau da kommt unser Begriff rein, das Project OS-Betriebssystem. Nicht als Buzzword, sondern als harte Diagnose, welche Mechanik fehlt uns gerade, sodass das Projekt nicht steuerbar ist. Und vielleicht muss ich da ein ganz kleines bisschen ausholen. Und zwar, ich habe mich in den letzten Wochen ziemlich intensiv mit der Frage nach den sogenannten First Principles beschäftigt. Vielleicht kennst du das. Anscheinend ist es wohl so, dass Elon Musk bei vielen Themen, die ihn beschäftigen oder mit denen er sich beschäftigt, nach den sogenannten First Principles schaut. Also sozusagen nach den Grundwahrheiten, die eben vielen anderen Dingen als ganz unabhängig vom Thema zugrunde liegen. Und ich habe dann mal gestöbert zum Thema Projektarbeit und habe insgesamt zwölf sogenannte First Principles zusammengetragen. Also diese Grundwahrheiten, die du in fast jedem erfolgreichen Projekt findest. Und ich zähle die dir jetzt nicht alle hier im Audio runter, weil das hilft eh nicht, wenn es irgendwie zu dicht wird und ich nur die Dinge aneinanderreihe. Ich packse dir aber auf jeden Fall super gerne in die Shownotes mit dazu. Und wenn du da ein bisschen mehr dazu haben willst, kannst du dich auch bei mir melden. Für uns verdichte ich das Ganze sozusagen auf fünf Sätze, mit denen wir hier und heute gut umgehen können. Also die du als Diagnoselinse im weitesten Sinne als Fernglas für dich, je nachdem, oder als Mikroskop, was auch immer für dich am geschicktesten ist, verwenden kannst. Erstens, Projekte sind Wertlieferung unter Unsicherheit. Und zwar, also Nichtabarbeitung eines Plans. Und das müssen wir uns vielleicht nochmal ganz kurz anschauen. Wertlieferung unter Unsicherheit, das sind ja zwei elementare Grundgedanken eines jeden Projektes. Also ein Projekt soll immer Wert oder Nutzen generieren, sonst würden wir es ja nicht machen. Und das zweite ist, ein Projekt, zumindest von seiner Grundannahme her, bewegt sich immer in einer gewissen Unsicherheit. Die Grundannahme im Projektmanagement ist ja, dass wir sagen, das, was wir hier machen, haben wir noch nie gemacht. Ergo muss es ja unsicher sein. Wenn du Dinge hast, die ihr schon mehrfach gemacht habt und so weiter und so fort, dann reduziert sich natürlich die Unsicherheit entsprechend. Du darfst es aber gerne auch weiterhin Projekt nennen. Zumindest wenn es eure Organisation so definiert. Ist ja auch ganz wichtig, wie definiert die eigene Organisation überhaupt den Begriff Projekt, aber das ist ein ganz anderes Thema. Zweitens, Erfolg muss definiert und messbar sein. Sonst gibt es eben keine echten Trade-offs. Und das ist auch ganz wichtig. Also erstens, du musst den Erfolg natürlich klar definiert haben, also auch im Sinne von was ist unser Ziel. Und du musst das Ganze irgendwie messbar gestalten. Weil nur, wenn du das hast, jetzt kommen wir zum Thema Trade-Off, können wir auch echte Abwägungen treffen. Also wenn wir halt kein Ziel haben und wir stoßen im Projekt an irgendwelche Unwägbarkeiten oder wie auch immer, naja, dann passen wir halt unser Ziel dementsprechend an die Unwägbarkeit an. Kann auch ein Ergebnis sein, aber eigentlich geht es ja eher darum, dass wir ein Ziel haben und dass wir versuchen, an den Unwägbarkeiten vorbei das Ziel zu erreichen. Und da musst du halt manchmal gewisse Dinge auch hinter dir lassen oder gewisse Dinge anders machen. Da sind wir wieder im magischen Dreieck, Qualität, Zeit und Kosten. Trade-offs kannst du nur dann auch richtig beschreiben, wenn du halt dieses definierte und messbare Ziel hast. Also das ist nur zweitens. Unser drittens ist, Entscheidungen sind der Engpass, nicht To-Dos. Das ist auch ganz wichtig. Also ganz häufig sind im Projekt nicht die Arbeiten, die abgearbeitet werden müssen, der eigentliche Engpass, es kommt uns nur so vor. Es sind die Entscheidungen. Also ein ganz einfache Bild ist hier, wenn eine bestimmte Person ihre To-Dos nicht abarbeitet fürs Projekt, dann ist es ganz einfach, auf diese Person zu schauen und zu sagen, naja, also kriegt halt die To-Dos nicht auf die Reihe. Vielleicht ist davor eher eine Entscheidung, die sagen sollte, die Linienführung zum Beispiel allokiert jetzt diese Ressource ganz stark aufs Projekt und nimmt sie aus dem Tagesgeschäft raus und plötzlich können To-Dos abgearbeitet werden. Also es sind eben ganz häufig Entscheidungen, die im Projekt deenbar sind und eben nicht das Abarbeiten oder die Menschen. Du musst eben dann schauen, wie die Ressourcen dementsprechend allokiert werden. Viertens, Feedback schlägt Prognose. Je unsicherer, desto wichtiger sind echte Reviews, Tests und Demos. Auch wieder ganz klar. Also wieder ein Projekt ist etwas sehr Unsicheres. Und eine Prognose ist ein Blick in die Zukunft. Und ein Feedback ist eine Rückschau auf etwas, das wir getan haben. Wovon haben wir mehr? Natürlich vom Feedback. Das heißt, wir brauchen halt Reviews, Tests und Demos und vielleicht dann auch manchmal dieses Minimal Viable Product und so weiter und so fort, um eben tatsächlich das Projekt nach vorne bringen zu können. Also einen relativ schnellen Prototypen, an dem wir dann weiterdenken können und und und und und. Und fünftens, Transparenz und Flow sind Steuerung. Also wenn Arbeit unsichtbar ist oder überall parallel läuft, dann wird ganz häufig nichts fertig. Also Arbeit muss sichtbar gemacht werden, damit wir eben tatsächlich auch steuern können. Und jetzt kommt der entscheidende Übergang. Wenn du diese fünf Sätze nimmst, dann brauchst du nicht 17 neue Meetings, könnte man ja annehmen. Du brauchst ein Betriebssystem oder eine Vorgehensweise, also nenn es wie du magst, dass genau diese Dinge dauerhaft absichert. Und das ist der entscheidende Punkt. Dass diese Dinge dauerhaft funktionieren. Und deswegen darf man es gerne auch Betriebssystem nennen. Und was ein solches Project Operating System nun liefert oder ist oder was nicht, das möchte ich gerne mit dir mal gemeinsam anschauen. Ein Project Operating System ist das kleinste Set an Regeln, an Artefakten und Routinen, die ein Projekt zuverlässig steuert. Nicht die Methode, sondern die Mechanik, die Zusammenarbeit unter Unsicherheit möglich macht. Nochmal ganz wichtig. Also im Zweifelsfall wird immer eine neue Methode drauf geworfen oder wir brauchen eine Software oder sonst irgendwas. Wenn das System, das Operating System nicht funktioniert, dann ist jede Methode, die du drauf wirfst, Grütze. Sorry. Und dieses Operating System löst im Prinzip vier Daueraufgaben, die du immer im Projekt hast. Das erste ist Alignment. Also wozu tun wir das und woran messen wir Erfolg? Also dass wir eben aligned sind, dass wir eben alle quasi auf derselben Spur unterwegs sind und dass wir alle dieselbe Sichtweise einnehmen können. Und wozu tun wir das? Macht darüber hinaus ja noch total viel Sinn, weil es halt eben auch Sinn aufbaut. Zweitens, Entscheidungen. Was gilt? Wer entscheidet was bis wann? Elementar, auch da wieder, sollte eigentlich in keiner Projektumgebung fehlen. Realität fehlt in ganz vielen Projektumgebungen. Also was ist eine gültige Entscheidung und wer entscheidet was bis wann? Dass du auch dementsprechend eben den Flow im Projekt, den Verlauf der Arbeit absichern kannst. Das dritte ist lernen. Also was stimmt wirklich, welche Annahmen sind bestätigt oder widerlegt, also Lernen im Projekt. Vorhin waren wir so bei den Prognosen. Beim Projekt ist ja viel Arbeiten mit Hypothesen erstmal, weil wir ja in die Zukunft schauen. Und dann eben zu schauen, okay, was stimmt, welche Annahmen sind bestätigt oder welche Annahmen haben sich als nicht hilfreich oder, wenn du so willst, richtig erwiesen. Wobei, ob richtig oder falsch geht es ja nie. Und das vierte ist Lieferung. Also, was wird als nächstes fertig und was blockiert den Flow? Das ist natürlich auch wieder elementar. Wir wollen ja so schnell wie möglich und so viel wie möglich Lieferung haben. Auf der einen Seite müssen wir halt wissen, was fertig wird. Eventuell gibt es da Abhängigkeiten, die berücksichtigt werden müssen oder neue Dinge, die angestoßen werden müssen und, und, und, und, und. Und wo hängt vielleicht irgendwas, das, wenn es fertig wäre, auch wieder dazu führen würde, dass es insgesamt im Projekt weitergehen kann. Und hier ist die, wenn du so willst, Designregel, die ich mega finde. Wenn ein Element nicht direkt ein First Principle unterstützt, Klarheit, Trade-offs, Entscheidungen, Feedback, Transparenz, Qualität, dann gehört es nicht in ein solches minimalistisches Betriebssystem, wenn du so willst. Und das ist der Moment, wo Projektmanagement halt aufhört, ein Bürokratiemonster zu werden oder zu sein, weil du plötzlich eine harte Leitplanke hast. Hilft das der Steuerung oder ist es Beschäftigung? Und das ist ja elementar. Wie oft beschäftigen wir uns im Projekt mit administrativen oder bürokratischen Dingen, die halt null Sinn machen? Warum füllst du das aus? Keine Ahnung, macht mal bei uns halt so. Übrigens, ich habe, also ich sage damit überhaupt nicht, dass Dinge nicht ausgefüllt werden sollen oder dass nicht reportet werden soll oder was auch immer. Weit weg davon. Ich bin ja für Transparenz. Aber man muss eben einfach schauen, was macht Sinn und was bringt uns voran. Und lass uns mal ein bisschen stärker sozusagen in dieses Operating System aus so einer Version 1 oder 0.9 Perspektive reinschauen und darauf gucken, was so fünf Artefakte sein könnten, um die es uns hier gehen sollte oder die wir im Prinzip haben sollten. Und Artefakt Nummer 1 wäre der Project Brief oder der Projekt Steckbrief oder also wie auch immer das bei euch heißen soll. Also eine Seite Klarheit wäre so meine Perspektive darauf. Und das bedeutet, also was ist der Zweck? Ein gemeinsames Verständnis von Zweck, Sinn, Erfolg, Constraints, Nichtzielen plus die Top-Annahmen, also Prognosen und Risiken, sowie eine Definition of Done. Also ganz elementar mal aufs Projekt geschaut und da wäre eine Diagnosefrage, die du reinwerfen kannst. Also haben wir diese Seite wirklich oder haben wir 30 Folien, aber niemand kann in einem Satz sagen, was Erfolg ist. Und ich meine, das ist schon auch klar. Manchmal braucht es auch zwei Sätze und noch einen Strichpunkt oder sonst irgendwas. Aber also das Ganze kompakt runterbrechen zu können, das sollte für jedes Projekt möglich sein. Ansonsten habt ihr eventuell ein anderes Problem. Und quasi der Merksatz zum Nachsprechen aus Projektleitungssicht wäre hier, bevor wir planen, bevor wir planen, woran messen wir Erfolg und was sind unsere harten Constraints? Ganz einfache Frage. Und aus Sicht der Führung müsste dann ein Satz dementsprechend lauten, wenn wir Outcome nicht. Operationalisieren, entscheiden wir später politisch statt fachlich. Und das ist ja nochmal total relevant, weil wie oft hast du das in deinen eigenen Projekten vielleicht sogar schon erlebt, dass dann halt politische Entscheidungen im Projektverlauf getroffen werden, anstatt die fachlich sinnvollen. Und dann fragt man sich wieder, wo sind wir gerade im Moment? Und hat vielleicht auch gar keinen Bock mehr, am Projekt weiterzuarbeiten. Deshalb gerne und direkt weiter zum Artefakt Nummer 2. Und man könnte jetzt sagen, das ist das One Board. Oder vielleicht auch eine Wahrheit, oder wenn du es Englisch willst, eine Single Source of Truth. Also quasi einen Platz oder eine Quelle der Wahrheit. Das bedeutet halt erstmal, dass wir nicht irgendwie Projektdaten an unterschiedlichen Orten zusammenführen. Weil dann hast du wieder unterschiedliche Stände und so weiter und so fort. Und ganz, ganz minimal könnte so etwas sein wie Next, Doing, Blocked und Done. Da sind wir so in so einer Kannbahn-Boardhaften Perspektive. Jede Karte hat einen Owner-Akzeptanzkriterien und ein Review-Datum. Und vielleicht haben wir dann noch ein Work-In Progress Limit festgelegt fürs Doing. Das kann ja durchaus Sinn machen, um Ressourcen dementsprechend zu schonen oder wie auch immer. Aber ganz viele Projekte kannst du auf die Art und Weise schon ganz gut einsteuern. Da braucht es gar keine komplexen Systematiken. Es gibt Raum für komplexe Systematiken, bin ich schon mit dabei. Aber so eine One-Boot-Perspektive, die ist an vielen Stellen schon mega hilfreich. Und jetzt kommt ein Detail, das halt ganz viele falsch machen. Das Board wird nicht von links nach rechts verwaltet. Es wird von rechts nach links gesteuert. Das heißt, dann Blocker, also dann Blocker und was muss als nächstes fertig werden? Das ist im Prinzip ja das Spannende. Also vielleicht eher so die Perspektive des Ziehens anstatt des Drückens könnte man hier auch nehmen. Warum? Weil Fertigstellung ja unsere eigentliche Währung ist und nicht das Starten. Kleiner Unterschied, große Wirkung. Und wenn du eine Diagnosefrage dazu haben wollen würdest, dann wäre die wie folgt. Gibt es Arbeit außerhalb des Boards in Köpfen, Chats, Nebenlisten? Und wenn ja, habt ihr nicht ein Board, sondern ihr habt irgendwie ein Alibi-Bord. Was natürlich schon wieder gar keinen Sinn macht. Satz zum Nachsprechen aus dieser Perspektive. Zeigt mir, was diese Woche wirklich dann wird, nicht was wir anfangen. Also, das wäre wieder so diese Projektleitungsperspektive, damit du dein Projekt am Laufen hält. Es gibt sogar einen simplen Zusammenhang aus der Warteschlangen-Theorie. So was gibt es. Warteschlangen-Theorie. Wenn du mehr gleichzeitig offen hast, dauert alles länger. Nicht, weil Menschen dümmer werden, sondern weil Systeme dann in sich stauen. Und genau das ist halt auch der Grund, warum diese WIP-Limits, die Work in Progress Limits, so gut funktionieren. Kann man sich vielleicht merken. Artefakt Nummer 3 sind die Decision Rights und das Decision Log. Also die Entscheidungsrechte und das Entscheidungstagebuch, wenn du so willst. Also wer entscheidet typische Dinge? Und da sind wir dann bei Scope, Budget, Termin, Architektur, Priorisierung. Und wo dokumentieren wir Entscheidungen als gemeinsames Gedächtnis? Übrigens ist es nicht das gleiche Wort wie oben, ne? Also nicht verwechseln. Entscheidungen ist hier das Wort. Wichtig, das Log ist nicht schön, sondern hart. Also Datum, Entscheidung, Kriterien, Entscheider, Konsequenzen und Follow-Ups. Eine Zeile reicht da. Vielleicht brauchst du manchmal ein bisschen Platz. Aber so muss es sein. Also mehr brauchst du nicht. Und quasi wieder so als diagnostische Frage, wenn wir das Ganze untersuchen, wir wollen ja dir auch was an die Hand geben, damit du deine Projekte, dein Projekt und dein Projektumgebung untersuchen kannst. Sind Entscheidungen klar? Oder passieren sie per Schweigen? Weil wenn keiner widerspricht, ist eine Entscheidung auch getroffen, aber gegebenenfalls eine verdammt teure. Und da wäre der Schlüsselsatz, welche Entscheidung brauchen wir heute und wer entscheidet bis wann? Und vielleicht ist auch, welche Entscheidung brauchen wir morgen und wer entscheidet bis wann. Aber immer zu gucken, wo hängen gerade Dinge fest, weil eben nicht entschieden wird. Also so kannst du ganz, ganz viele Engpässe im Projekt einfach auch auflösen, wenn du Entscheidungen einforderst. Also wir haben, was haben wir denn jetzt schon? Wir haben den Project Brief als erstes Artefakt. Dann haben wir das One Board, also die Single Source of Truth. Dann haben wir die Decision Rights und das Decision Log und dann fehlen uns im Prinzip noch zwei Artefakte. Das vierte wäre Assumptions and Risks, also Annahmen und Risiken. Aber eben nicht als Ablage, sondern als Reduktionsmaschine für Unsicherheit. So könnte man das nennen. Vielleicht die Top Ten, jeweils mit Test, Validierungsschritt, Signal, Trigger, Plan B und Owner. Wenn du willst, dann eben, also tatsächlich nicht nur die Top Ten aufgeführt, sondern die noch entsprechend kategorisiert und priorisiert. Wichtig ist halt hier, dass die Frage, die wir uns stellen, in die Richtung geht, sind Risiken bei uns Text oder haben sie eine nächste Aktion? Und das ist ja das Entscheidende. Also wie oft werden Risiko-Sessions oder Workshops gemacht und Risiken werden aufgepinselt, aber es ist keine Aktion dahinter. Und eine Aktion kann natürlich auch sein, keine Aktion. Aber dann muss eben dementsprechend, wie gesagt, vereinbart werden, wann testen wir diese Annahme oder wann validieren wir das oder wie auch immer. Also du kannst ein Risiko nicht einfach nur unbesprochen stehen lassen. Und der Satz wäre hier, also der Schlüsselsatz wäre halt hier, welche Annahme tragen wir gerade als Wahrheit und wie testen wir die bis nächste Woche? Weil, also diese Annahmen, die wir da treffen, in der Unsicherheit, die müssen wir auch irgendwie austesten. Und wenn das quasi, wenn es das nicht testenswert ist oder wie auch immer, dann ist vielleicht auch das Risiko nicht das Richtige. Muss man sich eben auch wieder anschauen. Und möglicherweise brauchst du gar keine Top 10. Reicht auch auch, wenn du Top 5 hast. Aber die müssen dann halt gut gedacht sein. Also nimm das nicht, als wir brauchen immer die Top 10. Manchmal muss man auswählen und dann ist es gar nicht so leicht, auf 10 zu reduzieren. Kommt eben ganz stark auf dein Projekt an. Und damit sind wir schon beim fünften Artefakt. Und das wäre dann so was ähnliches wie ein, naja, wenn du so willst, wie so ein Fünfzahlen-Dashboard. Und da geht es jetzt nicht irgendwie um eine KPI-Schlacht, KPI Key Performance Indicators, sondern es geht um bewusste und robuste Signale. Also quasi so ein Outcome-Indicator, Milestone Status, dazu musst du halt auch mal Einsteine beschrieben haben. Den Flow, also dann pro Woche oder Lead Time, je nachdem, was bei euch mehr Sinn macht. Qualität und Risikostatus im weitesten Sinne, also wie viele Top oder wie viele heiße Risiken haben wir gerade im Moment. Und da gibt es eine goldene Regel. Also, wenn eine Zahl gelb oder rot ist, dann definierst du die nächste Entscheidung oder das nächste Experiment. Weil sonst ist ein Dashboard nur Beschäftigung, Schrägstrich, Beruhigung. Also die diagnostische Frage an der Stelle wäre halt, haben eure Ampeln Konsequenzen oder nur Farben? Und der Satz zum Nachsprechen an der Stelle: Gelb bzw. Rot heißt nicht diskutieren, sondern gelb bzw. rot heißt Entscheidung oder Test bis wann. Jetzt kommt übrigens noch der Teil, der ganz viele triggert. Triggered. Und zwar, ja, ein solches Operating System hat Meetings. Aber eben nicht als Folklore-Veranstaltung, sondern als Steuerungsroutinen. Und das ist der Unterschied. Und diesen Satz liebe ich, wenn ein Meeting nicht zu Entscheidungen oder entblockter Arbeit führt, ist es zu lang oder falsch geschnitten. Dann sind die falschen Menschen da, die falschen Themen werden gesprochen oder, oder, oder. Also wie oft hocken wir uns so zusammen und am Ende des Meetings ist nichts rausgekommen. Es gibt ja eine Grundregel für Meetings überhaupt. Kein Meeting ohne Entscheidungen, also kein Meeting ohne To-Do-Liste. Warum sollten wir uns sonst treffen? Also die Dinge können auch anders ausgetauscht werden. Da machst du ein Video oder schreibst eine Notiz oder sonst irgendwas. Meetings sind dazu da, um Dinge abzustimmen. Und im Prinzip reichen theoretisch drei Meetings oder drei Meeting-Routinen, wenn du so willst, aus. Also das erste wäre, ich mache es jetzt mal wieder Englisch, wäre so das Weekly Team Heartbeat Meeting. Was bedeutet das? Naja, wir müssen halt einfach mal kurz den Puls fühlen, sozusagen. Also die Agenda ist kurz aufs Dashboard zu schauen, dann Board von rechts nach links, das haben wir gerade eben schon vorbesprochen. Blocker und Entscheidungen sich klar zu machen, die Top-Risiken anzuschauen. Und am Ende wären dann, also sozusagen im Sinn von Output wären dann Endblocker-Aktionen und Decision-Log-Updates. Und damit haben wir alle wieder gut auf Spur und gut auf Kurs. Das, keine Ahnung. Also weekly oder je nachdem, wie es halt Sinn macht. Aber so ein Meeting dauert 30 Minuten, maximal 45. Und dann sind alle schon wieder am Arbeiten. So eine zweite Routine, über die man einfach mal nachdenken kann, wäre dann ein Review-Meeting oder ein Demo-Meeting. Das könnte, je nachdem, wie euer Projektverlauf ist, alle zwei Wochen stattfinden. Und du zeigst halt, also was gerade dann ist. Nicht irgendwie ein PowerPoint-Status, sondern tatsächlich, also wo stehen wir gerade im Moment. Kann natürlich per PowerPoint gezeigt werden, aber du weißt schon, nicht irgendwie eine komische PowerPoint-Schlacht, die eh keiner sehen will und die auch viel zu viel Zeit in der Vorbereitung kostet. Und du holst Feedback ein, besprichst Prioritäten und Trade-offs und holst dir dazu Entscheidungen. Und genau das ist im Mittelstand ja oft ein Game Changer. Also nicht weil ihr irgendwie agil sein müsst, sondern weil Feedback ja dann echte Realität ist. Und da müssen halt die dementsprechenden Personen auch dabei sein, also die mit diesem Feedback dann auch, also dieses Feedback geben können, die aber dann auch mit diesem Feedback was anfangen können. Und die dritte Routine, das wäre so ein Steering oder Sponsor-Meeting, das kann man einmal im Monat machen. Oder je nachdem, was ihr für ein Projekt habt, auch gegebenenfalls in einem größeren Zeitraum. Kommt so ein bisschen drauf an. Da hätten wir dann das Dashboard. Und dann eben ein Briefing relativ zum Outcome und den Constraints. Da kriegen wir Top-Entscheidungen, wir besprechen die Top-Risiken und lassen uns die dann auch dementsprechend entscheiden bzw. absegnen. Und wenn du Projektleitung bist, dann ist das dein Schutzraum. Also deine, ich komme aus dem Gefängnisfreie Karte, könnte man sagen. Und wenn du Sponsor bist, dann ist es dein Job. So einfach ist es. Also der Sponsor, der Auftraggeber, der kann sich nicht einfach die ganze Zeit rausziehen, sondern es ist dein Job, mit dafür zu sorgen, dass das Projekt auf Kuss bleibt. Und wenn du das nicht machst, dann brauchst du dich auch nicht wundern, dass Projekte eben irgendwie in Schieflage hängen. So, und wie könnte man sowas jetzt in die Realität pushen? Naja, die praktische Frage ist halt, wie kriegen wir das jetzt quasi in die Organisation ohne großen Rollout oder ohne dass wir jetzt eine Reorganisation machen müssen oder sonst irgendwas. Und im Prinzip kannst du das mehr oder weniger in zehn Tagen hinbekommen. Also du baust als erstes am Brief am Briefing an der Erstversion, dann brauchst du Decision Rights und Log, dann brauchst du das Board und das WIP-Limit, dann die Risiken und Annahmen mit Tests plus das Dashboard. Und dann machst du mal so ein erstes Heartbeat-Meeting. Und dann machst du ein Demo und ein Review-Meeting dementsprechend. Das ist durchaus in zehn Tagen machbar. Ich packe dir das Ganze auch nochmal in die Shownotes mit rein, beziehungsweise wenn dich das mehr interessiert, wie man sowas ausrollen und einfassen kann. Dann gib mir einfach Bescheid. Und du wirst eventuell sagen, ja, aber ich brauche dafür Sponsor-Support. Und das ist richtig. Hier ist deine Sprache nach oben, beziehungsweise deine drei Sätze, die nicht bettelnd sind, sondern führend. Also du gehst in Führung, führen ohne disziplinarische Macht, das können wir im Projekt. Wäre der Satz 1. Und das ist sozusagen Diagnose. Wir haben kein Methodenproblem. Wir haben ein Steuerungsproblem und fehlt ein Projektbetriebssystem. Zweiter Satz, ganz konkret: Ich will in zehn Tagen so ein Betriebssystem aufsetzen mit einem Briefing, mit einem Board, mit einem Decision-Log, mit einem Fünf-Zahlen-Dashboard plus drei Routinen. Das kostet wenig, relativ wenig und macht uns entscheidungsfähig. Und dann vielleicht noch so eine kleine Anforderung an die Führung. Das wäre der dritte Satz. Ich brauche von dir dafür zwei Dinge. Klare Entscheidungsrechte und einen monatlichen Decision-Slot. Sonst liefern wir Status, aber keine Steuerung. So, und damit hättest du schon fast durch die Hintertür die Grundlage für ein funktionierendes. Und Hintertür meine ich jetzt gar nicht hinterlistig, sondern du hättest auf ganz schlankem Fuß die Grundlage gelegt für ein möglicherweise schon gut funktionierendes oder zumindest gut startendes System, mit dem ihr Projekte bearbeiten könnt. Übrigens, noch ganz wichtig für alle die, die sagen, irgendwo gibt es ein Projektmanagement-Handbuch. Ich weiß aber auch nicht genau, wo und was drinsteht. Sorry, ihr habt dann halt keins. Weil ein Projektmanagement oder ein Projektmanagement-Handbuch zeichnet sich dadurch aus, dass es in der gesamten Organisation von allen verstanden und von allen umgesetzt ist. Und wenn es das nicht ist, dann ist es halt nicht da. Sorry, sorry, sorry, sorry. Und deswegen sind diese drei Sätze, also die Systemdiagnose konkret, was du machen willst und die Anforderungen an Führung, die sind super fair, die sind super professionell und sie sind darüber hinaus auch die Wahrheit. Und das ist das Entscheidende. Und ich könnte dir, nein, ich mach das jetzt einfach. Ich gebe dir mal hier jetzt einen ganz kurzen Selbstcheck rein. Ehrlich und nicht politisch. Also du gehst einfach mit mir hier kurz durch und genießt mal die Fragen, die ich dir jetzt gleich stelle. Und zwar haben wir eine Seite, also so ein One-Pager, Klarheit, Outcome, Constraints, Definition of Done oder nur Folien? Ja, nein, kein vielleicht. Haben wir eine Wahrheit, ein Board oder Dashboard? Fünf Tools oder gar zehn Charts? Also es geht darum, haben wir ein Board, ein Dashboard oder haben wir fünf Tools und zehn Charts? Ne? Janai, vielleicht. Werden Entscheidungen mit Frist getroffen oder per Schweigen? Reduzieren wir Unsicherheit aktiv durch Tests oder hoffen wir auf den Plan? Und wird Arbeit fertig oder sind alle 100% ausgelastet und nichts ist erledigt, beziehungsweise dann. Und wenn du bei zwei oder mehr dieser Fragen zögerst, dann kein Vorwurf, dann ist das ein Signal, das euch eben genau. ein solches operating system fehlt und ich fasse dir das ganze jetzt mal in einem satz zusammen du kannst jedes projekt mit jeder methode fahren solange das betriebssystem klarheit entscheidungen feedback und flow absichert und dazu jetzt meine endfrage für diese folge an dich welche entscheidung braucht dein projekt diese woche und wo versteckst du dich gerade hinter status statt entscheidungen einzufordern und damit schließe ich heute diese folge von einfach projekte und sag wieder herzlichen Dank dass du wieder mit dabei warst schalte gerne wieder ein bleib dabei abonniere und teile gerne auch einfach projekte oder kommentiere auch gern und ich wünsche dir bis wir uns das nächste mal wieder hören einfach allseits erfolgreiche projekte bis dann vielen Dank dass du heute mit dabei warst und schalte einfach das nächste mal wieder ein wenn das heißt einfach Projekte